From cabo@tzi.org Thu Mar 7 12:08:32 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5410C21F8CDB; Thu, 7 Mar 2013 12:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1SDaov9Av3i; Thu, 7 Mar 2013 12:08:31 -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 39F4B21F8C20; Thu, 7 Mar 2013 12:08:16 -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.4/8.14.4) with ESMTP id r27K89og025537; Thu, 7 Mar 2013 21:08:09 +0100 (CET) Received: from [192.168.217.105] (p548929A6.dip.t-dialin.net [84.137.41.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4672C366F; Thu, 7 Mar 2013 21:08:09 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Mar 2013 21:08:06 +0100 To: "lwip@ietf.org" , "core@ietf.org WG" , roll WG , "6lowpan@ietf.org" <6lowpan@ietf.org> Message-Id: <3CD61744-1CC9-45F4-A004-80B83E6C2BA4@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [core] Constrained Node/Network Cluster @ IETF86 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Mar 2013 20:08:32 -0000 As you can see, I'm terribly late in preparing for IETF86. Here is my usual eclectic condensed agenda. All times are EDT = (UTC-0400). Very comfortable this time for Europeans. (This time, there are even more slot overlaps for me than I'm already = used to.) Gr=FC=DFe, Carsten MONDAY, March 11, 2013 0900-1130 Morning Session I Caribbean 1 APP appsawg Applications Area Working Group WG - = Combined with APPAREA Caribbean 5 TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1300-1530 Afternoon Session I Caribbean 4 APP json Javascript Object Notation BOF Caribbean 6 OPS eman Energy Management WG Caribbean 3 OPS v6ops IPv6 Operations WG 1540-1710 Afternoon Session II Boca 2 SEC oauth Web Authorization Protocol WG Caribbean 5 TSV tsvwg Transport Area Working Group WG TUESDAY, March 12, 2013 0900-1020 Morning Session I Caribbean 2 RTG *** roll Routing Over Low power and Lossy = networks WG 1030-1130 Morning Session II Caribbean 4 INT intarea Internet Area Working Group WG Caribbean 2 RTG *** roll Routing Over Low power and Lossy = networks WG 1300-1500 Afternoon Session I Caribbean 2 APP *** core Constrained RESTful Environments WG 1700-1830 Afternoon Session III Caribbean 2 SEC httpauth Hypertext Transmission Protocol = Authentication WG WEDNESDAY, March 13, 2013 0900-1130 Morning Session I Caribbean 1 SEC jose Javascript Object Signing and Encryption = WG Caribbean 3 TSV tsvarea Transport Area Open Meeting 1300-1500 Afternoon Session I Caribbean 5 APP *** core Constrained RESTful Environments WG 1510-1710 Afternoon Session II Caribbean 5 OPS v6ops IPv6 Operations WG THURSDAY, March 14, 2013 0900-1130 Morning Session I Caribbean 3 INT homenet Home Networking WG Caribbean 1 INT *** lwig Light-Weight Implementation Guidance WG 1300-1500 Afternoon Session I Caribbean 4 RTG rtgarea Routing Area Open Meeting 1510-1710 Afternoon Session II Caribbean 4 SEC saag Security Area Open Meeting 1730-1830 Afternoon Session III Boca 1 SEC oauth Web Authorization Protocol WG Caribbean 2 TSV tsvwg Transport Area Working Group WG FRIDAY, March 15, 2013 0900-1100 Morning Session I Caribbean 5 APP httpbis Hypertext Transfer Protocol Bis WG 1120-1220 Afternoon Session I Caribbean 4 INT 6man IPv6 Maintenance WG Boca 2 SEC tls Transport Layer Security WG 1230-1330 Afternoon Session II Caribbean 4 INT 6man IPv6 Maintenance WG Boca 2 SEC tls Transport Layer Security WG From cabo@tzi.org Thu Mar 7 12:39:53 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E0F21F8CE2 for ; Thu, 7 Mar 2013 12:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.189 X-Spam-Level: X-Spam-Status: No, score=-106.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 NyKnjbCTycnd for ; Thu, 7 Mar 2013 12:39:52 -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 7E17021F8CDF for ; Thu, 7 Mar 2013 12:39:52 -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.4/8.14.4) with ESMTP id r27KdiwO019900 for ; Thu, 7 Mar 2013 21:39:44 +0100 (CET) Received: from [192.168.217.105] (p548929A6.dip.t-dialin.net [84.137.41.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 618DD3691; Thu, 7 Mar 2013 21:39:44 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Mar 2013 21:39:43 +0100 To: "core@ietf.org WG" Message-Id: <1F0633C5-C254-45EF-A353-C8C1381509B0@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [core] IETF 86 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, 07 Mar 2013 20:39:53 -0000 I uploaded a first cut of the agenda to http://www.ietf.org/proceedings/86/agenda/agenda-86-core Since we haven't actually sent out a request for discussion slots, this = is incomplete. Please send in fixes and updates to Andrew and me. I'll be in various aluminum tubes tomorrow, so I'll be back updating = things when I have arrived at Caribe Royale. Gr=FC=DFe, Carsten PS.: Yes, the secretariat STILL doesn't present the agenda in UTF-8. Will retrofit to ASCII (aka X3.4-1967) in version 1.1. From cabo@tzi.org Mon Mar 11 07:52:12 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C07711E80D2 for ; Mon, 11 Mar 2013 07:52:12 -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 8XHKuNLK1VHg for ; Mon, 11 Mar 2013 07:52: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 2579C21F862E for ; Mon, 11 Mar 2013 07:52: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.4/8.14.4) with ESMTP id r2BEpvji025089; Mon, 11 Mar 2013 15:51:57 +0100 (CET) Received: from [127.0.0.1] (zoo.informatik.uni-bremen.de [134.102.218.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BA47C398D; Mon, 11 Mar 2013 15:51:56 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: multipart/mixed; boundary="Apple-Mail=_1D569EBF-9891-47D9-8E6A-7D87B2EEF8E6" From: Carsten Bormann In-Reply-To: Date: Mon, 11 Mar 2013 10:51:54 -0400 Message-Id: References: To: Barry Leiba X-Mailer: Apple Mail (2.1499) Cc: "draft-ietf-core-coap@tools.ietf.org" , core WG Subject: Re: [core] AD review of draft-ietf-core-coap, part 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 14:52:12 -0000 --Apple-Mail=_1D569EBF-9891-47D9-8E6A-7D87B2EEF8E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Barry, we finally got around to putting in these comments. Most of them are very welcome editorial enhancements,=20 some are clarifications that I don't believe change the substance. A detailed log of what I changed (and answers to some questions) is = below; these changes are in SVN now and will turn up in -14. Thanks again! Gr=FC=DFe, Carsten --Apple-Mail=_1D569EBF-9891-47D9-8E6A-7D87B2EEF8E6 Content-Disposition: attachment; filename=coap-ad-review-1.txt Content-Type: text/plain; name="coap-ad-review-1.txt" Content-Transfer-Encoding: quoted-printable General: Please check for consistency in capitalization of = "Non-Confirmable". You have a mixture of "Non-Confirmable" and "Non-confirmable", = even within the same paragraph in places, as well as a few instances = of "non-confirmable". Check for "Confirmable" vs "confirmable" = also (and "Acknowledgment" and "Reset"). Also look for "Message ID" vs "message-ID" (capitalization and hyphenation). Fixed. One important observation is that acknowledgment can be obtained via an Acknowledgment message or in the form of receiving the response message (first, or upon loss, only). So the term acknowledgment includes both. I have clarified this (in section "Separate"). I think you need quite a few more forward references than you = have. In general, if you talk about something that hasn't been = explained and won't be for some while, there should be a forward reference for = it. For example, in Section 5.7.3 you say that reverse proxies need = to be careful about how they handle the ETag option, and you go into = some bit of detail. But the ETag option is not explained until = 5.10.6. A forward reference would be useful. Look around for these, and = figure that extra references aren't bad, but missing ones can leave = readers wondering. More could be done about that, but realistically most spec readers are used to using the search function of their document readers. -- Sec 3.2 -- string: A Unicode string which is encoded using UTF-8 = [RFC3629] in Net-Unicode form [RFC5198]. I don't think you need to mention 3629 at all, and you certainly = don't need it as a normative reference. 5198 covers everything you = need, and can serve as your reference for UTF-8. It has, itself, a reference to 3629. This also applies to Section 5.5.2. In Section 6.4, you can = also take out the reference to 3629 (3986 also has one, if anyone needs = it). Well, I'm not a big fan of transitive references. Putting in the additional reference may indeed only be "informative", but many prospective readers don't know where to read up authoritatively about UTF-8. -- Sec 4.3 -- You have four types of messages: Confirmable, Non-Confirmable, = Ack, and Reset. Here you make it clear what to do with = Non-Confirmable messages: "A Non-confirmable message MUST NOT be acknowledged by = the recipient." It's clear that Ack and Reset messages are = different message types -- they are neither Confirmable nor = Non-Confirmable... but you require that implementors infer that they, too, are not acknowledged. It would probably be useful to make that explicit, probably by = adding a short paragraph to the end of Section 4.3, thus: Acknowledgment and Reset messages are different types of = messages, distinct from both Confirmable and Non-Confirmable messages. = They are treated similarly to Non-Confirmable messages in that they MUST NOT themselves be acknowledged by the recipient. I put in the first paragraph of 4.2: >> More generally, Acknowledgement and Reset messages MUST NOT elicit any Acknowledgement or Reset message from their recipient. << -- Sec 4.4 -- The initial variable value should be randomozed... Why? To further reduce the likelihood of Message-ID confusion. -- Sec 4.8.1 -- I'm always cautious about using "below", because people aren't = always sure which things "below" are relevant. For "(see discussion = below)" and "(see below)" in the last two paragraphs, I'd say, "(see = Section 4.8.2)". Thanks. I did a number of similar changes in a couple of other places, = too. ensure the adjusted value is also available to all the = endpoints in communicating with which these adjusted values are to be used. This is hyper-silly application of the non-rule rubbish that we shouldn't oughta end sentences with prepositions = (http://en.wikipedia.org/wiki/List_of_common_English_usage_misconceptions)= . It's terribly hard to follow. I say throw it out. Take it = away. What are you waiting for? That is, just say "to all the endpoints that these adjusted = values are to be used to communicate with." Done. -- Sec 4.8.2 -- In the formula for EXCHANGE_LIFETIME, would it not be good to substitute in MAX_TRANSMIT_SPAN instead of the first line, = especially because you say in the text that that value is included? That = will also make it easier to see how it compares with NON_LIFETIME. Done. -- Sec 5.2 -- After receiving and interpreting a request, a server responds = with a CoAP response, which is matched to the request by means of a = client- generated token. This is probably a good place to make clear what the difference = is between Message ID and Token: that the Ack of the request is = matched to the request by Message ID, but the response to the request is matched to the request by the Token. In cases where the = response is separate from the Ack (see 5.2.2) or where there is no Ack (see 5.2.3), this is an important distinction. Some text along those lines. No? We have a whole section on request/response matching: 5.3. I added a pointer. The upper three bits of the 8-bit Response Code number define = the class of response. The lower five bits do not have any categorization role; they give additional detail to the = overall class (Figure 9). There are 3 classes: I suggest moving the paragraph a couple of paragraphs down -- = the one that begins "As a human readable notation" -- up to here, so the documentation format is explained before it's used. I also = suggest that that paragraph is a bit wordier than necessary. Maybe = this?: NEW The upper three bits of the 8-bit Response Code number define = the class of response. The lower five bits do not have any categorization role; they give additional detail to the = overall class (Figure 9). The response code is documented in the format = "c.xx", where "c" is the class represented as an integer, and "xx" is = the detail represented as a two-digit integer. For example, for = the response code "10000011" (defined as "Forbidden"), "c" is = "100" and "xx" is "00011", and the code is written as "4.03". There are 3 classes: END I picked this up, but retained a bit existing text. Responses can be sent in multiple ways, which are defined = below. As with Section 4.8.1 on "below": here I'd say, "Responses can = be sent in multiple ways, which are defined in the following = subsections." Done. -- Sec 5.2.1 -- The response is returned in the Acknowledgement message = independent of whether the response indicates success or failure. In = effect, the response is piggy-backed on the Acknowledgement message, so no separate message is required to both acknowledge that the = request was received and return the response. The second sentence feels convoluted, trying to say the same = thing too many times. Maybe this is better?: NEW The response is returned in the Acknowledgement message = independent of whether the response indicates success or failure. In = effect, the response is piggy-backed on the Acknowledgement message, and = no separate message is required to return the response. END Done. -- Sec 5.2.2 -- Nit: Responses to requests carried in a Non-Confirmable message are always sent = separately (as there is no Acknowledgement message). Match the numbers right: NEW-1 Responses to requests carried in Non-Confirmable messages are always sent separately = (as there are no Acknowledgement messages). ...or... NEW-2 The response to a request carried in a Non-Confirmable message is always sent separately = (as there is no Acknowledgement message). END Done. there is no underlying transport protocol that could be = instructed to run a keep-alive mechanism, the requester MAY want to = set up a timeout that is unrelated to CoAP's retransmission timers = in case the server is destroyed or otherwise unable to send the = response.) This doesn't feel like a proper 2119 MAY (the "may want to" construction is one clue). I would lower-case it. Fixed. An exchange is separate by definition when the Acknowledgement = to the Confirmable request is an empty message. The Acknowledgement = to the Confirmable response MUST also be an empty message, i.e. one = that carries neither a request nor a response. However, a server = MUST stop retransmitting its response on any matching = Acknowledgement (silently ignoring any response code or payload) or Reset = message. I'm a little confused at what this is trying to tell me. Is = this giving one possible scenario, or is this telling me definitively = how to detect that the server is separating the response from the = ack? I think it's the latter, but that's not how it seems to read. If that's what you mean, how about this?: NEW When the server chooses to use a separate response, it sends = the Acknowledgement to the Confirmable request as an empty = message. If the server then sends a Confirmable response, the client's Acknowledgement to that response MUST also be an empty = message, (one that carries neither a request nor a response). The = server MUST stop retransmitting its response on any matching Acknowledgement (silently ignoring any response code or = payload) or Reset message. END I think I might also move this up above the implementation note. Done, done. -- Sec 5.2.3 -- Isn't the second sentence really saying something more general, = beyond what this section is for?: that any endpoint at any time MUST be prepared to receive either a Confirmable or Non-Confirmable = response to either a Confirmable or Non-Confirmable request. In other = words, whether a response is or is not Confirmable can be unrelated to whether the request was Confirmable or not. Should that be said somewhere above, somewhere in Section 4, as a more general = statement? Section 4 is about messages. Section 5.2.3 really is the first place that talks about using non-confirmable in a request-response = interaction. -- Sec 5.3 -- An endpoint receiving a token it did not generate MUST treat = it as opaque and make no assumptions about its format. I'd say "make no assumptions about its *content*. This also = applies to Section 5.10.6. Done. -- Sec 5.3.2 -- Is it true, and is it worth mentioning, that the determination = and matching of endpoint identifiers is specific to the underlying transport and is out of scope for this specification? The = reason I ask is that I want it to be clear that, while for UDP this is = done by comparing the IP addresses and ports of the endpoints as given = in the transport headers, it might be done differently in a system = that, for example, identifies an endpoint through means other than IP = address. Indeed, this is the point being addressed by draft-becker and = draft-silverajan. This spec defines the endpoint abstraction for UDP and DTLS. Other drafts may define other ones. I added to 4.1: - A CoAP endpoint is the source or destination of a CoAP = message. It is + A CoAP endpoint is the source or destination of a CoAP + message. The specific definition of an endpoint depends on + the transport being used for CoAP. For the transports defined + in this specification, + the endpoint is identified depending on the security mode used (see ): With no security, the endpoint is = solely identified by an IP address and a UDP port number. With other = security Along that line: In case a message carrying a response is unexpected (i.e. the = client is not waiting for a response at the endpoint addressed and/or = with the given token), the response is rejected (Section 4.2, Section 4.3). NEW In case a message carrying a response is unexpected (the = client is not waiting for a response from the identified endpoint = and/or with the given token), the response is rejected (Section 4.2, Section 4.3). END I added "from the identified endpoint", but didn't remove "at the endpoint addressed" as that is also part of the tuple being matched. (Yes, we could go about how "client" implies the endpoint being addressed, but this is trying to alert implementers of what they have to do.) -- Sec 5.4.2 -- In addition, for options that are marked Safe to Forward, the = option indicates whether it is intended to be part of the Cache-Key = in a request (NoCacheKey is not all set) or not (NoCacheKey is = set). "NoCacheKey is not all set" seems a little convoluted, = especially because NoCacheKey hasn't been introduced or explained yet. = Maybe this is better?: NEW In addition, for options that are marked Safe to Forward, the = option indicates whether it is intended to be part of the Cache-Key = in a request (some of the NoCacheKey bits are 0) or not (all = NoCacheKey bits are 1; see Section 5.4.6). END Done. As I look ahead, I see that there is nowhere an explanation of = why there are three bits to represent NoCacheKey. Why is that? = (Both: why are there three bits to represent it, *and* why is it not explained in the document?) I added: NoCacheKey is indicated in three bits so that only one out of eight codepoints is qualified as NoCacheKey, assuming this is the less likely case. -- Section 5.4.5 -- The definition of an option MAY specify the option to be = repeatable. An option that is repeatable MAY be included one or more times = in a message. An option that is not repeatable MUST NOT be = included more than once in a message. The first MAY should not be a 2119 key word (it's talking about = what's in this document, not about the protocol). I'd change it to, = "The definitions of some options specify that those options are repeatable." Fixed. -- Section 5.5.1 -- For responses indicating a client or server error, the payload = is considered a representation of the result of the requested = action only if a Content-Format Option is given. In the absence of = this option, the payload is a Diagnostic Payload = ({{diagnostic-message- payload}}). What's that at the end? A remnant of kramdown-rfc2629... Fixed. -- Section 5.7.3 -- In processing the response, a reverse-proxy has to be careful = about namespacing the ETag option. "Namespace" as a verb? Hm. I'm sure I don't know what = "namespacing the ETag option" means. Can you try re-wording? I have deverbed this sentence as follows: In processing the response, a reverse-proxy has to be = careful that ETag option values from different sources are not mixed up on one resource offered to its clients. In many cases, the ETag can be forwarded unchanged. If the mapping from a resource offered by the reverse-proxy to resources offered by its various origin servers is not unique, the reverse-proxy may need to generate a new ETag, making sure the semantics of this option are properly preserved. --Apple-Mail=_1D569EBF-9891-47D9-8E6A-7D87B2EEF8E6-- From cabo@tzi.org Mon Mar 11 20:43:14 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20C421F8A08 for ; Mon, 11 Mar 2013 20:43:14 -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 hfT+Uq7xt3e0 for ; Mon, 11 Mar 2013 20:43:14 -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 0A8B021F84B8 for ; Mon, 11 Mar 2013 20:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2C3hBOa004604 for ; Tue, 12 Mar 2013 04:43:11 +0100 (CET) Received: from [127.0.0.1] (zoo.informatik.uni-bremen.de [134.102.218.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1BFA53BED; Tue, 12 Mar 2013 04:43:10 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Mar 2013 23:43:09 -0400 To: core WG Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [core] Slides for IETF86 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Mar 2013 03:43:15 -0000 ... are in = http://www.ietf.org/proceedings/86/slides/slides-86-core-0.pdf Presenters/Authors: Please check that all is alright (e.g., I almost = destroyed Akbar's slides, but they should be OK now). And please do = fill in the remaining blanks as quickly as you can. Gr=FC=DFe, Carsten From cabo@tzi.org Tue Mar 12 03:55:06 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D21A21F8751 for ; Tue, 12 Mar 2013 03:55:06 -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 K2iW0gELnTYy for ; Tue, 12 Mar 2013 03:55:06 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B5DBA21F86AF for ; Tue, 12 Mar 2013 03:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2CAt0td020369 for ; Tue, 12 Mar 2013 11:55:00 +0100 (CET) Received: from [127.0.0.1] (zoo.informatik.uni-bremen.de [134.102.218.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F16E43E37; Tue, 12 Mar 2013 11:54:59 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Carsten Bormann In-Reply-To: Date: Tue, 12 Mar 2013 06:54:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <634325D9-243F-466E-AAD8-C8B865E8EC41@tzi.org> References: To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1499) Subject: [core] Consensus: Re: Accept option and intermediaries X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Mar 2013 10:55:06 -0000 After some more hallway discussions in Orlando, I just reread the 28 = messages in this thread, this time with my WG chair hat on (as opposed = to as a WG member with a defined opinion on this). It appears we have rough consensus to go with a single-valued = (non-repeatable) Accept option. (I'm personally not part of that rough consensus, but I'm also not aware = of anybody saying "over my dead body" about this simplification.) It appears that this will be the only substantive change from -13 to = -14. I'm sending this message now to validate this rough consensus once more. (We will also have the opportunity to validate this change at the CoRE = meeting today.) Gr=FC=DFe, Carsten From cabo@tzi.org Tue Mar 12 04:23:19 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B7C21F8A05 for ; Tue, 12 Mar 2013 04:23:19 -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 Q4+P6RSaUosj for ; Tue, 12 Mar 2013 04:23:19 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D90AA21F8930 for ; Tue, 12 Mar 2013 04:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2CBNHuC008061 for ; Tue, 12 Mar 2013 12:23:17 +0100 (CET) Received: from [127.0.0.1] (zoo.informatik.uni-bremen.de [134.102.218.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 00A593E76; Tue, 12 Mar 2013 12:23:16 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Mar 2013 07:23:15 -0400 To: "core@ietf.org WG" Message-Id: <6CB6EE37-4627-4F90-84C1-0969263B785B@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [core] Jabber scribes, note takers X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Mar 2013 11:23:19 -0000 In today's and tomorrow's meeting, we will need some increased attention = to the jabber channel, as multiple authors could not make it to Orlando. = So if you are xmpp-savvy, please volunteer watching the channel now or = at the start of the meeting. There is no need for actual "scribing", = just maybe relay information that may not be obvious from the audio = stream. We also need note takers. As in the previous couple of meetings, the = Etherpad will be available for this, so none of the note takers has to = take full notes. In particular, this also means that presenters can be = note takers for the rest of the meeting. We just have to make sure = there is at least one active note taker at any point in time. Again, = please volunteer to be part of this set now or at the start of the = meeting. (And do put your name in the Etherpad, so we can acknowledge = you.) Gr=FC=DFe, Carsten From cabo@tzi.org Tue Mar 12 09:33:14 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FB421F8C2A for ; Tue, 12 Mar 2013 09:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.228 X-Spam-Level: X-Spam-Status: No, score=-106.228 tagged_above=-999 required=5 tests=[AWL=0.021, 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 0F-1s0kaxOBF for ; Tue, 12 Mar 2013 09:33:13 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2178721F8C2C for ; Tue, 12 Mar 2013 09:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2CGX5WH004791 for ; Tue, 12 Mar 2013 17:33:05 +0100 (CET) Received: from [127.0.0.1] (zoo.informatik.uni-bremen.de [134.102.218.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 375A930BE; Tue, 12 Mar 2013 17:33:05 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Carsten Bormann In-Reply-To: Date: Tue, 12 Mar 2013 12:33:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: core WG X-Mailer: Apple Mail (2.1499) Subject: Re: [core] Slides for IETF86 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Mar 2013 16:33:14 -0000 I made a clerical error while updating them and the most recent version = is in: http://www.ietf.org/proceedings/86/slides/slides-86-core-1.pdf Gr=FC=DFe, Carsten From internet-drafts@ietf.org Tue Mar 12 13:42:15 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D0711E80D2; Tue, 12 Mar 2013 13:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0At9svSk7zR; Tue, 12 Mar 2013 13:42:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E57E211E8111; Tue, 12 Mar 2013 13:42:13 -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.42 Message-ID: <20130312204213.26706.66963.idtracker@ietfa.amsl.com> Date: Tue, 12 Mar 2013 13:42:13 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-14.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 20:42:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Constrained Application Protocol (CoAP) Author(s) : Zach Shelby Klaus Hartke Carsten Bormann Filename : draft-ietf-core-coap-14.txt Pages : 110 Date : 2013-03-12 Abstract: The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP easily interfaces with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-coap-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-coap-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cabo@tzi.org Wed Mar 13 07:31:25 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDAB721F8E45 for ; Wed, 13 Mar 2013 07:31: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=[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 kOoxotk1Py3H for ; Wed, 13 Mar 2013 07:31: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 0D8A621F8E4E for ; Wed, 13 Mar 2013 07:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2DEVN55022080 for ; Wed, 13 Mar 2013 15:31:23 +0100 (CET) Received: from dhcp-9032.meeting.ietf.org (dhcp-9032.meeting.ietf.org [130.129.8.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 86A1236EC; Wed, 13 Mar 2013 15:31:20 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Carsten Bormann Date: Wed, 13 Mar 2013 10:31:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130313141054.24729.28407.idtracker@ietfa.amsl.com> To: core WG X-Mailer: Apple Mail (2.1499) Subject: [core] draft-ietf-core-coap has been submitted to the IESG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 13 Mar 2013 14:31:26 -0000 My esteemed co-chair has just submitted draft-ietf-core-coap to the = IESG. Come celebrate (and discuss the next steps) at 13:00 today in Carribbean = 5. Gr=FC=DFe, Carsten Begin forwarded message: > Subject: Publication has been requested for draft draft-ietf-core-coap > Date: March 13, 2013 10:10:54 -0400 >=20 > The state of document draft-ietf-core-coap has been updated. See more = information below. >=20 > Previous state: WG Consensus: Waiting for Write-Up > Current state: Submitted to IESG for Publication > Transition date: 2013-03-13 07:10 > Author of the change: Andrew McGregor From zs68j2ee@gmail.com Wed Mar 13 09:34:23 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27DF21F8DEA for ; Wed, 13 Mar 2013 09:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.139 X-Spam-Level: X-Spam-Status: No, score=-0.139 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bExkg-ENzNav for ; Wed, 13 Mar 2013 09:34:23 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 388F621F8DFF for ; Wed, 13 Mar 2013 09:34:22 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hm6so955922wib.14 for ; Wed, 13 Mar 2013 09:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=Ssu1twYZlJoO0aLbPfPBwwutd7+rGsoMcjy/N0k1yhY=; b=rv3Wjku5D98jHlJnV9Oc7B+G5Lr8KNXH24ZYsmol73OnnxHbjw7cgKIDHOLOF4s3rO cr1dLgMoxmBRlF0FCv0+DiSGyCG8x2kJ5EornABcmoSzUh9eURpwf6bqrune6R4ytxTY ympXA3s9259KHM2w2HUmVejhLq3chYrIr8vlGTnsEjUHtf+8cGtEWSX4DI4mcHiUmtq4 rtab4+/BxjZj1NWPNEy/bShLUvKNB7SKMrmrBEv3WOvRGWu+hJ7V52xN9d5YZGhIiUjl 7g/VSmQqGa/IN5BmbhBKyxd+/0WnLZ+xpZeOj09+gen2znj/ZIRa2VAyWzOjcF+lnjBh L/AA== MIME-Version: 1.0 X-Received: by 10.180.183.193 with SMTP id eo1mr28221909wic.19.1363192461206; Wed, 13 Mar 2013 09:34:21 -0700 (PDT) Received: by 10.194.45.162 with HTTP; Wed, 13 Mar 2013 09:34:21 -0700 (PDT) Date: Thu, 14 Mar 2013 00:34:21 +0800 Message-ID: From: tom To: core@ietf.org Content-Type: multipart/alternative; boundary=001a11c241ce6933c404d7d0fab8 Subject: [core] iwebpp.io announce - run peer/p2p web service with Node.js X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 13 Mar 2013 16:34:24 -0000 --001a11c241ce6933c404d7d0fab8 Content-Type: text/plain; charset=UTF-8 iwebpp.io - Deliver Peer/P2P Web Service with Node.js. Features - Run http over udp, leverage udp's high data-transfer performance - Run web service in peer/p2p style, behind NAT/FW - Support both TURN and STUN session with Websocket - Expand client/central style web service transparently - Easy to use API, reuse existing http/web technologes - Thinking bridge M2M communication with Coap for IoT for details, please refer to https://github.com/InstantWebP2P/iwebpp.io https://github.com/InstantWebP2P/node-httpp Appreciate your suggestions and thoughts. Best regards Tom --001a11c241ce6933c404d7d0fab8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
iwebpp.io - Deliver Peer/P2P Web Service with Node.js.

Features

  • Run http over udp, leverage udp's high data-transfer performanc= e
  • Run web service in peer/p2p style, behind NAT/FW
  • Support = both TURN and STUN session with Websocket
  • Expand client/central sty= le web service transparently
  • Easy to use API, reuse existing http/web technologes
  • Thinking b= ridge M2M communication with Coap for IoT
for details, please = refer to
=C2=A0https://github.com/InstantWebP2P/iwebpp.io

h= ttps://github.com/InstantWebP2P/node-httpp

Appreciat= e your suggestions and thoughts.

Best regards
=C2=A0 Tom
--001a11c241ce6933c404d7d0fab8-- From iesg-secretary@ietf.org Wed Mar 13 11:41:25 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C3211E80DC; Wed, 13 Mar 2013 11:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hR5JPIw439Yk; Wed, 13 Mar 2013 11:41:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C8C21F8ABC; Wed, 13 Mar 2013 11:41:24 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.42 Message-ID: <20130313184124.20160.39271.idtracker@ietfa.amsl.com> Date: Wed, 13 Mar 2013 11:41:24 -0700 Cc: core@ietf.org Subject: [core] Last Call: (Constrained Application Protocol (CoAP)) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:41:25 -0000 The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Constrained Application Protocol (CoAP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-03-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP easily interfaces with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-core-coap/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-core-coap/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Wed Mar 13 11:41:25 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85C911E80E4 for ; Wed, 13 Mar 2013 11:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+GfAB2YUeRU; Wed, 13 Mar 2013 11:41:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0AC21F8C2A; Wed, 13 Mar 2013 11:41:25 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.42 X-IETF-Draft-string: draft-ietf-core-coap X-IETF-Draft-revision: 14 Message-ID: <20130313184125.20160.19265.idtracker@ietfa.amsl.com> Date: Wed, 13 Mar 2013 11:41:25 -0700 Cc: core@ietf.org Subject: [core] Last Call: (Constrained Application Protocol (CoAP)) to Proposed Standard X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@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, 13 Mar 2013 18:41:26 -0000 The IESG has received a request from the Constrained RESTful Environments WG (core) to consider the following document: - 'Constrained Application Protocol (CoAP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-03-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP easily interfaces with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-core-coap/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-core-coap/ballot/ No IPR declarations have been submitted directly on this I-D. From zach@sensinode.com Thu Mar 14 13:29:07 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA7511E80FB for ; Thu, 14 Mar 2013 13:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kS-xEWde8TN for ; Thu, 14 Mar 2013 13:29:05 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 87CC011E80F2 for ; Thu, 14 Mar 2013 13:29:05 -0700 (PDT) Received: from dhcp-44de.meeting.ietf.org (dhcp-44de.meeting.ietf.org [130.129.68.222]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r2EKT0PY002713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 14 Mar 2013 22:29:02 +0200 From: Zach Shelby Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <0789A7E1-2AEB-4CF5-BCF5-337C6CE9420B@sensinode.com> Date: Thu, 14 Mar 2013 16:29:00 -0400 To: "core@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [core] DTLS for IoT group X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 14 Mar 2013 20:29:07 -0000 Many of us who are advocates of making DTLS even better for IoT are = forming a group interested in working on this subject at the IETF. One = result of this could be standardisation of a set of optimisations to = DTLS for use with constrained devices and networks. Possible goals for = this activity could be: =95 A minimal configuration profile of DTLS =95 Optimization of the DTLS handshake and record layer =95 Multicast record layer support for DTLS =95 Use of DTLS for security bootstrapping and key management Interested? Add your name and ideas here: = https://docs.google.com/document/d/1Gw00WXRgjJJQJMv9seVpuXuLtIDYKhHE-7pX4e= Do3g8/edit?usp=3Dsharing Regards, Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From gilger@itsec.rwth-aachen.de Thu Mar 14 13:48:48 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70BB911E81D1 for ; Thu, 14 Mar 2013 13:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uw1uVe7bWE9w for ; Thu, 14 Mar 2013 13:48:47 -0700 (PDT) Received: from avalon.gnuzifer.de (avalon.gnuzifer.de [IPv6:2a01:4f8:190:6500::14:1]) by ietfa.amsl.com (Postfix) with ESMTP id B909E11E819E for ; Thu, 14 Mar 2013 13:48:47 -0700 (PDT) Received: from [134.130.78.3] (port=45588 helo=localhost) by avalon.gnuzifer.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UGF4w-0005oj-3I for core@ietf.org; Thu, 14 Mar 2013 21:48:46 +0100 Date: Thu, 14 Mar 2013 21:48:43 +0100 From: Johannes Gilger To: core@ietf.org Message-ID: <20130314204843.GA29719@dualtron> References: <0789A7E1-2AEB-4CF5-BCF5-337C6CE9420B@sensinode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0789A7E1-2AEB-4CF5-BCF5-337C6CE9420B@sensinode.com> User-Agent: Mutt/1.5.21 (2011-07-01) X-SA-Exim-Connect-IP: 134.130.78.3 X-SA-Exim-Mail-From: gilger@itsec.rwth-aachen.de Subject: Re: [core] DTLS for IoT group X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 14 Mar 2013 20:48:48 -0000 Hi Zach, the document you referenced seems to be read-only (or I'm missing how to edit it). Regards, Jojo On 14/03/13 16:29, Zach Shelby wrote: > Interested? Add your name and ideas here: > > https://docs.google.com/document/d/1Gw00WXRgjJJQJMv9seVpuXuLtIDYKhHE-7pX4eDo3g8/edit?usp=sharing -- Dipl.-Inform. Johannes Gilger Research Group IT-Security RWTH Aachen University Mies-van-der-Rohe-Straße 15 52074 Aachen Office: 211 Phone: +49 241 80 20781 http://itsec.rwth-aachen.de From zach@sensinode.com Thu Mar 14 14:00:30 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D60211E8204 for ; Thu, 14 Mar 2013 14:00:30 -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 T0FKnm3IKKUa for ; Thu, 14 Mar 2013 14:00:29 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4B911E81F4 for ; Thu, 14 Mar 2013 14:00:29 -0700 (PDT) Received: from dhcp-44de.meeting.ietf.org (dhcp-44de.meeting.ietf.org [130.129.68.222]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r2EL0MjL006697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Mar 2013 23:00:26 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Zach Shelby In-Reply-To: <20130314204843.GA29719@dualtron> Date: Thu, 14 Mar 2013 17:00:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0789A7E1-2AEB-4CF5-BCF5-337C6CE9420B@sensinode.com> <20130314204843.GA29719@dualtron> To: Johannes Gilger X-Mailer: Apple Mail (2.1499) Cc: core@ietf.org Subject: Re: [core] DTLS for IoT group X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 14 Mar 2013 21:00:30 -0000 Hi, I now made the editing completely public, should work now. Zach On Mar 14, 2013, at 4:48 PM, Johannes Gilger = wrote: > Hi Zach, >=20 > the document you referenced seems to be read-only (or I'm missing how = to > edit it). >=20 > Regards, > Jojo >=20 > On 14/03/13 16:29, Zach Shelby wrote: >> Interested? Add your name and ideas here: >>=20 >> = https://docs.google.com/document/d/1Gw00WXRgjJJQJMv9seVpuXuLtIDYKhHE-7pX4e= Do3g8/edit?usp=3Dsharing >=20 > --=20 > Dipl.-Inform. Johannes Gilger > Research Group IT-Security > RWTH Aachen University > Mies-van-der-Rohe-Stra=DFe 15 > 52074 Aachen >=20 > Office: 211 > Phone: +49 241 80 20781 >=20 > http://itsec.rwth-aachen.de > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From trac+core@trac.tools.ietf.org Tue Mar 19 00:15:57 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E645621F884B for ; Tue, 19 Mar 2013 00:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFKuzrtlh1OA for ; Tue, 19 Mar 2013 00:15:57 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 567B321F8839 for ; Tue, 19 Mar 2013 00:15:57 -0700 (PDT) Received: from localhost ([127.0.0.1]:45336 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UHqm2-0002zG-Ea; Tue, 19 Mar 2013 08:15:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: esko.dijk@philips.com X-Trac-Project: core Date: Tue, 19 Mar 2013 07:15:54 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/271#comment:2 Message-ID: <075.83fbee150c699adf3811ef60d8297d38@trac.tools.ietf.org> References: <060.098bc8881df48568161fdd11a361f525@trac.tools.ietf.org> X-Trac-Ticket-ID: 271 In-Reply-To: <060.098bc8881df48568161fdd11a361f525@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #271: Review groupcomm requirements language 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, 19 Mar 2013 07:15:58 -0000 #271: Review groupcomm requirements language Comment (by esko.dijk@philips.com): addition to 2. in above comment: in short, for interoperability. As indicated in the CoRE WG meeting at IETF 86. Also this use of requirements language should be clearly explained in the terminology section. -- -----------------------------------+------------------------------------ Reporter: esko.dijk@philips.com | Owner: esko.dijk@philips.com Type: task | Status: assigned Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Resolution: Keywords: | -----------------------------------+------------------------------------ Ticket URL: core From sakane@tanu.org Thu Mar 21 18:44:12 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54BAF21F8DE1 for ; Thu, 21 Mar 2013 18:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.723 X-Spam-Level: X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLaO4XLGJsB1 for ; Thu, 21 Mar 2013 18:44:11 -0700 (PDT) Received: from mama.tanu.org (z189134.ppp.asahi-net.or.jp [110.4.189.134]) by ietfa.amsl.com (Postfix) with ESMTP id C4AC321F8B51 for ; Thu, 21 Mar 2013 18:44:11 -0700 (PDT) Received: from mactanu.local (64-104-46-217.cisco.com [64.104.46.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTPSA id D969F16DD2 for ; Fri, 22 Mar 2013 10:44:09 +0900 (JST) Message-ID: <514BB768.1090404@tanu.org> Date: Fri, 22 Mar 2013 10:44:08 +0900 From: Shoichi Sakane User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: core@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [core] coap-14 and wireshark X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 22 Mar 2013 01:44:12 -0000 Hi, Just for your information, now the dissector of coap-14 has been merged into the repository of wireshark. Any feedback are welcome. Shoichi From angelo.castellani@gmail.com Sun Mar 24 07:44:25 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CC821F8CF7 for ; Sun, 24 Mar 2013 07:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KF8eZgTAr6Lb for ; Sun, 24 Mar 2013 07:44:24 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCB421F8CD6 for ; Sun, 24 Mar 2013 07:44:24 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id fo12so9913405lab.28 for ; Sun, 24 Mar 2013 07:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=5vrUm3+hzFN0tT/gq/5XX/OHVL8mW8TVTZo/Vedb6Bo=; b=HNioSXaCtux3cMLupjwwwnNiG+xQv0JonA3ELseBz0h1FND0TwTXLFuIFzJPcd6VIG Is/5GdIIm/5s30ka75MxVsmDdOV3KTmEQtac9Wi1bk7TwB8yeHHlGNR7x3ZvqgwCmsOD MgThwDIZwlVLNADU0h6uaHonVPzaDy+F+nAycl/NA4tB2lImXJ7ISPp8F2dl2Tx++LaY PLtq/Y7go/f+WcxYlqonjMN8M76SRCUTQjR/MOLyUa0xcHgICYIZMBU+AopVTKG8xn66 TjBpzTzOFVs6JC+mlchUK8IR9Y3p1eMpnNiOtL413m5chQ7POtG9RtbTpxN0X6ZNn1c8 1l8g== X-Received: by 10.112.49.201 with SMTP id w9mr4265714lbn.2.1364136263340; Sun, 24 Mar 2013 07:44:23 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.112.80.201 with HTTP; Sun, 24 Mar 2013 07:44:08 -0700 (PDT) From: "Angelo P. Castellani" Date: Sun, 24 Mar 2013 15:44:08 +0100 X-Google-Sender-Auth: KstiOAwjzF74nnPAGfrRL03WnaM Message-ID: To: core Content-Type: multipart/mixed; boundary=bcaec554d98466dd0f04d8acb9ae Subject: [core] Response suppression X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 Mar 2013 14:44:25 -0000 --bcaec554d98466dd0f04d8acb9ae Content-Type: text/plain; charset=UTF-8 Dear WG, one-way traffic could be a requirement in future application scenarios that need to keep the network unloaded of unrelevant traffic. (I have various examples in mind, if you feel that it's worth I can contribute some ideas) If a response suppression mechanism is built into the protocol, even this situation could be addressed using CoAP. I've given it a quick try, you can read my proposal in the following part of the message. However if any seasoned protocol-designer has better proposals for supporting this feature, please propose it here. I propose to restrict TKL field to a 3-bit size, as originally proposed by Klaus (http://www.ietf.org/mail-archive/web/core/current/msg03832.html). Note that right now TKL values 9-15 are reserved, so this means that actual encoding does not change. If we get back this reserved field we can use it for response suppression as described in the attached text file. Best, Angelo p.s.: probably for applicating this in the multicast case we need a little more work --bcaec554d98466dd0f04d8acb9ae Content-Type: text/plain; charset=US-ASCII; name="response-suppression.txt" Content-Disposition: attachment; filename="response-suppression.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_heoba85u0 ICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAg ICAgICAgICAzCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDEKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfFZlcnwgVCB8U3wgVEtMIHwgICAg ICBDb2RlICAgICB8ICAgICAgICAgIE1lc3NhZ2UgSUQgICAgICAgICAgIHwKICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsK ICAgfCAgIFRva2VuIChpZiBhbnksIFRLTCBieXRlcykgLi4uCiAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICBP cHRpb25zIChpZiBhbnkpIC4uLgogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICB8MSAxIDEgMSAxIDEgMSAxfCAgICBQ YXlsb2FkIChpZiBhbnkpIC4uLgogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKU3VwcHJlc3MgcmVzcG9uc2UgKFMpOiAx LWJpdCB1bnNpZ25lZCBpbnRlZ2VyLgpXaGVuIHNldCB0byAxLCBpbmRpY2F0ZXMgdG8gdGhlIHJl cXVlc3QtcmVzcG9uc2UgbGF5ZXIgdG8gYXZvaWQgcHJvZHVjaW5nIGEgcmVzcG9uc2UgdG8gdGhp cyByZXF1ZXN0LgpUaGlzIGZsYWcgTVVTVCBOT1QgYmUgZXF1YWwgdG8gMSwgaWYgQ29kZSB2YWx1 ZSBpcyBub3Qgd2l0aGluIDEtMzEuCgo= --bcaec554d98466dd0f04d8acb9ae-- From cabo@tzi.org Sun Mar 24 08:09:10 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B671721F8D2A for ; Sun, 24 Mar 2013 08:09: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 wcSPRDanKwOR for ; Sun, 24 Mar 2013 08:09: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 EBCEC21F8D1E for ; Sun, 24 Mar 2013 08:09: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.4/8.14.4) with ESMTP id r2OF91Ew013399; Sun, 24 Mar 2013 16:09:01 +0100 (CET) Received: from [192.168.217.105] (p5489308D.dip.t-dialin.net [84.137.48.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C49183FA2; Sun, 24 Mar 2013 16:09:00 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Sun, 24 Mar 2013 16:08:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3C721E6E-3524-4A6D-8453-500E40155F2F@tzi.org> References: To: "Angelo P. Castellani" X-Mailer: Apple Mail (2.1503) Cc: core Subject: Re: [core] Response suppression X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 Mar 2013 15:09:10 -0000 There are two proposals here: 1 -- introducing a way to indicate that a response is not desired; 2 -- changing the four-byte header to carry that indication. There are a quite a few ways to provide the indication (1) that have = fewer side-effects on what we have now than (2). Let's focus first on what the scenarios for application of response-less = methods would be, and then discuss how to encode them. (Just as an existence proof, obviously, the same information could be = carried in an Option with a single-byte encoding, or as separate method = numbers.) (As a protocol design meta-comment: There is a strange attraction from = unused or reserved bits/bit combinations in a protocol, constantly = moving people to invent ways to fill them. That is not good for further = evolution of the protocol, which often requires reserved bits/bit = combinations to be available. There is always more need to evolve a = protocol than is apparent from the information available at a specific = point in time.) So what are the application scenarios for response-less methods? Gr=FC=DFe, Carsten From angelo.castellani@gmail.com Sun Mar 24 08:24:24 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9BB21F8B27 for ; Sun, 24 Mar 2013 08:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5asaKVL0QNa for ; Sun, 24 Mar 2013 08:24:23 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 84C6321F8AF4 for ; Sun, 24 Mar 2013 08:24:23 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id fq12so9967430lab.33 for ; Sun, 24 Mar 2013 08:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=8lmB+7BQgWDu71N2VSRNF7lS+Hf+lv8tR+ZqppdwXI8=; b=T9maKgphGVoLj4MFsgE0CvpofUtvNKtKmAUnoQX/rpNXm6XQV7t5Vln82IsRZrtEyO MhL57IvMd4drJjk9F4WG/uoCsSBPW8a5R+9d0S0Fg/mCVO3q7qLhebn8ZYabIhYVXZWT HpouvvpvXJvfCfMdlzhCuVDdgUz5dXovJMLaApFs3dbajXFdLccd5w2FHWkJqKgVIrsP lY1aMNqgB3mAA8L0xGgpHImrGfaTmbTEVH7jxJSW5wu8qDy0KdiWIeQ1zm0FoKCqjH2H nL8bPmjJxm6INKvMLfqcX8y8pdwzXSZfxJ/EzyU394W19E90DbT3dV9RuW5Qy9nYy2ER EYOQ== X-Received: by 10.152.147.36 with SMTP id th4mr4385216lab.19.1364138662436; Sun, 24 Mar 2013 08:24:22 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.112.80.201 with HTTP; Sun, 24 Mar 2013 08:24:07 -0700 (PDT) In-Reply-To: <3C721E6E-3524-4A6D-8453-500E40155F2F@tzi.org> References: <3C721E6E-3524-4A6D-8453-500E40155F2F@tzi.org> From: "Angelo P. Castellani" Date: Sun, 24 Mar 2013 16:24:07 +0100 X-Google-Sender-Auth: fkELDUJgbQeQTh1KBH4l7RIizNs Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: core Subject: Re: [core] Response suppression X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 Mar 2013 15:24:24 -0000 Generally speaking, IMHO, there are two scenarios when response is not desidered: 1 -- in any case the response is not desidered, e.g., for timing reasons, or because the client operation does not depend upon the response 2 -- some responses are not desidered, e.g., see multicast requests and client-errors (404) from some, possibly many, servers In my point of view, case (1) is typically the case of high-priority commands. Something like "Hey, Do this! If you fail, there is no other possibility of doing this". Case (1) fits very well with having this in the header because this approach does not deserve enlarging the message, and the server (or even the network) can possibly process (or even relay) this message with higher priority than the others. Case (2) probably works better with an option that specifies criteria to understand which are the undesidered responses. I hope this clarifies my point, and motivates the reason why I put it in that very "tempting" part of the header :-) Best, Angelo 2013/3/24 Carsten Bormann : > There are two proposals here: > 1 -- introducing a way to indicate that a response is not desired; > 2 -- changing the four-byte header to carry that indication. > > There are a quite a few ways to provide the indication (1) that have fewe= r side-effects on what we have now than (2). > Let's focus first on what the scenarios for application of response-less = methods would be, and then discuss how to encode them. > (Just as an existence proof, obviously, the same information could be car= ried in an Option with a single-byte encoding, or as separate method number= s.) > > (As a protocol design meta-comment: There is a strange attraction from un= used or reserved bits/bit combinations in a protocol, constantly moving peo= ple to invent ways to fill them. That is not good for further evolution of= the protocol, which often requires reserved bits/bit combinations to be av= ailable. There is always more need to evolve a protocol than is apparent f= rom the information available at a specific point in time.) > > So what are the application scenarios for response-less methods? > > Gr=C3=BC=C3=9Fe, Carsten > From angelo.castellani@gmail.com Sun Mar 24 08:42:33 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DED621F898B for ; Sun, 24 Mar 2013 08:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMyABqGOFm3i for ; Sun, 24 Mar 2013 08:42:32 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7730421F8546 for ; Sun, 24 Mar 2013 08:42:32 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id fo13so9750256lab.24 for ; Sun, 24 Mar 2013 08:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=mmnU+2iCzGQhT/qN+owsDPNJ6AECTEDn07c8Wfujo4A=; b=vnVl9KN2zp/b6BbRsSn0BjLkZLqRkF0nMM90vXSlMj3CJ3n27WL9PmyI8mQu0d1bXX lIY3AZzZgDmBKqanISodllmJi/YcQh0XFv1sfyi2UNS8cURasBYBWuB7wxWgVPlT/7g1 nCGlfyDdPZZ7vr4lwfvWZBpHb7ojAJZuzWWkxnSwv16miA2XaSnrZw/Ck0vwPCotxidn UZ/scP+BJImHZlkWW/eaY7nqPb03+z5i82Ycr8cGucjymrbqYJYYEM0eSzGZN+qqEbWa +pHTqMKvWlIZ/IOAKtPvQmtkIYbpTI5Wn+hsCWOA6pFpMpjVltuc7kFKZq8Bju3pyRr2 MSzw== X-Received: by 10.112.99.65 with SMTP id eo1mr4551599lbb.78.1364139751108; Sun, 24 Mar 2013 08:42:31 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.112.80.201 with HTTP; Sun, 24 Mar 2013 08:42:16 -0700 (PDT) From: "Angelo P. Castellani" Date: Sun, 24 Mar 2013 16:42:16 +0100 X-Google-Sender-Auth: Jmj0nKg_d_8qhBpNN30RVi1KtiM Message-ID: To: core Content-Type: text/plain; charset=UTF-8 Subject: [core] CoAP-DNS mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 15:42:33 -0000 Dear WG, in our work, we know that designing software for Class-1 devices is generally a matter of selecting a strict set of features/protocols/algorithms that enable our tiny devices doing the wide range of things we want them to do. I was daydreaming of having a mapping between DNS and CoAP, so that the CoAP devices can GET, POST, PUT and DELETE values into the DNS server as they where resources of a CoAP server. This approach has (at least) two benefits: 1 -- we don't need to implement DNS on that devices 2 -- we have a protocol that enables (authorized) nodes to modify DNS entries Point (1) helps efficient node implementation. Point (2) enables a possible approach to solve ID-Locator split issues, generally requiring complex systems (see the resource directory). Using the DNS to name CoAP nodes enables reusing a well-known Internet protocol for solving about 90% cases where these systems are required. What does the WG feel about this mapping? Best, Angelo From cabo@tzi.org Sun Mar 24 15:16:33 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8462721F8DF2 for ; Sun, 24 Mar 2013 15:16:33 -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 U7KQy1GGCIOJ for ; Sun, 24 Mar 2013 15:16:32 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5F71021F8DEF for ; Sun, 24 Mar 2013 15:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2OMGQ4P012706 for ; Sun, 24 Mar 2013 23:16:26 +0100 (CET) Received: from [192.168.217.105] (p5489308D.dip.t-dialin.net [84.137.48.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 784CE305A; Sun, 24 Mar 2013 23:16:26 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Mar 2013 23:16:25 +0100 To: core WG Message-Id: <6AB86677-242A-4EE9-B4C3-E9F2A118BE06@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [core] IETF86 minutes uploaded X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 Mar 2013 22:16:33 -0000 The draft IETF86 minutes are at: http://www.ietf.org/proceedings/86/minutes/minutes-86-core Thanks again for the notetakers; all errors are mine. This was a pretty productive meeting, please take a couple of minutes = reviewing if your contributions are properly recorded. Please send editorial comments to me, substantive comments to the list. Gr=FC=DFe, Carsten From cabo@tzi.org Sun Mar 24 15:33:35 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606AB21F8E21 for ; Sun, 24 Mar 2013 15:33:34 -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 uj3SSjBiY9v9 for ; Sun, 24 Mar 2013 15:33:34 -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 7E53A21F8E1D for ; Sun, 24 Mar 2013 15:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2OMXVhj012821 for ; Sun, 24 Mar 2013 23:33:31 +0100 (CET) Received: from [192.168.217.105] (p5489308D.dip.t-dialin.net [84.137.48.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2DDC1305B; Sun, 24 Mar 2013 23:33:31 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Mar 2013 23:33:29 +0100 To: core WG Message-Id: <0C9867A6-AED5-4063-88AE-E9D1C6CDE75E@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [core] Call for reviews of draft-castellani-core-http-mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 22:33:35 -0000 In Orlando, we said we were trying to increase the level of attention on = the HTTP mapping draft with a view to making it a WG document very soon. So, if you have comments on it now, please send them to the list. We had a few people volunteering to review the draft as a prerequisite = to a call for WG adoption, so please do send in these (short or long, as = you like) reviews. Of course WG adoption means that the WG starts considering this as a WG = draft, not that we all already agree with every detail, but any concerns = about scoping and general approach should be discussed now. Gr=FC=DFe, Carsten From stokcons@xs4all.nl Mon Mar 25 01:49:13 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289BF21F8EAE for ; Mon, 25 Mar 2013 01:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.096 X-Spam-Level: ** X-Spam-Status: No, score=2.096 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YygmDJ97yso for ; Mon, 25 Mar 2013 01:49:12 -0700 (PDT) Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) by ietfa.amsl.com (Postfix) with ESMTP id 65B9721F8E6B for ; Mon, 25 Mar 2013 01:49:12 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube6.xs4all.net [194.109.20.204]) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id r2P8nAnl029349 for ; Mon, 25 Mar 2013 09:49:11 +0100 (CET) (envelope-from stokcons@xs4all.nl) Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 25 Mar 2013 09:49:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 25 Mar 2013 09:49:10 +0100 From: peter van der Stok To: Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: References: Message-ID: X-Sender: stokcons@xs4all.nl (zGSln9agucmpmOWzWsFHYVt0KO+qeqUG) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [core] CoAP-DNS mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 08:49:13 -0000 Hi Angelo, I don't understand your point 1; you mean DNS-client code? I partially agree with your dream, but I only see it as a reduction of code on the client device. We may use the coap security for the DNS access; given future edevelopments this may be a reduction in code size on the client. However, I don't see changes to DNS taking place, but may be you can convince Stuart for his Hybrid-1 draft: draft-cheshire-mdnsext-hybrid-01. Greetings, peter Angelo P. Castellani schreef op 2013-03-24 16:42: > Dear WG, > > in our work, we know that designing software for Class-1 devices is > generally a matter of selecting a strict set of > features/protocols/algorithms that enable our tiny devices doing the > wide range of things we want them to do. > > I was daydreaming of having a mapping between DNS and CoAP, so that > the CoAP devices can GET, POST, PUT and DELETE values into the DNS > server as they where resources of a CoAP server. > > This approach has (at least) two benefits: > > 1 -- we don't need to implement DNS on that devices > > 2 -- we have a protocol that enables (authorized) nodes to modify DNS > entries > > Point (1) helps efficient node implementation. Point (2) enables a > possible approach to solve ID-Locator split issues, generally > requiring complex systems (see the resource directory). Using the DNS > to name CoAP nodes enables reusing a well-known Internet protocol for > solving about 90% cases where these systems are required. > > What does the WG feel about this mapping? > > Best, > Angelo > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From esko.dijk@philips.com Mon Mar 25 02:05:31 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E9C21F8EB9 for ; Mon, 25 Mar 2013 02:05:31 -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 ZXmxAi4eWGfC for ; Mon, 25 Mar 2013 02:05:31 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id EB8C421F8EB3 for ; Mon, 25 Mar 2013 02:05:30 -0700 (PDT) Received: from mail111-co1-R.bigfish.com (10.243.78.234) by CO1EHSOBE024.bigfish.com (10.243.66.87) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Mar 2013 09:05:30 +0000 Received: from mail111-co1 (localhost [127.0.0.1]) by mail111-co1-R.bigfish.com (Postfix) with ESMTP id 3DF79300112; Mon, 25 Mar 2013 09:05:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -33 X-BigFish: VPS-33(zzbb2dI15d6O9251Jc89bh542I1432Idb82h217bIzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail111-co1 (localhost.localdomain [127.0.0.1]) by mail111-co1 (MessageSwitch) id 1364202329262178_26448; Mon, 25 Mar 2013 09:05:29 +0000 (UTC) Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.247]) by mail111-co1.bigfish.com (Postfix) with ESMTP id 33E7D60008D; Mon, 25 Mar 2013 09:05:29 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 25 Mar 2013 09:05:28 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.99]) by 011-DB3MMR1-001.MGDPHG.emi.philips.com ([10.128.28.51]) with mapi id 14.02.0328.011; Mon, 25 Mar 2013 09:05:25 +0000 From: "Dijk, Esko" To: "Angelo P. Castellani" , Carsten Bormann Thread-Topic: [core] Response suppression Thread-Index: AQHOKJ4bEkc9E3853EWKKf5zAXZlzpi08cmAgAAEOoCAAScHkA== Date: Mon, 25 Mar 2013 09:05:25 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618BED241@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <3C721E6E-3524-4A6D-8453-500E40155F2F@tzi.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.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: core Subject: Re: [core] Response suppression X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Mar 2013 09:05:31 -0000 Rm9yIG1vcmUgcmVsZXZhbnQgaW5wdXQgdG8gdGhpcyBkaXNjdXNzaW9uLCBzZWU6IGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29yZS1ncm91cGNvbW0tMDUjc2VjdGlvbi0z LjYNCkl0IGFpbXMgdG8gc2hvdyB3aHkgcmVzcG9uc2Ugc3VwcHJlc3Npb24gaXMgbmVlZGVkIGZv ciBtdWx0aWNhc3QgcmVzcG9uc2VzOyBhbmQgcHJvcG9zZXMgYSBzb2x1dGlvbiBmb3IgY29uZmln dXJpbmcgcmVzcG9uc2Ugc3VwcHJlc3Npb24gb24gQ29BUCBzZXJ2ZXJzIHRoYXQgaXMgbm90IHRv byBjb21wbGV4IGJ1dCBzdGlsbCBzdWl0YWJsZSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2VzL3Vz ZSBjYXNlcy4NCg0KSW4gbXkgdmlldyBhIENvQVAgb3B0aW9uIGZvciByZXNwb25zZSBzdXBwcmVz c2lvbiBzb3VuZHMgdXNlZnVsIGFuZCByZWxldmFudCBpbiB0aGlzIGNvbnRleHQ7IGhvd2V2ZXIg d2UgdGhlbiBoYXZlIHRvIGNsZWFybHkgbGlzdCBib3RoIGFkdmFudGFnZXMgYW5kIGRpc2FkdmFu dGFnZXMgb2YgdGhpcyBhcHByb2FjaCBhZ2FpbnN0IHRoZSBjdXJyZW50IGFwcHJvYWNoIGluIHRo ZSBHcm91cENvbW0gZHJhZnQgYmFzZWQgcHVyZWx5IG9uIHNlcnZlci9wZXItcmVzb3VyY2UgY29u ZmlndXJhdGlvbi4NCg0KRXNrbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog Y29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQW5nZWxvIFAuIENhc3RlbGxhbmkNClNlbnQ6IFN1bmRheSwgTWFyY2ggMjQsIDIw MTMgMTY6MjQNClRvOiBDYXJzdGVuIEJvcm1hbm4NCkNjOiBjb3JlDQpTdWJqZWN0OiBSZTogW2Nv cmVdIFJlc3BvbnNlIHN1cHByZXNzaW9uDQoNCkdlbmVyYWxseSBzcGVha2luZywgSU1ITywgdGhl cmUgYXJlIHR3byBzY2VuYXJpb3Mgd2hlbiByZXNwb25zZSBpcyBub3QNCmRlc2lkZXJlZDoNCg0K MSAtLSBpbiBhbnkgY2FzZSB0aGUgcmVzcG9uc2UgaXMgbm90IGRlc2lkZXJlZCwgZS5nLiwgZm9y IHRpbWluZyByZWFzb25zLCBvciBiZWNhdXNlIHRoZSBjbGllbnQgb3BlcmF0aW9uIGRvZXMgbm90 IGRlcGVuZCB1cG9uIHRoZSByZXNwb25zZQ0KDQoyIC0tIHNvbWUgcmVzcG9uc2VzIGFyZSBub3Qg ZGVzaWRlcmVkLCBlLmcuLCBzZWUgbXVsdGljYXN0IHJlcXVlc3RzIGFuZCBjbGllbnQtZXJyb3Jz ICg0MDQpIGZyb20gc29tZSwgcG9zc2libHkgbWFueSwgc2VydmVycw0KDQpJbiBteSBwb2ludCBv ZiB2aWV3LCBjYXNlICgxKSBpcyB0eXBpY2FsbHkgdGhlIGNhc2Ugb2YgaGlnaC1wcmlvcml0eSBj b21tYW5kcy4gU29tZXRoaW5nIGxpa2UgIkhleSwgRG8gdGhpcyEgSWYgeW91IGZhaWwsIHRoZXJl IGlzIG5vIG90aGVyIHBvc3NpYmlsaXR5IG9mIGRvaW5nIHRoaXMiLiBDYXNlICgxKSBmaXRzIHZl cnkgd2VsbCB3aXRoIGhhdmluZyB0aGlzIGluIHRoZSBoZWFkZXIgYmVjYXVzZSB0aGlzIGFwcHJv YWNoIGRvZXMgbm90IGRlc2VydmUgZW5sYXJnaW5nIHRoZSBtZXNzYWdlLCBhbmQgdGhlIHNlcnZl ciAob3IgZXZlbiB0aGUgbmV0d29yaykgY2FuIHBvc3NpYmx5IHByb2Nlc3MgKG9yIGV2ZW4gcmVs YXkpIHRoaXMgbWVzc2FnZSB3aXRoIGhpZ2hlciBwcmlvcml0eSB0aGFuIHRoZSBvdGhlcnMuDQoN CkNhc2UgKDIpIHByb2JhYmx5IHdvcmtzIGJldHRlciB3aXRoIGFuIG9wdGlvbiB0aGF0IHNwZWNp ZmllcyBjcml0ZXJpYSB0byB1bmRlcnN0YW5kIHdoaWNoIGFyZSB0aGUgdW5kZXNpZGVyZWQgcmVz cG9uc2VzLg0KDQpJIGhvcGUgdGhpcyBjbGFyaWZpZXMgbXkgcG9pbnQsIGFuZCBtb3RpdmF0ZXMg dGhlIHJlYXNvbiB3aHkgSSBwdXQgaXQgaW4gdGhhdCB2ZXJ5ICJ0ZW1wdGluZyIgcGFydCBvZiB0 aGUgaGVhZGVyIDotKQ0KDQpCZXN0LA0KQW5nZWxvDQoNCjIwMTMvMy8yNCBDYXJzdGVuIEJvcm1h bm4gPGNhYm9AdHppLm9yZz46DQo+IFRoZXJlIGFyZSB0d28gcHJvcG9zYWxzIGhlcmU6DQo+IDEg LS0gaW50cm9kdWNpbmcgYSB3YXkgdG8gaW5kaWNhdGUgdGhhdCBhIHJlc3BvbnNlIGlzIG5vdCBk ZXNpcmVkOw0KPiAyIC0tIGNoYW5naW5nIHRoZSBmb3VyLWJ5dGUgaGVhZGVyIHRvIGNhcnJ5IHRo YXQgaW5kaWNhdGlvbi4NCj4NCj4gVGhlcmUgYXJlIGEgcXVpdGUgYSBmZXcgd2F5cyB0byBwcm92 aWRlIHRoZSBpbmRpY2F0aW9uICgxKSB0aGF0IGhhdmUgZmV3ZXIgc2lkZS1lZmZlY3RzIG9uIHdo YXQgd2UgaGF2ZSBub3cgdGhhbiAoMikuDQo+IExldCdzIGZvY3VzIGZpcnN0IG9uIHdoYXQgdGhl IHNjZW5hcmlvcyBmb3IgYXBwbGljYXRpb24gb2YgcmVzcG9uc2UtbGVzcyBtZXRob2RzIHdvdWxk IGJlLCBhbmQgdGhlbiBkaXNjdXNzIGhvdyB0byBlbmNvZGUgdGhlbS4NCj4gKEp1c3QgYXMgYW4g ZXhpc3RlbmNlIHByb29mLCBvYnZpb3VzbHksIHRoZSBzYW1lIGluZm9ybWF0aW9uIGNvdWxkIGJl DQo+IGNhcnJpZWQgaW4gYW4gT3B0aW9uIHdpdGggYSBzaW5nbGUtYnl0ZSBlbmNvZGluZywgb3Ig YXMgc2VwYXJhdGUNCj4gbWV0aG9kIG51bWJlcnMuKQ0KPg0KPiAoQXMgYSBwcm90b2NvbCBkZXNp Z24gbWV0YS1jb21tZW50OiBUaGVyZSBpcyBhIHN0cmFuZ2UgYXR0cmFjdGlvbiBmcm9tDQo+IHVu dXNlZCBvciByZXNlcnZlZCBiaXRzL2JpdCBjb21iaW5hdGlvbnMgaW4gYSBwcm90b2NvbCwgY29u c3RhbnRseQ0KPiBtb3ZpbmcgcGVvcGxlIHRvIGludmVudCB3YXlzIHRvIGZpbGwgdGhlbS4gIFRo YXQgaXMgbm90IGdvb2QgZm9yDQo+IGZ1cnRoZXIgZXZvbHV0aW9uIG9mIHRoZSBwcm90b2NvbCwg d2hpY2ggb2Z0ZW4gcmVxdWlyZXMgcmVzZXJ2ZWQNCj4gYml0cy9iaXQgY29tYmluYXRpb25zIHRv IGJlIGF2YWlsYWJsZS4gIFRoZXJlIGlzIGFsd2F5cyBtb3JlIG5lZWQgdG8NCj4gZXZvbHZlIGEg cHJvdG9jb2wgdGhhbiBpcyBhcHBhcmVudCBmcm9tIHRoZSBpbmZvcm1hdGlvbiBhdmFpbGFibGUg YXQgYQ0KPiBzcGVjaWZpYyBwb2ludCBpbiB0aW1lLikNCj4NCj4gU28gd2hhdCBhcmUgdGhlIGFw cGxpY2F0aW9uIHNjZW5hcmlvcyBmb3IgcmVzcG9uc2UtbGVzcyBtZXRob2RzPw0KPg0KPiBHcsO8 w59lLCBDYXJzdGVuDQo+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJl IGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcu IFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZp ZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciByZXByb2R1Y3Rp b24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxh d2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRh Y3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2Yg dGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo= From esko.dijk@philips.com Mon Mar 25 02:16:26 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7342621F8EBE for ; Mon, 25 Mar 2013 02:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.501, 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 AUxQLGd4-IfZ for ; Mon, 25 Mar 2013 02:16:25 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id 494EE21F8EB4 for ; Mon, 25 Mar 2013 02:16:24 -0700 (PDT) Received: from mail44-db8-R.bigfish.com (10.174.8.243) by DB8EHSOBE039.bigfish.com (10.174.4.102) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Mar 2013 09:16:23 +0000 Received: from mail44-db8 (localhost [127.0.0.1]) by mail44-db8-R.bigfish.com (Postfix) with ESMTP id 21F4FCA0258 for ; Mon, 25 Mar 2013 09:16:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -10 X-BigFish: VPS-10(zz15d6O9251Jc85fh217bIzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz18c673hz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1155h) Received: from mail44-db8 (localhost.localdomain [127.0.0.1]) by mail44-db8 (MessageSwitch) id 1364202981209834_11617; Mon, 25 Mar 2013 09:16:21 +0000 (UTC) Received: from DB8EHSMHS019.bigfish.com (unknown [10.174.8.251]) by mail44-db8.bigfish.com (Postfix) with ESMTP id 25321580045; Mon, 25 Mar 2013 09:16:21 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB8EHSMHS019.bigfish.com (10.174.4.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 25 Mar 2013 09:16:20 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.99]) by 011-DB3MMR1-010.MGDPHG.emi.philips.com ([10.128.28.49]) with mapi id 14.02.0328.011; Mon, 25 Mar 2013 09:16:20 +0000 From: "Dijk, Esko" To: "core (core@ietf.org)" Thread-Topic: Any experience in using CoAP responses to multicast requests? Thread-Index: Ac4pONZ9jmyW33hUTk2rD/1uju9x1w== Date: Mon, 25 Mar 2013 09:16:19 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618BF0286@011-DB3MPN2-082.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618BF0286011DB3MPN2082MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] Any experience in using CoAP responses to multicast requests? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Mar 2013 09:16:26 -0000 --_000_031DD135F9160444ABBE3B0C36CED618BF0286011DB3MPN2082MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, one of the review comments to the GroupComm I-D concerns the lack of (imple= mentation or simulation) experience with use of CoAP multicast, and the ass= ociated multitude of CoAP responses. The I-D provides guidelines in this ar= ea but not based on such experience. Did anyone experiment with CoAP multicast? (Or knows someone, or a publicat= ion etc.) regards, Esko ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_031DD135F9160444ABBE3B0C36CED618BF0286011DB3MPN2082MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

one of the review comments to the GroupComm I-D conc= erns the lack of (implementation or simulation) experience with use of CoAP= multicast, and the associated multitude of CoAP responses. The I-D provide= s guidelines in this area but not based on such experience.

 

Did anyone experiment with CoAP multicast? (Or knows= someone, or a publication etc.)

 

regards,

Esko


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_031DD135F9160444ABBE3B0C36CED618BF0286011DB3MPN2082MGDP_-- From floris.vandenabeele@intec.ugent.be Tue Mar 26 07:52:36 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BD521F8BDB for ; Tue, 26 Mar 2013 07:52: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 kvTDnKDF5A7Y for ; Tue, 26 Mar 2013 07:52:35 -0700 (PDT) Received: from smtp3.ugent.be (smtp3.ugent.be [157.193.49.127]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC4721F8BD5 for ; Tue, 26 Mar 2013 07:52:35 -0700 (PDT) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp3.ugent.be (Postfix) with ESMTP id 7B1F9C209; Tue, 26 Mar 2013 15:52:34 +0100 (CET) X-Virus-Scanned: by UGent DICT Received: from smtp3.ugent.be ([157.193.49.127]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id OfKySC_Gnhxs; Tue, 26 Mar 2013 15:52:34 +0100 (CET) Received: from mail2.intec.ugent.be (mail2.intec.ugent.be [157.193.214.245]) by smtp3.ugent.be (Postfix) with ESMTP id E6CA4C40F; Tue, 26 Mar 2013 15:52:33 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail2.intec.ugent.be (Postfix) with ESMTP id 0265021; Tue, 26 Mar 2013 15:52:34 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at intec.ugent.be Received: from mail2.intec.ugent.be ([127.0.0.1]) by localhost (mail2.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-ZJjZDdyV5J; Tue, 26 Mar 2013 15:52:33 +0100 (CET) Received: from [157.193.135.176] (dhcp-zdpt-176.intec.ugent.be [157.193.135.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fvdabeele) by mail2.intec.ugent.be (Postfix) with ESMTPSA id E31811F; Tue, 26 Mar 2013 15:52:33 +0100 (CET) Message-ID: <5151B631.9050607@intec.ugent.be> Date: Tue, 26 Mar 2013 15:52:33 +0100 From: Floris Van den Abeele User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Carsten Bormann References: <0C9867A6-AED5-4063-88AE-E9D1C6CDE75E@tzi.org> In-Reply-To: <0C9867A6-AED5-4063-88AE-E9D1C6CDE75E@tzi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Miltered: at jchkm1 with ID 5151B631.008 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 5151B631.008 from mail2.intec.ugent.be/mail2.intec.ugent.be/157.193.214.245/mail2.intec.ugent.be/ X-j-chkmail-Score: MSGID : 5151B631.008 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] Call for reviews of draft-castellani-core-http-mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 14:52:36 -0000 In section 2 the definitions of reverse and forward proxies are not that clear to me. The text tries to clarify: Reverse and Forward proxies are technically very similar, with main differences being that the former appears to a client as an origin server while the latter does not, and that clients may be unaware they are communicating with a proxy. In my mind, a typical reverse cross protocol proxy (RXPP hereafter) exposes the following 'interface' http://www.proxy.com/foo/bar, which it internally translates to coap:///resA. The RXPP might serve resources from multiple resources, but the HTTP client is unaware of this (RXPP appears as origin server). My problem lies with a cross protocol proxy (XPP) with the following interface http://www.proxy.com/.wellknown/core-translate/1.2.3.4_4567/foo/bar?a=3 (which is translated to coap://1.2.3.4:4567/foo/bar?a=3). This is also said to be an example of a reverse proxy (right?). However, in this case the HTTP client is aware that the XPP isn't the origin server, the actual origin server is mentioned in the request, so I would say it resembles a forward XPP. Reading section 10.2 of the core coap spec seems to confirm this (one difference is that the coap scheme is omitted in the 2nd example, but it is implied anyway). Can the authors (or someone else) give clear examples of forward and reverse http/coap cross protocol proxies? Once I better understand the distinction, I hope to do a more thorough review of the draft. Greets, Floris Op zo 24 mrt 2013 23:33:29 CET, Carsten Bormann schreef: > > In Orlando, we said we were trying to increase the level of attention > on the HTTP mapping draft with a view to making it a WG document very > soon. > So, if you have comments on it now, please send them to the list. > We had a few people volunteering to review the draft as a prerequisite > to a call for WG adoption, so please do send in these (short or long, > as you like) reviews. > Of course WG adoption means that the WG starts considering this as a > WG draft, not that we all already agree with every detail, but any > concerns about scoping and general approach should be discussed now. > > Grüße, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Tue Mar 26 08:12:38 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB69321F8B58 for ; Tue, 26 Mar 2013 08:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.646 X-Spam-Level: X-Spam-Status: No, score=-105.646 tagged_above=-999 required=5 tests=[AWL=0.603, 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 0eqFGb1g-Bob for ; Tue, 26 Mar 2013 08:12:38 -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 B70E321F8AC1 for ; Tue, 26 Mar 2013 08:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2QFCUBa003054; Tue, 26 Mar 2013 16:12:30 +0100 (CET) Received: from [192.168.217.135] (p54893BDF.dip.t-dialin.net [84.137.59.223]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C2C483ABC; Tue, 26 Mar 2013 16:12:29 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <5151B631.9050607@intec.ugent.be> Date: Tue, 26 Mar 2013 16:12:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0C9867A6-AED5-4063-88AE-E9D1C6CDE75E@tzi.org> <5151B631.9050607@intec.ugent.be> To: Floris Van den Abeele X-Mailer: Apple Mail (2.1503) Cc: core WG Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 15:12:38 -0000 On Mar 26, 2013, at 15:52, Floris Van den Abeele = wrote: > Can the authors (or someone else) give clear examples of forward and = reverse http/coap cross protocol proxies? core-coap-14 defines: Forward-Proxy A "forward-proxy" is an endpoint selected by a client, usually via local configuration rules, to perform requests on behalf of the client, doing any necessary translations. Some translations are minimal, such as for proxy requests for "coap" URIs, whereas other requests might require translation to and from entirely different application-layer protocols. Reverse-Proxy A "reverse-proxy" is an endpoint that stands in for one or more other server(s) and satisfies requests on behalf of these, doing any necessary translations. Unlike a forward-proxy, the client may not be aware that it is communicating with a reverse-proxy; a reverse-proxy receives requests as if it was the origin server for the target resource. ... and goes on (5.7): In an overall architecture for a Constrained RESTful Environment, proxies can serve quite different purposes. Proxies can be explicitly selected by clients, a role that we term "forward-proxy". Proxies can also be inserted to stand in for origin servers, a role that we term "reverse-proxy". Orthogonal to this distinction, a proxy can map from a CoAP request to a CoAP request (CoAP-to-CoAP proxy) or translate from or to a different protocol ("cross-proxy"). Full definitions of these terms are provided in Section 1.2. Notes: The terminology in this specification has been selected to be culturally compatible with the terminology used in the wider Web application environments, without necessarily matching it in every detail (which may not even be relevant to Constrained RESTful Environments). Not too much semantics should be ascribed to the components of the terms (such as "forward", "reverse", or "cross"). HTTP proxies, besides acting as HTTP proxies, often offer a transport protocol proxying function ("CONNECT") to enable end-to- end transport layer security through the proxy. No such function is defined for CoAP-to-CoAP proxies in this specification, as forwarding of UDP packets is unlikely to be of much value in Constrained RESTful environments. See also Section 10.2.7 for the cross-proxy case. So the point is that a client always knows when it is using a = Forward-Proxy, i.e., it has explicitly chosen to talk to it as opposed = to the origin server. We have the options Proxy-Uri and Proxy-Scheme = that enable to express this choice explicitly: 5.7.2. Forward-Proxies CoAP distinguishes between requests made (as if) to an origin server and a request made through a forward-proxy. CoAP requests to a forward-proxy are made as normal Confirmable or Non-confirmable requests to the forward-proxy endpoint, but specify the request URI in a different way: The request URI in a proxy request is specified as a string in the Proxy-Uri Option (see Section 5.10.2), while the request URI in a request to an origin server is split into the Uri- Host, Uri-Port, Uri-Path and Uri-Query Options (see Section 5.10.1); alternatively the URI in a proxy request can be assembled from a Proxy-Scheme option and the split options mentioned. There is no way in a URI to specify the use of a forward-proxy. Which forward-proxy is used is decided by the client based on local = information (which may include information gleaned from the URI, of = course). The URI continues to looks For a reverse-proxy, the client might be thinking it is talking to the = actual origin server: The URI directly points to the reverse-proxy, but instead of serving its = resource directly, the reverse-proxy defers to an origin server (or = another reverse proxy!). 5.7.3. Reverse-Proxies Reverse-proxies do not make use of the Proxy-Uri or Proxy-Scheme options, but need to determine the destination (next hop) of a request from information in the request and information in their configuration. E.g., a reverse-proxy might offer various resources the existence of which it has learned through resource discovery as if they were its own resources. The reverse-proxy is free to build a namespace for the URIs that identify these resources. A reverse- proxy may also build a namespace that gives the client more control over where the request goes, e.g. by embedding host identifiers and port numbers into the URI path of the resources offered. draft-castellani-core-http-mapping-07.txt also alludes to the fact that = there may be "transparent" (intercepting) entities intervening on the = path to the origin server and acting a bit like reverse-proxies, except = that the network provider has chosen to interpose them as opposed to the = client. Of course, all these types can be combined on a path to an origin = server: A client can use a forward-proxy to talk to a reverse-proxy, = with any number of additional reverse-proxies (and "transparent" = (intercepting) proxies) on the way to the origin server. Maybe draft-castellani-core-http-mapping-07.txt doesn't really need to = define the terms forward-proxy and reverse-proxy, but can reference them = from the core coap spec. "transparent"/intercepting proxies are not = discussed in core-coap, though. Gr=FC=DFe, Carsten From cabo@tzi.org Tue Mar 26 08:18:57 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F34A21F8A3F for ; Tue, 26 Mar 2013 08:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.847 X-Spam-Level: X-Spam-Status: No, score=-105.847 tagged_above=-999 required=5 tests=[AWL=0.402, 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 60ehfDXaCblA for ; Tue, 26 Mar 2013 08:18: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 D64C021F8BFD for ; Tue, 26 Mar 2013 08:18: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.4/8.14.4) with ESMTP id r2QFIrQu015520; Tue, 26 Mar 2013 16:18:53 +0100 (CET) Received: from [192.168.217.135] (p54893BDF.dip.t-dialin.net [84.137.59.223]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 06F963AC5; Tue, 26 Mar 2013 16:18:52 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 26 Mar 2013 16:18:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7002B14B-F4FB-435F-A292-85076468564E@tzi.org> References: <0C9867A6-AED5-4063-88AE-E9D1C6CDE75E@tzi.org> <5151B631.9050607@intec.ugent.be> To: Floris Van den Abeele X-Mailer: Apple Mail (2.1503) Cc: core WG Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 15:18:57 -0000 On Mar 26, 2013, at 16:12, Carsten Bormann wrote: > The URI continues to looks (Apple Mail crashing again and interrupting my thought process. I was trying to say:) The URI continues to look as if the client was directly talking to the = origin server. Gr=FC=DFe, Carsten From cabo@tzi.org Tue Mar 26 08:30:34 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B1321F8C82 for ; Tue, 26 Mar 2013 08:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.947 X-Spam-Level: X-Spam-Status: No, score=-105.947 tagged_above=-999 required=5 tests=[AWL=0.302, 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 SAo+C8NLKF7v for ; Tue, 26 Mar 2013 08:30:34 -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 966F221F8C77 for ; Tue, 26 Mar 2013 08:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2QFUQAZ005525; Tue, 26 Mar 2013 16:30:26 +0100 (CET) Received: from [192.168.217.135] (p54893BDF.dip.t-dialin.net [84.137.59.223]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40BB03AE0; Tue, 26 Mar 2013 16:30:26 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <5151B631.9050607@intec.ugent.be> Date: Tue, 26 Mar 2013 16:30:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8789149E-312B-476D-B68E-FB69F52E75F0@tzi.org> References: <0C9867A6-AED5-4063-88AE-E9D1C6CDE75E@tzi.org> <5151B631.9050607@intec.ugent.be> To: Floris Van den Abeele X-Mailer: Apple Mail (2.1503) Cc: core WG Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 15:30:34 -0000 On Mar 26, 2013, at 15:52, Floris Van den Abeele = wrote: > My problem lies with a cross protocol proxy (XPP) with the following = interface = http://www.proxy.com/.wellknown/core-translate/1.2.3.4_4567/foo/bar?a=3D3 = (which is translated to coap://1.2.3.4:4567/foo/bar?a=3D3). This is also = said to be an example of a reverse proxy (right?). However, in this case = the HTTP client is aware that the XPP isn't the origin server, Actually, it may not be -- this URI may have been supplied by a server = to the client, and clients aren't supposed to be snooping into the = structure of URI path anyway. > the actual origin server is mentioned in the request, so I would say = it resembles a forward XPP. Reading section 10.2 of the core coap spec = seems to confirm this (one difference is that the coap scheme is omitted = in the 2nd example, but it is implied anyway). Defining a convention for how a reverse cross-proxy builds the URIs = under which it offers the resources of an origin server might look like = allowing a client to use the reverse cross-proxy as if it were a = forward-proxy. And that may actually be a benefit of such a convention, = because it is hard to carry forward-proxy configuration information = through client APIs (and, even more, through sequences of prepended = proxies). But I would expect these reverse proxies to make their URIs = available through a resource directory, so there may never be a need for = a client to compute a URI. The convention would then just help in = understanding what is going on, and in sending diagnostic requests to a = reverse cross-proxy. Gr=FC=DFe, Carsten From isam.ishaq@intec.ugent.be Tue Mar 26 08:49:07 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE6A21F88EA for ; Tue, 26 Mar 2013 08:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 eAi+rdPrpWoj for ; Tue, 26 Mar 2013 08:49:03 -0700 (PDT) Received: from smtp3.ugent.be (smtp3.ugent.be [157.193.49.127]) by ietfa.amsl.com (Postfix) with ESMTP id F1D8321F88C6 for ; Tue, 26 Mar 2013 08:49:02 -0700 (PDT) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp3.ugent.be (Postfix) with ESMTP id 5F090C43F for ; Tue, 26 Mar 2013 16:49:02 +0100 (CET) X-Virus-Scanned: by UGent DICT Received: from smtp3.ugent.be ([157.193.49.127]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id y8yTYcv2cuxX for ; Tue, 26 Mar 2013 16:49:00 +0100 (CET) Received: from mail2.intec.ugent.be (mail2.intec.ugent.be [157.193.214.245]) by smtp3.ugent.be (Postfix) with ESMTP id C706EC2AB for ; Tue, 26 Mar 2013 16:49:00 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail2.intec.ugent.be (Postfix) with ESMTP id DC8F121 for ; Tue, 26 Mar 2013 16:49:00 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at intec.ugent.be Received: from mail2.intec.ugent.be ([127.0.0.1]) by localhost (mail2.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lW5lY+yCoRkE for ; Tue, 26 Mar 2013 16:49:00 +0100 (CET) Received: from [127.0.0.1] (unknown [109.130.185.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: iishaq) by mail2.intec.ugent.be (Postfix) with ESMTPSA id A38A51F for ; Tue, 26 Mar 2013 16:49:00 +0100 (CET) Message-ID: <5151C37A.1010205@intec.ugent.be> Date: Tue, 26 Mar 2013 16:49:14 +0100 From: Isam Ishaq User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: core@ietf.org References: <031DD135F9160444ABBE3B0C36CED618BF0286@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618BF0286@011-DB3MPN2-082.MGDPHG.emi.philips.com> Content-Type: multipart/alternative; boundary="------------080704030101000307050705" X-Antivirus: avast! (VPS 130326-0, 03/26/2013), Outbound message X-Antivirus-Status: Clean X-Miltered: at jchkm1 with ID 5151C36C.003 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 5151C36C.003 from mail2.intec.ugent.be/mail2.intec.ugent.be/157.193.214.245/mail2.intec.ugent.be/ X-j-chkmail-Score: MSGID : 5151C36C.003 on smtp3.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Subject: Re: [core] Any experience in using CoAP responses to multicast requests? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 26 Mar 2013 15:49:07 -0000 This is a multi-part message in MIME format. --------------080704030101000307050705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear Esko and all, At iMinds we have some limited experience with multicast in wireless sensor networks. We have used multicast CoAP requests in order to discover sensors inside LLNs. At the networking layer of the LLN the multicast messages were routed as broadcasts. We have conducted our tests using our testbed with real sensor nodes and have experimented with network sizes up to 50 nodes in different network topologies with hop counts between 1 and 5 hops. As expected, the use of multicast/broadcasts proved to be challenging. Even for small sensor networks (10 nodes or less), we had issues with broadcast storms in the network. One reason for these storms was related to routing (a basic AODV implementation in our case). Once the sensor nodes got the multicast and wanted to reply they all started asking for the route to the gateway at the same time, causing the network to become unresponsive. In order to combat this broadcast storms we let the sensor gateway broadcast a route reply packet in the network. This caused all sensors to establish a route to the gateway and eliminated the need for them to start asking for a route once they get the discovery request. In our implementation the boarder router sending the broadcasts was also a constrained device (Tmote Sky). So it could not handle all the replies it got from the other sensors, because they arrived with small time gaps between them. This led to the receive buffer on the boarder router to start dropping packets. To help solving this issue we introduced random delays in the network -- before responding the CoAP requests (Leisure) and before forwarding broadcasts in the network. By using these techniques we improved the delivery of the multicast and the resulting unicast replies very much. Still since multicasts are delivered in a non-confirmable way, there was no way to tell that the multicast did actually get to all nodes. In our case this was ok and just meant that the sensors that did not get the multicast the first time will get it the next time when a new periodic pull for discovery was done. First results of this work have been published in the following paper: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6296943&isnumber=6296822 An extended version of this paper with more experimental results is currently under review. At this moment, we are also exploring the use of an intermediary to offer group communication functionality based on unicast (paper under review). We are also interested comparing this approach with a complete multicast solution for a LLN. Best Regards, Isam Ishaq On 25-Mar-13 10:16 AM, Dijk, Esko wrote: > > Dear all, > > one of the review comments to the GroupComm I-D concerns the lack of > (implementation or simulation) experience with use of CoAP multicast, > and the associated multitude of CoAP responses. The I-D provides > guidelines in this area but not based on such experience. > > Did anyone experiment with CoAP multicast? (Or knows someone, or a > publication etc.) > > regards, > > Esko > > > ------------------------------------------------------------------------ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Isam Ishaq Department of Information Technology Internet Based Communication Networks and Services (IBCN) Ghent University - iMinds Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium M: +32 (0)484 856 155 T: +32 (0)9 33 14946 T Secr: +32 (0)9 33 14900 F: +32 (0)9 33 14899 E: isam.ishaq@intec.UGent.be W : www.ibcn.intec.UGent.be --------------080704030101000307050705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear Esko and all,

At iMinds we have some limited experience with multicast in wireless sensor networks. We have used multicast CoAP requests in order to discover sensors inside LLNs. At the networking layer of the LLN the multicast messages were routed as broadcasts. We have conducted our tests using our testbed with real sensor nodes and have experimented with network sizes up to 50 nodes in different network topologies with hop counts between 1 and 5 hops.

As expected, the use of multicast/broadcasts proved to be challenging.  Even for small sensor networks (10 nodes or less), we had issues with broadcast storms in the network. One reason for these storms was related to routing (a basic AODV implementation in our case). Once the sensor nodes got the multicast and wanted to reply they all started asking for the route to the gateway at the same time, causing the network to become unresponsive. In order to combat this broadcast storms we let the sensor gateway broadcast a route reply packet in the network. This caused all sensors to establish a route to the gateway and eliminated the need for them to start asking for a route once they get the discovery request.

In our implementation the boarder router sending the broadcasts was also a constrained device (Tmote Sky). So it could not handle all the replies it got from the other sensors, because they arrived with small time gaps between them. This led to the receive buffer on the boarder router to start dropping packets. To help solving this issue we introduced random delays in the network – before responding the CoAP requests (Leisure) and before forwarding broadcasts in the network.

By using these techniques we improved the delivery of the multicast and the resulting unicast replies very much. Still since multicasts are delivered in a non-confirmable way, there was no way to tell that the multicast did actually get to all nodes. In our case this was ok and just meant that the sensors that did not get the multicast the first time will get it the next time when a new periodic pull for discovery was done.

First results of this work have been published in the following paper:
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6296943&isnumber=6296822

An extended version of this paper with more experimental results is currently under review. At this moment, we are also exploring the use of an intermediary to offer group communication functionality based on unicast (paper under review). We are also interested comparing this approach with a complete multicast solution for a LLN.

Best Regards,
Isam Ishaq


On 25-Mar-13 10:16 AM, Dijk, Esko wrote:

Dear all,

 

one of the review comments to the GroupComm I-D concerns the lack of (implementation or simulation) experience with use of CoAP multicast, and the associated multitude of CoAP responses. The I-D provides guidelines in this area but not based on such experience.

 

Did anyone experiment with CoAP multicast? (Or knows someone, or a publication etc.)

 

regards,

Esko


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

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



-- 
Isam Ishaq
Department of Information Technology
Internet Based Communication Networks and Services (IBCN)
Ghent University - iMinds 
Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
M: +32 (0)484 856 155
T: +32 (0)9 33 14946
T Secr: +32 (0)9 33 14900
F: +32 (0)9 33 14899
E: isam.ishaq@intec.UGent.be
W : www.ibcn.intec.UGent.be
--------------080704030101000307050705-- From Akbar.Rahman@InterDigital.com Tue Mar 26 10:25:57 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4836021F8C69 for ; Tue, 26 Mar 2013 10:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c007Skp73TYS for ; Tue, 26 Mar 2013 10:25:56 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id B36C621F8BF6 for ; Tue, 26 Mar 2013 10:25:55 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Mar 2013 13:25:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Mar 2013 13:25:53 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Call for reviews of draft-castellani-core-http-mapping Thread-Index: Ac4qNF5ZZcC7d4uKTP2/toIRuljpdwAELCxQ References: <0C9867A6-AED5-4063-88AE-E9D1C6CDE75E@tzi.org><5151B631.9050607@intec.ugent.be> From: "Rahman, Akbar" To: "Carsten Bormann" X-OriginalArrivalTime: 26 Mar 2013 17:25:54.0425 (UTC) FILETIME=[F86C5690:01CE2A46] Cc: core WG Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 17:25:57 -0000 Hi Carsten, With respect to your comment: Maybe draft-castellani-core-http-mapping-07.txt doesn't really need to = define the terms forward-proxy and reverse-proxy, but can reference them = from the core coap spec. "transparent"/intercepting proxies are not = discussed in core-coap, though. Yes, the definition for forward-proxy can be referenced to the coap-14 = I-D. However, the reverse-proxy definition in coap-14 does not = explicitly discuss HTTP-CoAP translation (which is the key point of this = I-D and the reason that we thought it was worthwhile to explicitly = define reverse-proxy in this way in this I-D). Do you agree with this = logic? Best Regards, Akbar -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Carsten Bormann Sent: Tuesday, March 26, 2013 11:12 AM To: Floris Van den Abeele Cc: core WG Subject: Re: [core] Call for reviews of = draft-castellani-core-http-mapping On Mar 26, 2013, at 15:52, Floris Van den Abeele = wrote: > Can the authors (or someone else) give clear examples of forward and = reverse http/coap cross protocol proxies? core-coap-14 defines: Forward-Proxy A "forward-proxy" is an endpoint selected by a client, usually via local configuration rules, to perform requests on behalf of the client, doing any necessary translations. Some translations are minimal, such as for proxy requests for "coap" URIs, whereas other requests might require translation to and from entirely different application-layer protocols. Reverse-Proxy A "reverse-proxy" is an endpoint that stands in for one or more other server(s) and satisfies requests on behalf of these, doing any necessary translations. Unlike a forward-proxy, the client may not be aware that it is communicating with a reverse-proxy; a reverse-proxy receives requests as if it was the origin server for the target resource. ... and goes on (5.7): In an overall architecture for a Constrained RESTful Environment, proxies can serve quite different purposes. Proxies can be explicitly selected by clients, a role that we term "forward-proxy". Proxies can also be inserted to stand in for origin servers, a role that we term "reverse-proxy". Orthogonal to this distinction, a proxy can map from a CoAP request to a CoAP request (CoAP-to-CoAP proxy) or translate from or to a different protocol ("cross-proxy"). Full definitions of these terms are provided in Section 1.2. Notes: The terminology in this specification has been selected to be culturally compatible with the terminology used in the wider Web application environments, without necessarily matching it in every detail (which may not even be relevant to Constrained RESTful Environments). Not too much semantics should be ascribed to the components of the terms (such as "forward", "reverse", or "cross"). HTTP proxies, besides acting as HTTP proxies, often offer a transport protocol proxying function ("CONNECT") to enable end-to- end transport layer security through the proxy. No such function is defined for CoAP-to-CoAP proxies in this specification, as forwarding of UDP packets is unlikely to be of much value in Constrained RESTful environments. See also Section 10.2.7 for the cross-proxy case. So the point is that a client always knows when it is using a = Forward-Proxy, i.e., it has explicitly chosen to talk to it as opposed = to the origin server. We have the options Proxy-Uri and Proxy-Scheme = that enable to express this choice explicitly: 5.7.2. Forward-Proxies CoAP distinguishes between requests made (as if) to an origin server and a request made through a forward-proxy. CoAP requests to a forward-proxy are made as normal Confirmable or Non-confirmable requests to the forward-proxy endpoint, but specify the request URI in a different way: The request URI in a proxy request is specified as a string in the Proxy-Uri Option (see Section 5.10.2), while the request URI in a request to an origin server is split into the Uri- Host, Uri-Port, Uri-Path and Uri-Query Options (see Section 5.10.1); alternatively the URI in a proxy request can be assembled from a Proxy-Scheme option and the split options mentioned. There is no way in a URI to specify the use of a forward-proxy. Which forward-proxy is used is decided by the client based on local = information (which may include information gleaned from the URI, of = course). The URI continues to looks For a reverse-proxy, the client might be thinking it is talking to the = actual origin server: The URI directly points to the reverse-proxy, but instead of serving its = resource directly, the reverse-proxy defers to an origin server (or = another reverse proxy!). 5.7.3. Reverse-Proxies Reverse-proxies do not make use of the Proxy-Uri or Proxy-Scheme options, but need to determine the destination (next hop) of a request from information in the request and information in their configuration. E.g., a reverse-proxy might offer various resources the existence of which it has learned through resource discovery as if they were its own resources. The reverse-proxy is free to build a namespace for the URIs that identify these resources. A reverse- proxy may also build a namespace that gives the client more control over where the request goes, e.g. by embedding host identifiers and port numbers into the URI path of the resources offered. draft-castellani-core-http-mapping-07.txt also alludes to the fact that = there may be "transparent" (intercepting) entities intervening on the = path to the origin server and acting a bit like reverse-proxies, except = that the network provider has chosen to interpose them as opposed to the = client. Of course, all these types can be combined on a path to an origin = server: A client can use a forward-proxy to talk to a reverse-proxy, = with any number of additional reverse-proxies (and "transparent" = (intercepting) proxies) on the way to the origin server. Maybe draft-castellani-core-http-mapping-07.txt doesn't really need to = define the terms forward-proxy and reverse-proxy, but can reference them = from the core coap spec. "transparent"/intercepting proxies are not = discussed in core-coap, though. Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From esko.dijk@philips.com Wed Mar 27 01:26:49 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183F121F90A4 for ; Wed, 27 Mar 2013 01:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[AWL=1.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhiPdqZpHOnU for ; Wed, 27 Mar 2013 01:26:48 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id DEC2621F906A for ; Wed, 27 Mar 2013 01:26:46 -0700 (PDT) Received: from mail21-co9-R.bigfish.com (10.236.132.250) by CO9EHSOBE005.bigfish.com (10.236.130.68) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Mar 2013 08:26:45 +0000 Received: from mail21-co9 (localhost [127.0.0.1]) by mail21-co9-R.bigfish.com (Postfix) with ESMTP id 8CD68C00C7; Wed, 27 Mar 2013 08:26:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -34 X-BigFish: VPS-34(zz98dI15d6O9371I9251Jc89bh542I14ffI217bIzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail21-co9 (localhost.localdomain [127.0.0.1]) by mail21-co9 (MessageSwitch) id 1364372804524646_9293; Wed, 27 Mar 2013 08:26:44 +0000 (UTC) Received: from CO9EHSMHS011.bigfish.com (unknown [10.236.132.230]) by mail21-co9.bigfish.com (Postfix) with ESMTP id 7CED11C0333; Wed, 27 Mar 2013 08:26:44 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS011.bigfish.com (10.236.130.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Mar 2013 08:26:43 +0000 Received: from 011-DB3MMR1-021.MGDPHG.emi.philips.com (10.128.28.103) by 011-DB3MMR1-006.MGDPHG.emi.philips.com (10.128.28.56) with Microsoft SMTP Server (TLS) id 14.2.328.11; Wed, 27 Mar 2013 08:26:16 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.99]) by 011-DB3MMR1-021.MGDPHG.emi.philips.com ([fe80::f066:9203:e7da:3658%11]) with mapi id 14.02.0328.011; Wed, 27 Mar 2013 08:26:16 +0000 From: "Dijk, Esko" To: "Rahman, Akbar" , Carsten Bormann , Floris Van den Abeele Thread-Topic: [core] Call for reviews of draft-castellani-core-http-mapping Thread-Index: AQHOKN+l05uJa1Rmo0etQcuHR51NeJi4EViAgAAFkoCAACVFgIAA86Rw Date: Wed, 27 Mar 2013 08:26:15 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618BF6A00@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <0C9867A6-AED5-4063-88AE-E9D1C6CDE75E@tzi.org><5151B631.9050607@intec.ugent.be> 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.103] 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] Call for reviews of draft-castellani-core-http-mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 08:26:49 -0000 Hi all, In my view it would be best to base ourselves on the coap-14 definitions. T= hese already mention that translations between protocols can be done, so th= at should be ok for our HTTP-CoAP translation purpose. But I agree with Akb= ar we still should have some text in draft-castellani-core-http-mapping tha= t shows what the general definitions mean when applied to HTTP-to-CoAP requ= est translation. However, there was some discussion among the authors of draft-castellani-co= re-http-mapping about one part of the coap-14 definition: "Unlike a forward-proxy, the client may not be aware that it is communicat= ing with a reverse-proxy;" This was considered too vague. The client's "awareness" is not something wh= ere we can technically distinguish forward/reverse proxies. The second part= of the sentence is more useful: " a reverse-proxy receives requests as if it was the origin server for th= e target resource". This is also what the longer definition in draft-castellani-core-http-mappi= ng tries to say. And [I-D.ietf-httpbis-p1-messaging] also defines the disti= nction in this manner. Floris, I hope this makes the distinction clear? In = a next version we could refer to the coap-14 definitions and add some text = that applies these in the specific HTTP-CoAP translation context. So the authors value a clear technical distinction between forward and reve= rse proxy without having to debate on "awareness" and whether the client ca= n or will do URI structure interpretation. regards, Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Rah= man, Akbar Sent: Tuesday, March 26, 2013 18:26 To: Carsten Bormann Cc: core WG Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping Hi Carsten, With respect to your comment: Maybe draft-castellani-core-http-mapping-07.txt doesn't really need= to define the terms forward-proxy and reverse-proxy, but can reference the= m from the core coap spec. "transparent"/intercepting proxies are = not discussed in core-coap, though. Yes, the definition for forward-proxy can be referenced to the coap-14 I-D.= However, the reverse-proxy definition in coap-14 does not explicitly disc= uss HTTP-CoAP translation (which is the key point of this I-D and the reaso= n that we thought it was worthwhile to explicitly define reverse-proxy in t= his way in this I-D). Do you agree with this logic? Best Regards, Akbar -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Car= sten Bormann Sent: Tuesday, March 26, 2013 11:12 AM To: Floris Van den Abeele Cc: core WG Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping On Mar 26, 2013, at 15:52, Floris Van den Abeele wrote: > Can the authors (or someone else) give clear examples of forward and reve= rse http/coap cross protocol proxies? core-coap-14 defines: Forward-Proxy A "forward-proxy" is an endpoint selected by a client, usually via local configuration rules, to perform requests on behalf of the client, doing any necessary translations. Some translations are minimal, such as for proxy requests for "coap" URIs, whereas other requests might require translation to and from entirely different application-layer protocols. Reverse-Proxy A "reverse-proxy" is an endpoint that stands in for one or more other server(s) and satisfies requests on behalf of these, doing any necessary translations. Unlike a forward-proxy, the client may not be aware that it is communicating with a reverse-proxy; a reverse-proxy receives requests as if it was the origin server for the target resource. ... and goes on (5.7): In an overall architecture for a Constrained RESTful Environment, proxies can serve quite different purposes. Proxies can be explicitly selected by clients, a role that we term "forward-proxy". Proxies can also be inserted to stand in for origin servers, a role that we term "reverse-proxy". Orthogonal to this distinction, a proxy can map from a CoAP request to a CoAP request (CoAP-to-CoAP proxy) or translate from or to a different protocol ("cross-proxy"). Full definitions of these terms are provided in Section 1.2. Notes: The terminology in this specification has been selected to be culturally compatible with the terminology used in the wider Web application environments, without necessarily matching it in every detail (which may not even be relevant to Constrained RESTful Environments). Not too much semantics should be ascribed to the components of the terms (such as "forward", "reverse", or "cross"). HTTP proxies, besides acting as HTTP proxies, often offer a transport protocol proxying function ("CONNECT") to enable end-to- end transport layer security through the proxy. No such function is defined for CoAP-to-CoAP proxies in this specification, as forwarding of UDP packets is unlikely to be of much value in Constrained RESTful environments. See also Section 10.2.7 for the cross-proxy case. So the point is that a client always knows when it is using a Forward-Proxy= , i.e., it has explicitly chosen to talk to it as opposed to the origin ser= ver. We have the options Proxy-Uri and Proxy-Scheme that enable to express= this choice explicitly: 5.7.2. Forward-Proxies CoAP distinguishes between requests made (as if) to an origin server and a request made through a forward-proxy. CoAP requests to a forward-proxy are made as normal Confirmable or Non-confirmable requests to the forward-proxy endpoint, but specify the request URI in a different way: The request URI in a proxy request is specified as a string in the Proxy-Uri Option (see Section 5.10.2), while the request URI in a request to an origin server is split into the Uri- Host, Uri-Port, Uri-Path and Uri-Query Options (see Section 5.10.1); alternatively the URI in a proxy request can be assembled from a Proxy-Scheme option and the split options mentioned. There is no way in a URI to specify the use of a forward-proxy. Which forward-proxy is used is decided by the client based on local informa= tion (which may include information gleaned from the URI, of course). The = URI continues to looks For a reverse-proxy, the client might be thinking it is talking to the actu= al origin server: The URI directly points to the reverse-proxy, but instead of serving its re= source directly, the reverse-proxy defers to an origin server (or another r= everse proxy!). 5.7.3. Reverse-Proxies Reverse-proxies do not make use of the Proxy-Uri or Proxy-Scheme options, but need to determine the destination (next hop) of a request from information in the request and information in their configuration. E.g., a reverse-proxy might offer various resources the existence of which it has learned through resource discovery as if they were its own resources. The reverse-proxy is free to build a namespace for the URIs that identify these resources. A reverse- proxy may also build a namespace that gives the client more control over where the request goes, e.g. by embedding host identifiers and port numbers into the URI path of the resources offered. draft-castellani-core-http-mapping-07.txt also alludes to the fact that the= re may be "transparent" (intercepting) entities intervening on the path to = the origin server and acting a bit like reverse-proxies, except that the ne= twork provider has chosen to interpose them as opposed to the client. Of course, all these types can be combined on a path to an origin server: A= client can use a forward-proxy to talk to a reverse-proxy, with any number= of additional reverse-proxies (and "transparent" (intercepting) proxies) o= n the way to the origin server. Maybe draft-castellani-core-http-mapping-07.txt doesn't really need to defi= ne the terms forward-proxy and reverse-proxy, but can reference them from t= he core coap spec. "transparent"/intercepting proxies are not discussed in= core-coap, though. Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ 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 Wed Mar 27 07:04:44 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B901B21F8E6C for ; Wed, 27 Mar 2013 07:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-0.334, 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 2WMxrHMxStyY for ; Wed, 27 Mar 2013 07:04:41 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 745F421F8B61 for ; Wed, 27 Mar 2013 07:04:41 -0700 (PDT) Received: from mail167-co1-R.bigfish.com (10.243.78.254) by CO1EHSOBE026.bigfish.com (10.243.66.89) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Mar 2013 14:04:39 +0000 Received: from mail167-co1 (localhost [127.0.0.1]) by mail167-co1-R.bigfish.com (Postfix) with ESMTP id 4A13E580209; Wed, 27 Mar 2013 14:04:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -32 X-BigFish: VPS-32(zz98dI15d6O9371I9251Jc85fh217bIzz1f42h1fc6h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah18c673h1954cbh18602eh8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1155h) Received: from mail167-co1 (localhost.localdomain [127.0.0.1]) by mail167-co1 (MessageSwitch) id 1364393076599310_12054; Wed, 27 Mar 2013 14:04:36 +0000 (UTC) Received: from CO1EHSMHS007.bigfish.com (unknown [10.243.78.249]) by mail167-co1.bigfish.com (Postfix) with ESMTP id 8CFE75C004A; Wed, 27 Mar 2013 14:04:36 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS007.bigfish.com (10.243.66.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Mar 2013 14:04:35 +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.2.328.11; Wed, 27 Mar 2013 14:04:19 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.99]) by 011-DB3MMR1-023.MGDPHG.emi.philips.com ([fe80::e485:97aa:9b41:86e3%11]) with mapi id 14.02.0328.011; Wed, 27 Mar 2013 14:04:19 +0000 From: "Dijk, Esko" To: Isam Ishaq , "core@ietf.org" Thread-Topic: [core] Any experience in using CoAP responses to multicast requests? Thread-Index: AQHOKjmBchpIVeX/tUC5di2JAdx13pi5kPdA Date: Wed, 27 Mar 2013 14:04:17 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618BF6B53@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618BF0286@011-DB3MPN2-082.MGDPHG.emi.philips.com> <5151C37A.1010205@intec.ugent.be> In-Reply-To: <5151C37A.1010205@intec.ugent.be> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618BF6B53011DB3MPN2082MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] Any experience in using CoAP responses to multicast requests? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 27 Mar 2013 14:04:44 -0000 --_000_031DD135F9160444ABBE3B0C36CED618BF6B53011DB3MPN2082MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Isam, It's good to hear that the two measures (CoAP Leisure + random delay in for= warding) solved the issue. CoAP server implementations SHOULD use the Leisu= re, and the random forwarding delay is also applied in the Multicast Protoc= ol for Low-power lossy networks (MPL) of the RoLL Working Group. I would be interested to hear about the extended paper as well, when it is = published. regards, Esko From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Isa= m Ishaq Sent: Tuesday, March 26, 2013 16:49 To: core@ietf.org Subject: Re: [core] Any experience in using CoAP responses to multicast req= uests? Dear Esko and all, At iMinds we have some limited experience with multicast in wireless sensor= networks. We have used multicast CoAP requests in order to discover sensor= s inside LLNs. At the networking layer of the LLN the multicast messages we= re routed as broadcasts. We have conducted our tests using our testbed with= real sensor nodes and have experimented with network sizes up to 50 nodes = in different network topologies with hop counts between 1 and 5 hops. As expected, the use of multicast/broadcasts proved to be challenging. Eve= n for small sensor networks (10 nodes or less), we had issues with broadcas= t storms in the network. One reason for these storms was related to routing= (a basic AODV implementation in our case). Once the sensor nodes got the m= ulticast and wanted to reply they all started asking for the route to the g= ateway at the same time, causing the network to become unresponsive. In ord= er to combat this broadcast storms we let the sensor gateway broadcast a ro= ute reply packet in the network. This caused all sensors to establish a rou= te to the gateway and eliminated the need for them to start asking for a ro= ute once they get the discovery request. In our implementation the boarder router sending the broadcasts was also a = constrained device (Tmote Sky). So it could not handle all the replies it g= ot from the other sensors, because they arrived with small time gaps betwee= n them. This led to the receive buffer on the boarder router to start dropp= ing packets. To help solving this issue we introduced random delays in the = network - before responding the CoAP requests (Leisure) and before forwardi= ng broadcasts in the network. By using these techniques we improved the delivery of the multicast and the= resulting unicast replies very much. Still since multicasts are delivered = in a non-confirmable way, there was no way to tell that the multicast did a= ctually get to all nodes. In our case this was ok and just meant that the s= ensors that did not get the multicast the first time will get it the next t= ime when a new periodic pull for discovery was done. First results of this work have been published in the following paper: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D6296943&isnumbe= r=3D6296822 An extended version of this paper with more experimental results is current= ly under review. At this moment, we are also exploring the use of an interm= ediary to offer group communication functionality based on unicast (paper u= nder review). We are also interested comparing this approach with a complet= e multicast solution for a LLN. Best Regards, Isam Ishaq On 25-Mar-13 10:16 AM, Dijk, Esko wrote: Dear all, one of the review comments to the GroupComm I-D concerns the lack of (imple= mentation or simulation) experience with use of CoAP multicast, and the ass= ociated multitude of CoAP responses. The I-D provides guidelines in this ar= ea but not based on such experience. Did anyone experiment with CoAP multicast? (Or knows someone, or a publicat= ion etc.) regards, Esko ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core -- Isam Ishaq Department of Information Technology Internet Based Communication Networks and Services (IBCN) Ghent University - iMinds Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium M: +32 (0)484 856 155 T: +32 (0)9 33 14946 T Secr: +32 (0)9 33 14900 F: +32 (0)9 33 14899 E: isam.ishaq@intec.UGent.be W : www.ibcn.intec.UGent.be --_000_031DD135F9160444ABBE3B0C36CED618BF6B53011DB3MPN2082MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Isam,

 

It’s good to hea= r that the two measures (CoAP Leisure + random delay in forwarding) sol= ved the issue. CoAP server implementations SHOULD use the Leisure, and the = random forwarding delay is also applied in the Multicast Protocol for Low-power lossy networks (MPL) of the RoLL Working = Group.

 

I would be interested = to hear about the extended paper as well, when it is published.<= /span>

 

regards,

Esko=

 

From: core-bounces@ietf.org [mailto:core-bounces@ietf.o= rg] On Behalf Of Isam Ishaq
Sent: Tuesday, March 26, 2013 16:49
To: core@ietf.org
Subject: Re: [core] Any experience in using CoAP responses to multic= ast requests?

 

Dear Esko and all,

At iMinds we have some limited experience with multicast in wireless sensor= networks. We have used multicast CoAP requests in order to discover sensor= s inside LLNs. At the networking layer of the LLN the multicast messages we= re routed as broadcasts. We have conducted our tests using our testbed with real sensor nodes and have expe= rimented with network sizes up to 50 nodes in different network topologies = with hop counts between 1 and 5 hops.

As expected, the use of multicast/broadcasts proved to be challenging. = ; Even for small sensor networks (10 nodes or less), we had issues with bro= adcast storms in the network. One reason for these storms was related to ro= uting (a basic AODV implementation in our case). Once the sensor nodes got the multicast and wanted to reply the= y all started asking for the route to the gateway at the same time, causing= the network to become unresponsive. In order to combat this broadcast stor= ms we let the sensor gateway broadcast a route reply packet in the network. This caused all sensors to establish = a route to the gateway and eliminated the need for them to start asking for= a route once they get the discovery request.

In our implementation the boarder router sending the broadcasts was also a = constrained device (Tmote Sky). So it could not handle all the replies it g= ot from the other sensors, because they arrived with small time gaps betwee= n them. This led to the receive buffer on the boarder router to start dropping packets. To help solving th= is issue we introduced random delays in the network – before respondi= ng the CoAP requests (Leisure) and before forwa= rding broadcasts in the network.


By using these techniques we improved the delivery of the multicast and the= resulting unicast replies very much. Still since multicasts are delivered = in a non-confirmable way, there was no way to tell that the multicast did a= ctually get to all nodes. In our case this was ok and just meant that the sensors that did not get the mult= icast the first time will get it the next time when a new periodic pull for= discovery was done.

First results of this work have been published in the following paper:
http://ieeexplore.ieee.org/stamp/stamp.jsp?= tp=3D&arnumber=3D6296943&isnumber=3D6296822

An extended version of this paper with more experimental results is current= ly under review. At this moment, we are also exploring the use of an interm= ediary to offer group communication functionality based on unicast (paper u= nder review). We are also interested comparing this approach with a complete multicast solution for a LLN.

Best Regards,
Isam Ishaq



On 25-Mar-13 10:16 AM, Dijk, Esko wrote:

Dear all,

 

one of the review comments to the GroupComm I-D conc= erns the lack of (implementation or simulation) experience with use of CoAP= multicast, and the associated multitude of CoAP responses. The I-D provide= s guidelines in this area but not based on such experience.

 

Did anyone experiment with CoAP multicast? (Or knows= someone, or a publication etc.)

 

regards,

Esko

 

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



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




-- 
Isam Ishaq
Department of Information Technology
Internet Based Communication Networks and Services (IBCN)

Ghent University - iMinds 


Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium


M: +32 (0)484 856 155


T: +32 (0)9 33 14946


T Secr: +32 (0)9 33 14900


F: +32 (0)9 33 14899


E: isam.ishaq@intec.UGent=
.be


W : www.ibcn.intec.UGent.be=
--_000_031DD135F9160444ABBE3B0C36CED618BF6B53011DB3MPN2082MGDP_-- From esko.dijk@philips.com Wed Mar 27 08:37:31 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DB221F9158 for ; Wed, 27 Mar 2013 08:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 z3xxdEmJgM16 for ; Wed, 27 Mar 2013 08:37:24 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 00C9D21F9141 for ; Wed, 27 Mar 2013 08:37:23 -0700 (PDT) Received: from mail36-co1-R.bigfish.com (10.243.78.249) by CO1EHSOBE021.bigfish.com (10.243.66.84) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Mar 2013 15:37:23 +0000 Received: from mail36-co1 (localhost [127.0.0.1]) by mail36-co1-R.bigfish.com (Postfix) with ESMTP id EBCBF24019F; Wed, 27 Mar 2013 15:37:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -35 X-BigFish: VPS-35(zz98dI15d6O9371I9251Jc89bh542Ic85dh1432I14ffIdb82h217bIzz1f42h1fc6h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah18c673h8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1155h) Received: from mail36-co1 (localhost.localdomain [127.0.0.1]) by mail36-co1 (MessageSwitch) id 1364398640792999_23334; Wed, 27 Mar 2013 15:37:20 +0000 (UTC) Received: from CO1EHSMHS003.bigfish.com (unknown [10.243.78.243]) by mail36-co1.bigfish.com (Postfix) with ESMTP id B72D6400058; Wed, 27 Mar 2013 15:37:20 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS003.bigfish.com (10.243.66.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Mar 2013 15:37:18 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.99]) by 011-DB3MMR1-002.MGDPHG.emi.philips.com ([10.128.28.52]) with mapi id 14.02.0328.011; Wed, 27 Mar 2013 15:36:41 +0000 From: "Dijk, Esko" To: Kerry Lynn Thread-Topic: [core] Call for reviews of draft-castellani-core-http-mapping Thread-Index: AQHOKN+l05uJa1Rmo0etQcuHR51NeJi4EViAgAAFkoCAACVFgIAA86RwgAB8cQCAAAKn4A== Date: Wed, 27 Mar 2013 15:36:41 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618BF6C40@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <0C9867A6-AED5-4063-88AE-E9D1C6CDE75E@tzi.org> <5151B631.9050607@intec.ugent.be> <031DD135F9160444ABBE3B0C36CED618BF6A00@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618BF6C40011DB3MPN2082MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core \(core@ietf.org\)" Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 15:37:31 -0000 --_000_031DD135F9160444ABBE3B0C36CED618BF6C40011DB3MPN2082MGDP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Kerry wrote:] > I'm not clear on how the term "awareness" is applied, but it seems that s= electing a forward > proxy is typically a configuration setting on the client. Perhaps config= uration is a distinction > that can be made between the forward and reverse proxy types? "Awareness= " may also > indicate that a known cross-proxy sits between the client and the data; i= n this case the client > specifies the path to the proxy as well as the origin server? Hi Kerry, using configuration (in general) as the distinguishing factor has some issu= es. I see now that coap-14 also uses this distinction in page 7 "Forward-Pr= oxy" definition, so the issue is there as well. For example, a client may be configured to access a proxy using HTTP syntax= for origin servers. Then the HTTP-to-CoAP proxy can not "see" from a reque= st whether the client is configured to do this, or if the client just got a= URL from someone and the client isn't configured to do anything special, i= t is just requesting the URL. So, the proxy can't detect whether it should = be a forward proxy or a reverse proxy. So this collapses both definitions i= nto one: the proxy is both at the same time! Any distinction should rather be a clear technical difference in the proxy = itself. (And this is how coap-14 "Reverse-Proxy" page 7 and httpbis-p1-mess= aging currently define it.) Thus the proposal in context of HTTP-CoAP mapping: if a proxy accepts HTTP = requests in the HTTP syntax for origin servers (i.e. as an origin server), = then we call it reverse proxy. If a proxy accepts HTTP requests in the HTTP proxy syntax, then we call it = forward proxy. (Described in section 10.2 of coap-14) If it accepts both, then it is both a reverse and forward proxy combined in= one device. regards, Esko From: kerlyn2001@gmail.com [mailto:kerlyn2001@gmail.com] On Behalf Of Kerry= Lynn Sent: Wednesday, March 27, 2013 16:23 To: Dijk, Esko Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping On Wed, Mar 27, 2013 at 4:26 AM, Dijk, Esko > wrote: Hi all, In my view it would be best to base ourselves on the coap-14 definitions. T= hese already mention that translations between protocols can be done, so th= at should be ok for our HTTP-CoAP translation purpose. But I agree with Akb= ar we still should have some text in draft-castellani-core-http-mapping tha= t shows what the general definitions mean when applied to HTTP-to-CoAP requ= est translation. However, there was some discussion among the authors of draft-castellani-co= re-http-mapping about one part of the coap-14 definition: "Unlike a forward-proxy, the client may not be aware that it is communicat= ing with a reverse-proxy;" This was considered too vague. The client's "awareness" is not something wh= ere we can technically distinguish forward/reverse proxies. The second part= of the sentence is more useful: " a reverse-proxy receives requests as if it was the origin server for th= e target resource". This is also what the longer definition in draft-castellani-core-http-mappi= ng tries to say. And [I-D.ietf-httpbis-p1-messaging] also defines the disti= nction in this manner. Floris, I hope this makes the distinction clear? In = a next version we could refer to the coap-14 definitions and add some text = that applies these in the specific HTTP-CoAP translation context. So the authors value a clear technical distinction between forward and reve= rse proxy without having to debate on "awareness" and whether the client ca= n or will do URI structure interpretation. I'm not clear on how the term "awareness" is applied, but it seems that sel= ecting a forward proxy is typically a configuration setting on the client. Perhaps configur= ation is a distinction that can be made between the forward and reverse proxy types? "Awareness" = may also indicate that a known cross-proxy sits between the client and the data; in = this case the client specifies the path to the proxy as well as the origin server? -K- regards, Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-boun= ces@ietf.org] On Behalf Of Rahman, Akbar Sent: Tuesday, March 26, 2013 18:26 To: Carsten Bormann Cc: core WG Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping Hi Carsten, With respect to your comment: Maybe draft-castellani-core-http-mapping-07.txt doesn't really need= to define the terms forward-proxy and reverse-proxy, but can reference the= m from the core coap spec. "transparent"/intercepting proxies are = not discussed in core-coap, though. Yes, the definition for forward-proxy can be referenced to the coap-14 I-D.= However, the reverse-proxy definition in coap-14 does not explicitly disc= uss HTTP-CoAP translation (which is the key point of this I-D and the reaso= n that we thought it was worthwhile to explicitly define reverse-proxy in t= his way in this I-D). Do you agree with this logic? Best Regards, Akbar -----Original Message----- From: core-bounces@ietf.org [mailto:core-boun= ces@ietf.org] On Behalf Of Carsten Bormann Sent: Tuesday, March 26, 2013 11:12 AM To: Floris Van den Abeele Cc: core WG Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping On Mar 26, 2013, at 15:52, Floris Van den Abeele > wrote: > Can the authors (or someone else) give clear examples of forward and reve= rse http/coap cross protocol proxies? core-coap-14 defines: Forward-Proxy A "forward-proxy" is an endpoint selected by a client, usually via local configuration rules, to perform requests on behalf of the client, doing any necessary translations. Some translations are minimal, such as for proxy requests for "coap" URIs, whereas other requests might require translation to and from entirely different application-layer protocols. Reverse-Proxy A "reverse-proxy" is an endpoint that stands in for one or more other server(s) and satisfies requests on behalf of these, doing any necessary translations. Unlike a forward-proxy, the client may not be aware that it is communicating with a reverse-proxy; a reverse-proxy receives requests as if it was the origin server for the target resource. ... and goes on (5.7): In an overall architecture for a Constrained RESTful Environment, proxies can serve quite different purposes. Proxies can be explicitly selected by clients, a role that we term "forward-proxy". Proxies can also be inserted to stand in for origin servers, a role that we term "reverse-proxy". Orthogonal to this distinction, a proxy can map from a CoAP request to a CoAP request (CoAP-to-CoAP proxy) or translate from or to a different protocol ("cross-proxy"). Full definitions of these terms are provided in Section 1.2. Notes: The terminology in this specification has been selected to be culturally compatible with the terminology used in the wider Web application environments, without necessarily matching it in every detail (which may not even be relevant to Constrained RESTful Environments). Not too much semantics should be ascribed to the components of the terms (such as "forward", "reverse", or "cross"). HTTP proxies, besides acting as HTTP proxies, often offer a transport protocol proxying function ("CONNECT") to enable end-to- end transport layer security through the proxy. No such function is defined for CoAP-to-CoAP proxies in this specification, as forwarding of UDP packets is unlikely to be of much value in Constrained RESTful environments. See also Section 10.2.7 for the cross-proxy case. So the point is that a client always knows when it is using a Forward-Proxy= , i.e., it has explicitly chosen to talk to it as opposed to the origin ser= ver. We have the options Proxy-Uri and Proxy-Scheme that enable to express= this choice explicitly: 5.7.2. Forward-Proxies CoAP distinguishes between requests made (as if) to an origin server and a request made through a forward-proxy. CoAP requests to a forward-proxy are made as normal Confirmable or Non-confirmable requests to the forward-proxy endpoint, but specify the request URI in a different way: The request URI in a proxy request is specified as a string in the Proxy-Uri Option (see Section 5.10.2), while the request URI in a request to an origin server is split into the Uri- Host, Uri-Port, Uri-Path and Uri-Query Options (see Section 5.10.1); alternatively the URI in a proxy request can be assembled from a Proxy-Scheme option and the split options mentioned. There is no way in a URI to specify the use of a forward-proxy. Which forward-proxy is used is decided by the client based on local informa= tion (which may include information gleaned from the URI, of course). The = URI continues to looks For a reverse-proxy, the client might be thinking it is talking to the actu= al origin server: The URI directly points to the reverse-proxy, but instead of serving its re= source directly, the reverse-proxy defers to an origin server (or another r= everse proxy!). 5.7.3. Reverse-Proxies Reverse-proxies do not make use of the Proxy-Uri or Proxy-Scheme options, but need to determine the destination (next hop) of a request from information in the request and information in their configuration. E.g., a reverse-proxy might offer various resources the existence of which it has learned through resource discovery as if they were its own resources. The reverse-proxy is free to build a namespace for the URIs that identify these resources. A reverse- proxy may also build a namespace that gives the client more control over where the request goes, e.g. by embedding host identifiers and port numbers into the URI path of the resources offered. draft-castellani-core-http-mapping-07.txt also alludes to the fact that the= re may be "transparent" (intercepting) entities intervening on the path to = the origin server and acting a bit like reverse-proxies, except that the ne= twork provider has chosen to interpose them as opposed to the client. Of course, all these types can be combined on a path to an origin server: A= client can use a forward-proxy to talk to a reverse-proxy, with any number= of additional reverse-proxies (and "transparent" (intercepting) proxies) o= n the way to the origin server. Maybe draft-castellani-core-http-mapping-07.txt doesn't really need to defi= ne the terms forward-proxy and reverse-proxy, but can reference them from t= he core coap spec. "transparent"/intercepting proxies are not discussed in= core-coap, though. Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ 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. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --_000_031DD135F9160444ABBE3B0C36CED618BF6C40011DB3MPN2082MGDP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

[Kerry wrote:]

> I'm not clear on how the term "awareness&q= uot; is applied, but it seems that selecting a forward
> proxy is typically a configuration setting on the client.  Perhap= s configuration is a distinction
> that can be made between the forward and reverse proxy types?  &q= uot;Awareness" may also
> indicate that a known cross-proxy sits between the client and the data= ; in this case the client
> specifies the path to the proxy as well as the origin server?

Hi Kerry,

 <= /p>

using configuration (in g= eneral) as the distinguishing factor has some issues. I see now that coap-1= 4 also uses this distinction in page 7 “Forward-Proxy” definiti= on, so the issue is there as well.

 <= /p>

For example, a client may= be configured to access a proxy using HTTP syntax for origin servers. Then= the HTTP-to-CoAP proxy can not “see” from a request whether the client is configured to do this, or if the client just got a URL from = someone and the client isn’t configured to do anything special, it is= just requesting the URL. So, the proxy can’t detect whether it shoul= d be a forward proxy or a reverse proxy. So this collapses both definitions into one: the proxy is both at the same ti= me!

 <= /p>

Any distinction should ra= ther be a clear technical difference in the proxy itself. (And this is how = coap-14 “Reverse-Proxy” page 7 and httpbis-p1-messaging currently define it.)

Thus the proposal in cont= ext of HTTP-CoAP mapping: if a proxy accepts HTTP requests in the HTTP synt= ax for origin servers (i.e. as an origin server), then we call it reverse proxy.

If a proxy accepts HTTP r= equests in the HTTP proxy syntax, then we call it forward proxy. (Described= in section 10.2 of coap-14)

If it accepts both, then = it is both a reverse and forward proxy combined in one device.

 <= /p>

regards,

Esko

 <= /p>

 <= /p>

From: kerlyn20= 01@gmail.com [mailto:kerlyn2001@gmail.com] On Behalf Of Kerry Lynn
Sent: Wednesday, March 27, 2013 16:23
To: Dijk, Esko
Subject: Re: [core] Call for reviews of draft-castellani-core-http-m= apping

 

 

On Wed, Mar 27, 2013 at 4:26 AM, Dijk, Esko <esko.dijk@philips.co= m> wrote:

Hi all,

In my view it would be best to base ourselves on the coap-14 definitions. T= hese already mention that translations between protocols can be done, so th= at should be ok for our HTTP-CoAP translation purpose. But I agree with Akb= ar we still should have some text in draft-castellani-core-http-mapping that shows what the general definiti= ons mean when applied to HTTP-to-CoAP request translation.

However, there was some discussion among the authors of draft-castellani-co= re-http-mapping about one part of the coap-14 definition:

 "Unlike a = forward-proxy, the client may not be aware that it is communicating with a = reverse-proxy;"

This was considered too vague. The client's "aw= areness" is not something where we can technically distinguish forward= /reverse proxies. The second part of the sentence is more useful:

 " a  reverse-proxy receives requests= as if it was the origin server for the target resource".

This is also what the= longer definition in draft-castellani-core-http-mapping tries to say. And = [I-D.ietf-httpbis-p1-messaging] also defines the distinction in this manner= . Floris, I hope this makes the distinction clear? In a next version we could refer to the coap-14 definitions and add= some text that applies these in the specific HTTP-CoAP translation context= .

So the authors value a clear technical distinction between forward and reve= rse proxy without having to debate on "awareness" and whether the= client can or will do URI structure interpretation.

I'm not clear on how = the term "awareness" is applied, but it seems that selecting a fo= rward
proxy is typically a configuration setting on the client.  Perhaps con= figuration is a distinction
that can be made between the forward and reverse proxy types?  "A= wareness" may also
indicate that a known cross-proxy sits between the client and the data; in = this case the client
specifies the path to the proxy as well as the origin server?

-K-

regards,
Esko




-----Original Message-----
From: core-bounces@ietf.org [m= ailto:core-bounces@ietf.org] O= n Behalf Of Rahman, Akbar
Sent: Tuesday, March 26, 2013 18:26
To: Carsten Bormann
Cc: core WG
Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping<= br>
Hi Carsten,


With respect to your comment:

        Maybe draft-castellani-core-http-mapping-07.txt= doesn't really need to define the terms forward-proxy and reverse-proxy, b= ut can reference them         from the core coap spec. =  "transparent"/intercepting proxies are not discussed in cor= e-coap, though.


Yes, the definition for forward-proxy can be referenced to the coap-14 I-D.=  However, the reverse-proxy definition in coap-14 does not explicitly= discuss HTTP-CoAP translation (which is the key point of this I-D and the = reason that we thought it was worthwhile to explicitly define reverse-proxy in this way in this I-D).  Do you = agree with this logic?




Best Regards,


Akbar


-----Original Message-----
From: core-bounces@ietf.org [m= ailto:core-bounces@ietf.org] O= n Behalf Of Carsten Bormann
Sent: Tuesday, March 26, 2013 11:12 AM
To: Floris Van den Abeele
Cc: core WG
Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping<= br>
On Mar 26, 2013, at 15:52, Floris Van den Abeele <floris.vandenabeele@intec.ugent.be> = wrote:

> Can the authors (or someone else) give clear examples of forward and r= everse http/coap cross protocol proxies?

core-coap-14 defines:


   Forward-Proxy
      A "forward-proxy" is an endpoint selected by= a client, usually via
      local configuration rules, to perform requests on beha= lf of the
      client, doing any necessary translations.  Some t= ranslations are
      minimal, such as for proxy requests for "coap&quo= t; URIs, whereas other
      requests might require translation to and from entirel= y different
      application-layer protocols.

   Reverse-Proxy
      A "reverse-proxy" is an endpoint that stands= in for one or more
      other server(s) and satisfies requests on behalf of th= ese, doing
      any necessary translations.  Unlike a forward-pro= xy, the client
      may not be aware that it is communicating with a rever= se-proxy; a
      reverse-proxy receives requests as if it was the origi= n server for
      the target resource.

... and goes on (5.7):

   In an overall architecture for a Constrained RESTful Environme= nt,
   proxies can serve quite different purposes.  Proxies can = be
   explicitly selected by clients, a role that we term "forw= ard-proxy".
   Proxies can also be inserted to stand in for origin servers, a= role
   that we term "reverse-proxy".  Orthogonal to th= is distinction, a
   proxy can map from a CoAP request to a CoAP request (CoAP-to-C= oAP
   proxy) or translate from or to a different protocol ("cro= ss-proxy").
   Full definitions of these terms are provided in Section 1.2.
   Notes:  The terminology in this specification has been se= lected to be
      culturally compatible with the terminology used in the= wider Web
      application environments, without necessarily matching= it in every
      detail (which may not even be relevant to Constrained = RESTful
      Environments).  Not too much semantics should be = ascribed to the
      components of the terms (such as "forward", = "reverse", or
      "cross").

      HTTP proxies, besides acting as HTTP proxies, often of= fer a
      transport protocol proxying function ("CONNECT&qu= ot;) to enable end-to-
      end transport layer security through the proxy.  = No such function
      is defined for CoAP-to-CoAP proxies in this specificat= ion, as
      forwarding of UDP packets is unlikely to be of much va= lue in
      Constrained RESTful environments.  See also Secti= on 10.2.7 for the
      cross-proxy case.


So the point is that a client always knows when it is using a Forward-Proxy= , i.e., it has explicitly chosen to talk to it as opposed to the origin ser= ver.  We have the options Proxy-Uri and Proxy-Scheme that enable to ex= press this choice explicitly:

5.7.2.  Forward-Proxies

   CoAP distinguishes between requests made (as if) to an origin = server
   and a request made through a forward-proxy.  CoAP request= s to a
   forward-proxy are made as normal Confirmable or Non-confirmabl= e
   requests to the forward-proxy endpoint, but specify the reques= t URI
   in a different way: The request URI in a proxy request is spec= ified
   as a string in the Proxy-Uri Option (see Section 5.10.2), whil= e the
   request URI in a request to an origin server is split into the= Uri-
   Host, Uri-Port, Uri-Path and Uri-Query Options (see Section 5.= 10.1);
   alternatively the URI in a proxy request can be assembled from= a
   Proxy-Scheme option and the split options mentioned.

There is no way in a URI to specify the use of a forward-proxy.
Which forward-proxy is used is decided by the client based on local informa= tion (which may include information gleaned from the URI, of course).  = ;The URI continues to looks

For a reverse-proxy, the client might be thinking it is talking to the actu= al origin server:
The URI directly points to the reverse-proxy, but instead of serving its re= source directly, the reverse-proxy defers to an origin server (or another r= everse proxy!).

5.7.3.  Reverse-Proxies

   Reverse-proxies do not make use of the Proxy-Uri or Proxy-Sche= me
   options, but need to determine the destination (next hop) of a=
   request from information in the request and information in the= ir
   configuration.  E.g., a reverse-proxy might offer various= resources
   the existence of which it has learned through resource discove= ry as
   if they were its own resources.  The reverse-proxy is fre= e to build a
   namespace for the URIs that identify these resources.  A = reverse-
   proxy may also build a namespace that gives the client more co= ntrol
   over where the request goes, e.g. by embedding host identifier= s and
   port numbers into the URI path of the resources offered.

draft-castellani-core-http-mapping-07.txt also alludes to the fact that the= re may be "transparent" (intercepting) entities intervening on th= e path to the origin server and acting a bit like reverse-proxies, except t= hat the network provider has chosen to interpose them as opposed to the client.

Of course, all these types can be combined on a path to an origin server: A= client can use a forward-proxy to talk to a reverse-proxy, with any number= of additional reverse-proxies (and "transparent" (intercepting) = proxies) on the way to the origin server.

Maybe draft-castellani-core-http-mapping-07.txt doesn't really need to defi= ne the terms forward-proxy and reverse-proxy, but can reference them from t= he core coap spec.  "transparent"/intercepting proxies are n= ot discussed in core-coap, though.

Gr=FC=DFe, Carsten

_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
core@ietf.org
ht= tps://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 strictly prohibited and may be unlawful= . If you are not the intended recipient, please contact the sender by retur= n e-mail and destroy all copies of the original message.


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

 

--_000_031DD135F9160444ABBE3B0C36CED618BF6C40011DB3MPN2082MGDP_-- From Akbar.Rahman@InterDigital.com Wed Mar 27 13:04:03 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2233421F919B for ; Wed, 27 Mar 2013 13:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ji5XncBjNBXh for ; Wed, 27 Mar 2013 13:03:59 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8779721F9188 for ; Wed, 27 Mar 2013 13:03:56 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Mar 2013 16:03:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CE2B26.35EF1F32" Date: Wed, 27 Mar 2013 16:03:51 -0400 Message-ID: In-Reply-To: <031DD135F9160444ABBE3B0C36CED618BF6B53@011-DB3MPN2-082.MGDPHG.emi.philips.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Any experience in using CoAP responses tomulticast requests? Thread-Index: AQHOKjmBchpIVeX/tUC5di2JAdx13pi5kPdAgABmHMA= References: <031DD135F9160444ABBE3B0C36CED618BF0286@011-DB3MPN2-082.MGDPHG.emi.philips.com><5151C37A.1010205@intec.ugent.be> <031DD135F9160444ABBE3B0C36CED618BF6B53@011-DB3MPN2-082.MGDPHG.emi.philips.com> From: "Rahman, Akbar" To: "Isam Ishaq" X-OriginalArrivalTime: 27 Mar 2013 20:03:55.0317 (UTC) FILETIME=[35E36650:01CE2B26] Cc: core@ietf.org Subject: Re: [core] Any experience in using CoAP responses tomulticast requests? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 27 Mar 2013 20:04:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CE2B26.35EF1F32 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Isam, =20 =20 Yes, it was indeed a very nice paper and your extra points below are also informative. I just had one question. The paper describes your Multicast GET scenarios. Did you ever send any other Multicast methods (e.g. PUT)? And if so, did you observe any additional interesting behavior? =20 =20 Best Regards, =20 =20 Akbar =20 =20 From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Dijk, Esko Sent: Wednesday, March 27, 2013 10:04 AM To: Isam Ishaq; core@ietf.org Subject: Re: [core] Any experience in using CoAP responses tomulticast requests? =20 Thanks Isam, =20 It's good to hear that the two measures (CoAP Leisure + random delay in forwarding) solved the issue. CoAP server implementations SHOULD use the Leisure, and the random forwarding delay is also applied in the Multicast Protocol for Low-power lossy networks (MPL) of the RoLL Working Group.=20 =20 I would be interested to hear about the extended paper as well, when it is published. =20 regards, Esko =20 From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Isam Ishaq Sent: Tuesday, March 26, 2013 16:49 To: core@ietf.org Subject: Re: [core] Any experience in using CoAP responses to multicast requests? =20 Dear Esko and all, At iMinds we have some limited experience with multicast in wireless sensor networks. We have used multicast CoAP requests in order to discover sensors inside LLNs. At the networking layer of the LLN the multicast messages were routed as broadcasts. We have conducted our tests using our testbed with real sensor nodes and have experimented with network sizes up to 50 nodes in different network topologies with hop counts between 1 and 5 hops. As expected, the use of multicast/broadcasts proved to be challenging. Even for small sensor networks (10 nodes or less), we had issues with broadcast storms in the network. One reason for these storms was related to routing (a basic AODV implementation in our case). Once the sensor nodes got the multicast and wanted to reply they all started asking for the route to the gateway at the same time, causing the network to become unresponsive. In order to combat this broadcast storms we let the sensor gateway broadcast a route reply packet in the network. This caused all sensors to establish a route to the gateway and eliminated the need for them to start asking for a route once they get the discovery request.=20 In our implementation the boarder router sending the broadcasts was also a constrained device (Tmote Sky). So it could not handle all the replies it got from the other sensors, because they arrived with small time gaps between them. This led to the receive buffer on the boarder router to start dropping packets. To help solving this issue we introduced random delays in the network - before responding the CoAP requests (Leisure) and before forwarding broadcasts in the network. By using these techniques we improved the delivery of the multicast and the resulting unicast replies very much. Still since multicasts are delivered in a non-confirmable way, there was no way to tell that the multicast did actually get to all nodes. In our case this was ok and just meant that the sensors that did not get the multicast the first time will get it the next time when a new periodic pull for discovery was done. First results of this work have been published in the following paper: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D6296943&isnum= ber =3D6296822 An extended version of this paper with more experimental results is currently under review. At this moment, we are also exploring the use of an intermediary to offer group communication functionality based on unicast (paper under review). We are also interested comparing this approach with a complete multicast solution for a LLN. Best Regards, Isam Ishaq On 25-Mar-13 10:16 AM, Dijk, Esko wrote: Dear all, =20 one of the review comments to the GroupComm I-D concerns the lack of (implementation or simulation) experience with use of CoAP multicast, and the associated multitude of CoAP responses. The I-D provides guidelines in this area but not based on such experience. =20 Did anyone experiment with CoAP multicast? (Or knows someone, or a publication etc.) =20 regards, Esko =20 =09 ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. =09 =09 =09 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --=20 Isam Ishaq Department of Information Technology Internet Based Communication Networks and Services (IBCN) Ghent University - iMinds=20 Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium M: +32 (0)484 856 155 T: +32 (0)9 33 14946 T Secr: +32 (0)9 33 14900 F: +32 (0)9 33 14899 E: isam.ishaq@intec.UGent.be W : www.ibcn.intec.UGent.be ------_=_NextPart_001_01CE2B26.35EF1F32 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Isam,

 

 

Yes, it was indeed a = very nice paper and your extra points below are also informative.  = I just had one question.  The paper describes your Multicast GET = scenarios.  Did you ever send any other Multicast methods (e.g. = PUT)?  And if so, did you observe any additional interesting = behavior?

 

 

Best = Regards,

 

 

Akbar

 

 

From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Dijk, Esko
Sent: Wednesday, March 27, 2013 10:04 = AM
To: Isam Ishaq; core@ietf.org
Subject: Re: [core] = Any experience in using CoAP responses tomulticast = requests?

 

Thanks Isam,

 

It’s good to hear = that the two measures (CoAP Leisure + random delay in forwarding) solved = the issue. CoAP server implementations SHOULD use the Leisure, and the = random forwarding delay is also applied in the Multicast Protocol for = Low-power lossy networks (MPL) of the RoLL Working Group. =

 

I would be interested to = hear about the extended paper as well, when it is = published.

 

regards,

Esko

 

From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of Isam Ishaq
Sent: Tuesday, March 26, 2013 = 16:49
To: core@ietf.org
Subject: Re: [core] Any = experience in using CoAP responses to multicast = requests?

 

Dear = Esko and all,

At iMinds we have some limited experience with = multicast in wireless sensor networks. We have used multicast CoAP = requests in order to discover sensors inside LLNs. At the networking = layer of the LLN the multicast messages were routed as broadcasts. We = have conducted our tests using our testbed with real sensor nodes and = have experimented with network sizes up to 50 nodes in different network = topologies with hop counts between 1 and 5 hops.

As expected, the = use of multicast/broadcasts proved to be challenging.  Even for = small sensor networks (10 nodes or less), we had issues with broadcast = storms in the network. One reason for these storms was related to = routing (a basic AODV implementation in our case). Once the sensor nodes = got the multicast and wanted to reply they all started asking for the = route to the gateway at the same time, causing the network to become = unresponsive. In order to combat this broadcast storms we let the sensor = gateway broadcast a route reply packet in the network. This caused all = sensors to establish a route to the gateway and eliminated the need for = them to start asking for a route once they get the discovery request. =

In our implementation the boarder router sending the broadcasts = was also a constrained device (Tmote Sky). So it could not handle all = the replies it got from the other sensors, because they arrived with = small time gaps between them. This led to the receive buffer on the = boarder router to start dropping packets. To help solving this issue we = introduced random delays in the network – before responding the = CoAP requests (Leisure) and before forwarding = broadcasts in the network.


By using these techniques we improved the delivery = of the multicast and the resulting unicast replies very much. Still = since multicasts are delivered in a non-confirmable way, there was no = way to tell that the multicast did actually get to all nodes. In our = case this was ok and just meant that the sensors that did not get the = multicast the first time will get it the next time when a new periodic = pull for discovery was done.

First results of this work have been = published in the following paper:
http://ieeexplore.ieee.org/stamp/stamp.jsp= ?tp=3D&arnumber=3D6296943&isnumber=3D6296822

An = extended version of this paper with more experimental results is = currently under review. At this moment, we are also exploring the use of = an intermediary to offer group communication functionality based on = unicast (paper under review). We are also interested comparing this = approach with a complete multicast solution for a LLN.

Best = Regards,
Isam Ishaq



On 25-Mar-13 10:16 AM, Dijk, Esko = wrote:

Dear all,

 

one of the = review comments to the GroupComm I-D concerns the lack of = (implementation or simulation) experience with use of CoAP multicast, = and the associated multitude of CoAP responses. The I-D provides = guidelines in this area but not based on such = experience.

 

Did anyone experiment with CoAP multicast? (Or knows = someone, or a publication etc.)

 

regards,

Esko

 

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


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



-- =

Isam Ishaq
Department of =
Information Technology
Internet Based Communication =
Networks and Services (IBCN)
Ghent University - =
iMinds 
Gaston Crommenlaan 8 (Bus 201), B-9050 =
Gent, Belgium
M: +32 (0)484 856 =
155
T: +32 (0)9 33 14946
T =
Secr: +32 (0)9 33 14900
F: +32 (0)9 33 =
14899
E: isam.ishaq@intec.UGent.be
W : www.ibcn.intec.UGent.be<=
/o:p>
------_=_NextPart_001_01CE2B26.35EF1F32-- From isam.ishaq@intec.ugent.be Thu Mar 28 01:59:31 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF75021F91E8 for ; Thu, 28 Mar 2013 01:59: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 T3SzCf0SkNUb for ; Thu, 28 Mar 2013 01:59:30 -0700 (PDT) Received: from smtp2.ugent.be (smtp2.ugent.be [157.193.49.126]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEE421F91E6 for ; Thu, 28 Mar 2013 01:59:30 -0700 (PDT) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp2.ugent.be (Postfix) with ESMTP id 261E812C751; Thu, 28 Mar 2013 09:59:29 +0100 (CET) X-Virus-Scanned: by UGent DICT Received: from smtp2.ugent.be ([157.193.49.126]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id 2hRDH5_kip3D; Thu, 28 Mar 2013 09:59:28 +0100 (CET) Received: from mail2.intec.ugent.be (mail2.intec.ugent.be [157.193.214.245]) by smtp2.ugent.be (Postfix) with ESMTP id 68F5C12C74D; Thu, 28 Mar 2013 09:59:28 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail2.intec.ugent.be (Postfix) with ESMTP id 680A926; Thu, 28 Mar 2013 09:59:28 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at intec.ugent.be Received: from mail2.intec.ugent.be ([127.0.0.1]) by localhost (mail2.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9f2ci7BSv4L3; Thu, 28 Mar 2013 09:59:28 +0100 (CET) Received: from [127.0.0.1] (visitors.ibbt.be [193.191.148.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: iishaq) by mail2.intec.ugent.be (Postfix) with ESMTPSA id 2EA9C25; Thu, 28 Mar 2013 09:59:27 +0100 (CET) Message-ID: <5154067E.3070802@intec.ugent.be> Date: Thu, 28 Mar 2013 09:59:42 +0100 From: Isam Ishaq User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Rahman, Akbar" References: <031DD135F9160444ABBE3B0C36CED618BF0286@011-DB3MPN2-082.MGDPHG.emi.philips.com> <5151C37A.1010205@intec.ugent.be> <031DD135F9160444ABBE3B0C36CED618BF6B53@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130327-1, 03/28/2013), Outbound message X-Antivirus-Status: Clean X-Miltered: at jchkm1 with ID 51540670.000 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 51540670.000 from mail2.intec.ugent.be/mail2.intec.ugent.be/157.193.214.245/mail2.intec.ugent.be/ X-j-chkmail-Score: MSGID : 51540670.000 on smtp2.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: core@ietf.org Subject: Re: [core] Any experience in using CoAP responses tomulticast requests? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 Mar 2013 08:59:31 -0000 Hi Akbar, We did not do any tests we other methods. I do not expect that there will be a difference in the behavior as a result of changing the method alone. What could cause different behaviors? Best, Isam On Wednesday, March 27, 2013 9:03:51 PM, Rahman, Akbar wrote: > Hi Isam, > > Yes, it was indeed a very nice paper and your extra points below are > also informative. I just had one question. The paper describes your > Multicast GET scenarios. Did you ever send any other Multicast > methods (e.g. PUT)? And if so, did you observe any additional > interesting behavior? > > Best Regards, > > Akbar > > *From:*core-bounces@ietf.org [mailto:core-bounces@ietf.org] *On Behalf > Of *Dijk, Esko > *Sent:* Wednesday, March 27, 2013 10:04 AM > *To:* Isam Ishaq; core@ietf.org > *Subject:* Re: [core] Any experience in using CoAP responses > tomulticast requests? > > Thanks Isam, > > It’s good to hear that the two measures (CoAP Leisure + random delay > in forwarding) solved the issue. CoAP server implementations SHOULD > use the Leisure, and the random forwarding delay is also applied in > the Multicast Protocol for Low-power lossy networks (MPL) of the RoLL > Working Group. > > I would be interested to hear about the extended paper as well, when > it is published. > > regards, > > Esko > > *From:*core-bounces@ietf.org [mailto:core-bounces@ietf.org] *On Behalf > Of *Isam Ishaq > *Sent:* Tuesday, March 26, 2013 16:49 > *To:* core@ietf.org > *Subject:* Re: [core] Any experience in using CoAP responses to > multicast requests? > > Dear Esko and all, > > At iMinds we have some limited experience with multicast in wireless > sensor networks. We have used multicast CoAP requests in order to > discover sensors inside LLNs. At the networking layer of the LLN the > multicast messages were routed as broadcasts. We have conducted our > tests using our testbed with real sensor nodes and have experimented > with network sizes up to 50 nodes in different network topologies with > hop counts between 1 and 5 hops. > > As expected, the use of multicast/broadcasts proved to be > challenging. Even for small sensor networks (10 nodes or less), we > had issues with broadcast storms in the network. One reason for these > storms was related to routing (a basic AODV implementation in our > case). Once the sensor nodes got the multicast and wanted to reply > they all started asking for the route to the gateway at the same time, > causing the network to become unresponsive. In order to combat this > broadcast storms we let the sensor gateway broadcast a route reply > packet in the network. This caused all sensors to establish a route to > the gateway and eliminated the need for them to start asking for a > route once they get the discovery request. > > In our implementation the boarder router sending the broadcasts was > also a constrained device (Tmote Sky). So it could not handle all the > replies it got from the other sensors, because they arrived with small > time gaps between them. This led to the receive buffer on the boarder > router to start dropping packets. To help solving this issue we > introduced random delays in the network – before responding the CoAP > requests (Leisure) and before forwarding broadcasts in the network. > > > By using these techniques we improved the delivery of the multicast > and the resulting unicast replies very much. Still since multicasts > are delivered in a non-confirmable way, there was no way to tell that > the multicast did actually get to all nodes. In our case this was ok > and just meant that the sensors that did not get the multicast the > first time will get it the next time when a new periodic pull for > discovery was done. > > First results of this work have been published in the following paper: > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6296943&isnumber=6296822 > > An extended version of this paper with more experimental results is > currently under review. At this moment, we are also exploring the use > of an intermediary to offer group communication functionality based on > unicast (paper under review). We are also interested comparing this > approach with a complete multicast solution for a LLN. > > Best Regards, > Isam Ishaq > > > > On 25-Mar-13 10:16 AM, Dijk, Esko wrote: > > Dear all, > > one of the review comments to the GroupComm I-D concerns the lack > of (implementation or simulation) experience with use of CoAP > multicast, and the associated multitude of CoAP responses. The I-D > provides guidelines in this area but not based on such experience. > > Did anyone experiment with CoAP multicast? (Or knows someone, or a > publication etc.) > > regards, > > Esko > > ------------------------------------------------------------------------ > > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended > solely for the addressee(s). If you are not the intended > recipient, you are hereby notified that any use, forwarding, > dissemination, or reproduction of this message is strictly > prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy > all copies of the original message. > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > > > -- > Isam Ishaq > Department of Information Technology > Internet Based Communication Networks and Services (IBCN) > Ghent University - iMinds > Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium > M: +32 (0)484 856 155 > T: +32 (0)9 33 14946 > T Secr: +32 (0)9 33 14900 > F: +32 (0)9 33 14899 > E:isam.ishaq@intec.UGent.be > W :www.ibcn.intec.UGent.be -- Isam Ishaq Department of Information Technology Internet Based Communication Networks and Services (IBCN) Ghent University - iMinds Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium M: +32 (0)484 856 155 T: +32 (0)9 33 14946 T Secr: +32 (0)9 33 14900 F: +32 (0)9 33 14899 E: isam.ishaq@intec.UGent.be W : www.ibcn.intec.UGent.be From isam.ishaq@intec.ugent.be Thu Mar 28 02:09:32 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27FEF21F9034 for ; Thu, 28 Mar 2013 02:09:32 -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 SZcazR9H1cb0 for ; Thu, 28 Mar 2013 02:09:29 -0700 (PDT) Received: from smtp2.ugent.be (smtp2.ugent.be [157.193.49.126]) by ietfa.amsl.com (Postfix) with ESMTP id 110B221F900B for ; Thu, 28 Mar 2013 02:09:29 -0700 (PDT) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp2.ugent.be (Postfix) with ESMTP id 6BA3512C75A; Thu, 28 Mar 2013 10:09:28 +0100 (CET) X-Virus-Scanned: by UGent DICT Received: from smtp2.ugent.be ([157.193.49.126]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id 3pUbzc-8NJMV; Thu, 28 Mar 2013 10:09:26 +0100 (CET) Received: from mail2.intec.ugent.be (mail2.intec.ugent.be [157.193.214.245]) by smtp2.ugent.be (Postfix) with ESMTP id D6B2912C733; Thu, 28 Mar 2013 10:09:26 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail2.intec.ugent.be (Postfix) with ESMTP id E483826; Thu, 28 Mar 2013 10:09:26 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at intec.ugent.be Received: from mail2.intec.ugent.be ([127.0.0.1]) by localhost (mail2.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4OZrEijkNrs; Thu, 28 Mar 2013 10:09:26 +0100 (CET) Received: from [127.0.0.1] (visitors.ibbt.be [193.191.148.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: iishaq) by mail2.intec.ugent.be (Postfix) with ESMTPSA id 95A7925; Thu, 28 Mar 2013 10:09:26 +0100 (CET) Message-ID: <515408D5.80300@intec.ugent.be> Date: Thu, 28 Mar 2013 10:09:41 +0100 From: Isam Ishaq User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Dijk, Esko" References: <031DD135F9160444ABBE3B0C36CED618BF0286@011-DB3MPN2-082.MGDPHG.emi.philips.com> <5151C37A.1010205@intec.ugent.be> <031DD135F9160444ABBE3B0C36CED618BF6B53@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618BF6B53@011-DB3MPN2-082.MGDPHG.emi.philips.com> Content-Type: multipart/alternative; boundary="------------030403030106070109020707" X-Antivirus: avast! (VPS 130327-1, 03/28/2013), Outbound message X-Antivirus-Status: Clean X-Miltered: at jchkm3 with ID 515408C6.002 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 515408C6.002 from mail2.intec.ugent.be/mail2.intec.ugent.be/157.193.214.245/mail2.intec.ugent.be/ X-j-chkmail-Score: MSGID : 515408C6.002 on smtp2.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: "core@ietf.org" Subject: Re: [core] Any experience in using CoAP responses to multicast requests? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 Mar 2013 09:09:32 -0000 This is a multi-part message in MIME format. --------------030403030106070109020707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, Is anybody aware of an MPL implementation that we can test? Best, Isam On 27-Mar-13 3:04 PM, Dijk, Esko wrote: > > Thanks Isam, > > It's good to hear that the two measures (CoAP Leisure + random delay > in forwarding) solved the issue. CoAP server implementations SHOULD > use the Leisure, and the random forwarding delay is also applied in > the Multicast Protocol for Low-power lossy networks (MPL) of the RoLL > Working Group. > > I would be interested to hear about the extended paper as well, when > it is published. > > regards, > > Esko > > *From:*core-bounces@ietf.org [mailto:core-bounces@ietf.org] *On Behalf > Of *Isam Ishaq > *Sent:* Tuesday, March 26, 2013 16:49 > *To:* core@ietf.org > *Subject:* Re: [core] Any experience in using CoAP responses to > multicast requests? > > Dear Esko and all, > > At iMinds we have some limited experience with multicast in wireless > sensor networks. We have used multicast CoAP requests in order to > discover sensors inside LLNs. At the networking layer of the LLN the > multicast messages were routed as broadcasts. We have conducted our > tests using our testbed with real sensor nodes and have experimented > with network sizes up to 50 nodes in different network topologies with > hop counts between 1 and 5 hops. > > As expected, the use of multicast/broadcasts proved to be > challenging. Even for small sensor networks (10 nodes or less), we > had issues with broadcast storms in the network. One reason for these > storms was related to routing (a basic AODV implementation in our > case). Once the sensor nodes got the multicast and wanted to reply > they all started asking for the route to the gateway at the same time, > causing the network to become unresponsive. In order to combat this > broadcast storms we let the sensor gateway broadcast a route reply > packet in the network. This caused all sensors to establish a route to > the gateway and eliminated the need for them to start asking for a > route once they get the discovery request. > > In our implementation the boarder router sending the broadcasts was > also a constrained device (Tmote Sky). So it could not handle all the > replies it got from the other sensors, because they arrived with small > time gaps between them. This led to the receive buffer on the boarder > router to start dropping packets. To help solving this issue we > introduced random delays in the network -- before responding the CoAP > requests (Leisure) and before forwarding broadcasts in the network. > > > By using these techniques we improved the delivery of the multicast > and the resulting unicast replies very much. Still since multicasts > are delivered in a non-confirmable way, there was no way to tell that > the multicast did actually get to all nodes. In our case this was ok > and just meant that the sensors that did not get the multicast the > first time will get it the next time when a new periodic pull for > discovery was done. > > First results of this work have been published in the following paper: > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6296943&isnumber=6296822 > > An extended version of this paper with more experimental results is > currently under review. At this moment, we are also exploring the use > of an intermediary to offer group communication functionality based on > unicast (paper under review). We are also interested comparing this > approach with a complete multicast solution for a LLN. > > Best Regards, > Isam Ishaq > > > > On 25-Mar-13 10:16 AM, Dijk, Esko wrote: > > Dear all, > > one of the review comments to the GroupComm I-D concerns the lack > of (implementation or simulation) experience with use of CoAP > multicast, and the associated multitude of CoAP responses. The I-D > provides guidelines in this area but not based on such experience. > > Did anyone experiment with CoAP multicast? (Or knows someone, or a > publication etc.) > > regards, > > Esko > > ------------------------------------------------------------------------ > > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended > solely for the addressee(s). If you are not the intended > recipient, you are hereby notified that any use, forwarding, > dissemination, or reproduction of this message is strictly > prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy > all copies of the original message. > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > > > > -- > Isam Ishaq > Department of Information Technology > Internet Based Communication Networks and Services (IBCN) > Ghent University - iMinds > Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium > M: +32 (0)484 856 155 > T: +32 (0)9 33 14946 > T Secr: +32 (0)9 33 14900 > F: +32 (0)9 33 14899 > E:isam.ishaq@intec.UGent.be > W :www.ibcn.intec.UGent.be -- Isam Ishaq Department of Information Technology Internet Based Communication Networks and Services (IBCN) Ghent University - iMinds Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium M: +32 (0)484 856 155 T: +32 (0)9 33 14946 T Secr: +32 (0)9 33 14900 F: +32 (0)9 33 14899 E: isam.ishaq@intec.UGent.be W : www.ibcn.intec.UGent.be --------------030403030106070109020707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello,

Is anybody aware of an MPL implementation that we can test?

Best,
Isam

On 27-Mar-13 3:04 PM, Dijk, Esko wrote:

Thanks Isam,

 

It’s good to hear that the two measures (CoAP Leisure + random delay in forwarding) solved the issue. CoAP server implementations SHOULD use the Leisure, and the random forwarding delay is also applied in the Multicast Protocol for Low-power lossy networks (MPL) of the RoLL Working Group.

 

I would be interested to hear about the extended paper as well, when it is published.

 

regards,

Esko

 

From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Isam Ishaq
Sent: Tuesday, March 26, 2013 16:49
To: core@ietf.org
Subject: Re: [core] Any experience in using CoAP responses to multicast requests?

 

Dear Esko and all,

At iMinds we have some limited experience with multicast in wireless sensor networks. We have used multicast CoAP requests in order to discover sensors inside LLNs. At the networking layer of the LLN the multicast messages were routed as broadcasts. We have conducted our tests using our testbed with real sensor nodes and have experimented with network sizes up to 50 nodes in different network topologies with hop counts between 1 and 5 hops.

As expected, the use of multicast/broadcasts proved to be challenging.  Even for small sensor networks (10 nodes or less), we had issues with broadcast storms in the network. One reason for these storms was related to routing (a basic AODV implementation in our case). Once the sensor nodes got the multicast and wanted to reply they all started asking for the route to the gateway at the same time, causing the network to become unresponsive. In order to combat this broadcast storms we let the sensor gateway broadcast a route reply packet in the network. This caused all sensors to establish a route to the gateway and eliminated the need for them to start asking for a route once they get the discovery request.

In our implementation the boarder router sending the broadcasts was also a constrained device (Tmote Sky). So it could not handle all the replies it got from the other sensors, because they arrived with small time gaps between them. This led to the receive buffer on the boarder router to start dropping packets. To help solving this issue we introduced random delays in the network – before responding the CoAP requests (Leisure) and before forwarding broadcasts in the network.


By using these techniques we improved the delivery of the multicast and the resulting unicast replies very much. Still since multicasts are delivered in a non-confirmable way, there was no way to tell that the multicast did actually get to all nodes. In our case this was ok and just meant that the sensors that did not get the multicast the first time will get it the next time when a new periodic pull for discovery was done.

First results of this work have been published in the following paper:
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6296943&isnumber=6296822

An extended version of this paper with more experimental results is currently under review. At this moment, we are also exploring the use of an intermediary to offer group communication functionality based on unicast (paper under review). We are also interested comparing this approach with a complete multicast solution for a LLN.

Best Regards,
Isam Ishaq



On 25-Mar-13 10:16 AM, Dijk, Esko wrote:

Dear all,

 

one of the review comments to the GroupComm I-D concerns the lack of (implementation or simulation) experience with use of CoAP multicast, and the associated multitude of CoAP responses. The I-D provides guidelines in this area but not based on such experience.

 

Did anyone experiment with CoAP multicast? (Or knows someone, or a publication etc.)

 

regards,

Esko

 

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



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




-- 
Isam Ishaq
Department of Information Technology
Internet Based Communication Networks and Services (IBCN)
Ghent University - iMinds 
Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
M: +32 (0)484 856 155
T: +32 (0)9 33 14946
T Secr: +32 (0)9 33 14900
F: +32 (0)9 33 14899
E: isam.ishaq@intec.UGent.be
W : www.ibcn.intec.UGent.be


-- 
Isam Ishaq
Department of Information Technology
Internet Based Communication Networks and Services (IBCN)
Ghent University - iMinds 
Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
M: +32 (0)484 856 155
T: +32 (0)9 33 14946
T Secr: +32 (0)9 33 14900
F: +32 (0)9 33 14899
E: isam.ishaq@intec.UGent.be
W : www.ibcn.intec.UGent.be
--------------030403030106070109020707-- From cabo@tzi.org Thu Mar 28 09:04:50 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2503C21F90F4 for ; Thu, 28 Mar 2013 09:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.864 X-Spam-Level: X-Spam-Status: No, score=-105.864 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyHDDF2N3wUD for ; Thu, 28 Mar 2013 09:04: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 5639521F90F3 for ; Thu, 28 Mar 2013 09:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2SG4jhb027201 for ; Thu, 28 Mar 2013 17:04:45 +0100 (CET) Received: from [172.16.42.101] (p548945DD.dip.t-dialin.net [84.137.69.221]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B3F4A3573; Thu, 28 Mar 2013 17:04:44 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Mar 2013 17:04:43 +0100 To: core WG Message-Id: <1C1F583C-F3D9-44C0-A628-57913220C8FA@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [core] =?utf-8?q?=F0=9F=94=94=3A_draft-ietf-core-coap_has_complet?= =?utf-8?q?ed_IETF_last_call?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 Mar 2013 16:04:50 -0000 draft-ietf-core-coap has completed IETF last call yesterday. The next step (after AD go-ahead) is the IESG decision process. Most IESG members will now take a position on the draft (YES, NO OBJECTION, DISCUSS, ABSTAIN), and many will supply COMMENTS (which are usually taken quite seriously, hence in upper case). DISCUSS positions essentially stop the process. Clearing them up, and addressing COMMENTS, often leads to editorial or even technical changes to the draft before it is accepted by the IESG. If you want to see this in action, have a look at the evolution of draft-ietf-core-link-format-11 (which was IETF last-called) to -14 (which was the input to the RFC editor). To wit: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-link-format-14.txt&ur= l1=3Ddraft-ietf-core-link-format-11.txt You will see many editorial changes, but you also will see that numerous fixes were applied to the formal descriptions, and even a technical change ("uri" to "href"). The IESG decision process is meant to take place between the Document Shepherd (Andrew McGregor in this case), the WG chairs, the document authors, and the IESG; often orchestrated by the sponsoring AD (Barry Leiba in this case). In the past, the process has often been mostly intransparent to the WG, unless one of the actors decided to make information available to the WG. With the datatracker, WG members can now gain some more insight, but they have to actively look for it. For this draft, Barry Leiba has decided to run an experiment: The discussion around the IESG decision process will be directly copied to the WG. This has the invaluable advantage that the entire expertise of the WG is available for evaluating the comments and changes that are being pondered. So the chairs and the authors welcome this experiment and hope we can apply it to all future documents this WG completes. It also has a potential downside. The IESG decision process is characterized by the heavy workload of the IESG members participating in it. Focusing the number of people directly interacting with them in such a process helps with that workload. So I would ask the WG to prefer using the Document Shepherd (and the Sponsoring AD) as the main channels into the IESG. (Of course, if that doesn't work, you are always free to escalate. But it should be worth an escalation.) Gr=FC=DFe, Carsten From esko.dijk@philips.com Fri Mar 29 03:01:01 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E2921F93DB for ; Fri, 29 Mar 2013 03:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.798 X-Spam-Level: X-Spam-Status: No, score=-3.798 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 17ONjUCUu3yK for ; Fri, 29 Mar 2013 03:00:59 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id EFB5021F9389 for ; Fri, 29 Mar 2013 03:00:57 -0700 (PDT) Received: from mail222-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Fri, 29 Mar 2013 10:00:56 +0000 Received: from mail222-ch1 (localhost [127.0.0.1]) by mail222-ch1-R.bigfish.com (Postfix) with ESMTP id F38BA2E03E1; Fri, 29 Mar 2013 10:00:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VPS-30(zz15d6O9251Jc85fh217bIzz1f42h1fc6h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dh18c673hz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1155h) Received: from mail222-ch1 (localhost.localdomain [127.0.0.1]) by mail222-ch1 (MessageSwitch) id 1364551253910643_5235; Fri, 29 Mar 2013 10:00:53 +0000 (UTC) Received: from CH1EHSMHS015.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail222-ch1.bigfish.com (Postfix) with ESMTP id C23931800B7; Fri, 29 Mar 2013 10:00:53 +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; Fri, 29 Mar 2013 10:00:51 +0000 Received: from 011-DB3MMR1-020.MGDPHG.emi.philips.com (10.128.28.101) by 011-DB3MMR1-008.MGDPHG.emi.philips.com (10.128.28.47) with Microsoft SMTP Server (TLS) id 14.2.328.11; Fri, 29 Mar 2013 10:00:50 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.99]) by 011-DB3MMR1-020.MGDPHG.emi.philips.com ([fe80::65e7:4d4c:4c67:daa9%11]) with mapi id 14.02.0328.011; Fri, 29 Mar 2013 10:00:49 +0000 From: "Dijk, Esko" To: "matthieu.vial@non.schneider-electric.com" Thread-Topic: Battery lifetime optimization idea for Mirror Server Thread-Index: Ac4sY//ao4HR1VWQR3a0MSoPPTxA4A== Date: Fri, 29 Mar 2013 10:00:49 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618BFB1A4@011-DB3MPN2-082.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618BFB1A4011DB3MPN2082MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core \(core@ietf.org\)" Subject: [core] Battery lifetime optimization idea for Mirror Server X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Mar 2013 10:01:01 -0000 --_000_031DD135F9160444ABBE3B0C36CED618BFB1A4011DB3MPN2082MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Matthieu, I considered an optimization for the Mirror Server (http://tools.ietf.org/h= tml/draft-vial-core-mirror-server-00) that could extend the battery lifetim= e of Sleepy Endpoints (SEPs) significantly. The idea applies to SEPs that = have writeable resources registered into a Mirror Server (MS). Based on Sec= tion 4.8 (Modification Check) a SEP needs to periodically check if one of i= ts resources has been changed on the Mirror Server. This requires an extra = CoAP request in addition to the sensor value updates the SEP is periodicall= y sending to the Mirror Server, e.g. like PUT /ms/0/sen/temp "22". In a typ= ical use case as I see it, the SEP performs this PUT every time it wakes up= and also GETs to do the modification check in the same awake-interval. Two= requests, two responses. The idea is to make this into only one request + one response in the follow= ing way: the SEP sends a PUT request to update e.g. its temperature value; = and then the Mirror Server responds with 2.04 Changed and only in case one = of the SEP resources has been modified on the Mirror Server, it attaches a = special short payload to the response that indicates "one or more of your r= esources have been changed". It could be a single character "M" for example= . This is a trigger for the SEP to do the modification check of section 4.8= . Because in >99% of the times no changes have been made to the SEP resources= on the MS, the average message load drops to one request + one response pe= r awake-interval. The alternative here is to define a new Option that is attached to the 2.04= response message; that seems a neater way to do it. This Option doesn't ne= ed to be recognized by anyone except the SEPs and Mirror Servers that adher= e to this specification so I don't see any bad side-effects to CoAP by defi= ning such Option in a spec separate from core-coap. So perhaps we can include a feature like this in MS, to meet the home/indus= try demands for long battery life for sensor-type devices. regards, Esko ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_031DD135F9160444ABBE3B0C36CED618BFB1A4011DB3MPN2082MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello  Matthieu,

 

I considered an optimization for the Mirror Server (= htt= p://tools.ietf.org/html/draft-vial-core-mirror-server-00) that could ex= tend the battery lifetime of Sleepy Endpoints (SEPs) significantly. The idea  applies to SEPs that have w= riteable resources registered into a Mirror Server (MS). Based on Section 4= .8 (Modification Check) a SEP needs to periodically check if one of its res= ources has been changed on the Mirror Server. This requires an extra CoAP request in addition to the sensor valu= e updates the SEP is periodically sending to the Mirror Server, e.g. like P= UT /ms/0/sen/temp "22". In a typical use case as I see it, the SE= P performs this PUT every time it wakes up and also GETs to do the modification check in the same awake-interval. Two= requests, two responses.

 

The idea is to make this into only one request += one response in the following way: the SEP sends a PUT request to update e= .g. its temperature value; and then the Mirror Server responds with 2.04 Ch= anged and only in case one of the SEP resources has been modified on the Mirror Server, it attaches a special sh= ort payload to the response that indicates “one or more of your resou= rces have been changed”. It could be a single character “M̶= 1; for example. This is a trigger for the SEP to do the modification check of section 4.8.

Because in >99% of the times no changes have been= made to the SEP resources on the MS, the average message load drops to one= request + one response per awake-interval.

 

The alternative here is to define a new Option that = is attached to the 2.04 response message; that seems a neater way to do it.= This Option doesn’t need to be recognized by anyone except the SEPs = and Mirror Servers that adhere to this specification so I don’t see any bad side-effects to CoAP by defining such Option = in a spec separate from core-coap.

 

So perhaps we can include a feature like this in MS,= to meet the home/industry demands for long battery life for sensor-type de= vices.

 

regards,

 

Esko

 


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_031DD135F9160444ABBE3B0C36CED618BFB1A4011DB3MPN2082MGDP_-- From cabo@tzi.org Fri Mar 29 03:15:29 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A4B21F93E9 for ; Fri, 29 Mar 2013 03:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.148 X-Spam-Level: X-Spam-Status: No, score=-106.148 tagged_above=-999 required=5 tests=[AWL=0.102, 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 bPP9+jyOXZBA for ; Fri, 29 Mar 2013 03:15:28 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 3B40B21F924F for ; Fri, 29 Mar 2013 03:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2TAFN9S010188; Fri, 29 Mar 2013 11:15:23 +0100 (CET) Received: from [192.168.217.105] (p548945DD.dip.t-dialin.net [84.137.69.221]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 655863663; Fri, 29 Mar 2013 11:15:23 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED618BFB1A4@011-DB3MPN2-082.MGDPHG.emi.philips.com> Date: Fri, 29 Mar 2013 11:15:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <031DD135F9160444ABBE3B0C36CED618BFB1A4@011-DB3MPN2-082.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1503) Cc: "core \(core@ietf.org\)" , "matthieu.vial@non.schneider-electric.com" Subject: Re: [core] Battery lifetime optimization idea for Mirror Server X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Mar 2013 10:15:29 -0000 Maybe this should be discussed in the context of bundling and batching. There would be no problem defining a new media-type that is essentially = a list of resources that might require attention. Since servers are = free to send back a PUT response of their liking, returning this media = type could be made into a convention for MS. (You might even misuse the link-format syntax for this.) While I have the attention of everybody interested in sleepy nodes: LWIG has a new version out of the terminology draft, with some = power-related terminology. We are likely to reference this in our specifications, so please do have = a look. Htmlized: =20 http://tools.ietf.org/html/draft-ietf-lwig-terminology-02 Diff from previous version: =20 http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lwig-terminology-02 Gr=FC=DFe, Carsten PS.: Oh, and calling them SEPs is part of a contest for how many = different unrelated meanings we can ascribe to this TLA? Like we do for = MAC? :-) From esko.dijk@philips.com Fri Mar 29 03:50:28 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01E621F91DF for ; Fri, 29 Mar 2013 03:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.765 X-Spam-Level: X-Spam-Status: No, score=-3.765 tagged_above=-999 required=5 tests=[AWL=-0.166, 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 4KQWq6qP1Hg1 for ; Fri, 29 Mar 2013 03:50:27 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id BFA5721F91D6 for ; Fri, 29 Mar 2013 03:50:27 -0700 (PDT) Received: from mail33-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.23; Fri, 29 Mar 2013 10:50:27 +0000 Received: from mail33-ch1 (localhost [127.0.0.1]) by mail33-ch1-R.bigfish.com (Postfix) with ESMTP id 1F0FAC01D1; Fri, 29 Mar 2013 10:50:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -32 X-BigFish: VPS-32(zz15d6O9251Jc89bh148cI542I217bIzz1f42h1fc6h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail33-ch1 (localhost.localdomain [127.0.0.1]) by mail33-ch1 (MessageSwitch) id 1364554224890691_27842; Fri, 29 Mar 2013 10:50:24 +0000 (UTC) Received: from CH1EHSMHS019.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.233]) by mail33-ch1.bigfish.com (Postfix) with ESMTP id ACE531C0098; Fri, 29 Mar 2013 10:50:24 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS019.bigfish.com (10.43.70.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 29 Mar 2013 10:50:23 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.99]) by 011-DB3MMR1-006.MGDPHG.emi.philips.com ([10.128.28.56]) with mapi id 14.02.0328.011; Fri, 29 Mar 2013 10:50:21 +0000 From: "Dijk, Esko" To: Carsten Bormann Thread-Topic: [core] Battery lifetime optimization idea for Mirror Server Thread-Index: Ac4sY//ao4HR1VWQR3a0MSoPPTxA4AAAlJ8AAADhYFA= Date: Fri, 29 Mar 2013 10:50:21 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618BFB281@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618BFB1A4@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core \(core@ietf.org\)" , "matthieu.vial@non.schneider-electric.com" Subject: Re: [core] Battery lifetime optimization idea for Mirror Server X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Mar 2013 10:50:28 -0000 Thanks for reminding ;) Exercising the LWIG terminology: Mirror Server clearly targets class S0 (Al= ways-off) devices and clearly not S2 (Always-on). What about class S1? I assume that class S1 "some form of network attachme= nt" means that the device is still reachable for CoAP requests. (e.g. becau= se nearby routers buffer IP packets for the sleepy device. An example for t= his is the "fast poll state" of ZigBee-IP; every 500 ms or sooner a node th= en wakes up to poll for packets at its parent router. Spec is now public at= http://www.zigbee.org/Specifications/ZigBeeIP/Download.aspx ). So only class S0 is targeted by Mirror Server if I'm correct. Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Friday, March 29, 2013 11:15 To: Dijk, Esko Cc: matthieu.vial@non.schneider-electric.com; core (core@ietf.org) Subject: Re: [core] Battery lifetime optimization idea for Mirror Server Maybe this should be discussed in the context of bundling and batching. There would be no problem defining a new media-type that is essentially a l= ist of resources that might require attention. Since servers are free to s= end back a PUT response of their liking, returning this media type could be= made into a convention for MS. (You might even misuse the link-format syntax for this.) While I have the attention of everybody interested in sleepy nodes: LWIG has a new version out of the terminology draft, with some power-relate= d terminology. We are likely to reference this in our specifications, so please do have a = look. Htmlized: http://tools.ietf.org/html/draft-ietf-lwig-terminology-02 Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lwig-terminology-02 Gr=FC=DFe, Carsten PS.: Oh, and calling them SEPs is part of a contest for how many different = unrelated meanings we can ascribe to this TLA? Like we do for MAC? :-) ________________________________ 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 Fri Mar 29 03:54:50 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B13921F93E3 for ; Fri, 29 Mar 2013 03:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.152 X-Spam-Level: X-Spam-Status: No, score=-106.152 tagged_above=-999 required=5 tests=[AWL=0.097, 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 RNmVC3XLp-NC for ; Fri, 29 Mar 2013 03:54: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 7890021F9169 for ; Fri, 29 Mar 2013 03:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2TAsjUe017662; Fri, 29 Mar 2013 11:54:45 +0100 (CET) Received: from [192.168.217.105] (p548945DD.dip.t-dialin.net [84.137.69.221]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F0AC13671; Fri, 29 Mar 2013 11:54:44 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED618BFB281@011-DB3MPN2-082.MGDPHG.emi.philips.com> Date: Fri, 29 Mar 2013 11:54:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <10A5A423-72B2-48F3-BDA4-84FF335FCE73@tzi.org> References: <031DD135F9160444ABBE3B0C36CED618BFB1A4@011-DB3MPN2-082.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED618BFB281@011-DB3MPN2-082.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1503) Cc: "core \(core@ietf.org\)" , "matthieu.vial@non.schneider-electric.com" Subject: Re: [core] Battery lifetime optimization idea for Mirror Server X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Mar 2013 10:54:50 -0000 On Mar 29, 2013, at 11:50, "Dijk, Esko" wrote: > So only class S0 is targeted by Mirror Server if I'm correct. Being able to say sentences like these in a concise way is exactly why = the terminology draft is so useful... Yes, that is my understanding of the Mirror Server concept as well. Gr=FC=DFe, Carsten From matthieu.vial@non.schneider-electric.com Fri Mar 29 05:28:49 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EEE21F93A0 for ; Fri, 29 Mar 2013 05:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 o11yRVVMtg6E for ; Fri, 29 Mar 2013 05:28:49 -0700 (PDT) Received: from mailX01.eud.schneider-electric.com (mailx01.eud.schneider-electric.com [205.167.7.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2B88621F9318 for ; Fri, 29 Mar 2013 05:28:49 -0700 (PDT) Received: from ateui03.schneider-electric.com ([10.198.21.36]) by mailX01.eud.schneider-electric.com with ESMTP id 2013032913284775-714860 ; Fri, 29 Mar 2013 13:28:47 +0100 In-Reply-To: References: <031DD135F9160444ABBE3B0C36CED618BFB1A4@011-DB3MPN2-082.MGDPHG.emi.philips.com> X-KeepSent: 6D53AA94:4AE0ED03-C1257B3D:003B2C0C; type=4; flags=0; name=$KeepSent To: Carsten Bormann X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: matthieu.vial@non.schneider-electric.com Date: Fri, 29 Mar 2013 13:28:46 +0100 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI03.Schneider-Electric.com/T/SVR/Schneider at 29/03/2013 13:28:47, Itemize by SMTP Server on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 29/03/2013 13:28:47, Serialize by Router on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 29/03/2013 13:28:49, Serialize complete at 29/03/2013 13:28:49 Content-type: multipart/alternative; Boundary="0__=4EBBF1AEDFA8AA9C8f9e8a93df938690918c4EBBF1AEDFA8AA9C" Content-Disposition: inline Cc: "core \(core@ietf.org\)" Subject: Re: [core] Battery lifetime optimization idea for Mirror Server X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Mar 2013 12:28:49 -0000 --0__=4EBBF1AEDFA8AA9C8f9e8a93df938690918c4EBBF1AEDFA8AA9C Content-type: text/plain; charset=US-ASCII Hi Carsten and Esko, >Since servers are free to send back a PUT response of their liking, returning this media type could be made into a convention for MS. It seems a bit strange to send back a payload that is unrelated with the target resource but I admit that it is efficient. Matthieu --0__=4EBBF1AEDFA8AA9C8f9e8a93df938690918c4EBBF1AEDFA8AA9C Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Hi Carsten and Esko,

>Since servers are free to send back a PUT response of their liking, returning this media type could be made into a convention for MS.

It seems a bit strange to send back a payload that is unrelated with the target resource but I admit that it is efficient.

Matthieu --0__=4EBBF1AEDFA8AA9C8f9e8a93df938690918c4EBBF1AEDFA8AA9C-- From matthieu.vial@non.schneider-electric.com Fri Mar 29 05:28:51 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722AD21F93A6 for ; Fri, 29 Mar 2013 05:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 F-gN4leDTtRV for ; Fri, 29 Mar 2013 05:28:51 -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 DD42921F9318 for ; Fri, 29 Mar 2013 05:28:50 -0700 (PDT) Received: from ateui03.schneider-electric.com ([10.198.21.36]) by mailX03.eud.schneider-electric.com with ESMTP id 2013032913284883-74785 ; Fri, 29 Mar 2013 13:28:48 +0100 In-Reply-To: <10A5A423-72B2-48F3-BDA4-84FF335FCE73@tzi.org> References: <031DD135F9160444ABBE3B0C36CED618BFB1A4@011-DB3MPN2-082.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED618BFB281@011-DB3MPN2-082.MGDPHG.emi.philips.com> <10A5A423-72B2-48F3-BDA4-84FF335FCE73@tzi.org> X-KeepSent: 518B3D67:900F0402-C1257B3D:003C4DE6; type=4; flags=0; name=$KeepSent To: Carsten Bormann X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: matthieu.vial@non.schneider-electric.com Date: Fri, 29 Mar 2013 13:28:48 +0100 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI03.Schneider-Electric.com/T/SVR/Schneider at 29/03/2013 13:28:48, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 29/03/2013 13:28:48, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 29/03/2013 13:28:50, Serialize complete at 29/03/2013 13:28:50 Content-type: multipart/alternative; Boundary="0__=4EBBF1AEDFAFCB768f9e8a93df938690918c4EBBF1AEDFAFCB76" Content-Disposition: inline Cc: "core \(core@ietf.org\)" Subject: Re: [core] Battery lifetime optimization idea for Mirror Server X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Mar 2013 12:28:51 -0000 --0__=4EBBF1AEDFAFCB768f9e8a93df938690918c4EBBF1AEDFAFCB76 Content-type: text/plain; charset=US-ASCII > So only class S0 is targeted by Mirror Server if I'm correct. Yes, but the idea is that a S0 is a kind of S1 when it is not off. Mirror Server is used in addition to optimized link-layer techniques. It doesn't aim at being a replacement. Matthieu --0__=4EBBF1AEDFAFCB768f9e8a93df938690918c4EBBF1AEDFAFCB76 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

> So only class S0 is targeted by Mirror Server if I'm correct.

Yes, but the idea is that a S0 is a kind of S1 when it is not off.
Mirror Server is used in addition to optimized link-layer techniques. It doesn't aim at being a replacement.

Matthieu
--0__=4EBBF1AEDFAFCB768f9e8a93df938690918c4EBBF1AEDFAFCB76-- From esko.dijk@philips.com Fri Mar 29 05:38:54 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC7B21F9401 for ; Fri, 29 Mar 2013 05:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.241 X-Spam-Level: X-Spam-Status: No, score=-3.241 tagged_above=-999 required=5 tests=[AWL=-0.643, 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 79ZlFkBHL6oL for ; Fri, 29 Mar 2013 05:38:54 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by ietfa.amsl.com (Postfix) with ESMTP id D3E7821F93FD for ; Fri, 29 Mar 2013 05:38:50 -0700 (PDT) Received: from mail5-db8-R.bigfish.com (10.174.8.238) by DB8EHSOBE011.bigfish.com (10.174.4.74) with Microsoft SMTP Server id 14.1.225.23; Fri, 29 Mar 2013 12:38:49 +0000 Received: from mail5-db8 (localhost [127.0.0.1]) by mail5-db8-R.bigfish.com (Postfix) with ESMTP id 85D6B720213; Fri, 29 Mar 2013 12:38:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VPS-30(zz15d6O9251Jc85fh217bIzz1f42h1fc6h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL18c673h8275bhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1155h) Received: from mail5-db8 (localhost.localdomain [127.0.0.1]) by mail5-db8 (MessageSwitch) id 1364560727525911_15597; Fri, 29 Mar 2013 12:38:47 +0000 (UTC) Received: from DB8EHSMHS029.bigfish.com (unknown [10.174.8.233]) by mail5-db8.bigfish.com (Postfix) with ESMTP id 7208454020D; Fri, 29 Mar 2013 12:38:47 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB8EHSMHS029.bigfish.com (10.174.4.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 29 Mar 2013 12:38:47 +0000 Received: from 011-DB3MMR1-022.MGDPHG.emi.philips.com (10.128.28.105) by 011-DB3MMR1-006.MGDPHG.emi.philips.com (10.128.28.56) with Microsoft SMTP Server (TLS) id 14.2.328.11; Fri, 29 Mar 2013 12:38:46 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.99]) by 011-DB3MMR1-022.MGDPHG.emi.philips.com ([fe80::1113:17d7:70dc:6faa%11]) with mapi id 14.02.0328.011; Fri, 29 Mar 2013 12:38:46 +0000 From: "Dijk, Esko" To: "matthieu.vial@non.schneider-electric.com" , Carsten Bormann Thread-Topic: [core] Battery lifetime optimization idea for Mirror Server Thread-Index: Ac4sY//ao4HR1VWQR3a0MSoPPTxA4AAAlJ8AAADhYFAAAH5xgAADSSsAAAA+OmA= Date: Fri, 29 Mar 2013 12:38:46 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618BFB370@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618BFB1A4@011-DB3MPN2-082.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED618BFB281@011-DB3MPN2-082.MGDPHG.emi.philips.com> <10A5A423-72B2-48F3-BDA4-84FF335FCE73@tzi.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.103] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618BFB370011DB3MPN2082MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core \(core@ietf.org\)" Subject: Re: [core] Battery lifetime optimization idea for Mirror Server X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Mar 2013 12:38:54 -0000 --_000_031DD135F9160444ABBE3B0C36CED618BFB370011DB3MPN2082MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In my understanding being a S0 device means that once you wake up, you can = still remain awake for arbitrary periods, even in an always-on mode (i.e. w= ithout doing any RF duty cycling, using a regular 802.15.4 link layer witho= ut optimized techniques, etc.). So indeed it then behaves as a S1 device o= r a S2 device would normally do all the time. Esko From: matthieu.vial@non.schneider-electric.com [mailto:matthieu.vial@non.sc= hneider-electric.com] Sent: Friday, March 29, 2013 13:29 To: Carsten Bormann Cc: core (core@ietf.org); Dijk, Esko Subject: Re: [core] Battery lifetime optimization idea for Mirror Server > So only class S0 is targeted by Mirror Server if I'm correct. Yes, but the idea is that a S0 is a kind of S1 when it is not off. Mirror Server is used in addition to optimized link-layer techniques. It do= esn't aim at being a replacement. Matthieu ________________________________ 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_031DD135F9160444ABBE3B0C36CED618BFB370011DB3MPN2082MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In my understanding bei= ng a S0 device means that once you wake up, you can still remain awake for = arbitrary periods, even in an always-on mode (i.e. without doing any RF duty cycling, using a regular 802.15.4 link layer without opt= imized techniques, etc.).  So indeed it then behaves as a S1 device or= a S2 device would normally do all the time.

 

Esko

 

From: matthi= eu.vial@non.schneider-electric.com [mailto:matthieu.vial@non.schneider-elec= tric.com]
Sent: Friday, March 29, 2013 13:29
To: Carsten Bormann
Cc: core (core@ietf.org); Dijk, Esko
Subject: Re: [core] Battery lifetime optimization idea for Mirror Se= rver

 

> So only class S0 is targeted b= y Mirror Server if I'm correct.

Yes, but the idea is that a S0 is a kind of S1 when it is not o= ff.
Mirror Server is used in addition to optimized link-layer techn= iques. It doesn't aim at being a replacement.

Matthieu


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_031DD135F9160444ABBE3B0C36CED618BFB370011DB3MPN2082MGDP_-- From cabo@tzi.org Fri Mar 29 06:22:16 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9825721F9403; Fri, 29 Mar 2013 06:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.156 X-Spam-Level: X-Spam-Status: No, score=-106.156 tagged_above=-999 required=5 tests=[AWL=0.093, 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 FNa9NZvslK2G; Fri, 29 Mar 2013 06:22:13 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id F3E9721F9401; Fri, 29 Mar 2013 06:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2TDM6lV003394; Fri, 29 Mar 2013 14:22:06 +0100 (CET) Received: from [192.168.217.105] (p5489300F.dip.t-dialin.net [84.137.48.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2BDE136A2; Fri, 29 Mar 2013 14:22:06 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <26808a929674c2b96850f40a9d7cd686@xs4all.nl> Date: Fri, 29 Mar 2013 14:22:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <18113.1339529290@marajade.sandelman.ca> <87AC724B-DC1F-41C2-9F1F-4357FA7B45A3@tzi.org> <31218.1345834358@sandelman.ca> <94E510D0-CFD3-45D5-BB4B-081A27D6AA4E@tzi.org> <26808a929674c2b96850f40a9d7cd686@xs4all.nl> To: "6lowpan@ietf.org" <6lowpan@ietf.org> X-Mailer: Apple Mail (2.1503) Cc: roll@ietf.org, "ipv6@ietf.org List" , "core \(core@ietf.org\)" Subject: [core] GHC now crunches DTLS (Re: [Roll] [6lowpan] draft-bormann-ghc) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Mar 2013 13:22:16 -0000 On Aug 25, 2012, at 13:41, peter van der Stok = wrote: > GHC applied to DTLS encrypted messages is interesting indeed. It may = represent an important number of messages to transmit. > I would concentrate on getting the GHC on DTLS results known and then = start pushing ghc draft. It took a while, but is now done: GHC-06 is ready for consumption. Htmlized: =20 http://tools.ietf.org/html/draft-bormann-6lowpan-ghc-06 Diff: =20 http://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-6lowpan-ghc-06 It turns out my gut feeling about how to design this was just about = right, so with all the research done, the only technical change from the = previous version is the addition of a 16-byte static dictionary. This = should result in about a 3-line change in an implementation (and 16 = bytes of increased temporary buffer size). The specification no longer = fits on a single page because that includes a note about the reserved = code points. I also have removed the speculative parts of GHC-05 -- there was little = interest in the added complexity. There is a little bit of innovative = formatting because I'm using XML2RFCv2 now; there should be fixes for = this soon. The examples have been expanded to show the compression of DTLS = handshake and application data messages; if you subtract the actual = payload (cleartext and authenticator), the total DTLS overhead is around = 8 bytes for application data (so, including the = TLS_PSK_WITH_AES_128_CCM_8 authenticator, a DTLS message is 16 bytes = longer than an uncompressed NoSec one). The examples section also shows = the very slight overall improvement to the compression (including a = regression, where the example ND advertisement now needs a byte more). I'm pretty sure now that we have reached the point of diminishing = returns. If we still had an active WG, I'd go for WG adoption and a WGLC soon. We'll see how to handle this in the shutdown phase of the 6lowpan WG. In the meantime, please do send in your comments (preferably to the = 6LoWPAN list). I'm CCing 6man because part of the proposal is a new ND (ICMPv6) option = for node capability indication. Specific comments on that probably best go to the 6man mailing list. Gr=FC=DFe, Carsten From cabo@tzi.org Fri Mar 29 14:25:15 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B254521E8089; Fri, 29 Mar 2013 14:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.164 X-Spam-Level: X-Spam-Status: No, score=-106.164 tagged_above=-999 required=5 tests=[AWL=0.085, 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 3tE71V32Jifc; Fri, 29 Mar 2013 14:25:15 -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 B17B021E8091; Fri, 29 Mar 2013 14:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2TLP8Mg018341; Fri, 29 Mar 2013 22:25:08 +0100 (CET) Received: from [192.168.217.105] (p5489300F.dip.t-dialin.net [84.137.48.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B18FF371E; Fri, 29 Mar 2013 22:25:07 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <1364591463.93179.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Fri, 29 Mar 2013 22:25:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9E50F482-9281-4787-A825-AAFF639E513B@tzi.org> References: <18113.1339529290@marajade.sandelman.ca> <87AC724B-DC1F-41C2-9F1F-4357FA7B45A3@tzi.org> <31218.1345834358@sandelman.ca> <94E510D0-CFD3-45D5-BB4B-081A27D6AA4E@tzi.org> <26808a929674c2b96850f40a9d7cd686@xs4all.nl> <1364591463.93179.YahooMailNeo@web142505.mail.bf1.yahoo.com> To: Mark Smith X-Mailer: Apple Mail (2.1503) Cc: "roll@ietf.org" , "6lowpan@ietf.org" <6lowpan@ietf.org>, "ipv6@ietf.org List" , "core \(core@ietf.org\)" Subject: Re: [core] GHC now crunches DTLS (Re: [Roll] [6lowpan] draft-bormann-ghc) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Mar 2013 21:25:15 -0000 On Mar 29, 2013, at 22:11, Mark Smith wrote: > RFC5175, "IPv6 Router Advertisement Flags Option" EFO was inspiration for 6CIO, but is different from 6CIO in that it is = about flags promulgated by a router (and therefore can only be used in = an RA). 6CIO is about the capabilities of the node sending that option. That's why they are not the same thing. 6CIO is indeed meant to be general enough to carry other node = capabilities that are relevant to a node-node situation. ROHC-over-802 = could have used it. That's why I'm proposing creating an IANA registry. = to make the other 47 bits available for other uses. I'm completely neutral to whether GHC's compression scheme and 6CIO = should be done in a combined draft or separate drafts. In the latter = case, stealing more text from 5175 is an obvious thing to do. Is there anything that could/should be generalized about 6CIO? (Without making it more complex, please.) Gr=FC=DFe, Carsten From Akbar.Rahman@InterDigital.com Fri Mar 29 21:16:02 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F8C21F88ED for ; Fri, 29 Mar 2013 21:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NF-C0OUEgXHJ for ; Fri, 29 Mar 2013 21:16:00 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id D83ED21F85E8 for ; Fri, 29 Mar 2013 21:15:56 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 30 Mar 2013 00:15:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 x-cr-hashedpuzzle: E/XS GjEl IIFW IQ2f JSTn LSWz RsGh Thsr TmQ1 XUQ9 YjYL YlQH aPJc bPye cH4B g/ct; 3; YwBvAHIAZQBAAGkAZQB0AGYALgBvAHIAZwA7AGUAcwBrAG8ALgBkAGkAagBrAEAAcABoAGkAbABpAHAAcwAuAGMAbwBtADsAaQBzAGEAbQAuAGkAcwBoAGEAcQBAAGkAbgB0AGUAYwAuAHUAZwBlAG4AdAAuAGIAZQA=; Sosha1_v1; 7; {4DD8AB99-2702-460F-AD06-EB83295084B0}; YQBrAGIAYQByAC4AcgBhAGgAbQBhAG4AQABpAG4AdABlAHIAZABpAGcAaQB0AGEAbAAuAGMAbwBtAA==; Sat, 30 Mar 2013 04:15:48 GMT; UgBFADoAIABbAGMAbwByAGUAXQAgAEEAbgB5ACAAZQB4AHAAZQByAGkAZQBuAGMAZQAgAGkAbgAgAHUAcwBpAG4AZwAgAEMAbwBBAFAAIAByAGUAcwBwAG8AbgBzAGUAcwAgAHQAbwBtAHUAbAB0AGkAYwBhAHMAdAAJAHIAZQBxAHUAZQBzAHQAcwA/AA== x-cr-puzzleid: {4DD8AB99-2702-460F-AD06-EB83295084B0} Content-class: urn:content-classes:message Date: Sat, 30 Mar 2013 00:15:48 -0400 Message-ID: In-Reply-To: <5154067E.3070802@intec.ugent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Any experience in using CoAP responses tomulticast requests? Thread-Index: Ac4rkpANAZjz0+GoTl6vDjsLtvppSgBaAbeQ References: <031DD135F9160444ABBE3B0C36CED618BF0286@011-DB3MPN2-082.MGDPHG.emi.philips.com> <5151C37A.1010205@intec.ugent.be> <031DD135F9160444ABBE3B0C36CED618BF6B53@011-DB3MPN2-082.MGDPHG.emi.philips.com> <5154067E.3070802@intec.ugent.be> From: "Rahman, Akbar" To: "Isam Ishaq" X-OriginalArrivalTime: 30 Mar 2013 04:15:55.0424 (UTC) FILETIME=[4611C200:01CE2CFD] Cc: core@ietf.org Subject: Re: [core] Any experience in using CoAP responses tomulticast requests? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 30 Mar 2013 04:16:02 -0000 SGkgSXNhbSwNCg0KDQpCYXNpY2FsbHksIEkgd2FzIGludGVyZXN0ZWQgaWYgeW91ciBleHBlcmlt ZW50cyBpbmNsdWRlZCBhbnkgYmVoYXZpb3IgZHVlIHRvIHRoZSB1bnJlbGlhYmlsaXR5IG9mIElQ IG11bHRpY2FzdCBzdWNoIGFzIHRoZSBmb2xsb3dpbmcgZXhhbXBsZSBvdXRsaW5lZCBpbiB0aGUg R3JvdXBjb21tIEktRDoNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1j b3JlLWdyb3VwY29tbS0wNSNzZWN0aW9uLTMuNg0KDQogICBvICBVcGRhdGUgZ3JvdXAgY29uZmln dXJhdGlvbiBkYXRhIHVzaW5nIG11bHRpY2FzdCBQVVQ6IG5vDQogICAgICBzdXBwcmVzc2lvbiBh dCBhbGwuICBVc2UgY29sbGVjdGVkIHJlc3BvbnNlcyB0byBpZGVudGlmeSB3aGljaA0KICAgICAg Z3JvdXAgbWVtYmVycyBkaWQgbm90IHJlY2VpdmUgdGhlIG5ldyBjb25maWd1cmF0aW9uOyB0aGVu IGF0dGVtcHQNCiAgICAgIHVzaW5nIENvQVAgQ09OIHVuaWNhc3QgdG8gdXBkYXRlIHRob3NlIGdy b3VwIG1lbWJlcnMuDQoNCg0KDQoNCkJlc3QgUmVnYXJkcywNCg0KDQpBa2Jhcg0KDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJc2FtIElzaGFxIFttYWlsdG86aXNhbS5pc2hh cUBpbnRlYy51Z2VudC5iZV0gDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMjgsIDIwMTMgNTowMCBB TQ0KVG86IFJhaG1hbiwgQWtiYXINCkNjOiBEaWprLCBFc2tvOyBjb3JlQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW2NvcmVdIEFueSBleHBlcmllbmNlIGluIHVzaW5nIENvQVAgcmVzcG9uc2VzIHRv bXVsdGljYXN0IHJlcXVlc3RzPw0KDQpIaSBBa2JhciwNCg0KV2UgZGlkIG5vdCBkbyBhbnkgdGVz dHMgd2Ugb3RoZXIgbWV0aG9kcy4NCkkgZG8gbm90IGV4cGVjdCB0aGF0IHRoZXJlIHdpbGwgYmUg YSBkaWZmZXJlbmNlIGluIHRoZSBiZWhhdmlvciBhcyBhIA0KcmVzdWx0IG9mIGNoYW5naW5nIHRo ZSBtZXRob2QgYWxvbmUuICBXaGF0IGNvdWxkIGNhdXNlIGRpZmZlcmVudCANCmJlaGF2aW9ycz8N Cg0KQmVzdCwNCklzYW0NCg0KDQpPbiBXZWRuZXNkYXksIE1hcmNoIDI3LCAyMDEzIDk6MDM6NTEg UE0sIFJhaG1hbiwgQWtiYXIgd3JvdGU6DQo+IEhpIElzYW0sDQo+DQo+IFllcywgaXQgd2FzIGlu ZGVlZCBhIHZlcnkgbmljZSBwYXBlciBhbmQgeW91ciBleHRyYSBwb2ludHMgYmVsb3cgYXJlDQo+ IGFsc28gaW5mb3JtYXRpdmUuICBJIGp1c3QgaGFkIG9uZSBxdWVzdGlvbi4gIFRoZSBwYXBlciBk ZXNjcmliZXMgeW91cg0KPiBNdWx0aWNhc3QgR0VUIHNjZW5hcmlvcy4gIERpZCB5b3UgZXZlciBz ZW5kIGFueSBvdGhlciBNdWx0aWNhc3QNCj4gbWV0aG9kcyAoZS5nLiBQVVQpPyAgQW5kIGlmIHNv LCBkaWQgeW91IG9ic2VydmUgYW55IGFkZGl0aW9uYWwNCj4gaW50ZXJlc3RpbmcgYmVoYXZpb3I/ DQo+DQo+IEJlc3QgUmVnYXJkcywNCj4NCj4gQWtiYXINCj4NCj4gKkZyb206KmNvcmUtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZg0KPiBP ZiAqRGlqaywgRXNrbw0KPiAqU2VudDoqIFdlZG5lc2RheSwgTWFyY2ggMjcsIDIwMTMgMTA6MDQg QU0NCj4gKlRvOiogSXNhbSBJc2hhcTsgY29yZUBpZXRmLm9yZw0KPiAqU3ViamVjdDoqIFJlOiBb Y29yZV0gQW55IGV4cGVyaWVuY2UgaW4gdXNpbmcgQ29BUCByZXNwb25zZXMNCj4gdG9tdWx0aWNh c3QgcmVxdWVzdHM/DQo+DQo+IFRoYW5rcyBJc2FtLA0KPg0KPiBJdOKAmXMgZ29vZCB0byBoZWFy IHRoYXQgdGhlIHR3byBtZWFzdXJlcyAoQ29BUCBMZWlzdXJlICsgcmFuZG9tIGRlbGF5DQo+IGlu IGZvcndhcmRpbmcpIHNvbHZlZCB0aGUgaXNzdWUuIENvQVAgc2VydmVyIGltcGxlbWVudGF0aW9u cyBTSE9VTEQNCj4gdXNlIHRoZSBMZWlzdXJlLCBhbmQgdGhlIHJhbmRvbSBmb3J3YXJkaW5nIGRl bGF5IGlzIGFsc28gYXBwbGllZCBpbg0KPiB0aGUgTXVsdGljYXN0IFByb3RvY29sIGZvciBMb3ct cG93ZXIgbG9zc3kgbmV0d29ya3MgKE1QTCkgb2YgdGhlIFJvTEwNCj4gV29ya2luZyBHcm91cC4N Cj4NCj4gSSB3b3VsZCBiZSBpbnRlcmVzdGVkIHRvIGhlYXIgYWJvdXQgdGhlIGV4dGVuZGVkIHBh cGVyIGFzIHdlbGwsIHdoZW4NCj4gaXQgaXMgcHVibGlzaGVkLg0KPg0KPiByZWdhcmRzLA0KPg0K PiBFc2tvDQo+DQo+ICpGcm9tOipjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjb3JlLWJv dW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYNCj4gT2YgKklzYW0gSXNoYXENCj4gKlNlbnQ6KiBU dWVzZGF5LCBNYXJjaCAyNiwgMjAxMyAxNjo0OQ0KPiAqVG86KiBjb3JlQGlldGYub3JnDQo+ICpT dWJqZWN0OiogUmU6IFtjb3JlXSBBbnkgZXhwZXJpZW5jZSBpbiB1c2luZyBDb0FQIHJlc3BvbnNl cyB0bw0KPiBtdWx0aWNhc3QgcmVxdWVzdHM/DQo+DQo+IERlYXIgRXNrbyBhbmQgYWxsLA0KPg0K PiBBdCBpTWluZHMgd2UgaGF2ZSBzb21lIGxpbWl0ZWQgZXhwZXJpZW5jZSB3aXRoIG11bHRpY2Fz dCBpbiB3aXJlbGVzcw0KPiBzZW5zb3IgbmV0d29ya3MuIFdlIGhhdmUgdXNlZCBtdWx0aWNhc3Qg Q29BUCByZXF1ZXN0cyBpbiBvcmRlciB0bw0KPiBkaXNjb3ZlciBzZW5zb3JzIGluc2lkZSBMTE5z LiBBdCB0aGUgbmV0d29ya2luZyBsYXllciBvZiB0aGUgTExOIHRoZQ0KPiBtdWx0aWNhc3QgbWVz c2FnZXMgd2VyZSByb3V0ZWQgYXMgYnJvYWRjYXN0cy4gV2UgaGF2ZSBjb25kdWN0ZWQgb3VyDQo+ IHRlc3RzIHVzaW5nIG91ciB0ZXN0YmVkIHdpdGggcmVhbCBzZW5zb3Igbm9kZXMgYW5kIGhhdmUg ZXhwZXJpbWVudGVkDQo+IHdpdGggbmV0d29yayBzaXplcyB1cCB0byA1MCBub2RlcyBpbiBkaWZm ZXJlbnQgbmV0d29yayB0b3BvbG9naWVzIHdpdGgNCj4gaG9wIGNvdW50cyBiZXR3ZWVuIDEgYW5k IDUgaG9wcy4NCj4NCj4gQXMgZXhwZWN0ZWQsIHRoZSB1c2Ugb2YgbXVsdGljYXN0L2Jyb2FkY2Fz dHMgcHJvdmVkIHRvIGJlDQo+IGNoYWxsZW5naW5nLiAgRXZlbiBmb3Igc21hbGwgc2Vuc29yIG5l dHdvcmtzICgxMCBub2RlcyBvciBsZXNzKSwgd2UNCj4gaGFkIGlzc3VlcyB3aXRoIGJyb2FkY2Fz dCBzdG9ybXMgaW4gdGhlIG5ldHdvcmsuIE9uZSByZWFzb24gZm9yIHRoZXNlDQo+IHN0b3JtcyB3 YXMgcmVsYXRlZCB0byByb3V0aW5nIChhIGJhc2ljIEFPRFYgaW1wbGVtZW50YXRpb24gaW4gb3Vy DQo+IGNhc2UpLiBPbmNlIHRoZSBzZW5zb3Igbm9kZXMgZ290IHRoZSBtdWx0aWNhc3QgYW5kIHdh bnRlZCB0byByZXBseQ0KPiB0aGV5IGFsbCBzdGFydGVkIGFza2luZyBmb3IgdGhlIHJvdXRlIHRv IHRoZSBnYXRld2F5IGF0IHRoZSBzYW1lIHRpbWUsDQo+IGNhdXNpbmcgdGhlIG5ldHdvcmsgdG8g YmVjb21lIHVucmVzcG9uc2l2ZS4gSW4gb3JkZXIgdG8gY29tYmF0IHRoaXMNCj4gYnJvYWRjYXN0 IHN0b3JtcyB3ZSBsZXQgdGhlIHNlbnNvciBnYXRld2F5IGJyb2FkY2FzdCBhIHJvdXRlIHJlcGx5 DQo+IHBhY2tldCBpbiB0aGUgbmV0d29yay4gVGhpcyBjYXVzZWQgYWxsIHNlbnNvcnMgdG8gZXN0 YWJsaXNoIGEgcm91dGUgdG8NCj4gdGhlIGdhdGV3YXkgYW5kIGVsaW1pbmF0ZWQgdGhlIG5lZWQg Zm9yIHRoZW0gdG8gc3RhcnQgYXNraW5nIGZvciBhDQo+IHJvdXRlIG9uY2UgdGhleSBnZXQgdGhl IGRpc2NvdmVyeSByZXF1ZXN0Lg0KPg0KPiBJbiBvdXIgaW1wbGVtZW50YXRpb24gdGhlIGJvYXJk ZXIgcm91dGVyIHNlbmRpbmcgdGhlIGJyb2FkY2FzdHMgd2FzDQo+IGFsc28gYSBjb25zdHJhaW5l ZCBkZXZpY2UgKFRtb3RlIFNreSkuIFNvIGl0IGNvdWxkIG5vdCBoYW5kbGUgYWxsIHRoZQ0KPiBy ZXBsaWVzIGl0IGdvdCBmcm9tIHRoZSBvdGhlciBzZW5zb3JzLCBiZWNhdXNlIHRoZXkgYXJyaXZl ZCB3aXRoIHNtYWxsDQo+IHRpbWUgZ2FwcyBiZXR3ZWVuIHRoZW0uIFRoaXMgbGVkIHRvIHRoZSBy ZWNlaXZlIGJ1ZmZlciBvbiB0aGUgYm9hcmRlcg0KPiByb3V0ZXIgdG8gc3RhcnQgZHJvcHBpbmcg cGFja2V0cy4gVG8gaGVscCBzb2x2aW5nIHRoaXMgaXNzdWUgd2UNCj4gaW50cm9kdWNlZCByYW5k b20gZGVsYXlzIGluIHRoZSBuZXR3b3JrIOKAkyBiZWZvcmUgcmVzcG9uZGluZyB0aGUgQ29BUA0K PiByZXF1ZXN0cyAoTGVpc3VyZSkgYW5kIGJlZm9yZSBmb3J3YXJkaW5nIGJyb2FkY2FzdHMgaW4g dGhlIG5ldHdvcmsuDQo+DQo+DQo+IEJ5IHVzaW5nIHRoZXNlIHRlY2huaXF1ZXMgd2UgaW1wcm92 ZWQgdGhlIGRlbGl2ZXJ5IG9mIHRoZSBtdWx0aWNhc3QNCj4gYW5kIHRoZSByZXN1bHRpbmcgdW5p Y2FzdCByZXBsaWVzIHZlcnkgbXVjaC4gU3RpbGwgc2luY2UgbXVsdGljYXN0cw0KPiBhcmUgZGVs aXZlcmVkIGluIGEgbm9uLWNvbmZpcm1hYmxlIHdheSwgdGhlcmUgd2FzIG5vIHdheSB0byB0ZWxs IHRoYXQNCj4gdGhlIG11bHRpY2FzdCBkaWQgYWN0dWFsbHkgZ2V0IHRvIGFsbCBub2Rlcy4gSW4g b3VyIGNhc2UgdGhpcyB3YXMgb2sNCj4gYW5kIGp1c3QgbWVhbnQgdGhhdCB0aGUgc2Vuc29ycyB0 aGF0IGRpZCBub3QgZ2V0IHRoZSBtdWx0aWNhc3QgdGhlDQo+IGZpcnN0IHRpbWUgd2lsbCBnZXQg aXQgdGhlIG5leHQgdGltZSB3aGVuIGEgbmV3IHBlcmlvZGljIHB1bGwgZm9yDQo+IGRpc2NvdmVy eSB3YXMgZG9uZS4NCj4NCj4gRmlyc3QgcmVzdWx0cyBvZiB0aGlzIHdvcmsgaGF2ZSBiZWVuIHB1 Ymxpc2hlZCBpbiB0aGUgZm9sbG93aW5nIHBhcGVyOg0KPiBodHRwOi8vaWVlZXhwbG9yZS5pZWVl Lm9yZy9zdGFtcC9zdGFtcC5qc3A/dHA9JmFybnVtYmVyPTYyOTY5NDMmaXNudW1iZXI9NjI5Njgy Mg0KPg0KPiBBbiBleHRlbmRlZCB2ZXJzaW9uIG9mIHRoaXMgcGFwZXIgd2l0aCBtb3JlIGV4cGVy aW1lbnRhbCByZXN1bHRzIGlzDQo+IGN1cnJlbnRseSB1bmRlciByZXZpZXcuIEF0IHRoaXMgbW9t ZW50LCB3ZSBhcmUgYWxzbyBleHBsb3JpbmcgdGhlIHVzZQ0KPiBvZiBhbiBpbnRlcm1lZGlhcnkg dG8gb2ZmZXIgZ3JvdXAgY29tbXVuaWNhdGlvbiBmdW5jdGlvbmFsaXR5IGJhc2VkIG9uDQo+IHVu aWNhc3QgKHBhcGVyIHVuZGVyIHJldmlldykuIFdlIGFyZSBhbHNvIGludGVyZXN0ZWQgY29tcGFy aW5nIHRoaXMNCj4gYXBwcm9hY2ggd2l0aCBhIGNvbXBsZXRlIG11bHRpY2FzdCBzb2x1dGlvbiBm b3IgYSBMTE4uDQo+DQo+IEJlc3QgUmVnYXJkcywNCj4gSXNhbSBJc2hhcQ0KPg0KPg0KPg0KPiBP biAyNS1NYXItMTMgMTA6MTYgQU0sIERpamssIEVza28gd3JvdGU6DQo+DQo+ICAgICBEZWFyIGFs bCwNCj4NCj4gICAgIG9uZSBvZiB0aGUgcmV2aWV3IGNvbW1lbnRzIHRvIHRoZSBHcm91cENvbW0g SS1EIGNvbmNlcm5zIHRoZSBsYWNrDQo+ICAgICBvZiAoaW1wbGVtZW50YXRpb24gb3Igc2ltdWxh dGlvbikgZXhwZXJpZW5jZSB3aXRoIHVzZSBvZiBDb0FQDQo+ICAgICBtdWx0aWNhc3QsIGFuZCB0 aGUgYXNzb2NpYXRlZCBtdWx0aXR1ZGUgb2YgQ29BUCByZXNwb25zZXMuIFRoZSBJLUQNCj4gICAg IHByb3ZpZGVzIGd1aWRlbGluZXMgaW4gdGhpcyBhcmVhIGJ1dCBub3QgYmFzZWQgb24gc3VjaCBl eHBlcmllbmNlLg0KPg0KPiAgICAgRGlkIGFueW9uZSBleHBlcmltZW50IHdpdGggQ29BUCBtdWx0 aWNhc3Q/IChPciBrbm93cyBzb21lb25lLCBvciBhDQo+ICAgICBwdWJsaWNhdGlvbiBldGMuKQ0K Pg0KPiAgICAgcmVnYXJkcywNCj4NCj4gICAgIEVza28NCj4NCj4gICAgIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPg0KPiAgICAgVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5 IGJlIGNvbmZpZGVudGlhbCBhbmQNCj4gICAgIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFwcGxp Y2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZA0KPiAgICAgc29sZWx5IGZvciB0aGUg YWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCj4gICAgIHJlY2lwaWVu dCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLA0KPiAg ICAgZGlzc2VtaW5hdGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgbWVzc2FnZSBpcyBzdHJp Y3RseQ0KPiAgICAgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQNCj4gICAgIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRl ciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95DQo+ICAgICBhbGwgY29waWVzIG9mIHRoZSBv cmlnaW5hbCBtZXNzYWdlLg0KPg0KPg0KPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4NCj4gICAgIGNvcmUgbWFpbGluZyBsaXN0DQo+DQo+ICAg ICBjb3JlQGlldGYub3JnICA8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+DQo+DQo+ICAgICBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCj4NCj4NCj4NCj4gLS0NCj4gSXNh bSBJc2hhcQ0KPiBEZXBhcnRtZW50IG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3kNCj4gSW50ZXJu ZXQgQmFzZWQgQ29tbXVuaWNhdGlvbiBOZXR3b3JrcyBhbmQgU2VydmljZXMgKElCQ04pDQo+IEdo ZW50IFVuaXZlcnNpdHkgLSBpTWluZHMNCj4gR2FzdG9uIENyb21tZW5sYWFuIDggKEJ1cyAyMDEp LCBCLTkwNTAgR2VudCwgQmVsZ2l1bQ0KPiBNOiArMzIgKDApNDg0IDg1NiAxNTUNCj4gVDogKzMy ICgwKTkgMzMgMTQ5NDYNCj4gVCBTZWNyOiArMzIgKDApOSAzMyAxNDkwMA0KPiBGOiArMzIgKDAp OSAzMyAxNDg5OQ0KPiBFOmlzYW0uaXNoYXFAaW50ZWMuVUdlbnQuYmUgIDxtYWlsdG86aXNhbS5p c2hhcUBpbnRlYy5VR2VudC5iZT4NCj4gVyA6d3d3LmliY24uaW50ZWMuVUdlbnQuYmUgIDxodHRw Oi8vd3d3LmliY24uaW50ZWMuVUdlbnQuYmU+DQoNCg0KDQotLQ0KSXNhbSBJc2hhcQ0KRGVwYXJ0 bWVudCBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5DQpJbnRlcm5ldCBCYXNlZCBDb21tdW5pY2F0 aW9uIE5ldHdvcmtzIGFuZCBTZXJ2aWNlcyAoSUJDTikNCkdoZW50IFVuaXZlcnNpdHkgLSBpTWlu ZHMNCkdhc3RvbiBDcm9tbWVubGFhbiA4IChCdXMgMjAxKSwgQi05MDUwIEdlbnQsIEJlbGdpdW0N Ck06ICszMiAoMCk0ODQgODU2IDE1NQ0KVDogKzMyICgwKTkgMzMgMTQ5NDYNClQgU2VjcjogKzMy ICgwKTkgMzMgMTQ5MDANCkY6ICszMiAoMCk5IDMzIDE0ODk5DQpFOiBpc2FtLmlzaGFxQGludGVj LlVHZW50LmJlDQpXIDogd3d3LmliY24uaW50ZWMuVUdlbnQuYmUNCg== From internet-drafts@ietf.org Sat Mar 30 14:34:14 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D30621F86D3; Sat, 30 Mar 2013 14:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnJ8NpzqXzBh; Sat, 30 Mar 2013 14:34:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B3921F867E; Sat, 30 Mar 2013 14:34:13 -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.43 Message-ID: <20130330213413.3315.36778.idtracker@ietfa.amsl.com> Date: Sat, 30 Mar 2013 14:34:13 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-block-11.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 21:34:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Blockwise transfers in CoAP Author(s) : Carsten Bormann Zach Shelby Filename : draft-ietf-core-block-11.txt Pages : 29 Date : 2013-03-30 Abstract: CoAP is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices. Occasionally, however, applications will need to transfer larger payloads -\u002D for instance, for firmware updates. With HTTP, TCP does the grunt work of slicing large payloads up into multiple packets and ensuring that they all arrive and are handled in the right order. CoAP is based on datagram transports such as UDP or DTLS, which limits the maximum size of resource representations that can be transferred without too much fragmentation. Although UDP supports larger payloads through IP fragmentation, it is limited to 64 KiB and, more importantly, doesn't really work well for constrained applications and networks. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options, for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. In summary, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. The present revision -11 fixes one example and adds the text and examples about the Block/Observe interaction, taken from -observe. It also adds a couple of formatting bugs from the new xml2rfc. The "grand rewrite" is next. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-block There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-block-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-block-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trac+core@trac.tools.ietf.org Sat Mar 30 14:41:01 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E2721F86D9 for ; Sat, 30 Mar 2013 14:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQmnoaghaj-U for ; Sat, 30 Mar 2013 14:41:00 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9091121F8691 for ; Sat, 30 Mar 2013 14:41:00 -0700 (PDT) Received: from localhost ([127.0.0.1]:44989 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UM3WB-0007fh-Bp; Sat, 30 Mar 2013 22:40:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: cabo@tzi.org X-Trac-Project: core Date: Sat, 30 Mar 2013 21:40:55 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/245#comment:2 Message-ID: <066.9921d1ac53abde05e305e0cd848e4833@trac.tools.ietf.org> References: <051.25002bcbb00ea4e0153e473b6ddf6c60@trac.tools.ietf.org> X-Trac-Ticket-ID: 245 In-Reply-To: <051.25002bcbb00ea4e0153e473b6ddf6c60@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #245: Compression vs. Block 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, 30 Mar 2013 21:41:01 -0000 #245: Compression vs. Block Changes (by cabo@tzi.org): * status: assigned => closed * resolution: => fixed Comment: Fixed in [1265]: Fix #203 Fix #206 Fix #209 Fix #210 Fix #245 -- -----------------------------+--------------------------- Reporter: cabo@tzi.org | Owner: cabo@tzi.org Type: other technical | Status: closed Priority: minor | Milestone: post-WGLC-1 Component: block | Version: block-08 Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+--------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sat Mar 30 14:41:01 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3573321F8691 for ; Sat, 30 Mar 2013 14:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SAD1qES8ZEY for ; Sat, 30 Mar 2013 14:41:00 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8E15221F8633 for ; Sat, 30 Mar 2013 14:41:00 -0700 (PDT) Received: from localhost ([127.0.0.1]:45000 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UM3WB-0007hi-G4; Sat, 30 Mar 2013 22:40:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-block@tools.ietf.org, hartke@tzi.org, cabo@tzi.org X-Trac-Project: core Date: Sat, 30 Mar 2013 21:40:55 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/206#comment:3 Message-ID: <066.68032c85d5a604e69f50ecae9d4ed319@trac.tools.ietf.org> References: <051.965a95dc46e1afb12f7d1a12aed61bdf@trac.tools.ietf.org> X-Trac-Ticket-ID: 206 In-Reply-To: <051.965a95dc46e1afb12f7d1a12aed61bdf@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, hartke@tzi.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, zach@sensinode.com Resent-Message-Id: <20130330214100.8E15221F8633@ietfa.amsl.com> Resent-Date: Sat, 30 Mar 2013 14:41:00 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #206: Clarify that atomic Block1 transfers match per token *and* endpoint 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, 30 Mar 2013 21:41:01 -0000 #206: Clarify that atomic Block1 transfers match per token *and* endpoint Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1265]: Fix #203 Fix #206 Fix #209 Fix #210 Fix #245 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | block@tools.ietf.org Type: editorial | Status: closed Priority: major | Milestone: post-WGLC-1 Component: block | Version: block-08 Severity: In WG Last | Resolution: fixed Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sat Mar 30 14:41:01 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882B821F8633 for ; Sat, 30 Mar 2013 14:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOfjeO-49TZA for ; Sat, 30 Mar 2013 14:41:01 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8E20021F8634 for ; Sat, 30 Mar 2013 14:41:00 -0700 (PDT) Received: from localhost ([127.0.0.1]:44993 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UM3WB-0007gz-EW; Sat, 30 Mar 2013 22:40:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: cabo@tzi.org, hartke@tzi.org X-Trac-Project: core Date: Sat, 30 Mar 2013 21:40:55 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/210#comment:3 Message-ID: <066.e5045b070fc30ba432911a883e1cf1ce@trac.tools.ietf.org> References: <051.d904ee0bea6c59be24fc5a28e7e8cf18@trac.tools.ietf.org> X-Trac-Ticket-ID: 210 In-Reply-To: <051.d904ee0bea6c59be24fc5a28e7e8cf18@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: cabo@tzi.org, hartke@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #210: Disentangle Block and Token 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, 30 Mar 2013 21:41:01 -0000 #210: Disentangle Block and Token Changes (by cabo@tzi.org): * status: assigned => closed * resolution: => fixed Comment: Fixed in [1265]: Fix #203 Fix #206 Fix #209 Fix #210 Fix #245 -- -----------------------------+--------------------------- Reporter: cabo@tzi.org | Owner: cabo@tzi.org Type: editorial | Status: closed Priority: major | Milestone: post-WGLC-1 Component: block | Version: block-08 Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+--------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sat Mar 30 14:41:02 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E9B21F8633 for ; Sat, 30 Mar 2013 14:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suIYEJX5jRNC for ; Sat, 30 Mar 2013 14:41:01 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 92D4D21F86B9 for ; Sat, 30 Mar 2013 14:41:00 -0700 (PDT) Received: from localhost ([127.0.0.1]:44992 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UM3WB-0007gI-D6; Sat, 30 Mar 2013 22:40:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Sat, 30 Mar 2013 21:40:55 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/203#comment:1 Message-ID: <066.d631da3f84cacd0789587dc0bb8b6ec6@trac.tools.ietf.org> References: <051.c9f279ab8cd10352f182c29fc7692982@trac.tools.ietf.org> X-Trac-Ticket-ID: 203 In-Reply-To: <051.c9f279ab8cd10352f182c29fc7692982@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, zach@sensinode.com Resent-Message-Id: <20130330214100.92D4D21F86B9@ietfa.amsl.com> Resent-Date: Sat, 30 Mar 2013 14:41:00 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [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: Sat, 30 Mar 2013 21:41:02 -0000 #203: Restrict the potential combinations of Block1 and Block2 Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1265]: Fix #203 Fix #206 Fix #209 Fix #210 Fix #245 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | block@tools.ietf.org Type: protocol | Status: closed defect | Milestone: Priority: major | Version: Component: block | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sat Mar 30 14:41:04 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4646421F87A4 for ; Sat, 30 Mar 2013 14:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odRNWL0NZZ2o for ; Sat, 30 Mar 2013 14:41:03 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 67DA721F873D for ; Sat, 30 Mar 2013 14:41:03 -0700 (PDT) Received: from localhost ([127.0.0.1]:44988 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UM3WB-0007ea-AF; Sat, 30 Mar 2013 22:40:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-block@tools.ietf.org, hartke@tzi.org, cabo@tzi.org X-Trac-Project: core Date: Sat, 30 Mar 2013 21:40:55 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/209#comment:2 Message-ID: <066.c66f797ac2c73643af2750f143b905b9@trac.tools.ietf.org> References: <051.51f78e9af0ddc8ee31f86b5cb9ac3c19@trac.tools.ietf.org> X-Trac-Ticket-ID: 209 In-Reply-To: <051.51f78e9af0ddc8ee31f86b5cb9ac3c19@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-block@tools.ietf.org, hartke@tzi.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, zach@sensinode.com Resent-Message-Id: <20130330214103.67DA721F873D@ietfa.amsl.com> Resent-Date: Sat, 30 Mar 2013 14:41:03 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #209: Add potential attacks to security considerations 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, 30 Mar 2013 21:41:04 -0000 #209: Add potential attacks to security considerations Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1265]: Fix #203 Fix #206 Fix #209 Fix #210 Fix #245 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | block@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: post-WGLC-1 Component: block | Version: block-08 Severity: In WG Last | Resolution: fixed Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From michael.scharf@alcatel-lucent.com Sun Mar 31 10:55:26 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4A021F845B; Sun, 31 Mar 2013 10:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.847 X-Spam-Level: X-Spam-Status: No, score=-9.847 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MreIuviojN+J; Sun, 31 Mar 2013 10:55:24 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id F3E7221F844C; Sun, 31 Mar 2013 10:55:23 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2VHtKeJ027727 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 31 Mar 2013 19:55:21 +0200 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Sun, 31 Mar 2013 19:55:20 +0200 From: "Scharf, Michael (Michael)" To: "tsv-ads@tools.ietf.org" , "tsv-dir@ietf.org" Date: Sun, 31 Mar 2013 19:55:18 +0200 Thread-Topic: tsv-dir review of draft-ietf-core-coap-14 Thread-Index: Ac4uOOf4f4Pc/M6rS0adQgDVIZrbFg== Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6F16@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "draft-ietf-core-coap@tools.ietf.org" , "core-chairs@tools.ietf.org" , The IESG , "core@ietf.org" , "ietf@ietf.org" Subject: [core] tsv-dir review of draft-ietf-core-coap-14 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 31 Mar 2013 17:55:26 -0000 I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. This draft is on the right track but has open issues, described in the review. Review - good news: I have reviewed few selected aspects in draft-ietf-core-coap-09 (http://www.ietf.org/mail-archive/web/core/current/msg03280.html). I confirm that those past concerns are sufficiently addressed by this document. Review - not so good news: * General: In a nutshell, this document proposes a rather lightwight protocol that provides a subset of TCP/HTTP transport. In order to reduce message sizes and implementation complexity, the protocol sacrifies many TCP/HTTP features. But I really had a hard time figuring out what the protocol as defined in this document does *not* provide, in particular in the message layer. At first sight, the CoAP protocol as defined in this document lacks features such as: - Support for messages exceeding the path MTU - Byte stream transport with segmentation and reassembly - Flow control - Congestion control for non-confirmable messages (this must IMHO be fixed) Further typical TCP features are pretty much left to the implementation or to extensions which will make the protocol more complex (imho, as complex as TCP): - In-order delivery of unconfirmed messages (for confirmed messages, delivery seems to be in-order right now if the implementation indeed complies to the mandated limit of one out-standing transaction per destination, but any application requiring a data transfer of more than 1KB will need something better) - Strong protection against message duplication (in particular if some checks are disabled based on cross-layer assumptions, which is allowed by this spec) - Non-trivial transport features for multicast - Security and DoS protection (mostly out-of-scope of this review) These aspects are further detailed below with specific text references. =3D> I think that the document needs a disclaimer in Section 1 that explicitly explains what users cannot expect from the CoAP base protocol (say, compared to a light-weight HTTP/TCP implementation with HTTP compression and the absolute minimum set of TCP features). * General: The message layer, which basically provides a transport protocol service, is in parts only vaguely specified, and many transport-related protocol features can be overwriten by implementation or environment-specific settings, or by future extensions drafts. This makes it very difficult to review the protocol regarding completeness and robustness, such as atypical packet arrival patterns, reordering, and other corner cases that fundamentally matter for a transport protocol design. I believe that the protocol is simple enough that a full description of the state engine and event processing would be possible (like RFC 793 Section 3.9. Event Processing). But without a rigourous specification, it is difficult to figure out what a CoAP implementation would do in many corner cases, and if interoperable implementations would interprete the spec in the same way. =3D> The following list of open issues is almost certainly incomplete; other TSV experts might identify further problems. * Section 4.2 A CoAP endpoint that sent a Confirmable message MAY give up in attempting to obtain an ACK even before the MAX_RETRANSMIT counter value is reached: E.g., the application has canceled the request as it no longer needs a response, or there is some other indication that the CON message did arrive. 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. However, a responder MUST NOT in turn rely on this cross-layer behavior from a requester, i.e. it SHOULD retain the state to create the ACK for the request, if needed, even if a Confirmable response was already acknowledged by the requester. =3D> I think that this situation can also occur during an attack with spoofed addresses, i. e., it is not "clear" that the ACK was lost. In that case, retransmitting the request may even be the better alternative, in order to identify the attack. As already mentioned, state diagrams and a clear event handling would help to identify such corner cases (there may be more than this specific one). This would also simplify discussion when it is indeed save to release state information. * Section 4.3 At the CoAP level, there is no way for the sender to detect if a Non- confirmable message was received or not. A sender MAY choose to transmit multiple copies of a Non-confirmable message within MAX_TRANSMIT_SPAN, or the network may duplicate the message in transit. =3D> This section lacks any guidance on how frequently non-confirmable messages may be sent. Section 4.7 mandates a maximum PROBING_RATE for congestion control. With the default parameters, MAX_TRANSMIT_SPAN is 45s, and PROBING_RATE is 1 Byte/second, i. e., for messages larger than 45 Byte, the limit for multiple copies is given by MESSAGE_SIZE/PROBING_RATE, not by MAX_TRANSMIT_SPAN. `* Section 4.5 o A constrained server MAY even want to relax this requirement for certain non-idempotent requests if the application semantics make this trade-off favorable. For example, if the result of a POST request is just the creation of some short-lived state at the server, it may be less expensive to incur this effort multiple times for a request than keeping track of whether a previous transmission of the same request already was processed. =3D> I think that this section must stronger state that both endpoints must agree on those modified semantics. Otherwise, it is not clear to me whether the client and server implementations would indeed be interoperable, in particular, if they are implemented independently and thus make different assumptions. The client here asked for reliable transfer, but the server actually ignores that requests for reliabile transfer, right? * Section 4.6 Message sizes are also of considerable importance to implementations on constrained nodes. Many implementations will need to allocate a buffer for incoming messages. If an implementation is too constrained to allow for allocating the above-mentioned upper bound, it could apply the following implementation strategy: Implementations receiving a datagram into a buffer that is too small are usually able to determine if the trailing portion of a datagram was discarded and to retrieve the initial portion. So, if not all of the payload, at least the CoAP header and options are likely to fit within the buffer. A server can thus fully interpret a request and return a 4.13 (Request Entity Too Large) response code if the payload was truncated. A client sending an idempotent request and receiving a response larger than would fit in the buffer can repeat the request with a suitable value for the Block Option [I-D.ietf-core-block]. =3D> This document must include a discussion on flow control, i. e., what happens if the receiver's receive buffer is full or if an application stalls and does not consume data for longer time (exceeding the retransmission timeout). Explanation: For constrainted devices with small receive buffers and communication with more than one endpoint, it seems to me pretty likely that at some points in time no receive buffer is available. The protocol spec does not discuss what happens if the buffer is to small to process even the header, and what the behavior of the receiver should be (silently dropping the incoming message? sending a RST? does the behavior depend on whether it is CON or NON?). I think that this spec must provide guidance how the protocol deals with buffer shortage. TCP's solution to this kind of situations is flow control by the receive window. In CoAP, there seems to be an implicit assumption that messages can either always be "somehow" processed by a receiver or savely be dropped. As long as the protocol allows only one outstanding transaction per destination, and allocates dedicated receive buffer for a full CoAP packet for each destination, out-of-my head this indeed seems to work without deadlocks because we basically have the alternating-bit-protocol. But in more complex situations with small buffer sizes (e. g., multiple transactions/applications sharing one buffer, or insequence-delivery for more than one transaction), I think that the protocol could run into deadlocks because it cannot prevent a sender from sending or retransmitting data into a receiver not having any receive buffer. I am not an expert on formal protocol verification, i. e., I cannot provide an exact specification for the minimum set of implementation requirements that savely prevents deadlock (also see my other remarks on state engine specification). But I am really concerned that the document does not even mention the terms "flow control", "buffer sizing", etc. * Section 4.7 In order not to cause congestion, Clients (including proxies) MUST strictly limit the number of simultaneous outstanding interactions that they maintain to a given server (including proxies) to NSTART. An outstanding interaction is either a CON for which an ACK has not yet been received but is still expected (message layer) or a request for which neither a response nor an Acknowledgment message has yet been received but is still expected (which may both occur at the same time, counting as one outstanding interaction). The default value of NSTART for this specification is 1. =3D> This section MUST clarify congestion control for non-confirmable messages. I miss a clear recommendation how frequently a sender is allowed to send non-confirmable messages if there is no other feedback. I think that a maximum data rate of PROBING_RATE would be reasonable and save, but I recall some discussion on other proposals (e. g., mandating a confirmable message every X non-confirmable messages, etc.). * Section 4.8.2 o PROCESSING_DELAY is the time a node takes to turn around a Confirmable message into an acknowledgement. We assume the node will attempt to send an ACK before having the sender time out, so as a conservative assumption we set it equal to ACK_TIMEOUT. =3D> I assume that the spec wants to say "a receiver MUST have sent an ACK after PROCESSING_DELAY"? I have not found that requirement elsewhere in the document. If it is not a MUST requirement, the calculations involving PROCESSING_DELAY seem to be not the worst case and are therefore not really useful for worst-case analysis. * Section 5.3.1 A token is intended for use as a client-local identifier for differentiating between concurrent requests (see Section 5.3); it could have been called a "request ID". =3D> Im my understanding, concurrent requests are not allowed by this spec, i. e., why does this document not recommend to use an empty token as long as NSTART=3D1? It apparently just wastes scace bandwidth if there is only one allowed request to a destination. As an editorial note, this reference to Section 5.3 is strange here; this is the only paragraph in the document where concurrent requests are mentioned. * Section 5.3.2 The exact rules for matching a response to a request are as follows: 1. The source endpoint of the response MUST be the same as the destination endpoint of the original request. 2. In a piggy-backed response, both the Message ID of the Confirmable request and the Acknowledgement, and the token of the response and original request MUST match. In a separate response, just the token of the response and original request MUST match. In case a message carrying a response is unexpected (the client is not waiting for a response from the identified endpoint, at the endpoint addressed, and/or with the given token), the response is rejected (Section 4.2, Section 4.3). =3D> To me, the CoAP message processing seems underspecified. What really happens if either the msg and token mismatch (two entirely different cases), i. e., what will the endpoint put into the RST message? Section 4.2 states "The Acknowledgement message MUST echo the Message ID of the Confirmable message, and MUST carry a response or be empty (see Section 5.2.1 and Section 5.2.2)."; based on text I cannot figure out what the response would be. For interoperability between implementations, this sort of events matter. =3D> Would it be allowed to send back a response both by a CON and a NON message, with the same token, but different message IDs? If so, how would the matching deal with this? * Section 5.3.2 Implementation Note: A client that receives a response in a CON message may want to clean up the message state right after sending the ACK. If that ACK is lost and the server retransmits the CON, the client may no longer have any state to correlate this response to, making the retransmission an unexpected message; the client may send a Reset message so it does not receive any more retransmissions. This behavior is normal and not an indication of an error. (Clients that are not aggressively optimized in their state memory usage will still have message state that will identify the second CON as a retransmission. Clients that actually expect more messages from the server [I-D.ietf-core-observe] will have to keep state in any case.) =3D> I am confused by this sort of argument of removing state. This statement probably refers to Token state, since some kind of Message ID state has to be kept at least for MAX_LATENCY according to Section 4.8.2? Again, I'd expect the protocol specification to clearly state what the minimum requirements on keeping state are. * Section 5.4 and Section 5.10 =3D> The maximum size of these options, in particular if more than one is used at the same time, can easily exceed the IPv6 MTU of 1280 bytes. In other words, a single non-fragmented IP packet will not only have not enough space for payload if options are used, possibly a single packet will not even be sufficient to transport all required options? What does the CoAP base protocol do in that case? Discard that request/response and return an application error? Why does Section 5 not have any guidance on size/segmentation issues if options are (too) large? * Section 8.1 A multicast request is characterized by being transported in a CoAP message that is addressed to an IP multicast address instead of a CoAP endpoint. Such multicast requests MUST be Non-confirmable. =3D> A normative statement on congestion control for *sending* to multicast addresses is missing. I think that a slow-speed network can get very easily congested by multicast messages, i. e., this matters for the main CoAP use cases. I believe that sending 1 Byte/second is save for multicast destinations. * Section 8.1 When a server is aware that a request arrived via multicast, it MUST NOT return a RST in reply to NON. If it is not aware, it MAY return a RST in reply to NON as usual. Because such a Reset message will look identical to an RST for a unicast message from the sender, the sender MUST avoid using a Message ID that is also still active from this endpoint with any unicast endpoint that might receive the multicast message. =3D> Why is a RST forbidden by a MUST? I would understand the motivation for a SHOULD, but if a server is overloaded by multicast requests and runs out of processing resources for multicast requests, isn't there a need to tell the sender that it has to stop using this multicast group? * Section 8.2 When matching a response to a multicast request, only the token MUST match; the source endpoint of the response does not need to (and will not) be the same as the destination endpoint of the original request. =3D> So, the token is the only way to deal with packets that are duplicated in the network? Then, this section must IMHO expand further on how to select token IDs for multicast transfer. For use in multicast, Section 5.3.1. "The client SHOULD generate tokens in such a way that tokens currently in use for a given source/destination endpoint pair are unique." is not sufficient; the token must in addition be unique during MAX_LATENCY, right? * Section 8.2 If a server does decide to respond to a multicast request, it should not respond immediately. =3D> The spec leaves open if a server is allowed to respond with confirmed message. If a large number of servers respond, the ACK traffic for many CONs could be an issue, right? But if only NON is allowed, what happens if the server wants that its message is indeed delivered reliably to the requester? * Section 8.2 E.g., for a multicast request with link-local scope on an 2.4 GHz IEEE 802.15.4 (6LoWPAN) network, G could be (relatively conservatively) set to 100, S to 100 bytes, and the target rate to a conservative 8 kbit/s =3D 1 kB/s. The resulting lower bound for the Leisure is 10 seconds. =3D> While I like the idea of randomizing the response time to avoid in-cast problems, according to Section 4.8, a conservative assumption about the allowed data rate in a potentially congested network is PROBING_RATE =3D 1 Byte/second. 1 kB/s might be realistic in a specific application scenario if the network does not have any other traffic, but the attribute "conservative" should not be used here, because reality with cross-traffic could be entirely different. * Section 8.2 If a CoAP endpoint does not have suitable data to compute a value for Leisure, it MAY resort to DEFAULT_LEISURE. =3D> With this vague specification of leisure time the client has no means to know whether *any* response will ever arrive. The servers could, for instance, err on the size of the group and just pick all a large random leasure time. I think it would make sense to define an upper limit on the leasure time, to allow some interpretation on the client side. If this upper limit significantly exceeds the rate PROBING_RATE, servers may just randomly decide not to reply, instead of waiting for a long time. * Section 8.2.2 When a forward-proxy receives a request with a Proxy-Uri or URI constructed from Proxy-Scheme that indicates a multicast address, the proxy obtains a set of responses as described above and sends all responses (both cached-still-fresh and new) back to the original client. =3D> I don't understand from the document how this works. For instance, will these responses all have the same token? How can a client process this if it expects only one response from the proxy? My general impression is that the multicast mode of CoAP would require a more rigorous specification for being included in a PS document. * Section 9 DTLS is not applicable to group keying (multicast communication); however, it may be a component in a future group key management protocol. =3D> I am not really familiar with DTLS. But communication to multicast addresses by CoAP cannot be secured by DTLS, right? If so, why is there not a big warning sign "DTLS is not available for multicast CoAP"? * Section 11 =3D> This section IMHO lacks the description of two further attacks: (a) The equivalent of a SYN flooding attack on TCP would be sending complex queries with CON to a server. Given that the cost of a CON request is small, this attack can easily be executed. Also, if the server responds with CONs, it will have to allocate buffer and retransmission logic for each request, and it will likely run out of resources. A simple remedy is rate limiting as mentioned in Section 4.7; this counter-measure should be repeated here. (b) A subtle attack with spoofed addresses could possibly exploit the lack of congestion control in CoAP. Due to NSTART=3D1, a tricky attacker could prevent a server to communicate with a legitime client, because only one transaction is allowed to one destination address. The attacker could try to always occupy this "slot". Both attacks are due to the lack of a three-way handshake like in TCP. * Section 11 =3D> This section IMHO needs a discussion on minimum requirements on how to select Message ID and Tokens. Both are a means to protect against "hijacking" of transactions / falsification of responses, but if an attacker can guess these values, an attacker can inject wrong data into a CoAP communication. Compare e.g. to a TCP receiver that carefully checks whether sequence numbers are valid, i.e., within the receive window. Editorial nits: * Section 2.2 CoAP makes use of GET, PUT, POST and DELETE methods in a similar manner to HTTP, with the semantics specified in Section 5.8. (Note that the detailed semantics of CoAP methods are "almost, but not entirely unlike" those of HTTP methods: =3D> s/unlike/like/ ? * Section 3 Following the header, token, and options, if any, comes the optional payload. If present and of non-zero length, it is prefixed by a fixed, one-byte Payload Marker (0xFF) which indicates the end of options and the start of the payload. The payload data extends from after the marker to the end of the UDP datagram, i.e., the Payload Length is calculated from the datagram size. The absence of the Payload Marker denotes a zero-length payload. The presence of a marker followed by a zero-length payload MUST be processed as a message format error. =3D> I think that the term "payload marker" is kind of dangerous; it would be better to use a term like "end-of-option option". When I first read this section, I wondered whether a CoAP implementation could just scan through the packet to find the begin of the payload by the first occence of 0xFF after the default CoAP header. However, this would require 0xFF to be masked in all options. Masking is realized in Section 3.1, but apparently not in Sections 3.2 and Section 5.4. * Section 4.4 The same Message ID MUST NOT be re-used (in communicating with the same endpoint) within the EXCHANGE_LIFETIME (Section 4.8.2). Implementation Note: Several implementation strategies can be employed for generating Message IDs. In the simplest case a CoAP endpoint generates Message IDs by keeping a single Message ID variable, which is changed each time a new Confirmable or Non- confirmable message is sent regardless of the destination address or port. Endpoints dealing with large numbers of transactions could keep multiple Message ID variables, for example per prefix or destination address. The initial variable value should be randomized. =3D> Using a single Message ID variable IMHO is only possible if there is only a single message outstanding to any address, because the Message ID has to be kept for verifying responses. Which implies that even in the "simplest case" there is also one Message ID variable per address. I wonder whether the Implementation Note should be something of the sort "implementations will typically store Message IDs per destination, but they may use a single counter to ensure uniqueness among several destinations". * Section 4.6 header and options are likely to fit within the buffer. A server can thus fully interpret a request and return a 4.13 (Request Entity Too Large) response code if the payload was truncated. A =3D> The syntax "4.13" is not introduced at this stage; it could make sense to add a brief sentence early in the document to explain the response code format * Section 4.8 Message transmission is controlled by the following parameters: =3D> At least DEFAULT_LEISURE is not defined in the text until this table (and it is not really self-explaining). * Section 4.8.2 =3D> The whole section on time values derived from transmission parameters is pretty hard to parse. Instead of organizing it according parameters, it would be better to highlight the subset of parameters that actually matter for an implementation, and what is exactly the event at the beginning and end of that duration. * Section 5.3.1 The Token is used to match a response with a request. The token value is a sequence of 0 to 8 bytes. =3D> While CoAP optimizes its protocol fields for single bits, the document does not comment at all on reasonable sizes for the token. At least some text mentioning the high overhead of a 4 or 8 byte token compared to the rest of the CoAP headers could be useful. Possibly also addressing the security-size tradeoff. * Section 5.10 =3D> I don't understand why the Proxy-URI is longer than others, and why the length is 1034. Finally, please note that I am not subscribed to the core WG mailing list. Thanks Michael