From trac+core@trac.tools.ietf.org Thu Mar 1 07:55:53 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DA621E8212 for ; Thu, 1 Mar 2012 07:55:53 -0800 (PST) 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.012, 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 gyO6GrzifTHt for ; Thu, 1 Mar 2012 07:55:53 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3189221E8202 for ; Thu, 1 Mar 2012 07:55:52 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S38M9-0001mb-FU; Thu, 01 Mar 2012 10:55:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: hartke@tzi.org, cabo@tzi.org X-Trac-Project: core Date: Thu, 01 Mar 2012 15:55:48 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/174#comment:5 Message-ID: <068.2ca414261d166b91f3f6706f58febc26@trac.tools.ietf.org> References: <053.70316ef76a2aab1204bc99bad86807ea@trac.tools.ietf.org> X-Trac-Ticket-ID: 174 In-Reply-To: <053.70316ef76a2aab1204bc99bad86807ea@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #174: Robust observation relationships 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, 01 Mar 2012 15:55:53 -0000 #174: Robust observation relationships Comment (by hartke@…): Replace the penultimate paragraph of section 3.4 with the following two paragraphs: To make sure it has a fresh representation and/or to re-register its interest, a client MAY issue a new GET request with an Observe Option at any time. The GET request SHOULD specify a new token to avoid ambiguity, because the token serves as epoch identifier for the sequence numbers in the Observe Option (see Section 3.4). It is RECOMMENDED that the client does not issue the request while it still has a fresh notification and, beyond that, while a new notification from the server is still likely to arrive. I.e. the client should wait until the age of the last notification becomes greater than its Max-Age plus the potential retransmission window (see Section 4.1 of [I-D.ietf- core-coap]) plus the expected maximum round trip time. -- -----------------------------------+----------------------- Reporter: hartke@… | Owner: hartke@… Type: protocol defect | Status: reopened Priority: major | Milestone: Component: observe | Version: Severity: Submitted WG Document | Resolution: Keywords: | -----------------------------------+----------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Mar 1 08:04:59 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A810B21E80B1 for ; Thu, 1 Mar 2012 08:04:59 -0800 (PST) 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.012, 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 VCqdx1gG8C8W for ; Thu, 1 Mar 2012 08:04:59 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 929E021E805B for ; Thu, 1 Mar 2012 08:04:58 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S38Uz-0001tj-Qq; Thu, 01 Mar 2012 11:04:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org X-Trac-Project: core Date: Thu, 01 Mar 2012 16:04:57 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/184#comment:1 Message-ID: <066.cb6972442c59a937cc7597800417ed51@trac.tools.ietf.org> References: <051.1d985a98083f5d7102ae3d8bf240deb7@trac.tools.ietf.org> X-Trac-Ticket-ID: 184 In-Reply-To: <051.1d985a98083f5d7102ae3d8bf240deb7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120301160458.929E021E805B@ietfa.amsl.com> Resent-Date: Thu, 1 Mar 2012 08:04:58 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #184: Add implementation note to 3.5 about careless GETs 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, 01 Mar 2012 16:04:59 -0000 #184: Add implementation note to 3.5 about careless GETs Comment (by hartke@…): At the end of section 3.5, add: Implementation note: A client that does not mediate all its requests through its cache might inadvertantly cancel an observation relationship by sending an unrelated GET to the same resource. To avoid this, without incurring a need for synchronization, such clients can use a different source transport address for these unrelated GET requests. -- --------------------------------+---------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-observe@… Type: editorial | Status: new Priority: minor | Milestone: Component: observe | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------+---------------------------------------- Ticket URL: core From bnordman@lbl.gov Thu Mar 1 12:36:54 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54CB21E8304 for ; Thu, 1 Mar 2012 12:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.694 X-Spam-Level: X-Spam-Status: No, score=-5.694 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 z1dQguGIWNJ4 for ; Thu, 1 Mar 2012 12:36:53 -0800 (PST) Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3B40D21E832B for ; Thu, 1 Mar 2012 12:36:53 -0800 (PST) X-Ironport-SBRS: 4.4 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4BAPzcT0/RVdQ0kGdsb2JhbABAA4JEqFIBiGcIIgEBAQEJCQ0HFAQjgX0BAhYCgQsGAwECURIBBQEUIQgah2QLmFmCXQqdIY0KCgIBCgIBUwsBAgEChFkOEgwBDQoyDQEGDwMbgycEiE+MbI4yPYJUgVA X-IronPort-AV: E=Sophos;i="4.73,511,1325491200"; d="scan'208";a="66804002" Received: from mail-vw0-f52.google.com ([209.85.212.52]) by ironport4.lbl.gov with ESMTP; 01 Mar 2012 12:36:52 -0800 Received: by vbih1 with SMTP id h1so1388044vbi.39 for ; Thu, 01 Mar 2012 12:36:52 -0800 (PST) Received-SPF: pass (google.com: domain of bnordman@lbl.gov designates 10.52.174.162 as permitted sender) client-ip=10.52.174.162; Authentication-Results: mr.google.com; spf=pass (google.com: domain of bnordman@lbl.gov designates 10.52.174.162 as permitted sender) smtp.mail=bnordman@lbl.gov Received: from mr.google.com ([10.52.174.162]) by 10.52.174.162 with SMTP id bt2mr11143769vdc.56.1330634212213 (num_hops = 1); Thu, 01 Mar 2012 12:36:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.174.162 with SMTP id bt2mr9456016vdc.56.1330634212096; Thu, 01 Mar 2012 12:36:52 -0800 (PST) Received: by 10.220.149.209 with HTTP; Thu, 1 Mar 2012 12:36:51 -0800 (PST) Date: Thu, 1 Mar 2012 12:36:51 -0800 Message-ID: From: Bruce Nordman To: core@ietf.org Content-Type: multipart/alternative; boundary=bcaec51dd81389ba4204ba346bef X-Gm-Message-State: ALoCoQmL/FzeDJQtxVjKL2ferSpeK7g7fPSwXloyZ7UA8aoCR9AlsSUv0ASUKy7qaQ39R13sjVpw Subject: [core] sleepy to sleepy communication 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: Thu, 01 Mar 2012 20:36:55 -0000 --bcaec51dd81389ba4204ba346bef Content-Type: text/plain; charset=ISO-8859-1 Hi all-- I don't have a comment on the substance of this topic, but just on terminology. I have worked for many years on saving energy in mains-powered devices, and found terminology on power state important to pay attention to. I have not worked on low-power sensors, but I think some of the lessons apply. I would only suggest that the requirement be changed from "powered off" to "powered down". "Down" is ambiguous as to whether it is to sleep or off, but the following sentence makes clear that the device is asleep since it wakes up. A device that is off needs to be turned on - a sleeping device can be wake itself up (on timer or local activity), or possibly be woken from the network (not all devices will support this). The distinction is that we would expect a wider range of events to trigger a wake than to trigger a turn-on, and a shorter latency on coming back from sleep than from turning on. Not all devices have all three states (on, sleep, off) - many have just on and sleep and many others just on and off. Some devices are always on. (Disconnection from all power sources, including internal batteries, will turn a device off so all devices have this sort of off mode) Thanks, --Bruce ---------- Forwarded message ---------- From: Thomas Fossati To: core WG Cc: Date: Wed, 29 Feb 2012 22:46:58 +0100 Subject: [core] sleepy to sleepy communication I-Ds Hello all, today we have submitted a couple of I-Ds proposing three new CoAP Options that try dealing with the requirement REQ3 of draft-shelby-core-coap-req-04 The ability to deal with sleeping nodes. Devices may be powered off at any point in time but periodically "wake up" for brief periods of time. leveraging on different techniques, i.e. store-and-forward, explicit origin delegation, REST interface to carbon-copy an observed resource. Their URIs and respective abstracts are given in the following for convenience: (1) "Sleepy Option for CoAP" (see http://tools.ietf.org/html/draft-giacomin-core-sleepy-option-00) This draft defines a new CoAP elective option, Sleepy, targeted specifically at proxies and used to signal a proxy the will to initiate an asynchronous request/response exchange. The Sleepy option is partitioned in 2/3 subfields indicating: the remaining time before sleep, the expected sleep interval, and (optionally) the on-duty interval. ..... -- *Bruce Nordman* Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --bcaec51dd81389ba4204ba346bef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all--

=A0 I don't have a comment on the substance of this top= ic, but just on terminology.
I have worked for many years on saving ener= gy in mains-powered devices, and
found terminology on power state import= ant to pay attention to.=A0 I have not worked
on low-power sensors, but I think some of the lessons apply.

=A0 I w= ould only suggest that the requirement be changed from "powered off&qu= ot; to "powered
down".=A0 "Down" is ambiguous as to = whether it is to sleep or off, but the following
sentence makes clear that the device is asleep since it wakes up.=A0 A devi= ce that
is off needs to be turned on - a sleeping device can be wake its= elf up (on timer or
local activity), or possibly be woken from the netwo= rk (not all devices will support this).

=A0 The distinction is that we would expect a wider range of events to = trigger a wake
than to trigger a turn-on, and a shorter latency on comin= g back from sleep than
from turning on.

=A0 Not all devices have = all three states (on, sleep, off) - many have just on and sleep
and many others just on and off.=A0 Some devices are always on.=A0 (Disconn= ection from
all power sources, including internal batteries, will turn a= device off so all devices have
this sort of off mode)

=A0 Thanks= ,

--Bruce
=A0

---------- Forwarded message ----------
From:= =A0Thomas Fossati <tho@koanlogic.co= m>
To:=A0core WG <core@ietf.o= rg>
Cc:=A0
Date:=A0Wed, 29 Feb 2012 22:46:58 +0100
Subject:=A0[core] slee= py to sleepy communication I-Ds
Hello all,

today we have submitted a couple of I-Ds proposing three new CoAP=20 Options that try dealing with the requirement REQ3 of=20 draft-shelby-core-coap-req-04

=A0 =A0The ability to deal with sleeping nodes. =A0Devices may be
=A0 =A0powered off at any point in time but periodically "wake up&quo= t;
=A0 =A0for brief periods of time.

leveraging on different techniques, i.e. store-and-forward, explicit=20 origin delegation, REST interface to carbon-copy an observed resource.
<= br>
Their URIs and respective abstracts are given in the following for c= onvenience:

(1) "Sleepy Option for CoAP" (see http://tools= .ietf.org/html/draft-giacomin-core-sleepy-option-00)

This draft defines a new CoAP elective option, Sleepy, targeted=20 specifically at proxies and used to signal a proxy the will to initiate=20 an asynchronous request/response exchange. =A0The Sleepy option is=20 partitioned in 2/3 subfields indicating: the remaining time before=20 sleep, the expected sleep interval, and (optionally) the on-duty=20 interval.
.....


--
Bruce NordmanLawrence Berkeley National Laboratory<= /span>
eetd= .lbl.gov/ea/nordman
BNordman@LBL.gov
510-486-7089
m: 510-501-7943

--bcaec51dd81389ba4204ba346bef-- From salvatore.loreto@ericsson.com Thu Mar 1 13:03:03 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFCF21E8021 for ; Thu, 1 Mar 2012 13:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.815 X-Spam-Level: X-Spam-Status: No, score=-109.815 tagged_above=-999 required=5 tests=[AWL=0.783, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4OKlPfzOggt for ; Thu, 1 Mar 2012 13:03:02 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE4E21E8085 for ; Thu, 1 Mar 2012 13:03:01 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-b4-4f4fe4048338 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 0D.E9.01970.404EF4F4; Thu, 1 Mar 2012 22:03:00 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Thu, 1 Mar 2012 22:02:59 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 981F22321; Thu, 1 Mar 2012 23:02:59 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7EB0952396; Thu, 1 Mar 2012 23:02:59 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2F06252171; Thu, 1 Mar 2012 23:02:59 +0200 (EET) Message-ID: <4F4FE403.8060205@ericsson.com> Date: Thu, 1 Mar 2012 23:02:59 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Bruce Nordman References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000701030209050803080601" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: "core@ietf.org" Subject: Re: [core] sleepy to sleepy communication 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: Thu, 01 Mar 2012 21:03:03 -0000 --------------000701030209050803080601 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi Bruce, thanks a lot for your terminology comment... that is for sure something that we will adjust in a next version as well as we need text explaining the fact that there are differences in how the sensor go to sleep or in another way that different sensor go to sleep in a different way e.g. just turning off the radio to save the battery can be considered a sleep actually we were already discussing, during the writing of the drafts, the eventual implications of the different way to go to sleep on the design of the Options but we decided to do it later as well hopefully with the help of the community cheers Salvatore -- Salvatore Loreto www.sloreto.com On 3/1/12 10:36 PM, Bruce Nordman wrote: > Hi all-- > > I don't have a comment on the substance of this topic, but just on > terminology. > I have worked for many years on saving energy in mains-powered > devices, and > found terminology on power state important to pay attention to. I > have not worked > on low-power sensors, but I think some of the lessons apply. > > I would only suggest that the requirement be changed from "powered > off" to "powered > down". "Down" is ambiguous as to whether it is to sleep or off, but > the following > sentence makes clear that the device is asleep since it wakes up. A > device that > is off needs to be turned on - a sleeping device can be wake itself up > (on timer or > local activity), or possibly be woken from the network (not all > devices will support this). > > The distinction is that we would expect a wider range of events to > trigger a wake > than to trigger a turn-on, and a shorter latency on coming back from > sleep than > from turning on. > > Not all devices have all three states (on, sleep, off) - many have > just on and sleep > and many others just on and off. Some devices are always on. > (Disconnection from > all power sources, including internal batteries, will turn a device > off so all devices have > this sort of off mode) > > Thanks, > > --Bruce > > > ---------- Forwarded message ---------- > From: Thomas Fossati > > To: core WG > > Cc: > Date: Wed, 29 Feb 2012 22:46:58 +0100 > Subject: [core] sleepy to sleepy communication I-Ds > Hello all, > > today we have submitted a couple of I-Ds proposing three new CoAP > Options that try dealing with the requirement REQ3 of > draft-shelby-core-coap-req-04 > > The ability to deal with sleeping nodes. Devices may be > powered off at any point in time but periodically "wake up" > for brief periods of time. > > leveraging on different techniques, i.e. store-and-forward, explicit > origin delegation, REST interface to carbon-copy an observed resource. > > > Their URIs and respective abstracts are given in the following for > convenience: > > (1) "Sleepy Option for CoAP" (see > http://tools.ietf.org/html/draft-giacomin-core-sleepy-option-00) > > This draft defines a new CoAP elective option, Sleepy, targeted > specifically at proxies and used to signal a proxy the will to > initiate an asynchronous request/response exchange. The Sleepy option > is partitioned in 2/3 subfields indicating: the remaining time before > sleep, the expected sleep interval, and (optionally) the on-duty interval. > ..... > > > -- > *Bruce Nordman* > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > --------------000701030209050803080601 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi Bruce,

thanks a lot for your terminology comment...
that is for sure something that we will adjust in a next version
as well as we need text explaining the fact
that there are differences in how the sensor go to sleep
or in another way that different sensor go to sleep in a different way
e.g. just turning off the radio to save the battery can be considered a sleep


actually we were already discussing, during the writing of the drafts, the eventual
implications of the different way to go to sleep on the design of the Options
but we decided to do it later as well
hopefully with the help of the community

cheers
Salvatore

-- 
Salvatore Loreto
www.sloreto.com


On 3/1/12 10:36 PM, Bruce Nordman wrote:
Hi all--

  I don't have a comment on the substance of this topic, but just on terminology.
I have worked for many years on saving energy in mains-powered devices, and
found terminology on power state important to pay attention to.  I have not worked
on low-power sensors, but I think some of the lessons apply.

  I would only suggest that the requirement be changed from "powered off" to "powered
down".  "Down" is ambiguous as to whether it is to sleep or off, but the following
sentence makes clear that the device is asleep since it wakes up.  A device that
is off needs to be turned on - a sleeping device can be wake itself up (on timer or
local activity), or possibly be woken from the network (not all devices will support this).

  The distinction is that we would expect a wider range of events to trigger a wake
than to trigger a turn-on, and a shorter latency on coming back from sleep than
from turning on.

  Not all devices have all three states (on, sleep, off) - many have just on and sleep
and many others just on and off.  Some devices are always on.  (Disconnection from
all power sources, including internal batteries, will turn a device off so all devices have
this sort of off mode)

  Thanks,

--Bruce
 

---------- Forwarded message ----------
From: Thomas Fossati <tho@koanlogic.com>
To: core WG <core@ietf.org>
Cc: 
Date: Wed, 29 Feb 2012 22:46:58 +0100
Subject: [core] sleepy to sleepy communication I-Ds
Hello all,

today we have submitted a couple of I-Ds proposing three new CoAP Options that try dealing with the requirement REQ3 of draft-shelby-core-coap-req-04

   The ability to deal with sleeping nodes.  Devices may be
   powered off at any point in time but periodically "wake up"
   for brief periods of time.

leveraging on different techniques, i.e. store-and-forward, explicit origin delegation, REST interface to carbon-copy an observed resource.


Their URIs and respective abstracts are given in the following for convenience:

(1) "Sleepy Option for CoAP" (see http://tools.ietf.org/html/draft-giacomin-core-sleepy-option-00)

This draft defines a new CoAP elective option, Sleepy, targeted specifically at proxies and used to signal a proxy the will to initiate an asynchronous request/response exchange.  The Sleepy option is partitioned in 2/3 subfields indicating: the remaining time before sleep, the expected sleep interval, and (optionally) the on-duty interval.
.....


--
Bruce Nordman
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
BNordman@LBL.gov
510-486-7089
m: 510-501-7943



--------------000701030209050803080601-- From bnordman@lbl.gov Thu Mar 1 13:56:18 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A803521E82BA for ; Thu, 1 Mar 2012 13:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 naoPVuNxTr1F for ; Thu, 1 Mar 2012 13:56:17 -0800 (PST) Received: from ironport4.lbl.gov (ironport4.lbl.gov [128.3.41.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC5721E82AB for ; Thu, 1 Mar 2012 13:56:17 -0800 (PST) X-Ironport-SBRS: 5.2 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjICAL7vT0/RVdy0mGdsb2JhbAA5BwOCRKhVAYhnCCIBAQEBAQgJDQcUJ4F9AQEBAwESAjUwBQsLCwYDAQIBLiISAQUBFAgGExQOh18FC5tZCp0fiX2DCwIKAgEEAQMCAgEKSQsBAgEChFkOBgkDAgsNCi8DDQEGCAMEAwcKCoMnBIhPiQ6DXo4yPYQk X-IronPort-AV: E=Sophos;i="4.73,513,1325491200"; d="scan'208";a="66817830" Received: from mail-vx0-f180.google.com ([209.85.220.180]) by ironport4.lbl.gov with ESMTP; 01 Mar 2012 13:56:16 -0800 Received: by vcbf13 with SMTP id f13so459661vcb.39 for ; Thu, 01 Mar 2012 13:56:16 -0800 (PST) Received-SPF: pass (google.com: domain of bnordman@lbl.gov designates 10.52.64.234 as permitted sender) client-ip=10.52.64.234; Authentication-Results: mr.google.com; spf=pass (google.com: domain of bnordman@lbl.gov designates 10.52.64.234 as permitted sender) smtp.mail=bnordman@lbl.gov Received: from mr.google.com ([10.52.64.234]) by 10.52.64.234 with SMTP id r10mr11650751vds.39.1330638976416 (num_hops = 1); Thu, 01 Mar 2012 13:56:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.64.234 with SMTP id r10mr9900714vds.39.1330638976207; Thu, 01 Mar 2012 13:56:16 -0800 (PST) Received: by 10.220.149.209 with HTTP; Thu, 1 Mar 2012 13:56:16 -0800 (PST) In-Reply-To: <4F4FE403.8060205@ericsson.com> References: <4F4FE403.8060205@ericsson.com> Date: Thu, 1 Mar 2012 13:56:16 -0800 Message-ID: From: Bruce Nordman To: Salvatore Loreto Content-Type: multipart/alternative; boundary=20cf307ac775804ced04ba358746 X-Gm-Message-State: ALoCoQnPTcpjR2Bui51/RLtzRenBl73fs76wkJU7wlvmYsr2dTUbeMUwnu8UYvDh2MHbB9z5EmzB Cc: "core@ietf.org" Subject: Re: [core] sleepy to sleepy communication 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: Thu, 01 Mar 2012 21:56:18 -0000 --20cf307ac775804ced04ba358746 Content-Type: text/plain; charset=ISO-8859-1 In some contexts it has been helpful to identify "light sleep" vs. "deep sleep" when there are two sub-states with different characteristics. Beyond two, the terminology gets trickier. It is probably already in the various drafts but it is important to distinguish the link state from the device power state. Energy Efficient Ethernet (IEEE 802.3az) created a sleep state for Ethernet with quick sleep/wake times (as opposed to a link disconnected state with very long renegotiation of the link). On PCs, the link state and the system power state are completely independent. Turning off the radio on a duty cycle sounds like a link sleep state that enables faster reestablishment of the link than from a no-link state. I have found that it is difficult to impose detailed requirements on the specifics of power states across a wide variety of devices, but CORE's clarity on this for CoAP low-power devices will be of great help in future. Thanks, --Bruce On Thu, Mar 1, 2012 at 1:02 PM, Salvatore Loreto < salvatore.loreto@ericsson.com> wrote: > Hi Bruce, > > thanks a lot for your terminology comment... > that is for sure something that we will adjust in a next version > as well as we need text explaining the fact > that there are differences in how the sensor go to sleep > or in another way that different sensor go to sleep in a different way > e.g. just turning off the radio to save the battery can be considered a > sleep > > > actually we were already discussing, during the writing of the drafts, the > eventual > implications of the different way to go to sleep on the design of the > Options > but we decided to do it later as well > hopefully with the help of the community > > cheers > Salvatore > > -- > Salvatore Loretowww.sloreto.com > > > > On 3/1/12 10:36 PM, Bruce Nordman wrote: > > Hi all-- > > I don't have a comment on the substance of this topic, but just on > terminology. > I have worked for many years on saving energy in mains-powered devices, and > found terminology on power state important to pay attention to. I have > not worked > on low-power sensors, but I think some of the lessons apply. > > I would only suggest that the requirement be changed from "powered off" > to "powered > down". "Down" is ambiguous as to whether it is to sleep or off, but the > following > sentence makes clear that the device is asleep since it wakes up. A > device that > is off needs to be turned on - a sleeping device can be wake itself up (on > timer or > local activity), or possibly be woken from the network (not all devices > will support this). > > The distinction is that we would expect a wider range of events to > trigger a wake > than to trigger a turn-on, and a shorter latency on coming back from sleep > than > from turning on. > > Not all devices have all three states (on, sleep, off) - many have just > on and sleep > and many others just on and off. Some devices are always on. > (Disconnection from > all power sources, including internal batteries, will turn a device off so > all devices have > this sort of off mode) > > Thanks, > > --Bruce > > > ---------- Forwarded message ---------- > From: Thomas Fossati > To: core WG > Cc: > Date: Wed, 29 Feb 2012 22:46:58 +0100 > Subject: [core] sleepy to sleepy communication I-Ds > Hello all, > > today we have submitted a couple of I-Ds proposing three new CoAP Options > that try dealing with the requirement REQ3 of draft-shelby-core-coap-req-04 > > The ability to deal with sleeping nodes. Devices may be > powered off at any point in time but periodically "wake up" > for brief periods of time. > > leveraging on different techniques, i.e. store-and-forward, explicit > origin delegation, REST interface to carbon-copy an observed resource. > > > Their URIs and respective abstracts are given in the following for > convenience: > > (1) "Sleepy Option for CoAP" (see > http://tools.ietf.org/html/draft-giacomin-core-sleepy-option-00) > > This draft defines a new CoAP elective option, Sleepy, targeted > specifically at proxies and used to signal a proxy the will to initiate an > asynchronous request/response exchange. The Sleepy option is partitioned > in 2/3 subfields indicating: the remaining time before sleep, the expected > sleep interval, and (optionally) the on-duty interval. > ..... > > > -- > *Bruce Nordman* > Lawrence Berkeley National Laboratory > eetd.lbl.gov/ea/nordman > BNordman@LBL.gov > 510-486-7089 > m: 510-501-7943 > > > > -- *Bruce Nordman* Lawrence Berkeley National Laboratory eetd.lbl.gov/ea/nordman BNordman@LBL.gov 510-486-7089 m: 510-501-7943 --20cf307ac775804ced04ba358746 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In some contexts it has been helpful to identify "light sleep" vs= . "deep sleep" when
there are two sub-states with different ch= aracteristics.=A0 Beyond two, the terminology gets trickier.

It is p= robably already in the various drafts but it is important to distinguish th= e link
state from the device power state.=A0 Energy Efficient Ethernet (IEEE 802.3= az) created
a sleep state for Ethernet with quick sleep/wake times (as o= pposed to a link disconnected
state with very long renegotiation of the = link).=A0 On PCs, the link state and the system
power state are completely independent.=A0 Turning off the radio on a duty = cycle sounds
like a link sleep state that enables faster reestablishment= of the link than from a no-link state.

I have found that it is diff= icult to impose detailed requirements on the specifics of
power states across a wide variety of devices, but CORE's clarity on th= is for CoAP
low-power devices will be of great help in future.

Th= anks,

--Bruce

On Thu, Mar 1, 2012 = at 1:02 PM, Salvatore Loreto <salvatore.loreto@ericsson.com> wrote:
=20 =20 =20
Hi Bruce,

thanks a lot for your terminology comment...
that is for sure something that we will adjust in a next version
as well as we need text explaining the fact
that there are differences in how the sensor go to sleep
or in another way that different sensor go to sleep in a different way
e.g. just turning off the radio to save the battery can be considered a sleep


actually we were already discussing, during the writing of the drafts, the eventual
implications of the different way to go to sleep on the design of the Options
but we decided to do it later as well
hopefully with the help of the community

cheers
Salvatore

--=20
Salvatore Loreto
www.sloreto.com

    

    

    On 3/1/12 10:36 PM, Bruce Nordman wrote:
    
Hi all--

      

      =A0 I don't have a comment on the substance of this topic, but ju=
st
      on terminology.

      I have worked for many years on saving energy in mains-powered
      devices, and

      found terminology on power state important to pay attention to.=A0 I
      have not worked

      on low-power sensors, but I think some of the lessons apply.

      

      =A0 I would only suggest that the requirement be changed from
      "powered off" to "powered

      down".=A0 "Down" is ambiguous as to whether it is to s=
leep or off,
      but the following

      sentence makes clear that the device is asleep since it wakes up.=A0
      A device that

      is off needs to be turned on - a sleeping device can be wake
      itself up (on timer or

      local activity), or possibly be woken from the network (not all
      devices will support this).

      

      =A0 The distinction is that we would expect a wider range of events
      to trigger a wake

      than to trigger a turn-on, and a shorter latency on coming back
      from sleep than

      from turning on.

      

      =A0 Not all devices have all three states (on, sleep, off) - many
      have just on and sleep

      and many others just on and off.=A0 Some devices are always on.=A0
      (Disconnection from

      all power sources, including internal batteries, will turn a
      device off so all devices have

      this sort of off mode)

      

      =A0 Thanks,

      

      --Bruce

      =A0 

      

      ---------- Forwarded message ----------

      From:=A0Thomas Fossati <tho@koanlogic.com>

      To:=A0core WG <=
core@ietf.org>

      Cc:=A0

      Date:=A0Wed, 29 Feb 2012 22:46:58 +0100

      Subject:=A0[core] sleepy to sleepy communication I-Ds

      Hello all,

      

      today we have submitted a couple of I-Ds proposing three new CoAP
      Options that try dealing with the requirement REQ3 of
      draft-shelby-core-coap-req-04

      

      =A0 =A0The ability to deal with sleeping nodes. =A0Devices may be

      =A0 =A0powered off at any point in time but periodically "wake u=
p"

      =A0 =A0for brief periods of time.

      

      leveraging on different techniques, i.e. store-and-forward,
      explicit origin delegation, REST interface to carbon-copy an
      observed resource.

      

      

      Their URIs and respective abstracts are given in the following for
      convenience:

      

      (1) "Sleepy Option for CoAP" (see http:/=
/tools.ietf.org/html/draft-giacomin-core-sleepy-option-00)

      

      This draft defines a new CoAP elective option, Sleepy, targeted
      specifically at proxies and used to signal a proxy the will to
      initiate an asynchronous request/response exchange. =A0The Sleepy
      option is partitioned in 2/3 subfields indicating: the remaining
      time before sleep, the expected sleep interval, and (optionally)
      the on-duty interval.

      .....

      

      

      -- 

      Bruce Nordman

      Lawrence Berkeley National
        Laboratory

      eetd.lbl=
.gov/ea/nordman

      BNordman@LBL.go=
v

      510-486-7089

      m: 510-501-7943



--
Bru= ce Nordman
Lawrence Berkel= ey National Laboratory
eetd.lbl.gov/ea/nordman
BNordman@LBL.gov
510-486-7089
m: 510-501-7943

--20cf307ac775804ced04ba358746-- From mab@comnets.uni-bremen.de Fri Mar 2 00:07:50 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF3F21E805C for ; Fri, 2 Mar 2012 00:07:50 -0800 (PST) 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 XTII7uh9ioWB for ; Fri, 2 Mar 2012 00:07:49 -0800 (PST) Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [134.102.186.10]) by ietfa.amsl.com (Postfix) with ESMTP id E248F21E8056 for ; Fri, 2 Mar 2012 00:07:44 -0800 (PST) Received: from shelbyville.comnets.uni-bremen.de (shelbyville [10.10.155.50]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTPS id CB303D4018C for ; Fri, 2 Mar 2012 09:07:42 +0100 (CET) From: Markus Becker Organization: Comnets, University Bremen To: core@ietf.org Date: Fri, 2 Mar 2012 09:07:41 +0100 User-Agent: KMail/1.13.7 (Linux/3.2.0-1-686-pae; KDE/4.7.4; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201203020907.42200.mab@comnets.uni-bremen.de> Subject: [core] Fwd: New Version Notification for draft-becker-core-coap-sms-gprs-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: Fri, 02 Mar 2012 08:07:50 -0000 Dear core WG, we have updated the draft on how to transport CoAP over SMS by merging Kepeng's draft-li-core-coap-over-sms-00 and my draft-becker-core-coap-sms- gprs-00 and additionally included also the CoAP transport over USSD. We are looking forward to discussing the draft on the mailing list and in Paris. Best regards, Markus > A new version of I-D, draft-becker-core-coap-sms-gprs-01.txt has been > successfully submitted by Markus Becker and posted to the IETF repository. > > Filename: draft-becker-core-coap-sms-gprs > Revision: 01 > Title: Transport of CoAP over SMS, USSD and GPRS > Creation date: 2012-03-01 > WG ID: Individual Submission > Number of pages: 14 > > Abstract: > The Short Message Service (SMS) and Unstructured Supplementary > Service Data (USSD) of mobile cellular networks is frequently used in > Machine-To-Machine (M2M) communications, such as for telematic > devices. The service offers small packet sizes and high delays just > as other typical low-power and lossy networks (LLNs), i.e. 6LoWPANs. > The design of the Constrained Application Protocol (CoAP), that took > the limitations of LLNs into account, is thus also applicable to > telematic M2M devices. The adaptation of CoAP to the SMS or USSD > transport mechanisms and the combination with IP transported over > cellular networks is described in this document. > > > > > The IETF Secretariat From kovatsch@inf.ethz.ch Fri Mar 2 04:20:48 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6365E21F8B6C for ; Fri, 2 Mar 2012 04:20:48 -0800 (PST) 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 0E38XyeZxylZ for ; Fri, 2 Mar 2012 04:20:46 -0800 (PST) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 66E6021F8B56 for ; Fri, 2 Mar 2012 04:20:43 -0800 (PST) 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.1.355.2; Fri, 2 Mar 2012 13:20:38 +0100 Received: from MBX10.d.ethz.ch ([169.254.1.91]) by CAS21.d.ethz.ch ([fe80::55ba:c4a5:d8a7:ab62%10]) with mapi id 14.01.0355.002; Fri, 2 Mar 2012 13:20:42 +0100 From: "Kovatsch Matthias" To: "core@ietf.org" Thread-Topic: [core] RST and NON (was Re: explicit observe de-registration) Thread-Index: AQHM67yy3rtQ1zwYeUCRaByC6dtxHpZXAvBw Date: Fri, 2 Mar 2012 12:20:41 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B5139227CB@MBX10.d.ethz.ch> References: <4F3B6E25.8000104@ericsson.com> In-Reply-To: <4F3B6E25.8000104@ericsson.com> Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [178.83.15.45] Content-Type: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B5139227CBMBX10dethzch_" MIME-Version: 1.0 Subject: Re: [core] RST and NON (was Re: explicit observe de-registration) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Mar 2012 12:20:48 -0000 --_000_55877B3AFB359744BA0F2140E36F52B5139227CBMBX10dethzch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear list I still see conflict with RST and NON, especially for observe: Usually, the sender does not store any transaction information for a NON me= ssage (and cannot unless he also introduces timers for NON, which kind of b= reaks the concept). But how should the sender identify the context when a RST arrives in reply = to a NON? The RST has must be empty and there is no matching message ID... Observe makes use of RST to cancel a relationship by the client, but which = one should be removed at server side when it is an answer to a NON notifica= tion? Maybe RSTs should be able to carry the context, so the peer knows what to r= eset? Best regards Matthias Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag von Sa= lvatore Loreto Gesendet: Mittwoch, 15. Februar 2012 09:35 An: core@ietf.org Betreff: [core] RST and NON (was Re: explicit observe de-registration) Hi there, from on the Thomas mail (see below) and the thread discussion related on ho= w to cancel an observation it seems that the core-coap 08 draft needs some text to clarify how the RST= message works and when it is possible to use it. sections seems to imply that RST MUST be used only with confirmable message= s 4.4.4. Reset (RST) A Reset message indicates that a specific confirmable message was received, but some context is missing to properly process it. This condition is usually caused when the receiving node has rebooted and has forgotten some state that would be required to interpret the message. A reset message MUST echo the Message ID of the confirmable message, and MUST be empty. however, section 4.2 states that it MAY be used also with an Unreliable Mes= sage 4.2. Unreliable Messages As a more lightweight alternative, a message can be transmitted less reliably by marking the message as "non-confirmable". A non- confirmable message MUST NOT be acknowledged by the recipient. If a recipient lacks context to process the message properly, it MAY reject the message with a reset message or otherwise MUST silently ignore it. -- Salvatore Loreto www.sloreto.com On 2/13/12 12:35 PM, Thomas Fossati wrote: Wouldn't it be cleaner to have an explicit Observe de-registration request = from the observer to the subject ? It'd work with both CON and NON observations (instead of being CON-only [*]= ) and would be more efficient with sleepy observers, avoiding all the usele= ss retransmission implied by an unreachable node that has entered the sleep= state. Thomas. [*] apropos, section 4.3 of coap-08 seems to imply that RST can be sent in = reply to a NON message, but then 4.4.4 associates RST to CON only (consiste= ntly with the usage in current Observe I-D.). To add some more entropy, th= e changelog says that 05->06 transition included an "Allowed RST message in= reply to a NON message with unexpected token", but I can't see it anywhere= in -08. This all leaves some degree of ambiguity about whether RST is a valid respo= nse to a NON message or not. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --_000_55877B3AFB359744BA0F2140E36F52B5139227CBMBX10dethzch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear list

 <= /p>

I still se= e conflict with RST and NON, especially for observe:

Usually, t= he sender does not store any transaction information for a NON message (and= cannot unless he also introduces timers for NON, which kind of breaks the concept).

But how sh= ould the sender identify the context when a RST arrives in reply to a NON? = The RST has  must be empty and there is no matching message ID…

Observe ma= kes use of RST to cancel a relationship by the client, but which one should= be removed at server side when it is an answer to a NON notification?

Maybe RSTs= should be able to carry the context, so the peer knows what to reset?=

 = ;

Best regar= ds

Matthias

 = ;

 = ;

Von: core-bounces@ietf.org [mai= lto:core-bounces@ietf.org] Im Auftrag von Salvatore Loreto
Gesendet: Mittwoch, 15. Februar 2012 09:35
An: core@ietf.org
Betreff: [core] RST and NON (was Re: explicit observe de-registratio= n)

 

Hi there,

from on the Thomas mail (see below) and the thread discussion related on ho= w to cancel an observation
it seems that the core-coap 08 draft needs some text to clarify how the RST= message works and when it is possible to use it.


sections seems to imply that RST MUST be used only with confirmable message= s

4.4.4.  Reset (RST)
 
   A Reset message indicates that a specific confirmable mes=
sage was
   received, but some context is missing to properly process=
 it.  This
   condition is usually caused when the receiving node has r=
ebooted and
   has forgotten some state that would be required to interp=
ret the
   message.
 
   A reset message MUST echo the Message ID of the confirmab=
le message,
   and MUST be empty.


however, section 4.2 states that it MAY be used also with an Unreliable Mes= sage

4.2.  Unreliable Messages
 
   As a more lightweight alternative, a message can be trans=
mitted less
   reliably by marking the message as "non-confirmable&=
quot;.  A non-
   confirmable message MUST NOT be acknowledged by the recip=
ient.  If a
   recipient lacks context to process the message properly, =
it MAY
   reject the message with a reset message or otherwise MUST=
 silently
   ignore it.




-- 
Salvatore Loreto
www.sloreto.com















On 2/13/12 12:35 PM, Thomas Fossati wrote: 


Wouldn't it be cleaner to have an explicit Observe de-registration req=
uest from the observer to the subject ?


 


It'd work with both CON and NON observations (instead of being CON-onl=
y [*]) and would be more efficient with sleepy observers, avoiding all the =
useless retransmission implied by an unreachable node that has entered the =
sleep state.


 


Thomas.


 


 


[*] apropos, section 4.3 of coap-08 seems to imply that RST can be sen=
t in reply to a NON message, but then 4.4.4 associates RST to CON only (con=
sistently with the usage in current Observe I-D.).  To add some more e=
ntropy, the changelog says that 05->06 transition included an "Allo=
wed RST message in reply to a NON message with unexpected token", but =
I can't see it anywhere in -08.  


This all leaves some degree of ambiguity about whether RST is a valid =
response to a NON message or not.


_______________________________________________


core mailing list


core@ietf.org


https://www.iet=
f.org/mailman/listinfo/core


 
--_000_55877B3AFB359744BA0F2140E36F52B5139227CBMBX10dethzch_-- From kovatsch@inf.ethz.ch Fri Mar 2 04:27:15 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6161021F8B8F for ; Fri, 2 Mar 2012 04:27:15 -0800 (PST) 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 6CImnTdnKP53 for ; Fri, 2 Mar 2012 04:27:13 -0800 (PST) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 45A4F21F8B89 for ; Fri, 2 Mar 2012 04:27:12 -0800 (PST) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 2 Mar 2012 13:27:07 +0100 Received: from MBX10.d.ethz.ch ([169.254.1.91]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.01.0355.002; Fri, 2 Mar 2012 13:27:11 +0100 From: "Kovatsch Matthias" To: "core@ietf.org" Thread-Topic: [core] RST and NON (was Re: explicit observe de-registration) Thread-Index: AQHM67yy3rtQ1zwYeUCRaByC6dtxHpZXAvBwgAAE1lA= Date: Fri, 2 Mar 2012 12:27:11 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B5139227E8@MBX10.d.ethz.ch> References: <4F3B6E25.8000104@ericsson.com> <55877B3AFB359744BA0F2140E36F52B5139227CB@MBX10.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B5139227CB@MBX10.d.ethz.ch> Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [178.83.15.45] Content-Type: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B5139227E8MBX10dethzch_" MIME-Version: 1.0 Subject: Re: [core] RST and NON (was Re: explicit observe de-registration) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Mar 2012 12:27:15 -0000 --_000_55877B3AFB359744BA0F2140E36F52B5139227E8MBX10dethzch_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Or it should be made clear somewhere that a RST resets all relationships fo= r a client (identified by address and port only). Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag von Ko= vatsch Matthias Gesendet: Freitag, 2. M=E4rz 2012 13:21 An: core@ietf.org Betreff: Re: [core] RST and NON (was Re: explicit observe de-registration) Dear list I still see conflict with RST and NON, especially for observe: Usually, the sender does not store any transaction information for a NON me= ssage (and cannot unless he also introduces timers for NON, which kind of b= reaks the concept). But how should the sender identify the context when a RST arrives in reply = to a NON? The RST has must be empty and there is no matching message ID... Observe makes use of RST to cancel a relationship by the client, but which = one should be removed at server side when it is an answer to a NON notifica= tion? Maybe RSTs should be able to carry the context, so the peer knows what to r= eset? Best regards Matthias Von: core-bounces@ietf.org [mailto:core-bounc= es@ietf.org] Im Auftrag von Salvator= e Loreto Gesendet: Mittwoch, 15. Februar 2012 09:35 An: core@ietf.org Betreff: [core] RST and NON (was Re: explicit observe de-registration) Hi there, from on the Thomas mail (see below) and the thread discussion related on ho= w to cancel an observation it seems that the core-coap 08 draft needs some text to clarify how the RST= message works and when it is possible to use it. sections seems to imply that RST MUST be used only with confirmable message= s 4.4.4. Reset (RST) A Reset message indicates that a specific confirmable message was received, but some context is missing to properly process it. This condition is usually caused when the receiving node has rebooted and has forgotten some state that would be required to interpret the message. A reset message MUST echo the Message ID of the confirmable message, and MUST be empty. however, section 4.2 states that it MAY be used also with an Unreliable Mes= sage 4.2. Unreliable Messages As a more lightweight alternative, a message can be transmitted less reliably by marking the message as "non-confirmable". A non- confirmable message MUST NOT be acknowledged by the recipient. If a recipient lacks context to process the message properly, it MAY reject the message with a reset message or otherwise MUST silently ignore it. -- Salvatore Loreto www.sloreto.com On 2/13/12 12:35 PM, Thomas Fossati wrote: Wouldn't it be cleaner to have an explicit Observe de-registration request = from the observer to the subject ? It'd work with both CON and NON observations (instead of being CON-only [*]= ) and would be more efficient with sleepy observers, avoiding all the usele= ss retransmission implied by an unreachable node that has entered the sleep= state. Thomas. [*] apropos, section 4.3 of coap-08 seems to imply that RST can be sent in = reply to a NON message, but then 4.4.4 associates RST to CON only (consiste= ntly with the usage in current Observe I-D.). To add some more entropy, th= e changelog says that 05->06 transition included an "Allowed RST message in= reply to a NON message with unexpected token", but I can't see it anywhere= in -08. This all leaves some degree of ambiguity about whether RST is a valid respo= nse to a NON message or not. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --_000_55877B3AFB359744BA0F2140E36F52B5139227E8MBX10dethzch_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Or it shou= ld be made clear somewhere that a RST resets all relationships for a client= (identified by address and port only).

 = ;

 = ;

Von: core-bounces@ietf.org [mai= lto:core-bounces@ietf.org] Im Auftrag von Kovatsch Matthias
Gesendet: Freitag, 2. M=E4rz 2012 13:21
An: core@ietf.org
Betreff: Re: [core] RST and NON (was Re: explicit observe de-registr= ation)

 

Dear list

 <= /p>

I still se= e conflict with RST and NON, especially for observe:

Usually, t= he sender does not store any transaction information for a NON message (and= cannot unless he also introduces timers for NON, which kind of breaks the concept).

But how sh= ould the sender identify the context when a RST arrives in reply to a NON? = The RST has  must be empty and there is no matching message ID…

Observe ma= kes use of RST to cancel a relationship by the client, but which one should= be removed at server side when it is an answer to a NON notification?

Maybe RSTs= should be able to carry the context, so the peer knows what to reset?=

 = ;

Best regar= ds

Matthias

 = ;

 = ;

Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag von Salvatore Loreto Gesendet: Mittwoch, 15. Februar 2012 09:35
An: core@ietf.org
Betreff: [core] RST and NON (was Re: explicit observe de-registratio= n)

 

Hi there,

from on the Thomas mail (see below) and the thread discussion related on ho= w to cancel an observation
it seems that the core-coap 08 draft needs some text to clarify how the RST= message works and when it is possible to use it.


sections seems to imply that RST MUST be used only with confirmable message= s

4.4.4.  Reset (RST)
 
   A Reset message indicates that a specific confirmable mes=
sage was
   received, but some context is missing to properly process=
 it.  This
   condition is usually caused when the receiving node has r=
ebooted and
   has forgotten some state that would be required to interp=
ret the
   message.
 
   A reset message MUST echo the Message ID of the confirmab=
le message,
   and MUST be empty.


however, section 4.2 states that it MAY be used also with an Unreliable Mes= sage

4.2.  Unreliable Messages
 
   As a more lightweight alternative, a message can be trans=
mitted less
   reliably by marking the message as "non-confirmable&=
quot;.  A non-
   confirmable message MUST NOT be acknowledged by the recip=
ient.  If a
   recipient lacks context to process the message properly, =
it MAY
   reject the message with a reset message or otherwise MUST=
 silently
   ignore it.



-- 
Salvatore Loreto
www.sloreto.com















On 2/13/12 12:35 PM, Thomas Fossati wrote: 


Wouldn't it be cleaner to have an explicit Observe de-registration req=
uest from the observer to the subject ?


 


It'd work with both CON and NON observations (instead of being CON-onl=
y [*]) and would be more efficient with sleepy observers, avoiding all the =
useless retransmission implied by an unreachable node that has entered the =
sleep state.


 


Thomas.


 


 


[*] apropos, section 4.3 of coap-08 seems to imply that RST can be sen=
t in reply to a NON message, but then 4.4.4 associates RST to CON only (con=
sistently with the usage in current Observe I-D.).  To add some more e=
ntropy, the changelog says that 05->06 transition included an "Allo=
wed RST message in reply to a NON message with unexpected token", but =
I can't see it anywhere in -08.  


This all leaves some degree of ambiguity about whether RST is a valid =
response to a NON message or not.


_______________________________________________


core mailing list


core@ietf.org


https://www.iet=
f.org/mailman/listinfo/core


 
--_000_55877B3AFB359744BA0F2140E36F52B5139227E8MBX10dethzch_-- From matthieu.vial@non.schneider-electric.com Fri Mar 2 05:09:47 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D784121F896A for ; Fri, 2 Mar 2012 05:09:47 -0800 (PST) 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 yQu4qHPqzPnL for ; Fri, 2 Mar 2012 05:09:47 -0800 (PST) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6C721F893F for ; Fri, 2 Mar 2012 05:09:44 -0800 (PST) Received: from ateui03.schneider-electric.com ([10.198.21.36]) by mailX03.eud.schneider-electric.com with ESMTP id 2012030214061967-56008 ; Fri, 2 Mar 2012 14:06:19 +0100 To: core WG MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: matthieu.vial@non.schneider-electric.com Message-ID: Date: Fri, 2 Mar 2012 14:09:40 +0100 X-MIMETrack: Serialize by Router on ATEUI03.Schneider-Electric.com/T/SVR/Schneider at 02/03/2012 14:09:43, Serialize complete at 02/03/2012 14:09:43, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 02/03/2012 14:06:19, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 02/03/2012 14:06:20, Serialize complete at 02/03/2012 14:06:20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Subject: [core] Tr : New Version Notification for draft-vial-core-mirror-proxy-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, 02 Mar 2012 13:09:48 -0000 Hello all, Here is another draft dealing with sleepy devices. I will be glad to read your comments and suggestions to improve the=20 document. Best regards, Matthieu Vial ----- R=E9achemin=E9 par Matthieu Vial/FR/Non/Schneider le 02/03/2012 14:01= =20 ----- internet-drafts@ietf.org=20 02/03/2012 13:58 A Matthieu Vial/FR/Non/Schneider@Europe cc Objet New Version Notification for draft-vial-core-mirror-proxy-00.txt A new version of I-D, draft-vial-core-mirror-proxy-00.txt has been=20 successfully submitted by Matthieu Vial and posted to the IETF repository. Filename: draft-vial-core-mirror-proxy Revision: 00 Title: CoRE Mirror Proxy Creation date: 2012-03-02 WG ID: Individual Submission Number of pages: 14 Abstract: This document introduces the concept of Mirror Proxy that enables sleeping devices to participate in a REST architecture despite the fact that they are not web servers. Most constrained devices may sleep during long periods preventing them from acting as traditional web servers. However as client-only endpoints they can rely on a Mirror Proxy to cache and serve the content they provide. =20 The IETF Secretariat =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=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 This email has been scanned by the Symantec Email Security.cloud service. =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=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 cabo@tzi.org Fri Mar 2 05:27:24 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F7221F8B14 for ; Fri, 2 Mar 2012 05:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.42 X-Spam-Level: X-Spam-Status: No, score=-106.42 tagged_above=-999 required=5 tests=[AWL=-0.171, 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 NJbNCRJszc2p for ; Fri, 2 Mar 2012 05:27:24 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 15FA021F8AEB for ; Fri, 2 Mar 2012 05:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q22DRFdU012317; Fri, 2 Mar 2012 14:27:15 +0100 (CET) Received: from [192.168.217.105] (p54899665.dip.t-dialin.net [84.137.150.101]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 95B5D90D; Fri, 2 Mar 2012 14:27:15 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <55877B3AFB359744BA0F2140E36F52B5139227CB@MBX10.d.ethz.ch> Date: Fri, 2 Mar 2012 14:27:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F3B6E25.8000104@ericsson.com> <55877B3AFB359744BA0F2140E36F52B5139227CB@MBX10.d.ethz.ch> To: "Kovatsch Matthias" X-Mailer: Apple Mail (2.1257) Cc: "core@ietf.org" Subject: Re: [core] RST and NON (was Re: explicit observe de-registration) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Mar 2012 13:27:25 -0000 On Mar 2, 2012, at 13:20, Kovatsch Matthias wrote: > The RST [...] must be empty Yes. > and there is no matching message ID=85 Here is the point of confusion: Yes, there is. 2.1: ... Non-confirmable message (NON). These are not acknowledged, but still have a Message ID for duplicate detection; see Figure 3. See also 4.3. But I understand your question: I don't think the current design is exactly beautiful. A normal NON sender implementation will not register that message ID, = because there is nobody that would be interested in any feedback. Here, however, the server being observed *is* interested, so within the = implementation it should pass a flag "please register this MID even = though it is a NON". It would then be able to match back the RST to the NON. Clearly, this is bending the semantics of NON a bit -- you can RST it, = but can't ACK it. I think the right way to handle this conflict is to make reacting to = RSTs that are being sent back for NONs, an implementation decision. If a server doesn't have the means to keep the MID, well, then it will = keep sending NONs despite the incoming RSTs until it finally decides to = probe the observer with CON. So this would be one combination of choices: -- receivers are not obliged to send RST to NON -- senders are not obliged to implement NON-RST-matching -- senders *ARE* obliged to occasionally probe using CON. Another combination: -- receivers *ARE* obliged to send RST on NON they don't know what to do = with -- senders *ARE* obliged to handle these RST -- senders are not obliged to probe. But the latter combination would still not cover the case where the = receiver vanishes in a black hole. (If it simply goes away, there will = be unreachables after a while -- these should work as well as a RST.) Again, I'm not entirely sure we have hit the right combination, but I = think it is the best solution we have right now. Gr=FC=DFe, Carsten From kovatsch@inf.ethz.ch Fri Mar 2 05:48:25 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E9321F883A for ; Fri, 2 Mar 2012 05:48:25 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBqk+Ub+nfC5 for ; Fri, 2 Mar 2012 05:48:24 -0800 (PST) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 088EC21F8822 for ; Fri, 2 Mar 2012 05:48:23 -0800 (PST) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 2 Mar 2012 14:48:19 +0100 Received: from MBX10.d.ethz.ch ([169.254.1.91]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.01.0355.002; Fri, 2 Mar 2012 14:48:22 +0100 From: "Kovatsch Matthias" To: Carsten Bormann Thread-Topic: [core] RST and NON (was Re: explicit observe de-registration) Thread-Index: AQHM67yy3rtQ1zwYeUCRaByC6dtxHpZXAvBwgAAFLwCAABJMMA== Date: Fri, 2 Mar 2012 13:48:21 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B513922993@MBX10.d.ethz.ch> References: <4F3B6E25.8000104@ericsson.com> <55877B3AFB359744BA0F2140E36F52B5139227CB@MBX10.d.ethz.ch> In-Reply-To: Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [178.83.15.45] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org" Subject: Re: [core] RST and NON (was Re: explicit observe de-registration) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Mar 2012 13:48:25 -0000 So making RST a full peer reset is not an option? It would carry all the in= formation required for that (address+port). It would make sense to me because a client for instance could only "forget"= an observing relationship because of a crash/reset (not counting implement= ation bugs). But after a crash, all relationships would be gone anyway. For= selective cancellation, observing for instance still provides the GETs wit= hout the observe option. The full peer reset would also fit a DoS attack scenario where faked subscr= iptions could cause the bombardment of one client. Just thinking... > -----Urspr=FCngliche Nachricht----- > Von: Carsten Bormann [mailto:cabo@tzi.org] > Gesendet: Freitag, 2. M=E4rz 2012 14:27 > An: Kovatsch Matthias > Cc: core@ietf.org > Betreff: Re: [core] RST and NON (was Re: explicit observe de-registration= ) >=20 > On Mar 2, 2012, at 13:20, Kovatsch Matthias wrote: >=20 > > The RST [...] must be empty >=20 > Yes. >=20 > > and there is no matching message ID. >=20 > Here is the point of confusion: > Yes, there is. 2.1: >=20 > ... > Non-confirmable message (NON). These are not acknowledged, but still > have a Message ID for duplicate detection; see Figure 3. >=20 > See also 4.3. >=20 > But I understand your question: > I don't think the current design is exactly beautiful. >=20 > A normal NON sender implementation will not register that message ID, bec= ause > there is nobody that would be interested in any feedback. > Here, however, the server being observed *is* interested, so within the > implementation it should pass a flag "please register this MID even thoug= h it is a > NON". > It would then be able to match back the RST to the NON. >=20 > Clearly, this is bending the semantics of NON a bit -- you can RST it, bu= t can't > ACK it. > I think the right way to handle this conflict is to make reacting to RSTs= that are > being sent back for NONs, an implementation decision. > If a server doesn't have the means to keep the MID, well, then it will ke= ep > sending NONs despite the incoming RSTs until it finally decides to probe = the > observer with CON. >=20 > So this would be one combination of choices: > -- receivers are not obliged to send RST to NON > -- senders are not obliged to implement NON-RST-matching > -- senders *ARE* obliged to occasionally probe using CON. >=20 > Another combination: > -- receivers *ARE* obliged to send RST on NON they don't know what to do = with > -- senders *ARE* obliged to handle these RST > -- senders are not obliged to probe. >=20 > But the latter combination would still not cover the case where the recei= ver > vanishes in a black hole. (If it simply goes away, there will be unreach= ables after > a while -- these should work as well as a RST.) >=20 > Again, I'm not entirely sure we have hit the right combination, but I thi= nk it is the > best solution we have right now. >=20 > Gr=FC=DFe, Carsten From jari.arkko@piuha.net Fri Mar 2 06:16:53 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0626521F84EC for ; Fri, 2 Mar 2012 06:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.54 X-Spam-Level: X-Spam-Status: No, score=-103.54 tagged_above=-999 required=5 tests=[AWL=1.059, BAYES_00=-2.599, GB_I_LETTER=-2, 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 YNypjLPD-vxt for ; Fri, 2 Mar 2012 06:16:52 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id E984221F84DF for ; Fri, 2 Mar 2012 06:16:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 438C82D35A; Fri, 2 Mar 2012 16:16:51 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBWS78i6xd1R; Fri, 2 Mar 2012 16:16:50 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 87E712CC3C; Fri, 2 Mar 2012 16:16:50 +0200 (EET) Message-ID: <4F50D652.1090501@piuha.net> Date: Fri, 02 Mar 2012 16:16:50 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: matthieu.vial@non.schneider-electric.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core WG Subject: Re: [core] Tr : New Version Notification for draft-vial-core-mirror-proxy-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, 02 Mar 2012 14:16:53 -0000 Matthieu, I have read your draft. I like it, and would very much like to see something like this as a part of the outputs from this working group. Your draft is kind of a well-designed REST version of what we did in admittedly rather ad hoc manner in draft-arkko-core-sleepy-sensors. I also like it that your interface is pretty much identical to the RD interface, making this easier to implement. Question: if I want to register myself in a RM *and* an RD (which might potentially be in the same server), is there a way for me to send just one set of messages, or do I have to register twice? A couple of comments on your open questions: > We need a way to identify a SEP registered in multiple proxies as a > single entity. Otherwise clients may have a wrong view of the > available services during resource discovery. The duplicate > resources are indeed seen as new devices. I would suggest that there could be a "origin" identity carried in the registration (e.g., dev:mac:....) and that origin identity can be communicated through the RD to anyone who sees the resources. This allows whoever is interested in the content to at least detect the duplicate resources as such. > > We need a simple mechanism to define allowed methods on mirrored > resources that is independant of the resource profile. A second > Interface Description attribute with the CRUD letters might work. I have no comment on this yet. > We may add a CoAP option that would permit a MP to indicate in a > response that a client has updated another writable resource in the > cache for the requesting SEP. This would gives better response time > than polling. Hmm. I think this needs further thought. Is there a way to ask "give me a list of my resources that have changed since yesterday"? > > When a SEP registers with multiple MP and each MP reuses the same > SEP's name to register with the RD, the resource directory entry > might be overwritten. We need to figure out what piece of > information is the handler for a resource directory entry in a RD > database. We have some ideas on this front... stay tuned. > > 6.1. Extensions > > > > Implicit registration could be useful for highly constrained SEP that > don't have enough energy to maintain soft state in a MP. Like the > proposition in [I-D.arkko-core-sleepy-sensors ], we could use a > multicast address to infer a resource type. Alternatively we could > allow explicit registration from a third-party endpoint. > For what it is worth, we took our implementation to the extreme limit. It is necessary to be able to create simple and power efficient devices, but there may be a reasonable limit that we do not have to cross. I think a constrained device can support a registration phase. The only problem that I have with registration phases is the issue that we experienced with coap-observe: we cannot assume that only one entity is interested in our results, we don't know when the addressing plan of the site changes, and we don't want to stay on all the time in case someone re-registers (as a server) or poll continuously if there's a new register that we must register to (as a client). If those problems can be overcome for a RM function, then I'm fine with programming a discovery and registration mechanism into my devices. Jari From cabo@tzi.org Fri Mar 2 06:18:36 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0111221F84FB for ; Fri, 2 Mar 2012 06:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.415 X-Spam-Level: X-Spam-Status: No, score=-106.415 tagged_above=-999 required=5 tests=[AWL=-0.166, 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 o9mH4iAF9LOY for ; Fri, 2 Mar 2012 06:18:35 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEFA21F84EF for ; Fri, 2 Mar 2012 06:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q22EISJw006790; Fri, 2 Mar 2012 15:18:28 +0100 (CET) Received: from [192.168.217.105] (p54899665.dip.t-dialin.net [84.137.150.101]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C04D3974; Fri, 2 Mar 2012 15:18:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <55877B3AFB359744BA0F2140E36F52B513922993@MBX10.d.ethz.ch> Date: Fri, 2 Mar 2012 15:18:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2D10A4A0-8215-4DA8-8E04-CF878C4D3726@tzi.org> References: <4F3B6E25.8000104@ericsson.com> <55877B3AFB359744BA0F2140E36F52B5139227CB@MBX10.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B513922993@MBX10.d.ethz.ch> To: "Kovatsch Matthias" X-Mailer: Apple Mail (2.1257) Cc: "core@ietf.org" Subject: Re: [core] RST and NON (was Re: explicit observe de-registration) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Mar 2012 14:18:36 -0000 On Mar 2, 2012, at 14:48, Kovatsch Matthias wrote: > So making RST a full peer reset is not an option? It would carry all = the information required for that (address+port). Yes, I seem to remember we had that discussion before.... =20 I'm still trying to remember the context. Klaus, do you remember? But I'd keep the MID matching, regardless of whether the RST only clears = the observation relationship that used this particular MID or all = observation relationships on this transport address pair. Without MID = matching, it becomes too easy to spray the world with RSTs as a DoS = (yes, 16 bits is a weak mitigation, but it is something, and it is = additionally aided by the window during which the NON is alive). > It would make sense to me because a client for instance could only = "forget" an observing relationship because of a crash/reset (not = counting implementation bugs). But after a crash, all relationships = would be gone anyway. Right. > For selective cancellation, observing for instance still provides the = GETs without the observe option. That would also fit the likely timing relationships better -- it is less = likely that a client suddenly finds out on a NON notification that it = really no longer wants the data. More likely, there is an independent trigger that causes the client to = stop the relationship, and no suitably recent NON may be lying around = then to send a RST on, so it is likely to implement the GET code path in = any case. But this is now becoming a bit of speculation... Maybe = sending the 4-byte RST is exactly what the doctor ordered... > The full peer reset would also fit a DoS attack scenario where faked = subscriptions could cause the bombardment of one client. Just = thinking... Yes, but see above. Gr=FC=DFe, Carsten From kovatsch@inf.ethz.ch Fri Mar 2 06:40:03 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8109821F863C for ; Fri, 2 Mar 2012 06:40:03 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfMsckoZ5EuV for ; Fri, 2 Mar 2012 06:40:03 -0800 (PST) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id B37DE21F85D7 for ; Fri, 2 Mar 2012 06:40:02 -0800 (PST) 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.1.355.2; Fri, 2 Mar 2012 15:39:58 +0100 Received: from MBX10.d.ethz.ch ([169.254.1.91]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%10]) with mapi id 14.01.0355.002; Fri, 2 Mar 2012 15:40:01 +0100 From: "Kovatsch Matthias" To: Carsten Bormann Thread-Topic: [core] RST and NON (was Re: explicit observe de-registration) Thread-Index: AQHM67yy3rtQ1zwYeUCRaByC6dtxHpZXAvBwgAAFLwCAABJMMP///AIAgAAT/BA= Date: Fri, 2 Mar 2012 14:40:01 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B513922AEF@MBX10.d.ethz.ch> References: <4F3B6E25.8000104@ericsson.com> <55877B3AFB359744BA0F2140E36F52B5139227CB@MBX10.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B513922993@MBX10.d.ethz.ch> <2D10A4A0-8215-4DA8-8E04-CF878C4D3726@tzi.org> In-Reply-To: <2D10A4A0-8215-4DA8-8E04-CF878C4D3726@tzi.org> Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [178.83.15.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org" Subject: Re: [core] RST and NON (was Re: explicit observe de-registration) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Mar 2012 14:40:03 -0000 > But I'd keep the MID matching, regardless of whether the RST only clears = the > observation relationship that used this particular MID or all observation > relationships on this transport address pair. Without MID matching, it b= ecomes > too easy to spray the world with RSTs as a DoS (yes, 16 bits is a weak mi= tigation, > but it is something, and it is additionally aided by the window during wh= ich the > NON is alive). >=20 > > The full peer reset would also fit a DoS attack scenario where faked > subscriptions could cause the bombardment of one client. Just thinking... >=20 > Yes, but see above. True. Okay, so I will probably add the last used MIDs to the observer state at th= e server. Thanks for the clarification! Matthias From hartketzi@googlemail.com Fri Mar 2 07:47:30 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF31B21F863D for ; Fri, 2 Mar 2012 07:47:30 -0800 (PST) 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 luOt0VEOdY4b for ; Fri, 2 Mar 2012 07:47:30 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC4F121F8656 for ; Fri, 2 Mar 2012 07:47:29 -0800 (PST) Received: by dakl33 with SMTP id l33so2376437dak.31 for ; Fri, 02 Mar 2012 07:47:29 -0800 (PST) Received-SPF: pass (google.com: domain of hartketzi@googlemail.com designates 10.68.217.104 as permitted sender) client-ip=10.68.217.104; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hartketzi@googlemail.com designates 10.68.217.104 as permitted sender) smtp.mail=hartketzi@googlemail.com; dkim=pass header.i=hartketzi@googlemail.com Received: from mr.google.com ([10.68.217.104]) by 10.68.217.104 with SMTP id ox8mr17603071pbc.43.1330703249621 (num_hops = 1); Fri, 02 Mar 2012 07:47:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=/qFp6kqLsQw6ScKu+FR3pr+UgXJFoNjqsxv2nOYsS8k=; b=qiaT/rq+9EspYWpB1nR6MpO7o7WM6GbuB8yvmrdf24pHumzD7gM+SY13VNHOQMtw/U 6KuknxwT00ooTvmXFRDCCrY3c9gfxY2lz8LfGWnCMbUv28ZqZiF8Nn1fSc+M87XrdwRR OISoEUQCvBtuxAhuPcMM0FVrRU8KLSjxutVFsPfVanpNrplFe5EzAJekemSku7E32wZj eP4eVKsSlFzSsO/f35ruEc8xJRupNagkviAfUvPWhm+UQ/dIjsJoSpihU2t+EOaP9gTe GFeVebPljS1XMe2PrQ74m+uO5HTXTK7rGl/ryc9+FkA5p4PeELGiGvU8Yjki/l2BRQ7g 0q4g== MIME-Version: 1.0 Received: by 10.68.217.104 with SMTP id ox8mr14705072pbc.43.1330703249547; Fri, 02 Mar 2012 07:47:29 -0800 (PST) Sender: hartketzi@googlemail.com Received: by 10.68.233.74 with HTTP; Fri, 2 Mar 2012 07:47:29 -0800 (PST) In-Reply-To: <2D10A4A0-8215-4DA8-8E04-CF878C4D3726@tzi.org> References: <4F3B6E25.8000104@ericsson.com> <55877B3AFB359744BA0F2140E36F52B5139227CB@MBX10.d.ethz.ch> <55877B3AFB359744BA0F2140E36F52B513922993@MBX10.d.ethz.ch> <2D10A4A0-8215-4DA8-8E04-CF878C4D3726@tzi.org> Date: Fri, 2 Mar 2012 16:47:29 +0100 X-Google-Sender-Auth: jgAKXU4HnGqT5J_FZ-AqZvesxPY Message-ID: From: Klaus Hartke To: "core@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [core] RST and NON (was Re: explicit observe de-registration) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Mar 2012 15:47:31 -0000 On 2 March 2012 15:18, Carsten Bormann wrote: > On Mar 2, 2012, at 14:48, Kovatsch Matthias wrote: > >> So making RST a full peer reset is not an option? It would carry all the= information required for that (address+port). > > Yes, I seem to remember we had that discussion before.... > I'm still trying to remember the context. =A0Klaus, do you remember? We had the discussion if a confirmable notification that ultimately times out should cause the server to remove the client from all lists of observers. When the last attempt to retransmit a confirmable message with a notification for a resource times out, the server SHOULD remove the client from the list of observers and MAY additionally remove the client from the lists of observers of all resources in its namespace. (http://tools.ietf.org/html/draft-ietf-core-observe-04#section-4.5) I'm not sure if this should also be done if the client sends a RST. RST means that the recipient of a CON/NON message is missing some context to process the message, whatever this context might be, not necessarily that it lost everything. Klaus From matthieu.vial@non.schneider-electric.com Fri Mar 2 08:55:02 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54BE21F86A2 for ; Fri, 2 Mar 2012 08:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.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 KGDbrpUOKr8c for ; Fri, 2 Mar 2012 08:55:00 -0800 (PST) Received: from mailX04.eud.schneider-electric.com (mailx04.eud.schneider-electric.com [205.167.7.39]) by ietfa.amsl.com (Postfix) with ESMTP id C02A021F8698 for ; Fri, 2 Mar 2012 08:54:59 -0800 (PST) Received: from ateui03.schneider-electric.com ([10.198.21.36]) by mailX04.eud.schneider-electric.com with ESMTP id 2012030217513258-11665 ; Fri, 2 Mar 2012 17:51:32 +0100 In-Reply-To: <4F50D652.1090501@piuha.net> To: Jari Arkko MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: matthieu.vial@non.schneider-electric.com Message-ID: Date: Fri, 2 Mar 2012 17:54:53 +0100 X-MIMETrack: Serialize by Router on ATEUI03.Schneider-Electric.com/T/SVR/Schneider at 02/03/2012 17:54:56, Serialize complete at 02/03/2012 17:54:56, Itemize by SMTP Server on AXEU4OUT.schneider-electric.com/X/SVR/SEIxtra at 02/03/2012 17:51:32, Serialize by Router on AXEU4OUT.schneider-electric.com/X/SVR/SEIxtra at 02/03/2012 17:51:36, Serialize complete at 02/03/2012 17:51:36 Content-Type: text/plain; charset="US-ASCII" Cc: core WG Subject: Re: [core] Tr : New Version Notification for draft-vial-core-mirror-proxy-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, 02 Mar 2012 16:55:02 -0000 Jari, Thanks for your interest in the draft. See my comments below. >I also like it that your interface is pretty much identical to the RD interface, making this easier to implement. Question: if I want to register myself in a RM *and* an RD (which might potentially be in the same server), is there a way for me to send just one set of messages, or do I have to register twice? For me a sleeping endpoint is not supposed to register with a RD. The mirror proxy can do it on its behalf if RD discovery is administratively configured in the network. When the RD and the MP are located on the same web server we can imagine internal optimizations to populate the RD database. Also by default the RD extracts the source address of the registration packet to get the address of the web server. A SEP is not a web server so it would have to explicitly specify the address of the MP in the registration request. It's just added complexity for a SEP and it's also less energy efficient. >I would suggest that there could be a "origin" identity carried in the registration (e.g., dev:mac:....) and that origin identity can be communicated through the RD to anyone who sees the resources. This allows whoever is interested in the content to at least detect the duplicate resources as such. The question is how to attach this identity to the web links returned during resource discovery. >I think a constrained device can support a registration phase. Depending on the energy harvesting technology, some devices might not be able to send periodic requests to maintain soft state or to start a complex registration procedure (link-format is quite verbose). A switch may collect energy from the movement of the rocker for example. In that case the SEP can only communicate when the switch is activated. Matthieu From jari.arkko@piuha.net Fri Mar 2 10:27:40 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6BF21E803C for ; Fri, 2 Mar 2012 10:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 MZyqmD2L2aqL for ; Fri, 2 Mar 2012 10:27:39 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 3A78B21E802D for ; Fri, 2 Mar 2012 10:27:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2E9AB2D35A; Fri, 2 Mar 2012 20:27:38 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQ7J0KPwCERr; Fri, 2 Mar 2012 20:27:37 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 808152CC3C; Fri, 2 Mar 2012 20:27:37 +0200 (EET) Message-ID: <4F511119.5010105@piuha.net> Date: Fri, 02 Mar 2012 20:27:37 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: matthieu.vial@non.schneider-electric.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core WG Subject: Re: [core] Tr : New Version Notification for draft-vial-core-mirror-proxy-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, 02 Mar 2012 18:27:40 -0000 Matthieu: > Jari, > > Thanks for your interest in the draft. See my comments below. > > >> I also like it that your interface is pretty much identical to the RD > interface, making this easier to implement. Question: if I want to > register myself in a RM *and* an RD (which might potentially be in the > same server), is there a way for me to send just one set of messages, or > do I have to register twice? > > For me a sleeping endpoint is not supposed to register with a RD. OK. That makes sense. So when the MP is register itself with an RD, it does so to register the mirrored resources, not the original client. > The > mirror proxy can do it on its behalf if RD discovery is administratively > configured in the network. When the RD and the MP are located on the same > web server we can imagine internal optimizations to populate the RD > database. Also by default the RD extracts the source address of the > registration packet to get the address of the web server. A SEP is not a > web server so it would have to explicitly specify the address of the MP in > the registration request. It's just added complexity for a SEP and it's > also less energy efficient. Yes. In any case, what is important for me is that I don't have to use multiple message rounds just to do both directory and mirroring; I just do one thing and the mirror takes care of directories for me. > > >> I would suggest that there could be a "origin" identity carried in the > registration (e.g., dev:mac:....) and that origin identity can be > communicated through the RD to anyone who sees the resources. This allows > whoever is interested in the content to at least detect the duplicate > resources as such. > > The question is how to attach this identity to the web links returned > during resource discovery. As a separate attribute? (But I haven't looked at the details...) > > >> I think a constrained device can support a registration phase. > Depending on the energy harvesting technology, some devices might not be > able to send periodic requests to maintain soft state or to start a > complex registration procedure (link-format is quite verbose). A switch > may collect energy from the movement of the rocker for example. In that > case the SEP can only communicate when the switch is activated. Yes. I think registration phase is probably OK, periodic soft state maintenance.... might not be. But it depends on the timings, too. And those timings have real-world trade-offs on how well you can not just save power but also deal with changes and problems. The issue is that once something changes, you do not want wait for a month for all of your devices to re-register, if the soft state maintenance timers were set to a month to save power. Jari > > Matthieu > From zach@sensinode.com Fri Mar 2 11:31:31 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC03721E8019 for ; Fri, 2 Mar 2012 11:31:31 -0800 (PST) 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 GcxRWQqYULSo for ; Fri, 2 Mar 2012 11:31:31 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id C2F5C21E8057 for ; Fri, 2 Mar 2012 11:31:30 -0800 (PST) Received: from [192.168.1.101] (87-93-235-96.bb.dnainternet.fi [87.93.235.96]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q22JTNaB012079; Fri, 2 Mar 2012 21:30:12 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4F511119.5010105@piuha.net> Date: Fri, 2 Mar 2012 21:28:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F511119.5010105@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] Tr : New Version Notification for draft-vial-core-mirror-proxy-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, 02 Mar 2012 19:31:32 -0000 On Mar 2, 2012, at 8:27 PM, Jari Arkko wrote: >>>=20 >>> I would suggest that there could be a "origin" identity carried in = the >> registration (e.g., dev:mac:....) and that origin identity can be >> communicated through the RD to anyone who sees the resources. This = allows >> whoever is interested in the content to at least detect the duplicate >> resources as such. >>=20 >> The question is how to attach this identity to the web links returned >> during resource discovery. >=20 > As a separate attribute? (But I haven't looked at the details...) Actually I have already considered including in the RD draft an id=3D = attribute that allows you to associate a unique identifier (e.g. = dev-urn) with an end-point. Would be happy to include that in the RD = registration interface if people find that useful.=20 Zach=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From jari.arkko@piuha.net Sun Mar 4 14:06:04 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B71621F8587 for ; Sun, 4 Mar 2012 14:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.233 X-Spam-Level: X-Spam-Status: No, score=-102.233 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, J_CHICKENPOX_72=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 8gyxmWaxNsyH for ; Sun, 4 Mar 2012 14:06:03 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 3697021F8526 for ; Sun, 4 Mar 2012 14:06:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 29F842D35A; Mon, 5 Mar 2012 00:06:02 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgyDh7sRFu-c; Mon, 5 Mar 2012 00:06:01 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 1C5BC2CC3C; Mon, 5 Mar 2012 00:06:01 +0200 (EET) Message-ID: <4F53E746.7050401@piuha.net> Date: Mon, 05 Mar 2012 00:05:58 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Thomas Fossati References: <9032C193-A015-4F41-B441-4D1D47594FC9@koanlogic.com> In-Reply-To: <9032C193-A015-4F41-B441-4D1D47594FC9@koanlogic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core WG Subject: Re: [core] sleepy to sleepy communication 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: Sun, 04 Mar 2012 22:06:04 -0000 I've read these drafts, too. I think it is very good that we have new proposals to support sleeping nodes better. It is needed! Thanks for writing the proposals. It is interesting to compare the spec to draft-vial-core-mirror-proxy. You seem to take an approach where communications in the sensor network are in the focus, whereas draft-vial defined a proxy that could be used by any regular client. I liked the resource model in draft-vial better, because it seems so straightforward from a REST point of view. POST to get an ID from the proxy, PUT to update. In particular, it is easy for me to understand how the URIs get constructed and where traffic is routed. A random client somewhere else on the Internet knows how to go to mirror.example.net/17/temp. I don't necessarily understand how the same thing happens in draft-giacomin, can you expand on that? On the other hand, I didn't like the writable resource monitoring model in draft-vial so much. It would be a drag to have to poll everything when you wake up. I'd rather see a model where I can wake up and ask what has changed. Maybe that can be changed in draft-vial. In any case, whatever we do, some additional information (like the sleepy option) in requests and responses might actually make sense as a generic mechanism. I suspect it should be something that works for both HTTP and COAP, if that can made to happen. I'm not expert enough to understand exactly how. However, accurate clock sync may be difficult if you attempt to achieve a very high ratio of sleep vs. awake. Even there it might be useful to think in terms of waking up and letting the proxy know you're now ready to act, than attempting to have the proxy fire a message at a calculated awake time. Draft-vial already works in this mode, as the sensors will wake up and inform/query the proxy on their own timing. In conclusion it seems that we have a architectural choice ahead of us. We could have sleepy nodes delegate their web existence to other nodes (like draft-vial does), enabling both other devices in the same network and devices elsewhere in the Internet to interact with mostly the other node. Or we could build support to COAP and proxies for mediation between sleeping nodes (like draft-giacomin and draft-fossati does). At the high level, the effects are similar but there are significant differences in details. I confess that I like the former model better, because it separates the support for sleepy nodes from whatever is needed by nodes interacting with them. But we probably don't understand the design space well enough yet to make a real decision. At least I certainly don't. Jari On 29.02.2012 23:46, Thomas Fossati wrote: > Hello all, > > today we have submitted a couple of I-Ds proposing three new CoAP Options that try dealing with the requirement REQ3 of draft-shelby-core-coap-req-04 > > The ability to deal with sleeping nodes. Devices may be > powered off at any point in time but periodically "wake up" > for brief periods of time. > > leveraging on different techniques, i.e. store-and-forward, explicit origin delegation, REST interface to carbon-copy an observed resource. > > > Their URIs and respective abstracts are given in the following for convenience: > > (1) "Sleepy Option for CoAP" (see http://tools.ietf.org/html/draft-giacomin-core-sleepy-option-00) > > This draft defines a new CoAP elective option, Sleepy, targeted specifically at proxies and used to signal a proxy the will to initiate an asynchronous request/response exchange. The Sleepy option is partitioned in 2/3 subfields indicating: the remaining time before sleep, the expected sleep interval, and (optionally) the on-duty interval. > > > (2) "Publish and Monitor Options for CoAP" (see http://tools.ietf.org/html/draft-fossati-core-publish-monitor-options-00) > > This draft defines two additional Options for the Constrained Application Protocol (CoAP) especially targeted at sleepy sensors: Publish and Monitor. > > The Publish Option enables opportunistic updates of a given resource state, by temporarily delegating the authority of the Publish'ed resource to a Proxy node. The whole process is driven by the (sleepy) origin -- which may actually never need to listen. > > The Monitor Option complements the typical Observe pattern, enabling the tracking of a resource hosted by a node sleeping most of the time, by taking care of establishing and maintaining an Observe relationship with the (sleepy) origin on behalf of the (sleepy) client. > > > We look forward for receiving comments and suggestions to the proposed solutions. > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From jari.arkko@piuha.net Sun Mar 4 17:04:29 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4EA21F8690 for ; Sun, 4 Mar 2012 17:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.602 X-Spam-Level: X-Spam-Status: No, score=-101.602 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_20=-0.74, 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 CFCO61NwetPX for ; Sun, 4 Mar 2012 17:04:28 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 84B4821F8657 for ; Sun, 4 Mar 2012 17:04:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 742FB2D35A; Mon, 5 Mar 2012 03:04:22 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R74w-9EqPpNf; Mon, 5 Mar 2012 03:04:21 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 9E7E42CC3C; Mon, 5 Mar 2012 03:04:21 +0200 (EET) Message-ID: <4F541113.1000806@piuha.net> Date: Mon, 05 Mar 2012 03:04:19 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Bruce Nordman References: <4F4FE403.8060205@ericsson.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] sleepy to sleepy communication 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: Mon, 05 Mar 2012 01:04:29 -0000 Good points, Bruce. I will add that for many applications and platforms, the ability to communicate is the primary issue and waking up the CPU is secondary. In addition, on many link layers the ability to communicate depends on the network as well as the device, as it is the network that does the final synchronization, granting of time slots, etc. These may not matter on a coarse time scale (I'll wake up to listen for messages from 00h00min0s to 00h00min5s, but it may matter for smaller time scales (it definitely does for a millisecond). Jari On 01.03.2012 23:56, Bruce Nordman wrote: > In some contexts it has been helpful to identify "light sleep" vs. "deep sleep" when > there are two sub-states with different characteristics. Beyond two, the terminology gets trickier. > > It is probably already in the various drafts but it is important to distinguish the link > state from the device power state. Energy Efficient Ethernet (IEEE 802.3az) created > a sleep state for Ethernet with quick sleep/wake times (as opposed to a link disconnected > state with very long renegotiation of the link). On PCs, the link state and the system > power state are completely independent. Turning off the radio on a duty cycle sounds > like a link sleep state that enables faster reestablishment of the link than from a no-link state. > > I have found that it is difficult to impose detailed requirements on the specifics of > power states across a wide variety of devices, but CORE's clarity on this for CoAP > low-power devices will be of great help in future. > > Thanks, > > --Bruce From tho@koanlogic.com Sun Mar 4 21:29:14 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0707D21F8672 for ; Sun, 4 Mar 2012 21:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.03 X-Spam-Level: * X-Spam-Status: No, score=1.03 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_05=-1.11, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzhtPKKLDKcL for ; Sun, 4 Mar 2012 21:29:13 -0800 (PST) Received: from relay3.serverpronto.com (srv1022-mia.serverpronto.com [38.117.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4109F21F8667 for ; Sun, 4 Mar 2012 21:29:12 -0800 (PST) Received: from gonzo.koanlogic.com (166-118-60-69.serverpronto.com [69.60.118.166] (may be forged)) by relay3.serverpronto.com (8.13.8/8.13.8) with ESMTP id q255TAWV005681; Mon, 5 Mar 2012 00:29:10 -0500 Received: from host196-51-dynamic.47-79-r.retail.telecomitalia.it ([79.47.51.196]:60577 helo=t.homenet.telecomitalia.it) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1S4QTn-0004tJ-2t; Mon, 05 Mar 2012 00:29:10 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <4F53E746.7050401@piuha.net> Date: Mon, 5 Mar 2012 06:28:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9B51E46C-D03D-4911-8D00-65B56DE48F63@koanlogic.com> References: <9032C193-A015-4F41-B441-4D1D47594FC9@koanlogic.com> <4F53E746.7050401@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.47.51.196 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Cc: core WG Subject: Re: [core] sleepy to sleepy communication 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: Mon, 05 Mar 2012 05:29:14 -0000 Hi Jari, On Mar 4, 2012, at 11:05 PM, Jari Arkko wrote: > I liked the resource model in draft-vial better, because it seems so = straightforward from a REST point of view. POST to get an ID from the = proxy, PUT to update. In particular, it is easy for me to understand how = the URIs get constructed and where traffic is routed. A random client = somewhere else on the Internet knows how to go to = mirror.example.net/17/temp. I don't necessarily understand how the same = thing happens in draft-giacomin, can you expand on that? you mean using the Publish option ? If so, the random client uses the = same URI that is associated to the sleepy resource (whose existence is = pretty safe to be assumed in a REST environment) and asks the proxy = acting as the delegated origin to serve it via Proxy-URI. So, = communication is pretty straightforward; discovery could be more tricky = because I fear it necessarily goes through an RD -- i.e. discovery via = /.well-known/core may not work (I have expanded a bit on this in the = following.) > In conclusion it seems that we have a architectural choice ahead of = us. We could have sleepy nodes delegate their web existence to other = nodes (like draft-vial does), enabling both other devices in the same = network and devices elsewhere in the Internet to interact with mostly = the other node. Or we could build support to COAP and proxies for = mediation between sleeping nodes (like draft-giacomin and draft-fossati = does). At the high level, the effects are similar but there are = significant differences in details. I confess that I like the former = model better, because it separates the support for sleepy nodes from = whatever is needed by nodes interacting with them. But we probably don't = understand the design space well enough yet to make a real decision. At = least I certainly don't. And we neither :-) We are just trying to explore the problem space by using a bunch of = different strategies. We play with one rule (use the proxy as a = mediator), and one constraint (stay in CoAP). I think that the second is especially important, because it allows us to = see how much we can achieve using just the protocol semantics (and its = self-extension facility, options). That's where we can hit interesting flaws and strengths of CoAP. E.g., differently from HTTP, we have an explicit Proxy-URI object (which = BTW is a wonderful thing): let's try to see how much can be said with = it, for example doing origin delegation without having to create = multiple different 'same resource' identifiers through mirroring. Another important thing we are going to hit this way is how discovery = based on /.well-known/core is meant to go through proxies. AFAIK both = core and link-format I-Ds are rather succinct on this matter, and even = if it seems reasonable to assume that the /.well-known/core resource is = both query-able through, and cacheable by, a proxy, perhaps the facts = are not very much so. We seem too much often to assume that the = "well-known" interface relies on the resource authority being defined by = the source address of the UDP packet carrying the response. If so, = querying the well-known interface (especially multicast) through a = Proxy-URI has little hope to be fully functional. We are sort of = abusing an implicit L3 locator as the identifier of the resource = authority, which makes "well-known" discovery generally incompatible = with proxy mediated communication, unless each target URI in a link is = given as a URI and not as a relative-ref (a thing that would be nice to = discuss somewhere in the spec, perhaps the DNA I-D by Peter, Kerry and = Anders is the right place ?) To cut a long story short, I don't really know if we are better off = establishing a new component like the MP proposed by Matthieu, or extend = the base spec with one or more options that give the proxy new ad hoc = capabilities. The important IMHO is to keep on pushing our two = (complementary) approaches as much as possible until, as you've said, we = reach a better understanding of the matter that can inform a wise = choice. Thomas. PS: It may also turn out that REQ3 of draft-shelby-core-coap-req is not = an application layer issue! ;-)= From angelo.castellani@gmail.com Mon Mar 5 00:10:16 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A83621F8505 for ; Mon, 5 Mar 2012 00:10:16 -0800 (PST) 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 3MiC2TVaBpii for ; Mon, 5 Mar 2012 00:10:15 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEEC21F8503 for ; Mon, 5 Mar 2012 00:10:14 -0800 (PST) Received: by wicr5 with SMTP id r5so1519641wic.31 for ; Mon, 05 Mar 2012 00:10:13 -0800 (PST) Received-SPF: pass (google.com: domain of angelo.castellani@gmail.com designates 10.180.79.231 as permitted sender) client-ip=10.180.79.231; Authentication-Results: mr.google.com; spf=pass (google.com: domain of angelo.castellani@gmail.com designates 10.180.79.231 as permitted sender) smtp.mail=angelo.castellani@gmail.com; dkim=pass header.i=angelo.castellani@gmail.com Received: from mr.google.com ([10.180.79.231]) by 10.180.79.231 with SMTP id m7mr72312wix.11.1330935013967 (num_hops = 1); Mon, 05 Mar 2012 00:10:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=udPKY5ZjwcdsraHblMf6uTJc66F0w437ZWy0pBfavDA=; b=CdHVoXJxodxH64VTrHL7MP3sC5koflaM1sTBog7Se8nWgX216WZc/SkmMpbkb7eIDv Ww8MwrrMi0u5n2RvzKHKAHJQjPyZv5LOVqC9Xynoy/bMzyDVq7xnGjNNxnDGaE3/GgUv QEeQR0tglphHt7CwpkrAgb2cCt/uAIYoCeRo7A2vrMa8rY4+jhV72b76ZAG5A16g0xzZ sZjOrC7jPPwfg0f+ojFveXJvfK2mruaSCW01O4xrFTD2LLoWBJ5VAeTb+TNDuy3gpPKk p7MhJ9XYF7LJpSYzmEAhZFF1u197pY85rKp+KPLCudOuuULkgdvUFYZAx2ait/Gv4eoj miVg== Received: by 10.180.79.231 with SMTP id m7mr52095wix.11.1330935013882; Mon, 05 Mar 2012 00:10:13 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.210.12 with HTTP; Mon, 5 Mar 2012 00:09:33 -0800 (PST) In-Reply-To: <9B51E46C-D03D-4911-8D00-65B56DE48F63@koanlogic.com> References: <9032C193-A015-4F41-B441-4D1D47594FC9@koanlogic.com> <4F53E746.7050401@piuha.net> <9B51E46C-D03D-4911-8D00-65B56DE48F63@koanlogic.com> From: "Angelo P. Castellani" Date: Mon, 5 Mar 2012 09:09:33 +0100 X-Google-Sender-Auth: z2E_lhgXOsXJte1cm-8O5PpTrNw Message-ID: To: Thomas Fossati Content-Type: text/plain; charset=UTF-8 Cc: core WG Subject: Re: [core] sleepy to sleepy communication 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: Mon, 05 Mar 2012 08:10:16 -0000 On Mon, Mar 5, 2012 at 06:28, Thomas Fossati wrote: > PS: It may also turn out that REQ3 of draft-shelby-core-coap-req is not an application layer issue! ;-) Indeed sensor networks support sleeping using radio duty cycling at lower layers, this turns out in having the sleeping functionality without any loss of communication at the upper layers. Best, Angelo From jari.arkko@piuha.net Mon Mar 5 01:16:55 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745B021F85FD for ; Mon, 5 Mar 2012 01:16:54 -0800 (PST) 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 FjXVCmTVPKIW for ; Mon, 5 Mar 2012 01:16:53 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 8E96F21F867F for ; Mon, 5 Mar 2012 01:16:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 961C62DA06; Mon, 5 Mar 2012 11:16:51 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8JEbS-3vfkw; Mon, 5 Mar 2012 11:16:51 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id C1EA22CC3C; Mon, 5 Mar 2012 11:16:50 +0200 (EET) Message-ID: <4F548482.9070707@piuha.net> Date: Mon, 05 Mar 2012 11:16:50 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "Angelo P. Castellani" References: <9032C193-A015-4F41-B441-4D1D47594FC9@koanlogic.com> <4F53E746.7050401@piuha.net> <9B51E46C-D03D-4911-8D00-65B56DE48F63@koanlogic.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: core WG Subject: Re: [core] sleepy to sleepy communication 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: Mon, 05 Mar 2012 09:16:55 -0000 Angelo, > Indeed sensor networks support sleeping using radio duty cycling at > lower layers, this turns out in having the sleeping functionality > without any loss of communication at the upper layers. > We discussed this a couple of IETFs back. Since then I've been doing some= talking to our researchers who measure and improve power usage in radios= =2E First, duty cycling is already pretty widely used for radio technology. A= ll cellular systems, for instance, turn off the radio except in during th= e time they listen for possible incoming paging signals, system informati= on necessary to stay in contact at all, or when they have been granted a = time slot to send. Secondly and more importantly, per their measurements, even after all the= above techniques, periodic listening for possibly incoming messages is t= he biggest consumer of energy in applications where we'd like to have a l= ong battery life, such as in sensors. That power usage dwarfs everything = else, so it has to come down, somehow, to make an improvement. So if we want to achieve significantly longer battery lifetimes (and I cl= aim we need those) we need to change some things. Obviously a lot of the = link layers can be tuned better, implementing simply longer paging freque= ncies, for instance. My hypothesis is that we'll have to go longer than w= hat typical application protocol timeouts are today, so the change would = be something that is visible to applications. We could change some of the= timeouts, but it is not clear that network buffers and all underlying me= chanisms deployed today support those without changes. And in general, I = think it is better to fit the communication model to the problem at hand = than vice versa. As a result, I personally believe that we need to build = applications that natively communicate in ways that make sleep modes easy= =2E Such as publish-subscribe instead of direct request-response from any= one who needs the information. But like I said, this is a hypothesis and = I'd love to be proven wrong. Jari From angelo.castellani@gmail.com Mon Mar 5 01:27:21 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A49D21F86FF for ; Mon, 5 Mar 2012 01:27:21 -0800 (PST) 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 slb0qbDH+Ns6 for ; Mon, 5 Mar 2012 01:27:20 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1577021F8704 for ; Mon, 5 Mar 2012 01:27:19 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so2279092wgb.13 for ; Mon, 05 Mar 2012 01:27:19 -0800 (PST) Received-SPF: pass (google.com: domain of angelo.castellani@gmail.com designates 10.180.92.229 as permitted sender) client-ip=10.180.92.229; Authentication-Results: mr.google.com; spf=pass (google.com: domain of angelo.castellani@gmail.com designates 10.180.92.229 as permitted sender) smtp.mail=angelo.castellani@gmail.com; dkim=pass header.i=angelo.castellani@gmail.com Received: from mr.google.com ([10.180.92.229]) by 10.180.92.229 with SMTP id cp5mr13678588wib.8.1330939639326 (num_hops = 1); Mon, 05 Mar 2012 01:27:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=7yCYPb27ApBOPrYIoE6hFJpvDH1ct1QfFiXaVLpfBM4=; b=Wwy1qsnUkezpmY6pO5ow9VzvYOhtcE2gKjxlW7Evys+IpvO4peooZrFm7lYkTlNaxR 9JUUQWbZAcZtK1dKIff/O5qPU2o5lItZdtYL53ComS2EJnmpqzofmoh3jLqwYhDLmHOh Q2Z2J2Z5Utb4kAt7t4f/s3PoTEiUGkghWPh9M1LewGzi9yFlcwgsvqiy2VlYWA92d95M BepNuSF0LeCtlwMQbn2FBV+06+mvDsRQh14/ujmfliLzQEZ7kv0GQ0GApX0GEaiW7o9k 6+v4Z0xoF1lTwcCg9FPEOYAn086KsUgQ6h04AcoyZO53aSOSkZRnVs/ggkrVsiBtk/sS Yatw== Received: by 10.180.92.229 with SMTP id cp5mr10853977wib.8.1330939639232; Mon, 05 Mar 2012 01:27:19 -0800 (PST) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.210.12 with HTTP; Mon, 5 Mar 2012 01:26:39 -0800 (PST) In-Reply-To: <4F548482.9070707@piuha.net> References: <9032C193-A015-4F41-B441-4D1D47594FC9@koanlogic.com> <4F53E746.7050401@piuha.net> <9B51E46C-D03D-4911-8D00-65B56DE48F63@koanlogic.com> <4F548482.9070707@piuha.net> From: "Angelo P. Castellani" Date: Mon, 5 Mar 2012 10:26:39 +0100 X-Google-Sender-Auth: kQHNzJTXqU9cSKwn_OHDcinfxAk Message-ID: To: Jari Arkko Content-Type: text/plain; charset=UTF-8 Cc: core WG Subject: Re: [core] sleepy to sleepy communication 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: Mon, 05 Mar 2012 09:27:21 -0000 I agree with you that this can save a lot more of energy, if the hosts can provide service during theirs "office hours" :) However if the nodes will behave in such a way, for sure this will be visible to the clients and lots of infrastructure (proxies) will be required to get anything usable by the users. With regular sensor networks duty cycling, a ~3 years lifetime is feasible with regular batteries (depending upon actual usage and network traffic). Are you targeting a use case with tighter requirements? Best, Angelo On Mon, Mar 5, 2012 at 10:16, Jari Arkko wrote: > > Angelo, > > >> Indeed sensor networks support sleeping using radio duty cycling at >> lower layers, this turns out in having the sleeping functionality >> without any loss of communication at the upper layers. >> > > We discussed this a couple of IETFs back. Since then I've been doing some > talking to our researchers who measure and improve power usage in radios. > > First, duty cycling is already pretty widely used for radio technology. All > cellular systems, for instance, turn off the radio except in during the time > they listen for possible incoming paging signals, system information > necessary to stay in contact at all, or when they have been granted a time > slot to send. > > Secondly and more importantly, per their measurements, even after all the > above techniques, periodic listening for possibly incoming messages is the > biggest consumer of energy in applications where we'd like to have a long > battery life, such as in sensors. That power usage dwarfs everything else, > so it has to come down, somehow, to make an improvement. > > So if we want to achieve significantly longer battery lifetimes (and I claim > we need those) we need to change some things. Obviously a lot of the link > layers can be tuned better, implementing simply longer paging frequencies, > for instance. My hypothesis is that we'll have to go longer than what > typical application protocol timeouts are today, so the change would be > something that is visible to applications. We could change some of the > timeouts, but it is not clear that network buffers and all underlying > mechanisms deployed today support those without changes. And in general, I > think it is better to fit the communication model to the problem at hand > than vice versa. As a result, I personally believe that we need to build > applications that natively communicate in ways that make sleep modes easy. > Such as publish-subscribe instead of direct request-response from anyone who > needs the information. But like I said, this is a hypothesis and I'd love to > be proven wrong. > > Jari > > From zach@sensinode.com Mon Mar 5 01:51:01 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B8521F8701 for ; Mon, 5 Mar 2012 01:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.669 X-Spam-Level: X-Spam-Status: No, score=-3.669 tagged_above=-999 required=5 tests=[AWL=-0.070, 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 I+8lROw6j6NN for ; Mon, 5 Mar 2012 01:51:00 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id F0D5A21F85D5 for ; Mon, 5 Mar 2012 01:50:58 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q259ow9u014370 for ; Mon, 5 Mar 2012 11:50:58 +0200 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Mar 2012 11:50:57 +0200 References: <20120305094330.27895.2135.idtracker@ietfa.amsl.com> To: core WG Message-Id: <525954D5-9A28-4C2B-A591-817999FB6A56@sensinode.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] Fwd: New Version Notification for draft-shelby-exi-registration-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 09:51:01 -0000 Here is a draft I wrote up describing a +exi Media Type suffix, and = which we have discussed over on the apps-discuss mailing list. = Soliciting any comments from CoRE as well. http://www.ietf.org/id/draft-shelby-exi-registration-00.txt Zach Begin forwarded message: > From: internet-drafts@ietf.org > Date: March 5, 2012 11:43:30 AM GMT+02:00 > To: zach@sensinode.com > Subject: New Version Notification for = draft-shelby-exi-registration-00.txt >=20 > A new version of I-D, draft-shelby-exi-registration-00.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-shelby-exi-registration > Revision: 00 > Title: The +exi Media Type Suffix > Creation date: 2012-03-05 > WG ID: Individual Submission > Number of pages: 5 >=20 > Abstract: > Efficient XML Interchange (EXI) is an XML representation technique > specified by the W3C to provie a binary alternative to the standard > text XML representation. This document defines a new Structure > Syntax Suffix "+exi" for use in a specific class of = protocols, where > "exi" content-type encoding or the generic = "application/exi" Media > Type are not applicable. >=20 >=20 >=20 >=20 > The IETF Secretariat --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From jari.arkko@piuha.net Mon Mar 5 03:01:19 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2393221F86DD for ; Mon, 5 Mar 2012 03:01:18 -0800 (PST) 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 oFcdX19FQWmP for ; Mon, 5 Mar 2012 03:01:02 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id BE71B21F86BB for ; Mon, 5 Mar 2012 03:01:01 -0800 (PST) Received: from localhost (178-55-233-219.bb.dnainternet.fi [178.55.233.219]) by p130.piuha.net (Postfix) with ESMTPSA id CC6932CC3C; Mon, 5 Mar 2012 13:00:46 +0200 (EET) Date: Mon, 05 Mar 2012 12:59:48 +0200 Message-ID: From: Jari Arkko To: "Angelo P. Castellani" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: core WG Subject: Re: [core] sleepy to sleepy communication 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: Mon, 05 Mar 2012 11:01:19 -0000 SSB3b3JyeSBhYm91dCBjcmVhdGluZyBsb3RzIG9mIGluZnJhc3RydWN0dXJlLCB0b28uIEJ1dCBJ IGFsc28gc2VlIG1hbnkgYXJjaGl0ZWN0dXJlcyB0aGF0IGFyZSBkZXZpY2Utc2VydmVyLXVzZXIv YXBwLCBhbmQgZm9yIHRob3NlIHRoZXJlIHdvdWxkbid0IG5lY2Vzc2FyaWx5IGJlIGFueSBpbXBh Y3QuCgpOb3QgYWxsIGxpbmsgbGF5ZXJzIGFuZCBkZXZpY2VzIGNhbiBnZXQgdG8gMyB5ZWFycywg YWN0dWFsbHkgZmFyIGZyb20gaXQuIFlldCB3ZSBwcm9wYWJseSB3YW50IHRvIHVzZSB0aG9zZSBm b3IgbWFueSByZWFzb25zLCBpbmNsdWRpbmcgY292ZXJhZ2UgKGNlbGx1bGFyKSBhbmQgZXhpc3Rp bmcgQVBzICh3bGFuKS4KCkFuZCBJIHRoaW5rIDMgeWVhcnMgaXMgZmFyIGZyb20gZW5vdWdoLiBJ IGhhdmUgMTAwIGRldmljZXMgYXQgaG9tZSwgYW5kIGlmIHRoZXkgaGFkIGV2ZW4gYSAxMCB5ZWFy IGJhdHRlcnkgbGlmZXRpbWUsIEknZCBzdGlsbCBjaGFuZ2UgYSBiYXR0ZXJ5IHBlciBtb250aC4K ClNvIEkgdGhpbmsgd2Ugc3RpbGwgaGF2ZSBwbGVudHkgb2Ygd29yayBsZWZ0LiBBdCBsZWFzdCBv biBzb21lIHBhcnRzOyBub3QgY2xhaW1pbmcgdGhhdCB0aGlzIG5lY2Vzc2FyaWx5IG1lYW5zIHNv bWV0aGluZyBmb3IgdGhlIENPUkUgV0cuCgpKYXJpCgoiQW5nZWxvIFAuIENhc3RlbGxhbmkiIDxh bmdlbG9AY2FzdGVsbGFuaS5uZXQ+IHdyb3RlOgoKPkkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGlz IGNhbiBzYXZlIGEgbG90IG1vcmUgb2YgZW5lcmd5LCBpZiB0aGUgaG9zdHMKPmNhbiBwcm92aWRl IHNlcnZpY2UgZHVyaW5nIHRoZWlycyAib2ZmaWNlIGhvdXJzIiA6KQo+Cj5Ib3dldmVyIGlmIHRo ZSBub2RlcyB3aWxsIGJlaGF2ZSBpbiBzdWNoIGEgd2F5LCBmb3Igc3VyZSB0aGlzIHdpbGwgYmUK PnZpc2libGUgdG8gdGhlIGNsaWVudHMgYW5kIGxvdHMgb2YgaW5mcmFzdHJ1Y3R1cmUgKHByb3hp ZXMpIHdpbGwgYmUKPnJlcXVpcmVkIHRvIGdldCBhbnl0aGluZyB1c2FibGUgYnkgdGhlIHVzZXJz Lgo+Cj5XaXRoIHJlZ3VsYXIgc2Vuc29yIG5ldHdvcmtzIGR1dHkgY3ljbGluZywgYSB+MyB5ZWFy cyBsaWZldGltZSBpcwo+ZmVhc2libGUgd2l0aCByZWd1bGFyIGJhdHRlcmllcyAoZGVwZW5kaW5n IHVwb24gYWN0dWFsIHVzYWdlIGFuZAo+bmV0d29yayB0cmFmZmljKS4gQXJlIHlvdSB0YXJnZXRp bmcgYSB1c2UgY2FzZSB3aXRoIHRpZ2h0ZXIKPnJlcXVpcmVtZW50cz8KPgo+QmVzdCwKPkFuZ2Vs bwo+Cj5PbiBNb24sIE1hciA1LCAyMDEyIGF0IDEwOjE2LCBKYXJpIEFya2tvIDxqYXJpLmFya2tv QHBpdWhhLm5ldD4gd3JvdGU6Cj4+Cj4+IEFuZ2VsbywKPj4KPj4KPj4+IEluZGVlZCBzZW5zb3Ig bmV0d29ya3Mgc3VwcG9ydCBzbGVlcGluZyB1c2luZyByYWRpbyBkdXR5IGN5Y2xpbmcgYXQKPj4+ IGxvd2VyIGxheWVycywgdGhpcyB0dXJucyBvdXQgaW4gaGF2aW5nIHRoZSBzbGVlcGluZyBmdW5j dGlvbmFsaXR5Cj4+PiB3aXRob3V0IGFueSBsb3NzIG9mIGNvbW11bmljYXRpb24gYXQgdGhlIHVw cGVyIGxheWVycy4KPj4+Cj4+Cj4+IFdlIGRpc2N1c3NlZCB0aGlzIGEgY291cGxlIG9mIElFVEZz IGJhY2suIFNpbmNlIHRoZW4gSSd2ZSBiZWVuIGRvaW5nIHNvbWUKPj4gdGFsa2luZyB0byBvdXIg cmVzZWFyY2hlcnMgd2hvIG1lYXN1cmUgYW5kIGltcHJvdmUgcG93ZXIgdXNhZ2UgaW4gcmFkaW9z Lgo+Pgo+PiBGaXJzdCwgZHV0eSBjeWNsaW5nIGlzIGFscmVhZHkgcHJldHR5IHdpZGVseSB1c2Vk IGZvciByYWRpbyB0ZWNobm9sb2d5LiBBbGwKPj4gY2VsbHVsYXIgc3lzdGVtcywgZm9yIGluc3Rh bmNlLCB0dXJuIG9mZiB0aGUgcmFkaW8gZXhjZXB0IGluIGR1cmluZyB0aGUgdGltZQo+PiB0aGV5 IGxpc3RlbiBmb3IgcG9zc2libGUgaW5jb21pbmcgcGFnaW5nIHNpZ25hbHMsIHN5c3RlbSBpbmZv cm1hdGlvbgo+PiBuZWNlc3NhcnkgdG8gc3RheSBpbiBjb250YWN0IGF0IGFsbCwgb3Igd2hlbiB0 aGV5IGhhdmUgYmVlbiBncmFudGVkIGEgdGltZQo+PiBzbG90IHRvIHNlbmQuCj4+Cj4+IFNlY29u ZGx5IGFuZCBtb3JlIGltcG9ydGFudGx5LCBwZXIgdGhlaXIgbWVhc3VyZW1lbnRzLCBldmVuIGFm dGVyIGFsbCB0aGUKPj4gYWJvdmUgdGVjaG5pcXVlcywgcGVyaW9kaWMgbGlzdGVuaW5nIGZvciBw b3NzaWJseSBpbmNvbWluZyBtZXNzYWdlcyBpcyB0aGUKPj4gYmlnZ2VzdCBjb25zdW1lciBvZiBl bmVyZ3kgaW4gYXBwbGljYXRpb25zIHdoZXJlIHdlJ2QgbGlrZSB0byBoYXZlIGEgbG9uZwo+PiBi YXR0ZXJ5IGxpZmUsIHN1Y2ggYXMgaW4gc2Vuc29ycy4gVGhhdCBwb3dlciB1c2FnZSBkd2FyZnMg ZXZlcnl0aGluZyBlbHNlLAo+PiBzbyBpdCBoYXMgdG8gY29tZSBkb3duLCBzb21laG93LCB0byBt YWtlIGFuIGltcHJvdmVtZW50Lgo+Pgo+PiBTbyBpZiB3ZSB3YW50IHRvIGFjaGlldmUgc2lnbmlm aWNhbnRseSBsb25nZXIgYmF0dGVyeSBsaWZldGltZXMgKGFuZCBJIGNsYWltCj4+IHdlIG5lZWQg dGhvc2UpIHdlIG5lZWQgdG8gY2hhbmdlIHNvbWUgdGhpbmdzLiBPYnZpb3VzbHkgYSBsb3Qgb2Yg dGhlIGxpbmsKPj4gbGF5ZXJzIGNhbiBiZSB0dW5lZCBiZXR0ZXIsIGltcGxlbWVudGluZyBzaW1w bHkgbG9uZ2VyIHBhZ2luZyBmcmVxdWVuY2llcywKPj4gZm9yIGluc3RhbmNlLiBNeSBoeXBvdGhl c2lzIGlzIHRoYXQgd2UnbGwgaGF2ZSB0byBnbyBsb25nZXIgdGhhbiB3aGF0Cj4+IHR5cGljYWwg YXBwbGljYXRpb24gcHJvdG9jb2wgdGltZW91dHMgYXJlIHRvZGF5LCBzbyB0aGUgY2hhbmdlIHdv dWxkIGJlCj4+IHNvbWV0aGluZyB0aGF0IGlzIHZpc2libGUgdG8gYXBwbGljYXRpb25zLiBXZSBj b3VsZCBjaGFuZ2Ugc29tZSBvZiB0aGUKPj4gdGltZW91dHMsIGJ1dCBpdCBpcyBub3QgY2xlYXIg dGhhdCBuZXR3b3JrIGJ1ZmZlcnMgYW5kIGFsbCB1bmRlcmx5aW5nCj4+IG1lY2hhbmlzbXMgZGVw bG95ZWQgdG9kYXkgc3VwcG9ydCB0aG9zZSB3aXRob3V0IGNoYW5nZXMuIEFuZCBpbiBnZW5lcmFs LCBJCj4+IHRoaW5rIGl0IGlzIGJldHRlciB0byBmaXQgdGhlIGNvbW11bmljYXRpb24gbW9kZWwg dG8gdGhlIHByb2JsZW0gYXQgaGFuZAo+PiB0aGFuIHZpY2UgdmVyc2EuIEFzIGEgcmVzdWx0LCBJ IHBlcnNvbmFsbHkgYmVsaWV2ZSB0aGF0IHdlIG5lZWQgdG8gYnVpbGQKPj4gYXBwbGljYXRpb25z IHRoYXQgbmF0aXZlbHkgY29tbXVuaWNhdGUgaW4gd2F5cyB0aGF0IG1ha2Ugc2xlZXAgbW9kZXMg ZWFzeS4KPj4gU3VjaCBhcyBwdWJsaXNoLXN1YnNjcmliZSBpbnN0ZWFkIG9mIGRpcmVjdCByZXF1 ZXN0LXJlc3BvbnNlIGZyb20gYW55b25lIHdobwo+PiBuZWVkcyB0aGUgaW5mb3JtYXRpb24uIEJ1 dCBsaWtlIEkgc2FpZCwgdGhpcyBpcyBhIGh5cG90aGVzaXMgYW5kIEknZCBsb3ZlIHRvCj4+IGJl IHByb3ZlbiB3cm9uZy4KPj4KPj4gSmFyaQo+Pgo+Pgo= From matthieu.vial@non.schneider-electric.com Mon Mar 5 06:32:20 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0C421F872D for ; Mon, 5 Mar 2012 06:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oq3fnMKTavlM for ; Mon, 5 Mar 2012 06:32:20 -0800 (PST) Received: from mailX01.eud.schneider-electric.com (mailx01.eud.schneider-electric.com [205.167.7.35]) by ietfa.amsl.com (Postfix) with ESMTP id 24DF521F8729 for ; Mon, 5 Mar 2012 06:32:19 -0800 (PST) Received: from ateui03.schneider-electric.com ([10.198.21.36]) by mailX01.eud.schneider-electric.com with ESMTP id 2012030515272111-94067 ; Mon, 5 Mar 2012 15:27:21 +0100 In-Reply-To: To: Zach Shelby MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: matthieu.vial@non.schneider-electric.com Message-ID: Date: Mon, 5 Mar 2012 15:32:12 +0100 X-MIMETrack: Serialize by Router on ATEUI03.Schneider-Electric.com/T/SVR/Schneider at 05/03/2012 15:32:16, Serialize complete at 05/03/2012 15:32:16, Itemize by SMTP Server on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 05/03/2012 15:27:21, Serialize by Router on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 05/03/2012 15:27:24, Serialize complete at 05/03/2012 15:27:24 Content-Type: text/plain; charset="US-ASCII" Cc: core WG Subject: Re: [core] Tr : New Version Notification for draft-vial-core-mirror-proxy-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, 05 Mar 2012 14:32:20 -0000 >Actually I have already considered including in the RD draft an id= attribute that allows you to associate a unique identifier (e.g. dev-urn) with an end-point. Would be happy to include that in the RD registration interface if people find that useful. I'm worried about the length of the payload if the identifier is repeated for each link. ;rt="profile:dev";if="core#p";id=" urn:dev:mac:0024befffe804ff1", Matthieu From zach@sensinode.com Mon Mar 5 07:27:14 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0166521F872F for ; Mon, 5 Mar 2012 07:27:14 -0800 (PST) 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 xWtvFqRi9gGa for ; Mon, 5 Mar 2012 07:27:13 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id CE3C421F872D for ; Mon, 5 Mar 2012 07:27:12 -0800 (PST) Received: from [172.20.10.4] (81-197-24-150.elisa-mobile.fi [81.197.24.150]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q25FR4Xt016522; Mon, 5 Mar 2012 17:27:09 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Mon, 5 Mar 2012 17:27:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: matthieu.vial@non.schneider-electric.com X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] Tr : New Version Notification for draft-vial-core-mirror-proxy-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, 05 Mar 2012 15:27:14 -0000 On Mar 5, 2012, at 4:32 PM, matthieu.vial@non.schneider-electric.com = wrote: >> Actually I have already considered including in the RD draft an id=3D=20= > attribute that allows you to associate a unique identifier (e.g. = dev-urn)=20 > with an end-point. Would be happy to include that in the RD = registration=20 > interface if people find that useful.=20 >=20 > I'm worried about the length of the payload if the identifier is = repeated=20 > for each link. >=20 > = ;rt=3D"profile:dev";if=3D"core#p";i= d=3D" > urn:dev:mac:0024befffe804ff1", I agree, which is why I wasn't suggesting putting it in the link. = Instead, id=3D would be associated to the end-point and passed to the RD = only during the initial registration. So: POST /rd?h=3Dpowernode-005&id=3Durn:dev:mac:0024befffe804ff1 Now I think you might be referring to the links that an RD returns as a = result of a lookup. I agree, it would be inefficient to repeat that for = each resource link. I think there should be a way to return a link to = the end-point itself, where such end-point specific information can be = returned (e.g. id=3D). This could be done by providing an additional = REST interface for looking up end-points rather than resources. Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From matthieu.vial@non.schneider-electric.com Mon Mar 5 09:05:37 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B5521F87D1 for ; Mon, 5 Mar 2012 09:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 oOe6XnTkK00l for ; Mon, 5 Mar 2012 09:05:36 -0800 (PST) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by ietfa.amsl.com (Postfix) with ESMTP id B81A721F85C5 for ; Mon, 5 Mar 2012 09:05:27 -0800 (PST) Received: from ateui03.schneider-electric.com ([10.198.21.36]) by mailX03.eud.schneider-electric.com with ESMTP id 2012030518015416-117643 ; Mon, 5 Mar 2012 18:01:54 +0100 In-Reply-To: To: Zach Shelby MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: matthieu.vial@non.schneider-electric.com Message-ID: Date: Mon, 5 Mar 2012 18:05:22 +0100 X-MIMETrack: Serialize by Router on ATEUI03.Schneider-Electric.com/T/SVR/Schneider at 05/03/2012 18:05:25, Serialize complete at 05/03/2012 18:05:25, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 05/03/2012 18:01:54, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 05/03/2012 18:01:56, Serialize complete at 05/03/2012 18:01:56 Content-Type: text/plain; charset="US-ASCII" Cc: core WG Subject: Re: [core] Tr : New Version Notification for draft-vial-core-mirror-proxy-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, 05 Mar 2012 17:05:37 -0000 >Now I think you might be referring to the links that an RD returns as a result of a lookup. I agree, it would be inefficient to repeat that for each resource link. Exactly. >I think there should be a way to return a link to the end-point itself, where such end-point specific information can be returned (e.g. id=). This could be done by providing an additional REST interface for looking up end-points rather than resources. When a sleeping endpoint registers with 2 mirror proxies, we've got 2 endpoints in the RD database for the same id attribute. Also the proxy shares its endpoint with the registered sleeping nodes. If I'm following your idea the right way, the new interface might return something like below (don't pay too much attention to the attribute format, could be something else) GET /rd/new_interface ;ep="coap://[aaaa::ff:fe00:0001]/";h="proxy1";id="urn:dev:mac:0024befffe804f01", ;ep="coap://[aaaa::ff:fe00:0001]/";h="proxy1";ins="sleepy";id="urn:dev:mac:0024befffe804f03", ;ep="coap://[aaaa::ff:fe00:0002]/";h="proxy2";id="urn:dev:mac:0024befffe804f02", ;ep="coap://[aaaa::ff:fe00:0002]/";h="proxy2";ins="sleepy";id="urn:dev:mac:0024befffe804f03", I still don't know how to relate the previous result with a resource lookup like: GET /rd/rt=Temperature ;rt="Temperature";if="sensor" ;rt="Temperature";if="sensor" ;rt="Temperature";if="sensor" ;rt="Temperature";if="sensor" Lines 2 and 4 are actually the same sensor mirrored on 2 proxies. We might extend the Context parameter in the registration interface to accept a root path. We would have then: GET /rd/new_interface ;ep="coap://[aaaa::ff:fe00:0001]/";h="proxy1";id="urn:dev:mac:0024befffe804f01", ;ep="coap://[aaaa::ff:fe00:0001]/mp/0";h="proxy1";ins="sleepy";id="urn:dev:mac:0024befffe804f03", ;ep="coap://[aaaa::ff:fe00:0002]/";h="proxy2";id="urn:dev:mac:0024befffe804f02", ;ep="coap://[aaaa::ff:fe00:0002]/mp/0";h="proxy2";ins="sleepy";id="urn:dev:mac:0024befffe804f03", But it's still quite complex for a client to deduplicate the links. Adding the identifier to each link is not efficient but should work with both RD and /.w-k/core. Matthieu From cabo@tzi.org Mon Mar 5 10:53:00 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B10221F8857; Mon, 5 Mar 2012 10:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.577 X-Spam-Level: X-Spam-Status: No, score=-105.577 tagged_above=-999 required=5 tests=[AWL=0.072, 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 7qtREwG4ZZcA; Mon, 5 Mar 2012 10:52:59 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A80EC21F8836; Mon, 5 Mar 2012 10:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q25IqjpP004456; Mon, 5 Mar 2012 19:52:45 +0100 (CET) Received: from eduroam-pool6-0113.wlan.uni-bremen.de (eduroam-pool6-0113.wlan.uni-bremen.de [134.102.24.113]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D02DB38B; Mon, 5 Mar 2012 19:52:45 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <1B2B5C1F-AF12-44CB-BCF1-C5DD2978FBEB@tzi.org> Date: Mon, 5 Mar 2012 19:52:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <95A48EF5-8E0A-46C7-9677-83D5B218497F@tzi.org> References: <1B2B5C1F-AF12-44CB-BCF1-C5DD2978FBEB@tzi.org> To: 6lowpan@ietf.org, "core@ietf.org WG" , roll@ietf.org, lwip@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [core] Constrained Node/Network Cluster @ IETF83 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Mar 2012 18:53:01 -0000 In the final agenda, homenet and 6man have exchanged places. 6man still is a bit of a conflict for core, but much less so than = homenet. Thanks to our ADs for fixing this! https://datatracker.ietf.org/meeting/83/agenda.html Gr=FC=DFe, Carsten On Feb 24, 2012, at 09:25, Carsten Bormann wrote: > Here is my usual compilation of the draft agenda for IETF83. > Note that this agenda is subject to change, so please don't plan = travel around it. > This time, we are nicely spread out over the week, so a lot of things = will happen between the meeting slots. >=20 > Gr=FC=DFe, Carsten >=20 >=20 > ***DRAFT*** Agenda for Constrained Node/Network related events during > IETF 83 in Paris > ***Subject to change*** -- don't plan travel around this >=20 > * FRIDAY, March 23, 2012 >=20 > IAB Workshop on Smart Object Security >=20 > * SATURDAY, March 24, 2012; SUNDAY, March 25, 2012 >=20 > ETSI CoAP plugfest >=20 > * MONDAY, March 26, 2012 >=20 > 0900-1130 > Maillot OPS v6ops IPv6 Operations WG >=20 > * TUESDAY, March 27, 2012 >=20 > 0900-1130 > 243 APP *core* Constrained RESTful Environments WG > Maillot INT homenet Home Networking WG >=20 > 1300-1500 > 241 OPS eman Energy Management WG >=20 > * WEDNESDAY, March 28, 2012 >=20 > 0900-1130 > 242AB INT 6man IPv6 Maintenance WG >=20 > 1300-1500 > 241 RTG *roll* Routing Over Low power and Lossy networks WG >=20 > * THURSDAY, March 29, 2012 >=20 > 1300-1500 > Maillot INT intarea Internet Area Working Group WG >=20 > 1520-1720 > 252B INT *lwig* Light-Weight Implementation Guidance WG > Maillot OPS v6ops IPv6 Operations WG >=20 > * FRIDAY, March 30, 2012 >=20 > 0900-1100 > 253 APP *core* Constrained RESTful Environments WG >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From tho@koanlogic.com Mon Mar 5 12:27:21 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8596C11E80AE for ; Mon, 5 Mar 2012 12:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[AWL=1.166, BAYES_00=-2.599, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XL44VihVPhYj for ; Mon, 5 Mar 2012 12:27:21 -0800 (PST) Received: from relay1.serverpronto.com (srv1023-mia.serverpronto.com [38.117.1.254]) by ietfa.amsl.com (Postfix) with ESMTP id F06DB11E80AB for ; Mon, 5 Mar 2012 12:27:20 -0800 (PST) Received: from gonzo.koanlogic.com (166-118-60-69.serverpronto.com [69.60.118.166] (may be forged)) by relay1.serverpronto.com (8.13.8/8.13.8) with ESMTP id q25HQ2E6007443; Mon, 5 Mar 2012 12:26:03 -0500 Received: from host196-51-dynamic.47-79-r.retail.telecomitalia.it ([79.47.51.196]:52053 helo=t.homenet.telecomitalia.it) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1S4eUk-0007Ja-7C; Mon, 05 Mar 2012 15:27:18 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: <95A48EF5-8E0A-46C7-9677-83D5B218497F@tzi.org> Date: Mon, 5 Mar 2012 21:26:49 +0100 Content-Transfer-Encoding: 7bit Message-Id: <46E7108E-2658-4758-B9FE-20F22F996981@koanlogic.com> References: <1B2B5C1F-AF12-44CB-BCF1-C5DD2978FBEB@tzi.org> <95A48EF5-8E0A-46C7-9677-83D5B218497F@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.47.51.196 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Cc: core WG Subject: Re: [core] Constrained Node/Network Cluster @ IETF83 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Mar 2012 20:27:21 -0000 On Mar 5, 2012, at 7:52 PM, Carsten Bormann wrote: > In the final agenda, homenet and 6man have exchanged places. > 6man still is a bit of a conflict for core, but much less so than homenet. > Thanks to our ADs for fixing this! > > https://datatracker.ietf.org/meeting/83/agenda.html Great, thanks a lot. From prvs=6412C1EF46=guido.moritz@uni-rostock.de Tue Mar 6 03:44:38 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6998821F88EB for ; Tue, 6 Mar 2012 03:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=1.064, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 uxKCIqkV0bIA for ; Tue, 6 Mar 2012 03:44:37 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0471C21F88D0 for ; Tue, 6 Mar 2012 03:44:37 -0800 (PST) From: Guido Moritz To: 'Zach Shelby' , 'core WG' References: <20120305094330.27895.2135.idtracker@ietfa.amsl.com> <525954D5-9A28-4C2B-A591-817999FB6A56@sensinode.com> In-Reply-To: <525954D5-9A28-4C2B-A591-817999FB6A56@sensinode.com> Date: Tue, 6 Mar 2012 12:44:38 +0100 Message-ID: <003001ccfb8e$8305b960$89112c20$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGIiWMwCsxA5IPfizRlUH/eCE4JFAHdaJpBltcbIRA= Content-Language: de X-Originating-IP: [139.30.201.226] Subject: Re: [core] Fwd: New Version Notification for draft-shelby-exi-registration-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 11:44:38 -0000 Hi Zach, I have read the draft and also stumbled through the discussion on the = APPS WG list. You describe two scenarios for the usage of +exi. I would = mainly pick up the second: o Use EXI as a native encoding (without the use of XML as an interemediate) in Strict Schema-informed mode, and the base Media Type indicates to the protocol the Schema that was used to produce the EXI grammar. The major intention of this use case is to indicate the used schemas = that are required to generate the appropriate EXI grammar. To come up with an example I would use application/soap. But there is no clear relationship which schemas have to be included if application/soap+exi is used. Is it only the SOAP schema? Which version of SOAP? Is it also the = WS-Addressing schema? Which version of WS-Addressing? What WS-* or application = specific schemas else?! Thus, it would be required to define for each Media Type very strict = which schemas and versions are required and which not. The approach described = in the draft is too generic. I would argue this definition is not in the responsibility of the IETF, but must be e.g. part of the W3C EXI WG.=20 My 2 cents, Guido > -----Urspr=FCngliche Nachricht----- > Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag = von > Zach Shelby > Gesendet: Montag, 5. M=E4rz 2012 10:51 > An: core WG > Betreff: [core] Fwd: New Version Notification for draft-shelby-exi-registration- > 00.txt >=20 > Here is a draft I wrote up describing a +exi Media Type suffix, and = which we > have discussed over on the apps-discuss mailing list. Soliciting any comments > from CoRE as well. >=20 > http://www.ietf.org/id/draft-shelby-exi-registration-00.txt >=20 > Zach >=20 > Begin forwarded message: >=20 > > From: internet-drafts@ietf.org > > Date: March 5, 2012 11:43:30 AM GMT+02:00 > > To: zach@sensinode.com > > Subject: New Version Notification for draft-shelby-exi-registration-00.txt > > > > A new version of I-D, draft-shelby-exi-registration-00.txt has been successfully > submitted by Zach Shelby and posted to the IETF repository. > > > > Filename: draft-shelby-exi-registration > > Revision: 00 > > Title: The +exi Media Type Suffix > > Creation date: 2012-03-05 > > WG ID: Individual Submission > > Number of pages: 5 > > > > Abstract: > > Efficient XML Interchange (EXI) is an XML representation technique > > specified by the W3C to provie a binary alternative to the = standard > > text XML representation. This document defines a new Structure > > Syntax Suffix "+exi" for use in a specific class of protocols, where > > "exi" content-type encoding or the generic > "application/exi" Media > > Type are not applicable. > > > > > > > > > > The IETF Secretariat >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From zach@sensinode.com Tue Mar 6 05:22:37 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392E921F8902 for ; Tue, 6 Mar 2012 05:22:37 -0800 (PST) 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 XXD6Rad7v05U for ; Tue, 6 Mar 2012 05:22:36 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 79FE521F8903 for ; Tue, 6 Mar 2012 05:22:33 -0800 (PST) Received: from [172.20.10.2] (80-186-80-108.elisa-mobile.fi [80.186.80.108]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q26DMOtT023212; Tue, 6 Mar 2012 15:22:27 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: <003001ccfb8e$8305b960$89112c20$@uni-rostock.de> Date: Tue, 6 Mar 2012 15:22:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1DAC05A7-F0F1-4415-8EEA-6975685F1D73@sensinode.com> References: <20120305094330.27895.2135.idtracker@ietfa.amsl.com> <525954D5-9A28-4C2B-A591-817999FB6A56@sensinode.com> <003001ccfb8e$8305b960$89112c20$@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1084) Cc: 'core WG' Subject: Re: [core] Fwd: New Version Notification for draft-shelby-exi-registration-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 13:22:37 -0000 Hi, On Mar 6, 2012, at 1:44 PM, Guido Moritz wrote: > Hi Zach, >=20 > I have read the draft and also stumbled through the discussion on the = APPS > WG list. You describe two scenarios for the usage of +exi. I would = mainly > pick up the second: The idea was that the use of +exi is recommended for both bullet points. = The point of that section is just to guide readers to where the use of = +exi is appropriate compared to the existing exi content encoding or = application/exi approaches.=20 >=20 > o Use EXI as a native encoding (without the use of XML as an > interemediate) in Strict Schema-informed mode, and the base Media > Type indicates to the protocol the Schema that was used to = produce > the EXI grammar. >=20 > The major intention of this use case is to indicate the used schemas = that > are required to generate the appropriate EXI grammar. Not only the used schema, but also the underlying semantics of what is = contained in the schema.=20 > To come up with an > example I would use application/soap. But there is no clear = relationship > which schemas have to be included if application/soap+exi is used. Is = it > only the SOAP schema? Which version of SOAP? Is it also the = WS-Addressing > schema? Which version of WS-Addressing? What WS-* or application = specific > schemas else?! The purpose of this draft is to define the registration guidelines for = someone registering an application/foo+exi media type. So it would be up = to the person requesting that media type to describe what schemas are = used and how to interpret the Schema ID field (in case multiple schemas = are possible e.g.). So if you are registering the media type = application/soap+exi then you need to define those details. > Thus, it would be required to define for each Media Type very strict = which > schemas and versions are required and which not. Yes, each media type registration needs to define these things. This is = needed to ensure interoperability. Is that a bad thing? > The approach described in > the draft is too generic. I would argue this definition is not in the > responsibility of the IETF, but must be e.g. part of the W3C EXI WG.=20= This draft is just defining the +exi suffix registration procedure, = which should be generic. In my understanding the iETF is the right place = to do it. Zach >=20 > My 2 cents, > Guido >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag = von >> Zach Shelby >> Gesendet: Montag, 5. M=E4rz 2012 10:51 >> An: core WG >> Betreff: [core] Fwd: New Version Notification for > draft-shelby-exi-registration- >> 00.txt >>=20 >> Here is a draft I wrote up describing a +exi Media Type suffix, and = which > we >> have discussed over on the apps-discuss mailing list. Soliciting any > comments >> from CoRE as well. >>=20 >> http://www.ietf.org/id/draft-shelby-exi-registration-00.txt >>=20 >> Zach >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Date: March 5, 2012 11:43:30 AM GMT+02:00 >>> To: zach@sensinode.com >>> Subject: New Version Notification for > draft-shelby-exi-registration-00.txt >>>=20 >>> A new version of I-D, draft-shelby-exi-registration-00.txt has been > successfully >> submitted by Zach Shelby and posted to the IETF repository. >>>=20 >>> Filename: draft-shelby-exi-registration >>> Revision: 00 >>> Title: The +exi Media Type Suffix >>> Creation date: 2012-03-05 >>> WG ID: Individual Submission >>> Number of pages: 5 >>>=20 >>> Abstract: >>> Efficient XML Interchange (EXI) is an XML representation technique >>> specified by the W3C to provie a binary alternative to the standard >>> text XML representation. This document defines a new Structure >>> Syntax Suffix "+exi" for use in a specific class of > protocols, where >>> "exi" content-type encoding or the generic >> "application/exi" Media >>> Type are not applicable. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>=20 >> -- >> Zach Shelby, Chief Nerd, Sensinode Ltd. >> http://www.sensinode.com >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" >> Mobile: +358 40 7796297 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From prvs=1412764E31=guido.moritz@uni-rostock.de Tue Mar 6 05:39:24 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C7A21F8857 for ; Tue, 6 Mar 2012 05:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.851, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 ir2wcf1N0Uyb for ; Tue, 6 Mar 2012 05:39:23 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFC321F8848 for ; Tue, 6 Mar 2012 05:39:18 -0800 (PST) From: Guido Moritz To: 'Zach Shelby' References: <20120305094330.27895.2135.idtracker@ietfa.amsl.com> <525954D5-9A28-4C2B-A591-817999FB6A56@sensinode.com> <003001ccfb8e$8305b960$89112c20$@uni-rostock.de> <1DAC05A7-F0F1-4415-8EEA-6975685F1D73@sensinode.com> In-Reply-To: <1DAC05A7-F0F1-4415-8EEA-6975685F1D73@sensinode.com> Date: Tue, 6 Mar 2012 14:39:16 +0100 Message-ID: <000e01ccfb9e$8688ab50$939a01f0$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGIiWMwCsxA5IPfizRlUH/eCE4JFAHdaJpBAW5IUc4CMt1O7Za6Mlzg Content-Language: de X-Originating-IP: [139.30.201.226] Cc: 'core WG' Subject: Re: [core] Fwd: New Version Notification for draft-shelby-exi-registration-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 13:39:24 -0000 I am still the opinion that this is way too much semantics that is tried = to push into the Media Type field. EXI has its own mechanisms/header field = for this (i.e. EXI header including SchemaID field).=20 To get a comprehensive solution, also all the other options of the EXI header (alignment, compression, strict, preserve...) must be included in = the Media Type definition. I still do not get the point, why the way EXI handles these by internal options is not sufficient? The only thing to carry in the Media Type is = that whether it is EXI or not. Everything beyond that, i.e. the specific EXI mode, should be expressed by the existing EXI options.=20 All these definitions are application/protocol specific. Sure, it must = be defined somewhere. But I would say define a new Media Type for each = possible combination of protocol schemas, application specific schemas and schema versions is not an appropriate solution.=20 Maybe some realistic examples of +exi Media Types to be defined would = help to generate new input for this discussion?=20 Guido > -----Urspr=FCngliche Nachricht----- > Von: Zach Shelby [mailto:zach@sensinode.com] > Gesendet: Dienstag, 6. M=E4rz 2012 14:22 > An: Guido Moritz > Cc: 'core WG' > Betreff: Re: AW: [core] Fwd: New Version Notification for draft-shelby-exi- > registration-00.txt >=20 > Hi, >=20 > On Mar 6, 2012, at 1:44 PM, Guido Moritz wrote: >=20 > > Hi Zach, > > > > I have read the draft and also stumbled through the discussion on = the APPS > > WG list. You describe two scenarios for the usage of +exi. I would mainly > > pick up the second: >=20 > The idea was that the use of +exi is recommended for both bullet = points. The > point of that section is just to guide readers to where the use of = +exi is > appropriate compared to the existing exi content encoding or application/exi > approaches. >=20 > > > > o Use EXI as a native encoding (without the use of XML as an > > interemediate) in Strict Schema-informed mode, and the base = Media > > Type indicates to the protocol the Schema that was used to = produce > > the EXI grammar. > > > > The major intention of this use case is to indicate the used schemas that > > are required to generate the appropriate EXI grammar. >=20 > Not only the used schema, but also the underlying semantics of what is > contained in the schema. >=20 > > To come up with an > > example I would use application/soap. But there is no clear = relationship > > which schemas have to be included if application/soap+exi is used. = Is it > > only the SOAP schema? Which version of SOAP? Is it also the WS-Addressing > > schema? Which version of WS-Addressing? What WS-* or application specific > > schemas else?! >=20 > The purpose of this draft is to define the registration guidelines for someone > registering an application/foo+exi media type. So it would be up to = the person > requesting that media type to describe what schemas are used and how = to > interpret the Schema ID field (in case multiple schemas are possible e.g.). So if > you are registering the media type application/soap+exi then you need = to > define those details. >=20 > > Thus, it would be required to define for each Media Type very strict which > > schemas and versions are required and which not. >=20 > Yes, each media type registration needs to define these things. This = is needed > to ensure interoperability. Is that a bad thing? >=20 > > The approach described in > > the draft is too generic. I would argue this definition is not in = the > > responsibility of the IETF, but must be e.g. part of the W3C EXI WG. >=20 > This draft is just defining the +exi suffix registration procedure, = which should be > generic. In my understanding the iETF is the right place to do it. >=20 > Zach >=20 >=20 > > > > My 2 cents, > > Guido > > > >> -----Urspr=FCngliche Nachricht----- > >> Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im = Auftrag von > >> Zach Shelby > >> Gesendet: Montag, 5. M=E4rz 2012 10:51 > >> An: core WG > >> Betreff: [core] Fwd: New Version Notification for > > draft-shelby-exi-registration- > >> 00.txt > >> > >> Here is a draft I wrote up describing a +exi Media Type suffix, and which > > we > >> have discussed over on the apps-discuss mailing list. Soliciting = any > > comments > >> from CoRE as well. > >> > >> http://www.ietf.org/id/draft-shelby-exi-registration-00.txt > >> > >> Zach > >> > >> Begin forwarded message: > >> > >>> From: internet-drafts@ietf.org > >>> Date: March 5, 2012 11:43:30 AM GMT+02:00 > >>> To: zach@sensinode.com > >>> Subject: New Version Notification for > > draft-shelby-exi-registration-00.txt > >>> > >>> A new version of I-D, draft-shelby-exi-registration-00.txt has = been > > successfully > >> submitted by Zach Shelby and posted to the IETF repository. > >>> > >>> Filename: draft-shelby-exi-registration > >>> Revision: 00 > >>> Title: The +exi Media Type Suffix > >>> Creation date: 2012-03-05 > >>> WG ID: Individual Submission > >>> Number of pages: 5 > >>> > >>> Abstract: > >>> Efficient XML Interchange (EXI) is an XML representation = technique > >>> specified by the W3C to provie a binary alternative to the = standard > >>> text XML representation. This document defines a new Structure > >>> Syntax Suffix "+exi" for use in a specific class of > > protocols, where > >>> "exi" content-type encoding or the generic > >> "application/exi" Media > >>> Type are not applicable. > >>> > >>> > >>> > >>> > >>> The IETF Secretariat > >> > >> -- > >> Zach Shelby, Chief Nerd, Sensinode Ltd. > >> http://www.sensinode.com > >> http://zachshelby.org - My blog "On the Internet of Things" > >> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" > >> Mobile: +358 40 7796297 > >> > >> _______________________________________________ > >> core mailing list > >> core@ietf.org > >> https://www.ietf.org/mailman/listinfo/core > > >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 From zehn.cao@gmail.com Wed Mar 7 02:02:14 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0443421F87A0 for ; Wed, 7 Mar 2012 02:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 aptL8XjepSgs for ; Wed, 7 Mar 2012 02:02:13 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 40E9521F86E4 for ; Wed, 7 Mar 2012 02:02:13 -0800 (PST) Received: by iazz13 with SMTP id z13so9788537iaz.31 for ; Wed, 07 Mar 2012 02:02:13 -0800 (PST) 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=akb23ijTyAEhYCo/kt35UxnzzT3E8N4jmY3YrjP2HR0=; b=XLZbpPWc9l1E7VfuIG2Gw/v3prgOjEW3TNpzhAM/+4/ylxFPrsQmgJSmNJDW/CXwZu 8YmEHEwHuEmbVB6/J4vmRNpZ51tANIOTHBrBZbSuHaIIRineCVNdgY7Hphv3od4gEPrR HDgbjxM6GGe4ZSjzOt1BKH7XbjJh6lNa6pC3pheiQt5qfQv4+M6pQDba0PvKXo+hkNec kg+tEVJSJ1VbFx2qBXW5nVclPEEWdPm/Sj/a50hZB6ExnRi3yoBWFAWTLBdLVclhFHhO 7v+qw7Qv8rdx4+yAlwCcePlvkkLn2xFePfvp+nEFPN/pbZ8AnFYSitVQDe5Db+7UkX7+ lsew== MIME-Version: 1.0 Received: by 10.50.194.228 with SMTP id hz4mr5626052igc.35.1331114532965; Wed, 07 Mar 2012 02:02:12 -0800 (PST) Received: by 10.42.197.7 with HTTP; Wed, 7 Mar 2012 02:02:12 -0800 (PST) In-Reply-To: References: <9032C193-A015-4F41-B441-4D1D47594FC9@koanlogic.com> <4F53E746.7050401@piuha.net> <9B51E46C-D03D-4911-8D00-65B56DE48F63@koanlogic.com> <4F548482.9070707@piuha.net> Date: Wed, 7 Mar 2012 18:02:12 +0800 Message-ID: From: Zhen Cao To: "Angelo P. Castellani" Content-Type: text/plain; charset=ISO-8859-1 Cc: core WG Subject: Re: [core] sleepy to sleepy communication 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: Wed, 07 Mar 2012 10:02:14 -0000 On Mon, Mar 5, 2012 at 5:26 PM, Angelo P. Castellani wrote: > I agree with you that this can save a lot more of energy, if the hosts > can provide service during theirs "office hours" :) > > However if the nodes will behave in such a way, for sure this will be > visible to the clients and lots of infrastructure (proxies) will be > required to get anything usable by the users. > > With regular sensor networks duty cycling, a ~3 years lifetime is > feasible with regular batteries (depending upon actual usage and > network traffic). Are you targeting a use case with tighter > requirements? Are you sure about the battery lifetime? I am using two AA battery with 700mAH each. And the power consumption of the RF module is 23mA, 21uA, 1uA for active, idle and sleep. So normally for me it is several month at most. Best regards, Zhen > > Best, > Angelo > > On Mon, Mar 5, 2012 at 10:16, Jari Arkko wrote: >> >> Angelo, >> >> >>> Indeed sensor networks support sleeping using radio duty cycling at >>> lower layers, this turns out in having the sleeping functionality >>> without any loss of communication at the upper layers. >>> >> >> We discussed this a couple of IETFs back. Since then I've been doing some >> talking to our researchers who measure and improve power usage in radios. >> >> First, duty cycling is already pretty widely used for radio technology. All >> cellular systems, for instance, turn off the radio except in during the time >> they listen for possible incoming paging signals, system information >> necessary to stay in contact at all, or when they have been granted a time >> slot to send. >> >> Secondly and more importantly, per their measurements, even after all the >> above techniques, periodic listening for possibly incoming messages is the >> biggest consumer of energy in applications where we'd like to have a long >> battery life, such as in sensors. That power usage dwarfs everything else, >> so it has to come down, somehow, to make an improvement. >> >> So if we want to achieve significantly longer battery lifetimes (and I claim >> we need those) we need to change some things. Obviously a lot of the link >> layers can be tuned better, implementing simply longer paging frequencies, >> for instance. My hypothesis is that we'll have to go longer than what >> typical application protocol timeouts are today, so the change would be >> something that is visible to applications. We could change some of the >> timeouts, but it is not clear that network buffers and all underlying >> mechanisms deployed today support those without changes. And in general, I >> think it is better to fit the communication model to the problem at hand >> than vice versa. As a result, I personally believe that we need to build >> applications that natively communicate in ways that make sleep modes easy. >> Such as publish-subscribe instead of direct request-response from anyone who >> needs the information. But like I said, this is a hypothesis and I'd love to >> be proven wrong. >> >> Jari >> >> > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Best regards, Zhen From zach@sensinode.com Wed Mar 7 12:50:56 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3402611E80B3 for ; Wed, 7 Mar 2012 12:50:56 -0800 (PST) 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 lga2B2pwLTod for ; Wed, 7 Mar 2012 12:50:55 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9030C11E80A1 for ; Wed, 7 Mar 2012 12:50:54 -0800 (PST) Received: from [192.168.1.102] (87-93-123-213.bb.dnainternet.fi [87.93.123.213]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q27KopGO010865 for ; Wed, 7 Mar 2012 22:50:52 +0200 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Mar 2012 22:50:51 +0200 References: <20120307204000.16778.33653.idtracker@ietfa.amsl.com> To: core WG Message-Id: <902A9258-618B-4D77-955A-B9059E315FE9@sensinode.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] Fwd: New Version Notification for draft-shelby-core-interfaces-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, 07 Mar 2012 20:50:56 -0000 http://www.ietf.org/id/draft-shelby-core-interfaces-02.txt A new version of the CoRE Interfaces draft is now available, including a = bunch of new contributions from Matthieu. Looking forward to discussing = this with folks in Paris. We also have an IPSO Alliance interop and demo = event coming up after the IETF in Paris, where -01 of this specification = is being used as part of the new IPSO Profile. Changes from -01 to -02 o Defined a Function Set and its guidelines. o Added the Link List interface. o Added the Linked Batch interface. o Improved the WADL interface definition. o Added a simple profile example.=20 Regards, Zach Begin forwarded message: > From: internet-drafts@ietf.org > Date: March 7, 2012 10:40:00 PM GMT+02:00 > To: zach@sensinode.com > Cc: matthieu.vial@schneider-electric.com > Subject: New Version Notification for = draft-shelby-core-interfaces-02.txt >=20 > A new version of I-D, draft-shelby-core-interfaces-02.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-shelby-core-interfaces > Revision: 02 > Title: CoRE Interfaces > Creation date: 2012-03-07 > WG ID: Individual Submission > Number of pages: 20 >=20 > Abstract: > This document defines well-known REST interface descriptions for > Batch, Sensor, Parameter and Actuator types for use in contrained = web > servers using the CoRE Link Format. A short reference is provided > for each type that can be efficiently included in the interface > description attribute of the CoRE Link Format. These descriptions > are intended to be for general use in resource designs or for > inclusion in more specific interface profiles. In addition, this > document defines the concept of Function Set to guide the creation = of > RESTful profiles. >=20 >=20 >=20 >=20 > The IETF Secretariat --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From zach@sensinode.com Thu Mar 8 04:28:13 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E881D21F86EF for ; Thu, 8 Mar 2012 04:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.658 X-Spam-Level: X-Spam-Status: No, score=-3.658 tagged_above=-999 required=5 tests=[AWL=-0.059, 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 ImIOAvYDFhyI for ; Thu, 8 Mar 2012 04:28:13 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 8782B21F86EE for ; Thu, 8 Mar 2012 04:28:12 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q28CSAr9006013; Thu, 8 Mar 2012 14:28:10 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: <000e01ccfb9e$8688ab50$939a01f0$@uni-rostock.de> Date: Thu, 8 Mar 2012 14:28:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <68E2CBBA-56C9-41A0-AEBA-F9C8FF573B67@sensinode.com> References: <20120305094330.27895.2135.idtracker@ietfa.amsl.com> <525954D5-9A28-4C2B-A591-817999FB6A56@sensinode.com> <003001ccfb8e$8305b960$89112c20$@uni-rostock.de> <1DAC05A7-F0F1-4415-8EEA-6975685F1D73@sensinode.com> <000e01ccfb9e$8688ab50$939a01f0$@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1084) Cc: 'core WG' Subject: Re: [core] Fwd: New Version Notification for draft-shelby-exi-registration-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 12:28:14 -0000 Guido, It seems you are anyways in favor of the need for +exi media types, = correct? Two examples where such a media type is being requested is the = Smart Energy 2 profile (application/sep2+exi) and SenML = (application/senml+exi), both of these have other versions of their = media type being requested, and both are for M2M use. Yourself you = mention application/soap+exi as being something you would find useful? = Note that the purpose of this +exi suffix is not for general purpose EXI = use by any means, it is meant for a narrow category of uses where a = suffix makes sense. For other cases, either using the existing = content-encoding or application/exi media type is recommended.=20 I am happy to adjust the text in this draft so that the registration = information to be provided by a media type requesting a +exi suffix is = right, this was just a first straw-man. So what would help me most is if = you would propose some improved text. I agree that the detailed EXI = options should be controlled by the EXI header, no disagreement (this = probably needs better text). I do however think that the media type = registration needs to define how the SchemaID field is to be used, as = the EXI standard doesn't give guidelines there.=20 Zach On Mar 6, 2012, at 3:39 PM, Guido Moritz wrote: > I am still the opinion that this is way too much semantics that is = tried to > push into the Media Type field. EXI has its own mechanisms/header = field for > this (i.e. EXI header including SchemaID field).=20 >=20 > To get a comprehensive solution, also all the other options of the EXI > header (alignment, compression, strict, preserve...) must be included = in the > Media Type definition. >=20 > I still do not get the point, why the way EXI handles these by = internal > options is not sufficient? The only thing to carry in the Media Type = is that > whether it is EXI or not. Everything beyond that, i.e. the specific = EXI > mode, should be expressed by the existing EXI options.=20 >=20 > All these definitions are application/protocol specific. Sure, it must = be > defined somewhere. But I would say define a new Media Type for each = possible > combination of protocol schemas, application specific schemas and = schema > versions is not an appropriate solution.=20 >=20 > Maybe some realistic examples of +exi Media Types to be defined would = help > to generate new input for this discussion?=20 >=20 > Guido >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: Zach Shelby [mailto:zach@sensinode.com] >> Gesendet: Dienstag, 6. M=E4rz 2012 14:22 >> An: Guido Moritz >> Cc: 'core WG' >> Betreff: Re: AW: [core] Fwd: New Version Notification for > draft-shelby-exi- >> registration-00.txt >>=20 >> Hi, >>=20 >> On Mar 6, 2012, at 1:44 PM, Guido Moritz wrote: >>=20 >>> Hi Zach, >>>=20 >>> I have read the draft and also stumbled through the discussion on = the > APPS >>> WG list. You describe two scenarios for the usage of +exi. I would > mainly >>> pick up the second: >>=20 >> The idea was that the use of +exi is recommended for both bullet = points. > The >> point of that section is just to guide readers to where the use of = +exi is >> appropriate compared to the existing exi content encoding or > application/exi >> approaches. >>=20 >>>=20 >>> o Use EXI as a native encoding (without the use of XML as an >>> interemediate) in Strict Schema-informed mode, and the base = Media >>> Type indicates to the protocol the Schema that was used to = produce >>> the EXI grammar. >>>=20 >>> The major intention of this use case is to indicate the used schemas > that >>> are required to generate the appropriate EXI grammar. >>=20 >> Not only the used schema, but also the underlying semantics of what = is >> contained in the schema. >>=20 >>> To come up with an >>> example I would use application/soap. But there is no clear = relationship >>> which schemas have to be included if application/soap+exi is used. = Is it >>> only the SOAP schema? Which version of SOAP? Is it also the > WS-Addressing >>> schema? Which version of WS-Addressing? What WS-* or application > specific >>> schemas else?! >>=20 >> The purpose of this draft is to define the registration guidelines = for > someone >> registering an application/foo+exi media type. So it would be up to = the > person >> requesting that media type to describe what schemas are used and how = to >> interpret the Schema ID field (in case multiple schemas are possible > e.g.). So if >> you are registering the media type application/soap+exi then you need = to >> define those details. >>=20 >>> Thus, it would be required to define for each Media Type very strict > which >>> schemas and versions are required and which not. >>=20 >> Yes, each media type registration needs to define these things. This = is > needed >> to ensure interoperability. Is that a bad thing? >>=20 >>> The approach described in >>> the draft is too generic. I would argue this definition is not in = the >>> responsibility of the IETF, but must be e.g. part of the W3C EXI WG. >>=20 >> This draft is just defining the +exi suffix registration procedure, = which > should be >> generic. In my understanding the iETF is the right place to do it. >>=20 >> Zach >>=20 >>=20 >>>=20 >>> My 2 cents, >>> Guido >>>=20 >>>> -----Urspr=FCngliche Nachricht----- >>>> Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im = Auftrag > von >>>> Zach Shelby >>>> Gesendet: Montag, 5. M=E4rz 2012 10:51 >>>> An: core WG >>>> Betreff: [core] Fwd: New Version Notification for >>> draft-shelby-exi-registration- >>>> 00.txt >>>>=20 >>>> Here is a draft I wrote up describing a +exi Media Type suffix, and > which >>> we >>>> have discussed over on the apps-discuss mailing list. Soliciting = any >>> comments >>>> from CoRE as well. >>>>=20 >>>> http://www.ietf.org/id/draft-shelby-exi-registration-00.txt >>>>=20 >>>> Zach >>>>=20 >>>> Begin forwarded message: >>>>=20 >>>>> From: internet-drafts@ietf.org >>>>> Date: March 5, 2012 11:43:30 AM GMT+02:00 >>>>> To: zach@sensinode.com >>>>> Subject: New Version Notification for >>> draft-shelby-exi-registration-00.txt >>>>>=20 >>>>> A new version of I-D, draft-shelby-exi-registration-00.txt has = been >>> successfully >>>> submitted by Zach Shelby and posted to the IETF repository. >>>>>=20 >>>>> Filename: draft-shelby-exi-registration >>>>> Revision: 00 >>>>> Title: The +exi Media Type Suffix >>>>> Creation date: 2012-03-05 >>>>> WG ID: Individual Submission >>>>> Number of pages: 5 >>>>>=20 >>>>> Abstract: >>>>> Efficient XML Interchange (EXI) is an XML representation technique >>>>> specified by the W3C to provie a binary alternative to the = standard >>>>> text XML representation. This document defines a new Structure >>>>> Syntax Suffix "+exi" for use in a specific class of >>> protocols, where >>>>> "exi" content-type encoding or the generic >>>> "application/exi" Media >>>>> Type are not applicable. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The IETF Secretariat >>>>=20 >>>> -- >>>> Zach Shelby, Chief Nerd, Sensinode Ltd. >>>> http://www.sensinode.com >>>> http://zachshelby.org - My blog "On the Internet of Things" >>>> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" >>>> Mobile: +358 40 7796297 >>>>=20 >>>> _______________________________________________ >>>> core mailing list >>>> core@ietf.org >>>> https://www.ietf.org/mailman/listinfo/core >>>=20 >>=20 >> -- >> Zach Shelby, Chief Nerd, Sensinode Ltd. >> http://www.sensinode.com >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded = Internet" >> Mobile: +358 40 7796297 >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From zach@sensinode.com Thu Mar 8 04:55:27 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE57121F8611; Thu, 8 Mar 2012 04:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.654 X-Spam-Level: X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[AWL=-0.055, 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 nM0Zii84-K0z; Thu, 8 Mar 2012 04:55:27 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id E072121F8607; Thu, 8 Mar 2012 04:55:26 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q28CtNsZ011294; Thu, 8 Mar 2012 14:55:24 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4F3FFB16.6030502@joelhalpern.com> Date: Thu, 8 Mar 2012 14:55:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <78A0D3BA-5EFE-4AD7-ACD6-56196CB588CF@sensinode.com> References: <4F3D931C.1000101@nostrum.com> <4F3FFB16.6030502@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1084) Cc: gen-art@ietf.org, core WG , "A. Jean Mahoney" Subject: Re: [core] [Gen-art] Review: draft-ietf-core-link-format-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 12:55:28 -0000 Joel, Thanks for the review. See comments regarding your suggestions in-ine: On Feb 18, 2012, at 9:25 PM, Joel M. Halpern wrote: > I am the assigned Gen-ART reviewer for this draft. For background on = Gen-ART, please see the FAQ at = . >=20 > Please resolve these comments along with any other Last Call comments = you may receive. >=20 > Document: draft-ietf-core-link-format-11 > CoRE Link Format > Reviewer: Joel M. Halpern > Review Date: 18-Feb 2012 > IETF LC End Date: 28-Feb-2012 > IESG Telechat date: N/A >=20 > Summary: This document is almost ready for publication as a proposed = standard. >=20 > Major issues: > What is the registration / collision avoidance strategy for = resource type (rt) and interface description (if) values? They are both = defined as opaque strings which can happen to be URIs. So there seems = to be potential for collision. There is definitely a possibility for collision for those two = attributes, especially as there will be a mix of specifications that = define specific values to be used, and developers using their own = values. Currently while those are being defined in CoRE drafts we can = avoid collisions, but when other WGs or SDOs start defining them... We have deliberated on the idea of defining registries for rt=3D and if=3D= values, but it has not been clear if that should be done in this = document. Recently several CoRE drafts have been written that do specify = well-known values for those fields, so it starts to become obvious that = those registries would be useful. If I understand right, your = recommendation would be that we define those registries in the IANA = section of this document? I would be in favor of doing that. > Minor issues: > Would it be sensible, in the introduction, when the well-known URI = is first introduced, to refer to it as a "well-known relative URI"? Sure, will fix. > Should this document register a resource type (rt) and interface = description (if) for the server resource manager itself? The text = refers to using multicast to find resources, with filtering based on rt = and if. (This would, I think, be defined in section 4, and registered = in the IANA considerations section?) Presumably all devices would = support the interface, which is why a resource type for the master = server would seem useful. I am not sure what you mean by "master server" here. Maybe you are = referring to something like a resource directory defined in = [http://tools.ietf.org/id/draft-shelby-core-resource-directory-02.txt]? = Yes, that specification does specify a well-known rt=3D value "core-rd" = with which any node can discovery the location of a resource directory. Thanks, Zach >=20 > Nits/editorial comments: > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From prvs=6414928FA6=guido.moritz@uni-rostock.de Thu Mar 8 05:12:17 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D75F21F86CE for ; Thu, 8 Mar 2012 05:12:17 -0800 (PST) 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.710, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 vCSBXLA7i-UP for ; Thu, 8 Mar 2012 05:12:17 -0800 (PST) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBAA21F8684 for ; Thu, 8 Mar 2012 05:12:16 -0800 (PST) From: Guido Moritz To: 'Zach Shelby' References: <20120305094330.27895.2135.idtracker@ietfa.amsl.com> <525954D5-9A28-4C2B-A591-817999FB6A56@sensinode.com> <003001ccfb8e$8305b960$89112c20$@uni-rostock.de> <1DAC05A7-F0F1-4415-8EEA-6975685F1D73@sensinode.com> <000e01ccfb9e$8688ab50$939a01f0$@uni-rostock.de> <68E2CBBA-56C9-41A0-AEBA-F9C8FF573B67@sensinode.com> In-Reply-To: <68E2CBBA-56C9-41A0-AEBA-F9C8FF573B67@sensinode.com> Date: Thu, 8 Mar 2012 14:12:17 +0100 Message-ID: <004f01ccfd2d$163c0690$42b413b0$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGIiWMwCsxA5IPfizRlUH/eCE4JFAHdaJpBAW5IUc4CMt1O7QFaEpf7AlQ76F+Wn9eB8A== Content-Language: de X-Originating-IP: [139.30.201.226] Cc: 'core WG' Subject: Re: [core] Fwd: New Version Notification for draft-shelby-exi-registration-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 13:12:17 -0000 > It seems you are anyways in favor of the need for +exi media types, correct? This is exactly what I am not sure about. For our use cases and experiences it makes no sense due to the reasons given in my last mails. But of course I am quite open if there are reasonable use cases. My first feeling simply was that many people have only few knowledge about EXI itself and the way it works. Thus, I would be happy to contribute with my experiences in using EXI in the constrained world. One of my major points is why the existing mechanisms of EXI are not sufficient and why there is a need for such a new mechanism. > Two examples where such a media type is being requested is the Smart Energy > 2 profile (application/sep2+exi) and SenML (application/senml+exi), both of > these have other versions of their media type being requested, and both are for > M2M use. Sounds somewhat reasonable, but I am not an expert in SEP2 and SenML. I would be happy to hear more about that. > Yourself you mention application/soap+exi as being something you > would find useful? No, makes no sense. SOAP deployments often use profiles (e.g. WS-I Basic Profile, DPWS, ....). Hence, application/soap is not sufficient to point to the required schema/grammar. > Note that the purpose of this +exi suffix is not for general > purpose EXI use by any means, it is meant for a narrow category of uses where > a suffix makes sense. For other cases, either using the existing content- > encoding or application/exi media type is recommended. Agreed. > I am happy to adjust the text in this draft so that the registration information to > be provided by a media type requesting a +exi suffix is right, this was just a first > straw-man. So what would help me most is if you would propose some > improved text. I agree that the detailed EXI options should be controlled by the > EXI header, no disagreement (this probably needs better text). As soon I have finished my PHD thesis I am willing to assist also with text. Would be after Paris. > I do however > think that the media type registration needs to define how the SchemaID field > is to be used, as the EXI standard doesn't give guidelines there. I agree that the semantics of the SchemaID field needs to be defined somewhere. But I am still not sure if there should be association with the media type. Maybe it would be reasonable to discuss this issue in a F2F in Paris? We should have plenty of time during the week. > Zach Guido From trac+core@trac.tools.ietf.org Thu Mar 8 12:05:41 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A880021F865B for ; Thu, 8 Mar 2012 12:05:41 -0800 (PST) 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.012, 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 dRcOkjBl1+iz for ; Thu, 8 Mar 2012 12:05:41 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB7621F864E for ; Thu, 8 Mar 2012 12:05:40 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S5jaj-00045u-JH; Thu, 08 Mar 2012 15:05:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Thu, 08 Mar 2012 20:05:37 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/189 Message-ID: <057.5896f28a7d6a8fdbe951260b7e48ddf9@trac.tools.ietf.org> X-Trac-Ticket-ID: 189 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #189: Access control X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 20:05:41 -0000 #189: Access control From Richard Barnes: This document defines a format for describing a list of resources linked from a server, e.g., an HTTP or CoAP server. The document suggests the use of TLS or DTLS on the underlying transport for transport security. My only remaining security concern is that there could be access control concerns as well. For example, a server might not authorize all clients to see all services, or might provide some clients with different levels of access (e.g., read vs. read/write). The document already envisions that the list of links will have some dynamism, allowing for filtering based on link attributes. I would suggest simply noting that servers may want to support HTTP, CoAP, or [D]TLS client authentication and adaptation of the list of returned links based on the client's identity and authorizations. Suggested text for Section 6: " Some servers may provide resource discovery services to a mix of clients that are trusted to different levels. For example, a lighting control system might allow any client to read state variables, but only certain clients to write state (turn lights on or off). Servers SHOULD support authentication features of the underlying transport protocols (HTTP, CoAP, or DTLS/TLS) and allow operators to return different lists of links based on a client's identity and authorization. " -- ----------------------------------+-------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: new Priority: minor | Milestone: Component: link-format | Version: Severity: - | Keywords: ----------------------------------+-------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Mar 8 14:05:42 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F2D21E802D for ; Thu, 8 Mar 2012 14:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 RyP2MaL0RCwd for ; Thu, 8 Mar 2012 14:05:41 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4789021E8028 for ; Thu, 8 Mar 2012 14:05:37 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S5lSa-0004IA-A8; Thu, 08 Mar 2012 17:05:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com, cabo@tzi.org X-Trac-Project: core Date: Thu, 08 Mar 2012 22:05:19 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/189#comment:1 Message-ID: <072.8f55fe70e2fe0d6d4bc0e2b3d2ac9db8@trac.tools.ietf.org> References: <057.5896f28a7d6a8fdbe951260b7e48ddf9@trac.tools.ietf.org> X-Trac-Ticket-ID: 189 In-Reply-To: <057.5896f28a7d6a8fdbe951260b7e48ddf9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #189: Access control X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 22:05:42 -0000 #189: Access control Comment (by cabo@…): Re the proposed text: * define "operators" * the SHOULD probably should be limited to servers that have authentication and authorization features in the first place. * authorization may differentiate between the privilege to see the existence of a resource and the privilege to read it ➔ "reflect their authorization features in what links are visible to a specific client based..." -- ----------------------------------+--------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: new Priority: minor | Milestone: Component: link-format | Version: Severity: - | Resolution: Keywords: | ----------------------------------+--------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Mar 8 23:12:13 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A764221F863E for ; Thu, 8 Mar 2012 23:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 iSOWP7j5EuFx for ; Thu, 8 Mar 2012 23:12:13 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3259A21F8574 for ; Thu, 8 Mar 2012 23:12:11 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S5tzl-0008Mi-JU; Fri, 09 Mar 2012 02:12:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Fri, 09 Mar 2012 07:12:09 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/190 Message-ID: <057.2cbe09664a4c092a9299d89076736cb0@trac.tools.ietf.org> X-Trac-Ticket-ID: 190 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #190: Conversion from HTTP Link Header 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, 09 Mar 2012 07:12:13 -0000 #190: Conversion from HTTP Link Header From Richard Barnes: Section 2: The document hints at conversion from the HTTP Link header a couple of times. It seems like it would be helpful to lay out the conversion rules in detail. It seems like you may at least need to convert some things to UTF-8? This ticket is to open up that explanation in the document, and explain how to convert the links in an HTTP Link Header into CoRE Link Format links. -- -------------------------+-------------------- Reporter: zach@… | Owner: zach@… Type: editorial | Status: new Priority: minor | Milestone: Component: link-format | Version: Severity: - | Keywords: -------------------------+-------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Mar 8 23:14:09 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8076321F8642 for ; Thu, 8 Mar 2012 23:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 0SOwmfdSDQgs for ; Thu, 8 Mar 2012 23:14:08 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id C0B5521F85AE for ; Thu, 8 Mar 2012 23:14:08 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S5u1g-0000tG-9c; Fri, 09 Mar 2012 02:14:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Fri, 09 Mar 2012 07:14:07 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/191 Message-ID: <057.4e1244ef038d918fe27027261c593fc8@trac.tools.ietf.org> X-Trac-Ticket-ID: 191 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #191: Origin definition 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, 09 Mar 2012 07:14:09 -0000 #191: Origin definition Richard Barnes pointed out that the definition of Origin in RFC6454 (scheme, host, and port) would be useful for explaining how we are taking the default context URI from the request URI. This ticket is to add that reference. -- -------------------------+-------------------- Reporter: zach@… | Owner: zach@… Type: editorial | Status: new Priority: trivial | Milestone: Component: link-format | Version: Severity: - | Keywords: -------------------------+-------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Mar 8 23:16:09 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F245921F85BB for ; Thu, 8 Mar 2012 23:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 bwM7RnaF8QH8 for ; Thu, 8 Mar 2012 23:16:08 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6E021F85AE for ; Thu, 8 Mar 2012 23:16:08 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S5u3c-0001q1-1q; Fri, 09 Mar 2012 02:16:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Fri, 09 Mar 2012 07:16:08 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/192 Message-ID: <057.53fd027adf946598cb90372e65cd2b92@trac.tools.ietf.org> X-Trac-Ticket-ID: 192 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #192: Query pattern matching 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, 09 Mar 2012 07:16:09 -0000 #192: Query pattern matching From Richard Barnes: Section 4.1: It seems like the byte-equality matching here might create a disconnect here between the query patterns you can write and parameters you can have. In particular, it seems like you might at least need to decode percent-encoding before comparison. Otherwise, you might have parameters that are un-filterable. -- -----------------------------+-------------------- Reporter: zach@… | Owner: zach@… Type: protocol defect | Status: new Priority: minor | Milestone: Component: link-format | Version: Severity: - | Keywords: -----------------------------+-------------------- Ticket URL: core From zach@sensinode.com Fri Mar 9 03:35:28 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4266721F85F3; Fri, 9 Mar 2012 03:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=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 AvEC4pqMNjMc; Fri, 9 Mar 2012 03:35:26 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF0821F861F; Fri, 9 Mar 2012 03:35:22 -0800 (PST) Received: from [192.168.1.103] (178-55-87-130.bb.dnainternet.fi [178.55.87.130]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q29BZFQm015298; Fri, 9 Mar 2012 13:35:16 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4F4D2FCB.8030805@gmx.de> Date: Fri, 9 Mar 2012 13:35:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F4D2FCB.8030805@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org, draft-ietf-core-link-format@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [core] APPSDIR review of draft-ietf-core-link-format-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 11:35:28 -0000 Julian, Thanks for the really detailed and helpful review! =20 On Feb 28, 2012, at 9:49 PM, Julian Reschke wrote: >=20 > Major Issues: >=20 > 2.2. Link relations >=20 > Since links in the CoRE Link Format are typically used to describe > resources hosted by a server, and thus in the absence of the = relation > parameter the new relation type "hosts" is assumed (see Section = 7.2). >=20 > It took me a moment to realize that "hosts" isn't the plural of "host" = here. Maybe a different relation name would make things clearer = (although I currently have no better proposal :-). Boy was that a fun discussion on the WG list as well, and hosts is what = we ended up with... Maybe just adding some explanatory text right there = would help. > The "hosts" relation type indicates that the target URI is a = resource > hosted by the server given by the base URI, or, if present, the > anchor parameter. >=20 > So the rule for determining the context URI is different for this link = relation? I believe this needs to change. Originally it was for the whole link format, and I think with the rules = you suggest below we can make it generic again.=20 > To express other relations, links can make use of any registered > relation by including the relation parameter. To simplify the > constrained implementations, the value of a "rel" parameter in this > link format SHOULD NOT contain more than one relation type. There >=20 > That's a SHOULD NOT that doesn't help anybody. Are recipients supposed = to understand multiple relation types or not? If yes, then the = constraint isn't needed. If no, it's a MUST NOT. The only reason we left the door open for allowing multiple relation = types, was in case other Web Links were converted to this format (and = thus may have multiple relation types). Constrained devices are not = expected to understand multiple relation types. I would recommend that = we just remove the SHOULD NOT. > may be cases where multiple relation types cannot be avoided, for > example when storing a RFC5988 Link header in this link format. The > context of a relation can be defined using the anchor parameter. In > this way, relations between resources hosted on a server, or between > hosted resources and external resources can be expressed. >=20 > This seems to repeat information from earlier on... >=20 >=20 > 3. CoRE link extensions >=20 > The following CoRE specific target attributes are defined in = addition > to the ABNF rules in Section 5 of [RFC5988]. These attributes > describe information useful in accessing the target link of the > relation, and in some cases may be URIs. These URIs MUST be treated >=20 > s/may be/can use the syntactical form of a/ >=20 > as non resolvable identifiers (they are not meant to be retrieved). >=20 > Not sure about the "MUST". Maybe replace with an explanation that they = can indeed by dereferenced (for instance to obtain a description of the = link relation), but that this is not part of the protocol and MUST NOT = be done automatically on link evaluation. Good suggestion, I will make a ticket. We do need to check that this is = consistent with RFC5988, as my understanding of target attributes was = that they are not meant to be retrieved (checking again though, I can't = find text in RFC5988 that contradicts what you are suggesting). > When attributes are compared, they MUST be compared as strings. >=20 > Attribute values? >=20 > Relationships to resources that are meant to be retrieved should be > expressed as separate links using the anchor attribute and the > appropriate relation type. >=20 > It's not clear to me what this means. Could you elaborate? Basically a work-around for the MUST you suggested replacing above. This = text would be removed if that change is made.=20 > link-extension =3D > link-extension =3D/ ( "rt=3D" quoted-string ) > link-extension =3D/ ( "if=3D" quoted-string ) > link-extension =3D/ ( "sz=3D" cardinal ) > cardinal =3D "0" / %x31-39 *DIGIT >=20 > In here, you copied the ABNF style from RFC 5988. I think that style = is something we should avoid, though, because it encourages parsers to = special case certain attributes. >=20 > I would recommend to allow both token and quoted-string for all new = parameters. >=20 > (and yes, I'll raise an erratum against RFC 5988 once we have done the = base work in HTTPbis) Carsten already touched on this, and I will make a ticket.=20 >=20 > 3.1. Resource type 'rt' attribute >=20 > The resource type "rt" attribute is an opaque string used to assign = a > semantically important type to a resource. One can think of this as > a noun describing the resource. In the case of a temperature > resource this could be e.g. an application-specific semantic type > like "OutdoorTemperature", a Universal Resource Name (URN) like > "urn:temperature:outdoor" or a URI referencing a specific concept in > an ontology like >=20 > "http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature". Multiple > resource type attributes MAY appear in a link. >=20 > Please avoid that. In general, the format that you're borrowing from = doesn't allow multiple parameters with the same name. Either make it = multiple links, or allow a white-space separated list of values in the = attribute value. Right, same goes for if=3D. In theory we could allow multiple values = separated by a white-space, like in the rel=3D attribute. This makes the = attribute matching more difficult however. At the same time including = multiple links is wasteful overhead. So far when applying these in = designs only a single rt=3D or if=3D attribute has been needed, but I = could foresee multiple values in the future. =20 > The resource type attribute is not meant to used to assign a human > readable name to a resource. The "title" attribute defined in > [RFC5988] is meant for that purpose. >=20 > Did you consider using the type attribute that already is defined in = RFC 5988? type=3D refers to the Media Type, and this is already used also in this = format for that purpose.=20 > 5. Examples >=20 > A few examples of typical link descriptions in this format follows. > Multiple resource descriptions in a representation are separated by > commas. Linefeeds never occur in the actual format, but are shown = in > these examples for readability. Although the following examples use > CoAP response codes, the examples are applicable to HTTP as well = (the > corresponding response code would be 200 OK). >=20 > Actually, RFC 5988 allows CR LF between parameters as it uses the RFC = 2616 list production allowing implied LWS. >=20 > If you want to rule this out, you probably need to specify your own = ABNF. I would not mind allowing the CR LF actually, but do we really inherit = that from the RFC 2616 production as we are not inside the HTTP header = anymore?=20 > This example arranges link descriptions hierarchically, with the > entry point including a link to a sub-resource containing links = about > the sensors. >=20 > REQ: GET /.well-known/core >=20 > RES: 2.05 "Content" > ;rt=3D"index" >=20 > REQ: GET /sensors >=20 > RES: 2.05 "Content" > ;rt=3D"TemperatureC";if=3D"sensor", > ;rt=3D"LightLux";if=3D"sensor" >=20 > rt=3D"index" is mentioned for the first time here. Is this something = recipients need to understand, so is it predefined? Also, isn't this a = use case for rel=3Dindex? Yep, "index" is not a great example here. I will update this to be more = appropriate.=20 > Minor Issues: >=20 > The main function of such a discovery mechanism is to provide > Universal Resource Identifiers (URIs, called links) for the = resources >=20 > Nope. As discussed further down below, a link requires two resources, = not a single one. >=20 > 2.1. Target and context URIs >=20 > Each link conveys one target URI as a URI-reference inside angle > brackets ("<>"). The context URI of a link (also called base URI in > [RFC3986]) conveyed in the CoRE Link Format is by default built from > the scheme and authority parts of the target URI. In the absence of >=20 > OK, so >=20 > ; rel=3Dbar >=20 > represents the link >=20 > http://example.com --bar--> http://example.com/foo >=20 > ? Sounds a bit counter-intuitive to me; maybe you should explain that = in examples. It is intuitive for our main use case, which is describing the resources = hosted by that server using the rel=3Dhosts relation. But yes, I can add = more example. >=20 > this information in the target URI, the context URI is built from = the > scheme and authority that was used for referencing the resource > returning the set of links, replacing the path with an empty path. >=20 > Thus by default links can be thought of as describing a target > resource hosted by the server. Other relations can be expressed by > including an anchor parameter (which defines the context URI) along > with an explicit relation parameter. This is an important = difference > to the way the HTTP Link Header format is used, as it is included in > the header of an HTTP response for some URI (this URI is by default > the context URI). Thus the HTTP Link Header is by default relating > the target URI to the URI that was requested. In comparison, the > CoRE link format includes one or more links, each describing a > resource hosted by a server by default. Other relations can be > expressed by using the anchor parameter. See Section 5 of [RFC3986] > for a description of how URIs are constructed from URI references. >=20 > Alternative explanation: >=20 > The context URI specified by >=20 > a) the anchor parameter, when specified, or >=20 > b) protocol + authority of the target URI, when specified >=20 > c) protocol + authority of the link format document's base URI. >=20 > It would be nice if the reason why only protocol + authority are used. I like this way of explaining it, will make a ticket.=20 > (you may also want to use the term "Origin" (RFC 6454) for protocol + = authority) Richard Barnes also suggested this in his review, added a ticket = already:=20 http://trac.tools.ietf.org/wg/core/trac/ticket/191 > 2.3. Use of anchors >=20 > As per Section 5.2 of [RFC5988] a link description MAY include an > "anchor" attribute, in which case the context is the URI included in > that attribute. This is used to describe a relationship between two > resources. A consuming implementation can however choose to ignore > such links. It is not expected that all implementations will be = able > to derive useful information from explicitly anchored links. >=20 > Right. Maybe make clear that recipients MUST either process anchor = correctly, or ignore the whole link relation (not only the anchor = parameter). OK.=20 > 7.2. New 'hosts' relation type >=20 > This memo registers the new "hosts" Web Linking relation type as per > [RFC5988]. >=20 > Relation Name: hosts >=20 > Description: Refers to a resource hosted by the server indicated by > the link context. >=20 > Does that indicate more than "is one the same server"? In which case I = believe no link relation is needed. We are using this to indicate: Origin -> hosts -> Target URI e.g. coap://this.server -> hosts -> /sensor/temperature (and has these = attributes) How would we relate this following Web Linking without a relation? >=20 > Nits: >=20 > Abstract >=20 > This document defines Web Linking using a link format for use by > constrained web servers to describe hosted resources, their > attributes and other relationships between links. Based on the HTTP > Link Header format defined in RFC5988, the CoRE Link Format is >=20 > Please s/header/header field/ throughout. >=20 > Resource Discovery can be performed either unicast or multicast. > When a server's IP address is already known, either a priori or > resolved via the Domain Name System (DNS) [RFC1034][RFC1035], = unicast > discovery is performed in order to locate the entry point to the > resource of interest. This is performed using a GET to = /.well-known/ > core on the server, which returns a payload in the CoRE Link Format. > A client would then match the appropriate Resource Type, Interface > Description and possible Content-Type [RFC2045] for its application. >=20 > "Media type, as specified in the type attribute"? >=20 > CoRE Link Format > A particular serialization of typed links based the HTTP Link > Header serialization defined in Section 5 of RFC5988, but carried > as a resource representation with a MIME type. >=20 > s/MIME type/Internet Media Type/ >=20 > Attribute > Properly called "Target Attribute" in RFC5988. A set of = key/value > pairs that describe the link or its target. >=20 > One attribute is a *single* key/value pair... >=20 >=20 > 3.2. Interface description 'if' attribute >=20 > The Interface Description "if" attribute is an opaque string used to > provide a name, URI or URN indicating a specific interface = definition >=20 > URNs are a subset of URIs... >=20 > used to interact with the target resource. One can think of this as > describing verbs usable on a resource. The Interface Description > attribute is meant to describe the generic REST interface to = interact > with a resource or a set of resources. It is expected that an > Interface Description will be re-used by different resource types. > For example the resource types "OutdoorTemperature", "DewPoint" and > "RelHumidity" could all be accessible using the Interface = Description > "http://www.example.org/myapp.wadl#sensor". >=20 > The Interface Description could be for example the URI of a Web > Application Description Language (WADL) [WADL] definition of the > target resource "http://www.example.org/myapp.wadl#sensor", a URN > indicating the type of interface to the resource "urn:myapp:sensor", > or an application-specific name "Sensor". Multiple Interface > Description attributes MAY appear in a link. >=20 > (see above) >=20 > 3.3. Maximum size estimate 'sz' attribute >=20 > The maximum size estimate attribute "sz" gives an indication of the > maximum size of the resource indicated by the target URI. This >=20 > Checking: is "size of the resource" sufficiently defined in Core? In = HTTP it would need a somewhat more complex definition ("payload returned = upon GET..."). What does the WG think? > 4.1. Query Filtering >=20 > A server implementing this document MAY recognize the query part of = a > resource discovery URI as a filter on the resources to be returned. > The query part should conform to the following syntax (parmname is = as > defined in [RFC5988], pct-encoded and unreserved are defined in > [RFC3986]). Note that this only defines querying for a single > parameter at a time. >=20 > I note that hardwiring URI query parameters into the protocol is *not* = Restful. >=20 > Also, you probably need to state how to present non-ASCII parameter = characters in the parameter (UTF8-encode-then-percent-escape...) Yes, already opened up a ticket on that: http://trac.tools.ietf.org/wg/core/trac/ticket/192 >=20 > filter-query =3D resource-param "=3D" query-pattern > resource-param =3D "uri" / parmname > query-pattern =3D search-token [ "*" ] > search-token =3D *search-char > search-char =3D unreserved / pct-encoded > / ":" / "@" ; from pchar > / "/" / "?" ; from query > / "!" / "$" / "'" / "(" / ")" > / "+" / "," / ";" / "=3D" ; from sub-delims >=20 > The resource-param "uri" refers to the URI-reference between the "<" > and ">" characters of a link. Other resource-param values refer to > the link attribute they name. Filtering is performed by comparing > the query-pattern against the value of the attribute identified by > the resource-param for each link-value in the collection of = resources > identified by the URI path. >=20 > Which makes it impossible to use "uri" as link attribute. Maybe this = should be noted. Alternatively maybe use a format that doesn't require = overloading the name. Carsten touched on this, we'll look at a better way. > This example shows the use of an anchor attribute to relate the > temperature sensor resource to an external description and to an > alternative URL. >=20 > s/URL/URI/ > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core Thanks, Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From trac+core@trac.tools.ietf.org Fri Mar 9 04:06:31 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E7C21F85B6 for ; Fri, 9 Mar 2012 04:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 98c2oPFTgVvq for ; Fri, 9 Mar 2012 04:06:31 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 30E2721F860D for ; Fri, 9 Mar 2012 04:06:30 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S5yac-0002JH-5l; Fri, 09 Mar 2012 07:06:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: hartke@tzi.org, cabo@tzi.org X-Trac-Project: core Date: Fri, 09 Mar 2012 12:06:30 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/174#comment:6 Message-ID: <068.f2ae803c7cc0986712f5d8fa5dee61ab@trac.tools.ietf.org> References: <053.70316ef76a2aab1204bc99bad86807ea@trac.tools.ietf.org> X-Trac-Ticket-ID: 174 In-Reply-To: <053.70316ef76a2aab1204bc99bad86807ea@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartke@tzi.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #174: Robust observation relationships 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, 09 Mar 2012 12:06:31 -0000 #174: Robust observation relationships Changes (by hartke@…): * status: reopened => closed * resolution: => fixed Comment: Done. -- -----------------------------------+----------------------- Reporter: hartke@… | Owner: hartke@… Type: protocol defect | Status: closed Priority: major | Milestone: Component: observe | Version: Severity: Submitted WG Document | Resolution: fixed Keywords: | -----------------------------------+----------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Mar 9 04:15:18 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4262421F8611 for ; Fri, 9 Mar 2012 04:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 4zx2Sualbpde for ; Fri, 9 Mar 2012 04:15:17 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3291221F8609 for ; Fri, 9 Mar 2012 04:15:09 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S5yix-0004Bs-LD; Fri, 09 Mar 2012 07:15:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org X-Trac-Project: core Date: Fri, 09 Mar 2012 12:15:06 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/184#comment:2 Message-ID: <066.3119f15dde1a81bebef95f257d2947ed@trac.tools.ietf.org> References: <051.1d985a98083f5d7102ae3d8bf240deb7@trac.tools.ietf.org> X-Trac-Ticket-ID: 184 In-Reply-To: <051.1d985a98083f5d7102ae3d8bf240deb7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120309121509.3291221F8609@ietfa.amsl.com> Resent-Date: Fri, 9 Mar 2012 04:15:09 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #184: Add implementation note to 3.5 about careless GETs 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, 09 Mar 2012 12:15:18 -0000 #184: Add implementation note to 3.5 about careless GETs Changes (by hartke@…): * status: new => closed * resolution: => fixed Comment: Done. -- --------------------------------+---------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-observe@… Type: editorial | Status: closed Priority: minor | Milestone: Component: observe | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+---------------------------------------- Ticket URL: core From jari.arkko@piuha.net Fri Mar 9 04:35:25 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8EB121F85F0 for ; Fri, 9 Mar 2012 04:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.172 X-Spam-Level: X-Spam-Status: No, score=-102.172 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, J_CHICKENPOX_44=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 luOyoq9lUL1m for ; Fri, 9 Mar 2012 04:35:25 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 835D421F858B for ; Fri, 9 Mar 2012 04:35:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5DB272DA06; Fri, 9 Mar 2012 14:35:20 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xClkHAlFrhzq; Fri, 9 Mar 2012 14:35:18 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 758CB2CC3C; Fri, 9 Mar 2012 14:35:18 +0200 (EET) Message-ID: <4F59F906.4080906@piuha.net> Date: Fri, 09 Mar 2012 14:35:18 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Zach Shelby , matthieu.vial@non.schneider-electric.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Heidi-Maria Rissanen , core Subject: [core] feedback on resource-directory and mirror-proxy (and base) drafts X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Mar 2012 12:35:26 -0000 Matthieu, Zach, I implemented an early prototype based on these drafts the other day. Or to be more precise, we have a couple of implementations, and wanted to provide some feedback on the drafts. First, these are really important pieces of functionality for smart object networks, lightweight for small devices to implement, and architecturally well designed. It has been very easy to construct a small device that registers to a mirror proxy and makes just periodic updates. But we're also hitting some number of problems, mostly in the area of the drafts being imprecise or lacking information. Or maybe we just have not found the right text or have simply misunderstood something. In any case, here are the issues that we run into: 1. Section 5.2 in draft-vial uses "Location: /mp/0" when I think you mean Location-Path from the coap base draft. Or am I missing something? 2. Same with draft-shelby, Section 4.2. 3. Section 5.10.8 in coap base draft in imprecise and inconsistent in its definition of what path should be included in the option. It says "absolute path URI" but also that "the Location-Path attribute is similar to Uri-Path option" and that it "may occur multiple times". Is Location-Path a segment or the full path? Uri-Path option in turn is defined elsewhere as "one segment of the absolute path to the resource". I think it would make far more sense for Location-Path to be a segment, because a device needs to copy information from Location-Path to Uri-Path on subsequent communications. "The Location-Path and Location-Query Options indicates the location of a resource as an absolute path URI. The Location-Path Option is similar to the Uri-Path Option, and the Location-Query Option similar to the Uri-Query Option. The two options MAY be included in a response to indicate the location of a new resource created with POST. If a response with a Location-Path and/or Location-Query Option passes through a cache and the implied URI identifies one or more currently stored responses, those entries SHOULD be marked as not fresh. Both options are "elective" and MAY occur one or more times." 4. If our suggestion about the correct definition of Location-Path above is adopted, examples from Section 5.2 in draft-vial need fixing. Currently they include the absolute URI, including the leading slash. 5. Section 5.8.2 in coap base draft says that Location-Path is not returned for 2.04 results. This may be problematic. If I am a sensor who has previously registered, will register again after some reboot or the like but has forgotten state from previous times, it does not know what the location might have been. Is there a downside to including Location-Path in every 2xx result for POST? "If a resource has been created on the server, a 2.01 (Created) response that includes the URI of the new resource in a sequence of one or more Location-Path Options and/or a Location-Query Option SHOULD be returned. If the POST succeeds but does not result in a new resource being created on the server, a 2.04 (Changed) response SHOULD be returned. If the POST succeeds and results in the target resource being deleted, a 2.02 (Deleted) response SHOULD be returned." 6. More generally, how does mirroring work when clients reboot, forget their state, move from one address to another, etc.? A paragraph or two explaining this would be useful. 7. Section 5.8.2 and 5.9.1.1 in coap base draft seem to disagree (?) about whether Location-Path should be returned. Compare the above quote to the below one: "If the response includes one or more Location-Path Options and/or a Location-Query Option, the values of these options specify the location at which the resource was created. Otherwise, the resource was created at the request URI." 8. Sections 5.8.2 and 5.9.1.1 in base and Section 4.2 in draft-shelby have a different requirement (SHOULD vs. MUST) for when to include a Location-Path attribute. Is this intentional for this specific use of COAP, or an inconsistency? Success: 2.01 "Created". The Location header MUST be included with the new resource entry for the end-point. This Location SHOULD be an stable identifier generated by the RD as it is used for all subsequent operations on this registration (update, delete). 9. How do I know whether a particular POST message (for instance) is directed to an RD or MP? Where does the "resource type" from the below statement (s4.1, draft-vial) go? How do clients know they have to use "/rd" path when talking to the RD? The discovery procedure is identical except that the resource type is replaced with "core-mp". I think it goes to the rt parameter when doing a .well-known query, but does this mean that I *have* to do discovery every time, even if I already have been configured with the address of an RD or MP? In many configurations the address needs to be configured because there is no easy way to do discovery beyond the local link. 10. Section 3.1 in draft-shelby needs some work to explain what discovery approaches can work in mobile networks (or any other networks that are not local LANs and may include router hops or even NATs). 11. We have trouble understanding the usage of various identifiers (host, instance, location, ep) and the logic behind selecting this particular design. Which identifier can be used in - registration - update - mirror put - get uri - get query parameters ... Please specify and provide some overall explanation of what should go where, and why. For instance, why isn't host:port sufficient to distinguish different instances as opposed to host + instance? When should the location-path be used, and when the host + instance? Are some values secret and to be used only by the node that registered, while others are to be used by anyone? And so on. 12. The lookup interface only allows using ep, link-format parameters, and domain. Why? Can I lookup based on the URI as provided by Location-Path? Can I look up based on host name? Can I look up based on host IP address if the host gave its address as a host name? Can I look up the different instances if I just know the host name, if so, how? 13. Section 4.2 of draft-shelby it says: "In the absense of a Host parameter, the RD will generate a unique one on behalf of the end-point." This seems odd. The purpose of the of the RD is to enable others to reach the devices, so what kind of "unique host parameter" should be generated? The source address + port from the query? A random string? A host name added to dyndns, or something else? Please specify. Jari From salvatore.loreto@ericsson.com Fri Mar 9 05:44:46 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E604C21F8645 for ; Fri, 9 Mar 2012 05:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.874 X-Spam-Level: X-Spam-Status: No, score=-109.874 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+gk-eXNZGlI for ; Fri, 9 Mar 2012 05:44:46 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5F121F8642 for ; Fri, 9 Mar 2012 05:44:45 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-93-4f5a094c6f28 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3E.0E.27041.C490A5F4; Fri, 9 Mar 2012 14:44:45 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Fri, 9 Mar 2012 14:44:44 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C18772321 for ; Fri, 9 Mar 2012 15:44:44 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C30EB5218B for ; Fri, 9 Mar 2012 15:44:44 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 82B4E519C6 for ; Fri, 9 Mar 2012 15:44:44 +0200 (EET) Message-ID: <4F5A094C.1000509@ericsson.com> Date: Fri, 9 Mar 2012 15:44:44 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: core@ietf.org References: <051.1d985a98083f5d7102ae3d8bf240deb7@trac.tools.ietf.org> <066.cb6972442c59a937cc7597800417ed51@trac.tools.ietf.org> In-Reply-To: <066.cb6972442c59a937cc7597800417ed51@trac.tools.ietf.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [core] #184: Add implementation note to 3.5 about careless GETs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Mar 2012 13:44:47 -0000 On 3/1/12 6:04 PM, core issue tracker wrote: > #184: Add implementation note to 3.5 about careless GETs > > > Comment (by hartke@…): > > At the end of section 3.5, add: > > Implementation note: A client that does not mediate all its requests > through its cache might inadvertantly cancel an observation relationship > by sending an unrelated GET to the same resource. To avoid this, without > incurring a need for synchronization, such clients can use a different > source transport address for these unrelated GET requests. > I fully agree with the second sentence of the above paragraph. Above the first one I have the following question: how does a mediation level (e.g. a cache) distinguish an actual cancel request from an inadvertent one cheers Salvatore -- Salvatore Loreto www.sloreto.com From matthieu.vial@non.schneider-electric.com Fri Mar 9 06:41:28 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A19B21F8609 for ; Fri, 9 Mar 2012 06:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8t4guauI2Za for ; Fri, 9 Mar 2012 06:41:27 -0800 (PST) Received: from mailX01.eud.schneider-electric.com (mailx01.eud.schneider-electric.com [205.167.7.35]) by ietfa.amsl.com (Postfix) with ESMTP id AD69221F8564 for ; Fri, 9 Mar 2012 06:41:27 -0800 (PST) Received: from ateui03.schneider-electric.com ([10.198.21.36]) by mailX01.eud.schneider-electric.com with ESMTP id 2012030915361733-69387 ; Fri, 9 Mar 2012 15:36:17 +0100 In-Reply-To: <4F59F906.4080906@piuha.net> To: Jari Arkko MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: matthieu.vial@non.schneider-electric.com Message-ID: Date: Fri, 9 Mar 2012 15:41:20 +0100 X-MIMETrack: Serialize by Router on ATEUI03.Schneider-Electric.com/T/SVR/Schneider at 09/03/2012 15:41:26, Serialize complete at 09/03/2012 15:41:26, Itemize by SMTP Server on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 09/03/2012 15:36:17, Serialize by Router on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 09/03/2012 15:36:18, Serialize complete at 09/03/2012 15:36:18 Content-Type: text/plain; charset="US-ASCII" Cc: Heidi-Maria Rissanen , core Subject: [core] RE feedback on resource-directory and mirror-proxy (and base) drafts X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Mar 2012 14:41:28 -0000 Hi Jari, Few comments inline. > 1. Section 5.2 in draft-vial uses "Location: /mp/0" when I think you mean Location-Path from the coap base draft. Or am I missing something? I suppose the reason is that earlier version of CoAP didn't split the path and the old notation is easier to read in examples. But if it just creates confusion I can change this to make it consistent with the last CoAP spec. >5. Section 5.8.2 in coap base draft says that Location-Path is not returned for 2.04 results. This may be problematic. If I am a sensor who has previously registered, will register again after some reboot or the like but has forgotten state from previous times, it does not know what the location might have been. Is there a downside to including Location-Path in every 2xx result for POST? My opinion is to process a registration request as if it were always a new creation. So a POST response always returns Location-Path options. You need to implement registration as an idempotent request for that. A new registration just overwrites previous state. As I understand the RD draft the h query parameter is the primary identifier for a RD entry. Since this parameter is optional it could be tricky to implement an idempotent POST when h is omitted (perhaps use source address as a fallback primary identifier). Personally I'd prefer using a unique identifier of the device (EUI64) as a primary identifier for the RD/MP entry. Previous versions of the RD draft had an id parameter but it was also optional. >6. More generally, how does mirroring work when clients reboot, forget their state, move from one address to another, etc.? A paragraph or two explaining this would be useful. What is a Client in your sentence? sleeping endpoint (SEP) in MP draft, endpoint (EP) in RD draft or a client in MP draft. I assume SEP hereafter. If the SEP can store its MP entry location in flash it should check that its MP entry is up-to-date after reboot using ETAG. When the MP entry is not fresh or deleted the SEP should update or register again. If the SEP can't store state it should register after reboot. If the SEP registers with a different MP there may be a cache with stall content in another MP until the MP entry expires. If a SEP changes its address I don't think there is a big impact on mirroring because it's the MP address which is advertised. If an EP changes its address then the consumers of the services hosted on this EP need to restart discovery. Of course the MP is also an EP. >9. How do I know whether a particular POST message (for instance) is directed to an RD or MP? Where does the "resource type" from the below statement (s4.1, draft-vial) go? How do clients know they have to use "/rd" path when talking to the RD? resource type is the rt attribute in link format. A web server with RD and MP services advertises resources like that: ;rt="core-rd", ;rt="core-mp" The result of the resource lookup gives you the root path of the corresponding service. The address of this server can be configured out-of-band but the (S)EP still needs to discover the root path of the service or at least to check that the configured URI has the good resource type. > 11. We have trouble understanding the usage of various identifiers (host, instance, location, ep) and the logic behind selecting this particular design. Which identifier can be used in Me too :) - Instance is not clear to me. - For MP, the Location path is the root path under which the cached resources are created *and* the resource where is located the MP entry. Now there may be a conflict between the path used to refresh the MP entry and the path corresponding to the root resource of the SEP. The difference between /mp/0 and /mp/0/ is effectively very subtle. I suppose the latter should end with an empty Uri-Path option. - For RD, the arbitrary index included in the path is usually the primary key of a database table used to store data about an EP. The idea is to be able to update various metadata associated to an EP from a third-party client (typically a commissioning tool). So there is a need for a stable identifier. But RD lacks an interface to enumerate or query the registered EPs, so it's not clear how a third-party can access those identifiers. This new interface was discussed briefly on the mailing list. Matthieu From cabo@tzi.org Fri Mar 9 07:58:59 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415FE21F866A for ; Fri, 9 Mar 2012 07:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.31 X-Spam-Level: X-Spam-Status: No, score=-106.31 tagged_above=-999 required=5 tests=[AWL=-0.061, 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 9IJYDMMANn9p for ; Fri, 9 Mar 2012 07:58:58 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7A75D21F85F4 for ; Fri, 9 Mar 2012 07:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q29Fwo9M029379; Fri, 9 Mar 2012 16:58:50 +0100 (CET) Received: from [192.168.217.117] (p5B3E6A4A.dip.t-dialin.net [91.62.106.74]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6F8F97C6; Fri, 9 Mar 2012 16:58:50 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4F5A094C.1000509@ericsson.com> Date: Fri, 9 Mar 2012 16:58:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <64936AE1-BBB8-4BCF-B31E-5505AA0927A1@tzi.org> References: <051.1d985a98083f5d7102ae3d8bf240deb7@trac.tools.ietf.org> <066.cb6972442c59a937cc7597800417ed51@trac.tools.ietf.org> <4F5A094C.1000509@ericsson.com> To: Salvatore Loreto X-Mailer: Apple Mail (2.1257) Cc: core@ietf.org Subject: Re: [core] #184: Add implementation note to 3.5 about careless GETs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Mar 2012 15:58:59 -0000 On Mar 9, 2012, at 14:44, Salvatore Loreto wrote: > Above the first one I have the following question: > how does a mediation level (e.g. a cache) distinguish an actual cancel = request > from an inadvertent one It doesn't. If a cache has a single client with an observation relationship and that = cancels (for a reason or inadvertently), the cache no longer has a = client with an observation relationship. It depends on the cache's = configuration whether that also causes the cache to cancel its = observation relationship with upstream. If it has two, and one is canceled, it still has one. No need to do = anything towards upstream. All this is true independent of whether the cache is an actual = intermediary sitting in the network or a local software layer. Gr=FC=DFe, Carsten From cabo@tzi.org Fri Mar 9 08:14:03 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5633721F8681 for ; Fri, 9 Mar 2012 08:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.308 X-Spam-Level: X-Spam-Status: No, score=-106.308 tagged_above=-999 required=5 tests=[AWL=-0.059, 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 0J+WasKbD5L8 for ; Fri, 9 Mar 2012 08:14:02 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7D40C21F853B for ; Fri, 9 Mar 2012 08:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q29GDPIr007585; Fri, 9 Mar 2012 17:13:25 +0100 (CET) Received: from [192.168.217.117] (p5B3E6A4A.dip.t-dialin.net [91.62.106.74]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9C7CD7DD; Fri, 9 Mar 2012 17:13:24 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4F59F906.4080906@piuha.net> Date: Fri, 9 Mar 2012 17:13:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6144B86F-0CAF-47E9-BE60-16647BFF22DA@tzi.org> References: <4F59F906.4080906@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1257) Cc: Heidi-Maria Rissanen , core Subject: Re: [core] feedback on resource-directory and mirror-proxy (and base) drafts X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Mar 2012 16:14:03 -0000 On Mar 9, 2012, at 13:35, Jari Arkko wrote: > Is Location-Path a segment or the full path?=20 A single Location-Path Option is a (percent-decoded) segment of the URI = offered as the Location. The name of the option is a bit historical (but Location-Path-Segment or = Uri-Path-Segment are a bit long). When talking about the value of the sequence of options, it is a bit = more intuitive to instead talk about the implied URI. Notated in a HTTP = header style: Location: /foo/bar is a short form of =BBtwo Location-Path options "foo" and "bar"=AB. Yes, we need to get consistent here -- either use that notation and = explain it or use the actual option values. I still like to talk about = /.well-known/core etc. instead of saying [{"Location-Path": = ".well-known"}, {"Location-Path": "core"}] (or, worse, = "\x6B.well-known\x04core"). Gr=FC=DFe, Carsten From cabo@tzi.org Fri Mar 9 08:17:46 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA5F21F86DA for ; Fri, 9 Mar 2012 08:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.305 X-Spam-Level: X-Spam-Status: No, score=-106.305 tagged_above=-999 required=5 tests=[AWL=-0.056, 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 XTBzlBbJ7w98 for ; Fri, 9 Mar 2012 08:17:45 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 76DE321F8692 for ; Fri, 9 Mar 2012 08:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q29GH50V008984; Fri, 9 Mar 2012 17:17:05 +0100 (CET) Received: from [192.168.217.117] (p5B3E6A4A.dip.t-dialin.net [91.62.106.74]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CA7767E1; Fri, 9 Mar 2012 17:17:04 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4F59F906.4080906@piuha.net> Date: Fri, 9 Mar 2012 17:17:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <314DD35C-E588-43E9-A9C5-B8DAA9CAE768@tzi.org> References: <4F59F906.4080906@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1257) Cc: Heidi-Maria Rissanen , core Subject: Re: [core] feedback on resource-directory and mirror-proxy (and base) drafts X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Mar 2012 16:17:46 -0000 On Mar 9, 2012, at 13:35, Jari Arkko wrote: > 7. Section 5.8.2 and 5.9.1.1 in coap base draft seem to disagree (?) = about whether Location-Path should be returned. Compare the above quote = to the below one: >=20 > "If the response includes one or more Location-Path Options and/or a > Location-Query Option, the values of these options specify the > location at which the resource was created. Otherwise, the resource > was created at the request URI." This seems to be hard to get right :-) See http://trac.tools.ietf.org/wg/httpbis/trac/ticket/331 -- we should = aim to be culturally compatible. Gr=FC=DFe, Carsten From jari.arkko@piuha.net Fri Mar 9 08:59:57 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534FA21E8013 for ; Fri, 9 Mar 2012 08:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 o7r7FXr3GT1z for ; Fri, 9 Mar 2012 08:59:56 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 94E3A21F872E for ; Fri, 9 Mar 2012 08:59:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E5E362DA06; Fri, 9 Mar 2012 18:59:54 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3dIqfO4YJTd; Fri, 9 Mar 2012 18:59:54 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 59BE32CC3C; Fri, 9 Mar 2012 18:59:54 +0200 (EET) Message-ID: <4F5A370A.7090308@piuha.net> Date: Fri, 09 Mar 2012 18:59:54 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Carsten Bormann References: <4F59F906.4080906@piuha.net> <6144B86F-0CAF-47E9-BE60-16647BFF22DA@tzi.org> In-Reply-To: <6144B86F-0CAF-47E9-BE60-16647BFF22DA@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Heidi-Maria Rissanen , core Subject: Re: [core] feedback on resource-directory and mirror-proxy (and base) drafts X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Mar 2012 16:59:57 -0000 Carsten, > > > When talking about the value of the sequence of options, it is a bit more intuitive to instead talk about the implied URI. Notated in a HTTP header style: > > Location: /foo/bar > > is a short form of two Location-Path options "foo" and "bar". > > Yes, we need to get consistent here -- either use that notation and explain it or use the actual option values. I still like to talk about /.well-known/core etc. instead of saying [{"Location-Path": ".well-known"}, {"Location-Path": "core"}] (or, worse, "\x6B.well-known\x04core"). > You can certainly still talk about paths such as /.well-known/core in the text, but if you actually write an example that has lines like Location: /.well-known/core that is always going to be confusing, no matter what explanations you might add to the text. The point of an example is to show the real messages and attributes, and shorthand notations there is misleading. IMO, of course. Jari From internet-drafts@ietf.org Fri Mar 9 12:38:01 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABC421E8040; Fri, 9 Mar 2012 12:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 1-svDNCXZJgg; Fri, 9 Mar 2012 12:38:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8478421F8629; Fri, 9 Mar 2012 12:38:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120309203800.4279.2383.idtracker@ietfa.amsl.com> Date: Fri, 09 Mar 2012 12:38:00 -0800 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-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: Fri, 09 Mar 2012 20:38:01 -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 Work= ing Group of the IETF. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-01.txt Pages : 34 Date : 2012-03-09 This is a working document intended to develop draft text for the CoAP protocol specification in the area of group communication. A solution based on IP multicast is proposed and detailed. Also, guidance is provided for deployment in various constrained network topologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-groupcomm-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-groupcomm-01.txt From tho@koanlogic.com Sat Mar 10 00:30:05 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DA421F8608 for ; Sat, 10 Mar 2012 00:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9oDmTk1R1sE for ; Sat, 10 Mar 2012 00:30:05 -0800 (PST) Received: from relay3.serverpronto.com (srv1022-mia.serverpronto.com [38.117.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id 1F27021F8606 for ; Sat, 10 Mar 2012 00:30:04 -0800 (PST) Received: from gonzo.koanlogic.com (166-118-60-69.serverpronto.com [69.60.118.166] (may be forged)) by relay3.serverpronto.com (8.13.8/8.13.8) with ESMTP id q2A8U4Jw013165 for ; Sat, 10 Mar 2012 03:30:04 -0500 Received: from host229-62-dynamic.42-79-r.retail.telecomitalia.it ([79.42.62.229]:54900 helo=t.homenet.telecomitalia.it) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1S6Hga-0006SF-88 for core@ietf.org; Sat, 10 Mar 2012 03:30:03 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Thomas Fossati In-Reply-To: <9032C193-A015-4F41-B441-4D1D47594FC9@koanlogic.com> Date: Sat, 10 Mar 2012 09:29:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <710A4E85-AE94-44C4-852C-EB88108E2204@koanlogic.com> References: <9032C193-A015-4F41-B441-4D1D47594FC9@koanlogic.com> To: core WG X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.42.62.229 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com) Subject: Re: [core] sleepy to sleepy communication 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: Sat, 10 Mar 2012 08:30:06 -0000 Hello all, a small note to inform that we've just uploaded the -01 version of the = Publish/Monitor I-D: http://tools.ietf.org/html/draft-fossati-core-publish-monitor-options It includes access control rules on the published resource via a "CRUD" = mask, an interface for explicit drop of the delegation, and some initial = ramblings on discovery. We plan to bring to Paris a proxy implementing the Publish logics. If = anyone is interested to implement the client bits (which should be quite = easy) and wants to do some testing, please drop us a line. Thomas.= From zach@sensinode.com Sat Mar 10 01:11:01 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEFC21F8680 for ; Sat, 10 Mar 2012 01:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 eTJlUcRP8I0K for ; Sat, 10 Mar 2012 01:10:59 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id EBBBE21F8678 for ; Sat, 10 Mar 2012 01:10:57 -0800 (PST) Received: from [192.168.1.103] (188-67-155-20.bb.dnainternet.fi [188.67.155.20]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q2A9An3G023776; Sat, 10 Mar 2012 11:10:49 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: <4F5A370A.7090308@piuha.net> Date: Sat, 10 Mar 2012 11:10:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F59F906.4080906@piuha.net> <6144B86F-0CAF-47E9-BE60-16647BFF22DA@tzi.org> <4F5A370A.7090308@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1084) Cc: Heidi-Maria Rissanen , core Subject: Re: [core] feedback on resource-directory and mirror-proxy (and base) drafts X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 10 Mar 2012 09:11:01 -0000 On Mar 9, 2012, at 6:59 PM, Jari Arkko wrote: >> When talking about the value of the sequence of options, it is a bit = more intuitive to instead talk about the implied URI. Notated in a HTTP = header style: >>=20 >> Location: /foo/bar >>=20 >> is a short form of =BBtwo Location-Path options "foo" and "bar"=AB. >>=20 >> Yes, we need to get consistent here -- either use that notation and = explain it or use the actual option values. I still like to talk about = /.well-known/core etc. instead of saying [{"Location-Path": = ".well-known"}, {"Location-Path": "core"}] (or, worse, = "\x6B.well-known\x04core"). >>=20 >=20 > You can certainly still talk about paths such as /.well-known/core in = the text, but if you actually write an example that has lines like = Location: /.well-known/core that is always going to be confusing, no = matter what explanations you might add to the text. The point of an = example is to show the real messages and attributes, and shorthand = notations there is misleading. IMO, of course. The RD draft is agnostic to whether CoAP or HTTP is used, thus the = examples are as generic as possible. I think in CoRE it might be good to = write up a draft that recommends a notation for specifying or giving = examples of generic REST exchanges in drafts (other than the use of = WADL).=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From trac+core@trac.tools.ietf.org Sat Mar 10 04:49:52 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C0621F851A for ; Sat, 10 Mar 2012 04:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 R4o6qbSLF7AN for ; Sat, 10 Mar 2012 04:49:51 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 0579221F852A for ; Sat, 10 Mar 2012 04:49:50 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6Lk4-0001SH-0p; Sat, 10 Mar 2012 07:49:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Sat, 10 Mar 2012 12:49:48 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/182#comment:2 Message-ID: <072.74e34016e148ec9074754c7021c0a801@trac.tools.ietf.org> References: <057.eb0bec758d2a33802dc7c2d34316419b@trac.tools.ietf.org> X-Trac-Ticket-ID: 182 In-Reply-To: <057.eb0bec758d2a33802dc7c2d34316419b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #182: Piggy-backing note 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: Sat, 10 Mar 2012 12:49:52 -0000 #182: Piggy-backing note Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done. -- -----------------------+--------------------- Reporter: zach@… | Owner: zach@… Type: editorial | Status: closed Priority: trivial | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | -----------------------+--------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sat Mar 10 04:50:33 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5141421F8610 for ; Sat, 10 Mar 2012 04:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 K3PsDJwcS7JW for ; Sat, 10 Mar 2012 04:50:32 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id DE90321F851A for ; Sat, 10 Mar 2012 04:50:32 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6Lka-0002Tc-QD; Sat, 10 Mar 2012 07:50:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Sat, 10 Mar 2012 12:50:20 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/183#comment:2 Message-ID: <066.67a0a4508637f536c55301eadb4864e1@trac.tools.ietf.org> References: <051.d737d9d709bad431585042b142a583f4@trac.tools.ietf.org> X-Trac-Ticket-ID: 183 In-Reply-To: <051.d737d9d709bad431585042b142a583f4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120310125032.DE90321F851A@ietfa.amsl.com> Resent-Date: Sat, 10 Mar 2012 04:50:32 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #183: Check consistency of statements about RST on NON X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 12:50:33 -0000 #183: Check consistency of statements about RST on NON Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done. -- --------------------------------+------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-coap@… Type: editorial | Status: closed Priority: major | Milestone: Component: coap | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sat Mar 10 05:08:34 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6364C21F861E for ; Sat, 10 Mar 2012 05:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 LmTsqyarBR8M for ; Sat, 10 Mar 2012 05:08:34 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id E38EB21F8596 for ; Sat, 10 Mar 2012 05:08:33 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6M2D-00053N-7O; Sat, 10 Mar 2012 08:08:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Sat, 10 Mar 2012 13:08:33 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/181#comment:1 Message-ID: <072.4b97df53101155d0adfe1b176cd90fe1@trac.tools.ietf.org> References: <057.1dd055576c61f3a0de6e843be86789a4@trac.tools.ietf.org> X-Trac-Ticket-ID: 181 In-Reply-To: <057.1dd055576c61f3a0de6e843be86789a4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #181: Content-encoding column 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: Sat, 10 Mar 2012 13:08:34 -0000 #181: Content-encoding column Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done. -- ----------------------------------+--------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | ----------------------------------+--------------------- Ticket URL: core From zach@sensinode.com Sat Mar 10 05:17:30 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A7421F8610 for ; Sat, 10 Mar 2012 05:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 Kt8Pokz3Gex2 for ; Sat, 10 Mar 2012 05:17:30 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 962B621F860B for ; Sat, 10 Mar 2012 05:17:29 -0800 (PST) Received: from [192.168.1.103] (188-67-155-20.bb.dnainternet.fi [188.67.155.20]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q2ADHPkC009762; Sat, 10 Mar 2012 15:17:26 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Zach Shelby In-Reply-To: <9922C3A0-6AE1-4782-938E-3B968EB34CB2@tzi.org> Date: Sat, 10 Mar 2012 15:17:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9922C3A0-6AE1-4782-938E-3B968EB34CB2@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: core WG Subject: Re: [core] Protocol Constants section of coap-08 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 13:17:30 -0000 As it seems we had good consensus on this new text, I have made the = following addition to Section 9 (Protocol Constants), replacing the = current text about future mechanisms with: "The values for RESPONSE_TIMEOUT, RESPONSE_RANDOM_FACTOR, and MAX_RETRANSMIT may be configured to values specific to the application environment, however the configuration method is out of scope of this document. It is recommended that an application environment use consistent values for these parameters." Zach On Feb 22, 2012, at 7:53 PM, Carsten Bormann wrote: > On Feb 22, 2012, at 18:44, Thomas Herbst wrote: >=20 >> Suggested Text : >> The values for RESPONSE_TIMEOUT, RESPONSE_RANDOM_FACTOR, and = MAX_RETRANSMIT may be configured to network specific values, but the = configuration method is out of scope of this document. It is = recommended that a network use consistent values for these parameters. =20= >=20 > Thanks! > We probably want to replace "network" by something more general, as = the network characteristics are not the only factor in choosing good = values -- one also has to look at application requirements for = timeliness and delivery probabilities etc. E.g., some applications' = networks will "the Internet", and there won't be a single set of values = right for those applications... >=20 > maybe: > =85 to values specific on the application environment =85 > =85 that an application environment employ consistent =85 >=20 > In the long run, I expect many implementations will be able to employ = adaptive schemes for configuring the values. But, as you said, this is = out of scope for this document. >=20 > Thanks again for bringing this up; it is important we get this right. >=20 > Gr=FC=DFe, Carsten >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From trac+core@trac.tools.ietf.org Sat Mar 10 05:31:24 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8508121F8629 for ; Sat, 10 Mar 2012 05:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUYpx5BYBUAz for ; Sat, 10 Mar 2012 05:31:23 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5E41D21F8621 for ; Sat, 10 Mar 2012 05:31:23 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6MOD-0001WB-Oa; Sat, 10 Mar 2012 08:31:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Sat, 10 Mar 2012 13:31:17 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/176#comment:4 Message-ID: <072.5bf41658df93e2a3eb7ff69d4696a7c3@trac.tools.ietf.org> References: <057.1e9c9b555be0e4f1e7b8069f00a990a7@trac.tools.ietf.org> X-Trac-Ticket-ID: 176 In-Reply-To: <057.1e9c9b555be0e4f1e7b8069f00a990a7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #176: Removing 15 option limit 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: Sat, 10 Mar 2012 13:31:24 -0000 #176: Removing 15 option limit Changes (by zach@…): * status: new => closed * resolution: => fixed Comment: Done. -- ----------------------------------+--------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: closed Priority: minor | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | ----------------------------------+--------------------- Ticket URL: core From julian.reschke@gmx.de Sun Mar 11 05:49:39 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DAE21F8674 for ; Sun, 11 Mar 2012 05:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-1.205, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=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 tcooYTUZ3KjP for ; Sun, 11 Mar 2012 05:49:38 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 4103921F8623 for ; Sun, 11 Mar 2012 05:49:37 -0700 (PDT) Received: (qmail invoked by alias); 11 Mar 2012 12:49:36 -0000 Received: from p57A6E004.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.224.4] by mail.gmx.net (mp033) with SMTP; 11 Mar 2012 13:49:36 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19r5v1zv1ZrmnIftOMDVc5eWOJWPObcR72fpu9mJU xFby6deIfuuaYV Message-ID: <4F5C9F5D.4060302@gmx.de> Date: Sun, 11 Mar 2012 13:49:33 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Zach Shelby References: <4F4D2FCB.8030805@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: core@ietf.org, draft-ietf-core-link-format@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [core] APPSDIR review of draft-ietf-core-link-format-11 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 12:49:39 -0000 On 2012-03-09 12:35, Zach Shelby wrote: > Julian, > > Thanks for the really detailed and helpful review! Well, sometimes a review request comes in where I actually can contribute (hopefully) :-) > On Feb 28, 2012, at 9:49 PM, Julian Reschke wrote: >> >> Major Issues: >> >> 2.2. Link relations >> >> Since links in the CoRE Link Format are typically used to describe >> resources hosted by a server, and thus in the absence of the relation >> parameter the new relation type "hosts" is assumed (see Section 7.2). >> >> It took me a moment to realize that "hosts" isn't the plural of "host" here. Maybe a different relation name would make things clearer (although I currently have no better proposal :-). > > Boy was that a fun discussion on the WG list as well, and hosts is what we ended up with... Maybe just adding some explanatory text right there would help. +1 >> The "hosts" relation type indicates that the target URI is a resource >> hosted by the server given by the base URI, or, if present, the >> anchor parameter. >> >> So the rule for determining the context URI is different for this link relation? I believe this needs to change. > > Originally it was for the whole link format, and I think with the rules you suggest below we can make it generic again. Sounds good. >> To express other relations, links can make use of any registered >> relation by including the relation parameter. To simplify the >> constrained implementations, the value of a "rel" parameter in this >> link format SHOULD NOT contain more than one relation type. There >> >> That's a SHOULD NOT that doesn't help anybody. Are recipients supposed to understand multiple relation types or not? If yes, then the constraint isn't needed. If no, it's a MUST NOT. > > The only reason we left the door open for allowing multiple relation types, was in case other Web Links were converted to this format (and thus may have multiple relation types). Constrained devices are not expected to understand multiple relation types. I would recommend that we just remove the SHOULD NOT. Well, you could serialized multiple relations in one link instance into multiple links. >> may be cases where multiple relation types cannot be avoided, for >> example when storing a RFC5988 Link header in this link format. The >> context of a relation can be defined using the anchor parameter. In >> this way, relations between resources hosted on a server, or between >> hosted resources and external resources can be expressed. >> >> This seems to repeat information from earlier on... >> >> >> 3. CoRE link extensions >> >> The following CoRE specific target attributes are defined in addition >> to the ABNF rules in Section 5 of [RFC5988]. These attributes >> describe information useful in accessing the target link of the >> relation, and in some cases may be URIs. These URIs MUST be treated >> >> s/may be/can use the syntactical form of a/ >> >> as non resolvable identifiers (they are not meant to be retrieved). >> >> Not sure about the "MUST". Maybe replace with an explanation that they can indeed by dereferenced (for instance to obtain a description of the link relation), but that this is not part of the protocol and MUST NOT be done automatically on link evaluation. > > Good suggestion, I will make a ticket. We do need to check that this is consistent with RFC5988, as my understanding of target attributes was that they are not meant to be retrieved (checking again though, I can't find text in RFC5988 that contradicts what you are suggesting). Consistency with 5988 is good :-) The main point here is that processing the link doesn't *need* dereferencing the link; but there may be other cases, such as looking up information, when it's useful to do so. >> When attributes are compared, they MUST be compared as strings. >> >> Attribute values? >> >> Relationships to resources that are meant to be retrieved should be >> expressed as separate links using the anchor attribute and the >> appropriate relation type. >> >> It's not clear to me what this means. Could you elaborate? > > Basically a work-around for the MUST you suggested replacing above. This text would be removed if that change is made. > >> link-extension = >> link-extension =/ ( "rt=" quoted-string ) >> link-extension =/ ( "if=" quoted-string ) >> link-extension =/ ( "sz=" cardinal ) >> cardinal = "0" / %x31-39 *DIGIT >> >> In here, you copied the ABNF style from RFC 5988. I think that style is something we should avoid, though, because it encourages parsers to special case certain attributes. >> >> I would recommend to allow both token and quoted-string for all new parameters. >> >> (and yes, I'll raise an erratum against RFC 5988 once we have done the base work in HTTPbis) > > Carsten already touched on this, and I will make a ticket. > >> >> 3.1. Resource type 'rt' attribute >> >> The resource type "rt" attribute is an opaque string used to assign a >> semantically important type to a resource. One can think of this as >> a noun describing the resource. In the case of a temperature >> resource this could be e.g. an application-specific semantic type >> like "OutdoorTemperature", a Universal Resource Name (URN) like >> "urn:temperature:outdoor" or a URI referencing a specific concept in >> an ontology like >> >> "http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature". Multiple >> resource type attributes MAY appear in a link. >> >> Please avoid that. In general, the format that you're borrowing from doesn't allow multiple parameters with the same name. Either make it multiple links, or allow a white-space separated list of values in the attribute value. > > Right, same goes for if=. In theory we could allow multiple values separated by a white-space, like in the rel= attribute. This makes the attribute matching more difficult however. At the same time including multiple links is wasteful overhead. So far when applying these in designs only a single rt= or if= attribute has been needed, but I could foresee multiple values in the future. If you require the separator to be a single SP, matching can be done by doing contains(concat(" ",value," "),concat(" ",searchfor," ") so it's no too hard. >> The resource type attribute is not meant to used to assign a human >> readable name to a resource. The "title" attribute defined in >> [RFC5988] is meant for that purpose. >> >> Did you consider using the type attribute that already is defined in RFC 5988? > > type= refers to the Media Type, and this is already used also in this format for that purpose. > >> 5. Examples >> >> A few examples of typical link descriptions in this format follows. >> Multiple resource descriptions in a representation are separated by >> commas. Linefeeds never occur in the actual format, but are shown in >> these examples for readability. Although the following examples use >> CoAP response codes, the examples are applicable to HTTP as well (the >> corresponding response code would be 200 OK). >> >> Actually, RFC 5988 allows CR LF between parameters as it uses the RFC 2616 list production allowing implied LWS. >> >> If you want to rule this out, you probably need to specify your own ABNF. > > I would not mind allowing the CR LF actually, but do we really inherit that from the RFC 2616 production as we are not inside the HTTP header anymore? It's part of the ABNF, not something specific to header fields. So yes, it does inherit that. >> This example arranges link descriptions hierarchically, with the >> entry point including a link to a sub-resource containing links about >> the sensors. >> >> REQ: GET /.well-known/core >> >> RES: 2.05 "Content" >> ;rt="index" >> >> REQ: GET /sensors >> >> RES: 2.05 "Content" >> ;rt="TemperatureC";if="sensor", >> ;rt="LightLux";if="sensor" >> >> rt="index" is mentioned for the first time here. Is this something recipients need to understand, so is it predefined? Also, isn't this a use case for rel=index? > > Yep, "index" is not a great example here. I will update this to be more appropriate. > >> Minor Issues: >> >> The main function of such a discovery mechanism is to provide >> Universal Resource Identifiers (URIs, called links) for the resources >> >> Nope. As discussed further down below, a link requires two resources, not a single one. >> >> 2.1. Target and context URIs >> >> Each link conveys one target URI as a URI-reference inside angle >> brackets ("<>"). The context URI of a link (also called base URI in >> [RFC3986]) conveyed in the CoRE Link Format is by default built from >> the scheme and authority parts of the target URI. In the absence of >> >> OK, so >> >> ; rel=bar >> >> represents the link >> >> http://example.com --bar--> http://example.com/foo >> >> ? Sounds a bit counter-intuitive to me; maybe you should explain that in examples. > > It is intuitive for our main use case, which is describing the resources hosted by that server using the rel=hosts relation. But yes, I can add more example. > >> >> this information in the target URI, the context URI is built from the >> scheme and authority that was used for referencing the resource >> returning the set of links, replacing the path with an empty path. >> >> Thus by default links can be thought of as describing a target >> resource hosted by the server. Other relations can be expressed by >> including an anchor parameter (which defines the context URI) along >> with an explicit relation parameter. This is an important difference >> to the way the HTTP Link Header format is used, as it is included in >> the header of an HTTP response for some URI (this URI is by default >> the context URI). Thus the HTTP Link Header is by default relating >> the target URI to the URI that was requested. In comparison, the >> CoRE link format includes one or more links, each describing a >> resource hosted by a server by default. Other relations can be >> expressed by using the anchor parameter. See Section 5 of [RFC3986] >> for a description of how URIs are constructed from URI references. >> >> Alternative explanation: >> >> The context URI specified by >> >> a) the anchor parameter, when specified, or >> >> b) protocol + authority of the target URI, when specified >> >> c) protocol + authority of the link format document's base URI. >> >> It would be nice if the reason why only protocol + authority are used. > > I like this way of explaining it, will make a ticket. > >> (you may also want to use the term "Origin" (RFC 6454) for protocol + authority) > > Richard Barnes also suggested this in his review, added a ticket already: > http://trac.tools.ietf.org/wg/core/trac/ticket/191 > >> 2.3. Use of anchors >> >> As per Section 5.2 of [RFC5988] a link description MAY include an >> "anchor" attribute, in which case the context is the URI included in >> that attribute. This is used to describe a relationship between two >> resources. A consuming implementation can however choose to ignore >> such links. It is not expected that all implementations will be able >> to derive useful information from explicitly anchored links. >> >> Right. Maybe make clear that recipients MUST either process anchor correctly, or ignore the whole link relation (not only the anchor parameter). > > OK. > >> 7.2. New 'hosts' relation type >> >> This memo registers the new "hosts" Web Linking relation type as per >> [RFC5988]. >> >> Relation Name: hosts >> >> Description: Refers to a resource hosted by the server indicated by >> the link context. >> >> Does that indicate more than "is one the same server"? In which case I believe no link relation is needed. > > We are using this to indicate: > > Origin -> hosts -> Target URI > > e.g. > > coap://this.server -> hosts -> /sensor/temperature (and has these attributes) > > How would we relate this following Web Linking without a relation? By specifying an untyped link... > ... Best regards, Julian From trac+core@trac.tools.ietf.org Mon Mar 12 09:25:40 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6D511E808F for ; Mon, 12 Mar 2012 09:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8GJZHCqFGx1 for ; Mon, 12 Mar 2012 09:25:39 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3B56311E808C for ; Mon, 12 Mar 2012 09:25:39 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S783e-0001dU-UM; Mon, 12 Mar 2012 12:25:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 12 Mar 2012 16:25:14 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/177#comment:1 Message-ID: <066.924a528dfa41671c33a7c32467afea34@trac.tools.ietf.org> References: <051.f2c70308ab0d71f7798afa515a549f6b@trac.tools.ietf.org> X-Trac-Ticket-ID: 177 In-Reply-To: <051.f2c70308ab0d71f7798afa515a549f6b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120312162539.3B56311E808C@ietfa.amsl.com> Resent-Date: Mon, 12 Mar 2012 09:25:39 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #177: Response suppression for multicast not defined 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, 12 Mar 2012 16:25:40 -0000 #177: Response suppression for multicast not defined Changes (by cabo@…): * status: new => closed * resolution: => fixed Comment: Fixed in [524]: Fix #177 -- --------------------------------+------------------------------------- Reporter: cabo@… | Owner: draft-ietf-core-coap@… Type: protocol defect | Status: closed Priority: major | Milestone: Component: coap | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------- Ticket URL: core From internet-drafts@ietf.org Mon Mar 12 10:09:25 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA4021F85D1; Mon, 12 Mar 2012 10:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 orbg4xShadXx; Mon, 12 Mar 2012 10:09:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B48021F853B; Mon, 12 Mar 2012 10:09:24 -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.00 Message-ID: <20120312170924.6123.20388.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 10:09:24 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-observe-05.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, 12 Mar 2012 17:09:25 -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 Work= ing Group of the IETF. Title : Observing Resources in CoAP Author(s) : Klaus Hartke Filename : draft-ietf-core-observe-05.txt Pages : 27 Date : 2012-03-12 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 gives clients the ability to observe such changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-observe-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-observe-05.txt From Akbar.Rahman@InterDigital.com Mon Mar 12 11:40:11 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36DE21F899C for ; Mon, 12 Mar 2012 11:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[AWL=0.571, 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 mWALpQbhqauj for ; Mon, 12 Mar 2012 11:40:11 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2829521F899B for ; Mon, 12 Mar 2012 11:40:11 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 14:40:09 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 12 Mar 2012 14:40:09 -0400 Message-ID: In-Reply-To: <066.924a528dfa41671c33a7c32467afea34@trac.tools.ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] #177: Response suppression for multicast not defined Thread-Index: Ac0AbNLBiXDDPt6TRkqAPzgaRsf7AQAEaN+A References: <051.f2c70308ab0d71f7798afa515a549f6b@trac.tools.ietf.org> <066.924a528dfa41671c33a7c32467afea34@trac.tools.ietf.org> From: "Rahman, Akbar" To: X-OriginalArrivalTime: 12 Mar 2012 18:40:09.0917 (UTC) FILETIME=[8D8B36D0:01CD007F] Cc: draft-ietf-core-coap@tools.ietf.org, trac+core@trac.tools.ietf.org, core@ietf.org Subject: Re: [core] #177: Response suppression for multicast not defined X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Mar 2012 18:40:11 -0000 SGkgQ2Fyc3RlbiwNCg0KDQpDb3VsZCB5b3UgcGxlYXNlIGNsYXJpZnkgZXhhY3RseSB3aGF0IGNo YW5nZSB3YXMgaW5jb3Jwb3JhdGVkIGludG8gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1jb3JlLWNvYXAtMDg/DQoNCldoZW4gSSBsb29rIGF0IHRoZSBGaXggIzE3NyBjaXRl ZCBiZWxvdyANCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2NvcmUvY3Vy cmVudC9tc2cwMjM4Mi5odG1sDQoNCml0IHJlZmVycyB0byANCg0KCSJTbyB5ZXMsIEkgdGhpbmsg dGhlcmUgc2hvdWxkIGJlIG5ldyB0ZXh0IGluIDQuNCB0aGF0IHNheXMgdGhlIHJlbGlhYmlsaXR5 DQogCWxheWVyIGRvZXMgaW5kaWNhdGUgdG8gdGhlIHIvciBsYXllciB0aGF0IHRoaXMgd2FzIGEg bXVsdGljYXN0LiINCg0KDQpJIGRpZCBub3Qgc2VlIHRoaXMgdHlwZSBvZiB0ZXh0IGluIHNlY3Rp b24gNC40IGhvd2V2ZXIuICBCdXQgbWF5YmUgSSBhIG0gbWlzc2luZyBzb21ldGhpbmc/DQoNCg0K DQpUaGFua3MsDQoNCg0KQWtiYXINCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBjb3JlIGlzc3VlIHRyYWNrZXINClNlbnQ6IE1vbmRheSwgTWFyY2ggMTIs IDIwMTIgMTI6MjUgUE0NClRvOiBkcmFmdC1pZXRmLWNvcmUtY29hcEB0b29scy5pZXRmLm9yZzsg Y2Fib0B0emkub3JnDQpDYzogY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtjb3JlXSAjMTc3 OiBSZXNwb25zZSBzdXBwcmVzc2lvbiBmb3IgbXVsdGljYXN0IG5vdCBkZWZpbmVkDQoNCiMxNzc6 IFJlc3BvbnNlIHN1cHByZXNzaW9uIGZvciBtdWx0aWNhc3Qgbm90IGRlZmluZWQNCg0KQ2hhbmdl cyAoYnkgY2Fib0DigKYpOg0KDQogKiBzdGF0dXM6ICBuZXcgPT4gY2xvc2VkDQogKiByZXNvbHV0 aW9uOiAgID0+IGZpeGVkDQoNCg0KQ29tbWVudDoNCg0KIEZpeGVkIGluIFs1MjRdOg0KDQogRml4 ICMxNzcNCg0KLS0gDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogUmVwb3J0ZXI6ICBjYWJvQOKApiAgICAgICAg ICAgICAgfCAgICAgICBPd25lcjogIGRyYWZ0LWlldGYtY29yZS1jb2FwQOKApg0KICAgICBUeXBl OiAgcHJvdG9jb2wgZGVmZWN0ICAgICB8ICAgICAgU3RhdHVzOiAgY2xvc2VkDQogUHJpb3JpdHk6 ICBtYWpvciAgICAgICAgICAgICAgIHwgICBNaWxlc3RvbmU6DQpDb21wb25lbnQ6ICBjb2FwICAg ICAgICAgICAgICAgIHwgICAgIFZlcnNpb246DQogU2V2ZXJpdHk6ICBBY3RpdmUgV0cgRG9jdW1l bnQgIHwgIFJlc29sdXRpb246ICBmaXhlZA0KIEtleXdvcmRzOiAgICAgICAgICAgICAgICAgICAg ICB8DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNClRpY2tldCBVUkw6IDwvdGlja2V0LzE3NyNjb21tZW50OjE+ DQpjb3JlIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvY29yZS8+DQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo= From zach@sensinode.com Mon Mar 12 12:33:20 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783F321F8925 for ; Mon, 12 Mar 2012 12:33:20 -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 lhVkLYOq6dFu for ; Mon, 12 Mar 2012 12:33:19 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 4951A21F8914 for ; Mon, 12 Mar 2012 12:33:18 -0700 (PDT) Received: from [172.20.10.2] (85-156-154-154.elisa-mobile.fi [85.156.154.154]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q2CJWwbK030838; Mon, 12 Mar 2012 21:33:00 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Zach Shelby In-Reply-To: Date: Mon, 12 Mar 2012 21:32:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <051.f2c70308ab0d71f7798afa515a549f6b@trac.tools.ietf.org> <066.924a528dfa41671c33a7c32467afea34@trac.tools.ietf.org> To: "Rahman, Akbar" X-Mailer: Apple Mail (2.1084) Cc: core issue tracker , core WG Subject: Re: [core] #177: Response suppression for multicast not defined X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Mar 2012 19:33:20 -0000 Hi Akbar, These changes are being checked into the SVN as they are closed, and = will show up in the coap-09 submission tonight. By the way, the SVN is = accessible by anyone if you are ever interested in changes as we close = tickets on WG documents: http://trac.tools.ietf.org/wg/core/trac/browser Zach On Mar 12, 2012, at 8:40 PM, Rahman, Akbar wrote: > Hi Carsten, >=20 >=20 > Could you please clarify exactly what change was incorporated into = http://tools.ietf.org/html/draft-ietf-core-coap-08? >=20 > When I look at the Fix #177 cited below=20 >=20 > http://www.ietf.org/mail-archive/web/core/current/msg02382.html >=20 > it refers to=20 >=20 > "So yes, I think there should be new text in 4.4 that says the = reliability > layer does indicate to the r/r layer that this was a multicast." >=20 >=20 > I did not see this type of text in section 4.4 however. But maybe I a = m missing something? >=20 >=20 >=20 > Thanks, >=20 >=20 > Akbar >=20 >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of core issue tracker > Sent: Monday, March 12, 2012 12:25 PM > To: draft-ietf-core-coap@tools.ietf.org; cabo@tzi.org > Cc: core@ietf.org > Subject: Re: [core] #177: Response suppression for multicast not = defined >=20 > #177: Response suppression for multicast not defined >=20 > Changes (by cabo@=85): >=20 > * status: new =3D> closed > * resolution: =3D> fixed >=20 >=20 > Comment: >=20 > Fixed in [524]: >=20 > Fix #177 >=20 > --=20 > --------------------------------+------------------------------------- > Reporter: cabo@=85 | Owner: = draft-ietf-core-coap@=85 > Type: protocol defect | Status: closed > Priority: major | Milestone: > Component: coap | Version: > Severity: Active WG Document | Resolution: fixed > Keywords: | > --------------------------------+------------------------------------- >=20 > Ticket URL: > core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From Akbar.Rahman@InterDigital.com Mon Mar 12 12:41:45 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FEA21E8090 for ; Mon, 12 Mar 2012 12:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.428, 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 gd6nIxur11MW for ; Mon, 12 Mar 2012 12:41:44 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id B509221E805C for ; Mon, 12 Mar 2012 12:41:44 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 15:41:43 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 12 Mar 2012 15:41:43 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] #177: Response suppression for multicast not defined Thread-Index: Ac0Ahv055FqR9pvuT5ivsq9FGMaUawAANcmA References: <051.f2c70308ab0d71f7798afa515a549f6b@trac.tools.ietf.org> <066.924a528dfa41671c33a7c32467afea34@trac.tools.ietf.org> From: "Rahman, Akbar" To: "Zach Shelby" X-OriginalArrivalTime: 12 Mar 2012 19:41:43.0705 (UTC) FILETIME=[27368890:01CD0088] Cc: core issue tracker , core WG Subject: Re: [core] #177: Response suppression for multicast not defined X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Mar 2012 19:41:45 -0000 Thanks, Zach. I will then make sure to read the updated I-D after you submit it tonight. Esko and I have some text in our Groupcomm I-D for multicast support (on the topic of multicast response handling) that we want to make sure is well coordinated with the coap-09 I-D. Akbar -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com]=20 Sent: Monday, March 12, 2012 3:33 PM To: Rahman, Akbar Cc: core issue tracker; core WG Subject: Re: [core] #177: Response suppression for multicast not defined Hi Akbar, These changes are being checked into the SVN as they are closed, and will show up in the coap-09 submission tonight. By the way, the SVN is accessible by anyone if you are ever interested in changes as we close tickets on WG documents: http://trac.tools.ietf.org/wg/core/trac/browser Zach On Mar 12, 2012, at 8:40 PM, Rahman, Akbar wrote: > Hi Carsten, >=20 >=20 > Could you please clarify exactly what change was incorporated into http://tools.ietf.org/html/draft-ietf-core-coap-08? >=20 > When I look at the Fix #177 cited below=20 >=20 > http://www.ietf.org/mail-archive/web/core/current/msg02382.html >=20 > it refers to=20 >=20 > "So yes, I think there should be new text in 4.4 that says the reliability > layer does indicate to the r/r layer that this was a multicast." >=20 >=20 > I did not see this type of text in section 4.4 however. But maybe I a m missing something? >=20 >=20 >=20 > Thanks, >=20 >=20 > Akbar >=20 >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of core issue tracker > Sent: Monday, March 12, 2012 12:25 PM > To: draft-ietf-core-coap@tools.ietf.org; cabo@tzi.org > Cc: core@ietf.org > Subject: Re: [core] #177: Response suppression for multicast not defined >=20 > #177: Response suppression for multicast not defined >=20 > Changes (by cabo@...): >=20 > * status: new =3D> closed > * resolution: =3D> fixed >=20 >=20 > Comment: >=20 > Fixed in [524]: >=20 > Fix #177 >=20 > --=20 > --------------------------------+------------------------------------- > Reporter: cabo@... | Owner: draft-ietf-core-coap@... > Type: protocol defect | Status: closed > Priority: major | Milestone: > Component: coap | Version: > Severity: Active WG Document | Resolution: fixed > Keywords: | > --------------------------------+------------------------------------- >=20 > Ticket URL: > core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From trac+core@trac.tools.ietf.org Mon Mar 12 14:56:01 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD99221E80DE for ; Mon, 12 Mar 2012 14:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Lwx3IrVSvnw for ; Mon, 12 Mar 2012 14:56:01 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 13DB421E80DC for ; Mon, 12 Mar 2012 14:56:00 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S7DDe-0006HO-JT; Mon, 12 Mar 2012 17:55:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Mon, 12 Mar 2012 21:55:54 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/166#comment:3 Message-ID: <072.a6c57b1f9f3586f18bac4b0ffb20c003@trac.tools.ietf.org> References: <057.11808fbd63fcfaacaafb1d432d39b421@trac.tools.ietf.org> X-Trac-Ticket-ID: 166 In-Reply-To: <057.11808fbd63fcfaacaafb1d432d39b421@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #166: Security re-focus on public keys 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, 12 Mar 2012 21:56:02 -0000 #166: Security re-focus on public keys Changes (by zach@…): * status: reopened => closed * resolution: => fixed Comment: The RPK re-focus is now in good shape, so now closing this ticket. -- ----------------------------------+--------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: closed Priority: major | Milestone: Component: coap | Version: Severity: - | Resolution: fixed Keywords: | ----------------------------------+--------------------- Ticket URL: core From internet-drafts@ietf.org Mon Mar 12 15:06:42 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9674521E811F; Mon, 12 Mar 2012 15:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 5DjkN1w6wMuq; Mon, 12 Mar 2012 15:06:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A60821E8112; Mon, 12 Mar 2012 15:06:42 -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.00 Message-ID: <20120312220642.5282.46187.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 15:06:42 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-09.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, 12 Mar 2012 22:06:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Work= ing Group of the IETF. Title : Constrained Application Protocol (CoAP) Author(s) : Zach Shelby Klaus Hartke Carsten Bormann Brian Frank Filename : draft-ietf-core-coap-09.txt Pages : 91 Date : 2012-03-12 This document specifies the Constrained Application Protocol (CoAP), a specialized web transfer protocol for use with constrained networks and nodes for machine-to-machine applications such as smart energy and building automation. These constrained nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. CoAP provides a method/response interaction model between application end-points, supports built-in resource discovery, and includes key web concepts such as URIs and content-types. CoAP easily translates to HTTP for integration with the web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-core-coap-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-coap-09.txt From cabo@tzi.org Mon Mar 12 16:47:43 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED6C21E825C for ; Mon, 12 Mar 2012 16:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.304 X-Spam-Level: X-Spam-Status: No, score=-106.304 tagged_above=-999 required=5 tests=[AWL=-0.055, 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 kRxIFYh8H8ci for ; Mon, 12 Mar 2012 16:47:43 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2171721E8256 for ; Mon, 12 Mar 2012 16:47: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.3/8.14.3) with ESMTP id q2CNlXNa013879 for ; Tue, 13 Mar 2012 00:47:33 +0100 (CET) Received: from [192.168.217.105] (p5B3E605E.dip.t-dialin.net [91.62.96.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 10795D9; Tue, 13 Mar 2012 00:47:33 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1257) From: Carsten Bormann Date: Tue, 13 Mar 2012 00:47:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <15FC5D3E-66CF-4139-8FB3-6E12C2857A12@tzi.org> References: <20120312233925.24232.21964.idtracker@ietfa.amsl.com> To: core WG X-Mailer: Apple Mail (2.1257) Subject: [core] Fwd: I-D Action: draft-bormann-coap-misc-13.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:47:44 -0000 I have submitted a new version of coap-misc. Enjoy at: http://tools.ietf.org/html/coap-misc The two main additions are: 1) Appendix A.3: o256 -- a length-aware encoding for cardinals (unsigned = integers) 2) Appendix A.4: an ASCII-aware SMS encoding for CoAP See the new stuff at: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-bormann-coap-misc-13.txt (I haven't cleaned out the text that went into coap-09 yet, so you can = cross-check whether you are happy with the slightly more brief wording = chosen in coap09.) Gr=FC=DFe und Gute Nacht, Carsten From peter.van.der.stok@philips.com Tue Mar 13 02:04:47 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E7421F86EF for ; Tue, 13 Mar 2012 02:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+ZyKeinkkCi for ; Tue, 13 Mar 2012 02:04:47 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 2A22C21F86B0 for ; Tue, 13 Mar 2012 02:04:47 -0700 (PDT) Received: from mail75-ch1-R.bigfish.com (10.43.68.243) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Tue, 13 Mar 2012 09:04:46 +0000 Received: from mail75-ch1 (localhost [127.0.0.1]) by mail75-ch1-R.bigfish.com (Postfix) with ESMTP id E696E4203F4 for ; Tue, 13 Mar 2012 09:04:46 +0000 (UTC) X-SpamScore: -33 X-BigFish: VPS-33(zz217bL15d6O9251Jc85fhzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail75-ch1 (localhost.localdomain [127.0.0.1]) by mail75-ch1 (MessageSwitch) id 1331629484910077_22047; Tue, 13 Mar 2012 09:04:44 +0000 (UTC) Received: from CH1EHSMHS015.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.228]) by mail75-ch1.bigfish.com (Postfix) with ESMTP id D20464C0066 for ; Tue, 13 Mar 2012 09:04:44 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 13 Mar 2012 09:04:43 +0000 Received: from 011-DB3MMR1-020.MGDPHG.emi.philips.com (10.128.28.101) by 011-DB3MMR1-007.MGDPHG.emi.philips.com (10.128.28.57) with Microsoft SMTP Server (TLS) id 14.1.355.3; Tue, 13 Mar 2012 09:06:47 +0000 Received: from 011-DB3MPN1-061.MGDPHG.emi.philips.com ([169.254.1.139]) by 011-DB3MMR1-020.MGDPHG.emi.philips.com ([fe80::65e7:4d4c:4c67:daa9%11]) with mapi id 14.01.0355.003; Tue, 13 Mar 2012 09:06:47 +0000 From: "Stok, Peter van der" To: "core@ietf.org" Thread-Topic: new discovery, naming, addressing (dna) draft Thread-Index: Ac0A+FUv2PRzfC6JRaGCFD6yPVP4oQ== Date: Tue, 13 Mar 2012 09:06:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.102] Content-Type: multipart/alternative; boundary="_000_A31CB84F6F0BFC449C6807DF752A715B03DDE4011DB3MPN1061MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] new discovery, naming, addressing (dna) draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 09:04:48 -0000 --_000_A31CB84F6F0BFC449C6807DF752A715B03DDE4011DB3MPN1061MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have submitted version 1 of the dna draft draft-vanderstok-core-dna-01 Changes are: updates of definitions clarified text. Peter van der Stok Philips Research Laboratories Eindhoven High Tech Campus H= TC 34 (WB) 1-067 5656 AA Eindhoven The = Netherlands phone +31 40 2749657 Fax: + = 31 40 2746321 mailto: Peter.van.der.Stok@philips.com ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_A31CB84F6F0BFC449C6807DF752A715B03DDE4011DB3MPN1061MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have submitted version 1 of the dna draft

draft-vanderstok-core-dna-01

 

Changes are:

updates of definitions

clarified text.

 

 

 

Peter van der Stok

Philips Research Laboratories Eind= hoven

High Tech Campus       &nb= sp;            =             &nb= sp;            =              HT= C 34 (WB) 1-067

5656 AA Eindhoven       &n= bsp;            = ;            &n= bsp;            = ;         The Netherlands

phone +31 40 2749657      &= nbsp;            &nb= sp;            =             &nb= sp;   Fax: + 31 40 2746321

mailto: Peter.van.der.Stok@philips.com

 


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_A31CB84F6F0BFC449C6807DF752A715B03DDE4011DB3MPN1061MGDP_-- From esko.dijk@philips.com Tue Mar 13 06:19:48 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2796621F86CA for ; Tue, 13 Mar 2012 06:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.028 X-Spam-Level: X-Spam-Status: No, score=-4.028 tagged_above=-999 required=5 tests=[AWL=-0.429, 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 5RhkjqGpZgPY for ; Tue, 13 Mar 2012 06:19:47 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id EAFF021F86C2 for ; Tue, 13 Mar 2012 06:19:46 -0700 (PDT) Received: from mail119-db3-R.bigfish.com (10.3.81.248) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Tue, 13 Mar 2012 13:19:46 +0000 Received: from mail119-db3 (localhost [127.0.0.1]) by mail119-db3-R.bigfish.com (Postfix) with ESMTP id 919B56006D; Tue, 13 Mar 2012 13:19:46 +0000 (UTC) X-SpamScore: -58 X-BigFish: VPS-58(zz217bL15d6O9371I9251J542M1432N98dKef7Rzz1202hzz8275ch1033IL8275dhz2dh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail119-db3 (localhost.localdomain [127.0.0.1]) by mail119-db3 (MessageSwitch) id 133164478582995_20724; Tue, 13 Mar 2012 13:19:45 +0000 (UTC) Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.248]) by mail119-db3.bigfish.com (Postfix) with ESMTP id 0F8E414004D; Tue, 13 Mar 2012 13:19:45 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 13 Mar 2012 13:19:41 +0000 Received: from 011-DB3MMR1-023.MGDPHG.emi.philips.com (10.128.28.107) by 011-DB3MMR1-003.MGDPHG.emi.philips.com (10.128.28.53) with Microsoft SMTP Server (TLS) id 14.1.355.3; Tue, 13 Mar 2012 13:21:47 +0000 Received: from 011-DB3MPN1-014.MGDPHG.emi.philips.com ([169.254.4.162]) by 011-DB3MMR1-023.MGDPHG.emi.philips.com ([fe80::e485:97aa:9b41:86e3%11]) with mapi id 14.01.0355.003; Tue, 13 Mar 2012 13:21:46 +0000 From: "Dijk, Esko" To: Zhen Cao , "Angelo P. Castellani" Thread-Topic: [core] sleepy to sleepy communication I-Ds Thread-Index: AQHM9yvFF4vhgW3HcE6AjepfFzvAB5Zat50AgAB7rICAACz3gIAAEs0AgAACvoCAAy6YAIAJpH1A Date: Tue, 13 Mar 2012 13:21:46 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61807B391@011-DB3MPN1-014.MGDPHG.emi.philips.com> References: <9032C193-A015-4F41-B441-4D1D47594FC9@koanlogic.com> <4F53E746.7050401@piuha.net> <9B51E46C-D03D-4911-8D00-65B56DE48F63@koanlogic.com> <4F548482.9070707@piuha.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: core WG Subject: Re: [core] sleepy to sleepy communication 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: Tue, 13 Mar 2012 13:19:48 -0000 Typical industry requirements for battery-powered wireless sensors are in t= he order of 7-10 years, from what I know. So certainly tighter requirements. Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Zhe= n Cao Sent: Wednesday 7 March 2012 11:02 To: Angelo P. Castellani Cc: core WG Subject: Re: [core] sleepy to sleepy communication I-Ds On Mon, Mar 5, 2012 at 5:26 PM, Angelo P. Castellani wrote: > I agree with you that this can save a lot more of energy, if the hosts > can provide service during theirs "office hours" :) > > However if the nodes will behave in such a way, for sure this will be > visible to the clients and lots of infrastructure (proxies) will be > required to get anything usable by the users. > > With regular sensor networks duty cycling, a ~3 years lifetime is > feasible with regular batteries (depending upon actual usage and > network traffic). Are you targeting a use case with tighter > requirements? Are you sure about the battery lifetime? I am using two AA battery with 700mAH each. And the power consumption of the RF module is 23mA, 21uA, 1uA for active, idle and sleep. So normally for me it is several month at most. Best regards, Zhen > > Best, > Angelo > > On Mon, Mar 5, 2012 at 10:16, Jari Arkko wrote: >> >> Angelo, >> >> >>> Indeed sensor networks support sleeping using radio duty cycling at >>> lower layers, this turns out in having the sleeping functionality >>> without any loss of communication at the upper layers. >>> >> >> We discussed this a couple of IETFs back. Since then I've been doing som= e >> talking to our researchers who measure and improve power usage in radios= . >> >> First, duty cycling is already pretty widely used for radio technology. = All >> cellular systems, for instance, turn off the radio except in during the = time >> they listen for possible incoming paging signals, system information >> necessary to stay in contact at all, or when they have been granted a ti= me >> slot to send. >> >> Secondly and more importantly, per their measurements, even after all th= e >> above techniques, periodic listening for possibly incoming messages is t= he >> biggest consumer of energy in applications where we'd like to have a lon= g >> battery life, such as in sensors. That power usage dwarfs everything els= e, >> so it has to come down, somehow, to make an improvement. >> >> So if we want to achieve significantly longer battery lifetimes (and I c= laim >> we need those) we need to change some things. Obviously a lot of the lin= k >> layers can be tuned better, implementing simply longer paging frequencie= s, >> for instance. My hypothesis is that we'll have to go longer than what >> typical application protocol timeouts are today, so the change would be >> something that is visible to applications. We could change some of the >> timeouts, but it is not clear that network buffers and all underlying >> mechanisms deployed today support those without changes. And in general,= I >> think it is better to fit the communication model to the problem at hand >> than vice versa. As a result, I personally believe that we need to build >> applications that natively communicate in ways that make sleep modes eas= y. >> Such as publish-subscribe instead of direct request-response from anyone= who >> needs the information. But like I said, this is a hypothesis and I'd lov= e to >> be proven wrong. >> >> Jari >> >> > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Best regards, Zhen _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From esko.dijk@philips.com Tue Mar 13 06:39:19 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B56421F8871 for ; Tue, 13 Mar 2012 06:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1FfhIXYyOUW for ; Tue, 13 Mar 2012 06:39:18 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEF821F882E for ; Tue, 13 Mar 2012 06:39:18 -0700 (PDT) Received: from mail14-ch1-R.bigfish.com (10.43.68.234) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Tue, 13 Mar 2012 13:39:17 +0000 Received: from mail14-ch1 (localhost [127.0.0.1]) by mail14-ch1-R.bigfish.com (Postfix) with ESMTP id 9A6DA480125; Tue, 13 Mar 2012 13:39:17 +0000 (UTC) X-SpamScore: -49 X-BigFish: VPS-49(zzbb2dI217bL15d6O9251Jc89bh936eK542M14ffOzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail14-ch1 (localhost.localdomain [127.0.0.1]) by mail14-ch1 (MessageSwitch) id 1331645955440484_8117; Tue, 13 Mar 2012 13:39:15 +0000 (UTC) Received: from CH1EHSMHS004.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.235]) by mail14-ch1.bigfish.com (Postfix) with ESMTP id 6960C200045; Tue, 13 Mar 2012 13:39:15 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS004.bigfish.com (10.43.70.4) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 13 Mar 2012 13:39:12 +0000 Received: from 011-DB3MPN1-014.MGDPHG.emi.philips.com ([169.254.4.162]) by 011-DB3MMR1-005.MGDPHG.emi.philips.com ([10.128.28.55]) with mapi id 14.01.0355.003; Tue, 13 Mar 2012 13:41:16 +0000 From: "Dijk, Esko" To: "matthieu.vial@non.schneider-electric.com" Thread-Topic: [core] Tr : New Version Notification for draft-vial-core-mirror-proxy-00.txt Thread-Index: AQHM+HXGBKCQEHwzEUqw/PYE5xqGJZZoR3rQ Date: Tue, 13 Mar 2012 13:41:16 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61807B3C7@011-DB3MPN1-014.MGDPHG.emi.philips.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: core WG Subject: Re: [core] Tr : New Version Notification for draft-vial-core-mirror-proxy-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, 13 Mar 2012 13:39:19 -0000 Thanks Matthieu, interesting that you mention the response suppression option ("Suppr-Rsp"),= which was discussed before on the CoRE list. Would you be interested to contribute to a short I-D about such CoAP option= ? It may be useful for multiple purposes. Although now in coap-09 there is additional text on CoAP response suppressi= on (for the multicast case), where each CoAP server decides whether to resp= ond or not, an explicit signaling from the client may be useful for certain= use cases or to improve on some interoperability/upgradability aspects of = larger CoAP systems. A response suppression option could use a bitmask to signal the clients pre= ferences, e.g.: bit 0: Suppress all 2.xx success responses bit 1: Suppress all 4.xx client errors bit 2: Suppress all 5.xx server errors bit 3: Suppress all query responses with a size zero result set (if bit NOT= set, don't suppress empty result sets!) bit 4: (Suppress payload in response ?) Any combination of the previous items is thus possible. All bits clears mea= ns follow CoAP protocol defaults and the server's defaults. Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of mat= thieu.vial@non.schneider-electric.com Sent: Friday 2 March 2012 14:10 To: core WG Subject: [core] Tr : New Version Notification for draft-vial-core-mirror-pr= oxy-00.txt Hello all, Here is another draft dealing with sleepy devices. I will be glad to read your comments and suggestions to improve the document. Best regards, Matthieu Vial ----- R=E9achemin=E9 par Matthieu Vial/FR/Non/Schneider le 02/03/2012 14:01 ----- internet-drafts@ietf.org 02/03/2012 13:58 A Matthieu Vial/FR/Non/Schneider@Europe cc Objet New Version Notification for draft-vial-core-mirror-proxy-00.txt A new version of I-D, draft-vial-core-mirror-proxy-00.txt has been successfully submitted by Matthieu Vial and posted to the IETF repository. Filename: draft-vial-core-mirror-proxy Revision: 00 Title: CoRE Mirror Proxy Creation date: 2012-03-02 WG ID: Individual Submission Number of pages: 14 Abstract: This document introduces the concept of Mirror Proxy that enables sleeping devices to participate in a REST architecture despite the fact that they are not web servers. Most constrained devices may sleep during long periods preventing them from acting as traditional web servers. However as client-only endpoints they can rely on a Mirror Proxy to cache and serve the content they provide. The IETF Secretariat ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. ______________________________________________________________________ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From angelo.castellani@gmail.com Tue Mar 13 06:58:36 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69A821F88B7 for ; Tue, 13 Mar 2012 06:58:36 -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 Wz5106bT034W for ; Tue, 13 Mar 2012 06:58:35 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC2221F888B for ; Tue, 13 Mar 2012 06:58:35 -0700 (PDT) Received: by werb10 with SMTP id b10so692095wer.31 for ; Tue, 13 Mar 2012 06:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; bh=32JWuDfSw56IkbcFOAH6L24e71fyoTXvMAGUQFtLaxQ=; b=rsG9zsLmlymINsWwxVVZnJ04wobtjyW72mku1VbnnsCUahj6B+D4pqk25emDDz4Jig E4dh7hP0M2FCxC7irCzjPdPExkGsVgx4f6VZfXT0MDcSe3t0S7FYSRJ+Y5wWp6bxPQg6 mi1oKJVyJ6TWyLEMwB6Ew6aq9ydi0dH00XyF713WpjUSC4LDKp9neVIA8pXCBhF8qrLK 8ZLktcJjnWr9J4JkCgVyIeUIlIEagL7y5x9aupVGMWOM1sEVuhiYwcZKLxix9FBVkpYE OxWrwsnXlxKon52YkzrGCnFvw0BUogKnlvQt5mpSw011ZmwfZo/Q7aOjDB3RUvcHqSLJ QM1Q== Received: by 10.180.79.231 with SMTP id m7mr7729378wix.11.1331647114257; Tue, 13 Mar 2012 06:58:34 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.210.12 with HTTP; Tue, 13 Mar 2012 06:57:53 -0700 (PDT) In-Reply-To: <20120312134053.26440.60152.idtracker@ietfa.amsl.com> References: <20120312134053.26440.60152.idtracker@ietfa.amsl.com> From: "Angelo P. Castellani" Date: Tue, 13 Mar 2012 14:57:53 +0100 X-Google-Sender-Auth: rf050yWNvLzxii3bGAzPFJeKTv0 Message-ID: To: core Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [core] Fwd: New Version Notification for draft-castellani-core-http-mapping-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, 13 Mar 2012 13:58:36 -0000 Dear WG, we have worked at the document providing text for the "Observe mapping" sec= tion: http://tools.ietf.org/html/draft-castellani-core-http-mapping Moreover we have implemented some parts of the current I-D while working on to two different implementations of HTTP-CoAP proxies: - http://telecom.dei.unipd.it/iot from University of Padova - https://github.com/koanlogic/webthings/tree/master/bridge/sw/lib/evcoap from KoanLogic, University of Bologna and Salvatore Loreto (as individual) We would like to discuss our progress and our experiences with the WG, so we would like to have a 5-10 minutes slot in Paris. Best, Angelo (on behalf of the I-D authors) ---------- Forwarded message ---------- From: Date: Mon, Mar 12, 2012 at 14:40 Subject: New Version Notification for draft-castellani-core-http-mapping-03= .txt To: angelo@castellani.net Cc: salvatore.loreto@ericsson.com, akbar.rahman@interdigital.com, tho@koanlogic.com, esko.dijk@philips.com A new version of I-D, draft-castellani-core-http-mapping-03.txt has been successfully submitted by Angelo P. Castellani and posted to the IETF repository. Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-castellani-core-http-mapping Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A003 Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Best practices for HTTP-CoAP mapp= ing implementation Creation date: =C2=A0 2012-03-12 WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission Number of pages: 42 Abstract: =C2=A0 This draft aims at being a base reference documentation for HTTP-CoA= P =C2=A0 proxy implementors. =C2=A0It details deployment options, discusses =C2=A0 possible approaches for URI mapping, and provides useful =C2=A0 considerations related to protocol translation. The IETF Secretariat From Akbar.Rahman@InterDigital.com Wed Mar 14 11:46:06 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D95821F87EA for ; Wed, 14 Mar 2012 11:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.343, 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 a180ziaj0bA5 for ; Wed, 14 Mar 2012 11:46:05 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1503B21F87EE for ; Wed, 14 Mar 2012 11:46:04 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Mar 2012 14:46:04 -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: Wed, 14 Mar 2012 14:46:03 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] #177: Response suppression for multicast not defined Thread-Index: Ac0Ahv055FqR9pvuT5ivsq9FGMaUawAANcmAAGJW/IA= References: <051.f2c70308ab0d71f7798afa515a549f6b@trac.tools.ietf.org><066.924a528dfa41671c33a7c32467afea34@trac.tools.ietf.org> From: "Rahman, Akbar" To: "Zach Shelby" X-OriginalArrivalTime: 14 Mar 2012 18:46:04.0335 (UTC) FILETIME=[B59E9BF0:01CD0212] Cc: core issue tracker , core WG Subject: Re: [core] #177: Response suppression for multicast not defined X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 14 Mar 2012 18:46:06 -0000 Hi Zach, Thanks, I read coap-09 and saw the new text for multicast response handling in section 4.5. One follow up question: - If the multicast message receivers (servers) do send back valid responses (e.g. successful Response to a GET), then the original sender (or some intermediate CoAP proxy) will receive multiple responses and will have to some method of filtering and processing the multiple responses. - We show one possible use case in=20 http://tools.ietf.org/html/draft-ietf-core-groupcomm-01#page-17 - Should we have some text in coap-09 to cover this multiple response processing as well? Akbar -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Rahman, Akbar Sent: Monday, March 12, 2012 3:42 PM To: Zach Shelby Cc: core issue tracker; core WG Subject: Re: [core] #177: Response suppression for multicast not defined Thanks, Zach. I will then make sure to read the updated I-D after you submit it tonight. Esko and I have some text in our Groupcomm I-D for multicast support (on the topic of multicast response handling) that we want to make sure is well coordinated with the coap-09 I-D. Akbar -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com]=20 Sent: Monday, March 12, 2012 3:33 PM To: Rahman, Akbar Cc: core issue tracker; core WG Subject: Re: [core] #177: Response suppression for multicast not defined Hi Akbar, These changes are being checked into the SVN as they are closed, and will show up in the coap-09 submission tonight. By the way, the SVN is accessible by anyone if you are ever interested in changes as we close tickets on WG documents: http://trac.tools.ietf.org/wg/core/trac/browser Zach On Mar 12, 2012, at 8:40 PM, Rahman, Akbar wrote: > Hi Carsten, >=20 >=20 > Could you please clarify exactly what change was incorporated into http://tools.ietf.org/html/draft-ietf-core-coap-08? >=20 > When I look at the Fix #177 cited below=20 >=20 > http://www.ietf.org/mail-archive/web/core/current/msg02382.html >=20 > it refers to=20 >=20 > "So yes, I think there should be new text in 4.4 that says the reliability > layer does indicate to the r/r layer that this was a multicast." >=20 >=20 > I did not see this type of text in section 4.4 however. But maybe I a m missing something? >=20 >=20 >=20 > Thanks, >=20 >=20 > Akbar >=20 >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of core issue tracker > Sent: Monday, March 12, 2012 12:25 PM > To: draft-ietf-core-coap@tools.ietf.org; cabo@tzi.org > Cc: core@ietf.org > Subject: Re: [core] #177: Response suppression for multicast not defined >=20 > #177: Response suppression for multicast not defined >=20 > Changes (by cabo@...): >=20 > * status: new =3D> closed > * resolution: =3D> fixed >=20 >=20 > Comment: >=20 > Fixed in [524]: >=20 > Fix #177 >=20 > --=20 > --------------------------------+------------------------------------- > Reporter: cabo@... | Owner: draft-ietf-core-coap@... > Type: protocol defect | Status: closed > Priority: major | Milestone: > Component: coap | Version: > Severity: Active WG Document | Resolution: fixed > Keywords: | > --------------------------------+------------------------------------- >=20 > Ticket URL: > core >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Wed Mar 14 12:07:26 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1F621F8833 for ; Wed, 14 Mar 2012 12:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.122 X-Spam-Level: X-Spam-Status: No, score=-106.122 tagged_above=-999 required=5 tests=[AWL=0.127, 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 boWjOuySEOQh for ; Wed, 14 Mar 2012 12:07:25 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 86D9221F8821 for ; Wed, 14 Mar 2012 12:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2EJ75Ek000243; Wed, 14 Mar 2012 20:07:06 +0100 (CET) Received: from [10.0.1.3] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id ADAE4A58; Wed, 14 Mar 2012 20:07:05 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 14 Mar 2012 20:07:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <051.f2c70308ab0d71f7798afa515a549f6b@trac.tools.ietf.org><066.924a528dfa41671c33a7c32467afea34@trac.tools.ietf.org> To: "Rahman, Akbar" X-Mailer: Apple Mail (2.1257) Cc: core issue tracker , core WG Subject: Re: [core] #177: Response suppression for multicast not defined X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 14 Mar 2012 19:07:26 -0000 > Thanks, I read coap-09 and saw the new text for multicast response > handling in section 4.5. One follow up question: >=20 >=20 > - If the multicast message receivers (servers) do send back valid > responses (e.g. successful Response to a GET), then the original = sender > (or some intermediate CoAP proxy) will receive multiple responses and > will have to some method of filtering and processing the multiple > responses. That is the nature of multicast, so I would expect the need for that to = be obvious. We do not specify local processing, so what exactly the client does with = the information is up to the implementer. > - We show one possible use case in=20 >=20 > http://tools.ietf.org/html/draft-ietf-core-groupcomm-01#page-17 Indeed, but generally the core-coap draft is very sparse on use cases. > - Should we have some text in coap-09 to cover this multiple response > processing as well? So, in summary, I do not see a need for additions to core-coap. Gr=FC=DFe, Carsten From Markus.Isomaki@nokia.com Wed Mar 14 14:20:20 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCB821F8865 for ; Wed, 14 Mar 2012 14:20:20 -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 m+aRRlqaposY for ; Wed, 14 Mar 2012 14:20:19 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 79A5A21F8864 for ; Wed, 14 Mar 2012 14:20:19 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q2ELJuJ2018623 for ; Wed, 14 Mar 2012 23:20:18 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Mar 2012 23:20:15 +0200 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.120]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0355.003; Wed, 14 Mar 2012 22:20:15 +0100 From: To: Thread-Topic: New Version Notification for draft-nieminen-core-service-discovery-02.txt Thread-Index: Ac0CJxSJcrLNbnt+TYmbXNI1Rc750g== Date: Wed, 14 Mar 2012 21:20:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.114.24.166] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 14 Mar 2012 21:20:15.0581 (UTC) FILETIME=[3FCAB8D0:01CD0228] X-Nokia-AV: Clean Subject: [core] FW: New Version Notification for draft-nieminen-core-service-discovery-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, 14 Mar 2012 21:20:20 -0000 SGkgYWxsLA0KDQpXZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIENvQVAgYXBwbGlj YXRpb24gYXV0b2NvbmZpZ3VyYXRpb24gZHJhZnQ6IA0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1uaWVtaW5lbi1jb3JlLXNlcnZpY2UtZGlzY292ZXJ5Lw0KDQpJdCBwcm9w b3NlcyBhIENvQVAgYmFzZWQgbWVjaGFuaXNtIGZvciBhIENvQVAgYXBwbGljYXRpb24gdG8gZGlz Y292ZXIgYW5kIHJldHJpZXZlIGl0cyBjb25maWd1cmF0aW9uLiAgQXQgbWluaW11bSBtb3N0IENv QVAgYXBwcyB3aWxsIHJlcXVpcmUga25vd2xlZGdlIG9mIGEgVVJJIG9mIHRoZSBzZXJ2ZXIgdG8g dXNlLCBidXQgdGhleSBtYXkgYWxzbyBuZWVkIGNyZWRlbnRpYWxzLiBUaGUgZHJhZnQgaGFzIGlz IGEgbWFqb3IgcmV3cml0ZSBjb21wYXJlZCB0byB0aGUgcHJldmlvdXMgdmVyc2lvbnMsIHNvIHlv dSBzaG91bGQgcmVhZCBpdCBhZ2FpbiBldmVuIGlmIHlvdSBoYXZlIGNoZWNrZWQgLTAwIG9yIC0w MSA6LSkNCg0KUGxlYXNlIHJldmlldy4gSSBob3BlIHRoZXJlIGlzIHRpbWUgdG8gdGFsayBhYm91 dCB0aGlzIGF0IENvUkUgZHVyaW5nIElFVEYgODMuDQoNCk1hcmt1cw0KDQoNCj4NCj5GaWxlbmFt ZToJIGRyYWZ0LW5pZW1pbmVuLWNvcmUtc2VydmljZS1kaXNjb3ZlcnkNCj5SZXZpc2lvbjoJIDAy DQo+VGl0bGU6CQkgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gQXV0b2NvbmZpZ3VyYXRpb24NCj5D cmVhdGlvbiBkYXRlOgkgMjAxMi0wMy0xMg0KPldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lv bg0KPk51bWJlciBvZiBwYWdlczogMTMNCj4NCj5BYnN0cmFjdDoNCj4gICBUaGUgbnVtYmVyIGFu ZCB0eXBlcyBvZiBkZXZpY2VzIHRoYXQgYXJlIEludGVybmV0IGNvbm5lY3RlZCBjb250aW51ZXMN Cj4gICB0byBncm93LiAgU2Vuc29ycywgYXBwbGlhbmNlcywgdXRpbGl0eSBtZXRlcnMsIG1lZGlj YWwgZGV2aWNlcyBldGMuDQo+ICAgYXJlIEludGVybmV0IGNvbm5lY3RlZCBmb3IgdmFyaW91cyBy ZWFzb25zLiAgTWFueSBvZiB0aGVzZSBuZXdlcg0KPiAgIGRldmljZXMgYXJlIGNvbnN0cmFpbmVk IGluIHRlcm1zIG9mIHByb2Nlc3NpbmcgcG93ZXIsIG1lbW9yeSwNCj4gICBjb21tdW5pY2F0aW9u IGNhcGFiaWxpdHkgYW5kLCBhdmFpbGFibGUgcG93ZXIuICBEZXZpY2VzIHN1Y2ggYXMNCj4gICBz ZW5zb3JzIGFuZCBzaW1pbGFyIHZlcnkgc21hbGwgZGV2aWNlcyBvZnRlbiBsYWNrIGEgcHJvcGVy IHVzZXINCj4gICBpbnRlcmZhY2UgYW5kIGhlbmNlIGNvbmZpZ3VyaW5nIGV2ZW4gdGhlIG1vc3Qg YmFzaWMgcGFyYW1ldGVycyBmb3INCj4gICBlbmFibGluZyBJbnRlcm5ldCBjb25uZWN0aXZpdHkg b24gdGhlc2UgaXMgZXh0cmVtZWx5IGRpZmZpY3VsdC4gIFNvbWUNCj4gICBvZiB0aGUgZXhpc3Rp bmcgY29uZmlndXJhdGlvbiBwcm90b2NvbHMgY2FuIGhlbHAgaW4gYXV0b2NvbmZpZ3VyaW5nDQo+ ICAgdmFyaW91cyBwYXJhbWV0ZXJzIG9mIHRoZSBJUCBzdGFjayBuZWVkZWQgZm9yIEludGVybmV0 IGNvbm5lY3Rpdml0eS4NCj4gICBIb3dldmVyIHRoaXMgaXMgbm90IHN1ZmZpY2llbnQgaWYgdGhl IGRldmljZXMgYXJlIHVzaW5nIGEgd2ViIHNlcnZpY2UNCj4gICBhcHBsaWNhdGlvbi4gIFRoZXJl IGlzIGEgbmVlZCBmb3IgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBzdWNoIGFzDQo+ICAgc2Vydmlj ZSBwcm92aWRlciBuYW1lIGFuZCB1c2VybmFtZS9wYXNzd29yZCBldGMuIGZvciBhdXRoZW50aWNh dGlvbg0KPiAgIGV0Yy4gIEEgY29uZmlndXJhdGlvbiBwcm90b2NvbCBzb2x1dGlvbiBmb3IgcmVz b3VyY2UgY29uc3RyYWluZWQNCj4gICBkZXZpY2VzIGlzIG5lZWRlZCBpbiBvcmRlciB0byBlbmFi bGUgdGhlIHBvdGVudGlhbCBlbmFibGVkIGJ5DQo+ICAgSW50ZXJuZXQgY29ubmVjdGl2aXR5LiAg VGhpcyBkb2N1bWVudCBvdXRsaW5lcyB0aGUgdXNlIGNhc2VzIGFuZA0KPiAgIHJlcXVpcmVtZW50 cyBmb3IgdXNlciBmcmllbmRseSBjb25maWd1cmF0aW9uIG9mIHN1Y2ggaW5mb3JtYXRpb24gb24g YQ0KPiAgIGNvbnN0cmFpbmVkIGRldmljZSwgYW5kIHNwZWNpZmllcyBhIENvbnN0cmFpbmVkIEFw cGxpY2F0aW9uIFByb3RvY29sDQo+ICAgKENvQVApIGJhc2VkIG1lY2hhbmlzbSB0byBtZWV0IHRo ZSByZXF1aXJlbWVudHMuDQo+DQo= From cabo@tzi.org Wed Mar 14 15:48:58 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1DD11E8089 for ; Wed, 14 Mar 2012 15:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.425 X-Spam-Level: X-Spam-Status: No, score=-106.425 tagged_above=-999 required=5 tests=[AWL=-0.176, 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 T2lx0digK4i3 for ; Wed, 14 Mar 2012 15:48: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 A633411E8075 for ; Wed, 14 Mar 2012 15:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2EMmn55020546 for ; Wed, 14 Mar 2012 23:48:49 +0100 (CET) Received: from [192.168.217.105] (p5489B3CC.dip.t-dialin.net [84.137.179.204]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F050EACB; Wed, 14 Mar 2012 23:48:48 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Mar 2012 23:48:47 +0100 To: core WG Message-Id: <16BC0348-5BDA-4628-AF9A-BC4E95614E66@tzi.org> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [core] IETF 83 CoRE agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 14 Mar 2012 22:48:58 -0000 I have uploaded a first draft of the CoRE agenda for Paris: http://www.ietf.org/proceedings/83/agenda/agenda-83-core.txt We have over 20 drafts on the plate, and even with the 300 minutes total = of meeting time we have this time, this will be tough. So we may have = to do some of the work in bars and hallways. (I'm sure a lot of careful = deliberation on the four most advanced documents will also happen on = Saturday/Sunday during the ETSI plugfest.) Everybody who wants to make use of a CoRE slot in Paris, please send me = objectives like the ones the more fleshed-out slots already have. We may also try to spill over some drafts to LWIG (with apologies to the = LWIG chairs), so we may be able to discuss e.g. = draft-hartke-core-codtls-01.txt there. Comments and additions are welcome! Gr=FC=DFe, Carsten PS.: A heads up to the presenters: Because of the large = non-english-speaking audience, and because we need the freedom to push = around items at the last minute, I need all slides on Friday, March 23. = Of course, as usual you can make changes up to an hour before the = meeting, but the Friday version should be feature-complete. From peter.van.der.stok@philips.com Thu Mar 15 01:06:25 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057E721F8638 for ; Thu, 15 Mar 2012 01:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.348 X-Spam-Level: X-Spam-Status: No, score=-4.348 tagged_above=-999 required=5 tests=[AWL=-0.749, 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 8ec0AzFsr2aA for ; Thu, 15 Mar 2012 01:06:23 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id DF11421F8637 for ; Thu, 15 Mar 2012 01:06:20 -0700 (PDT) Received: from mail49-db3-R.bigfish.com (10.3.81.245) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 15 Mar 2012 08:06:21 +0000 Received: from mail49-db3 (localhost [127.0.0.1]) by mail49-db3-R.bigfish.com (Postfix) with ESMTP id C903C100543; Thu, 15 Mar 2012 08:06:20 +0000 (UTC) X-SpamScore: -40 X-BigFish: VPS-40(zz217bL15d6O9251Jc89bh542M1a09Jzz1202hzz1033IL8275dhz2dh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail49-db3 (localhost.localdomain [127.0.0.1]) by mail49-db3 (MessageSwitch) id 133179877961260_8251; Thu, 15 Mar 2012 08:06:19 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.235]) by mail49-db3.bigfish.com (Postfix) with ESMTP id 02216380052; Thu, 15 Mar 2012 08:06:19 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 15 Mar 2012 08:06:19 +0000 Received: from 011-DB3MMR1-021.MGDPHG.emi.philips.com (10.128.28.103) by 011-DB3MMR1-005.MGDPHG.emi.philips.com (10.128.28.55) with Microsoft SMTP Server (TLS) id 14.1.355.3; Thu, 15 Mar 2012 08:08:24 +0000 Received: from 011-DB3MPN1-061.MGDPHG.emi.philips.com ([169.254.1.139]) by 011-DB3MMR1-021.MGDPHG.emi.philips.com ([fe80::f066:9203:e7da:3658%11]) with mapi id 14.01.0355.003; Thu, 15 Mar 2012 08:08:24 +0000 From: "Stok, Peter van der" To: Carsten Bormann , core WG Thread-Topic: [core] IETF 83 CoRE agenda Thread-Index: AQHNAjTzutQW0dCyFU27i4pNNccoHZZq/2OA Date: Thu, 15 Mar 2012 08:08:24 +0000 Message-ID: References: <16BC0348-5BDA-4628-AF9A-BC4E95614E66@tzi.org> In-Reply-To: <16BC0348-5BDA-4628-AF9A-BC4E95614E66@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.102] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] IETF 83 CoRE agenda X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 15 Mar 2012 08:06:25 -0000 Hi Carsten, I would like a slot to present the vanderstok-dna draft. Objectives: Introduce discovery requirements, especially with respect to groups Introduce solutions using DNS-SD and RD to satisfy these requirements. Many thanks, peter -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Car= sten Bormann Sent: Wednesday 14 March 2012 23:49 To: core WG Subject: [core] IETF 83 CoRE agenda I have uploaded a first draft of the CoRE agenda for Paris: http://www.ietf.org/proceedings/83/agenda/agenda-83-core.txt We have over 20 drafts on the plate, and even with the 300 minutes total of= meeting time we have this time, this will be tough. So we may have to do = some of the work in bars and hallways. (I'm sure a lot of careful deliberat= ion on the four most advanced documents will also happen on Saturday/Sunday= during the ETSI plugfest.) Everybody who wants to make use of a CoRE slot in Paris, please send me obj= ectives like the ones the more fleshed-out slots already have. We may also try to spill over some drafts to LWIG (with apologies to the LW= IG chairs), so we may be able to discuss e.g. draft-hartke-core-codtls-01.t= xt there. Comments and additions are welcome! Gr=FC=DFe, Carsten PS.: A heads up to the presenters: Because of the large non-english-speakin= g audience, and because we need the freedom to push around items at the las= t minute, I need all slides on Friday, March 23. Of course, as usual you c= an make changes up to an hour before the meeting, but the Friday version sh= ould be feature-complete. _______________________________________________ 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 prvs=2421D579C1=guido.moritz@uni-rostock.de Thu Mar 15 02:40:10 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E575D21F8685 for ; Thu, 15 Mar 2012 02:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 aGoyjrcYcDBg for ; Thu, 15 Mar 2012 02:40:10 -0700 (PDT) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB7121F866E for ; Thu, 15 Mar 2012 02:40:10 -0700 (PDT) From: Guido Moritz To: 'core' Date: Thu, 15 Mar 2012 10:40:09 +0100 Message-ID: <001801cd028f$9cce0a20$d66a1e60$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0CjtieSSb6HX2/TFaeC6NFnGOoYQ== Content-Language: de X-Originating-IP: [139.30.201.226] Subject: [core] CoAP over TCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 15 Mar 2012 09:40:11 -0000 Dear WG, as stated in the current CoAP draft TCP as transport is out of scope. Nevertheless, has anybody ever tried to use CoAP over TCP? We would be very interested in the experiences and problems! We have to use CoAP over TCP, because TCP and TLS are required by a specific security profile we are implementing. The security profile is independent from CoAP itself, but TCP and TLS are mandatory. So what we are trying to realize is a persistent TCP connection to have the handshakes etc. only one time at the startup of the connection. At a first glance, the major issue we identified is the missing length information for the packet size when using TCP instead of UDP. The solutions we came up with are either (1) a new length option for CoAP similar to HTTP or (2) use blocking to indicate if for this request more payload will be send or if this is the last packet. At (2) we are not sure if a sender can indicate for small payload which fits into one packet that the first block is also the last. Has anybody on the list comments or further experiences. It might already have been discussed somewhere, but then I have missed this discussion. Regards, Guido From esko.dijk@philips.com Thu Mar 15 02:51:32 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4D421F86C5 for ; Thu, 15 Mar 2012 02:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.974 X-Spam-Level: X-Spam-Status: No, score=-3.974 tagged_above=-999 required=5 tests=[AWL=-0.375, 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 hwE2vhIAQJj5 for ; Thu, 15 Mar 2012 02:51:31 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 689B821F86B1 for ; Thu, 15 Mar 2012 02:51:31 -0700 (PDT) Received: from mail79-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.23; Thu, 15 Mar 2012 09:51:31 +0000 Received: from mail79-ch1 (localhost [127.0.0.1]) by mail79-ch1-R.bigfish.com (Postfix) with ESMTP id AA0A64E0171; Thu, 15 Mar 2012 09:51:31 +0000 (UTC) X-SpamScore: -45 X-BigFish: VPS-45(zz217bL15d6O9251Jc89bh542M1432N4015Izz1202hzz1033IL8275dhz2dh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail79-ch1 (localhost.localdomain [127.0.0.1]) by mail79-ch1 (MessageSwitch) id 1331805089225991_4926; Thu, 15 Mar 2012 09:51:29 +0000 (UTC) Received: from CH1EHSMHS018.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail79-ch1.bigfish.com (Postfix) with ESMTP id 32C25160046; Thu, 15 Mar 2012 09:51:29 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 15 Mar 2012 09:51:29 +0000 Received: from 011-DB3MMR1-019.MGDPHG.emi.philips.com (10.128.28.106) by 011-DB3MMR1-003.MGDPHG.emi.philips.com (10.128.28.53) with Microsoft SMTP Server (TLS) id 14.1.355.3; Thu, 15 Mar 2012 09:53:34 +0000 Received: from 011-DB3MPN1-014.MGDPHG.emi.philips.com ([169.254.4.162]) by 011-DB3MMR1-019.MGDPHG.emi.philips.com ([10.128.28.106]) with mapi id 14.01.0355.003; Thu, 15 Mar 2012 09:53:34 +0000 From: "Dijk, Esko" To: Carsten Bormann , "Rahman, Akbar" Thread-Topic: [core] #177: Response suppression for multicast not defined Thread-Index: AQHNAG0eoEYfT91CQkeVkNJXPFXbn5Zm/j+AgAAOwgCAAAJygIADFRyAgAAF4ICAAOrNMA== Date: Thu, 15 Mar 2012 09:53:33 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED61807B94B@011-DB3MPN1-014.MGDPHG.emi.philips.com> References: <051.f2c70308ab0d71f7798afa515a549f6b@trac.tools.ietf.org><066.924a528dfa41671c33a7c32467afea34@trac.tools.ietf.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: core WG Subject: Re: [core] #177: Response suppression for multicast not defined X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 15 Mar 2012 09:51:32 -0000 What is not explicit in core-coap is how a CoAP proxy sends multicast respo= nses back to a client (that used the Proxy-URI option), and hence what a cl= ient should expect to get back from the proxy. Maybe the general idea is ob= vious: proxy does not perform any processing/filtering/aggregation but send= s back the individual responses to the client. One remaining question; what if a client sends a unicast CON request to a C= oAP proxy containing the Proxy-URI option, and then receives from the proxy= multiple responses resulting from the CoAP multicast. Would it get NON res= ponses from the proxy, or CON, or is that up to the implementation? NON wou= ld be preferable for congestion control reasons but this is not explicitly = mandated by core-coap. CON would be logical if the aim of the proxy is to r= eply CON to a CON proxy-request following section 5.2.3. It could also be l= eft as an implementation decision. (Without any extra guiding text, my gues= s would be that it becomes implementation-specific behaviour.) Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Car= sten Bormann Sent: Wednesday 14 March 2012 20:07 To: Rahman, Akbar Cc: core issue tracker; core WG Subject: Re: [core] #177: Response suppression for multicast not defined > Thanks, I read coap-09 and saw the new text for multicast response > handling in section 4.5. One follow up question: > > > - If the multicast message receivers (servers) do send back valid > responses (e.g. successful Response to a GET), then the original sender > (or some intermediate CoAP proxy) will receive multiple responses and > will have to some method of filtering and processing the multiple > responses. That is the nature of multicast, so I would expect the need for that to be = obvious. We do not specify local processing, so what exactly the client does with th= e information is up to the implementer. > - We show one possible use case in > > http://tools.ietf.org/html/draft-ietf-core-groupcomm-01#page-17 Indeed, but generally the core-coap draft is very sparse on use cases. > - Should we have some text in coap-09 to cover this multiple response > processing as well? So, in summary, I do not see a need for additions to core-coap. Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From cabo@tzi.org Thu Mar 15 02:54:11 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA4A21F84CE for ; Thu, 15 Mar 2012 02:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.42 X-Spam-Level: X-Spam-Status: No, score=-106.42 tagged_above=-999 required=5 tests=[AWL=-0.171, 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 E61-aD1U-FH7 for ; Thu, 15 Mar 2012 02:54:10 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4270321F84B5 for ; Thu, 15 Mar 2012 02:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2F9s224019877; Thu, 15 Mar 2012 10:54:02 +0100 (CET) Received: from [192.168.217.105] (p5489B3CC.dip.t-dialin.net [84.137.179.204]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 74DC6C33; Thu, 15 Mar 2012 10:54:02 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <001801cd028f$9cce0a20$d66a1e60$@uni-rostock.de> Date: Thu, 15 Mar 2012 10:54:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <001801cd028f$9cce0a20$d66a1e60$@uni-rostock.de> To: Guido Moritz X-Mailer: Apple Mail (2.1257) Cc: 'core' Subject: Re: [core] CoAP over TCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 15 Mar 2012 09:54:11 -0000 On Mar 15, 2012, at 10:40, Guido Moritz wrote: > Dear WG, >=20 > as stated in the current CoAP draft TCP as transport is out of scope. > Nevertheless, has anybody ever tried to use CoAP over TCP? We would be = very > interested in the experiences and problems! We never said that aloud, but in designing CoAP we have paid specific = attention to making sure it works well over TCP. There are lots of applications where intermediaries can talk to each = other over a nice flow-/congestion-controlled, auto-aggregating = transport much better than over a stream of UDP packets. > At a first glance, the major issue we identified is the missing length > information for the packet size when using TCP instead of UDP. The = solutions > we came up with are either (1) a new length option for CoAP similar to = HTTP > or (2) use blocking to indicate if for this request more payload will = be > send or if this is the last packet. At (2) we are not sure if a sender = can > indicate for small payload which fits into one packet that the first = block > is also the last. Essentially, you don't need the MID, because TCP already takes care of = ACKs and duplicate detection. So you can steal the field for a length = field. (Or add a new one. There is no need for the TCP header to look = exactly the same as the UDP 4-byte header.) That little piece of design should be done at an appropriate time. Klaus, I think we may need to write up the TCP header format... Guido: To minimize confusion, can we wait for that until after the WGLC = of the current documents? :-) Gr=FC=DFe, Carsten From cabo@tzi.org Thu Mar 15 02:58:02 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D0B21F86CB for ; Thu, 15 Mar 2012 02:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.416 X-Spam-Level: X-Spam-Status: No, score=-106.416 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 eyhYQOWSuuu0 for ; Thu, 15 Mar 2012 02:58: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 5456A21F86C7 for ; Thu, 15 Mar 2012 02:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2F9voY4021811; Thu, 15 Mar 2012 10:57:50 +0100 (CET) Received: from [192.168.217.105] (p5489B3CC.dip.t-dialin.net [84.137.179.204]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3738CC40; Thu, 15 Mar 2012 10:57:50 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED61807B94B@011-DB3MPN1-014.MGDPHG.emi.philips.com> Date: Thu, 15 Mar 2012 10:57:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8E700EA5-2C41-43B0-8600-D59C8555867C@tzi.org> References: <051.f2c70308ab0d71f7798afa515a549f6b@trac.tools.ietf.org><066.924a528dfa41671c33a7c32467afea34@trac.tools.ietf.org> <031DD135F9160444ABBE3B0C36CED61807B94B@011-DB3MPN1-014.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1257) Cc: core WG Subject: Re: [core] #177: Response suppression for multicast not defined X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 15 Mar 2012 09:58:02 -0000 On Mar 15, 2012, at 10:53, Dijk, Esko wrote: > What is not explicit in core-coap is how a CoAP proxy sends multicast = responses back to a client (that used the Proxy-URI option), and hence = what a client should expect to get back from the proxy. Maybe the = general idea is obvious: proxy does not perform any = processing/filtering/aggregation but sends back the individual responses = to the client. I don't think we want to constrain what intermediaries do here before = gaining more experience with this. > One remaining question; what if a client sends a unicast CON request = to a CoAP proxy containing the Proxy-URI option, and then receives from = the proxy multiple responses resulting from the CoAP multicast. Would it = get NON responses from the proxy, or CON, or is that up to the = implementation? Right. Again, we have not constrained it, and I think that is the right = decision. > NON would be preferable for congestion control reasons Actually, (at least partially using) CON would enable getting some = congestion control feedback. With NON, you send into thin air. > but this is not explicitly mandated by core-coap. CON would be logical = if the aim of the proxy is to reply CON to a CON proxy-request following = section 5.2.3. It could also be left as an implementation decision. = (Without any extra guiding text, my guess would be that it becomes = implementation-specific behavior.) Yes, and I think at this stage that is fine. Gr=FC=DFe, Carsten From prvs=3421463D27=guido.moritz@uni-rostock.de Thu Mar 15 03:01:44 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5EA21F86CE for ; Thu, 15 Mar 2012 03:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.717 X-Spam-Level: X-Spam-Status: No, score=-2.717 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 XK465AbcbCd4 for ; Thu, 15 Mar 2012 03:01:43 -0700 (PDT) Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 5979821F86CB for ; Thu, 15 Mar 2012 03:01:43 -0700 (PDT) From: Guido Moritz To: 'Carsten Bormann' References: <001801cd028f$9cce0a20$d66a1e60$@uni-rostock.de> In-Reply-To: Date: Thu, 15 Mar 2012 11:01:40 +0100 Message-ID: <001d01cd0292$9e3708a0$daa519e0$@uni-rostock.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHVRFnonvmUbEKPOSqVYGCvWCLATQKgjZNPlkWXf2A= Content-Language: de X-Originating-IP: [139.30.201.226] Cc: 'core' Subject: Re: [core] CoAP over TCP X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 15 Mar 2012 10:01:44 -0000 Thanks for the fast reply. Of course, we can wait. But I am happy that = this issue already has been taken care of.=20 See you in Paris, Guido > -----Urspr=FCngliche Nachricht----- > Von: Carsten Bormann [mailto:cabo@tzi.org] > Gesendet: Donnerstag, 15. M=E4rz 2012 10:54 > An: Guido Moritz > Cc: 'core' > Betreff: Re: [core] CoAP over TCP >=20 >=20 > On Mar 15, 2012, at 10:40, Guido Moritz wrote: >=20 > > Dear WG, > > > > as stated in the current CoAP draft TCP as transport is out of = scope. > > Nevertheless, has anybody ever tried to use CoAP over TCP? We would = be > very > > interested in the experiences and problems! >=20 > We never said that aloud, but in designing CoAP we have paid specific attention > to making sure it works well over TCP. >=20 > There are lots of applications where intermediaries can talk to each = other over > a nice flow-/congestion-controlled, auto-aggregating transport much = better > than over a stream of UDP packets. >=20 > > At a first glance, the major issue we identified is the missing = length > > information for the packet size when using TCP instead of UDP. The solutions > > we came up with are either (1) a new length option for CoAP similar = to HTTP > > or (2) use blocking to indicate if for this request more payload = will be > > send or if this is the last packet. At (2) we are not sure if a = sender can > > indicate for small payload which fits into one packet that the first block > > is also the last. >=20 > Essentially, you don't need the MID, because TCP already takes care of ACKs > and duplicate detection. So you can steal the field for a length = field. (Or add a > new one. There is no need for the TCP header to look exactly the same = as the > UDP 4-byte header.) > That little piece of design should be done at an appropriate time. >=20 > Klaus, I think we may need to write up the TCP header format... > Guido: To minimize confusion, can we wait for that until after the = WGLC of the > current documents? :-) >=20 > Gr=FC=DFe, Carsten From Akbar.Rahman@InterDigital.com Thu Mar 15 12:50:13 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1769921F8587 for ; Thu, 15 Mar 2012 12:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=0.286, 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 kRszCq6vkSiN for ; Thu, 15 Mar 2012 12:50:12 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7833221F857F for ; Thu, 15 Mar 2012 12:50:12 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Mar 2012 15:50:11 -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: Thu, 15 Mar 2012 15:50:10 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] #177: Response suppression for multicast not defined Thread-Index: Ac0CFbNEXbbMNBN1RmmmoOdaqqIAAQAzk4uw References: <051.f2c70308ab0d71f7798afa515a549f6b@trac.tools.ietf.org><066.924a528dfa41671c33a7c32467afea34@trac.tools.ietf.org> From: "Rahman, Akbar" To: "Carsten Bormann" X-OriginalArrivalTime: 15 Mar 2012 19:50:11.0135 (UTC) FILETIME=[D4E774F0:01CD02E4] Cc: core issue tracker , core WG Subject: Re: [core] #177: Response suppression for multicast not defined X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 15 Mar 2012 19:50:13 -0000 Carsten, Can you clarify what you mean by "We do not specify local processing = ..."?=20 I do not follow your logic. For example, in coap-09 there is clearly = specification language for local caching = (http://tools.ietf.org/html/draft-ietf-core-coap-09#section-5.6). So = what did you really mean? Akbar -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: Wednesday, March 14, 2012 3:07 PM To: Rahman, Akbar Cc: Zach Shelby; core issue tracker; core WG Subject: Re: [core] #177: Response suppression for multicast not defined > Thanks, I read coap-09 and saw the new text for multicast response > handling in section 4.5. One follow up question: >=20 >=20 > - If the multicast message receivers (servers) do send back valid > responses (e.g. successful Response to a GET), then the original = sender > (or some intermediate CoAP proxy) will receive multiple responses and > will have to some method of filtering and processing the multiple > responses. That is the nature of multicast, so I would expect the need for that to = be obvious. We do not specify local processing, so what exactly the client does with = the information is up to the implementer. > - We show one possible use case in=20 >=20 > http://tools.ietf.org/html/draft-ietf-core-groupcomm-01#page-17 Indeed, but generally the core-coap draft is very sparse on use cases. > - Should we have some text in coap-09 to cover this multiple response > processing as well? So, in summary, I do not see a need for additions to core-coap. Gr=FC=DFe, Carsten From zach@sensinode.com Fri Mar 16 04:04:13 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB66421F85A4 for ; Fri, 16 Mar 2012 04:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.65 X-Spam-Level: X-Spam-Status: No, score=-3.65 tagged_above=-999 required=5 tests=[AWL=-0.051, 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 VltVtf6COKXQ for ; Fri, 16 Mar 2012 04:04:12 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 7729C21F854B for ; Fri, 16 Mar 2012 04:04:12 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q2GB4ANQ030257 for ; Fri, 16 Mar 2012 13:04:10 +0200 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Mar 2012 13:04:09 +0200 Message-Id: <0D26A5A2-3DF5-4D88-841B-40A9E733B632@sensinode.com> To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] The IPSO Profile X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 16 Mar 2012 11:04:14 -0000 Hi, Over at the IPSO Alliance we have been developing a simple RESTful = profile for generic use between embedded devices as part of our = interoperability work. The first version of the profile is now = available for download here: http://www.ipso-alliance.org/downloads/The+IPSO+Profile I will be presenting the profile during the CoRE WG meeting, and we look = forward to comments and ideas from the IETF community as well. This = profile will be used as the basis of a multi-vendor IPSO interop and = demo event right after the IETF in Paris between real devices and web = applications using CoAP and HTTP. Although this first version has = focused on the needs of this interop event, we envision this evolving to = be a solution that compliments other application specific profiles like = SEP2.=20 Zach =20 =20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From fluffy@cisco.com Mon Mar 19 20:32:31 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4C221E805F for ; Mon, 19 Mar 2012 20:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.578 X-Spam-Level: X-Spam-Status: No, score=-108.578 tagged_above=-999 required=5 tests=[AWL=2.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yFNThe7j1cS for ; Mon, 19 Mar 2012 20:32:30 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9F221E804C for ; Mon, 19 Mar 2012 20:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2578; q=dns/txt; s=iport; t=1332214350; x=1333423950; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=GdZADWUtlk0S7JIRpySYOjyxpvSk1k8/uZUPGWMKedU=; b=BNB5rIhTQo4G4DZ1Qa0o1xPdY1vbC9qRWAIIaKGyiYByt+GVLKcpyrq6 /65PfaCXVQZ1lj+Qok/94zVUYv4m82WreSnQMJBptwxrJ+Er/rTI05Ls6 g2liCyDfBH08QT9/+KP7xutyTg1L2Tves35WAcLwTAJD/UunK/pqnWDW1 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At0GAKT5Z0+rRDoH/2dsb2JhbABBgw2zRIEHgiIBJ4F9NYdnlyyBJ58Uj35jBIhWjQmFbYhSgWiDBYE9 X-IronPort-AV: E=Sophos;i="4.73,616,1325462400"; d="scan'208";a="36823475" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 20 Mar 2012 03:32:30 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2K3WTxT007974 for ; Tue, 20 Mar 2012 03:32:29 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Mar 2012 21:32:29 -0600 Message-Id: <0701A114-EEA1-4080-998D-02EE94D60C02@cisco.com> To: core WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [core] WGLC of draft-ietf-core-observe-05 draft-ietf-core-block-08 and draft-ietf-core-coap-09 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 03:32:31 -0000 The chairs and authors hope that we are about done on = draft-ietf-core-observe-05, draft-ietf-core-block-08, and = draft-ietf-core-coap-09. The time has come to test that theory and see = if the WG agrees. Given we have three major drafts, as well as the IETF = meeting and various religious holidays, I am setting the Working Group = Last Call to end on midnight PDT on Monday, April 16.=20 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 a 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 board the review has = been.=20 I will note that no IPR declarations have been made on these drafts. If = you are aware of any patents 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 if you need to make a declaration = or not, please talk to me and I will help get you in touch with people = that can provide appropriate advice.=20 I would also like to take this opportunity to thank the authors and many = of the participants of this WG that have put in an incredibly amount of = energy to get us to this point. It's always a bit of a slog to get from = here to "done" on drafts but the easiest way to do that is with fast = review and fast turn around of revised drafts after the review. I'm sure = the chairs and authors will be pushing for that.=20 I'd like to implore people to actually go and review theses documents - = WGLC review is probably the single most important thing that a WG = participant can do. We need to get this right because stuff we miss now = can easily cause problems for a long time to come. The people that have = participated heavily in these drafts have read them so many times that = they have a hard time noticing what is wrong or missing from them but = fresh eyes can help. I know that everyone has many documents to read for = the upcoming IETF, but I'd like to try and convince you that reading = drafts that are in WGLC is probably more important than many others. = Please help us get these right.=20 Thank you, Cullen From trac+core@trac.tools.ietf.org Tue Mar 20 13:02:30 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EAB21F8646 for ; Tue, 20 Mar 2012 13:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KusEP5Jsva7w for ; Tue, 20 Mar 2012 13:02:30 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 41CA921F85CC for ; Tue, 20 Mar 2012 13:02:29 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SA5GF-0000xb-Me; Tue, 20 Mar 2012 16:02:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: zach@sensinode.com X-Trac-Project: core Date: Tue, 20 Mar 2012 20:02:26 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/193 Message-ID: <057.85cc43a26125e3187a3b9897d94973c5@trac.tools.ietf.org> X-Trac-Ticket-ID: 193 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: [core] #193: Anchor restriction for "hosts" relation 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, 20 Mar 2012 20:02:30 -0000 #193: Anchor restriction for "hosts" relation From the review of Richard Barnes, the suggestion was made to restrict the target URI of the link format to relative URIs when used with the "hosts" relation. In other words, the target and context URI must be on the same origin server for the "hosts" relation. This ticket is to add the following text to the end of the first paragraph of Section 2.2: "The target MUST be a relative URI of the context for this relation type." -- ----------------------------------+-------------------- Reporter: zach@… | Owner: zach@… Type: protocol enhancement | Status: new Priority: minor | Milestone: Component: link-format | Version: Severity: - | Keywords: ----------------------------------+-------------------- Ticket URL: core From alper.yegin@yegin.org Wed Mar 21 01:48:59 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F57521F8523 for ; Wed, 21 Mar 2012 01:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 7OM4cfu9kz9E for ; Wed, 21 Mar 2012 01:48:58 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id A045821F8466 for ; Wed, 21 Mar 2012 01:48:58 -0700 (PDT) Received: from [192.168.2.2] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0M93Mz-1S08jV1wHl-00D66p; Wed, 21 Mar 2012 04:48:46 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Alper Yegin In-Reply-To: <4994B756-515A-4B50-8445-F4DBDBBE00EE@tzi.org> Date: Wed, 21 Mar 2012 10:48:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <674287D1-C99A-45EE-9969-D0B35160056B@yegin.org> <7D669CE5-0F33-4163-A43B-E05589BE9892@tzi.org> <3615F3CCD55F054395A882F51C6E5FDA1824457B@szxeml513-mbs.china.huawei.com> <0B4B352D-3D32-4305-872F-853F26F5EDF8@tzi.org> <3615F3CCD55F054395A882F51C6E5FDA18248DD9@szxeml513-mbs.china.huawei.com> <4994B756-515A-4B50-8445-F4DBDBBE00EE@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1257) X-Provags-ID: V02:K0:NtwxY5WWG9OCZrljJo+avZ6uLRizriP4BfrVcAm+LD2 wbkCsjD/ZLLYGyn1xo+9iOLDis6dsTlvxZ7UJIj5aXvCwmPWiH ZnRkCAhgMSohdj8zhj73eGoqjaMq9K5Eco5zpLctLd/lYuGY74 PfBfrbKHrqNmhYiE0xn5zdYKJlXgP9scz0fpyeq5PK0OuzGX37 VQyWtN8XwZEIBfV3mIqK3qQX+gdbeqHn/4qt3znLjXFlFDHdM5 n7F/6jMVaCjpDamhDQtuQFJ9rTw09neY0hfEpRXmIa//Jv2Kq9 lPAPvIfjmocnl0mmyn2KnNDnOeYqixYcSBB1a0SpKZDsOfjEV/ h2wB2XZt6xTXzcyjEAMCmyFehL7t9r2W0CH43YsBCqyVuUXcnQ ECxbpLrlH5zcg== Cc: core WG Subject: Re: [core] Vendor-specific options X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 08:48:59 -0000 On Feb 8, 2012, at 1:45 PM, Carsten Bormann wrote: > On Feb 8, 2012, at 11:44, Zach Shelby wrote: >=20 >> Should something like that be added to the base spec, I am not sure. = If we are not in a hurry for it, then a separate specification in the = future is fine. >=20 > I think the interesting question is when are people going to need = these, For any vendor building products and any SDO intending to use this = protocol, the answer would always be "yesterday" :-) > and what is the danger that they will they go ahead and ship something = in a widely deployed product that will create a backwards compatibility = headache for us. >=20 > Defining the vendor-specific option in the base spec would enable us = to make very clear that squatting is not the way to go (by demonstrating = the right way to go). Keeping the option definition in coap-misc works = for me, but has two disadvantages: >=20 > 1) the details may not be vetted as well, possibly creating another = headache later, > 2) people might not find it, and/or may think what is in the personal = draft is not relevant for "conformance". >=20 > In any case, we need to agree on and reserve the option number (is 14 = it?), so we might as well standardize the option. >=20 > So far, the only thing I know that might need some more thought here = is my "SDNV of enterprise ID" tagging proposal. Putting option 14 into = the base spec might get us some more input on that :-) >=20 I support that. Alper > Gr=FC=DFe, Carsten >=20 From alper.yegin@yegin.org Wed Mar 21 02:22:54 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4268821F864F for ; Wed, 21 Mar 2012 02:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.43 X-Spam-Level: X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 CAjL2siQGXNx for ; Wed, 21 Mar 2012 02:22:53 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE5921F862F for ; Wed, 21 Mar 2012 02:22:53 -0700 (PDT) Received: from [192.168.2.2] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0LgaRJ-1SfmY91Qt3-00nd8i; Wed, 21 Mar 2012 05:22:52 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Alper Yegin In-Reply-To: <20120214114904.GA8794@blackbox> Date: Wed, 21 Mar 2012 11:22:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <55D88CC8-EF12-4A29-8476-E22F1470B855@yegin.org> References: <20120214114904.GA8794@blackbox> To: Johannes Gilger X-Mailer: Apple Mail (2.1257) X-Provags-ID: V02:K0:/tvjov9Vi64jHX3960vZb/aoXu42BDWOxIiMMM53MvZ J9LiYWkZQ9Hstri1Q+oAlLvA+Zr4DmgGoO4vjt3+GRt6H8xctH La+a2VGssk1W6VwVxakKY94j2/Ww4/UZ8C3PQJh3kVuGlo3l1Y iY55Zq1NjJypcKxaZCVxeWLonAl66g1+QKuNx8iThFD+J/s0wH NeMBgMLB8BsFDqDYOn0gZ+HZ2xS4pvojEc/jOx6EIYjJXVo4l/ GdzVyaG/7C+VxeTmCOzH01kYz0MnRNSalP6EXIFYWy2UxysgBh jFzsjGwH7UwW5GlBXwWwKlf6sumOa2olUdGAfLKl7aZzguFluw PQ3XDKJMsX2EZw7hpAbGARhbzxGxA8sO6GFZ5GvGUIlrsJ/Nn4 +ShSwLVTDXpDA== Cc: "core@ietf.org WG" Subject: Re: [core] RawPublicKeys X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 Mar 2012 09:22:54 -0000 Hi Johannes, Sorry for late response. Please see below. >=20 > On 17/11/11 17:22, Alper Yegin wrote: >> The above text explains how the network node authenticates/authorizes >> the device. But, how does the device authenticate/authorize the >> network node? For that, the "identity" of the network node's public >> key needs to be known to the device. But how? >=20 > In my understanding of the functionality of an interface-constrained = IoT > device, there is no need for the node to identify the network. I can understand "it's not possible", or "it's difficult". But I don't = understand how "there is no need." Device needs to know it's connected to the right "server"=20 (being right involves being authenticated and authorized, two really = separate things). > In fact, > there is no meaning behind any identity as far as the node is = concerned. >=20 > The only thing that matters is that the network can identify the node > (as has been discussed) and that the network can ensure that it is the > only one able to command the node. So, a rogue network can do that. "Identify" the victim device, and read = from it and write into it. This is obviously not acceptable. > This goes beyond what has been > discussed here, and I may be outside the topic, but it all boils down = to > the Resurrecting Duckling model [1]. >=20 >=20 >=20 > On 21/12/11 11:29, Alper Yegin wrote: >> The issue I'm raising is that, there story has two sides. We gotta be >> talking about not only how the network authorizes the device, but = also >> how the device authorizes the network. What you describe above is the >> former, latter one is missing. >>=20 >> It's not like the device will/shall be OK to talk to anyone who wants >> to talk to itself. Device needs to authenticate and authorize the >> other end as well, using ACLs etc.=20 >=20 > Why not? Looking at the Resurrecting Duckling again, the device will > talk to anyone when its in the "imprintable" state. After it has been > imprinted by an authority (hopefully the right one, or you'll have to > reset the device and try again), So, knowing the "right one" is the issue. Who's going to detect this is the wrong one and reset the device? The = user. We cannot assume user will detect and act upon it, if you consider the = wide range of IoT use cases. Users are rarely involved, especially in that capacity. Cheers, Alper > it will identify the network as the > party which holds the newly agreed symmetric key. >=20 >> How do we introduce the ACL into such devices? There's gotta be an >> interface for that. >=20 > The ACL is this: > - The symmetric key agreed with the first party to start imprinting = has > all the authority. > - The authority can add and modify the ACL (using in-band messages). >=20 >> Note that this is an issue for asymmetric-crypto. With the symmetric >> crypto, device can assume whoever holds the same PSK is already >> authorized hence I don't also need to maintain an ACL. Symmetric >> crypto has other issues though (e.g., how did you get the PSK here = and >> there?) >=20 > See above. After asymmetric crypto was used to establish a symmetric = key > (using DTLS with ECDHE_ECDSA), the symmetric key will be used and the > asymmetric key will only be needed again if the device is reset. >=20 > On 22/12/11 10:02, Alper Yegin wrote: >> Alper> I thought we were trying to solve the problem of "dealing with = interface-less devices".=20 >> Alper> Maybe we shall re-state the problem statement, if that's not = it. >=20 > I think this is what we should be talking about, in this or another > thread. >=20 > These are my thoughts, > would like to hear what you guys think, > Jojo >=20 >=20 > [1] - http://www.cl.cam.ac.uk/~fms27/duckling/ >=20 >=20 > --=20 > Dipl.-Inform. Johannes Gilger > Research Group IT-Security > UMIC Research Centre > RWTH Aachen University > Mies-van-der-Rohe-Stra=DFe 15 > 52074 Aachen >=20 > Office: 211 > Phone: +49 241 80 20781 > Fax: +49 241 80 22731 >=20 > http://itsec.rwth-aachen.de > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From gilger@umic.rwth-aachen.de Wed Mar 21 03:09:01 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6705B21F8599 for ; Wed, 21 Mar 2012 03:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.592 X-Spam-Level: X-Spam-Status: No, score=-1.592 tagged_above=-999 required=5 tests=[AWL=1.006, BAYES_00=-2.599, FUZZY_VLIUM=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61iShdEUbA32 for ; Wed, 21 Mar 2012 03:09:00 -0700 (PDT) Received: from avalon.gnuzifer.de (avalon.gnuzifer.de [IPv6:2a01:4f8:121:43c1::a2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E86021F853E for ; Wed, 21 Mar 2012 03:09:00 -0700 (PDT) Received: from [137.226.161.159] (port=43698 helo=localhost) by avalon.gnuzifer.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1SAITS-0000MV-3B; Wed, 21 Mar 2012 11:08:58 +0100 Date: Wed, 21 Mar 2012 11:09:01 +0100 From: Johannes Gilger To: Alper Yegin Message-ID: <20120321100901.GA15321@blackbox> References: <20120214114904.GA8794@blackbox> <55D88CC8-EF12-4A29-8476-E22F1470B855@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <55D88CC8-EF12-4A29-8476-E22F1470B855@yegin.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 137.226.161.159 X-SA-Exim-Mail-From: gilger@umic.rwth-aachen.de Cc: "core@ietf.org WG" Subject: Re: [core] RawPublicKeys X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 Mar 2012 10:09:01 -0000 Hello Alper, thanks for your comments. I'll try to explain the point I was making with the last mail. I do suspect my approaches to be naive, and would like to learn about scenarios where they fail. On 21/03/12 11:22, Alper Yegin wrote: >> In my understanding of the functionality of an interface-constrained IoT >> device, there is no need for the node to identify the network. > > I can understand "it's not possible", or "it's difficult". But I don't understand how "there is no need." > Device needs to know it's connected to the right "server" > (being right involves being authenticated and authorized, two really separate things). Yes, for some devices that is true. Lets take for example a plain lightbulb (with Smart Object capabilities) and a Smart Meter which is installed by a utility. The lightbulb has no owner until it is bought and taken from the shelf. The owner then wants to make sure that the lightbulb listens to him, and not to his neighbor. The lightbulb does not (and can not) care about "who" is switching it off and on, so long as it is the same person which first associated with it. For a Smart Meter, the relationship might look different on the surface. After all, a Smart Meter installed at at customers home should only talk to the correct utility. But then again, when the utility acquires the Smart Meter from the manufacturer, it could imprint and use it like a lightbulb, before installing it at the customer. >> The only thing that matters is that the network can identify the node >> (as has been discussed) and that the network can ensure that it is the >> only one able to command the node. > > So, a rogue network can do that. "Identify" the victim device, and read from it and write into it. > This is obviously not acceptable. The assumption here is that the Smart Object is in one of two global states: Imprintable or Imprinted. The rogue network can simply imprint itself in the Smart Object it if is able to reset the device or if it is "faster" than the legitimate operator for the first imprinting process. Both attack vectors can be controlled. If you buy a new lightbulb and it does not listen to you, you will reset it and try imprinting again. At some point you'll hopefully succeed (because your neighbor gave up). If you have imprinted a device and don't want it to be reset, you have to take measures to prevent just that, like mounting the device so its inaccesible or simply omitting a reset button. > > Why not? Looking at the Resurrecting Duckling again, the device will > > talk to anyone when its in the "imprintable" state. After it has been > > imprinted by an authority (hopefully the right one, or you'll have to > > reset the device and try again), > > So, knowing the "right one" is the issue. > Who's going to detect this is the wrong one and reset the device? The user. > We cannot assume user will detect and act upon it, if you consider the wide range of IoT use cases. > Users are rarely involved, especially in that capacity. I am not sure. What is probably clouding my judgement is that I know so few actual end-to-end real-world applications for Smart Objects, which I hope will change with the Smart Object Security workshop. Regards, Jojo -- Dipl.-Inform. Johannes Gilger Research Group IT-Security UMIC Research Centre RWTH Aachen University Mies-van-der-Rohe-Straße 15 52074 Aachen Office: 211 Phone: +49 241 80 20781 Fax: +49 241 80 22731 http://itsec.rwth-aachen.de From rstruik.ext@gmail.com Wed Mar 21 08:01:29 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E7021F86A7 for ; Wed, 21 Mar 2012 08:01:29 -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 4LPlm3Gs6a-a for ; Wed, 21 Mar 2012 08:01:28 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CD2D521F8732 for ; Wed, 21 Mar 2012 08:01:27 -0700 (PDT) Received: by iazz13 with SMTP id z13so1964975iaz.31 for ; Wed, 21 Mar 2012 08:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=X2m9Cl4fmMEuoTnajAkn9IDNsN1vbKzqdcfYpfD7Xgw=; b=fyBXpRUwdOKv2piBUAAXhXuv5CbW7+SmGTLUmCNrnF6KGVtows7lwg1vIl2oCcjdPK iKGIMzvvyD3Tx+xSSqErRoDY0gkATVMlpGsjFng73ZfSaME+YKTlO/TnDFaqf/Ozje5p SpYu/MJL05J7yAoiQY/Ou6az0r+e2rhwfThLHyooYL1T50MyyiJUjL5QmC9wH93uBEUv ntZHyrCaTspbM2noQR5RNvLl/IM+jOMPXorMS1WhPmcif6sBpYHCxNDNWMGcu2CnI/F2 +uEs3OsULsRGLPeoRiFqCmX2lO7Sd3YRa5uztijXuIkIoNbjpW91ieXAe6IxzWNTYeNq u68g== Received: by 10.50.149.131 with SMTP id ua3mr11952855igb.41.1332342087467; Wed, 21 Mar 2012 08:01:27 -0700 (PDT) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [72.138.181.246]) by mx.google.com with ESMTPS id ke7sm1853958igc.10.2012.03.21.08.01.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Mar 2012 08:01:26 -0700 (PDT) Message-ID: <4F69ED25.6010705@gmail.com> Date: Wed, 21 Mar 2012 11:00:53 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Johannes Gilger References: <20120214114904.GA8794@blackbox> <55D88CC8-EF12-4A29-8476-E22F1470B855@yegin.org> <20120321100901.GA15321@blackbox> In-Reply-To: <20120321100901.GA15321@blackbox> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "core@ietf.org WG" Subject: Re: [core] RawPublicKeys X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 Mar 2012 15:01:29 -0000 Hi Johannes: Provisioning usually involves both authentication and authorization. Cryptography takes care of the authentication aspects and would result in evidence to each of the devices involved (imprinter, imprinted) of each other's identity {in case authentication would involve an authenticated public-key key agreement scheme). Authorization can be dealt with via cryptographic tools only if the authentication protocol would include exchange of credentials from which authorization privileges can be inferred (e.g., via incoding hereof in policy attributes of a certificate). For large scale networks, this is inflexible, since this requires coordination beforehand. The more likely scenario would be to have some human decision element here, who influences authorization decisions, e.g., via (1) location-limited channel {Diana Smetters et al}: here, only devices in close proximity would successfully complete the protocol, the idea being that the user can control devices lingering around close to devices in play; (2) mechanism for communicating by device of true id of the other device it communicated with, e.g., via display, beep pattern, light flashes {by bulb in question}, etc., followed by ack/nak by human (the infamous button-push scenario); (3) etc. Reset of a device to initial state is a transition in the trust lifecycle of device and should be managed accordingly. As an example, pressing a tiny reset button (similar to the one on my Wifi router at home) may not provoke this reset, if my state machine transition is triggered by more than just physical access to the device and would require, e.g., receipt of a properly formatted command to reset from an authorized device (i.e., one with the proper device role privileges) as well (or by the latter only). We can discuss more Friday. Best regards, Rene == The assumption here is that the Smart Object is in one of two global states: Imprintable or Imprinted. The rogue network can simply imprint itself in the Smart Object it if is able to reset the device or if it is "faster" than the legitimate operator for the first imprinting process. Both attack vectors can be controlled. If you buy a new lightbulb and it does not listen to you, you will reset it and try imprinting again. At some point you'll hopefully succeed (because your neighbor gave up). If you have imprinted a device and don't want it to be reset, you have to take measures to prevent just that, like mounting the device so its inaccesible or simply omitting a reset button. On 21/03/2012 6:09 AM, Johannes Gilger wrote: > Hello Alper, > > thanks for your comments. I'll try to explain the point I was making > with the last mail. I do suspect my approaches to be naive, and would > like to learn about scenarios where they fail. > > On 21/03/12 11:22, Alper Yegin wrote: >>> In my understanding of the functionality of an interface-constrained IoT >>> device, there is no need for the node to identify the network. >> I can understand "it's not possible", or "it's difficult". But I don't understand how "there is no need." >> Device needs to know it's connected to the right "server" >> (being right involves being authenticated and authorized, two really separate things). > Yes, for some devices that is true. Lets take for example a plain > lightbulb (with Smart Object capabilities) and a Smart Meter which is > installed by a utility. > > The lightbulb has no owner until it is bought and taken from the shelf. > The owner then wants to make sure that the lightbulb listens to him, and > not to his neighbor. The lightbulb does not (and can not) care about > "who" is switching it off and on, so long as it is the same person which > first associated with it. > > For a Smart Meter, the relationship might look different on the surface. > After all, a Smart Meter installed at at customers home should only talk > to the correct utility. But then again, when the utility acquires the > Smart Meter from the manufacturer, it could imprint and use it like a > lightbulb, before installing it at the customer. > >>> The only thing that matters is that the network can identify the node >>> (as has been discussed) and that the network can ensure that it is the >>> only one able to command the node. >> So, a rogue network can do that. "Identify" the victim device, and read from it and write into it. >> This is obviously not acceptable. > The assumption here is that the Smart Object is in one of two global > states: Imprintable or Imprinted. The rogue network can simply imprint > itself in the Smart Object it if is able to reset the device or if it is > "faster" than the legitimate operator for the first imprinting process. > > Both attack vectors can be controlled. If you buy a new lightbulb and it > does not listen to you, you will reset it and try imprinting again. At > some point you'll hopefully succeed (because your neighbor gave up). > > If you have imprinted a device and don't want it to be reset, you have > to take measures to prevent just that, like mounting the device so its > inaccesible or simply omitting a reset button. > >>> Why not? Looking at the Resurrecting Duckling again, the device will >>> talk to anyone when its in the "imprintable" state. After it has been >>> imprinted by an authority (hopefully the right one, or you'll have to >>> reset the device and try again), >> So, knowing the "right one" is the issue. >> Who's going to detect this is the wrong one and reset the device? The user. >> We cannot assume user will detect and act upon it, if you consider the wide range of IoT use cases. >> Users are rarely involved, especially in that capacity. > I am not sure. What is probably clouding my judgement is that I know so > few actual end-to-end real-world applications for Smart Objects, which I > hope will change with the Smart Object Security workshop. > > Regards, > Jojo > -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From alper.yegin@yegin.org Wed Mar 21 08:21:01 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9F521F8755 for ; Wed, 21 Mar 2012 08:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 7c4wiiVVaRj7 for ; Wed, 21 Mar 2012 08:21:00 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 2E62621F874C for ; Wed, 21 Mar 2012 08:21:00 -0700 (PDT) Received: from [192.168.2.2] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MZTs5-1RrLQI1Ak9-00LzEz; Wed, 21 Mar 2012 11:20:59 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: <20120321100901.GA15321@blackbox> Date: Wed, 21 Mar 2012 17:20:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7259510C-543A-45E5-9458-FEEE5B2D6F97@yegin.org> References: <20120214114904.GA8794@blackbox> <55D88CC8-EF12-4A29-8476-E22F1470B855@yegin.org> <20120321100901.GA15321@blackbox> To: Johannes Gilger X-Mailer: Apple Mail (2.1257) X-Provags-ID: V02:K0:XS1hmXTfrN5/Op7WgSxG7N/bDyhWEvCpJdyBl8u0eUx KVKlwCRxdBl3ui8ZLGggTAKn5w9mTyyPT77X5Bl6mkxca1uKV7 yh3rTAr1gnxVZ+HreABALR7wcEmsGUxe+Ug/qreXrka6LIAx+O gnBb1FsMzpZaSU1sT/5YSre4nzNQf72Adp32t0TCaEkTxneycO SJa0D1Yo8VzPowMBlNXXEAp4P625zoT+J1HCSM7oVy14B0Pw5M KyLRQe7zJOH+r2u273OQ1pLzzpNWj1z1V3qYr3auDF8uU8WHuZ VxnYX49R6VcQso0keIw74upsUbPI/veqcrayJNzqDCr9pLy+Yz 64s4xxcBEwAp9UdDngqHS10SfkUUKJ2R73tMV3wmnuhqovxcgS b4cIjriv1AIvg== Cc: "core@ietf.org WG" Subject: Re: [core] RawPublicKeys X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 Mar 2012 15:21:01 -0000 Hi Johannes, > Hello Alper, >=20 > thanks for your comments. I'll try to explain the point I was making > with the last mail. I do suspect my approaches to be naive, and would > like to learn about scenarios where they fail. >=20 > On 21/03/12 11:22, Alper Yegin wrote: >>> In my understanding of the functionality of an interface-constrained = IoT >>> device, there is no need for the node to identify the network. >>=20 >> I can understand "it's not possible", or "it's difficult". But I = don't understand how "there is no need." >> Device needs to know it's connected to the right "server"=20 >> (being right involves being authenticated and authorized, two really = separate things). >=20 > Yes, for some devices that is true. Lets take for example a plain > lightbulb (with Smart Object capabilities) and a Smart Meter which is > installed by a utility. >=20 > The lightbulb has no owner until it is bought and taken from the = shelf. > The owner then wants to make sure that the lightbulb listens to him, = and > not to his neighbor. The lightbulb does not (and can not) care about > "who" is switching it off and on, so long as it is the same person = which > first associated with it. >=20 > For a Smart Meter, the relationship might look different on the = surface. > After all, a Smart Meter installed at at customers home should only = talk > to the correct utility. But then again, when the utility acquires the > Smart Meter from the manufacturer, it could imprint and use it like a > lightbulb, before installing it at the customer. >=20 >>> The only thing that matters is that the network can identify the = node >>> (as has been discussed) and that the network can ensure that it is = the >>> only one able to command the node. >>=20 >> So, a rogue network can do that. "Identify" the victim device, and = read from it and write into it. >> This is obviously not acceptable. >=20 > The assumption here is that the Smart Object is in one of two global > states: Imprintable or Imprinted. The rogue network can simply imprint > itself in the Smart Object it if is able to reset the device or if it = is > "faster" than the legitimate operator for the first imprinting = process. >=20 > Both attack vectors can be controlled. If you buy a new lightbulb and = it > does not listen to you, you will reset it and try imprinting again. At > some point you'll hopefully succeed (because your neighbor gave up). >=20 > If you have imprinted a device and don't want it to be reset, you have > to take measures to prevent just that, like mounting the device so its > inaccesible or simply omitting a reset button. >=20 See, these all have implications to provide "complete security", such = as: - A test is needed. The later the test, bigger the vulnerability as = rogue operation cannot be detected until that. And test takes time. User = jiggles few things, and possibly gives up and leaves the bulb in place = for hours, days=85 There won't be a warning that says "if the bulb is = not responding, remove it immediately, it may be compromised!". - Lack of a reset button means someone can decommission the device by = simply imprinting it before the victimized owner. No reset button, so = the device is a brick now. - Physical security (unreachable device). My point is, having certs in place does not provide a complete solution = for security. =20 Alper >>> Why not? Looking at the Resurrecting Duckling again, the device will >>> talk to anyone when its in the "imprintable" state. After it has = been >>> imprinted by an authority (hopefully the right one, or you'll have = to >>> reset the device and try again), >>=20 >> So, knowing the "right one" is the issue. >> Who's going to detect this is the wrong one and reset the device? The = user. >> We cannot assume user will detect and act upon it, if you consider = the wide range of IoT use cases. >> Users are rarely involved, especially in that capacity. >=20 > I am not sure. What is probably clouding my judgement is that I know = so > few actual end-to-end real-world applications for Smart Objects, which = I > hope will change with the Smart Object Security workshop. >=20 > Regards, > Jojo >=20 > --=20 > Dipl.-Inform. Johannes Gilger > Research Group IT-Security > UMIC Research Centre > RWTH Aachen University > Mies-van-der-Rohe-Stra=DFe 15 > 52074 Aachen >=20 > Office: 211 > Phone: +49 241 80 20781 > Fax: +49 241 80 22731 >=20 > http://itsec.rwth-aachen.de From gilger@umic.rwth-aachen.de Thu Mar 22 02:17:27 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7656721F8565 for ; Thu, 22 Mar 2012 02:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, FUZZY_VLIUM=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfnHW+jRzNlD for ; Thu, 22 Mar 2012 02:17:26 -0700 (PDT) Received: from avalon.gnuzifer.de (avalon.gnuzifer.de [IPv6:2a01:4f8:121:43c1::a2:1]) by ietfa.amsl.com (Postfix) with ESMTP id C231521F8548 for ; Thu, 22 Mar 2012 02:17:26 -0700 (PDT) Received: from [137.226.161.159] (port=50150 helo=localhost) by avalon.gnuzifer.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1SAe96-0002ti-Ip; Thu, 22 Mar 2012 10:17:24 +0100 Date: Thu, 22 Mar 2012 10:17:29 +0100 From: Johannes Gilger To: Alper Yegin Message-ID: <20120322091729.GA21014@blackbox> References: <20120214114904.GA8794@blackbox> <55D88CC8-EF12-4A29-8476-E22F1470B855@yegin.org> <20120321100901.GA15321@blackbox> <7259510C-543A-45E5-9458-FEEE5B2D6F97@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7259510C-543A-45E5-9458-FEEE5B2D6F97@yegin.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 137.226.161.159 X-SA-Exim-Mail-From: gilger@umic.rwth-aachen.de Cc: "core@ietf.org WG" Subject: Re: [core] RawPublicKeys X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 22 Mar 2012 09:17:27 -0000 Hi Alper, On 21/03/12 17:20, Alper Yegin wrote: > See, these all have implications to provide "complete security", such as: Yes, I've been making a few assumptions for this specific class of devices. > - A test is needed. The later the test, bigger the vulnerability as > rogue operation cannot be detected until that. And test takes time. > User jiggles few things, and possibly gives up and leaves the bulb in > place for hours, days… There won't be a warning that says "if the bulb > is not responding, remove it immediately, it may be compromised!". OK, that could be a problem. But then again, one has to look at the kind of devices and the combinations of the techniques I described here. For example, some lightbulbs come with a big warning to not touch the glass with your bare hands, which seems to work out fine. Likely, a Smart Object lightbulb could say "If not responding within 30 seconds, unscrew lightbulb within 5 minutes to avoid permanent damage". A lightbulb is probably even a bad example if we assume that it is installed in a private room. If it is, then it can have a small physical reset button, and we can simply use the Resurrecting Duckling model to reset and re-imprint it until we are successfull. > - Lack of a reset button means someone can decommission the device by > simply imprinting it before the victimized owner. No reset button, so > the device is a brick now. Yes, as I described for this case, one would need a grace period during which the device can simply be rebooted without any imprinting becoming permanent. Obviously this kind of imprinting scheme can be dangerous if used by inexperienced users. But it seems to work fine today. If you forget your BIOS supervisor password, your mainboard and hard-drive have to be replaced. Likely, there are features to disable password recovery for network switches (the story of this SF network operator who hard-locked everyone out of the city's Cisco hardware), yet nobody is complaining about this feature. So, looking at the Smart Meter application, we can safely assume that the people imprinting the credentials at the utility company know how the process works, and won't leave a device plugged in if for some reason someone else was able to implement himself first. > My point is, having certs in place does not provide a complete solution for security. No, certainly not, and I don't want to come across as making that claim. I have just been thinking a lot about imprinting schemes for (very) interface-constrained devices and wanted a reality check. Regards, Jojo -- Dipl.-Inform. Johannes Gilger Research Group IT-Security UMIC Research Centre RWTH Aachen University Mies-van-der-Rohe-Straße 15 52074 Aachen Office: 211 Phone: +49 241 80 20781 Fax: +49 241 80 22731 http://itsec.rwth-aachen.de From esko.dijk@philips.com Thu Mar 22 03:51:49 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBBC21F868A for ; Thu, 22 Mar 2012 03:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 tagged_above=-999 required=5 tests=[AWL=0.647, BAYES_00=-2.599, GB_I_LETTER=-2, 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 SZAQp6unObd6 for ; Thu, 22 Mar 2012 03:51:47 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id C682E21F8684 for ; Thu, 22 Mar 2012 03:51:44 -0700 (PDT) Received: from mail30-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 22 Mar 2012 10:51:35 +0000 Received: from mail30-va3 (localhost [127.0.0.1]) by mail30-va3-R.bigfish.com (Postfix) with ESMTP id CAB351C0419; Thu, 22 Mar 2012 10:51:35 +0000 (UTC) X-SpamScore: -50 X-BigFish: VPS-50(zz217bL15d6O9251J179dN542M1432Nzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI Received: from mail30-va3 (localhost.localdomain [127.0.0.1]) by mail30-va3 (MessageSwitch) id 1332413494259066_15162; Thu, 22 Mar 2012 10:51:34 +0000 (UTC) Received: from VA3EHSMHS013.bigfish.com (unknown [10.7.14.245]) by mail30-va3.bigfish.com (Postfix) with ESMTP id 3ABB11A00E4; Thu, 22 Mar 2012 10:51:34 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS013.bigfish.com (10.7.99.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 22 Mar 2012 10:51:32 +0000 Received: from 011-DB3MMR1-022.MGDPHG.emi.philips.com (10.128.28.105) by 011-DB3MMR1-005.MGDPHG.emi.philips.com (10.128.28.55) with Microsoft SMTP Server (TLS) id 14.1.355.3; Thu, 22 Mar 2012 10:53:53 +0000 Received: from 011-DB3MPN1-013.MGDPHG.emi.philips.com ([169.254.3.240]) by 011-DB3MMR1-022.MGDPHG.emi.philips.com ([fe80::1113:17d7:70dc:6faa%11]) with mapi id 14.01.0355.003; Thu, 22 Mar 2012 10:53:53 +0000 From: "Dijk, Esko" To: Jari Arkko , "matthieu.vial@non.schneider-electric.com" Thread-Topic: [core] Tr : New Version Notification for draft-vial-core-mirror-proxy-00.txt Thread-Index: AQHM+HXGBKCQEHwzEUqw/PYE5xqGJZZXDUwAgB8w+4A= Date: Thu, 22 Mar 2012 10:53:52 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED6180852B2@011-DB3MPN1-013.MGDPHG.emi.philips.com> References: <4F50D652.1090501@piuha.net> In-Reply-To: <4F50D652.1090501@piuha.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: core WG Subject: Re: [core] Tr : New Version Notification for draft-vial-core-mirror-proxy-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, 22 Mar 2012 10:51:49 -0000 > Hmm. I think this needs further thought. Is there a way to ask "give me a= list of my resources that have changed since yesterday"? Agree! This could be the way to go if we do not want to define another CoAP= Option. It could be "give me a list of my resources that have changed sinc= e last time I checked". That seems far more scalable than a SEP polling all= its resources for changes. If there's no change the SEP can quickly go to = sleep again. One way for the SEP to query the MP for this could be like this (just an ad= -hoc query syntax here...): GET /mp/0?change MP responds with: 2.05 Content Content-Type: application/link-format , where the default rel=3D"hosts" relation is used, though it might be anothe= r (rel=3D"updated" ??) The SEP has to parse these link-format descriptions, but in general link-fo= rmat parsing was already part of the specified SEP behavior in this draft. Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Jar= i Arkko Sent: Friday 2 March 2012 15:17 To: matthieu.vial@non.schneider-electric.com Cc: core WG Subject: Re: [core] Tr : New Version Notification for draft-vial-core-mirro= r-proxy-00.txt Matthieu, I have read your draft. I like it, and would very much like to see somethin= g like this as a part of the outputs from this working group. Your draft is= kind of a well-designed REST version of what we did in admittedly rather a= d hoc manner in draft-arkko-core-sleepy-sensors. I also like it that your interface is pretty much identical to the RD inter= face, making this easier to implement. Question: if I want to register myse= lf in a RM *and* an RD (which might potentially be in the same server), is = there a way for me to send just one set of messages, or do I have to regist= er twice? A couple of comments on your open questions: > We need a way to identify a SEP registered in multiple proxies as a > single entity. Otherwise clients may have a wrong view of the > available services during resource discovery. The duplicate > resources are indeed seen as new devices. I would suggest that there could be a "origin" identity carried in the regi= stration (e.g., dev:mac:....) and that origin identity can be communicated = through the RD to anyone who sees the resources. This allows whoever is int= erested in the content to at least detect the duplicate resources as such. > > We need a simple mechanism to define allowed methods on mirrored > resources that is independant of the resource profile. A second > Interface Description attribute with the CRUD letters might work. I have no comment on this yet. > We may add a CoAP option that would permit a MP to indicate in a > response that a client has updated another writable resource in the > cache for the requesting SEP. This would gives better response time > than polling. Hmm. I think this needs further thought. Is there a way to ask "give me a l= ist of my resources that have changed since yesterday"? > > When a SEP registers with multiple MP and each MP reuses the same > SEP's name to register with the RD, the resource directory entry > might be overwritten. We need to figure out what piece of > information is the handler for a resource directory entry in a RD > database. We have some ideas on this front... stay tuned. > > 6.1. Extensions > > > > Implicit registration could be useful for highly constrained SEP that > don't have enough energy to maintain soft state in a MP. Like the > proposition in [I-D.arkko-core-sleepy-sensors ], = we could use a > multicast address to infer a resource type. Alternatively we could > allow explicit registration from a third-party endpoint. > For what it is worth, we took our implementation to the extreme limit. It i= s necessary to be able to create simple and power efficient devices, but th= ere may be a reasonable limit that we do not have to cross. I think a const= rained device can support a registration phase. The only problem that I hav= e with registration phases is the issue that we experienced with coap-obser= ve: we cannot assume that only one entity is interested in our results, we = don't know when the addressing plan of the site changes, and we don't want= to stay on all the time in case someone re-registers (as a server) or poll= continuously if there's a new register that we must register to (as a clie= nt). If those problems can be overcome for a RM function, then I'm fine wit= h programming a discovery and registration mechanism into my devices. Jari _______________________________________________ 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 rgm@labs.htt-consult.com Thu Mar 22 10:07:55 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AED821F8638 for ; Thu, 22 Mar 2012 10:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 3DVXF4vsgNkw for ; Thu, 22 Mar 2012 10:07:53 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id BC49E21F8629 for ; Thu, 22 Mar 2012 10:07:52 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 0176362A45; Thu, 22 Mar 2012 17:07:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaUr-6zgeUKr; Thu, 22 Mar 2012 13:07:18 -0400 (EDT) Received: from lx120e.htt-consult.com (static-195.22.91.6.addr.tdcsong.se [195.22.91.6]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id C4AA862A79; Thu, 22 Mar 2012 13:07:16 -0400 (EDT) Message-ID: <4F6B5C32.50107@labs.htt-consult.com> Date: Thu, 22 Mar 2012 18:06:58 +0100 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: "core@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gurtov@ee.oulu.fi, jpellikk@ee.oulu.fi Subject: [core] A 'new' view in use of RawPublicKeys in Core and elsewhere X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 22 Mar 2012 17:07:55 -0000 First I am in Stockholm right now after a meeting with a Verizon ISV (Wow, real company work :) ). I will be arriving in Paris sunday noonish and leaving thursday afternoon. Second, what I am about to present has been the outgrowth of conversations and emails during and after the IEEE 802 meeting last week, from people in both 802.11ai and 802.15.9. Paul Lambert (Marvel) made a short presentation to the 802.11 wng session on 'Key Centric Identity' to get the larger 802.11 community into an understanding of discussions ongoing in 802.11ai, this is at: https://mentor.ieee.org/802.11/dcn/12/11-12-0378-00-0wng-key-centric-identity.ppt Very short and to the point and content (other than the hash used as a local MAC address) should be familiar with people on this list. But a couple of key points is that the public key IS the identity and a hash of that key IS a powerful tool to authentication services. Now although I am a big proponent of KCI for over 12 years, only recently have I worked out some key environmental portions and some still needs some work (as well as being ECC centric). Enough background. Premise: The sensor and a network service (To Be Named) both have RawPublicKey Identities that are available in a hashed format. I will call these RpkI and RpkHI until someone gives me better generic handles (I want to avoid HIP-style labels). Further the sensor's RpkHI and some other information (Some to be discussed further down) will be printed on the sensor or on provided paper in a QR code (probably v3 should be enough). The QR code will be used to preload the network authentication server with the sensor's identity as Paul shows. I will not discuss here (though I am elsewhere) the protocol used by the network service and the authentication service to retrieve valid sensor RpkHI. This deployment method provides one side of the problem on how the network service accept a new sensor. For the other side, how does the sensor recognize the proper PAN and service, I am going to introduce some things that are rather 'new' to me, and I may not have all the pieces right and so far I only know how to do this with EC identities like static ECDH (though ECDSA works as well). The piece here is ECQV, Implicit Certificates, that was just shown to me last week by Andrei Gutov for his student, Jani Pellikka. Here the sensor vendor pre-loads the sensor with the random value need for the ECQV and places that in the QR code. The network authentication server takes that and the network service identity and builds the ECQV to use in the KMP. It is ASSUMEd that only the intended PAN has this information (thus there is a weakness of leakage here for who scans the QR code). Now the sensor can validate the RpkHI in the form of the ECQV it got. Not 100%, but much closer than anything else I have worked out. There is always the backoff and retry approach if the neighboring PAN is able to make the same ECQV (you picked the room thermometer out of your neighbor's garbage, shame on you). I also have only seen this with ECC. I am in the process of working this out. Some of it I only really put together last week, and really the ECQV in this direction in this manner only came to me a couple hours ago rereading the 'RawPublicKeys' thread on this list. I offer this for your reading pleasure. I have my preferred KMP and I fully intend to pursue this, but I believe this will work with MOST KMPs that implement support for RpkHI. Finally, I will point out what I view as obvious. The world of sensor networks is not all CoAP, let alone 6lowpan and even Zigbee. LECIM (802.15.4k) looks to be fun. And now we have the PTC SG with a PAR (just a different set of challenges). Thus I am working on the network securing and authentication in 802.15.9 where I believe it needs to live. Oh and it looks like there is life still in 802.15.7 based on a presentation last week. See people Sunday afternoon or later. From rstruik.ext@gmail.com Thu Mar 22 11:08:20 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B874C21F84FF for ; Thu, 22 Mar 2012 11:08:20 -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 5cqvZvzrf873 for ; Thu, 22 Mar 2012 11:08:19 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCE221E801F for ; Thu, 22 Mar 2012 11:08:19 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so913277wib.13 for ; Thu, 22 Mar 2012 11:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=tQu11PShdF+vDQIcxaj+racKSEJN6Lg1yt4sp7YN+k0=; b=zEy0YuWwZfnuzfXJ1bVfkxzpC/Ze5s+rYlVFunYGGHPJ7iaOrDazK1QD0Bs3rC4ZXr qkwcF8hkMdlYwmfvBW/l3RntSXnzpXrQhuk4PTplExK8SdxJOStf6YBJhxcy0T6O4DZ+ kY29qvQabDSnp7z/a+INv/lUngDzGppAGiP3RfUB9ATUupEe6tn4fV2ic50Usym5DGwg H55aTiJjna5SHn88GMOlDtp1vKGJRcscQ3zmZi4lwag0Gx5tAmS9VwIbWRtJGzuYdhJx DU/OT+8yldHnoRramT2X+SvYT8dUcbL6FsO/8O6077hOtODh/cXETpwYKpDrL8EPRv1z U4qA== Received: by 10.180.19.37 with SMTP id b5mr7495050wie.9.1332439698412; Thu, 22 Mar 2012 11:08:18 -0700 (PDT) Received: from [192.168.182.49] (pha75-6-82-226-118-157.fbx.proxad.net. [82.226.118.157]) by mx.google.com with ESMTPS id e6sm6949927wix.8.2012.03.22.11.08.17 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Mar 2012 11:08:17 -0700 (PDT) Message-ID: <4F6B6A72.8010602@gmail.com> Date: Thu, 22 Mar 2012 14:07:46 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Robert Moskowitz References: <4F6B5C32.50107@labs.htt-consult.com> In-Reply-To: <4F6B5C32.50107@labs.htt-consult.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: gurtov@ee.oulu.fi, "core@ietf.org WG" , jpellikk@ee.oulu.fi Subject: Re: [core] A 'new' view in use of RawPublicKeys in Core and elsewhere X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 22 Mar 2012 18:08:20 -0000 Hi Bob: I have been struggling with the equation PubKey = Identity for a long time and will continue to do so till someone can explain to me how one can speak of "the" identity in this case in settings where the public key (or, for that matter, data associated with that public key) may change during the lifecycle of the device. Moreover, it may very well be the case that initial public keys are only generated after the need to communicate the identifier becomes available. Some deployment scenarios where public key related info may change over time: 1) short-lived certificates (as would, e.g., be the case with ECQV certs, where the reconstructed public key depends on all data field of the to-be-signed data, including public key reconstruction data and policy fields, such as key validity time period). 2) public keys certified by more than one entity (although I have not looked into this in detail, shouldn't one then bind the public key to the binding entity and not "cut the ties"?). 3) delegation of public keys, e.g., in the event one may authenticate via more than one device. To me, it seems that having a certificate provides for the binding of an entity's identity to (the private key corresponding to) a public key, so we have a mechanism that has been around for decades that allows definition of identities and public keys in orthogonal fashion, withou hardcoding one in terms of the other. Isn't the real reason to bring this up then that one does not believe in certificates, find them unmanageable, bulky, etc.? There are easy fixes here (e.g., short-lived certificates, which may take a whole cottage industry of CRL, OCSP etc. specs out of business), so I would suggest that would also be a valuable approach --- if my speculation on underlying cause of bringing up the PubKey = Identity "equation" has some merit (I bet a bottle of Bordeaux there is some truth in this...). == Some earlier CoRE traffic on this: {Hannes Tschofenig, December 20, 2011} http://www.ietf.org/mail-archive/web/core/current/msg02543.html {Rene Struik, Alper Yegin, December 19, 2012} http://www.ietf.org/mail-archive/web/core/current/msg02540.html On 22/03/2012 1:06 PM, Robert Moskowitz wrote: > First I am in Stockholm right now after a meeting with a Verizon ISV > (Wow, real company work :) ). I will be arriving in Paris sunday > noonish and leaving thursday afternoon. > > Second, what I am about to present has been the outgrowth of > conversations and emails during and after the IEEE 802 meeting last > week, from people in both 802.11ai and 802.15.9. > > Paul Lambert (Marvel) made a short presentation to the 802.11 wng > session on 'Key Centric Identity' to get the larger 802.11 community > into an understanding of discussions ongoing in 802.11ai, this is at: > > https://mentor.ieee.org/802.11/dcn/12/11-12-0378-00-0wng-key-centric-identity.ppt > > > Very short and to the point and content (other than the hash used as a > local MAC address) should be familiar with people on this list. But a > couple of key points is that the public key IS the identity and a hash > of that key IS a powerful tool to authentication services. Now > although I am a big proponent of KCI for over 12 years, only recently > have I worked out some key environmental portions and some still needs > some work (as well as being ECC centric). > > Enough background. > > Premise: The sensor and a network service (To Be Named) both have > RawPublicKey Identities that are available in a hashed format. I will > call these RpkI and RpkHI until someone gives me better generic > handles (I want to avoid HIP-style labels). > > Further the sensor's RpkHI and some other information (Some to be > discussed further down) will be printed on the sensor or on provided > paper in a QR code (probably v3 should be enough). The QR code will > be used to preload the network authentication server with the sensor's > identity as Paul shows. I will not discuss here (though I am > elsewhere) the protocol used by the network service and the > authentication service to retrieve valid sensor RpkHI. This > deployment method provides one side of the problem on how the network > service accept a new sensor. > > For the other side, how does the sensor recognize the proper PAN and > service, I am going to introduce some things that are rather 'new' to > me, and I may not have all the pieces right and so far I only know how > to do this with EC identities like static ECDH (though ECDSA works as > well). The piece here is ECQV, Implicit Certificates, that was just > shown to me last week by Andrei Gutov for his student, Jani Pellikka. > Here the sensor vendor pre-loads the sensor with the random value need > for the ECQV and places that in the QR code. The network > authentication server takes that and the network service identity and > builds the ECQV to use in the KMP. It is ASSUMEd that only the > intended PAN has this information (thus there is a weakness of leakage > here for who scans the QR code). Now the sensor can validate the > RpkHI in the form of the ECQV it got. Not 100%, but much closer than > anything else I have worked out. > > There is always the backoff and retry approach if the neighboring PAN > is able to make the same ECQV (you picked the room thermometer out of > your neighbor's garbage, shame on you). I also have only seen this > with ECC. > > I am in the process of working this out. Some of it I only really put > together last week, and really the ECQV in this direction in this > manner only came to me a couple hours ago rereading the > 'RawPublicKeys' thread on this list. > > I offer this for your reading pleasure. I have my preferred KMP and I > fully intend to pursue this, but I believe this will work with MOST > KMPs that implement support for RpkHI. > > Finally, I will point out what I view as obvious. The world of sensor > networks is not all CoAP, let alone 6lowpan and even Zigbee. LECIM > (802.15.4k) looks to be fun. And now we have the PTC SG with a PAR > (just a different set of challenges). Thus I am working on the > network securing and authentication in 802.15.9 where I believe it > needs to live. Oh and it looks like there is life still in 802.15.7 > based on a presentation last week. > > See people Sunday afternoon or later. > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From rgm@labs.htt-consult.com Thu Mar 22 12:11:54 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF77721F84F3 for ; Thu, 22 Mar 2012 12:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, 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 iFFLSIYcYeF7 for ; Thu, 22 Mar 2012 12:11:51 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id D1B5821F84C5 for ; Thu, 22 Mar 2012 12:11:50 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 72A6362A73; Thu, 22 Mar 2012 19:11:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m37tY+ZF-a1x; Thu, 22 Mar 2012 15:11:09 -0400 (EDT) Received: from lx120e.htt-consult.com (static-195.22.91.6.addr.tdcsong.se [195.22.91.6]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id C2FD062A6F; Thu, 22 Mar 2012 15:11:07 -0400 (EDT) Message-ID: <4F6B7943.4040907@labs.htt-consult.com> Date: Thu, 22 Mar 2012 20:10:59 +0100 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Rene Struik References: <4F6B5C32.50107@labs.htt-consult.com> <4F6B6A72.8010602@gmail.com> In-Reply-To: <4F6B6A72.8010602@gmail.com> Content-Type: multipart/alternative; boundary="------------080405070102000106000201" Cc: gurtov@ee.oulu.fi, "core@ietf.org WG" , jpellikk@ee.oulu.fi Subject: Re: [core] A 'new' view in use of RawPublicKeys in Core and elsewhere X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 22 Mar 2012 19:11:54 -0000 This is a multi-part message in MIME format. --------------080405070102000106000201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have a 6:30am flight to get to so early to bed tonight, but I will try... On 03/22/2012 07:07 PM, Rene Struik wrote: > Hi Bob: > > I have been struggling with the equation PubKey = Identity for a long > time and will continue to do so till someone can explain to me how one > can speak of "the" identity in this case in settings where the public > key (or, for that matter, data associated with that public key) may > change during the lifecycle of the device. Moreover, it may very well be > the case that initial public keys are only generated after the need to > communicate the identifier becomes available. In practice, all identities have an ephemeral quality. Eight days after my birth my parents named me Reuven Gershon ben Benyomin (spelled in Hebrew) and put on my birth certificate Robert Glenn Moskowitz. Now I did not see my birth certificate until I was 17 and from the age of 5, I was writing my english name as Robert Glen Moskowitz (that I still use for legal purposes). In school I was called Bob Moskowitz and at age 11 for the first time a classmate called (this was '61 and not a lot of phone calls were made even in suburbia, you WENT to the house) and asked appearently for Bob. My 7 year old sister had picked up the phone and I heard her side of the conversation, "Bob, there is no Bob here". Click. My family has always only known me as Robert. Premise #1: An Identity is ANYTHING you want as long as you can use it. (Think of the singer once known as Prince :) ). Corollary #1: A public key portion of a public/private key pair MAY be used as an identity in and of itself as long as you can use it. I can go on for hours and pages about namespaces (I was a member of the Namespace Research Group and sat through hours of philosophy of names and namespaces) and the role of textual, symbolic, and mathematical names. Premise #2: Something added MUST bring value commensurate with its cost. (well there is always bric-a-brac out there) Postulate #1: In M2M secure communications RawPublicKeys are sufficient in and of themselves, provided there is a mechanism to authenticate them within the domain of their use. Further the total system cost can be minimized by working with RawPublicKeys over other PublicKey methods. Now are these RpkI provided at owner purchase time or build time? Do they get changed to some concept of changing (ask me about the Jewish practice of adding to a critically sick person's name. Hint it is Mystical) or do they last as long as the silicon does? (or someone runs them through a microwave oven!) The answer to both is yes and no. You choose what works for you. (Premise #1) For myself, and what I recommend is that the common usage will be manufacture installed RpkI that last the life of the device. Recognizing that there are special customers out there that will want to install their own RpkI and will reprovision them as they deem necessary and will pay the freight. Good night. See you next week. Well I will pick up email in Amsterdam friday, and MAY reply. > > Some deployment scenarios where public key related info may change over > time: > 1) short-lived certificates (as would, e.g., be the case with ECQV > certs, where the reconstructed public key depends on all data field of > the to-be-signed data, including public key reconstruction data and > policy fields, such as key validity time period). > 2) public keys certified by more than one entity (although I have not > looked into this in detail, shouldn't one then bind the public key to > the binding entity and not "cut the ties"?). > 3) delegation of public keys, e.g., in the event one may authenticate > via more than one device. > > To me, it seems that having a certificate provides for the binding of an > entity's identity to (the private key corresponding to) a public key, so > we have a mechanism that has been around for decades that allows > definition of identities and public keys in orthogonal fashion, withou > hardcoding one in terms of the other. > > Isn't the real reason to bring this up then that one does not believe in > certificates, find them unmanageable, bulky, etc.? There are easy fixes > here (e.g., short-lived certificates, which may take a whole cottage > industry of CRL, OCSP etc. specs out of business), so I would suggest > that would also be a valuable approach --- if my speculation on > underlying cause of bringing up the PubKey = Identity "equation" has > some merit (I bet a bottle of Bordeaux there is some truth in this...). > > == > Some earlier CoRE traffic on this: > > {Hannes Tschofenig, December 20, 2011} > http://www.ietf.org/mail-archive/web/core/current/msg02543.html > > {Rene Struik, Alper Yegin, December 19, 2012} > http://www.ietf.org/mail-archive/web/core/current/msg02540.html > > On 22/03/2012 1:06 PM, Robert Moskowitz wrote: >> First I am in Stockholm right now after a meeting with a Verizon ISV >> (Wow, real company work :) ). I will be arriving in Paris sunday >> noonish and leaving thursday afternoon. >> >> Second, what I am about to present has been the outgrowth of >> conversations and emails during and after the IEEE 802 meeting last >> week, from people in both 802.11ai and 802.15.9. >> >> Paul Lambert (Marvel) made a short presentation to the 802.11 wng >> session on 'Key Centric Identity' to get the larger 802.11 community >> into an understanding of discussions ongoing in 802.11ai, this is at: >> >> https://mentor.ieee.org/802.11/dcn/12/11-12-0378-00-0wng-key-centric-identity.ppt >> >> >> Very short and to the point and content (other than the hash used as a >> local MAC address) should be familiar with people on this list. But a >> couple of key points is that the public key IS the identity and a hash >> of that key IS a powerful tool to authentication services. Now >> although I am a big proponent of KCI for over 12 years, only recently >> have I worked out some key environmental portions and some still needs >> some work (as well as being ECC centric). >> >> Enough background. >> >> Premise: The sensor and a network service (To Be Named) both have >> RawPublicKey Identities that are available in a hashed format. I will >> call these RpkI and RpkHI until someone gives me better generic >> handles (I want to avoid HIP-style labels). >> >> Further the sensor's RpkHI and some other information (Some to be >> discussed further down) will be printed on the sensor or on provided >> paper in a QR code (probably v3 should be enough). The QR code will >> be used to preload the network authentication server with the sensor's >> identity as Paul shows. I will not discuss here (though I am >> elsewhere) the protocol used by the network service and the >> authentication service to retrieve valid sensor RpkHI. This >> deployment method provides one side of the problem on how the network >> service accept a new sensor. >> >> For the other side, how does the sensor recognize the proper PAN and >> service, I am going to introduce some things that are rather 'new' to >> me, and I may not have all the pieces right and so far I only know how >> to do this with EC identities like static ECDH (though ECDSA works as >> well). The piece here is ECQV, Implicit Certificates, that was just >> shown to me last week by Andrei Gutov for his student, Jani Pellikka. >> Here the sensor vendor pre-loads the sensor with the random value need >> for the ECQV and places that in the QR code. The network >> authentication server takes that and the network service identity and >> builds the ECQV to use in the KMP. It is ASSUMEd that only the >> intended PAN has this information (thus there is a weakness of leakage >> here for who scans the QR code). Now the sensor can validate the >> RpkHI in the form of the ECQV it got. Not 100%, but much closer than >> anything else I have worked out. >> >> There is always the backoff and retry approach if the neighboring PAN >> is able to make the same ECQV (you picked the room thermometer out of >> your neighbor's garbage, shame on you). I also have only seen this >> with ECC. >> >> I am in the process of working this out. Some of it I only really put >> together last week, and really the ECQV in this direction in this >> manner only came to me a couple hours ago rereading the >> 'RawPublicKeys' thread on this list. >> >> I offer this for your reading pleasure. I have my preferred KMP and I >> fully intend to pursue this, but I believe this will work with MOST >> KMPs that implement support for RpkHI. >> >> Finally, I will point out what I view as obvious. The world of sensor >> networks is not all CoAP, let alone 6lowpan and even Zigbee. LECIM >> (802.15.4k) looks to be fun. And now we have the PTC SG with a PAR >> (just a different set of challenges). Thus I am working on the >> network securing and authentication in 802.15.9 where I believe it >> needs to live. Oh and it looks like there is life still in 802.15.7 >> based on a presentation last week. >> >> See people Sunday afternoon or later. >> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > -- Robert Moskowitz Senior Technical Advisor Security & Standards Verizon Business Systems C:248-219-2059 F:248-968-2824 E:robert.moskowitz@verizonbusiness.com There's no limit to what can be accomplished if it doesn't matter who gets the credit --------------080405070102000106000201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have a 6:30am flight to get to so early to bed tonight, but I will try...



On 03/22/2012 07:07 PM, Rene Struik wrote: 
Hi Bob:

I have been struggling with the equation PubKey = Identity for a long
time and will continue to do so till someone can explain to me how one
can speak of "the" identity in this case in settings where the public
key (or, for that matter, data associated with that public key) may
change during the lifecycle of the device. Moreover, it may very well be
the case that initial public keys are only generated after the need to
communicate the identifier becomes available.

In practice, all identities have an ephemeral quality.  Eight days after my birth my parents named me Reuven Gershon ben Benyomin (spelled in Hebrew) and put on my birth certificate Robert Glenn Moskowitz. Now I did not see my birth certificate until I was 17 and from the age of 5, I was writing my english name as Robert Glen Moskowitz (that I still use for legal purposes).

In school I was called Bob Moskowitz and at age 11 for the first time a classmate called (this was '61 and not a lot of phone calls were made even in suburbia, you WENT to the house) and asked appearently for Bob.  My 7 year old sister had picked up the phone and I heard her side of the conversation, "Bob, there is no Bob here". Click.  My family has always only known me as Robert.

Premise #1:  An Identity is ANYTHING you want as long as you can use it.  (Think of the singer once known as Prince :) ).

Corollary #1:  A public key portion of a public/private key pair MAY be used as an identity in and of itself as long as you can use it.

I can go on for hours and pages about namespaces (I was a member of the Namespace Research Group and sat through hours of philosophy of names and namespaces) and the role of textual, symbolic, and mathematical names.

Premise #2:  Something added MUST bring value commensurate with its cost. (well there is always bric-a-brac out there)

Postulate #1: In M2M secure communications RawPublicKeys are sufficient in and of themselves, provided there is a mechanism to authenticate them within the domain of their use.  Further the total system cost can be minimized by working with RawPublicKeys over other PublicKey methods.


Now are these RpkI provided at owner purchase time or build time?
Do they get changed to some concept of changing (ask me about the Jewish practice of adding to a critically sick person's name.  Hint it is Mystical) or do they last as long as the silicon does? (or someone runs them through a microwave oven!)

The answer to both is yes and no.  You choose what works for you.  (Premise #1)

For myself, and what I recommend is that the common usage will be manufacture installed RpkI that last the life of the device.  Recognizing that there are special customers out there that will want to install their own RpkI and will reprovision them as they deem necessary and will pay the freight.

Good night.  See you next week.  Well I will pick up email in Amsterdam friday, and MAY reply.


Some deployment scenarios where public key related info may change over
time:
1) short-lived certificates (as would, e.g., be the case with ECQV
certs, where the reconstructed public key depends on all data field of
the to-be-signed data, including public key reconstruction data and
policy fields, such as key validity time period).
2) public keys certified by more than one entity (although I have not
looked into this in detail, shouldn't one then bind the public key to
the binding entity and not "cut the ties"?).
3) delegation of public keys, e.g., in the event one may authenticate
via more than one device.

To me, it seems that having a certificate provides for the binding of an
entity's identity to (the private key corresponding to) a public key, so
we have a mechanism that has been around for decades that allows
definition of identities and public keys in orthogonal fashion, withou
hardcoding one in terms of the other.

Isn't the real reason to bring this up then that one does not believe in
certificates, find them unmanageable, bulky, etc.? There are easy fixes
here (e.g., short-lived certificates, which may take a whole cottage
industry of CRL, OCSP etc. specs out of business), so I would suggest
that would also be a valuable approach --- if my speculation on
underlying cause of bringing up the PubKey = Identity "equation" has
some merit (I bet a bottle of Bordeaux there is some truth in this...).

==
Some earlier CoRE traffic on this:

{Hannes Tschofenig, December 20, 2011}
http://www.ietf.org/mail-archive/web/core/current/msg02543.html

{Rene Struik, Alper Yegin, December 19, 2012}
http://www.ietf.org/mail-archive/web/core/current/msg02540.html

On 22/03/2012 1:06 PM, Robert Moskowitz wrote:

First I am in Stockholm right now after a meeting with a Verizon ISV
(Wow, real company work :) ).  I will be arriving in Paris sunday
noonish and leaving thursday afternoon.

Second, what I am about to present has been the outgrowth of
conversations and emails during and after the IEEE 802 meeting last
week, from people in both 802.11ai and 802.15.9.

Paul Lambert (Marvel) made a short presentation to the 802.11 wng
session on 'Key Centric Identity' to get the larger 802.11 community
into an understanding of discussions ongoing in 802.11ai, this is at:

https://mentor.ieee.org/802.11/dcn/12/11-12-0378-00-0wng-key-centric-identity.ppt


Very short and to the point and content (other than the hash used as a
local MAC address) should be familiar with people on this list.  But a
couple of key points is that the public key IS the identity and a hash
of that key IS a powerful tool to authentication services.  Now
although I am a big proponent of KCI for over 12 years, only recently
have I worked out some key environmental portions and some still needs
some work (as well as being ECC centric).

Enough background.

Premise:  The sensor and a network service (To Be Named) both have
RawPublicKey Identities that are available in a hashed format.  I will
call these RpkI and RpkHI until someone gives me better generic
handles (I want to avoid HIP-style labels).

Further the sensor's RpkHI and some other information (Some to be
discussed further down) will be printed on the sensor or on provided
paper in a QR code (probably v3 should be enough).  The QR code will
be used to preload the network authentication server with the sensor's
identity as Paul shows.  I will not discuss here (though I am
elsewhere) the protocol used by the network service and the
authentication service to retrieve valid sensor RpkHI.  This
deployment method provides one side of the problem on how the network
service accept a new sensor.

For the other side, how does the sensor recognize the proper PAN and
service, I am going to introduce some things that are rather 'new' to
me, and I may not have all the pieces right and so far I only know how
to do this with EC identities like static ECDH (though ECDSA works as
well).  The piece here is ECQV, Implicit Certificates, that was just
shown to me last week by Andrei Gutov for his student, Jani Pellikka. 
Here the sensor vendor pre-loads the sensor with the random value need
for the ECQV and places that in the QR code.  The network
authentication server takes that and the network service identity and
builds the ECQV to use in the KMP.  It is ASSUMEd that only the
intended PAN has this information (thus there is a weakness of leakage
here for who scans the QR code).  Now the sensor can validate the
RpkHI in the form of the ECQV it got.  Not 100%, but much closer than
anything else I have worked out.

There is always the backoff and retry approach if the neighboring PAN
is able to make the same ECQV (you picked the room thermometer out of
your neighbor's garbage, shame on you).  I also have only seen this
with ECC.

I am in the process of working this out.  Some of it I only really put
together last week, and really the ECQV in this direction in this
manner only came to me a couple hours ago rereading the
'RawPublicKeys' thread on this list.

I offer this for your reading pleasure.  I have my preferred KMP and I
fully intend to pursue this, but I believe this will work with MOST
KMPs that implement support for RpkHI.

Finally, I will point out what I view as obvious.  The world of sensor
networks is not all CoAP, let alone 6lowpan and even Zigbee.  LECIM
(802.15.4k) looks to be fun.  And now we have the PTC SG with a PAR
(just a different set of challenges).  Thus I am working on the
network securing and authentication in 802.15.9 where I believe it
needs to live.  Oh and it looks like there is life still in 802.15.7
based on a presentation last week.

See people Sunday afternoon or later.


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

--
Standard Robert Moskowitz
Senior Technical Advisor
Security & Standards
Verizon Business Systems
C:      248-219-2059
F:      248-968-2824
E:      robert.moskowitz@verizonbusiness.com

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--------------080405070102000106000201-- From rgm@labs.htt-consult.com Fri Mar 23 01:53:19 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0AB21F8517 for ; Fri, 23 Mar 2012 01:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 jdPYeXWbrznX for ; Fri, 23 Mar 2012 01:53:17 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 91B9121F853A for ; Fri, 23 Mar 2012 01:53:17 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id B737562A6B for ; Fri, 23 Mar 2012 08:52:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fP0aYg73-mWv for ; Fri, 23 Mar 2012 04:52:37 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [77.241.230.246]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id C954362A96 for ; Fri, 23 Mar 2012 04:52:30 -0400 (EDT) Message-ID: <4F6C39C7.3060300@labs.htt-consult.com> Date: Fri, 23 Mar 2012 09:52:23 +0100 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: "core@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [core] Loading a sensor's identity and other bootstrap data X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 08:53:19 -0000 I am not an engineer and I do not know if anyone has patented this approach... The cost of loading identity information has to be weighed against the cost of a device without (if credentials are stolen is it cheaper to just by new?). Under water/acid/oil proof glue are two contacts. This glue can be removed with a razor blade, and the contacts shorted out. Once shorted out, for N seconds the sensor will accept a datagram with a key pair, perhaps an ECQV random secret, and other special bootstrap data. This needs to fit into one 127 byte frame (unless it is 15.4g capable). Perhaps the sensor will only allow this operation M times. So you work for an organization that doesnt' trust outsiders with its security, even its vendors. Or you had just pulled a door lock out of your neighbor's garbage. So you scrap off the glue, put the sensor and your PC (with 802.15.4 adapter and special bootstrap loading software) into a faraday cage. With probes in the cage, you short out the contacts, and press the enter key on the PC. Tada! New credentials in the sensor that you set! Take stuff out of the cage, and put fresh glue over the contacts and install the sensor in your network. If you live out in the countryside you can forego the faraday cage. ;) An alternative approach with a sensor that is powerful enough to gen keys and have a really good PRF: On shorting out the contacts, the sensor gens up fresh identity, random ECQV secret, etc. then sends them out at low power (but not the private key!). More secure; faraday cage is optional. But you need to trust the manufacturer in its ablity to perduce good key pairs and random numbers. Plus pay for the computing functionality on each sensor. Just sitting here in the KLM lounge in Schipol waiting for my friends to get home to go there for the Sabbath. Got to keep the mind busy on things other than real work and committed writing assignments! From robert.cragie@gridmerge.com Fri Mar 23 04:34:24 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF1321F850B for ; Fri, 23 Mar 2012 04:34:24 -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, 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 DouUny1-CAGH for ; Fri, 23 Mar 2012 04:34:19 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id ECEFB21F8503 for ; Fri, 23 Mar 2012 04:34:18 -0700 (PDT) Received: from client-86-29-160-245.brhm-bam-3.adsl.virginmedia.com ([86.29.160.245] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1SB2l5-0005H6-Nr for core@ietf.org; Fri, 23 Mar 2012 11:34:16 +0000 Message-ID: <4F6C600E.6050805@gridmerge.com> Date: Fri, 23 Mar 2012 11:35:42 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: core@ietf.org References: <4F6B5C32.50107@labs.htt-consult.com> <4F6B6A72.8010602@gmail.com> <4F6B7943.4040907@labs.htt-consult.com> In-Reply-To: <4F6B7943.4040907@labs.htt-consult.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050001020706010304010605" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [core] A 'new' view in use of RawPublicKeys in Core and elsewhere X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 11:34:24 -0000 This is a cryptographically signed message in MIME format. --------------ms050001020706010304010605 Content-Type: multipart/alternative; boundary="------------090100040609050405080501" This is a multi-part message in MIME format. --------------090100040609050405080501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Bob, Interesting discussion. I think one important distinction is that with a = programmable electronic device, it is possible to change its identity,=20 in spite of the fact the hardware may persist. I have as yet come across = this ability in human beings; no matter how much you eschew a former=20 moniker, you are still the same person. The Prince story is an=20 interesting one - he actually wanted to be known as a 'symbol' but in=20 practice (in the UK at least), he became 'TAFKAP' (The Artist Formerly=20 Known As Prince). However, he was still the same person - his=20 fingerprints would not have changed. This begs the question whether a programmable electronic device should=20 have an immutable identity. If based on public key cryptography, a raw=20 public key is the bare minimum, but a certificate has an advantage (when = use with PKI) of being able to carry additional information (including=20 another form of identity) which is attested by another trusted entity. A = self-signed certificate clearly cannot claim to have attestable fields=20 and therefore its properties revert to that of a raw public key. But the = cost may be worth it in having uniformity in operation. This immutable device identity should ideally just be used in that=20 context and additional tokens should be granted as appropriate for=20 further functionality. This is the premise of 802.1AR, with its secure=20 device identity concept. Regarding steering to the correct network - my view so far is that there = is probably no need to bust a gut on this. A simple shared secret (which = doesn't have to be particularly secret) is probably adequate, but one=20 which is not sent in the context of the wireless network it is=20 associated with, i.e. is commissioned out-of-band on the network=20 authentication server along with the identity of the joining device. The = identity of the joining device can be advertised by networks which are=20 looking for it, the joining device will then authenticate and this=20 secret is then sent at the end of authentication (secured) to the=20 joining device. So a honeypot may be able to advertise an eavesdropped=20 device identity and even complete authentication but it typically would=20 not have shared secret, so the joiner would reject it and look=20 elsewhere. I accept this scenario does not work for every situation but=20 is effective in the "ESI" (Energy Services Interface) in Smart Energy=20 scenario. Robert On 22/03/2012 7:10 PM, Robert Moskowitz wrote: > I have a 6:30am flight to get to so early to bed tonight, but I will=20 > try... > > > > On 03/22/2012 07:07 PM, Rene Struik wrote: >> Hi Bob: >> >> I have been struggling with the equation PubKey =3D Identity for a lon= g >> time and will continue to do so till someone can explain to me how one= >> can speak of "the" identity in this case in settings where the public >> key (or, for that matter, data associated with that public key) may >> change during the lifecycle of the device. Moreover, it may very well = be >> the case that initial public keys are only generated after the need to= >> communicate the identifier becomes available. > > In practice, all identities have an ephemeral quality. Eight days=20 > after my birth my parents named me Reuven Gershon ben Benyomin=20 > (spelled in Hebrew) and put on my birth certificate Robert Glenn=20 > Moskowitz. Now I did not see my birth certificate until I was 17 and=20 > from the age of 5, I was writing my english name as Robert Glen=20 > Moskowitz (that I still use for legal purposes). > > In school I was called Bob Moskowitz and at age 11 for the first time=20 > a classmate called (this was '61 and not a lot of phone calls were=20 > made even in suburbia, you WENT to the house) and asked appearently=20 > for Bob. My 7 year old sister had picked up the phone and I heard her = > side of the conversation, "Bob, there is no Bob here". Click. My=20 > family has always only known me as Robert. > > Premise #1: An Identity is ANYTHING you want as long as you can use=20 > it. (Think of the singer once known as Prince :) ). > > Corollary #1: A public key portion of a public/private key pair MAY=20 > be used as an identity in and of itself as long as you can use it. > > I can go on for hours and pages about namespaces (I was a member of=20 > the Namespace Research Group and sat through hours of philosophy of=20 > names and namespaces) and the role of textual, symbolic, and=20 > mathematical names. > > Premise #2: Something added MUST bring value commensurate with its=20 > cost. (well there is always bric-a-brac out there) > > Postulate #1: In M2M secure communications RawPublicKeys are=20 > sufficient in and of themselves, provided there is a mechanism to=20 > authenticate them within the domain of their use. Further the total=20 > system cost can be minimized by working with RawPublicKeys over other=20 > PublicKey methods. > > > Now are these RpkI provided at owner purchase time or build time? > Do they get changed to some concept of changing (ask me about the=20 > Jewish practice of adding to a critically sick person's name. Hint it = > is Mystical) or do they last as long as the silicon does? (or someone=20 > runs them through a microwave oven!) > > The answer to both is yes and no. You choose what works for you. =20 > (Premise #1) > > For myself, and what I recommend is that the common usage will be=20 > manufacture installed RpkI that last the life of the device. =20 > Recognizing that there are special customers out there that will want=20 > to install their own RpkI and will reprovision them as they deem=20 > necessary and will pay the freight. > > Good night. See you next week. Well I will pick up email in=20 > Amsterdam friday, and MAY reply. > >> Some deployment scenarios where public key related info may change ove= r >> time: >> 1) short-lived certificates (as would, e.g., be the case with ECQV >> certs, where the reconstructed public key depends on all data field of= >> the to-be-signed data, including public key reconstruction data and >> policy fields, such as key validity time period). >> 2) public keys certified by more than one entity (although I have not >> looked into this in detail, shouldn't one then bind the public key to >> the binding entity and not "cut the ties"?). >> 3) delegation of public keys, e.g., in the event one may authenticate >> via more than one device. >> >> To me, it seems that having a certificate provides for the binding of = an >> entity's identity to (the private key corresponding to) a public key, = so >> we have a mechanism that has been around for decades that allows >> definition of identities and public keys in orthogonal fashion, withou= >> hardcoding one in terms of the other. >> >> Isn't the real reason to bring this up then that one does not believe = in >> certificates, find them unmanageable, bulky, etc.? There are easy fixe= s >> here (e.g., short-lived certificates, which may take a whole cottage >> industry of CRL, OCSP etc. specs out of business), so I would suggest >> that would also be a valuable approach --- if my speculation on >> underlying cause of bringing up the PubKey =3D Identity "equation" has= >> some merit (I bet a bottle of Bordeaux there is some truth in this...)= =2E >> >> =3D=3D >> Some earlier CoRE traffic on this: >> >> {Hannes Tschofenig, December 20, 2011} >> http://www.ietf.org/mail-archive/web/core/current/msg02543.html >> >> {Rene Struik, Alper Yegin, December 19, 2012} >> http://www.ietf.org/mail-archive/web/core/current/msg02540.html >> >> On 22/03/2012 1:06 PM, Robert Moskowitz wrote: >>> First I am in Stockholm right now after a meeting with a Verizon ISV >>> (Wow, real company work :) ). I will be arriving in Paris sunday >>> noonish and leaving thursday afternoon. >>> >>> Second, what I am about to present has been the outgrowth of >>> conversations and emails during and after the IEEE 802 meeting last >>> week, from people in both 802.11ai and 802.15.9. >>> >>> Paul Lambert (Marvel) made a short presentation to the 802.11 wng >>> session on 'Key Centric Identity' to get the larger 802.11 community >>> into an understanding of discussions ongoing in 802.11ai, this is at:= >>> >>> https://mentor.ieee.org/802.11/dcn/12/11-12-0378-00-0wng-key-centric-= identity.ppt >>> >>> >>> Very short and to the point and content (other than the hash used as = a >>> local MAC address) should be familiar with people on this list. But = a >>> couple of key points is that the public key IS the identity and a has= h >>> of that key IS a powerful tool to authentication services. Now >>> although I am a big proponent of KCI for over 12 years, only recently= >>> have I worked out some key environmental portions and some still need= s >>> some work (as well as being ECC centric). >>> >>> Enough background. >>> >>> Premise: The sensor and a network service (To Be Named) both have >>> RawPublicKey Identities that are available in a hashed format. I wil= l >>> call these RpkI and RpkHI until someone gives me better generic >>> handles (I want to avoid HIP-style labels). >>> >>> Further the sensor's RpkHI and some other information (Some to be >>> discussed further down) will be printed on the sensor or on provided >>> paper in a QR code (probably v3 should be enough). The QR code will >>> be used to preload the network authentication server with the sensor'= s >>> identity as Paul shows. I will not discuss here (though I am >>> elsewhere) the protocol used by the network service and the >>> authentication service to retrieve valid sensor RpkHI. This >>> deployment method provides one side of the problem on how the network= >>> service accept a new sensor. >>> >>> For the other side, how does the sensor recognize the proper PAN and >>> service, I am going to introduce some things that are rather 'new' to= >>> me, and I may not have all the pieces right and so far I only know ho= w >>> to do this with EC identities like static ECDH (though ECDSA works as= >>> well). The piece here is ECQV, Implicit Certificates, that was just >>> shown to me last week by Andrei Gutov for his student, Jani Pellikka.= >>> Here the sensor vendor pre-loads the sensor with the random value nee= d >>> for the ECQV and places that in the QR code. The network >>> authentication server takes that and the network service identity and= >>> builds the ECQV to use in the KMP. It is ASSUMEd that only the >>> intended PAN has this information (thus there is a weakness of leakag= e >>> here for who scans the QR code). Now the sensor can validate the >>> RpkHI in the form of the ECQV it got. Not 100%, but much closer than= >>> anything else I have worked out. >>> >>> There is always the backoff and retry approach if the neighboring PAN= >>> is able to make the same ECQV (you picked the room thermometer out of= >>> your neighbor's garbage, shame on you). I also have only seen this >>> with ECC. >>> >>> I am in the process of working this out. Some of it I only really pu= t >>> together last week, and really the ECQV in this direction in this >>> manner only came to me a couple hours ago rereading the >>> 'RawPublicKeys' thread on this list. >>> >>> I offer this for your reading pleasure. I have my preferred KMP and = I >>> fully intend to pursue this, but I believe this will work with MOST >>> KMPs that implement support for RpkHI. >>> >>> Finally, I will point out what I view as obvious. The world of senso= r >>> networks is not all CoAP, let alone 6lowpan and even Zigbee. LECIM >>> (802.15.4k) looks to be fun. And now we have the PTC SG with a PAR >>> (just a different set of challenges). Thus I am working on the >>> network securing and authentication in 802.15.9 where I believe it >>> needs to live. Oh and it looks like there is life still in 802.15.7 >>> based on a presentation last week. >>> >>> See people Sunday afternoon or later. >>> >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core > > --=20 > Robert Moskowitz > Senior Technical Advisor > Security & Standards > Verizon Business Systems > C:248-219-2059 > F:248-968-2824 > E:robert.moskowitz@verizonbusiness.com > > There's no limit to what can be accomplished if it doesn't matter who=20 > gets the credit > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --------------090100040609050405080501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bob,

Interesting discussion. I think one important distinction is that with a programmable electronic device, it is possible to change its identity, in spite of the fact the hardware may persist. I have as yet come across this ability in human beings; no matter how much you eschew a former moniker, you are still the same person. The Prince story is an interesting one - he actually wanted to be known as a 'symbol' but in practice (in the UK at least), he became 'TAFKAP' (The Artist Formerly Known As Prince). However, he was still the same person - his fingerprints would not have changed.

This begs the question whether a programmable electronic device should have an immutable identity. If based on public key cryptography, a raw public key is the bare minimum, but a certificate has an advantage (when use with PKI) of being able to carry additional information (including another form of identity) which is attested by another trusted entity. A self-signed certificate clearly cannot claim to have attestable fields and therefore its properties revert to that of a raw public key. But the cost may be worth it in having uniformity in operation.

This immutable device identity should ideally just be used in that context and additional tokens should be granted as appropriate for further functionality. This is the premise of 802.1AR, with its secure device identity concept.

Regarding steering to the correct network - my view so far is that there is probably no need to bust a gut on this. A simple shared secret (which doesn't have to be particularly secret) is probably adequate, but one which is not sent in the context of the wireless network it is associated with, i.e. is commissioned out-of-band on the network authentication server along with the identity of the joining device. The identity of the joining device can be advertised by networks which are looking for it, the joining device will then authenticate and this secret is then sent at the end of authentication (secured) to the joining device. So a honeypot may be able to advertise an eavesdropped device identity and even complete authentication but it typically would not have shared secret, so the joiner would reject it and look elsewhere. I accept this scenario does not work for every situation but is effective in the "ESI" (Energy Services Interface) in Smart Energy scenario.

Robert

On 22/03/2012 7:10 PM, Robert Moskowitz wrote:
I have a 6:30am flight to get to so early to bed tonight, but I will try...



On 03/22/2012 07:07 PM, Rene Struik wrote: 
Hi Bob:

I have been struggling with the equation PubKey =3D Identity for a long
time and will continue to do so till someone can explain to me how one
can speak of "the" identity in this case in settings where the public
key (or, for that matter, data associated with that public key) may
change during the lifecycle of the device. Moreover, it may very well be
the case that initial public keys are only generated after the need to
communicate the identifier becomes available.

In practice, all identities have an ephemeral quality.  Eight = days after my birth my parents named me Reuven Gershon ben Benyomin (spelled in Hebrew) and put on my birth certificate Robert Glenn Moskowitz. Now I did not see my birth certificate until I was 17 and from the age of 5, I was writing my english name as Robert Glen Moskowitz (that I still use for legal purposes).

In school I was called Bob Moskowitz and at age 11 for the first time a classmate called (this was '61 and not a lot of phone calls were made even in suburbia, you WENT to the house) and asked appearently for Bob.  My 7 year old sister had picked up the p= hone and I heard her side of the conversation, "Bob, there is no Bob here". Click.  My family has always only known me as Robert.
Premise #1:  An Identity is ANYTHING you want as long as you c= an use it.  (Think of the singer once known as Prince :) ).

Corollary #1:  A public key portion of a public/private key pa= ir MAY be used as an identity in and of itself as long as you can use it.

I can go on for hours and pages about namespaces (I was a member of the Namespace Research Group and sat through hours of philosophy of names and namespaces) and the role of textual, symbolic, and mathematical names.

Premise #2:  Something added MUST bring value commensurate wit= h its cost. (well there is always bric-a-brac out there)

Postulate #1: In M2M secure communications RawPublicKeys are sufficient in and of themselves, provided there is a mechanism to authenticate them within the domain of their use.  Further the= total system cost can be minimized by working with RawPublicKeys over other PublicKey methods.


Now are these RpkI provided at owner purchase time or build time? Do they get changed to some concept of changing (ask me about the Jewish practice of adding to a critically sick person's name. = Hint it is Mystical) or do they last as long as the silicon does? (or someone runs them through a microwave oven!)

The answer to both is yes and no.  You choose what works for y= ou.  (Premise #1)

For myself, and what I recommend is that the common usage will be manufacture installed RpkI that last the life of the device.  Recognizing that there are special customers out there that will want to install their own RpkI and will reprovision them as they deem necessary and will pay the freight.

Good night.  See you next week.  Well I will pick up emai= l in Amsterdam friday, and MAY reply.

Some deployment scenarios where public key related info may change over
time:
1) short-lived certificates (as would, e.g., be the case with ECQV
certs, where the reconstructed public key depends on all data field of
the to-be-signed data, including public key reconstruction data and
policy fields, such as key validity time period).
2) public keys certified by more than one entity (although I have not
looked into this in detail, shouldn't one then bind the public key to
the binding entity and not "cut the ties"?).
3) delegation of public keys, e.g., in the event one may authenticate
via more than one device.

To me, it seems that having a certificate provides for the binding of an
entity's identity to (the private key corresponding to) a public key, so
we have a mechanism that has been around for decades that allows
definition of identities and public keys in orthogonal fashion, withou
hardcoding one in terms of the other.

Isn't the real reason to bring this up then that one does not believe in
certificates, find them unmanageable, bulky, etc.? There are easy fixes
here (e.g., short-lived certificates, which may take a whole cottage
industry of CRL, OCSP etc. specs out of business), so I would suggest
that would also be a valuable approach --- if my speculation on
underlying cause of bringing up the PubKey =3D Identity "equation" has
some merit (I bet a bottle of Bordeaux there is some truth in this...).

=3D=3D
Some earlier CoRE traffic on this:

{Hannes Tschofenig, December 20, 2011}
http://www.ie=
tf.org/mail-archive/web/core/current/msg02543.html

{Rene Struik, Alper Yegin, December 19, 2012}
http://www.ie=
tf.org/mail-archive/web/core/current/msg02540.html

On 22/03/2012 1:06 PM, Robert Moskowitz wrote:

First I am in Stockholm right now after a meetin=
g with a Verizon ISV
(Wow, real company work :) ).  I will be arriving in Paris sunday
noonish and leaving thursday afternoon.

Second, what I am about to present has been the outgrowth of
conversations and emails during and after the IEEE 802 meeting last
week, from people in both 802.11ai and 802.15.9.

Paul Lambert (Marvel) made a short presentation to the 802.11 wng
session on 'Key Centric Identity' to get the larger 802.11 community
into an understanding of discussions ongoing in 802.11ai, this is at:

https://mentor.ieee.org/802.11/dcn/12/11-12-0378-00-0wng-key-centric=
-identity.ppt


Very short and to the point and content (other than the hash used as a
local MAC address) should be familiar with people on this list.  But a
couple of key points is that the public key IS the identity and a hash
of that key IS a powerful tool to authentication services.  Now
although I am a big proponent of KCI for over 12 years, only recently
have I worked out some key environmental portions and some still needs
some work (as well as being ECC centric).

Enough background.

Premise:  The sensor and a network service (To Be Named) both have
RawPublicKey Identities that are available in a hashed format.  I will
call these RpkI and RpkHI until someone gives me better generic
handles (I want to avoid HIP-style labels).

Further the sensor's RpkHI and some other information (Some to be
discussed further down) will be printed on the sensor or on provided
paper in a QR code (probably v3 should be enough).  The QR code will
be used to preload the network authentication server with the sensor's
identity as Paul shows.  I will not discuss here (though I am
elsewhere) the protocol used by the network service and the
authentication service to retrieve valid sensor RpkHI.  This
deployment method provides one side of the problem on how the network
service accept a new sensor.

For the other side, how does the sensor recognize the proper PAN and
service, I am going to introduce some things that are rather 'new' to
me, and I may not have all the pieces right and so far I only know how
to do this with EC identities like static ECDH (though ECDSA works as
well).  The piece here is ECQV, Implicit Certificates, that was just
shown to me last week by Andrei Gutov for his student, Jani Pellikka.=20
Here the sensor vendor pre-loads the sensor with the random value need
for the ECQV and places that in the QR code.  The network
authentication server takes that and the network service identity and
builds the ECQV to use in the KMP.  It is ASSUMEd that only the
intended PAN has this information (thus there is a weakness of leakage
here for who scans the QR code).  Now the sensor can validate the
RpkHI in the form of the ECQV it got.  Not 100%, but much closer than
anything else I have worked out.

There is always the backoff and retry approach if the neighboring PAN
is able to make the same ECQV (you picked the room thermometer out of
your neighbor's garbage, shame on you).  I also have only seen this
with ECC.

I am in the process of working this out.  Some of it I only really put
together last week, and really the ECQV in this direction in this
manner only came to me a couple hours ago rereading the
'RawPublicKeys' thread on this list.

I offer this for your reading pleasure.  I have my preferred KMP and I
fully intend to pursue this, but I believe this will work with MOST
KMPs that implement support for RpkHI.

Finally, I will point out what I view as obvious.  The world of sensor
networks is not all CoAP, let alone 6lowpan and even Zigbee.  LECIM
(802.15.4k) looks to be fun.  And now we have the PTC SG with a PAR
(just a different set of challenges).  Thus I am working on the
network securing and authentication in 802.15.9 where I believe it
needs to live.  Oh and it looks like there is life still in 802.15.7
based on a presentation last week.

See people Sunday afternoon or later.


_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listi=
nfo/core


      

      

      
-- 

        
        Standard
        Robert Moskowitz

         Senior Technical Advisor

         Security & Standards

         Verizon Business Systems

        C:     &nb=
sp;248-219-2059

         F:     &nb=
sp;248-968-2824

         E:     &nb=
sp;robert.m=
oskowitz@verizonbusiness.com

        

         There's no limit to what can=

          be accomplished if it doesn't matter who gets the credit=


      

      

      

      

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


    

  


--------------090100040609050405080501--

--------------ms050001020706010304010605
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP3jCC
BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE
BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w
NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC
VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l
dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO
LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN
NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy
lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq
vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6
hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu
9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G
A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/
BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU
cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk
ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi
54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0
g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd
WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz
Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy
XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi
5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw
FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr
MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS
Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa
Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j
aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5
MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY
X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi
QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT
bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX
WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i
Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd
JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB
/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E
UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll
bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH
MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw
JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD
ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf
y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T
4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU
yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE
uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggYuMIIFFqAD
AgECAhBcMVDbxC2oy5hyHl/adO9mMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb
MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK
ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh
dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwMjAwMDAwMFoXDTE0MDkwMTIzNTk1
OVowggE3MQswCQYDVQQGEwJHQjEQMA4GA1UEERMHV0Y0IDRXQTEXMBUGA1UECBMOV2VzdCBZ
b3Jrc2hpcmUxEjAQBgNVBAcTCVdha2VmaWVsZDEUMBIGA1UECRMLR3JhbmdlIE1vb3IxHzAd
BgNVBAkTFjg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQxFzAVBgNVBAoTDkdyaWRtZXJnZSBMdGQu
MTQwMgYDVQQLEytJc3N1ZWQgdGhyb3VnaCBHcmlkbWVyZ2UgTHRkLiBFLVBLSSBNYW5hZ2Vy
MR8wHQYDVQQLExZDb3Jwb3JhdGUgU2VjdXJlIEVtYWlsMRYwFAYDVQQDEw1Sb2JlcnQgQ3Jh
Z2llMSowKAYJKoZIhvcNAQkBFhtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxOGq8t5ZTVDVkmadv7ZRBLA5ApaiTcDUzCTn
zYB2/BoBDIEWWI/InSRcmq3A0Ghm+T7dYmvRADllGv4nTHexdWlzFp2iM/Yc3PLWCyAO0gYb
yW2hTi+ZfUDwFOU4hRP4+Dyn9tKu7FXS/PQJHyGjaGxHRmLm9T6tAo2ZuC59uRaGVCcwRiOS
d6axwtB/DVhnP3S1rrt2g0O6MXLr5fojToemO52AxjHxt2w1LnFUUXC4EDV6o1Ctr7EvOEI5
5f088H/Mrryp02GueLdY9gb0SFK3gPOT7EjP2GPvCtRkhVcNM+xjyptRIFWnCbMjmUIc+DO6
sfU4rtbCCkNKyXmnAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBb
vHnFezAdBgNVHQ4EFgQUEI5c0f6UObxT2DLdvdtG+vG8qCswDgYDVR0PAQH/BAQDAgWgMAwG
A1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0w
OwYMKwYBBAGyMQECAQMFMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u
ZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E
T0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEB
BHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50
QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AuY29tb2RvY2EuY29tMCYGA1UdEQQfMB2BG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl
LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAPpv87QuQ9q+RHhmeirGDQB3szd24Obi7N+uVfh5y
CrnoJx3B37dNrLPsTB6PfTChUyZMqQD80pFoJ3TBUz3yx4X+hmNco7ujVIfbuKBGcZJaMKhZ
ex3AkZ9ltie9wgiGGzEmgI81t5JHsLQ8AUMqw/fGsnIwcyWMgmyhFtm79+dg3IVaH05d/t9g
k4aYoMoCFJptQZ+Fju6a9T139hOqjTZDpjMLt3jM80bVrvkC4dIRyF/oZ0qrJwbfwjnL2OUN
ph9eymhLc+VM0Ih5k41s5IxmB+2c0RUqr5JbK0WrIb/z53Cmb9rXYox7HknyIfBpQqP77Y7a
sAU2MMOpel4RijGCBAwwggQIAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl
YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg
TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMAkGBSsOAwIaBQCgggI4MBgGCSqGSIb3
DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMyMzExMzU0MlowIwYJKoZI
hvcNAQkEMRYEFHaEEsQ6pLikC2pu4JsmoJFZFauSMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr
DgMCBzANBggqhkiG9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJH
QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD
VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50
aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMIG7BgsqhkiG
9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3
BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD
QQIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0BAQEFAASCAQAaLZFKtZlUIaRXTFf8EbWA
E9br+Wjg3E++x9dMDn33MzLkxO8Kyu5urn5mnjs1RUq4AgRtdu8FVrIpTTjyynpNgra2qiEk
K2NAPrus7sc0vD7GaEy2En4rq4TWYVKhpOl4ZXalNtWSHCqd9W6kHuB1cJyqqm308CFCtmIw
3/VsiSdFld943sdmNVkehVYO03fuNOL+d00KNS+9YhQukxka+0UbG0pjKMR+2W4pnYKaLw1b
Wd+CNKCz/+Hg+nDx42gvjlcXEed1/QCgQt2OxPvQDAmEHGWIgarbT8iEa5rJAsSEtXit1JKr
sfeoAFOLekEn9qTXzySTMlGeHYrVmpJEAAAAAAAA
--------------ms050001020706010304010605--

From robert.cragie@gridmerge.com  Fri Mar 23 04:42:57 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1352421F8514 for ; Fri, 23 Mar 2012 04:42: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=[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 BfmMB+OiQjPi for ; Fri, 23 Mar 2012 04:42:56 -0700 (PDT)
Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEF721F8527 for ; Fri, 23 Mar 2012 04:42:54 -0700 (PDT)
Received: from client-86-29-160-245.brhm-bam-3.adsl.virginmedia.com ([86.29.160.245] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1SB2tR-0003GD-FO for core@ietf.org; Fri, 23 Mar 2012 11:42:53 +0000
Message-ID: <4F6C6214.8090700@gridmerge.com>
Date: Fri, 23 Mar 2012 11:44:20 +0000
From: Robert Cragie 
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: core@ietf.org
References: <20120214114904.GA8794@blackbox> <55D88CC8-EF12-4A29-8476-E22F1470B855@yegin.org> <20120321100901.GA15321@blackbox> <4F69ED25.6010705@gmail.com>
In-Reply-To: <4F69ED25.6010705@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050500070202070306020901"
X-Authenticated-As: robert.cragie@gridmerge.com
Subject: Re: [core] RawPublicKeys
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert.cragie@gridmerge.com
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Mar 2012 11:42:57 -0000

This is a cryptographically signed message in MIME format.

--------------ms050500070202070306020901
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Rene,

I agree with what you say and to Alper's point that certs. cannot be the =

only mechanism for authentication and thus implicit authorization. There =

invariably has to be some additional factor (human, OOB) and the=20
practicality of that factor depends on the scenario.

Apologies I couldn't make the workshop - it was announced quite late and =

I had already made plans. Hope to catch up with some of you in Paris to=20
discuss the findings.

Robert

On 21/03/2012 3:00 PM, Rene Struik wrote:
> Hi Johannes:
>
> Provisioning usually involves both authentication and authorization. Cr=
yptography takes care of the authentication aspects and would result in e=
vidence to each of the devices involved (imprinter, imprinted) of each ot=
her's identity {in case authentication would involve an authenticated pub=
lic-key key agreement scheme). Authorization can be dealt with via crypto=
graphic tools only if the authentication protocol would include exchange =
of credentials from which authorization privileges can be inferred (e.g.,=
 via incoding hereof in policy attributes of a certificate). For large sc=
ale networks, this is inflexible, since this requires coordination before=
hand. The more likely scenario would be to have some human decision eleme=
nt here, who influences authorization decisions, e.g., via
> (1) location-limited channel {Diana Smetters et al}: here, only devices=
 in close proximity would successfully complete the protocol, the idea be=
ing that the user can control devices lingering around close to devices i=
n play;
> (2) mechanism for communicating by device of true id of the other devic=
e it communicated with, e.g., via display, beep pattern, light flashes {b=
y bulb in question}, etc., followed by ack/nak by human (the infamous but=
ton-push scenario);
> (3) etc.
>
> Reset of a device to initial state is a transition in the trust lifecyc=
le of device and should be managed accordingly. As an example, pressing a=
 tiny reset button (similar to the one on my Wifi router at home) may not=
 provoke this reset, if my state machine transition is triggered by more =
than just physical access to the device and would require, e.g., receipt =
of a properly formatted command to reset from an authorized device (i.e.,=
 one with the proper device role privileges) as well (or by the latter on=
ly).
>
> We can discuss more Friday.
>
> Best regards, Rene
>
>
> =3D=3D
>
> The assumption here is that the Smart Object is in one of two global
> states: Imprintable or Imprinted. The rogue network can simply imprint
> itself in the Smart Object it if is able to reset the device or if it i=
s
> "faster" than the legitimate operator for the first imprinting process.=

>
> Both attack vectors can be controlled. If you buy a new lightbulb and i=
t
> does not listen to you, you will reset it and try imprinting again. At
> some point you'll hopefully succeed (because your neighbor gave up).
>
> If you have imprinted a device and don't want it to be reset, you have
> to take measures to prevent just that, like mounting the device so its
> inaccesible or simply omitting a reset button.
>
>
> On 21/03/2012 6:09 AM, Johannes Gilger wrote:
>> Hello Alper,
>>
>> thanks for your comments. I'll try to explain the point I was making
>> with the last mail. I do suspect my approaches to be naive, and would
>> like to learn about scenarios where they fail.
>>
>> On 21/03/12 11:22, Alper Yegin wrote:
>>>> In my understanding of the functionality of an interface-constrained=
 IoT
>>>> device, there is no need for the node to identify the network.
>>> I can understand "it's not possible", or "it's difficult". But I don'=
t understand how "there is no need."
>>> Device needs to know it's connected to the right "server"
>>> (being right involves being authenticated and authorized, two really =
separate things).
>> Yes, for some devices that is true. Lets take for example a plain
>> lightbulb (with Smart Object capabilities) and a Smart Meter which is
>> installed by a utility.
>>
>> The lightbulb has no owner until it is bought and taken from the shelf=
=2E
>> The owner then wants to make sure that the lightbulb listens to him, a=
nd
>> not to his neighbor. The lightbulb does not (and can not) care about
>> "who" is switching it off and on, so long as it is the same person whi=
ch
>> first associated with it.
>>
>> For a Smart Meter, the relationship might look different on the surfac=
e.
>> After all, a Smart Meter installed at at customers home should only ta=
lk
>> to the correct utility. But then again, when the utility acquires the
>> Smart Meter from the manufacturer, it could imprint and use it like a
>> lightbulb, before installing it at the customer.
>>
>>>> The only thing that matters is that the network can identify the nod=
e
>>>> (as has been discussed) and that the network can ensure that it is t=
he
>>>> only one able to command the node.
>>> So, a rogue network can do that. "Identify" the victim device, and re=
ad from it and write into it.
>>> This is obviously not acceptable.
>> The assumption here is that the Smart Object is in one of two global
>> states: Imprintable or Imprinted. The rogue network can simply imprint=

>> itself in the Smart Object it if is able to reset the device or if it =
is
>> "faster" than the legitimate operator for the first imprinting process=
=2E
>>
>> Both attack vectors can be controlled. If you buy a new lightbulb and =
it
>> does not listen to you, you will reset it and try imprinting again. At=

>> some point you'll hopefully succeed (because your neighbor gave up).
>>
>> If you have imprinted a device and don't want it to be reset, you have=

>> to take measures to prevent just that, like mounting the device so its=

>> inaccesible or simply omitting a reset button.
>>
>>>> Why not? Looking at the Resurrecting Duckling again, the device will=

>>>> talk to anyone when its in the "imprintable" state. After it has bee=
n
>>>> imprinted by an authority (hopefully the right one, or you'll have t=
o
>>>> reset the device and try again),
>>> So, knowing the "right one" is the issue.
>>> Who's going to detect this is the wrong one and reset the device? The=
 user.
>>> We cannot assume user will detect and act upon it, if you consider th=
e wide range of IoT use cases.
>>> Users are rarely involved, especially in that capacity.
>> I am not sure. What is probably clouding my judgement is that I know s=
o
>> few actual end-to-end real-world applications for Smart Objects, which=
 I
>> hope will change with the Smart Object Security workshop.
>>
>> Regards,
>> Jojo
>>
>


--------------ms050500070202070306020901
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP3jCC
BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE
BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w
NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC
VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l
dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO
LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN
NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy
lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq
vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6
hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu
9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G
A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/
BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU
cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk
ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi
54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0
g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd
WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz
Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy
XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi
5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw
FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr
MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS
Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa
Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j
aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5
MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY
X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi
QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT
bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX
WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i
Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd
JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB
/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E
UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll
bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH
MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw
JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD
ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf
y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T
4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU
yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE
uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggYuMIIFFqAD
AgECAhBcMVDbxC2oy5hyHl/adO9mMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb
MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK
ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh
dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwMjAwMDAwMFoXDTE0MDkwMTIzNTk1
OVowggE3MQswCQYDVQQGEwJHQjEQMA4GA1UEERMHV0Y0IDRXQTEXMBUGA1UECBMOV2VzdCBZ
b3Jrc2hpcmUxEjAQBgNVBAcTCVdha2VmaWVsZDEUMBIGA1UECRMLR3JhbmdlIE1vb3IxHzAd
BgNVBAkTFjg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQxFzAVBgNVBAoTDkdyaWRtZXJnZSBMdGQu
MTQwMgYDVQQLEytJc3N1ZWQgdGhyb3VnaCBHcmlkbWVyZ2UgTHRkLiBFLVBLSSBNYW5hZ2Vy
MR8wHQYDVQQLExZDb3Jwb3JhdGUgU2VjdXJlIEVtYWlsMRYwFAYDVQQDEw1Sb2JlcnQgQ3Jh
Z2llMSowKAYJKoZIhvcNAQkBFhtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxOGq8t5ZTVDVkmadv7ZRBLA5ApaiTcDUzCTn
zYB2/BoBDIEWWI/InSRcmq3A0Ghm+T7dYmvRADllGv4nTHexdWlzFp2iM/Yc3PLWCyAO0gYb
yW2hTi+ZfUDwFOU4hRP4+Dyn9tKu7FXS/PQJHyGjaGxHRmLm9T6tAo2ZuC59uRaGVCcwRiOS
d6axwtB/DVhnP3S1rrt2g0O6MXLr5fojToemO52AxjHxt2w1LnFUUXC4EDV6o1Ctr7EvOEI5
5f088H/Mrryp02GueLdY9gb0SFK3gPOT7EjP2GPvCtRkhVcNM+xjyptRIFWnCbMjmUIc+DO6
sfU4rtbCCkNKyXmnAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBb
vHnFezAdBgNVHQ4EFgQUEI5c0f6UObxT2DLdvdtG+vG8qCswDgYDVR0PAQH/BAQDAgWgMAwG
A1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0w
OwYMKwYBBAGyMQECAQMFMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u
ZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E
T0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEB
BHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50
QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AuY29tb2RvY2EuY29tMCYGA1UdEQQfMB2BG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl
LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAPpv87QuQ9q+RHhmeirGDQB3szd24Obi7N+uVfh5y
CrnoJx3B37dNrLPsTB6PfTChUyZMqQD80pFoJ3TBUz3yx4X+hmNco7ujVIfbuKBGcZJaMKhZ
ex3AkZ9ltie9wgiGGzEmgI81t5JHsLQ8AUMqw/fGsnIwcyWMgmyhFtm79+dg3IVaH05d/t9g
k4aYoMoCFJptQZ+Fju6a9T139hOqjTZDpjMLt3jM80bVrvkC4dIRyF/oZ0qrJwbfwjnL2OUN
ph9eymhLc+VM0Ih5k41s5IxmB+2c0RUqr5JbK0WrIb/z53Cmb9rXYox7HknyIfBpQqP77Y7a
sAU2MMOpel4RijGCBAwwggQIAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl
YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg
TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj
dXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMAkGBSsOAwIaBQCgggI4MBgGCSqGSIb3
DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMyMzExNDQyMFowIwYJKoZI
hvcNAQkEMRYEFCaecxveuAHKJh7mkDog8USD3/0ZMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr
DgMCBzANBggqhkiG9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJH
QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD
VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50
aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMIG7BgsqhkiG
9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3
BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD
QQIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0BAQEFAASCAQCjZXILDqtxEV3WV6Exk9L/
9lZ0woUk6k+MQAbUwchRPJHu9UPHg4FgndMQOa+vqK966pgaNziAVQlCFVDcCnToFWqGWDiC
l50WqFhE7mD7o56NlOnj2z+PVx78GjPHwzEYISF9OTCKemjnMOuKYCYiAzG8QJh/5uCMaARX
r/X0hItKQdzlMHslwIRuWdQzmayaaYmLqmYc6/ZDGAEg1s3EcX9H6CKrtXlAwRMtN8k19LZ2
LsPnlfqxEj25VPFQqjOzsaAZ5jWeqLTi+82DBV0stdwW72ZPvtK1ldx704Vry5RpZwQp9aIX
u55gJLd1PBHtn5+D3X8QWqbzePVP/4wTAAAAAAAA
--------------ms050500070202070306020901--

From rgm@labs.htt-consult.com  Fri Mar 23 09:37:59 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79F821F8582 for ; Fri, 23 Mar 2012 09:37:59 -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, 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 Anv1R3SPhS3V for ; Fri, 23 Mar 2012 09:37:55 -0700 (PDT)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by ietfa.amsl.com (Postfix) with ESMTP id 501AA21F858E for ; Fri, 23 Mar 2012 09:37:54 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 4267162A6F; Fri, 23 Mar 2012 16:37:25 +0000 (UTC)
X-Virus-Scanned: amavisd-new at localhost
Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pib+b1xudNOl; Fri, 23 Mar 2012 12:37:02 -0400 (EDT)
Received: from lx120e.htt-consult.com (s5147c637.adsl.wanadoo.nl [81.71.198.55]) (Authenticated sender: rgm@labs.htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPA id 51C1562A6E; Fri, 23 Mar 2012 12:36:58 -0400 (EDT)
Message-ID: <4F6CA69E.9050202@labs.htt-consult.com>
Date: Fri, 23 Mar 2012 17:36:46 +0100
From: Robert Moskowitz 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: robert.cragie@gridmerge.com
References: <4F6B5C32.50107@labs.htt-consult.com> <4F6B6A72.8010602@gmail.com> <4F6B7943.4040907@labs.htt-consult.com> <4F6C600E.6050805@gridmerge.com>
In-Reply-To: <4F6C600E.6050805@gridmerge.com>
Content-Type: multipart/alternative; boundary="------------090606030308000609060706"
Cc: core@ietf.org
Subject: Re: [core] A 'new' view in use of RawPublicKeys in Core and elsewhere
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 23 Mar 2012 16:37:59 -0000

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



On 03/23/2012 12:35 PM, Robert Cragie wrote:
> Bob,
>
> Interesting discussion. I think one important distinction is that with 
> a programmable electronic device, it is possible to change its 
> identity, in spite of the fact the hardware may persist. I have as yet 
> come across this ability in human beings; no matter how much you 
> eschew a former moniker, you are still the same person. The Prince 
> story is an interesting one - he actually wanted to be known as a 
> 'symbol' but in practice (in the UK at least), he became 'TAFKAP' (The 
> Artist Formerly Known As Prince). However, he was still the same 
> person - his fingerprints would not have changed.

Oh, I am aware of more cases, including ones that alter base bio 
signatures (police have long had to deal with altered fingerprints), but 
no need.  Rather I wanted to get people to see my position that an 
'thing' is useful as an identity if you have a way to use it.  And it 
may be used only in a limited context.

>
> This begs the question whether a programmable electronic device should 
> have an immutable identity. If based on public key cryptography, a raw 
> public key is the bare minimum, but a certificate has an advantage 
> (when use with PKI) of being able to carry additional information 
> (including another form of identity) which is attested by another 
> trusted entity. A self-signed certificate clearly cannot claim to have 
> attestable fields and therefore its properties revert to that of a raw 
> public key. But the cost may be worth it in having uniformity in 
> operation.

There are sensor scenarios where a certificate brings value and there 
scenarios where they don't  I just don't see the value of a certificate 
in a thermometer or a light switch.  Granted they have additional 
information like what room are they in, but that binding does not need 
to be placed in a cert.

I am NOT against certs or PKI, I have enough history with them to know 
that there are scenarios that can only be met with certs.  But likewise 
I want to see the non-cert pk, ie RawPublicKey, approah be provided for 
as well.

Now think about LECIM where the local DOT is imbedding hundreds of 
sensors in the roadbed that will communicate with the controller up to 
10KM away (look at the 15.4k PAR).  We don't want a malicious person 
claiming that the road is icy when it is clear; trusted identity is 
valueable here.  But considering the various factors, what does the 
sensor need in it and what can be handled in the app as provisioning?

In PTC, how much time does the train have to validate the identity of a 
sensor?  Granted there are only 25,000 trains on the US system and we 
can throw an extra $1000 into computing power on each train.  But what 
about the gate crossing actuator?  Implicit Certs like ECQV can make a 
real difference.

The real point here is we cannot forecast all the uses.  We do know 
there are very constrained uses.  We are encouraged to see how small can 
we go.  Rule #12 in RFC 1925, perhaps.

>
> This immutable device identity should ideally just be used in that 
> context and additional tokens should be granted as appropriate for 
> further functionality. This is the premise of 802.1AR, with its secure 
> device identity concept.

I know, I worked early on on 1AR.  It again has applicability, but how 
does a homeowner that has minimual computer skills load one with their 
specific needs into the light switch for the back hallway?  Put the 
information into the AAA server.  Actually I like LDAP over AAA, but 
that opens yet another can of worms.

>
> Regarding steering to the correct network - my view so far is that 
> there is probably no need to bust a gut on this. A simple shared 
> secret (which doesn't have to be particularly secret) is probably 
> adequate, but one which is not sent in the context of the wireless 
> network it is associated with, i.e. is commissioned out-of-band on the 
> network authentication server along with the identity of the joining 
> device. The identity of the joining device can be advertised by 
> networks which are looking for it, the joining device will then 
> authenticate and this secret is then sent at the end of authentication 
> (secured) to the joining device. So a honeypot may be able to 
> advertise an eavesdropped device identity and even complete 
> authentication but it typically would not have shared secret, so the 
> joiner would reject it and look elsewhere. I accept this scenario does 
> not work for every situation but is effective in the "ESI" (Energy 
> Services Interface) in Smart Energy scenario.

No way to get the shared secret into a light switch.  So the light 
switch comes with a joining password, if you will. This password can be 
used within the KMO as a password, or in SAE, or ECQV.

There are sensors that can be provisioned before installed, and there 
are those that can't.

>
> Robert
>
> On 22/03/2012 7:10 PM, Robert Moskowitz wrote:
>> I have a 6:30am flight to get to so early to bed tonight, but I will 
>> try...
>>
>>
>>
>> On 03/22/2012 07:07 PM, Rene Struik wrote:
>>> Hi Bob:
>>>
>>> I have been struggling with the equation PubKey = Identity for a long
>>> time and will continue to do so till someone can explain to me how one
>>> can speak of "the" identity in this case in settings where the public
>>> key (or, for that matter, data associated with that public key) may
>>> change during the lifecycle of the device. Moreover, it may very well be
>>> the case that initial public keys are only generated after the need to
>>> communicate the identifier becomes available.
>>
>> In practice, all identities have an ephemeral quality.  Eight days 
>> after my birth my parents named me Reuven Gershon ben Benyomin 
>> (spelled in Hebrew) and put on my birth certificate Robert Glenn 
>> Moskowitz. Now I did not see my birth certificate until I was 17 and 
>> from the age of 5, I was writing my english name as Robert Glen 
>> Moskowitz (that I still use for legal purposes).
>>
>> In school I was called Bob Moskowitz and at age 11 for the first time 
>> a classmate called (this was '61 and not a lot of phone calls were 
>> made even in suburbia, you WENT to the house) and asked appearently 
>> for Bob.  My 7 year old sister had picked up the phone and I heard 
>> her side of the conversation, "Bob, there is no Bob here". Click.  My 
>> family has always only known me as Robert.
>>
>> Premise #1:  An Identity is ANYTHING you want as long as you can use 
>> it.  (Think of the singer once known as Prince :) ).
>>
>> Corollary #1:  A public key portion of a public/private key pair MAY 
>> be used as an identity in and of itself as long as you can use it.
>>
>> I can go on for hours and pages about namespaces (I was a member of 
>> the Namespace Research Group and sat through hours of philosophy of 
>> names and namespaces) and the role of textual, symbolic, and 
>> mathematical names.
>>
>> Premise #2:  Something added MUST bring value commensurate with its 
>> cost. (well there is always bric-a-brac out there)
>>
>> Postulate #1: In M2M secure communications RawPublicKeys are 
>> sufficient in and of themselves, provided there is a mechanism to 
>> authenticate them within the domain of their use.  Further the total 
>> system cost can be minimized by working with RawPublicKeys over other 
>> PublicKey methods.
>>
>>
>> Now are these RpkI provided at owner purchase time or build time?
>> Do they get changed to some concept of changing (ask me about the 
>> Jewish practice of adding to a critically sick person's name.  Hint 
>> it is Mystical) or do they last as long as the silicon does? (or 
>> someone runs them through a microwave oven!)
>>
>> The answer to both is yes and no.  You choose what works for you.  
>> (Premise #1)
>>
>> For myself, and what I recommend is that the common usage will be 
>> manufacture installed RpkI that last the life of the device.  
>> Recognizing that there are special customers out there that will want 
>> to install their own RpkI and will reprovision them as they deem 
>> necessary and will pay the freight.
>>
>> Good night.  See you next week.  Well I will pick up email in 
>> Amsterdam friday, and MAY reply.
>>
>>> Some deployment scenarios where public key related info may change over
>>> time:
>>> 1) short-lived certificates (as would, e.g., be the case with ECQV
>>> certs, where the reconstructed public key depends on all data field of
>>> the to-be-signed data, including public key reconstruction data and
>>> policy fields, such as key validity time period).
>>> 2) public keys certified by more than one entity (although I have not
>>> looked into this in detail, shouldn't one then bind the public key to
>>> the binding entity and not "cut the ties"?).
>>> 3) delegation of public keys, e.g., in the event one may authenticate
>>> via more than one device.
>>>
>>> To me, it seems that having a certificate provides for the binding of an
>>> entity's identity to (the private key corresponding to) a public key, so
>>> we have a mechanism that has been around for decades that allows
>>> definition of identities and public keys in orthogonal fashion, withou
>>> hardcoding one in terms of the other.
>>>
>>> Isn't the real reason to bring this up then that one does not believe in
>>> certificates, find them unmanageable, bulky, etc.? There are easy fixes
>>> here (e.g., short-lived certificates, which may take a whole cottage
>>> industry of CRL, OCSP etc. specs out of business), so I would suggest
>>> that would also be a valuable approach --- if my speculation on
>>> underlying cause of bringing up the PubKey = Identity "equation" has
>>> some merit (I bet a bottle of Bordeaux there is some truth in this...).
>>>
>>> ==
>>> Some earlier CoRE traffic on this:
>>>
>>> {Hannes Tschofenig, December 20, 2011}
>>> http://www.ietf.org/mail-archive/web/core/current/msg02543.html
>>>
>>> {Rene Struik, Alper Yegin, December 19, 2012}
>>> http://www.ietf.org/mail-archive/web/core/current/msg02540.html
>>>
>>> On 22/03/2012 1:06 PM, Robert Moskowitz wrote:
>>>> First I am in Stockholm right now after a meeting with a Verizon ISV
>>>> (Wow, real company work :) ).  I will be arriving in Paris sunday
>>>> noonish and leaving thursday afternoon.
>>>>
>>>> Second, what I am about to present has been the outgrowth of
>>>> conversations and emails during and after the IEEE 802 meeting last
>>>> week, from people in both 802.11ai and 802.15.9.
>>>>
>>>> Paul Lambert (Marvel) made a short presentation to the 802.11 wng
>>>> session on 'Key Centric Identity' to get the larger 802.11 community
>>>> into an understanding of discussions ongoing in 802.11ai, this is at:
>>>>
>>>> https://mentor.ieee.org/802.11/dcn/12/11-12-0378-00-0wng-key-centric-identity.ppt
>>>>
>>>>
>>>> Very short and to the point and content (other than the hash used as a
>>>> local MAC address) should be familiar with people on this list.  But a
>>>> couple of key points is that the public key IS the identity and a hash
>>>> of that key IS a powerful tool to authentication services.  Now
>>>> although I am a big proponent of KCI for over 12 years, only recently
>>>> have I worked out some key environmental portions and some still needs
>>>> some work (as well as being ECC centric).
>>>>
>>>> Enough background.
>>>>
>>>> Premise:  The sensor and a network service (To Be Named) both have
>>>> RawPublicKey Identities that are available in a hashed format.  I will
>>>> call these RpkI and RpkHI until someone gives me better generic
>>>> handles (I want to avoid HIP-style labels).
>>>>
>>>> Further the sensor's RpkHI and some other information (Some to be
>>>> discussed further down) will be printed on the sensor or on provided
>>>> paper in a QR code (probably v3 should be enough).  The QR code will
>>>> be used to preload the network authentication server with the sensor's
>>>> identity as Paul shows.  I will not discuss here (though I am
>>>> elsewhere) the protocol used by the network service and the
>>>> authentication service to retrieve valid sensor RpkHI.  This
>>>> deployment method provides one side of the problem on how the network
>>>> service accept a new sensor.
>>>>
>>>> For the other side, how does the sensor recognize the proper PAN and
>>>> service, I am going to introduce some things that are rather 'new' to
>>>> me, and I may not have all the pieces right and so far I only know how
>>>> to do this with EC identities like static ECDH (though ECDSA works as
>>>> well).  The piece here is ECQV, Implicit Certificates, that was just
>>>> shown to me last week by Andrei Gutov for his student, Jani Pellikka.
>>>> Here the sensor vendor pre-loads the sensor with the random value need
>>>> for the ECQV and places that in the QR code.  The network
>>>> authentication server takes that and the network service identity and
>>>> builds the ECQV to use in the KMP.  It is ASSUMEd that only the
>>>> intended PAN has this information (thus there is a weakness of leakage
>>>> here for who scans the QR code).  Now the sensor can validate the
>>>> RpkHI in the form of the ECQV it got.  Not 100%, but much closer than
>>>> anything else I have worked out.
>>>>
>>>> There is always the backoff and retry approach if the neighboring PAN
>>>> is able to make the same ECQV (you picked the room thermometer out of
>>>> your neighbor's garbage, shame on you).  I also have only seen this
>>>> with ECC.
>>>>
>>>> I am in the process of working this out.  Some of it I only really put
>>>> together last week, and really the ECQV in this direction in this
>>>> manner only came to me a couple hours ago rereading the
>>>> 'RawPublicKeys' thread on this list.
>>>>
>>>> I offer this for your reading pleasure.  I have my preferred KMP and I
>>>> fully intend to pursue this, but I believe this will work with MOST
>>>> KMPs that implement support for RpkHI.
>>>>
>>>> Finally, I will point out what I view as obvious.  The world of sensor
>>>> networks is not all CoAP, let alone 6lowpan and even Zigbee.  LECIM
>>>> (802.15.4k) looks to be fun.  And now we have the PTC SG with a PAR
>>>> (just a different set of challenges).  Thus I am working on the
>>>> network securing and authentication in 802.15.9 where I believe it
>>>> needs to live.  Oh and it looks like there is life still in 802.15.7
>>>> based on a presentation last week.
>>>>
>>>> See people Sunday afternoon or later.
>>>>
>>>>
>>>> _______________________________________________
>>>> core mailing list
>>>> core@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/core
>>
>> -- 
>> Robert Moskowitz
>> Senior Technical Advisor
>> Security & Standards
>> Verizon Business Systems
>> C:248-219-2059
>> F:248-968-2824
>> E:robert.moskowitz@verizonbusiness.com
>>
>> There's no limit to what can be accomplished if it doesn't matter who 
>> gets the credit
>>
>>
>> _______________________________________________
>> 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

-- 
Robert Moskowitz
Senior Technical Advisor
Security & Standards
Verizon Business Systems
C:248-219-2059
F:248-968-2824
E:robert.moskowitz@verizonbusiness.com

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

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


  
    
  
  
    

    

    On 03/23/2012 12:35 PM, Robert Cragie wrote:
    

      
      Bob,

      

      Interesting discussion. I think one important distinction is that
      with a programmable electronic device, it is possible to change
      its identity, in spite of the fact the hardware may persist. I
      have as yet come across this ability in human beings; no matter
      how much you eschew a former moniker, you are still the same
      person. The Prince story is an interesting one - he actually
      wanted to be known as a 'symbol' but in practice (in the UK at
      least), he became 'TAFKAP' (The Artist Formerly Known As Prince).
      However, he was still the same person - his fingerprints would not
      have changed.

    

    

    Oh, I am aware of more cases, including ones that alter base bio
    signatures (police have long had to deal with altered fingerprints),
    but no need.  Rather I wanted to get people to see my position that
    an 'thing' is useful as an identity if you have a way to use it. 
    And it may be used only in a limited context.

    

    
 

      This begs the question whether a programmable electronic device
      should have an immutable identity. If based on public key
      cryptography, a raw public key is the bare minimum, but a
      certificate has an advantage (when use with PKI) of being able to
      carry additional information (including another form of identity)
      which is attested by another trusted entity. A self-signed
      certificate clearly cannot claim to have attestable fields and
      therefore its properties revert to that of a raw public key. But
      the cost may be worth it in having uniformity in operation.

    

    

    There are sensor scenarios where a certificate brings value and
    there scenarios where they don't  I just don't see the value of a
    certificate in a thermometer or a light switch.  Granted they have
    additional information like what room are they in, but that binding
    does not need to be placed in a cert.

    

    I am NOT against certs or PKI, I have enough history with them to
    know that there are scenarios that can only be met with certs.  But
    likewise I want to see the non-cert pk, ie RawPublicKey, approah be
    provided for as well.

    

    Now think about LECIM where the local DOT is imbedding hundreds of
    sensors in the roadbed that will communicate with the controller up
    to 10KM away (look at the 15.4k PAR).  We don't want a malicious
    person claiming that the road is icy when it is clear; trusted
    identity is valueable here.  But considering the various factors,
    what does the sensor need in it and what can be handled in the app
    as provisioning?

    

    In PTC, how much time does the train have to validate the identity
    of a sensor?  Granted there are only 25,000 trains on the US system
    and we can throw an extra $1000 into computing power on each train. 
    But what about the gate crossing actuator?  Implicit Certs like ECQV
    can make a real difference.

    

    The real point here is we cannot forecast all the uses.  We do know
    there are very constrained uses.  We are encouraged to see how small
    can we go.  Rule #12 in RFC 1925, perhaps.

    

    
 

      This immutable device identity should ideally just be used in that
      context and additional tokens should be granted as appropriate for
      further functionality. This is the premise of 802.1AR, with its
      secure device identity concept.

    

    

    I know, I worked early on on 1AR.  It again has applicability, but
    how does a homeowner that has minimual computer skills load one with
    their specific needs into the light switch for the back hallway? 
    Put the information into the AAA server.  Actually I like LDAP over
    AAA, but that opens yet another can of worms.

    

    
 

      Regarding steering to the correct network - my view so far is that
      there is probably no need to bust a gut on this. A simple shared
      secret (which doesn't have to be particularly secret) is probably
      adequate, but one which is not sent in the context of the wireless
      network it is associated with, i.e. is commissioned out-of-band on
      the network authentication server along with the identity of the
      joining device. The identity of the joining device can be
      advertised by networks which are looking for it, the joining
      device will then authenticate and this secret is then sent at the
      end of authentication (secured) to the joining device. So a
      honeypot may be able to advertise an eavesdropped device identity
      and even complete authentication but it typically would not have
      shared secret, so the joiner would reject it and look elsewhere. I
      accept this scenario does not work for every situation but is
      effective in the "ESI" (Energy Services Interface) in Smart Energy
      scenario.

    

    

    No way to get the shared secret into a light switch.  So the light
    switch comes with a joining password, if you will. This password can
    be used within the KMO as a password, or in SAE, or ECQV.

    

    There are sensors that can be provisioned before installed, and
    there are those that can't.

    

    
 

      Robert

      

      On 22/03/2012 7:10 PM, Robert Moskowitz wrote:
      

        
        I have a 6:30am flight to get to so early to bed tonight, but I
        will try...

        

        

        

        On 03/22/2012 07:07 PM, Rene Struik wrote:
        

          
Hi Bob:

I have been struggling with the equation PubKey = Identity for a long
time and will continue to do so till someone can explain to me how one
can speak of "the" identity in this case in settings where the public
key (or, for that matter, data associated with that public key) may
change during the lifecycle of the device. Moreover, it may very well be
the case that initial public keys are only generated after the need to
communicate the identifier becomes available.

        

        

        In practice, all identities have an ephemeral quality.  Eight
        days after my birth my parents named me Reuven Gershon ben
        Benyomin (spelled in Hebrew) and put on my birth certificate
        Robert Glenn Moskowitz. Now I did not see my birth certificate
        until I was 17 and from the age of 5, I was writing my english
        name as Robert Glen Moskowitz (that I still use for legal
        purposes).

        

        In school I was called Bob Moskowitz and at age 11 for the first
        time a classmate called (this was '61 and not a lot of phone
        calls were made even in suburbia, you WENT to the house) and
        asked appearently for Bob.  My 7 year old sister had picked up
        the phone and I heard her side of the conversation, "Bob, there
        is no Bob here". Click.  My family has always only known me as
        Robert.

        

        Premise #1:  An Identity is ANYTHING you want as long as you can
        use it.  (Think of the singer once known as Prince :) ).

        

        Corollary #1:  A public key portion of a public/private key pair
        MAY be used as an identity in and of itself as long as you can
        use it.

        

        I can go on for hours and pages about namespaces (I was a member
        of the Namespace Research Group and sat through hours of
        philosophy of names and namespaces) and the role of textual,
        symbolic, and mathematical names.

        

        Premise #2:  Something added MUST bring value commensurate with
        its cost. (well there is always bric-a-brac out there)

        

        Postulate #1: In M2M secure communications RawPublicKeys are
        sufficient in and of themselves, provided there is a mechanism
        to authenticate them within the domain of their use.  Further
        the total system cost can be minimized by working with
        RawPublicKeys over other PublicKey methods.

        

        

        Now are these RpkI provided at owner purchase time or build
        time?

        Do they get changed to some concept of changing (ask me about
        the Jewish practice of adding to a critically sick person's
        name.  Hint it is Mystical) or do they last as long as the
        silicon does? (or someone runs them through a microwave oven!)

        

        The answer to both is yes and no.  You choose what works for
        you.  (Premise #1)

        

        For myself, and what I recommend is that the common usage will
        be manufacture installed RpkI that last the life of the device. 
        Recognizing that there are special customers out there that will
        want to install their own RpkI and will reprovision them as they
        deem necessary and will pay the freight.

        

        Good night.  See you next week.  Well I will pick up email in
        Amsterdam friday, and MAY reply.

        

        

          
Some deployment scenarios where public key related info may change over
time:
1) short-lived certificates (as would, e.g., be the case with ECQV
certs, where the reconstructed public key depends on all data field of
the to-be-signed data, including public key reconstruction data and
policy fields, such as key validity time period).
2) public keys certified by more than one entity (although I have not
looked into this in detail, shouldn't one then bind the public key to
the binding entity and not "cut the ties"?).
3) delegation of public keys, e.g., in the event one may authenticate
via more than one device.

To me, it seems that having a certificate provides for the binding of an
entity's identity to (the private key corresponding to) a public key, so
we have a mechanism that has been around for decades that allows
definition of identities and public keys in orthogonal fashion, withou
hardcoding one in terms of the other.

Isn't the real reason to bring this up then that one does not believe in
certificates, find them unmanageable, bulky, etc.? There are easy fixes
here (e.g., short-lived certificates, which may take a whole cottage
industry of CRL, OCSP etc. specs out of business), so I would suggest
that would also be a valuable approach --- if my speculation on
underlying cause of bringing up the PubKey = Identity "equation" has
some merit (I bet a bottle of Bordeaux there is some truth in this...).

==
Some earlier CoRE traffic on this:

{Hannes Tschofenig, December 20, 2011}
http://www.ietf.org/mail-archive/web/core/current/msg02543.html

{Rene Struik, Alper Yegin, December 19, 2012}
http://www.ietf.org/mail-archive/web/core/current/msg02540.html

On 22/03/2012 1:06 PM, Robert Moskowitz wrote:


          

            
First I am in Stockholm right now after a meeting with a Verizon ISV
(Wow, real company work :) ).  I will be arriving in Paris sunday
noonish and leaving thursday afternoon.

Second, what I am about to present has been the outgrowth of
conversations and emails during and after the IEEE 802 meeting last
week, from people in both 802.11ai and 802.15.9.

Paul Lambert (Marvel) made a short presentation to the 802.11 wng
session on 'Key Centric Identity' to get the larger 802.11 community
into an understanding of discussions ongoing in 802.11ai, this is at:

https://mentor.ieee.org/802.11/dcn/12/11-12-0378-00-0wng-key-centric-identity.ppt


Very short and to the point and content (other than the hash used as a
local MAC address) should be familiar with people on this list.  But a
couple of key points is that the public key IS the identity and a hash
of that key IS a powerful tool to authentication services.  Now
although I am a big proponent of KCI for over 12 years, only recently
have I worked out some key environmental portions and some still needs
some work (as well as being ECC centric).

Enough background.

Premise:  The sensor and a network service (To Be Named) both have
RawPublicKey Identities that are available in a hashed format.  I will
call these RpkI and RpkHI until someone gives me better generic
handles (I want to avoid HIP-style labels).

Further the sensor's RpkHI and some other information (Some to be
discussed further down) will be printed on the sensor or on provided
paper in a QR code (probably v3 should be enough).  The QR code will
be used to preload the network authentication server with the sensor's
identity as Paul shows.  I will not discuss here (though I am
elsewhere) the protocol used by the network service and the
authentication service to retrieve valid sensor RpkHI.  This
deployment method provides one side of the problem on how the network
service accept a new sensor.

For the other side, how does the sensor recognize the proper PAN and
service, I am going to introduce some things that are rather 'new' to
me, and I may not have all the pieces right and so far I only know how
to do this with EC identities like static ECDH (though ECDSA works as
well).  The piece here is ECQV, Implicit Certificates, that was just
shown to me last week by Andrei Gutov for his student, Jani Pellikka. 
Here the sensor vendor pre-loads the sensor with the random value need
for the ECQV and places that in the QR code.  The network
authentication server takes that and the network service identity and
builds the ECQV to use in the KMP.  It is ASSUMEd that only the
intended PAN has this information (thus there is a weakness of leakage
here for who scans the QR code).  Now the sensor can validate the
RpkHI in the form of the ECQV it got.  Not 100%, but much closer than
anything else I have worked out.

There is always the backoff and retry approach if the neighboring PAN
is able to make the same ECQV (you picked the room thermometer out of
your neighbor's garbage, shame on you).  I also have only seen this
with ECC.

I am in the process of working this out.  Some of it I only really put
together last week, and really the ECQV in this direction in this
manner only came to me a couple hours ago rereading the
'RawPublicKeys' thread on this list.

I offer this for your reading pleasure.  I have my preferred KMP and I
fully intend to pursue this, but I believe this will work with MOST
KMPs that implement support for RpkHI.

Finally, I will point out what I view as obvious.  The world of sensor
networks is not all CoAP, let alone 6lowpan and even Zigbee.  LECIM
(802.15.4k) looks to be fun.  And now we have the PTC SG with a PAR
(just a different set of challenges).  Thus I am working on the
network securing and authentication in 802.15.9 where I believe it
needs to live.  Oh and it looks like there is life still in 802.15.7
based on a presentation last week.

See people Sunday afternoon or later.


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


          

        

        

        
-- 

          
          Standard
          Robert Moskowitz

           Senior Technical Advisor

           Security & Standards

           Verizon Business Systems

          C:      248-219-2059

           F:      248-968-2824

           E:      robert.moskowitz@verizonbusiness.com

          

           There's no limit to what
            can be accomplished if it doesn't matter who gets the credit

        

        

        

        

        
_______________________________________________
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


    

    

    
-- 

      
      Standard
      Robert Moskowitz

      
        Senior Technical Advisor

      
        Security & Standards

      
        Verizon Business Systems

      C:      248-219-2059

      
        F:      248-968-2824

      
        E:      robert.moskowitz@verizonbusiness.com

      

      
        There's no limit to what can be accomplished if it doesn't
        matter who gets the credit

    

  


--------------090606030308000609060706--

From cabo@tzi.org  Sat Mar 24 10:42:41 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D513B21F85E1 for ; Sat, 24 Mar 2012 10:42:41 -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 8tqQh+g8brRl for ; Sat, 24 Mar 2012 10:42:41 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 13A1C21F85E0 for ; Sat, 24 Mar 2012 10:42:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2OHgYrc003995 for ; Sat, 24 Mar 2012 18:42:34 +0100 (CET)
Received: from [10.200.60.20] (pcp.vipnetwork.fr [193.108.21.251]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42041164; Sat, 24 Mar 2012 18:42:34 +0100 (CET)
From: Carsten Bormann 
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Sat, 24 Mar 2012 18:42:33 +0100
To: core WG 
Message-Id: <1B9A6741-A856-4354-B7A0-B1A1F20948A4@tzi.org>
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
Subject: [core] ETSI plug test work in progress...
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 24 Mar 2012 17:42:41 -0000

Just a quick snapshot from the first day of CoRE interop testing:

We ran 1678 interop tests today, with a success rate of 93.6 %.

That number may not mean much to most of us, but the ETSI experts tell =
us that is a very good statistic for a first formal interop.

Apart from the usual IPv6 source address selection issues, the number =
one set of issues was around Block1 (blockwise transfer for POST/PUT).

This represents about half of the matrix between the organizations =
present.
Looking forward to another day of testing...
Drop by room 242 and show your support :-)

Gr=FC=DFe, Carsten


From cabo@tzi.org  Sat Mar 24 10:56:49 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347F921F856C for ; Sat, 24 Mar 2012 10:56:49 -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 AZQBrr9FFgtl for ; Sat, 24 Mar 2012 10:56: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 50D6C21F856A for ; Sat, 24 Mar 2012 10:56:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2OHubQV007777 for ; Sat, 24 Mar 2012 18:56:37 +0100 (CET)
Received: from [10.200.60.20] (pcp.vipnetwork.fr [193.108.21.251]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 044D1168; Sat, 24 Mar 2012 18:56:36 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <16BC0348-5BDA-4628-AF9A-BC4E95614E66@tzi.org>
Date: Sat, 24 Mar 2012 18:56:36 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <16BC0348-5BDA-4628-AF9A-BC4E95614E66@tzi.org>
To: core WG 
X-Mailer: Apple Mail (2.1257)
Subject: Re: [core] IETF 83 CoRE agenda
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 24 Mar 2012 17:56:49 -0000

On Mar 14, 2012, at 23:48, Carsten Bormann wrote:

> PS.: A heads up to the presenters: Because of the large =
non-english-speaking audience, and because we need the freedom to push =
around items at the last minute, I need all slides on Friday, March 23.  =
Of course, as usual you can make changes up to an hour before the =
meeting, but the Friday version should be feature-complete.

Presenters:

If you don't find your slides in the provisional slide set at

	http://www.ietf.org/proceedings/83/slides/slides-83-core-0.pdf

please send me a pointer again!

Gr=FC=DFe, Carsten


From tsavo.stds@gmail.com  Sun Mar 25 01:26:50 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42DA621F8594 for ; Sun, 25 Mar 2012 01:26:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Level: 
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OIxXu9XWSeq for ; Sun, 25 Mar 2012 01:26:49 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC83921F846F for ; Sun, 25 Mar 2012 01:26:49 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so4650483obb.31 for ; Sun, 25 Mar 2012 01:26:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yBMqYfj1+sAb/RRNzI/eTbYhFU2zcpjA+3Y2yYLqFb4=; b=avLQgpA+c44eYgEedb7dDaMD8V0htBfv3zSOlpRSR3QYTF9gPDl4Utf3Vr+lwaNrqi 2uwxLNS9x9YEKvOF4zY62LVkgoFGu35naNGERexyLZ8GVSgp6JUOF4OewR3yQpnYyxw5 BQz/lGzJ4S0srz6eiFsrwskYYKEL8vqxRppJVYBFqbUqasYM73frVjbcM0/imF0wGTd7 eXmA5nbGxP4iPfU9iJr5bLFsom8VNIv79mCSjCzTbV1Lnqky9s2Rve2bLhZyYtsb9Uds J1n3kqvPSa4f43ufTAGupINdU116lGFcJ8qvLY9+HfERsudt14aMSYSf6URIE0Sa3l9I NcdA==
MIME-Version: 1.0
Received: by 10.182.154.5 with SMTP id vk5mr22485851obb.24.1332664009257; Sun, 25 Mar 2012 01:26:49 -0700 (PDT)
Received: by 10.60.41.163 with HTTP; Sun, 25 Mar 2012 01:26:49 -0700 (PDT)
Date: Sun, 25 Mar 2012 11:26:49 +0300
Message-ID: 
From: Teemu Savolainen 
To: core@ietf.org
Content-Type: multipart/alternative; boundary=f46d04479fd9e0736a04bc0d0411
Subject: [core] Sensors using CoAP over IPv6 over BT-LE demo on Tuesday morning 8-9
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 25 Mar 2012 08:26:50 -0000

--f46d04479fd9e0736a04bc0d0411
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi,



Please come and see demonstration of IPv6 over Bluetooth Low Energy
implementation related to draft-ietf-6lowpan-btle-06.



In the demo we have IPv6 enabled heart-rate belt and thermistor sensor.
These sensors act as CoAP servers and provide measurements for CoAP client
running on a web server.



We did not (yet at least) got any specific room for this, so we plan to
show the demo just prior to Core WG meeting at:



Tuesday March 27, 08:00 =96 9:00 room 243.



As a fallback we will show this on corridor just next to 243 (the demo is
quite portable:)



Best regards,



                Teemu

--f46d04479fd9e0736a04bc0d0411
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable




Hi,



=A0



Please come and see demonstration of IPv6 over Bluet=
ooth Low
Energy implementation related to draft-ietf-6lowpan-btle-06.



=A0



In the demo we have IPv6 enabled heart-rate belt and=
 thermistor
sensor. These sensors act as CoAP servers and provide measurements for CoAP
client running on a web server.



=A0



We did not (yet at least) got any specific room for =
this, so
we plan to show the demo just prior to Core WG meeting at:



=A0



Tuesday March 27, 08:00 =96 9:00 room 243.



=A0



As a fallback we will show this on corridor just nex=
t to 243
(the demo is quite portable:)



=A0



Best regards,



=A0



=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Teemu



--f46d04479fd9e0736a04bc0d0411--

From trac+core@trac.tools.ietf.org  Sun Mar 25 05:37:28 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3966121F8476 for ; Sun, 25 Mar 2012 05:37:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.592
X-Spam-Level: 
X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4SNKwB2FhaD for ; Sun, 25 Mar 2012 05:37:27 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id A4E5121F8472 for ; Sun, 25 Mar 2012 05:37:27 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SBmhI-0002Px-DC; Sun, 25 Mar 2012 08:37:24 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: zach@sensinode.com
X-Trac-Project: core
Date: Sun, 25 Mar 2012 12:37:24 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/194
Message-ID: <057.24154e1821135f60ab6245fe5093796a@trac.tools.ietf.org>
X-Trac-Ticket-ID: 194
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: [core] #194: Rules for determining the context of a link relation
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, 25 Mar 2012 12:37:28 -0000

#194: Rules for determining the context of a link relation

 From the review by Julian Reschke:

 The current explanation of how context is determined for a link relation
 is awkward as it is paragraph form. This ticket proposes expansion and
 clarification of these rules for determining the context as a step-by-step
 list.

 The current text says:

 " this information in the target URI, the context URI is built from the
  scheme and authority that was used for referencing the resource
  returning the set of links, replacing the path with an empty path.

  Thus by default links can be thought of as describing a target
  resource hosted by the server.  Other relations can be expressed by
  including an anchor parameter (which defines the context URI) along
  with an explicit relation parameter.  This is an important difference
  to the way the HTTP Link Header format is used, as it is included in
  the header of an HTTP response for some URI (this URI is by default
  the context URI).  Thus the HTTP Link Header is by default relating
  the target URI to the URI that was requested.  In comparison, the
  CoRE link format includes one or more links, each describing a
  resource hosted by a server by default.  Other relations can be
  expressed by using the anchor parameter.  See Section 5 of [RFC3986]
  for a description of how URIs are constructed from URI references."

 An alternative explanation for the context rules would be:

 "
 The context URI specified by

 a) the anchor parameter, when specified, or

 b) Origin of the target URI, when specified

 c) Origin of the link format document's base URI.
 "

 It also should be explained why only the origin is used in cases b) or c).

 In addition, in Section 2.2 it says:

 "The "hosts" relation type indicates that the target URI is a resource
  hosted by the server given by the base URI, or, if present, the
  anchor parameter."

 With the new context rules this will be generalized, and the context is
 determined like that regardless of the relation type.

-- 
----------------------------------+--------------------
 Reporter:  zach@…                |      Owner:  zach@…
     Type:  protocol enhancement  |     Status:  new
 Priority:  minor                 |  Milestone:
Component:  link-format           |    Version:
 Severity:  -                     |   Keywords:
----------------------------------+--------------------

Ticket URL: 
core 


From trac+core@trac.tools.ietf.org  Sun Mar 25 05:47:36 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666E221F84B2 for ; Sun, 25 Mar 2012 05:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.592
X-Spam-Level: 
X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 wsnEUzAVMfzK for ; Sun, 25 Mar 2012 05:47:35 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id B27DF21F84AF for ; Sun, 25 Mar 2012 05:47:34 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SBmr7-0002VB-7O; Sun, 25 Mar 2012 08:47:33 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: zach@sensinode.com
X-Trac-Project: core
Date: Sun, 25 Mar 2012 12:47:33 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/195
Message-ID: <057.146326395afb2006204011907bdec046@trac.tools.ietf.org>
X-Trac-Ticket-ID: 195
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: [core]  #195: Create registry for rt= and if= values
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, 25 Mar 2012 12:47:36 -0000

#195: Create registry for rt= and if= values

 In Joel Halpern's Gen-Art review it was suggested that we create a
 registry for the rt= and if= as there is a high possibility for collision
 when using short strings there.

 This ticket is to create registries for values of the rt= and if=
 attributes.

 The registry will be along the lines of the RFC5988 Link Relation
 Registry. Extension values will be allowed using URIs (and thus the
 registry value will have similar restrictions as for relations to prevent
 collision). Expert review will be proposed for registrations.

-- 
----------------------------------+--------------------
 Reporter:  zach@…                |      Owner:  zach@…
     Type:  protocol enhancement  |     Status:  new
 Priority:  minor                 |  Milestone:
Component:  link-format           |    Version:
 Severity:  -                     |   Keywords:
----------------------------------+--------------------

Ticket URL: 
core 


From trac+core@trac.tools.ietf.org  Sun Mar 25 06:01:02 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8C621F8484 for ; Sun, 25 Mar 2012 06:01:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.592
X-Spam-Level: 
X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 Qhps1-0mvWIE for ; Sun, 25 Mar 2012 06:01:01 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7224E21F8480 for ; Sun, 25 Mar 2012 06:01:01 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SBn48-0000Eo-Fk; Sun, 25 Mar 2012 09:01:00 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: zach@sensinode.com
X-Trac-Project: core
Date: Sun, 25 Mar 2012 13:00:59 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/196
Message-ID: <057.c1662d067dfc070bd6d903bfded99c90@trac.tools.ietf.org>
X-Trac-Ticket-ID: 196
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: [core] #196: Clarify URI fetching rule for attribute values in Section 3
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, 25 Mar 2012 13:01:03 -0000

#196: Clarify URI fetching rule for attribute values in Section 3

 From Julian Reschke's review:

 Section 3 currently has a MUST for treating values of attributes as non-
 retrievable identifiers. This ticket proposes to loosen that requirement
 and allow dereferencing (making it explicit that this is however not part
 of the protocol).

 Proposed text change:

 3.  CoRE link extensions

  The following CoRE specific target attributes are defined in addition
  to the ABNF rules in Section 5 of [RFC5988].  These attributes
  describe information useful in accessing the target link of the
  relation, and in some cases may be URIs.  These URIs MUST be treated

 s/may be/can use the syntactical form of a/

  as non resolvable identifiers (they are not meant to be retrieved).

 Not sure about the "MUST". Maybe replace with an explanation that they can
 indeed by dereferenced (for instance to obtain a description of the link
 relation), but that this is not part of the protocol and MUST NOT be done
 automatically on link evaluation.

-- 
----------------------------------+--------------------
 Reporter:  zach@…                |      Owner:  zach@…
     Type:  protocol enhancement  |     Status:  new
 Priority:  trivial               |  Milestone:
Component:  link-format           |    Version:
 Severity:  -                     |   Keywords:
----------------------------------+--------------------

Ticket URL: 
core 


From trac+core@trac.tools.ietf.org  Sun Mar 25 06:12:28 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D519221F84D1 for ; Sun, 25 Mar 2012 06:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.592
X-Spam-Level: 
X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 GLof+IR5VtwG for ; Sun, 25 Mar 2012 06:12:28 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 600B921F84D0 for ; Sun, 25 Mar 2012 06:12:28 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SBnFC-0002U8-Ba; Sun, 25 Mar 2012 09:12:26 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: zach@sensinode.com
X-Trac-Project: core
Date: Sun, 25 Mar 2012 13:12:26 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/197
Message-ID: <057.ae839c9bea06031d9960d51b275f4b21@trac.tools.ietf.org>
X-Trac-Ticket-ID: 197
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: [core]  #197: Upgrade to RFC5234 ABNF (lose LWS issue)
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, 25 Mar 2012 13:12:28 -0000

#197: Upgrade to RFC5234 ABNF (lose LWS issue)

 Julian Reschke and Jari Arkko suggested that we fix the ABNF, which is
 currently inheriting old RFC2616 ABNF.

 This ticket is to upgrade to RFC5234 by repeating the ABNF from RFC5988 in
 the correct RFC5234 form, at the same time thus losing the problem of
 implied linear white space.

-- 
----------------------------------+--------------------
 Reporter:  zach@…                |      Owner:  zach@…
     Type:  protocol enhancement  |     Status:  new
 Priority:  trivial               |  Milestone:
Component:  link-format           |    Version:
 Severity:  -                     |   Keywords:
----------------------------------+--------------------

Ticket URL: 
core 


From trac+core@trac.tools.ietf.org  Sun Mar 25 06:15:15 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E17B21F84AE for ; Sun, 25 Mar 2012 06:15:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.592
X-Spam-Level: 
X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 Ht6BV-Z7uz+M for ; Sun, 25 Mar 2012 06:15:14 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 1A35021F8462 for ; Sun, 25 Mar 2012 06:15:14 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SBnHt-0003f5-K9; Sun, 25 Mar 2012 09:15:13 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: zach@sensinode.com
X-Trac-Project: core
Date: Sun, 25 Mar 2012 13:15:13 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/198
Message-ID: <057.f42685ca60a80d5908f2ab50dc21f6b5@trac.tools.ietf.org>
X-Trac-Ticket-ID: 198
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: [core] #198: Always allow both token and quoted-string in attributes
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, 25 Mar 2012 13:15:15 -0000

#198: Always allow both token and quoted-string in attributes

 From Julian Reschke's review:

 The rt= and if= attributes currently only allow quoted-string values. This
 ticket is to allow also token values, thus aligning with the rest of the
 RFC5988 attributes.

-- 
----------------------------------+--------------------
 Reporter:  zach@…                |      Owner:  zach@…
     Type:  protocol enhancement  |     Status:  new
 Priority:  minor                 |  Milestone:
Component:  link-format           |    Version:
 Severity:  -                     |   Keywords:
----------------------------------+--------------------

Ticket URL: 
core 


From trac+core@trac.tools.ietf.org  Sun Mar 25 06:42:27 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D34321F84B8 for ; Sun, 25 Mar 2012 06:42:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.592
X-Spam-Level: 
X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 6evE8DbQsCmw for ; Sun, 25 Mar 2012 06:42:26 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id A2F9F21F84B9 for ; Sun, 25 Mar 2012 06:42:26 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SBniD-0006PC-8d; Sun, 25 Mar 2012 09:42:25 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: zach@sensinode.com
X-Trac-Project: core
Date: Sun, 25 Mar 2012 13:42:25 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/199
Message-ID: <057.e951b530e583a655854661b346d26c7f@trac.tools.ietf.org>
X-Trac-Ticket-ID: 199
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: [core]  #199: Put multiple values in a single attribute, separated by spaces (do not allow multiple attributes)
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, 25 Mar 2012 13:42:27 -0000

#199: Put multiple values in a single attribute, separated by spaces (do not
allow multiple attributes)

 Julian Reschke pointed out that our use of multiple rt and if attributes
 in order to represent multiple values differs from the other RFC5988
 attributes.

 This ticket is to align the carrying of multiple values with RFC5988.
 Instead of allowing multiple attributes, multiple values will be allowed
 inside an rt= or if= separated by spaces (and this requires a white-space
 restriction for values).

-- 
----------------------------------+--------------------
 Reporter:  zach@…                |      Owner:  zach@…
     Type:  protocol enhancement  |     Status:  new
 Priority:  minor                 |  Milestone:
Component:  link-format           |    Version:
 Severity:  -                     |   Keywords:
----------------------------------+--------------------

Ticket URL: 
core 


From trac+core@trac.tools.ietf.org  Sun Mar 25 06:57:10 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1F921F84DA for ; Sun, 25 Mar 2012 06:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.366
X-Spam-Level: 
X-Spam-Status: No, score=-102.366 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 dsvnNbaQ0frO for ; Sun, 25 Mar 2012 06:57:10 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2534921F84D9 for ; Sun, 25 Mar 2012 06:57:09 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SBnwS-0006o8-0m; Sun, 25 Mar 2012 09:57:08 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: zach@sensinode.com
X-Trac-Project: core
Date: Sun, 25 Mar 2012 13:57:07 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/200
Message-ID: <057.637046816c24d6b1d5a0f65b02f84f63@trac.tools.ietf.org>
X-Trac-Ticket-ID: 200
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: zach@sensinode.com, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: core@ietf.org
Subject: [core] =?utf-8?b?ICMyMDA6IENoYW5nZSDigJx1cmnigJ0gaW4gcXVlcnkgc3Ry?= =?utf-8?b?aW5nIHRvIOKAnGhyZWbigJ0gKGxpa2UgSFRNTCA8bGluaz4p?=
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, 25 Mar 2012 13:57:10 -0000

#200: Change “uri” in query string to “href” (like HTML )

 Julian Reschke pointed out that the use of "uri" in the query parameter
 definition of /.well-known/core is awkward, and instead we should use a
 known parameter name like "href" for that purpose.

 This ticket is to change the following text in Section 4.1:

 "          filter-query = resource-param "=" query-pattern
           resource-param = "uri" / parmname
           query-pattern = search-token [ "*" ]
           search-token = *search-char
           search-char = unreserved / pct-encoded
                       / ":" / "@"   ; from pchar
                       / "/" / "?"   ; from query
                       / "!" / "$" / "'" / "(" / ")"
                       / "+" / "," / ";" / "="  ; from sub-delims



    The resource-param "uri" refers to the URI-reference between the "<"
    and ">" characters of a link.  Other resource-param values refer to
    the link attribute they name.  Filtering is performed by comparing
    the query-pattern against the value of the attribute identified by
    the resource-param for each link-value in the collection of resources
    identified by the URI path."

 with:

 "
           filter-query = resource-param "=" query-pattern
           resource-param = "href" / parmname
           query-pattern = search-token [ "*" ]
           search-token = *search-char
           search-char = unreserved / pct-encoded
                       / ":" / "@"   ; from pchar
                       / "/" / "?"   ; from query
                       / "!" / "$" / "'" / "(" / ")"
                       / "+" / "," / ";" / "="  ; from sub-delims



    The resource-param "href" refers to the URI-reference between the "<"
    and ">" characters of a link.  Other resource-param values refer to
    the link attribute they name.  Filtering is performed by comparing
    the query-pattern against the value of the attribute identified by
    the resource-param for each link-value in the collection of resources
    identified by the URI path."

-- 
----------------------------------+--------------------
 Reporter:  zach@…                |      Owner:  zach@…
     Type:  protocol enhancement  |     Status:  new
 Priority:  trivial               |  Milestone:
Component:  link-format           |    Version:
 Severity:  -                     |   Keywords:
----------------------------------+--------------------

Ticket URL: 
core 


From jari.arkko@piuha.net  Mon Mar 26 00:06:29 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FFA21E8093 for ; Mon, 26 Mar 2012 00:06:29 -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 YvGg6NCPl-jV for ; Mon, 26 Mar 2012 00:06:28 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 7C85321E8092 for ; Mon, 26 Mar 2012 00:06:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 76A402DA06 for ; Mon, 26 Mar 2012 10:06:26 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgrymCADgRcm for ; Mon, 26 Mar 2012 10:06:26 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 0265B2CC5D for ; Mon, 26 Mar 2012 10:06:25 +0300 (EEST)
Message-ID: <4F701571.9060002@piuha.net>
Date: Mon, 26 Mar 2012 09:06:25 +0200
From: Jari Arkko 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: core 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [core] RD, MP implementations
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 07:06:29 -0000

If anyone has implementations of resource directories or mirror proxies, I'd be interested in doing some interop testing over the Internet. We have both client and server components.

Jari


From cabo@tzi.org  Mon Mar 26 02:25:59 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F2421F859F for ; Mon, 26 Mar 2012 02:25: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 0lOJmvY2XRe8 for ; Mon, 26 Mar 2012 02:25:58 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 979FF21F8598 for ; Mon, 26 Mar 2012 02:25:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2Q9PkcU001643 for ; Mon, 26 Mar 2012 11:25:46 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 125432E6; Mon, 26 Mar 2012 11:25:46 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Mon, 26 Mar 2012 11:25:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <301E5623-AA96-4A15-A943-8646F0B84CC5@tzi.org>
References: <16BC0348-5BDA-4628-AF9A-BC4E95614E66@tzi.org> 
To: core WG 
X-Mailer: Apple Mail (2.1257)
Subject: Re: [core] IETF 83 CoRE agenda
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 09:25:59 -0000

On Mar 24, 2012, at 18:56, Carsten Bormann wrote:

> 	http://www.ietf.org/proceedings/83/slides/slides-83-core-0.pdf

Updated once more.
They are starting to become complete.
(And the slots that still don't have slides are starting to crumble...)

I hope the "sleepy" authors can coordinate their slides some more in the =
next hours.

Gr=FC=DFe, Carsten


From kovatsch@inf.ethz.ch  Mon Mar 26 06:52:35 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C3D21F85AC for ; Mon, 26 Mar 2012 06:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.109
X-Spam-Level: 
X-Spam-Status: No, score=-9.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 n0fzPHdYiMjM for ; Mon, 26 Mar 2012 06:52:32 -0700 (PDT)
Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id AAC6721E808B for ; Mon, 26 Mar 2012 06:52:30 -0700 (PDT)
Received: from CAS22.d.ethz.ch (172.31.51.112) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 26 Mar 2012 15:52:08 +0200
Received: from MBX10.d.ethz.ch ([169.254.1.51]) by CAS22.d.ethz.ch ([fe80::dd0e:466a:b055:c090%10]) with mapi id 14.01.0355.002; Mon, 26 Mar 2012 15:52:07 +0200
From: "Kovatsch  Matthias" 
To: Cullen Jennings , core WG 
Thread-Topic: draft-ietf-core-coap-09: Artificial option count and length limitations
Thread-Index: Ac0LSyb3j1Q+m0sURGSXa615D7OvXQ==
Date: Mon, 26 Mar 2012 13:52:07 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B51396D485@MBX10.d.ethz.ch>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [83.202.17.18]
Content-Type: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B51396D485MBX10dethzch_"
MIME-Version: 1.0
Subject: [core] draft-ietf-core-coap-09: Artificial option count and length limitations
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 13:52:35 -0000

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

Dear working group



draft-ietf-core-coap-09 fixed the 15 options limitation with a special rule=
, the End-of-options Marker. We have a second special rule to concatenate P=
roxy-Uri options that exceed the length of a single option. The length limi=
tation for options in general, however, is still there! Although hitting a =
limit of 270 seems more unlikely than hitting 15, it is still there. With t=
hat, CoAP would also be the first RFC that introduces a limitation for URI =
segments.



I suggest a solution that removes the artificial limitation and the special=
 handling for option count and Proxy-Uri.

Starting from a 4-bit length field, an additional 1-byte field of length in=
formation is  added whenever all bits of a field are set to ones:



     0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |OC/Del.|1 1 1 1|  Length - 15  | Option Value ...

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



     0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |OC/Del.|1 1 1 1|1 1 1 1 1 1 1 1| Length - 270  | Option Value...

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



This unary numeral system might become inefficient for really large numbers=
, but they are unlikely and not even supported in the current draft. It is =
efficient for the expected lengths, as the encoding length adapts.



The biggest pain will be that the CoAP header will need restructuring to mo=
ve the option count to the end.

To keep the alignment for code and MID, we should also move version and typ=
e:



     0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |      Code     |          Message ID           |Ver| T |  OC   |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



I do not know, if anyone used the version field to filter out garbage datag=
rams early, but a valid code might even be more effective for that.

Although this restructuring appears radical and we just now had a CoAP conf=
ormance test with the "old format," I really think we should fix the limita=
tion we would introduce for URIs and benefit from a simpler, unified handli=
ng of length information.



The changes in the draft text would be as follows:



3.1. Message Format



"Option Count (OC): 4-bit unsigned integer.  Indicates the number of option=
s after the header (0-14).  If set to 0, there are no options and the paylo=
ad (if any) immediately follows the header.

If the number of options is greater than 14, OC is set to 15 and another by=
te is added as an 8-bit unsigned integer whose value is added to the 15, al=
lowing a number of 15-269 options. This procedure can be repeated by settin=
g a byte to 255. Another byte is added to allow a number of 270-524 and so =
forth."



3.2. Option Format



"Length: Indicates the length of the Option Value, in bytes. Normally Lengt=
h is a 4-bit unsigned integer allowing value lengths of 0-14 bytes.  When t=
he Length field is set to 15, another byte is added as an 8-bit unsigned in=
teger whose value is added to the 15, allowing option value lengths of 15-2=
69 bytes. This procedure can be repeated like for the Option Count field (s=
ee Section 3.1) until the option length can be represented.



Note that the same mechanism can be used to de-/encode the Option Count and=
 the option length field."



The paragraphs "Alternatively..." and "End-of-options Marker..." would be d=
ropped.



5.10.3. Proxy-Uri



"The option value is an absolute-URI ([RFC3986], Section 4.3)." can be move=
d to the first paragraph and the second and third would be dropped.





I hope I will find enough support for these changes, as I am quite unhappy =
with the current solution in draft 09.

Best regards

Matthias

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











Dear working group


 


draft-ietf-core-coap-09 fixed the 15 options limi=
tation with a special rule, the End-of-options Marker.
We have a second special rule to concatenate Pr=
oxy-Uri options that exceed the length of a single option.
The length limitation for options in general, h=
owever, is still there! Although hitting a limit of 270 seems more unlikely=
 than hitting 15, it is still there. With that, CoAP would also be the firs=
t RFC that introduces a limitation
 for URI segments.


 


I suggest a solution =
that removes the artificial limitation and the special handling for option =
count and Proxy-Uri.


Starting from a 4-bit=
 length field, an additional 1-byte field of length information is  ad=
ded whenever all bits of a field are set to ones:


 


     0     &nbs=
p;             =
1            &n=
bsp;      2      &nb=
sp;            3


    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0=
 1 2 3 4 5 6 7 8 9 0 1


   +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=



   |OC/Del.|1 1 1 1|  Length - 15  | Option Value ..=
.


   +-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+<=
/span>


 


     0       &nbs=
p;           1  =
;            &n=
bsp;    2        &nb=
sp;          3


    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6=
 7 8 9 0 1


   +-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+<=
/span>


   |OC/Del.|1 1 1 1|1 1 1 1 1 1 1 1| Length – 270  =
| Option Value...


   +-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+<=
/span>


 


This unary numeral sy=
stem might become inefficient for really large numbers, but they are unlike=
ly and not even supported in the current draft. It is efficient for the exp=
ected lengths, as the encoding length
 adapts.


 


The biggest pain will=
 be that the CoAP header will need restructuring to move the option count t=
o the end.



To keep the alignment=
 for code and MID, we should also move version and type:



 


     
0            &=
nbsp;      1      &n=
bsp;            2&nb=
sp;            =
      3


    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4=
 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1


   +-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+


   |      Cod=
e     |        =
  Message ID         &nbs=
p; |Ver| T |  OC   |


  
+=
;-+-+-+-+-+-+-+-+-+-+-+-+-&=
#43;-+-+-+-+-+-+-+-+-+-+-+-+=
;-+-+-+-+-+-+-+


 


I do not know, if any=
one used the version field to filter out garbage datagrams early, but a val=
id code might even be more effective for that.


Although this restruc=
turing appears radical and we just now had a CoAP conformance test with the=
 “old format,” I really think we should fix the limitation we w=
ould introduce for URIs and benefit from a simpler,
 unified handling of length information.


 


The changes in the dr=
aft text would be as follows:


 


3.1. Message Format


 


“Option Count (OC): 4-bit unsigned integer.  I=
ndicates the number of options after the header (0-14).  If set to 0, =
there are no options and the payload (if any) immediately follows the heade=
r.


If the number of options is greater than 14, OC is set to=
 15 and another byte is added as an 8-bit unsigned integer whose value is a=
dded to the 15, allowing a number of 15-269 options. This procedure can be =
repeated by setting a byte to 255. Another byte is added to allow a number =
of 270-524 and so forth.”


 


3.2. Option Format


 


“Length: Indicates the length of the Option Value, =
in bytes. Normally Length is a 4-bit unsigned integer allowing value length=
s of 0-14 bytes.  When the Length field is set to 15, another byte is =
added as an 8-bit unsigned integer whose value is added to the 15, allowing=
 option value lengths of 15-269 bytes. This procedure can be repeated like =
for the Option Count field (see Section 3.1) until the option length can be=
 represented.


 


Note that the same me=
chanism can be used to de-/encode the Option Count and the option length fi=
eld.”


 


The paragraphs “=
;Alternatively…” and “End-of-options Marker…”=
 would be dropped.


 


5.10.3. Proxy-Uri


 


“The option val=
ue is an absolute-URI ([RFC3986], Section 4.3).” can be moved to the =
first paragraph and the second and third would be dropped.


 


 


I hope I will find en=
ough support for these changes, as I am quite unhappy with the current solu=
tion in draft 09.


Best regards


Matthias






--_000_55877B3AFB359744BA0F2140E36F52B51396D485MBX10dethzch_--

From jeroen.hoebeke@intec.ugent.be  Mon Mar 26 08:19:03 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19E921E80B8 for ; Mon, 26 Mar 2012 08:19:03 -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 7foqmVwm+hST for ; Mon, 26 Mar 2012 08:19:03 -0700 (PDT)
Received: from smtp2.UGent.be (smtp2.ugent.be [157.193.49.126]) by ietfa.amsl.com (Postfix) with ESMTP id ED55521E8097 for ; Mon, 26 Mar 2012 08:19:02 -0700 (PDT)
Received: from localhost (mcheck5.ugent.be [157.193.49.247]) by smtp2.UGent.be (Postfix) with ESMTP id D062F44A5D3; Mon, 26 Mar 2012 17:19:01 +0200 (CEST)
X-Virus-Scanned: by UGent DICT
Received: from smtp2.UGent.be ([157.193.49.126]) by localhost (mcheck5.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id 6kPagy72qyCI; Mon, 26 Mar 2012 17:19:01 +0200 (CEST)
Received: from [192.168.1.155] (ATuileries-152-1-24-87.w82-123.abo.wanadoo.fr [82.123.52.87]) (Authenticated sender: jjhoebek) by smtp2.UGent.be (Postfix) with ESMTPSA id 5283044A5FD; Mon, 26 Mar 2012 17:19:01 +0200 (CEST)
From: Jeroen Hoebeke 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 26 Mar 2012 17:19:00 +0200
To: core WG 
Message-Id: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
X-Miltered: at mcheck3 with ID 4F7088E4.002 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)!
X-j-chkmail-Enveloppe: 4F7088E4.002/82.123.52.87/ATuileries-152-1-24-87.w82-123.abo.wanadoo.fr/[192.168.1.155]/
X-j-chkmail-Score: MSGID : 4F7088E4.002 on smtp2.UGent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Subject: [core] draft-ietf-core-coap-09: Separate response in a lossy context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 15:19:03 -0000

Dear working group,

During the plug test event, we noticed different behavior of =
implementations in case of separated responses in a lossy context.

Case 1:
- client sends CON request
- ACK from server is lost
- separate CON response from server to client
- ACK from client to server

Some implementations do not consider the CON response as an implicit =
acknowledgement and retransmit the CON request, causing unnecessary =
traffic. In section 4.1, the draft says:=20
> =20
> In particular, a CoAP request message may have elicited a
>    separate response, in which case it is clear to the requester that
>    only the ACK was lost and a retransmission of the request would =
serve
>    no purpose.=20

This is only an implementation note. It would be better to state =
explicitly in section 4.1 of the draft: "The reception of a separate =
confirmable response before the acknowledgement should be considered as =
an implicit acknowledgement and should not result in a retransmission of =
the request in case the acknowledgment never arrives."

Case 2:
- client sends CON request
- server sends ACK
- server sends separate CON response
- ACK from client to server is lost
- server retransmits the CON response
In several implementations, the reception of the ACK results in the =
removal of the context of the transaction (which makes sense for =
constrained devices). When the server retransmits the response, this =
results in a RST message.=20

It would be useful to describe this behavior in section 4.1 (or section =
4.4.4 as one of the cases where a RST is sent). For a CON request for =
which the ACK is lost, this behavior is well explained in section 4.1, =
but for the CON response for which the ACK is lost this is missing.
=20
"The reception of a retransmitted confirmable response due to the loss =
of the client's acknowledgment, may result in RST message in case the =
client removed the state information after sending the acknowledgment."

Kind regards,
Jeroen Hoebeke





From cabo@tzi.org  Mon Mar 26 08:23:45 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773B821E80C0 for ; Mon, 26 Mar 2012 08:23:45 -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 4oAJJZNseHpQ for ; Mon, 26 Mar 2012 08:23: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 69B7D21E8097 for ; Mon, 26 Mar 2012 08:23:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2QFNbQd011523; Mon, 26 Mar 2012 17:23:37 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 31DBE5E0; Mon, 26 Mar 2012 17:23:36 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <55877B3AFB359744BA0F2140E36F52B51396D485@MBX10.d.ethz.ch>
Date: Mon, 26 Mar 2012 17:23:35 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <272BED9E-E267-475E-BDF2-A8D2C4A94D2D@tzi.org>
References: <55877B3AFB359744BA0F2140E36F52B51396D485@MBX10.d.ethz.ch>
To: "Kovatsch  Matthias" 
X-Mailer: Apple Mail (2.1257)
Cc: core WG 
Subject: Re: [core] draft-ietf-core-coap-09: Artificial option count and length limitations
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 15:23:45 -0000

Hi Matthias,

thank you for this WGLC comment.
Quick reaction (no WG chair hats in sight):

I like your idea of getting rid of the 270 limit for options, because =
the current limit made us introduce the irregular handling of uri-proxy =
which we really need to get rid of, and there seems to be very little =
downside to fixing this.

I don't understand what makes you think we need to develop a new, =
non-compatible way to solve the OC=3D15 problem.  We just had a rather =
successful interoperability event with over 20 implementations =
supporting the current format.  There are also good technical reasons to =
have the version field in front.  The whole thing strikes me as a =
gratuitous change with zero benefits.

So I would like to have us discuss separately:

1 -- removing the 270 limit, enabling us to fix long Uri-Proxy values.

2 -- going back to the drawing board on the message format to solve a =
problem you don't state (except that you are "unhappy").

Gr=FC=DFe, Carsten


From prvs=943223854D=guido.moritz@uni-rostock.de  Mon Mar 26 08:56:46 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387E621E80D0 for ; Mon, 26 Mar 2012 08:56:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 aPr2-79hXMfN for ; Mon, 26 Mar 2012 08:56:45 -0700 (PDT)
Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6B49A21E80BB for ; Mon, 26 Mar 2012 08:56:37 -0700 (PDT)
From: Guido Moritz 
To: 'Carsten Bormann' 
References: <55877B3AFB359744BA0F2140E36F52B51396D485@MBX10.d.ethz.ch> <272BED9E-E267-475E-BDF2-A8D2C4A94D2D@tzi.org>
In-Reply-To: <272BED9E-E267-475E-BDF2-A8D2C4A94D2D@tzi.org>
Date: Mon, 26 Mar 2012 17:56:47 +0200
Message-ID: <003901cd0b69$0ce99a40$26bccec0$@uni-rostock.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIBE2eBBHDvzH+/+uxwSZy+hq4ZQwGfR38Nlgeu/lA=
Content-Language: de
X-Originating-IP: [130.129.22.70]
Cc: 'core WG' 
Subject: Re: [core] draft-ietf-core-coap-09: Artificial option count and	length limitations
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 15:56:46 -0000

Just to clarify: The current limitation to 270 Byte in the draft also
affects the URI-options, not only the proxy URI?!

Without reading the draft in depth again: Wouldn't it be reasonable to
remove the limitation from all the URI options?! I would appreciate! As
Matthias already mentioned, in other protocols there is no limitation as
well. It may become terribly inefficient to use longer URIs. But it will
become even worse when putting all the stuff from the URI in the payload =
due
to the URI limitation.

URIs are such an important concept of REST, we shouldn't scare =
implementers
due to such limitations.=20

My2Cents,
Guido

> -----Urspr=FCngliche Nachricht-----
> Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag =
von
> Carsten Bormann
> Gesendet: Montag, 26. M=E4rz 2012 17:24
> An: Kovatsch Matthias
> Cc: core WG
> Betreff: Re: [core] draft-ietf-core-coap-09: Artificial option count =
and
length
> limitations
>=20
> Hi Matthias,
>=20
> thank you for this WGLC comment.
> Quick reaction (no WG chair hats in sight):
>=20
> I like your idea of getting rid of the 270 limit for options, because =
the
current
> limit made us introduce the irregular handling of uri-proxy which we
really
> need to get rid of, and there seems to be very little downside to =
fixing
this.
>=20
> I don't understand what makes you think we need to develop a new, non-
> compatible way to solve the OC=3D15 problem.  We just had a rather
successful
> interoperability event with over 20 implementations supporting the =
current
> format.  There are also good technical reasons to have the version =
field
in
> front.  The whole thing strikes me as a gratuitous change with zero
benefits.
>=20
> So I would like to have us discuss separately:
>=20
> 1 -- removing the 270 limit, enabling us to fix long Uri-Proxy values.
>=20
> 2 -- going back to the drawing board on the message format to solve a
problem
> you don't state (except that you are "unhappy").
>=20
> Gr=FC=DFe, Carsten
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


From jeroen.hoebeke@intec.ugent.be  Mon Mar 26 08:58:34 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE0D21E80DD for ; Mon, 26 Mar 2012 08:58:34 -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 Mg63ZA5NG7-e for ; Mon, 26 Mar 2012 08:58:34 -0700 (PDT)
Received: from smtp1.UGent.be (smtp1.ugent.be [157.193.71.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0270221E80D9 for ; Mon, 26 Mar 2012 08:58:34 -0700 (PDT)
Received: from localhost (mcheck3.ugent.be [157.193.71.89]) by smtp1.UGent.be (Postfix) with ESMTP id E02EB3F6BF3; Mon, 26 Mar 2012 17:58:32 +0200 (CEST)
X-Virus-Scanned: by UGent DICT
Received: from smtp1.UGent.be ([157.193.71.182]) by localhost (mcheck3.ugent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id hvK-fUJgpEnr; Mon, 26 Mar 2012 17:58:32 +0200 (CEST)
Received: from [192.168.1.155] (ATuileries-152-1-24-87.w82-123.abo.wanadoo.fr [82.123.52.87]) (Authenticated sender: jjhoebek) by smtp1.UGent.be (Postfix) with ESMTPSA id 5EC773F6BF0; Mon, 26 Mar 2012 17:58:32 +0200 (CEST)
From: Jeroen Hoebeke 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 26 Mar 2012 17:58:32 +0200
To: core WG 
Message-Id: 
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
X-Miltered: at mcheck3 with ID 4F709227.00A by Joe's j-chkmail (http://helpdesk.ugent.be/email/)!
X-j-chkmail-Enveloppe: 4F709227.00A/82.123.52.87/ATuileries-152-1-24-87.w82-123.abo.wanadoo.fr/[192.168.1.155]/
X-j-chkmail-Score: MSGID : 4F709227.00A on smtp1.UGent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Subject: [core] draft-ietf-core-observe-05 - use of 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, 26 Mar 2012 15:58:34 -0000

Dear working group,

In draft-ietf-core-coap-09, max-age is introduced to indicate the =
freshness of a response, useful for caching. In =
draft-ietf-core-observe-05, max-age is also used and the following is =
stated: It (the server) will send a notification whenever the resource =
changes, or at latest when the age of the last notification becomes =
greater than its Max-Age.

While implementing this functionality for the plugtest event, we found =
this to be a quite stringent requirement for a resource constrained =
device (in particular when the resource does not change frequently, e.g. =
a door sensor during night). Simply increasing max-age is not really a =
nice solution, since then you impact freshness. Also, alternative =
solutions for realizing notifications latest after X seconds have been =
proposed already (e.g. draft-shelby-core-interfaces-02 section 4.8 or =
draft-li-core-conditional-observe-01). It seems the behavior in =
draft-ietf-core-observe-05 has been particularly designed for e.g. a =
cache that always needs to have a fresh representation.

We would like to have some more freedom here. This could be done by =
shifting the responsibility to the observer by stating that "an observer =
should not re-register its interest before max-age expires". The server =
then has the freedom to send notifications only when the resource =
changes OR every time the age of the last notification becomes greater =
than max-age. The client then has the freedom to reregister immediately =
after max-age or to wait much longer (depending on the application). The =
meaning of max-age for caching purposes does not change.

Kind regards,
Jeroen



From cabo@tzi.org  Mon Mar 26 09:02:41 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D16C21E80D9 for ; Mon, 26 Mar 2012 09:02:41 -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 s7lOEHToPF-S for ; Mon, 26 Mar 2012 09:02:40 -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 7D7F121E80A3 for ; Mon, 26 Mar 2012 09:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2QG2WVt011334; Mon, 26 Mar 2012 18:02:33 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 90C78610; Mon, 26 Mar 2012 18:02:32 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <003901cd0b69$0ce99a40$26bccec0$@uni-rostock.de>
Date: Mon, 26 Mar 2012 18:02:32 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <55877B3AFB359744BA0F2140E36F52B51396D485@MBX10.d.ethz.ch> <272BED9E-E267-475E-BDF2-A8D2C4A94D2D@tzi.org> <003901cd0b69$0ce99a40$26bccec0$@uni-rostock.de>
To: Guido Moritz 
X-Mailer: Apple Mail (2.1257)
Cc: 'core WG' 
Subject: Re: [core] draft-ietf-core-coap-09: Artificial option count and	length limitations
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 16:02:41 -0000

On Mar 26, 2012, at 17:56, Guido Moritz wrote:

> Just to clarify: The current limitation to 270 Byte in the draft also
> affects the URI-options, not only the proxy URI?!
>=20
> Without reading the draft in depth again: Wouldn't it be reasonable to
> remove the limitation from all the URI options?!=20

Hi Guido,

welcome back to the mailing list :-)

the 270 byte limitation we have in -09 applies to each single option; in =
the case of URIs these are already split up into component options to =
eliminate percent-encoding processing at the servers.  So you can have =
pretty long URIs, just not with segments longer than 270 bytes.
Matthias' proposal 1 fixes that limitation, too.
It also allows us to get rid of a special case that provided for longer =
Uri-Proxy URIs by splitting them up into 270-byte fragments (ouch).

Gr=FC=DFe, Carsten


From angelo.castellani@gmail.com  Mon Mar 26 09:08:26 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A57721E80BB for ; Mon, 26 Mar 2012 09:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o30KX38E9QPN for ; Mon, 26 Mar 2012 09:08:25 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 2E71F21E8097 for ; Mon, 26 Mar 2012 09:08:25 -0700 (PDT)
Received: by wibhq7 with SMTP id hq7so3694240wib.13 for ; Mon, 26 Mar 2012 09:08:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=H6ZBUUPyCdNH+J32O5BMqGBpw+LexcTbBhOl0f6VIVo=; b=B/4Zt5QY2vqfas/PreLK93GRVXCPQv07fk5j6Jb0jHB27X0aJl4MpPvmQilOD0Cglt y9RzleteFifVK59dKMClwesMIfGvYF03CKqsflMBdtuvEfJ8AAw44DPhjJpW2DyWCalA ncPcr4vcE2lgaOAGfpf+SSSM+5Q6zzlhXUkqSEqTGPa8SUUGzhVpm7g7nN7d0d5RYhOT FWCZvaL/pp7Cpmc2BK66mpXeDxHWkAbnq1dMa23atkjZXLjZC5YyQwvPn7Ta52cJ9uKF aAWosmL8UXDBQwho+9PhjLkpngtpDXStnYWDQAycSOhfvR5Z/1gqqrWnG8NCinq0vBoL 6KVA==
Received: by 10.180.24.7 with SMTP id q7mr19889090wif.11.1332778101085; Mon, 26 Mar 2012 09:08:21 -0700 (PDT)
MIME-Version: 1.0
Sender: angelo.castellani@gmail.com
Received: by 10.216.121.148 with HTTP; Mon, 26 Mar 2012 09:07:40 -0700 (PDT)
In-Reply-To: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>
From: "Angelo P. Castellani" 
Date: Mon, 26 Mar 2012 18:07:40 +0200
X-Google-Sender-Auth: oIZiDd8oFJKUKMBVQIVGAOJCPDQ
Message-ID: 
To: Jeroen Hoebeke 
Content-Type: multipart/alternative; boundary=f46d043892ab47977504bc2795f1
Cc: core WG 
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 16:08:26 -0000

--f46d043892ab47977504bc2795f1
Content-Type: text/plain; charset=UTF-8

I feel that this discussion is really interesting and needed.

In my opinion there are lots of situations that should be openly discussed
when separate responses are involved.

Case 1: I am working on it, and I have some doubts that when you have this
optimization in place the protocol is consistent. Will get back soon on
this.

Case 2: Are we sure that server behaviour MUST never change when it
receives a RST to the CON instead of an ACK?

Probably in some cases you may want to use a separate response to be sure
that the client has received it, but if we standardize that clients can
lose their state this will not be possible anymore.

Best,
Angelo

On Mon, Mar 26, 2012 at 17:19, Jeroen Hoebeke  wrote:

> Dear working group,
>
> During the plug test event, we noticed different behavior of
> implementations in case of separated responses in a lossy context.
>
> Case 1:
> - client sends CON request
> - ACK from server is lost
> - separate CON response from server to client
> - ACK from client to server
>
> Some implementations do not consider the CON response as an implicit
> acknowledgement and retransmit the CON request, causing unnecessary
> traffic. In section 4.1, the draft says:
> >
> > In particular, a CoAP request message may have elicited a
> >    separate response, in which case it is clear to the requester that
> >    only the ACK was lost and a retransmission of the request would serve
> >    no purpose.
>
> This is only an implementation note. It would be better to state
> explicitly in section 4.1 of the draft: "The reception of a separate
> confirmable response before the acknowledgement should be considered as an
> implicit acknowledgement and should not result in a retransmission of the
> request in case the acknowledgment never arrives."
>
> Case 2:
> - client sends CON request
> - server sends ACK
> - server sends separate CON response
> - ACK from client to server is lost
> - server retransmits the CON response
> In several implementations, the reception of the ACK results in the
> removal of the context of the transaction (which makes sense for
> constrained devices). When the server retransmits the response, this
> results in a RST message.
>
> It would be useful to describe this behavior in section 4.1 (or section
> 4.4.4 as one of the cases where a RST is sent). For a CON request for which
> the ACK is lost, this behavior is well explained in section 4.1, but for
> the CON response for which the ACK is lost this is missing.
>
> "The reception of a retransmitted confirmable response due to the loss of
> the client's acknowledgment, may result in RST message in case the client
> removed the state information after sending the acknowledgment."
>
> Kind regards,
> Jeroen Hoebeke
>
>
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

--f46d043892ab47977504bc2795f1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I feel that this discussion is really interesting and needed.

In my opinion there are lots of situations that should be openly disc=
ussed when separate responses are involved.

Case 1=
: I am working on it, and I have some doubts that when you have this optimi=
zation in place the protocol is consistent. Will get back soon on this.




Case 2: Are we sure that server behaviour MUST never ch=
ange when it receives a RST to the CON instead of an ACK?

Probably in some cases you may want to use a separate response to b=
e sure that the client has received it, but if we standardize that clients =
can lose their state this will not be possible anymore.





Best,
Angelo

On Mo=
n, Mar 26, 2012 at 17:19, Jeroen Hoebeke <jeroen.hoebeke@intec=
.ugent.be> wrote:




Dear working group,



During the plug test event, we noticed different behavior of implementation=
s in case of separated responses in a lossy context.



Case 1:

- client sends CON request

- ACK from server is lost

- separate CON response from server to client

- ACK from client to server



Some implementations do not consider the CON response as an implicit acknow=
ledgement and retransmit the CON request, causing unnecessary traffic. In s=
ection 4.1, the draft says:

>

> In particular, a CoAP request message may have elicited a

> =C2=A0 =C2=A0separate response, in which case it is clear to the reque=
ster that

> =C2=A0 =C2=A0only the ACK was lost and a retransmission of the request=
 would serve

> =C2=A0 =C2=A0no purpose.



This is only an implementation note. It would be better to state explicitly=
 in section 4.1 of the draft: "The reception of a separate confirmable=
 response before the acknowledgement should be considered as an implicit ac=
knowledgement and should not result in a retransmission of the request in c=
ase the acknowledgment never arrives."






Case 2:

- client sends CON request

- server sends ACK

- server sends separate CON response

- ACK from client to server is lost

- server retransmits the CON response

In several implementations, the reception of the ACK results in the removal=
 of the context of the transaction (which makes sense for constrained devic=
es). When the server retransmits the response, this results in a RST messag=
e.






It would be useful to describe this behavior in section 4.1 (or section 4.4=
.4 as one of the cases where a RST is sent). For a CON request for which th=
e ACK is lost, this behavior is well explained in section 4.1, but for the =
CON response for which the ACK is lost this is missing.






"The reception of a retransmitted confirmable response due to the loss=
 of the client's acknowledgment, may result in RST message in case the =
client removed the state information after sending the acknowledgment."=
;






Kind regards,

Jeroen Hoebeke









_______________________________________________

core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core





--f46d043892ab47977504bc2795f1--

From cabo@tzi.org  Mon Mar 26 09:14:50 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C4621E8097 for ; Mon, 26 Mar 2012 09:14:50 -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 b5IlxOYzKtR3 for ; Mon, 26 Mar 2012 09:14:49 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0BE21E80F6 for ; Mon, 26 Mar 2012 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.3/8.14.3) with ESMTP id q2QGEC5H020524; Mon, 26 Mar 2012 18:14:12 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E70B761B; Mon, 26 Mar 2012 18:14:11 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Mon, 26 Mar 2012 18:14:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A3332BE-750E-4193-90BB-ED18D405E07A@tzi.org>
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be> 
To: "Angelo P. Castellani" 
X-Mailer: Apple Mail (2.1257)
Cc: core WG 
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 16:14:50 -0000

On Mar 26, 2012, at 18:07, Angelo P. Castellani wrote:

> Probably in some cases you may want to use a separate response to be =
sure that the client has received it, but if we standardize that clients =
can lose their state this will not be possible anymore.

That is not part of the REST semantics.
If we have a good use case for this, we could decide that we want to =
make it work.
Currently, as you note, there is no support "certified delivery" for =
responses, just as in HTTP.

Gr=FC=DFe, Carsten


From prvs=143235C967=guido.moritz@uni-rostock.de  Mon Mar 26 09:17:21 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE9921E80EC for ; Mon, 26 Mar 2012 09:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.248
X-Spam-Level: 
X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 74sbP7C35gN7 for ; Mon, 26 Mar 2012 09:17:20 -0700 (PDT)
Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDBD21E80E5 for ; Mon, 26 Mar 2012 09:17:17 -0700 (PDT)
From: Guido Moritz 
To: "'Angelo P. Castellani'" , 'Jeroen Hoebeke' 
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be> 
In-Reply-To: 
Date: Mon, 26 Mar 2012 18:17:28 +0200
Message-ID: <004001cd0b6b$f1051220$d30f3660$@uni-rostock.de>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01CD0B7C.B48FB6E0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQI+jSyYxezHb35jh1VR9IZ1dfLDewJW3mWxlYcF0VA=
Content-Language: de
X-Originating-IP: [130.129.22.70]
Cc: 'core WG' 
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy	context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 16:17:21 -0000

------=_NextPart_000_0041_01CD0B7C.B48FB6E0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I am not a fan of ASCII-Art ;), but maybe we can have a state-machine =
depicting the different states for client and server to make sure about =
consistency in transitions etc? The TCP RFC is also using states to make =
sure to cover all cases that can occur.

=20

Guido

=20

Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag von =
Angelo P. Castellani
Gesendet: Montag, 26. M=C3=A4rz 2012 18:08
An: Jeroen Hoebeke
Cc: core WG
Betreff: Re: [core] draft-ietf-core-coap-09: Separate response in a =
lossy context

=20

I feel that this discussion is really interesting and needed.

=20

In my opinion there are lots of situations that should be openly =
discussed when separate responses are involved.

=20

Case 1: I am working on it, and I have some doubts that when you have =
this optimization in place the protocol is consistent. Will get back =
soon on this.

=20

Case 2: Are we sure that server behaviour MUST never change when it =
receives a RST to the CON instead of an ACK?

=20

Probably in some cases you may want to use a separate response to be =
sure that the client has received it, but if we standardize that clients =
can lose their state this will not be possible anymore.

=20

Best,
Angelo

On Mon, Mar 26, 2012 at 17:19, Jeroen Hoebeke =
 wrote:

Dear working group,

During the plug test event, we noticed different behavior of =
implementations in case of separated responses in a lossy context.

Case 1:
- client sends CON request
- ACK from server is lost
- separate CON response from server to client
- ACK from client to server

Some implementations do not consider the CON response as an implicit =
acknowledgement and retransmit the CON request, causing unnecessary =
traffic. In section 4.1, the draft says:
>
> In particular, a CoAP request message may have elicited a
>    separate response, in which case it is clear to the requester that
>    only the ACK was lost and a retransmission of the request would =
serve
>    no purpose.

This is only an implementation note. It would be better to state =
explicitly in section 4.1 of the draft: "The reception of a separate =
confirmable response before the acknowledgement should be considered as =
an implicit acknowledgement and should not result in a retransmission of =
the request in case the acknowledgment never arrives."

Case 2:
- client sends CON request
- server sends ACK
- server sends separate CON response
- ACK from client to server is lost
- server retransmits the CON response
In several implementations, the reception of the ACK results in the =
removal of the context of the transaction (which makes sense for =
constrained devices). When the server retransmits the response, this =
results in a RST message.

It would be useful to describe this behavior in section 4.1 (or section =
4.4.4 as one of the cases where a RST is sent). For a CON request for =
which the ACK is lost, this behavior is well explained in section 4.1, =
but for the CON response for which the ACK is lost this is missing.

"The reception of a retransmitted confirmable response due to the loss =
of the client's acknowledgment, may result in RST message in case the =
client removed the state information after sending the acknowledgment."

Kind regards,
Jeroen Hoebeke




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

=20


------=_NextPart_000_0041_01CD0B7C.B48FB6E0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I am not a fan of ASCII-Art ;), but maybe we can have a state-machine =
depicting the different states for client and server to make sure about =
consistency in transitions etc? The TCP RFC is also using states to make =
sure to cover all cases that can occur.
 
Guido
 
Von:<=
/b> =
core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag von =
Angelo P. Castellani
Gesendet: Montag, 26. M=C3=A4rz 2012 =
18:08
An: Jeroen Hoebeke
Cc: core =
WG
Betreff: Re: [core] draft-ietf-core-coap-09: Separate =
response in a lossy context
 
I feel that =
this discussion is really interesting and needed.
 
In my opinion there are lots of situations that should =
be openly discussed when separate responses are =
involved.
 
Case 1: I am working on it, and I have some doubts =
that when you have this optimization in place the protocol is =
consistent. Will get back soon on this.
 
Case 2: Are we sure that server behaviour MUST never =
change when it receives a RST to the CON instead of an =
ACK?
 
Probably in some cases you may want to use a separate =
response to be sure that the client has received it, but if we =
standardize that clients can lose their state this will not be possible =
anymore.
 
Best,
Angelo
On Mon, Mar 26, 2012 at 17:19, Jeroen Hoebeke <jeroen.hoebeke@intec.ugent.be> =
wrote:
Dear working =
group,

During the plug test event, we noticed different behavior =
of implementations in case of separated responses in a lossy =
context.

Case 1:
- client sends CON request
- ACK from =
server is lost
- separate CON response from server to client
- ACK =
from client to server

Some implementations do not consider the =
CON response as an implicit acknowledgement and retransmit the CON =
request, causing unnecessary traffic. In section 4.1, the draft =
says:
>
> In particular, a CoAP request message may have =
elicited a
>    separate response, in which case it is =
clear to the requester that
>    only the ACK was lost =
and a retransmission of the request would serve
>    no =
purpose.

This is only an implementation note. It would be better =
to state explicitly in section 4.1 of the draft: "The reception of =
a separate confirmable response before the acknowledgement should be =
considered as an implicit acknowledgement and should not result in a =
retransmission of the request in case the acknowledgment never =
arrives."

Case 2:
- client sends CON request
- server =
sends ACK
- server sends separate CON response
- ACK from client =
to server is lost
- server retransmits the CON response
In several =
implementations, the reception of the ACK results in the removal of the =
context of the transaction (which makes sense for constrained devices). =
When the server retransmits the response, this results in a RST =
message.

It would be useful to describe this behavior in section =
4.1 (or section 4.4.4 as one of the cases where a RST is sent). For a =
CON request for which the ACK is lost, this behavior is well explained =
in section 4.1, but for the CON response for which the ACK is lost this =
is missing.

"The reception of a retransmitted confirmable =
response due to the loss of the client's acknowledgment, may result in =
RST message in case the client removed the state information after =
sending the acknowledgment."

Kind regards,
Jeroen =
Hoebeke




______________________________________________=
_
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
 

------=_NextPart_000_0041_01CD0B7C.B48FB6E0--

From angelo.castellani@gmail.com  Mon Mar 26 09:20:55 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D505A21E80F2 for ; Mon, 26 Mar 2012 09:20:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klRSH7hzMtgR for ; Mon, 26 Mar 2012 09:20:55 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 43E5921E80F5 for ; Mon, 26 Mar 2012 09:20:54 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so2747495wgb.13 for ; Mon, 26 Mar 2012 09:20:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=7Vv0nmJ6KRbGG2BrWHBEQhdF3o8JiraIkvlrBu4BdVs=; b=X9M6rYi95IuGkuRXNkrHDM18Ct5lZ13GWY2Kl8hV4Wt0Pdp7pAKyZkNhmZXyLWpCG2 ShYtE1bI6UIEnThzLoLvOc56PfbAQx/Sdl3vKlSssp/XBOEc4K7FlJMfgQaInk+ek1LW JW8fz56TQKeotUNs2tF1U5QEvK4WLYd1xIPBmlIyHQanQ6YgFipM2Va2efHALFiGWkSR PGWSHmSQmMBjeH3FA0zy8v16Lh5xYCKsg/Ir4IGllzT2pDcPAeD/PyZQ1nWehUJPQTG+ mpn2qiGELqqwS25UpIfnmlkkOVgF+MvZegHFPuETeDJ85+QO0WUawoKSxuapXY8eOF83 hNPg==
Received: by 10.216.132.202 with SMTP id o52mr12866625wei.106.1332778853092; Mon, 26 Mar 2012 09:20:53 -0700 (PDT)
MIME-Version: 1.0
Sender: angelo.castellani@gmail.com
Received: by 10.216.121.148 with HTTP; Mon, 26 Mar 2012 09:20:12 -0700 (PDT)
In-Reply-To: <004001cd0b6b$f1051220$d30f3660$@uni-rostock.de>
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>  <004001cd0b6b$f1051220$d30f3660$@uni-rostock.de>
From: "Angelo P. Castellani" 
Date: Mon, 26 Mar 2012 18:20:12 +0200
X-Google-Sender-Auth: QLLjPxG3TVEgREA9juiAJ0Y_BNo
Message-ID: 
To: Guido Moritz 
Content-Type: multipart/alternative; boundary=0016e6d647b21a4c7604bc27c20d
Cc: core WG 
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 16:20:56 -0000

--0016e6d647b21a4c7604bc27c20d
Content-Type: text/plain; charset=UTF-8

On Mon, Mar 26, 2012 at 18:17, Guido Moritz wrote:

> I am not a fan of ASCII-Art ;), but maybe we can have a state-machine
> depicting the different states for client and server to make sure about
> consistency in transitions etc? The TCP RFC is also using states to make
> sure to cover all cases that can occur.****
>
>
I think that this document could be really useful, and also including in
that document some interesting cases (especially where separate responses
are involved).

Implementers may benefit from having such a document, and also having
critical examples that they should handle in their implementation.

Best,
Angelo

--0016e6d647b21a4c7604bc27c20d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 26, 2012 at 18:17, Guido Moritz <guido.moritz@uni-=
rostock.de> wrote:





I am not a=
 fan of ASCII-Art ;), but maybe we can have a state-machine depicting the d=
ifferent states for client and server to make sure about consistency in tra=
nsitions etc? The TCP RFC is also using states to make sure to cover all ca=
ses that can occur.






I think that this do=
cument could be really useful, and also including in that document some int=
eresting cases (especially where separate responses are involved).






Implementers may benefit from having such a document, and al=
so having critical examples that they should handle in their implementation=
.

Best,
Angelo


--0016e6d647b21a4c7604bc27c20d--

From ietf@meetecho.com  Mon Mar 26 09:27:20 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6373821E80C4 for ; Mon, 26 Mar 2012 09:27:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEV-IJ31Q6Cm for ; Mon, 26 Mar 2012 09:27:19 -0700 (PDT)
Received: from smtplq03.aruba.it (smtplqs-out24.aruba.it [62.149.158.64]) by ietfa.amsl.com (Postfix) with SMTP id 4069521E8044 for ; Mon, 26 Mar 2012 09:27:18 -0700 (PDT)
Received: (qmail 18313 invoked by uid 89); 26 Mar 2012 16:27:04 -0000
Received: from unknown (HELO smtp4.aruba.it) (62.149.158.224) by smtplq03.aruba.it with SMTP; 26 Mar 2012 16:27:04 -0000
Received: (qmail 19754 invoked by uid 89); 26 Mar 2012 16:27:04 -0000
Received: from unknown (HELO ?130.129.21.177?) (ietf@meetecho.com@130.129.21.177) by smtp4.ad.aruba.it with SMTP; 26 Mar 2012 16:27:04 -0000
Message-ID: <4F7098D8.7@meetecho.com>
Date: Mon, 26 Mar 2012 18:27:04 +0200
From: Meetecho IETF support 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: core@ietf.org
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: smtp4.ad.aruba.it 1.6.2 0/1000/N
X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N
Cc: Team Meetecho 
Subject: [core] Meetecho support for CORE WG session
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 16:27:20 -0000

Hi all,

a virtual room has been reserved on the Meetecho system for Tuesday's 
CORE WG meeting session.

Access to the on-line session (including audio and video streams) will 
be available at:
http://www.meetecho.com/ietf83/core

The Meetecho session automatically logs you into the standard IETF 
jabber room. So, from there, you can have an integrated experience 
involving all media and allowing you to interact with the room.
Remote participants might also send their own voice to the room, if they 
want to.

A tutorial of interactivity features of the tool can be found at:
http://www.meetecho.com/ietf83/tutorials

Cheers,
the Meetecho team

-- 
Meetecho s.r.l.
Web Conferencing and Collaboration Tools
www.meetecho.com

From salvatore.loreto@ericsson.com  Mon Mar 26 09:35:52 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5144C21E80BE for ; Mon, 26 Mar 2012 09:35:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.091
X-Spam-Level: 
X-Spam-Status: No, score=-110.091 tagged_above=-999 required=5 tests=[AWL=0.507, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qemLCZM2r4aU for ; Mon, 26 Mar 2012 09:35:51 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4E321E8044 for ; Mon, 26 Mar 2012 09:35:51 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c6fae0000045c0-a6-4f709ade6395
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 78.18.17856.EDA907F4; Mon, 26 Mar 2012 18:35:42 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Mon, 26 Mar 2012 18:35:42 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 032242321	for ; Mon, 26 Mar 2012 19:35:41 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E735F520FD	for ; Mon, 26 Mar 2012 19:35:41 +0300 (EEST)
Received: from dhcp-1324.meeting.ietf.org (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 966C451DDF	for ; Mon, 26 Mar 2012 19:35:41 +0300 (EEST)
Message-ID: <4F709ADC.6050800@ericsson.com>
Date: Mon, 26 Mar 2012 18:35:40 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: core@ietf.org
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>  <004001cd0b6b$f1051220$d30f3660$@uni-rostock.de> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010202070808010102090105"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 16:35:52 -0000

--------------010202070808010102090105
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

if we want include a state-machine depicting the different states for 
client and server (and I think it would be a great idea)
the best place to have it is in the core-coap main spec, perhaps as an 
Appendix

/Sal



On 3/26/12 6:20 PM, Angelo P. Castellani wrote:
> On Mon, Mar 26, 2012 at 18:17, Guido Moritz 
> > wrote:
>
>     I am not a fan of ASCII-Art ;), but maybe we can have a
>     state-machine depicting the different states for client and server
>     to make sure about consistency in transitions etc? The TCP RFC is
>     also using states to make sure to cover all cases that can occur.
>
>
> I think that this document could be really useful, and also including 
> in that document some interesting cases (especially where separate 
> responses are involved).
>
> Implementers may benefit from having such a document, and also having 
> critical examples that they should handle in their implementation.
>
> Best,
> Angelo


--------------010202070808010102090105
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 7bit


  
    
  
  
    if we want include a state-machine depicting the different states
    for client and server (and I think it would be a great idea) 

    the best place to have it is in the core-coap main spec, perhaps as
    an Appendix 

    

    /Sal

    

    

    

    On 3/26/12 6:20 PM, Angelo P. Castellani wrote:
    
On Mon, Mar 26, 2012 at 18:17, Guido Moritz <guido.moritz@uni-rostock.de>
      wrote:

      

        

          
I am not a fan of ASCII-Art ;), but maybe we
              can have a state-machine depicting the different states
              for client and server to make sure about consistency in
              transitions etc? The TCP RFC is also using states to make
              sure to cover all cases that can occur.

        

      

      

      
I think that this document could be really useful, and also
        including in that document some interesting cases (especially
        where separate responses are involved).

      

        

      

      
Implementers may benefit from having such a document, and
        also having critical examples that they should handle in their
        implementation.

      


      

      
Best,

      

      
Angelo

    

    

  


--------------010202070808010102090105--

From salvatore.loreto@ericsson.com  Mon Mar 26 09:40:09 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496B621E80C0 for ; Mon, 26 Mar 2012 09:40:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.1
X-Spam-Level: 
X-Spam-Status: No, score=-110.1 tagged_above=-999 required=5 tests=[AWL=0.499,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXFq0pS+0QYN for ; Mon, 26 Mar 2012 09:40:08 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9A521E80BE for ; Mon, 26 Mar 2012 09:40:08 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c6fae0000045c0-8c-4f709be75bfb
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EF.98.17856.7EB907F4; Mon, 26 Mar 2012 18:40:07 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Mon, 26 Mar 2012 18:40:07 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id E211E2321	for ; Mon, 26 Mar 2012 19:40:06 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id DC83D520FD	for ; Mon, 26 Mar 2012 19:40:06 +0300 (EEST)
Received: from dhcp-1324.meeting.ietf.org (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8E98D51DDF	for ; Mon, 26 Mar 2012 19:40:06 +0300 (EEST)
Message-ID: <4F709BE5.5000701@ericsson.com>
Date: Mon, 26 Mar 2012 18:40:05 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: core@ietf.org
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>  <1A3332BE-750E-4193-90BB-ED18D405E07A@tzi.org>
In-Reply-To: <1A3332BE-750E-4193-90BB-ED18D405E07A@tzi.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 16:40:09 -0000

On 3/26/12 6:14 PM, Carsten Bormann wrote:
> On Mar 26, 2012, at 18:07, Angelo P. Castellani wrote:
>
>> Probably in some cases you may want to use a separate response to be sure that the client has received it, but if we standardize that clients can lose their state this will not be possible anymore.
> That is not part of the REST semantics.
> If we have a good use case for this, we could decide that we want to make it work.
> Currently, as you note, there is no support "certified delivery" for responses, just as in HTTP.
I don't get the HTTP comparison here;
what do you mean saying that HTTP does not support "certified delivery" ?
you mean that if the TCP connection brakes (somehow) then the server has 
no way to send back an answer... or what

/Sal


From cabo@tzi.org  Mon Mar 26 10:02:23 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E440F21E8115 for ; Mon, 26 Mar 2012 10:02:23 -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 ipFNx6XcDXdQ for ; Mon, 26 Mar 2012 10:02: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 2ACFA21E80BE for ; Mon, 26 Mar 2012 10:02:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2QH2Fue026521; Mon, 26 Mar 2012 19:02:15 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5EEB663D; Mon, 26 Mar 2012 19:02:15 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <4F709BE5.5000701@ericsson.com>
Date: Mon, 26 Mar 2012 19:02:14 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <20784A81-DE6C-4728-8A84-98E09DB5C9D2@tzi.org>
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>  <1A3332BE-750E-4193-90BB-ED18D405E07A@tzi.org> <4F709BE5.5000701@ericsson.com>
To: Salvatore Loreto 
X-Mailer: Apple Mail (2.1257)
Cc: core@ietf.org
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 17:02:24 -0000

>>> Probably in some cases you may want to use a separate response to be =
sure that the client has received it, but if we standardize that clients =
can lose their state this will not be possible anymore.
>> That is not part of the REST semantics.
>> If we have a good use case for this, we could decide that we want to =
make it work.
>> Currently, as you note, there is no support "certified delivery" for =
responses, just as in HTTP.
> I don't get the HTTP comparison here;
> what do you mean saying that HTTP does not support "certified =
delivery" ?
> you mean that if the TCP connection brakes (somehow) then the server =
has no way to send back an answer... or what

In both protocols, there is no way for the server to find out whether =
the application actually processed the response successfully.
(I.e., this is not a three-way ACK.)
In the HTTP case, the server does not see whether the last bytes of its =
response reached the client's computer (this could be fixed by changing =
the TCP socket interface, but then there is no way to find out whether =
these then reached the client, and whether the client finished the =
processing e.g. before a crash).

Gr=FC=DFe, Carsten


From Gene.Falendysz@itron.com  Mon Mar 26 10:07:17 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0D021F8496 for ; Mon, 26 Mar 2012 10:07:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Bdq3gy-gYJmM for ; Mon, 26 Mar 2012 10:07:16 -0700 (PDT)
Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDED21F848C for ; Mon, 26 Mar 2012 10:07:16 -0700 (PDT)
Received: from ITR-EXMBXVS-2.itron.com ([192.168.9.110]) by spo-exchcn-1.itron.com ([192.168.9.115]) with mapi; Mon, 26 Mar 2012 10:07:16 -0700
From: "Falendysz, Gene" 
To: Jari Arkko , "Angelo P. Castellani" 
Date: Mon, 26 Mar 2012 10:07:14 -0700
Thread-Topic: [core] sleepy to sleepy communication I-Ds
Thread-Index: Acz6v1kqRYL5v0XYSFmglwInn9HyfAQsn7pA
Message-ID: <8E77780E66177E44BC77F3AE0187DA4519A38A66@ITR-EXMBXVS-2.itron.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: core WG 
Subject: Re: [core] sleepy to sleepy communication 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: Mon, 26 Mar 2012 17:07:17 -0000

I think it is worthwhile to divide battery devices into two categories. Tho=
se with consumer accessible batteries (think home thermostat or temperature=
 sensors) and those with embedded batteries (gas or water meters). Where ty=
pical lifetimes for the first being generally accepted as 3+ years the seco=
nd is at least 10 and more commonly 20 years. Jari's example of 100 devices=
 in the home gets really onerous when you think of a utility with 5,000,000=
 meters to manage. The cost of a homeowner changing a battery is a couple o=
f bucks, the cost to change a gas meter battery is measured in hundreds of =
dollars.

Gene Falendysz
Phone: (864) 718.6676
Fax: (864) 718.6871



-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Jar=
i Arkko
Sent: Monday, March 05, 2012 6:00 AM
To: Angelo P. Castellani
Cc: core WG
Subject: Re: [core] sleepy to sleepy communication I-Ds

I worry about creating lots of infrastructure, too. But I also see many arc=
hitectures that are device-server-user/app, and for those there wouldn't ne=
cessarily be any impact.

Not all link layers and devices can get to 3 years, actually far from it. Y=
et we propably want to use those for many reasons, including coverage (cell=
ular) and existing APs (wlan).

And I think 3 years is far from enough. I have 100 devices at home, and if =
they had even a 10 year battery lifetime, I'd still change a battery per mo=
nth.

So I think we still have plenty of work left. At least on some parts; not c=
laiming that this necessarily means something for the CORE WG.

Jari

"Angelo P. Castellani"  wrote:

>I agree with you that this can save a lot more of energy, if the hosts=20
>can provide service during theirs "office hours" :)
>
>However if the nodes will behave in such a way, for sure this will be=20
>visible to the clients and lots of infrastructure (proxies) will be=20
>required to get anything usable by the users.
>
>With regular sensor networks duty cycling, a ~3 years lifetime is=20
>feasible with regular batteries (depending upon actual usage and=20
>network traffic). Are you targeting a use case with tighter=20
>requirements?
>
>Best,
>Angelo
>
>On Mon, Mar 5, 2012 at 10:16, Jari Arkko  wrote:
>>
>> Angelo,
>>
>>
>>> Indeed sensor networks support sleeping using radio duty cycling at=20
>>> lower layers, this turns out in having the sleeping functionality=20
>>> without any loss of communication at the upper layers.
>>>
>>
>> We discussed this a couple of IETFs back. Since then I've been doing=20
>> some talking to our researchers who measure and improve power usage in r=
adios.
>>
>> First, duty cycling is already pretty widely used for radio=20
>> technology. All cellular systems, for instance, turn off the radio=20
>> except in during the time they listen for possible incoming paging=20
>> signals, system information necessary to stay in contact at all, or=20
>> when they have been granted a time slot to send.
>>
>> Secondly and more importantly, per their measurements, even after all=20
>> the above techniques, periodic listening for possibly incoming=20
>> messages is the biggest consumer of energy in applications where we'd=20
>> like to have a long battery life, such as in sensors. That power=20
>> usage dwarfs everything else, so it has to come down, somehow, to make a=
n improvement.
>>
>> So if we want to achieve significantly longer battery lifetimes (and=20
>> I claim we need those) we need to change some things. Obviously a lot=20
>> of the link layers can be tuned better, implementing simply longer=20
>> paging frequencies, for instance. My hypothesis is that we'll have to=20
>> go longer than what typical application protocol timeouts are today,=20
>> so the change would be something that is visible to applications. We=20
>> could change some of the timeouts, but it is not clear that network=20
>> buffers and all underlying mechanisms deployed today support those=20
>> without changes. And in general, I think it is better to fit the=20
>> communication model to the problem at hand than vice versa. As a=20
>> result, I personally believe that we need to build applications that nat=
ively communicate in ways that make sleep modes easy.
>> Such as publish-subscribe instead of direct request-response from=20
>> anyone who needs the information. But like I said, this is a=20
>> hypothesis and I'd love to be proven wrong.
>>
>> Jari
>>
>>
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

From tho@koanlogic.com  Mon Mar 26 10:08:47 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F26A21E8106 for ; Mon, 26 Mar 2012 10:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.933
X-Spam-Level: 
X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RECV_IP_069060096=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WlQJdegIV-d for ; Mon, 26 Mar 2012 10:08:46 -0700 (PDT)
Received: from relay2.serverpronto.com (relay2.infolink.com [38.117.1.250]) by ietfa.amsl.com (Postfix) with ESMTP id 77EA621E80FF for ; Mon, 26 Mar 2012 10:08:46 -0700 (PDT)
Received: from gonzo.koanlogic.com (166-118-60-69.serverpronto.com [69.60.118.166] (may be forged)) by relay2.serverpronto.com (8.13.8/8.13.8) with ESMTP id q2QH8hF2032072; Mon, 26 Mar 2012 13:08:43 -0400
Received: from dhcp-1446.meeting.ietf.org ([130.129.20.70]:52239) by gonzo.koanlogic.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1SCDPE-0007hJ-Ap; Mon, 26 Mar 2012 13:08:42 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Thomas Fossati 
In-Reply-To: <4F709ADC.6050800@ericsson.com>
Date: Mon, 26 Mar 2012 19:08:29 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3A433490-AB35-4340-9CA8-B5DA2FF69F26@koanlogic.com>
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>  <004001cd0b6b$f1051220$d30f3660$@uni-rostock.de>  <4F709ADC.6050800@ericsson.com>
To: Salvatore Loreto 
X-Mailer: Apple Mail (2.1084)
X-SA-Exim-Connect-IP: 130.129.20.70
X-SA-Exim-Mail-From: tho@koanlogic.com
X-Spam-DCC: : 
X-Spam-Pyzor: Reported 0 times.
X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100)
X-SA-Exim-Scanned: Yes (on gonzo.koanlogic.com)
Cc: core@ietf.org
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 17:08:47 -0000

On Mar 26, 2012, at 6:35 PM, Salvatore Loreto wrote:
> if we want include a state-machine depicting the different states for =
client and server (and I think it would be a great idea)=20
> the best place to have it is in the core-coap main spec, perhaps as an =
Appendix=20

I think this is a very good idea (BTW I have made my two FSMs pics =
before implementing evcoap that I can happily share if you want).

Anyway, if we want to provide such information, every I-D that =
introduces new state (Observe and atomic Block the twos that come =
immediately to my mind) have to specify their own "appendix" FSM to the =
core FSM.=

From cabo@tzi.org  Mon Mar 26 10:11:46 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF5221E811D for ; Mon, 26 Mar 2012 10:11:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p81YRlPN4kpp for ; Mon, 26 Mar 2012 10:11:46 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9E71021E8107 for ; Mon, 26 Mar 2012 10:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2QHBauu004172; Mon, 26 Mar 2012 19:11:36 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id ACA27647; Mon, 26 Mar 2012 19:11:36 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <3A433490-AB35-4340-9CA8-B5DA2FF69F26@koanlogic.com>
Date: Mon, 26 Mar 2012 19:11:36 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>  <004001cd0b6b$f1051220$d30f3660$@uni-rostock.de>  <4F709ADC.6050800@ericsson.com> <3A433490-AB35-4340-9CA8-B5DA2FF69F26@koanlogic.com>
To: Thomas Fossati 
X-Mailer: Apple Mail (2.1257)
Cc: core@ietf.org
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 17:11:46 -0000

On Mar 26, 2012, at 19:08, Thomas Fossati wrote:

> I have made my two FSMs pics before implementing evcoap that I can =
happily share if you want

Yes, please.

Gr=FC=DFe, Carsten


From prvs=74322535E2=guido.moritz@uni-rostock.de  Mon Mar 26 10:15:34 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6754A21E8107 for ; Mon, 26 Mar 2012 10:15:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 DrIYtIeePoyh for ; Mon, 26 Mar 2012 10:15:33 -0700 (PDT)
Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 958B621E8111 for ; Mon, 26 Mar 2012 10:15:32 -0700 (PDT)
From: Guido Moritz 
To: 'Thomas Fossati' , 'Salvatore Loreto' 
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>		<004001cd0b6b$f1051220$d30f3660$@uni-rostock.de>		<4F709ADC.6050800@ericsson.com> <3A433490-AB35-4340-9CA8-B5DA2FF69F26@koanlogic.com>
In-Reply-To: <3A433490-AB35-4340-9CA8-B5DA2FF69F26@koanlogic.com>
Date: Mon, 26 Mar 2012 19:15:44 +0200
Message-ID: <000601cd0b74$1444fdb0$3ccef910$@uni-rostock.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQI+jSyYxezHb35jh1VR9IZ1dfLDewJW3mWxAl6p5fIBW1ALowITp5uLAQekFwCVUGuzMA==
Content-Language: de
X-Originating-IP: [130.129.22.70]
Cc: core@ietf.org
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy	context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 17:15:34 -0000

> Anyway, if we want to provide such information, every I-D that introduces
new
> state (Observe and atomic Block the twos that come immediately to my mind)
> have to specify their own "appendix" FSM to the core FSM.
Block may benefit from this as well, indeed. But having a combined FSM for
all the funky features of CoAP may blow up the figure way too much. Maybe
first start with the easiest ones which have been identified during the ETSI
plugtest, i.e./e.g. separated response in lossy networks.

Guido


From kovatsch@inf.ethz.ch  Mon Mar 26 10:20:47 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B021C21E80E5 for ; Mon, 26 Mar 2012 10:20:47 -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 UqjQIRD8-FCd for ; Mon, 26 Mar 2012 10:20:47 -0700 (PDT)
Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id D46E421E80BC for ; Mon, 26 Mar 2012 10:20:46 -0700 (PDT)
Received: from CAS12.d.ethz.ch (172.31.38.212) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 26 Mar 2012 19:20:44 +0200
Received: from MBX10.d.ethz.ch ([169.254.1.51]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%10]) with mapi id 14.01.0355.002; Mon, 26 Mar 2012 19:20:45 +0200
From: "Kovatsch  Matthias" 
To: "cabo@tzi.org" 
Thread-Topic: [core] draft-ietf-core-coap-09: Artificial option count and length limitations
Thread-Index: Ac0LdMZGj1Q+m0sURGSXa615D7OvXQ==
Date: Mon, 26 Mar 2012 17:20:43 +0000
Message-ID: <9r8ktncasq4d5v8ehibgor77.1332782021418@email.android.com>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="utf-8"
Content-ID: <374B7DEFE0CD574D889FD8345588EED7@intern.ethz.ch>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "core@ietf.org" 
Subject: Re: [core] draft-ietf-core-coap-09: Artificial option count and length limitations
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 17:20:47 -0000

PiAxIC0tIHJlbW92aW5nIHRoZSAyNzAgbGltaXQsIGVuYWJsaW5nIHVzIHRvIGZpeCBsb25nIFVy
aS1Qcm94eSB2YWx1ZXMuDQoNClNvdW5kcyBnb29kLg0KDQo+IDIgLS0gZ29pbmcgYmFjayB0byB0
aGUgZHJhd2luZyBib2FyZCBvbiB0aGUgbWVzc2FnZSBmb3JtYXQgdG8gc29sdmUgYSBwcm9ibGVt
IHlvdSBkb24ndCBzdGF0ZSAoZXhjZXB0IHRoYXQgeW91IGFyZSAidW5oYXBweSIpLg0KDQpUaGUg
b25seSByZWFzb24gbm90IHRvIGRvIGl0IGNhbiBzZWUgaXMgbGVnYWN5LiBCdXQgdGhpcyBpcyBh
IGRyYWZ0LCB0aGVyZSBzaG91bGQgbm90IGJlIGFueSBsZWdhY3kuDQpEdXJpbmcgdGhlIFBsdWd0
ZXN0cyB0aGVyZSB3YXMgbm8gaXNzdWUgcGFyc2luZyB0aGUgYml0LWZpZWxkcyBvZiB0aGUgaGVh
ZGVycywgYXMgaXQgaXMgdHJpdmlhbC4gSSBkbyBub3Qga25vdyBob3cgbWFueSBpbXBsZW1lbnRh
dGlvbnMgd291bGQgaGF2ZSBoYWQgc3VwcG9ydCBmb3IgbW9yZSB0aGFuIDE1IG9wdGlvbnMsIGJ1
dCBpdCB3YXMgbm90IHRlc3RlZCBhbnl3YXkuIFVwZGF0ZXMgdG8gZHJhZnQtMDkgd2lsbCBuZWVk
IHRvIGNoYW5nZSB0aGVpciBPQyBoYW5kbGluZywgc28gY2hhbmdpbmcgdGhlIGhlYWRlciBoYW5k
bGluZyB3aWxsIG5vdCBiZSB0aGF0IHBhaW5mdWwuIFNvIG5vIGxvc3MgdGhlcmUuDQpXaXRoIHRo
ZSBjdXJyZW50IHR3by1mb2xkIGhhbmRsaW5nIG1vcmUgY29kZSBpcyByZXF1aXJlZCBmb3IgdGhl
IHVuaWZpZWQgbGVuZ3RoIGhhbmRsaW5nIGFuZCB0aGUgY3VycmVudCBkZXNpZ24gaXMgb25lIG9m
IHRob3NlIHdoZXJlIGZ1dHVyZSBnZW5lcmF0aW9ucyB3aWxsIGFzayAid2h5PyEiDQoNCkNpYW8N
Ck1hdHRoaWFzDQoNCg==

From kovatsch@inf.ethz.ch  Mon Mar 26 10:20:47 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E279E21E80BC for ; Mon, 26 Mar 2012 10:20:47 -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 t-+D-7Z4h7F4 for ; Mon, 26 Mar 2012 10:20:47 -0700 (PDT)
Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD9521E80BE for ; Mon, 26 Mar 2012 10:20:47 -0700 (PDT)
Received: from CAS20.d.ethz.ch (172.31.51.110) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 26 Mar 2012 19:20:44 +0200
Received: from MBX10.d.ethz.ch ([169.254.1.51]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%10]) with mapi id 14.01.0355.002; Mon, 26 Mar 2012 19:20:45 +0200
From: "Kovatsch  Matthias" 
To: "cabo@tzi.org" 
Thread-Topic: [core] draft-ietf-core-coap-09: Artificial option count and length limitations
Thread-Index: Ac0LdMZ1j1Q+m0sURGSXa615D7OvXQ==
Date: Mon, 26 Mar 2012 17:20:44 +0000
Message-ID: <9r8ktncasq4d5v8ehibgor77.1332782021418@email.android.com>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "core@ietf.org" 
Subject: Re: [core] draft-ietf-core-coap-09: Artificial option count and length limitations
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 17:20:48 -0000

PiAxIC0tIHJlbW92aW5nIHRoZSAyNzAgbGltaXQsIGVuYWJsaW5nIHVzIHRvIGZpeCBsb25nIFVy
aS1Qcm94eSB2YWx1ZXMuDQoNClNvdW5kcyBnb29kLg0KDQo+IDIgLS0gZ29pbmcgYmFjayB0byB0
aGUgZHJhd2luZyBib2FyZCBvbiB0aGUgbWVzc2FnZSBmb3JtYXQgdG8gc29sdmUgYSBwcm9ibGVt
IHlvdSBkb24ndCBzdGF0ZSAoZXhjZXB0IHRoYXQgeW91IGFyZSAidW5oYXBweSIpLg0KDQpUaGUg
b25seSByZWFzb24gbm90IHRvIGRvIGl0IGNhbiBzZWUgaXMgbGVnYWN5LiBCdXQgdGhpcyBpcyBh
IGRyYWZ0LCB0aGVyZSBzaG91bGQgbm90IGJlIGFueSBsZWdhY3kuDQpEdXJpbmcgdGhlIFBsdWd0
ZXN0cyB0aGVyZSB3YXMgbm8gaXNzdWUgcGFyc2luZyB0aGUgYml0LWZpZWxkcyBvZiB0aGUgaGVh
ZGVycywgYXMgaXQgaXMgdHJpdmlhbC4gSSBkbyBub3Qga25vdyBob3cgbWFueSBpbXBsZW1lbnRh
dGlvbnMgd291bGQgaGF2ZSBoYWQgc3VwcG9ydCBmb3IgbW9yZSB0aGFuIDE1IG9wdGlvbnMsIGJ1
dCBpdCB3YXMgbm90IHRlc3RlZCBhbnl3YXkuIFVwZGF0ZXMgdG8gZHJhZnQtMDkgd2lsbCBuZWVk
IHRvIGNoYW5nZSB0aGVpciBPQyBoYW5kbGluZywgc28gY2hhbmdpbmcgdGhlIGhlYWRlciBoYW5k
bGluZyB3aWxsIG5vdCBiZSB0aGF0IHBhaW5mdWwuIFNvIG5vIGxvc3MgdGhlcmUuDQpXaXRoIHRo
ZSBjdXJyZW50IHR3by1mb2xkIGhhbmRsaW5nIG1vcmUgY29kZSBpcyByZXF1aXJlZCBmb3IgdGhl
IHVuaWZpZWQgbGVuZ3RoIGhhbmRsaW5nIGFuZCB0aGUgY3VycmVudCBkZXNpZ24gaXMgb25lIG9m
IHRob3NlIHdoZXJlIGZ1dHVyZSBnZW5lcmF0aW9ucyB3aWxsIGFzayAid2h5PyEiDQoNCkNpYW8N
Ck1hdHRoaWFzDQoNCg==

From cabo@tzi.org  Mon Mar 26 10:34:57 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD8821F85AF for ; Mon, 26 Mar 2012 10:34:57 -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 kPsvbrSVfEAH for ; Mon, 26 Mar 2012 10:34: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 096E221F8569 for ; Mon, 26 Mar 2012 10:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2QHYl9r020770; Mon, 26 Mar 2012 19:34:47 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AE6DE653; Mon, 26 Mar 2012 19:34:47 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <9r8ktncasq4d5v8ehibgor77.1332782021418@email.android.com>
Date: Mon, 26 Mar 2012 19:34:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <93DB01AB-F5F6-4885-A840-A886682D71F0@tzi.org>
References: <9r8ktncasq4d5v8ehibgor77.1332782021418@email.android.com>
To: "Kovatsch  Matthias" 
X-Mailer: Apple Mail (2.1257)
Cc: "core@ietf.org" 
Subject: Re: [core] draft-ietf-core-coap-09: Artificial option count and length limitations
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 17:34:57 -0000

On Mar 26, 2012, at 19:20, Kovatsch Matthias wrote:

> The only reason not to do it can see is legacy. But this is a draft, =
there should not be any legacy.

There is not a single point in time where the cost of making changes =
suddenly increases from zero to infinite.
This is a gradual process.  We are pretty advanced on this curve =
already.
Most of CoAP has been stable since -06, and we have been tweaking minor =
points since.

We are way beyond the place where making gratuitous changes would be =
justifiable.

Every single change has a cost and a benefit.  This change (what I =
called 2) has a high cost (everybody has to change their implementation =
and we have to re-test, and we are likely to have a transition period in =
which there are both versions as we had with coap-03 and coap-06).  I =
happen to believe the actual benefits are negative, as well, but even if =
they were positive, we'd have to have a good reason now.

1 is a change with very small cost (the majority of cases will still =
interoperate).  Let's find out whether it is the best way to do this and =
then agree to do it.

Gr=FC=DFe, Carsten


From angelo.castellani@gmail.com  Mon Mar 26 12:17:54 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C877D21E8101; Mon, 26 Mar 2012 12:17:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id az+0HV2xrFBZ; Mon, 26 Mar 2012 12:17:54 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id E5F0821E8013; Mon, 26 Mar 2012 12:17:38 -0700 (PDT)
Received: by wibhj6 with SMTP id hj6so3773835wib.13 for ; Mon, 26 Mar 2012 12:17:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=tcHgbJ1LfDeswPWDdLYLgY1nONievoP/lockEzS/sdY=; b=gS2vHhfgoEWc5TUNGChUjht2G/L4W1TQ5zZUJkcU0VgwM3XSWeNt9UqZvOZISTHibS iG5i8kNNi2ulQnOrROQaCFhHJzjHqdEcS8J5VpSK53JV4YFG6soxa9awxn/KjqtD2aJy jJkmJ7tuJouAzIV3DKs6NSlAW9bzZnHB8c7KugX76/ufmtQPmFJkaWEe5S/Wp2ZrmIG9 GgyBhlXZuilpRcO0PWeGVxn3Bj59cMU3kSC0UBx6566YvitaISLWjMsm7OmE9WAZvW3q NNzvBIAfuUQMrSb1IfnAI2RnIOtrcVCekN7PZFO2nJUjpY2awiEHw3hgOGpKRHrlXuC7 LObw==
Received: by 10.216.132.202 with SMTP id o52mr13161645wei.106.1332789457937; Mon, 26 Mar 2012 12:17:37 -0700 (PDT)
MIME-Version: 1.0
Sender: angelo.castellani@gmail.com
Received: by 10.216.121.148 with HTTP; Mon, 26 Mar 2012 12:16:57 -0700 (PDT)
In-Reply-To: <20120326191208.9938.77384.idtracker@ietfa.amsl.com>
References: <20120326191208.9938.77384.idtracker@ietfa.amsl.com>
From: "Angelo P. Castellani" 
Date: Mon, 26 Mar 2012 21:16:57 +0200
X-Google-Sender-Auth: xJhIqHYo_sXUry01_oswj_kHM2A
Message-ID: 
To: lwip@ietf.org, core 
Content-Type: multipart/alternative; boundary=0016e6d647b23366bb04bc2a3ae7
Subject: [core] Fwd: New Version Notification for draft-castellani-lwig-coap-separate-responses-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, 26 Mar 2012 19:17:54 -0000

--0016e6d647b23366bb04bc2a3ae7
Content-Type: text/plain; charset=UTF-8

After the very interesting and useful ETSI CoAP Plugtest, and given the
recent discussion on the CoRE mailing list, I felt the urge to write a
short draft collecting some interesting examples of CoAP separate responses
that may happen in "lossy" environments.

I think that this document is mainly useful for protocol implementers, to
quickly review possible situations that their implementations are required
to handle.

You can access the document at:
http://tools.ietf.org/html/draft-castellani-lwig-coap-separate-responses

If you think that is good having such a document, I can continue working on
it.

Best,
Angelo

---------- Forwarded message ----------
From: 
Date: Mon, Mar 26, 2012 at 21:12
Subject: New Version Notification for
draft-castellani-lwig-coap-separate-responses-00.txt
To: angelo@castellani.net


A new version of I-D, draft-castellani-lwig-coap-separate-responses-00.txt
has been successfully submitted by Angelo P. Castellani and posted to the
IETF repository.

Filename:        draft-castellani-lwig-coap-separate-responses
Revision:        00
Title:           Learning CoAP separate responses by examples
Creation date:   2012-03-26
WG ID:           Individual Submission
Number of pages: 9

Abstract:
  This draft aims at providing interesting examples of CoAP separate
  responses that are useful to aid CoAP implementers on understanding
  possible rare situation incurring.




The IETF Secretariat

--0016e6d647b23366bb04bc2a3ae7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

After the very interesting and useful ETSI CoAP Plugtest, and given the rec=
ent discussion on the CoRE mailing list,=C2=A0I felt the urge to write a sh=
ort draft collecting some interesting examples of CoAP separate responses t=
hat may happen in "lossy" environments.




I think that this document is mainly useful for protocol imp=
lementers, to quickly review possible situations that their implementations=
 are required to handle.

You can access the docume=
nt at:





If you think th=
at is good having such a document, I can continue working on it.





Best,
Angelo

---------- Forwarded message ----------
From:  <internet-drafts@ietf.org>



Date: Mon, Mar 26, 2012 at 21:12
Subject: New Version Notification for d=
raft-castellani-lwig-coap-separate-responses-00.txt
To: angelo@castellani.net



A new version of I-D, draft-castellani-lwig-coap-separate-responses-00.=
txt has been successfully submitted by Angelo P. Castellani and posted to t=
he IETF repository.




Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-castellani-lwig-coap-separate-re=
sponses

Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000

Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Learning CoAP separate responses =
by examples

Creation date: =C2=A0 2012-03-26

WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission

Number of pages: 9



Abstract:

 =C2=A0 This draft aims at providing interesting examples of CoAP separate<=
br>
 =C2=A0 responses that are useful to aid CoAP implementers on understanding=


 =C2=A0 possible rare situation incurring.









The IETF Secretariat





--0016e6d647b23366bb04bc2a3ae7--

From jeroen.hoebeke@intec.ugent.be  Mon Mar 26 12:27:39 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB7D21E803C for ; Mon, 26 Mar 2012 12:27:39 -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 CEOM0kjeX98z for ; Mon, 26 Mar 2012 12:27:38 -0700 (PDT)
Received: from smtp3.UGent.be (smtp3.ugent.be [157.193.49.127]) by ietfa.amsl.com (Postfix) with ESMTP id F2E0D21E8013 for ; Mon, 26 Mar 2012 12:27:31 -0700 (PDT)
Received: from localhost (mcheck3.ugent.be [157.193.71.89]) by smtp3.UGent.be (Postfix) with ESMTP id BBCBD147EE4; Mon, 26 Mar 2012 21:27:30 +0200 (CEST)
X-Virus-Scanned: by UGent DICT
Received: from smtp3.UGent.be ([157.193.49.127]) by localhost (mcheck3.ugent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id 0JFy8QFJbhUF; Mon, 26 Mar 2012 21:27:30 +0200 (CEST)
Received: from [192.168.1.155] (ATuileries-152-1-36-124.w82-123.abo.wanadoo.fr [82.123.176.124]) (Authenticated sender: jjhoebek) by smtp3.UGent.be (Postfix) with ESMTPSA id 61145147EE2; Mon, 26 Mar 2012 21:27:28 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Jeroen Hoebeke 
In-Reply-To: <000601cd0b74$1444fdb0$3ccef910$@uni-rostock.de>
Date: Mon, 26 Mar 2012 21:27:28 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>		<004001cd0b6b$f1051220$d30f3660$@uni-rostock.de>		<4F709ADC.6050800@ericsson.com> <3A433490-AB35-4340-9CA8-B5DA2FF69F26@koanlogic.com> <000601cd0b74$1444fdb0$3ccef910$@uni-rostock.de>
To: Guido Moritz 
X-Mailer: Apple Mail (2.1257)
X-Miltered: at mcheck3 with ID 4F70C31F.001 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)!
X-j-chkmail-Enveloppe: 4F70C31F.001/82.123.176.124/ATuileries-152-1-36-124.w82-123.abo.wanadoo.fr/[192.168.1.155]/
X-j-chkmail-Score: MSGID : 4F70C31F.001 on smtp3.UGent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Cc: core WG 
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy	context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 19:27:39 -0000

On 26 Mar 2012, at 19:15, Guido Moritz wrote:

>> Anyway, if we want to provide such information, every I-D that =
introduces
> new
>> state (Observe and atomic Block the twos that come immediately to my =
mind)
>> have to specify their own "appendix" FSM to the core FSM.
> Block may benefit from this as well, indeed. But having a combined FSM =
for
> all the funky features of CoAP may blow up the figure way too much. =
Maybe
> first start with the easiest ones which have been identified during =
the ETSI
> plugtest, i.e./e.g. separated response in lossy networks.

State machines depicting client and server states is a good idea I =
definitely support, since it will help developers (in a similar how the =
examples in Appendix B can help them). Apart for state machines in the =
appendix, we should not forget to phrase all possible/allowed effects of =
packet losses in the draft text itself, thereby referring to the two =
suggestions I made in my earlier e-mail. Looking forward to any =
improvement or verification of these:

"The reception of a separate confirmable response before the =
acknowledgement should be considered as an implicit acknowledgement and =
should not result in a retransmission of the request in case the =
acknowledgment never arrives."

"The reception of a retransmitted confirmable response due to the loss =
of the client's acknowledgment, may result in RST message in case the =
client removed the state information after sending the acknowledgment."

Kind regards,
Jeroen



From kovatsch@inf.ethz.ch  Mon Mar 26 14:02:19 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6602421E8107 for ; Mon, 26 Mar 2012 14:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.854
X-Spam-Level: 
X-Spam-Status: No, score=-7.854 tagged_above=-999 required=5 tests=[AWL=-1.255, 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 ivqIeok12OqN for ; Mon, 26 Mar 2012 14:02:18 -0700 (PDT)
Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 3804421E8015 for ; Mon, 26 Mar 2012 14:02:15 -0700 (PDT)
Received: from CAS20.d.ethz.ch (172.31.51.110) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 26 Mar 2012 23:02:14 +0200
Received: from MBX10.d.ethz.ch ([169.254.1.51]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%10]) with mapi id 14.01.0355.002; Mon, 26 Mar 2012 23:02:14 +0200
From: "Kovatsch  Matthias" 
To: Carsten Bormann 
Thread-Topic: [core] draft-ietf-core-coap-09: Artificial option count and length limitations
Thread-Index: Ac0LdMZGj1Q+m0sURGSXa615D7OvXf//4mUA//+mNGA=
Date: Mon, 26 Mar 2012 21:02:14 +0000
Message-ID: <55877B3AFB359744BA0F2140E36F52B5139707EA@MBX10.d.ethz.ch>
References: <9r8ktncasq4d5v8ehibgor77.1332782021418@email.android.com> <93DB01AB-F5F6-4885-A840-A886682D71F0@tzi.org>
In-Reply-To: <93DB01AB-F5F6-4885-A840-A886682D71F0@tzi.org>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [83.202.17.18]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "core@ietf.org" 
Subject: Re: [core] draft-ietf-core-coap-09: Artificial option count and length limitations
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 21:02:19 -0000

> We are way beyond the place where making gratuitous changes would be
> justifiable.

Okay. Maybe we can then at least change to always using the option terminat=
or and make use of the 4 OC bits. Even if it is only reserving them for new=
 versions.

> Gr=FC=DFe, Carsten
Matthias


From sye.loong.keoh@philips.com  Mon Mar 26 15:09:03 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC63521E802A for ; Mon, 26 Mar 2012 15:09:03 -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 U3jSYHCRPsc3 for ; Mon, 26 Mar 2012 15:09:03 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6F821E801F for ; Mon, 26 Mar 2012 15:09:02 -0700 (PDT)
Received: from mail14-am1-R.bigfish.com (10.3.201.237) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Mon, 26 Mar 2012 22:08:49 +0000
Received: from mail14-am1 (localhost [127.0.0.1])	by mail14-am1-R.bigfish.com (Postfix) with ESMTP id B8AB680317	for ; Mon, 26 Mar 2012 22:08:48 +0000 (UTC)
X-SpamScore: -48
X-BigFish: VPS-48(zz217bL15d6O9251J2174M936eK542M1a09Jzz1202hzz1033IL8275dhz2dh2a8h668h839h93fhd25h)
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI
Received: from mail14-am1 (localhost.localdomain [127.0.0.1]) by mail14-am1 (MessageSwitch) id 1332799726658518_21850; Mon, 26 Mar 2012 22:08:46 +0000 (UTC)
Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.242])	by mail14-am1.bigfish.com (Postfix) with ESMTP id 92DC8406BB	for ; Mon, 26 Mar 2012 22:08:46 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 26 Mar 2012 22:08:45 +0000
Received: from 011-DB3MPN1-031.MGDPHG.emi.philips.com ([169.254.1.24]) by 011-DB3MMR1-009.MGDPHG.emi.philips.com ([10.128.28.48]) with mapi id 14.01.0355.003; Mon, 26 Mar 2012 23:10:59 +0100
From: "Keoh, Sye Loong" 
To: "core@ietf.org" 
Thread-Topic: New Version Notification for draft-garcia-core-security-04.txt
Thread-Index: AQHNC5r0EwDett+O70KiTbE6KGnT95Z9Hiyw
Date: Mon, 26 Mar 2012 22:08:38 +0000
Message-ID: 
References: <20120326215140.20793.73440.idtracker@ietfa.amsl.com>
In-Reply-To: <20120326215140.20793.73440.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [213.41.80.49]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Subject: [core] New Version Notification for draft-garcia-core-security-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: Mon, 26 Mar 2012 22:09:03 -0000

RGVhciBhbGwsDQoNCkluIHRoaXMgbmV3IHZlcnNpb24sIHdlIGhhdmUgdXBkYXRlZCB0aGUgY29u
Y2x1c2lvbnMgc2VjdGlvbiB0byByZWZsZWN0IHRoZSBzdGF0dXMgb2YgY3VycmVudCBzZWN1cml0
eSB0ZWNobm9sb2dpZXMgYW5kIHRoZSBtaXNzaW5nIGJpdHMgd2l0aCByZWdhcmRzIHRvIHRoZSBz
ZWN1cml0eSByZXF1aXJlbWVudHMgd2UgaWRlbnRpZmllZCBpbiB0aGUgZG9jdW1lbnQuDQoNClNp
bmNlIHRoZSBXRyBhZHZpc2VkIHRoYXQgd2Ugc2hvdWxkIGNvbnRpbnVlIHdvcmtpbmcgb24gdGhp
cyBkcmFmdCAgaW4gVGFpcGVpLCB3ZSBhcmUgY29udGludW91c2x5IGltcHJvdmluZyB0aGUgZHJh
ZnQgc28gdGhhdCBpdCBzZXJ2ZXMgaXRzIHB1cnBvc2UgdG8gcHJvdmlkZSBhbiBvdmVydmlldyBv
ZiB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGZvciBJb1QuIFRoZXJlZm9yZSwgd2Ugd291bGQg
Z3JlYXRseSBhcHByZWNpYXRlIGZlZWRiYWNrIGFuZCBjb21tZW50cyBmcm9tIFdHIG1lbWJlcnMg
b24gdGhpcyBkb2N1bWVudC4NCg0KTWFueSB0aGFua3MNClN5ZSBMb29uZw0KDQotLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86
aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KU2VudDogbWFhbmRhZyAyNiBtYWFydCAyMDEyIDIz
OjUyDQpUbzogS2VvaCwgU3llIExvb25nDQpDYzogcnN0cnVpay5leHRAZ21haWwuY29tOyBLdW1h
ciwgU2FuZGVlcDsgcmVuZS5odW1tZW5AY3Mucnd0aC1hYWNoZW4uZGU7IEdhcmNpYSBNb3JjaG9u
LCBPc2Nhcg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1nYXJj
aWEtY29yZS1zZWN1cml0eS0wNC50eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWdh
cmNpYS1jb3JlLXNlY3VyaXR5LTA0LnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk
IGJ5IFN5ZSBMb29uZyBLZW9oIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0K
RmlsZW5hbWU6ICAgICAgICBkcmFmdC1nYXJjaWEtY29yZS1zZWN1cml0eQ0KUmV2aXNpb246ICAg
ICAgICAwNA0KVGl0bGU6ICAgICAgICAgICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBpbiB0aGUg
SVAtYmFzZWQgSW50ZXJuZXQgb2YgVGhpbmdzDQpDcmVhdGlvbiBkYXRlOiAgIDIwMTItMDMtMjYN
CldHIElEOiAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6
IDQ1DQoNCkFic3RyYWN0Og0KICAgQSBkaXJlY3QgaW50ZXJwcmV0YXRpb24gb2YgdGhlIEludGVy
bmV0IG9mIFRoaW5ncyBjb25jZXB0IHJlZmVycyB0bw0KICAgdGhlIHVzYWdlIG9mIHN0YW5kYXJk
IEludGVybmV0IHByb3RvY29scyB0byBhbGxvdyBmb3IgaHVtYW4tdG8tdGhpbmcNCiAgIG9yIHRo
aW5nLXRvLXRoaW5nIGNvbW11bmljYXRpb24uICBBbHRob3VnaCB0aGUgc2VjdXJpdHkgbmVlZHMg
YXJlDQogICB3ZWxsLXJlY29nbml6ZWQsIGl0IGlzIHN0aWxsIG5vdCBmdWxseSBjbGVhciBob3cg
ZXhpc3RpbmcgSVAtYmFzZWQNCiAgIHNlY3VyaXR5IHByb3RvY29scyBjYW4gYmUgYXBwbGllZCB0
byB0aGlzIG5ldyBzZXR0aW5nLiAgVGhpcw0KICAgSW50ZXJuZXQtRHJhZnQgZmlyc3QgcHJvdmlk
ZXMgYW4gb3ZlcnZpZXcgb2Ygc2VjdXJpdHkgYXJjaGl0ZWN0dXJlLA0KICAgaXRzIGRlcGxveW1l
bnQgbW9kZWwgYW5kIGdlbmVyYWwgc2VjdXJpdHkgbmVlZHMgaW4gdGhlIGNvbnRleHQgb2YgdGhl
DQogICBsaWZlY3ljbGUgb2YgYSB0aGluZy4gIFRoZW4sIGl0IHByZXNlbnRzIGNoYWxsZW5nZXMg
YW5kIHJlcXVpcmVtZW50cw0KICAgZm9yIHRoZSBzdWNjZXNzZnVsIHJvbGwtb3V0IG9mIG5ldyBh
cHBsaWNhdGlvbnMgYW5kIHVzYWdlIG9mIHN0YW5kYXJkDQogICBJUC1iYXNlZCBzZWN1cml0eSBw
cm90b2NvbHMgd2hlbiBhcHBsaWVkIHRvIGdldCBhIGZ1bmN0aW9uYWwgSW50ZXJuZXQNCiAgIG9m
IFRoaW5ncy4NCg0KDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNz
YWdlIG1heSBiZSBjb25maWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxp
Y2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNz
ZWUocykuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVy
ZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgZm9yd2FyZGluZywgZGlzc2VtaW5hdGlvbiwgb3Ig
cmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBt
YXkgYmUgdW5sYXdmdWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBs
ZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCBhbmQgZGVzdHJveSBhbGwg
Y29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0K


From tho@koanlogic.com  Mon Mar 26 15:59:58 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6409921F8575 for ; Mon, 26 Mar 2012 15:59: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=[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 7wzjZ+ACYmuC for ; Mon, 26 Mar 2012 15:59:57 -0700 (PDT)
Received: from latitanza.investici.org (latitanza.investici.org [82.94.249.234]) by ietfa.amsl.com (Postfix) with ESMTP id A273221F856D for ; Mon, 26 Mar 2012 15:59:57 -0700 (PDT)
Received: from [82.94.249.234] (latitanza [82.94.249.234]) (Authenticated sender: tho@anche.no) by localhost (Postfix) with ESMTPSA id 2523B98449; Mon, 26 Mar 2012 22:59:55 +0000 (UTC)
X-DKIM: Sendmail DKIM Filter v2.8.2 latitanza.investici.org 2523B98449
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=koanlogic.com; s=stigmate; t=1332802796; bh=8LOwyQ/DMp9Oa35IVhz/jhpQgfwgN//FTpwqyqfoV2U=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pHYExS1IdnAEeLhrgVtiIo91GYA+eCfeAIUavB6lOqbsS0CDR04Fdll26wz5yxCpo SLmC+Nv7V0cHsFOPeAv+KLag9IWjfF0stNjrbjyEdzznL0Dr3a7z58TtDAQNRSkVm4 0OoNDwnBwhPcSJgWUYasVs+qzTspYA+9Jl099joU=
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Thomas Fossati 
In-Reply-To: 
Date: Tue, 27 Mar 2012 00:59:54 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7BFCD86A-AA06-45E9-8F4D-ABFC4AE9C681@koanlogic.com>
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>  <004001cd0b6b$f1051220$d30f3660$@uni-rostock.de>  <4F709ADC.6050800@ericsson.com> <3A433490-AB35-4340-9CA8-B5DA2FF69F26@koanlogic.com> 
To: Carsten Bormann 
X-Mailer: Apple Mail (2.1084)
Cc: core WG 
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Mar 2012 22:59:58 -0000

On Mar 26, 2012, at 7:11 PM, Carsten Bormann wrote:
> On Mar 26, 2012, at 19:08, Thomas Fossati wrote:
>> I have made my two FSMs pics before implementing evcoap that I can =
happily share if you want
>=20
> Yes, please.

http://koanlogic.com/coap/evcoap-server-fsm.pdf
http://koanlogic.com/coap/evcoap-client-fsm.pdf=

From jari.arkko@piuha.net  Mon Mar 26 23:31:31 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF6A21E8053 for ; Mon, 26 Mar 2012 23:31:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.545
X-Spam-Level: 
X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 rWV-ai7dEJXM for ; Mon, 26 Mar 2012 23:31:31 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 103FB21E801F for ; Mon, 26 Mar 2012 23:31:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 936E92DA0E for ; Tue, 27 Mar 2012 09:31:29 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAr-mWbFdZue for ; Tue, 27 Mar 2012 09:31:29 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 070C72CC56 for ; Tue, 27 Mar 2012 09:31:28 +0300 (EEST)
Message-ID: <4F715EC0.5000707@piuha.net>
Date: Tue, 27 Mar 2012 08:31:28 +0200
From: Jari Arkko 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: core 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [core] public key crypto on small devices
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 27 Mar 2012 06:31:31 -0000

We've done some work to understand what kind of public key crypto is possible on small devices. The results may be of interest:

http://tools.ietf.org/html/draft-aks-crypto-sensors-02

We'd also love to hear about other similar experiences to compare notes.

Jari


From jari.arkko@piuha.net  Mon Mar 26 23:43:42 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7DD21F845A for ; Mon, 26 Mar 2012 23:43:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.546
X-Spam-Level: 
X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 MCnmWxni3U9z for ; Mon, 26 Mar 2012 23:43:41 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id DDADF21F844A for ; Mon, 26 Mar 2012 23:43:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3BD7B2D35A for ; Tue, 27 Mar 2012 09:43:40 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZZrAc_eHfid for ; Tue, 27 Mar 2012 09:43:39 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 538AE2CC56 for ; Tue, 27 Mar 2012 09:43:39 +0300 (EEST)
Message-ID: <4F71619B.1020707@piuha.net>
Date: Tue, 27 Mar 2012 08:43:39 +0200
From: Jari Arkko 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: core 
References: <4F59F906.4080906@piuha.net> <6144B86F-0CAF-47E9-BE60-16647BFF22DA@tzi.org> <4F5A370A.7090308@piuha.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [core] feedback on resource-directory and mirror-proxy (and base) drafts
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 27 Mar 2012 06:43:42 -0000

Incidentally, as a part of our work on testing public key crypto on small devices, we also implemented an early prototype to give end-to-end security for mirror proxying. We think the approach has some appeal, given that validity can be checked at any time, through any number of proxies, can use zero-config or SSH like models, etc. Obviously this is very early work and we don't have all the pieces that we'd need to make this work fully. But nevertheless, we're putting it out for your consideration:

http://tools.ietf.org/html/draft-aks-crypto-sensors-02

(We also have some slides from the smart object security workshop about this, see http://www.arkko.com/publications/draft-aks-preso.pdf)

Jari


From salvatore.loreto@ericsson.com  Tue Mar 27 00:00:17 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A241B21F8730 for ; Tue, 27 Mar 2012 00:00:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.108
X-Spam-Level: 
X-Spam-Status: No, score=-110.108 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WkP3jcfzWHS for ; Tue, 27 Mar 2012 00:00:16 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 732A021F872E for ; Tue, 27 Mar 2012 00:00:16 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c6fae0000045c0-b4-4f71657fc51f
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 56.D9.17856.F75617F4; Tue, 27 Mar 2012 09:00:15 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Tue, 27 Mar 2012 09:00:15 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id EC4D22321; Tue, 27 Mar 2012 10:00:14 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 02CCF51E5C; Tue, 27 Mar 2012 10:00:15 +0300 (EEST)
Received: from dhcp-1324.meeting.ietf.org (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9ABCB51D5E; Tue, 27 Mar 2012 10:00:14 +0300 (EEST)
Message-ID: <4F71657D.4040006@ericsson.com>
Date: Tue, 27 Mar 2012 09:00:13 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Carsten Bormann 
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>  <1A3332BE-750E-4193-90BB-ED18D405E07A@tzi.org> <4F709BE5.5000701@ericsson.com> <20784A81-DE6C-4728-8A84-98E09DB5C9D2@tzi.org>
In-Reply-To: <20784A81-DE6C-4728-8A84-98E09DB5C9D2@tzi.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Cc: "core@ietf.org" 
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 27 Mar 2012 07:00:17 -0000

On 3/26/12 7:02 PM, Carsten Bormann wrote:
>>>> Probably in some cases you may want to use a separate response to be sure that the client has received it, but if we standardize that clients can lose their state this will not be possible anymore.
>>> That is not part of the REST semantics.
>>> If we have a good use case for this, we could decide that we want to make it work.
>>> Currently, as you note, there is no support "certified delivery" for responses, just as in HTTP.
>> I don't get the HTTP comparison here;
>> what do you mean saying that HTTP does not support "certified delivery" ?
>> you mean that if the TCP connection brakes (somehow) then the server has no way to send back an answer... or what
> In both protocols, there is no way for the server to find out whether the application actually processed the response successfully.
> (I.e., this is not a three-way ACK.)
> In the HTTP case, the server does not see whether the last bytes of its response reached the client's computer (this could be fixed by changing the TCP socket interface, but then there is no way to find out whether these then reached the client, and whether the client finished the processing e.g. before a crash).
sure,
but if you use TCP you are reasonable sure that the OS Stack does it 
works properly
so unless the server does not close the socket right after having sent 
the answer it works
and the REST semantic is safe...
not sure this is the case here in CoAP


From martin.thomson@gmail.com  Tue Mar 27 01:17:37 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B276D21F8551 for ; Tue, 27 Mar 2012 01:17:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.669
X-Spam-Level: 
X-Spam-Status: No, score=-4.669 tagged_above=-999 required=5 tests=[AWL=-1.070, 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 EVuaHTNvb24J for ; Tue, 27 Mar 2012 01:17:35 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C22D21F8554 for ; Tue, 27 Mar 2012 01:17:32 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so5379082bku.31 for ; Tue, 27 Mar 2012 01:17:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=e0UEZThlhWjdyVmqITAXjxwnPb/r6b7haGPWZ/R3b/4=; b=eEnUpLXteGIVwP9t0PDtZCKKoEJ+jSmEnIb4r+kX1Bc6JDidQdoSr95Q+d+L0wEbkP QhOAL0L8YTxlfUi/PNm8yTder+oPfysetkqUrBO7Hf27CeEKtRoJUSf1k7KZRIDgb7Mj Zbop7LjnVP8kezYAsqtbSQhjjz2cXQsInZzEivhtemAW8H36s01akmXTJYeH45FgKzbX ldBp975WOB3wwU4DiBsFE+sXbo0P2tUSVSj6IK5Rwvn7ujOWD0nxtGSqfuuX0ZnIgAtd 7sUFSOX9Lyha7blYGs667kP0KUKyv2B0xzZ5pmLbaD1DZOMUYvlZB9Q3BcmeA/1NvBy9 0J7g==
MIME-Version: 1.0
Received: by 10.205.137.14 with SMTP id im14mr9786163bkc.137.1332836251502; Tue, 27 Mar 2012 01:17:31 -0700 (PDT)
Received: by 10.205.38.73 with HTTP; Tue, 27 Mar 2012 01:17:31 -0700 (PDT)
Date: Tue, 27 Mar 2012 10:17:31 +0200
Message-ID: 
From: Martin Thomson 
To: core@ietf.org
Content-Type: text/plain; charset=UTF-8
Subject: [core] About the idea of a canonical resource
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 27 Mar 2012 08:17:37 -0000

This came up in discussion in the room, and I think that it's
something fairly important.

Jari raised the idea that there was a "resource" that might have
several ways to reach it.  I don't think that this works particularly
well when you consider the subjective view that each client will have
of that resource.

It's already fairly well understood that an IP address as an
identifier is something of a subjective concept.  The position of the
observer in the network can determine what an IP address actually
identifies.  The same problem extends to the identification of
resources.

coap://x/foo and coaps://x/foo are different resources.  The fact that
they have similar names, identical content and come from the same IP
is not useful.  That applies to resources accessed over different IP
versions; and names vs IPs.  These could be resources served by
entirely different servers and a client cannot make any assumptions
about the relationship of those identifiers.

Servers are only authoritative for the resources that they serve.
That doesn't mean that an application can't learn that two resources
are "the same" through means specific to the application.

Proxied requests are a little different.  A proxy in the classic sense
only passes information along from an authoritative server.  Though as
I understand it, the deployment of infrequently available nodes relies
on "proxies" that are really servers in the sense that they provide
the identifiers.  That is, you query for coap://proxy/foo rather than
coap://infrequently.available.device/foo; which leads to the
conclusion that the proxy is not a proxy, but an authoritative server
in its own right.

--Martin

From rstruik.ext@gmail.com  Tue Mar 27 02:29:02 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F068D21E80E4 for ; Tue, 27 Mar 2012 02:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tU7UEN96pTo for ; Tue, 27 Mar 2012 02:29:01 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7A30521E80CA for ; Tue, 27 Mar 2012 02:29:00 -0700 (PDT)
Received: by eaaq11 with SMTP id q11so1742894eaa.31 for ; Tue, 27 Mar 2012 02:28:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; bh=rkrcjxv3g0iuOIZilUZVd4TvFzoec+npskPHOIpbRZ0=; b=lbZ3qOZ+Bfc+uNbPMJF3Wn2UxIWzwis4Os8OWNeyYroSh+63Nt4rZMHiCqGmM2RLOc 0HSCVJ/IFCwqO8q0eB27hdltsXFTNRvThB3yiNcLna+Xgz2uB7RPI+NKTgdt+JUFnPhy QipEOZgZQ/dNlDirgXu7WHaMb8Cm3jZPfWRKS/rHrf0reoNs56jEIRul4r3chtAmP3fi 8d6a8M5PEDIihfcwYmduWYIF/sqWyJGgj+0oSClxkr7t3s7NPuioOgVkwVehQpm4yD5j lTekktgcK+l6CO1+zSWM+lkCdmiXqzzrdg1GNnStbs1eOzkk3axLQVW6BeQRBB6/aFXm 9yMg==
Received: by 10.213.11.2 with SMTP id r2mr1697071ebr.290.1332840539546; Tue, 27 Mar 2012 02:28:59 -0700 (PDT)
Received: from [88.159.137.152] (152-137-ftth.onsnetnuenen.nl. [88.159.137.152]) by mx.google.com with ESMTPS id d54sm67508711eei.9.2012.03.27.02.28.58 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 02:28:59 -0700 (PDT)
Message-ID: <4F718856.5050902@gmail.com>
Date: Tue, 27 Mar 2012 05:28:54 -0400
From: Rene Struik 
User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Jari Arkko 
References: <4F715EC0.5000707@piuha.net>
In-Reply-To: <4F715EC0.5000707@piuha.net>
X-Enigmail-Version: 1.4
Content-Type: multipart/alternative; boundary="------------060305000806030408010201"
Cc: core 
Subject: [core] (question on computational cost) Re: public key crypto on small devices
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 27 Mar 2012 09:29:02 -0000

This is a multi-part message in MIME format.
--------------060305000806030408010201
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Hi Jari:

Thanks for circulating this draft. If you could elaborate on the
underlying algorithms somewhat more (e.g., does RSA signing use CRT
method, what method for ECC scalar multiplication is used, modular
reduction method, tables with pre-computed points, etc), that would be
great.

This info may make it easier to analyze differences in computational
efficiencies and storage requirements when comparing with other approaches.

Background of this question is that there are some significant
differences in computational cost reported in your draft and numbers in
papers referenced on the "Relic" website
(https://sites.google.com/site/tinypbc/), such as with the following paper:
[1] Diego F. Aranha, Julio Lpez, Leonardo B. Oliveira and Ricardo
Dahab. Efficient implementation of elliptic curves on sensor nodes
.
Conference on Hyperelliptic curves, discrete Logarithms, Encryption,
etc., Frutillar, Chile, 2009.  slides


Your draft: ATMega 328, 16 MHz
Paper [1] above: ATMega 128, 7.3828 Mhz

            Paper [1] @8Mhz      Your draft @ 16Mhz 
++++++++++++++++++++++++++++++++++++++++++++
curve        C         Assemb           C  fast        Assemb
++++++++++++++++++++++++++++++++++++++++++++
K-163    0.67    0.32                    0.97            0.30
K-233    1.48    0.73                    1.83
B-163    1.55    0.74                    2.41
B-233    3.30    1.83                    4.83

Note that in [1] time latency, also without asembly coding, is up to
1.6x faster on a 2x slower clock speed processor.


On 27/03/2012 2:31 AM, Jari Arkko wrote:
> We've done some work to understand what kind of public key crypto is
> possible on small devices. The results may be of interest:
>
> http://tools.ietf.org/html/draft-aks-crypto-sensors-02
>
> We'd also love to hear about other similar experiences to compare notes.
>
> Jari
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363


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


  
    
  
  
    Hi Jari:

    

    Thanks for circulating this draft. If you could elaborate on the
    underlying algorithms somewhat more (e.g., does RSA signing use CRT
    method, what method for ECC scalar multiplication is used, modular
    reduction method, tables with pre-computed points, etc), that would
    be great.

    

    This info may make it easier to analyze differences in computational
    efficiencies and storage requirements when comparing with other
    approaches.

    

    Background of this question is that there are some significant
    differences in computational cost reported in your draft and numbers
    in papers referenced on the "Relic" website (https://sites.google.com/site/tinypbc/),
    such as with the following paper:

    [1] Diego F. Aranha, Julio López, Leonardo B. Oliveira and
      Ricardo Dahab. Efficient
          implementation of elliptic curves on sensor nodes. Conference on Hyperelliptic curves, discrete Logarithms,
      Encryption, etc., Frutillar, Chile, 2009.  slides

    

    Your draft: ATMega 328, 16 MHz

    Paper [1] above: ATMega 128, 7.3828 Mhz

    

                Paper [1] @8Mhz      Your draft @ 16Mhz  

    ++++++++++++++++++++++++++++++++++++++++++++

    curve        C         Assemb           C  fast        Assemb

    ++++++++++++++++++++++++++++++++++++++++++++

    K-163    0.67    0.32                    0.97            0.30

    K-233    1.48    0.73                    1.83

    B-163    1.55    0.74                    2.41

    B-233    3.30    1.83                    4.83

    

    Note that in [1] time latency, also without asembly coding, is up to
    1.6x faster on a 2x slower clock speed processor.

    

    

    On 27/03/2012 2:31 AM, Jari Arkko wrote:
    
We've
      done some work to understand what kind of public key crypto is
      possible on small devices. The results may be of interest:
      

      

      http://tools.ietf.org/html/draft-aks-crypto-sensors-02
      

      

      We'd also love to hear about other similar experiences to compare
      notes.
      

      

      Jari
      

      

      _______________________________________________
      

      core mailing list
      

      core@ietf.org
      

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

    

    

    

    
-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363

  


--------------060305000806030408010201--

From angelo.castellani@gmail.com  Tue Mar 27 02:33:31 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A6A21F8938; Tue, 27 Mar 2012 02:33:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+btRHyht0O4; Tue, 27 Mar 2012 02:33:31 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4801021F8934; Tue, 27 Mar 2012 02:33:29 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so3179183wgb.13 for ; Tue, 27 Mar 2012 02:33:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=YO11M81kJX9hAAF15LE62TK5GGV9O3mLfyFdhCBGTl0=; b=Tcnu6pQt3HsHOCAjddiS/Pf5mY2fNm5ZE2jQZgW7bE9BctcP4dHzw18rpF643v6pEj hRWU7DvO6eKm9QN0EQxmcYvUpmXvbTkSfnH2K1iCngRg3vwsbDBIZK1VpRT/NWZ4utWH 7JaQwnCvC2qWanONdvy6tRrK1AkRHJsX8PBAV+vqwYBdkyWbc16Sp6D5JbB32D6CGvJ5 E+XLjNkfThShcJAT2lgwmzyzLajhCWRrKt2sFuMVL4WQO31KNJK/4zQukt/HcJQErKba janchu4B+6RuHDm3gVOgpHQiBka62x/BKyt6d1+t7Qx4RNmc8F5pGEbgt74lUiAlMkwo 8aJg==
Received: by 10.180.24.7 with SMTP id q7mr25950089wif.11.1332840808386; Tue, 27 Mar 2012 02:33:28 -0700 (PDT)
MIME-Version: 1.0
Sender: angelo.castellani@gmail.com
Received: by 10.216.121.148 with HTTP; Tue, 27 Mar 2012 02:32:48 -0700 (PDT)
In-Reply-To: <7BFCD86A-AA06-45E9-8F4D-ABFC4AE9C681@koanlogic.com>
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>  <004001cd0b6b$f1051220$d30f3660$@uni-rostock.de>  <4F709ADC.6050800@ericsson.com> <3A433490-AB35-4340-9CA8-B5DA2FF69F26@koanlogic.com>  <7BFCD86A-AA06-45E9-8F4D-ABFC4AE9C681@koanlogic.com>
From: "Angelo P. Castellani" 
Date: Tue, 27 Mar 2012 11:32:48 +0200
X-Google-Sender-Auth: WC6UEaF1OgocRCZaLH5sfIBgAIQ
Message-ID: 
To: Thomas Fossati 
Content-Type: multipart/alternative; boundary=f46d043892abed0ee504bc362edc
Cc: lwip@ietf.org, core WG 
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 27 Mar 2012 09:33:31 -0000

--f46d043892abed0ee504bc362edc
Content-Type: text/plain; charset=UTF-8

On Tue, Mar 27, 2012 at 00:59, Thomas Fossati  wrote:

> http://koanlogic.com/coap/evcoap-server-fsm.pdf
> http://koanlogic.com/coap/evcoap-client-fsm.pdf


Nice drawing Thomas.

I think that your graph is more focused on the overall server/client
software implementation, and I found it quite complex to read from a
protocol perspective (are some states even missing?).

Following the suggestion of Guido, I tried to sketch the FSM of CoAP itself
from a protocol perspective point-of-view, mainly to better understand all
the possible transitions.

If you mind to have a look, you can find it here:
http://www.dei.unipd.it/~castellani/coap-fsm.pdf
(it is really a draft version right now, please be patient if you find any
error)

Best,
Angelo

p.s.: I still have to add the RST messages to the graph, I will update this
later.

--f46d043892abed0ee504bc362edc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 27, 2012 at 00:59, Thomas Fossati <tho@koanlogic.com> wrote:





http://koanlogic.com/coap/evcoap-server-fsm.pdf

http://koanlogic.com/coap/evcoap-client-fsm.pdf

Nice drawing Thomas.

I think tha=
t your graph is more focused on the overall server/client software implemen=
tation, and I found it quite complex to read from a protocol perspective (a=
re some states even missing?).







Following the suggestion of Guido, I tried to sketch th=
e FSM of CoAP itself from a protocol perspective point-of-view, mainly to b=
etter understand all the possible transitions.





If you mind to have a look, you can find it here:
(it is really a draft v=
ersion right now, please be patient if you find any error)





Best,


Angelo

p.s.: I still have to add the RST mess=
ages to the graph, I will update this later.


--f46d043892abed0ee504bc362edc--

From cabo@tzi.org  Tue Mar 27 04:31:50 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CDF21E818D; Tue, 27 Mar 2012 04:31:50 -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 FeNxZkf4q1YY; Tue, 27 Mar 2012 04:31:49 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 20D6A21E817F; Tue, 27 Mar 2012 04:31:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2RBVdKD028665; Tue, 27 Mar 2012 13:31:39 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 34196934; Tue, 27 Mar 2012 13:31:39 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Tue, 27 Mar 2012 13:31:38 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6FA878C6-AB5E-43B2-9474-36FF6670C265@tzi.org>
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>  <004001cd0b6b$f1051220$d30f3660$@uni-rostock.de>  <4F709ADC.6050800@ericsson.com> <3A433490-AB35-4340-9CA8-B5DA2FF69F26@koanlogic.com>  <7BFCD86A-AA06-45E9-8F4D-ABFC4AE9C681@koanlogic.com> 
To: "Angelo P. Castellani" 
X-Mailer: Apple Mail (2.1257)
Cc: lwip@ietf.org, core WG 
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 27 Mar 2012 11:31:51 -0000

On Mar 27, 2012, at 11:32, Angelo P. Castellani wrote:

> http://www.dei.unipd.it/~castellani/coap-fsm.pdf

Can we try to separate the message and request/response layers?

Gr=FC=DFe, Carsten


From angelo.castellani@gmail.com  Tue Mar 27 04:54:41 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2C821E81B6; Tue, 27 Mar 2012 04:54:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TKrX79uVbd5; Tue, 27 Mar 2012 04:54:40 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5BB21E81AE; Tue, 27 Mar 2012 04:54:36 -0700 (PDT)
Received: by wibhj6 with SMTP id hj6so4304547wib.13 for ; Tue, 27 Mar 2012 04:54:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Bbge5b1ex+MwCQBfNEasBt3zclqBpgJGRLvnQRuETvc=; b=P4UInxthRGt1d6iSxziwsFHD3DnhLtKUc9Sl2AJouIFofWugUMlMHzml37d8oYD0kG hM5stHnrTfohiXgf8bXqlEgquwm3fVbOk8NuVekoJukHs0fL7q9dZHcUPfisakTh3X5M QH2si+K8upWl9smFp5E30SOuEnH3VdmBIK78EsFhbLD61IetBOefPCXZzqimwgLAfeqh sBhVsWcWHo8HKwFyjmCgv1WminizkbWYxiX9c5l+1oOci4o4PyaiCRLRWPUXS17oQQL3 75+4JafgxfczLnsNptit+S/91ikdMgipVK4ZZmzcb8becO3JS86F0C7xe1CdjVDNZ62q Ppiw==
Received: by 10.180.83.198 with SMTP id s6mr26868089wiy.8.1332849275398; Tue, 27 Mar 2012 04:54:35 -0700 (PDT)
MIME-Version: 1.0
Sender: angelo.castellani@gmail.com
Received: by 10.216.121.148 with HTTP; Tue, 27 Mar 2012 04:53:54 -0700 (PDT)
In-Reply-To: <6FA878C6-AB5E-43B2-9474-36FF6670C265@tzi.org>
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>  <004001cd0b6b$f1051220$d30f3660$@uni-rostock.de>  <4F709ADC.6050800@ericsson.com> <3A433490-AB35-4340-9CA8-B5DA2FF69F26@koanlogic.com>  <7BFCD86A-AA06-45E9-8F4D-ABFC4AE9C681@koanlogic.com>  <6FA878C6-AB5E-43B2-9474-36FF6670C265@tzi.org>
From: "Angelo P. Castellani" 
Date: Tue, 27 Mar 2012 13:53:54 +0200
X-Google-Sender-Auth: w2tQkU6tVLI4FvOATFwiyPgfl78
Message-ID: 
To: Carsten Bormann 
Content-Type: multipart/alternative; boundary=f46d0442726c996a0e04bc3827d8
Cc: lwip@ietf.org, core WG 
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 27 Mar 2012 11:54:41 -0000

--f46d0442726c996a0e04bc3827d8
Content-Type: text/plain; charset=UTF-8

On Tue, Mar 27, 2012 at 13:31, Carsten Bormann  wrote:

> Can we try to separate the message and request/response layers?
>

Having the Token Option in the request/response layer leads to a problem in
the separation.

In this state machine graph I made the assumption that proper session
matching is applied before applying state transitions. In my point of view
"proper session matching" means checking (loc-host, loc-port, rem-host,
rem-port, token).

Legenda: "loc: Local", "rem: Remote", "host: IP Host", "port: UDP Port",
"token: CoAP Token Option"

If I remove the Token Option from the session matching condition (i.e., I
check [loc-host, loc-port, rem-host, rem-port]), I can't devise any real
state since I can still receive any message in any state, and transition to
any other state depending upon the Token contained in it... Suggestions?

Best,
Angelo

--f46d0442726c996a0e04bc3827d8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 27, 2012 at 13:31, Carsten Bormann <cabo@tzi.org> wro=
te:





Can we try to separate the message and request/response layers?

Having the Token Option in the request/respo=
nse layer leads to a problem in the separation.



In this state machine graph I made the assumption that proper se=
ssion matching is applied before applying state transitions.=C2=A0In my poi=
nt of view "proper session matching" means checking=C2=A0(loc-hos=
t, loc-port, rem-host, rem-port, token).





Legenda: "loc: Local", "rem: Remote"=
;, "host: IP Host", "port: UDP Port", "token: CoAP=
 Token Option"

If I remove the Token Option f=
rom the session matching condition (i.e., I check [loc-host, loc-port, rem-=
host, rem-port]), I can't devise any real state since I can still recei=
ve any message in any state, and transition to any other state depending up=
on the Token contained in it... Suggestions?





Best,
Angelo


--f46d0442726c996a0e04bc3827d8--

From cabo@tzi.org  Tue Mar 27 05:01:10 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264B221F8A05 for ; Tue, 27 Mar 2012 05:01:10 -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 f4oNKd72tcXA for ; Tue, 27 Mar 2012 05:01:09 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4270A21F89CA for ; Tue, 27 Mar 2012 05:01:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2RC11ko015682; Tue, 27 Mar 2012 14:01:01 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F322295B; Tue, 27 Mar 2012 14:01:00 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <000601cd0b74$1444fdb0$3ccef910$@uni-rostock.de>
Date: Tue, 27 Mar 2012 14:00:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <81CF2226-C08E-4E74-9B50-C93E99E9C5B5@tzi.org>
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>		<004001cd0b6b$f1051220$d30f3660$@uni-rostock.de>		<4F709ADC.6050800@ericsson.com> <3A433490-AB35-4340-9CA8-B5DA2FF69F26@koanlogic.com> <000601cd0b74$1444fdb0$3ccef910$@uni-rostock.de>
To: Guido Moritz 
X-Mailer: Apple Mail (2.1257)
Cc: core@ietf.org
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy	context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 27 Mar 2012 12:01:10 -0000

An ACK-0 (the one you get for a request that causes a separate response, =
as well as the one that asks the separate response) does not have a =
token.
I believe we still have a proper separation between the =
retransmission/duplicate detection mechanics (based on MID) and the =
request/response layer.
Can you point out where you need the token to do the matching here?

I don't know what a "session" is, by the way.

Gr=FC=DFe, Carsten


From cabo@tzi.org  Tue Mar 27 05:02:13 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4181021F88CE for ; Tue, 27 Mar 2012 05:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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 IgVW2KfiQojC for ; Tue, 27 Mar 2012 05:02: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 88BF221F88CD for ; Tue, 27 Mar 2012 05:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2RC24EC016350; Tue, 27 Mar 2012 14:02:04 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B406095C; Tue, 27 Mar 2012 14:02:04 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <81CF2226-C08E-4E74-9B50-C93E99E9C5B5@tzi.org>
Date: Tue, 27 Mar 2012 14:02:04 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>		<004001cd0b6b$f1051220$d30f3660$@uni-rostock.de>		<4F709ADC.6050800@ericsson.com> <3A433490-AB35-4340-9CA8-B5DA2FF69F26@koanlogic.com> <000601cd0b74$1444fdb0$3ccef910$@uni-rostock.de> <81CF2226-C08E-4E74-9B50-C93E99E9C5B5@tzi.org>
To: Guido Moritz 
X-Mailer: Apple Mail (2.1257)
Cc: core@ietf.org
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy	context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 27 Mar 2012 12:02:13 -0000

On Mar 27, 2012, at 14:00, Carsten Bormann wrote:

> An ACK-0 (the one you get for a request that causes a separate =
response, as well as the one that asks the separate response) does not =
have a token.
> I believe we still have a proper separation between the =
retransmission/duplicate detection mechanics (based on MID) and the =
request/response layer.
> Can you point out where you need the token to do the matching here?
>=20
> I don't know what a "session" is, by the way.
>=20
> Gr=FC=DFe, Carsten

Sorry, this one was about Angelo's last message.

Gr=FC=DFe, Carsten


From cabo@tzi.org  Tue Mar 27 05:11:32 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F4B21E80B3 for ; Tue, 27 Mar 2012 05:11:32 -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 itX1tsvGJ1kF for ; Tue, 27 Mar 2012 05:11:31 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E017A21F8A4E for ; Tue, 27 Mar 2012 05:11:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2RCBNPb021648; Tue, 27 Mar 2012 14:11:23 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 22F2096C; Tue, 27 Mar 2012 14:11:23 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <4F71657D.4040006@ericsson.com>
Date: Tue, 27 Mar 2012 14:11:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5780B368-0DF7-4F1F-BA06-5EF6DB3F6F70@tzi.org>
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>  <1A3332BE-750E-4193-90BB-ED18D405E07A@tzi.org> <4F709BE5.5000701@ericsson.com> <20784A81-DE6C-4728-8A84-98E09DB5C9D2@tzi.org> <4F71657D.4040006@ericsson.com>
To: Salvatore Loreto 
X-Mailer: Apple Mail (2.1257)
Cc: "core@ietf.org" 
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 27 Mar 2012 12:11:32 -0000

On Mar 27, 2012, at 09:00, Salvatore Loreto wrote:

> On 3/26/12 7:02 PM, Carsten Bormann wrote:
>>>>> Probably in some cases you may want to use a separate response to =
be sure that the client has received it, but if we standardize that =
clients can lose their state this will not be possible anymore.
>>>> That is not part of the REST semantics.
>>>> If we have a good use case for this, we could decide that we want =
to make it work.
>>>> Currently, as you note, there is no support "certified delivery" =
for responses, just as in HTTP.
>>> I don't get the HTTP comparison here;
>>> what do you mean saying that HTTP does not support "certified =
delivery" ?
>>> you mean that if the TCP connection brakes (somehow) then the server =
has no way to send back an answer... or what
>> In both protocols, there is no way for the server to find out whether =
the application actually processed the response successfully.
>> (I.e., this is not a three-way ACK.)
>> In the HTTP case, the server does not see whether the last bytes of =
its response reached the client's computer (this could be fixed by =
changing the TCP socket interface, but then there is no way to find out =
whether these then reached the client, and whether the client finished =
the processing e.g. before a crash).
> sure,
> but if you use TCP you are reasonable sure that the OS Stack does it =
works properly
> so unless the server does not close the socket right after having sent =
the answer it works

No, the app may have crashed.
It may have become impatient and have closed the socket before the data =
actually got delivered.
It may be buggy and simply not read the offered data.
Etc.

> and the REST semantic is safe...
> not sure this is the case here in CoAP

Exactly the same, I'd say.

(But, yes, having TCP implemented professionally in the kernel has its =
advantages that application developers don't always keep in mind.)

Gr=FC=DFe, Carsten


From cabo@tzi.org  Tue Mar 27 07:17:25 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454B321F8859 for ; Tue, 27 Mar 2012 07:17:25 -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 VnfhrDtjM81d for ; Tue, 27 Mar 2012 07:17: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 8816A21F866B for ; Tue, 27 Mar 2012 07:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2REH87M029194 for ; Tue, 27 Mar 2012 16:17:08 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 33316A2A; Tue, 27 Mar 2012 16:17:08 +0200 (CEST)
From: Carsten Bormann 
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Tue, 27 Mar 2012 16:17:07 +0200
To: "core@ietf.org WG" 
Message-Id: <1500B915-DEBD-44A4-AC11-6379755FFAF6@tzi.org>
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
Subject: [core] CoRE simple service discovery
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 27 Mar 2012 14:17:25 -0000

I have updated and resubmitted

	=
http://tools.ietf.org/html/draft-bormann-core-simple-server-discovery

It appears this is still needed.
(I let the draft lapse when I didn't resubmit it because there haven't =
been changes to its technical content).

Gr=FC=DFe, Carsten


From angelo.castellani@gmail.com  Tue Mar 27 07:53:23 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD95721E816D for ; Tue, 27 Mar 2012 07:53:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2oQiqlBj7AF for ; Tue, 27 Mar 2012 07:53:23 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 51C7521E816B for ; Tue, 27 Mar 2012 07:53:22 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so6962wgb.13 for ; Tue, 27 Mar 2012 07:53:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=ojmtLN5Hm7KvC4ObXnddh2NndYlbZxxa0RrxYLVqJ3A=; b=xWb8WMZwklieUOFhZ9AfRf3gH+Amk47nZhYImGhTrRVs07TVK+3YCnMLKgoFNwWWHR RXSVY89iz5h+s/XfUkSF75Yvti0npkxrlPKmxk1J0YZAs81YNvt2rXw4Bh/j2uqwdoaz neqUzp36s5THhTKM0dPLB8o6NbUzmZXjIr+z5DP+kisirjZuSFmgDlB2rbfsPwc68Axc a76pjCkBLsJ7oazplMP/Yy5YgDjGcW+0gZSbJcHJ9lzugjVz1sVxQOrdAKK6Ll6w/pnt rMm/nsZ3qyq/K6uOrsFdbXxg8X6/owmtQCF14Oy4ZgXJTa1vj4XZ74wdUwnylNF3freo tKSw==
Received: by 10.180.73.143 with SMTP id l15mr28230843wiv.11.1332860001449; Tue, 27 Mar 2012 07:53:21 -0700 (PDT)
MIME-Version: 1.0
Sender: angelo.castellani@gmail.com
Received: by 10.216.121.148 with HTTP; Tue, 27 Mar 2012 07:52:40 -0700 (PDT)
In-Reply-To: 
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>  <004001cd0b6b$f1051220$d30f3660$@uni-rostock.de>  <4F709ADC.6050800@ericsson.com> <3A433490-AB35-4340-9CA8-B5DA2FF69F26@koanlogic.com> <000601cd0b74$1444fdb0$3ccef910$@uni-rostock.de> <81CF2226-C08E-4E74-9B50-C93E99E9C5B5@tzi.org> 
From: "Angelo P. Castellani" 
Date: Tue, 27 Mar 2012 16:52:40 +0200
X-Google-Sender-Auth: -Z_DOcbYPnQMksCusjvlPaQRsjY
Message-ID: 
To: Carsten Bormann 
Content-Type: multipart/alternative; boundary=f46d043c06bcebf89904bc3aa615
Cc: core@ietf.org
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 27 Mar 2012 14:53:23 -0000

--f46d043c06bcebf89904bc3aa615
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I propose an example to better clarify my point:
           C                S
           |                |
id=3D0x38 |  | GET /a         | /|\
        |  | Token: "a"     |  | id=3D0x21
=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
           | CON MID=3D0x1234 |
           |--------------->|
           |                |
id=3D0x39 |  | GET /b         | /|\
        |  | Token: "b"     |  | id=3D0x22
=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
           | CON MID=3D0x1235 |
           |--------------->|
           |                | response is delayed
           |                | message layer sends
           | ACK MID=3D0x1235 | an empty ack
           |<---------------|
           |                |
id=3D0x? /|\ | 2.05 "B"       |  |
38 or 39|  | Token: "b"     |  | id=3D0x22
=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
           | CON MID=3D0xfefe |
           |<---------------|

Assume that the message-layer has no knowledge of the content of each
message, but its knowledge is limited to an identifier univocally
identifying each different conversation (previously called session).

How does the message-layer know to which identifier should the response in
the example be mapped to?

Best,
Angelo

On Tue, Mar 27, 2012 at 14:02, Carsten Bormann  wrote:

> On Mar 27, 2012, at 14:00, Carsten Bormann wrote:
>
> > An ACK-0 (the one you get for a request that causes a separate response=
,
> as well as the one that asks the separate response) does not have a token=
.
> > I believe we still have a proper separation between the
> retransmission/duplicate detection mechanics (based on MID) and the
> request/response layer.
> > Can you point out where you need the token to do the matching here?
> >
> > I don't know what a "session" is, by the way.
> >
> > Gr=C3=BC=C3=9Fe, Carsten
>
> Sorry, this one was about Angelo's last message.
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

--f46d043c06bcebf89904bc3aa615
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I propose an exa=
mple to better clarify my point:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0S
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|




id=3D0x38 | =C2=A0| GET /a =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 | /|\


=C2=A0 =C2=A0 =C2=A0 =C2=A0 | =
=C2=A0| Token: "a" =C2=A0 =C2=A0 | =C2=A0| id=3D0x21
=

=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<=
/font>
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0| CON MID=3D0x1234 |





=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0|--------------->|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
id=3D0x39 | =C2=A0| GET /b =C2=A0 =C2=A0 =C2=A0 =C2=A0 | /=
|\





=C2=A0 =C2=A0 =C2=A0 =C2=A0 | =
=C2=A0| Token: "b" =C2=A0 =C2=A0 | =C2=A0| id=3D0x22
=

=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<=
/font>
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0| CON MID=3D0x1235 |





=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0|--------------->|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| response is delayed
<=
font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0|=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0| message layer sends





=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0|=C2=A0ACK MID=3D0x1235=C2=A0| an empty ack




=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0|<---------------|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
id=3D0x? /|\ | 2.05 "B" =C2=A0 =C2=A0 =C2=A0 | =
=C2=A0|





38 or 39| =C2=A0| Token: "b=
" =C2=A0 =C2=A0 | =C2=A0| id=3D0x22
=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
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0| CON MID=3D0xfefe |





=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0|<---------------|

Assume that=
 the message-layer has no knowledge of the content of each message, but its=
 knowledge is limited to an identifier univocally identifying each differen=
t conversation (previously called session).





How does the message-layer know to which identifier should t=
he response in the example be mapped to?



Best,
Angelo

On Tue, Mar 27, 2012 at 14:02, Carsten Bormann <cabo@tzi.org=
> wrote:







On Mar 27, 2012, at 14:00, Carsten Bormann wrote:



> An ACK-0 (the one you get for a request that causes a separate respons=
e, as well as the one that asks the separate response) does not have a toke=
n.

> I believe we still have a proper separation between the retransmission=
/duplicate detection mechanics (based on MID) and the request/response laye=
r.

> Can you point out where you need the token to do the matching here?
>

> I don't know what a "session" is, by the way.

>

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




Sorry, this one was about Angelo's last message.




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



_______________________________________________

core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core





--f46d043c06bcebf89904bc3aa615--

From ietf@meetecho.com  Tue Mar 27 12:22:13 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C8321F8666 for ; Tue, 27 Mar 2012 12:22:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.866
X-Spam-Level: 
X-Spam-Status: No, score=-0.866 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cx4leHNffA-w for ; Tue, 27 Mar 2012 12:22:13 -0700 (PDT)
Received: from smtplq02.aruba.it (smtplqs-out28.aruba.it [62.149.158.68]) by ietfa.amsl.com (Postfix) with SMTP id 7DF3E21F84FD for ; Tue, 27 Mar 2012 12:22:06 -0700 (PDT)
Received: (qmail 32029 invoked by uid 89); 27 Mar 2012 19:22:04 -0000
Received: from unknown (HELO smtp6.aruba.it) (62.149.158.226) by smtplq02.aruba.it with SMTP; 27 Mar 2012 19:22:04 -0000
Received: (qmail 4339 invoked by uid 89); 27 Mar 2012 19:22:04 -0000
Received: from unknown (HELO ?130.129.21.177?) (ietf@meetecho.com@130.129.21.177) by smtp6.ad.aruba.it with SMTP; 27 Mar 2012 19:22:04 -0000
Message-ID: <4F721358.5010702@meetecho.com>
Date: Tue, 27 Mar 2012 21:22:00 +0200
From: Meetecho IETF support 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: core@ietf.org
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: smtp6.ad.aruba.it 1.6.2 0/1000/N
X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N
Subject: [core] Meetecho session recording available
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 27 Mar 2012 19:22:14 -0000

Dear all,

the full recording (synchronized video, audio, slides and jabber room)
of CORE session at IETF-83 is available.

You can watch it by either clicking the proper link on the remote 
participation page 
(http://www.ietf.org/meeting/83/remote-participation.html#Meetecho), or 
by directly accessing the following URL:
http://www.meetecho.com/ietf83/recordings#CORE_IETF83

For the chair(s): please feel free to put the link to the recording in 
the minutes, if you think this might be useful.

In case of problems with the playout, just drop an e-mail to
ietf-support@meetecho.com.

Cheers,
the Meetecho team

-- 
Meetecho s.r.l.
Web Conferencing and Collaboration Tools
www.meetecho.com

From jari.arkko@piuha.net  Tue Mar 27 14:03:36 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681E621E80F8 for ; Tue, 27 Mar 2012 14:03:36 -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 lLYnFQ0YYdi0 for ; Tue, 27 Mar 2012 14:03:35 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id BFE9D21E80F2 for ; Tue, 27 Mar 2012 14:03:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 159B52D35A; Wed, 28 Mar 2012 00:03:35 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1VXxJEEFSFY; Wed, 28 Mar 2012 00:03:34 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id DE3002CC56; Wed, 28 Mar 2012 00:03:33 +0300 (EEST)
Message-ID: <4F722B25.5040300@piuha.net>
Date: Tue, 27 Mar 2012 23:03:33 +0200
From: Jari Arkko 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Rene Struik 
References: <4F715EC0.5000707@piuha.net> <4F718856.5050902@gmail.com>
In-Reply-To: <4F718856.5050902@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: core 
Subject: Re: [core] (question on computational cost) Re: public key crypto on small devices
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 27 Mar 2012 21:03:36 -0000

Thanks for the pointer to the other results. We are collecting papers of =
similar measurements, and this is a good addition.

I don't know the reason for the differences, but I asked Mohit to find ou=
t if he has an answer. Note that there are many compiler options, algorit=
hm optimization choices when you compile the libraries listed in the draf=
t, and other similar things that might affect the results. It is also pos=
sible that we have missed something; we have not done much verification y=
et that our numbers are really representing the right thing, except check=
ing that the crypto verifies correctly between different devices. In gene=
ral, if someone has really spent a lot of effort to pick the right optimi=
zation flags and algorithm settings, I'd expect them to beat our numbers =
which seems to be the case here. Then again, our approach was to see what=
 we get when we act like a typical implementation engineer would act when=
 needing to use these algorithms for a project: get some libraries, compi=
le them with reasonable looking options, test that the crypto works, try =
a few different libraries, pick the best=20
ones, not spend more than a few weeks in the process :-)

Jari



From kovatsch@inf.ethz.ch  Wed Mar 28 00:51:33 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10D421F88D6 for ; Wed, 28 Mar 2012 00:51:33 -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_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 eYrw0cxaFrOf for ; Wed, 28 Mar 2012 00:51:32 -0700 (PDT)
Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id EC76B21F88E5 for ; Wed, 28 Mar 2012 00:51:30 -0700 (PDT)
Received: from CAS12.d.ethz.ch (172.31.38.212) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 28 Mar 2012 09:51:29 +0200
Received: from MBX10.d.ethz.ch ([169.254.1.51]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%10]) with mapi id 14.01.0355.002; Wed, 28 Mar 2012 09:51:28 +0200
From: "Kovatsch  Matthias" 
To: "angelo@castellani.net" , "cabo@tzi.org" 
Thread-Topic: [core] draft-ietf-core-coap-09: Separate response in a lossy context
Thread-Index: Ac0Mt5TNKfsu0ov9HUKF8eapwiEiPA==
Date: Wed, 28 Mar 2012 07:51:28 +0000
Message-ID: 
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "core@ietf.org" 
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy	context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 28 Mar 2012 07:51:34 -0000

SGkNCg0KSSB3aWxsIGRlc2NyaWJlIG15IGV4cGVyaWVuY2UgdG93YXJkcyB0aGlzIHBvaW50IHRo
YXQgSSBnYWluZWQgZHVyaW5nIGltcGxlbWVudGF0aW9uLg0KDQpJIHRoaW5rIHRoZSBwcm9ibGVt
IGlzIHRoYXQgeW91IGNhbm5vdCBhc3NpZ24gdGhlc2UgSURzIGF0IHRoZSBtZXNzYWdlIGxheWVy
LiBZb3VyIElEcyBjbGVhcmx5IHJlcHJlc2VudCBhIHJlcXVlc3QvcmVzcG9uc2UgcGFpciB0aGF0
IGlzIGlkZW50aWZpZWQgYnkgZW5kLXBvaW50IGFkZHJlc3MgKyB0b2tlbiAoc29tZXRoaW5nIEkg
YWxzbyBwcmV2aW91c2x5IGNhbGxlZCBhIHNlc3Npb24sIGFzIGEgYmxvY2t3aXNlIHRyYW5zZmVy
IGNvdWxkIGhhcHBlbiBiZWxvdyB0aGlzIGFic3RyYWN0aW9uKS4NCkluIHlvdXIgY2hhcnQsIHRo
ZSBtZXNzYWdlIGxheWVyIGNhbiBvbmx5IGFnbm9zdGljbHkgZGVsaXZlciB0aGUgbWFzc2FnZSB1
cHdhcmRzIGFuZCBzb21lIHVwcGVyIGluc3RhbmNlIG1ha2VzIHRoZSB0b2tlbiBtYXRjaGluZyAo
SSBjYWxsIGl0IHRoZSB0b2tlbiBsYXllcikuDQpBIHByb2JsZW0gaXMgbm93LCB3aG8gc2hvdWxk
IGFja25vd2xlZGdlIHRoZSBpbmNvbWluZyBDT04sIHRoZSBtZXNzYWdlIGxheWVyIG9yIHRoZSB0
b2tlbiBsYXllcj8gQXMgaXQgaXMgdW5saWtlbHkgdGhhdCB0aGlzIHJlY2VpdmVkIG1lc3NhZ2Ug
Z2V0cyBsb3N0IGludGVybmFsbHksIHRoZSBtZXNzYWdlIGxheWVyIGNhbiBBQ0sgaXQuIElmIHRo
aXMgQUNLIGdldHMgbG9zdCBvbiB0aGUgY2hhbm5lbCBhbmQgYSByZXRyYW5zbWlzc2lvbiBhcnJp
dmVzLCB0aGVyZSBhcmUgbXVsdGlwbGUgb3B0aW9uczoNCi0gVGhlIGR1cGxpY2F0ZSBkZXRlY3Rp
b24gcmVjb2duaXplcyB0aGUgbWVzc2FnZSwgQUNLcyBpdCBhbmQgZG9lcyBub3QgZGVsaXZlciBp
dCB1cHdhcmRzLg0KLSBUaGVyZSBpcyBubyBkdXAgZGV0ZWN0aW9uIGFuZCB0aGUgbWVzc2FnZSBp
cyBwYXNzZWQgdXB3YXJkcy4gTm93LCB0aGUgdG9rZW4gbGF5ZXIgd2lsbCBub3QgYmUgYWJsZSB0
byBtYWtlIGEgbWF0Y2gsIGFzIHRoZSB0b2tlbiAiYiIgd2FzIGFscmVhZHkgY2xvc2VkLiBTbyBp
dCB3aWxsIHNlbmQgYSBSU1QsIGJ1dCB0aGlzIGlzIG5vIHByb2JsZW0uIFRoZSBzZXJ2ZXIga25v
d3MgaXQgZGlkIGZ1bGZpbGwgdGhlIHJlcXVlc3QsIHRoZSBjbGllbnQgaXMganVzdCBub3QgaW50
ZXJlc3RlZCBhbnltb3JlLiBUaGlzIGRvZXMgbm90IG1lZXQgYSB0cmFuc2FjdGlvbi1saWtlIHJl
cXVlc3QvcmVzcG9uc2UgcmVxdWlyZW1lbnQsIGJ1dCB3YXMgdGhhdCB0aGUgZ29hbD8NCg0KDQpT
b21ldGhpbmcgcmVsYXRlZCBhdCB0aGUgc2VydmVyIHNpZGUgdGhhdCBtaWdodCBiZSBpbnRlcmVz
dGluZzoNCkEgYnVnIHRoYXQgd2UgY291bGQgaWRlbnRpZnkgaW4gQ2FsaWZvcm5pdW0gd2FzIHRo
YXQgdGhlIGNhY2hlIHRvIGFuc3dlciBkZXRlY3RlZCBkdXBsaWNhdGVzIG9ubHkgc3RvcmVkIHRo
ZSBlbXB0eSBBQ0sgZm9yIGFuIGluY29taW5nIG1lc3NhZ2UgSUQgd2hlbiBzZXBhcmF0ZSByZXNw
b25zZXMgd2VyZSB1c2VkLiBJIHdpbGwgaGF2ZSB0byBhZGQgYSBmaXggdGhhdCB1cGRhdGVzIHRo
ZSBjYWNoZWQgQUNLIHdpdGggdGhlIHNlcGFyYXRlIHJlc3BvbnNlLg0KDQpDaWFvDQpNYXR0aGlh
cw0KDQoiQW5nZWxvIFAuIENhc3RlbGxhbmkiIDxhbmdlbG9AY2FzdGVsbGFuaS5uZXQ+IHdyb3Rl
Og0KSSBwcm9wb3NlIGFuIGV4YW1wbGUgdG8gYmV0dGVyIGNsYXJpZnkgbXkgcG9pbnQ6DQogICAg
ICAgICAgIEMgICAgICAgICAgICAgICAgUw0KICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwN
CmlkPTB4MzggfCAgfCBHRVQgL2EgICAgICAgICB8IC98XA0KICAgICAgICB8ICB8IFRva2VuOiAi
YSIgICAgIHwgIHwgaWQ9MHgyMQ0KPT09PT09PVx8Lz18PT09PT09PT09PT09PT09PXw9PXw9PT09
PT09DQogICAgICAgICAgIHwgQ09OIE1JRD0weDEyMzQgfA0KICAgICAgICAgICB8LS0tLS0tLS0t
LS0tLS0tPnwNCiAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQppZD0weDM5IHwgIHwgR0VU
IC9iICAgICAgICAgfCAvfFwNCiAgICAgICAgfCAgfCBUb2tlbjogImIiICAgICB8ICB8IGlkPTB4
MjINCj09PT09PT1cfC89fD09PT09PT09PT09PT09PT18PT18PT09PT09PQ0KICAgICAgICAgICB8
IENPTiBNSUQ9MHgxMjM1IHwNCiAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLT58DQogICAgICAg
ICAgIHwgICAgICAgICAgICAgICAgfCByZXNwb25zZSBpcyBkZWxheWVkDQogICAgICAgICAgIHwg
ICAgICAgICAgICAgICAgfCBtZXNzYWdlIGxheWVyIHNlbmRzDQogICAgICAgICAgIHwgQUNLIE1J
RD0weDEyMzUgfCBhbiBlbXB0eSBhY2sNCiAgICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLS18DQog
ICAgICAgICAgIHwgICAgICAgICAgICAgICAgfA0KaWQ9MHg/IC98XCB8IDIuMDUgIkIiICAgICAg
IHwgIHwNCjM4IG9yIDM5fCAgfCBUb2tlbjogImIiICAgICB8ICB8IGlkPTB4MjINCj09PT09PT09
fD09fD09PT09PT09PT09PT09PT18PVx8Lz09PT09PT0NCiAgICAgICAgICAgfCBDT04gTUlEPTB4
ZmVmZSB8DQogICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0tfA0KDQpBc3N1bWUgdGhhdCB0aGUg
bWVzc2FnZS1sYXllciBoYXMgbm8ga25vd2xlZGdlIG9mIHRoZSBjb250ZW50IG9mIGVhY2ggbWVz
c2FnZSwgYnV0IGl0cyBrbm93bGVkZ2UgaXMgbGltaXRlZCB0byBhbiBpZGVudGlmaWVyIHVuaXZv
Y2FsbHkgaWRlbnRpZnlpbmcgZWFjaCBkaWZmZXJlbnQgY29udmVyc2F0aW9uIChwcmV2aW91c2x5
IGNhbGxlZCBzZXNzaW9uKS4NCg0KSG93IGRvZXMgdGhlIG1lc3NhZ2UtbGF5ZXIga25vdyB0byB3
aGljaCBpZGVudGlmaWVyIHNob3VsZCB0aGUgcmVzcG9uc2UgaW4gdGhlIGV4YW1wbGUgYmUgbWFw
cGVkIHRvPw0KDQpCZXN0LA0KQW5nZWxvDQoNCk9uIFR1ZSwgTWFyIDI3LCAyMDEyIGF0IDE0OjAy
LCBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZzxtYWlsdG86Y2Fib0B0emkub3JnPj4gd3Jv
dGU6DQpPbiBNYXIgMjcsIDIwMTIsIGF0IDE0OjAwLCBDYXJzdGVuIEJvcm1hbm4gd3JvdGU6DQoN
Cj4gQW4gQUNLLTAgKHRoZSBvbmUgeW91IGdldCBmb3IgYSByZXF1ZXN0IHRoYXQgY2F1c2VzIGEg
c2VwYXJhdGUgcmVzcG9uc2UsIGFzIHdlbGwgYXMgdGhlIG9uZSB0aGF0IGFza3MgdGhlIHNlcGFy
YXRlIHJlc3BvbnNlKSBkb2VzIG5vdCBoYXZlIGEgdG9rZW4uDQo+IEkgYmVsaWV2ZSB3ZSBzdGls
bCBoYXZlIGEgcHJvcGVyIHNlcGFyYXRpb24gYmV0d2VlbiB0aGUgcmV0cmFuc21pc3Npb24vZHVw
bGljYXRlIGRldGVjdGlvbiBtZWNoYW5pY3MgKGJhc2VkIG9uIE1JRCkgYW5kIHRoZSByZXF1ZXN0
L3Jlc3BvbnNlIGxheWVyLg0KPiBDYW4geW91IHBvaW50IG91dCB3aGVyZSB5b3UgbmVlZCB0aGUg
dG9rZW4gdG8gZG8gdGhlIG1hdGNoaW5nIGhlcmU/DQo+DQo+IEkgZG9uJ3Qga25vdyB3aGF0IGEg
InNlc3Npb24iIGlzLCBieSB0aGUgd2F5Lg0KPg0KPiBHcsO8w59lLCBDYXJzdGVuDQoNClNvcnJ5
LCB0aGlzIG9uZSB3YXMgYWJvdXQgQW5nZWxvJ3MgbGFzdCBtZXNzYWdlLg0KDQpHcsO8w59lLCBD
YXJzdGVuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4N
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQo=

From angelo.castellani@gmail.com  Wed Mar 28 01:22:44 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA08221F884E for ; Wed, 28 Mar 2012 01:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OUTAmaXjj+r for ; Wed, 28 Mar 2012 01:22:40 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 81E2B21F8760 for ; Wed, 28 Mar 2012 01:22:36 -0700 (PDT)
Received: by wibhj6 with SMTP id hj6so5030254wib.13 for ; Wed, 28 Mar 2012 01:22:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=ZbMFQv1vBF5tnE7Q4cqIh3VimDWLE/5jSiRNja6JoLQ=; b=hxuQ5bSZxSEIYEtIrSdF/AZhS3XF6qx3GnqmNfpSbFO7Bh8Vc2W7m/44lQfuQukRyc 5GmM/Re/vWQWQDaW8f1qVPAxlftRtsq75aNdvzagodhkXTIT9stYMa+ecQEKXOPLlk82 oqfll1s3ZNgP+n0b1LruKcWYBGzGad3/UstwNjzznNAlNr9Q12x/aSOb3eDvaGb+OIkk faRXP1C62rioK+JJHXotXy/nXfkSS0PiLsaSFyDcFaeOy3T2/M++fSgfwHi1zJfGbg30 YULmI4rpO+AdjOOnQCqOJNCJ9OvsXqGTl4DXddyrbsP1cgh1ea8VBpIaoDlDXNPHld1g pY/g==
Received: by 10.180.107.104 with SMTP id hb8mr4827759wib.8.1332922955602; Wed, 28 Mar 2012 01:22:35 -0700 (PDT)
MIME-Version: 1.0
Sender: angelo.castellani@gmail.com
Received: by 10.216.121.148 with HTTP; Wed, 28 Mar 2012 01:21:42 -0700 (PDT)
In-Reply-To: 
References: 
From: "Angelo P. Castellani" 
Date: Wed, 28 Mar 2012 10:21:42 +0200
X-Google-Sender-Auth: fig3jOX7dGmr7oiuDxxmLZd-J-A
Message-ID: 
To: Kovatsch Matthias 
Content-Type: multipart/alternative; boundary=e89a8f234ce5481d3704bc494fea
Cc: "core@ietf.org" 
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 28 Mar 2012 08:22:44 -0000

--e89a8f234ce5481d3704bc494fea
Content-Type: text/plain; charset=UTF-8

On Wed, Mar 28, 2012 at 09:51, Kovatsch Matthias wrote:

> I think the problem is that you cannot assign these IDs at the message
> layer. Your IDs clearly represent a request/response pair that is
> identified by end-point address + token (something I also previously called
> a session, as a blockwise transfer could happen below this abstraction).
>

Yes, I share your point of view. That was exactly my point (gained during
implementation as well) and the reason that led me to drawing the FSM based
on this concept of session/conversation, that integrates also Token
matching.


> In your chart, the message layer can only agnosticly deliver the massage
> upwards and some upper instance makes the token matching (I call it the
> token layer).

A problem is now, who should acknowledge the incoming CON, the message
> layer or the token layer? As it is unlikely that this received message gets
> lost internally, the message layer can ACK it.


If it has no state to match this, the message-layer must not ACK it...
Imagine to receive a response with Token: "c". Would you ACK it? You have
to RST it.

The upper-layer should instruct the message layer on ACKing or RSTing it,
because the message-layer has no state at all (thus neither a state machine
to handle it).

If this ACK gets lost on the channel and a retransmission arrives, there
> are multiple options:
> - The duplicate detection recognizes the message, ACKs it and does not
> deliver it upwards.
> - There is no dup detection and the message is passed upwards. Now, the
> token layer will not be able to make a match, as the token "b" was already
> closed. So it will send a RST, but this is no problem. The server knows it
> did fulfill the request, the client is just not interested anymore. This
> does not meet a transaction-like request/response requirement, but was that
> the goal?
>

Assuming that duplicate detection is in place, as should be the case
following the specification, the real problem here is about the overall
complexity of this "duplicate detection" system.

You have to keep at least (remote IPv4 or IPv6 (!!), remote UDP port, MID,
[Message to send again])... In regular implementations keeping this state
is not a problem, on sensor nodes (class-1 HW) this is a real burden.

Something related at the server side that might be interesting:
> A bug that we could identify in Californium was that the cache to answer
> detected duplicates only stored the empty ACK for an incoming message ID
> when separate responses were used. I will have to add a fix that updates
> the cached ACK with the separate response.
>

Interesting point. Take in mind that if the implementation on the end has
get the response, but still wants the empty ACK (does not implement the
related "implementation note") will not be satisfied by your response.

Best,
Angelo

--e89a8f234ce5481d3704bc494fea
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Wed, Mar 28, 2012 at 09:51, Kovatsch  Matthias &l=
t;kovatsch@inf.et=
hz.ch> wrote:



I think the problem is that you cannot assign these IDs at the message laye=
r. Your IDs clearly represent a request/response pair that is identified by=
 end-point address + token (something I also previously called a session, a=
s a blockwise transfer could happen below this abstraction).





Yes, I share your point of view. That was =
exactly my point (gained during implementation as well) and the reason that=
 led me to drawing the FSM based on this concept of session/conversation, t=
hat integrates also Token matching.




=C2=A0

In your chart, the message layer can only agnosticly deliver the massage up=
wards and some upper instance makes the token matching (I call it the token=
 layer).


A problem is now, who should acknowledge the incoming CON, the message laye=
r or the token layer? As it is unlikely that this received message gets los=
t internally, the message layer can ACK it.
=C2=A0


If it has no state to match this, the message-layer must not ACK=
 it... Imagine to receive a response with Token: "c". Would you A=
CK it? You have to RST it.

The upper-layer should =
instruct the message layer on ACKing or RSTing it, because the message-laye=
r has no state at all (thus neither a state machine to handle it).





If this ACK gets lost on the =
channel and a retransmission arrives, there are multiple options:

- The duplicate detection recognizes the message, ACKs it and does not deli=
ver it upwards.

- There is no dup detection and the message is passed upwards. Now, the tok=
en layer will not be able to make a match, as the token "b" was a=
lready closed. So it will send a RST, but this is no problem. The server kn=
ows it did fulfill the request, the client is just not interested anymore. =
This does not meet a transaction-like request/response requirement, but was=
 that the goal?





Assuming that duplicate detection is in pl=
ace, as should be the case following the specification, the real problem he=
re is about the overall complexity of this "duplicate detection" =
system.





You have to keep at least (remote IPv4 or IPv6 (!!), re=
mote UDP port, MID, [Message to send again])... In regular implementations =
keeping this state is not a problem, on sensor nodes (class-1 HW) this is a=
 real burden.





Something related at the serv=
er side that might be interesting:

A bug that we could identify in Californium was that the cache to answer de=
tected duplicates only stored the empty ACK for an incoming message ID when=
 separate responses were used. I will have to add a fix that updates the ca=
ched ACK with the separate response.





Interesting point. Take in mind that if th=
e implementation on the end has get the response, but still wants the empty=
 ACK (does not implement the related "implementation note") will =
not be satisfied by your response.





Best,
Angelo


--e89a8f234ce5481d3704bc494fea--

From angelo.castellani@gmail.com  Wed Mar 28 01:47:14 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FC921F878E for ; Wed, 28 Mar 2012 01:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFICDGbG7YEG for ; Wed, 28 Mar 2012 01:47:13 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2203821F8786 for ; Wed, 28 Mar 2012 01:47:12 -0700 (PDT)
Received: by wibhj6 with SMTP id hj6so5045917wib.13 for ; Wed, 28 Mar 2012 01:47:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=ijTjkD+JNqL9fo2+t+cCtZ7+RzOlJUrrZbHWKAoj0FM=; b=oWvml9BRNAnvezM44dyU5g13mA2Knlp54LxiLOq+8YKWb5WMsm2yDGWBnprg8x0bZX TNAjD0XAhWwOQPLKsgHf2hpdNsBDTEldpFjTPdKMsUJRaaej1nkGyM3IL9rowZ15F7BM EhrOKi+JY3fBdQeYpccMuqP9KzpuZ605eZQF63OuiZ+IcXFDiYLpqFdywZzIEii1y22F mJa59LpncGsM3kaV2pcmfE9fuijw82O1MQe5pJGg0CygqzJ69KXg0Zd7g0x+Zg3Lgb7a 255zAwDMQ+q/2Vxv2HfcGnHcHUXI764Jmn5dW1eSdGUsGnqyCx6w4GARjYbrOpJbQFvX N4Mg==
Received: by 10.180.73.143 with SMTP id l15mr4981445wiv.11.1332924432335; Wed, 28 Mar 2012 01:47:12 -0700 (PDT)
MIME-Version: 1.0
Sender: angelo.castellani@gmail.com
Received: by 10.216.121.148 with HTTP; Wed, 28 Mar 2012 01:46:32 -0700 (PDT)
From: "Angelo P. Castellani" 
Date: Wed, 28 Mar 2012 10:46:32 +0200
X-Google-Sender-Auth: CHPG-X67UViMwSq8CdsehoKQINU
Message-ID: 
To: core 
Content-Type: multipart/alternative; boundary=f46d043c06bc4d450504bc49a75f
Subject: [core] draft-ietf-core-coap-09: Mixed NON/CON separate responses
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 28 Mar 2012 08:47:14 -0000

--f46d043c06bc4d450504bc49a75f
Content-Type: text/plain; charset=UTF-8

Dear WG,

while re-reading the coap spec for WGLC, I noticed that a mixed NON/CON
message exchanges is permitted by the spec. E.g., see this text in Section
2.2:


   Likewise, if a request is sent in a Non-Confirmable message, then the
   response is usually sent using a new Non-Confirmable message,
   although the server may send a Confirmable message.  This type of
   exchange is illustrated in Figure 6.


In other words these exchanges seems to be permitted:

C     S   ||   C     S
| CON |   ||   | NON |
|---->|   ||   |---->|
| ACK |   ||   | CON |
|<----|   ||   |<----|
| NON |   ||   | ACK |
|<----|   ||   |---->|

>From a client perspective, supporting a server responding in this way may
introduce complexity.

Does someone has an implementation supporting this? Anyone has some
experience with this?

Best,
Angelo

p.s.: I think that I have to update my FSM drawing to include this option
too.

--f46d043c06bc4d450504bc49a75f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Dear WG,

while re-reading the coap spec for WGLC, I noti=
ced that a mixed NON/CON message exchanges is permitted by the spec. E.g., =
see this text in Section 2.2:


   Likewise, if a request is sent in a Non-Confirmable messa=
ge, then the
   response is usually sent using a new Non-Confirmable message,
   although the server may send a Confirmable message.  This type of
   exchange is illustrated in Figure 6.


In other words these exchanges seems to be permit=
ted:

C =
=C2=A0 =C2=A0 S =C2=A0 || =C2=A0 C =C2=A0 =C2=A0 S
| CON | =C2=A0 || =C2=A0 | NON |


|---->| =C2=A0 || =C2=A0 |---=
->|
| ACK | =C2=
=A0 || =C2=A0 | CON |
| NON | =C2=A0 || =C2=A0 | ACK |=

|<----| =C2=A0 |=
| =C2=A0 |---->|

From a client per=
spective, supporting a server responding in this way may introduce complexi=
ty.




Does someone has an implementation supporting this? Any=
one has some experience with this?

Best,
Angelo

p.s.:=C2=A0I think that I have to update m=
y FSM drawing to include this option too.



--f46d043c06bc4d450504bc49a75f--

From angelo.castellani@gmail.com  Wed Mar 28 02:01:14 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0940721F89AD for ; Wed, 28 Mar 2012 02:01:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9QccmxWJ4xN for ; Wed, 28 Mar 2012 02:01:13 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 333C221F8946 for ; Wed, 28 Mar 2012 02:01:13 -0700 (PDT)
Received: by werb10 with SMTP id b10so578770wer.31 for ; Wed, 28 Mar 2012 02:01:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=7TcaiFivTQ7qRKjRIgBDxWoZzJ6dLLqCmX+ud3WSgFM=; b=zzr41PR1bz/NvUPpZvpXDJTaUSgkcLFGVCkcIwLWlqpeeWGIHSXfNg5QYd3L4szPXU cto9QiD6GlDUt5kofBxZmK8iZc4ZaGl4i3V2+Xhf26D0qNAknRwcTeP3fDrFNAwMzaMK ytznTx5UuAE+haMnIm7Zy6Rizv7Zp1HapdNFxSKI7nLa46hB/skw+p/U5rGfftjGlBsW NbD3aWlVuLGaiZTChFvc7gzrk7WRTrJ0PK7Xg5bRu36W0GltfoUm/yVDiTQMkKuqNOyt pkHXP7aYug/mCz+9TBYYzFWPjW69QHkCX2nA9xIaFwsrmO6LgQ/tY+eGslLyJ8c8SkHU xBfQ==
Received: by 10.216.131.30 with SMTP id l30mr16435187wei.111.1332925272376; Wed, 28 Mar 2012 02:01:12 -0700 (PDT)
MIME-Version: 1.0
Sender: angelo.castellani@gmail.com
Received: by 10.216.121.148 with HTTP; Wed, 28 Mar 2012 02:00:32 -0700 (PDT)
From: "Angelo P. Castellani" 
Date: Wed, 28 Mar 2012 11:00:32 +0200
X-Google-Sender-Auth: gQhKkYY_UtSkR_3LP4Y21wecNKs
Message-ID: 
To: core 
Content-Type: multipart/alternative; boundary=0016e6d648345f46b104bc49d9d7
Subject: [core] draft-ietf-core-coap-09: retransmission window
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Mar 2012 09:01:14 -0000

--0016e6d648345f46b104bc49d9d7
Content-Type: text/plain; charset=UTF-8

Dear WG,

Section 4.1 tells:

   The same Message ID MUST NOT be re-used (per Message
   ID variable) within the potential retransmission window, calculated
   as RESPONSE_TIMEOUT * RESPONSE_RANDOM_FACTOR * (2 ^ MAX_RETRANSMIT -
   1) plus the expected maximum round trip time.


Question 1: Given that these parameters are not mandated by the standard,
does the spec assume that will be available some way to synchronize those
parameters across different implementations to correctly avoid reusing a
MID in the retransmission window?

Later on there is the following text:

   A recipient MUST be prepared to receive the same confirmable message

   (as indicated by the Message ID and additional address information of
   the corresponding end-point as described in Section 4.3
)
multiple
   times, for example, when its acknowledgement went missing or didn't
   reach the original sender before the first timeout.  The recipient


Question 2: Should be specified that "the recipient MUST be prepared to
receive the same confirmable message *within the potential retransmission
window*" as well?

Best,
Angelo

--0016e6d648345f46b104bc49d9d7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Dear WG,

Section 4.1 tells:

   The same Message ID MUST NOT be re-used (per Message
   ID variable) within the potential retransmission window, calculated
   as RESPONSE_TIMEOUT * RESPONSE_RANDOM_FACTOR * (2 ^ MAX_RETRANSMIT -
   1) plus the expected maximum round trip time.


Question 1: Given that these parameters are=
 not mandated by the standard, does the spec assume that will be available =
some way to synchronize those parameters across different implementations t=
o correctly avoid reusing a MID in the retransmission window?




Later on there is the following text:

   A recipient MUST be prep=
ared to receive the same confirmable message



   (as indicated by the Message ID and additional add=
ress information of
   the corresponding end-point as described in Section 4.3) multiple
   times, for example, when its acknowledgement went missing or didn't
   reach the original sender before the first timeout.  The recipient


Question 2: Should be specified that "=
the recipient MUST be prepared to receive the same confirmable message *wit=
hin the potential retransmission window*" as well?




Best,
Angelo


--0016e6d648345f46b104bc49d9d7--

From likepeng@huawei.com  Wed Mar 28 02:06:24 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F8521F89FB for ; Wed, 28 Mar 2012 02:06:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.605
X-Spam-Level: *
X-Spam-Status: No, score=1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpROCQFQnM7G for ; Wed, 28 Mar 2012 02:06:23 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B808621F89F9 for ; Wed, 28 Mar 2012 02:06:22 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AET40043; Wed, 28 Mar 2012 05:06:22 -0400 (EDT)
Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Mar 2012 02:04:36 -0700
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Mar 2012 02:04:33 -0700
Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.158]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 28 Mar 2012 17:04:24 +0800
From: Likepeng 
To: "Angelo P. Castellani" , core 
Thread-Topic: [core] draft-ietf-core-coap-09: Mixed NON/CON separate responses
Thread-Index: AQHNDL9zXEdC5PMbg0irvfQCv4Hie5Z/Z5gJ
Date: Wed, 28 Mar 2012 09:04:23 +0000
Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F20331D5DC@szxeml525-mbs.china.huawei.com>
References: 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.24.1.45]
Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F20331D5DCszxeml525mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [core] draft-ietf-core-coap-09: Mixed NON/CON separate responses
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 28 Mar 2012 09:06:25 -0000

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F20331D5DCszxeml525mbschi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

PkRvZXMgc29tZW9uZSBoYXMgYW4gaW1wbGVtZW50YXRpb24gc3VwcG9ydGluZyB0aGlzPyBBbnlv
bmUgaGFzIHNvbWUgZXhwZXJpZW5jZSB3aXRoIHRoaXM/DQoNCg0KDQpJbiBvdXIgaW1wbGVtZW50
YXRpb24sIHdlIHN1cHBvcnQgZmlyc3Qgb25lLCBub3QgdGhlIHNlY29uZCBvbmUuDQoNCg0KDQpU
aGUgZmlyc3QgZmxvdyBpcyBtYWlubHkgdXNlZCBpbiBvYnNlcnZlIHJlbGF0aW9uc2hpcCBlc3Rh
Ymxpc2htZW50LiBGaXJzdCBDT04gaXMgdG8gY3JlYXRlIG9ic2VydmUgcmVsYXRpb25zaGlwLCBz
ZWNvbmQgTk9OIGlzIHRvIHNlbmQgbm90aWZpY2F0aW9ucy4NCg0KDQoNCkkgYW0gbm90IHN1cmUg
d2hhdCBpcyB0aGUgdXNlIGNhc2UgZm9yIHRoZSBzZWNvbmQgZmxvdy4NCg0KDQoNCktlcGVuZw0K
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBjb3JlLWJvdW5jZXNA
aWV0Zi5vcmcgW2NvcmUtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBBbmdlbG8gUC4gQ2FzdGVsbGFu
aSBbYW5nZWxvQGNhc3RlbGxhbmkubmV0XQ0Kt6LLzcqxvOQ6IDIwMTLE6jPUwjI4yNUgMTY6NDYN
CrW9OiBjb3JlDQrW98ziOiBbY29yZV0gZHJhZnQtaWV0Zi1jb3JlLWNvYXAtMDk6IE1peGVkIE5P
Ti9DT04gc2VwYXJhdGUgcmVzcG9uc2VzDQoNCkRlYXIgV0csDQoNCndoaWxlIHJlLXJlYWRpbmcg
dGhlIGNvYXAgc3BlYyBmb3IgV0dMQywgSSBub3RpY2VkIHRoYXQgYSBtaXhlZCBOT04vQ09OIG1l
c3NhZ2UgZXhjaGFuZ2VzIGlzIHBlcm1pdHRlZCBieSB0aGUgc3BlYy4gRS5nLiwgc2VlIHRoaXMg
dGV4dCBpbiBTZWN0aW9uIDIuMjoNCg0KDQogICBMaWtld2lzZSwgaWYgYSByZXF1ZXN0IGlzIHNl
bnQgaW4gYSBOb24tQ29uZmlybWFibGUgbWVzc2FnZSwgdGhlbiB0aGUNCiAgIHJlc3BvbnNlIGlz
IHVzdWFsbHkgc2VudCB1c2luZyBhIG5ldyBOb24tQ29uZmlybWFibGUgbWVzc2FnZSwNCiAgIGFs
dGhvdWdoIHRoZSBzZXJ2ZXIgbWF5IHNlbmQgYSBDb25maXJtYWJsZSBtZXNzYWdlLiAgVGhpcyB0
eXBlIG9mDQogICBleGNoYW5nZSBpcyBpbGx1c3RyYXRlZCBpbiBGaWd1cmUgNi4NCg0KDQpJbiBv
dGhlciB3b3JkcyB0aGVzZSBleGNoYW5nZXMgc2VlbXMgdG8gYmUgcGVybWl0dGVkOg0KDQpDICAg
ICBTICAgfHwgICBDICAgICBTDQp8IENPTiB8ICAgfHwgICB8IE5PTiB8DQp8LS0tLT58ICAgfHwg
ICB8LS0tLT58DQp8IEFDSyB8ICAgfHwgICB8IENPTiB8DQp8PC0tLS18ICAgfHwgICB8PC0tLS18
DQp8IE5PTiB8ICAgfHwgICB8IEFDSyB8DQp8PC0tLS18ICAgfHwgICB8LS0tLT58DQoNCkZyb20g
YSBjbGllbnQgcGVyc3BlY3RpdmUsIHN1cHBvcnRpbmcgYSBzZXJ2ZXIgcmVzcG9uZGluZyBpbiB0
aGlzIHdheSBtYXkgaW50cm9kdWNlIGNvbXBsZXhpdHkuDQoNCkRvZXMgc29tZW9uZSBoYXMgYW4g
aW1wbGVtZW50YXRpb24gc3VwcG9ydGluZyB0aGlzPyBBbnlvbmUgaGFzIHNvbWUgZXhwZXJpZW5j
ZSB3aXRoIHRoaXM/DQoNCkJlc3QsDQpBbmdlbG8NCg0KcC5zLjogSSB0aGluayB0aGF0IEkgaGF2
ZSB0byB1cGRhdGUgbXkgRlNNIGRyYXdpbmcgdG8gaW5jbHVkZSB0aGlzIG9wdGlvbiB0b28uDQo=

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F20331D5DCszxeml525mbschi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable










>Does someone has an implementation supporting this? Anyone has som=
e experience with this?


 


In our implementation, we support first one, not the second one.


 


The first flow is mainly used in observe relationship establishment. Fir=
st CON is to create observe relationship, second NON is to send notificatio=
ns.


 


I am not sure what is the use case for the second flow.


 


Kepeng




=B7=A2=BC=FE=C8=CB: core-bounces@ietf.org [=
core-bounces@ietf.org] =B4=FA=B1=ED Angelo P. Castellani [angelo@castellani=
.net]

=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C228=C8=D5 16:46

=B5=BD: core

=D6=F7=CC=E2: [core] draft-ietf-core-coap-09: Mixed NON/CON separate=
 responses








Dear WG,






while re-reading the coap spec for WGLC, I noticed that a mixed NON/CO=
N message exchanges is permitted by the spec. E.g., see this text in Sectio=
n 2.2:





   Likewise, if a request is sent in a Non-Confirmable message, t=
hen the
   response is usually sent using a new Non-Confirmable message,
   although the server may send a Confirmable message.  This type of
   exchange is illustrated in Figure 6.








In other words these exchanges seems to be permitted:









C     S   || &nbs=
p; C     S


| CON |   ||   | NON |=



|---->|   ||   |---=
->|


| ACK |   ||   | CON |=



|<----|   ||   |<=
;----|


| NON |   ||   | ACK |=



|<----|   ||   |---=
->|









From a client perspective, supporting a server responding in this way =
may introduce complexity.







Does someone has an implementation supporting this? Anyone has some ex=
perience with this?







Best,


Angelo







p.s.: I think that I have to update my FSM drawing to include thi=
s option too.










--_000_34966E97BE8AD64EAE9D3D6E4DEE36F20331D5DCszxeml525mbschi_--

From likepeng@huawei.com  Wed Mar 28 02:16:03 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0997221E8097 for ; Wed, 28 Mar 2012 02:16:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.605
X-Spam-Level: *
X-Spam-Status: No, score=1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sUDK4VsiYlR for ; Wed, 28 Mar 2012 02:16:02 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE0C21E804A for ; Wed, 28 Mar 2012 02:16:00 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEL37617; Wed, 28 Mar 2012 05:15:59 -0400 (EDT)
Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Mar 2012 02:13:55 -0700
Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Mar 2012 02:13:51 -0700
Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.158]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Wed, 28 Mar 2012 17:11:45 +0800
From: Likepeng 
To: "Angelo P. Castellani" , core 
Thread-Topic: [core] draft-ietf-core-coap-09: retransmission window
Thread-Index: AQHNDMFigMNDKW436Emn9hFpJZIoeJZ/aqmx
Date: Wed, 28 Mar 2012 09:11:44 +0000
Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F20331D61B@szxeml525-mbs.china.huawei.com>
References: 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.24.1.45]
Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F20331D61Bszxeml525mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [core] draft-ietf-core-coap-09: retransmission window
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Mar 2012 09:16:03 -0000

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F20331D61Bszxeml525mbschi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

PiBRdWVzdGlvbiAxOiBHaXZlbiB0aGF0IHRoZXNlIHBhcmFtZXRlcnMgYXJlIG5vdCBtYW5kYXRl
ZCBieSB0aGUgc3RhbmRhcmQsIGRvZXMgdGhlIHNwZWMgYXNzdW1lIHRoYXQgd2lsbCBiZSBhdmFp
bGFibGUgc29tZSB3YXkgdG8gc3luY2hyb25pemUgdGhvc2UgcGFyYW1ldGVycyBhY3Jvc3MgZGlm
ZmVyZW50IGltcGxlbWVudGF0aW9ucyB0byBjb3JyZWN0bHkgYXZvaWQgcmV1c2luZyBhIE1JRCBp
biB0aGUgcmV0cmFuc21pc3Npb24gd2luZG93Pw0KDQoNCg0KSW4gb3VyIGltcGxlbWVudGF0aW9u
LCB3ZSBjaG9vc2UgYXJiaXRyYXJ5L3JhbmRvbSBNSURzLiBJIHRoaW5rIGl0IHdpbGwgYmUgZWFz
eSBmb3IgdGhlIGNsaWVudCB0byBjaG9vc2UgZGlmZmVyZW50IE1JRHMgaW4gdGhlIHJldHJhbnNt
aXNzaW9uIHdpbmRvdy4NCg0KDQoNCj4gUXVlc3Rpb24gMjogU2hvdWxkIGJlIHNwZWNpZmllZCB0
aGF0ICJ0aGUgcmVjaXBpZW50IE1VU1QgYmUgcHJlcGFyZWQgdG8gcmVjZWl2ZSB0aGUgc2FtZSBj
b25maXJtYWJsZSBtZXNzYWdlICp3aXRoaW4gdGhlIHBvdGVudGlhbCByZXRyYW5zbWlzc2lvbiB3
aW5kb3cqIiBhcyB3ZWxsPw0KDQpUaGF0IHdpbGwgYmUgaGVscGZ1bC4NCg0KDQpLZXBlbmcNCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogY29yZS1ib3VuY2VzQGll
dGYub3JnIFtjb3JlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gQW5nZWxvIFAuIENhc3RlbGxhbmkg
W2FuZ2Vsb0BjYXN0ZWxsYW5pLm5ldF0NCreiy83KsbzkOiAyMDEyxOoz1MIyOMjVIDE3OjAwDQq1
vTogY29yZQ0K1vfM4jogW2NvcmVdIGRyYWZ0LWlldGYtY29yZS1jb2FwLTA5OiByZXRyYW5zbWlz
c2lvbiB3aW5kb3cNCg0KRGVhciBXRywNCg0KU2VjdGlvbiA0LjEgdGVsbHM6DQoNCg0KICAgVGhl
IHNhbWUgTWVzc2FnZSBJRCBNVVNUIE5PVCBiZSByZS11c2VkIChwZXIgTWVzc2FnZQ0KICAgSUQg
dmFyaWFibGUpIHdpdGhpbiB0aGUgcG90ZW50aWFsIHJldHJhbnNtaXNzaW9uIHdpbmRvdywgY2Fs
Y3VsYXRlZA0KICAgYXMgUkVTUE9OU0VfVElNRU9VVCAqIFJFU1BPTlNFX1JBTkRPTV9GQUNUT1Ig
KiAoMiBeIE1BWF9SRVRSQU5TTUlUIC0NCiAgIDEpIHBsdXMgdGhlIGV4cGVjdGVkIG1heGltdW0g
cm91bmQgdHJpcCB0aW1lLg0KDQoNClF1ZXN0aW9uIDE6IEdpdmVuIHRoYXQgdGhlc2UgcGFyYW1l
dGVycyBhcmUgbm90IG1hbmRhdGVkIGJ5IHRoZSBzdGFuZGFyZCwgZG9lcyB0aGUgc3BlYyBhc3N1
bWUgdGhhdCB3aWxsIGJlIGF2YWlsYWJsZSBzb21lIHdheSB0byBzeW5jaHJvbml6ZSB0aG9zZSBw
YXJhbWV0ZXJzIGFjcm9zcyBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb25zIHRvIGNvcnJlY3RseSBh
dm9pZCByZXVzaW5nIGEgTUlEIGluIHRoZSByZXRyYW5zbWlzc2lvbiB3aW5kb3c/DQoNCkxhdGVy
IG9uIHRoZXJlIGlzIHRoZSBmb2xsb3dpbmcgdGV4dDoNCg0KDQogICBBIHJlY2lwaWVudCBNVVNU
IGJlIHByZXBhcmVkIHRvIHJlY2VpdmUgdGhlIHNhbWUgY29uZmlybWFibGUgbWVzc2FnZQ0KDQog
ICAoYXMgaW5kaWNhdGVkIGJ5IHRoZSBNZXNzYWdlIElEIGFuZCBhZGRpdGlvbmFsIGFkZHJlc3Mg
aW5mb3JtYXRpb24gb2YNCiAgIHRoZSBjb3JyZXNwb25kaW5nIGVuZC1wb2ludCBhcyBkZXNjcmli
ZWQgaW4gU2VjdGlvbiA0LjM8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1j
b3JlLWNvYXAtMDkjc2VjdGlvbi00LjM+KSBtdWx0aXBsZQ0KICAgdGltZXMsIGZvciBleGFtcGxl
LCB3aGVuIGl0cyBhY2tub3dsZWRnZW1lbnQgd2VudCBtaXNzaW5nIG9yIGRpZG4ndA0KICAgcmVh
Y2ggdGhlIG9yaWdpbmFsIHNlbmRlciBiZWZvcmUgdGhlIGZpcnN0IHRpbWVvdXQuICBUaGUgcmVj
aXBpZW50DQoNCg0KUXVlc3Rpb24gMjogU2hvdWxkIGJlIHNwZWNpZmllZCB0aGF0ICJ0aGUgcmVj
aXBpZW50IE1VU1QgYmUgcHJlcGFyZWQgdG8gcmVjZWl2ZSB0aGUgc2FtZSBjb25maXJtYWJsZSBt
ZXNzYWdlICp3aXRoaW4gdGhlIHBvdGVudGlhbCByZXRyYW5zbWlzc2lvbiB3aW5kb3cqIiBhcyB3
ZWxsPw0KDQpCZXN0LA0KQW5nZWxvDQo=

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F20331D61Bszxeml525mbschi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable










> Question 1: Given that these parameters are not mandated by the s=
tandard, does the spec assume that will be available some way to synchroniz=
e those parameters across different implementations to correctly avoid reus=
ing a MID in the retransmission window?


 


In our implementation, we choose arbitrary/random MIDs. I think it will =
be easy for the client to choose different MIDs in the retransmission windo=
w.


 


> Question 2: Should be specified that "the recipient MUST be =
prepared to receive the same confirmable message *within the potential retr=
ansmission window*" as well?


 


That will be helpful. 


 


Kepeng




=B7=A2=BC=FE=C8=CB: core-bounces@ietf.org =
[core-bounces@ietf.org] =B4=FA=B1=ED Angelo P. Castellani [angelo@castellan=
i.net]

=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C228=C8=D5 17:00

=B5=BD: core

=D6=F7=CC=E2: [core] draft-ietf-core-coap-09: retransmission window<=
br>







Dear WG,






Section 4.1 tells:









   The same Message ID MUST NOT be re-used (per Message
   ID variable) within the potential retransmission window, calculated
   as RESPONSE_TIMEOUT * RESPONSE_RANDOM_FACTOR * (2 ^ MAX_RETRANSMIT -
   1) plus the expected maximum round trip time.










Question 1: Given that these parameters are not mandated by the standa=
rd, does the spec assume that will be available some way to synchronize tho=
se parameters across different implementations to correctly avoid reusing a=
 MID in the retransmission window?







Later on there is the following text:











   A recipient MUST be prepared to=
 receive the same confirmable message








   (as indicated by the Message ID and additional address informa=
tion of
   the corresponding end-point as described in Section 4.=
3) multiple
   times, for example, when its acknowledgement went missing or didn't
   reach the original sender before the first timeout.  The recipient










Question 2: Should be specified that "the recipient MUST be prepa=
red to receive the same confirmable message *within the potential retransmi=
ssion window*" as well?







Best,


Angelo










--_000_34966E97BE8AD64EAE9D3D6E4DEE36F20331D61Bszxeml525mbschi_--

From angelo.castellani@gmail.com  Wed Mar 28 02:22:48 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F300D21F88B6 for ; Wed, 28 Mar 2012 02:22:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMfcTQoKArOb for ; Wed, 28 Mar 2012 02:22:47 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id CA4AB21F88A9 for ; Wed, 28 Mar 2012 02:22:46 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so518566wgb.13 for ; Wed, 28 Mar 2012 02:22:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Ng153z7K2zYexHk7qBSGfLqLjRpve0D7c7MnERBvfYk=; b=VqUew5yRxsfoDMByZYpm8RhIFJwzNGfzltYUZkEiK4Z+XMiACSe6jF+jzgfnIooGAr B7e3eH8Hex+nPzvIfTWwNLKXz7bgEAoPGY43ZwUHsQXxKLR4zuAf/sIBqs7s4ZQI2q7h or57pjMg/qmGsLg0w95HjsUQfW2OazLICWWj0kz48BK7mOZqCyzpnxMaDbd7B1y2nQYs BhkUjZCox+UlXpvj7ICOpdBOtltY4TOQ9CIV5cmxjRYnlroOjNLSRlzDig3L63b1UgtO 6aDK8enTmE055MFmEkbrMUKt7ph9Sa95b1xGmlm9nyjB2NgHg8WZ9vWZOgaXL6Z1erBw IgLg==
Received: by 10.180.107.104 with SMTP id hb8mr5276080wib.8.1332926565658; Wed, 28 Mar 2012 02:22:45 -0700 (PDT)
MIME-Version: 1.0
Sender: angelo.castellani@gmail.com
Received: by 10.216.121.148 with HTTP; Wed, 28 Mar 2012 02:22:05 -0700 (PDT)
In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F20331D5DC@szxeml525-mbs.china.huawei.com>
References:  <34966E97BE8AD64EAE9D3D6E4DEE36F20331D5DC@szxeml525-mbs.china.huawei.com>
From: "Angelo P. Castellani" 
Date: Wed, 28 Mar 2012 11:22:05 +0200
X-Google-Sender-Auth: 73_5QgHFj2F8gZ4hMuk1WMCXT5k
Message-ID: 
To: Likepeng 
Content-Type: multipart/alternative; boundary=e89a8f234ce57531a104bc4a2653
Cc: core 
Subject: Re: [core] draft-ietf-core-coap-09: Mixed NON/CON separate responses
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 28 Mar 2012 09:22:48 -0000

--e89a8f234ce57531a104bc4a2653
Content-Type: text/plain; charset=UTF-8

Right, supporting observe requires you to support this exchange.

Does that work even if the first ACK is empty? Said in another way, do you
support establishing an Observe relationship even when that is done using a
separate response arriving in a NON message?

Do you support it even if that happens during a regular request/response
exchange (no Observe)?

There is nothing wrong with this. I am dubious that this changes the FSM,
so I was wondering if you support this, if it has required specific support
for this case, and your overall experience in implementing it (from a
complexity point-of-view).

Best,
Angelo

On Wed, Mar 28, 2012 at 11:04, Likepeng  wrote:

> The first flow is mainly used in observe relationship establishment. First
> CON is to create observe relationship, second NON is to send notifications.
>
>

--e89a8f234ce57531a104bc4a2653
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Right, supporting observe requires you to support this exchange.=C2=A0=


Does that work even if the first ACK is empty?=C2=A0Said in =
another way, do you support establishing an Observe relationship even when =
that is done using a separate response arriving in a NON message?





Do you support it even if that happens during a regular=
 request/response exchange (no Observe)?

There is =
nothing wrong with this. I am dubious that this changes the FSM, so I was w=
ondering if you support this, if it has required specific support for this =
case, and your overall experience in implementing it (from a complexity poi=
nt-of-view).





Best,
Angelo

On Wed, Mar 28, 2012 at 11:04, Likepeng <likepeng@huawei.com&g=
t; wrote:





The first flow is mainly used in observe relationship establishment. Fir=
st CON is to create observe relationship, second NON is to send notificatio=
ns.





--e89a8f234ce57531a104bc4a2653--

From mab@comnets.uni-bremen.de  Wed Mar 28 02:22:48 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AAD721F88B0 for ; Wed, 28 Mar 2012 02:22:48 -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 YyPDqK-zRfbM for ; Wed, 28 Mar 2012 02:22:47 -0700 (PDT)
Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [134.102.186.10]) by ietfa.amsl.com (Postfix) with ESMTP id AFBFD21F88B5 for ; Wed, 28 Mar 2012 02:22:47 -0700 (PDT)
Received: from shelbyville.comnets.uni-bremen.de (unknown [10.8.0.62]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTPS id 08681D4079E; Wed, 28 Mar 2012 11:22:47 +0200 (CEST)
From: Markus Becker 
Organization: Comnets, University Bremen
To: core@ietf.org
Date: Wed, 28 Mar 2012 11:22:45 +0200
User-Agent: KMail/1.13.7 (Linux/3.2.0-1-686-pae; KDE/4.7.4; i686; ; )
References: 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201203281122.46080.mab@comnets.uni-bremen.de>
Subject: Re: [core] draft-ietf-core-coap-09: retransmission window
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Mar 2012 09:22:48 -0000

> Dear WG,
> 
> Section 4.1 tells:
> 
>    The same Message ID MUST NOT be re-used (per Message
>    ID variable) within the potential retransmission window, calculated
>    as RESPONSE_TIMEOUT * RESPONSE_RANDOM_FACTOR * (2 ^ MAX_RETRANSMIT -
>    1) plus the expected maximum round trip time.
> 
> 
> Question 1: Given that these parameters are not mandated by the standard,
> does the spec assume that will be available some way to synchronize those
> parameters across different implementations to correctly avoid reusing a
> MID in the retransmission window?

I was wondering about this as well, since clients and server cannot be assumed 
to be under the same ownership. SHOULD or MUST those settings (if not using 
the default setting) be exhibited under some profile like IPSO's? In the 
discovery phase than a conservative (large) setting for RESPONSE_TIMEOUT 
should be assumed?

Markus

From likepeng@huawei.com  Wed Mar 28 03:11:40 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 084FF21F89CA for ; Wed, 28 Mar 2012 03:11:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.605
X-Spam-Level: *
X-Spam-Status: No, score=1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1P1CQx-btdUs for ; Wed, 28 Mar 2012 03:11:37 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6743921F8A10 for ; Wed, 28 Mar 2012 03:11:37 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AET43521; Wed, 28 Mar 2012 06:11:37 -0400 (EDT)
Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Mar 2012 03:08:44 -0700
Received: from SZXEML435-HUB.china.huawei.com (10.72.61.63) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Mar 2012 03:08:40 -0700
Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.158]) by szxeml435-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 28 Mar 2012 18:08:35 +0800
From: Likepeng 
To: "Angelo P. Castellani" 
Thread-Topic: [core] draft-ietf-core-coap-09: Mixed NON/CON separate responses
Thread-Index: AQHNDL9zXEdC5PMbg0irvfQCv4Hie5Z/Z5gJ//+BSICAAJD1SQ==
Date: Wed, 28 Mar 2012 10:08:34 +0000
Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F20331D6AA@szxeml525-mbs.china.huawei.com>
References:  <34966E97BE8AD64EAE9D3D6E4DEE36F20331D5DC@szxeml525-mbs.china.huawei.com>, 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.24.1.45]
Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F20331D6AAszxeml525mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: core 
Subject: Re: [core] draft-ietf-core-coap-09: Mixed NON/CON separate responses
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 28 Mar 2012 10:11:40 -0000

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F20331D6AAszxeml525mbschi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

PiBEb2VzIHRoYXQgd29yayBldmVuIGlmIHRoZSBmaXJzdCBBQ0sgaXMgZW1wdHk/IFNhaWQgaW4g
YW5vdGhlciB3YXksIGRvIHlvdSBzdXBwb3J0IGVzdGFibGlzaGluZyBhbiBPYnNlcnZlIHJlbGF0
aW9uc2hpcCBldmVuIHdoZW4gdGhhdCBpcyBkb25lIHVzaW5nIGEgc2VwYXJhdGUgcmVzcG9uc2Ug
YXJyaXZpbmcgaW4gYSBOT04gbWVzc2FnZT8NCg0KTm8sIGlmIHRoZXJlIGlzIG5vIEFDSywgdGhl
IG9ic2VydmUgZXN0YWJsaXNobWVudCBpcyBub3Qgc3VjY2Vzc2Z1bCwgYW5kIGNsaWVudCBjYW4n
dCB1bmRlcnN0YW5kIHRoZSBuZXh0IE5PTiBtZXNzYWdlLg0KDQo+IERvIHlvdSBzdXBwb3J0IGl0
IGV2ZW4gaWYgdGhhdCBoYXBwZW5zIGR1cmluZyBhIHJlZ3VsYXIgcmVxdWVzdC9yZXNwb25zZSBl
eGNoYW5nZSAobm8gT2JzZXJ2ZSk/DQoNCg0KDQpOby4gV2hlbiBjbGllbnQgc2VuZHMgYSBDT04s
IGl0IGV4cGVjdHMgYW4gQUNLIG9yIHBpZ2d5LWJhY2tlZCByZXNwb25zZSwgb3IgYSBSU1QuIElm
IG5vLCBjbGllbnQgd2lsbCByZXRyYW5zbWl0LCBhbmQgYWZ0ZXIgcmV0cmFuc21pc3Npb24sIGdp
dmUgdXAuDQoNCg0KDQpLZXBlbmcNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
CreivP7IyzogYW5nZWxvLmNhc3RlbGxhbmlAZ21haWwuY29tIFthbmdlbG8uY2FzdGVsbGFuaUBn
bWFpbC5jb21dILT6se0gQW5nZWxvIFAuIENhc3RlbGxhbmkgW2FuZ2Vsb0BjYXN0ZWxsYW5pLm5l
dF0NCreiy83KsbzkOiAyMDEyxOoz1MIyOMjVIDE3OjIyDQq1vTogTGlrZXBlbmcNCkNjOiBjb3Jl
DQrW98ziOiBSZTogW2NvcmVdIGRyYWZ0LWlldGYtY29yZS1jb2FwLTA5OiBNaXhlZCBOT04vQ09O
IHNlcGFyYXRlIHJlc3BvbnNlcw0KDQpSaWdodCwgc3VwcG9ydGluZyBvYnNlcnZlIHJlcXVpcmVz
IHlvdSB0byBzdXBwb3J0IHRoaXMgZXhjaGFuZ2UuDQoNCkRvZXMgdGhhdCB3b3JrIGV2ZW4gaWYg
dGhlIGZpcnN0IEFDSyBpcyBlbXB0eT8gU2FpZCBpbiBhbm90aGVyIHdheSwgZG8geW91IHN1cHBv
cnQgZXN0YWJsaXNoaW5nIGFuIE9ic2VydmUgcmVsYXRpb25zaGlwIGV2ZW4gd2hlbiB0aGF0IGlz
IGRvbmUgdXNpbmcgYSBzZXBhcmF0ZSByZXNwb25zZSBhcnJpdmluZyBpbiBhIE5PTiBtZXNzYWdl
Pw0KDQpEbyB5b3Ugc3VwcG9ydCBpdCBldmVuIGlmIHRoYXQgaGFwcGVucyBkdXJpbmcgYSByZWd1
bGFyIHJlcXVlc3QvcmVzcG9uc2UgZXhjaGFuZ2UgKG5vIE9ic2VydmUpPw0KDQpUaGVyZSBpcyBu
b3RoaW5nIHdyb25nIHdpdGggdGhpcy4gSSBhbSBkdWJpb3VzIHRoYXQgdGhpcyBjaGFuZ2VzIHRo
ZSBGU00sIHNvIEkgd2FzIHdvbmRlcmluZyBpZiB5b3Ugc3VwcG9ydCB0aGlzLCBpZiBpdCBoYXMg
cmVxdWlyZWQgc3BlY2lmaWMgc3VwcG9ydCBmb3IgdGhpcyBjYXNlLCBhbmQgeW91ciBvdmVyYWxs
IGV4cGVyaWVuY2UgaW4gaW1wbGVtZW50aW5nIGl0IChmcm9tIGEgY29tcGxleGl0eSBwb2ludC1v
Zi12aWV3KS4NCg0KQmVzdCwNCkFuZ2Vsbw0KDQpPbiBXZWQsIE1hciAyOCwgMjAxMiBhdCAxMTow
NCwgTGlrZXBlbmcgPGxpa2VwZW5nQGh1YXdlaS5jb208bWFpbHRvOmxpa2VwZW5nQGh1YXdlaS5j
b20+PiB3cm90ZToNCg0KVGhlIGZpcnN0IGZsb3cgaXMgbWFpbmx5IHVzZWQgaW4gb2JzZXJ2ZSBy
ZWxhdGlvbnNoaXAgZXN0YWJsaXNobWVudC4gRmlyc3QgQ09OIGlzIHRvIGNyZWF0ZSBvYnNlcnZl
IHJlbGF0aW9uc2hpcCwgc2Vjb25kIE5PTiBpcyB0byBzZW5kIG5vdGlmaWNhdGlvbnMuDQoNCg==

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F20331D6AAszxeml525mbschi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable










> Does that work even if the first ACK is empty? Said in anoth=
er way, do you support establishing an Observe relationship even when that =
is done using a separate response arriving in a NON message?


 


No, if there is no ACK, the observe establishment is not successful, a=
nd client can't understand the next NON message.


 


> Do you support it even if that happens during a regular request/r=
esponse exchange (no Observe)?


 


No. When client sends a CON, it expects an ACK or piggy-backed=
 response, or a RST. If no, client will retransmit, and after retransmissio=
n, give up.


 


Kepeng




=B7=A2=BC=FE=C8=CB: angelo.castellani@gmai=
l.com [angelo.castellani@gmail.com] =B4=FA=B1=ED Angelo P. Castellani [ange=
lo@castellani.net]

=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C228=C8=D5 17:22

=B5=BD: Likepeng

Cc: core

=D6=F7=CC=E2: Re: [core] draft-ietf-core-coap-09: Mixed NON/CON sepa=
rate responses










Right, supporting observe requires you to support this exchange. =





Does that work even if the first ACK is empty? Said in another wa=
y, do you support establishing an Observe relationship even when that is do=
ne using a separate response arriving in a NON message?







Do you support it even if that happens during a regular request/respon=
se exchange (no Observe)?







There is nothing wrong with this. I am dubious that this changes the F=
SM, so I was wondering if you support this, if it has required specific sup=
port for this case, and your overall experience in implementing it (from a =
complexity point-of-view).







Best,


Angelo




On Wed, Mar 28, 2012 at 11:04, Likepeng 
<likepeng@huawe=
i.com> wrote:




The first flow is mainly used in observe relationship establishment. Fir=
st CON is to create observe relationship, second NON is to send notificatio=
ns.


















--_000_34966E97BE8AD64EAE9D3D6E4DEE36F20331D6AAszxeml525mbschi_--

From cabo@tzi.org  Wed Mar 28 03:30:10 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B8521F8744 for ; Wed, 28 Mar 2012 03:30:10 -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 j2slaD-TEJGx for ; Wed, 28 Mar 2012 03:30:09 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 78FDD21F8733 for ; Wed, 28 Mar 2012 03:30:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2SAU0rA014444 for ; Wed, 28 Mar 2012 12:30:00 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7C79CD03; Wed, 28 Mar 2012 12:30:00 +0200 (CEST)
From: Carsten Bormann 
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Wed, 28 Mar 2012 12:29:59 +0200
To: "core@ietf.org WG" 
Message-Id: 
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
Subject: [core] CoRE Roadmap
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 28 Mar 2012 10:30:10 -0000

As a WG chair, I get to read all of your drafts.

Thank you.

But with the number of drafts out there, it becomes too hard for most WG =
members to know what's out there already.
Rampant reinvention is one of the smaller curses resulting from this.
The more general public not understanding what's going on is even more =
important.

I have written a very rough draft of a Roadmap document for the CoRE WG.

Find it at:

	http://tools.ietf.org/html/draft-bormann-core-roadmap

I trust I will hear from those of you whose drafts I have somehow missed =
or misrepresented.
If you have little (!) snippets of text do add, I would appreciate =
those, too.
(And, if you write a new draft or update an existing one, you might =
consider where it fits here.)

I would hope that this becomes a useful resource over the life of the =
WG.
I plan to update it often (the diff tool will help with reading the =
updates).
Please help me to keep it (and make it more) useful.

Use it!

Gr=FC=DFe, Carsten


From trac+core@trac.tools.ietf.org  Wed Mar 28 03:34:32 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB4A21F891C for ; Wed, 28 Mar 2012 03:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.588
X-Spam-Level: 
X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 BQCx5fQf0Ryv for ; Wed, 28 Mar 2012 03:34:32 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 154E121F88B5 for ; Wed, 28 Mar 2012 03:34:31 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SCqCg-0006go-17; Wed, 28 Mar 2012 06:34:10 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org
X-Trac-Project: core
Date: Wed, 28 Mar 2012 10:34:09 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/201
Message-ID: <051.b90ea2a4caf57d34ab6abdaf3603301a@trac.tools.ietf.org>
X-Trac-Ticket-ID: 201
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: 
Resent-Message-Id: <20120328103432.154E121F88B5@ietfa.amsl.com>
Resent-Date: Wed, 28 Mar 2012 03:34:31 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: [core] #201: Clarify use of retransmission window for duplicate detection
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Mar 2012 10:34:32 -0000

#201: Clarify use of retransmission window for duplicate detection

 A recipient MUST be prepared to receive the same confirmable message
    (as indicated by the Message ID and additional address information of
    the corresponding end-point as described in Section 4.3) multiple
    times, for example, when its acknowledgement went missing or didn't
    reach the original sender before the first timeout.  The recipient

 Question 2: Should be specified that "the recipient MUST be prepared to
 receive the same confirmable message *within the potential retransmission
 window*" as well?

-- 
-----------------------------+------------------------------------
 Reporter:  cabo@…           |      Owner:  draft-ietf-core-coap@…
     Type:  editorial        |     Status:  new
 Priority:  minor            |  Milestone:
Component:  coap             |    Version:
 Severity:  In WG Last Call  |   Keywords:
-----------------------------+------------------------------------

Ticket URL: 
core 


From cabo@tzi.org  Wed Mar 28 03:36:52 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEBA21F8961 for ; Wed, 28 Mar 2012 03:36:52 -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 fGj9a0Nbv1WD for ; Wed, 28 Mar 2012 03:36: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 15F9421F8941 for ; Wed, 28 Mar 2012 03:36: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.3/8.14.3) with ESMTP id q2SAahL2018061; Wed, 28 Mar 2012 12:36:43 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8717DD10; Wed, 28 Mar 2012 12:36:43 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Wed, 28 Mar 2012 12:36:43 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: "Angelo P. Castellani" 
X-Mailer: Apple Mail (2.1257)
Cc: core 
Subject: Re: [core] draft-ietf-core-coap-09: retransmission window
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Mar 2012 10:36:53 -0000

On Mar 28, 2012, at 11:00, Angelo P. Castellani wrote:

> Dear WG,
>=20
> Section 4.1 tells:
>=20
>    The same Message ID MUST NOT be re-used (per Message
>    ID variable) within the potential retransmission window, calculated
>    as RESPONSE_TIMEOUT * RESPONSE_RANDOM_FACTOR * (2 ^ MAX_RETRANSMIT =
-
>    1) plus the expected maximum round trip time.
>=20
>=20
> Question 1: Given that these parameters are not mandated by the =
standard, does the spec assume that will be available some way to =
synchronize those parameters across different implementations to =
correctly avoid reusing a MID in the retransmission window?

We say this is out of scope in section 9.

	The values for RESPONSE_TIMEOUT, RESPONSE_RANDOM_FACTOR, and =
MAX_RETRANSMIT may be configured to values specific to the application =
environment, however the configuration method is out of scope of this =
document. It is recommended that an application environment use =
consistent values for these parameters.=20

I expect we will come up with a way to do this in the area of discovery =
and auto configuration.
Maybe we should add text about a default "potential retransmission =
window", e.g. 256 s.

> Later on there is the following text:
>=20
>    A recipient MUST be prepared to receive the same confirmable =
message
>    (as indicated by the Message ID and additional address information =
of
>    the corresponding end-point as described in=20
> Section 4.3
> ) multiple
>    times, for example, when its acknowledgement went missing or didn't
>    reach the original sender before the first timeout.  The recipient
>=20
>=20
> Question 2: Should be specified that "the recipient MUST be prepared =
to receive the same confirmable message *within the potential =
retransmission window*" as well?

Now ticket #201.

Gr=FC=DFe, Carsten


From cabo@tzi.org  Wed Mar 28 03:42:49 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8667221F894F for ; Wed, 28 Mar 2012 03:42:49 -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 256kMoDNBUSg for ; Wed, 28 Mar 2012 03:42:47 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4B87721F88D0 for ; Wed, 28 Mar 2012 03:42:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2SAgdOL020918; Wed, 28 Mar 2012 12:42:39 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DB88AD16; Wed, 28 Mar 2012 12:42:38 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Wed, 28 Mar 2012 12:42:38 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  
To: "Angelo P. Castellani" 
X-Mailer: Apple Mail (2.1257)
Cc: core 
Subject: Re: [core] draft-ietf-core-coap-09: retransmission window
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Mar 2012 10:42:50 -0000

On Mar 28, 2012, at 12:36, Carsten Bormann wrote:

> Maybe we should add text about a default "potential retransmission =
window", e.g. 256 s.

Oh, and a little back-of-the-envelope exercise, too:

If we assume a value of 256 s, we can still send 256 messages per second =
from one endpoint to each other endpoint before the MIDs run out.
(You can use additional port numbers if that is not enough, but I think =
I'd switch to TCP when I need that level of throughput.)

The larger problem is of course keeping the state for all those MIDs =
around until the 256 s run out.  Please see

	http://tools.ietf.org/html/draft-bormann-lwig-guidance

for one discussion on how to do that.  Esko and I will certainly be =
happy to add your suggestions to this text!

One more observation: In many cases, a server can run stateless and =
completely eliminate the need to ever think about MIDs (except for =
echoing them back in ACK/RST).

Gr=FC=DFe, Carsten


From cabo@tzi.org  Wed Mar 28 03:45:16 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D6C21F8A2B for ; Wed, 28 Mar 2012 03:45: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 CuIjl0iaz3nc for ; Wed, 28 Mar 2012 03:45:16 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D30D121F8A33 for ; Wed, 28 Mar 2012 03:45:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2SAj8JU021970; Wed, 28 Mar 2012 12:45:08 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 803AFD1B; Wed, 28 Mar 2012 12:45:08 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Wed, 28 Mar 2012 12:45:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2FD8BC71-93B9-44FA-BCF1-9B9BDD705CDA@tzi.org>
References: 
To: "Angelo P. Castellani" 
X-Mailer: Apple Mail (2.1257)
Cc: core 
Subject: Re: [core] draft-ietf-core-coap-09: Mixed NON/CON separate responses
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 28 Mar 2012 10:45:16 -0000

On Mar 28, 2012, at 10:46, Angelo P. Castellani wrote:

> Does someone has an implementation supporting this? Anyone has some =
experience with this?

If you properly separate off the message layer, it becomes hard work not =
to support this.

Gr=FC=DFe, Carsten


From cabo@tzi.org  Wed Mar 28 03:51:03 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6BE21F8A43 for ; Wed, 28 Mar 2012 03:51:03 -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 dk4ufqF7cT99 for ; Wed, 28 Mar 2012 03:51: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 4A95521F8997 for ; Wed, 28 Mar 2012 03:51:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2SAosG2026805; Wed, 28 Mar 2012 12:50:54 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CAF6BD23; Wed, 28 Mar 2012 12:50:53 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Wed, 28 Mar 2012 12:50:53 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7CF009A0-2395-468F-81A0-8D3701200E4F@tzi.org>
References: 
To: "Angelo P. Castellani" 
X-Mailer: Apple Mail (2.1257)
Cc: core WG 
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 28 Mar 2012 10:51:03 -0000

On Mar 28, 2012, at 09:51, Kovatsch Matthias wrote:

> How does the message-layer know to which identifier should the =
response in the example be mapped to?

The job of the message layer is to make sure confirmable messages do =
arrive and that duplicates are detected where that is required.
This question belongs in the request/response layer.

In other words:
This is about the same question as "how does IP forward packets without =
understanding port numbers".
Of course, once the message layer has done its job, the request/response =
layer has to look at the token to find out which exchange this message =
is about.

When talking about the matching that occurs at the two layers, please =
make sure to talk about MIDs and Tokens explicitly. =20
They are different enough that this effort in clarity is worth it.

Gr=FC=DFe, Carsten


From cabo@tzi.org  Wed Mar 28 04:12:55 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BDA21F898C for ; Wed, 28 Mar 2012 04:12:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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 tyQpqM+jtXsx for ; Wed, 28 Mar 2012 04:12: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 EEAE121F8946 for ; Wed, 28 Mar 2012 04:12:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2SBClxW006275; Wed, 28 Mar 2012 13:12:47 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 59BF3D53; Wed, 28 Mar 2012 13:12:47 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Wed, 28 Mar 2012 13:12:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  
To: "Angelo P. Castellani" 
X-Mailer: Apple Mail (2.1257)
Cc: "core@ietf.org" 
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 28 Mar 2012 11:12:56 -0000

On Mar 28, 2012, at 10:21, Angelo P. Castellani wrote:

> The upper-layer should instruct the message layer on ACKing or RSTing =
it, because the message-layer has no state at all (thus neither a state =
machine to handle it).

Indeed.  The interface between message-layer and request/response layer =
is quite tightly coupled.
When an incoming message is handed up the SAP, the rr layer should say =
whether that message is acceptable or not and only then should the m =
layer generate the ACK/RST.  But you have to do something like this =
already for properly piggy-backing responses, so this is not a big =
additional burden.

Gr=FC=DFe, Carsten


From kovatsch@inf.ethz.ch  Wed Mar 28 04:28:07 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B128521F8881 for ; Wed, 28 Mar 2012 04:28:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.599
X-Spam-Level: 
X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJS9o7Fs4TJp for ; Wed, 28 Mar 2012 04:28:07 -0700 (PDT)
Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id E71EE21F8868 for ; Wed, 28 Mar 2012 04:28:06 -0700 (PDT)
Received: from CAS20.d.ethz.ch (172.31.51.110) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 28 Mar 2012 13:28:04 +0200
Received: from MBX10.d.ethz.ch ([169.254.1.51]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%10]) with mapi id 14.01.0355.002; Wed, 28 Mar 2012 13:28:04 +0200
From: "Kovatsch  Matthias" 
To: "cabo@tzi.org" , "guido.moritz@uni-rostock.de" 
Thread-Topic: [core] draft-ietf-core-coap-09: Artificial option count	and length limitations
Thread-Index: AQHNC2kWJGNv2uSVf0GaDzBe1rEPJJZ8m1oAgAL5gfs=
Date: Wed, 28 Mar 2012 11:28:03 +0000
Message-ID: 
References: <55877B3AFB359744BA0F2140E36F52B51396D485@MBX10.d.ethz.ch> <272BED9E-E267-475E-BDF2-A8D2C4A94D2D@tzi.org> <003901cd0b69$0ce99a40$26bccec0$@uni-rostock.de>, 
In-Reply-To: 
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "core@ietf.org" 
Subject: Re: [core] draft-ietf-core-coap-09: Artificial option count	and	length limitations
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 28 Mar 2012 11:28:07 -0000

So, will there be a ticket for '1?' :)
Carsten Bormann  wrote:
On Mar 26, 2012, at 17:56, Guido Moritz wrote:

> Just to clarify: The current limitation to 270 Byte in the draft also
> affects the URI-options, not only the proxy URI?!
>
> Without reading the draft in depth again: Wouldn't it be reasonable to
> remove the limitation from all the URI options?!

Hi Guido,

welcome back to the mailing list :-)

the 270 byte limitation we have in -09 applies to each single option; in th=
e case of URIs these are already split up into component options to elimina=
te percent-encoding processing at the servers.  So you can have pretty long=
 URIs, just not with segments longer than 270 bytes.
Matthias' proposal 1 fixes that limitation, too.
It also allows us to get rid of a special case that provided for longer Uri=
-Proxy URIs by splitting them up into 270-byte fragments (ouch).

Gr=FC=DFe, Carsten

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

From jeroen.hoebeke@intec.ugent.be  Wed Mar 28 04:59:37 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723AD21F8858 for ; Wed, 28 Mar 2012 04:59:36 -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 7dQYvnA1QEv1 for ; Wed, 28 Mar 2012 04:59:34 -0700 (PDT)
Received: from smtp1.UGent.be (smtp1.ugent.be [157.193.71.182]) by ietfa.amsl.com (Postfix) with ESMTP id A918221F8835 for ; Wed, 28 Mar 2012 04:59:32 -0700 (PDT)
Received: from localhost (mcheck3.ugent.be [157.193.71.89]) by smtp1.UGent.be (Postfix) with ESMTP id A2E293F6B2A; Wed, 28 Mar 2012 13:59:31 +0200 (CEST)
X-Virus-Scanned: by UGent DICT
Received: from smtp1.UGent.be ([157.193.71.182]) by localhost (mcheck3.ugent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id M+dCRoeVD+JO; Wed, 28 Mar 2012 13:59:31 +0200 (CEST)
Received: from [192.168.123.5] (78-21-4-198.access.telenet.be [78.21.4.198]) (Authenticated sender: jjhoebek) by smtp1.UGent.be (Postfix) with ESMTPSA id 423753F6AFE; Wed, 28 Mar 2012 13:59:31 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Jeroen Hoebeke 
In-Reply-To: <2FD8BC71-93B9-44FA-BCF1-9B9BDD705CDA@tzi.org>
Date: Wed, 28 Mar 2012 13:59:32 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0DBD9CF4-7AAF-4404-B5EA-F5AC266F49AA@intec.ugent.be>
References:  <2FD8BC71-93B9-44FA-BCF1-9B9BDD705CDA@tzi.org>
To: "Angelo P. Castellani" , core WG 
X-Mailer: Apple Mail (2.1257)
X-Miltered: at mcheck3 with ID 4F72FD23.000 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)!
X-j-chkmail-Enveloppe: 4F72FD23.000/78.21.4.198/78-21-4-198.access.telenet.be/[192.168.123.5]/
X-j-chkmail-Score: MSGID : 4F72FD23.000 on smtp1.UGent.be : j-chkmail score : . : R=. U=. O=# B=0.000 -> S=0.083
X-j-chkmail-Status: Ham
Subject: Re: [core] draft-ietf-core-coap-09: Mixed NON/CON separate responses
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 28 Mar 2012 11:59:37 -0000

On 28 Mar 2012, at 12:45, Carsten Bormann wrote:

> On Mar 28, 2012, at 10:46, Angelo P. Castellani wrote:
>=20
>> Does someone has an implementation supporting this? Anyone has some =
experience with this?
>=20
> If you properly separate off the message layer, it becomes hard work =
not to support this.

I agree with that. Both cases are supported by default in our =
implementation.
When making a request, we have two basic things to check:
1) is the message acknowledged (only needed for CON)
2) did the response arrive (request/response matching)

In case 1, the ACK will fulfill 1 and the NON will fulfill 2, completing =
the request
In case 2, the CON will automatically result in an ACK response and the =
response processing will fulfill 2 (1 does not apply here, since the =
request is NON).

Even when in case 1, the ACK and NON arrive in a different order, the =
end result will be the same. You will just follow an alternative path in =
your state machine.


C     S   ||   C     S
| CON |   ||   | NON |
|---->|   ||   |---->|
| ACK |   ||   | CON |
|<----|   ||   |<----|
| NON |   ||   | ACK |
|<----|   ||   |---->|



Kind regards,
Jeroen





From jeroen.hoebeke@intec.ugent.be  Wed Mar 28 05:21:47 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5386121E81B3 for ; Wed, 28 Mar 2012 05:21:47 -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 uzsq3JeyF+Td for ; Wed, 28 Mar 2012 05:21:46 -0700 (PDT)
Received: from smtp1.UGent.be (smtp1.ugent.be [157.193.71.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4534921E817F for ; Wed, 28 Mar 2012 05:21:46 -0700 (PDT)
Received: from localhost (mcheck3.ugent.be [157.193.71.89]) by smtp1.UGent.be (Postfix) with ESMTP id 3B9DD3F6D36; Wed, 28 Mar 2012 14:21:45 +0200 (CEST)
X-Virus-Scanned: by UGent DICT
Received: from smtp1.UGent.be ([157.193.71.182]) by localhost (mcheck3.ugent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id zkVEbD-zKYXI; Wed, 28 Mar 2012 14:21:45 +0200 (CEST)
Received: from [192.168.123.5] (78-21-4-198.access.telenet.be [78.21.4.198]) (Authenticated sender: jjhoebek) by smtp1.UGent.be (Postfix) with ESMTPSA id D9DC83F6D34; Wed, 28 Mar 2012 14:21:44 +0200 (CEST)
From: Jeroen Hoebeke 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Date: Wed, 28 Mar 2012 14:21:40 +0200
To: core WG 
Message-Id: <2764021A-0555-46ED-871E-B434A1EF1541@intec.ugent.be>
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
X-Miltered: at mcheck3 with ID 4F730258.000 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)!
X-j-chkmail-Enveloppe: 4F730258.000/78.21.4.198/78-21-4-198.access.telenet.be/[192.168.123.5]/
X-j-chkmail-Score: MSGID : 4F730258.000 on smtp1.UGent.be : j-chkmail score : . : R=. U=. O=# B=0.000 -> S=0.083
X-j-chkmail-Status: Ham
Subject: [core] draft-ietf-core-observe-05 - combination of block-wise transfers with 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, 28 Mar 2012 12:21:47 -0000

Dear WG,

While once more reading through draft observe, I have a few questions =
about section 6 (block-wise transfers with notifications). The server =
sends all blocks sequentially, which differs from a normal block 2 =
transfer where the client requests the next block.

- isn't it a drawback to have 2 different block2 transfer mechanisms? =
E.g. the first response to the initial GET with the observe option, will =
use normal block2 transfer. All subsequent notifications will use the =
'turbo-mode' block2 approach described in section 6. Both client and =
server now need to implement additional block2 behavior + a congestion =
control mechanism.=20
- the existence of this approach could leave the door open for abuse, =
where some implementations use it to speed up normal block2 transfer=20
- is there a preferred behavior when there are multiple observers? =
Sending the first block to all observers, then the next block=85?

A possible alternative could be the following:
- the server sends an empty (no payload) notification containing the =
size option and possible etag options. The client now knows that the =
resource has changed and can decide to fetch it. With multiple =
observers, this could have a advantage in case there is a cache. As soon =
as 1 client has retrieved the updated resource, all the other clients =
can get it from an intermediate cache.=20

Block-wise transfer of notifications will certainly occur (e.g. when =
observing .well-known/core), but should we have a different mechanism =
for that?

Kind regards,
Jeroen=

From cabo@tzi.org  Wed Mar 28 05:27:35 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF50521E8198 for ; Wed, 28 Mar 2012 05:27:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.242
X-Spam-Level: 
X-Spam-Status: No, score=-106.242 tagged_above=-999 required=5 tests=[AWL=0.007, 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 UpKBJ9ZJ2xXw for ; Wed, 28 Mar 2012 05:27:35 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF5521E8195 for ; Wed, 28 Mar 2012 05:27:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2SCN8C4002486; Wed, 28 Mar 2012 14:27:27 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F125F8BF; Wed, 28 Mar 2012 13:47:08 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Wed, 28 Mar 2012 13:47:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <864124BA-CC04-4B71-86F9-2B9382472979@tzi.org>
References: <55877B3AFB359744BA0F2140E36F52B51396D485@MBX10.d.ethz.ch> <272BED9E-E267-475E-BDF2-A8D2C4A94D2D@tzi.org> <003901cd0b69$0ce99a40$26bccec0$@uni-rostock.de>,  
To: "Kovatsch  Matthias" 
X-Mailer: Apple Mail (2.1257)
Cc: "core@ietf.org WG" 
Subject: Re: [core] draft-ietf-core-coap-09: Artificial option count	and length limitations
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 28 Mar 2012 12:27:35 -0000

> So, will there be a ticket for '1?' :)

Yes!

I plan to make tickets from the notes of the first WG meeting in the =
course of the afternoon.
(I just want to make sure I capture things like repairing Uri-Proxy when =
this is fixed in the same ticket...)

Gr=FC=DFe, Carsten


From trac+core@trac.tools.ietf.org  Wed Mar 28 05:27:35 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39F421E8195 for ; Wed, 28 Mar 2012 05:27:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.588
X-Spam-Level: 
X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 6EprmBEgCA3l for ; Wed, 28 Mar 2012 05:27:35 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 10EE421E8197 for ; Wed, 28 Mar 2012 05:27:34 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SCrxy-00046R-Gi; Wed, 28 Mar 2012 08:27:06 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org
X-Trac-Project: core
Date: Wed, 28 Mar 2012 12:27:06 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/202
Message-ID: <051.e7fbc0f0f5736d305a309a9e8d0cd924@trac.tools.ietf.org>
X-Trac-Ticket-ID: 202
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: 
Resent-Message-Id: <20120328122735.10EE421E8197@ietfa.amsl.com>
Resent-Date: Wed, 28 Mar 2012 05:27:34 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: [core]  #202: Remove the 270 byte artificial limit
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, 28 Mar 2012 12:27:36 -0000

#202: Remove the 270 byte artificial limit

 For a while, it seemed we had consensus to leave in the artificial limit
 of 270 bytes for the option length.  However, this left a scar on Uri-
 Proxy, which needed special handling for the rare case where this creates
 a problem.

 Matthias Kovatsch has now proposed a simple way to remove the artificial
 limitation, which is documented in section 2.1 of

        http://tools.ietf.org/html/draft-bormann-coap-misc-14#section-2.1

 This change will also enable the reverting of Uri-Proxy to its natural
 state of a  non-repeatable option.

-- 
-----------------------------+------------------------------------
 Reporter:  cabo@…           |      Owner:  draft-ietf-core-coap@…
     Type:  protocol defect  |     Status:  new
 Priority:  minor            |  Milestone:
Component:  coap             |    Version:
 Severity:  In WG Last Call  |   Keywords:
-----------------------------+------------------------------------

Ticket URL: 
core 


From jeroen.hoebeke@intec.ugent.be  Wed Mar 28 05:46:42 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE6321E8203 for ; Wed, 28 Mar 2012 05:46: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 tCoC-NI2+OjR for ; Wed, 28 Mar 2012 05:46:41 -0700 (PDT)
Received: from smtp2.UGent.be (smtp2.ugent.be [157.193.49.126]) by ietfa.amsl.com (Postfix) with ESMTP id EA5E321E8200 for ; Wed, 28 Mar 2012 05:46:40 -0700 (PDT)
Received: from localhost (mcheck5.ugent.be [157.193.49.247]) by smtp2.UGent.be (Postfix) with ESMTP id 061C244A2CD; Wed, 28 Mar 2012 14:46:40 +0200 (CEST)
X-Virus-Scanned: by UGent DICT
Received: from smtp2.UGent.be ([157.193.49.126]) by localhost (mcheck5.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id L627kWRu1oTo; Wed, 28 Mar 2012 14:46:39 +0200 (CEST)
Received: from [192.168.123.5] (78-21-4-198.access.telenet.be [78.21.4.198]) (Authenticated sender: jjhoebek) by smtp2.UGent.be (Postfix) with ESMTPSA id 2F94644A2A8; Wed, 28 Mar 2012 14:46:39 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=windows-1252
From: Jeroen Hoebeke 
In-Reply-To: 
Date: Wed, 28 Mar 2012 14:46:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <74BA79E9-3A3A-43AB-85B7-3BE22A9C0DAD@intec.ugent.be>
References: 
To: core WG 
X-Mailer: Apple Mail (2.1257)
X-Miltered: at mcheck3 with ID 4F73082E.000 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)!
X-j-chkmail-Enveloppe: 4F73082E.000/78.21.4.198/78-21-4-198.access.telenet.be/[192.168.123.5]/
X-j-chkmail-Score: MSGID : 4F73082E.000 on smtp2.UGent.be : j-chkmail score : . : R=. U=. O=# B=0.000 -> S=0.083
X-j-chkmail-Status: Ham
Cc: hartke@tzi.org
Subject: Re: [core] draft-ietf-core-observe-05 - use of 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: Wed, 28 Mar 2012 12:46:42 -0000

Dear working group,

I gave the max-age issue a bit more thought and discussed this with =
Klaus.

I feel the issue described in my earlier e-mail, is mainly caused due to =
the fact that the max-age option is used for two purposes at the same =
time: 1) the freshness of a notification 2) the duration of the =
established observation relationship. This has a number of drawbacks:
- how to deal with notifications of non-cacheable resources (max-age =
=3D0). This is not described in the draft
- what when a client wants to only observe changes, max-age is short and =
the client does not want to reregister all the time to be sure about the =
duration of the relationship

Giving it some further thought, it feels most of the problems could be =
solved by incorporating the Pledge option (described in =
draft-bormann-coap-misc-13 section 4.3) into this draft
- max-age option: only indicates the freshness of the notification
- pledge option: only indicates the duration of the relationship.

With these two options one can cover all different cases, as I will =
describe below:

1) client establishes observation relationship, server sends back =
response with Obs and Max-age option
-> in absence of the Pledge option, the duration of the relationship is =
assumed to be minimally max-age
=3D> this is the behavior as currently described in the draft

2) client establishes observation relationship, server sends back =
response with Obs, Max-age and Pledge option
-> max-age is the freshness and can be used by a cache
-> pledge (> max-age) indicates the duration of the relationship, which =
can be much longer than max-age. Client should not reregister interest =
before pledge duration expires.

3)  client establishes observation relationship for non-cacheable =
resource, server sends back response with Obs, Max-age and Pledge option
-> max-age is 0, pledge option must be set
-> non cacheable, but pledge indicates the duration of the relationship

4) client establishes observation relationship and indicates a preferred =
duration of this relationship
-> client can send request including observe and pledge option
-> server decides about value of the pledge option in response

With this approach, all cases can be covered:
- relationship where a client will always have a fresh and consistent =
representation of the resource (max-age =3D pledge)
- long-lasting relationship where pledge > max-age
- observation relationship of non-cacheable resource
=85

I would prefer to see the Pledge option become part of the draft, since =
it would allow more flexibility (without losing interoperability), would =
cleanly separate freshness from relationship duration and would solve =
some inconsistencies in the current draft such as observing =
non-cacheable resources.

Kind regards,
Jeroen


On 26 Mar 2012, at 17:58, Jeroen Hoebeke wrote:

> Dear working group,
>=20
> In draft-ietf-core-coap-09, max-age is introduced to indicate the =
freshness of a response, useful for caching. In =
draft-ietf-core-observe-05, max-age is also used and the following is =
stated: It (the server) will send a notification whenever the resource =
changes, or at latest when the age of the last notification becomes =
greater than its Max-Age.
>=20
> While implementing this functionality for the plugtest event, we found =
this to be a quite stringent requirement for a resource constrained =
device (in particular when the resource does not change frequently, e.g. =
a door sensor during night). Simply increasing max-age is not really a =
nice solution, since then you impact freshness. Also, alternative =
solutions for realizing notifications latest after X seconds have been =
proposed already (e.g. draft-shelby-core-interfaces-02 section 4.8 or =
draft-li-core-conditional-observe-01). It seems the behavior in =
draft-ietf-core-observe-05 has been particularly designed for e.g. a =
cache that always needs to have a fresh representation.
>=20
> We would like to have some more freedom here. This could be done by =
shifting the responsibility to the observer by stating that "an observer =
should not re-register its interest before max-age expires". The server =
then has the freedom to send notifications only when the resource =
changes OR every time the age of the last notification becomes greater =
than max-age. The client then has the freedom to reregister immediately =
after max-age or to wait much longer (depending on the application). The =
meaning of max-age for caching purposes does not change.
>=20
> Kind regards,
> Jeroen
>=20
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

********************************************************************
dr. ir. Jeroen Hoebeke
Department of Information Technology
Internet Based Communication Networks and Services (IBCN)
Ghent University - IBBT=20
Gaston Crommenlaan 8 (Bus 201)
B-9050 Gent, Belgium

T:              +32 9 33 14954
T Secr:     +32 9 33 14900=09
F:              +32 9 33 14899
E-mail:     jeroen.hoebeke@intec.UGent.be
Web site: http://www.ibcn.intec.UGent.be=09
                  http://www.ibbt.be
********************************************************************


From kovatsch@inf.ethz.ch  Wed Mar 28 05:53:49 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3027021E820E for ; Wed, 28 Mar 2012 05:53:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.266
X-Spam-Level: 
X-Spam-Status: No, score=-7.266 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 Dkox9gHFtjoI for ; Wed, 28 Mar 2012 05:53:47 -0700 (PDT)
Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0BE21E81DE for ; Wed, 28 Mar 2012 05:53:45 -0700 (PDT)
Received: from CAS22.d.ethz.ch (172.31.51.112) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 28 Mar 2012 14:53:44 +0200
Received: from MBX10.d.ethz.ch ([169.254.1.51]) by CAS22.d.ethz.ch ([fe80::dd0e:466a:b055:c090%10]) with mapi id 14.01.0355.002; Wed, 28 Mar 2012 14:53:44 +0200
From: "Kovatsch  Matthias" 
To: "jeroen.hoebeke@intec.ugent.be" , "core@ietf.org" 
Thread-Topic: [core] draft-ietf-core-observe-05 - use of max-age
Thread-Index: AQHNC2lUarr/yknXEESDD3Hq6cN3Z5Z/iUoAgAAjgR4=
Date: Wed, 28 Mar 2012 12:53:44 +0000
Message-ID: 
References: , <74BA79E9-3A3A-43AB-85B7-3BE22A9C0DAD@intec.ugent.be>
In-Reply-To: <74BA79E9-3A3A-43AB-85B7-3BE22A9C0DAD@intec.ugent.be>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "hartke@tzi.org" 
Subject: Re: [core] draft-ietf-core-observe-05 - use of 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: Wed, 28 Mar 2012 12:53:49 -0000

+1 to include Pledge in observing

Matthias


Jeroen Hoebeke  wrote:
Dear working group,

I gave the max-age issue a bit more thought and discussed this with Klaus.

I feel the issue described in my earlier e-mail, is mainly caused due to th=
e fact that the max-age option is used for two purposes at the same time: 1=
) the freshness of a notification 2) the duration of the established observ=
ation relationship. This has a number of drawbacks:
- how to deal with notifications of non-cacheable resources (max-age =3D0).=
 This is not described in the draft
- what when a client wants to only observe changes, max-age is short and th=
e client does not want to reregister all the time to be sure about the dura=
tion of the relationship

Giving it some further thought, it feels most of the problems could be solv=
ed by incorporating the Pledge option (described in draft-bormann-coap-misc=
-13 section 4.3) into this draft
- max-age option: only indicates the freshness of the notification
- pledge option: only indicates the duration of the relationship.

With these two options one can cover all different cases, as I will describ=
e below:

1) client establishes observation relationship, server sends back response =
with Obs and Max-age option
-> in absence of the Pledge option, the duration of the relationship is ass=
umed to be minimally max-age
=3D> this is the behavior as currently described in the draft

2) client establishes observation relationship, server sends back response =
with Obs, Max-age and Pledge option
-> max-age is the freshness and can be used by a cache
-> pledge (> max-age) indicates the duration of the relationship, which can=
 be much longer than max-age. Client should not reregister interest before =
pledge duration expires.

3)  client establishes observation relationship for non-cacheable resource,=
 server sends back response with Obs, Max-age and Pledge option
-> max-age is 0, pledge option must be set
-> non cacheable, but pledge indicates the duration of the relationship

4) client establishes observation relationship and indicates a preferred du=
ration of this relationship
-> client can send request including observe and pledge option
-> server decides about value of the pledge option in response

With this approach, all cases can be covered:
- relationship where a client will always have a fresh and consistent repre=
sentation of the resource (max-age =3D pledge)
- long-lasting relationship where pledge > max-age
- observation relationship of non-cacheable resource
=85

I would prefer to see the Pledge option become part of the draft, since it =
would allow more flexibility (without losing interoperability), would clean=
ly separate freshness from relationship duration and would solve some incon=
sistencies in the current draft such as observing non-cacheable resources.

Kind regards,
Jeroen


On 26 Mar 2012, at 17:58, Jeroen Hoebeke wrote:

> Dear working group,
>
> In draft-ietf-core-coap-09, max-age is introduced to indicate the freshne=
ss of a response, useful for caching. In draft-ietf-core-observe-05, max-ag=
e is also used and the following is stated: It (the server) will send a not=
ification whenever the resource changes, or at latest when the age of the l=
ast notification becomes greater than its Max-Age.
>
> While implementing this functionality for the plugtest event, we found th=
is to be a quite stringent requirement for a resource constrained device (i=
n particular when the resource does not change frequently, e.g. a door sens=
or during night). Simply increasing max-age is not really a nice solution, =
since then you impact freshness. Also, alternative solutions for realizing =
notifications latest after X seconds have been proposed already (e.g. draft=
-shelby-core-interfaces-02 section 4.8 or draft-li-core-conditional-observe=
-01). It seems the behavior in draft-ietf-core-observe-05 has been particul=
arly designed for e.g. a cache that always needs to have a fresh representa=
tion.
>
> We would like to have some more freedom here. This could be done by shift=
ing the responsibility to the observer by stating that "an observer should =
not re-register its interest before max-age expires". The server then has t=
he freedom to send notifications only when the resource changes OR every ti=
me the age of the last notification becomes greater than max-age. The clien=
t then has the freedom to reregister immediately after max-age or to wait m=
uch longer (depending on the application). The meaning of max-age for cachi=
ng purposes does not change.
>
> Kind regards,
> Jeroen
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

********************************************************************
dr. ir. Jeroen Hoebeke
Department of Information Technology
Internet Based Communication Networks and Services (IBCN)
Ghent University - IBBT
Gaston Crommenlaan 8 (Bus 201)
B-9050 Gent, Belgium

T:              +32 9 33 14954
T Secr:     +32 9 33 14900
F:              +32 9 33 14899
E-mail:     jeroen.hoebeke@intec.UGent.be
Web site: http://www.ibcn.intec.UGent.be
                  http://www.ibbt.be
********************************************************************

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

From trac+core@trac.tools.ietf.org  Wed Mar 28 07:05:48 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C784C21E8239 for ; Wed, 28 Mar 2012 07:05:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.588
X-Spam-Level: 
X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 IEiWr0L0Dqy5 for ; Wed, 28 Mar 2012 07:05:47 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4810821E824E for ; Wed, 28 Mar 2012 07:05:46 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SCtVA-0000co-NU; Wed, 28 Mar 2012 10:05:28 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org
X-Trac-Project: core
Date: Wed, 28 Mar 2012 14:05:28 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/203
Message-ID: <051.c9f279ab8cd10352f182c29fc7692982@trac.tools.ietf.org>
X-Trac-Ticket-ID: 203
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: 
Resent-Message-Id: <20120328140547.4810821E824E@ietfa.amsl.com>
Resent-Date: Wed, 28 Mar 2012 07:05:46 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: [core] #203: Restrict the potential combinations of Block1 and Block2
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, 28 Mar 2012 14:05:49 -0000

#203: Restrict the potential combinations of Block1 and Block2

 Bert Greevenbosch noted that, currently, there is nothing that would
 disallow a server to respond to a message that carries a non-final
 (more=1) Block1 with a response carrying a Block2 option.  This
 creates a large number of potential combinations, not all of which
 have been tested by examining them in examples or implementing them.

 Instead, the set of combinations should be limited to the ones that we
 created Block1/Block2 for in the first place.  If more complex
 exchanges are required later, they can be enabled by another option.

 The main reason to have Block1 separate from Block2 was to be able to
 send large response payloads to a POST request with a large payload.
 It is therefore sufficient to allow the use of Block2 (or any payload,
 for that matter) in the response only for requests that either don't
 carry Block1 or carry a Block1 option with M=0 (i.e., final).

 (Note that it still needs to be possible to send error indication
 payloads with 4.xx/5.xx responses to requests that carry Block1 with
 M=1).

-- 
-----------------------------+-------------------------------------
 Reporter:  cabo@…           |      Owner:  draft-ietf-core-block@…
     Type:  protocol defect  |     Status:  new
 Priority:  major            |  Milestone:
Component:  block            |    Version:
 Severity:  In WG Last Call  |   Keywords:
-----------------------------+-------------------------------------

Ticket URL: 
core 


From angelo.castellani@gmail.com  Wed Mar 28 07:08:49 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244E421E8253; Wed, 28 Mar 2012 07:08: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=[AWL=0.000,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnzSOOrOtLgm; Wed, 28 Mar 2012 07:08:48 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id DB30421E8200; Wed, 28 Mar 2012 07:08:47 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so691861wgb.13 for ; Wed, 28 Mar 2012 07:08:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=8wGWU5Y21e1ZPW+Ij22Ln+cCqoORoEL0Z8LpY8Brxfg=; b=FccKZblrDEfJz5B6kypaPWvV+p8AbcAY073tho+x/4f7DrIMU7GZ11geck5ynN7fHd sLjypCqYnS48K+kGy8CGmtt6lwQJA6+zNn4H0KhSaiUrMePiklJc7i3gJoooSkssGh7v Vu763M6KC1P+rxi85iqkpJECeYRtxLkdosv8xyAWNm8bwcdYeANjaZtjlXbRBAWYKOy6 9s1DFYOJLLQGMoyxSOoa0OjBSDdVE62cWavB9u4e7UpRcFuRSIjSVoiHHX2QTv+AcZNC 6Cl0kWYfEvSmnuRNgqgG6ZswffK39h+tCcKB//rZtl2rLmCxPQZ+GBhHCErpK+kcAbGc W/fg==
Received: by 10.216.131.30 with SMTP id l30mr17044040wei.111.1332943727044; Wed, 28 Mar 2012 07:08:47 -0700 (PDT)
MIME-Version: 1.0
Sender: angelo.castellani@gmail.com
Received: by 10.216.121.148 with HTTP; Wed, 28 Mar 2012 07:08:06 -0700 (PDT)
In-Reply-To: <6FA878C6-AB5E-43B2-9474-36FF6670C265@tzi.org>
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>  <004001cd0b6b$f1051220$d30f3660$@uni-rostock.de>  <4F709ADC.6050800@ericsson.com> <3A433490-AB35-4340-9CA8-B5DA2FF69F26@koanlogic.com>  <7BFCD86A-AA06-45E9-8F4D-ABFC4AE9C681@koanlogic.com>  <6FA878C6-AB5E-43B2-9474-36FF6670C265@tzi.org>
From: "Angelo P. Castellani" 
Date: Wed, 28 Mar 2012 16:08:06 +0200
X-Google-Sender-Auth: ldyYWHtFmV005t-ShznZAj_9zT8
Message-ID: 
To: Carsten Bormann 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: lwip@ietf.org, core WG 
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 28 Mar 2012 14:08:49 -0000

On Tue, Mar 27, 2012 at 13:31, Carsten Bormann  wrote:
> Can we try to separate the message and request/response layers?

I have built a FSM with the message-layer splitted from the
request/response-layer.=C2=A0I will validate this by implementation.

If you want to have a look at that you can find it here:
http://www.dei.unipd.it/~castellani/coap_m_fsm.pdf
http://www.dei.unipd.it/~castellani/coap_rr_fsm.pdf

Comments are welcome.

(it is a draft drawing, please be patient).

Best,
Angelo

From angelo.castellani@gmail.com  Wed Mar 28 07:10:28 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F11E21E8190 for ; Wed, 28 Mar 2012 07:10:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xrj2teJnZGX9 for ; Wed, 28 Mar 2012 07:10:27 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 73BB921E824E for ; Wed, 28 Mar 2012 07:10:27 -0700 (PDT)
Received: by werb10 with SMTP id b10so805464wer.31 for ; Wed, 28 Mar 2012 07:10:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=fotoAL8NJ6GbsL/BbDqY6CPnHtRudTYkj+xnk3anYEc=; b=R0qdBZsRp4EMlpo23iGB+r1/tCLcJfgmqzUo79Gtkr5ZKDYKVZj3Xb8gakIhvXq7RR 4Ig7wM/j/tot91y36rm6X6w6/DdHEji1btG8KiRt92tIAloykW/Bn9YUS179SNmpfdjf QmLqEf1Ogpv2oAVSLOSvLhbXX/m2AZ0nEVz1+/nnVBCvAkggMnxtNbiFEp81AlpELAGc 6oPfDfmPcujbImtA/B2a0tvUVyz21VTyA5dXSDE4MjvAIYmrX0IWPtIu7E7YQE25tKV9 XqBzqbkJZNiTxAiuZgpUUHc9heonT/y4hcG2Ijx58NpeO2Br/FCXhS2S2T+s6yvo3gKu FcQA==
Received: by 10.216.132.202 with SMTP id o52mr17368432wei.106.1332943826459; Wed, 28 Mar 2012 07:10:26 -0700 (PDT)
MIME-Version: 1.0
Sender: angelo.castellani@gmail.com
Received: by 10.216.121.148 with HTTP; Wed, 28 Mar 2012 07:09:46 -0700 (PDT)
In-Reply-To: <0DBD9CF4-7AAF-4404-B5EA-F5AC266F49AA@intec.ugent.be>
References:  <2FD8BC71-93B9-44FA-BCF1-9B9BDD705CDA@tzi.org> <0DBD9CF4-7AAF-4404-B5EA-F5AC266F49AA@intec.ugent.be>
From: "Angelo P. Castellani" 
Date: Wed, 28 Mar 2012 16:09:46 +0200
X-Google-Sender-Auth: r1U-SLWErpHDuNB19z5EsJBMAtc
Message-ID: 
To: Jeroen Hoebeke 
Content-Type: multipart/alternative; boundary=0016e6d647b2481df004bc4e2bf8
Cc: core WG 
Subject: Re: [core] draft-ietf-core-coap-09: Mixed NON/CON separate responses
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 28 Mar 2012 14:10:28 -0000

--0016e6d647b2481df004bc4e2bf8
Content-Type: text/plain; charset=UTF-8

OK. You have convinced me, I have also drawn a FSM supporting this (see
related separate response thread).

I hope to have time to implement it and get back with comments.

Best,
Angelo

On Wed, Mar 28, 2012 at 13:59, Jeroen Hoebeke  wrote:

>
> On 28 Mar 2012, at 12:45, Carsten Bormann wrote:
>
> > On Mar 28, 2012, at 10:46, Angelo P. Castellani wrote:
> >
> >> Does someone has an implementation supporting this? Anyone has some
> experience with this?
> >
> > If you properly separate off the message layer, it becomes hard work not
> to support this.
>
> I agree with that. Both cases are supported by default in our
> implementation.
> When making a request, we have two basic things to check:
> 1) is the message acknowledged (only needed for CON)
> 2) did the response arrive (request/response matching)
>
> In case 1, the ACK will fulfill 1 and the NON will fulfill 2, completing
> the request
> In case 2, the CON will automatically result in an ACK response and the
> response processing will fulfill 2 (1 does not apply here, since the
> request is NON).
>
> Even when in case 1, the ACK and NON arrive in a different order, the end
> result will be the same. You will just follow an alternative path in your
> state machine.
>
>
> C     S   ||   C     S
> | CON |   ||   | NON |
> |---->|   ||   |---->|
> | ACK |   ||   | CON |
> |<----|   ||   |<----|
> | NON |   ||   | ACK |
> |<----|   ||   |---->|
>
>
>
> Kind regards,
> Jeroen
>
>
>
>
>

--0016e6d647b2481df004bc4e2bf8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

OK. You have convinced me, I have also drawn a FSM supporting this (see rel=
ated separate response thread).

I hope to have time to i=
mplement it and get back with comments.

Best,


Angelo

On Wed, Mar =
28, 2012 at 13:59, Jeroen Hoebeke <jeroen.hoebeke@intec.ugent.=
be> wrote:






On 28 Mar 2012, at 12:45, Carsten Bormann wrote:



> On Mar 28, 2012, at 10:46, Angelo P. Castellani wrote:

>

>> Does someone has an implementation supporting this? Anyone has som=
e experience with this?

>

> If you properly separate off the message layer, it becomes hard work n=
ot to support this.




I agree with that. Both cases are supported by default in our i=
mplementation.

When making a request, we have two basic things to check:

1) is the message acknowledged (only needed for CON)

2) did the response arrive (request/response matching)



In case 1, the ACK will fulfill 1 and the NON will fulfill 2, completing th=
e request

In case 2, the CON will automatically result in an ACK response and the res=
ponse processing will fulfill 2 (1 does not apply here, since the request i=
s NON).



Even when in case 1, the ACK and NON arrive in a different order, the end r=
esult will be the same. You will just follow an alternative path in your st=
ate machine.






C =C2=A0 =C2=A0 S =C2=A0 || =C2=A0 C =C2=A0 =C2=A0 S

| CON | =C2=A0 || =C2=A0 | NON |

|---->| =C2=A0 || =C2=A0 |---->|

| ACK | =C2=A0 || =C2=A0 | CON |

|<----| =C2=A0 || =C2=A0 |<----|

| NON | =C2=A0 || =C2=A0 | ACK |

|<----| =C2=A0 || =C2=A0 |---->|








Kind regards,

Jeroen















--0016e6d647b2481df004bc4e2bf8--

From hartke@tzi.org  Wed Mar 28 07:45:22 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC19721E8249 for ; Wed, 28 Mar 2012 07:45:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level: 
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[AWL=1.325,  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 RCt8Af0uoSPa for ; Wed, 28 Mar 2012 07:45: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 A1CD021E8240 for ; Wed, 28 Mar 2012 07:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2SEjCPX009687 for ; Wed, 28 Mar 2012 16:45:12 +0200 (CEST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D33249CD for ; Wed, 28 Mar 2012 16:45:11 +0200 (CEST)
Received: by vcbfk13 with SMTP id fk13so893418vcb.31 for ; Wed, 28 Mar 2012 07:45:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.27.69 with SMTP id r5mr11707544vdg.129.1332945910409; Wed, 28 Mar 2012 07:45:10 -0700 (PDT)
Received: by 10.220.37.199 with HTTP; Wed, 28 Mar 2012 07:45:10 -0700 (PDT)
In-Reply-To: <74BA79E9-3A3A-43AB-85B7-3BE22A9C0DAD@intec.ugent.be>
References:  <74BA79E9-3A3A-43AB-85B7-3BE22A9C0DAD@intec.ugent.be>
Date: Wed, 28 Mar 2012 16:45:10 +0200
Message-ID: 
From: Klaus Hartke 
To: core WG 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [core] draft-ietf-core-observe-05 - use of 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: Wed, 28 Mar 2012 14:45:22 -0000

Jeroen Hoebeke wrote:
> I would prefer to see the Pledge option become part of the draft, since i=
t would allow more flexibility (without losing interoperability), would cle=
anly separate freshness from relationship duration and would solve some inc=
onsistencies in the current draft such as observing non-cacheable resources=
.

+1.

However, Pledge creates a new problem: The purpose of -observe is to
let a client have a fresh representation of a resource at any given
time. When max-age ends and no notification arrives, the client does
not have a fresh representation. Due to the Pledge Option, the client
knows that it's still on the list of observers, so this could mean two
things:

1. the server sent a notification but the notification got lost;
2. the server did not send a notification because the resource state
did not change.

These are indistinguishable for the client.

The Max-OFE Option solved this problem by defaulting to 2., i.e.
Max-OFE =3D pledge to keep the client on the list of observers for a
certain time period + the client should assume that the resource did
not change if it does not have a fresh representation but knows that
it is on the list of observers.


Klaus

From matthieu.vial@non.schneider-electric.com  Wed Mar 28 08:08:56 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6981221E81B1; Wed, 28 Mar 2012 08:08:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.199
X-Spam-Level: 
X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400,  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 hv8evEN1Bgze; Wed, 28 Mar 2012 08:08:55 -0700 (PDT)
Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4498221E80AC; Wed, 28 Mar 2012 08:08:55 -0700 (PDT)
Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX03.eud.schneider-electric.com with ESMTP id 2012032817042769-203124 ; Wed, 28 Mar 2012 17:04:27 +0200 
In-Reply-To: 
To: Klaus Hartke 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
From: matthieu.vial@non.schneider-electric.com
Message-ID: 
Date: Wed, 28 Mar 2012 17:08:09 +0200
X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 28/03/2012 17:09:52, Serialize complete at 28/03/2012 17:09:52, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 28/03/2012 17:04:27, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 28/03/2012 17:04:29, Serialize complete at 28/03/2012 17:04:29
Content-Type: text/plain; charset="US-ASCII"
Cc: core-bounces@ietf.org, core WG 
Subject: Re: [core] draft-ietf-core-observe-05 - use of 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: Wed, 28 Mar 2012 15:08:56 -0000

Hi Klaus

>When max-age ends and no notification arrives, the client does
>not have a fresh representation. Due to the Pledge Option, the client
>knows that it's still on the list of observers, so this could mean two
>things:

I'm facing almost the same problem with the cache on the mirror proxy 
where Pledge = lifetime of the mirror proxy entry.

I'm not sure about what to do when Max-Age has expired but the resource is 
still reachable on the mirror.
For a mirror proxy I'm thinking about returning a "Gateway Timeout" code 
as a transient error.

Does it make sense for you?

Matthieu

From jeroen.hoebeke@intec.ugent.be  Wed Mar 28 08:10:31 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D0521E80AC for ; Wed, 28 Mar 2012 08:10:31 -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 9bi8-g7YQrzD for ; Wed, 28 Mar 2012 08:10:30 -0700 (PDT)
Received: from smtp3.UGent.be (smtp3.ugent.be [157.193.49.127]) by ietfa.amsl.com (Postfix) with ESMTP id 5153E21E822B for ; Wed, 28 Mar 2012 08:10:30 -0700 (PDT)
Received: from localhost (mcheck3.ugent.be [157.193.71.89]) by smtp3.UGent.be (Postfix) with ESMTP id 3A3F4148098; Wed, 28 Mar 2012 17:10:29 +0200 (CEST)
X-Virus-Scanned: by UGent DICT
Received: from smtp3.UGent.be ([157.193.49.127]) by localhost (mcheck3.ugent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id EQUB4BX2CLMJ; Wed, 28 Mar 2012 17:10:29 +0200 (CEST)
Received: from [192.168.123.5] (78-21-4-198.access.telenet.be [78.21.4.198]) (Authenticated sender: jjhoebek) by smtp3.UGent.be (Postfix) with ESMTPSA id CC408148068; Wed, 28 Mar 2012 17:10:28 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Jeroen Hoebeke 
In-Reply-To: 
Date: Wed, 28 Mar 2012 17:10:27 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <40565EED-37B3-4D56-9197-2C869746CEF7@intec.ugent.be>
References:  <74BA79E9-3A3A-43AB-85B7-3BE22A9C0DAD@intec.ugent.be> 
To: Klaus Hartke 
X-Mailer: Apple Mail (2.1257)
X-Miltered: at mcheck3 with ID 4F7329E4.000 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)!
X-j-chkmail-Enveloppe: 4F7329E4.000/78.21.4.198/78-21-4-198.access.telenet.be/[192.168.123.5]/
X-j-chkmail-Score: MSGID : 4F7329E4.000 on smtp3.UGent.be : j-chkmail score : . : R=. U=. O=# B=0.000 -> S=0.083
X-j-chkmail-Status: Ham
Cc: core WG 
Subject: Re: [core] draft-ietf-core-observe-05 - use of 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: Wed, 28 Mar 2012 15:10:31 -0000

On 28 Mar 2012, at 16:45, Klaus Hartke wrote:

> Jeroen Hoebeke wrote:
>> I would prefer to see the Pledge option become part of the draft, =
since it would allow more flexibility (without losing interoperability), =
would cleanly separate freshness from relationship duration and would =
solve some inconsistencies in the current draft such as observing =
non-cacheable resources.
>=20
> +1.
>=20
> However, Pledge creates a new problem: The purpose of -observe is to
> let a client have a fresh representation of a resource at any given
> time.

There is a difference between the following:
1) informing a client about every change of the state of a resource: =
this is what one would expect when just reading the abstract of the =
draft=20
2) delivering a client an always fresh representation of a resource =
(even if the resource did not change): this is what the draft actually =
implements through the max-age option

Having both makes a lot of sense. Draft observe could fulfill both =
purposes (and would be a good place to do so). If draft observe is only =
about 1) and the abstract clarifies this, an extension to observe =
(introducing pledge) for case 2) seems an obvious step. Personally, I am =
in favor of having this in a single draft.

Kind regards,
Jeroen


From cabo@tzi.org  Wed Mar 28 08:52:03 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CAF21E82BA; Wed, 28 Mar 2012 08:52:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.242
X-Spam-Level: 
X-Spam-Status: No, score=-106.242 tagged_above=-999 required=5 tests=[AWL=0.007, 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 qz2WjMiNHVNa; Wed, 28 Mar 2012 08:52: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 8841B21E82B7; Wed, 28 Mar 2012 08:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2SFprgk011272; Wed, 28 Mar 2012 17:51:53 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BFC7CA1E; Wed, 28 Mar 2012 17:51:52 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Wed, 28 Mar 2012 17:51:51 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1B87D5F8-5520-4EDB-B573-B0916AAABAC3@tzi.org>
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>  <004001cd0b6b$f1051220$d30f3660$@uni-rostock.de>  <4F709ADC.6050800@ericsson.com> <3A433490-AB35-4340-9CA8-B5DA2FF69F26@koanlogic.com>  <7BFCD86A-AA06-45E9-8F4D-ABFC4AE9C681@koanlogic.com>  <6FA878C6-AB5E-43B2-9474-36FF6670C265@tzi.org> 
To: "Angelo P. Castellani" 
X-Mailer: Apple Mail (2.1257)
Cc: lwip@ietf.org, core WG 
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 28 Mar 2012 15:52:04 -0000

On Mar 28, 2012, at 16:08, Angelo P. Castellani wrote:

> http://www.dei.unipd.it/~castellani/coap_m_fsm.pdf

I like that much better.

The RETX ACK is missing its reason (i.e., having got another copy of the =
CON).

It would also probably be useful to indicate that this is a state per =
MID, and that MIDs attach to the *sender* of the NON/CON.

TX-CON allocates a MID.

NONs received get dedupped, too (except see below), and their MIDs time =
out the same way.

In my implementation there is also a reply from the RR layer upon a =
received CON or NON that the RR layer (or its client) didn't care about =
duplicate detection ("stateless").  This MID then goes right back to =
closed.

Gr=FC=DFe, Carsten


From cabo@tzi.org  Wed Mar 28 08:59:21 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0261021F8959; Wed, 28 Mar 2012 08:59:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.243
X-Spam-Level: 
X-Spam-Status: No, score=-106.243 tagged_above=-999 required=5 tests=[AWL=0.006, 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 IYCK-FeQ5sYG; Wed, 28 Mar 2012 08:59:20 -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 1082F21F8934; Wed, 28 Mar 2012 08:59:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2SFx6Sf013959; Wed, 28 Mar 2012 17:59:06 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9D052A25; Wed, 28 Mar 2012 17:59:06 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: 
Date: Wed, 28 Mar 2012 17:59:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <7CAA889A-A0A5-420F-8A4C-639330F180DA@intec.ugent.be>  <004001cd0b6b$f1051220$d30f3660$@uni-rostock.de>  <4F709ADC.6050800@ericsson.com> <3A433490-AB35-4340-9CA8-B5DA2FF69F26@koanlogic.com>  <7BFCD86A-AA06-45E9-8F4D-ABFC4AE9C681@koanlogic.com>  <6FA878C6-AB5E-43B2-9474-36FF6670C265@tzi.org> 
To: "Angelo P. Castellani" 
X-Mailer: Apple Mail (2.1257)
Cc: lwip@ietf.org, core WG 
Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy context
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 28 Mar 2012 15:59:21 -0000

On Mar 28, 2012, at 16:08, Angelo P. Castellani wrote:

> http://www.dei.unipd.it/~castellani/coap_rr_fsm.pdf

Again, much better.

The states are per token.
Note that the client (the one who sent the request) selects the token, =
and the token again attaches to the endpoint pair.

Block (with M=3D1 responses) and observe create somewhat more complex =
state charts.

A somewhat novel event in my implementation is "active token was =
reused":

When a client starts using the same token for a request that the server =
thought still was active (e.g., for an observation relationship or for a =
pending response), this activity is effectively canceled.

Gr=FC=DFe, Carsten


From trac+core@trac.tools.ietf.org  Wed Mar 28 10:52:10 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4F821E8040 for ; Wed, 28 Mar 2012 10:52:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.588
X-Spam-Level: 
X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 MPD2d81NTXho for ; Wed, 28 Mar 2012 10:52:09 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 150E121F860B for ; Wed, 28 Mar 2012 10:52:09 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SCx2L-000234-8Y; Wed, 28 Mar 2012 13:51:57 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: draft-ietf-core-observe@tools.ietf.org, cabo@tzi.org
X-Trac-Project: core
Date: Wed, 28 Mar 2012 17:51:57 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/204
Message-ID: <051.7d477dcf63d5a27be6104f253d5fe611@trac.tools.ietf.org>
X-Trac-Ticket-ID: 204
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-observe@tools.ietf.org, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: 
Resent-Message-Id: <20120328175209.150E121F860B@ietfa.amsl.com>
Resent-Date: Wed, 28 Mar 2012 10:52:09 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: [core]  #204: Introduce a minimal version of Pledge
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Mar 2012 17:52:10 -0000

#204: Introduce a minimal version of Pledge

 Various proposals have been made to solve the robust observation
 relationships problem (#174).
 174 was closed because the "80 %" were solved and a solution for the "20
 %" had not yet come up.

 Jeroen Hoebeke now proposed to do a similar option to Pledge (CoAP-misc
 section 4.3):

        http://tools.ietf.org/html/draft-bormann-coap-misc-14#section-4.3

 but decoupling this completely from Max-Age.
 This would work as follows:

 A server can indicate its promise to keep the client informed in each
 message using the Pledge option (it is probably still useful to let
 Pledge default to the value of Max-Age).  This does not cause any
 extension of Max-Age, i.e. the resource becomes uncacheable once
 Max-Age runs out.  A client can always perform a new explicit GET
 (with or without Observe) to obtain a cacheable representation again.
 An intermediary can pass on the Pledge to its clients, but will need
 to respond to any explicit GET with an explicit GET upstream.

-- 
----------------------------------+---------------------------------------
 Reporter:  cabo@…                |      Owner:  draft-ietf-core-observe@…
     Type:  protocol enhancement  |     Status:  new
 Priority:  major                 |  Milestone:
Component:  observe               |    Version:
 Severity:  In WG Last Call       |   Keywords:
----------------------------------+---------------------------------------

Ticket URL: 
core 


From jeroen.hoebeke@intec.ugent.be  Wed Mar 28 13:13:48 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0890E21F8852 for ; Wed, 28 Mar 2012 13:13:48 -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=[AWL=-0.001, 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 Dl8q4j51wN9P for ; Wed, 28 Mar 2012 13:13:47 -0700 (PDT)
Received: from smtp2.UGent.be (smtp2.ugent.be [157.193.49.126]) by ietfa.amsl.com (Postfix) with ESMTP id 028AA21F884B for ; Wed, 28 Mar 2012 13:13:47 -0700 (PDT)
Received: from localhost (mcheck5.ugent.be [157.193.49.247]) by smtp2.UGent.be (Postfix) with ESMTP id DFD7F44A438; Wed, 28 Mar 2012 22:13:45 +0200 (CEST)
X-Virus-Scanned: by UGent DICT
Received: from smtp2.UGent.be ([157.193.49.126]) by localhost (mcheck5.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id gA0nPZuVob62; Wed, 28 Mar 2012 22:13:45 +0200 (CEST)
Received: from [192.168.123.5] (78-21-4-198.access.telenet.be [78.21.4.198]) (Authenticated sender: jjhoebek) by smtp2.UGent.be (Postfix) with ESMTPSA id 701CD44A40B; Wed, 28 Mar 2012 22:13:45 +0200 (CEST)
From: Jeroen Hoebeke 
Content-Type: multipart/alternative; boundary="Apple-Mail=_CBF21363-D922-40FB-AB48-4BDF5B88AE80"
Date: Wed, 28 Mar 2012 22:13:45 +0200
To: core WG 
Message-Id: <5AE8C0D8-B82E-45D0-B015-A80C8DDBDBB5@intec.ugent.be>
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
X-Miltered: at mcheck3 with ID 4F7370F9.000 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)!
X-j-chkmail-Enveloppe: 4F7370F9.000/78.21.4.198/78-21-4-198.access.telenet.be/[192.168.123.5]/
X-j-chkmail-Score: MSGID : 4F7370F9.000 on smtp2.UGent.be : j-chkmail score : . : R=. U=. O=# B=0.000 -> S=0.083
X-j-chkmail-Status: Ham
Subject: [core] draft-ietf-core-block-08 - size request
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 28 Mar 2012 20:13:48 -0000

--Apple-Mail=_CBF21363-D922-40FB-AB48-4BDF5B88AE80
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Dear WG,

After giving the block draft a final reading, I discovered one minor =
issue that is not clear to me:

How does the server need to behave upon the reception of a size request?
- does it send back an empty response with a size option that gives the =
size estimate of the response? In this case, what is the response when =
the server does not support this option?
or
- does it send back a response with a size option giving the size =
estimate of the response, but with a payload already containing the =
first block?

It would be good to add the desired behavior to the description of the =
size request to avoid confusion.

Kind regards,
Jeroen=

--Apple-Mail=_CBF21363-D922-40FB-AB48-4BDF5B88AE80
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Dear =
WG,

After giving the block draft a final reading, I =
discovered one minor issue that is not clear to me:

How does the server need to =
behave upon the reception of a size request?
- does it send back an empty response with a size =
option that gives the size estimate of the response? In this case, what =
is the response when the server does not support this option?
or
- does it send back a response with a size =
option giving the size estimate of the response, but with a payload =
already containing the first block?

It =
would be good to add the desired behavior to the description of the size =
request to avoid confusion.
Kind regards,

Subject: Re: [core] draft-ietf-core-coap-09: retransmission window
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Mar 2012 07:41:54 -0000

> On Mar 28, 2012, at 11:00, Angelo P. Castellani wrote:
> > Dear WG,
> >=20
> > Section 4.1 tells:
> >    The same Message ID MUST NOT be re-used (per Message
> >    ID variable) within the potential retransmission window, calculated
> >    as RESPONSE_TIMEOUT * RESPONSE_RANDOM_FACTOR * (2 ^ MAX_RETRANSMIT -
> >    1) plus the expected maximum round trip time.
> >=20
> > Question 1: Given that these parameters are not mandated by the standar=
d,
> > does the spec assume that will be available some way to synchronize
> > those parameters across different implementations to correctly avoid
> > reusing a MID in the retransmission window?
>=20
> We say this is out of scope in section 9.

OK. But this might then be good to have somewhere else, e.g. IPSO profile.

> 	The values for RESPONSE_TIMEOUT, RESPONSE_RANDOM_FACTOR, and
> MAX_RETRANSMIT may be configured to values specific to the application
> environment, however the configuration method is out of scope of this
> document. It is recommended that an application environment use consistent
> values for these parameters.
>=20
> I expect we will come up with a way to do this in the area of discovery a=
nd
> auto configuration.

Ignoring the retransmission window aspect of this and focussing on the=20
discovery of the pure parameters, so that the client can adapt its behaviou=
r=20
to the server's setting, e.g. to RESPONSE_TIMEOUT. It is gonna be likely th=
at=20
the server has more knowledge about itself and the environment close to it,=
=20
than a client far away, but the client should 'behave' to the server's=20
constraints.

So it might make sense to add something along the following lines to e.g. t=
he=20
Device Function Set of the IPSO profile then.

CoAP protocol constant RESPONSE_TIMEOUT=09
/dev/cpt
ipso:dev-cpt
core#p,core#rp
xsd:decimal

CoAP protocol constant RESPONSE_RANDOM_FACTOR
/dev/cpf
ipso:dev-cpf
core#p,core#rp
xsd:decimal

CoAP protocol constant MAX_RETRANSMIT
/dev/cpr
ipso:dev-cpr
core#p,core#rp
xsd:integer

> Maybe we should add text about a default "potential
> retransmission window", e.g. 256 s.
>=20
> > Later on there is the following text:
> >    A recipient MUST be prepared to receive the same confirmable message
> >    (as indicated by the Message ID and additional address information of
> >    the corresponding end-point as described in
> >=20
> > Section 4.3
> > ) multiple
> >=20
> >    times, for example, when its acknowledgement went missing or didn't
> >    reach the original sender before the first timeout.  The recipient
> >=20
> > Question 2: Should be specified that "the recipient MUST be prepared to
> > receive the same confirmable message *within the potential
> > retransmission window*" as well?
>=20
> Now ticket #201.
>=20
> Gr=FC=DFe, Carsten
>=20
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

From likepeng@huawei.com  Thu Mar 29 02:10:07 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C27221F89FD for ; Thu, 29 Mar 2012 02:10:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.605
X-Spam-Level: *
X-Spam-Status: No, score=1.605 tagged_above=-999 required=5 tests=[AWL=-0.000,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6D9+Iymz4eKN for ; Thu, 29 Mar 2012 02:10:06 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 85D7A21F86D1 for ; Thu, 29 Mar 2012 02:10:06 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEU18212; Thu, 29 Mar 2012 05:10:06 -0400 (EDT)
Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 02:08:24 -0700
Received: from SZXEML435-HUB.china.huawei.com (10.72.61.63) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 02:08:21 -0700
Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.158]) by szxeml435-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 29 Mar 2012 17:08:01 +0800
From: Likepeng 
To: Jeroen Hoebeke , core WG 
Thread-Topic: [core] draft-ietf-core-block-08 - size request
Thread-Index: AQHNDR9QU22ca5D8fkCgnI/JgSxxfJaA9dnV
Date: Thu, 29 Mar 2012 09:08:00 +0000
Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F20331E0FF@szxeml525-mbs.china.huawei.com>
References: <5AE8C0D8-B82E-45D0-B015-A80C8DDBDBB5@intec.ugent.be>
In-Reply-To: <5AE8C0D8-B82E-45D0-B015-A80C8DDBDBB5@intec.ugent.be>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.24.1.46]
Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F20331E0FFszxeml525mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [core] draft-ietf-core-block-08 - size request
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 29 Mar 2012 09:10:07 -0000

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F20331E0FFszxeml525mbschi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGksDQoNCg0KDQo+SG93IGRvZXMgdGhlIHNlcnZlciBuZWVkIHRvIGJlaGF2ZSB1cG9uIHRoZSBy
ZWNlcHRpb24gb2YgYSBzaXplIHJlcXVlc3Q/DQo+LSgxKSBkb2VzIGl0IHNlbmQgYmFjayBhbiBl
bXB0eSByZXNwb25zZSB3aXRoIGEgc2l6ZSBvcHRpb24gdGhhdCBnaXZlcyB0aGUgc2l6ZSBlc3Rp
bWF0ZSBvZiB0aGUgcmVzcG9uc2U/IEluIHRoaXMgY2FzZSwgd2hhdCBpcyB0aGUgcmVzcG9uc2Ug
d2hlbiB0aGUgc2VydmVyIGRvZXMgbm90IHN1cHBvcnQgdGhpcyBvcHRpb24/DQo+b3INCj4tKDIp
IGRvZXMgaXQgc2VuZCBiYWNrIGEgcmVzcG9uc2Ugd2l0aCBhIHNpemUgb3B0aW9uIGdpdmluZyB0
aGUgc2l6ZSBlc3RpbWF0ZSBvZiB0aGUgcmVzcG9uc2UsIGJ1dCB3aXRoIGEgcGF5bG9hZCBhbHJl
YWR5IGNvbnRhaW5pbmcgdGhlIGZpcnN0IGJsb2NrPw0KDQoNCg0KV2UgY2FuIGRpZmZlcmVudGlh
dGUgdGhlc2UgdHdvIGNhc2VzIGJ5IGdpdmluZyB0aGUgU2l6ZSBhIHplcm8gdmFsdWUgb3Igbm90
LiBIZXJlIGlzIHRoZSB0ZXh0IGZyb20gQmxvY2sgZHJhZnQ6DQoNCg0KDQogICBvICBpbiBhIHJl
cXVlc3QsIHRvIGFzayB0aGUgc2VydmVyIHRvIHByb3ZpZGUgYSBzaXplIGVzdGltYXRlIGluIHRo
ZQ0KICAgICAgcmVzcG9uc2UgKCJzaXplIHJlcXVlc3QiKS4gIEZvciB0aGlzIHVzYWdlLCB0aGUg
dmFsdWUgTVVTVCBiZSBzZXQNCiAgICAgIHRvIDAuDQoNClNvLCBpZiBTaXplPTAsIHRoYXQgbWVh
bnMgY2FzZSAxLiBJZiBTaXplIG9wdGlvbiBpcyBlbXB0eSwgdGhhdCBtZWFucyBjYXNlIDIuDQoN
Cg0KDQo+SXQgd291bGQgYmUgZ29vZCB0byBhZGQgdGhlIGRlc2lyZWQgYmVoYXZpb3IgdG8gdGhl
IGRlc2NyaXB0aW9uIG9mIHRoZSBzaXplIHJlcXVlc3QgdG8gYXZvaWQgY29uZnVzaW9uLg0KDQpB
Z3JlZSwgd2Ugc2hvdWxkIGFkZCBzb21lIHRleHRzIHRvIGNsYXJpZnkgdGhlIHNpdHVhdGlvbi4g
SSBwcm9wb3NlIHRvIHRha2Ugc29tZSB0ZXh0cyAob3IgY2hhbmdlIGl0IGEgbGl0dGxlIGJpdCkg
ZnJvbSB0aGUgU2l6ZSBkcmFmdCB0byBCbG9jayBkcmFmdC4NCg0KDQoNCkhlcmUgaXMgdGhlIHRl
eHQgZnJvbSBkcmFmdC1saS1jb3JlLWNvYXAtc2l6ZS1vcHRpb24tMDIudHh0Og0KDQoNCg0KICAg
VGhlIEdFVCByZXF1ZXN0IGluY2x1ZGluZyBTaXplPTAgaXMgdHJlYXRlZCBhcyBhIHJlcXVlc3Qg
dG8gZ2V0IHRoZQ0KICAgc2l6ZSBvZiB0aGUgcmVzb3VyY2UgcmVwcmVzZW50YXRpb24gKGJ1dCBu
b3QgdGhlIHJlc291cmNlIHBheWxvYWQpLg0KDQogICBUaGUgR0VUIHJlcXVlc3QgaW5jbHVkaW5n
IGFuIGVtcHR5IFNpemUgb3B0aW9uIGlzIHRyZWF0ZWQgYXMgYQ0KICAgcmVxdWVzdCB0byBnZXQg
dGhlIHNpemUgb2YgdGhlIHJlc291cmNlIHJlcHJlc2VudGF0aW9uIHdpdGggdGhlDQogICByZXNv
dXJjZSBwYXlsb2FkLg0KDQogICBUaGUgU2l6ZSBvcHRpb24gU0hPVUxEIGJlIGluY2x1ZGVkIGZv
ciByZXNvdXJjZXMgbGFyZ2VyIHRoYW4gYSBzaW5nbGUNCiAgIFBEVSwgaWYgdGhlIFNpemUgaW5m
b3JtYXRpb24gaXMgYXZhaWxhYmxlLiAgQW5kIGl0IE1BWSBiZSBpbmNsdWRlZA0KICAgZm9yIHJl
c291cmNlcyBzbWFsbGVyIHRoYW4gYSBzaW5nbGUgTVRVLg0KDQoNCg0KICAgVGhlIFNpemUgb3B0
aW9uIFNIT1VMRCBiZSB1c2VkIGluIGEgUE9TVC9QVVQgcmVxdWVzdCBpbiB0aGUgZmlyc3QNCiAg
IEJsb2NrMSBPcHRpb24gbWVzc2FnZS4gIElmIHRoZSByZWNpcGllbnQgaXMgbm90IGNhcGFibGUg
dG8gcmVjZWl2ZSB0aGUNCiAgIGRhdGEgd2l0aCB0aGUgaW5kaWNhdGVkIHNpemUsIHRoZSByZWNp
cGllbnQgTVVTVCByZXR1cm4gYSA0LjEzDQogICAoUmVxdWVzdCBFbnRpdHkgVG9vIExhcmdlKSBy
ZXNwb25zZSBjb2RlIHRvIHRoZSByZXF1ZXN0ZXIsIGFuZCB0aGUNCiAgIGRhdGEgdHJhbnNtaXNz
aW9uIGlzIGF2b2lkZWQsIHNvIHRoYXQgdGhlIGNvc3Qgb2YgdGhlIGFjdHVhbCBkYXRhDQogICB0
cmFuc21pc3Npb24gaXMgc2F2ZWQuDQoNCiAgIEZvciBhIEdFVCByZXF1ZXN0IHdpdGggQmxvY2sy
LCBpZiBpdCBpbmNsdWRlcyBhbiBlbXB0eSBTaXplIG9wdGlvbiwgdGhlIFNpemUNCiAgIG9wdGlv
biBNVVNUIGJlIGluY2x1ZGVkIGluIHRoZSByZXNwb25zZS4gIElmIHRoZSBHRVQgcmVxdWVzdCBp
bmNsdWRlcw0KICAgYSBCbG9jazIgb3B0aW9uLCB0aGUgU2l6ZSBvcHRpb24gU0hPVUxEIGJlIGlu
Y2x1ZGVkIGluIHRoZSBmaXJzdCBCbG9jazINCiAgIHJlc3BvbnNlLiAgSW4gb3RoZXIgY2FzZXMg
dGhlIEdFVCByZXNwb25zZSBNQVkgY29udGFpbiBhIFNpemUgb3B0aW9uLg0KDQpLaW5kIFJlZ2Fy
ZHMNCg0KS2VwZW5nDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8
/sjLOiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW2NvcmUtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBK
ZXJvZW4gSG9lYmVrZSBbamVyb2VuLmhvZWJla2VAaW50ZWMudWdlbnQuYmVdDQq3osvNyrG85Dog
MjAxMsTqM9TCMjnI1SA0OjEzDQq1vTogY29yZSBXRw0K1vfM4jogW2NvcmVdIGRyYWZ0LWlldGYt
Y29yZS1ibG9jay0wOCAtIHNpemUgcmVxdWVzdA0KDQpEZWFyIFdHLA0KDQpBZnRlciBnaXZpbmcg
dGhlIGJsb2NrIGRyYWZ0IGEgZmluYWwgcmVhZGluZywgSSBkaXNjb3ZlcmVkIG9uZSBtaW5vciBp
c3N1ZSB0aGF0IGlzIG5vdCBjbGVhciB0byBtZToNCg0KSG93IGRvZXMgdGhlIHNlcnZlciBuZWVk
IHRvIGJlaGF2ZSB1cG9uIHRoZSByZWNlcHRpb24gb2YgYSBzaXplIHJlcXVlc3Q/DQotIGRvZXMg
aXQgc2VuZCBiYWNrIGFuIGVtcHR5IHJlc3BvbnNlIHdpdGggYSBzaXplIG9wdGlvbiB0aGF0IGdp
dmVzIHRoZSBzaXplIGVzdGltYXRlIG9mIHRoZSByZXNwb25zZT8gSW4gdGhpcyBjYXNlLCB3aGF0
IGlzIHRoZSByZXNwb25zZSB3aGVuIHRoZSBzZXJ2ZXIgZG9lcyBub3Qgc3VwcG9ydCB0aGlzIG9w
dGlvbj8NCm9yDQotIGRvZXMgaXQgc2VuZCBiYWNrIGEgcmVzcG9uc2Ugd2l0aCBhIHNpemUgb3B0
aW9uIGdpdmluZyB0aGUgc2l6ZSBlc3RpbWF0ZSBvZiB0aGUgcmVzcG9uc2UsIGJ1dCB3aXRoIGEg
cGF5bG9hZCBhbHJlYWR5IGNvbnRhaW5pbmcgdGhlIGZpcnN0IGJsb2NrPw0KDQpJdCB3b3VsZCBi
ZSBnb29kIHRvIGFkZCB0aGUgZGVzaXJlZCBiZWhhdmlvciB0byB0aGUgZGVzY3JpcHRpb24gb2Yg
dGhlIHNpemUgcmVxdWVzdCB0byBhdm9pZCBjb25mdXNpb24uDQoNCktpbmQgcmVnYXJkcywNCkpl
cm9lbg0K

--_000_34966E97BE8AD64EAE9D3D6E4DEE36F20331E0FFszxeml525mbschi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable










Hi,


 


>How does the server need to behave=
 upon the reception of a size request?


>-(1) does it send back an empty re=
sponse with a size option that gives the size estimate of the response? In =
this case, what is the response when the server does not support this optio=
n?


>or


>-(2) does it send back a response =
with a size option giving the size estimate of the response, but with =
a payload already containing the first block?


 


We can differentiate these two cases by giving the Size a zero value or =
not. Here is the text from Block draft:


 


   o  in a request, to ask the server to provide a size e=
stimate in the

      response ("size request").  F=
or this usage, the value MUST be set

      to 0.



So, if Size=3D0, that means case 1. If Size option is empty, that means cas=
e 2.


 


>It would be good to add the desire=
d behavior to the description of the size request to avoid confusion.




Agree, we should add some texts to clarify the situation. I propose to=
 take some texts (or change it a little bit) from the Size draft to Block d=
raft.


 


Here is the text from draft-li-core-coap-size-option-02.txt:


 


   The GET request including Size=3D0 is treated as a request =
to get the

   size of the resource representation (but not the resource payl=
oad).



   The GET request including an empty Size option is treated as a=


   request to get the size of the resource representation with th=
e

   resource payload.



   The Size option SHOULD be included for resources larger than a=
 single

   PDU, if the Size information is available.  And it MAY be=
 included

   for resources smaller than a single MTU.


 


   The Size option SHOULD be used in a POST/PUT request in the=
 first

   Block1 Option message.  If the recipient is not capable t=
o receive the

   data with the indicated size, the recipient MUST return a 4.13=


   (Request Entity Too Large) response code to the requester, and=
 the

   data transmission is avoided, so that the cost of the actual d=
ata

   transmission is saved.



   For a GET request with Block2, if it includes an empty Size op=
tion, the Size

   option MUST be included in the response.  If the GET requ=
est includes

   a Block2 option, the Size option SHOULD be included in the fir=
st Block2

   response.  In other cases the GET response MAY contain a =
Size option.




Kind Regards


Kepeng


 




=B7=A2=BC=FE=C8=CB: core-bounces@ietf.org =
[core-bounces@ietf.org] =B4=FA=B1=ED Jeroen Hoebeke [jeroen.hoebeke@intec.u=
gent.be]

=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA3=D4=C229=C8=D5 4:13

=B5=BD: core WG

=D6=F7=CC=E2: [core] draft-ietf-core-block-08 - size request








Dear WG,












After giving the block draft a final r=
eading, I discovered one minor issue that is not clear to me:







How does the server need to behave upo=
n the reception of a size request?


- does it send back an empty response =
with a size option that gives the size estimate of the response? In this ca=
se, what is the response when the server does not support this option?

or


- does it send back a response with&nb=
sp;a size option giving the size estimate of the response, but with a paylo=
ad already containing the first block?







It would be good to add the desired be=
havior to the description of the size request to avoid confusion.







Kind regards,


Jeroen
















--_000_34966E97BE8AD64EAE9D3D6E4DEE36F20331E0FFszxeml525mbschi_--

From cabo@tzi.org  Thu Mar 29 02:24:42 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B1321F89B1 for ; Thu, 29 Mar 2012 02:24:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.018
X-Spam-Level: 
X-Spam-Status: No, score=-105.018 tagged_above=-999 required=5 tests=[AWL=-1.219, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_CHARSET_FARAWAY=2.45, 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 I900d0kp6OvA for ; Thu, 29 Mar 2012 02:24:39 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 946C121F88AC for ; Thu, 29 Mar 2012 02:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2T9OFaH027095; Thu, 29 Mar 2012 11:24:15 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AD7D7C57; Thu, 29 Mar 2012 11:24:15 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=gb18030
From: Carsten Bormann 
In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F20331E0FF@szxeml525-mbs.china.huawei.com>
Date: Thu, 29 Mar 2012 11:24:15 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <04B801B6-1BCB-406B-BB9B-28745D6F8B56@tzi.org>
References: <5AE8C0D8-B82E-45D0-B015-A80C8DDBDBB5@intec.ugent.be> <34966E97BE8AD64EAE9D3D6E4DEE36F20331E0FF@szxeml525-mbs.china.huawei.com>
To: Likepeng 
X-Mailer: Apple Mail (2.1257)
Cc: core WG 
Subject: Re: [core] draft-ietf-core-block-08 - size request
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 29 Mar 2012 09:24:42 -0000

On Mar 29, 2012, at 11:08, Likepeng wrote:

> So, if Size=3D0, that means case 1. If Size option is empty, that =
means case 2.

Size is a uint.  Empty is zero.

Gr=A8=B9=810=898e, Carsten


From cabo@tzi.org  Thu Mar 29 02:39:57 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BFD21F8915 for ; Thu, 29 Mar 2012 02:39:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.196
X-Spam-Level: 
X-Spam-Status: No, score=-106.196 tagged_above=-999 required=5 tests=[AWL=0.053, 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 L7jjVc8lcCF3 for ; Thu, 29 Mar 2012 02:39: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 ACE0221F87F2 for ; Thu, 29 Mar 2012 02:39:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2T9dnH4003992; Thu, 29 Mar 2012 11:39:49 +0200 (CEST)
Received: from dhcp-9069.meeting.ietf.org (dhcp-9069.meeting.ietf.org [130.129.8.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2DA6DC77; Thu, 29 Mar 2012 11:39:49 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann 
In-Reply-To: <5AE8C0D8-B82E-45D0-B015-A80C8DDBDBB5@intec.ugent.be>
Date: Thu, 29 Mar 2012 11:39:48 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5AE8C0D8-B82E-45D0-B015-A80C8DDBDBB5@intec.ugent.be>
To: Jeroen Hoebeke 
X-Mailer: Apple Mail (2.1257)
Cc: core WG 
Subject: Re: [core] draft-ietf-core-block-08 - size request
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 29 Mar 2012 09:39:58 -0000

On Mar 28, 2012, at 22:13, Jeroen Hoebeke wrote:

> Dear WG,
>=20
> After giving the block draft a final reading, I discovered one minor =
issue that is not clear to me:
>=20
> How does the server need to behave upon the reception of a size =
request?
> - does it send back an empty response with a size option that gives =
the size estimate of the response?

No.  Is there text that suggests that?

> In this case, what is the response when the server does not support =
this option?

It is elective, so in this case, the result is exactly as if it had not =
been sent.

> - does it send back a response with a size option giving the size =
estimate of the response, but with a payload already containing the =
first block?

Yes.

If you want to keep this small, use a block size of 16 (szx =3D 0).

> It would be good to add the desired behavior to the description of the =
size request to avoid confusion.

Do you have a proposed text change?
Maybe we can add something like:

# Apart from conveying/asking for size information, the Size option has =
no other effect on the processing of the request or response.

Gr=FC=DFe, Carsten



From jeroen.hoebeke@intec.ugent.be  Thu Mar 29 03:59:51 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E475721F8907 for ; Thu, 29 Mar 2012 03:59:51 -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 jNhXLY+mn325 for ; Thu, 29 Mar 2012 03:59:50 -0700 (PDT)
Received: from smtp2.UGent.be (smtp2.ugent.be [157.193.49.126]) by ietfa.amsl.com (Postfix) with ESMTP id B3BCA21F8903 for ; Thu, 29 Mar 2012 03:59:50 -0700 (PDT)
Received: from localhost (mcheck5.ugent.be [157.193.49.247]) by smtp2.UGent.be (Postfix) with ESMTP id AAE2944A55C; Thu, 29 Mar 2012 12:59:49 +0200 (CEST)
X-Virus-Scanned: by UGent DICT
Received: from smtp2.UGent.be ([157.193.49.126]) by localhost (mcheck5.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id h7O37hB88kSc; Thu, 29 Mar 2012 12:59:49 +0200 (CEST)
Received: from dhcp-10d3.meeting.ietf.org (dhcp-10d3.meeting.ietf.org [130.129.16.211]) (Authenticated sender: jjhoebek) by smtp2.UGent.be (Postfix) with ESMTPSA id 38CBF44A551; Thu, 29 Mar 2012 12:59:49 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Jeroen Hoebeke 
In-Reply-To: 
Date: Thu, 29 Mar 2012 12:59:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5AE8C0D8-B82E-45D0-B015-A80C8DDBDBB5@intec.ugent.be> 
To: Carsten Bormann 
X-Mailer: Apple Mail (2.1257)
X-Miltered: at mcheck3 with ID 4F7440A4.007 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)!
X-j-chkmail-Enveloppe: 4F7440A4.007/130.129.16.211/dhcp-10d3.meeting.ietf.org/dhcp-10d3.meeting.ietf.org/
X-j-chkmail-Score: MSGID : 4F7440A4.007 on smtp2.UGent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Cc: core WG 
Subject: Re: [core] draft-ietf-core-block-08 - size request
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 29 Mar 2012 10:59:52 -0000

Hi Carsten,

>> - does it send back an empty response with a size option that gives =
the size estimate of the response?
>=20
> No.  Is there text that suggests that?

Only the name 'size request' and absence of further clarification in the =
text, made me think it could mean a pure size request, resulting in a =
response without payload and with size option.
>=20
>> It would be good to add the desired behavior to the description of =
the size request to avoid confusion.
>=20
> Do you have a proposed text change?
> Maybe we can add something like:
>=20
> # Apart from conveying/asking for size information, the Size option =
has no other effect on the processing of the request or response.

This is clear. Maybe also add:
If the clients wants to minimize the size of the payload in the =
resulting response, it should add a Block2 option to the request with a =
small block size.

Kind regards,
Jeroen


From trac+core@trac.tools.ietf.org  Thu Mar 29 04:09:35 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2A321F887E for ; Thu, 29 Mar 2012 04:09:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.589
X-Spam-Level: 
X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 ZraFiahAiY-N for ; Thu, 29 Mar 2012 04:09:34 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6F59621F8810 for ; Thu, 29 Mar 2012 04:09:34 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SDDED-0008HX-KN; Thu, 29 Mar 2012 07:09:17 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "core issue tracker" 
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org
X-Trac-Project: core
Date: Thu, 29 Mar 2012 11:09:16 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/205
Message-ID: <051.9b5708494f8201a3ec752fc23da47723@trac.tools.ietf.org>
X-Trac-Ticket-ID: 205
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: 
Resent-Message-Id: <20120329110934.6F59621F8810@ietfa.amsl.com>
Resent-Date: Thu, 29 Mar 2012 04:09:34 -0700 (PDT)
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: [core] #205: Clarify that Size does not modify the request semantics beyond adding the size information
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, 29 Mar 2012 11:09:35 -0000

#205: Clarify that Size does not modify the request semantics beyond adding the
size information

 Jeroen Hoebeke noticed that the term "size request" might be misunderstood
 as "just a size request".

 Proposed text to add to sec 3:

 # Apart from conveying/asking for size information, the Size option has no
 other effect on the processing of the request or response.
 # If the client wants to minimize the size of the payload in the resulting
 response, it should add a Block2 option to the request with a small block
 size (e.g., setting SZX=0).

-- 
-----------------------------+-------------------------------------
 Reporter:  cabo@…           |      Owner:  draft-ietf-core-block@…
     Type:  editorial        |     Status:  new
 Priority:  minor            |  Milestone:
Component:  block            |    Version:
 Severity:  In WG Last Call  |   Keywords:
-----------------------------+-------------------------------------

Ticket URL: 
core 


From jara@um.es  Thu Mar 29 04:34:05 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13CA21F8985 for ; Thu, 29 Mar 2012 04:34:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.818
X-Spam-Level: 
X-Spam-Status: No, score=-3.818 tagged_above=-999 required=5 tests=[AWL=-0.841, 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 ybHStYUwGJj0 for ; Thu, 29 Mar 2012 04:34:04 -0700 (PDT)
Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEC621F88D0 for ; Thu, 29 Mar 2012 04:34:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 8841A5D47E for ; Thu, 29 Mar 2012 13:34:02 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon13.um.es
Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WOz6X79y6O90 for ; Thu, 29 Mar 2012 13:34:02 +0200 (CEST)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jara) by xenon13.um.es (Postfix) with ESMTPSA id 70A915D4CE for ; Thu, 29 Mar 2012 13:33:58 +0200 (CEST)
Received: by vbbez10 with SMTP id ez10so1603936vbb.31 for ; Thu, 29 Mar 2012 04:33:57 -0700 (PDT)
Received: by 10.220.140.200 with SMTP id j8mr15930771vcu.17.1333020837294; Thu, 29 Mar 2012 04:33:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.192.138 with HTTP; Thu, 29 Mar 2012 04:33:17 -0700 (PDT)
From: Antonio Jara 
Date: Thu, 29 Mar 2012 13:33:17 +0200
Message-ID: 
To: core@ietf.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: [core] draft-li-core-conditional-observe-01 - Another type of conditional (for out of range)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Mar 2012 11:34:06 -0000

Dear all,

Just to comment  that recently we have required an additional kind of
conditional for our implementation. Therefore, I suggest the following
changes after our experience with this draft.

TYPES
We suggest that in addition to the current ones (for single values):
1- minimum response time
2- maximum response time
3- step
4- range
5- periodic

We should add the types for multiples values:
6- Inside of range
7- out of range

METHOD - M field
This indicates the method being used. This field is represented by a
2-bit integer, indicating the method used in the condition as shown in
the next table.
0- Equal to (=3D)=09
1- More than (>)=09
2- Less than (<)

We should add the method multiple:
3- MULTIPLE

Note that if multiple conditions with the same condition type are
present in the same request, the priority is the same for all of them,
and the relationship is =93AND=94.

One example could be check if a value is inside the range in order to
launch an alarm implementation, where the client adds two different
range Condition options, one set to 3/2/10, and the other set to
3/1/1, meaning that the server will only notify when the temperature
value monitored is below 10 =BAC (3/2/10), or above 1 =BAC (3/1/1), i.e. 1
< value < 10.

However, it could be more interesting to receive notifications just
when an out of range alarm occurs, instead of sending successive
confirmations for a normal operation of the system when the
temperature is varying inside the range defined. In this case, and due
to the definition of the Condition options, the only way for inquire
this type of notifications is using two Condition options, instead of
just one in order to define a out of range alarm notification. The
next figure describes this possibility where the range of interest is
the same as described above but notifications are only sent when the
temperature values are above 10 =BAC (3/1/10) or below 1=BAC (3/2/1).

This requires two messages, see picture:
http://imageshack.us/photo/my-images/706/outofrangecurrent.png/

Therefore, a new definition for TYPE out of range and METHOD multiple,
where it can be defined two VALUES instead of one.

Since the VAL field has three different sizes, it could be considered
to add also a 2 bits field in order to indicate the size. Thereby, it
is reached a 1 bytes initial option without the value.

TYPE - 4 bits
METHOD - 2 bits
SIZE - 2 bits

Then, SIZE value (S)
0- 1 byte
1- 2 bytes
2- 2 values of 1 byte
3- 2 values of 2 bytes

Thereby, it is more deterministic that a so "flexible" 1 to 3 bytes
option which could bring problems in the processing.

In addition, with the capability to define 2 values instead of only
one, it will simpler to build the methods MULTIPLE, and for the
special TYPES of range more complex than < or > to inside or outside
the range, which is highly value for alarms.

In conclusion, with these changes we can made more deterministic the
size of the conditional option, and reduce the number of messages for
ranges conditions (from 2 to 1 for usual cases such as ranges for
alarms).

Best regards and thanks,
Antonio J. Jara

From cabo@tzi.org  Thu Mar 29 06:01:41 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A977C21F8B16 for ; Thu, 29 Mar 2012 06:01:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.144
X-Spam-Level: 
X-Spam-Status: No, score=-106.144 tagged_above=-999 required=5 tests=[AWL=0.105, 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 8okXjfn4Wzz4 for ; Thu, 29 Mar 2012 06:01:41 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E553021F8A29 for ; Thu, 29 Mar 2012 06:01:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2TD1Xfw014828 for ; Thu, 29 Mar 2012 15:01:33 +0200 (CEST)
Received: from pptp-218-1.informatik.uni-bremen.de (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9B24DDF9; Thu, 29 Mar 2012 15:01:33 +0200 (CEST)
From: Carsten Bormann 
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Thu, 29 Mar 2012 15:01:33 +0200
To: core WG 
Message-Id: <2DBB2BEF-BE0E-4282-A14D-A71F913A990C@tzi.org>
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
Subject: [core] Agenda and slides for tomorrow = Friday
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 29 Mar 2012 13:01:41 -0000

I have uploaded slightly adjusted agenda and slides for tomorrow.
I have tried to make some room for continuing the WGLC discussion that =
we had on Tuesday, based on the tickets that we already made.

Presenters: Please check again that your slides are in and your slots =
are as required.

Gr=FC=DFe, Carsten


From lishitao@huawei.com  Thu Mar 29 06:28:43 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3353E21F8ABB for ; Thu, 29 Mar 2012 06:28:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.147
X-Spam-Level: 
X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZdMxKbES2kH for ; Thu, 29 Mar 2012 06:28:42 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 00F1821F8A9B for ; Thu, 29 Mar 2012 06:28:41 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEM29175; Thu, 29 Mar 2012 09:28:41 -0400 (EDT)
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 06:26:36 -0700
Received: from SZXEML439-HUB.china.huawei.com (10.72.61.74) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 06:26:41 -0700
Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.30]) by szxeml439-hub.china.huawei.com ([10.72.61.74]) with mapi id 14.01.0323.003; Thu, 29 Mar 2012 21:26:37 +0800
From: Li Shitao 
To: Antonio Jara , "core@ietf.org" 
Thread-Topic: draft-li-core-conditional-observe-01 - Another type of conditional (for out of range)
Thread-Index: AQHNDZ/d8Pd3RoHQoEGIpl0suiNRL5aBQ3zo
Date: Thu, 29 Mar 2012 13:26:47 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.24.1.67]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [core] =?utf-8?b?562U5aSNOiBkcmFmdC1saS1jb3JlLWNvbmRpdGlvbmFsLW9i?= =?utf-8?q?serve-01_-_Another_type_of_conditional_=28for_out_of_range=29?=
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 29 Mar 2012 13:28:43 -0000

SGkgYW50b25pYSANCg0KSSB0aGluayB0aGUgcmVxdWlyZW1lbnQgaXMgcmVhc29uYWJsZSwgd2Ug
Y2FuIGRpc2N1c3MgdGhlIGRldGFpbCBpbiB0aGUgZnV0dXJlIHZlcnNpb24gb2YgdGhpcyBkcmFm
dA0KDQpyZWdhcmRzDQpzaGl0YW8NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCuWPkeS7tuS6ujogQW50b25pbyBKYXJhIFtqYXJhQHVtLmVzXQ0K5Y+R6YCB5pe26Ze0
OiAyMDEy5bm0M+aciDI55pelIDE5OjMzDQrliLA6IGNvcmVAaWV0Zi5vcmcNCkNjOiBMaSBTaGl0
YW87IEplcm9lbiBIb2ViZWtlDQrkuLvpopg6IGRyYWZ0LWxpLWNvcmUtY29uZGl0aW9uYWwtb2Jz
ZXJ2ZS0wMSAtIEFub3RoZXIgdHlwZSBvZiBjb25kaXRpb25hbCAoZm9yIG91dCBvZiByYW5nZSkN
Cg0KRGVhciBhbGwsDQoNCkp1c3QgdG8gY29tbWVudCAgdGhhdCByZWNlbnRseSB3ZSBoYXZlIHJl
cXVpcmVkIGFuIGFkZGl0aW9uYWwga2luZCBvZg0KY29uZGl0aW9uYWwgZm9yIG91ciBpbXBsZW1l
bnRhdGlvbi4gVGhlcmVmb3JlLCBJIHN1Z2dlc3QgdGhlIGZvbGxvd2luZw0KY2hhbmdlcyBhZnRl
ciBvdXIgZXhwZXJpZW5jZSB3aXRoIHRoaXMgZHJhZnQuDQoNClRZUEVTDQpXZSBzdWdnZXN0IHRo
YXQgaW4gYWRkaXRpb24gdG8gdGhlIGN1cnJlbnQgb25lcyAoZm9yIHNpbmdsZSB2YWx1ZXMpOg0K
MS0gbWluaW11bSByZXNwb25zZSB0aW1lDQoyLSBtYXhpbXVtIHJlc3BvbnNlIHRpbWUNCjMtIHN0
ZXANCjQtIHJhbmdlDQo1LSBwZXJpb2RpYw0KDQpXZSBzaG91bGQgYWRkIHRoZSB0eXBlcyBmb3Ig
bXVsdGlwbGVzIHZhbHVlczoNCjYtIEluc2lkZSBvZiByYW5nZQ0KNy0gb3V0IG9mIHJhbmdlDQoN
Ck1FVEhPRCAtIE0gZmllbGQNClRoaXMgaW5kaWNhdGVzIHRoZSBtZXRob2QgYmVpbmcgdXNlZC4g
VGhpcyBmaWVsZCBpcyByZXByZXNlbnRlZCBieSBhDQoyLWJpdCBpbnRlZ2VyLCBpbmRpY2F0aW5n
IHRoZSBtZXRob2QgdXNlZCBpbiB0aGUgY29uZGl0aW9uIGFzIHNob3duIGluDQp0aGUgbmV4dCB0
YWJsZS4NCjAtIEVxdWFsIHRvICg9KQ0KMS0gTW9yZSB0aGFuICg+KQ0KMi0gTGVzcyB0aGFuICg8
KQ0KDQpXZSBzaG91bGQgYWRkIHRoZSBtZXRob2QgbXVsdGlwbGU6DQozLSBNVUxUSVBMRQ0KDQpO
b3RlIHRoYXQgaWYgbXVsdGlwbGUgY29uZGl0aW9ucyB3aXRoIHRoZSBzYW1lIGNvbmRpdGlvbiB0
eXBlIGFyZQ0KcHJlc2VudCBpbiB0aGUgc2FtZSByZXF1ZXN0LCB0aGUgcHJpb3JpdHkgaXMgdGhl
IHNhbWUgZm9yIGFsbCBvZiB0aGVtLA0KYW5kIHRoZSByZWxhdGlvbnNoaXAgaXMg4oCcQU5E4oCd
Lg0KDQpPbmUgZXhhbXBsZSBjb3VsZCBiZSBjaGVjayBpZiBhIHZhbHVlIGlzIGluc2lkZSB0aGUg
cmFuZ2UgaW4gb3JkZXIgdG8NCmxhdW5jaCBhbiBhbGFybSBpbXBsZW1lbnRhdGlvbiwgd2hlcmUg
dGhlIGNsaWVudCBhZGRzIHR3byBkaWZmZXJlbnQNCnJhbmdlIENvbmRpdGlvbiBvcHRpb25zLCBv
bmUgc2V0IHRvIDMvMi8xMCwgYW5kIHRoZSBvdGhlciBzZXQgdG8NCjMvMS8xLCBtZWFuaW5nIHRo
YXQgdGhlIHNlcnZlciB3aWxsIG9ubHkgbm90aWZ5IHdoZW4gdGhlIHRlbXBlcmF0dXJlDQp2YWx1
ZSBtb25pdG9yZWQgaXMgYmVsb3cgMTAgwrpDICgzLzIvMTApLCBvciBhYm92ZSAxIMK6QyAoMy8x
LzEpLCBpLmUuIDENCjwgdmFsdWUgPCAxMC4NCg0KSG93ZXZlciwgaXQgY291bGQgYmUgbW9yZSBp
bnRlcmVzdGluZyB0byByZWNlaXZlIG5vdGlmaWNhdGlvbnMganVzdA0Kd2hlbiBhbiBvdXQgb2Yg
cmFuZ2UgYWxhcm0gb2NjdXJzLCBpbnN0ZWFkIG9mIHNlbmRpbmcgc3VjY2Vzc2l2ZQ0KY29uZmly
bWF0aW9ucyBmb3IgYSBub3JtYWwgb3BlcmF0aW9uIG9mIHRoZSBzeXN0ZW0gd2hlbiB0aGUNCnRl
bXBlcmF0dXJlIGlzIHZhcnlpbmcgaW5zaWRlIHRoZSByYW5nZSBkZWZpbmVkLiBJbiB0aGlzIGNh
c2UsIGFuZCBkdWUNCnRvIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBDb25kaXRpb24gb3B0aW9ucywg
dGhlIG9ubHkgd2F5IGZvciBpbnF1aXJlDQp0aGlzIHR5cGUgb2Ygbm90aWZpY2F0aW9ucyBpcyB1
c2luZyB0d28gQ29uZGl0aW9uIG9wdGlvbnMsIGluc3RlYWQgb2YNCmp1c3Qgb25lIGluIG9yZGVy
IHRvIGRlZmluZSBhIG91dCBvZiByYW5nZSBhbGFybSBub3RpZmljYXRpb24uIFRoZQ0KbmV4dCBm
aWd1cmUgZGVzY3JpYmVzIHRoaXMgcG9zc2liaWxpdHkgd2hlcmUgdGhlIHJhbmdlIG9mIGludGVy
ZXN0IGlzDQp0aGUgc2FtZSBhcyBkZXNjcmliZWQgYWJvdmUgYnV0IG5vdGlmaWNhdGlvbnMgYXJl
IG9ubHkgc2VudCB3aGVuIHRoZQ0KdGVtcGVyYXR1cmUgdmFsdWVzIGFyZSBhYm92ZSAxMCDCukMg
KDMvMS8xMCkgb3IgYmVsb3cgMcK6QyAoMy8yLzEpLg0KDQpUaGlzIHJlcXVpcmVzIHR3byBtZXNz
YWdlcywgc2VlIHBpY3R1cmU6DQpodHRwOi8vaW1hZ2VzaGFjay51cy9waG90by9teS1pbWFnZXMv
NzA2L291dG9mcmFuZ2VjdXJyZW50LnBuZy8NCg0KVGhlcmVmb3JlLCBhIG5ldyBkZWZpbml0aW9u
IGZvciBUWVBFIG91dCBvZiByYW5nZSBhbmQgTUVUSE9EIG11bHRpcGxlLA0Kd2hlcmUgaXQgY2Fu
IGJlIGRlZmluZWQgdHdvIFZBTFVFUyBpbnN0ZWFkIG9mIG9uZS4NCg0KU2luY2UgdGhlIFZBTCBm
aWVsZCBoYXMgdGhyZWUgZGlmZmVyZW50IHNpemVzLCBpdCBjb3VsZCBiZSBjb25zaWRlcmVkDQp0
byBhZGQgYWxzbyBhIDIgYml0cyBmaWVsZCBpbiBvcmRlciB0byBpbmRpY2F0ZSB0aGUgc2l6ZS4g
VGhlcmVieSwgaXQNCmlzIHJlYWNoZWQgYSAxIGJ5dGVzIGluaXRpYWwgb3B0aW9uIHdpdGhvdXQg
dGhlIHZhbHVlLg0KDQpUWVBFIC0gNCBiaXRzDQpNRVRIT0QgLSAyIGJpdHMNClNJWkUgLSAyIGJp
dHMNCg0KVGhlbiwgU0laRSB2YWx1ZSAoUykNCjAtIDEgYnl0ZQ0KMS0gMiBieXRlcw0KMi0gMiB2
YWx1ZXMgb2YgMSBieXRlDQozLSAyIHZhbHVlcyBvZiAyIGJ5dGVzDQoNClRoZXJlYnksIGl0IGlz
IG1vcmUgZGV0ZXJtaW5pc3RpYyB0aGF0IGEgc28gImZsZXhpYmxlIiAxIHRvIDMgYnl0ZXMNCm9w
dGlvbiB3aGljaCBjb3VsZCBicmluZyBwcm9ibGVtcyBpbiB0aGUgcHJvY2Vzc2luZy4NCg0KSW4g
YWRkaXRpb24sIHdpdGggdGhlIGNhcGFiaWxpdHkgdG8gZGVmaW5lIDIgdmFsdWVzIGluc3RlYWQg
b2Ygb25seQ0Kb25lLCBpdCB3aWxsIHNpbXBsZXIgdG8gYnVpbGQgdGhlIG1ldGhvZHMgTVVMVElQ
TEUsIGFuZCBmb3IgdGhlDQpzcGVjaWFsIFRZUEVTIG9mIHJhbmdlIG1vcmUgY29tcGxleCB0aGFu
IDwgb3IgPiB0byBpbnNpZGUgb3Igb3V0c2lkZQ0KdGhlIHJhbmdlLCB3aGljaCBpcyBoaWdobHkg
dmFsdWUgZm9yIGFsYXJtcy4NCg0KSW4gY29uY2x1c2lvbiwgd2l0aCB0aGVzZSBjaGFuZ2VzIHdl
IGNhbiBtYWRlIG1vcmUgZGV0ZXJtaW5pc3RpYyB0aGUNCnNpemUgb2YgdGhlIGNvbmRpdGlvbmFs
IG9wdGlvbiwgYW5kIHJlZHVjZSB0aGUgbnVtYmVyIG9mIG1lc3NhZ2VzIGZvcg0KcmFuZ2VzIGNv
bmRpdGlvbnMgKGZyb20gMiB0byAxIGZvciB1c3VhbCBjYXNlcyBzdWNoIGFzIHJhbmdlcyBmb3IN
CmFsYXJtcykuDQoNCkJlc3QgcmVnYXJkcyBhbmQgdGhhbmtzLA0KQW50b25pbyBKLiBKYXJhDQo=

From angelo.castellani@gmail.com  Thu Mar 29 10:04:03 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71F121F88D8 for ; Thu, 29 Mar 2012 10:04:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJZ1haBmVIw7 for ; Thu, 29 Mar 2012 10:04:03 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id F37D721F893F for ; Thu, 29 Mar 2012 10:04:02 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so1254296wgb.13 for ; Thu, 29 Mar 2012 10:04:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; bh=hB/+YQjxRv8fr+Fia5xnT5zxn5x609Tl5GnKeqx24Yw=; b=dS685mONpY5XVtU1CU+rFE7ycdNyl9GDdTQz2fHehEYu4FPvFGcmtrNt7YIBUENf6U FiZ1qeY6PAnNt9gCYkid89HOVUEWmZmy9TOcQ080jtZ7VT4BZZxdHdkawy/DGo57hK2Q 85A5TcMz0lBRQgqdcuvFrZ3sds0E0dJ/o4500ZqTicH29rUY5heUXQnZ0JUM69SxxDih oNb8LyDfWwbGHhT/CGH5cGN37uUMDEintTdtCWiXMH/heYI9iZJSrCB8FHwvUiwbK07y PCN0OOdoGRp0ha+wdsfKfUn8AYzroxdhmsq6ZdoEP4eyY247brtckZ7LqCgRg0pRYJUv nXAA==
Received: by 10.180.107.162 with SMTP id hd2mr7436518wib.8.1333040642158; Thu, 29 Mar 2012 10:04:02 -0700 (PDT)
MIME-Version: 1.0
Sender: angelo.castellani@gmail.com
Received: by 10.216.121.148 with HTTP; Thu, 29 Mar 2012 10:03:21 -0700 (PDT)
In-Reply-To: <20120329165959.13085.27704.idtracker@ietfa.amsl.com>
References: <20120329165959.13085.27704.idtracker@ietfa.amsl.com>
From: "Angelo P. Castellani" 
Date: Thu, 29 Mar 2012 19:03:21 +0200
X-Google-Sender-Auth: vs_rybt1C1a6sXHgzcX2_uHP-eg
Message-ID: 
To: core 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [core] Fwd: New Version Notification for draft-castellani-core-alive-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, 29 Mar 2012 17:04:04 -0000

Dear WG,

we have written a novel, very simple proposal to deal with sleeping
server nodes.

The solution propose the use of a new message indicating the current
availability of a CoAP server, sent immediately after wake up.

If you mind having a look, you find it here:
http://tools.ietf.org/html/draft-castellani-core-alive

Best,
Angelo & Salvatore


---------- Forwarded message ----------
From:  
Date: Thu, Mar 29, 2012 at 18:59
Subject: New Version Notification for draft-castellani-core-alive-00.txt
To: angelo@castellani.net
Cc: salvatore.loreto@ericsson.com


A new version of I-D, draft-castellani-core-alive-00.txt has been
successfully submitted by Angelo P. Castellani and posted to the IETF
repository.

Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-castellani-core-alive
Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CoAP Alive Message
Creation date: =C2=A0 2012-03-29
WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Number of pages: 6

Abstract:
=C2=A0 In the context of a Constrained RESTful Environment (CoRE), hosts
=C2=A0 could frequently be energy-constrained and be turned off the vast
=C2=A0 majority of time for energy-saving purposes.

=C2=A0 In the case of a CoAP server, while it is offline, it is neither
=C2=A0 available to serve requests. =C2=A0Clients desiring to access its
=C2=A0 resources have no way to understand when they will find it up again.

=C2=A0 This specification provides a simple new message that gives to a CoA=
P
=C2=A0 server the ability to signal its current availability in the network=
.




The IETF Secretariat

From prvs=5435968DC2=guido.moritz@uni-rostock.de  Thu Mar 29 10:23:49 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8110421F8787 for ; Thu, 29 Mar 2012 10:23:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.776
X-Spam-Level: 
X-Spam-Status: No, score=-2.776 tagged_above=-999 required=5 tests=[AWL=0.473,  BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Yz2K5rS3e+4H for ; Thu, 29 Mar 2012 10:23:18 -0700 (PDT)
Received: from mailrelay1.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9B121F87A2 for ; Thu, 29 Mar 2012 10:23:16 -0700 (PDT)
From: Guido Moritz 
To: "'Angelo P. Castellani'" , 'core' 
References: <20120329165959.13085.27704.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Date: Thu, 29 Mar 2012 19:23:13 +0200
Message-ID: <001701cd0dd0$9f49e070$dddda150$@uni-rostock.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHRakXmjonI28EUCLUQAD6657vsfwIab0DUlmf3LtA=
Content-Language: de
X-Originating-IP: [139.30.106.13]
Subject: Re: [core] Fwd: New Version Notification for	draft-castellani-core-alive-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, 29 Mar 2012 17:23:49 -0000

Angelo,

the first thoughts that come into my mind:

Couldn't this also be realized through using the existing observe, by =
modeling a dedicated observable resource as 'Alive' indicator. Clients =
can subscribe to the 'Alive' resource and may be get informed each time =
the node (1) wakes up and/or (2) the node is going into sleepy state.

Do you have a specific multicast address in mind to use, to not affect =
clients not interested in these notifications?=20

If the Alive signal would be multicast, there is no reliability. Might =
it be worse having also a reliable version of this signal (i.e. CON)? =
Isn't this in turn similar to using observe then?

Best,
Guido

> -----Urspr=C3=BCngliche Nachricht-----
> Von: core-bounces@ietf.org [mailto:core-bounces@ietf.org] Im Auftrag =
von
> Angelo P. Castellani
> Gesendet: Donnerstag, 29. M=C3=A4rz 2012 19:03
> An: core
> Betreff: [core] Fwd: New Version Notification for =
draft-castellani-core-alive-
> 00.txt
>=20
> Dear WG,
>=20
> we have written a novel, very simple proposal to deal with sleeping
> server nodes.
>=20
> The solution propose the use of a new message indicating the current
> availability of a CoAP server, sent immediately after wake up.
>=20
> If you mind having a look, you find it here:
> http://tools.ietf.org/html/draft-castellani-core-alive
>=20
> Best,
> Angelo & Salvatore
>=20
>=20
> ---------- Forwarded message ----------
> From:  
> Date: Thu, Mar 29, 2012 at 18:59
> Subject: New Version Notification for =
draft-castellani-core-alive-00.txt
> To: angelo@castellani.net
> Cc: salvatore.loreto@ericsson.com
>=20
>=20
> A new version of I-D, draft-castellani-core-alive-00.txt has been
> successfully submitted by Angelo P. Castellani and posted to the IETF
> repository.
>=20
> Filename:        draft-castellani-core-alive
> Revision:        00
> Title:           CoAP Alive Message
> Creation date:   2012-03-29
> WG ID:           Individual Submission
> Number of pages: 6
>=20
> Abstract:
>   In the context of a Constrained RESTful Environment (CoRE), hosts
>   could frequently be energy-constrained and be turned off the vast
>   majority of time for energy-saving purposes.
>=20
>   In the case of a CoAP server, while it is offline, it is neither
>   available to serve requests.  Clients desiring to access its
>   resources have no way to understand when they will find it up again.
>=20
>   This specification provides a simple new message that gives to a =
CoAP
>   server the ability to signal its current availability in the =
network.
>=20
>=20
>=20
>=20
> The IETF Secretariat
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core


From ietf@meetecho.com  Thu Mar 29 15:50:01 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA60A21F8559 for ; Thu, 29 Mar 2012 15:50:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdKKjycSMkfL for ; Thu, 29 Mar 2012 15:50:01 -0700 (PDT)
Received: from smtplq04.aruba.it (smtplqs-out26.aruba.it [62.149.158.66]) by ietfa.amsl.com (Postfix) with SMTP id B475621F84D5 for ; Thu, 29 Mar 2012 15:50:00 -0700 (PDT)
Received: (qmail 22578 invoked by uid 89); 29 Mar 2012 22:49:57 -0000
Received: from unknown (HELO smtp8.aruba.it) (62.149.158.228) by smtplq04.aruba.it with SMTP; 29 Mar 2012 22:49:57 -0000
Received: (qmail 5941 invoked by uid 89); 29 Mar 2012 22:49:57 -0000
Received: from unknown (HELO ?192.168.0.40?) (alex@meetecho.com@78.192.151.119) by smtp8.ad.aruba.it with ESMTPA; 29 Mar 2012 22:49:57 -0000
Message-ID: <4F74E70C.8010705@meetecho.com>
Date: Fri, 30 Mar 2012 00:49:48 +0200
From: Meetecho IETF support 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: core@ietf.org
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N
Cc: Team Meetecho 
Subject: [core] Meetecho support for CORE WG meeting session
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 29 Mar 2012 22:50:01 -0000

Hi all,

a virtual room has been reserved on the Meetecho system for Friday's 
CORE WG meeting session.

Access to the on-line session (including audio and video streams) will 
be available at:
http://www.meetecho.com/ietf83/core

The Meetecho session automatically logs you into the standard IETF 
jabber room. So, from there, you can have an integrated experience 
involving all media and allowing you to interact with the room.
Remote participants might also send their own voice to the room, if they 
want to, by either calling a landline phone number, or using our 
embedded VoIP applet (in this last case they are *strongly* advised to 
use a headset).

A tutorial of interactivity features of the tool can be found at:
http://www.meetecho.com/ietf83/tutorials

Cheers,
the Meetecho team

-- 
Meetecho s.r.l.
Web Conferencing and Collaboration Tools
www.meetecho.com

From angelo.castellani@gmail.com  Thu Mar 29 23:55:42 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232D321E809E for ; Thu, 29 Mar 2012 23:55:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDrDss181bXk for ; Thu, 29 Mar 2012 23:55:41 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1852E21E8094 for ; Thu, 29 Mar 2012 23:55:39 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so179168wgb.13 for ; Thu, 29 Mar 2012 23:55:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=RBhBbanJ4L8FxsGEpdnCk4d/sF0VwhNR3/3IFlYnB4U=; b=PHEaUG4Kct56ZiIiPWY/xxU2jIrY/Nj8KWIf4Bcy6NtuAOE+DP5sgwL1vNPlTb79cY h6zK0dQ608dNc/mRnOqnP3K1Ofvm48oHKukv0r4AeE8drJXVAEvxu4IQVrdgCOZWgyAZ GQWb0lpJliM7Hha20B02NemACWB8neED6f/U4K/uo5uCb4YuyRfSQsNKYSF/7S2EKfXE gQaxKDc22Vsfh9IxHPYz6B4ed87JGfMMwZZMdfCNqnAEktOHvJ2oGGNubPwGc48jWWpS pinp+L6TdN6UbXeuTt485IWRYbS0Z6eUQ3ByNQjrpOHm90kc4+RsiGa3L+SlA2W950Nd DxLg==
Received: by 10.180.73.143 with SMTP id l15mr3358760wiv.11.1333090539073; Thu, 29 Mar 2012 23:55:39 -0700 (PDT)
MIME-Version: 1.0
Sender: angelo.castellani@gmail.com
Received: by 10.216.121.148 with HTTP; Thu, 29 Mar 2012 23:54:58 -0700 (PDT)
In-Reply-To: <001701cd0dd0$9f49e070$dddda150$@uni-rostock.de>
References: <20120329165959.13085.27704.idtracker@ietfa.amsl.com>  <001701cd0dd0$9f49e070$dddda150$@uni-rostock.de>
From: "Angelo P. Castellani" 
Date: Fri, 30 Mar 2012 08:54:58 +0200
X-Google-Sender-Auth: N88okum-CclSokc-DzEc00fqmTo
Message-ID: 
To: Guido Moritz 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: core 
Subject: Re: [core] Fwd: New Version Notification for draft-castellani-core-alive-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, 30 Mar 2012 06:55:42 -0000

Thanks Guido for your very interesting comments.

On Thu, Mar 29, 2012 at 19:23, Guido Moritz  w=
rote:
> Couldn't this also be realized through using the existing observe, by mod=
eling a dedicated observable resource as 'Alive' indicator. Clients can sub=
scribe to the 'Alive' resource and may be get informed each time the node (=
1) wakes up and/or (2) the node is going into sleepy state.

It's a very good point yours actually, however the use case I am
targeting is different.

Probably you should have a look at this "Observer model" discussion:
http://tools.ietf.org/html/draft-arkko-core-sleepy-sensors-01#section-4.2.3

The alive message is targeting to address this initial establishment
problem pointed out by Jari.

> Do you have a specific multicast address in mind to use, to not affect cl=
ients not interested in these notifications?

Yes probably these notifications should be definitely sent to a
specific multicast address, or to a specific proxy anycast address.

> If the Alive signal would be multicast, there is no reliability. Might it=
 be worse having also a reliable version of this signal (i.e. CON)? Isn't t=
his in turn similar to using observe then?

As said before, the problem is that you have to be able to get this
sensor awake, in order to successfully observe that kind of resource.

There is also another problem, using Observe it costs you two messages
(and the "going to sleep" is really not useful at all), whereas the
"Alive" message uses a single one thanks to its special semantics.

Best,
Angelo

From stpeter@stpeter.im  Fri Mar 30 00:54:23 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BFC21F87FF for ; Fri, 30 Mar 2012 00:54:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.739
X-Spam-Level: 
X-Spam-Status: No, score=-102.739 tagged_above=-999 required=5 tests=[AWL=-0.140, 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 yaXMElmc4HNI for ; Fri, 30 Mar 2012 00:54:23 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EA4A821F8800 for ; Fri, 30 Mar 2012 00:54:22 -0700 (PDT)
Received: from dhcp-153f.meeting.ietf.org (unknown [64.103.25.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B03184005B for ; Fri, 30 Mar 2012 02:07:34 -0600 (MDT)
Message-ID: <4F7566AC.3050309@stpeter.im>
Date: Fri, 30 Mar 2012 09:54:20 +0200
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120313 Thunderbird/11.0
MIME-Version: 1.0
To: core WG 
X-Enigmail-Version: 1.4
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [core] service names in draft-lynn-core-discovery-mapping-01
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Mar 2012 07:54:23 -0000

Service names like this are wrong:

_lamp._sub._dali

You can't include underscores in the Service names. Please see RFC 2782.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From ari.keranen@nomadiclab.com  Fri Mar 30 00:57:04 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B0621F880E for ; Fri, 30 Mar 2012 00:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.732
X-Spam-Level: 
X-Spam-Status: No, score=-2.732 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 6cObFxmzA4xi for ; Fri, 30 Mar 2012 00:57:03 -0700 (PDT)
Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 71C7E21F8802 for ; Fri, 30 Mar 2012 00:57:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 35DDC4E6E4 for ; Fri, 30 Mar 2012 10:57:02 +0300 (EEST)
X-Virus-Scanned: amavisd-new at nomadiclab.com
Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8deRaEzwO8hZ for ; Fri, 30 Mar 2012 10:57:01 +0300 (EEST)
Received: from dhcp-6227.meeting.ietf.org (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTPSA id 8ACD74E679 for ; Fri, 30 Mar 2012 10:57:01 +0300 (EEST)
Message-ID: <4F75674E.8020404@nomadiclab.com>
Date: Fri, 30 Mar 2012 09:57:02 +0200
From: Ari Keranen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1
MIME-Version: 1.0
To: core@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [core] Identifier format for 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: Fri, 30 Mar 2012 07:57:04 -0000

Hi all,

Here's the draft about the identifier format that we could use with 
CoAP: http://tools.ietf.org/html/draft-farrell-decade-ni-01


Cheers,
Ari

From angelo.castellani@gmail.com  Fri Mar 30 01:10:39 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3EC21F871B for ; Fri, 30 Mar 2012 01:10:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuzyBVCtfD92 for ; Fri, 30 Mar 2012 01:10:38 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4321321F877E for ; Fri, 30 Mar 2012 01:10:37 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so217120wgb.13 for ; Fri, 30 Mar 2012 01:10:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=YPp+Pn3uT8hnOm075Vbeqjr910shqREtxVlyWcUUiM8=; b=bIQUUwl9YjaoBE3OUOcnvgXBKHdTVv/oWfM2Abo6iRJwGyO8nC5cFy/gVmBWE/JNCR BVWHjdxBBd/JsOuSqD9Hxaxz3ROqFvdWvH6QSrbs8HY1yhZe9v+WJLmQpI43L2PFTNJM RVIm1oNYzDR3W9lGejwvV7zso48Zux2fG+kVd2UXmrAbZyH3XLIEmjVDKFhOtXCfCiSr Y94C5Z/8ReOTveTtK3PgOu6MGtuhD+GHxLFaEA1xGypuTSWJ5FBOMnCzRQw4+5LCfo07 qgJR8QDaHxvCIzgGAp/GLCXmaCQmH4+crJK9164m3u/s1aJxJ4I4VtPcZbuUXTUt3xAd oXaA==
Received: by 10.180.103.134 with SMTP id fw6mr7630891wib.0.1333095036258; Fri, 30 Mar 2012 01:10:36 -0700 (PDT)
MIME-Version: 1.0
Sender: angelo.castellani@gmail.com
Received: by 10.216.121.148 with HTTP; Fri, 30 Mar 2012 01:09:55 -0700 (PDT)
From: "Angelo P. Castellani" 
Date: Fri, 30 Mar 2012 10:09:55 +0200
X-Google-Sender-Auth: FMUq_kvSTkQAwBRX55x2GhNlVTM
Message-ID: 
To: core 
Content-Type: multipart/alternative; boundary=f46d0443044216884a04bc716066
Subject: [core] comments on draft-li-core-conditional-observe-01
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Mar 2012 08:10:39 -0000

--f46d0443044216884a04bc716066
Content-Type: text/plain; charset=UTF-8

I think that the concept of conditional observe is interesting, and I
personally like to see that this work being explored here.

I had a look at the document, and I have two technical comments.

1) The following formats seem to be wrong:

              0
              0 1 2 3 4 5 6 7 8 9
             +-+-+-+-+-+-+-+-+-+-+
             | TYPE  | M | VAL   |
             +-+-+-+-+-+-+-+-+-+-+

              0                   1
              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             | TYPE  | M |          VAL          |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              0                   1                   2
              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             | TYPE  | M |          VAL                          |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The first one is 1 byte + 2 bits, the second one 2 bytes + 2 bits, and the
third one is 3 bytes + 2 bits.

You should probably reduce the VAL field by 2 bits in each case.

2) You should include the Condition option in the notification as well (at
least in the first), to make the client aware of the fact that you accepted
a Condition (for each condition you accepted).

Best,
Angelo

--f46d0443044216884a04bc716066
Content-Type: text/html; charset=UTF-8

I think that the concept of conditional observe is interesting, and I personally like to see that this work being explored here.

I had a look at the document, and I have two technical comments.

1) The following formats seem to be wrong:



              0
              0 1 2 3 4 5 6 7 8 9
             +-+-+-+-+-+-+-+-+-+-+
             | TYPE  | M | VAL   |
             +-+-+-+-+-+-+-+-+-+-+

              0                   1
              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             | TYPE  | M |          VAL          |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              0                   1                   2
              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             | TYPE  | M |          VAL                          |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The first one is 1 byte + 2 bits, the second one 2 bytes + 2 bits, and the third one is 3 bytes + 2 bits.

You should probably reduce the VAL field by 2 bits in each case.




2) You should include the Condition option in the notification as well (at least in the first), to make the client aware of the fact that you accepted a Condition (for each condition you accepted).




Best,
Angelo


--f46d0443044216884a04bc716066--

From kerlyn2001@gmail.com  Fri Mar 30 06:58:04 2012
Return-Path: 
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEEBE21F8652 for ; Fri, 30 Mar 2012 06:58:04 -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=1.225,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TT2yIeVnRg2w for ; Fri, 30 Mar 2012 06:58:04 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id F294021F84B4 for ; Fri, 30 Mar 2012 06:58:03 -0700 (PDT)
Received: by lagj5 with SMTP id j5so945604lag.31 for ; Fri, 30 Mar 2012 06:58:02 -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=oC3gGK15jI8ptdXqJe9pqCqAfAvfOIczeWfWXFexRFw=; b=GI9ufYqzKIx/T5NhIFY7FNCnhR3LlMCRsiu79XYrzVaNNObyPbmRcFLzV9K87Tuqvz MIcYuw1QKZY6rhB0ptruGJ2tgz5PTK+taweNmBzdC/nTPEdvlKwsQ4G26dQVKwmDNUWk iYzIW1wEQ532h+Cjh+MRCvo7FvYRduIEPkzMM5Zu2LMfaXNDpnYZkfYQ4EI0e5JGHaTn +VFSk5ieiR7mRZc/LGZu/3S4Dkat3JjhBtlSTBqFrCV9VpiEIYQE8gQDyZtk9j8HDb1I 03LvKVhWcrcVmDi9LjJQLQ3bglhsA3wpZ+FzqqOPaCMF8H5gGH4Emhz0JUc9Sd+Qb8HK Gjaw==
MIME-Version: 1.0
Received: by 10.152.131.66 with SMTP id ok2mr2577210lab.10.1333115882685; Fri, 30 Mar 2012 06:58:02 -0700 (PDT)
Received: by 10.112.77.179 with HTTP; Fri, 30 Mar 2012 06:58:02 -0700 (PDT)
In-Reply-To: <4F7566AC.3050309@stpeter.im>
References: <4F7566AC.3050309@stpeter.im>
Date: Fri, 30 Mar 2012 15:58:02 +0200
Message-ID: 
From: Kerry Lynn 
To: Peter Saint-Andre 
Content-Type: multipart/alternative; boundary=f46d042c6b83a1c31204bc763ae3
Cc: core WG 
Subject: Re: [core] service names in draft-lynn-core-discovery-mapping-01
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Mar 2012 13:58:05 -0000

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

Hi Peter,

We are basing this on RFC 6335, section 5.2 as well as the guidance
provided in http://tools.ietf.org/html/draft-cheshire-dnsext-dns-sd
sections 4.1.2 and 7.1.  What's not required is a leading underscore
for the subtype label, though many (including Apple) seem to have
adopted that convention.

Regards, -K-


On Fri, Mar 30, 2012 at 9:54 AM, Peter Saint-Andre wrote:

> Service names like this are wrong:
>
> _lamp._sub._dali
>
> You can't include underscores in the Service names. Please see RFC 2782.
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>

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

Hi Peter,

We are basing this on RFC 6335, section 5.2 as=
 well as the guidance


sections 4.1.2 and 7.1. =A0What's not required is a leading unders=
core
for the subtype label, though many (including Apple) seem to=
 have
adopted that=A0convention.

Regards=
, -K-



On Fri, Mar 30, 2012 at 9:54 AM, P=
eter Saint-Andre <stpeter@stpeter.im> wrote:


Peter



--

Peter Saint-Andre

https://stpeter.im/




_______________________________________________

core mailing list

core@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/core





--f46d042c6b83a1c31204bc763ae3--