From ietf-secretariat-reply@ietf.org Sun Mar 31 17:58:55 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9CA21F86D6 for ; Sun, 31 Mar 2013 17:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.59 X-Spam-Level: X-Spam-Status: No, score=-101.59 tagged_above=-999 required=5 tests=[AWL=1.010, 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 OL-ad+TbOdcJ; Sun, 31 Mar 2013 17:58:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A45721F867D; Sun, 31 Mar 2013 17:58:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: core-chairs@tools.ietf.org, draft-ietf-core-coap@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130401005855.19799.67381.idtracker@ietfa.amsl.com> Date: Sun, 31 Mar 2013 17:58:55 -0700 From: IETF Secretariat X-Mailman-Approved-At: Mon, 01 Apr 2013 01:05:42 -0700 Subject: [core] ID Tracker State Update Notice: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 01 Apr 2013 00:58:56 -0000 State changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting f= or AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-coap/ From alexey.melnikov@isode.com Thu Apr 4 05:45:05 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EE521F8444; Thu, 4 Apr 2013 05:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 ksTiiSjXNtxD; Thu, 4 Apr 2013 05:45:05 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id BFBCE21F842C; Thu, 4 Apr 2013 05:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1365079503; d=isode.com; s=selector; i=@isode.com; bh=z/ctoknOlJE8lS+pUhS+n4RonClOaWiFkl5OkKWph8o=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=KBi0JKXJV6yk+SahrMHvTNWMa6qLheD9WxowWwhBr24LdSm5GkVWUAYp4r5pLwuKY3+UZJ nA7GDQ5b8dMkVk3pllTBZGReCkLHDYriP3SeC8+griZAGxfa5L6xxjqPFeyGlQNeaoeRM5 tPpel7d3CVT32B+FEDOILmNWOar4+no=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 4 Apr 2013 13:45:03 +0100 Message-ID: <515D75FE.9070008@isode.com> Date: Thu, 04 Apr 2013 13:45:50 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: IETF Apps Discuss , draft-ietf-core-coap.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "HE, XUAN -HCHBJ" , The IESG , core@ietf.org Subject: [core] AppsDir 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: Thu, 04 Apr 2013 12:45:05 -0000 I have been selected as the Applications Area Directorate (appsdir) reviewer for this draft. (For background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-core-coap-14 Title: Constrained Application Protocol (CoAP) Reviewer: Xuan He and Alexey Melnikov Review Date: April 4, 2013 IETF Last Call Date: 27 March 2013 IESG Telechat Date: not known Summary: This draft is nearly ready for publication as an Standards Track RFC. Major Issues: none. Minor: In Section 3, version number field: have you thought about backward compatibility rules for future versions (if any) and version negotiation rules? In Section 4.6: is a SHOULD requirement on IP MTU actually valid in this document? IMHO, you can't redefine what relevant RFCs say about that. In 5.10.8, last para: wouldn't it be more correct to say that preconditions must be tested after all other verification is performed? If not, what is the intent of the MAY? In 6.4: why is URI's default encoding is UTF-8 and not ASCII? URIs can't contain 8bit data. Or did you mean IRIs? (Hopefully you haven't!) In 6.4: 8/9 - it would be correct to say octet instead of "character" when discussing %-decoding. Unicode characters can be represented as multiple octets in UTF-8, each octet would be %-encoded separately. Nits: In 5.4.6: Strange alignment of figure 10. Should it be center aligned? In 7.1: the section title is "Service Discovery", but the section is talking about "server discovery". These are used as synonyms, but this might be confusing to non native English speakers. In 12.2 Page82: There is a table below Table 6 and without any number. From cabo@tzi.org Thu Apr 4 06:58:00 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561C421F8DDD; Thu, 4 Apr 2013 06:58:00 -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 mwy3hFJabD3f; Thu, 4 Apr 2013 06:57:59 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5973321F8BBC; Thu, 4 Apr 2013 06:57:59 -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 r34DvmO9020317; Thu, 4 Apr 2013 15:57:49 +0200 (CEST) Received: from [192.168.217.105] (p54893641.dip.t-dialin.net [84.137.54.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F3C54303D; Thu, 4 Apr 2013 15:57:47 +0200 (CEST) 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: <515D75FE.9070008@isode.com> Date: Thu, 4 Apr 2013 15:57:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8C2FE55F-A4FF-4340-AEBF-C626B42BAA67@tzi.org> References: <515D75FE.9070008@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1503) Cc: "HE, XUAN -HCHBJ" , core@ietf.org, draft-ietf-core-coap.all@tools.ietf.org, IETF Apps Discuss , The IESG Subject: Re: [core] [apps-discuss] AppsDir 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: Thu, 04 Apr 2013 13:58:00 -0000 Hi Alexey, thank you for this review. > In Section 3, version number field: have you thought about backward = compatibility rules for future versions (if any) and version negotiation = rules? I don't think we discussed this in the WG. I remember some hallway discussions the gist of which is approximately: We don't know yet why we would have a version transition, so it is hard = to plan for it. Whatever we define now is likely to be wrong when we actually know what = we need. Anything that is radical enough that we can't express it in an option is = likely to change the message layout enough that it's not even clear what = kind of error response to send back. =20 Sending back something for anything also has its perils. So the version number is mainly in there as an insurance against unknown = unknowns. One other purpose is to allow some multiplexing on the UDP port, = including to avoid STUN codepoints. > In Section 4.6: is a SHOULD requirement on IP MTU actually valid in = this document? IMHO, you can't redefine what relevant RFCs say about = that. There is no SHOULD on the MTU, but a SHOULD on what CoAP implementations = should assume as an MTU. Most of our users think in terms of IPv6, so 1280 is a good assumption. For IPv4, 1280 is also a good base assumption. There is an extensive = implementation note on that, which qualifies this further. The upshot really is that you want to limit the payload size to 1KiB = and, if you use all that, be reasonable about the option size; but for = constrained applications, these numbers are already high. > In 5.10.8, last para: wouldn't it be more correct to say that = preconditions must be tested after all other verification is performed? = If not, what is the intent of the MAY? It gives the server some lenience. It does allow checking for the = preconditions first, and it does allow for checking them last. (We = always try to give the server some lenience to implement things in a way = that is best for the specific constrained node.) In other words, the = client cannot rely on, say, a 4.05 indicating that the preconditions did = match, or on a 4.12 indicating that the method would have been allowed, = but the server is free to check things in either order. > In 6.4: why is URI's default encoding is UTF-8 and not ASCII? URIs = can't contain 8bit data. Or did you mean IRIs? (Hopefully you haven't!) We certainly didn't mean IRIs. Specifying UTF-8 and ASCII should be = equivalent here. (Either way is likely to confuse a different part of the audience.) > In 6.4: 8/9 - it would be correct to say octet instead of "character" = when discussing %-decoding. Unicode characters can be represented as = multiple octets in UTF-8, each octet would be %-encoded separately. We probably just wanted to avoid "octet" because the average age of the = authors is low enough that we can say byte :-) Indeed, each byte is = percent-encoded separately, and decoding each percent-triple generates a = single byte, the sequences of which are then decoded as UTF-8 = characters. We'll try to find better wording for these two items. > Nits: >=20 > In 5.4.6: Strange alignment of figure 10. Should it be center aligned? I don't have a preference either way. Centered now in SVN [1269]. > In 7.1: the section title is "Service Discovery", but the section is = talking about "server discovery". These are used as synonyms, but this = might be confusing to non native English speakers. Well, the usual terminology here *is* confusing. A CoAP server offers a = service. It's not that interesting to discover the server alone, you want to = discover the service on that server. (Actually, the software entity that = offers the service might offer it in the form of multiple endpoints at = different port numbers, which are by definition different servers, even = though we colloquially would rather call it a server with multiple = endpoints.) Let's see if we can untangle the wording a bit here. But I think we want to stick with the heading "Service Discovery". > In 12.2 Page82: There is a table below Table 6 and without any number. Thanks, captioned "CoAP Option Number Registry Policy" now in SVN = [1269]. Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Thu Apr 4 07:06:45 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDA521F93C2 for ; Thu, 4 Apr 2013 07:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeWzzFKEbypt for ; Thu, 4 Apr 2013 07:06:45 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1875721F93AA for ; Thu, 4 Apr 2013 07:06:44 -0700 (PDT) Received: from localhost ([127.0.0.1]:35521 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UNkoN-0007mR-BP; Thu, 04 Apr 2013 16:06:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Thu, 04 Apr 2013 14:06:43 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/282 Message-ID: <051.558fd96867c8d6d9cae2b6e05f651e00@trac.tools.ietf.org> X-Trac-Ticket-ID: 282 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130404140645.1875721F93AA@ietfa.amsl.com> Resent-Date: Thu, 4 Apr 2013 07:06:44 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #282: Clarify bytes/characters and UTF-8/ASCII in "Decomposing URIs into Options" X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 14:06:45 -0000 #282: Clarify bytes/characters and UTF-8/ASCII in "Decomposing URIs into Options" Alexey Melnikov (apps-dir reviewer) notes (msg04193-appsdir-1): Section 6.4 In 6.4: why is URI's default encoding is UTF-8 and not ASCII? URIs can't contain 8bit data. Or did you mean IRIs? (Hopefully you haven't!) Carsten replied: We certainly didn't mean IRIs. Specifying UTF-8 and ASCII should be equivalent here. (Either way is likely to confuse a different part of the audience.) In 6.4: 8/9 - it would be correct to say octet instead of "character" when discussing %-decoding. Unicode characters can be represented as multiple octets in UTF-8, each octet would be %-encoded separately. Carsten replied: Indeed, each byte is percent-encoded separately, and decoding each percent-triple generates a single byte, the sequences of which are then decoded as UTF-8 characters. We'll try to find better wording for these two items. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-14 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Apr 4 07:07: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 4B0AF21F93DA for ; Thu, 4 Apr 2013 07:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1f+HAyy7t7hi for ; Thu, 4 Apr 2013 07:07:25 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A597821F93AA for ; Thu, 4 Apr 2013 07:07:25 -0700 (PDT) Received: from localhost ([127.0.0.1]:35530 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UNkp2-0008US-Ly; Thu, 04 Apr 2013 16:07:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Thu, 04 Apr 2013 14:07:24 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/283 Message-ID: <051.4ccb4c7e9cf7151395cf395b5810c6ec@trac.tools.ietf.org> X-Trac-Ticket-ID: 283 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130404140725.A597821F93AA@ietfa.amsl.com> Resent-Date: Thu, 4 Apr 2013 07:07:25 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #283: Servers vs. Service Discovery X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 14:07:26 -0000 #283: Servers vs. Service Discovery Alexey Melnikov (apps-dir reviewer) notes (msg04193-appsdir-2): Section 7.1 In 7.1: the section title is "Service Discovery", but the section is talking about "server discovery". These are used as synonyms, but this might be confusing to non native English speakers. Carsten replied: Well, the usual terminology here *is* confusing. A CoAP server offers a service. It's not that interesting to discover the server alone, you want to discover the service on that server. (Actually, the software entity that offers the service might offer it in the form of multiple endpoints at different port numbers, which are by definition different servers, even though we colloquially would rather call it a server with multiple endpoints.) Let's see if we can untangle the wording a bit here. But I think we want to stick with the heading "Service Discovery". -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-14 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From cabo@tzi.org Thu Apr 4 07:10:59 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8710821F93EF for ; Thu, 4 Apr 2013 07:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.023 X-Spam-Level: X-Spam-Status: No, score=-106.023 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3tBXr6kaUjr for ; Thu, 4 Apr 2013 07:10:59 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id C585F21F8E7E for ; Thu, 4 Apr 2013 07:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r34EAuIV014372 for ; Thu, 4 Apr 2013 16:10:56 +0200 (CEST) Received: from [192.168.217.105] (p54893641.dip.t-dialin.net [84.137.54.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 048063065; Thu, 4 Apr 2013 16:10:55 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Carsten Bormann In-Reply-To: <1C1F583C-F3D9-44C0-A628-57913220C8FA@tzi.org> Date: Thu, 4 Apr 2013 16:10:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9B113CA5-C754-4826-A9E1-99EB362BD404@tzi.org> References: <1C1F583C-F3D9-44C0-A628-57913220C8FA@tzi.org> To: core WG X-Mailer: Apple Mail (2.1503) Subject: Re: [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, 04 Apr 2013 14:10:59 -0000 So, now that the various directorate reviews are in, the authors will = try to process them in consultation with the reviewers, the chairs and = possibly the various ADs involved. To make sure that this process stays transparent, we will open Tracker = tickets for each non-trivial change. Those are likely to close quickly, = but please to pay close attention to what we are changing... Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Thu Apr 4 07:22: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 80E1921F90AC for ; Thu, 4 Apr 2013 07:22:42 -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.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w00N++j9WI2T for ; Thu, 4 Apr 2013 07:22:42 -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 28BCE21F90A1 for ; Thu, 4 Apr 2013 07:22:40 -0700 (PDT) Received: from localhost ([127.0.0.1]:35966 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UNl3m-0001pK-62; Thu, 04 Apr 2013 16:22:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Thu, 04 Apr 2013 14:22:38 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/284 Message-ID: <051.db1a9938adff5bec98b14c262d132149@trac.tools.ietf.org> X-Trac-Ticket-ID: 284 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130404142241.28BCE21F90A1@ietfa.amsl.com> Resent-Date: Thu, 4 Apr 2013 07:22:40 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #284: Reference terminology from lwig-terminology X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 14:22:44 -0000 #284: Reference terminology from lwig-terminology Dan Romascanu (GEN-ART reviewer) notes: Section 1.2 The terms of 'constrained node' and 'constrained network' are widely used but never defined in this document (but by example in the introduction). I would suggest to include a definition in section 1.2 (Terminology) or a reference if proper definitions can be found some place else. Carsten Bormann replied: A draft is nearing completion in LWIG that is defining these and other terms relevant to this field. We should reference this as an informative reference. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-14 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Apr 4 07:24:21 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879C521F8EBC for ; Thu, 4 Apr 2013 07:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 CveP1lt0FgJD for ; Thu, 4 Apr 2013 07:24:21 -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 E568821F8D10 for ; Thu, 4 Apr 2013 07:24:20 -0700 (PDT) Received: from localhost ([127.0.0.1]:36011 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UNl5P-0003FQ-Tw; Thu, 04 Apr 2013 16:24:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Thu, 04 Apr 2013 14:24:19 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/285 Message-ID: <051.b48c10558fb2c588c917b0d1674a35d8@trac.tools.ietf.org> X-Trac-Ticket-ID: 285 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130404142420.E568821F8D10@ietfa.amsl.com> Resent-Date: Thu, 4 Apr 2013 07:24:20 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #285: Make reference to HTTP terms more explicit X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 14:24:21 -0000 #285: Make reference to HTTP terms more explicit Dan Romascanu (GEN-ART reviewer) notes: Section 1.2 It would be good to define in section 1.2 (Terminology) or provide a reference for the term of 'resource' as this specification used it (again, defined only by example when talking about 'resource discovery') Carsten Bormann replied: Indeed. For this central term, we could simply make more explicit the reference to RFC 2616. (Section 1.2 says: »This specification requires readers to be familiar with all the terms and concepts that are discussed in [RFC2616]. [...]« We could expand this into: »This specification requires readers to be familiar with all the terms and concepts that are discussed in [RFC2616], including "resource", "representation", "cache", and "fresh". [...]« ) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-14 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Apr 4 07:26: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 AFA7721F93ED for ; Thu, 4 Apr 2013 07:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6YsXcBWWj5s for ; Thu, 4 Apr 2013 07:26:36 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFDE21F93DE for ; Thu, 4 Apr 2013 07:26:33 -0700 (PDT) Received: from localhost ([127.0.0.1]:36141 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UNl7Y-0006IV-7f; Thu, 04 Apr 2013 16:26:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Thu, 04 Apr 2013 14:26:32 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/286 Message-ID: <051.0765cc130ff8d113c3d95d4d6a3f2214@trac.tools.ietf.org> X-Trac-Ticket-ID: 286 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130404142633.3FFDE21F93DE@ietfa.amsl.com> Resent-Date: Thu, 4 Apr 2013 07:26:33 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #286: Make reference to ECC/CCM DTLS ciphersuite normative X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 14:26:37 -0000 #286: Make reference to ECC/CCM DTLS ciphersuite normative Alexey Melnikov (sec-dir reviewer) notes: Section 9.1.3.2 9.1.3.2. Raw Public Key Certificates .... »Implementations in RawPublicKey mode MUST support the mandatory to implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in [I-D.mcgrew-tls-aes-ccm-ecc],« It looks like this reference is Normative, while you have it as Informative. Carsten Bormann replied: We will add this as a normative reference in draft-ietf-core-coap-15. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: other | Milestone: post-IESG-1 technical | Version: coap-14 Priority: major | Keywords: Component: coap | Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From cabo@tzi.org Thu Apr 4 07:30: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 27C9F21F9410 for ; Thu, 4 Apr 2013 07:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.991 X-Spam-Level: X-Spam-Status: No, score=-105.991 tagged_above=-999 required=5 tests=[AWL=-0.194, 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 GAdhVTG5ukVH for ; Thu, 4 Apr 2013 07:30: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 626A421F85DC for ; Thu, 4 Apr 2013 07:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r34EUJZD019235 for ; Thu, 4 Apr 2013 16:30:19 +0200 (CEST) Received: from [192.168.217.105] (p54893641.dip.t-dialin.net [84.137.54.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6E74B30A2; Thu, 4 Apr 2013 16:30:19 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Carsten Bormann In-Reply-To: <9B113CA5-C754-4826-A9E1-99EB362BD404@tzi.org> Date: Thu, 4 Apr 2013 16:30:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1C1F583C-F3D9-44C0-A628-57913220C8FA@tzi.org> <9B113CA5-C754-4826-A9E1-99EB362BD404@tzi.org> To: core WG X-Mailer: Apple Mail (2.1503) Subject: Re: [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, 04 Apr 2013 14:30:26 -0000 On Apr 4, 2013, at 16:10, Carsten Bormann wrote: > To make sure that this process stays transparent, we will open Tracker = tickets for each non-trivial change. Those are likely to close quickly, = but please to pay close attention to what we are changing... Sorry. Translation: To make sure that this process stays transparent, we will open Tracker = tickets for each change that is not entirely trivial. Those are likely = to close quickly, but please *do* pay close attention to what we are = changing... Gr=FC=DFe, Carsten From mab@comnets.uni-bremen.de Fri Apr 5 06:20: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 0B54421F9789 for ; Fri, 5 Apr 2013 06:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myDNzNi9EI+8 for ; Fri, 5 Apr 2013 06:20:43 -0700 (PDT) Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [IPv6:2001:638:708:1155::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE12A21F978F for ; Fri, 5 Apr 2013 06:20:42 -0700 (PDT) Received: from shelbyville.comnets.uni-bremen.de (shelbyville [10.10.155.50]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTPS id 35FD9D41093; Fri, 5 Apr 2013 15:20:41 +0200 (CEST) From: Markus Becker Organization: Comnets, University Bremen To: core@ietf.org Date: Fri, 5 Apr 2013 15:20:40 +0200 User-Agent: KMail/1.13.7 (Linux/3.7-trunk-686-pae; KDE/4.9.5; i686; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201304051520.40375.mab@comnets.uni-bremen.de> Cc: teemu.savolainen@nokia.com Subject: [core] CoAP Other Transports: DNS usage X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Apr 2013 13:20:44 -0000 Hi, during the last IETF meeting draft-silverajan-core-coap-alternative-transports was discussed. The document among other things presents alternative ways of integrating different transports into the URI scheme compared to what is done in draft-becker-core-coap-sms-gprs. What I picked up (when listening remotely) was that there were opinions mostly for having the transport identifier in the scheme and some against it, and that it should be checked with the URI people. It was also pointed out that DNS could in some application cases be used. We (@ComNets) have discussed this for the use case we have in mind and came to the conclusion that it might work for us, but not in the general case. Nevertheless, we tried to figure out the way to use DNS for giving out several transport addresses. There are several options that could facilitate handing out different addresses, namely the following DNS resource record types: * TXT (RFC1035,RFC1464) * SRV (RFC2782) * NAPTR (RFC3403) * ISDN (RFC1183) * new DNS resource record type Let's assume the following DNS entries: =========== device1.example.com. IN A 192.0.2.1 device1.example.com. IN AAAA 2001:DB8::1 device2.example.com. IN A 192.0.2.2 device2.example.com. IN AAAA 2001:DB8::2 1.2.0.192.in-addr.arpa. IN PTR device1.example.com. 2.2.0.192.in-addr.arpa. IN PTR device2.example.com. 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.1.0.0.2.ip6.arpa. IN PTR device1.example.com. 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.1.0.0.2.ip6.arpa. IN PTR device2.example.com. # The entries might need to be dynamically updated for dynamic IPs. =========== So what whould the different RR types look like? =========== ; ISDN records: device1.example.com. IN ISDN 150862028003217 device2.example.com. IN ISDN 150862028003218 # Looks OK for SMS. Other transports would not fit in here. =========== ; SRV records: ; _service._proto.name TTL class SRV priority weight port target _coap._udp.device1.example.com. 86400 IN SRV 0 5 5683 device1.example.com. _coap._udp.device2.example.com. 86400 IN SRV 0 9 5683 device2.example.com. _coap._tel.device1.example.com. 86400 IN SRV 0 5 5683 device1.example.com. _coap._tel.device2.example.com. 86400 IN SRV 0 9 5683 device2.example.com. # How should SRV be used for SMS? service _tel allowed/registered? # Note: port does not make sense for _tel. =========== ; SRV + ISDN records: device1.tel.example.com. IN ISDN 150862028003217 _coap._tel.device1.example.com. 86400 IN SRV 0 5 5683 device1.tel.example.com. =========== ; NAPTR records: ; order pref flags service regexp $ORIGIN 4.3.2.1.5.5.5.0.0.8.1.e164.arpa. IN NAPTR 100 10 "U" "E2U+coap" "!^.*$!coap://device1.example.com!" . IN NAPTR 102 10 "U" "E2U+coap+tel" "!^.*$!tel:+18005551234!" . # NAPTR RR only solves E.164 to IP/URI. How could this be extended to other transports? # which service should be used for NAPTR? # "E2U+coap" # "E2U+coap+udp" # "E2U+coap+tel" # "E2U+coap+sms" # "E2U+coap+sms+tel" # "E2U+web+coap" # "E2U+sms+tel" reuse E2U+sms from RFC4355 =========== ; TXT records: possibly in RFC6763 DNS-SD format? device1.example.com IN TXT "\0x0dtransport=sms\0x10sms=+18005551234" =========== ; new DNS resource record type? =========== We would be interested in hearing what others think about the usage of DNS for storing other transports addresses and of the resource type usage laid out above. Markus P.S.: For your convenience here are the relevant RFC numbers. RFC1035: DOMAIN NAMES (TXT RR) RFC1464: Using the Domain Name System To Store Arbitrary String Attributes (TXT RR)TXT RFC1183: New DNS RR Definitions (ISDN RR) RFC2782: A DNS RR for specifying the location of services (DNS SRV RR) RFC3401 ff: Dynamic Delegation Discovery System (NAPTR RR: RFC 3403) RFC6118: Update of Legacy IANA Registrations of Enumservices RFC3966: The tel URI for Telephone Numbers RFC4355: IANA Registration for Enumservices email, fax, mms, ems, and sms RFC2916: E.164 number and DNS (Service E2U) RFC3761 obsoletes RFC2916: The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) ------------------------------------------------ | Dipl.-Ing. Markus Becker | Communication Networks | TZI - Center for Computing Technologies | University Bremen | Germany ------------------------------------------------ | web: http://www.comnets.uni-bremen.de/~mab/ | mailto: mab@comnets.uni-bremen.de | telephone: +49 421 218 62379 | building: NW1 room: N2260 ------------------------------------------------ From trac+core@trac.tools.ietf.org Sun Apr 7 05:13:58 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582AF21F84A9 for ; Sun, 7 Apr 2013 05:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 d9k+9cLkXsB5 for ; Sun, 7 Apr 2013 05:13: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 47C7F21F849C for ; Sun, 7 Apr 2013 05:13:56 -0700 (PDT) Received: from localhost ([127.0.0.1]:60421 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UOoTq-0000Ie-4O; Sun, 07 Apr 2013 14:13:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Sun, 07 Apr 2013 12:13:54 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/287 Message-ID: <051.852767a49b85928dce42c7e61234c7f2@trac.tools.ietf.org> X-Trac-Ticket-ID: 287 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130407121357.47C7F21F849C@ietfa.amsl.com> Resent-Date: Sun, 7 Apr 2013 05:13:56 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #287: Add a quick warning that bytewise scanning for a payload marker is not a good idea X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 12:13:58 -0000 #287: Add a quick warning that bytewise scanning for a payload marker is not a good idea Michael Scharf (tsv-dir reviewer) notes (msg04191-tsvdir-7): Section 3 * 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.« => 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. Carsten Bormann plans to reply: The payload marker is not by itself an option. Also, it is only present if there is payload. Instead of changing the name, maybe we should add a note that byte-wise scanning for 0xFF is not a viable technique for finding the payload. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-14 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun Apr 7 05:16:11 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A0721F8D90 for ; Sun, 7 Apr 2013 05:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 dSYXL-Ry8uZ0 for ; Sun, 7 Apr 2013 05:16:11 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id C35D721F84A9 for ; Sun, 7 Apr 2013 05:16:10 -0700 (PDT) Received: from localhost ([127.0.0.1]:60486 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UOoW1-0008U4-LQ; Sun, 07 Apr 2013 14:16:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Sun, 07 Apr 2013 12:16:09 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/288 Message-ID: <051.2be51c5e623e108fe30fca1a40cf1d2a@trac.tools.ietf.org> X-Trac-Ticket-ID: 288 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130407121610.C35D721F84A9@ietfa.amsl.com> Resent-Date: Sun, 7 Apr 2013 05:16:10 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #288: Make reference to PROBING_RATE explicit X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 12:16:11 -0000 #288: Make reference to PROBING_RATE explicit Michael Scharf (tsv-dir reviewer) notes (msg04191-tsvdir-1): Section 4.3 * 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.« => 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. Carsten Bormann plans to reply: Indeed, a reference to 4.7 wouldn't hurt here. (Sending multiple copies that are spaced more than MAX_TRANSMIT_SPAN may defeat the duplicate detection. Messages that benefit from saturation are often short discovery requests, so extremely very low value we chose for PROBING_RATE may not hurt in practice.) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-14 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun Apr 7 05:20:37 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E779121F8DD6 for ; Sun, 7 Apr 2013 05:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiQcpAdA+gWE for ; Sun, 7 Apr 2013 05:20:36 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 37E6421F8867 for ; Sun, 7 Apr 2013 05:20:36 -0700 (PDT) Received: from localhost ([127.0.0.1]:60589 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UOoaJ-0006PH-2P; Sun, 07 Apr 2013 14:20:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Sun, 07 Apr 2013 12:20:35 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/289 Message-ID: <051.f948e6154bd02325eb29fb216d93af27@trac.tools.ietf.org> X-Trac-Ticket-ID: 289 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130407122036.37E6421F8867@ietfa.amsl.com> Resent-Date: Sun, 7 Apr 2013 05:20:36 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #289: Add a forward reference to 5.9.2.9. X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 12:20:37 -0000 #289: Add a forward reference to 5.9.2.9. Michael Scharf (tsv-dir reviewer) notes (msg04191-tsvdir-8): Section 4.6 * 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.« => 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 Carsten Bormann plans to reply: Or just a forward reference to 5.9.2.9. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-14 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun Apr 7 05:22:17 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD1321F8EC6 for ; Sun, 7 Apr 2013 05:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPJq2OM1sf+r for ; Sun, 7 Apr 2013 05:22:16 -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 5B68D21F8EC3 for ; Sun, 7 Apr 2013 05:22:16 -0700 (PDT) Received: from localhost ([127.0.0.1]:60617 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UOobv-0008Vj-9q; Sun, 07 Apr 2013 14:22:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Sun, 07 Apr 2013 12:22:15 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/290 Message-ID: <051.8630ff7f1a6070b30bbc5a9fa3f5c762@trac.tools.ietf.org> X-Trac-Ticket-ID: 290 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130407122216.5B68D21F8EC3@ietfa.amsl.com> Resent-Date: Sun, 7 Apr 2013 05:22:16 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #290: Mention PROCESSING_DELAY when discussion piggy-backing X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 12:22:17 -0000 #290: Mention PROCESSING_DELAY when discussion piggy-backing Michael Scharf (tsv-dir reviewer) notes (msg04191-tsvdir-2): Section 5.2.1 * 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.« => 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. Carsten Bormann plans to reply: The worst-case analysis is about as robust as that for TCP 2MSL. There is absolutely no assurance in IP that data won't be in the network longer than MSL (and I sure have measured latencies way higher). The analysis describes what we try to guard against, not the absolute worst case. But I agree that the discussion of when to piggy-back (5.2.1) could include a mention of PROCESSING_DELAY. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-14 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun Apr 7 05: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 466EE21F8EE1 for ; Sun, 7 Apr 2013 05:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Szye1eF4wHeJ for ; Sun, 7 Apr 2013 05:24:23 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 54F0821F8ED8 for ; Sun, 7 Apr 2013 05:24:22 -0700 (PDT) Received: from localhost ([127.0.0.1]:60647 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UOodx-0008KA-1g; Sun, 07 Apr 2013 14:24:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Sun, 07 Apr 2013 12:24:21 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/291 Message-ID: <051.27446f5e2a73746d614b61ea97a6956a@trac.tools.ietf.org> X-Trac-Ticket-ID: 291 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130407122422.54F0821F8ED8@ietfa.amsl.com> Resent-Date: Sun, 7 Apr 2013 05:24:22 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #291: 8 kbit/s is not "conservative" X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 12:24:24 -0000 #291: 8 kbit/s is not "conservative" Michael Scharf (tsv-dir reviewer) notes (msg04191-tsvdir-3): Section 8.2 * 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 = 1 kB/s. The resulting lower bound for the Leisure is 10 seconds.« => 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 = 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. Carsten Bormann plans to reply: Indeed. We should strike "conservative". -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-14 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun Apr 7 05:26:58 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9859921F8EFD for ; Sun, 7 Apr 2013 05:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5t5RKKA7pF12 for ; Sun, 7 Apr 2013 05:26:58 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 003ED21F8D40 for ; Sun, 7 Apr 2013 05:26:57 -0700 (PDT) Received: from localhost ([127.0.0.1]:60719 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UOogS-0006E0-Ot; Sun, 07 Apr 2013 14:26:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Sun, 07 Apr 2013 12:26:56 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/292 Message-ID: <051.7035f63909d2440b2c6af2888f76f7b2@trac.tools.ietf.org> X-Trac-Ticket-ID: 292 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130407122658.003ED21F8D40@ietfa.amsl.com> Resent-Date: Sun, 7 Apr 2013 05:26:57 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #292: Add description of resource depletion attack X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 12:26:58 -0000 #292: Add description of resource depletion attack Michael Scharf (tsv-dir reviewer) notes (msg04191-tsvdir-4): Section 11 * Section 11 => 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. Carsten Bormann plans to reply: Yes. (There is a whole set of battery depletion attacks that are hard to guard against without some form of network segregation.) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: other | Milestone: post-IESG-1 technical | Version: coap-14 Priority: minor | Keywords: Component: coap | Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun Apr 7 05:30:58 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B2A21F8DD1 for ; Sun, 7 Apr 2013 05:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iv7ZnXjrxm2T for ; Sun, 7 Apr 2013 05:30:58 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B6F3421F8DB2 for ; Sun, 7 Apr 2013 05:30:57 -0700 (PDT) Received: from localhost ([127.0.0.1]:60814 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UOokJ-0006Wa-CG; Sun, 07 Apr 2013 14:30:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Sun, 07 Apr 2013 12:30:55 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/293 Message-ID: <051.8015ecb64e1448e0da80b116b104e0a0@trac.tools.ietf.org> X-Trac-Ticket-ID: 293 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130407123057.B6F3421F8DB2@ietfa.amsl.com> Resent-Date: Sun, 7 Apr 2013 05:30:57 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #293: Add description of DoS attack on congestion control X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 12:30:58 -0000 #293: Add description of DoS attack on congestion control Michael Scharf (tsv-dir reviewer) notes (msg04191-tsvdir-5): Section 11 (b) A subtle attack with spoofed addresses could possibly exploit the lack of congestion control in CoAP. Due to NSTART=1, 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". -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: other | Milestone: post-IESG-1 technical | Version: coap-14 Priority: minor | Keywords: Component: coap | Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun Apr 7 05: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 9654D21F8E2C for ; Sun, 7 Apr 2013 05:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 fYzHEpQBdp0A for ; Sun, 7 Apr 2013 05:34:14 -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 E1CDC21F8DD1 for ; Sun, 7 Apr 2013 05:34:13 -0700 (PDT) Received: from localhost ([127.0.0.1]:60831 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UOonU-00034f-RC; Sun, 07 Apr 2013 14:34:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Sun, 07 Apr 2013 12:34:12 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/294 Message-ID: <051.07b994a18d06121dc7a48fa336ed1618@trac.tools.ietf.org> X-Trac-Ticket-ID: 294 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130407123413.E1CDC21F8DD1@ietfa.amsl.com> Resent-Date: Sun, 7 Apr 2013 05:34:13 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #294: Add discussion of using non-trivial token for protecting against hijacking X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 12:34:14 -0000 #294: Add discussion of using non-trivial token for protecting against hijacking Michael Scharf (tsv-dir reviewer) notes (msg04191-tsvdir-6): Section 11 * Section 11 => 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. * 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.« => 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. Carsten Bormann plans to reply: The Token length was chosen to be as big as it is to enable this kind of protection, if desired. More likely, we will simply use DTLS security where that matters. But a short discussion of this could be added. Note that there is a recommendation that message-IDs are allocated sequentially in draft-ietf-lwig-guidance; for a constrained system, this may be the only way to keep enough message state for reliable duplicate removal. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: other | Milestone: post-IESG-1 technical | Version: coap-14 Priority: minor | Keywords: Component: coap | Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From cabo@tzi.org Sun Apr 7 06:03: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 3048221F8CD8; Sun, 7 Apr 2013 06:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.448 X-Spam-Level: X-Spam-Status: No, score=-105.448 tagged_above=-999 required=5 tests=[AWL=-0.688, BAYES_05=-1.11, 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 I2uYw9M+YAVQ; Sun, 7 Apr 2013 06:03:26 -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 EA71E21F8C45; Sun, 7 Apr 2013 06:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r37D3BaS023269; Sun, 7 Apr 2013 15:03:11 +0200 (CEST) Received: from [192.168.217.105] (p54894EAC.dip.t-dialin.net [84.137.78.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 547D13B2B; Sun, 7 Apr 2013 15:03:10 +0200 (CEST) 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: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6F16@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Date: Sun, 7 Apr 2013 15:03:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2A886F9088894347A3BE0CC5B7A85F3E9AB12A6F16@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> To: "Scharf, Michael (Michael)" X-Mailer: Apple Mail (2.1503) Cc: "core-chairs@tools.ietf.org" , "ietf@ietf.org" , "tsv-ads@tools.ietf.org" , The IESG , "core@ietf.org" , "tsv-dir@ietf.org" , "draft-ietf-core-coap@tools.ietf.org" Subject: Re: [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, 07 Apr 2013 13:03:29 -0000 Michael, thank you for this thoughtful and extensive review. We have turned nine of the items below into eight tickets, #287 to #294 (see in-line references below), that will be processed along with the other IETF last-call tickets and turned into draft-ietf-core-coap-15 in the next few days. Below, please find a detailed discussion of the review comments. Gr=FC=DFe, Carsten 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. Thank you, that is good to know. Review - not so good news: * General: In a nutshell, this document proposes a rather = lightwight protocol that provides a subset of TCP/HTTP transport. The authors don't agree with this view at all. CoAP is a application layer transfer protocol. It provides very few transport features. It is not very productive to compare it to TCP. It can be used for certain applications that could theoretically also be supported by HTTP over TCP, if the complexity of these protocols didn't get in the way. We sense very little danger that Web developers will run out and abandon HTTP and TCP in droves when CoAP is published. 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). Disagree. That is not the job of a protocol specification. RFC 2616 does not have a disclaimer that explains how it is inferior to FTP, even though both can be used for related applications and FTP clearly has a number of desirable features that HTTP lacks (some of which were later defined in additional protocols on top of HTTP, e.g., WebDAV, and some that apparently weren't actually needed by HTTP users). Creating such a section would already fail at the definition of the protocol stack against which CoAP is to be compared to, as a "light-weight HTTP/TCP implementation with HTTP compression" is neither standardized nor even possible within the confines of the constrained nodes addressed by CoAP. Once written, such a section would almost immediately be dated as implementers find new ways to solve old problems, and as additional specifications are written (cf. WebDAV above). * 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. As is apparent from interops, this was less of a problem for implementers so far. We have drafts that discuss implementation approaches in LWIG, and these will be developed further. I'm not a big fan of an FDT requirement for an initial protocol specification, this was part of what killed OSI. =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. I don't understand the concern. This is a comment on a common implementation optimization. There are multiple ways to counter an attack, the preferable one of which is to use DTLS security. * 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. Indeed, a reference to 4.7 wouldn't hurt here. [#288] (Sending multiple copies that are spaced more than MAX_TRANSMIT_SPAN may defeat the duplicate detection. Messages that benefit from saturation are often short discovery requests, so extremely very low value we chose for PROBING_RATE may not hurt in practice.) `* 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? It is the purview of the server how it implements its resources. The server can unilaterally decide that its resources don't need this processing. There is no interoperability concern with this. The keyword is "if the application semantics make this trade-off favorable". This kind of latitude may be unusual for a protocol specification, but it is often what makes a constrained implementation possible. * 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? Yes. 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. That is an implementation concern. TCP's solution to this kind of situations is flow control by = the receive window. Actually, TCP's solution is dropping the SYN. 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. There is no way to define the CoAP protocol such that it prevents implementers from painting themselves into a corner. Again, I would expect much of this discussion to turn up in future LWIG documents. Work is being done one some of these issues in draft-ietf-lwig-guidance, draft-kovatsch-lwig-class1-coap, and the (currently expired) draft-castellani-lwig-coap-separate-responses. In Orlando, there was considerable energy between the authors of these documents to get more documentation done; a first authors' draft is already in the LWIG SVN and is actively being worked on. * 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.). That specific discussion would be part of the -observe extension. The base protocol is stuck at PROBING_RATE. * 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. The worst-case analysis is about as robust as that for TCP 2MSL. There is absolutely no assurance in IP that data won't be in the network longer than MSL (and I sure have measured latencies way higher). The analysis describes what we try to guard against, not the absolute worst case. But I agree that the discussion of when to piggy-back (5.2.1) could include a mention of PROCESSING_DELAY. [#290] * 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. Concurrent requests are allowed as long as there has been a return message. E.g., a client could send a CON GET, get an empty ACK (resetting the outstanding count to zero), and then decide to do another CON GET (and receive another empty ACK) before the response CON for the first request arrives. Which request does the response reply to? * 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. There is some discussion of rejecting messages in 4.2. There is relatively little need for details here as there is no connection state to maintain or fix up once a message has been rejected. =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? Yes. This is one of the things that -observe might be doing. (Note that a message can have more than one response.) * 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. We try to minimize those minimum requirements. The specific optimization described here has the unfortunate property that a client may seem like it just has been rebooted. We cannot disallow rebooting in the protocol. * 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? There is a SHOULD about messages sizes in 4.6. * 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. As the text you cite says, multicast requests are governed by NON rules. It is indeed easy to congest a constrained node network using multicast (if that is implemented at all, usually by flooding a broadcast message). Multicast application protocol specifications for more powerful networks, such as RFC 6762 (which does not contain the word "congestion" and only alludes to "rate-limiting"), have not even tried to codify the limits of reasonableness here: it is nearly impossible to give limits that aren't both ridiculously high for some environments and too conservative for others. Multicast congestion control for wireless constrained node networks is significantly less well understood because of the dynamics of the flooding protocols used; it also has to contend with memory limits in the router nodes. In summary, CoAP implementers are likely to be extremely careful about using multicast. And that is about the level of advice we could give them: "Be very, very careful about using multicast". * 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? There is no flow control implication of RST, so I'm not quite sure I understand the scenario. Sending back an RST to a multicast is not going to help an overloaded server (there are no retransmissions to be curbed). (The specific case discussed in the rest of that paragraph is that of a server stuck with pre-3542 posix, so it is unaware that it just received a multicast. This is an ugly situation, and there is not really that much that can be done to clean it up.) * 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? The text is about response matching, not about removing duplicates. Duplicate removal will be done based on message-IDs. That state (if duplicate removal is desired) indeed needs to live on. * 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? 5.2.3 says a NON SHOULD be answered by a NON. Now: "if the server wants that its message is indeed delivered reliably" -- why? there was no guarantee the requesting NON would have reached it in the first place, so why is delivering the response now so important? But if it indeed is, that might be a good reason to send a CON. The ACK traffic will indeed confound the network load. So, as with any SHOULD, there should be a strong reason to depart from 5.2.3. * 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. Indeed. We should strike "conservative". [#291] * 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. That is indeed a problem, but it strikes me as more of of a quality of implementation problem. (I don't understand the last sentence, though. How does a time limit exceed a rate?) * 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? Yes. How can a client process this if it expects only one response from the = proxy? Indeed, there is a problem if the authority contains indirection (e.g., is a DNS name), and maps to a multicast address unbeknownst of the client. My general impression is that the multicast mode of CoAP would require a more rigorous specification for being included in a = PS document. There is continuing discussion of this in draft-ietf-core-groupcomm. The fundamental mechanism works well for the problem we are trying to solve using multicast (local service discovery), but, as the text says, e.g., multicasting through a proxy may need additional mechanisms. * 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"? This sentence is the warning sign. In today's usage of CoAP, multicast is mainly used for discovery, and that often takes place as a prerequisite to establishing security. So there is no practical problem today. But we want to be able to secure multicast CoAP, so we are working on multicast extensions to DTLS. These will take some time. * 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. Yes. [#292] (There is a whole set of battery depletion attacks that are hard to guard against without some form of network segregation.) (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". Good point. [#293] Both attacks are due to the lack of a three-way handshake = like in TCP. Yes. This is a design feature, and we are fully aware of its cost. (The real answer, of course, is global deployment of BCP38. But I won't open that can of worms.) * 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. The Token length was chosen to be as big as it is to enable this kind of protection, if desired. More likely, we will simply use DTLS security where that matters. But a short discussion of this could be added. [#294] Note that there is a recommendation that message-IDs are allocated sequentially in draft-ietf-lwig-guidance; for a constrained system, this may be the only way to keep enough message state for reliable duplicate removal. 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/ ? Ah, sorry, that is an inside joke for Douglas Adams fans. Reference added (SVN [1272]). * 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. The payload marker is not by itself an option. Also, it is only present if there is payload. Instead of changing the name, maybe we should add a note that byte-wise scanning for 0xFF is not a viable technique for finding the payload. [#287] * 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". The state per outstanding request is separate from this. Simple implementations will have one counter and one (or a very small number of) outstanding request, so they will indeed not keep per-destinations state. * 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 Or just a forward reference to 5.9.2.9. [#289] * 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). This is one of the places where I would expect curious readers to make use of the search function of their display device... * 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. I'd rather write an LWIG document with lots of more details about these parameters than trying to shoe-horn all this information in here. The specification is already heavy on implementation information. * 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. Yes, see [_] above. * Section 5.10 =3D> I don't understand why the Proxy-URI is longer than = others, and why the length is 1034. The reason this is much larger than the other options is that it might be used for interfacing to HTTP, which tends to use much larger URIs = than we normally create in the CoAP world (say, for OAuth). (The specific value of 1034 is a remnant of an earlier option encoding, 1023 would do, too, but we never made that change.) From stokcons@xs4all.nl Tue Apr 9 01:45:59 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D286F21F9132 for ; Tue, 9 Apr 2013 01:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.933 X-Spam-Level: X-Spam-Status: No, score=0.933 tagged_above=-999 required=5 tests=[AWL=1.437, BAYES_00=-2.599, 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 MSx+TUPyBUJR for ; Tue, 9 Apr 2013 01:45:59 -0700 (PDT) Received: from smtp-vbr15.xs4all.nl (smtp-vbr15.xs4all.nl [194.109.24.35]) by ietfa.amsl.com (Postfix) with ESMTP id F028221F904B for ; Tue, 9 Apr 2013 01:45:58 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube8.xs4all.net [194.109.20.206]) by smtp-vbr15.xs4all.nl (8.13.8/8.13.8) with ESMTP id r398juEX014750 for ; Tue, 9 Apr 2013 10:45:57 +0200 (CEST) (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); Tue, 09 Apr 2013 10:45:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 09 Apr 2013 10:45:56 +0200 From: peter van der Stok To: Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: <0C9867A6-AED5-4063-88AE-E9D1C6CDE75E@tzi.org> References: <0C9867A6-AED5-4063-88AE-E9D1C6CDE75E@tzi.org> Message-ID: X-Sender: stokcons@xs4all.nl (wKuVURmYuJO7m2cgo422vis9S1qK6Hra) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner 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 Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 08:45:59 -0000 Dear wg, Review of draft-castellani-core-http-mapping, including coap-14 section 10. For me text and objective have become clearer compared to earlier versions. The objective of the document to describe proxies such that proxies from different manufacturers can be exchanged is a valid motivation for the document. My first concern is the uri naming convention and proxy definition. Concerning proxy definition: I am happy with the explanation of forward, cross and reverse proxy, it clarifies the bit opaque text of coap-14. However, it does not help me much because the cullen example of I-D.bormann-core-cross-reverse-convention is presented as reverse proxy example while the text in castellani made me think it is a forward proxy example, because the client seems to be aware that translation takes place. There still seems to be a gap in my understanding from purely reading the texts. Concerning naming convention: The document does not help much in restricting the URI naming conventions. I would expect one of two things: 1) Strict guidelines how to translate uris (restrict the number of possibilities) 2) Provide means to define the uri translation on the proxy. I do not see any other way of making sure that proxies of different manufacturers can be exchanged. My second concern is that the document only treats http-coap translation. The case coap-http seems more urgent. We do not want to provide the small devices with a http/tcp code next to the coap/udp code, while these devices will need to talk to “legacy” http back-end servers. Suggestion: add the coap-http part. Individual nits and suggestions. Page 6, section 5, all 2, line 5…….explicitly indicates THAT it targets …… (that forgotten?) Section 5, all 3, unicast http to multicast coap is a completely different document (remove the currently in the “currently out of scope”. Wouldn’t you discourage the unicast to multicast aspect in a standardized proxy? Section 5.1 caching: add “given” to …. all request traffic to a given COAP server……. Sec 5.1 Multicast; possibly the wrong reason for a valid efficiency argument: to connect a proxy interface to the mesh network. Sec 5.1 TCP/UDP: I do not see the placement aspect here Sec 5.2 Notes. Do you not need to give formulas? For example in note 8, the determination of max-age value Sec 5.4 how to configure the limit and queuing/dropping behavior? The document should specify an interface. Sec 5.5 and 5.6 I like the effort to specify limits of behaviors. Sec 7. I understand that a proxy represents the typical “man in the middle” threat. Having it securely connected to the network before any access and a regular reconnection may have a positive effect. hope this helps, peter Carsten Bormann schreef op 2013-03-24 23:33: > 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 esko.dijk@philips.com Tue Apr 9 03:12: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 1390D21F937D for ; Tue, 9 Apr 2013 03:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 O45vlM+pE0UX for ; Tue, 9 Apr 2013 03:12:21 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD0221F937B for ; Tue, 9 Apr 2013 03:12:21 -0700 (PDT) Received: from mail103-tx2-R.bigfish.com (10.9.14.228) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Tue, 9 Apr 2013 10:12:20 +0000 Received: from mail103-tx2 (localhost [127.0.0.1]) by mail103-tx2-R.bigfish.com (Postfix) with ESMTP id A9A713002E3 for ; Tue, 9 Apr 2013 10:12:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -10 X-BigFish: VPS-10(zz15d6O9251Jc85fh217bIzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz18c673hz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1155h) Received: from mail103-tx2 (localhost.localdomain [127.0.0.1]) by mail103-tx2 (MessageSwitch) id 1365502338849747_20203; Tue, 9 Apr 2013 10:12:18 +0000 (UTC) Received: from TX2EHSMHS015.bigfish.com (unknown [10.9.14.244]) by mail103-tx2.bigfish.com (Postfix) with ESMTP id CA17A2E0164 for ; Tue, 9 Apr 2013 10:12:18 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS015.bigfish.com (10.9.99.115) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 9 Apr 2013 10:12:17 +0000 Received: from 011-DB3MMR1-013.MGDPHG.emi.philips.com (10.128.28.97) by 011-DB3MMR1-006.MGDPHG.emi.philips.com (10.128.28.56) with Microsoft SMTP Server (TLS) id 14.2.328.11; Tue, 9 Apr 2013 10:12:15 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.99]) by 011-DB3MMR1-013.MGDPHG.emi.philips.com ([10.128.28.97]) with mapi id 14.02.0328.011; Tue, 9 Apr 2013 10:12:15 +0000 From: "Dijk, Esko" To: "core (core@ietf.org)" Thread-Topic: Informative refs in core-coap: groupcomm / http-mapping ? Thread-Index: Ac41ClTg+6BWDiH9Qu6C/Zf1AJDdpQ== Date: Tue, 9 Apr 2013 10:12:14 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618BFE2BA@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_031DD135F9160444ABBE3B0C36CED618BFE2BA011DB3MPN2082MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] Informative refs in core-coap: groupcomm / 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, 09 Apr 2013 10:12:23 -0000 --_000_031DD135F9160444ABBE3B0C36CED618BFE2BA011DB3MPN2082MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I was just looking at the informative references section of core-coap. Idea= s for improving these references: 1) We could replace reference to [I-D.bormann-core-cross-reverse-convention] = with [draft-castellani-core-http-mapping], where we plan to add a default U= RI convention for a reverse proxy in the next version, similar to the curre= nt content of [I-D.bormann-core-cross-reverse-convention]. 2) We could add a reference to [draft-ietf-core-groupcomm] to point to additio= nal guiding text on these two aspects: * Multicast Request Acceptance and Response Suppression (section 3.= 6). This provides details to the core-coap rule that a "server MAY always p= retend it did not receive the request" * A new section will be added for the next groupcomm version about = Proxying of multicast requests; related to core-coap section 8.2.2. It expl= ains in more detail the problems when doing this and a solution as well. Would this be useful to have in core-coap - any opinions? regards, Esko Dijk ________________________________ 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_031DD135F9160444ABBE3B0C36CED618BFE2BA011DB3MPN2082MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

I was just looking at the informative references sec= tion of core-coap. Ideas for improving these references:

 

1)

We could replace reference to  [I-D.bormann-cor= e-cross-reverse-convention] with [draft-castellani-core-http-mapping], wher= e we plan to add a default URI convention for a reverse proxy in the next v= ersion, similar to the current content of [I-D.bormann-core-cross-reverse-convention].

 

2)

We could add a reference to [draft-ietf-core-groupco= mm] to point to additional guiding text on these two aspects:

·         Multicast Request Acceptance and Response Suppression = (section 3.6). This provides details to the core-coap rule that a “se= rver MAY always pretend it did not receive the request”

·         A new section will be added for the next groupcomm ver= sion about Proxying of multicast requests; related to core-coap section 8.2= .2. It explains in more detail the problems when doing this and a solution = as well.

 

Would this be useful to have in core-coap – an= y opinions?

 

regards,

 

Esko Dijk


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_031DD135F9160444ABBE3B0C36CED618BFE2BA011DB3MPN2082MGDP_-- From cabo@tzi.org Tue Apr 9 03:39:18 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44E021F89D3 for ; Tue, 9 Apr 2013 03:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.14 X-Spam-Level: X-Spam-Status: No, score=-106.14 tagged_above=-999 required=5 tests=[AWL=0.109, 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 adjzsMRfqj2b for ; Tue, 9 Apr 2013 03:39:17 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF0E21F8546 for ; Tue, 9 Apr 2013 03:39:08 -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 r39Ad6Fu026670; Tue, 9 Apr 2013 12:39:06 +0200 (CEST) Received: from [192.168.217.105] (p54891CAB.dip.t-dialin.net [84.137.28.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E038D3829; Tue, 9 Apr 2013 12:39:05 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED618BFE2BA@011-DB3MPN2-082.MGDPHG.emi.philips.com> Date: Tue, 9 Apr 2013 12:39:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9957A4C5-1B36-49D2-AADD-35481C1F7894@tzi.org> References: <031DD135F9160444ABBE3B0C36CED618BFE2BA@011-DB3MPN2-082.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1503) Cc: "core \(core@ietf.org\)" Subject: Re: [core] Informative refs in core-coap: groupcomm / 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, 09 Apr 2013 10:39:19 -0000 On Apr 9, 2013, at 12:12, "Dijk, Esko" wrote: > Dear all, > =20 > I was just looking at the informative references section of core-coap. = Ideas for improving these references: > =20 > 1) > We could replace reference to = [I-D.bormann-core-cross-reverse-convention] with = [draft-castellani-core-http-mapping], where we plan to add a default URI = convention for a reverse proxy in the next version, similar to the = current content of [I-D.bormann-core-cross-reverse-convention]. Oh. This is so obvious that I just made that change in the SVN right = away [1275]. (This hasn't been done before because I was expecting a future version = of http-mapping to have a "replaces" relationship to the = cross-reverse-convention draft -- that hasn't happened yet, but it is = sure the intention, and we should make this intention visible now.) > 2) > We could add a reference to [draft-ietf-core-groupcomm] to point to = additional guiding text on these two aspects: > =B7 Multicast Request Acceptance and Response Suppression = (section 3.6). This provides details to the core-coap rule that a = =93server MAY always pretend it did not receive the request=94 > =B7 A new section will be added for the next groupcomm version = about Proxying of multicast requests; related to core-coap section = 8.2.2. It explains in more detail the problems when doing this and a = solution as well. I would think that referencing groupcomm is a good idea. I'm not quite = sure where and how, so let's discuss this: I'd probably add a sentence of the form=20 A more general discussion of group communication with CoAP is in = [I-D.ietf-core-groupcomm]. at the end of the first paragraph of section 8. I'd also insert a reference to groupcomm before the reference to = coap-misc in 8.2.2, like this: Proxying multicast requests is discussed in more detail in = [I-D.ietf-core-groupcomm]; a proposal to address the base URI issue can be found in section 3 of [I-D.bormann-coap-misc]. Gr=FC=DFe, Carsten From esko.dijk@philips.com Tue Apr 9 04:00: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 BABD621F8FD6 for ; Tue, 9 Apr 2013 04:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.169 X-Spam-Level: X-Spam-Status: No, score=-4.169 tagged_above=-999 required=5 tests=[AWL=-0.570, 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 CDwPUN4d+CaW for ; Tue, 9 Apr 2013 04:00:43 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 78F0021F8FD4 for ; Tue, 9 Apr 2013 04:00:43 -0700 (PDT) Received: from mail208-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Tue, 9 Apr 2013 11:00:42 +0000 Received: from mail208-va3 (localhost [127.0.0.1]) by mail208-va3-R.bigfish.com (Postfix) with ESMTP id C59AD7208EB; Tue, 9 Apr 2013 11:00:42 +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(zz98dI15d6O9251Jc89bh542I1432Idb82h217bIzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL8275bhz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail208-va3 (localhost.localdomain [127.0.0.1]) by mail208-va3 (MessageSwitch) id 13655052414781_10224; Tue, 9 Apr 2013 11:00:41 +0000 (UTC) Received: from VA3EHSMHS037.bigfish.com (unknown [10.7.14.252]) by mail208-va3.bigfish.com (Postfix) with ESMTP id F20DDD40069; Tue, 9 Apr 2013 11:00:40 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS037.bigfish.com (10.7.99.47) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 9 Apr 2013 11:00:41 +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; Tue, 9 Apr 2013 11:00:00 +0000 From: "Dijk, Esko" To: Carsten Bormann Thread-Topic: [core] Informative refs in core-coap: groupcomm / http-mapping ? Thread-Index: Ac41ClTg+6BWDiH9Qu6C/Zf1AJDdpQABCAuAAABDR9A= Date: Tue, 9 Apr 2013 11:00:00 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618BFE37E@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618BFE2BA@011-DB3MPN2-082.MGDPHG.emi.philips.com> <9957A4C5-1B36-49D2-AADD-35481C1F7894@tzi.org> In-Reply-To: <9957A4C5-1B36-49D2-AADD-35481C1F7894@tzi.org> 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\)" Subject: Re: [core] Informative refs in core-coap: groupcomm / 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, 09 Apr 2013 11:00:44 -0000 > Oh. This is so obvious that I just made that change in the SVN right awa= y [1275]. Ok, good. That puts some pressure on the http-mapping authors to include a = decent default URI convention soon ;) > A more general discussion of group communication with CoAP is in [I-D.i= etf-core-groupcomm]. Ok for me as well. > Proxying multicast requests is discussed in more detail in [I-D.ietf-co= re-groupcomm]; a > proposal to address the base URI issue can be found in section 3 of [I-= D.bormann-coap-misc]. Ok for me. (Under the working assumption that our next-version text on this= topic will arrive soon) Additionally, we could add in core-coap section 8.2 in the first paragraph,= in the sentence between the brackets " (For example, in [RFC6690] query filtering, a server should not respond to a multicast request if the filter does not match.)" the following: "[I-D.ietf-core-groupcomm] lists a number of example use cases, each with g= uidelines on when a server needs to respond and when not." This is a kind of extension of the single example to multiple examples via = the reference. regards, Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Tuesday, April 09, 2013 12:39 To: Dijk, Esko Cc: core (core@ietf.org) Subject: Re: [core] Informative refs in core-coap: groupcomm / http-mapping= ? On Apr 9, 2013, at 12:12, "Dijk, Esko" wrote: > Dear all, > > I was just looking at the informative references section of core-coap. Id= eas for improving these references: > > 1) > We could replace reference to [I-D.bormann-core-cross-reverse-convention= ] with [draft-castellani-core-http-mapping], where we plan to add a default= URI convention for a reverse proxy in the next version, similar to the cur= rent content of [I-D.bormann-core-cross-reverse-convention]. Oh. This is so obvious that I just made that change in the SVN right away = [1275]. (This hasn't been done before because I was expecting a future version of h= ttp-mapping to have a "replaces" relationship to the cross-reverse-conventi= on draft -- that hasn't happened yet, but it is sure the intention, and we = should make this intention visible now.) > 2) > We could add a reference to [draft-ietf-core-groupcomm] to point to addit= ional guiding text on these two aspects: > =B7 Multicast Request Acceptance and Response Suppression (sectio= n 3.6). This provides details to the core-coap rule that a "server MAY alwa= ys pretend it did not receive the request" > =B7 A new section will be added for the next groupcomm version ab= out Proxying of multicast requests; related to core-coap section 8.2.2. It = explains in more detail the problems when doing this and a solution as well= . I would think that referencing groupcomm is a good idea. I'm not quite sur= e where and how, so let's discuss this: I'd probably add a sentence of the form A more general discussion of group communication with CoAP is in [I-D.ie= tf-core-groupcomm]. at the end of the first paragraph of section 8. I'd also insert a reference to groupcomm before the reference to coap-misc = in 8.2.2, like this: Proxying multicast requests is discussed in more detail in [I-D.ietf-cor= e-groupcomm]; a proposal to address the base URI issue can be found in section 3 of [I-D.bormann-coap-misc]. Gr=FC=DFe, Carsten ________________________________ 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 Tue Apr 9 04:46: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 4A9B621F901B for ; Tue, 9 Apr 2013 04:46:51 -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 teKrdzpB59HR for ; Tue, 9 Apr 2013 04:46:50 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEFE21F900F for ; Tue, 9 Apr 2013 04:46:50 -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 r39BkmKA026684; Tue, 9 Apr 2013 13:46:48 +0200 (CEST) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5139238D2; Tue, 9 Apr 2013 13:46:48 +0200 (CEST) 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: <031DD135F9160444ABBE3B0C36CED618BFE37E@011-DB3MPN2-082.MGDPHG.emi.philips.com> Date: Tue, 9 Apr 2013 13:46:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <031DD135F9160444ABBE3B0C36CED618BFE2BA@011-DB3MPN2-082.MGDPHG.emi.philips.com> <9957A4C5-1B36-49D2-AADD-35481C1F7894@tzi.org> <031DD135F9160444ABBE3B0C36CED618BFE37E@011-DB3MPN2-082.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1503) Cc: "core \(core@ietf.org\)" Subject: Re: [core] Informative refs in core-coap: groupcomm / 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, 09 Apr 2013 11:46:51 -0000 On Apr 9, 2013, at 13:00, "Dijk, Esko" wrote: > " (For example, in [RFC6690] query > filtering, a server should not respond to a multicast request if the > filter does not match.)" >=20 > the following: > "[I-D.ietf-core-groupcomm] lists a number of example use cases, each = with guidelines on when a server needs to respond and when not." I'd simplify this to: (For example, in [RFC6690] query filtering, a server should not respond to a multicast request if the filter does not match. More examples are in = [I-D.ietf-core-groupcomm].) Gr=FC=DFe, Carsten From matthieu.vial@non.schneider-electric.com Wed Apr 10 01:51:20 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BE021F888C for ; Wed, 10 Apr 2013 01:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TRNFER=2.3, 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 dR6NElOdsHqc for ; Wed, 10 Apr 2013 01:51:19 -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 58F7821F89DE for ; Wed, 10 Apr 2013 01:51:18 -0700 (PDT) Received: from ateui03.schneider-electric.com ([10.198.21.36]) by mailX03.eud.schneider-electric.com with ESMTP id 2013041010511670-293833 ; Wed, 10 Apr 2013 10:51:16 +0200 X-KeepSent: 80B87FE3:FB43AF23-C1257B49:00302528; type=4; flags=0; name=$KeepSent To: core@ietf.org X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: matthieu.vial@non.schneider-electric.com Date: Wed, 10 Apr 2013 10:51:15 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI03.Schneider-Electric.com/T/SVR/Schneider at 10/04/2013 10:51:16, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 10/04/2013 10:51:16, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 10/04/2013 10:51:18, Serialize complete at 10/04/2013 10:51:18 Content-type: multipart/alternative; Boundary="0__=4EBBF1DADFA3A3B88f9e8a93df938690918c4EBBF1DADFA3A3B8" Content-Disposition: inline Subject: [core] Tr : New Version Notification for draft-vial-core-mirror-server-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 08:51:20 -0000 --0__=4EBBF1DADFA3A3B88f9e8a93df938690918c4EBBF1DADFA3A3B8 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Dear working group, I have posted a minor change to mirror server draft thanks to Esko and Carsten. Best regards, Matthieu ----- Transf=E9r=E9 par Matthieu Vial/FR/Non/Schneider le 10/04/2013 10= :45 ----- De : internet-drafts@ietf.org A : Matthieu Vial/FR/Non/Schneider@Europe, Date : 10/04/2013 10:18 Objet : New Version Notification for draft-vial-core-mirror-server-01.txt A new version of I-D, draft-vial-core-mirror-server-01.txt has been successfully submitted by Matthieu Vial and posted to the IETF repository. Filename: draft-vial-core-mirror-server Revision: 01 Title: CoRE Mirror Server Creation date: 2013-04-10 Group: Individual Submission Number of pages: 20 URL: http://www.ietf.org/internet-drafts/draft-vial-core-mirror-server-01.tx= t Status: http://datatracker.ietf.org/doc/draft-vial-core-mirror-server Htmlized: http://tools.ietf.org/html/draft-vial-core-mirror-server-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-vial-core-mirror-server-01 Abstract: The Constrained RESTful Environments (CoRE) working group aims at realizing the REpresentational State Transfer (REST) architecture in= a suitable form for the most constrained nodes. Thanks to the Constrained Application Protocol (CoAP), REST is now applicable to constrained networks. However the most energy-constrained devices may enter sleep mode and disconnect their network link during severa= l minutes to save energy, hence preventing them from acting as traditional web servers. This document describes how a sleeping device can store resource representations in an entity called Mirror= Server and participate in a constrained RESTful environment. The IETF Secretariat ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud servic= e. ______________________________________________________________________= --0__=4EBBF1DADFA3A3B88f9e8a93df938690918c4EBBF1DADFA3A3B8 Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

Dear working group,

I have posted a minor change to mi= rror server draft thanks to Esko and Carsten.

Best regards,
Matthieu

----- Transf=E9r= =E9 par Matthieu Vial/FR/Non/Schneider le 10/04/2013 10:45 -----

De : internet-drafts@ietf.org
A : Matthieu Vial/FR/Non/Schneider@Europe, =
Date : 10/04/2013 10:18
Objet : <= font size=3D"1" face=3D"sans-serif">New Version Notification for draft-= vial-core-mirror-server-01.txt





A new version of I-D, draft-vial-core-mirror-server-01.txt
has been successfully submitted by Matthieu Vial and posted to the
IETF repository.

Filename:  draft-vial-core-mirror-server
Revision:  01
Title:  CoRE Mirror Server
Creation date:  2013-04-10
Group:  Individual Submission
Number of pages: 20
URL:             http://www.ietf.org/internet-drafts/draft-vial-c= ore-mirror-server-01.txt
Status:          http://datatracker.ietf.org/doc/draft-vial-core-mirror-server
Htmlized:        <= a href=3D"http://tools.ietf.org/html/draft-vial-core-mirror-server-01">= http://tools.ietf.org/html/draft-vial-core-mirror-server-01<= /tt>
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-vial-core-mi= rror-server-01

Abstract:
  The Constrained RESTful Environments (CoRE) working group aims = at
  realizing the REpresentational State Transfer (REST) architectu= re in
  a suitable form for the most constrained nodes.  Thanks to= the
  Constrained Application Protocol (CoAP), REST is now applicable= to
  constrained networks.  However the most energy-constrained= devices
  may enter sleep mode and disconnect their network link during s= everal
  minutes to save energy, hence preventing them from acting as   traditional web servers.  This document describes how a sl= eeping
  device can store resource representations in an entity called M= irror
  Server and participate in a constrained RESTful environment.
                    =                     &= nbsp;                   &n= bsp;                   &nb= sp;


The IETF Secretariat

______________________________________________________________________<= br> This email has been scanned by the Symantec Email Security.cloud servic= e.
______________________________________________________________________<= br> = --0__=4EBBF1DADFA3A3B88f9e8a93df938690918c4EBBF1DADFA3A3B8-- From esko.dijk@philips.com Thu Apr 11 05:18:48 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF3521F8CDF for ; Thu, 11 Apr 2013 05:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMvtopnkS3PI for ; Thu, 11 Apr 2013 05:18:45 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id 211CE21F8C98 for ; Thu, 11 Apr 2013 05:18:45 -0700 (PDT) Received: from mail86-db8-R.bigfish.com (10.174.8.239) by DB8EHSOBE002.bigfish.com (10.174.4.65) with Microsoft SMTP Server id 14.1.225.23; Thu, 11 Apr 2013 12:18:44 +0000 Received: from mail86-db8 (localhost [127.0.0.1]) by mail86-db8-R.bigfish.com (Postfix) with ESMTP id 229528C0090; Thu, 11 Apr 2013 12:18:44 +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(zzbb2dI15d6O9251Jc89bh936eIc85dh217bIzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz18de19h1033IL17326ah18c673h8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1155h) Received: from mail86-db8 (localhost.localdomain [127.0.0.1]) by mail86-db8 (MessageSwitch) id 1365682722320001_9322; Thu, 11 Apr 2013 12:18:42 +0000 (UTC) Received: from DB8EHSMHS030.bigfish.com (unknown [10.174.8.228]) by mail86-db8.bigfish.com (Postfix) with ESMTP id 48FBB300045; Thu, 11 Apr 2013 12:18:42 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB8EHSMHS030.bigfish.com (10.174.4.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 11 Apr 2013 12:18:38 +0000 Received: from 011-DB3MMR1-021.MGDPHG.emi.philips.com (10.128.28.103) by 011-DB3MMR1-003.MGDPHG.emi.philips.com (10.128.28.53) with Microsoft SMTP Server (TLS) id 14.2.328.11; Thu, 11 Apr 2013 12:17:52 +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; Thu, 11 Apr 2013 12:17:51 +0000 From: "Dijk, Esko" To: "matthieu.vial@non.schneider-electric.com" Thread-Topic: [core] Tr : New Version Notification for draft-vial-core-mirror-server-01.txt Thread-Index: AQHONcicMX49Zjokn0+/q8egYZyJOZjQs9zg Date: Thu, 11 Apr 2013 12:17:51 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618BFE8A2@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.104] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618BFE8A2011DB3MPN2082MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: Re: [core] Tr : New Version Notification for draft-vial-core-mirror-server-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 12:18:48 -0000 --_000_031DD135F9160444ABBE3B0C36CED618BFE8A2011DB3MPN2082MGDP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Matthieu, I wondered about the phrasing: "it is a list of web links to resources that have been modified by clients since either the last PUT request or the last call to the modification check interface. " That sounds ambiguous, as if the Mirror Server (MS) implementation could *c= hoose* one out of two point in time as the last-modified-time. Maybe something like this is more accurate? "it is a list that contains web links to all resources that have been modif= ied by clients since either 1) the last PUT request from the SEP was receiv= ed by the Mirror Server, or 2) the last call to the modification check interface made by the SEP was received by the Mir= ror Server, whichever one was most recent. " Esko PS glad to see that my earlier comments have been promoted from 'fruitful' = to 'useful' ;) From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of mat= thieu.vial@non.schneider-electric.com Sent: Wednesday, April 10, 2013 10:51 To: core@ietf.org Subject: [core] Tr : New Version Notification for draft-vial-core-mirror-se= rver-01.txt Dear working group, I have posted a minor change to mirror server draft thanks to Esko and Cars= ten. Best regards, Matthieu ----- Transf=E9r=E9 par Matthieu Vial/FR/Non/Schneider le 10/04/2013 10:45 = ----- De : internet-drafts@ietf.org A : Matthieu Vial/FR/Non/Schneider@Europe, Date : 10/04/2013 10:18 Objet : New Version Notification for draft-vial-core-mirror-server-01.txt ________________________________ A new version of I-D, draft-vial-core-mirror-server-01.txt has been successfully submitted by Matthieu Vial and posted to the IETF repository. Filename: draft-vial-core-mirror-server Revision: 01 Title: CoRE Mirror Server Creation date: 2013-04-10 Group: Individual Submission Number of pages: 20 URL: http://www.ietf.org/internet-drafts/draft-vial-core-mirror= -server-01.txt Status: http://datatracker.ietf.org/doc/draft-vial-core-mirror-ser= ver Htmlized: http://tools.ietf.org/html/draft-vial-core-mirror-server-0= 1 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-vial-core-mirror-= server-01 Abstract: The Constrained RESTful Environments (CoRE) working group aims at realizing the REpresentational State Transfer (REST) architecture in a suitable form for the most constrained nodes. Thanks to the Constrained Application Protocol (CoAP), REST is now applicable to constrained networks. However the most energy-constrained devices may enter sleep mode and disconnect their network link during several minutes to save energy, hence preventing them from acting as traditional web servers. This document describes how a sleeping device can store resource representations in an entity called Mirror Server and participate in a constrained RESTful environment. The IETF Secretariat ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. ______________________________________________________________________ ________________________________ 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_031DD135F9160444ABBE3B0C36CED618BFE8A2011DB3MPN2082MGDP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks Matthieu,=

 

I wondered about the ph= rasing:

“it is a list of = web links to resources that have been modified by 

    = ;   clients since either the last PUT request or the last ca= ll to the 

    = ;   modification check interface.  “

 

That sounds ambiguous, = as if the Mirror Server (MS) implementation could *choose* one out o= f two point in time as the last-modified-time.   

 

Maybe something like th= is is more accurate?

“it is a list tha= t contains web links to all resources that have been modified by 

    = ;   clients since either 1) the last PUT request from the SE= P was received by the Mirror Server, or 2) the last call to the 

    = ;   modification check interface made by the SEP was receive= d by the Mirror Server, whichever one was most recent. “

    = ;          

Esko

 

PS glad to see that my = earlier comments have been promoted from ‘fruitful’ to ‘u= seful’ ;)

 

From: core-b= ounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of matthieu.vial@non.schneider-electric.com
Sent: Wednesday, April 10, 2013 10:51
To: core@ietf.org
Subject: [core] Tr : New Version Notification for draft-vial-core-mi= rror-server-01.txt

 

Dear working group,

I have posted a minor change to mirror server draft thanks to E= sko and Carsten.

Best regards,
Matthieu

----- Transf=E9r=E9 par Matthieu Vial/FR/Non/Schne= ider le 10/04/2013 10:45 -----

De : internet-draf= ts@ietf.org
A : Matthieu Vial/FR/Non/Schneider@Europe,
Date : 10/04/2013 10:18
Objet : New Version Notification for draft-vial-core-mirror-serve= r-01.txt





A new version of I-D, draft-vial-core-mirror-server-01.txt
has been successfully submitted by Matthieu Vial and posted to the=
IETF repository.

Filename:  draft-vial-core-mirror-server
Revision:  01
Title:  CoRE Mirror Server
Creation date:  2013-04-10
Group:  Individual Submission
Number of pages: 20
URL:             http://www.ietf.org/internet-drafts/draft-vial-core-mirror-server-01.txt
Status:          http://datatracker.ietf.org/do= c/draft-vial-core-mirror-server
Htmlized:        http://tools.ietf.org/html/draft-vial= -core-mirror-server-01
Diff:            http://www.ietf.org= /rfcdiff?url2=3Ddraft-vial-core-mirror-server-01

Abstract:
  The Constrained RESTful Environments (CoRE) working group aims a= t
  realizing the REpresentational State Transfer (REST) architectur= e in
  a suitable form for the most constrained nodes.  Thanks to = the
  Constrained Application Protocol (CoAP), REST is now applicable = to
  constrained networks.  However the most energy-constrained = devices
  may enter sleep mode and disconnect their network link during se= veral
  minutes to save energy, hence preventing them from acting as
  traditional web servers.  This document describes how a sle= eping
  device can store resource representations in an entity called Mi= rror
  Server and participate in a constrained RESTful environment.

                    &= nbsp;                    =                     &nbs= p;                  


The IETF Secretariat

______________________________________________________________________<= /tt>
This email has been scanned by the Symantec Email Security.cloud servic= e.
______________________________________________________________________<= /tt>


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_031DD135F9160444ABBE3B0C36CED618BFE8A2011DB3MPN2082MGDP_-- From matthieu.vial@non.schneider-electric.com Thu Apr 11 07:55:23 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B374B21F8E3C for ; Thu, 11 Apr 2013 07:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[AWL=1.150, 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 SmwMXjNBUx8l for ; Thu, 11 Apr 2013 07:55:22 -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 68F7E21F8D5F for ; Thu, 11 Apr 2013 07:55:22 -0700 (PDT) Received: from ateui03.schneider-electric.com ([10.198.21.36]) by mailX03.eud.schneider-electric.com with ESMTP id 2013041116552112-40857 ; Thu, 11 Apr 2013 16:55:21 +0200 In-Reply-To: <031DD135F9160444ABBE3B0C36CED618BFE8A2@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618BFE8A2@011-DB3MPN2-082.MGDPHG.emi.philips.com> X-KeepSent: 4A9260A0:1991D2DA-C1257B4A:004F445F; type=4; flags=0; name=$KeepSent To: "Dijk, Esko" X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: matthieu.vial@non.schneider-electric.com Date: Thu, 11 Apr 2013 16:55:20 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI03.Schneider-Electric.com/T/SVR/Schneider at 11/04/2013 16:55:21, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 11/04/2013 16:55:21, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 11/04/2013 16:55:22, Serialize complete at 11/04/2013 16:55:22 Content-type: multipart/alternative; Boundary="0__=4EBBF1D9DFDCC2CF8f9e8a93df938690918c4EBBF1D9DFDCC2CF" Content-Disposition: inline Cc: "core@ietf.org" Subject: Re: [core] Tr : New Version Notification for draft-vial-core-mirror-server-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 14:55:24 -0000 --0__=4EBBF1D9DFDCC2CF8f9e8a93df938690918c4EBBF1D9DFDCC2CF Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Thanks Esko for your comment, > That sounds ambiguous, as if the Mirror Server (MS) implementation co= uld *choose* one out of two point in time as the last-modified-time. Agreed What do you think of: Instead, it is a list of web links to all resources that have been modi= fied by clients since the last check be it with the Modification check inter= face or the SEP operation interface. Matthieu= --0__=4EBBF1D9DFDCC2CF8f9e8a93df938690918c4EBBF1D9DFDCC2CF Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

Thanks Esko for = your comment,

> That sounds am= biguous, as if the Mirror Server (MS) implementation could *choose* one out of two point= in time as the last-modified-time. =A0=A0

Agreed

What do you think o= f:
Instead, it is a li= st of web links to all resources that have been modified by clients sin= ce the last check be it with the Modification check interface or the SE= P operation interface.
=A0
Matthieu= --0__=4EBBF1D9DFDCC2CF8f9e8a93df938690918c4EBBF1D9DFDCC2CF-- From esko.dijk@philips.com Thu Apr 11 09:15: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 CD9E021F8FAC for ; Thu, 11 Apr 2013 09:15:04 -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 jJw7WAUHDANU for ; Thu, 11 Apr 2013 09:15:03 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1CE21F8CF7 for ; Thu, 11 Apr 2013 09:15:03 -0700 (PDT) Received: from mail71-co1-R.bigfish.com (10.243.78.228) by CO1EHSOBE025.bigfish.com (10.243.66.88) with Microsoft SMTP Server id 14.1.225.23; Thu, 11 Apr 2013 16:15:02 +0000 Received: from mail71-co1 (localhost [127.0.0.1]) by mail71-co1-R.bigfish.com (Postfix) with ESMTP id B042DB4018F; Thu, 11 Apr 2013 16:15:02 +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(zz15d6O9251Jc89bh936eI542I1432I217bIzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail71-co1 (localhost.localdomain [127.0.0.1]) by mail71-co1 (MessageSwitch) id 1365696900863247_4471; Thu, 11 Apr 2013 16:15:00 +0000 (UTC) Received: from CO1EHSMHS021.bigfish.com (unknown [10.243.78.244]) by mail71-co1.bigfish.com (Postfix) with ESMTP id D05ABB800C3; Thu, 11 Apr 2013 16:15:00 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS021.bigfish.com (10.243.66.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 11 Apr 2013 16:15:00 +0000 Received: from 011-DB3MMR1-019.MGDPHG.emi.philips.com (10.128.28.106) by 011-DB3MMR1-008.MGDPHG.emi.philips.com (10.128.28.47) with Microsoft SMTP Server (TLS) id 14.2.328.11; Thu, 11 Apr 2013 16:14:59 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.99]) by 011-DB3MMR1-019.MGDPHG.emi.philips.com ([10.128.28.106]) with mapi id 14.02.0328.011; Thu, 11 Apr 2013 16:14:58 +0000 From: "Dijk, Esko" To: "consultancy@vanderstok.org" Thread-Topic: [core] Call for reviews of draft-castellani-core-http-mapping Thread-Index: AQHOKN+l05uJa1Rmo0etQcuHR51NeJjNq40AgAOE8xA= Date: Thu, 11 Apr 2013 16:14:58 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618BFEA84@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <0C9867A6-AED5-4063-88AE-E9D1C6CDE75E@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: [188.207.101.165] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "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: Thu, 11 Apr 2013 16:15:04 -0000 SGkgUGV0ZXIsDQoNCnRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gQWJvdXQgeW91ciBtYWluIGNv bmNlcm5zOg0KMS4gUHJveHkgZGVmaW5pdGlvbiBjb3VsZCBiZSB1cGRhdGVkLiBUaGVyZSB3YXMg YWxyZWFkeSBhbiBlbWFpbCB0aHJlYWQgb24gdGhpczsgd2hlcmUgSSBwcm9wb3NlIHRvIGRlZmlu ZSB0aGUgZm9yd2FyZC9yZXZlcnNlIHByb3h5IGluIHN1Y2ggYSB3YXkgdGhhdCB0aGUgImNsaWVu dCBhd2FyZW5lc3MiIGRvZXMgbm90IHBsYXkgYSByb2xlIGFueW1vcmUuIChTbzogb25seSB0aGUg c3ludGF4IHVzZWQgdG8gYWNjZXNzIHRoZSBwcm94eSBkZXRlcm1pbmVzIGZvcndhcmQgb3IgcmV2 ZXJzZS4pDQoyLiBVUkkgbmFtaW5nIGNvbnZlbnRpb24gZm9yIHJldmVyc2UgcHJveHkgd2lsbCBi ZSBhZGRlZCBpbiB0aGUgbmV4dCB2ZXJzaW9uLg0KMy4gQ29BUC10by1IVFRQIGNvbnZlcnNpb246 IHRoaXMgcGFydCB3YXMgcmVtb3ZlZCBlYXJsaWVyIGJhc2VkIG9uIFdHIGZlZWRiYWNrIHRoYXQg b3VyIHNjb3BlIGlzIHRvbyB3aWRlLiBJIGRvIGFncmVlIHRoYXQgdGhpcyB0b3BpYyBpcyBhbHNv IHVzZWZ1bC4gQXMgYSBzZXBhcmF0ZSBJLUQgcGVyaGFwcz8NCg0KcmVnYXJkcywNCkVza28NCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGNvcmUtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHBldGVyIHZhbiBkZXIg U3Rvaw0KU2VudDogVHVlc2RheSwgQXByaWwgMDksIDIwMTMgMTA6NDYNClRvOiBjb3JlQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW2NvcmVdIENhbGwgZm9yIHJldmlld3Mgb2YgZHJhZnQtY2FzdGVs bGFuaS1jb3JlLWh0dHAtbWFwcGluZw0KDQpEZWFyIHdnLA0KDQpSZXZpZXcgb2YgZHJhZnQtY2Fz dGVsbGFuaS1jb3JlLWh0dHAtbWFwcGluZywgaW5jbHVkaW5nIGNvYXAtMTQgc2VjdGlvbiAxMC4N Cg0KRm9yIG1lIHRleHQgYW5kIG9iamVjdGl2ZSBoYXZlIGJlY29tZSBjbGVhcmVyIGNvbXBhcmVk IHRvIGVhcmxpZXIgdmVyc2lvbnMuDQpUaGUgb2JqZWN0aXZlIG9mIHRoZSBkb2N1bWVudCB0byBk ZXNjcmliZSBwcm94aWVzIHN1Y2ggdGhhdCBwcm94aWVzIGZyb20gZGlmZmVyZW50IG1hbnVmYWN0 dXJlcnMgY2FuIGJlIGV4Y2hhbmdlZCBpcyBhIHZhbGlkIG1vdGl2YXRpb24gZm9yIHRoZSBkb2N1 bWVudC4NCg0KTXkgZmlyc3QgY29uY2VybiBpcyB0aGUgdXJpIG5hbWluZyBjb252ZW50aW9uIGFu ZCBwcm94eSBkZWZpbml0aW9uLg0KQ29uY2VybmluZyBwcm94eSBkZWZpbml0aW9uOg0KSSBhbSBo YXBweSB3aXRoIHRoZSBleHBsYW5hdGlvbiBvZiBmb3J3YXJkLCBjcm9zcyBhbmQgcmV2ZXJzZSBw cm94eSwgaXQgY2xhcmlmaWVzIHRoZSBiaXQgb3BhcXVlIHRleHQgb2YgY29hcC0xNC4gSG93ZXZl ciwgaXQgZG9lcyBub3QgaGVscCBtZSBtdWNoIGJlY2F1c2UgdGhlIGN1bGxlbiBleGFtcGxlIG9m IEktRC5ib3JtYW5uLWNvcmUtY3Jvc3MtcmV2ZXJzZS1jb252ZW50aW9uIGlzIHByZXNlbnRlZCBh cyByZXZlcnNlIHByb3h5IGV4YW1wbGUgd2hpbGUgdGhlIHRleHQgaW4gY2FzdGVsbGFuaSBtYWRl IG1lIHRoaW5rIGl0IGlzIGEgZm9yd2FyZCBwcm94eSBleGFtcGxlLCBiZWNhdXNlIHRoZSBjbGll bnQgc2VlbXMgdG8gYmUgYXdhcmUgdGhhdCB0cmFuc2xhdGlvbiB0YWtlcyBwbGFjZS4gVGhlcmUg c3RpbGwgc2VlbXMgdG8gYmUgYSBnYXAgaW4gbXkgdW5kZXJzdGFuZGluZyBmcm9tIHB1cmVseSBy ZWFkaW5nIHRoZSB0ZXh0cy4NCkNvbmNlcm5pbmcgbmFtaW5nIGNvbnZlbnRpb246DQpUaGUgZG9j dW1lbnQgZG9lcyBub3QgaGVscCBtdWNoIGluIHJlc3RyaWN0aW5nIHRoZSBVUkkgbmFtaW5nIGNv bnZlbnRpb25zLiBJIHdvdWxkIGV4cGVjdCBvbmUgb2YgdHdvIHRoaW5nczoNCjEpICAgICAgU3Ry aWN0IGd1aWRlbGluZXMgaG93IHRvIHRyYW5zbGF0ZSB1cmlzIChyZXN0cmljdCB0aGUgbnVtYmVy IG9mDQpwb3NzaWJpbGl0aWVzKQ0KMikgICAgICBQcm92aWRlIG1lYW5zIHRvIGRlZmluZSB0aGUg dXJpIHRyYW5zbGF0aW9uIG9uIHRoZSBwcm94eS4NCkkgZG8gbm90IHNlZSBhbnkgb3RoZXIgd2F5 IG9mIG1ha2luZyBzdXJlIHRoYXQgcHJveGllcyBvZiBkaWZmZXJlbnQgbWFudWZhY3R1cmVycyBj YW4gYmUgZXhjaGFuZ2VkLg0KDQpNeSBzZWNvbmQgY29uY2VybiBpcyB0aGF0IHRoZSBkb2N1bWVu dCBvbmx5IHRyZWF0cyBodHRwLWNvYXAgdHJhbnNsYXRpb24uIFRoZSBjYXNlIGNvYXAtaHR0cCBz ZWVtcyBtb3JlIHVyZ2VudC4gV2UgZG8gbm90IHdhbnQgdG8gcHJvdmlkZSB0aGUgc21hbGwgZGV2 aWNlcyB3aXRoIGEgaHR0cC90Y3AgY29kZSBuZXh0IHRvIHRoZSBjb2FwL3VkcCBjb2RlLCB3aGls ZSB0aGVzZSBkZXZpY2VzIHdpbGwgbmVlZCB0byB0YWxrIHRvIOKAnGxlZ2FjeeKAnSBodHRwIGJh Y2stZW5kIHNlcnZlcnMuIFN1Z2dlc3Rpb246IGFkZCB0aGUgY29hcC1odHRwIHBhcnQuDQoNCklu ZGl2aWR1YWwgbml0cyBhbmQgc3VnZ2VzdGlvbnMuDQpQYWdlIDYsIHNlY3Rpb24gNSwgYWxsIDIs IGxpbmUgNeKApuKApi5leHBsaWNpdGx5IGluZGljYXRlcyBUSEFUIGl0IHRhcmdldHMg4oCm4oCm ICh0aGF0IGZvcmdvdHRlbj8pIFNlY3Rpb24gNSwgYWxsIDMsIHVuaWNhc3QgaHR0cCB0byBtdWx0 aWNhc3QgY29hcCBpcyBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IGRvY3VtZW50IChyZW1vdmUgdGhl IGN1cnJlbnRseSBpbiB0aGUg4oCcY3VycmVudGx5IG91dCBvZiBzY29wZeKAnS4gV291bGRu4oCZ dCB5b3UgZGlzY291cmFnZSB0aGUgdW5pY2FzdCB0byBtdWx0aWNhc3QgYXNwZWN0IGluIGEgc3Rh bmRhcmRpemVkIHByb3h5Pw0KU2VjdGlvbiA1LjEgY2FjaGluZzogYWRkIOKAnGdpdmVu4oCdIHRv IOKApi4gYWxsIHJlcXVlc3QgdHJhZmZpYyB0byBhIGdpdmVuIENPQVAgc2VydmVy4oCm4oCmLg0K U2VjIDUuMSBNdWx0aWNhc3Q7IHBvc3NpYmx5IHRoZSB3cm9uZyByZWFzb24gZm9yIGEgdmFsaWQg ZWZmaWNpZW5jeQ0KYXJndW1lbnQ6IHRvIGNvbm5lY3QgYSBwcm94eSBpbnRlcmZhY2UgdG8gdGhl IG1lc2ggbmV0d29yay4NClNlYyA1LjEgVENQL1VEUDogSSBkbyBub3Qgc2VlIHRoZSBwbGFjZW1l bnQgYXNwZWN0IGhlcmUgU2VjIDUuMiBOb3Rlcy4gRG8geW91IG5vdCBuZWVkIHRvIGdpdmUgZm9y bXVsYXM/IEZvciBleGFtcGxlIGluIG5vdGUgOCwgdGhlIGRldGVybWluYXRpb24gb2YgbWF4LWFn ZSB2YWx1ZSBTZWMgNS40IGhvdyB0byBjb25maWd1cmUgdGhlIGxpbWl0IGFuZCBxdWV1aW5nL2Ry b3BwaW5nIGJlaGF2aW9yPyBUaGUgZG9jdW1lbnQgc2hvdWxkIHNwZWNpZnkgYW4gaW50ZXJmYWNl Lg0KU2VjIDUuNSBhbmQgNS42IEkgbGlrZSB0aGUgZWZmb3J0IHRvIHNwZWNpZnkgbGltaXRzIG9m IGJlaGF2aW9ycy4NClNlYyA3LiBJIHVuZGVyc3RhbmQgdGhhdCBhIHByb3h5IHJlcHJlc2VudHMg dGhlIHR5cGljYWwg4oCcbWFuIGluIHRoZSBtaWRkbGXigJ0gdGhyZWF0LiBIYXZpbmcgaXQgc2Vj dXJlbHkgY29ubmVjdGVkIHRvIHRoZSBuZXR3b3JrIGJlZm9yZSBhbnkgYWNjZXNzIGFuZCBhIHJl Z3VsYXIgcmVjb25uZWN0aW9uIG1heSBoYXZlIGEgcG9zaXRpdmUgZWZmZWN0Lg0KDQpob3BlIHRo aXMgaGVscHMsDQoNCnBldGVyDQoNCkNhcnN0ZW4gQm9ybWFubiBzY2hyZWVmIG9wIDIwMTMtMDMt MjQgMjM6MzM6DQo+IEluIE9ybGFuZG8sIHdlIHNhaWQgd2Ugd2VyZSB0cnlpbmcgdG8gaW5jcmVh c2UgdGhlIGxldmVsIG9mIGF0dGVudGlvbg0KPiBvbiB0aGUgSFRUUCBtYXBwaW5nIGRyYWZ0IHdp dGggYSB2aWV3IHRvIG1ha2luZyBpdCBhIFdHIGRvY3VtZW50IHZlcnkNCj4gc29vbi4NCj4gU28s IGlmIHlvdSBoYXZlIGNvbW1lbnRzIG9uIGl0IG5vdywgcGxlYXNlIHNlbmQgdGhlbSB0byB0aGUg bGlzdC4NCj4gV2UgaGFkIGEgZmV3IHBlb3BsZSB2b2x1bnRlZXJpbmcgdG8gcmV2aWV3IHRoZSBk cmFmdCBhcyBhIHByZXJlcXVpc2l0ZQ0KPiB0byBhIGNhbGwgZm9yIFdHIGFkb3B0aW9uLCBzbyBw bGVhc2UgZG8gc2VuZCBpbiB0aGVzZSAoc2hvcnQgb3IgbG9uZywNCj4gYXMgeW91IGxpa2UpIHJl dmlld3MuDQo+IE9mIGNvdXJzZSBXRyBhZG9wdGlvbiBtZWFucyB0aGF0IHRoZSBXRyBzdGFydHMg Y29uc2lkZXJpbmcgdGhpcyBhcyBhDQo+IFdHIGRyYWZ0LCBub3QgdGhhdCB3ZSBhbGwgYWxyZWFk eSBhZ3JlZSB3aXRoIGV2ZXJ5IGRldGFpbCwgYnV0IGFueQ0KPiBjb25jZXJucyBhYm91dCBzY29w aW5nIGFuZCBnZW5lcmFsIGFwcHJvYWNoIHNob3VsZCBiZSBkaXNjdXNzZWQgbm93Lg0KPg0KPiBH csO8w59lLCBDYXJzdGVuDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IGNvcmUgbWFpbGluZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0 ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBm b3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNz ZW1pbmF0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFu ZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo= From hartke@tzi.org Thu Apr 11 12:46:52 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A781C21F8D94 for ; Thu, 11 Apr 2013 12:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5Omx1C+IT4d for ; Thu, 11 Apr 2013 12:46:51 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id DF0EA21F8D8E for ; Thu, 11 Apr 2013 12:46:50 -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 r3BJkmSu001232 for ; Thu, 11 Apr 2013 21:46:48 +0200 (CEST) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DA6373BAE for ; Thu, 11 Apr 2013 21:46:47 +0200 (CEST) Received: by mail-vc0-f177.google.com with SMTP id hr11so1620260vcb.36 for ; Thu, 11 Apr 2013 12:46:46 -0700 (PDT) X-Received: by 10.220.104.68 with SMTP id n4mr6198770vco.37.1365709606719; Thu, 11 Apr 2013 12:46:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.187.134 with HTTP; Thu, 11 Apr 2013 12:46:06 -0700 (PDT) In-Reply-To: <031DD135F9160444ABBE3B0C36CED618BFEA84@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <0C9867A6-AED5-4063-88AE-E9D1C6CDE75E@tzi.org> <031DD135F9160444ABBE3B0C36CED618BFEA84@011-DB3MPN2-082.MGDPHG.emi.philips.com> From: Klaus Hartke Date: Thu, 11 Apr 2013 22:46:06 +0300 Message-ID: To: "core@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 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: Thu, 11 Apr 2013 19:46:52 -0000 Esko Dijk wrote: > I propose to define the forward/reverse proxy in such a way that the "client awareness" does not play a role anymore Client awareness is pretty much what distinguishes a forward proxy from a reverse proxy. Assume a client retrieves a representation of a resource and this representation contains a link. Then there are the following cases: * The client uses the information in the URI to connect to a server. The server at that address is the authoritative source for representations of the resource identified by the URI, so it returns a response directly. -> "Origin server". * The client uses the information in the URI to connect to a server. However, the server is _not_ the authoritative source for representations of the resource identified by the URI. Instead, it has been configured to obtain the representation from an unrelated third party. Which third party it connects to can come from local configuration or be embedded in the URI. From the perspective of the client, the response looks and feels exactly as a response from an origin server, though. -> "Reverse proxy". It is an unilateral decision of the server to obtain the representation from a third party. * The client does _not_ use the information in the URI. Instead, it has been configured to connect to an unrelated third party. The client requests this third party to obtain the representation of the resource identified by the URI, well aware that this third party not the authoritative source for the representation. -> "Forward proxy". It is an unilateral decision of the client to request a third party to obtain the representation and not to connect to the server specified in the URI. The protocol between client--proxy and proxy--origin-server do not have to be the same. For example, a client can make an HTTP request to a reverse proxy and the reverse proxy makes a CoAP request to the origin server. http://coap.me/ is a good example of an HTTP/CoAP cross-protocol reverse proxy. It embeds the information which CoAP server to connect to in the http:// URI, and rewrites all links in representations obtained from CoAP servers to http:// URIs, so you can use a simple web browser to browse CoAP servers. The protocol between client--forward-proxy is often a bit different than between client--origin-server and client--reverse-proxy. For example, when a client makes a CoAP request to a forward proxy, the URI is transmitted in the Proxy-Uri Option and not in the Uri-* Options. Similarly, when a client makes an HTTP request to a forward proxy, the entire URI is transmitted in the request line and not in the Host header field. Unfortunately, in case of a HTTP/CoAP cross-protocol forward proxy, we cannot simply put a coap:// URI in the HTTP request line. So we need a different protocol that both the client and the forward-proxy agree on to encode this request. One way is to let the client translate the coap:// URI to an http:// URI in a standardized way, and the forward proxy translates the http:// URI back to the original coap:// URI. The line between reverse proxy and forward proxy seems to blur when we embed coap:// URIs in http:// URIs in the reverse proxy case, and translate coap:// URIs to http:// URIs in the forward proxy case. But it doesn't. - Does the client have an http:// URI and does the HTTP server make the unilateral decision to make a CoAP request (based on an embedded coap:// URI in the http:// URI, opaque to the client)? Reverse proxy. - Does the client have a coap:// URI and does it make the unilateral decision to perform an HTTP request (with the coap:// URI translated to a http:// URI according to some standardized scheme)? Forward proxy. Just my 2 cents. Klaus From esko.dijk@philips.com Fri Apr 12 00:07:55 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B903421F8AB2 for ; Fri, 12 Apr 2013 00:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.001, 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 qCsZIBMv6kUE for ; Fri, 12 Apr 2013 00:07:55 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3D10421F8A4F for ; Fri, 12 Apr 2013 00:07:44 -0700 (PDT) Received: from mail175-tx2-R.bigfish.com (10.9.14.233) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 12 Apr 2013 07:07:43 +0000 Received: from mail175-tx2 (localhost [127.0.0.1]) by mail175-tx2-R.bigfish.com (Postfix) with ESMTP id 9BD86320090; Fri, 12 Apr 2013 07:07:43 +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: -31 X-BigFish: VPS-31(zz15d6O9251Jc89bh936eI542I1432I217bIzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dh1b3f39h92f2jz2dh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail175-tx2 (localhost.localdomain [127.0.0.1]) by mail175-tx2 (MessageSwitch) id 1365750462228500_15147; Fri, 12 Apr 2013 07:07:42 +0000 (UTC) Received: from TX2EHSMHS013.bigfish.com (unknown [10.9.14.251]) by mail175-tx2.bigfish.com (Postfix) with ESMTP id 354EB300043; Fri, 12 Apr 2013 07:07:42 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS013.bigfish.com (10.9.99.113) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 12 Apr 2013 07:07:42 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.176]) by 011-DB3MMR1-010.MGDPHG.emi.philips.com ([10.128.28.49]) with mapi id 14.02.0328.011; Fri, 12 Apr 2013 07:06:52 +0000 From: "Dijk, Esko" To: "consultancy@vanderstok.org" , "core@ietf.org" Thread-Topic: [core] Call for reviews of draft-castellani-core-http-mapping Thread-Index: AQHOKN+l05uJa1Rmo0etQcuHR51NeJjNq40AgASZaaA= Date: Fri, 12 Apr 2013 07:06:51 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C04EB3@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <0C9867A6-AED5-4063-88AE-E9D1C6CDE75E@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 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: Fri, 12 Apr 2013 07:07:55 -0000 SGkgUGV0ZXIsDQoNCkZvcmdvdCB0byBtZW50aW9uIGFib3V0IHRoZSBjYXNlIENvQVAtSFRUUDog YW5vdGhlciByZWFzb24gdGhlIGF1dGhvcnMgZGlkIG5vdCBwdXJzdWUgdGhpcyB3YXMgdGhhdCBh IENvQVAgY2xpZW50IGNhbiBzaW1wbHkgdXNlIHRoZSBDb0FQIGZvcndhcmQgcHJveHlpbmcgZnVu Y3Rpb25hbGl0eSAoaS5lLiBhIENvQVAgcmVxdWVzdCB3aXRoIGEgUHJveHktVVJJIG9wdGlvbiBv ciBQcm94eS1TY2hlbWUgb3B0aW9uIGNvbnRhaW5pbmcgYSBodHRwOi8vIFVSSSkgdG8gYWNjZXNz IEhUVFAgc2VydmVycy4NCg0KRXNrbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgcGV0ZXIgdmFuIGRlciBTdG9rDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAwOSwg MjAxMyAxMDo0Ng0KVG86IGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbY29yZV0gQ2FsbCBm b3IgcmV2aWV3cyBvZiBkcmFmdC1jYXN0ZWxsYW5pLWNvcmUtaHR0cC1tYXBwaW5nDQoNCkRlYXIg d2csDQoNClJldmlldyBvZiBkcmFmdC1jYXN0ZWxsYW5pLWNvcmUtaHR0cC1tYXBwaW5nLCBpbmNs dWRpbmcgY29hcC0xNCBzZWN0aW9uIDEwLg0KDQpGb3IgbWUgdGV4dCBhbmQgb2JqZWN0aXZlIGhh dmUgYmVjb21lIGNsZWFyZXIgY29tcGFyZWQgdG8gZWFybGllciB2ZXJzaW9ucy4NClRoZSBvYmpl Y3RpdmUgb2YgdGhlIGRvY3VtZW50IHRvIGRlc2NyaWJlIHByb3hpZXMgc3VjaCB0aGF0IHByb3hp ZXMgZnJvbSBkaWZmZXJlbnQgbWFudWZhY3R1cmVycyBjYW4gYmUgZXhjaGFuZ2VkIGlzIGEgdmFs aWQgbW90aXZhdGlvbiBmb3IgdGhlIGRvY3VtZW50Lg0KDQpNeSBmaXJzdCBjb25jZXJuIGlzIHRo ZSB1cmkgbmFtaW5nIGNvbnZlbnRpb24gYW5kIHByb3h5IGRlZmluaXRpb24uDQpDb25jZXJuaW5n IHByb3h5IGRlZmluaXRpb246DQpJIGFtIGhhcHB5IHdpdGggdGhlIGV4cGxhbmF0aW9uIG9mIGZv cndhcmQsIGNyb3NzIGFuZCByZXZlcnNlIHByb3h5LCBpdCBjbGFyaWZpZXMgdGhlIGJpdCBvcGFx dWUgdGV4dCBvZiBjb2FwLTE0LiBIb3dldmVyLCBpdCBkb2VzIG5vdCBoZWxwIG1lIG11Y2ggYmVj YXVzZSB0aGUgY3VsbGVuIGV4YW1wbGUgb2YgSS1ELmJvcm1hbm4tY29yZS1jcm9zcy1yZXZlcnNl LWNvbnZlbnRpb24gaXMgcHJlc2VudGVkIGFzIHJldmVyc2UgcHJveHkgZXhhbXBsZSB3aGlsZSB0 aGUgdGV4dCBpbiBjYXN0ZWxsYW5pIG1hZGUgbWUgdGhpbmsgaXQgaXMgYSBmb3J3YXJkIHByb3h5 IGV4YW1wbGUsIGJlY2F1c2UgdGhlIGNsaWVudCBzZWVtcyB0byBiZSBhd2FyZSB0aGF0IHRyYW5z bGF0aW9uIHRha2VzIHBsYWNlLiBUaGVyZSBzdGlsbCBzZWVtcyB0byBiZSBhIGdhcCBpbiBteSB1 bmRlcnN0YW5kaW5nIGZyb20gcHVyZWx5IHJlYWRpbmcgdGhlIHRleHRzLg0KQ29uY2VybmluZyBu YW1pbmcgY29udmVudGlvbjoNClRoZSBkb2N1bWVudCBkb2VzIG5vdCBoZWxwIG11Y2ggaW4gcmVz dHJpY3RpbmcgdGhlIFVSSSBuYW1pbmcgY29udmVudGlvbnMuIEkgd291bGQgZXhwZWN0IG9uZSBv ZiB0d28gdGhpbmdzOg0KMSkgICAgICBTdHJpY3QgZ3VpZGVsaW5lcyBob3cgdG8gdHJhbnNsYXRl IHVyaXMgKHJlc3RyaWN0IHRoZSBudW1iZXIgb2YNCnBvc3NpYmlsaXRpZXMpDQoyKSAgICAgIFBy b3ZpZGUgbWVhbnMgdG8gZGVmaW5lIHRoZSB1cmkgdHJhbnNsYXRpb24gb24gdGhlIHByb3h5Lg0K SSBkbyBub3Qgc2VlIGFueSBvdGhlciB3YXkgb2YgbWFraW5nIHN1cmUgdGhhdCBwcm94aWVzIG9m IGRpZmZlcmVudCBtYW51ZmFjdHVyZXJzIGNhbiBiZSBleGNoYW5nZWQuDQoNCk15IHNlY29uZCBj b25jZXJuIGlzIHRoYXQgdGhlIGRvY3VtZW50IG9ubHkgdHJlYXRzIGh0dHAtY29hcCB0cmFuc2xh dGlvbi4gVGhlIGNhc2UgY29hcC1odHRwIHNlZW1zIG1vcmUgdXJnZW50LiBXZSBkbyBub3Qgd2Fu dCB0byBwcm92aWRlIHRoZSBzbWFsbCBkZXZpY2VzIHdpdGggYSBodHRwL3RjcCBjb2RlIG5leHQg dG8gdGhlIGNvYXAvdWRwIGNvZGUsIHdoaWxlIHRoZXNlIGRldmljZXMgd2lsbCBuZWVkIHRvIHRh bGsgdG8g4oCcbGVnYWN54oCdIGh0dHAgYmFjay1lbmQgc2VydmVycy4gU3VnZ2VzdGlvbjogYWRk IHRoZSBjb2FwLWh0dHAgcGFydC4NCg0KSW5kaXZpZHVhbCBuaXRzIGFuZCBzdWdnZXN0aW9ucy4N ClBhZ2UgNiwgc2VjdGlvbiA1LCBhbGwgMiwgbGluZSA14oCm4oCmLmV4cGxpY2l0bHkgaW5kaWNh dGVzIFRIQVQgaXQgdGFyZ2V0cyDigKbigKYgKHRoYXQgZm9yZ290dGVuPykgU2VjdGlvbiA1LCBh bGwgMywgdW5pY2FzdCBodHRwIHRvIG11bHRpY2FzdCBjb2FwIGlzIGEgY29tcGxldGVseSBkaWZm ZXJlbnQgZG9jdW1lbnQgKHJlbW92ZSB0aGUgY3VycmVudGx5IGluIHRoZSDigJxjdXJyZW50bHkg b3V0IG9mIHNjb3Bl4oCdLiBXb3VsZG7igJl0IHlvdSBkaXNjb3VyYWdlIHRoZSB1bmljYXN0IHRv IG11bHRpY2FzdCBhc3BlY3QgaW4gYSBzdGFuZGFyZGl6ZWQgcHJveHk/DQpTZWN0aW9uIDUuMSBj YWNoaW5nOiBhZGQg4oCcZ2l2ZW7igJ0gdG8g4oCmLiBhbGwgcmVxdWVzdCB0cmFmZmljIHRvIGEg Z2l2ZW4gQ09BUCBzZXJ2ZXLigKbigKYuDQpTZWMgNS4xIE11bHRpY2FzdDsgcG9zc2libHkgdGhl IHdyb25nIHJlYXNvbiBmb3IgYSB2YWxpZCBlZmZpY2llbmN5DQphcmd1bWVudDogdG8gY29ubmVj dCBhIHByb3h5IGludGVyZmFjZSB0byB0aGUgbWVzaCBuZXR3b3JrLg0KU2VjIDUuMSBUQ1AvVURQ OiBJIGRvIG5vdCBzZWUgdGhlIHBsYWNlbWVudCBhc3BlY3QgaGVyZSBTZWMgNS4yIE5vdGVzLiBE byB5b3Ugbm90IG5lZWQgdG8gZ2l2ZSBmb3JtdWxhcz8gRm9yIGV4YW1wbGUgaW4gbm90ZSA4LCB0 aGUgZGV0ZXJtaW5hdGlvbiBvZiBtYXgtYWdlIHZhbHVlIFNlYyA1LjQgaG93IHRvIGNvbmZpZ3Vy ZSB0aGUgbGltaXQgYW5kIHF1ZXVpbmcvZHJvcHBpbmcgYmVoYXZpb3I/IFRoZSBkb2N1bWVudCBz aG91bGQgc3BlY2lmeSBhbiBpbnRlcmZhY2UuDQpTZWMgNS41IGFuZCA1LjYgSSBsaWtlIHRoZSBl ZmZvcnQgdG8gc3BlY2lmeSBsaW1pdHMgb2YgYmVoYXZpb3JzLg0KU2VjIDcuIEkgdW5kZXJzdGFu ZCB0aGF0IGEgcHJveHkgcmVwcmVzZW50cyB0aGUgdHlwaWNhbCDigJxtYW4gaW4gdGhlIG1pZGRs ZeKAnSB0aHJlYXQuIEhhdmluZyBpdCBzZWN1cmVseSBjb25uZWN0ZWQgdG8gdGhlIG5ldHdvcmsg YmVmb3JlIGFueSBhY2Nlc3MgYW5kIGEgcmVndWxhciByZWNvbm5lY3Rpb24gbWF5IGhhdmUgYSBw b3NpdGl2ZSBlZmZlY3QuDQoNCmhvcGUgdGhpcyBoZWxwcywNCg0KcGV0ZXINCg0KQ2Fyc3RlbiBC b3JtYW5uIHNjaHJlZWYgb3AgMjAxMy0wMy0yNCAyMzozMzoNCj4gSW4gT3JsYW5kbywgd2Ugc2Fp ZCB3ZSB3ZXJlIHRyeWluZyB0byBpbmNyZWFzZSB0aGUgbGV2ZWwgb2YgYXR0ZW50aW9uDQo+IG9u IHRoZSBIVFRQIG1hcHBpbmcgZHJhZnQgd2l0aCBhIHZpZXcgdG8gbWFraW5nIGl0IGEgV0cgZG9j dW1lbnQgdmVyeQ0KPiBzb29uLg0KPiBTbywgaWYgeW91IGhhdmUgY29tbWVudHMgb24gaXQgbm93 LCBwbGVhc2Ugc2VuZCB0aGVtIHRvIHRoZSBsaXN0Lg0KPiBXZSBoYWQgYSBmZXcgcGVvcGxlIHZv bHVudGVlcmluZyB0byByZXZpZXcgdGhlIGRyYWZ0IGFzIGEgcHJlcmVxdWlzaXRlDQo+IHRvIGEg Y2FsbCBmb3IgV0cgYWRvcHRpb24sIHNvIHBsZWFzZSBkbyBzZW5kIGluIHRoZXNlIChzaG9ydCBv ciBsb25nLA0KPiBhcyB5b3UgbGlrZSkgcmV2aWV3cy4NCj4gT2YgY291cnNlIFdHIGFkb3B0aW9u IG1lYW5zIHRoYXQgdGhlIFdHIHN0YXJ0cyBjb25zaWRlcmluZyB0aGlzIGFzIGENCj4gV0cgZHJh ZnQsIG5vdCB0aGF0IHdlIGFsbCBhbHJlYWR5IGFncmVlIHdpdGggZXZlcnkgZGV0YWlsLCBidXQg YW55DQo+IGNvbmNlcm5zIGFib3V0IHNjb3BpbmcgYW5kIGdlbmVyYWwgYXBwcm9hY2ggc2hvdWxk IGJlIGRpc2N1c3NlZCBub3cuDQo+DQo+IEdyw7zDn2UsIENhcnN0ZW4NCj4NCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gY29yZSBtYWlsaW5nIGxp c3QNCj4gY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NvcmUNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlk ZW50aWFsIGFuZCBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1l c3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0 IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0 aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUg c2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3Jp Z2luYWwgbWVzc2FnZS4NCg== From esko.dijk@philips.com Fri Apr 12 01:15: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 6DF8521F89FB for ; Fri, 12 Apr 2013 01:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwernPHn6hNc for ; Fri, 12 Apr 2013 01:15:52 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9C84D21F8AA6 for ; Fri, 12 Apr 2013 01:15:50 -0700 (PDT) Received: from mail48-tx2-R.bigfish.com (10.9.14.230) by TX2EHSOBE014.bigfish.com (10.9.40.34) with Microsoft SMTP Server id 14.1.225.23; Fri, 12 Apr 2013 08:15:47 +0000 Received: from mail48-tx2 (localhost [127.0.0.1]) by mail48-tx2-R.bigfish.com (Postfix) with ESMTP id 260BD48019F; Fri, 12 Apr 2013 08:15:47 +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: -31 X-BigFish: VPS-31(zz98dI15d6O9251J542I1432I217bIzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL177df4h17326ah8275dh1b3f39h92f2jz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail48-tx2 (localhost.localdomain [127.0.0.1]) by mail48-tx2 (MessageSwitch) id 1365754544429794_9031; Fri, 12 Apr 2013 08:15:44 +0000 (UTC) Received: from TX2EHSMHS024.bigfish.com (unknown [10.9.14.237]) by mail48-tx2.bigfish.com (Postfix) with ESMTP id 650C222006F; Fri, 12 Apr 2013 08:15:44 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS024.bigfish.com (10.9.99.124) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 12 Apr 2013 08:15:43 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.176]) by 011-DB3MMR1-005.MGDPHG.emi.philips.com ([10.128.28.55]) with mapi id 14.02.0328.011; Fri, 12 Apr 2013 08:15:37 +0000 From: "Dijk, Esko" To: Klaus Hartke , "core@ietf.org" Thread-Topic: [core] Call for reviews of draft-castellani-core-http-mapping Thread-Index: AQHOKN+l05uJa1Rmo0etQcuHR51NeJjNq40AgAOE8xCAAFgqAIAAzS6g Date: Fri, 12 Apr 2013 08:15:36 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C08FCE@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <0C9867A6-AED5-4063-88AE-E9D1C6CDE75E@tzi.org> <031DD135F9160444ABBE3B0C36CED618BFEA84@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com 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: Fri, 12 Apr 2013 08:15:53 -0000 Hi Klaus, > - Does the client have an http:// URI and does the HTTP server make the u= nilateral decision > to make a CoAP request (based on an embedded coap:// URI in the http:// U= RI, opaque to the client)? > Reverse proxy. > > - Does the client have a coap:// URI and does it make the unilateral deci= sion to perform an HTTP request > (with the coap:// URI translated to a http:// URI according to some stand= ardized scheme)? > Forward proxy. If I apply the same argumentation, I may get these 2 cases: 1) The client has a coap:// URI and makes the unilateral decision to perfor= m an HTTP request (with the coap:// URI translated to a http:// URI accordi= ng to some standardized scheme) to the proxy. Then the proxy makes the deci= sion to get the coap:// URI out of the HTTP request and performs a CoAP req= uest using this coap:// URI. -> Forward proxy. 2) The client got a http:// URI from someone, doesn't know a thing about Co= AP, and this URI happens to be the same http:// URI as the one in point 1) = above. Then the HTTP server makes the unilateral decision to get the coap:/= / URI out of the HTTP request and performs a CoAP request using this coap:/= / URI. -> Reverse proxy. The point/issue here is that the proxy acting in point 1) and 2) is the sam= e HTTP server operating in exactly the same way. And it's both a Forward an= d a Reverse proxy depending on what the client knows. So it's hard to defin= e guidelines for a Reverse Proxy only, because it could unknowingly be also= a Forward Proxy. Therefore I argued that the distinction in this way is no= t useful. (See also the earlier thread http://www.ietf.org/mail-archive/web/core/curr= ent/msg04170.html ) Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Kla= us Hartke Sent: Thursday, April 11, 2013 21:46 To: core@ietf.org Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping Esko Dijk wrote: > I propose to define the forward/reverse proxy in such a way that the > "client awareness" does not play a role anymore Client awareness is pretty much what distinguishes a forward proxy from a r= everse proxy. Assume a client retrieves a representation of a resource and this represent= ation contains a link. Then there are the following cases: * The client uses the information in the URI to connect to a server. The server at that address is the authoritative source for representations = of the resource identified by the URI, so it returns a response directly. -> "Origin server". * The client uses the information in the URI to connect to a server. However, the server is _not_ the authoritative source for representations o= f the resource identified by the URI. Instead, it has been configured to ob= tain the representation from an unrelated third party. Which third party it= connects to can come from local configuration or be embedded in the URI. F= rom the perspective of the client, the response looks and feels exactly as = a response from an origin server, though. -> "Reverse proxy". It is an unilateral decision of the server to obta= in the representation from a third party. * The client does _not_ use the information in the URI. Instead, it has bee= n configured to connect to an unrelated third party. The client requests th= is third party to obtain the representation of the resource identified by t= he URI, well aware that this third party not the authoritative source for t= he representation. -> "Forward proxy". It is an unilateral decision of the client to requ= est a third party to obtain the representation and not to connect to the se= rver specified in the URI. The protocol between client--proxy and proxy--origin-server do not have to = be the same. For example, a client can make an HTTP request to a reverse pr= oxy and the reverse proxy makes a CoAP request to the origin server. http://coap.me/ is a good example of an HTTP/CoAP cross-protocol reverse pr= oxy. It embeds the information which CoAP server to connect to in the http:= // URI, and rewrites all links in representations obtained from CoAP server= s to http:// URIs, so you can use a simple web browser to browse CoAP serve= rs. The protocol between client--forward-proxy is often a bit different than be= tween client--origin-server and client--reverse-proxy. For example, when a = client makes a CoAP request to a forward proxy, the URI is transmitted in t= he Proxy-Uri Option and not in the Uri-* Options. Similarly, when a client = makes an HTTP request to a forward proxy, the entire URI is transmitted in = the request line and not in the Host header field. Unfortunately, in case of a HTTP/CoAP cross-protocol forward proxy, we cann= ot simply put a coap:// URI in the HTTP request line. So we need a differen= t protocol that both the client and the forward-proxy agree on to encode th= is request. One way is to let the client translate the coap:// URI to an ht= tp:// URI in a standardized way, and the forward proxy translates the http:= // URI back to the original coap:// URI. The line between reverse proxy and forward proxy seems to blur when we embe= d coap:// URIs in http:// URIs in the reverse proxy case, and translate coa= p:// URIs to http:// URIs in the forward proxy case. But it doesn't. - Does the client have an http:// URI and does the HTTP server make the uni= lateral decision to make a CoAP request (based on an embedded coap:// URI i= n the http:// URI, opaque to the client)? Reverse proxy. - Does the client have a coap:// URI and does it make the unilateral decisi= on to perform an HTTP request (with the coap:// URI translated to a http://= URI according to some standardized scheme)? Forward proxy. Just my 2 cents. Klaus _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From trac+core@trac.tools.ietf.org Fri Apr 12 04:25:20 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636C721F892B for ; Fri, 12 Apr 2013 04:25:20 -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 BUgDUrnFt6la for ; Fri, 12 Apr 2013 04:25:20 -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 D144D21F8573 for ; Fri, 12 Apr 2013 04:25:19 -0700 (PDT) Received: from localhost ([127.0.0.1]:39027 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UQc6V-0004IB-IX; Fri, 12 Apr 2013 13:25:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Fri, 12 Apr 2013 11:25:15 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/295 Message-ID: <060.8757b37fd42e8ea6e6513915442267df@trac.tools.ietf.org> X-Trac-Ticket-ID: 295 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130412112519.D144D21F8573@ietfa.amsl.com> Resent-Date: Fri, 12 Apr 2013 04:25:19 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #295: Add discovery of group addresses via DNS or RD X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 11:25:20 -0000 #295: Add discovery of group addresses via DNS or RD As remarked during IETF86, discovery of group addresses via DNS or RD was not sufficiently addressed yet. - Add to section 3.7: discovery of group address via DNS or RD. - Add to use case section 4: example flow for group address commissioning based on discovery mechanisms with input from Peter van der Stok. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: new Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Apr 12 04:46:55 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAA521F8A3F for ; Fri, 12 Apr 2013 04:46:55 -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 PTNdon2TRcF8 for ; Fri, 12 Apr 2013 04:46:55 -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 CBE4821F899E for ; Fri, 12 Apr 2013 04:46:54 -0700 (PDT) Received: from localhost ([127.0.0.1]:39767 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UQcRQ-0003Qr-Nn; Fri, 12 Apr 2013 13:46:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Fri, 12 Apr 2013 11:46:52 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/274#comment:1 Message-ID: <075.3885233eb06eafcd71f1a0ac0d8d9c33@trac.tools.ietf.org> References: <060.7eda5107ad7608dc2f4f1046db908829@trac.tools.ietf.org> X-Trac-Ticket-ID: 274 In-Reply-To: <060.7eda5107ad7608dc2f4f1046db908829@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130412114654.CBE4821F899E@ietfa.amsl.com> Resent-Date: Fri, 12 Apr 2013 04:46:54 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #274: Add section on multicast via Proxy and its limitations X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 11:46:55 -0000 #274: Add section on multicast via Proxy and its limitations Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Done in [1276] -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: closed Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Apr 12 04:47: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 3D36221F85BF for ; Fri, 12 Apr 2013 04:47:33 -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 g-Xenzpi6zZf for ; Fri, 12 Apr 2013 04:47:32 -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 B0C7321F859C for ; Fri, 12 Apr 2013 04:47:32 -0700 (PDT) Received: from localhost ([127.0.0.1]:39800 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UQcS2-0002Jf-KW; Fri, 12 Apr 2013 13:47:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Fri, 12 Apr 2013 11:47:30 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/280#comment:1 Message-ID: <075.437c01bb1c3951170b9a74606a24482d@trac.tools.ietf.org> References: <060.551223a5c99f3a96dbcae80387a25ad3@trac.tools.ietf.org> X-Trac-Ticket-ID: 280 In-Reply-To: <060.551223a5c99f3a96dbcae80387a25ad3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130412114732.B0C7321F859C@ietfa.amsl.com> Resent-Date: Fri, 12 Apr 2013 04:47:32 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #280: Issues with two/multiple Resource Directories in use case X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 11:47:33 -0000 #280: Issues with two/multiple Resource Directories in use case Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Done in [1276] -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: closed Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Apr 12 04:48: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 D274B21F8B08 for ; Fri, 12 Apr 2013 04:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 vvFObu5T9-P5 for ; Fri, 12 Apr 2013 04:48:28 -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 4AFE121F8A3F for ; Fri, 12 Apr 2013 04:48:28 -0700 (PDT) Received: from localhost ([127.0.0.1]:39818 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UQcSw-000534-E8; Fri, 12 Apr 2013 13:48:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Fri, 12 Apr 2013 11:48:26 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/278#comment:1 Message-ID: <075.9f352092ce1a50bec9d14ffb3bb05391@trac.tools.ietf.org> References: <060.5a65e8888a8762d62705314cddf068ae@trac.tools.ietf.org> X-Trac-Ticket-ID: 278 In-Reply-To: <060.5a65e8888a8762d62705314cddf068ae@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130412114828.4AFE121F8A3F@ietfa.amsl.com> Resent-Date: Fri, 12 Apr 2013 04:48:28 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #278: Add single-subnet configuration to use cases X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 11:48:28 -0000 #278: Add single-subnet configuration to use cases Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => wontfix Comment: Authors decided it does not add much, also based on IETF86 CoRE WG meeting input (no clear preferences). -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: closed Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Resolution: wontfix Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Apr 12 04:59:27 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEA121F87D0 for ; Fri, 12 Apr 2013 04:59:27 -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 Aa3UyN2gkQNu for ; Fri, 12 Apr 2013 04:59:27 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6833121F86E8 for ; Fri, 12 Apr 2013 04:59:27 -0700 (PDT) Received: from localhost ([127.0.0.1]:40511 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UQcdY-0001XJ-W2; Fri, 12 Apr 2013 13:59:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Fri, 12 Apr 2013 11:59:24 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/279#comment:1 Message-ID: <075.dbd35993d092a46ee7f3567bb2881273@trac.tools.ietf.org> References: <060.96eb9ab9636e9ef18dbaf3eb2c38a6d0@trac.tools.ietf.org> X-Trac-Ticket-ID: 279 In-Reply-To: <060.96eb9ab9636e9ef18dbaf3eb2c38a6d0@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130412115927.6833121F86E8@ietfa.amsl.com> Resent-Date: Fri, 12 Apr 2013 04:59:27 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #279: Add use case with controller (client) located on the backbone X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 11:59:28 -0000 #279: Add use case with controller (client) located on the backbone Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Resolved with [1276] and [1277]. It was added. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: closed Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From pda@unistra.fr Fri Apr 12 05:10: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 C806B21F86F2 for ; Fri, 12 Apr 2013 05:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLyU-0RU5A9O for ; Fri, 12 Apr 2013 05:10:24 -0700 (PDT) Received: from mailhost.u-strasbg.fr (mailhost-v6.u-strasbg.fr [IPv6:2001:660:2402::201:46]) by ietfa.amsl.com (Postfix) with ESMTP id 1377E21F852A for ; Fri, 12 Apr 2013 05:10:23 -0700 (PDT) Received: from md16.u-strasbg.fr (md16.u-strasbg.fr [130.79.200.206]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id r3CCAJ1e080656 for ; Fri, 12 Apr 2013 14:10:19 +0200 (CEST) (envelope-from pda@unistra.fr) Received: from mailserver.u-strasbg.fr (ms15.u-strasbg.fr [130.79.204.115]) by md16.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id r3CCAI9A025037 for ; Fri, 12 Apr 2013 14:10:18 +0200 (envelope-from pda@unistra.fr) Received: from localhost (vagabond.u-strasbg.fr [130.79.90.217]) (user=pda mech=PLAIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id r3CCAIbK026984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 12 Apr 2013 14:10:18 +0200 (envelope-from pda@unistra.fr) Date: Fri, 12 Apr 2013 14:10:18 +0200 From: Pierre DAVID To: core@ietf.org Message-ID: <20130412121017.GA26159@vagabond.ma.maison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.5 (mailhost.u-strasbg.fr [130.79.201.46]); Fri, 12 Apr 2013 14:10:19 +0200 (CEST) Subject: [core] Message ID in 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: Fri, 12 Apr 2013 12:10:25 -0000 Hi, in draft-ietf-core-coap-14.txt, section 4.4 (Message Correlation), I have a problem regarding the implementation note for Message ID generation. It is said: Endpoints dealing with large numbers of transactions could keep multiple Message ID variables, for example per prefix or destination address If I generate Message IDs per *destination address*, how do I deal with broadcast/multicast addresses? It can generate collisions on Message IDs. Let's take the case where I have (say on node N): - an ID generator for unicast address A - an ID generator for broadcast or multicast address B The node A may thus receive the same message ID (with a low probability) for a unicast message from N to A and for a broadcast/multicast message =66rom N. In my opinion, the Message ID can not be generated by destination address nor by prefix. Have I missed something? Pierre David From trac+core@trac.tools.ietf.org Fri Apr 12 05:23: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 C64DD21F8B15 for ; Fri, 12 Apr 2013 05:23:35 -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 ZK0hSC+iWBY2 for ; Fri, 12 Apr 2013 05:23:35 -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 3488521F8B13 for ; Fri, 12 Apr 2013 05:23:34 -0700 (PDT) Received: from localhost ([127.0.0.1]:41550 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UQd0u-0005H5-Tl; Fri, 12 Apr 2013 14:23:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Fri, 12 Apr 2013 12:23:32 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/295#comment:1 Message-ID: <075.57c5b027149d491765b18d0f93404e5d@trac.tools.ietf.org> References: <060.8757b37fd42e8ea6e6513915442267df@trac.tools.ietf.org> X-Trac-Ticket-ID: 295 In-Reply-To: <060.8757b37fd42e8ea6e6513915442267df@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130412122335.3488521F8B13@ietfa.amsl.com> Resent-Date: Fri, 12 Apr 2013 05:23:34 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #295: Add discovery of group addresses via DNS or RD X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 12:23:35 -0000 #295: Add discovery of group addresses via DNS or RD Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Section 4.6 added in [1278] for the RD case. Section 3.7 updated. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: closed Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Apr 12 05:41:40 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D375221F8A68 for ; Fri, 12 Apr 2013 05:41:40 -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 DWuhwJEhnbG8 for ; Fri, 12 Apr 2013 05:41:40 -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 3DA4421F8A3F for ; Fri, 12 Apr 2013 05:41:40 -0700 (PDT) Received: from localhost ([127.0.0.1]:42129 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UQdIP-0005dU-K9; Fri, 12 Apr 2013 14:41:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Fri, 12 Apr 2013 12:41:37 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/296 Message-ID: <060.dbca848cf7a32945871723581b121bd4@trac.tools.ietf.org> X-Trac-Ticket-ID: 296 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130412124140.3DA4421F8A3F@ietfa.amsl.com> Resent-Date: Fri, 12 Apr 2013 05:41:40 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #296: Process review comments PvdS of Tue 2013-02-12 11:13 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 12:41:40 -0000 #296: Process review comments PvdS of Tue 2013-02-12 11:13 Groupcomm: Process review comments PvdS of Tue 2013-02-12 11:13 http://www.ietf.org/mail-archive/web/core/current/msg04099.html -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: editorial | Status: new Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: core From internet-drafts@ietf.org Fri Apr 12 05:50:00 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049E021F8A85; Fri, 12 Apr 2013 05:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.180, 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 3FiOTif03Nev; Fri, 12 Apr 2013 05:49:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F2F21F8A91; Fri, 12 Apr 2013 05:49:59 -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.p4 Message-ID: <20130412124959.22556.94358.idtracker@ietfa.amsl.com> Date: Fri, 12 Apr 2013 05:49:59 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 12:50:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-06.txt Pages : 33 Date : 2013-04-12 Abstract: CoAP is a RESTful transfer protocol for constrained devices and networks. It is anticipated that constrained devices will often naturally operate in groups (e.g. in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document provides guidance for how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed for both constrained and un-constrained networks. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cabo@tzi.org Fri Apr 12 06:10:41 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C58C21F8842 for ; Fri, 12 Apr 2013 06:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMFBaZEJc7mT for ; Fri, 12 Apr 2013 06:10:40 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAC621F86BB for ; Fri, 12 Apr 2013 06:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r3CDAc0m023179; Fri, 12 Apr 2013 15:10:38 +0200 (CEST) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4B58B30A4; Fri, 12 Apr 2013 15:10:38 +0200 (CEST) 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: <20130412121017.GA26159@vagabond.ma.maison> Date: Fri, 12 Apr 2013 15:10:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <783DBA27-B1AF-4305-B06F-E7B10E96547C@tzi.org> References: <20130412121017.GA26159@vagabond.ma.maison> To: Pierre DAVID X-Mailer: Apple Mail (2.1503) Cc: core@ietf.org Subject: Re: [core] Message ID in 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: Fri, 12 Apr 2013 13:10:41 -0000 On Apr 12, 2013, at 14:10, Pierre DAVID wrote: > Let's take the case where I have (say on node N): > - an ID generator for unicast address A > - an ID generator for broadcast or multicast address B > The node A may thus receive the same message ID (with a low = probability) > for a unicast message from N to A and for a broadcast/multicast = message > from N. Unless the recipient is RFC 3542-challenged, it could find out whether = the message was addressed to it by unicast or to the multicast group. But, indeed, there may be RFC 3542-challenged nodes. Another problem is any RST generated in such a situation: =20 That comes from the unicast address of A and goes to N, using the = message-ID set by N. =20 If N has used the same message ID for A and for B, it won't be able to = find out which message is being rejected. So the best way to handle multicast is to namespace the message-IDs:=20 reserve a little part of the message-ID space for the multicast messages = you are going to send, and do global allocation out of them. Do you think this subject should receive more attention in the coap = spec? As in "As a multicast message may reach endpoints who may not be able to = recognize the message as a multicast message, care must be taken to = avoid overlap between message-IDs used for unicast and multicast = messages."? Or should we move more of the implementation notes to the LWIG document = that contains a more detailed discussion of message-ID handling? Gr=FC=DFe, Carsten From angelo.castellani@gmail.com Fri Apr 12 06:20:59 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD76721F8CCB for ; Fri, 12 Apr 2013 06:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXTP76+dkbb7 for ; Fri, 12 Apr 2013 06:20:59 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CBFAD21F8CA5 for ; Fri, 12 Apr 2013 06:20:58 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id u10so2644056lbi.31 for ; Fri, 12 Apr 2013 06:20:57 -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; bh=PrJPXAm7WU5/et9buYAIQBX3+IyXl+2IZZ/osrG4Dcw=; b=akVvjIuZ+EEXvEJtAxkGevJWEeUasY68RkPfW9OxCsw3MnqSx6ZLiSvtNJ9RClb7Jf fJZ3QZ1mVmVjLmZID2EbN6wLAaz9Gd8Jx5iJRXYWByyZmltM7Tltqh+B8/AsSqbvdmyb Gpy5ZnkmUAT3JM1ajPxFZhrVzaHjLkkq3LCqPGlzF/D8abylVNE1TE9Tgj5oj2uXsGV7 IbWQTmhb1pT6BhM8oOZEVcPwBOMF4GAOm5YulSDhQArAtYCEJljclo/Znxu6FBsjagn4 Bwj/5bNI/B8MDFdjkx2WSMNZ7PmGjMd7P3DO2byJQMtotHfcsAJOFvxzzG3nClQLSXPZ o5Iw== X-Received: by 10.152.104.199 with SMTP id gg7mr5336507lab.14.1365772857734; Fri, 12 Apr 2013 06:20:57 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.112.20.195 with HTTP; Fri, 12 Apr 2013 06:20:42 -0700 (PDT) In-Reply-To: <20130412121017.GA26159@vagabond.ma.maison> References: <20130412121017.GA26159@vagabond.ma.maison> From: "Angelo P. Castellani" Date: Fri, 12 Apr 2013 15:20:42 +0200 X-Google-Sender-Auth: 9RWNnDSt_qjmcH_m6MMDbIcKZdQ Message-ID: To: Pierre DAVID Content-Type: text/plain; charset=UTF-8 Cc: core Subject: Re: [core] Message ID in 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: Fri, 12 Apr 2013 13:20:59 -0000 Dear Pierre David, the problem you are pointing out is quite interesting in my opinion. In the current draft has been made the (typical?) assumption that each destination address, i.e., (IP, port) pair, corresponds to a different endpoint. The case you propose is just one of those where this assumption does not hold anymore. Some other cases very similar that I am thinking about are: 1. multihomed hosts, i.e., hosts with multiple IP addresses all pointing to the same machine 2. CoAP servers listening on multiple ports Some time ago there was also discussion about using a 16-bit internal clock value for generating MIDs, as long as the requirement in CoAP spec is met: The same Message ID MUST NOT be re-used (in communicating with the same endpoint) within the EXCHANGE_LIFETIME (Section 4.8.2). If this is the case it has collision probability equal to 1, as long as the communications we are talking about happen during the granularity period of the internal clock (e.g. depending on hardware and internal clock they typically range between 1 second and 1 millisecond, as far as I know). To avoid reusing the same MID with the *same endpoint* within EXCHANGE_LIFETIME, we probably can't rely on the (IP, port) address pair as endpoint identifier. Best, Angelo 2013/4/12 Pierre DAVID : > Hi, > > in draft-ietf-core-coap-14.txt, section 4.4 (Message Correlation), I have > a problem regarding the implementation note for Message ID generation. > > It is said: > > Endpoints dealing with large numbers of transactions > could keep multiple Message ID variables, for example per prefix > or destination address > > If I generate Message IDs per *destination address*, how do I deal with > broadcast/multicast addresses? It can generate collisions on Message IDs. > > Let's take the case where I have (say on node N): > - an ID generator for unicast address A > - an ID generator for broadcast or multicast address B > The node A may thus receive the same message ID (with a low probability) > for a unicast message from N to A and for a broadcast/multicast message > from N. > > In my opinion, the Message ID can not be generated by destination address > nor by prefix. > > Have I missed something? > > Pierre David > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From pda@unistra.fr Fri Apr 12 07:13:42 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76CD21F8721 for ; Fri, 12 Apr 2013 07:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RcVv2flxRKS for ; Fri, 12 Apr 2013 07:13:42 -0700 (PDT) Received: from mailhost.u-strasbg.fr (mailhost-v6.u-strasbg.fr [IPv6:2001:660:2402::201:46]) by ietfa.amsl.com (Postfix) with ESMTP id EFDC621F86B7 for ; Fri, 12 Apr 2013 07:13:41 -0700 (PDT) Received: from md14.u-strasbg.fr (md14.u-strasbg.fr [130.79.200.249]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id r3CEDWsQ009693 ; Fri, 12 Apr 2013 16:13:32 +0200 (CEST) (envelope-from pda@unistra.fr) Received: from mailserver.u-strasbg.fr (ms13.u-strasbg.fr [130.79.204.113]) by md14.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id r3CEDUIl018910 ; Fri, 12 Apr 2013 16:13:32 +0200 Received: from localhost (vagabond.u-strasbg.fr [130.79.90.217]) (user=pda mech=PLAIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id r3CEDRwm032417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) ; Fri, 12 Apr 2013 16:13:28 +0200 (envelope-from pda@unistra.fr) Date: Fri, 12 Apr 2013 16:13:27 +0200 From: Pierre DAVID To: Carsten Bormann Message-ID: <20130412141327.GA6746@vagabond.ma.maison> References: <20130412121017.GA26159@vagabond.ma.maison> <783DBA27-B1AF-4305-B06F-E7B10E96547C@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <783DBA27-B1AF-4305-B06F-E7B10E96547C@tzi.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.5 (mailhost.u-strasbg.fr [130.79.201.46]); Fri, 12 Apr 2013 16:13:32 +0200 (CEST) Cc: core@ietf.org Subject: Re: [core] Message ID in 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: Fri, 12 Apr 2013 14:13:42 -0000 On Fri, Apr 12, 2013 at 03:10:37PM +0200, Carsten Bormann wrote: > On Apr 12, 2013, at 14:10, Pierre DAVID wrote: > > > Let's take the case where I have (say on node N): > > - an ID generator for unicast address A > > - an ID generator for broadcast or multicast address B > > The node A may thus receive the same message ID (with a low probability) > > for a unicast message from N to A and for a broadcast/multicast message > > from N. > > Unless the recipient is RFC 3542-challenged, it could find out whether the message was addressed to it by unicast or to the multicast group. > But, indeed, there may be RFC 3542-challenged nodes. > Another problem is any RST generated in such a situation: > That comes from the unicast address of A and goes to N, using the message-ID set by N. > If N has used the same message ID for A and for B, it won't be able to find out which message is being rejected. > > So the best way to handle multicast is to namespace the message-IDs: > reserve a little part of the message-ID space for the multicast messages you are going to send, and do global allocation out of them. > > Do you think this subject should receive more attention in the coap spec? > As in "As a multicast message may reach endpoints who may not be able to recognize the message as a multicast message, care must be taken to avoid overlap between message-IDs used for unicast and multicast messages."? > Or should we move more of the implementation notes to the LWIG document that contains a more detailed discussion of message-ID handling? > IMHO, distinguish MIDs for messages addressed via unicast or broadcast/multicast is a too heavy burden in for a really constrained node. If I had to vote, I would remove this implementation note from the current draft. Pierre From trac+core@trac.tools.ietf.org Fri Apr 12 08:51:47 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868C821F8C00 for ; Fri, 12 Apr 2013 08:51:47 -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 aypGkNqs1YSh for ; Fri, 12 Apr 2013 08:51:47 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E20B621F8D4E for ; Fri, 12 Apr 2013 08:51:46 -0700 (PDT) Received: from localhost ([127.0.0.1]:50852 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UQgGP-00009n-3F; Fri, 12 Apr 2013 17:51:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Fri, 12 Apr 2013 15:51:45 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/284#comment:1 Message-ID: <066.8934a84350eafe4c4fcf9f9543560834@trac.tools.ietf.org> References: <051.db1a9938adff5bec98b14c262d132149@trac.tools.ietf.org> X-Trac-Ticket-ID: 284 In-Reply-To: <051.db1a9938adff5bec98b14c262d132149@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130412155146.E20B621F8D4E@ietfa.amsl.com> Resent-Date: Fri, 12 Apr 2013 08:51:46 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #284: Reference terminology from lwig-terminology X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 15:51:47 -0000 #284: Reference terminology from lwig-terminology Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1281]: Fix #284 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: post-IESG-1 Component: coap | Version: coap-14 Severity: Submitted | Resolution: fixed WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Apr 12 08:54:31 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6AF21F8C3C for ; Fri, 12 Apr 2013 08:54:31 -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 usb32LyD75kY for ; Fri, 12 Apr 2013 08:54:30 -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 49F4221F8C16 for ; Fri, 12 Apr 2013 08:54:30 -0700 (PDT) Received: from localhost ([127.0.0.1]:51007 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UQgJ3-0002yY-46; Fri, 12 Apr 2013 17:54:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Fri, 12 Apr 2013 15:54:29 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/285#comment:1 Message-ID: <066.6a1294f0d66908d5d6cf20612422407c@trac.tools.ietf.org> References: <051.b48c10558fb2c588c917b0d1674a35d8@trac.tools.ietf.org> X-Trac-Ticket-ID: 285 In-Reply-To: <051.b48c10558fb2c588c917b0d1674a35d8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130412155430.49F4221F8C16@ietfa.amsl.com> Resent-Date: Fri, 12 Apr 2013 08:54:30 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #285: Make reference to HTTP terms more explicit X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 15:54:31 -0000 #285: Make reference to HTTP terms more explicit Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1282]: Fix #285 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: post-IESG-1 Component: coap | Version: coap-14 Severity: Submitted | Resolution: fixed WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From esko.dijk@philips.com Fri Apr 12 09:07: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 6C0D521F8E91 for ; Fri, 12 Apr 2013 09:07:14 -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 nrHjBY9ofPDP for ; Fri, 12 Apr 2013 09:07:13 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id BD08721F8E87 for ; Fri, 12 Apr 2013 09:07:13 -0700 (PDT) Received: from mail48-co1-R.bigfish.com (10.243.78.241) by CO1EHSOBE014.bigfish.com (10.243.66.77) with Microsoft SMTP Server id 14.1.225.23; Fri, 12 Apr 2013 16:07:12 +0000 Received: from mail48-co1 (localhost [127.0.0.1]) by mail48-co1-R.bigfish.com (Postfix) with ESMTP id B7FB55C017D; Fri, 12 Apr 2013 16:07:12 +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(zz98dI15d6O9251Jc89bh542I217bIzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail48-co1 (localhost.localdomain [127.0.0.1]) by mail48-co1 (MessageSwitch) id 136578283039221_15559; Fri, 12 Apr 2013 16:07:10 +0000 (UTC) Received: from CO1EHSMHS012.bigfish.com (unknown [10.243.78.243]) by mail48-co1.bigfish.com (Postfix) with ESMTP id F204EBC0076; Fri, 12 Apr 2013 16:07:09 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS012.bigfish.com (10.243.66.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 12 Apr 2013 16:07:09 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.176]) by 011-DB3MMR1-005.MGDPHG.emi.philips.com ([10.128.28.55]) with mapi id 14.02.0328.011; Fri, 12 Apr 2013 16:07:08 +0000 From: "Dijk, Esko" To: Carsten Bormann , Pierre DAVID Thread-Topic: [core] Message ID in draft-ietf-core-coap-14.txt Thread-Index: AQHON3a6DwAFqDGo4k6HO/p86P4zVJjSj1GAgAAwL6A= Date: Fri, 12 Apr 2013 16:07:07 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C0B211@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <20130412121017.GA26159@vagabond.ma.maison> <783DBA27-B1AF-4305-B06F-E7B10E96547C@tzi.org> In-Reply-To: <783DBA27-B1AF-4305-B06F-E7B10E96547C@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [188.207.100.157] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: Re: [core] Message ID in 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: Fri, 12 Apr 2013 16:07:14 -0000 Hi Carsten, > Unless the recipient is RFC 3542-challenged, it could find out whether th= e message was addressed to it by unicast or to the multicast group. I thought that for deduplication purposes this information (whether message= was unicast or multicast) is not used? Section 4.5: " (as indicated by the Message ID and source endpoint)". So even if a recipient is not RFC 3542-challenged, the problem would be sti= ll there or not? Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Car= sten Bormann Sent: Friday, April 12, 2013 15:11 To: Pierre DAVID Cc: core@ietf.org Subject: Re: [core] Message ID in draft-ietf-core-coap-14.txt On Apr 12, 2013, at 14:10, Pierre DAVID wrote: > Let's take the case where I have (say on node N): > - an ID generator for unicast address A > - an ID generator for broadcast or multicast address B The node A may > thus receive the same message ID (with a low probability) for a > unicast message from N to A and for a broadcast/multicast message from > N. Unless the recipient is RFC 3542-challenged, it could find out whether the = message was addressed to it by unicast or to the multicast group. But, indeed, there may be RFC 3542-challenged nodes. Another problem is any RST generated in such a situation: That comes from the unicast address of A and goes to N, using the message-I= D set by N. If N has used the same message ID for A and for B, it won't be able to find= out which message is being rejected. So the best way to handle multicast is to namespace the message-IDs: reserve a little part of the message-ID space for the multicast messages yo= u are going to send, and do global allocation out of them. Do you think this subject should receive more attention in the coap spec? As in "As a multicast message may reach endpoints who may not be able to re= cognize the message as a multicast message, care must be taken to avoid ove= rlap between message-IDs used for unicast and multicast messages."? Or should we move more of the implementation notes to the LWIG document tha= t contains a more detailed discussion of message-ID handling? Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From trac+core@trac.tools.ietf.org Fri Apr 12 09:13: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 7156A21F8E4B for ; Fri, 12 Apr 2013 09:13:13 -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 7VWREKFcc0P3 for ; Fri, 12 Apr 2013 09:13:13 -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 BCE4821F8E49 for ; Fri, 12 Apr 2013 09:13:12 -0700 (PDT) Received: from localhost ([127.0.0.1]:52144 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UQgb5-00074Q-EN; Fri, 12 Apr 2013 18:13:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Fri, 12 Apr 2013 16:13:07 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/286#comment:1 Message-ID: <066.7a6f1592ee37ef6ca3ecb12d298d9095@trac.tools.ietf.org> References: <051.0765cc130ff8d113c3d95d4d6a3f2214@trac.tools.ietf.org> X-Trac-Ticket-ID: 286 In-Reply-To: <051.0765cc130ff8d113c3d95d4d6a3f2214@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130412161312.BCE4821F8E49@ietfa.amsl.com> Resent-Date: Fri, 12 Apr 2013 09:13:12 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #286: Make reference to ECC/CCM DTLS ciphersuite normative X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 16:13:13 -0000 #286: Make reference to ECC/CCM DTLS ciphersuite normative Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1283]: Fix #286 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: other | Status: closed technical | Milestone: post-IESG-1 Priority: major | Version: coap-14 Component: coap | Resolution: fixed Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Apr 12 09:26: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 B93F821F8F7A for ; Fri, 12 Apr 2013 09:26: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=[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 qz4mVvxaLYak for ; Fri, 12 Apr 2013 09:26:54 -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 E7AF021F8F76 for ; Fri, 12 Apr 2013 09:26:45 -0700 (PDT) Received: from localhost ([127.0.0.1]:52482 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UQgoF-0002vf-Va; Fri, 12 Apr 2013 18:26:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Fri, 12 Apr 2013 16:26:43 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/287#comment:1 Message-ID: <066.34b32b6844594623f0939993e26b3c02@trac.tools.ietf.org> References: <051.852767a49b85928dce42c7e61234c7f2@trac.tools.ietf.org> X-Trac-Ticket-ID: 287 In-Reply-To: <051.852767a49b85928dce42c7e61234c7f2@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130412162650.E7AF021F8F76@ietfa.amsl.com> Resent-Date: Fri, 12 Apr 2013 09:26:45 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #287: Add a quick warning that bytewise scanning for a payload marker is not a good idea X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 16:26:57 -0000 #287: Add a quick warning that bytewise scanning for a payload marker is not a good idea Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1284]: Fix #287 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: post-IESG-1 Component: coap | Version: coap-14 Severity: Submitted | Resolution: fixed WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Apr 12 09:34: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 30FE621F8F02 for ; Fri, 12 Apr 2013 09:34: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=[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 VmGujlgzWMaW for ; Fri, 12 Apr 2013 09:34:56 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 90FD721F8EE1 for ; Fri, 12 Apr 2013 09:34:56 -0700 (PDT) Received: from localhost ([127.0.0.1]:52701 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UQgwB-0008O9-Fq; Fri, 12 Apr 2013 18:34:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Fri, 12 Apr 2013 16:34:55 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/288#comment:1 Message-ID: <066.de6c56033933ee36959c471951e1a7c1@trac.tools.ietf.org> References: <051.2be51c5e623e108fe30fca1a40cf1d2a@trac.tools.ietf.org> X-Trac-Ticket-ID: 288 In-Reply-To: <051.2be51c5e623e108fe30fca1a40cf1d2a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130412163456.90FD721F8EE1@ietfa.amsl.com> Resent-Date: Fri, 12 Apr 2013 09:34:56 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #288: Make reference to PROBING_RATE explicit X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 16:34:57 -0000 #288: Make reference to PROBING_RATE explicit Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1285]: Fix #288 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: post-IESG-1 Component: coap | Version: coap-14 Severity: Submitted | Resolution: fixed WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Apr 12 11: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 7C28621F8E6D for ; Fri, 12 Apr 2013 11:42:15 -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 GBL6PdrgmmFp for ; Fri, 12 Apr 2013 11:42:15 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id DD15B21F8D4E for ; Fri, 12 Apr 2013 11:42:14 -0700 (PDT) Received: from localhost ([127.0.0.1]:58847 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UQivL-00069n-Hh; Fri, 12 Apr 2013 20:42:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Fri, 12 Apr 2013 18:42:11 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/289#comment:1 Message-ID: <066.de99c7a65c5970f597045f1787f86972@trac.tools.ietf.org> References: <051.f948e6154bd02325eb29fb216d93af27@trac.tools.ietf.org> X-Trac-Ticket-ID: 289 In-Reply-To: <051.f948e6154bd02325eb29fb216d93af27@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130412184214.DD15B21F8D4E@ietfa.amsl.com> Resent-Date: Fri, 12 Apr 2013 11:42:14 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #289: Add a forward reference to 5.9.2.9. X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 18:42:15 -0000 #289: Add a forward reference to 5.9.2.9. Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1286]: Fix #289 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: post-IESG-1 Component: coap | Version: coap-14 Severity: Submitted | Resolution: fixed WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Apr 12 11:42: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 1E58B21F8E6D for ; Fri, 12 Apr 2013 11:42:16 -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 WoHDjJeAJxK3 for ; Fri, 12 Apr 2013 11:42:15 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 84C8921F8D4E for ; Fri, 12 Apr 2013 11:42:15 -0700 (PDT) Received: from localhost ([127.0.0.1]:58853 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UQivO-0007xf-FP; Fri, 12 Apr 2013 20:42:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Fri, 12 Apr 2013 18:42:14 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/290#comment:1 Message-ID: <066.c747a67f691c6363f7208a45c6039807@trac.tools.ietf.org> References: <051.8630ff7f1a6070b30bbc5a9fa3f5c762@trac.tools.ietf.org> X-Trac-Ticket-ID: 290 In-Reply-To: <051.8630ff7f1a6070b30bbc5a9fa3f5c762@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130412184215.84C8921F8D4E@ietfa.amsl.com> Resent-Date: Fri, 12 Apr 2013 11:42:15 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #290: Mention PROCESSING_DELAY when discussion piggy-backing X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 18:42:16 -0000 #290: Mention PROCESSING_DELAY when discussion piggy-backing Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1287]: Fix #290 (actually mention PROCESSING_DELAY at the start of 5.2.2) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: post-IESG-1 Component: coap | Version: coap-14 Severity: Submitted | Resolution: fixed WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Apr 12 11:45:12 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7A321F8E7B for ; Fri, 12 Apr 2013 11:45:12 -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 d1Ya9Z7o905s for ; Fri, 12 Apr 2013 11:45:12 -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 5FD4A21F8E77 for ; Fri, 12 Apr 2013 11:45:12 -0700 (PDT) Received: from localhost ([127.0.0.1]:58981 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UQiyD-0005Cv-M6; Fri, 12 Apr 2013 20:45:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Fri, 12 Apr 2013 18:45:09 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/291#comment:1 Message-ID: <066.7d13daf1f5d9185b7cdda6da3ed509bb@trac.tools.ietf.org> References: <051.27446f5e2a73746d614b61ea97a6956a@trac.tools.ietf.org> X-Trac-Ticket-ID: 291 In-Reply-To: <051.27446f5e2a73746d614b61ea97a6956a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130412184512.5FD4A21F8E77@ietfa.amsl.com> Resent-Date: Fri, 12 Apr 2013 11:45:12 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #291: 8 kbit/s is not "conservative" X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 18:45:13 -0000 #291: 8 kbit/s is not "conservative" Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1288]: Fix #291 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: post-IESG-1 Component: coap | Version: coap-14 Severity: Submitted | Resolution: fixed WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Apr 12 12:25: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 E6EDC21F8F03 for ; Fri, 12 Apr 2013 12:25: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=[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 ZQzz4k5sENXf for ; Fri, 12 Apr 2013 12:25: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 4138621F8F02 for ; Fri, 12 Apr 2013 12:25:01 -0700 (PDT) Received: from localhost ([127.0.0.1]:60992 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UQjal-0007oB-Vc; Fri, 12 Apr 2013 21:24:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Fri, 12 Apr 2013 19:24:59 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/293#comment:1 Message-ID: <066.2a9ab130ed33aeb09b599091899065bf@trac.tools.ietf.org> References: <051.8015ecb64e1448e0da80b116b104e0a0@trac.tools.ietf.org> X-Trac-Ticket-ID: 293 In-Reply-To: <051.8015ecb64e1448e0da80b116b104e0a0@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130412192501.4138621F8F02@ietfa.amsl.com> Resent-Date: Fri, 12 Apr 2013 12:25:01 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #293: Add description of DoS attack on congestion control X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 19:25:02 -0000 #293: Add description of DoS attack on congestion control Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1289]: Add a paragraph about resource depletion attacks, fix #292 and fix #293 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: other | Status: closed technical | Milestone: post-IESG-1 Priority: minor | Version: coap-14 Component: coap | Resolution: fixed Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Fri Apr 12 12:25: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 110FD21F8F10 for ; Fri, 12 Apr 2013 12:25: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=[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 awWJPryNJoDz for ; Fri, 12 Apr 2013 12:25: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 4114321F8F01 for ; Fri, 12 Apr 2013 12:25:01 -0700 (PDT) Received: from localhost ([127.0.0.1]:60991 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UQjal-0007nP-Ug; Fri, 12 Apr 2013 21:24:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Fri, 12 Apr 2013 19:24:59 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/292#comment:1 Message-ID: <066.0dbdf77dd28f8326e62617226fa713cc@trac.tools.ietf.org> References: <051.7035f63909d2440b2c6af2888f76f7b2@trac.tools.ietf.org> X-Trac-Ticket-ID: 292 In-Reply-To: <051.7035f63909d2440b2c6af2888f76f7b2@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130412192501.4114321F8F01@ietfa.amsl.com> Resent-Date: Fri, 12 Apr 2013 12:25:01 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #292: Add description of resource depletion attack X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 19:25:02 -0000 #292: Add description of resource depletion attack Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1289]: Add a paragraph about resource depletion attacks, fix #292 and fix #293 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: other | Status: closed technical | Milestone: post-IESG-1 Priority: minor | Version: coap-14 Component: coap | Resolution: fixed Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun Apr 14 06:41:24 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C9B21F9058 for ; Sun, 14 Apr 2013 06:41:24 -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 fLtLtQycHxAq for ; Sun, 14 Apr 2013 06:41:24 -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 1B5CA21F902C for ; Sun, 14 Apr 2013 06:41:24 -0700 (PDT) Received: from localhost ([127.0.0.1]:58225 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1URNBF-0002WK-FV; Sun, 14 Apr 2013 15:41:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Sun, 14 Apr 2013 13:41:17 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/294#comment:1 Message-ID: <066.f960019596c5bb36fcbcffaeb8f3f1ab@trac.tools.ietf.org> References: <051.07b994a18d06121dc7a48fa336ed1618@trac.tools.ietf.org> X-Trac-Ticket-ID: 294 In-Reply-To: <051.07b994a18d06121dc7a48fa336ed1618@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130414134124.1B5CA21F902C@ietfa.amsl.com> Resent-Date: Sun, 14 Apr 2013 06:41:24 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #294: Add discussion of using non-trivial token for protecting against hijacking X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 13:41:25 -0000 #294: Add discussion of using non-trivial token for protecting against hijacking Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1290]: Fix #294 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: other | Status: closed technical | Milestone: post-IESG-1 Priority: minor | Version: coap-14 Component: coap | Resolution: fixed Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun Apr 14 07:03:41 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8F721F90B1 for ; Sun, 14 Apr 2013 07:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm1PyqJzFDUN for ; Sun, 14 Apr 2013 07:03:41 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id EE63B21F9079 for ; Sun, 14 Apr 2013 07:03:40 -0700 (PDT) Received: from localhost ([127.0.0.1]:59463 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1URNWo-0005Ez-5u; Sun, 14 Apr 2013 16:03:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Sun, 14 Apr 2013 14:03:34 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/282#comment:1 Message-ID: <066.4b7544a3ba8a6dc79288dccd563796bd@trac.tools.ietf.org> References: <051.558fd96867c8d6d9cae2b6e05f651e00@trac.tools.ietf.org> X-Trac-Ticket-ID: 282 In-Reply-To: <051.558fd96867c8d6d9cae2b6e05f651e00@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130414140340.EE63B21F9079@ietfa.amsl.com> Resent-Date: Sun, 14 Apr 2013 07:03:40 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #282: Clarify bytes/characters and UTF-8/ASCII in "Decomposing URIs into Options" X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 14:03:41 -0000 #282: Clarify bytes/characters and UTF-8/ASCII in "Decomposing URIs into Options" Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1291]: Fix #282 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: post-IESG-1 Component: coap | Version: coap-14 Severity: Submitted | Resolution: fixed WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun Apr 14 07:13:42 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A911E21F8FE9 for ; Sun, 14 Apr 2013 07:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 Obat41FvLGcE for ; Sun, 14 Apr 2013 07:13:42 -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 EA0F621F902A for ; Sun, 14 Apr 2013 07:13:41 -0700 (PDT) Received: from localhost ([127.0.0.1]:59673 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1URNgZ-00060S-Do; Sun, 14 Apr 2013 16:13:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Sun, 14 Apr 2013 14:13:39 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/283#comment:1 Message-ID: <066.f27371eeaf03ec076efd7455999742ed@trac.tools.ietf.org> References: <051.4ccb4c7e9cf7151395cf395b5810c6ec@trac.tools.ietf.org> X-Trac-Ticket-ID: 283 In-Reply-To: <051.4ccb4c7e9cf7151395cf395b5810c6ec@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130414141341.EA0F621F902A@ietfa.amsl.com> Resent-Date: Sun, 14 Apr 2013 07:13:41 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #283: Servers vs. Service Discovery X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 14:13:42 -0000 #283: Servers vs. Service Discovery Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1292]: Fix #283 (clarify the use of the noun "service", in particular for section 7.1). -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: post-IESG-1 Component: coap | Version: coap-14 Severity: Submitted | Resolution: fixed WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From internet-drafts@ietf.org Sun Apr 14 07:55:43 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B2B21F9123; Sun, 14 Apr 2013 07:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.122, 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 qqh-hLyFEmqb; Sun, 14 Apr 2013 07:55:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C4021F912C; Sun, 14 Apr 2013 07:55:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130414145542.670.84446.idtracker@ietfa.amsl.com> Date: Sun, 14 Apr 2013 07:55:42 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-15.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 14:55:43 -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-15.txt Pages : 112 Date : 2013-04-14 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-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-coap-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Apr 14 07:55:43 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7203821F9123 for ; Sun, 14 Apr 2013 07:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.120, 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 NFOYL3HyGgt3; Sun, 14 Apr 2013 07:55:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F00A21F911C; Sun, 14 Apr 2013 07:55:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: core-chairs@tools.ietf.org, draft-ietf-core-coap@tools.ietf.org, core@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130414145542.670.26428.idtracker@ietfa.amsl.com> Date: Sun, 14 Apr 2013 07:55:42 -0700 Subject: [core] New Version Notification - draft-ietf-core-coap-15.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 14:55:43 -0000 A new version (-15) has been submitted for draft-ietf-core-coap: http://www.ietf.org/internet-drafts/draft-ietf-core-coap-15.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-coap-15 IETF Secretariat. From cabo@tzi.org Sun Apr 14 08:02:47 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C6521F84D1 for ; Sun, 14 Apr 2013 08:02:47 -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 E-06i04zM-v4 for ; Sun, 14 Apr 2013 08:02:47 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A532C21F84CC for ; Sun, 14 Apr 2013 08:02:46 -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 r3EF2iEM017832 for ; Sun, 14 Apr 2013 17:02:44 +0200 (CEST) Received: from [192.168.217.135] (p54893C48.dip.t-dialin.net [84.137.60.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DA21534A5; Sun, 14 Apr 2013 17:02:43 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Carsten Bormann Date: Sun, 14 Apr 2013 17:02:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <291E0253-EC24-4782-8E78-90475C9CFE57@tzi.org> References: <20130414145542.670.39614.idtracker@ietfa.amsl.com> To: "core@ietf.org (core@ietf.org)" X-Mailer: Apple Mail (2.1503) Subject: [core] core-coap updated to -15 based on IETF last-call comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 14 Apr 2013 15:02:47 -0000 I have updated draft-ietf-core-coap based on the IETF last-call = comments. All tickets on that draft are now closed. The changes are welcome clarifications (thanks to the many reviewers!). There should be no impact on implementations. On with the process... As I mentioned in = http://www.ietf.org/mail-archive/web/core/current/msg04174.html, = comments by IESG members should soon be trickling in. > Status: http://datatracker.ietf.org/doc/draft-ietf-core-coap > Htmlized: http://tools.ietf.org/html/draft-ietf-core-coap-15 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-coap-15 Gr=FC=DFe, Carsten From Akbar.Rahman@InterDigital.com Sun Apr 14 15:53: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 18A0721F8E5E for ; Sun, 14 Apr 2013 15:53:32 -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 k7zTbEj2E117 for ; Sun, 14 Apr 2013 15:53:31 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5088421F8E47 for ; Sun, 14 Apr 2013 15:53:31 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 14 Apr 2013 18:53:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 14 Apr 2013 18:53:19 -0400 Message-ID: In-Reply-To: <20130412124959.22556.94358.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] I-D Action: draft-ietf-core-groupcomm-06.txt Thread-Index: Ac43fFtTy28Sf+JURZ2ozdTXujLKNQB5eODQ References: <20130412124959.22556.94358.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: "Carsten Bormann" , X-OriginalArrivalTime: 14 Apr 2013 22:53:30.0401 (UTC) FILETIME=[E2258110:01CE3962] Cc: core@ietf.org Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-06.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: Sun, 14 Apr 2013 22:53:32 -0000 Hi Carsten/Andrew, As per the direction from the last IETF in Orlando, Esko and I have updated the Groupcomm I-D as listed below. Please advise us on the next steps. Sincerely, Akbar & Esko, =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D Changes from ietf-05 to ietf-06: o Added a new section on commissioning flow when using discovery services when end devices discover in which multicast group they are allocated (#295). o Added a new section on CoAP Proxy Operation (section 3.9) that outlines the potential issues and limitations of doing CoAP multicast requests via a CoAP Proxy (#274). o Added use case of multicasting controller on the backbone (#279). o Use cases were updated to show only a single CoAP RD (to replace the previous multiple RDs with one in each subnet). This is a more efficient deployment and also avoids RD specific issues such as synchronization of RD information between serves (#280). o Added text to section 3.6 (Configuring Group Membership in Endpoints) that clarified that any (unicast) operation to change an endpoint's group membership must use DTLS-secured CoAP. o Clarified relationship of this document to [I-D.ietf-core-coap] in section 2.2 (Scope). o Removed IPSec related requirement, as IPSec is not part of [I-D.ietf-core-coap] anymore. o Editorial reordering of subsections in section 3 to have a better flow of topics. Also renamed some of the (sub)sections to better reflect their content. Finally, moved the URI Configuration text to the same section as the Port Configuration section as it was a more natural grouping (now in section 3.3) . o Editorial rewording of section 3.7 (Multicast Request Acceptance and Response Suppression) to make the logic easier to comprehend (parse). o Various editorial updates for improved readability. -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Friday, April 12, 2013 8:50 AM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-06.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-06.txt Pages : 33 Date : 2013-04-12 Abstract: CoAP is a RESTful transfer protocol for constrained devices and networks. It is anticipated that constrained devices will often naturally operate in groups (e.g. in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document provides guidance for how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed for both constrained and un-constrained networks. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From stokcons@xs4all.nl Sun Apr 14 23:51:46 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF6F21F92BD for ; Sun, 14 Apr 2013 23:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.095 X-Spam-Level: ** X-Spam-Status: No, score=2.095 tagged_above=-999 required=5 tests=[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 uNAiuTnPRoIh for ; Sun, 14 Apr 2013 23:51:46 -0700 (PDT) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by ietfa.amsl.com (Postfix) with ESMTP id A182621F92F4 for ; Sun, 14 Apr 2013 23:51:40 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube6.xs4all.net [194.109.20.204]) by smtp-vbr7.xs4all.nl (8.13.8/8.13.8) with ESMTP id r3F6paJU052282; Mon, 15 Apr 2013 08:51:37 +0200 (CEST) (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, 15 Apr 2013 08:51:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 15 Apr 2013 08:51:36 +0200 From: peter van der Stok To: "Dijk, Esko" Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: <031DD135F9160444ABBE3B0C36CED618C04EB3@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <0C9867A6-AED5-4063-88AE-E9D1C6CDE75E@tzi.org> <031DD135F9160444ABBE3B0C36CED618C04EB3@011-DB3MPN2-083.MGDPHG.emi.philips.com> Message-ID: <132080d17026f995dc2ea53e38c7627b@xs4all.nl> X-Sender: stokcons@xs4all.nl (gD1C+yZclf5O18pAkJUF0+hSHdDFTrFQ) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Cc: 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 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, 15 Apr 2013 06:51:47 -0000 Hi Esko, So it is indeed a small change to handle the coap-http case as well and does not warrant a different document. Peter Dijk, Esko schreef op 2013-04-12 09:06: > Hi Peter, > > Forgot to mention about the case CoAP-HTTP: another reason the > authors did not pursue this was that a CoAP client can simply use the > CoAP forward proxying functionality (i.e. a CoAP request with a > Proxy-URI option or Proxy-Scheme option containing a http:// URI) to > access HTTP servers. > > Esko > > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf > Of peter van der Stok > Sent: Tuesday, April 09, 2013 10:46 > To: core@ietf.org > Subject: Re: [core] Call for reviews of > draft-castellani-core-http-mapping > > Dear wg, > > Review of draft-castellani-core-http-mapping, including coap-14 > section 10. > > For me text and objective have become clearer compared to earlier > versions. > The objective of the document to describe proxies such that proxies > from different manufacturers can be exchanged is a valid motivation > for the document. > > My first concern is the uri naming convention and proxy definition. > Concerning proxy definition: > I am happy with the explanation of forward, cross and reverse proxy, > it clarifies the bit opaque text of coap-14. However, it does not help > me much because the cullen example of > I-D.bormann-core-cross-reverse-convention is presented as reverse > proxy example while the text in castellani made me think it is a > forward proxy example, because the client seems to be aware that > translation takes place. There still seems to be a gap in my > understanding from purely reading the texts. > Concerning naming convention: > The document does not help much in restricting the URI naming > conventions. I would expect one of two things: > 1) Strict guidelines how to translate uris (restrict the number > of > possibilities) > 2) Provide means to define the uri translation on the proxy. > I do not see any other way of making sure that proxies of different > manufacturers can be exchanged. > > My second concern is that the document only treats http-coap > translation. The case coap-http seems more urgent. We do not want to > provide the small devices with a http/tcp code next to the coap/udp > code, while these devices will need to talk to “legacy” http back-end > servers. Suggestion: add the coap-http part. > > Individual nits and suggestions. > Page 6, section 5, all 2, line 5…….explicitly indicates THAT it > targets …… (that forgotten?) Section 5, all 3, unicast http to > multicast coap is a completely different document (remove the > currently in the “currently out of scope”. Wouldn’t you discourage the > unicast to multicast aspect in a standardized proxy? > Section 5.1 caching: add “given” to …. all request traffic to a given > COAP server……. > Sec 5.1 Multicast; possibly the wrong reason for a valid efficiency > argument: to connect a proxy interface to the mesh network. > Sec 5.1 TCP/UDP: I do not see the placement aspect here Sec 5.2 > Notes. Do you not need to give formulas? For example in note 8, the > determination of max-age value Sec 5.4 how to configure the limit and > queuing/dropping behavior? The document should specify an interface. > Sec 5.5 and 5.6 I like the effort to specify limits of behaviors. > Sec 7. I understand that a proxy represents the typical “man in the > middle” threat. Having it securely connected to the network before any > access and a regular reconnection may have a positive effect. > > hope this helps, > > peter > > Carsten Bormann schreef op 2013-03-24 23:33: >> 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 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > ________________________________ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original > message. From esko.dijk@philips.com Mon Apr 15 01:32: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 AB34A21F8700 for ; Mon, 15 Apr 2013 01:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOxfQNBEtpy4 for ; Mon, 15 Apr 2013 01:32:36 -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 A6C5721F848D for ; Mon, 15 Apr 2013 01:32:34 -0700 (PDT) Received: from mail54-db8-R.bigfish.com (10.174.8.254) by DB8EHSOBE034.bigfish.com (10.174.4.97) with Microsoft SMTP Server id 14.1.225.23; Mon, 15 Apr 2013 08:32:33 +0000 Received: from mail54-db8 (localhost [127.0.0.1]) by mail54-db8-R.bigfish.com (Postfix) with ESMTP id EFD35DC01B0; Mon, 15 Apr 2013 08:32:32 +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: -31 X-BigFish: VPS-31(zz15d6O9251J542Id799h217bIzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail54-db8 (localhost.localdomain [127.0.0.1]) by mail54-db8 (MessageSwitch) id 1366014751341461_468; Mon, 15 Apr 2013 08:32:31 +0000 (UTC) Received: from DB8EHSMHS001.bigfish.com (unknown [10.174.8.231]) by mail54-db8.bigfish.com (Postfix) with ESMTP id 46A54C80045; Mon, 15 Apr 2013 08:32:31 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB8EHSMHS001.bigfish.com (10.174.4.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 15 Apr 2013 08:32:30 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.176]) by 011-DB3MMR1-011.MGDPHG.emi.philips.com ([10.128.28.50]) with mapi id 14.02.0328.011; Mon, 15 Apr 2013 08:32:30 +0000 From: "Dijk, Esko" To: Pierre DAVID , "core@ietf.org" Thread-Topic: [core] Message ID in draft-ietf-core-coap-14.txt Thread-Index: AQHON3a6DwAFqDGo4k6HO/p86P4zVJjW9wYw Date: Mon, 15 Apr 2013 08:32:30 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C0C5F4@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <20130412121017.GA26159@vagabond.ma.maison> In-Reply-To: <20130412121017.GA26159@vagabond.ma.maison> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] Message ID in 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: Mon, 15 Apr 2013 08:32:36 -0000 > If I generate Message IDs per *destination address*, how do I deal with b= roadcast/multicast addresses? It can generate collisions on Message IDs. I think the same problem could occur if a CoAP client N sends a unicast to = A's global IPv6 address and also another unicast to A's link-local address,= using two different message ID variables. (Where the client might 'think' that these two requests go to different CoA= P servers). Solutions may be up to the implementations? In that case we may need to put= a warning in the text about this (potential) problem. Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Pie= rre DAVID Sent: Friday, April 12, 2013 14:10 To: core@ietf.org Subject: [core] Message ID in draft-ietf-core-coap-14.txt Hi, in draft-ietf-core-coap-14.txt, section 4.4 (Message Correlation), I have a= problem regarding the implementation note for Message ID generation. It is said: Endpoints dealing with large numbers of transactions could keep multiple Message ID variables, for example per prefix or destination address If I generate Message IDs per *destination address*, how do I deal with bro= adcast/multicast addresses? It can generate collisions on Message IDs. Let's take the case where I have (say on node N): - an ID generator for unicast address A - an ID generator for broadcast or multicast address B The node A may thus = receive the same message ID (with a low probability) for a unicast message = from N to A and for a broadcast/multicast message from N. In my opinion, the Message ID can not be generated by destination address n= or by prefix. Have I missed something? Pierre David _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From cabo@tzi.org Mon Apr 15 01:39:11 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5C521F8928 for ; Mon, 15 Apr 2013 01:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.150, 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 ZWizLl7SRAPp for ; Mon, 15 Apr 2013 01:39:11 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id DEE8A21F84CD for ; Mon, 15 Apr 2013 01:39:10 -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 r3F8d80V006450; Mon, 15 Apr 2013 10:39:08 +0200 (CEST) Received: from [192.168.217.105] (p54893C48.dip.t-dialin.net [84.137.60.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8111D375D; Mon, 15 Apr 2013 10:39:08 +0200 (CEST) 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: <031DD135F9160444ABBE3B0C36CED618C0C5F4@011-DB3MPN2-083.MGDPHG.emi.philips.com> Date: Mon, 15 Apr 2013 10:39:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <72A31E2A-8622-438B-B8AB-4D9F8B933DD2@tzi.org> References: <20130412121017.GA26159@vagabond.ma.maison> <031DD135F9160444ABBE3B0C36CED618C0C5F4@011-DB3MPN2-083.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1503) Cc: "core@ietf.org" Subject: Re: [core] Message ID in 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: Mon, 15 Apr 2013 08:39:11 -0000 On Apr 15, 2013, at 10:32, "Dijk, Esko" wrote: >> If I generate Message IDs per *destination address*, how do I deal = with broadcast/multicast addresses? It can generate collisions on = Message IDs. > I think the same problem could occur if a CoAP client N sends a = unicast to A's global IPv6 address and also another unicast to A's = link-local address, using two different message ID variables. > (Where the client might 'think' that these two requests go to = different CoAP servers). Well, A wouldn't know how to send anything back then? What source = address should be on the return message? In a 3542-challenged environment, you have to have a socket per each of = your endpoint addresses, bound to that address only. (See section 6.2 of RFC 3542 for how to do this in a modern = environment.) If that worked well enough for multicast, too, there wouldn't be a = problem. Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Mon Apr 15 09:58: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 B642221F9613 for ; Mon, 15 Apr 2013 09:58: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 iL9Mq-b8escb for ; Mon, 15 Apr 2013 09:58: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 7879D21F95EC for ; Mon, 15 Apr 2013 09:58:56 -0700 (PDT) Received: from localhost ([127.0.0.1]:49409 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1URmk2-0002SD-Mf; Mon, 15 Apr 2013 18:58:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 15 Apr 2013 16:58:54 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/297 Message-ID: <051.0e4ca2554c29ad6839a19ea85f54051a@trac.tools.ietf.org> X-Trac-Ticket-ID: 297 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130415165856.7879D21F95EC@ietfa.amsl.com> Resent-Date: Mon, 15 Apr 2013 09:58:56 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #297: Informative refs in core-coap: groupcomm X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:58:57 -0000 #297: Informative refs in core-coap: groupcomm Esko Dijk notes (msg04215msg04216): Section 8 (a lack of reference to the groupcomm draft for refining the multicast discussion that is in the spec.) Mailing list discussion leads to the following changes (msg04215, msg04216): 1) add a sentence of the form »A more general discussion of group communication with CoAP is in [I-D .ietf-core-groupcomm].« at the end of the first paragraph of section 8. 2) add in core-coap section 8.2 in the first paragraph, in the sentence between the brackets: (For example, in [RFC6690] query filtering, a server should not respond to a multicast request if the filter does not match. »More examples are in [I-D.ietf-core-groupcomm].«) 3) insert a reference to groupcomm before the reference to coap-misc in 8.2.2: »Proxying multicast requests is discussed in more detail in [I-D.ietf- core-groupcomm];« a proposal to address the base URI issue can be found in section 3 of [I-D.bormann-coap-misc]. These editorial changes were agreed on the mailing list but missed for -15. They will be retrofitted in -16. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-15 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From kovatsch@inf.ethz.ch Tue Apr 16 08:36:43 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8716821F9768 for ; Tue, 16 Apr 2013 08:36:43 -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 yJm56G9kQsWS for ; Tue, 16 Apr 2013 08:36:43 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA6021F9765 for ; Tue, 16 Apr 2013 08:36:36 -0700 (PDT) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 16 Apr 2013 17:36:20 +0200 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.02.0298.004; Tue, 16 Apr 2013 17:36:23 +0200 From: "Kovatsch Matthias" To: "core@ietf.org" Thread-Topic: Small discrepancy about 2.02 Delete Thread-Index: Ac46t+RLkUPD40czQmaDjnmwYSKw9g== Date: Tue, 16 Apr 2013 15:36:23 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514E8302E@MBX10.d.ethz.ch> Accept-Language: en-US, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [77.57.171.155] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [core] Small discrepancy about 2.02 Delete X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 16 Apr 2013 15:36:43 -0000 Hi There is a small discrepancy in the definition of 2.02 Deleted: In 5.8.2. POST it says: "If the POST succeeds and results in the target resource being deleted, the= response SHOULD have a 2.02 (Deleted) response code." However, in 5.9.1.2. 2.02 Deleted it says: "Like HTTP 204 "No Content", but only used in response to DELETE requests." Should this be fixed to "in response to POST and DELETE requests"? Ciao Matthias From sakane@tanu.org Wed Apr 17 02:45: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 9052221F8DB2 for ; Wed, 17 Apr 2013 02:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.777 X-Spam-Level: * X-Spam-Status: No, score=1.777 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_JP=1.265, MANGLED_CIALIS=2.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crWvemuBn3AQ for ; Wed, 17 Apr 2013 02:45:00 -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 9725921F8DB4 for ; Wed, 17 Apr 2013 02:44:56 -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 7461616B4C; Wed, 17 Apr 2013 18:44:54 +0900 (JST) Message-ID: <516E6F15.2050907@tanu.org> Date: Wed, 17 Apr 2013 18:44:53 +0900 From: Shoichi Sakane User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Klaus Hartke Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: [core] observe and message id X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 Apr 2013 09:45:01 -0000 Hi Hartke, Question and suggestion about the Observe. > Appendix A. Examples > > Observed CLIENT SERVER Actual > t State | | State > ____________ | | ____________ > 1 | | > 2 unknown | | 18.5 C > 3 +----->| Header: GET 0x41011633 > 4 | GET | Token: 0x4a > 5 | | Uri-Path: temperature > 6 | | Observe: (empty) > 7 | | > 8 | | > 9 ____________ |<-----+ Header: 2.05 0x61451633 > 10 | 2.05 | Token: 0x4a > 11 18.5 C | | Observe: 9 > 12 | | Max-Age: 15 > 13 | | Payload: "18.5 C" > 14 | | > 15 | | ____________ > 16 ____________ |<-----+ Header: 2.05 0x51457b50 > 17 | 2.05 | 19.2 C Token: 0x4a > 18 19.2 C | | Observe: 16 > 29 | | Max-Age: 15 > 20 | | Payload: "19.2 C" > 21 | | Could you clarify how to deal with the Message ID in the draft ? I imagine that the Message ID in the 1st response from the server is just echoed by the server and must be different from the 2nd one that is initiated by the server. I think it's better for a reader to show how Message ID handling by both server and client. It might be enough to refer the text in the core draft. And, for implementers, the draft should have at least one complete flow from the start to the end of an observation with type and message id, like the core coap draft has the one. > 3.6. Cancellation > > When a client rejects a confirmable notification with a Reset message > or when it issues a GET request without an Observe Option for a > currently observed resource, the server will remove the client from > the list of observers of this resource. The client MAY use either > method to indicate that it is no longer interested in receiving > further notifications for the resource until it eventually registers > again. In the 2nd way, the server not only remove the client in the list, but also send the final resource state to the client ? It is mentioned in the figure 6 at Appendix A. However, the body in the draft should describe it. Shoichi From cabo@tzi.org Wed Apr 17 03:05:08 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377C121F8BC7 for ; Wed, 17 Apr 2013 03:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.924 X-Spam-Level: X-Spam-Status: No, score=-104.924 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_CIALIS=2.5, 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 Q3Ig3KgP-CgS for ; Wed, 17 Apr 2013 03:05:07 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id AB3C421F8C08 for ; Wed, 17 Apr 2013 03:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r3HA4wWj013666; Wed, 17 Apr 2013 12:04:58 +0200 (CEST) Received: from [192.168.217.105] (p54892D04.dip.t-dialin.net [84.137.45.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 86CAF375A; Wed, 17 Apr 2013 12:04:58 +0200 (CEST) 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: <516E6F15.2050907@tanu.org> Date: Wed, 17 Apr 2013 12:04:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <447D07DA-2712-43B7-AA76-8410F3C92536@tzi.org> References: <516E6F15.2050907@tanu.org> To: Shoichi Sakane X-Mailer: Apple Mail (2.1503) Cc: core@ietf.org, Klaus Hartke Subject: Re: [core] observe and message id X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 Apr 2013 10:05:08 -0000 Hi Shoichi, I think Klaus is in transit right now, so let me try a quick reply. On Apr 17, 2013, at 11:44, Shoichi Sakane wrote: > Hi Hartke, >=20 > Question and suggestion about the Observe. >=20 >> Appendix A. Examples >>=20 >> Observed CLIENT SERVER Actual >> t State | | State >> ____________ | | ____________ >> 1 | | >> 2 unknown | | 18.5 C >> 3 +----->| Header: GET = 0x41011633 >> 4 | GET | Token: 0x4a >> 5 | | Uri-Path: temperature >> 6 | | Observe: (empty) >> 7 | | >> 8 | | >> 9 ____________ |<-----+ Header: 2.05 = 0x61451633 >> 10 | 2.05 | Token: 0x4a >> 11 18.5 C | | Observe: 9 >> 12 | | Max-Age: 15 >> 13 | | Payload: "18.5 C" >> 14 | | >> 15 | | ____________ >> 16 ____________ |<-----+ Header: 2.05 = 0x51457b50 >> 17 | 2.05 | 19.2 C Token: 0x4a >> 18 19.2 C | | Observe: 16 >> 29 | | Max-Age: 15 >> 20 | | Payload: "19.2 C" >> 21 | | >=20 > Could you clarify how to deal with the Message ID in the draft ? > I imagine that the Message ID in the 1st response from the server > is just echoed by the server Yes. The first 2.05 is an ACK (this isn't very apparent from the = example; you have to decode the hexadecimal header to see that -- 0x6.. = & 0x3.. =3D=3D 0x2..., 2=3DACK.). An ACK echoes the message-ID of the CON that solicited it. > and must be different from the 2nd > one that is initiated by the server. No. The second 2.05 is a NON (again, you have to look at the hex -- = 0x5.. & 0x3.. =3D=3D 0x1..., 1=3DNON.). So it uses the message-ID space of the server, not that of the client. (The message-ID therefore *could* happen to be the same, but the = likelihood is 2**-16.) > I think it's better for a reader to show how Message ID handling > by both server and client. It might be enough to refer the text > in the core draft.=20 I think Klaus tried to focus the example on the observe-specific = aspects. Showing everything at once can be quite confusing. But maybe we can find a way. > And, for implementers, the draft should have at least one complete > flow from the start to the end of an observation with type and > message id, like the core coap draft has the one. Good idea. >> 3.6. Cancellation >>=20 >> When a client rejects a confirmable notification with a Reset = message >> or when it issues a GET request without an Observe Option for a >> currently observed resource, the server will remove the client from >> the list of observers of this resource. The client MAY use either >> method to indicate that it is no longer interested in receiving >> further notifications for the resource until it eventually = registers >> again. >=20 > In the 2nd way, the server not only remove the client in the list, > but also send the final resource state to the client ? > It is mentioned in the figure 6 at Appendix A. However, the body > in the draft should describe it. Yes. The text, again, focuses on what's specific to observe, but it = indeed has to guard against the common misunderstanding "expressio unius = est exclusio alterius" (which is making lawyers a lot of money, but = isn't true in protocol specifications). (Looking at this specific paragraph, there is also #258/#281; I think it = is easy to fix both these tickets but there is an underlying cognitive = dissonance with the fact that a GET without Observe is influencing = existing observation relationships. This is one of the things we have = to nail down (i.e., change to something better or agree to accept as is) = before finishing -observe.) Gr=FC=DFe, Carsten From cabo@tzi.org Wed Apr 17 08:52: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 558F621F86BA for ; Wed, 17 Apr 2013 08:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suNbCCNcdVUY for ; Wed, 17 Apr 2013 08:52:56 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8F93B21F8682 for ; Wed, 17 Apr 2013 08:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r3HFqnub020838; Wed, 17 Apr 2013 17:52:49 +0200 (CEST) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7A05B3A97; Wed, 17 Apr 2013 17:52:49 +0200 (CEST) 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: <55877B3AFB359744BA0F2140E36F52B514E8302E@MBX10.d.ethz.ch> Date: Wed, 17 Apr 2013 17:52:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <01F9F976-5C2D-4BC1-94A1-E80B74A22316@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514E8302E@MBX10.d.ethz.ch> To: Kovatsch Matthias X-Mailer: Apple Mail (2.1503) Cc: "core@ietf.org" Subject: Re: [core] Small discrepancy about 2.02 Delete X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 Apr 2013 15:52:57 -0000 On Apr 16, 2013, at 17:36, Kovatsch Matthias = wrote: > Hi >=20 > There is a small discrepancy in the definition of 2.02 Deleted: >=20 > In 5.8.2. POST it says: > "If the POST succeeds and results in the target resource being = deleted, the response SHOULD have a 2.02 (Deleted) response code." >=20 > However, in 5.9.1.2. 2.02 Deleted it says: > "Like HTTP 204 "No Content", but only used in response to DELETE = requests." Obvious bug. Clearly, 5.9.1.2 needs to be fixed, because the language = in 5.8.2 is there intentionally (#105, listed in the changes from -04 to = -05). > Should this be fixed to "in response to POST and DELETE requests"? That would be the simplest fix. Maybe more future proof: "in response to requests that cause the = resource to cease being available, such as DELETE and in certain = circumstances POST". Since we are in IESG processing now, I'll do this by the book and open a = ticket. Gr=FC=DFe, Carsten From ietf-secretariat-reply@ietf.org Wed Apr 17 08:57:11 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7097721E8054 for ; Wed, 17 Apr 2013 08:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.048, 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 YKtL-J51GscU; Wed, 17 Apr 2013 08:57:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B9421E8047; Wed, 17 Apr 2013 08:57:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: core-chairs@tools.ietf.org, draft-ietf-core-coap@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130417155710.16352.73632.idtracker@ietfa.amsl.com> Date: Wed, 17 Apr 2013 08:57:10 -0700 From: IETF Secretariat Subject: [core] ID Tracker State Update Notice: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 Apr 2013 15:57:11 -0000 State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-coap/ From trac+core@trac.tools.ietf.org Thu Apr 18 03:47:41 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B6421F8EBF for ; Thu, 18 Apr 2013 03:47:41 -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 nCGsQOpgCWhg for ; Thu, 18 Apr 2013 03:47:41 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 29D5821F8E8F for ; Thu, 18 Apr 2013 03:47:41 -0700 (PDT) Received: from localhost ([127.0.0.1]:58967 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1USmNP-00038p-PQ; Thu, 18 Apr 2013 12:47:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Thu, 18 Apr 2013 10:47:39 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/298 Message-ID: <051.7fe60c62187d4c88b101bc8b9262e08a@trac.tools.ietf.org> X-Trac-Ticket-ID: 298 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130418104741.29D5821F8E8F@ietfa.amsl.com> Resent-Date: Thu, 18 Apr 2013 03:47:41 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #298: Small discrepancy about 2.02 Delete X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 10:47:41 -0000 #298: Small discrepancy about 2.02 Delete Matthias Kovatsch notes (msg04258): Section 5.8.2 There is a small discrepancy in the definition of 2.02 Deleted: In 5.8.2. POST it says: "If the POST succeeds and results in the target resource being deleted, the response SHOULD have a 2.02 (Deleted) response code." However, in 5.9.1.2. 2.02 Deleted it says: "Like HTTP 204 "No Content", but only used in response to DELETE requests." Should this be fixed to "in response to POST and DELETE requests"? Carsten says (msg04261): Obvious bug. Clearly, 5.9.1.2 needs to be fixed, because the language in 5.8.2 is there intentionally (#105, listed in the changes from -04 to -05). > Should this be fixed to "in response to POST and DELETE requests"? That would be the simplest fix. Maybe more future proof: "in response to requests that cause the resource to cease being available, such as DELETE and in certain circumstances POST". -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-15 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From kovatsch@inf.ethz.ch Fri Apr 19 02:24: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 4BDFD21F8A85 for ; Fri, 19 Apr 2013 02:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 x9AtnYjU1KR5 for ; Fri, 19 Apr 2013 02:24:28 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id CBACB21F8A0C for ; Fri, 19 Apr 2013 02:24:26 -0700 (PDT) Received: from CAS20.d.ethz.ch (172.31.51.110) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.298.4; Fri, 19 Apr 2013 11:24:19 +0200 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%10]) with mapi id 14.02.0298.004; Fri, 19 Apr 2013 11:24:24 +0200 From: "Kovatsch Matthias" To: "core@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-groupcomm-06.txt Thread-Index: AQHON3xetyyyB6vlzUqueNFPo/VPjZjdTWyw Date: Fri, 19 Apr 2013 09:24:24 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514E8C867@MBX20.d.ethz.ch> References: <20130412124959.22556.94358.idtracker@ietfa.amsl.com> In-Reply-To: <20130412124959.22556.94358.idtracker@ietfa.amsl.com> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 09:24:29 -0000 Dear list Having had a closer look at the groupcomm draft, I would like to propose to= register a proper hypermedia type for the group management protocol. We ca= ll us Constrained RESTful Environments, so we should follow the HATEOAS con= straint for the central specifications. RD for instance has application/lin= k-format for that. How about "application/groupcomm+json" for the currently proposed format? Ciao Matthias From zach@sensinode.com Sun Apr 21 11:48: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 0867021F9346 for ; Sun, 21 Apr 2013 11:48:50 -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 PjLQMbE5ntug for ; Sun, 21 Apr 2013 11:48:49 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id EF8FC21F933B for ; Sun, 21 Apr 2013 11:48:48 -0700 (PDT) Received: from [192.168.113.2] (85-23-200-242.co.dnainternet.fi [85.23.200.242]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r3LImg3P029659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 21 Apr 2013 21:48:44 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514E8C867@MBX20.d.ethz.ch> Date: Sun, 21 Apr 2013 21:48:41 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130412124959.22556.94358.idtracker@ietfa.amsl.com> <55877B3AFB359744BA0F2140E36F52B514E8C867@MBX20.d.ethz.ch> To: Kovatsch Matthias X-Mailer: Apple Mail (2.1503) Cc: "core@ietf.org" Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-06.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: Sun, 21 Apr 2013 18:48:50 -0000 Hi, On Apr 19, 2013, at 12:24 PM, Kovatsch Matthias = wrote: > Having had a closer look at the groupcomm draft, I would like to = propose to register a proper hypermedia type for the group management = protocol. We call us Constrained RESTful Environments, so we should = follow the HATEOAS constraint for the central specifications. RD for = instance has application/link-format for that. >=20 > How about "application/groupcomm+json" for the currently proposed = format? I agree, although maybe groupcomm is not all that descriptive. Would = e.g. application/coap-group+json make more sense?=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From esko.dijk@philips.com Mon Apr 22 07:54: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 1A8B221F8B65 for ; Mon, 22 Apr 2013 07:54:06 -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 mmgsycIwgJ7d for ; Mon, 22 Apr 2013 07:54:05 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4B721F8414 for ; Mon, 22 Apr 2013 07:54:04 -0700 (PDT) Received: from mail158-co1-R.bigfish.com (10.243.78.250) by CO1EHSOBE030.bigfish.com (10.243.66.95) with Microsoft SMTP Server id 14.1.225.23; Mon, 22 Apr 2013 14:54:03 +0000 Received: from mail158-co1 (localhost [127.0.0.1]) by mail158-co1-R.bigfish.com (Postfix) with ESMTP id 60C9B7001E9; Mon, 22 Apr 2013 14:54:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VPS-31(zz15d6O9251J542I217bIzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz8275dh1033ILz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail158-co1 (localhost.localdomain [127.0.0.1]) by mail158-co1 (MessageSwitch) id 1366642380530330_2475; Mon, 22 Apr 2013 14:53:00 +0000 (UTC) Received: from CO1EHSMHS028.bigfish.com (unknown [10.243.78.253]) by mail158-co1.bigfish.com (Postfix) with ESMTP id 7F78E440259; Mon, 22 Apr 2013 14:53:00 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS028.bigfish.com (10.243.66.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 22 Apr 2013 14:52:59 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.176]) by 011-DB3MMR1-009.MGDPHG.emi.philips.com ([10.128.28.48]) with mapi id 14.02.0328.011; Mon, 22 Apr 2013 14:52:48 +0000 From: "Dijk, Esko" To: "Kovatsch Matthias" , "core@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-groupcomm-06.txt Thread-Index: AQHON3xmIL4DCVtc+EGTnUynhWYw0ZjdUGMAgAUQu9A= Date: Mon, 22 Apr 2013 14:52:48 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C14BD2@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <20130412124959.22556.94358.idtracker@ietfa.amsl.com> <55877B3AFB359744BA0F2140E36F52B514E8C867@MBX20.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514E8C867@MBX20.d.ethz.ch> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.138.224.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 14:54:06 -0000 Hello Matthias, thanks for your look at the group management protocol. Could you explain pe= rhaps why a specific content type is needed for this? A client that GETs su= ch a resource presumably already knows (resource discovery) that the resour= ce type is e.g. "core.gp", so that provides already the information what th= e interpretation of the returned content exactly should be. Why would the c= ontent-format be needed, just to repeat this information - is this related = to the HATEOAS mentioned? regards, Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Kov= atsch Matthias Sent: Friday, April 19, 2013 11:24 To: core@ietf.org Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-06.txt Dear list Having had a closer look at the groupcomm draft, I would like to propose to= register a proper hypermedia type for the group management protocol. We ca= ll us Constrained RESTful Environments, so we should follow the HATEOAS con= straint for the central specifications. RD for instance has application/lin= k-format for that. How about "application/groupcomm+json" for the currently proposed format? Ciao Matthias _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From cabo@tzi.org Mon Apr 22 08:16:41 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05E921E8082 for ; Mon, 22 Apr 2013 08:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.428 X-Spam-Level: X-Spam-Status: No, score=-107.428 tagged_above=-999 required=5 tests=[AWL=-1.179, 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 hA9CCqxHDKrD for ; Mon, 22 Apr 2013 08:16:41 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D984A21E8044 for ; Mon, 22 Apr 2013 08:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r3MFGcJZ009158; Mon, 22 Apr 2013 17:16:38 +0200 (CEST) Received: from [192.168.217.105] (p5489274E.dip0.t-ipconnect.de [84.137.39.78]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4FFB731B4; Mon, 22 Apr 2013 17:16:38 +0200 (CEST) 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: <55877B3AFB359744BA0F2140E36F52B514E8C867@MBX20.d.ethz.ch> Date: Mon, 22 Apr 2013 17:16:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1D0C7346-F410-4E90-B030-7CB10D3EE55E@tzi.org> References: <20130412124959.22556.94358.idtracker@ietfa.amsl.com> <55877B3AFB359744BA0F2140E36F52B514E8C867@MBX20.d.ethz.ch> To: "Kovatsch Matthias" X-Mailer: Apple Mail (2.1503) Cc: "core@ietf.org" Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 15:16:41 -0000 On Apr 19, 2013, at 11:24, "Kovatsch Matthias" = wrote: > propose to register a proper hypermedia type Indeed. Several questions come to my (WG member) mind: -- the format has both multicast names and addresses -- which ones are = needed? What if resolution disagrees? -- a single /gp for all multicast groups may become unwieldy if multiple = groups need adds and removes -- how does the manager of one group know = what other groups the node should be in? -- removes: the current text only has a PUT replacement of the whole = group to do this. More meta: -- should we do this format in here? This may be a bit beyond what an = informational document does. On the other hand, we have a lot of informational media type = registrations. -- if we want to standardize this format, it this the right time? =20 The format would have to fit into other API-related formats, and I'm = not sure we have found our style for these yet. I'm very much for exploring this more, I'm just not sure what exactly = the outcome should be at this point. Gr=FC=DFe, Carsten From kovatsch@inf.ethz.ch Mon Apr 22 08:37: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 8D45621E8085 for ; Mon, 22 Apr 2013 08:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.854 X-Spam-Level: X-Spam-Status: No, score=-7.854 tagged_above=-999 required=5 tests=[AWL=2.744, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWsE1N6gvlmD for ; Mon, 22 Apr 2013 08:37:34 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id B67D321E805E for ; Mon, 22 Apr 2013 08:37:32 -0700 (PDT) Received: from CAS20.d.ethz.ch (172.31.51.110) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Mon, 22 Apr 2013 17:37:27 +0200 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%10]) with mapi id 14.02.0298.004; Mon, 22 Apr 2013 17:37:28 +0200 From: "Kovatsch Matthias" To: "Dijk, Esko" , "core@ietf.org" Thread-Topic: [core] I-D Action: draft-ietf-core-groupcomm-06.txt Thread-Index: AQHON3xetyyyB6vlzUqueNFPo/VPjZjdTWywgAT0MACAACRCQA== Date: Mon, 22 Apr 2013 15:37:28 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514E9AB83@MBX20.d.ethz.ch> References: <20130412124959.22556.94358.idtracker@ietfa.amsl.com> <55877B3AFB359744BA0F2140E36F52B514E8C867@MBX20.d.ethz.ch> <031DD135F9160444ABBE3B0C36CED618C14BD2@011-DB3MPN2-083.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618C14BD2@011-DB3MPN2-083.MGDPHG.emi.philips.com> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 15:37:34 -0000 > thanks for your look at the group management protocol. Could you explain > perhaps why a specific content type is needed for this? A client that GET= s > such a resource presumably already knows (resource discovery) that the > resource type is e.g. "core.gp", so that provides already the information= what > the interpretation of the returned content exactly should be. Why would t= he > content-format be needed, just to repeat this information - is this relat= ed to > the HATEOAS mentioned? Yes, in the end, the information is the same. REST says, however, that the = shared common knowledge must be stored in the media types. This is what act= ually decouples client and server, and allows clients to use services they = were not explicitly written for (unlike a hardcoded "POST x to /path/y" whi= ch is simply an RPC). Resource types are good to find an entry link to an a= pplication, but going beyond that and specifying what methods to use on whi= ch URI completely conflicts with our RESTful banner. This is an old problem= and there is a lot of discussion (e.g., http://roy.gbiv.com/untangled/2008= /rest-apis-must-be-hypertext-driven).=20 Ciao Matthias From barryleiba@gmail.com Mon Apr 22 16:04: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 A206821F91D9; Mon, 22 Apr 2013 16:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8n5ZV0wEHDP; Mon, 22 Apr 2013 16:04:52 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id 8721921F91CE; Mon, 22 Apr 2013 16:04:48 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id w10so76349lbi.23 for ; Mon, 22 Apr 2013 16:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=y9USIy1ZcS5/JypzaZKTagXWiMTJkkCO74Pe+7j+uN0=; b=AbhfWbJJwOIKuxXJUw5ht8Mvyy3JFylAnXliDnK2Z6uMFzL9htcTilAkk9fbBGGp3A AYx2sqC/RSbxvdmwbVxxdHrk6+/+Nh64w0fFlJrdEROkr5UZHDZh5lYhIwYuTtMRKYWc zt0Ft+P6hHK5mMgC5sYOSTCzPyDLDuqlWw5AgZtEKcroJjEKy8d2vm7MP3quiNquSCdw IjEpfy+yRMQSKIm6/I39LjnRnqtx2z2yWALazdzTzHiTM+t35eF57PXJMdg5+x4rmIWy pEsu5UvKsTVtpQz8Z8lLE1OjTyB1xcDAuv6s4vittq+gDAXMIcGj77/W2HotlCqXlaLj kO9g== MIME-Version: 1.0 X-Received: by 10.112.134.135 with SMTP id pk7mr14150768lbb.54.1366671887183; Mon, 22 Apr 2013 16:04:47 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.112.117.225 with HTTP; Mon, 22 Apr 2013 16:04:47 -0700 (PDT) In-Reply-To: <20130422222215.25364.10312.idtracker@ietfa.amsl.com> References: <20130422222215.25364.10312.idtracker@ietfa.amsl.com> Date: Mon, 22 Apr 2013 19:04:47 -0400 X-Google-Sender-Auth: x4n65_HtQcEQfdVnm5qa0_BJRN0 Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: multipart/alternative; boundary=089e011841d65c378004dafb18f7 Cc: "draft-ietf-core-coap@tools.ietf.org" , "core-chairs@tools.ietf.org" , The IESG , "core@ietf.org" Subject: [core] Pete Resnick's Discuss on draft-ietf-core-coap-15: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 22 Apr 2013 23:04:53 -0000 --089e011841d65c378004dafb18f7 Content-Type: text/plain; charset=ISO-8859-1 > 4.1: > > An empty message has the Code field set to 0. The Token Length field > MUST be set to 0 and no bytes MUST be present after the Message ID > field. If there are any bytes, they MUST be processed as a message > format error. ... > I find the > combination of MUSTs to be a bit problematic. MUST NOT send data, but > MUST receive as a format error ... > If it were me, I'd drop the last sentence. Indeed. Actually, I suggest this: "...bytes of data MUST NOT be present; any data bytes are considered a message format error." Barry --089e011841d65c378004dafb18f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >=A04.1:
>
>=A0 =A0An empty message has the Code field se= t to 0. =A0The Token Length field
>=A0 =A0MUST be set to 0 and no byt= es MUST be present after the Message ID
>=A0 =A0field. =A0If there are any bytes, they MUST be processed as a me= ssage
>=A0 =A0format error.
...
>=A0I find the
>=A0com= bination of MUSTs to be a bit problematic. MUST NOT send data, but
>= =A0MUST receive as a format error

...
>=A0If it were me, I'= d drop the last=A0sentence.

Indeed. =A0 Actually, I suggest thi= s:=A0"...bytes of da= ta MUST NOT=A0be present; any data bytes are considered= a message format error."

Barry
--089e011841d65c378004dafb18f7-- From chrysn@fsfe.org Mon Apr 22 17:39: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 9028B11E80E1 for ; Mon, 22 Apr 2013 17:39:36 -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 AwhwIcy4NIGm for ; Mon, 22 Apr 2013 17:39:36 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::2]) by ietfa.amsl.com (Postfix) with ESMTP id C8AF611E80BA for ; Mon, 22 Apr 2013 17:39:35 -0700 (PDT) Received: from mail.amsuess.com (unknown [IPv6:2001:15c0:6765:1:a800:ff:fe57:ab1e]) by prometheus.amsuess.com (Postfix) with ESMTPS id 591E540123; Tue, 23 Apr 2013 02:39:33 +0200 (CEST) Received: from hephaistos.amsuess.com (poseidon-stable [10.13.14.225]) by mail.amsuess.com (Postfix) with SMTP id 217AD4C143; Tue, 23 Apr 2013 02:39:32 +0200 (CEST) Received: (nullmailer pid 22519 invoked by uid 1000); Tue, 23 Apr 2013 00:39:31 -0000 Date: Tue, 23 Apr 2013 02:39:31 +0200 From: chrysn To: core@ietf.org Message-ID: <20130423003931.GB24192@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i0/AhcQY5QxfSsSZ" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [core] core-interfaces: rationale behind resource observation *attributes* X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 23 Apr 2013 00:39:36 -0000 --i0/AhcQY5QxfSsSZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hello, draft-shelby-core-interfaces-05 introduced a modification to the observation parameters, where observations that would in -4 look like this: > Req: GET Observe /s/temp?pmin=3D10&pmax=3D60&st=3D1 > Res: 2.05 Content Observe:0 (text/plain) > 23.2 would turn into this: > Req PUT /s/temp?pmin=3D10&pmax=3D60&st=3D1 > Res: 2.04 Changed >=20 > Req: GET Observe /s/temp > Res: 2.05 Content Observe:0 (text/plain) > 23.2 this seems to be a modification for the worse, for it introduces a global state on the server (which previously resided in the observe subscription that is stateful by design). if two subscribers connect, the second will overwrite the observation parameters the first configured. if the intention is that the parameters that are configured at connection time stay valid for the connection, that's still open for race conditions. what was wrong with the old solution, and why was the new one chosen to supersede the old one? best regards chrysn --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --i0/AhcQY5QxfSsSZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJRddg9AAoJEDmNERLTpL3hhQgP/RkGpqaU+AlO9iW/Dl+jcUNx 9atsI3MDcOB4RBKHLLWUSQlKWtLJTohKJUswL7NnzmkEWuTmHw0hIlvQrbkPzEaG MUdojSMXe1rK1x8a+2SobL5s4DJ0ZeZmZ27/9kteAOtyZbUugwSD0pNWj+zU+eOF b0tNLdvYzCgFshJparmI+9r1Y/TI0PKV7F3OftoZwGkYL5nw1y1fKP+IWe6baiTg 3wjIJTb+2gFjnSpDFZDIKXN37je9JD2w/VglagBFBfoh8yKv47a2nhCq0OC6yLqV izxteuYXITT+G/SiA4ZH4gS1eWe9gqI1Eb698yPZRXxDOV9DMvXdtlGdlnqehxl8 R6+R/7g764MEFH0bZkK7FlEKonwh6sWHyYFMWrdMV8/R+O5sBSBOEjAuH7hbgrqL rih9ELiCfyiuFWzMR41jP5wgO1lrc/CtCAnc8DSo6UY6DX8LDmdnJICxqTmz/nHd eqw4B3oq42wB0oqdc6OpB0jDHI+WDZnROizKNYjrqz6NSDrG8UULVpyF6Fnochur LZZtP9QtLYS9UPlhZQIvIdtzjXAVcLn3TjAtW8HjsBK+Qa236y12io6IRaLPzxVd Lwr66Bol9P2SIeBg73BF2wyptqwLDjKaP8oh4chV/057zjzuYgiLZhAQqZfy4APr nVPqMxY9VZiGkDC6AgCC =r2HP -----END PGP SIGNATURE----- --i0/AhcQY5QxfSsSZ-- From presnick@qti.qualcomm.com Mon Apr 22 15:22:37 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6C821E809C; Mon, 22 Apr 2013 15:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 5W+-SWmpflga; Mon, 22 Apr 2013 15:22:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F5D21E808D; Mon, 22 Apr 2013 15:22:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130422222215.25364.10312.idtracker@ietfa.amsl.com> Date: Mon, 22 Apr 2013 15:22:15 -0700 X-Mailman-Approved-At: Mon, 22 Apr 2013 22:23:21 -0700 Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Pete Resnick's Discuss on draft-ietf-core-coap-15: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 22 Apr 2013 22:22:37 -0000 Pete Resnick has entered the following ballot position for draft-ietf-core-coap-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The items here are very borderline in my book for DISCUSS items; I'm happy to be talked out of them. But I would like to hear from the authors and/or chairs before I give my "YES" (which is my plan once these are resolved). 4.1: An empty message has the Code field set to 0. The Token Length field MUST be set to 0 and no bytes MUST be present after the Message ID field. If there are any bytes, they MUST be processed as a message format error. = If you insist on the MUSTs, make the second one "bytes of data MUST NOT be present". The current construction is ambiguous. That said, I find the combination of MUSTs to be a bit problematic. MUST NOT send data, but MUST receive as a format error will lead to some sender saying, "A conformant receiver MUST reject with an error, so no need for me to validate on the way out" and for a receiver to say, "A conformant sender MUST NOT send data, so no need for me to validate on the way in." That's a recipe for non-interoperability. If it were me, I'd drop the last sentence. 4.3: rejecting a Non-confirmable message MAY involve sending a matching Reset message, and apart from the Reset message the rejected message MUST be silently ignored. See comment on 2.1. But if you're going to allow this, I don't understand the MAY: Doesn't rejecting the message require sending a Reset? Otherwise, the message has not been rejected; it's simply been ignored. The second part is either redundant or confusing: What else might I do with a rejected message other than send the Reset and ignore it? I think this needs rewriting. 5.2.2: It is probably worth saying somewhere in here: "Once the server sends back an empty Acknowledgement, it MUST NOT send back the response in another Acknowledgement, even if the client retransmits another identical request. If a retransmitted request is received (perhaps because the original Acknowledgement was delayed), another empty Acknowledgement is sent and any response MUST be sent as a separate response." 5.4.2: Cache-Key is undefined, here or in any other document I can find. It probably needs an explanation somewhere in this document. 5.5: Again, I don't like the combination of MUST NOT include/MUST ignore. I would drop the MUST ignore part. 5.10.4: The server SHOULD return the preferred Content-Format if available. If the preferred Content-Format cannot be returned, then a 4.06 "Not Acceptable" SHOULD be sent as a response. What are the exceptions to the above two SHOULDs? If the preferred format is available, when would a server not return it. If it's not available, when would the server return other than "Not Acceptable"? Also, since Accept is not marked as "Critical", why isn't it *always* treated as elective and therefore ignored if the server can't satisfy the request? (In other words, shouldn't you also have a "Critical Accept" option defined?) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- By section number: 1. The reference to [I-D.ietf-lwig-terminology] worries me, given that it is not even in LC yet. 2.1: When a recipient is not able to process a Non-confirmable message, it may reply with a Reset message (RST). Why is this? If a NON message can't be ACKed, why can it be RST? This seems like additional machinery for the client. 2.2: the response to a request carried in a Confirmable message is carried in the resulting Acknowledgement (ACK) message. This is called a piggy-backed response, detailed in Section 5.2.1. [...] If the server is not able to respond immediately to a request carried in a Confirmable message, it simply responds with an empty Acknowledgement message so that the client can stop retransmitting the request. When the response is ready, the server sends it in a new Confirmable message (which then in turn needs to be acknowledged by the client). It took me a bit to figure out why things worked this way, and I think a sentence or two of explanation would be useful. A piggy-backed response to a Confirmable request doesn't itself need to be confirmable because if the ACK gets lost, the client will re-transmit the request until it gets the answer. When the response to a Confirmable request is not piggy-backed, the response should itself be Confirmable, since a Confirmable request will normally want a guaranteed response. Likewise, if a request is sent in a Non-confirmable message, then the response is usually sent using a new Non-confirmable message, although the server may send a Confirmable message. "Likewise" seems wrong here. A Non-confirmable request can *not* get an Acknowledgement message, and therefore can *not* get a piggy-backed response. Additionally, the response MAY be Confirmable or MAY be Non-confirmable, though certainly Non-Confirmable is the more likely case. This should probably be reworded. 3: Token Length (TKL): 4-bit unsigned integer. Indicates the length of the variable-length Token field (0-8 bytes). Lengths 9-15 are reserved, MUST NOT be sent, and MUST be processed as a message format error. Why not make TKL a 3-bit unsigned integer and have a reserved padding bit before it? Is this protocol likely to be extended to 9-15 byte Tokens? Code: 8-bit unsigned integer. Indicates if the message carries a request (1-31) or a response (64-191), or is empty (0). = As above, why not make a 3-bit field for Code Type (000=3Drequest, 001=3Dreserved, 010=3Dsuccess response, 100=3Dclient error response, 101 =3Dserver error response, 110/111=3Dreserved), and then a 6-bit Code? It would also make the registry much easier to read. 4.2: A Confirmable message always carries either a request or response and MUST NOT be empty, unless it is used only to elicit a Reset message. = I don't understand the requirement not to be empty, especially when there is an exception at the end of the sentence. Shouldn't this be "and contains data bytes unless it is used only to elicit a Reset message."? 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). = I don't understand the second MUST: What other choice is there besides carrying a response or being empty? Aren't those the only two options? = The Reset message MUST echo the Message ID of the Confirmable message, and MUST be empty. Why MUST a Reset be empty? What harm is there if there is data in there? = Rejecting an Acknowledgement or Reset message is effected by silently ignoring it. I don't understand the above. As far as I can tell, an Acknowledgement nor a Reset can be rejected; the side that sent them will never know it is rejected. = 4.5: All of the MUSTs and MAYs in the section are used rather terribly. I'm glad to suggest text if you need. 4.6: The phrase "and (by fitting into one UDP payload) obviously MUST fit within a single IP datagram" is unnecessary, but even if you do use it, s/MUST/needs to. The MUST is not a requirement on an implementation of CoAP. That said, I fear this section is really nothing more than an implementation note: Because it is a layer violation, it's not clear to me that any implementer has the ability to figure out much of this. (For example, the idea that an implementer would be willing to -- or even know how to -- set the Do Not Fragment bit or figure out the Path MTU is a bit hopeful.) I have no objection to this section, but it might be better as an implementation note rather than a set of requirements. 5.2: I found "indicating a value of 4*32+3, hexadecimal 0x83 or decimal 131" just adds confusion rather than clarify. Perhaps instead: "even though if taken as an 8-bit unsigned, the entire Response Code field would have a value of hexadecimal 0x83 or decimal 131 (4*32+3)". But personally, I would simply drop it; it doesn't add anything. See also comments above on section 3 and below on 12.1. Also: The response codes are designed to be extensible: Response Codes in the Client Error and Server Error class that are unrecognized by an endpoint MUST be treated as being equivalent to the generic Response Code of that class (4.00 and 5.00, respectively). However, there is no generic Response Code indicating success, so a Response Code in the Success class that is unrecognized by an endpoint can only be used to determine that the request was successful without any further details. = First, I suggest changing the first sentence after the colon: "Response Code details that are unrecognized by an endpoint when the class is Client Error or Server Error are treated as equivalent to the...". Much clearer, and the MUST is wrong. Second, I don't see why you don't simply define a 2.00 so that this can be a bunch simpler. 5.2.3: Potential confusion: s/the client may send a Resent message/the client will send a Resent message 5.4.1: I don't understand the need for the third bullet. Isn't this already said in the second bullet? The fourth bullet has the same issue as 2.1 and 4.3. 5.4.4 If the option is not present, the default value MUST be assumed. Don't you really mean, "If an option is present with no value, the value is the default."? The way you have it written sounds like a completely missing option should be assumed to be present and have a default value. I don't think that's what you mean. (The MUST is just superfluous anyway.) 5.4.5: If a message includes an option with more occurrences than the option is defined for, the additional option occurrences MUST be treated like an unrecognized option (see Section 5.4.1). = I think you want to be specific about the order: If a message includes an option with more occurrences than the option is defined for, any additional option occurrences that appear subsequently in the message MUST be treated like an unrecognized option (see Section 5.4.1). That is to say, you can't choose to keep later ones and discard earlier ones. 5.4.6: If it were me, I would have put the NoCacheKey bits in the high four bits so that you could simply do a <224 test for cache-matching options. I suppose this ship has sailed. 5.5.1: The implementation note notwithstanding, I don't understand why Content-Format is not a SHOULD. 5.7.1: If a response is generated out of a cache, it MUST be generated with a Max-Age Option that does not extend the max-age originally set by the server The reverse would be clearer: If a response is generated out of a cache, the generated Max-Age Option MUST NOT extend the max-age originally set by the server = Also: "a proxy SHOULD be conservative" s/SHOULD/should. There's nothing to implement here. 5.10.5 s/MUST/is. The MUST is not meaningful. 8.1: A server SHOULD be aware that a request arrived via multicast, e.g. by making use of modern APIs such as IPV6_RECVPKTINFO [RFC3542], if available. That SHOULD is not meaningful. It is useful, not required with exceptions (as SHOULD indicates), for the server to know that it is using multicast. This also gives a reason not to allow RST on *any* NON messages. 8.2: "the server MAY always pretend"? We are getting sillier with our 2119 usage later in the document. Did you really mean, "the server MAY ignore the request"? Isn't that true of any NON request, not just multicast ones? (I did not do an significant review of sections 9 or 11.) 12.1: As mentioned regarding section 3 and 5.2 above, I think it would be much easier to figure these out if you separated out the bit fields of code type and code, and then had sub-registries for request codes, success codes, client error codes, and server error codes. From cabo@tzi.org Mon Apr 22 23:03:45 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68FDD21F93A3; Mon, 22 Apr 2013 23:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.277 X-Spam-Level: X-Spam-Status: No, score=-107.277 tagged_above=-999 required=5 tests=[AWL=-1.028, 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 HYQhI3FmK4Eh; Mon, 22 Apr 2013 23:03:44 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0643D21F9389; Mon, 22 Apr 2013 23:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r3N63f0u022009; Tue, 23 Apr 2013 08:03:41 +0200 (CEST) Received: from [192.168.217.105] (p5489274E.dip0.t-ipconnect.de [84.137.39.78]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id ABA013383; Tue, 23 Apr 2013 08:03:40 +0200 (CEST) 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: <20130422222215.25364.10312.idtracker@ietfa.amsl.com> Date: Tue, 23 Apr 2013 08:03:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130422222215.25364.10312.idtracker@ietfa.amsl.com> To: "Pete Resnick" X-Mailer: Apple Mail (2.1503) Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, The IESG , core@ietf.org Subject: Re: [core] Pete Resnick's Discuss on draft-ietf-core-coap-15: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 23 Apr 2013 06:03:45 -0000 On Apr 23, 2013, at 00:22, "Pete Resnick" = wrote: > 1. The reference to [I-D.ietf-lwig-terminology] worries me, given that = it > is not even in LC yet. Point of information: This passed WGLC in LWIG just yesterday. draft-ietf-lwig-terminology-04 has the WGLC changes. Waiting for write-up. Gr=FC=DFe, Carsten From zach@sensinode.com Tue Apr 23 00:40: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 7F19521F9648 for ; Tue, 23 Apr 2013 00:40:44 -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 npgMkTvkXAhk for ; Tue, 23 Apr 2013 00:40:43 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 840F421F8D90 for ; Tue, 23 Apr 2013 00:40:42 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r3N7ecDM021496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Apr 2013 10:40:38 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: <20130423003931.GB24192@hephaistos.amsuess.com> Date: Tue, 23 Apr 2013 10:40:38 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5148A583-2C06-4CAD-804C-89F8BBB555F7@sensinode.com> References: <20130423003931.GB24192@hephaistos.amsuess.com> To: chrysn X-Mailer: Apple Mail (2.1503) Cc: core@ietf.org Subject: Re: [core] core-interfaces: rationale behind resource observation *attributes* X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 23 Apr 2013 07:40:44 -0000 Hi, On Apr 23, 2013, at 3:39 AM, chrysn wrote: > hello, >=20 > draft-shelby-core-interfaces-05 introduced a modification to the > observation parameters, where observations that would in -4 look like > this: >=20 >> Req: GET Observe /s/temp?pmin=3D10&pmax=3D60&st=3D1 >> Res: 2.05 Content Observe:0 (text/plain) >> 23.2 >=20 > would turn into this: >=20 >> Req PUT /s/temp?pmin=3D10&pmax=3D60&st=3D1 >> Res: 2.04 Changed >>=20 >> Req: GET Observe /s/temp >> Res: 2.05 Content Observe:0 (text/plain) >> 23.2 >=20 > this seems to be a modification for the worse, for it introduces a > global state on the server (which previously resided in the observe > subscription that is stateful by design). if two subscribers connect, > the second will overwrite the observation parameters the first > configured. if the intention is that the parameters that are = configured > at connection time stay valid for the connection, that's still open = for > race conditions. >=20 > what was wrong with the old solution, and why was the new one chosen = to > supersede the old one? Right, let me answer that first. The old model was not compatible with = caching. In other words, /s/temp?pmin=3D10 and /s/temp?pmin=3D20 are = completely different resources from the cache perspective, so in the old = model an intermediate or client side cache would not be able to handle a = simple request for /s/temp as it would have no cache entry. Observe is = extremely useful for keeping a cache updated, thus we don't want to = loose that. For that reason, the parameters for Observation control are now treated = as resources rather than query string parameters included with the = Observe request. The endpoint still has a lot of flexibility in dealing = with these parameters, they could be stored per client, thus giving you = the same effect as in the original model but requiring more RAM, or they = could be aggregated across all clients, saving RAM.=20 That said, CoRE Interfaces is meant to give best practices on how to = design resources for use with CoRE specifications. It doesn't mean this = is the only way to design REST interfaces over CoAP, you could certainly = use another paradigm if caching for example is not of importance. = Although at the same time, using a common REST design has advantages = too.=20 Zach >=20 > best regards > chrysn >=20 > --=20 > To use raw power is to make yourself infinitely vulnerable to greater = powers. > -- Bene Gesserit axiom --=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 esko.dijk@philips.com Tue Apr 23 04:43:27 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D23921F9758 for ; Tue, 23 Apr 2013 04:43:27 -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 Lg7QVF4qE9jA for ; Tue, 23 Apr 2013 04:43:26 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8A26621F9763 for ; Tue, 23 Apr 2013 04:43:24 -0700 (PDT) Received: from mail83-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Tue, 23 Apr 2013 11:43:23 +0000 Received: from mail83-ch1 (localhost [127.0.0.1]) by mail83-ch1-R.bigfish.com (Postfix) with ESMTP id B6C0D2C01AA; Tue, 23 Apr 2013 11:43: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: -34 X-BigFish: VPS-34(zz15d6O9251J103dK542I217bIzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz17326ah8275bh8275dh1033ILz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail83-ch1 (localhost.localdomain [127.0.0.1]) by mail83-ch1 (MessageSwitch) id 1366717402782158_4709; Tue, 23 Apr 2013 11:43:22 +0000 (UTC) Received: from CH1EHSMHS026.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail83-ch1.bigfish.com (Postfix) with ESMTP id B36AF440261; Tue, 23 Apr 2013 11:43:22 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS026.bigfish.com (10.43.70.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 23 Apr 2013 11:43:22 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.176]) by 011-DB3MMR1-010.MGDPHG.emi.philips.com ([10.128.28.49]) with mapi id 14.02.0328.011; Tue, 23 Apr 2013 11:43:08 +0000 From: "Dijk, Esko" To: "Kovatsch Matthias" Thread-Topic: [core] I-D Action: draft-ietf-core-groupcomm-06.txt Thread-Index: AQHON3xmIL4DCVtc+EGTnUynhWYw0ZjdUGMAgAUQu9CAAA6AAIABSyXA Date: Tue, 23 Apr 2013 11:43:08 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C14EF3@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <20130412124959.22556.94358.idtracker@ietfa.amsl.com> <55877B3AFB359744BA0F2140E36F52B514E8C867@MBX20.d.ethz.ch> <031DD135F9160444ABBE3B0C36CED618C14BD2@011-DB3MPN2-083.MGDPHG.emi.philips.com> <55877B3AFB359744BA0F2140E36F52B514E9AB83@MBX20.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514E9AB83@MBX20.d.ethz.ch> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org" Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-06.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, 23 Apr 2013 11:43:27 -0000 Ok, thanks! So a separate media type seems best and RESTful. Suppose we define 'application/coap-group+json' for that, the side effect i= s that a client not knowing this specific content-format can't deduce that = it is in fact JSON format. (E.g. the client could integrate a generic-JSON-= viewer-plus-editor that shows the information to a user. In this case it wo= n't invoke the JSON-viewer anymore because the content is not recognized as= being JSON). So in a way, we also lose a bit of functionality/generality = by this solution. Esko -----Original Message----- From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch] Sent: Monday, April 22, 2013 17:37 To: Dijk, Esko; core@ietf.org Subject: RE: [core] I-D Action: draft-ietf-core-groupcomm-06.txt > thanks for your look at the group management protocol. Could you > explain perhaps why a specific content type is needed for this? A > client that GETs such a resource presumably already knows (resource > discovery) that the resource type is e.g. "core.gp", so that provides > already the information what the interpretation of the returned > content exactly should be. Why would the content-format be needed, > just to repeat this information - is this related to the HATEOAS mentione= d? Yes, in the end, the information is the same. REST says, however, that the = shared common knowledge must be stored in the media types. This is what act= ually decouples client and server, and allows clients to use services they = were not explicitly written for (unlike a hardcoded "POST x to /path/y" whi= ch is simply an RPC). Resource types are good to find an entry link to an a= pplication, but going beyond that and specifying what methods to use on whi= ch URI completely conflicts with our RESTful banner. This is an old problem= and there is a lot of discussion (e.g., http://roy.gbiv.com/untangled/2008= /rest-apis-must-be-hypertext-driven). Ciao Matthias ________________________________ 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 kovatsch@inf.ethz.ch Tue Apr 23 04:55: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 11D5621F963F for ; Tue, 23 Apr 2013 04:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.227 X-Spam-Level: X-Spam-Status: No, score=-9.227 tagged_above=-999 required=5 tests=[AWL=1.372, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZbHOdDsbYzl for ; Tue, 23 Apr 2013 04:55:28 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA1921F962E for ; Tue, 23 Apr 2013 04:55:27 -0700 (PDT) Received: from CAS11.d.ethz.ch (172.31.38.211) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 23 Apr 2013 13:55:21 +0200 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS11.d.ethz.ch ([fe80::ecc9:4e2d:b26b:1614%10]) with mapi id 14.02.0298.004; Tue, 23 Apr 2013 13:55:24 +0200 From: "Kovatsch Matthias" To: "Dijk, Esko" Thread-Topic: [core] I-D Action: draft-ietf-core-groupcomm-06.txt Thread-Index: AQHON3xetyyyB6vlzUqueNFPo/VPjZjdTWywgAT0MACAACRCQIABORUAgAAjCDA= Date: Tue, 23 Apr 2013 11:55:23 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514E9B828@MBX20.d.ethz.ch> References: <20130412124959.22556.94358.idtracker@ietfa.amsl.com> <55877B3AFB359744BA0F2140E36F52B514E8C867@MBX20.d.ethz.ch> <031DD135F9160444ABBE3B0C36CED618C14BD2@011-DB3MPN2-083.MGDPHG.emi.philips.com> <55877B3AFB359744BA0F2140E36F52B514E9AB83@MBX20.d.ethz.ch> <031DD135F9160444ABBE3B0C36CED618C14EF3@011-DB3MPN2-083.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618C14EF3@011-DB3MPN2-083.MGDPHG.emi.philips.com> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org" Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-06.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, 23 Apr 2013 11:55:29 -0000 Hmm, that is a good point. The problem here lies more in the number registr= y for the Content-Format, I suppose. Maybe we should have something similar to option numbers, so that specific = bits indicate a "+json" or "+xml"? In general, it is the point, though, that the media types must be pre-share= d. A generic client would probably be like a Web browser that has plugins f= or new types or at least can make a lookup in the registry. Ciao Matthias > Suppose we define 'application/coap-group+json' for that, the side effect= is > that a client not knowing this specific content-format can't deduce that = it is in > fact JSON format. (E.g. the client could integrate a generic-JSON-viewer-= plus- > editor that shows the information to a user. In this case it won't invoke= the > JSON-viewer anymore because the content is not recognized as being JSON). > So in a way, we also lose a bit of functionality/generality by this solut= ion. From brian@innovationslab.net Tue Apr 23 08:27:39 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F52F21F9676; Tue, 23 Apr 2013 08:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.201 X-Spam-Level: X-Spam-Status: No, score=-102.201 tagged_above=-999 required=5 tests=[AWL=0.400, 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 4eUEDhPjEBbM; Tue, 23 Apr 2013 08:27:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 024F621F9642; Tue, 23 Apr 2013 08:27:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Brian Haberman" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130423152738.28060.55006.idtracker@ietfa.amsl.com> Date: Tue, 23 Apr 2013 08:27:38 -0700 Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Brian Haberman's No Objection on draft-ietf-core-coap-15: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 23 Apr 2013 15:27:39 -0000 Brian Haberman has entered the following ballot position for draft-ietf-core-coap-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for a well-written document. I do support Pete's DISCUSS points. From martin.stiemerling@neclab.eu Wed Apr 24 01:00: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 5880321F8FAA; Wed, 24 Apr 2013 01:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.133, 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 K9Rbeixphy2A; Wed, 24 Apr 2013 01:00:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF52B21F8EE6; Wed, 24 Apr 2013 01:00:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Martin Stiemerling" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130424080048.15722.12973.idtracker@ietfa.amsl.com> Date: Wed, 24 Apr 2013 01:00:48 -0700 Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Martin Stiemerling's Discuss on draft-ietf-core-coap-15: (with DISCUSS) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 Apr 2013 08:00:49 -0000 Martin Stiemerling has entered the following ballot position for draft-ietf-core-coap-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- A well-written document and I have a few points to discuss, but I still need to write them in a comprehensive way. = A tentative short list: 1) IPv6 UDP checksum calculation It is not clear if zero UDP checksums are permitted or not permitted with COAP.? (UDP zero checksums: = https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/) That should be specified. = 2) Handling of UDP-lite Can UDP-lite (RFC 3828) be used or cannot be used in conjunction with CoAP? From martin.stiemerling@neclab.eu Wed Apr 24 02:22: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 573FB21F8E9A; Wed, 24 Apr 2013 02:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcbAN4A5lkk2; Wed, 24 Apr 2013 02:22:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A66C21F8B98; Wed, 24 Apr 2013 02:22:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Martin Stiemerling" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130424092228.10345.76059.idtracker@ietfa.amsl.com> Date: Wed, 24 Apr 2013 02:22:28 -0700 Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Martin Stiemerling's Discuss on draft-ietf-core-coap-15: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 Apr 2013 09:22:29 -0000 Martin Stiemerling has entered the following ballot position for draft-ietf-core-coap-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- A well-written document and I have a few points to discuss. = The congestion avoidance mechanisms look ok, but I assume we will get feedback from implementers and deployments on the parameters and mechanisms. It would be good to get this feedback documented at some point. = Here are the issues (based on my own review and input from Joe Touch and Michael Scharf): 1) IPv6 UDP checksum calculation It is not clear if zero UDP checksums are permitted or not permitted with COAP.? (UDP zero checksums: https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/) That should be specified. 2) Handling of UDP-lite Can UDP-lite (RFC 3828) be used or cannot be used in conjunction with CoAP? 3) Fragmentation of messages The recommendation in Section 4.6 about the path MTU is generally valid only for IPv6. For IPv4, 567 bytes is the safe area to work without fragmentation, though in today WANs 1280 work perfectly, but I am not so sure about the networks envisioned for CoAP. This 576 bytes for IPv4 are mentioned in the implementation note, but deserves text on the same level as for IPv6. = 4) Ensuring no fragmentation with IPv4 The implementation note in Section 4.6 states that for IPv4 it is 'harder to ensure that there is no IP fragmentation'. This neglects the possibility of using the Don't Fragment (DF) flag in the IPv4 header and also that there is possibly feedback from a node enroute that the MTU is too big if the DF flag is set, i.e., by means of an ICMP error message. = Should there be any recommendation or protocol machinery to deal with path probing? E.g., referencing RFC 4821 (PMTUD). = 5) Reaction to network errors that are signalled I wonder why the draft is not discussing any reaction to network failures signalled through ICMP messages. This relates also to my DISCUSS issue no 4. = 6) Idempotency The discussion of idempotency is useful, but overlooks message order. I.e., the discussion appears to assume that a sequence of the same actions has the same effect as a single action, but this is true only if different sets of actions (from different sources, or copies of different actions from a single source) aren't interleaved. This should be addressed. = 7) Protocol reactions to reserved or prohibited values Regarding reserved or prohibited values in the IANA section, it would be useful to be clear about what happens when those values are seen. I.e., should they be ignored, generate an error, etc. 8) Flow Control/Receiver Buffer The protocol does not have any real means for the receiver to control the amount of data that is being sent to it. I can understand the attempt to provide a simple protocol, but adding a very basic flow control mechanism will not prohibitively increase the complexity of the protocol, while improving robustness. = According to Section 2.1, a node can always return a RST if the message cannot be process for whatever reason. = I propose to add an option to the RST message that allows the message receiver to state how much data it is willing to accept from a particular sender or in general (up to the implementation). = 9) Handling a wrapping message IDs According to 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)" with EXCHANGE_LIFETIME of 247s. = By now it is unrealistic that the message ID of 16 bits will wrap around in that time frame, but protocols live long and at some later time it can be possible. = However, the protocol doesn't have any means to detect wrapped message IDs. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) Endpoint vs. host = This document uses the term "endpoint" to refer to the combination of address and port, and possibly also security association, that is local to one end of an association. I would have expected the more common term "socket", as originated in TCP parlance, to be used instead (even though here the term is used in a connectionless context). = 2) Reaction to network errors due to local link errors Link layers can give some hints if the link is up, down, etc. Traditionally, this has not been taken into account too much when design transport protocols, but wouldn't it make sense to take it into account for CoAP, as it is much more working in constrained environments? 3) Short messages Section 3., paragraph 1: > CoAP is based on the exchange of short messages which, by default, > are transported over UDP (i.e. each CoAP message occupies the data > section of one UDP datagram). CoAP may also be used over Datagram What are short messages in terms of bytes? Is this a hidden protocol requirement? 4) randomization of message IDs Section 4.4., paragraph 3: > 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 (note that some receiving endpoints may not > be able to distinguish unicast and multicast packets adressed to > it, so endpoints generating Message IDs need to make sure these do > not overlap). The initial variable value should be randomized. the initial variable SHOULD be randomized, just to avoid blind off path attacks, right? 5) In Section 4.6.: > larger than an IP fragment result in undesired packet fragmentation. should read larger than an 'IP packet' instead of 'IP fragment'. 6) Section 5.4.1., paragraph 7: > Critical/Elective rules apply to non-proxying endpoints. A proxy > processes options based on Unsafe/Safe classes as defined in > Section 5.7. I suggest moving this statement to the beginning of this subsection, as it provides important information that shouldn=E2=80=99t be missed. 7) Dependency between application layer and CoAP Section 5.2.2., paragraph 2: > The server maybe initiates the attempt to obtain the resource > representation and times out an acknowledgement timer, or it > immediately sends an acknowledgement knowing in advance that there > will be no piggy-backed response. The acknowledgement effectively is > a promise that the request will be acted upon. This may or may not be an issue: Assuming that the server did sent an ACK for a request but is never ever fulfilling its promise to send any real 'response'. The request/response initiated from the client is done on the CoAP level, but not for the application on top. = Is there any recommendation for the application on top of CoAP how to handle such cases? From cabo@tzi.org Wed Apr 24 03:59:20 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE70521F8B60 for ; Wed, 24 Apr 2013 03:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.758 X-Spam-Level: X-Spam-Status: No, score=-106.758 tagged_above=-999 required=5 tests=[AWL=-0.768, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259, 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 caPqTccwZrAR for ; Wed, 24 Apr 2013 03:59: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 867F021F8ADC for ; Wed, 24 Apr 2013 03:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r3OAxCq4005703 for ; Wed, 24 Apr 2013 12:59:12 +0200 (CEST) Received: from [192.168.217.105] (p54891E67.dip0.t-ipconnect.de [84.137.30.103]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B4B003DEA; Wed, 24 Apr 2013 12:59:11 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Carsten Bormann In-Reply-To: <20130424080048.15722.12973.idtracker@ietfa.amsl.com> Date: Wed, 24 Apr 2013 12:59:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8D67C1C5-FE0A-4DA8-85D6-00C5B023D26E@tzi.org> References: <20130424080048.15722.12973.idtracker@ietfa.amsl.com> To: "core@ietf.org (core@ietf.org)" X-Mailer: Apple Mail (2.1503) Subject: [core] UDPzero/UDPlite (Re: Martin Stiemerling's Discuss on draft-ietf-core-coap-15: (with DISCUSS)) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 Apr 2013 10:59:20 -0000 WG, I think Martin's comment is interesting because I think we, as a WG, = have never thought about this. So let's have some discussion as a WG before the authors/chairs reply. Background: IPv4 can "switch off" the UDP checksum by setting it to zero = (=3D "not generated"). When IPv6 was designed, this capability was removed for two reasons: -- The IP header checksum was removed in IPv6, and there was a feeling = there should be at least some integrity protection of the header. This is provided by including the (pseudo-)header in the UDP checksum = calculation (as it is in IPv4). -- There was a general sentiment that switching off the UDP checksum in = IPv4 had been occurring for all the wrong reasons, and there was = operational experience with hard-to-find bugs caused by this (actually, = my first activity on the university network here in Bremen in 1993 was = finding a strange NFS hickup that, in the end, was caused exactly by = this). The backdrop for 6LoWPAN was, of course, IPv6, so when we designed the = header compression there, we made sure that we preserved the UDP = checksum. There is some weasel-wording in 4.3.2 that allows "compressing" = (eliding) the UDP checksum if this "is authorized by the upper layer". This might make some sense with DTLS on top, which already provides its = own integrity check. (This doesn't guard against misdelivery, though.) RFC 6282 also has no way to compress a zero checksum -- an elided = checksum is just recomputed at the next hop. So, with 6LoWPAN, we wouldn't easily get a 2-byte compression gain from = UDPzero. Now what about CoRE? > 1) IPv6 UDP checksum calculation > It is not clear if zero UDP checksums are permitted or not permitted = with > COAP.? > (UDP zero checksums:=20 > https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/) (That draft is in AUTH48 and will be RFC6936 soon.)=09 This is a relatively new development, mostly motivated by tunneling in = routers; I believe we are outside the scope of this RFC. > That should be specified.=20 I believe that is clearly specified by not referencing the udpzero = draft. In other words, for -15, it is not allowed. (I'm ignoring the IPv4 case here, where we don't make a statement.) But should it? It mostly would save CPU, at least initially not space (see above). It would remove one safety net that, in a world of somewhat unreliable = and even haphazard devices, may be even more useful than it was in our = campus network in 1993. Other data points: There is very little host support for UDPzero right now. It is not clear how a node would decide to use UDPzero or not (would = there have to be an indication in the URI?). > 2) Handling of UDP-lite > Can UDP-lite (RFC 3828) be used or cannot be used in conjunction with > CoAP? UDPlite was an interesting extension of UDP to enable the use of UEP = (unequal error protection) link layers: Only part of the packet is protected with a checksum, so you get the = data even if they are slightly corrupted in the unprotected space. This is useful e.g. for speech. To support this, UDPlite allows to "retract" the checksum by using the = (otherwise redundant) length field to indicate the length of the = protected space. The considerations are similar, except that UDPlite support is even = worse. Hosts typically don't do it. RFC 6282 can't NHC compress UDPlite as is (I think we even briefly = discussed that and decided not to do it). But most important, UEP link layers that are needed to make UDPlite = really useful don't seem to exist in our space. So: What do you think? Gr=FC=DFe, Carsten From Akbar.Rahman@InterDigital.com Wed Apr 24 07:53: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 DE51A21F8EF5 for ; Wed, 24 Apr 2013 07:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[AWL=1.420, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7kKjasxzo+M for ; Wed, 24 Apr 2013 07:53:35 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id A6B6621F8EC9 for ; Wed, 24 Apr 2013 07:53:34 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Apr 2013 10:53:33 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Apr 2013 10:53:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <8D67C1C5-FE0A-4DA8-85D6-00C5B023D26E@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] UDPzero/UDPlite (Re: Martin Stiemerling's Discuss ondraft-ietf-core-coap-15: (with DISCUSS)) Thread-Index: Ac5A2srwPWbximShSzeKBeu+8bH8DAAHhAiQ References: <20130424080048.15722.12973.idtracker@ietfa.amsl.com> <8D67C1C5-FE0A-4DA8-85D6-00C5B023D26E@tzi.org> From: "Rahman, Akbar" To: "Carsten Bormann" X-OriginalArrivalTime: 24 Apr 2013 14:53:33.0881 (UTC) FILETIME=[7E36C290:01CE40FB] Cc: core@ietf.org Subject: Re: [core] UDPzero/UDPlite (Re: Martin Stiemerling's Discuss ondraft-ietf-core-coap-15: (with DISCUSS)) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 Apr 2013 14:53:38 -0000 Hi Carsten, Thanks for the good background and explanation. My WG member feedback: --- Snip-1 --- > That should be specified.=20 I believe that is clearly specified by not referencing the udpzero = draft. In other words, for -15, it is not allowed. (I'm ignoring the IPv4 case here, where we don't make a statement.) AKBAR - YES, BUT I THINK MARTIN WANTS THE COAP-15 I-D TO EXPLICTILY MAKE = THE STATEMENT OF SUPPORT OR NOT (FOR CLARITY). AND ALSO, I GUESS, WE = SHOULD HAVE SOME BRIEF TEXT DESCRIBING THE REASON FOR THE CHOICE. THIS = COULD, FOR EXAMPLE, BE DONE THROUGH A NEW "EXCEPTIONS" SECTION (ASSUMING = THAT THE UDPZERO AND UDPLITE FEATURES ARE NOT SUPPORTED). --- End Snip-1 ----- --- Snip-2 --- Other data points: There is very little host support for UDPzero right now. It is not clear how a node would decide to use UDPzero or not (would = there have to be an indication in the URI?). AKBAR - INDICATING IT IN THE URI WOULD BE A REAL CROSS LAYER MESS IN MY = OPINION! --- End Snip-2 ----- Finally, on the main point about whether we should support the UDPZERO = and UDPLITE, my vote would be to stick with our current approach (i.e. = NOT support either of the two). They seem to be specialized = optimizations that are not well deployed and somehow seem to add overall = deployment complexity and performance risk to the solution even if they = provide some CPU reduction. Best Regards, Akbar -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Carsten Bormann Sent: Wednesday, April 24, 2013 6:59 AM To: core@ietf.org (core@ietf.org) Subject: [core] UDPzero/UDPlite (Re: Martin Stiemerling's Discuss = ondraft-ietf-core-coap-15: (with DISCUSS)) WG, I think Martin's comment is interesting because I think we, as a WG, = have never thought about this. So let's have some discussion as a WG before the authors/chairs reply. Background: IPv4 can "switch off" the UDP checksum by setting it to zero = (=3D "not generated"). When IPv6 was designed, this capability was removed for two reasons: -- The IP header checksum was removed in IPv6, and there was a feeling = there should be at least some integrity protection of the header. This is provided by including the (pseudo-)header in the UDP checksum = calculation (as it is in IPv4). -- There was a general sentiment that switching off the UDP checksum in = IPv4 had been occurring for all the wrong reasons, and there was = operational experience with hard-to-find bugs caused by this (actually, = my first activity on the university network here in Bremen in 1993 was = finding a strange NFS hickup that, in the end, was caused exactly by = this). The backdrop for 6LoWPAN was, of course, IPv6, so when we designed the = header compression there, we made sure that we preserved the UDP = checksum. There is some weasel-wording in 4.3.2 that allows "compressing" = (eliding) the UDP checksum if this "is authorized by the upper layer". This might make some sense with DTLS on top, which already provides its = own integrity check. (This doesn't guard against misdelivery, though.) RFC 6282 also has no way to compress a zero checksum -- an elided = checksum is just recomputed at the next hop. So, with 6LoWPAN, we wouldn't easily get a 2-byte compression gain from = UDPzero. Now what about CoRE? > 1) IPv6 UDP checksum calculation > It is not clear if zero UDP checksums are permitted or not permitted = with > COAP.? > (UDP zero checksums:=20 > https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/) (That draft is in AUTH48 and will be RFC6936 soon.)=09 This is a relatively new development, mostly motivated by tunneling in = routers; I believe we are outside the scope of this RFC. > That should be specified.=20 I believe that is clearly specified by not referencing the udpzero = draft. In other words, for -15, it is not allowed. (I'm ignoring the IPv4 case here, where we don't make a statement.) But should it? It mostly would save CPU, at least initially not space (see above). It would remove one safety net that, in a world of somewhat unreliable = and even haphazard devices, may be even more useful than it was in our = campus network in 1993. Other data points: There is very little host support for UDPzero right now. It is not clear how a node would decide to use UDPzero or not (would = there have to be an indication in the URI?). > 2) Handling of UDP-lite > Can UDP-lite (RFC 3828) be used or cannot be used in conjunction with > CoAP? UDPlite was an interesting extension of UDP to enable the use of UEP = (unequal error protection) link layers: Only part of the packet is protected with a checksum, so you get the = data even if they are slightly corrupted in the unprotected space. This is useful e.g. for speech. To support this, UDPlite allows to "retract" the checksum by using the = (otherwise redundant) length field to indicate the length of the = protected space. The considerations are similar, except that UDPlite support is even = worse. Hosts typically don't do it. RFC 6282 can't NHC compress UDPlite as is (I think we even briefly = discussed that and decided not to do it). But most important, UEP link layers that are needed to make UDPlite = really useful don't seem to exist in our space. So: What do you think? Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From zach@sensinode.com Wed Apr 24 07:55:30 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B431721F92B2 for ; Wed, 24 Apr 2013 07:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.34 X-Spam-Level: X-Spam-Status: No, score=-3.34 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgeL6ETjsCo3 for ; Wed, 24 Apr 2013 07:55:28 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id DB29121F91BC for ; Wed, 24 Apr 2013 07:55:25 -0700 (PDT) Received: from [192.168.1.100] (87-95-85-145.bb.dnainternet.fi [87.95.85.145]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r3OEtLTk024261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Apr 2013 17:55:22 +0300 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: Date: Wed, 24 Apr 2013 17:55:19 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <90E18B27-32E5-4ADE-9205-D2DD0F34F0EE@sensinode.com> References: <20130424080048.15722.12973.idtracker@ietfa.amsl.com> <8D67C1C5-FE0A-4DA8-85D6-00C5B023D26E@tzi.org> To: "Rahman, Akbar" X-Mailer: Apple Mail (2.1503) Cc: core@ietf.org Subject: Re: [core] UDPzero/UDPlite (Re: Martin Stiemerling's Discuss ondraft-ietf-core-coap-15: (with DISCUSS)) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 Apr 2013 14:55:31 -0000 On Apr 24, 2013, at 5:53 PM, "Rahman, Akbar" = wrote: > Finally, on the main point about whether we should support the UDPZERO = and UDPLITE, my vote would be to stick with our current approach (i.e. = NOT support either of the two). They seem to be specialized = optimizations that are not well deployed and somehow seem to add overall = deployment complexity and performance risk to the solution even if they = provide some CPU reduction. +1 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 tho@koanlogic.com Wed Apr 24 08:09:27 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBF321F8900 for ; Wed, 24 Apr 2013 08:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Z=0.259] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFc+Paxp8aH1 for ; Wed, 24 Apr 2013 08:09:27 -0700 (PDT) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id CA3D521F88EA for ; Wed, 24 Apr 2013 08:09:26 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id p11so1857643lbi.0 for ; Wed, 24 Apr 2013 08:09:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ACndT9o63qaSLtsoazySe/wRO1M+cj1Qqllrq20vGV4=; b=PApSZ0shFHujlA0OLnpFF2EPVLNooJxnM5tw0mqVzfS5Ro1QgreH9nf86DprbtEZ9q CgVMhonbc1sns2L7LbrBcbUGvtual2j1kpWBlI5tbDQg9jO7kUPMgKHxreeq9dbi59v/ K1EbxtToVWywe/NuBTa0n+0BIm2No/XHQIWm3M+rxmMkdAVih30xAXxSZkei3+LytmM4 qlRPgqmkFFjdTM6fBGB3ujqnnhWK4u5k7Aue/9tDE8LLx+eO4peSfJiKGv7JayHlkipI n+c1q9uia7XggIMeb8ToMkWADXae74jSs+UrUUb4J+9bM9sZ4DyondS9/6yk1BSzYA3A L9Gg== MIME-Version: 1.0 X-Received: by 10.112.132.73 with SMTP id os9mr7182606lbb.120.1366816165718; Wed, 24 Apr 2013 08:09:25 -0700 (PDT) Received: by 10.114.93.7 with HTTP; Wed, 24 Apr 2013 08:09:25 -0700 (PDT) X-Originating-IP: [81.134.152.4] In-Reply-To: References: <20130424080048.15722.12973.idtracker@ietfa.amsl.com> <8D67C1C5-FE0A-4DA8-85D6-00C5B023D26E@tzi.org> Date: Wed, 24 Apr 2013 16:09:25 +0100 Message-ID: From: Thomas Fossati To: "Rahman, Akbar" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlan3jFnd0lpmWHJU9DPSfrsZslnmyqwQFlI8CYKqP34fJVTdC03JKoSDuNNNCOIBGMWlUS Cc: "core@ietf.org" Subject: Re: [core] UDPzero/UDPlite (Re: Martin Stiemerling's Discuss ondraft-ietf-core-coap-15: (with DISCUSS)) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 Apr 2013 15:09:27 -0000 +1 on all comments made by Akbar. From trac+core@trac.tools.ietf.org Wed Apr 24 13:48: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 537D821F894E for ; Wed, 24 Apr 2013 13:48: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 q7tRjKVoZrpd for ; Wed, 24 Apr 2013 13:48: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 9123221F86F0 for ; Wed, 24 Apr 2013 13:48:00 -0700 (PDT) Received: from localhost ([127.0.0.1]:59843 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UV6bd-0003We-1u; Wed, 24 Apr 2013 22:47:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Wed, 24 Apr 2013 20:47:56 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/298#comment:1 Message-ID: <066.4bbba23421871cb1361b27171c2d3bc0@trac.tools.ietf.org> References: <051.7fe60c62187d4c88b101bc8b9262e08a@trac.tools.ietf.org> X-Trac-Ticket-ID: 298 In-Reply-To: <051.7fe60c62187d4c88b101bc8b9262e08a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130424204800.9123221F86F0@ietfa.amsl.com> Resent-Date: Wed, 24 Apr 2013 13:48:00 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #298: Small discrepancy about 2.02 Delete X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 20:48:01 -0000 #298: Small discrepancy about 2.02 Delete Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1312]: Fix #298 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: post-IESG-1 Component: coap | Version: coap-15 Severity: Submitted | Resolution: fixed WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Wed Apr 24 14:06: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 D58C221F8E9E for ; Wed, 24 Apr 2013 14:06:15 -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 LErHIjHgn9Po for ; Wed, 24 Apr 2013 14:06:15 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A481121F8B07 for ; Wed, 24 Apr 2013 14:06:14 -0700 (PDT) Received: from localhost ([127.0.0.1]:33397 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UV6sx-0004N4-62; Wed, 24 Apr 2013 23:05:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Wed, 24 Apr 2013 21:05:51 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/297#comment:1 Message-ID: <066.aab3e15513a874fdc05b44a83534ab7d@trac.tools.ietf.org> References: <051.0e4ca2554c29ad6839a19ea85f54051a@trac.tools.ietf.org> X-Trac-Ticket-ID: 297 In-Reply-To: <051.0e4ca2554c29ad6839a19ea85f54051a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130424210614.A481121F8B07@ietfa.amsl.com> Resent-Date: Wed, 24 Apr 2013 14:06:14 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #297: Informative refs in core-coap: groupcomm X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 21:06:16 -0000 #297: Informative refs in core-coap: groupcomm Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1313]: Fix #297 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: post-IESG-1 Component: coap | Version: coap-15 Severity: Submitted | Resolution: fixed WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From stephen.farrell@cs.tcd.ie Wed Apr 24 18:26: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 C3D3C21F8AE8; Wed, 24 Apr 2013 18:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98 X-Spam-Level: X-Spam-Status: No, score=-98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_EMAIL=2.3, MANGLED_LIST=2.3, 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 q6HFvHFSYYu8; Wed, 24 Apr 2013 18:26:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3AA21F8629; Wed, 24 Apr 2013 18:26:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130425012605.7589.40567.idtracker@ietfa.amsl.com> Date: Wed, 24 Apr 2013 18:26:05 -0700 Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Stephen Farrell's Discuss on draft-ietf-core-coap-15: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Apr 2013 01:26:06 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-core-coap-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I will end up balloting yes for his. I think its good work and has lots of implementations. Note also that some of the discuss points here should be easily resolved or are just checking stuff. (Its in the nature of very very long documents that the accumulation of such stuff generates more discuss points.) Anyway, let's discuss... (1) 2.3: What if the URI scheme doesn't have a host or port or path or query? Also in 5.6, 2nd bullet in list: Just to note that if you were using ni URIs with CoAP, then you no longer need to insist on exactly the same URI (e.g. the authority part needn't matter with ni URIs, the alg-val part is what counts). That might be true of other schemes too, so perhaps this statment is scheme specific to some extent? This is just a discuss point to check that you're ok with CoAP being restricted to some URI schemes in this manner, the ni URI case is just an example I happen to know fairly well:-) So I'll clear this one when told that this is considered acceptable but I want to check the general issue about uri-scheme dependencies for CoAP. The same point occurs in 5.7.1 and maybe elsewhere btw. So basic point is: please provide some sensible description of which URI schemes can be used with CoAP and which cannot. (2) 4.2, "when the timeout is triggered" - what happens with sleepy nodes that only wake on external events, and where e.g. if 2 timeouts have elapsed whilst asleep? Not sure if odd behaviour of that kind could cause much harm, but was it considered? This could also affect the definition in 4.8.2 of MAX_TRANSMIT_SPAN. (3) 4.2, last para: this creates an attack that can work from off-path - just send loads of faked ACKs with guessed Tokens and some of 'em will be accepted with probability depending on Token-length and perhaps the quality of the RNG used by the sender of the CON. That could cause all sorts of "interesting" application layer behaviour. Why is that ok? (Or put another way - was this considered and with what conclusion?) I suspect you need to have text trading off the Token length versus use of DTLS or else CoAP may end up too insecure for too many uses. (Note: the attack here is made worse because the message ID comparison can be skipped. Removing that "feature" would help a lot here.) 5.3.1's client "may want to use a non-trivial, randomized token" doesn't seem to cut it to me. How does this kind of interaction map to DTLS sessions/epoch? Basically, I'd like to see some RECOMMENDED handling of token length that would result in it not being unsafe to connect a CoAP node to the Internet. (And please note recent instances where 10's of thousands of insecure devices have been found via probing the IPv4 address space. These are real attacks.) (4) 4.4, implementation note - this seems unwise since it means that once Alice has interacted with Bob, then Bob can easily guess the message IDs that Alice will use to talk to Charlie. (5) 4.6, last para - this only applies to insecure uses of CoAP, you should point that out (6) 6.2 - "the UDP datagrams MUST...use DTLS" is fine but maybe not enough, if the request uses DTLS then presumably so MUST *all* response messages, and they MUST use the same DTLS session? Or perhaps one with the same authenticated endpoints. Don't you need to say that? If you don't then just sending the request via DTLS but getting (some) response messages in clear would seem to be allowed. I think 9.1 might cover all the above, but want to just check. (7) 9.1.1, 1st para: what is "the server" - is that the destination host from the URI? If yes, then fine. If no, then we need to DISCUSS that. = (8) 9.1.3.3 - "signed by an appropriate chain of trust" is an odd phrase - do you mean it MUST be validated as per RFC 5280 section 6? If so, say so. If not, say what you do mean. (But we might need to talk about it in that case, depending;-) (9) 9.1.3.3 - you don't mention certificate status checking. I can see why that's hard to impossible in some n/w's but entirely ignoring it seems wrong. Perhaps call out the vulnerability and point at OCSP stapling as a potential solution, but one that requires further work and/or further specification? (10) 10.1 - what does https mean here? If it means that the request/response are in clear between the source and proxy and then encrypted then a) you really really need to say that clearly and b) why is that even acceptable and c) what if the destination resource requires client auth? It just seems broken to pretend to use https this way. Going via a cross-proxy breaks security. Similarly, what does coaps mean in 10.2? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- general: 112 pages, sheesh;-) Seriously though, there is repetition here that'd be better not there and fewer words is better. Too late now though. abstract: "CoAP easily..." is a bit of sales-talk, better to say "CoAP is designed to easily..." intro, 2nd para: better to not talk about the WG name and its work really, but about the resulting protocol intro, 2nd para: suggest s/limiting the use of/limiting the need for/ intro, last para: more sales pitch language 1.2, critical option - I wondered here if proxies have to know these or just client & server. "Endpoint receiving the message" doesn't make that (ctystal) clear. "Unsafe Option" made me wonder more. (It is clear later.) 2.2: This is the first time Token is used. Might be no harm to distinguish that explicitly from Message ID. 2.3: For what "security reason" are proxies useful? = 3: Ver field "MUST set this field to 1" - I guess someone might set both bits to 1, so saying '01'B might be better. Section 3: I didn't see where Message ID wrap-around was described. I see Martin has a discuss on that which I support. 3: Message ID - with 16 bits that imposes a rate limit on how often you can send. I don't think that's described and I'm curious as to whether it'd set to max goodput for CoAP that'd be way less than otherwise possible with e.g. HTTP. 3.2: So I can't have an option with a uint value where missing !=3D 0? Might be worth saying. 4.1: middle two paragraphs seem like repetition - maybe they could be deleted? 4.2, 1st para, "acknowledge such a message" - do you mean all CONs or just an empty CON? splitting up this para into a few or using a bullet list or pseudo-code would be better I think. 4.2, "a random number between 2 and 3" (replacing names with defaults) - ought you recommend some minimun granularity just in case some careless developer did something like: initialTimeout=3DACK_TIMEOUT+ rand()%(ACK_TIMEOUT*ACKRANDOM_FACTOR-ACK_TIMEOUT) 4.3, last sentence in parenthesis - I have no idea what that means 4.4, last para: I just wonder if any NAT or v6 transition schemes might invalidate this MUST? 4.6, 1st sentence: don't get that, maybe better deleted. 4.8.1, DEFAULT_LEISURE is in table 1 but not discussed until section 8, a fwd ref at least would be good 5.2.2, "The server maybe initiates..." seems too casual. 5.3.1, 3rd para - the note about using the same token for different source ports seems broken to me. I don't think you say anything to the effect that the response has to go to that source port. 5.4.6, option numbers can be 16 bits long, in that case bit 7 is not the lsb - does that need fixing? Similarly with Figure 11. 5.5.2, I buy your argument here about language tagging, but what happens at a CoAP->HTTP g/w? Doesn't language tagging become an issue there? How's that handled? 5.10.1 - can any of the valid options for Host from 3986 be used? e.g. IPv6 addresses as text in square brackets, decimal form IPv4 addresses? You do have some guidance later but I think that'd be bettern being more obvious. 5.10.5 - I'm probably just confused by reading so much;-) If there are two Max-Age options, which wins? Where's that stated in general? 5.10.8.1 - I don't get why its ok to not say which If-Match to pick if more than one matches. Why's that? 6.1 - I don't get what you mean by saying that the coap URI scheme "supports" /.well-known, maybe that'll be clear in section 7. (I don't think it was.) 6.2 - s/for privacy// - DTLS does authentication, integrity and confidentiality, not privacy 7.1 - what if I want to only do discovery via DTLS? What does "support" mean for port 5683 then? 7.2 - I didn't really get how this works, but I assume that if I re-read RFC6690, then I'd get it. Is that a good assumption? 8.2.1, 1st para - this talks about "the cache" but I don't think you've (so far) told me that clients that send multicast requests have to have a cache for responses. Don't you need to? 8.2.2 - Please make it clear(er) that bormann-coap-misc is properly an informative ref. (Assuming it is.) section 9, last para: what's that mean? I got the feeling the text was trying to hide something from me fwiw. 6.5 - I thin you need a security consideration somwhere about comparing coap(s) URIs and the potential for access control screw-ups. = 9.1 - have people implemented the ECDH ciphersuites in CoAP testing? Knowing if this is just text or also running code might help discuss resolution. 9.1.3.3 - throwing in RSA as a SHOULD (albeit within a section that's a MAY) is odd - if devices can do RSA then why not have 'em all do it for the raw public keys and get the interop gains that will accrue from that. 11.5 - this is a bit detailed, wouldn't a reference do most of it? 12.7 - as it turns out I also don't see why this needs two ports - the cost is two more bytes for security which is significantly-enough less than the current cost (in terms of message size) for security. Am I wrong? = Please also consider the secdir review [1] (if you've not done so already, I do see a shepherd response). [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03873.html From ietf-secretariat-reply@ietf.org Wed Apr 24 19:28: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 4428B21F91A2 for ; Wed, 24 Apr 2013 19:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.053, 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 WhoAkhQ+1PDP; Wed, 24 Apr 2013 19:28:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D96F521F8B07; Wed, 24 Apr 2013 19:28:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: core-chairs@tools.ietf.org, draft-ietf-core-coap@tools.ietf.org, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130425022849.5648.47934.idtracker@ietfa.amsl.com> Date: Wed, 24 Apr 2013 19:28:49 -0700 From: IETF Secretariat Subject: [core] ID Tracker State Update Notice: X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Apr 2013 02:28:50 -0000 State changed to IESG Evaluation - Defer from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-coap/ From ted.lemon@nominum.com Wed Apr 24 20:32: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 B849E21F92B2; Wed, 24 Apr 2013 20:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 lcE6jBA0q7U3; Wed, 24 Apr 2013 20:32:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA2F21F91A2; Wed, 24 Apr 2013 20:32:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Ted Lemon" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130425033226.32552.99254.idtracker@ietfa.amsl.com> Date: Wed, 24 Apr 2013 20:32:26 -0700 Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Ted Lemon's No Objection on draft-ietf-core-coap-15: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Apr 2013 03:32:29 -0000 Ted Lemon has entered the following ballot position for draft-ietf-core-coap-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- P. 14: informative reference to HHGTG almost, but not entirely, helpful. :) P. 15: why start at version 1 when you can only have a total of 4 versions? Wouldn't version 0 be a better choice? P. 19: I'm a little uncomfortable with this text: There is no expectation and no need to perform normalization within a CoAP implementation (except where Unicode strings that are not known to be normalized are imported from sources outside the CoAP protocol). I think what's intended here is right, but you've mentioned what amounts to a strong suggestion, if not a requirement, as a parenthetical note. It seems like what you intended was something like this: There is no expectation and no need to perform normalization within a CoAP implementation, since senders are expected to be implemented with pre-normalized strings. However, strings received from non-CoAP sources SHOULD be normalized where possible. Of course, there's actually no value to normalization in this case if it can't be depended on, and I suspect that you don't want to make that a MUST. So this might be a better way to do it: There is no expectation and no need to perform normalization within a CoAP implementation, since senders are expected to be implemented with pre-normalized strings. Strings received from non-CoAP sources and then forwarded by CoAP senders cannot be assumed to have been normalized, and may not compare correctly with normalized strings representing the same text. I don't have a strong opinion about how this should be done, but it seems like the text as written doesn't give clear guidance. It seems that cross-proxies ought to be able to do normalization, and maybe other proxies could as well, but that's a much bigger change. Section 4.1: Even though I think it doesn't make any sense to do this, it might be worth stating how a receiver should behave if it receives an ACK with a request. Section 4.2: Wouldn't this: More generally, Acknowledgement and Reset messages MUST NOT elicit any Acknowledgement or Reset message from their recipient. be better stated this way? More generally, recipients of Acknowledgement and Reset messages MUST NOT respond with either Acknowledgement or Reset messages. Might be worth grouping for operator precedence here: OLD: ACK_TIMEOUT * (2 ** MAX_RETRANSMIT - 1) * ACK_RANDOM_FACTOR NEW: ACK_TIMEOUT * (2 ** (MAX_RETRANSMIT - 1)) * ACK_RANDOM_FACTOR OLD: 2 * MAX_LATENCY + PROCESSING_DELAY NEW: (2 * MAX_LATENCY) + PROCESSING_DELAY Section 5.8: The use of the word "safe" to describe methods is really confusing because of save/unsafe options. It would help ease of comprehension if you used a different word--e.g., read-only. I realize that this goes somewhat against the idea of sharing nomenclature with HTTP, but I think the clash between safe/unsafe options and safe/unsafe methods is confusing enough that you aren't really benefiting from that anyway. In 5.9: as a user and implementor of RESTful systems who has learned by doing more than by reading, the term "action result" is somewhat opaque to me. I think I know what it means, but it might be nice to explain what it means before using it like this: Like HTTP 201 "Created", but only used in response to POST and PUT requests. The payload returned with the response, if any, is a representation of the action result. 5.9.2.2: I think you mean "first" rather than "previously": The client is not authorized to perform the requested action. The client SHOULD NOT repeat the request without previously improving its authentication status to the server. Which specific mechanism can be used for this is outside this document's scope; see also Section 9. 5.10.1: how does the client know that an endpoint hosts multiple virtual servers in time to leave out the Uri-Host option? Is this literally just in the case where the hostname appears in the URI to be decomposed as an IP address literal? are sufficient for requests to most servers. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers. In 5.10.8.2: I can't quite understand what is meant here. I could see it meaning either or both of the following: 1. If If-None-Match appears in a query with one or more If-Match options, and none of the If-Match options match, the condition is fulfilled. 2. If If-None-Match appears in a query, no If-Match options may appear in that query; the condition is met if the target doesn't exist. I think that the text means just (2), but because of the name of the option, I want it to mean (1), even though the text doesn't say that, and since the text doesn't say that If-None-Match and If-Match are mutually exclusive, I can easily imagine someone reading the text and carelessly assuming that it means (1) or (1 or 2). In 6.4, why /url/? This is really confusing--I was halfway through this section, and kind of confused, before I realized that the slashes were for emphasis, and weren't path separators. Also in 6.4, the text does not account for the case where there's a user part to the authority section of the URI. From rlb@ipv.sx Wed Apr 24 20:21:18 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B18F21F92B2; Wed, 24 Apr 2013 20:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 FTQ+xLrj9ZGh; Wed, 24 Apr 2013 20:21:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A5121F8B9C; Wed, 24 Apr 2013 20:21:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Richard Barnes" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130425032117.15766.38491.idtracker@ietfa.amsl.com> Date: Wed, 24 Apr 2013 20:21:17 -0700 X-Mailman-Approved-At: Wed, 24 Apr 2013 22:44:59 -0700 Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Richard Barnes' Discuss on draft-ietf-core-coap-15: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Apr 2013 03:21:18 -0000 Richard Barnes has entered the following ballot position for draft-ietf-core-coap-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Overall, this is a very nicely written specification. Thanks! There's just one point I think needs action on before I switch to a "YES" position. In Section 5.3.1, "A client sending a request...". This needs to be stronger. The requirement for a randomized token needs to be a MUST, and the stack SHOULD limit the number of rejected responses (before closing the request) based on the length of the token (e.g., 2**(TKL/2)). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 2.2., are requests and responses in 1-1 correspondence? Or can a single request receive more than one response? In Section 3, why is version number 1 and not 0? What's the plan here, do we get 3 or 4 versions out of this? In Section 4.3, would it make sense to have something stronger than MAY for cases where future messages are likely to be screwed up, e.g., where CoAP syntax is malformed? (A "STFU RST"?) >From Section 4.2 and 4.3, I generated a table mapping message types to request/response/empty: CON NON ACK RST Request X X ? ! Response X X X ! Empty ! ! X X = Might be helpful to include something like that as a summary. This might be a bad idea, but: Did the WG consider allowing an ACK to contain a request? In the case where a CON contains a response and the client wants to send another request, it would save a message to put the request in the ACK to the response. From joelja@bogus.com Wed Apr 24 22:46: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 708CB21F9377; Wed, 24 Apr 2013 22:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 CeilJlF0oIuk; Wed, 24 Apr 2013 22:46:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F11A021F925B; Wed, 24 Apr 2013 22:46:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Joel Jaeggli" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130425054611.2107.30163.idtracker@ietfa.amsl.com> Date: Wed, 24 Apr 2013 22:46:11 -0700 Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Joel Jaeggli's No Objection on draft-ietf-core-coap-15: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Apr 2013 05:46:12 -0000 Joel Jaeggli has entered the following ballot position for draft-ietf-core-coap-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support some of the points raised by mehmet against draft 13 (addressed by carsten) which ultimately are not likely to be resolved by the this draft alone. > ** Concerning the migration path, and future versions of CoAP in the same network: > > - It would be useful to state clearly, in which cases it is dangerous to change any of the recommended default values or parameters in future versions of CoAP and would potentially impact the co-existence of two CoAP versions. Thus such a statement would support an incremental deployment to be successful. Again, I believe this is future work, which also applies for the configuration and management data model. Protocol debugging is aided by the self-describing nature of the protocol messages. This has worked pretty well in the (informal and formal) interops so far. Future work will have to address management interfaces for CoAP nodes, including management of security related events. I think some of this will have to integrate with resource discovery, an active subject in the working group. Gr=C3=BC=C3=9Fe, Carsten --- this is not a dicuss because frankly I think at some point you have to draw a line under work that has been done so far and progress work from there. From cabo@tzi.org Thu Apr 25 04:24: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 84CF121F95E1; Thu, 25 Apr 2013 04:24:04 -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 dWfT5YZY2o+i; Thu, 25 Apr 2013 04:24:01 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id F398B21F95D0; Thu, 25 Apr 2013 04:23:59 -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 r3PBNoB6003968; Thu, 25 Apr 2013 13:23:51 +0200 (CEST) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E0B5934BE; Thu, 25 Apr 2013 13:23:50 +0200 (CEST) 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: <20130422222215.25364.10312.idtracker@ietfa.amsl.com> Date: Thu, 25 Apr 2013 13:23:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130422222215.25364.10312.idtracker@ietfa.amsl.com> To: Pete Resnick X-Mailer: Apple Mail (2.1503) Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, The IESG , core@ietf.org Subject: Re: [core] Pete Resnick's Discuss on draft-ietf-core-coap-15: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Apr 2013 11:24:04 -0000 Hi Pete, thanks for this comprehensive review. I have done some of the changes as simple editorial fixes, these are marked like [1304] below and can be reviewed in http://trac.tools.ietf.org/wg/core/trac/changeset/1304 (Overview in http://trac.tools.ietf.org/wg/core/trac/timeline). Some of the replies are marked "-> Ticket": This means that the authors think that the change is a good idea, but probably needs a bit more discussion with the WG, so we will handle this as a ticket. Gr=FC=DFe, Carsten = ---------------------------------------------------------------------- DISCUSS: = ---------------------------------------------------------------------- The items here are very borderline in my book for DISCUSS items; = I'm happy to be talked out of them. But I would like to hear from = the authors and/or chairs before I give my "YES" (which is my plan once = these are resolved). 4.1: An empty message has the Code field set to 0. The Token = Length field MUST be set to 0 and no bytes MUST be present after the = Message ID field. If there are any bytes, they MUST be processed as a = message format error. If you insist on the MUSTs, make the second one "bytes of data = MUST NOT be present". The current construction is ambiguous. (Done the obvious editorial fix as [1304].) That said, I find the combination of MUSTs to be a bit problematic. MUST NOT send = data, but MUST receive as a format error will lead to some sender saying, = "A conformant receiver MUST reject with an error, so no need for me = to validate on the way out" and for a receiver to say, "A = conformant sender MUST NOT send data, so no need for me to validate on the way = in." That's a recipe for non-interoperability. If it were me, I'd drop the = last sentence. There are two different kinds of MUST here. The "MUST NOT send data" is an extension point MUST -- a later version of CoAP MIGHT change that. Since a 1.0 version cannot know what those bytes might mean in a 1.1, it MUST NOT send them. The "MUST treat as error" is an anti-soup MUST (the alternative would be MUST ignore, but that is a recipe for soup, and might make the extension point unworkable). 4.3: rejecting a Non-confirmable message MAY involve sending a = matching Reset message, and apart from the Reset message the rejected = message MUST be silently ignored. See comment on 2.1. But if you're going to allow this, I don't = understand the MAY: Doesn't rejecting the message require sending a Reset? Otherwise, the message has not been rejected; it's simply been = ignored. The second part is either redundant or confusing: What else = might I do with a rejected message other than send the Reset and ignore it? = I think this needs rewriting. I think we are trying to use "reject" as a technical term here (as used in the draft "rejecting" often does not imply actively sending a message). I'm open to inventing another term that is assigned the semantics that "reject" has in CoAP right now. 5.2.2: It is probably worth saying somewhere in here: "Once the = server sends back an empty Acknowledgement, it MUST NOT send back the = response in another Acknowledgement, even if the client retransmits = another identical request. If a retransmitted request is received = (perhaps because the original Acknowledgement was delayed), another empty Acknowledgement is sent and any response MUST be sent as a = separate response." Good point! -> Ticket 5.4.2: Cache-Key is undefined, here or in any other document I = can find. It probably needs an explanation somewhere in this document. The "cache key" is the informal concept that describes all the data that go into selecting the right cache instance, such as the URI, but also options such as "Accept". This concept is important to allow proxies (and other caches) to handle options they don't understand. We probably should describe this in 5.6 and do a foward reference here (there is little point in raising this already in 2.3, I think). Add at the end of (the introduction to) 5.6: =BBThe set of options that is used for matching the cache entry is also collectively referred to as the "Cache-Key".=AB -> Ticket 5.5: Again, I don't like the combination of MUST NOT = include/MUST ignore. I would drop the MUST ignore part. The MUST NOT is an extension point MUST NOT. The MUST ignore means that we expect such extensions to be = "non-critical". 5.10.4: The server = SHOULD return the preferred Content-Format if available. If the = preferred Content-Format cannot be returned, then a 4.06 "Not = Acceptable" SHOULD be sent as a response. What are the exceptions to the above two SHOULDs? If the = preferred format is available, when would a server not return it. If it's not = available, when would the server return other than "Not Acceptable"? Also, = since Accept is not marked as "Critical", why isn't it *always* = treated as elective and therefore ignored if the server can't satisfy the = request? (In other words, shouldn't you also have a "Critical Accept" = option defined?) We had this discussion a couple of times between the authors and in the = WG. =46rom a protocol point of view, you are of course right -- if the options is elective, it can always be ignored. =46rom a quality of implementation point of view, this is a "if you implement this option, this is the way we expect you to". Sending the wrong response typically is an efficiency violation, so this can stay at a less-than-MUST level. We can turn this into an implementation note if this RFC 2119 usage is too offensive. = ---------------------------------------------------------------------- COMMENT: = ---------------------------------------------------------------------- By section number: 1. The reference to [I-D.ietf-lwig-terminology] worries me, = given that it is not even in LC yet. (See previous note: Now in "waiting for write-up" also on the = datatracker.) 2.1: When a recipient is not able to process a Non-confirmable message, = it may reply with a Reset message (RST). Why is this? If a NON message can't be ACKed, why can it be RST? = This seems like additional machinery for the client. Because Observe benefits from this capability (here the sender is a server): The client might have asked to observe a resource, the sender might be sending occasional updates, and then the client loses its mind (reboots). RST is a quick way to stop the incoming messages. 2.2: the response to a = request carried in a Confirmable message is carried in the resulting Acknowledgement (ACK) message. This is called a piggy-backed response, detailed in Section 5.2.1. [...] If the server is not able to respond immediately to a request = carried in a Confirmable message, it simply responds with an empty Acknowledgement message so that the client can stop = retransmitting the request. When the response is ready, the server sends it = in a new Confirmable message (which then in turn needs to be = acknowledged by the client). It took me a bit to figure out why things worked this way, and I = think a sentence or two of explanation would be useful. A piggy-backed = response to a Confirmable request doesn't itself need to be confirmable = because if the ACK gets lost, the client will re-transmit the request = until it gets the answer. Yes, we could add that explanation. This is at an early stage in the exposition, so we have to figure out how to do this without generating confusion. -> Ticket When the response to a Confirmable request is not piggy-backed, the response should itself be Confirmable, since a Confirmable request will normally want a guaranteed response. Likewise, if a request is sent in a Non-confirmable message, = then the response is usually sent using a new Non-confirmable message, although the server may send a Confirmable message. "Likewise" seems wrong here. A Non-confirmable request can *not* = get an Acknowledgement message, and therefore can *not* get a = piggy-backed response. Additionally, the response MAY be Confirmable or MAY = be Non-confirmable, though certainly Non-Confirmable is the more = likely case. This should probably be reworded. Likewise -> A similar form of separate response is used... -> Ticket 3: Token Length (TKL): 4-bit unsigned integer. Indicates the = length of the variable-length Token field (0-8 bytes). Lengths 9-15 = are reserved, MUST NOT be sent, and MUST be processed as a = message format error. Why not make TKL a 3-bit unsigned integer and have a reserved = padding bit before it? Is this protocol likely to be extended to 9-15 byte = Tokens? The value of the field can be 0-8, so three bits is not enough. (The values of 9-15 are reserved and might be used for something completely different in the future.) Code: 8-bit unsigned integer. Indicates if the message = carries a request (1-31) or a response (64-191), or is empty (0). As above, why not make a 3-bit field for Code Type (000=3Drequest,= 001=3Dreserved, 010=3Dsuccess response, 100=3Dclient error = response, 101 =3Dserver error response, 110/111=3Dreserved), and then a 6-bit = Code? It would also make the registry much easier to read. This requires some surgery but is probably a good idea. -> Ticket 4.2: A Confirmable = message always carries either a request or response and MUST NOT be = empty, unless it is used only to elicit a Reset message. I don't understand the requirement not to be empty, especially = when there is an exception at the end of the sentence. Shouldn't this be = "and contains data bytes unless it is used only to elicit a Reset = message."? "be empty" is a technical term here for code=3D0. 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). I don't understand the second MUST: What other choice is there = besides carrying a response or being empty? Aren't those the only two = options? It could carry a request. The Reset message MUST echo the Message ID of = the Confirmable message, and MUST be empty. Why MUST a Reset be empty? What harm is there if there is data = in there? The code must be 0. Rejecting an Acknowledgement or Reset message is effected by silently ignoring it. I don't understand the above. As far as I can tell, an = Acknowledgement nor a Reset can be rejected; the side that sent them will never = know it is rejected. (That is the technical meaning of "reject" again.) 4.5: All of the MUSTs and MAYs in the section are used rather = terribly. I'm glad to suggest text if you need. This is a difficult section, because it has to express all the lenience that is needed to make very constrained implementations work. Text gladly accepted. -> Ticket 4.6: The phrase "and (by fitting into one UDP payload) obviously = MUST fit within a single IP datagram" is unnecessary, but even if you do = use it, s/MUST/needs to. Done in [1305]. The MUST is not a requirement on an implementation of CoAP. That said, I fear this section is really nothing more than = an implementation note: Because it is a layer violation, it's not = clear to me that any implementer has the ability to figure out much of = this. (For example, the idea that an implementer would be willing to -- or = even know how to -- set the Do Not Fragment bit or figure out the Path MTU = is a bit hopeful.) I have no objection to this section, but it might be = better as an implementation note rather than a set of requirements. It is a bit more than an implementation note, because we are setting expectations for message sizes here. This is a subject that has received quite a bit of discussion, and it seemed the current text has just the right level of firmness. (We really need a 6919bis for this kind of language.) 5.2: I found "indicating a value of 4*32+3, hexadecimal 0x83 or = decimal 131" just adds confusion rather than clarify. Perhaps instead: = "even though if taken as an 8-bit unsigned, the entire Response Code = field would have a value of hexadecimal 0x83 or decimal 131 (4*32+3)". = But personally, I would simply drop it; it doesn't add anything. I'm picking up the "8-bit" and the reordering as an editorial comment = [1306]. (It is not meant to add anything, it's meant as explanatory.) [I'd rather write those in RFC4648 base32hex.] See also comments above on section 3 and below on 12.1. Also: The response codes are designed to be extensible: Response = Codes in the Client Error and Server Error class that are unrecognized = by an endpoint MUST be treated as being equivalent to the generic = Response Code of that class (4.00 and 5.00, respectively). However, = there is no generic Response Code indicating success, so a Response = Code in the Success class that is unrecognized by an endpoint can only = be used to determine that the request was successful without any = further details. First, I suggest changing the first sentence after the colon: = "Response Code details that are unrecognized by an endpoint when the class = is Client Error or Server Error are treated as equivalent to = the...". Much clearer, and the MUST is wrong. Second, I don't see why you = don't simply define a 2.00 so that this can be a bunch simpler. Done the s/MUST be/are/ as [1306]. The non-mention of a 2.00 is intentional: 200 OK is so ingrained that, if we ever mention a 2.00, the HTTP crowd will always send these when we want them to send specific codes such as 2.05 etc. 5.2.3: Potential confusion: s/the client may send a Resent = message/the client will send a Resent message [this is 5.3.2, and about "Reset" messages] Editorial change in [1307] (added a "likely"). 5.4.1: I don't understand the need for the third bullet. Isn't = this already said in the second bullet? The fourth bullet has the = same issue as 2.1 and 4.3. The second bullet is about requests, the third about responses. (And the fourth about either.) 5.4.4 If the option is not present, the default value MUST be assumed. Don't you really mean, "If an option is present with no value, = the value is the default."? No, that is not possible. If it is present, it has a value, and that will be used. The way you have it written sounds like a completely missing option should be assumed to be present and have a = default value. Yes! I don't think that's what you mean. (The MUST is just = superfluous anyway.) Sometimes redundancy is helpful. This is a reminder that those options that do have default values always count as "present", even if they are absent. 5.4.5: If a message includes an option with more occurrences than the = option is defined for, the additional option occurrences MUST be = treated like an unrecognized option (see Section 5.4.1). I think you want to be specific about the order: If a message includes an option with more occurrences than the = option is defined for, any additional option occurrences that appear subsequently in the message MUST be treated like an = unrecognized option (see Section 5.4.1). That is to say, you can't choose to keep later ones and discard = earlier ones. Good clarification. Wordsmithed this into [1308]. 5.4.6: If it were me, I would have put the NoCacheKey bits in = the high four bits so that you could simply do a <224 test for = cache-matching options. I suppose this ship has sailed. Option numbers have more than 8 bits... 5.5.1: The implementation note notwithstanding, I don't = understand why Content-Format is not a SHOULD. This is another one of these hard-to-calibrate-the-lenience things. The "why" is right there, though: This is not a "SHOULD"-level requirement solely because it is not a protocol requirement, and it also would be difficult to outline exactly in what cases this expectation can be violated. 5.7.1: If a response is generated out of a cache, it MUST be = generated with a Max-Age Option that does not extend the max-age originally = set by the server The reverse would be clearer: If a response is generated out of a cache, the generated = Max-Age Option MUST NOT extend the max-age originally set by the = server (This was trying to say that you probably MUST generate the option...) Wordsmithed this into [1309]. Also: "a proxy SHOULD be conservative" s/SHOULD/should. There's = nothing to implement here. Hmm, I'm not sure I want to get rid of this 2119 abuse here. [Maybe change it to RFC 6919 OUGHT TO?] But really, you may want to implement some network-delay--based fudge = factor here. 5.10.5 s/MUST/is. The MUST is not meaningful. You MAY consider it unfresh at any time, but MUST consider it unfresh after Max-Age expires. It sure means something to me. 8.1: A server SHOULD be aware that a request arrived via multicast, = e.g. by making use of modern APIs such as IPV6_RECVPKTINFO = [RFC3542], if available. That SHOULD is not meaningful. It is useful, not required with = exceptions (as SHOULD indicates), for the server to know that it is using multicast. This really means "A server SHOULD spend the effort needed to be aware"... (The exception to the SHOULD being that it may not be possible in in a RFC 3542 challenged host.) This also gives a reason not to allow RST on *any* NON messages. Trade-Off. We really want those RSTs with Observe. 8.2: "the server MAY always pretend"? We are getting sillier = with our 2119 usage later in the document. Did you really mean, "the = server MAY ignore the request"? Isn't that true of any NON request, not = just multicast ones? Yes, but this section is giving a server specific license to discard incoming multicast at the slightest discomfort. We don't want to say the same for every NON. This certainly can be said in a better way -> Ticket (I did not do an significant review of sections 9 or 11.) 12.1: As mentioned regarding section 3 and 5.2 above, I think it = would be much easier to figure these out if you separated out the bit = fields of code type and code, and then had sub-registries for request = codes, success codes, client error codes, and server error codes. (Yes, see ticket on 3 above.) From cabo@tzi.org Thu Apr 25 04:26:45 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7E421F95F4; Thu, 25 Apr 2013 04:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCCYZJQZAq+J; Thu, 25 Apr 2013 04:26:43 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 67B8621F84F6; Thu, 25 Apr 2013 04:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r3PBQbmR008836; Thu, 25 Apr 2013 13:26:37 +0200 (CEST) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3936F34C1; Thu, 25 Apr 2013 13:26:37 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <20130424092228.10345.76059.idtracker@ietfa.amsl.com> Date: Thu, 25 Apr 2013 13:26:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8C88F8A7-9B07-4D82-8EA8-89794BD32EFC@tzi.org> References: <20130424092228.10345.76059.idtracker@ietfa.amsl.com> To: Martin Stiemerling X-Mailer: Apple Mail (2.1503) Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, The IESG , core@ietf.org Subject: Re: [core] Martin Stiemerling's Discuss on draft-ietf-core-coap-15: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Apr 2013 11:26:45 -0000 Hi Martin, thanks for this detailed review. I have done some of the changes as simple editorial fixes, these are marked like [1310] below and can be reviewed in http://trac.tools.ietf.org/wg/core/trac/changeset/1310 (Overview in http://trac.tools.ietf.org/wg/core/trac/timeline). Some of the replies are marked "-> Ticket": This means that the authors think that the change is a good idea, but probably needs a bit more discussion with the WG, so we will handle this as a ticket. Gr=FC=DFe, Carsten = ---------------------------------------------------------------------- DISCUSS: = ---------------------------------------------------------------------- A well-written document and I have a few points to discuss.=20 The congestion avoidance mechanisms look ok, but I assume we = will get feedback from implementers and deployments on the parameters and mechanisms. It would be good to get this feedback documented at = some point.=20 Indeed, this will require active attention by the WG. Fortunately, researchers are looking at this, and I expect additional results to become available soon. Here are the issues (based on my own review and input from Joe = Touch and Michael Scharf): 1) IPv6 UDP checksum calculation It is not clear if zero UDP checksums are permitted or not = permitted with COAP.? (UDP zero checksums: https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/) That should be specified. 2) Handling of UDP-lite Can UDP-lite (RFC 3828) be used or cannot be used in conjunction = with CoAP? Re 1 and 2: We just had a bit of discussion on the WG list, because we never had considered this. The consensus seems to be that CoAP will be used on a wide variety of systems, and neither host support nor support e.g. in RFC 6282 is available. (Citing from the discussion: "They seem to be specialized optimizations that are not well deployed and somehow seem to add overall deployment complexity and performance risk to the solution even if they provide some CPU reduction.") I don't actually think we need to say anything new in the draft because UDP is distinct from UDP-lite and we are not referencing 3828; neither do we reference 6936-to-be, so we are stuck with the features in 0768 and 2460. (I also believe the discusion in 6936 puts CoAP out of its own scope.) But, of course, we would be open to suggested text. 3) Fragmentation of messages The recommendation in Section 4.6 about the path MTU is = generally valid only for IPv6. For IPv4, 567 bytes is the safe area to work = without fragmentation, though in today WANs 1280 work perfectly, but I = am not so sure about the networks envisioned for CoAP. This 576 bytes for = IPv4 are mentioned in the implementation note, but deserves text on the = same level as for IPv6.=20 IPv4 simply hasn't received a lot of attention here. The more normative text is about message size selection; there should be little practical difference between IPv4 and IPv6 here. The 576 byte MRU is more of a theoretical value. IPv4 implementations will have live with IP layer fragmentation for the larger message sizes just as 6LoWPAN will have to live with adaptation layer = fragmentation. 4) Ensuring no fragmentation with IPv4 The implementation note in Section 4.6 states that for IPv4 it = is 'harder to ensure that there is no IP fragmentation'. This neglects the possibility of using the Don't Fragment (DF) flag in the IPv4 = header and also that there is possibly feedback from a node enroute that = the MTU is too big if the DF flag is set, i.e., by means of an ICMP error = message.=20 Should there be any recommendation or protocol machinery to deal = with path probing? E.g., referencing RFC 4821 (PMTUD).=20 CoAP is meant to be operable without persistent state between exchanges. Normal operation of CoAP in constrained implementations (if they even implement IPv4) will not use DF. More advanced implementations may be able to keep state about peers; it should be pretty obvious how to do this (and will generally be combined with establishing congestion control state). I have added a reference to RFC 4821 to the discussion of path MTU discovery [1310]. 5) Reaction to network errors that are signalled I wonder why the draft is not discussing any reaction to network = failures signalled through ICMP messages. This relates also to my DISCUSS = issue no 4.=20 We didn't find much guidance in existing UDP-based protocols on handling ICMP messages. RFC5405 section 3.7 is on a level of "can utilize", and the practical problems of robustness and validation of messages (including against attacks) make handling ICMP messages in constrained implementations difficult. In any case, even advanced forms of ICMP handling are unlikely to impact CoAP protocol processing beyond improved local error handling, so we believe the subject is best left to a point in time when more operational experience is available. 6) Idempotency The discussion of idempotency is useful, but overlooks message = order. I.e., the discussion appears to assume that a sequence of the = same actions has the same effect as a single action, but this is true = only if different sets of actions (from different sources, or copies of = different actions from a single source) aren't interleaved. This should be addressed.=20 The CoAP specification generally does not attempt to explain all the relevant concepts of the Web, but defers to other specifications. Section 9.1.2 of RFC2616 contains a discussion about sequences of idempotent method executions. Section 9.1 is explicitly referenced from section 5.1, which is the main section discussing idempotence. 7) Protocol reactions to reserved or prohibited values Regarding reserved or prohibited values in the IANA section, it = would be useful to be clear about what happens when those values are = seen. I.e., should they be ignored, generate an error, etc. Good point. We need to check this in detail. -> Ticket. 8) Flow Control/Receiver Buffer The protocol does not have any real means for the receiver to = control the amount of data that is being sent to it. I can understand the = attempt to provide a simple protocol, but adding a very basic flow control = mechanism will not prohibitively increase the complexity of the protocol, = while improving robustness.=20 According to Section 2.1, a node can always return a RST if the = message cannot be process for whatever reason.=20 I propose to add an option to the RST message that allows the = message receiver to state how much data it is willing to accept from a = particular sender or in general (up to the implementation). =20 (RST messages are empty messages and cannot have options.) CoAP servers currently perform load shedding by not reacting to an incoming message at all. Note that an 5.03 error can also set the Max-Age option in place of the "Retry-After" known from HTTP (section 5.9.3.4). There has been discussion on more explicit feedback for load shedding, e.g., draft-greevenbosch-core-minimum-request-interval-00; currently, the WG feels that finding a good solution (or even understanding the problem space) for this requires more study (see minutes from Orlando, where we discussed Bert's draft). 9) Handling a wrapping message IDs According to 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)" with EXCHANGE_LIFETIME of 247s.=20 By now it is unrealistic that the message ID of 16 bits will = wrap around in that time frame, but protocols live long and at some later = time it can be possible.=20 However, the protocol doesn't have any means to detect wrapped = message IDs. Indeed, the onus is on the sender to ensure that the Message ID does not wrap around within EXCHANGE_LIFETIME. In contrast to, say, the IPv4 IP ID, the potential problem of Message ID reuse has been well-highlighted, and it is receiving additional attention in the LWIG drafts that are starting to provide guidance on CoAP implementation. Implementations that need more than ~ 250 messages per second (per peer endpoint) may need to use multiple source endpoints. We don't think much more can be or should be done here. = ---------------------------------------------------------------------- COMMENT: = ---------------------------------------------------------------------- 1) Endpoint vs. host=20 This document uses the term "endpoint" to refer to the = combination of address and port, and possibly also security association, that = is local to one end of an association. I would have expected the more = common term "socket", as originated in TCP parlance, to be used instead = (even though here the term is used in a connectionless context).=20 Most implementers have a quite different idea of a "socket", so this language would be rather confusing for them. The authors might have used "transport address", but "endpoint" seemed shorter. 2) Reaction to network errors due to local link errors Link layers can give some hints if the link is up, down, etc. Traditionally, this has not been taken into account too much = when design transport protocols, but wouldn't it make sense to take it into = account for CoAP, as it is much more working in constrained = environments? As a quality of implementation issue: certainly. I also expect this to come up in the LWIG work. But how would it impact the CoAP specification? 3) Short messages Section 3., paragraph 1: CoAP is based on the exchange of short messages which, by = default, are transported over UDP (i.e. each CoAP message occupies the = data section of one UDP datagram). CoAP may also be used over = Datagram What are short messages in terms of bytes? Is this a hidden = protocol requirement? Section 4.6 discusses message sizes and should leave the implementer with a pretty good idea what message sizes are a good fit for CoAP. I don't think forward-referencing to 4.6 from section 3 is necessary. 4) randomization of message IDs Section 4.4., paragraph 3: 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 (note that some receiving endpoints = may not be able to distinguish unicast and multicast packets = adressed to it, so endpoints generating Message IDs need to make sure = these do not overlap). The initial variable value should be = randomized. the initial variable SHOULD be randomized, just to avoid blind = off path attacks, right? Yes. We are trying to avoid RFC 2119 language in the implementation = notes. Since this is about a variable that only exists in a specific implementation strategy, a SHOULD wouldn't work very well, anyway. 5) In Section 4.6.: larger than an IP fragment result in undesired packet = fragmentation. should read larger than an 'IP packet' instead of 'IP fragment'. Indeed, [1311]. 6) Section 5.4.1., paragraph 7: Critical/Elective rules apply to non-proxying endpoints. A = proxy processes options based on Unsafe/Safe classes as defined in Section 5.7. I suggest moving this statement to the beginning of this = subsection, as it provides important information that shouldn=92t be = missed. Since the entire next subsection also discusses the subject, I think there is little danger that this will be missed. (Putting the exception early confuses the section, so I would like to avoid this change.) 7) Dependency between application layer and CoAP Section 5.2.2., paragraph 2: The server maybe initiates the attempt to obtain the resource representation and times out an acknowledgement timer, or it immediately sends an acknowledgement knowing in advance that = there will be no piggy-backed response. The acknowledgement = effectively is a promise that the request will be acted upon. This may or may not be an issue: Assuming that the server did sent an ACK for a request but is = never ever fulfilling its promise to send any real 'response'. The = request/response initiated from the client is done on the CoAP level, but not for = the application on top.=20 Is there any recommendation for the application on top of CoAP = how to handle such cases? Generally, we would expect applications to handle this in similar ways they are handling other application-layer timeouts. E.g., many e-mail and web applications timeout requests after a time on the order of a minute. We think this is another issue best left for discussion after some operational experience is available. From cabo@tzi.org Thu Apr 25 05:54: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 BAC8D21F95FB for ; Thu, 25 Apr 2013 05:54:00 -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 4fa8rNIZi4dw for ; Thu, 25 Apr 2013 05:53:58 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB9121F95E1 for ; Thu, 25 Apr 2013 05:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r3PCrqOo010106 for ; Thu, 25 Apr 2013 14:53:52 +0200 (CEST) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A965E35AA; Thu, 25 Apr 2013 14:53:52 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Apr 2013 14:53:52 +0200 To: "core@ietf.org (core@ietf.org)" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [core] TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Apr 2013 12:54:08 -0000 All, can you give me a quick status about how far we got with interop-testing = TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8? (I'm interested both specifically in conjunction with CoAP/DTLS and = about that cipher suite in general.) Gr=FC=DFe, Carsten From zach@sensinode.com Thu Apr 25 07:03:22 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA1621F9619 for ; Thu, 25 Apr 2013 07:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.130, 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 832EEK4QWuhV for ; Thu, 25 Apr 2013 07:03:22 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id AFA5121F9612 for ; Thu, 25 Apr 2013 07:03:21 -0700 (PDT) Received: from [192.168.1.100] (87-95-85-145.bb.dnainternet.fi [87.95.85.145]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r3PE3HrA006195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Apr 2013 17:03:18 +0300 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: Date: Thu, 25 Apr 2013 17:03:16 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7CA25262-22FA-4D81-A881-ADB7223B5705@sensinode.com> References: To: Carsten Bormann X-Mailer: Apple Mail (2.1503) Cc: "core@ietf.org \(core@ietf.org\)" Subject: Re: [core] TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Apr 2013 14:03:22 -0000 On Apr 25, 2013, at 3:53 PM, Carsten Bormann wrote: >=20 > can you give me a quick status about how far we got with = interop-testing TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8? > (I'm interested both specifically in conjunction with CoAP/DTLS and = about that cipher suite in general.) ZigBee IP uses this same cipher suite with TLS, and that has been = through a long period of interop and conformance testing. Just recently = a bunch of vendors completed the first ZigBee IP certification. So = definitely working there. 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 d.sturek@att.net Thu Apr 25 07:35:20 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFAE021F90A1 for ; Thu, 25 Apr 2013 07:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNvdYN1y3nv5 for ; Thu, 25 Apr 2013 07:35:19 -0700 (PDT) Received: from nm3.access.bullet.mail.mud.yahoo.com (nm3.access.bullet.mail.mud.yahoo.com [66.94.237.204]) by ietfa.amsl.com (Postfix) with ESMTP id 257C821F9079 for ; Thu, 25 Apr 2013 07:35:19 -0700 (PDT) Received: from [66.94.237.192] by nm3.access.bullet.mail.mud.yahoo.com with NNFMP; 25 Apr 2013 14:35:18 -0000 Received: from [98.138.104.98] by tm3.access.bullet.mail.mud.yahoo.com with NNFMP; 25 Apr 2013 14:35:18 -0000 Received: from [127.0.0.1] by smtp118.sbc.mail.ne1.yahoo.com with NNFMP; 25 Apr 2013 14:35:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1366900518; bh=/+dJSmZfBcVBTOHdijNdckBNBNSI0yxVSNSEutSchTM=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=g9mzPu6c4BtnUKzqCQMoMVxcNcs1KhzyQKzgsqepQtzqFn3qWy/b1Fc9c/DFG9ChbiF+ZDJn02+KaW0IBxRJdoxcD/CxOFsuCNb8pjEoukvhAvTEQcHEBPZMymitL6FAaICrvuIgoGOhTPkHDry0sEuyyQbaQMj/4uGeibujMrE= X-Yahoo-Newman-Id: 609090.8224.bm@smtp118.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: AZwVZ8sVM1lqrmqefh2Cj7tH6_N8.RNcdr1Lh8DiHEydsZV GmilLrQHvrG76Ocld8nic3WILfdr3ScGvoIzkND1ThqewqbZnvKUvzXNz6ac kZnsycIODuCs7l6wpTgRij9pprZwGoPoYE3HW_JknCtlAx94oC1kLOC67zIo Zg6m1YZGN.sOYNETR3E.yxoFZ8d0YVWOZy3.xNzIJ6wydP0MOqtgd5QGVjzi oj3luM5_70afLKeg9oytb2RPO7EjzTPOH.HzYYRMuxYSO7j1pu592om8eHFQ i.pqa6nfBpXWESULpJo0k3JpJqFke9wE8CPhcz5JTNpeP13ryjVAV2vtjx31 xvLxeVAem4gLCBTx0mZPDAALfMT_hoWINIepJllJc0CbBwyRC1Wsav.Vv.ix 92v1i_BT65xu2SpW0DuTo4hABiLQh6cvo7r6kU8jnpfCcepJgzWwBj3nsQ3x 7c7JhnEUL98Tue9TihZqC26VkpbMOxupnxJvsaTv1teaPJ6shb4InRoNrx54 t3lHpoHhbzO0Tn3Dr44yaevrn4tkQbdB9KWwIX9jd0JIQzt3plN15H9IYrax f6Vce9E_o60PLAd7BnIxpXsGtbTGz5rmUv66wNkzAgXLfL4TP5tuJLqkU0K7 AacAGctl3l2B5UZ8NpJ5F6Qe0FT7cxWBtt9r_uEq6r_veQZw5JH4dUBwAg.I RpXPEb0jaQbqq0LnnFjZ3yKALWBTe9h7nZWxQXLBzcRF4ydxEBIpbKB7x1Qm xQRl2gpct74XQ.O.geyg- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [192.168.0.198] (d.sturek@69.105.138.166 with login) by smtp118.sbc.mail.ne1.yahoo.com with SMTP; 25 Apr 2013 14:35:18 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.2.130206 Date: Thu, 25 Apr 2013 07:35:15 -0700 From: Don Sturek To: Zach Shelby , Carsten Bormann Message-ID: Thread-Topic: [core] TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 In-Reply-To: <7CA25262-22FA-4D81-A881-ADB7223B5705@sensinode.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "core@ietf.org \(core@ietf.org\)" Subject: Re: [core] TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Apr 2013 14:35:20 -0000 To back up what Zach mentioned, we have the following companies who completed ZigBee IP certification using TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8. Here is a note on the specification which is now available publicly: http://www.greentechmedia.com/articles/read/zigbees-ipv6-compatible-spec-go es-live Five companies completed the first round of ZigBee IP certification, including: Texas Instruments, Sensinode, Grid2Home, Exegin, and Silicon Labs. Additionally, for SEP 2.0 (the application portion residing over ZigBee IP), we will use the same cipher suite for HTTPS/TLS. There are currently around 10 companies involved in interoperability testing (some of the same companies as for ZigBee IP plus some additional end product, Wi-Fi and HomePlug companies) Don On 4/25/13 7:03 AM, "Zach Shelby" wrote: >On Apr 25, 2013, at 3:53 PM, Carsten Bormann wrote: >> >> can you give me a quick status about how far we got with >>interop-testing TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8? >> (I'm interested both specifically in conjunction with CoAP/DTLS and >>about that cipher suite in general.) > > >ZigBee IP uses this same cipher suite with TLS, and that has been through >a long period of interop and conformance testing. Just recently a bunch >of vendors completed the first ZigBee IP certification. So definitely >working there. > >Zach > >-- >Zach Shelby, Chief Nerd, Sensinode Ltd. >http://www.sensinode.com @SensinodeIoT >Mobile: +358 40 7796297 >Twitter: @zach_shelby >LinkedIn: http://fi.linkedin.com/in/zachshelby >6LoWPAN Book: http://6lowpan.net > > > > >_______________________________________________ >core mailing list >core@ietf.org >https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Fri Apr 26 03:36: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 974D321F989F for ; Fri, 26 Apr 2013 03:36:51 -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 m0Jim1NoQ8DX for ; Fri, 26 Apr 2013 03:36:51 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id BC97821F982F for ; Fri, 26 Apr 2013 03:36:50 -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 r3QAag9H023705 for ; Fri, 26 Apr 2013 12:36:42 +0200 (CEST) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 905633B9F; Fri, 26 Apr 2013 12:36:42 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Carsten Bormann In-Reply-To: <20130426092352.870.74099.idtracker@ietfa.amsl.com> Date: Fri, 26 Apr 2013 12:36:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130426092352.870.74099.idtracker@ietfa.amsl.com> To: "core@ietf.org (core@ietf.org)" X-Mailer: Apple Mail (2.1503) Subject: Re: [core] I-D Action: draft-greevenbosch-core-minimum-request-interval-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 10:36:51 -0000 Bert: Thanks for updating this. I referred to the -00 in my reply to Martin Stiemerling's IESG comments. There were some comments in the Orlando meeting that people didn't quite = know when to use such an Option and how to find a good value to put in = it. (I think we need to check whether there is a better metric to use for = throttling/load shedding than the elapsed time between two requests.) It would probably help to look at the use cases in some more detail. = What specifically is a server trying to achieve by limiting the request = interval? What kind of metric aligns best with such an objective? Just to build a very rough strawman for such an alternative metric:=20 A server could ask a client to send the next request only after twice = the time it took the client to obtain the previous response. (This would figure in network load in a way that the server on its own = cannot do.) Another issue is the scope of the throttling: Is it for a single = resource, this endpoint, the IP address, a prefix (say, a /64)? (Wider scopes have more security implications.) Gr=FC=DFe, Carsten On Apr 26, 2013, at 11:23, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : CoAP Minimum Request Interval > Author(s) : Bert Greevenbosch > Filename : = draft-greevenbosch-core-minimum-request-interval-01.txt > Pages : 8 > Date : 2013-04-26 >=20 > Abstract: > This document defines an "Minimum-Request-Interval" option for CoAP, > which can be used to negotiate the minimum time between two > subsequent requests within a single client and server pair. It can > be used for flow and congestion control, reducing the consumption of > server and network resources when needed. >=20 > Note >=20 > Discussion and suggestions for improvement are requested, and should > be sent to core@ietf.org. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-greevenbosch-core-minimum-request-i= nterval >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-greevenbosch-core-minimum-request-interva= l-01 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-greevenbosch-core-minimum-request= -interval-01 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 From kovatsch@inf.ethz.ch Fri Apr 26 06:43:11 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFCA21F9982 for ; Fri, 26 Apr 2013 06:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kL8iMf2q7VaL for ; Fri, 26 Apr 2013 06:43:10 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 136D921F9981 for ; Fri, 26 Apr 2013 06:43:08 -0700 (PDT) Received: from CAS21.d.ethz.ch (172.31.51.111) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Fri, 26 Apr 2013 15:42:56 +0200 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS21.d.ethz.ch ([fe80::55ba:c4a5:d8a7:ab62%10]) with mapi id 14.02.0298.004; Fri, 26 Apr 2013 15:43:05 +0200 From: "Kovatsch Matthias" To: Carsten Bormann , "core@ietf.org (core@ietf.org)" Thread-Topic: [core] TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 Thread-Index: AQHOQbQN6yP7wQs7dUy7t/ET54O3P5johBpw Date: Fri, 26 Apr 2013 13:43:05 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514EA02A7@MBX20.d.ethz.ch> References: In-Reply-To: Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.10.67.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 26 Apr 2013 13:43:11 -0000 > can you give me a quick status about how far we got with interop-testing > TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8? > (I'm interested both specifically in conjunction with CoAP/DTLS and about > that cipher suite in general.) Californium has a full CoAPS implementation (PSK, ECDHE, RawPublicKeys, Cer= tificates): https://github.com/mkovatsc/Californium We had DTLS interops with Bremen (TinyDTLS), SICS (JCoAP + own DTLS), and S= ilicon Labs (own DTLS, unknown CoAP). PSK worked with all of them. ECDHE was tested successfully with SICS and Silicon Labs. Mutual Authentication was working with SICS. Fragmentation and RawPublicKeys could not be tested for interoperability wi= th others so far, but it works with Californium only nodes. Everything to the best of my knowledge of course. There might be more imple= mentations I am not aware of. Ciao Matthias From hauke@hauke-m.de Fri Apr 26 08:48:20 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C00E21F9940 for ; Fri, 26 Apr 2013 08:48:20 -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 Uy3YvDiqlh9e for ; Fri, 26 Apr 2013 08:48:19 -0700 (PDT) Received: from hauke-m.de (Hauke-2-pt.tunnel.tserv6.fra1.ipv6.he.net [IPv6:2001:470:1f0a:465::2]) by ietfa.amsl.com (Postfix) with ESMTP id 88C2521F993D for ; Fri, 26 Apr 2013 08:48:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hauke-m.de (Postfix) with ESMTP id 5BBAD8F61; Fri, 26 Apr 2013 17:48:18 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at hauke-m.de Received: from hauke-m.de ([127.0.0.1]) by localhost (hauke-m.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xARHjAM5YpVh; Fri, 26 Apr 2013 17:48:09 +0200 (CEST) Received: from [IPv6:2001:470:1f0b:447:194a:7206:f949:e8ab] (unknown [IPv6:2001:470:1f0b:447:194a:7206:f949:e8ab]) by hauke-m.de (Postfix) with ESMTPSA id 06722857F; Fri, 26 Apr 2013 17:48:08 +0200 (CEST) Message-ID: <517AA1B6.8020104@hauke-m.de> Date: Fri, 26 Apr 2013 17:48:06 +0200 From: Hauke Mehrtens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Kovatsch Matthias References: <55877B3AFB359744BA0F2140E36F52B514EA02A7@MBX20.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514EA02A7@MBX20.d.ethz.ch> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "core@ietf.org \(core@ietf.org\)" Subject: Re: [core] TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 26 Apr 2013 15:48:20 -0000 On 04/26/2013 03:43 PM, Kovatsch Matthias wrote: >> can you give me a quick status about how far we got with interop-testing >> TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8? >> (I'm interested both specifically in conjunction with CoAP/DTLS and about >> that cipher suite in general.) > > Californium has a full CoAPS implementation (PSK, ECDHE, RawPublicKeys, Certificates): > https://github.com/mkovatsc/Californium > > We had DTLS interops with Bremen (TinyDTLS), SICS (JCoAP + own DTLS), and Silicon Labs (own DTLS, unknown CoAP). > PSK worked with all of them. > ECDHE was tested successfully with SICS and Silicon Labs. > Mutual Authentication was working with SICS. > Fragmentation and RawPublicKeys could not be tested for interoperability with others so far, but it works with Californium only nodes. > > Everything to the best of my knowledge of course. There might be more implementations I am not aware of. As already discussed off list I am currently working on adding support for TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and RawPublicKeys to TinyDTLS. I got an initial handshake with Californium working, currently I implemented the minimal feature set to do so, ECDSA signature generation and verification is still missing. Californium currently just supports RawPublicKeys in draft version 06, but the current version is 07 and there are incompatible changes between these versions in the client and server hello extensions. Hauke From johnsonhammond2@hushmail.com Sat Apr 27 10:09: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 AB5D021F9810 for ; Sat, 27 Apr 2013 10:09: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 e6YjcdO+IO5k for ; Sat, 27 Apr 2013 10:09:48 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6A95021F980F for ; Sat, 27 Apr 2013 10:09:48 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by smtp2.hushmail.com (Postfix) with SMTP id 1FAB8E7C1B for ; Sat, 27 Apr 2013 17:09:48 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp2.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:09:47 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 6A9B614DBDE; Sat, 27 Apr 2013 17:09:47 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:09:47 -0400 To: core@ietf.org From: johnsonhammond2@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427170947.6A9B614DBDE@smtp.hushmail.com> Subject: [core] Biggest Fake Conference in Computer Science X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 27 Apr 2013 18:10:50 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From cabo@tzi.org Sat Apr 27 12:33:46 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B465A21F95F0; Sat, 27 Apr 2013 12:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.949 X-Spam-Level: X-Spam-Status: No, score=-103.949 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_EMAIL=2.3, MANGLED_LIST=2.3, 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 JvBKa08w1E6U; Sat, 27 Apr 2013 12:33:45 -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 98F4E21F95EC; Sat, 27 Apr 2013 12:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r3RJX6s5009248; Sat, 27 Apr 2013 21:33:06 +0200 (CEST) Received: from [192.168.217.105] (p54894F53.dip0.t-ipconnect.de [84.137.79.83]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6BF443F90; Sat, 27 Apr 2013 21:33:05 +0200 (CEST) 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: <20130425012605.7589.40567.idtracker@ietfa.amsl.com> Date: Sat, 27 Apr 2013 21:33:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130425012605.7589.40567.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.1503) Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, The IESG , core@ietf.org Subject: Re: [core] Stephen Farrell's Discuss on draft-ietf-core-coap-15: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 27 Apr 2013 19:33:46 -0000 Stephen, thank you for this comprehensive review. I have done some of the changes as simple editorial fixes, these are marked like [1316] below and can be reviewed in http://trac.tools.ietf.org/wg/core/trac/changeset/1316 (Overview in http://trac.tools.ietf.org/wg/core/trac/timeline). Some of the replies are marked "-> Ticket": This means that the authors think that the change is a good idea, but probably needs a bit more discussion with the WG, so we will handle this as a ticket. Gr=FC=DFe, Carsten = ---------------------------------------------------------------------- DISCUSS: = ---------------------------------------------------------------------- I will end up balloting yes for his. I think its good work and has lots of implementations. Note also that some of the discuss points here should be easily resolved or are just checking stuff. (Its in the nature of very very long documents ... that they get longer with each review cycle, and ... that the accumulation of such stuff generates more discuss points.) Anyway, let's discuss... (1) 2.3: What if the URI scheme doesn't have a host or port or path or query? Also in 5.6, 2nd bullet in list: Just to note that if you were using ni URIs with CoAP, then you no longer need to insist on exactly the same URI (e.g. the authority part needn't matter with ni URIs, the alg-val part is what counts). That might be true of other schemes too, so perhaps this statment is scheme specific to some extent? That is a very good point. I think what happens here is that some schemes such as the ni scheme open a way of matching that is specific to that scheme and not available in the default case. We should add a statement to this effect to the definition of "Cache-Key" that needs to be added at the end of this section. Add at the end of (the introduction to) 5.6: =BBThe set of options that is used for matching the cache entry is also collectively referred to as the "Cache-Key". For URI schemes other than coap and coaps, matching of those options that constitute the request URI may be performed under rules specific to the URI scheme.=AB -> Ticket This is just a discuss point to check that you're ok with CoAP being restricted to some URI schemes in this manner, the ni URI case is just an example I happen to know fairly well:-) So I'll clear this one when told that this is considered acceptable but I want to check the general issue about uri-scheme dependencies for CoAP. The same point occurs in 5.7.1 and maybe elsewhere btw. So basic point is: please provide some sensible description of which URI schemes can be used with CoAP and which cannot. The specification defines two URI schemes, coap and coaps. It is probably a good idea to start some thinking about how RFC 6920 can be used, but that should be a separate specification. So, I think, the answer is "any URI scheme defined to use the CoAP protocol". Do we need to state this explicitly? (2) 4.2, "when the timeout is triggered" - what happens with sleepy nodes that only wake on external events, and where e.g. if 2 timeouts have elapsed whilst asleep? Not sure if odd behaviour of that kind could cause much harm, but was it considered? This could also affect the definition in 4.8.2 of MAX_TRANSMIT_SPAN. The intention is that retransmissions stay in the overall envelope of MAX_TRANSMIT_SPAN, even if they are not perfectly spaced. Indeed, this could benefit from some additional discussion. -> Ticket (3) 4.2, last para: this creates an attack that can work from off-path - just send loads of faked ACKs with guessed Tokens and some of 'em will be accepted with probability depending on Token-length and perhaps the quality of the RNG used by the sender of the CON. That could cause all sorts of "interesting" application layer behaviour. Why is that ok? (Or put another way - was this considered and with what conclusion?) Actually, the ACK would be matched on the Message ID (or I could simply point to the penultimate paragraph of 5.3.1). This is a relatively powerful attack that could be added to the list in 11.4. -> Ticket I suspect you need to have text trading off the Token length versus use of DTLS or else CoAP may end up too insecure for too many uses. (Note: the attack here is made worse because the message ID comparison can be skipped. Removing that "feature" would help a lot here.) 5.3.1's client "may want to use a non-trivial, randomized token" doesn't seem to cut it to me. How does this kind of interaction map to DTLS sessions/epoch? Basically, I'd like to see some RECOMMENDED handling of token length that would result in it not being unsafe to connect a CoAP node to the Internet. (And please note recent instances where 10's of thousands of insecure devices have been found via probing the IPv4 address space. These are real attacks.) Well, ceterum censeo BCP39. But it seems the discussion at the end of 5.3.1 could make the security considerations for selecting a token value in NoSec mode more explicit. Right now the basic consideration, but not the parameters that go into it, is discussed in 11.4 as well. -> Ticket (4) 4.4, implementation note - this seems unwise since it means that once Alice has interacted with Bob, then Bob can easily guess the message IDs that Alice will use to talk to Charlie. Not every CoAP client will have the means to keep state per peer server. (It is not quite "once Alice has interacted", because the initiator of an exchange chooses the Message ID. But it is often not too hard to trick Alice into initiating an exchange.) (5) 4.6, last para - this only applies to insecure uses of CoAP, you should point that out "can" is indeed probably too strong. -> Ticket (6) 6.2 - "the UDP datagrams MUST...use DTLS" is fine but maybe not enough, if the request uses DTLS then presumably so MUST *all* response messages, and they MUST use the same DTLS session? Or perhaps one with the same authenticated endpoints. Don't you need to say that? If you don't then just sending the request via DTLS but getting (some) response messages in clear would seem to be allowed. I think 9.1 might cover all the above, but want to just check. This is implicit in the fact that all exchanges (except for multicast) use the same pair of endpoints for both directions, so you simply can't reply via NoSec to a DTLS message. It probably doesn't hurt to make that explicit somewhere. -> Ticket. (7) 9.1.1, 1st para: what is "the server" - is that the destination host from the URI? If yes, then fine. If no, then we need to DISCUSS that.=20 Yes, it is. (8) 9.1.3.3 - "signed by an appropriate chain of trust" is an odd phrase - do you mean it MUST be validated as per RFC 5280 section 6? If so, say so. If not, say what you do mean. (But we might need to talk about it in that case, depending;-) We probably should say: The certificate MUST be validated as appropriate for the security requirements, using functionality equivalent to the algorithm specified in RFC5280 Section 6. -> Ticket. (9) 9.1.3.3 - you don't mention certificate status checking. I can see why that's hard to impossible in some n/w's but entirely ignoring it seems wrong. Perhaps call out the vulnerability and point at OCSP stapling as a potential solution, but one that requires further work and/or further specification? Yes, we should point this out. -> Ticket (10) 10.1 - what does https mean here? If it means that the request/response are in clear between the source and proxy and then encrypted then a) you really really need to say that clearly and b) why is that even acceptable and c) what if the destination resource requires client auth? Well, it is way worse, because the proxy needs to decide on the security policy that it wants to apply to the TLS connection underlying HTTPS. This kind of proxy function only makes sense if the proxy has a legitimate role in the trust chain, e.g. as a domain boundary controller. In constrained node networks, this is actually a likely use case. It just seems broken to pretend to use https this way. Going via a cross-proxy breaks security. Similarly, what does coaps mean in 10.2? Again, doing this kind of proxying only makes sense if the proxy has a legitimate role. = ---------------------------------------------------------------------- COMMENT: = ---------------------------------------------------------------------- general: 112 pages, sheesh;-) Seriously though, there is repetition here that'd be better not there and fewer words is better. Too late now though. (See above...) abstract: "CoAP easily..." is a bit of sales-talk, better to say "CoAP is designed to easily..." [1316] intro, 2nd para: better to not talk about the WG name and its work really, but about the resulting protocol We used the "CoRE" tag in RFC 6690, and would like to continue using it, for the overall architecture that the CoAP protocol is a part of. (If that is a problem, please rename all MPLS documents first :-) intro, 2nd para: suggest s/limiting the use of/limiting the need for/ [1317] intro, last para: more sales pitch language But it's all true and not even exaggerated! 1.2, critical option - I wondered here if proxies have to know these or just client & server. "Endpoint receiving the message" doesn't make that (ctystal) clear. "Unsafe Option" made me wonder more. (It is clear later.) Hmm. See my attempt in [1320]. 2.2: This is the first time Token is used. Might be no harm to distinguish that explicitly from Message ID. [1318] 2.3: For what "security reason" are proxies useful?=20 The domain boundary controller one (see above). 3: Ver field "MUST set this field to 1" - I guess someone might set both bits to 1, so saying '01'B might be better. [1319] Section 3: I didn't see where Message ID wrap-around was described. I see Martin has a discuss on that which I support. (See my reply there.) 3: Message ID - with 16 bits that imposes a rate limit on how often you can send.=20 The rate limit is ~ 250 messages per second per pair of endpoints with default parameters. I don't think that's described It will be described in the LWIG documents that are discussing Message ID management in more detail. and I'm curious as to whether it'd set to max goodput for CoAP that'd be way less than otherwise possible with e.g. HTTP. Answer: Yes. (~ 250 KiB/s with default parameters and large messages; 20 kB/s with more realistic 80-byte messages.) If you need faster, please use TCP (you will get better congestion control, too). 3.2: So I can't have an option with a uint value where missing !=3D 0? Might be worth saying. I'm not sure I'm decoding this sentence correctly, but a present option with a zero-byte uint (value 0) is distinguishable from an absent option. E.g., Max-Age has a default value (that is used if the option is absent) of 60 (seconds). If the option is present with a zero-byte value encoding, the default is overridden and Max-Age is set to 0. 4.1: middle two paragraphs seem like repetition - maybe they could be deleted? In teaching, I love repetition, if it is done at the right place. This is trying to recap types and codes, and I think it is at the right place. 4.2, 1st para, "acknowledge such a message" - do you mean all CONs or just an empty CON? splitting up this para into a few or using a bullet list or pseudo-code would be better I think. I don't want to hixiefy the spec too much (section 6 is worse enough). Just fixed the specific problem: [1321] 4.2, "a random number between 2 and 3" (replacing names with defaults) - ought you recommend some minimun granularity just in case some careless developer did something like: initialTimeout=3DACK_TIMEOUT+ rand()%(ACK_TIMEOUT*ACKRANDOM_FACTOR-ACK_TIMEOUT) I'm not sure there is a good basis for defining a specific minimum granularity. This is a good observation for the LWIG implementation guidance draft, though. For the specification, I slightly clarified: [1324] 4.3, last sentence in parenthesis - I have no idea what that means It means that, since RSTs can refer to both CONs and NONs, you need to avoid using the same Message ID for a CON and a NON during the time you might hit a RST. 4.4, last para: I just wonder if any NAT or v6 transition schemes might invalidate this MUST? This is a matching rule that is enforced at the endpoint that sent a CON/NON. If the NAT/transition scheme breaks the property that when you send a message to IP address X and Port Y, you get back the reply message from IP address X and Port Y, CoAP is not going to work over it. (Neither will DNS or anything else much, so I hope no such NAT or transition scheme is deployed widely). By the way, it also means you fundamentally can't do ACKs to a multicast message, because they won't match. 4.6, 1st sentence: don't get that, maybe better deleted. This is trying to alert implementers to the fact that there may be overriding concerns with respect to the choice of a message size that are not part of the CoAP spec. 4.8.1, DEFAULT_LEISURE is in table 1 but not discussed until section 8, a fwd ref at least would be good [1322] 5.2.2, "The server maybe initiates..." seems too casual. [1323] 5.3.1, 3rd para - the note about using the same token for different source ports seems broken to me. I don't think you say anything to the effect that the response has to go to that source port. This is implied in the endpoint concept. A different port is a different endpoint is a different client. (What the introduction to 5.3 is really trying to say is that the token space is per endpoint-pair.) 5.4.6, option numbers can be 16 bits long, in that case bit 7 is not the lsb - does that need fixing? Similarly with Figure 11. Clarified some more: [1325] (Figure 11 is fine, because this operates on the actual number.) 5.5.2, I buy your argument here about language tagging, but what happens at a CoAP->HTTP g/w? Doesn't language tagging become an issue there? How's that handled? This is best compared to the human-readable component of the HTTP status line, called Reason-Phrase in RFC 2616 and reason-phrase in section 3.1.2 of draft-ietf-httpbis-p1-messaging-22.txt. We mainly simplify this from "an encoding that is a superset of US-ASCII [USASCII]" to "UTF-8". It is unlikely that constrained node implementations will need a language-tag here more urgently than HTTP users. 5.10.1 - can any of the valid options for Host from 3986 be used? e.g. IPv6 addresses as text in square brackets, decimal form IPv4 addresses? You do have some guidance later but I think that'd be bettern being more obvious. Unfortunately, CoAP needs to use URIs pretty much as-is, so it does import all this complexity. Note that the default value of Uri-Host already uses an IP address, so the need for address literals should be clear from the context. 5.10.5 - I'm probably just confused by reading so much;-) If there are two Max-Age options, which wins? Where's that stated in general? For options that are not specified as repeatable (table 3), supernumerary option instances are interpreted according to 5.4.5 (which we just fixed slightly in [1308]). 5.10.8.1 - I don't get why its ok to not say which If-Match to pick if more than one matches. Why's that? There is only one current representation of the target resource. If that matches any of the If-Match options, the condition is fulfilled. Essentially, you can say "if the resource has value a or b, replace it with the payload c of this message". Whether it had value a or b does not matter, because there is only one replacement value c that can be given. (If that is not the intention, there is no way to say this with what we have.) 6.1 - I don't get what you mean by saying that the coap URI scheme "supports" /.well-known, maybe that'll be clear in section 7. (I don't think it was.) RFC5785: A well-known URI is a URI [RFC3986] whose path component begins with the characters "/.well-known/", and whose scheme is "HTTP", "HTTPS", or another scheme that has explicitly been specified to use well- known URIs. We thus explicitly specify that usage for the COAP scheme (and by derivation in 6.2 for COAPS). 6.2 - s/for privacy// - DTLS does authentication, integrity and confidentiality, not privacy Oops. [1326] 7.1 - what if I want to only do discovery via DTLS? What does "support" mean for port 5683 then? Well, what links exactly you offer there is up to the server. But the current text says that if you do any resource discovery at all, you also MUST provide something via CoAP over UDP on port 5683. There is a trade-off between security and manageability here. Using this, I can find out that a node does speak CoAP, and if it wants to make any (e.g. management) resources widely available, it can offer them there. (We can argue how MUSTy that MUST must be. E.g., RFC 4443 requires any router to send an ICMPv6 Time Exceeded message with Code 0 in response to a packet sent to it that is formed in a certain way. On the other hand, there is only a "MUST implement" on the ICMP echo function.) 7.2 - I didn't really get how this works, but I assume that if I re-read RFC6690, then I'd get it. Is that a good assumption? You probably need to read the whole tome on Web linking (starting from RFC 5988) as well; reading draft-shelby-core-resource-directory-05.txt won't hurt either. There is a lot of interest in making this work well for Smart Object Networks, so I expect documentation to grow in this space. 8.2.1, 1st para - this talks about "the cache" but I don't think you've (so far) told me that clients that send multicast requests have to have a cache for responses. Don't you need to? s/the/a/ [1327] 8.2.2 - Please make it clear(er) that bormann-coap-misc is properly an informative ref. (Assuming it is.) s/a/one/ [1328] section 9, last para: what's that mean? I got the feeling the text was trying to hide something from me fwiw. To the contrary, it is making very explicit some important limitations on what the current authorization can do. Essentially, you can only be secure through a proxy using either object security (end-to-end) or when the proxy actually is part of your security model. 6.5 - I thin you need a security consideration somwhere about comparing coap(s) URIs and the potential for access control screw-ups.=20 Good point. -> Ticket 9.1 - have people implemented the ECDH ciphersuites in CoAP testing? Knowing if this is just text or also running code might help discuss resolution. Don Sturek reported on the list that multiple interoperable implementations exist (and obtained ZigBee IP certification) for TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, also using it with (TCP) TLS for SEP 2.0. Zach Shelby reports they have the same ciphersuite running with DTLS/CoAP (CoAPS). Various open source implementations of CoAPS are ongoing. Matthias Kovatsch reports on the list: Californium has a full CoAPS implementation (PSK, ECDHE, RawPublicKeys, Certificates): https://github.com/mkovatsc/Californium We had DTLS interops with Bremen (TinyDTLS), SICS (JCoAP + own DTLS), and Silicon Labs (own DTLS, unknown CoAP). PSK worked with all of them. ECDHE was tested successfully with SICS and Silicon Labs. Mutual Authentication was working with SICS. Fragmentation and RawPublicKeys could not be tested for interoperability with others so far, but it works with Californium only nodes. 9.1.3.3 - throwing in RSA as a SHOULD (albeit within a section that's a MAY) is odd - if devices can do RSA then why not have 'em all do it for the raw public keys and get the interop gains that will accrue from that. Well, this is for the (somewhat high-end) case of cert usage. WG: Is there a cipher suite that better its the other ones we use? E.g., Why didn't we use TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA (RFC 5489)? I notice that in the transition from -05 to -06, we got rid of TLS_RSA_WITH_AES_128_CBC_SHA in favor of TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, but not of TLS_RSA_PSK_WITH_AES_128_CBC_SHA. The changes comment is "DTLS cipher suites aligned with ZigBee IP, DTLS clarified as default CoAP security mechanism (#138, #139)". http://trac.tools.ietf.org/wg/core/trac/ticket/139 mentions TLS_PSK_WITH_AES_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, but not anything about the cert-with-PSK case. -> Ticket 11.5 - this is a bit detailed, wouldn't a reference do most of it? It may be a bit graphic, but I don't know a good reference discussing CoAP cross-protocol attacks. Just discussing them in general terms didn't seem to cut it. (And the secdir reviewer liked the text :-) 12.7 - as it turns out I also don't see why this needs two ports - the cost is two more bytes for security which is significantly-enough less than the current cost (in terms of message size) for security. Am I wrong? On constrained node networks, we are fighting for every byte. GHC gives us back most of what DTLS and the relevant ciphersuites waste a bit carelessly, so we mostly pay for the authenticator, and that is money (battery) well-spent. There are indeed good ways to multiplex on the first byte of the message (we effectively use only 1/4 of the space), but that would require the cooperation of the TLS WG, and we removed this feature between coap-06 and coap-07 (we discussed this again in the Atlanta TSVAREA meeting, http://www.ietf.org/proceedings/85/minutes/minutes-85-tsvwg). So for now, the second port is the way we arrived at. Please also consider the secdir review [1] (if you've not done so already, I do see a shepherd response). [1] = http://www.ietf.org/mail-archive/web/secdir/current/msg03873.html The comments from that review should have been covered in -15 already. From Bert.Greevenbosch@huawei.com Sun Apr 28 01:58: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 3902D21F996D for ; Sun, 28 Apr 2013 01:58:15 -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 bfGEPG0EX-Cm for ; Sun, 28 Apr 2013 01:58:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 343E921F9959 for ; Sun, 28 Apr 2013 01:58:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASG28701; Sun, 28 Apr 2013 08:58:11 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 28 Apr 2013 09:57:25 +0100 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 28 Apr 2013 09:58:06 +0100 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.35]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.007; Sun, 28 Apr 2013 16:58:02 +0800 From: Bert Greevenbosch To: Carsten Bormann Thread-Topic: [core] I-D Action: draft-greevenbosch-core-minimum-request-interval-01.txt Thread-Index: AQHOQmn7KKkjK6YXUUyevqd2IT/+VJjpRJvw Date: Sun, 28 Apr 2013 08:58:01 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D71E0E1@szxeml558-mbx.china.huawei.com> References: <20130426092352.870.74099.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org \(core@ietf.org\)" Subject: Re: [core] I-D Action: draft-greevenbosch-core-minimum-request-interval-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 08:58:15 -0000 SGkgQ2Fyc3RlbiwNCg0KVGhhbmsgeW91IGZvciB5b3VyIGZlZWRiYWNrLiBJbmRlZWQgSSByZW1l bWJlciB0aGUgZGlzY3Vzc2lvbnMgaW4gT3JsYW5kby4NCg0KSSB0aGluayB0aGUgbWFpbiB1c2Ug Y2FzZSBvZiBteSBmbG93IGNvbnRyb2wgZHJhZnQgaXMgcmVkdWNpbmcgdGhlIHNlcnZlciBsb2Fk IGJhc2VkIG9uIGxpbWl0aW5nIHRoZSBjb21tdW5pY2F0aW9uIHdpdGhpbiBhIGNsaWVudC9zZXJ2 ZXIgcGFpci4gQXMgdGhlIHNvbHV0aW9uIGxpbWl0cyB0aGUgdGltZSBiZXR3ZWVuIHN1YnNlcXVl bnQgcmVxdWVzdHMgdGhyb3VnaCBhIG1pbmltdW0gcmVxdWVzdCBpbnRlcnZhbCAoTVJJKSwgaXQg aXMgdXNlZnVsIGZvciB0cmFuc2FjdGlvbnMgdGhhdCByZXF1aXJlIG11bHRpcGxlIHJlcXVlc3Rz LiBFeGFtcGxlcyBhcmUgYmxvY2sgdHJhbnNhY3Rpb25zIGFuZCBicm93c2luZyB0cmFuc2FjdGlv bnMuDQoNCk9uZSBvZiB0aGUgZGlzY3Vzc2lvbiBwb2ludHMgaW4gT3JsYW5kbyB3YXMgYWJvdXQg aG93IHRoZSBzZXJ2ZXIgY2FuIGRldGVybWluZSBhIGdvb2QgTVJJLiBJIHdvdWxkIHNheSB0aGUg bWFpbiBpc3N1ZSBpcyB0aGF0IHdoZW4gdGhlIHNlcnZlciBpcyBvdmVybG9hZGVkLCBlLmcuIGlm IGl0IGhhcyB0byBkcm9wIHJlcXVlc3RzIGR1ZSB0byBmdWxsIGJ1ZmZlcnMsIGl0IG5lZWRzIHRv IGluY3JlYXNlIHRoZSBNUkksIHdoZXJlYXMgaWYgdGhlcmUgaXMgbm8gcHJvYmxlbSwgaXQgY2Fu IGRlY3JlYXNlIHRoZSBNUkkgb3IgZXZlbiBzZXQgaXQgdG8gMCBpZiBjb25zaWRlcmVkIHNhZmUu IEluY3JlYXNpbmcgdGhlIE1SSSBjb3VsZCBiZSBzb21ldGhpbmcgc2ltcGxlIGxpa2UgbXVsdGlw bHlpbmcgYnkgMiAod2l0aGluIGJvdW5kcyksIHdoZXJlYXMgZGVjcmVhc2luZyBjb3VsZCBiZSBz b21ldGhpbmcgbGlrZSBsaW5lYXIgZGVjcmVhc2UuIFRoaXMgd291bGQgbWltaWMgVENQIGJ1dCBv dGhlciBzdHJhdGVnaWVzIGNvdWxkIGJlIHBvc3NpYmxlIGFzIHdlbGwuDQoNCjxxdW90ZT4NCkp1 c3QgdG8gYnVpbGQgYSB2ZXJ5IHJvdWdoIHN0cmF3bWFuIGZvciBzdWNoIGFuIGFsdGVybmF0aXZl IG1ldHJpYzogDQpBIHNlcnZlciBjb3VsZCBhc2sgYSBjbGllbnQgdG8gc2VuZCB0aGUgbmV4dCBy ZXF1ZXN0IG9ubHkgYWZ0ZXIgdHdpY2UgdGhlIHRpbWUgaXQgdG9vayB0aGUgY2xpZW50IHRvIG9i dGFpbiB0aGUgcHJldmlvdXMgcmVzcG9uc2UuDQooVGhpcyB3b3VsZCBmaWd1cmUgaW4gbmV0d29y ayBsb2FkIGluIGEgd2F5IHRoYXQgdGhlIHNlcnZlciBvbiBpdHMgb3duIGNhbm5vdCBkby4pDQo8 L3F1b3RlPg0KDQpZZXMsIHRoYXQgaXMgYW4gaWRlYSB0aGF0IGRlc2VydmVzIGV4cGxvcmF0aW9u LiBJdCBtZWFucyB0aGF0IHRoZSBjbGllbnQgd291bGQgY2FsY3VsYXRlIHRoZSBNUkkgYnkgaXRz ZWxmLCB3aGVyZWFzIHRoZSBzZXJ2ZXIgb25seSBpbmRpY2F0ZXMgdG8gdGhlIGNsaWVudCB0aGUg bmVlZCB0byBhZGp1c3QgdGhlIE1SSSwgd2l0aG91dCBzaWduYWxsaW5nIGFuIGV4cGxpY2l0IHZh bHVlIG9mIHRoZSBNUkkuIFRoaXMgY291bGQgZS5nLiBiZSBkb25lIHRocm91Z2ggYSBuZXcgInNs b3ctZG93biIgb3B0aW9uLg0KDQpXaXRoICJkb3VibGluZyIsIGRvIHlvdSBtZWFuIGRvdWJsaW5n IHRoZSBNUkkgb25jZSBvciBkb3VibGluZyB0aGUgY3VycmVudCBNUkkgZXZlcnkgdGltZSB0aGUg Y2xpZW50IHJlY2VpdmVzIGEgInNsb3ctZG93biIgb3B0aW9uPyBJZiB0aGUgbGF0dGVyLCB0aGVy ZSBzaG91bGQgYmUgYW4gdXBwZXIgYm91bmQgdG8gdGhlIE1SSS4gQWxzbywgb25lIGNvdWxkIGNv bnNpZGVyIGxpbmVhcmx5IHJlZHVjaW5nIHRoZSBNUkkgaWYgdGhlICJzbG93LWRvd24iIG9wdGlv biBpcyBub3QgaW5jbHVkZWQuIFNpbmNlIHdlIHdhbnQgdG8gcHJldmVudCB0aGUgc2VydmVyIHRv IG1haW50YWluIHN0YXRlLCBpdCBjYW5ub3QgcmVtZW1iZXIgdG8gd2hvbSBpdCBzZW50IGhvdyBt YW55ICJzbG93LWRvd24iIHJlc3BvbnNlcy4NCg0KU2ltcGxlciB3b3VsZCBiZSBmb3IgdGhlIGNs aWVudCB0byBqdXN0IGRvdWJsZSB0aGUgbGFzdCBvYnNlcnZlZCB0aW1lIGJldHdlZW4gUmVxdWVz dCBhbmQgUmVzcG9uc2UgKHRoZSBmb3JtZXIgaW4gYWJvdmUgcGFyYWdyYXBoKSwgYnV0IHRoYXQg d291bGQgb25seSByZWR1Y2UgdGhlIG51bWJlciBvZiByZXF1ZXN0cyBwZXIgdGltZSB1bml0IHRv IGl0cyBoYWxmLCB3aGljaCBtYXkgb3IgbWF5IG5vdCBiZSBlbm91Z2ggcmVkdWN0aW9uIG9mIHRo ZSBzZXJ2ZXIgbG9hZC4NCg0KV2hhdCBhcmUgeW91ciB0aG91Z2h0cz8NCg0KPHF1b3RlPg0KQW5v dGhlciBpc3N1ZSBpcyB0aGUgc2NvcGUgb2YgdGhlIHRocm90dGxpbmc6IElzIGl0IGZvciBhIHNp bmdsZSByZXNvdXJjZSwgdGhpcyBlbmRwb2ludCwgdGhlIElQIGFkZHJlc3MsIGEgcHJlZml4IChz YXksIGEgLzY0KT8NCihXaWRlciBzY29wZXMgaGF2ZSBtb3JlIHNlY3VyaXR5IGltcGxpY2F0aW9u cy4pDQo8L3F1b3RlPg0KDQpJbmRlZWQgaWYgdGhlIHNlcnZlciBjYW4gc2lnbmFsIGV4cGxpY2l0 IE1SSSB2YWx1ZXMsIHRoZW4gaXQgY2FuIHRha2UgbW9yZSBmYWN0b3JzIGludG8gYWNjb3VudC4g SXQgY291bGQgZS5nLiB0YWtlIHRoZSBtdWx0aXBsaWNpdHkgb2YgY2xpZW50cyBpdCBpcyB0YWxr aW5nIHRvIGludG8gYWNjb3VudCB3aGVuIGNob29zaW5nIGl0cyBNUkkuIEFsc28gaWYgaXQgc2ln bmFscyB0aGUgc2FtZSBNUkkgdG8gYWxsIGNsaWVudHMsIGl0IGVuZm9yY2VzIGZhaXJuZXNzLiBI b3dldmVyIGluZGVlZCB0aGVyZSBhcmUgc2VjdXJpdHkgaW1wbGljYXRpb25zLCBhcyBpbiB0aGlz IHdheSBjbGllbnRzIHdvdWxkIGhhdmUgaW5mbHVlbmNlIG9uIG90aGVyIGNsaWVudHMnIGJlaGF2 aW91ciwgYWx0aG91Z2ggd2l0aCBhIGNvbmdlc3RlZCBzZXJ2ZXIgdGhpcyBpcyB0aGUgY2FzZSBt b3JlIG9mdGVuIHRoYW4gbm90LiBXZSBuZWVkIHRvIGNvbnNpZGVyIHdoZXRoZXIgdGhlIHNlcnZl cidzIG1vcmUgZXh0ZW5zaXZlIGtub3dsZWRnZSBvZiB0aGUgc2l0dWF0aW9uIGNhbiBsZWFkIHRv IHNpZ25pZmljYW50bHkgYmV0dGVyIE1SSXMsIGFuZCBpZiB0aGF0IHdvdWxkIGp1c3RpZnkgdGhl IGhpZ2hlciBjb21wbGV4aXR5Lg0KDQpKdXN0IHNvbWUgY29uc2lkZXJhdGlvbnMgZm9yIGZ1cnRo ZXIgZGlzY3Vzc2lvbi4uLg0KDQpCZXN0IHJlZ2FyZHMsDQpCZXJ0DQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IGNvcmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNvcmUt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENhcnN0ZW4gQm9ybWFubg0KU2VudDogMjAx M+W5tDTmnIgyNuaXpSAxODozNw0KVG86IGNvcmVAaWV0Zi5vcmcgKGNvcmVAaWV0Zi5vcmcpDQpT dWJqZWN0OiBSZTogW2NvcmVdIEktRCBBY3Rpb246IGRyYWZ0LWdyZWV2ZW5ib3NjaC1jb3JlLW1p bmltdW0tcmVxdWVzdC1pbnRlcnZhbC0wMS50eHQNCg0KQmVydDogVGhhbmtzIGZvciB1cGRhdGlu ZyB0aGlzLg0KSSByZWZlcnJlZCB0byB0aGUgLTAwIGluIG15IHJlcGx5IHRvIE1hcnRpbiBTdGll bWVybGluZydzIElFU0cgY29tbWVudHMuDQoNClRoZXJlIHdlcmUgc29tZSBjb21tZW50cyBpbiB0 aGUgT3JsYW5kbyBtZWV0aW5nIHRoYXQgcGVvcGxlIGRpZG4ndCBxdWl0ZSBrbm93IHdoZW4gdG8g dXNlIHN1Y2ggYW4gT3B0aW9uIGFuZCBob3cgdG8gZmluZCBhIGdvb2QgdmFsdWUgdG8gcHV0IGlu IGl0Lg0KKEkgdGhpbmsgd2UgbmVlZCB0byBjaGVjayB3aGV0aGVyIHRoZXJlIGlzIGEgYmV0dGVy IG1ldHJpYyB0byB1c2UgZm9yIHRocm90dGxpbmcvbG9hZCBzaGVkZGluZyB0aGFuIHRoZSBlbGFw c2VkIHRpbWUgYmV0d2VlbiB0d28gcmVxdWVzdHMuKQ0KSXQgd291bGQgcHJvYmFibHkgaGVscCB0 byBsb29rIGF0IHRoZSB1c2UgY2FzZXMgaW4gc29tZSBtb3JlIGRldGFpbC4gIFdoYXQgc3BlY2lm aWNhbGx5IGlzIGEgc2VydmVyIHRyeWluZyB0byBhY2hpZXZlIGJ5IGxpbWl0aW5nIHRoZSByZXF1 ZXN0IGludGVydmFsPw0KV2hhdCBraW5kIG9mIG1ldHJpYyBhbGlnbnMgYmVzdCB3aXRoIHN1Y2gg YW4gb2JqZWN0aXZlPw0KDQpKdXN0IHRvIGJ1aWxkIGEgdmVyeSByb3VnaCBzdHJhd21hbiBmb3Ig c3VjaCBhbiBhbHRlcm5hdGl2ZSBtZXRyaWM6IA0KQSBzZXJ2ZXIgY291bGQgYXNrIGEgY2xpZW50 IHRvIHNlbmQgdGhlIG5leHQgcmVxdWVzdCBvbmx5IGFmdGVyIHR3aWNlIHRoZSB0aW1lIGl0IHRv b2sgdGhlIGNsaWVudCB0byBvYnRhaW4gdGhlIHByZXZpb3VzIHJlc3BvbnNlLg0KKFRoaXMgd291 bGQgZmlndXJlIGluIG5ldHdvcmsgbG9hZCBpbiBhIHdheSB0aGF0IHRoZSBzZXJ2ZXIgb24gaXRz IG93biBjYW5ub3QgZG8uKQ0KDQpBbm90aGVyIGlzc3VlIGlzIHRoZSBzY29wZSBvZiB0aGUgdGhy b3R0bGluZzogSXMgaXQgZm9yIGEgc2luZ2xlIHJlc291cmNlLCB0aGlzIGVuZHBvaW50LCB0aGUg SVAgYWRkcmVzcywgYSBwcmVmaXggKHNheSwgYSAvNjQpPw0KKFdpZGVyIHNjb3BlcyBoYXZlIG1v cmUgc2VjdXJpdHkgaW1wbGljYXRpb25zLikNCg0KR3LDvMOfZSwgQ2Fyc3Rlbg0KDQoNCk9uIEFw ciAyNiwgMjAxMywgYXQgMTE6MjMsIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyB3cm90ZToNCg0K PiANCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUg SW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiANCj4gDQo+IAlUaXRsZSAgICAgICAgICAg OiBDb0FQIE1pbmltdW0gUmVxdWVzdCBJbnRlcnZhbA0KPiAJQXV0aG9yKHMpICAgICAgIDogQmVy dCBHcmVldmVuYm9zY2gNCj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWdyZWV2ZW5ib3NjaC1j b3JlLW1pbmltdW0tcmVxdWVzdC1pbnRlcnZhbC0wMS50eHQNCj4gCVBhZ2VzICAgICAgICAgICA6 IDgNCj4gCURhdGUgICAgICAgICAgICA6IDIwMTMtMDQtMjYNCj4gDQo+IEFic3RyYWN0Og0KPiAg IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbiAiTWluaW11bS1SZXF1ZXN0LUludGVydmFsIiBvcHRp b24gZm9yIENvQVAsDQo+ICAgd2hpY2ggY2FuIGJlIHVzZWQgdG8gbmVnb3RpYXRlIHRoZSBtaW5p bXVtIHRpbWUgYmV0d2VlbiB0d28NCj4gICBzdWJzZXF1ZW50IHJlcXVlc3RzIHdpdGhpbiBhIHNp bmdsZSBjbGllbnQgYW5kIHNlcnZlciBwYWlyLiAgSXQgY2FuDQo+ICAgYmUgdXNlZCBmb3IgZmxv dyBhbmQgY29uZ2VzdGlvbiBjb250cm9sLCByZWR1Y2luZyB0aGUgY29uc3VtcHRpb24gb2YNCj4g ICBzZXJ2ZXIgYW5kIG5ldHdvcmsgcmVzb3VyY2VzIHdoZW4gbmVlZGVkLg0KPiANCj4gTm90ZQ0K PiANCj4gICBEaXNjdXNzaW9uIGFuZCBzdWdnZXN0aW9ucyBmb3IgaW1wcm92ZW1lbnQgYXJlIHJl cXVlc3RlZCwgYW5kIHNob3VsZA0KPiAgIGJlIHNlbnQgdG8gY29yZUBpZXRmLm9yZy4NCj4gDQo+ IA0KPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoN Cj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ3JlZXZlbmJvc2NoLWNv cmUtbWluaW11bS1yZXF1ZXN0LWludGVydmFsDQo+IA0KPiBUaGVyZSdzIGFsc28gYSBodG1saXpl ZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtZ3JlZXZlbmJvc2NoLWNvcmUtbWluaW11bS1yZXF1ZXN0LWludGVydmFsLTAxDQo+IA0KPiBB IGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+IGh0dHA6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWdyZWV2ZW5ib3NjaC1jb3JlLW1pbmlt dW0tcmVxdWVzdC1pbnRlcnZhbC0wMQ0KPiANCj4gDQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxz byBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy8NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCj4gSS1ELUFubm91bmNl QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFu bm91bmNlDQo+IEludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3Jn L3NoYWRvdy5odG1sDQo+IG9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMu dHh0DQo+IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY29yZQ0K From zach@sensinode.com Sun Apr 28 05:33:58 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B9921F8E6C for ; Sun, 28 Apr 2013 05:33:58 -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 D8gbpiCA6zBA for ; Sun, 28 Apr 2013 05:33:58 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id B667E21F8DCF for ; Sun, 28 Apr 2013 05:33:57 -0700 (PDT) Received: from [10.222.28.64] ([82.203.205.227]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r3SCXi4I004266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Apr 2013 15:33:45 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D71E0E1@szxeml558-mbx.china.huawei.com> Date: Sun, 28 Apr 2013 14:53:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0FC19719-D59D-47A7-A7D2-38EA1A39DBD3@sensinode.com> References: <20130426092352.870.74099.idtracker@ietfa.amsl.com> <46A1DF3F04371240B504290A071B4DB63D71E0E1@szxeml558-mbx.china.huawei.com> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1503) Cc: "core@ietf.org \(core@ietf.org\)" Subject: Re: [core] I-D Action: draft-greevenbosch-core-minimum-request-interval-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 12:33:58 -0000 Bert, On Apr 28, 2013, at 11:58 AM, Bert Greevenbosch = wrote: > I think the main use case of my flow control draft is reducing the = server load based on limiting the communication within a client/server = pair. As the solution limits the time between subsequent requests = through a minimum request interval (MRI), it is useful for transactions = that require multiple requests. Examples are block transactions and = browsing transactions. So far, we have found NSTART=3D1 to be more than sufficient for CoAP = doing real deployments. At the same time, even with the most contained = devices, we have not experienced problems with no delay between = subsequent requests. If the server did want to slow down the request = rate of a client, it can do so simply by inserting some delay before = sending a response (and this happens naturally). Thus I am having = problems understanding what this MRI mechanism brings us. Are you = assuming NSTART>1? Before going as far as designing sophisticated = mechanisms for dealing with NSTART>1, we should wait for real use cases = (if any!).=20 Now, there are other congestion related issues that would be useful for = this WG to solve in the future: - Automatic adjustment of ACK_TIMEOUT using RTT estimation. = Today you either use our 2 second default or configure this manually.=20 - Rate control to a group of destinations (e.g. a LoWPAN) and in = particular automatic estimation of that rate. It is fairly easy for a = non-contrained endpoint to overload a LoWPAN if it just considers = NSTART=3D1 for each individual destination in the LoWPAN.=20 Zach=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From stephen.farrell@cs.tcd.ie Sun Apr 28 09:01:58 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B40221F9A2E; Sun, 28 Apr 2013 09:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[AWL=-2.600, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, MANGLED_EMAIL=2.3, MANGLED_LIST=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPOhzN0GGABh; Sun, 28 Apr 2013 09:01:56 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9B83B21F9A2D; Sun, 28 Apr 2013 09:01:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 09907BE73; Sun, 28 Apr 2013 17:01:28 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61ODvr11iUbb; Sun, 28 Apr 2013 17:01:25 +0100 (IST) Received: from [10.87.48.10] (unknown [86.46.22.79]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9A1E7BE61; Sun, 28 Apr 2013 17:01:24 +0100 (IST) Message-ID: <517D47CA.1030900@cs.tcd.ie> Date: Sun, 28 Apr 2013 17:01:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: Carsten Bormann References: <20130425012605.7589.40567.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, The IESG , core@ietf.org Subject: Re: [core] Stephen Farrell's Discuss on draft-ietf-core-coap-15: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 Apr 2013 16:01:58 -0000 Hi Carsten, On 04/27/2013 08:33 PM, Carsten Bormann wrote: > Stephen, > > thank you for this comprehensive review. > I have done some of the changes as simple editorial fixes, these are > marked like [1316] below and can be reviewed in > http://trac.tools.ietf.org/wg/core/trac/changeset/1316 > (Overview in http://trac.tools.ietf.org/wg/core/trac/timeline). FWIW, I'm not finding the above that useful but will check a diff when an updated I-D is produced so that's ok. I only responded to some bits below, I expect the rest will be worked out as we go, if they're not already pretty obvious. > > Some of the replies are marked "-> Ticket": This means that the > authors think that the change is a good idea, but probably needs a bit > more discussion with the WG, so we will handle this as a ticket. > > Gre, Carsten > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > I will end up balloting yes for his. I think its good work > and has lots of implementations. Note also that some of the > discuss points here should be easily resolved or are just > checking stuff. (Its in the nature of very very long > documents > > ... that they get longer with each review cycle, and ... > > that the accumulation of such stuff generates more > discuss points.) Anyway, let's discuss... > > (1) 2.3: What if the URI scheme doesn't have a host or port > or path or query? Also in 5.6, 2nd bullet in list: Just to > note that if you were using ni URIs with CoAP, then you no > longer need to insist on exactly the same URI (e.g. the > authority part needn't matter with ni URIs, the alg-val part > is what counts). That might be true of other schemes too, so > perhaps this statment is scheme specific to some extent? > > That is a very good point. I think what happens here is that some > schemes such as the ni scheme open a way of matching that is specific > to that scheme and not available in the default case. We should add a > statement to this effect to the definition of "Cache-Key" that needs > to be added at the end of this section. > > Add at the end of (the introduction to) 5.6: > The set of options that is used for matching the cache entry is also > collectively referred to as the "Cache-Key". For URI schemes other > than coap and coaps, matching of those options that constitute the > request URI may be performed under rules specific to the URI scheme. > > -> Ticket > > This is just a discuss point to check that you're ok with > CoAP being restricted to some URI schemes in this manner, > the ni URI case is just an example I happen to know fairly > well:-) So I'll clear this one when told that this is > considered acceptable but I want to check the general issue > about uri-scheme dependencies for CoAP. The same point > occurs in 5.7.1 and maybe elsewhere btw. So basic point is: > please provide some sensible description of which URI > schemes can be used with CoAP and which cannot. > > The specification defines two URI schemes, coap and coaps. > It is probably a good idea to start some thinking about how RFC 6920 > can be used, but that should be a separate specification. > So, I think, the answer is "any URI scheme defined to use the CoAP > protocol". Do we need to state this explicitly? I think you do since you refer to carrying http and https URIs and I guess folks may well try ftp URIs with CoAP or maybe even mailto, who knows. I've no strong opinion as to what you ought say about schemes other than coap(s) but I think you do need to say something. (BTW, 6920 is not an important case here at all, maybe it was a bad example to pick, even if it is one that highlights some of this.) > > (2) 4.2, "when the timeout is triggered" - what happens with > sleepy nodes that only wake on external events, and where > e.g. if 2 timeouts have elapsed whilst asleep? Not sure if > odd behaviour of that kind could cause much harm, but was it > considered? This could also affect the definition in 4.8.2 > of MAX_TRANSMIT_SPAN. > > The intention is that retransmissions stay in the overall envelope of > MAX_TRANSMIT_SPAN, even if they are not perfectly spaced. > Indeed, this could benefit from some additional discussion. > -> Ticket > > (3) 4.2, last para: this creates an attack that can work > from off-path - just send loads of faked ACKs with guessed > Tokens and some of 'em will be accepted with probability > depending on Token-length and perhaps the quality of the RNG > used by the sender of the CON. That could cause all sorts of > "interesting" application layer behaviour. Why is that ok? > (Or put another way - was this considered and with what > conclusion?) > > Actually, the ACK would be matched on the Message ID (or I could > simply point to the penultimate paragraph of 5.3.1). This is a > relatively powerful attack that could be added to the list in 11.4. > -> Ticket Not sure we're talking about the same thing, so just to check. Figure 5 shows the nominal behaviour, the variant on that below (use fixed width to see it) tries to show the attack. Client Server | | | CON [0x7a10] | | GET /temperature | | (Token 0x73) | +----------------->| | | | | |<-----------------+ |<-----------------+ bad guy sends loads of | CON [0x23bb] | these, this one matches | 2.05 Content | the token value | (Token 0x73) | | "-273.15 C" | |<-----------------+ |<-----------------+ |<-----------------+ | | this is the original ack | ACK [0x7a10] | but bad guy has won the +----------------->| race already | | So in the above scenario the bad guy only needs to match the Token value to achieve his intended chilling effect:-) I think the fix here is to disallow accepting the bad guy's message there by saying that you can only do that with an at-least N bit Token where maybe N=80 or so. N ought be whatever we think will be safe to use when directly connecting a CoAP node to the Internet for the next few (5?) years at leats. I'd also like to argue for a RECOMMENDATION that the combined length of Message ID + Token be at least N bits, for the same N, for the same basic reason. > I suspect you need to have text trading off the > Token length versus use of DTLS or else CoAP may end up too > insecure for too many uses. (Note: the attack here is made > worse because the message ID comparison can be skipped. > Removing that "feature" would help a lot here.) 5.3.1's > client "may want to use a non-trivial, randomized token" > doesn't seem to cut it to me. How does this kind of > interaction map to DTLS sessions/epoch? Basically, I'd like > to see some RECOMMENDED handling of token length that would > result in it not being unsafe to connect a CoAP node to the > Internet. (And please note recent instances where 10's of > thousands of insecure devices have been found via probing > the IPv4 address space. These are real attacks.) > > Well, ceterum censeo BCP39. > But it seems the discussion at the end of 5.3.1 could make the > security considerations for selecting a token value in NoSec mode more > explicit. Right now the basic consideration, but not the parameters > that go into it, is discussed in 11.4 as well. > -> Ticket > > (4) 4.4, implementation note - this seems unwise since it > means that once Alice has interacted with Bob, then Bob can > easily guess the message IDs that Alice will use to talk to > Charlie. > > Not every CoAP client will have the means to keep state per peer server. > (It is not quite "once Alice has interacted", because the initiator of > an exchange chooses the Message ID. But it is often not too hard to > trick Alice into initiating an exchange.) Not sure if you're proposing to change that or not. I'd say describing a case where Message IDs are always random would be better. > > (5) 4.6, last para - this only applies to insecure uses of > CoAP, you should point that out > > "can" is indeed probably too strong. > -> Ticket > > (6) 6.2 - "the UDP datagrams MUST...use DTLS" is fine but > maybe not enough, if the request uses DTLS then presumably > so MUST *all* response messages, and they MUST use the same > DTLS session? Or perhaps one with the same authenticated > endpoints. Don't you need to say that? If you don't then > just sending the request via DTLS but getting (some) > response messages in clear would seem to be allowed. I > think 9.1 might cover all the above, but want to just check. > > This is implicit in the fact that all exchanges (except for multicast) > use the same pair of endpoints for both directions, so you simply > can't reply via NoSec to a DTLS message. It probably doesn't hurt to > make that explicit somewhere. > -> Ticket. > > (7) 9.1.1, 1st para: what is "the server" - is that the > destination host from the URI? If yes, then fine. If no, > then we need to DISCUSS that. > > Yes, it is. Great. > > (8) 9.1.3.3 - "signed by an appropriate chain of trust" is > an odd phrase - do you mean it MUST be validated as per RFC > 5280 section 6? If so, say so. If not, say what you do mean. > (But we might need to talk about it in that case, > depending;-) > > We probably should say: > The certificate MUST be validated as appropriate for the security > requirements, using functionality equivalent to the algorithm > specified in RFC5280 Section 6. > -> Ticket. > > (9) 9.1.3.3 - you don't mention certificate status checking. > I can see why that's hard to impossible in some n/w's but > entirely ignoring it seems wrong. Perhaps call out the > vulnerability and point at OCSP stapling as a potential > solution, but one that requires further work and/or further > specification? > > Yes, we should point this out. > -> Ticket > > (10) 10.1 - what does https mean here? If it means that > the request/response are in clear between the source and > proxy and then encrypted then a) you really really need to > say that clearly and b) why is that even acceptable and c) > what if the destination resource requires client auth? > > Well, it is way worse, because the proxy needs to decide on the > security policy that it wants to apply to the TLS connection > underlying HTTPS. This kind of proxy function only makes sense if the > proxy has a legitimate role in the trust chain, e.g. as a domain > boundary controller. In constrained node networks, this is actually a > likely use case. > > It just seems broken to pretend to use https this way. Going > via a cross-proxy breaks security. Similarly, what does coaps > mean in 10.2? > > Again, doing this kind of proxying only makes sense if the proxy has a > legitimate role. Hmmm. I suspect we'll want to chat more about this one. I don't see how the sender can in general know whether or not a "legitimate" proxy is going to do the right, or entirely wrong, thing. I also think that if an HTTPS endpoint somewhere on the Internet hands out an https URL then the current scheme doesn't meet their expectations in quite a bad way. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- Your responses to the comments are almost all ok - close enough to skip quibbling anyway:-) But I'm happy to chat if there're ones that need that. Cheers, S. > > general: 112 pages, sheesh;-) Seriously though, there is > repetition here that'd be better not there and fewer words > is better. Too late now though. > > (See above...) > > abstract: "CoAP easily..." is a bit of sales-talk, better to > say "CoAP is designed to easily..." > > [1316] > > intro, 2nd para: better to not talk about the WG name and > its work really, but about the resulting protocol > > We used the "CoRE" tag in RFC 6690, and would like to continue using > it, for the overall architecture that the CoAP protocol is a part of. > (If that is a problem, please rename all MPLS documents first :-) > > intro, 2nd para: suggest s/limiting the use of/limiting the > need for/ > > [1317] > > intro, last para: more sales pitch language > > But it's all true and not even exaggerated! > > 1.2, critical option - I wondered here if proxies have to > know these or just client & server. "Endpoint receiving the > message" doesn't make that (ctystal) clear. "Unsafe Option" > made me wonder more. (It is clear later.) > > Hmm. See my attempt in [1320]. > > 2.2: This is the first time Token is used. Might be no harm > to distinguish that explicitly from Message ID. > > [1318] > > 2.3: For what "security reason" are proxies useful? > > The domain boundary controller one (see above). > > 3: Ver field "MUST set this field to 1" - I guess someone > might set both bits to 1, so saying '01'B might be better. > > [1319] > > Section 3: I didn't see where Message ID wrap-around was > described. I see Martin has a discuss on that which I > support. > > (See my reply there.) > > 3: Message ID - with 16 bits that imposes a rate limit on > how often you can send. > > The rate limit is ~ 250 messages per second per pair of endpoints with > default parameters. > > I don't think that's described > > It will be described in the LWIG documents that are discussing Message > ID management in more detail. > > and I'm curious as to whether it'd set to max goodput for CoAP > that'd be way less than otherwise possible with e.g. HTTP. > > Answer: Yes. (~ 250 KiB/s with default parameters and large messages; > 20 kB/s with more realistic 80-byte messages.) If you need faster, > please use TCP (you will get better congestion control, too). > > 3.2: So I can't have an option with a uint value where > missing != 0? Might be worth saying. > > I'm not sure I'm decoding this sentence correctly, but a present > option with a zero-byte uint (value 0) is distinguishable from an > absent option. E.g., Max-Age has a default value (that is used if the > option is absent) of 60 (seconds). If the option is present with a > zero-byte value encoding, the default is overridden and Max-Age is set > to 0. > > 4.1: middle two paragraphs seem like repetition - maybe they > could be deleted? > > In teaching, I love repetition, if it is done at the right place. > This is trying to recap types and codes, and I think it is at the > right place. > > 4.2, 1st para, "acknowledge such a message" - do you mean > all CONs or just an empty CON? splitting up this para into a > few or using a bullet list or pseudo-code would be better I > think. > > I don't want to hixiefy the spec too much (section 6 is worse enough). > Just fixed the specific problem: [1321] > > 4.2, "a random number between 2 and 3" (replacing names with > defaults) - ought you recommend some minimun granularity > just in case some careless developer did something like: > > initialTimeout=ACK_TIMEOUT+ > rand()%(ACK_TIMEOUT*ACKRANDOM_FACTOR-ACK_TIMEOUT) > > I'm not sure there is a good basis for defining a specific minimum > granularity. This is a good observation for the LWIG implementation > guidance draft, though. > For the specification, I slightly clarified: [1324] > > 4.3, last sentence in parenthesis - I have no idea what that > means > > It means that, since RSTs can refer to both CONs and NONs, you need to > avoid using the same Message ID for a CON and a NON during the time > you might hit a RST. > > 4.4, last para: I just wonder if any NAT or v6 transition > schemes might invalidate this MUST? > > This is a matching rule that is enforced at the endpoint that sent a > CON/NON. If the NAT/transition scheme breaks the property that when > you send a message to IP address X and Port Y, you get back the reply > message from IP address X and Port Y, CoAP is not going to work over > it. (Neither will DNS or anything else much, so I hope no such NAT or > transition scheme is deployed widely). By the way, it also means you > fundamentally can't do ACKs to a multicast message, because they won't > match. > > 4.6, 1st sentence: don't get that, maybe better deleted. > > This is trying to alert implementers to the fact that there may be > overriding concerns with respect to the choice of a message size that > are not part of the CoAP spec. > > 4.8.1, DEFAULT_LEISURE is in table 1 but not discussed until > section 8, a fwd ref at least would be good > > [1322] > > 5.2.2, "The server maybe initiates..." seems too casual. > > [1323] > > 5.3.1, 3rd para - the note about using the same token for > different source ports seems broken to me. I don't think you > say anything to the effect that the response has to go to > that source port. > > This is implied in the endpoint concept. A different port is a > different endpoint is a different client. (What the introduction to > 5.3 is really trying to say is that the token space is per > endpoint-pair.) > > 5.4.6, option numbers can be 16 bits long, in that case bit > 7 is not the lsb - does that need fixing? Similarly with > Figure 11. > > Clarified some more: [1325] > (Figure 11 is fine, because this operates on the actual number.) > > 5.5.2, I buy your argument here about language tagging, but > what happens at a CoAP->HTTP g/w? Doesn't language tagging > become an issue there? How's that handled? > > This is best compared to the human-readable component of the HTTP > status line, called Reason-Phrase in RFC 2616 and reason-phrase in > section 3.1.2 of draft-ietf-httpbis-p1-messaging-22.txt. > We mainly simplify this from "an encoding that is a superset of > US-ASCII [USASCII]" to "UTF-8". It is unlikely that constrained node > implementations will need a language-tag here more urgently than HTTP > users. > > 5.10.1 - can any of the valid options for Host from 3986 be > used? e.g. IPv6 addresses as text in square brackets, > decimal form IPv4 addresses? You do have some guidance later > but I think that'd be bettern being more obvious. > > Unfortunately, CoAP needs to use URIs pretty much as-is, so it does > import all this complexity. Note that the default value of Uri-Host > already uses an IP address, so the need for address literals should be > clear from the context. > > 5.10.5 - I'm probably just confused by reading so much;-) If > there are two Max-Age options, which wins? Where's that > stated in general? > > For options that are not specified as repeatable (table 3), > supernumerary option instances are interpreted according to 5.4.5 > (which we just fixed slightly in [1308]). > > 5.10.8.1 - I don't get why its ok to not say which If-Match > to pick if more than one matches. Why's that? > > There is only one current representation of the target resource. If > that matches any of the If-Match options, the condition is fulfilled. > Essentially, you can say "if the resource has value a or b, replace it > with the payload c of this message". Whether it had value a or b does > not matter, because there is only one replacement value c that can be > given. (If that is not the intention, there is no way to say this > with what we have.) > > 6.1 - I don't get what you mean by saying that the coap URI > scheme "supports" /.well-known, maybe that'll be clear in > section 7. (I don't think it was.) > > RFC5785: > A well-known URI is a URI [RFC3986] whose path component begins with > the characters "/.well-known/", and whose scheme is "HTTP", "HTTPS", > or another scheme that has explicitly been specified to use well- > known URIs. > > We thus explicitly specify that usage for the COAP scheme (and by > derivation in 6.2 for COAPS). > > 6.2 - s/for privacy// - DTLS does authentication, integrity > and confidentiality, not privacy > > Oops. [1326] > > 7.1 - what if I want to only do discovery via DTLS? What > does "support" mean for port 5683 then? > > Well, what links exactly you offer there is up to the server. > But the current text says that if you do any resource discovery at > all, you also MUST provide something via CoAP over UDP on port 5683. > There is a trade-off between security and manageability here. > Using this, I can find out that a node does speak CoAP, and if it > wants to make any (e.g. management) resources widely available, it can > offer them there. > (We can argue how MUSTy that MUST must be. E.g., RFC 4443 requires > any router to send an ICMPv6 Time Exceeded message with Code 0 in > response to a packet sent to it that is formed in a certain way. On > the other hand, there is only a "MUST implement" on the ICMP echo > function.) > > 7.2 - I didn't really get how this works, but I assume that > if I re-read RFC6690, then I'd get it. Is that a good > assumption? > > You probably need to read the whole tome on Web linking (starting from > RFC 5988) as well; reading draft-shelby-core-resource-directory-05.txt > won't hurt either. There is a lot of interest in making this work > well for Smart Object Networks, so I expect documentation to grow in > this space. > > 8.2.1, 1st para - this talks about "the cache" but I don't > think you've (so far) told me that clients that send > multicast requests have to have a cache for responses. Don't > you need to? > > s/the/a/ [1327] > > 8.2.2 - Please make it clear(er) that bormann-coap-misc is > properly an informative ref. (Assuming it is.) > > s/a/one/ [1328] > > section 9, last para: what's that mean? I got the feeling > the text was trying to hide something from me fwiw. > > To the contrary, it is making very explicit some important limitations > on what the current authorization can do. Essentially, you can only > be secure through a proxy using either object security (end-to-end) or > when the proxy actually is part of your security model. > > 6.5 - I thin you need a security consideration somwhere > about comparing coap(s) URIs and the potential for access > control screw-ups. > > Good point. > -> Ticket > > 9.1 - have people implemented the ECDH ciphersuites in CoAP > testing? Knowing if this is just text or also running code > might help discuss resolution. > > Don Sturek reported on the list that multiple interoperable > implementations exist (and obtained ZigBee IP certification) for > TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, also using it with (TCP) TLS for > SEP 2.0. Zach Shelby reports they have the same ciphersuite running > with DTLS/CoAP (CoAPS). > > Various open source implementations of CoAPS are ongoing. > Matthias Kovatsch reports on the list: > Californium has a full CoAPS implementation (PSK, ECDHE, > RawPublicKeys, Certificates): > https://github.com/mkovatsc/Californium > We had DTLS interops with Bremen (TinyDTLS), SICS (JCoAP + own DTLS), > and Silicon Labs (own DTLS, unknown CoAP). > PSK worked with all of them. > ECDHE was tested successfully with SICS and Silicon Labs. > Mutual Authentication was working with SICS. > Fragmentation and RawPublicKeys could not be tested for > interoperability with others so far, but it works with Californium > only nodes. > > 9.1.3.3 - throwing in RSA as a SHOULD (albeit within a > section that's a MAY) is odd - if devices can do RSA then > why not have 'em all do it for the raw public keys and get > the interop gains that will accrue from that. > > Well, this is for the (somewhat high-end) case of cert usage. > > WG: Is there a cipher suite that better its the other ones we use? > E.g., Why didn't we use TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA (RFC 5489)? > I notice that in the transition from -05 to -06, we got rid of > TLS_RSA_WITH_AES_128_CBC_SHA in favor of > TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, but not of > TLS_RSA_PSK_WITH_AES_128_CBC_SHA. The changes comment is "DTLS cipher > suites aligned with ZigBee IP, DTLS clarified as default CoAP security > mechanism (#138, #139)". > http://trac.tools.ietf.org/wg/core/trac/ticket/139 mentions > TLS_PSK_WITH_AES_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, but > not anything about the cert-with-PSK case. > > -> Ticket > > 11.5 - this is a bit detailed, wouldn't a reference do > most of it? > > It may be a bit graphic, but I don't know a good reference discussing > CoAP cross-protocol attacks. Just discussing them in general terms > didn't seem to cut it. (And the secdir reviewer liked the text :-) > > 12.7 - as it turns out I also don't see why this needs > two ports - the cost is two more bytes for security which > is significantly-enough less than the current cost (in > terms of message size) for security. Am I wrong? > > On constrained node networks, we are fighting for every byte. GHC > gives us back most of what DTLS and the relevant ciphersuites waste a > bit carelessly, so we mostly pay for the authenticator, and that is > money (battery) well-spent. There are indeed good ways to multiplex > on the first byte of the message (we effectively use only 1/4 of the > space), but that would require the cooperation of the TLS WG, and we > removed this feature between coap-06 and coap-07 (we discussed this > again in the Atlanta TSVAREA meeting, > http://www.ietf.org/proceedings/85/minutes/minutes-85-tsvwg). > So for now, the second port is the way we arrived at. > > Please also consider the secdir review [1] (if you've > not done so already, I do see a shepherd response). > > [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03873.html > > The comments from that review should have been covered in -15 already. > From alexey.melnikov@isode.com Sun Apr 28 14:33: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 3E79621F8496; Sun, 28 Apr 2013 14:33:33 -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 vyi275RBdwBI; Sun, 28 Apr 2013 14:33:32 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3BC21F8314; Sun, 28 Apr 2013 14:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1367184808; d=isode.com; s=selector; i=@isode.com; bh=m9hWLLMyaT4hQn74HjSjpUc5FlPfM/mKuXIJgixu+Jw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Iwr+W8FLb8S0wDmTo8PgqA3lK3qvJlzN409uHaYbEDrnb70mfWk0a10GpQDrjv3jJkYJJN 7F6L7sfVRhTX2up2JsTBuVdKR8NqHvOdAzVBr6u8wgc2vG27+RCaVMQCVHOVoclKlimOxC gCaUBlpj6SGlxN9QxYF9QO9sWM/xIIA=; Received: from [172.20.10.2] ((unknown) [212.183.128.229]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 28 Apr 2013 22:33:28 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <517D855C.40701@isode.com> Date: Sun, 28 Apr 2013 21:23:56 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Carsten Bormann References: <515D75FE.9070008@isode.com> <8C2FE55F-A4FF-4340-AEBF-C626B42BAA67@tzi.org> In-Reply-To: <8C2FE55F-A4FF-4340-AEBF-C626B42BAA67@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "HE, XUAN -HCHBJ" , core@ietf.org, draft-ietf-core-coap.all@tools.ietf.org, IETF Apps Discuss , The IESG Subject: Re: [core] [apps-discuss] AppsDir 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, 28 Apr 2013 21:33:33 -0000 On 04/04/2013 14:57, Carsten Bormann wrote: > Hi Alexey, Hi Carsten, Sorry for the slow response, I was on holidays. > thank you for this review. > >> In Section 3, version number field: have you thought about backward compatibility rules for future versions (if any) and version negotiation rules? > I don't think we discussed this in the WG. > I remember some hallway discussions the gist of which is approximately: > We don't know yet why we would have a version transition, so it is hard to plan for it. > Whatever we define now is likely to be wrong when we actually know what we need. > Anything that is radical enough that we can't express it in an option is likely to change the message layout enough that it's not even clear what kind of error response to send back. > Sending back something for anything also has its perils. > > So the version number is mainly in there as an insurance against unknown unknowns. > One other purpose is to allow some multiplexing on the UDP port, including to avoid STUN codepoints. Ok. >> In Section 4.6: is a SHOULD requirement on IP MTU actually valid in this document? IMHO, you can't redefine what relevant RFCs say about that. > There is no SHOULD on the MTU, but a SHOULD on what CoAP implementations should assume as an MTU. > Most of our users think in terms of IPv6, so 1280 is a good assumption. > For IPv4, 1280 is also a good base assumption. There is an extensive implementation note on that, which qualifies this further. > > The upshot really is that you want to limit the payload size to 1KiB and, if you use all that, be reasonable about the option size; but for constrained applications, these numbers are already high. I would rather you said just that in the document. But Ok, your explanation is sufficient. >> In 5.10.8, last para: wouldn't it be more correct to say that preconditions must be tested after all other verification is performed? If not, what is the intent of the MAY? > It gives the server some lenience. It does allow checking for the preconditions first, and it does allow for checking them last. (We always try to give the server some lenience to implement things in a way that is best for the specific constrained node.) In other words, the client cannot rely on, say, a 4.05 indicating that the preconditions did match, or on a 4.12 indicating that the method would have been allowed, but the server is free to check things in either order. I am not sure this is very interoperable, but maybe this doesn't matter. >> In 6.4: why is URI's default encoding is UTF-8 and not ASCII? URIs can't contain 8bit data. Or did you mean IRIs? (Hopefully you haven't!) > We certainly didn't mean IRIs. Specifying UTF-8 and ASCII should be equivalent here. > (Either way is likely to confuse a different part of the audience.) I think you should just say ASCII. From cabo@tzi.org Sun Apr 28 15:02: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 2777F21F9682; Sun, 28 Apr 2013 15:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.482 X-Spam-Level: X-Spam-Status: No, score=-105.482 tagged_above=-999 required=5 tests=[AWL=0.767, 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 Q6gks7xusNDk; Sun, 28 Apr 2013 15:02:47 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5E29121F8233; Sun, 28 Apr 2013 15:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r3SM2bQx003649; Mon, 29 Apr 2013 00:02:37 +0200 (CEST) Received: from [192.168.217.105] (p54894882.dip0.t-ipconnect.de [84.137.72.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 84ECF3173; Mon, 29 Apr 2013 00:02:36 +0200 (CEST) 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: <517D855C.40701@isode.com> Date: Mon, 29 Apr 2013 00:02:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <515D75FE.9070008@isode.com> <8C2FE55F-A4FF-4340-AEBF-C626B42BAA67@tzi.org> <517D855C.40701@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1503) Cc: "HE, XUAN -HCHBJ" , core@ietf.org, draft-ietf-core-coap.all@tools.ietf.org, IETF Apps Discuss , The IESG Subject: Re: [core] [apps-discuss] AppsDir 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, 28 Apr 2013 22:02:48 -0000 Hi Alexey, > Sorry for the slow response, I was on holidays. I'll start my vacation (in Russia, by the way) on Friday... Hope to have a -16 by then. >>> In 6.4: why is URI's default encoding is UTF-8 and not ASCII? URIs = can't contain 8bit data. Or did you mean IRIs? (Hopefully you haven't!) >> We certainly didn't mean IRIs. Specifying UTF-8 and ASCII should be = equivalent here. >> (Either way is likely to confuse a different part of the audience.) >=20 > I think you should just say ASCII. This is what the current draft -16pre says: 2. Resolve the |url| string using the process of reference resolution defined by [RFC3986]. At this stage the URL is in ASCII encoding [RFC0020], even though the decoded components will be interpreted in UTF-8 [RFC3629] after step 5, 8 and 9. I think this should be much clearer. Gr=FC=DFe, Carsten From esko.dijk@philips.com Mon Apr 29 00:43: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 A181B21F94CC for ; Mon, 29 Apr 2013 00:43:54 -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 fOS8+axO0XUc for ; Mon, 29 Apr 2013 00:43:54 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id DB24B21F9497 for ; Mon, 29 Apr 2013 00:43:50 -0700 (PDT) Received: from mail1-va3-R.bigfish.com (10.7.14.230) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Mon, 29 Apr 2013 07:43:50 +0000 Received: from mail1-va3 (localhost [127.0.0.1]) by mail1-va3-R.bigfish.com (Postfix) with ESMTP id E306030010C; Mon, 29 Apr 2013 07:43: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: -33 X-BigFish: VPS-33(zz98dI15d6O9251Jc89bh542I1432I217bIzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz8275dh1033ILz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1155h) Received: from mail1-va3 (localhost.localdomain [127.0.0.1]) by mail1-va3 (MessageSwitch) id 1367221428450916_27592; Mon, 29 Apr 2013 07:43:48 +0000 (UTC) Received: from VA3EHSMHS036.bigfish.com (unknown [10.7.14.245]) by mail1-va3.bigfish.com (Postfix) with ESMTP id 69977240043; Mon, 29 Apr 2013 07:43:48 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS036.bigfish.com (10.7.99.46) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 29 Apr 2013 07:43:48 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.176]) by 011-DB3MMR1-004.MGDPHG.emi.philips.com ([10.128.28.54]) with mapi id 14.02.0328.011; Mon, 29 Apr 2013 07:43:47 +0000 From: "Dijk, Esko" To: Carsten Bormann , "Kovatsch Matthias" Thread-Topic: [core] I-D Action: draft-ietf-core-groupcomm-06.txt Thread-Index: AQHON3xmIL4DCVtc+EGTnUynhWYw0ZjdUGMAgAUZZ4CACnPeMA== Date: Mon, 29 Apr 2013 07:43:45 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C198AE@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <20130412124959.22556.94358.idtracker@ietfa.amsl.com> <55877B3AFB359744BA0F2140E36F52B514E8C867@MBX20.d.ethz.ch> <1D0C7346-F410-4E90-B030-7CB10D3EE55E@tzi.org> In-Reply-To: <1D0C7346-F410-4E90-B030-7CB10D3EE55E@tzi.org> 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@ietf.org" Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-06.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 07:43:54 -0000 > Several questions come to my (WG member) mind: > > -- the format has both multicast names and addresses -- which ones are ne= eded? What if resolution disagrees? The current solution has per entry an IP address and/or name, so it was int= ended as follows: if an IP address is given, this takes priority. (The name= is just informational in this case.) If only a name is given, the CoAP end= point has to do DNS resolution to obtain the IP address. (If it can't do DN= S resolution - there's currently no way defined to detect/fix this.) We can= update the text to reflect this. > -- a single /gp for all multicast groups may become unwieldy if multiple = groups need adds and removes -- how does the manager of one group know what= other groups the node should be in? > -- removes: the current text only has a PUT replacement of the whole grou= p to do this. Maybe a set of requirements is needed for the solution :) that way we make= explicit whether there's only a single manager involved or multiple may be= present. Similar for the 'remove' function, or updating of individual entr= ies. The assumption for this solution was always a single all-knowing manag= er to make the CoAP-device side as simple as possible. Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Car= sten Bormann Sent: Monday, April 22, 2013 17:17 To: Kovatsch Matthias Cc: core@ietf.org Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-06.txt On Apr 19, 2013, at 11:24, "Kovatsch Matthias" wrot= e: > propose to register a proper hypermedia type Indeed. Several questions come to my (WG member) mind: -- the format has both multicast names and addresses -- which ones are need= ed? What if resolution disagrees? -- a single /gp for all multicast groups may become unwieldy if multiple gr= oups need adds and removes -- how does the manager of one group know what o= ther groups the node should be in? -- removes: the current text only has a PUT replacement of the whole group = to do this. More meta: -- should we do this format in here? This may be a bit beyond what an info= rmational document does. On the other hand, we have a lot of informational media type registratio= ns. -- if we want to standardize this format, it this the right time? The format would have to fit into other API-related formats, and I'm not= sure we have found our style for these yet. I'm very much for exploring this more, I'm just not sure what exactly the o= utcome should be at this point. Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From trac+core@trac.tools.ietf.org Mon Apr 29 00:48: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 9E41821F97EE for ; Mon, 29 Apr 2013 00:48:12 -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 uTTVkbsB2740 for ; Mon, 29 Apr 2013 00:48:12 -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 0BE6C21F97C5 for ; Mon, 29 Apr 2013 00:48:11 -0700 (PDT) Received: from localhost ([127.0.0.1]:54096 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWioi-0006O1-EH; Mon, 29 Apr 2013 09:48:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 29 Apr 2013 07:48:08 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/299 Message-ID: <060.4297d5cdaa7cf5b347c3eb8fc5264bfe@trac.tools.ietf.org> X-Trac-Ticket-ID: 299 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130429074812.0BE6C21F97C5@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 00:48:11 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #299: Introduce new hypermedia type / content-format for group management X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 07:48:12 -0000 #299: Introduce new hypermedia type / content-format for group management Groupcomm-06 Section 3.6; Introduce a dedicate content-format for the JSON description of multicast groups that a CoAP endpoint is member of. Mentioned by Matthias Kovatsch (thread http://www.ietf.org/mail- archive/web/core/current/msg04264.html) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: new enhancement | Milestone: Priority: major | Version: Component: groupcomm | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Apr 29 00:50:41 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F0F21F9A00 for ; Mon, 29 Apr 2013 00:50:40 -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 tMqJtidvPeSV for ; Mon, 29 Apr 2013 00:50:39 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 20D2121F99EC for ; Mon, 29 Apr 2013 00:50:39 -0700 (PDT) Received: from localhost ([127.0.0.1]:54178 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWir3-0008Ct-4Q; Mon, 29 Apr 2013 09:50:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 29 Apr 2013 07:50:33 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/300 Message-ID: <060.8f42cd858e81ce968cf05a558a0a45c5@trac.tools.ietf.org> X-Trac-Ticket-ID: 300 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20130429075039.20D2121F99EC@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 00:50:39 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #300: Clarify semantics of group management JSON format X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 07:50:41 -0000 #300: Clarify semantics of group management JSON format groupcomm-06 section 3.6: Clarify semantics of group management JSON format. It's unclear what the optional presence/absence of multicast IP address and hostname mean, currently. Mentioned by Carsten (thread http://www.ietf.org/mail- archive/web/core/current/msg04267.html) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: new enhancement | Milestone: Priority: major | Version: Component: groupcomm | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: core From alexey.melnikov@isode.com Mon Apr 29 02:31: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 9C9D421F9A33; Mon, 29 Apr 2013 02:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 2DTRzR-VwRlr; Mon, 29 Apr 2013 02:31:06 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 807C621F9A31; Mon, 29 Apr 2013 02:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1367227863; d=isode.com; s=selector; i=@isode.com; bh=fJU+7I+0o8cfbe+c74zZ2jtCqFxcy3chDpxmGbC0kc0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=GITAbdv6eCqRUpHhgP1IUfc+z2bN/yecHx2aiSQwq7VZTKlVkt00JTV0wsV/Lw3GfO7VeF 62iVma5plBkz/5KHMsCfoklFdqkEnRvAMDZevDqGCeyA7B3dHiWmZBeqxU/2cIW2DlphMo fWdIE39kCRPQ9goq9GflVFbU7enfbhY=; Received: from [172.17.128.24] (richard.isode.com [62.3.217.249]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 29 Apr 2013 10:31:03 +0100 References: <515D75FE.9070008@isode.com> <8C2FE55F-A4FF-4340-AEBF-C626B42BAA67@tzi.org> <517D855C.40701@isode.com> In-Reply-To: Message-Id: <5387C390-3033-4455-B8C8-8172897F2B0F@isode.com> X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Mon, 29 Apr 2013 10:33:56 +0100 To: Carsten Bormann MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cc: "HE, XUAN -HCHBJ" , "core@ietf.org" , "draft-ietf-core-coap.all@tools.ietf.org" , IETF Apps Discuss , The IESG Subject: Re: [core] [apps-discuss] AppsDir 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: Mon, 29 Apr 2013 09:31:07 -0000 On 28 Apr 2013, at 23:02, Carsten Bormann wrote: > Hi Alexey, >=20 >> Sorry for the slow response, I was on holidays. >=20 > I'll start my vacation (in Russia, by the way) on Friday... > Hope to have a -16 by then. >=20 >>>> In 6.4: why is URI's default encoding is UTF-8 and not ASCII? URIs can'= t contain 8bit data. Or did you mean IRIs? (Hopefully you haven't!) >>> We certainly didn't mean IRIs. Specifying UTF-8 and ASCII should be equ= ivalent here. >>> (Either way is likely to confuse a different part of the audience.) >>=20 >> I think you should just say ASCII. >=20 > This is what the current draft -16pre says: >=20 > 2. Resolve the |url| string using the process of reference > resolution defined by [RFC3986]. At this stage the URL is in > ASCII encoding [RFC0020], even though the decoded components will > be interpreted in UTF-8 [RFC3629] after step 5, 8 and 9. >=20 > I think this should be much clearer. Yes, this works. Thanks! From cabo@tzi.org Mon Apr 29 02:57:56 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA1E21F9961; Mon, 29 Apr 2013 02:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0az8Rdd0KQGJ; Mon, 29 Apr 2013 02:57:55 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8A69621F9949; Mon, 29 Apr 2013 02:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r3T9vqgP023805; Mon, 29 Apr 2013 11:57:52 +0200 (CEST) Received: from [192.168.217.105] (p54894882.dip0.t-ipconnect.de [84.137.72.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AEFCF33FB; Mon, 29 Apr 2013 11:57:51 +0200 (CEST) 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: <20130425032117.15766.38491.idtracker@ietfa.amsl.com> Date: Mon, 29 Apr 2013 11:57:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0EB9BEF9-AF13-4ADF-858D-38B7418D7232@tzi.org> References: <20130425032117.15766.38491.idtracker@ietfa.amsl.com> To: Richard Barnes X-Mailer: Apple Mail (2.1503) Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, The IESG , core@ietf.org Subject: Re: [core] Richard Barnes' Discuss on draft-ietf-core-coap-15: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Apr 2013 09:57:56 -0000 Richard, thank you for this review. I have done some of the changes as simple editorial fixes, these are marked like [1329] below and can be reviewed in http://trac.tools.ietf.org/wg/core/trac/changeset/1329 (Overview in http://trac.tools.ietf.org/wg/core/trac/timeline). Some of the replies are marked "-> Ticket": This means that the authors think that the change is a good idea, but probably needs a bit more discussion with the WG, so we will handle this as a ticket. Gr=FC=DFe, Carsten = ---------------------------------------------------------------------- DISCUSS: = ---------------------------------------------------------------------- Overall, this is a very nicely written specification. Thanks! = There's just one point I think needs action on before I switch to a = "YES" position. In Section 5.3.1, "A client sending a request...". This needs = to be stronger. The requirement for a randomized token needs to be a = MUST, and the stack SHOULD limit the number of rejected responses (before = closing the request) based on the length of the token (e.g., = 2**(TKL/2)). (See also Stephen's most recent reply: http://www.ietf.org/mail-archive/web/core/current/msg04302.html where he seems to argue for a RECOMMENDATION.) The specification is currently leaving to the client the level of protection that it makes use of: It can choose the token length based on its security requirements. The phrasing certainly can be improved to avoid the RFC6919 allusion (as in "MAY WISH TO") and to explain the criteria for choosing the size. E.g., explain that, with N=3DTKL*8 (possibly plus 16 if this is an ACK and the Message ID also matches, even though that should generally not be randomized), an off-path attacker has a chance of 2**-N per spoof to successfully spoof a response. To the lockdown proposal (2**(N/2)): Interesting idea. We don't have experience with that yet. One issue might be correlating incoming non-matching responses to a specific request. As with any lockdown mechanism, the potential for DoS (or pure malfunction) also needs to be considered. A client that keeps some state can tally recent non-matching responses to derive a "current attack level"; this might then be used to adjust its token length for future requests. (In today's constrained node networks, attack packet rates that make this more than a somewhat theoretical concern already will cause other problems, but we'll need to make the protocol robust for the "cloud" side as well.) -> Ticket = ---------------------------------------------------------------------- COMMENT: = ---------------------------------------------------------------------- In Section 2.2., are requests and responses in 1-1 = correspondence? Or can a single request receive more than one response? Section 2.2 doesn't explain that, but, indeed, a request might receive more than one response, which we use for multicast and draft-ietf-core-observe, (and, for future methods, even less than one response). I think I'd rather discuss this in section 5, though. -> Ticket In Section 3, why is version number 1 and not 0? What's the = plan here, do we get 3 or 4 versions out of this? (A version number 4 could be represented modulo 4, i.e. as 0. But:) In the reply to the appdir review, I wrote: ~~~ We don't know yet why we would have a version transition, so it is hard = to plan for it. Whatever we define now is likely to be wrong when we actually know what = we need. Anything that is radical enough that we can't express it in an option is = likely to change the message layout enough that it's not even clear what = kind of error response to send back. =20 Sending back something for anything also has its perils. So the version number is mainly in there as an insurance against unknown = unknowns. One other purpose is to allow some multiplexing on the UDP port, = including to avoid STUN codepoints. ~~~ So, in summary, it is not clear that we would have a "version 2", or use the version field (e.g., in conjunction with the token length field) for something more complicated. Starting with the value 1 for the version field was mainly motivated by trying to avoid the codepoints of STUN and DTLS for operational purposes. In Section 4.3, would it make sense to have something stronger = than MAY for cases where future messages are likely to be screwed up, = e.g., where CoAP syntax is malformed? (A "STFU RST"?) CoAP implementations are likely to be simple-minded, so if they are misbehaving, sending them more packets is not very likely to help. Also, there are security implications for a "STFU RST"... (Actually, with -observe, a RST is pretty much a STFU.) =46rom Section 4.2 and 4.3, I generated a table mapping message = types to request/response/empty: CON NON ACK RST Request X X ? ! Response X X X ! Empty ! ! X X =20 Might be helpful to include something like that as a summary. Good idea! [1329] This might be a bad idea, but: Did the WG consider allowing an ACK to = contain a request? In the case where a CON contains a response and the = client wants to send another request, it would save a message to put = the request in the ACK to the response. Well, what if that ACK is lost? Nobody would have the initiative to retransmit it. (See also reply to Ted Lemon.) One way to save a packet here might be to aggregate multiple CoAP messages (here: ACK and CON) into one packet. That was discussed for a while, but in the end didn't receive much support as it was considered an unnecessary complication. (Message aggregation also can quickly lead to packet fragmentation.) From cabo@tzi.org Mon Apr 29 04:32: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 A827A21F9D24; Mon, 29 Apr 2013 04:32:38 -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 a8cXysHxjK1y; Mon, 29 Apr 2013 04:32: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 DE39D21F99E8; Mon, 29 Apr 2013 04:32: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 r3TBVsWR007620; Mon, 29 Apr 2013 13:31:55 +0200 (CEST) Received: from [192.168.217.105] (p54893A4B.dip0.t-ipconnect.de [84.137.58.75]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EE46534F2; Mon, 29 Apr 2013 13:31:53 +0200 (CEST) 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: <517D47CA.1030900@cs.tcd.ie> Date: Mon, 29 Apr 2013 13:31:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130425012605.7589.40567.idtracker@ietfa.amsl.com> <517D47CA.1030900@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1503) Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, The IESG , core@ietf.org Subject: Re: [core] Stephen Farrell's Discuss on draft-ietf-core-coap-15: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Apr 2013 11:32:38 -0000 On Apr 28, 2013, at 18:01, Stephen Farrell = wrote: >> It just seems broken to pretend to use https this way. Going >> via a cross-proxy breaks security. Similarly, what does coaps >> mean in 10.2? >>=20 >> Again, doing this kind of proxying only makes sense if the proxy has = a >> legitimate role. >=20 > Hmmm. I suspect we'll want to chat more about this one. > I don't see how the sender can in general know whether > or not a "legitimate" proxy is going to do the right, > or entirely wrong, thing. I also think that if an HTTPS > endpoint somewhere on the Internet hands out an https URL > then the current scheme doesn't meet their expectations > in quite a bad way. So let's talk about the proxy thing. A forward proxy is explicitly chosen by the client. One would expect the client to choose a proxy that will fit to its = security requirements. (Assuming that the client cannot talk https directly, which would always = be preferable.) What can we do in the protocol to make this work better? A reverse proxy somehow managed to get itself accepted in the DTLS = handshake. So it seems to work together with the origin server, which we hope will = work with it on its security requirements. Again, what can we do in the protocol to make this work better? The underlying problem, again, is that a coaps (or https) URI only gives = a boolean "be secure", but doesn't tell you what the kind of security = assurance is that you need. I think that is an important thing to work = on (many people actually strongly disagree with that). I just think it = is more general about the use of URIs in the Web, not just about the = CoRE part of it. In the HTTP world, we are using HSTS to augment the = security semantics of an http URI out of band, cert pinning or trying to = add things from the DNSSEC side does the same for https URIs. We also have to think about what the equivalent to an httpauth would be = in the CoRE world. What we can do at the moment is authentication via DTLS, keeping = authorization completely outside the protocol. You cannot help a proxy = authenticate to the next endpoint. Some form of delegated authorization = will also need to be added, and that will have to work through proxies, = too. A student here actually implemented a form of OAuth 2.0 proxy, in = order to be able to talk to a google+ service from a CoAP client. Gr=FC=DFe, Carsten From stephen.farrell@cs.tcd.ie Mon Apr 29 07:13: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 4A51421F9402; Mon, 29 Apr 2013 07:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teeLV3G2004h; Mon, 29 Apr 2013 07:13:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3273321F99E9; Mon, 29 Apr 2013 07:13:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A3B60BE5C; Mon, 29 Apr 2013 15:13:03 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YSp7S5zc4Eo; Mon, 29 Apr 2013 15:13:03 +0100 (IST) Received: from [IPv6:2001:770:10:203:8409:d52d:30e3:9901] (unknown [IPv6:2001:770:10:203:8409:d52d:30e3:9901]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7F22BBE5B; Mon, 29 Apr 2013 15:13:03 +0100 (IST) Message-ID: <517E7FF0.9020202@cs.tcd.ie> Date: Mon, 29 Apr 2013 15:13:04 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: Carsten Bormann References: <20130425012605.7589.40567.idtracker@ietfa.amsl.com> <517D47CA.1030900@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, The IESG , core@ietf.org Subject: Re: [core] Stephen Farrell's Discuss on draft-ietf-core-coap-15: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Apr 2013 14:13:28 -0000 On 04/29/2013 12:31 PM, Carsten Bormann wrote: > On Apr 28, 2013, at 18:01, Stephen Farrell wrote: > >>> It just seems broken to pretend to use https this way. Going >>> via a cross-proxy breaks security. Similarly, what does coaps >>> mean in 10.2? >>> >>> Again, doing this kind of proxying only makes sense if the proxy has a >>> legitimate role. >> >> Hmmm. I suspect we'll want to chat more about this one. >> I don't see how the sender can in general know whether >> or not a "legitimate" proxy is going to do the right, >> or entirely wrong, thing. I also think that if an HTTPS >> endpoint somewhere on the Internet hands out an https URL >> then the current scheme doesn't meet their expectations >> in quite a bad way. > > So let's talk about the proxy thing. > > A forward proxy is explicitly chosen by the client. > One would expect the client to choose a proxy that will fit to its security requirements. Yeah. Doesn't always happen though. > (Assuming that the client cannot talk https directly, which would always be preferable.) > What can we do in the protocol to make this work better? Yes, if (D)TLS works from the client that's better. Sure. However, as-is, I think the spec says that a client with a configured forward proxy just sends all https or coaps URIs in clear to that proxy and gets responses in clear. Is that right? I note that that forward proxy is also allowed to have another forward proxy, so in practice a coaps or https request could get all the way to the origin server with only the very last hop using (D)TLS. I assume someone suggested at some point to never send coaps or https out in clear. What was the winning argument against that? (A pointer to the list archive will do if there's a good thread.) > A reverse proxy somehow managed to get itself accepted in the DTLS handshake. > So it seems to work together with the origin server, which we hope will work with it on its security requirements. > Again, what can we do in the protocol to make this work better? I'm less sure here to be honest. On the web most reverse proxies are tightly coupled to the "real" application server in a maybe-secure environment (e.g. a DMZ) - is that considered likely to be the same with CoAP? I guess scenarios where a UA on the Internet accesses an actuator via a coaps or https URI but where there's a cleartext CoAP exchange between a reverse proxy and the actual actuator node might be somewhat to very scary. (And I could see people deploying that with crappy or no authentication too since it'd be "encrypted over the Internet" according to their marketing literature;-) > The underlying problem, again, is that a coaps (or https) URI only gives a boolean "be secure", but doesn't tell you what the kind of security assurance is that you need. I think that is an important thing to work on (many people actually strongly disagree with that). I just think it is more general about the use of URIs in the Web, not just about the CoRE part of it. In the HTTP world, we are using HSTS to augment the security semantics of an http URI out of band, cert pinning or trying to add things from the DNSSEC side does the same for https URIs. > > We also have to think about what the equivalent to an httpauth would be in the CoRE world. > What we can do at the moment is authentication via DTLS, keeping authorization completely outside the protocol. You cannot help a proxy authenticate to the next endpoint. Some form of delegated authorization will also need to be added, and that will have to work through proxies, too. A student here actually implemented a form of OAuth 2.0 proxy, in order to be able to talk to a google+ service from a CoAP client. I agree that the above are good things for future work, i.e. the DISCUSS isn't saying that I think you need to solve e2e authentication and authorization now for all proxy scenarios. Cheers, S. > Gre, Carsten > From adrian@olddog.co.uk Mon Apr 29 07:34:52 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F9E21F9E3A; Mon, 29 Apr 2013 07:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ZpxxxoLMcr24; Mon, 29 Apr 2013 07:34:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5B021F9E44; Mon, 29 Apr 2013 07:34:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Adrian Farrel" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130429143451.13168.40760.idtracker@ietfa.amsl.com> Date: Mon, 29 Apr 2013 07:34:51 -0700 Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Adrian Farrel's Yes on draft-ietf-core-coap-15: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Apr 2013 14:34:53 -0000 Adrian Farrel has entered the following ballot position for draft-ietf-core-coap-15: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I want to thank the authors and WG for producing this specification. I think it may be one of the more important pieces of work in recent years. As might be expected with a document of over 100 pages reviewed by a pedant, I have a list of nits and worries. These are all enetered as Comments: I hope you will find time to address them and make the resulting RFC more polished, but none of them comes even close to a requirement that you change the text, and I am ballotting Yes. --- How quickly we forget! I looked up the spec of a typical home computer around the time of HTTP v1.0 and discovered that it was not so very different from what you are scoping your environment to today. That is not to say that your work is not valid. Far from it! But I do believe it might be helpful to explore in more detail why you don't simply run an early, low-function version of HTTP. FWIW, I believe the answer is that you want some of the advanced functions that have been added to HTTP over the years, but do not want the full family of rich features that may chew memory and bandwidth. --- What about the use of CoAP on the wider Internet? --- A very minor terminology point from Section 1.2 Confirmable Message Some messages require an acknowledgement. These messages are called "Confirmable". When no packets are lost, each Confirmable message elicits exactly one return message of type Acknowledgement or type Reset. Non-confirmable Message Some other messages do not require an acknowledgement. This is particularly true for messages that are repeated regularly for application requirements, such as repeated readings from a sensor. You have picked a form "confirmable" and "non-confirmable" tha expresses the ability to do something: this message can be confirmed. But you have mapped the form to a description that requires action: an acknowledgement must be sent. "Can be confirmed" !=3D "A confirmation must be sent" "Cannot be confirmed" !=3D "A conformation does not need to be sent" I don't believe this is too important because you are defining the tems, but I do think that the casual reader will not embed your redefinitions of normal English words, and so will be confused by these terms in the text. --- Section 1.2. Also a very minor point. Acknowledgement Message An Acknowledgement message acknowledges that a specific Confirmable Message arrived. It does not indicate success or failure of any encapsulated request. The fact that and Acknowledgement Message can carry a response is lost in this definition. Maybe you need (including fixes to your typos)... Acknowledgement Message An Acknowledgement Message acknowledges that a specific Confirmable Message arrived. Of itself, an Acknoweledgement Message does not indicate success or failure of any request encapsulated in the Confirmable Message, but the Acknoweledgement Message may also carry a Piggy-backed response (q.v.). --- My feeling was that the Message IDs shown in figures 2 through 6 were confusing in their randomness. For example, you could spend a lot of time staring at figures 2 and 3 trying to work out how CON is encodeded as 0x7d34 while NON is encoded as 0x01a0. Since you want to show Message IDs to show how they correspond on different parts of the flow, you could have written, e.g., Client Server | | | CON [MsgID1] | +----------------->| | | | ACK [MsgID1] | |<-----------------+ | | --- Section 2.1 As CoAP is based on UDP, it also supports the use of multicast IP I don't think it is based on UDP. I think it runs over UDP. --- Section 2.3 As CoAP was designed according to the REST architecture and thus Maybe insert another pointer to [REST]. --- Section 4.2 A Confirmable message always carries either a request or response and MUST NOT be empty, unless it is used only to elicit a Reset message. That is a bit of an over-use of "MUST NOT". I think = A Confirmable message = always carries either a request or response, unless it is used only to elicit a Reset message in which case it is empty. --- 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. This paragraph is giving me some worries. I think the initial MAY confuses the CoAP implementation with the = endpoint containing the CoAP implementation. The endpoint may give up, and may instruct the CoAP implementation to stop retransmitting. But I think a CoAP implementaiton must not give up unless it is told to. The drop from MUST NOT to SHOULD in the final sentence seems odd. My understanding was that a CoAP implementation MUST always retain the = state to create the ACK for the request. Is this use of SHOULD a relaxation, and how does it square with the MUST NOT? --- Section 4.6 Messages larger than an IP fragment result in undesired packet fragmentation. s/undesired/undesirable/ ? --- Section 4.6 A CoAP message, appropriately encapsulated, SHOULD fit within a single IP packet (i.e., avoid IP fragmentation) and (by fitting into one UDP payload) obviously MUST fit within a single IP datagram. s/MUST/will/ --- Section 12 I am surprised that IANA was relaxed about the use of "reserved" in = Section 12. = For example, in 12.1 you have two ranges marked "Reserved" without any clue to what this means. For example, does it mean that allocations can be made, that an RFC can dedicate them to a new use, or that they must never be allocated? In 12.1.2 you have = The Response Codes 96-127 are Reserved for future use. All other Response Codes are Unassigned. I take "Unassigned" to mean available for assignment according to the = policy for the registry. But "Reserved or future use" means what? In 12.2 you have = | 0 | (Reserved) | | This is the meaning of "reserved" I think we are used to, and means will not be made available for allocation. (Although I am puzzled that you = don't include the pointer to this RFC.) From cabo@tzi.org Mon Apr 29 07:52: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 6ED0621F9DDD; Mon, 29 Apr 2013 07:52:31 -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 OemF6xdPpQLj; Mon, 29 Apr 2013 07:52:30 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 80F3221F9DC8; Mon, 29 Apr 2013 07:52: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 r3TEqPKN027496; Mon, 29 Apr 2013 16:52:25 +0200 (CEST) Received: from [192.168.217.105] (p54893A4B.dip0.t-ipconnect.de [84.137.58.75]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 290853738; Mon, 29 Apr 2013 16:52:25 +0200 (CEST) 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: <20130425033226.32552.99254.idtracker@ietfa.amsl.com> Date: Mon, 29 Apr 2013 16:52:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <457E56CC-B066-4F0D-8941-B97D30C95C18@tzi.org> References: <20130425033226.32552.99254.idtracker@ietfa.amsl.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, The IESG , core@ietf.org Subject: Re: [core] Ted Lemon's No Objection on draft-ietf-core-coap-15: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Apr 2013 14:52:31 -0000 Ted, thank you for this review. I have done some of the changes as simple editorial fixes, these are marked like [1330] below and can be reviewed in http://trac.tools.ietf.org/wg/core/trac/changeset/1330 (Overview in http://trac.tools.ietf.org/wg/core/trac/timeline). Some of the replies are marked "-> Ticket": This means that the authors think that the change is a good idea, but probably needs a bit more discussion with the WG, so we will handle this as a ticket. Gr=FC=DFe, Carsten = ---------------------------------------------------------------------- COMMENT: = ---------------------------------------------------------------------- P. 14: informative reference to HHGTG almost, but not entirely, helpful. :) The authors continue to believe that the quote describes the relationship between HTTP and CoAP in the most elucidating way... P. 15: why start at version 1 when you can only have a total of = 4 versions? Wouldn't version 0 be a better choice? (See my response to Richard Barnes.) P. 19: I'm a little uncomfortable with this text: There is no expectation and no need to perform normalization = within a CoAP implementation (except where Unicode strings = that are not known to be normalized are imported from sources outside the CoAP protocol). I think what's intended here is right, but you've mentioned what amounts to a strong suggestion, if not a requirement, as a parenthetical note. It seems like what you intended was = something like this: There is no expectation and no need to perform normalization within a CoAP implementation, since = senders are expected to be implemented with pre-normalized strings. However, strings received from non-CoAP = sources SHOULD be normalized where possible. Of course, there's actually no value to normalization in this = case if it can't be depended on, and I suspect that you don't want to = make that a MUST. So this might be a better way to do it: There is no expectation and no need to perform normalization within a CoAP implementation, since = senders are expected to be implemented with pre-normalized strings. Strings received from non-CoAP sources and = then forwarded by CoAP senders cannot be assumed to have = been normalized, and may not compare correctly with = normalized strings representing the same text. I don't have a strong opinion about how this should be done, but = it seems like the text as written doesn't give clear guidance. It = seems that cross-proxies ought to be able to do normalization, and = maybe other proxies could as well, but that's a much bigger change. Unicode normalization is always a sticky point. I think the choice of a point on the continuum between your suggestions (which I both like) needs to be discussed with the WG. -> Ticket. Section 4.1: Even though I think it doesn't make any sense to do = this, it might be worth stating how a receiver should behave if it = receives an ACK with a request. 4.2 says: "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). [Sentence about RST.] Rejecting an Acknowledgement or Reset message is effected by silently ignoring it." OK, that may not be as explicit as we thought: [1330] Section 4.2: Wouldn't this: More generally, Acknowledgement and Reset messages MUST NOT elicit = any Acknowledgement or Reset message from their recipient. be better stated this way? More generally, recipients of Acknowledgement and Reset = messages MUST NOT respond with either Acknowledgement or Reset = messages. Indeed: [1330] Might be worth grouping for operator precedence here: OLD: ACK_TIMEOUT * (2 ** MAX_RETRANSMIT - 1) * = ACK_RANDOM_FACTOR NEW: ACK_TIMEOUT * (2 ** (MAX_RETRANSMIT - 1)) * = ACK_RANDOM_FACTOR We actually mean: ACK_TIMEOUT * ((2 ** MAX_RETRANSMIT) - 1) * = ACK_RANDOM_FACTOR OLD: 2 * MAX_LATENCY + PROCESSING_DELAY NEW: (2 * MAX_LATENCY) + PROCESSING_DELAY Both are done in [1331] Section 5.8: The use of the word "safe" to describe methods is = really confusing because of save/unsafe options. It would help ease of comprehension if you used a different word--e.g., read-only. I realize that this goes somewhat against the idea of sharing nomenclature with HTTP, but I think the clash between = safe/unsafe options and safe/unsafe methods is confusing enough that you = aren't really benefiting from that anyway. Safe methods is a rather established piece of REST terminology. I'd rather rename the safe options. "safe" here is an abbreviation for = "safe-to-forward-in-a-proxy-while-not-understanding-them". My thesaurus is of no use ... (well, it does suggest "hairy" for unsafe. hairy and bald?) In 5.9: as a user and implementor of RESTful systems who has = learned by doing more than by reading, the term "action result" is = somewhat opaque to me. I think I know what it means, but it might be = nice to explain what it means before using it like this: Like HTTP 201 "Created", but only used in response to POST and = PUT requests. The payload returned with the response, if any, is = a representation of the action result. 5.5.1 introduces the concept, but without putting "action" and "result" beside each other. Added that. [1332] 5.9.2.2: I think you mean "first" rather than "previously": The client is not authorized to perform the requested action. = The client SHOULD NOT repeat the request without previously = improving its authentication status to the server. Which specific mechanism = can be used for this is outside this document's scope; see also = Section 9. [1333] 5.10.1: how does the client know that an endpoint hosts multiple virtual servers in time to leave out the Uri-Host option? Is = this literally just in the case where the hostname appears in the URI = to be decomposed as an IP address literal? are sufficient for requests to most servers. Explicit = Uri-Host and Uri-Port Options are typically used when an endpoint hosts = multiple virtual servers. Indeed, the Uri-Host option can use its default value only when the URI has an IP address literal. In 5.10.8.2: I can't quite understand what is meant here. I = could see it meaning either or both of the following: 1. If If-None-Match appears in a query with one or more = If-Match options, and none of the If-Match options match, the condition = is fulfilled. That is not what we mean. If-None-Match is not meant to be combined with If-Match. 2. If If-None-Match appears in a query, no If-Match options = may appear in that query; the condition is met if the target = doesn't exist. Yes. I think that the text means just (2), but because of the name of = the option, I want it to mean (1), even though the text doesn't say = that, and since the text doesn't say that If-None-Match and If-Match = are mutually exclusive, I can easily imagine someone reading the = text and carelessly assuming that it means (1) or (1 or 2). I clarified this somewhat. [1334] In 6.4, why /url/? This is really confusing--I was halfway = through this section, and kind of confused, before I realized that the = slashes were for emphasis, and weren't path separators. It is hard to provide emphasis for variable names for pseudo-code in an ASCII-only document. I replaced the slahes by vertical bars, knowing well that this might offend mathematicians. [1335] Also in 6.4, the text does not account for the case where = there's a user part to the authority section of the URI. It is not meant to. This could never occur until we introduced Proxy-Scheme; we need to add text that the use of Proxy-Scheme is not possible in this case. -> Ticket From trac+core@trac.tools.ietf.org Mon Apr 29 08:09: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 B2D4521F9E3F for ; Mon, 29 Apr 2013 08:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDUNEMgFMG5w for ; Mon, 29 Apr 2013 08:09:49 -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 24C4C21F9E39 for ; Mon, 29 Apr 2013 08:09:48 -0700 (PDT) Received: from localhost ([127.0.0.1]:56037 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWpi7-0000Lj-6b; Mon, 29 Apr 2013 17:09:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 29 Apr 2013 15:09:47 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/301 Message-ID: <051.7563e72089a600fb465c5ca371093e32@trac.tools.ietf.org> X-Trac-Ticket-ID: 301 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130429150949.24C4C21F9E39@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 08:09:48 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #301: Once separate, separate forever X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 15:09:49 -0000 #301: Once separate, separate forever Pete Resnick notes (msg04271a): Section 5.2.2 5.2.2: It is probably worth saying somewhere in here: "Once the server sends back an empty Acknowledgement, it MUST NOT send back the response in another Acknowledgement, even if the client retransmits another identical request. If a retransmitted request is received (perhaps because the original Acknowledgement was delayed), another empty Acknowledgement is sent and any response MUST be sent as a separate response." -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: other | Milestone: post-IESG-1 technical | Version: coap-15 Priority: minor | Keywords: Component: coap | Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Apr 29 08:13: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 6FA0B21F9389 for ; Mon, 29 Apr 2013 08:13: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=[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 2ZnDSpgmxuye for ; Mon, 29 Apr 2013 08:13: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 7BDFC21F9387 for ; Mon, 29 Apr 2013 08:13:00 -0700 (PDT) Received: from localhost ([127.0.0.1]:56385 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWplD-0005QC-3Q; Mon, 29 Apr 2013 17:12:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 29 Apr 2013 15:12:59 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/302 Message-ID: <051.a8274f5d8806b4cb6934402d708a1aac@trac.tools.ietf.org> X-Trac-Ticket-ID: 302 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130429151300.7BDFC21F9387@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 08:13:00 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #302: Define Cache-key properly X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 15:13:01 -0000 #302: Define Cache-key properly Pete Resnick notes (msg04271b): Section 5.4.2 5.4.2: Cache-Key is undefined, here or in any other document I can find. It probably needs an explanation somewhere in this document. Carsten says: The "cache key" is the informal concept that describes all the data that go into selecting the right cache instance, such as the URI, but also options such as "Accept". This concept is important to allow proxies (and other caches) to handle options they don't understand. We probably should describe this in 5.6 and do a foward reference here (there is little point in raising this already in 2.3, I think). Add at the end of (the introduction to) 5.6: »The set of options that is used for matching the cache entry is also collectively referred to as the "Cache-Key".« -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-15 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Apr 29 08:15:56 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5971F21F95EE for ; Mon, 29 Apr 2013 08:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 W5i3rEEzsKOd for ; Mon, 29 Apr 2013 08:15:55 -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 ABC3521F95EA for ; Mon, 29 Apr 2013 08:15:55 -0700 (PDT) Received: from localhost ([127.0.0.1]:56609 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWpo1-0005fl-UM; Mon, 29 Apr 2013 17:15:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 29 Apr 2013 15:15:53 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/303 Message-ID: <051.131a8cf335fc9b5591e5ef3d50ce8ec8@trac.tools.ietf.org> X-Trac-Ticket-ID: 303 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130429151555.ABC3521F95EA@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 08:15:55 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #303: Clarify that ACKs don't get retransmitted, the CONs do X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 15:15:56 -0000 #303: Clarify that ACKs don't get retransmitted, the CONs do Pete Resnick notes (msg04271c): Section 2.2 2.2: the response to a request carried in a Confirmable message is carried in the resulting Acknowledgement (ACK) message. This is called a piggy- backed response, detailed in Section 5.2.1. [...] If the server is not able to respond immediately to a request carried in a Confirmable message, it simply responds with an empty Acknowledgement message so that the client can stop retransmitting the request. When the response is ready, the server sends it in a new Confirmable message (which then in turn needs to be acknowledged by the client). It took me a bit to figure out why things worked this way, and I think a sentence or two of explanation would be useful. A piggy-backed response to a Confirmable request doesn't itself need to be confirmable because if the ACK gets lost, the client will re-transmit the request until it gets the answer. Carsten says: Yes, we could add that explanation. This is at an early stage in the exposition, so we have to figure out how to do this without generating confusion. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-15 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Apr 29 08:18:52 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910D421F9D98 for ; Mon, 29 Apr 2013 08:18:52 -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 C-S7nKvSfdej for ; Mon, 29 Apr 2013 08:18:52 -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 596B321F9D76 for ; Mon, 29 Apr 2013 08:18:46 -0700 (PDT) Received: from localhost ([127.0.0.1]:56721 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWpql-0001A9-Jw; Mon, 29 Apr 2013 17:18:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 29 Apr 2013 15:18:43 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/304 Message-ID: <051.448ad98d27c7eb82eda7957a9c0c66e4@trac.tools.ietf.org> X-Trac-Ticket-ID: 304 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130429151846.596B321F9D76@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 08:18:46 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #304: NON is like separate for CON X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 15:18:52 -0000 #304: NON is like separate for CON Pete Resnick notes (msg04271d): Section 2.2 When the response to a Confirmable request is not piggy-backed, the response should itself be Confirmable, since a Confirmable request will normally want a guaranteed response. Likewise, if a request is sent in a Non-confirmable message, then the response is usually sent using a new Non-confirmable message, although the server may send a Confirmable message. "Likewise" seems wrong here. A Non-confirmable request can *not* get an Acknowledgement message, and therefore can *not* get a piggy-backed response. Additionally, the response MAY be Confirmable or MAY be Non- confirmable, though certainly Non-Confirmable is the more likely case. This should probably be reworded. Carsten says: Likewise -> A similar form of separate response is used... -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-15 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Apr 29 08:22:37 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C06421F9D98 for ; Mon, 29 Apr 2013 08:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iMw9Xbx0MU7 for ; Mon, 29 Apr 2013 08:22:36 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5296321F9E0B for ; Mon, 29 Apr 2013 08:22:36 -0700 (PDT) Received: from localhost ([127.0.0.1]:56950 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWpuU-0007iL-M5; Mon, 29 Apr 2013 17:22:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 29 Apr 2013 15:22:34 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/305 Message-ID: <051.5bed01198eb0fab04aa653806903cbc7@trac.tools.ietf.org> X-Trac-Ticket-ID: 305 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130429152236.5296321F9E0B@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 08:22:36 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #305: Don't use decimal response codes, keep the 3+5 structure throughout X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 15:22:37 -0000 #305: Don't use decimal response codes, keep the 3+5 structure throughout Pete Resnick notes (msg04271e): Section 3 Code: 8-bit unsigned integer. Indicates if the message carries a request (1-31) or a response (64-191), or is empty (0). As above, why not make a 3-bit field for Code Type (000=request, 001=reserved, 010=success response, 100=client error response, 101 =server error response, 110/111=reserved), and then a 6-bit Code? It would also make the registry much easier to read. Carsten says: This requires some surgery but is probably a good idea. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-15 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Apr 29 08:25: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 6D67E21F9D98 for ; Mon, 29 Apr 2013 08:25:33 -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 rFakbol5NCR3 for ; Mon, 29 Apr 2013 08:25:32 -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 A7D9021F9E0E for ; Mon, 29 Apr 2013 08:25:32 -0700 (PDT) Received: from localhost ([127.0.0.1]:57246 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWpxL-0003oX-9G; Mon, 29 Apr 2013 17:25:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 29 Apr 2013 15:25:31 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/306 Message-ID: <051.a9a9c933046ce717a5f65ae69eb46e5e@trac.tools.ietf.org> X-Trac-Ticket-ID: 306 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130429152532.A7D9021F9E0E@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 08:25:32 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #306: RFC 2119 usage in 4.5 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 15:25:33 -0000 #306: RFC 2119 usage in 4.5 Pete Resnick notes (msg04271f): Section 4.5 4.5: All of the MUSTs and MAYs in the section are used rather terribly. I'm glad to suggest text if you need. Carsten says: This is a difficult section, because it has to express all the lenience that is needed to make very constrained implementations work. Text gladly accepted. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-15 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Apr 29 08:26: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 E1BAE21F9387 for ; Mon, 29 Apr 2013 08:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wWRBJJYctXF for ; Mon, 29 Apr 2013 08:26:28 -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 4ED2421F930A for ; Mon, 29 Apr 2013 08:26:26 -0700 (PDT) Received: from localhost ([127.0.0.1]:57266 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWpyD-0003kn-Io; Mon, 29 Apr 2013 17:26:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 29 Apr 2013 15:26:25 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/307 Message-ID: <051.aa90bbea462bd49525720f565fc937d9@trac.tools.ietf.org> X-Trac-Ticket-ID: 307 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130429152628.4ED2421F930A@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 08:26:26 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #307: RFC 2119 usage in 8.2 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 15:26:29 -0000 #307: RFC 2119 usage in 8.2 Pete Resnick notes (msg04271g): Section 8.2 8.2: "the server MAY always pretend"? We are getting sillier with our 2119 usage later in the document. Did you really mean, "the server MAY ignore the request"? Isn't that true of any NON request, not just multicast ones? Carsten says: Yes, but this section is giving a server specific license to discard incoming multicast at the slightest discomfort. We don't want to say the same for every NON. This certainly can be said in a better way -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-15 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Apr 29 08:29:11 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5F621F9E15 for ; Mon, 29 Apr 2013 08:29:11 -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 1B6aTod-NHKH for ; Mon, 29 Apr 2013 08:29:10 -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 4CF6421F9E0F for ; Mon, 29 Apr 2013 08:29:10 -0700 (PDT) Received: from localhost ([127.0.0.1]:57336 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWq0q-0002oZ-Vw; Mon, 29 Apr 2013 17:29:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 29 Apr 2013 15:29:08 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/308 Message-ID: <051.da8ada320410274d951a579e32b1c800@trac.tools.ietf.org> X-Trac-Ticket-ID: 308 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130429152910.4CF6421F9E0F@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 08:29:10 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #308: Make sure all protocol reactions to reserved or prohibited values are defined X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 15:29:11 -0000 #308: Make sure all protocol reactions to reserved or prohibited values are defined Martin Stiemerling notes (msg04278): 7) Protocol reactions to reserved or prohibited values Regarding reserved or prohibited values in the IANA section, it would be useful to be clear about what happens when those values are seen. I.e., should they be ignored, generate an error, etc. Carsten says: Good point. We need to check this in detail. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: other | Milestone: post-IESG-1 technical | Version: coap-15 Priority: minor | Keywords: Component: coap | Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Apr 29 08:36: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 DDF7821F9D1F for ; Mon, 29 Apr 2013 08:36:24 -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 R0A1JYcwNZ9W for ; Mon, 29 Apr 2013 08:36:24 -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 34D9721F9029 for ; Mon, 29 Apr 2013 08:36:23 -0700 (PDT) Received: from localhost ([127.0.0.1]:57870 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWq7p-000166-UG; Mon, 29 Apr 2013 17:36:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 29 Apr 2013 15:36:21 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/309 Message-ID: <051.f585672c1ab4fdc3979451b45ebc3fb9@trac.tools.ietf.org> X-Trac-Ticket-ID: 309 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130429153624.34D9721F9029@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 08:36:23 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #309: URI matching rules may be scheme specific X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 15:36:25 -0000 #309: URI matching rules may be scheme specific Stephen Farrell notes (msg04285a): Section 2.3 (1) 2.3: What if the URI scheme doesn't have a host or port or path or query? Also in 5.6, 2nd bullet in list: Just to note that if you were using ni URIs with CoAP, then you no longer need to insist on exactly the same URI (e.g. the authority part needn't matter with ni URIs, the alg-val part is what counts). That might be true of other schemes too, so perhaps this statment is scheme specific to some extent? Carsten says: That is a very good point. I think what happens here is that some schemes such as the ni scheme open a way of matching that is specific to that scheme and not available in the default case. We should add a statement to this effect to the definition of "Cache-Key" that needs to be added at the end of this section. Add at the end of (the introduction to) 5.6: »The set of options that is used for matching the cache entry is also collectively referred to as the "Cache-Key". For URI schemes other than coap and coaps, matching of those options that constitute the request URI may be performed under rules specific to the URI scheme.« (This covers #302) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: other | Milestone: post-IESG-1 technical | Version: coap-15 Priority: minor | Keywords: Component: coap | Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Apr 29 08:38: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 82EF321F9E07 for ; Mon, 29 Apr 2013 08:38:24 -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 QABvnehAHA1f for ; Mon, 29 Apr 2013 08:38:24 -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 9E0DA21F9DF0 for ; Mon, 29 Apr 2013 08:38:20 -0700 (PDT) Received: from localhost ([127.0.0.1]:57935 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWq9i-00067H-Vh; Mon, 29 Apr 2013 17:38:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 29 Apr 2013 15:38:18 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/310 Message-ID: <051.187ee374bd1a6d9f570ef59238b48296@trac.tools.ietf.org> X-Trac-Ticket-ID: 310 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130429153820.9E0DA21F9DF0@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 08:38:20 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #310: Don't dally beyond MAX_TRANSMIT_SPAN during retransmission X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 15:38:24 -0000 #310: Don't dally beyond MAX_TRANSMIT_SPAN during retransmission Stephen Farrell notes (msg04285b): Section 4.2 (2) 4.2, "when the timeout is triggered" - what happens with sleepy nodes that only wake on external events, and where e.g. if 2 timeouts have elapsed whilst asleep? Not sure if odd behaviour of that kind could cause much harm, but was it considered? This could also affect the definition in 4.8.2 of MAX_TRANSMIT_SPAN. Carsten says: The intention is that retransmissions stay in the overall envelope of MAX_TRANSMIT_SPAN, even if they are not perfectly spaced. Indeed, this could benefit from some additional discussion. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: other | Milestone: post-IESG-1 technical | Version: coap-15 Priority: minor | Keywords: Component: coap | Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Apr 29 08:47:21 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2B021F9DDF for ; Mon, 29 Apr 2013 08:47:21 -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 IGeyfPTzHNwr for ; Mon, 29 Apr 2013 08:47:20 -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 5BDE221F9D84 for ; Mon, 29 Apr 2013 08:47:20 -0700 (PDT) Received: from localhost ([127.0.0.1]:58561 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWqIP-0007xy-3p; Mon, 29 Apr 2013 17:47:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 29 Apr 2013 15:47:17 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/311 Message-ID: <051.7719f3e037df1610b65b3c8afa6cc970@trac.tools.ietf.org> X-Trac-Ticket-ID: 311 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130429154720.5BDE221F9D84@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 08:47:20 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #311: Selecting a token length for anti-spoofing X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 15:47:21 -0000 #311: Selecting a token length for anti-spoofing Stephen Farrell and Richard Barnes note (msg04285d, msg04288a): Section 5.3.1 Stephen Farrell: I suspect you need to have text trading off the Token length versus use of DTLS or else CoAP may end up too insecure for too many uses. (Note: the attack here is made worse because the message ID comparison can be skipped. Removing that "feature" would help a lot here.) 5.3.1's client "may want to use a non-trivial, randomized token" doesn't seem to cut it to me. How does this kind of interaction map to DTLS sessions/epoch? Basically, I'd like to see some RECOMMENDED handling of token length that would result in it not being unsafe to connect a CoAP node to the Internet. (And please note recent instances where 10's of thousands of insecure devices have been found via probing the IPv4 address space. These are real attacks.) Carsten says: Well, ceterum censeo BCP39. But it seems the discussion at the end of 5.3.1 could make the security considerations for selecting a token value in NoSec mode more explicit. Right now the basic consideration, but not the parameters that go into it, is discussed in 11.4 as well. Richard Barnes says: In Section 5.3.1, "A client sending a request...". This needs to be stronger. The requirement for a randomized token needs to be a MUST, and the stack SHOULD limit the number of rejected responses (before closing the request) based on the length of the token (e.g., 2**(TKL/2)). Carsten says: (See also Stephen's most recent reply: http://www.ietf.org/mail- archive/web/core/current/msg04302.html where he seems to argue for a RECOMMENDATION.) The specification is currently leaving to the client the level of protection that it makes use of: It can choose the token length based on its security requirements. The phrasing certainly can be improved to avoid the RFC6919 allusion (as in "MAY WISH TO") and to explain the criteria for choosing the size. E.g., explain that, with N=TKL*8 (possibly plus 16 if this is an ACK and the Message ID also matches, even though that should generally not be randomized), an off-path attacker has a chance of 2**-N per spoof to successfully spoof a response. To the lockdown proposal (2**(N/2)): Interesting idea. We don't have experience with that yet. One issue might be correlating incoming non- matching responses to a specific request. As with any lockdown mechanism, the potential for DoS (or pure malfunction) also needs to be considered. A client that keeps some state can tally recent non-matching responses to derive a "current attack level"; this might then be used to adjust its token length for future requests. (In today's constrained node networks, attack packet rates that make this more than a somewhat theoretical concern already will cause other problems, but we'll need to make the protocol robust for the "cloud" side as well.) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: other | Milestone: post-IESG-1 technical | Version: coap-15 Priority: critical | Keywords: Component: coap | Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Apr 29 08:48:58 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C597721F9E28 for ; Mon, 29 Apr 2013 08:48:58 -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 FGTKIuyyd6Q2 for ; Mon, 29 Apr 2013 08:48:58 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4F05621F9E26 for ; Mon, 29 Apr 2013 08:48:54 -0700 (PDT) Received: from localhost ([127.0.0.1]:58594 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWqJw-00023p-He; Mon, 29 Apr 2013 17:48:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 29 Apr 2013 15:48:52 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/312 Message-ID: <051.9cbcb77aad3ab5af70308fe0461dd019@trac.tools.ietf.org> X-Trac-Ticket-ID: 312 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130429154854.4F05621F9E26@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 08:48:54 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #312: Discuss spoofing ACKs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 15:48:59 -0000 #312: Discuss spoofing ACKs Stephen Farrell notes (msg04285c): Section 11.4 (3) 4.2, last para: this creates an attack that can work from off-path - just send loads of faked ACKs with guessed Tokens and some of 'em will be accepted with probability depending on Token-length and perhaps the quality of the RNG used by the sender of the CON. That could cause all sorts of "interesting" application layer behaviour. Why is that ok? (Or put another way - was this considered and with what conclusion?) Carsten says: Actually, the ACK would be matched on the Message ID (or I could simply point to the penultimate paragraph of 5.3.1). This is a relatively powerful attack that could be added to the list in 11.4. (See also #311) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-15 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Apr 29 09:03:56 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1275021F9E08 for ; Mon, 29 Apr 2013 09:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 C8cu2aTDyUZP for ; Mon, 29 Apr 2013 09:03:55 -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 7DD1F21F9E04 for ; Mon, 29 Apr 2013 09:03:55 -0700 (PDT) Received: from localhost ([127.0.0.1]:60048 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWqYS-0006aZ-9y; Mon, 29 Apr 2013 18:03:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 29 Apr 2013 16:03:52 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/313 Message-ID: <051.58ae34f5c17549453dc2b45582e93a3c@trac.tools.ietf.org> X-Trac-Ticket-ID: 313 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130429160355.7DD1F21F9E04@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 09:03:55 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #313: Qualify partial discard strategy implementation note: UDP only X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 16:03:56 -0000 #313: Qualify partial discard strategy implementation note: UDP only Stephen Farrell notes (msg04285e): Section 4.6 (5) 4.6, last para - this only applies to insecure uses of CoAP, you should point that out Carsten says: "can" is indeed probably too strong. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-15 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Apr 29 09:04: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 B6BDF21F9E1A for ; Mon, 29 Apr 2013 09:04:35 -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 6d5Kbz0tiiZF for ; Mon, 29 Apr 2013 09:04:35 -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 1D1B721F9E08 for ; Mon, 29 Apr 2013 09:04:35 -0700 (PDT) Received: from localhost ([127.0.0.1]:60123 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWqZ7-0007h7-LE; Mon, 29 Apr 2013 18:04:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 29 Apr 2013 16:04:33 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/314 Message-ID: <051.5a2a199cb637ebcc8c443de0100e4a6a@trac.tools.ietf.org> X-Trac-Ticket-ID: 314 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130429160435.1D1B721F9E08@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 09:04:35 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #314: Explicitly point out that UDP and DTLS don't mix X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 16:04:35 -0000 #314: Explicitly point out that UDP and DTLS don't mix Stephen Farrell notes (msg04285f): Section 6.2 (6) 6.2 - "the UDP datagrams MUST...use DTLS" is fine but maybe not enough, if the request uses DTLS then presumably so MUST *all* response messages, and they MUST use the same DTLS session? Or perhaps one with the same authenticated endpoints. Don't you need to say that? If you don't then just sending the request via DTLS but getting (some) response messages in clear would seem to be allowed. I think 9.1 might cover all the above, but want to just check. Carsten says: This is implicit in the fact that all exchanges (except for multicast) use the same pair of endpoints for both directions, so you simply can't reply via NoSec to a DTLS message. It probably doesn't hurt to make that explicit somewhere. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-15 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Apr 29 09:05:43 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310AE21F9E3E for ; Mon, 29 Apr 2013 09:05:43 -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 FQ1yfzWoMWoo for ; Mon, 29 Apr 2013 09:05:42 -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 99A8521F9E3C for ; Mon, 29 Apr 2013 09:05:42 -0700 (PDT) Received: from localhost ([127.0.0.1]:60185 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWqaD-0007li-6o; Mon, 29 Apr 2013 18:05:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 29 Apr 2013 16:05:41 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/315 Message-ID: <051.592cf9722b44f472940a68fdeac17899@trac.tools.ietf.org> X-Trac-Ticket-ID: 315 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130429160542.99A8521F9E3C@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 09:05:42 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #315: Point out security consideration around coap(s) URIs and access control X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 16:05:43 -0000 #315: Point out security consideration around coap(s) URIs and access control Stephen Farrell notes (msg04285i): Section 6.5 6.5 - I think you need a security consideration somewhere about comparing coap(s) URIs and the potential for access control screw-ups. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-15 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Apr 29 09:06:55 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB49E21F99E8 for ; Mon, 29 Apr 2013 09:06:55 -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 v2BijHAEAdD0 for ; Mon, 29 Apr 2013 09:06:55 -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 141D921F9991 for ; Mon, 29 Apr 2013 09:06:55 -0700 (PDT) Received: from localhost ([127.0.0.1]:60215 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWqbN-0000kJ-PP; Mon, 29 Apr 2013 18:06:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 29 Apr 2013 16:06:53 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/316 Message-ID: <051.939317a9997ae4ef232efe7f35cc85d0@trac.tools.ietf.org> X-Trac-Ticket-ID: 316 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130429160655.141D921F9991@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 09:06:55 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #316: MUST apply RFC 5280 section 6 as appropriate X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 16:06:55 -0000 #316: MUST apply RFC 5280 section 6 as appropriate Stephen Farrell notes (msg04285g): Section 9.1.3.3 (8) 9.1.3.3 - "signed by an appropriate chain of trust" is an odd phrase - do you mean it MUST be validated as per RFC 5280 section 6? If so, say so. If not, say what you do mean. (But we might need to talk about it in that case, depending;-) Carsten says: We probably should say: The certificate MUST be validated as appropriate for the security requirements, using functionality equivalent to the algorithm specified in RFC5280 Section 6. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: other | Milestone: post-IESG-1 technical | Version: coap-15 Priority: major | Keywords: Component: coap | Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Apr 29 09:07:40 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C254F21F9A3F for ; Mon, 29 Apr 2013 09:07:40 -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 fYM9kUHEcBtR for ; Mon, 29 Apr 2013 09:07:40 -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 2E15021F9991 for ; Mon, 29 Apr 2013 09:07:40 -0700 (PDT) Received: from localhost ([127.0.0.1]:60226 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWqc6-0003hF-Rd; Mon, 29 Apr 2013 18:07:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 29 Apr 2013 16:07:38 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/317 Message-ID: <051.40390e78181a5495322700d2f176a59e@trac.tools.ietf.org> X-Trac-Ticket-ID: 317 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130429160740.2E15021F9991@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 09:07:40 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #317: Point out OCSP stapling (TLS Certificate Status Request) as a viable way to get cert status info on a constrained node X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 16:07:40 -0000 #317: Point out OCSP stapling (TLS Certificate Status Request) as a viable way to get cert status info on a constrained node Stephen Farrell notes (msg04285h): Section 9.1.3.3 (9) 9.1.3.3 - you don't mention certificate status checking. I can see why that's hard to impossible in some n/w's but entirely ignoring it seems wrong. Perhaps call out the vulnerability and point at OCSP stapling as a potential solution, but one that requires further work and/or further specification? Carsten says: Yes, we should point this out (ref RFC 6066 section 8, too). -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-15 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Apr 29 09:09:09 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C0A21F9E41 for ; Mon, 29 Apr 2013 09:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.449 X-Spam-Level: X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_EMAIL=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukdFZSyh9mcp for ; Mon, 29 Apr 2013 09:09:09 -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 3970821F9E3E for ; Mon, 29 Apr 2013 09:09:09 -0700 (PDT) Received: from localhost ([127.0.0.1]:60257 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWqdX-0000PI-T6; Mon, 29 Apr 2013 18:09:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 29 Apr 2013 16:09:07 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/318 Message-ID: <051.05692005f1b2cf79007d08f3eb276f65@trac.tools.ietf.org> X-Trac-Ticket-ID: 318 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130429160909.3970821F9E3E@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 09:09:09 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #318: cert-with-PSK: RSA is out, ECDHE is in X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 16:09:09 -0000 #318: cert-with-PSK: RSA is out, ECDHE is in Stephen Farrell notes (msg04285j): Section 9.1.3.3 9.1.3.3 - throwing in RSA as a SHOULD (albeit within a section that's a MAY) is odd - if devices can do RSA then why not have 'em all do it for the raw public keys and get the interop gains that will accrue from that. Carsten says: Well, this is for the (somewhat high-end) case of cert usage. WG: Is there a cipher suite that better its the other ones we use? E.g., Why didn't we use TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA (RFC 5489)? I notice that in the transition from -05 to -06, we got rid of TLS_RSA_WITH_AES_128_CBC_SHA in favor of TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, but not of TLS_RSA_PSK_WITH_AES_128_CBC_SHA. The changes comment is "DTLS cipher suites aligned with ZigBee IP, DTLS clarified as default CoAP security mechanism (#138, #139)". http://trac.tools.ietf.org/wg/core/trac/ticket/139 mentions TLS_PSK_WITH_AES_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, but not anything about the cert-with-PSK case. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: other | Milestone: post-IESG-1 technical | Version: coap-15 Priority: major | Keywords: Component: coap | Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Apr 29 09:17: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 200A421F9E1A for ; Mon, 29 Apr 2013 09:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 b1slJw-9gCP0 for ; Mon, 29 Apr 2013 09:17:11 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5B82521F9DB1 for ; Mon, 29 Apr 2013 09:17:11 -0700 (PDT) Received: from localhost ([127.0.0.1]:60706 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWqlJ-0003Rt-Mj; Mon, 29 Apr 2013 18:17:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 29 Apr 2013 16:17:09 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/319 Message-ID: <051.40d5fedc31546d4a0bcb879a368974cd@trac.tools.ietf.org> X-Trac-Ticket-ID: 319 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130429161711.5B82521F9DB1@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 09:17:11 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #319: Point out that requests and responses don't always come in pairs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 16:17:12 -0000 #319: Point out that requests and responses don't always come in pairs Richard Barnes notes (msg04288b): Section 2.2 In Section 2.2., are requests and responses in 1-1 correspondence? Or can a single request receive more than one response? Carsten says: Section 2.2 doesn't explain that, but, indeed, a request might receive more than one response, which we use for multicast and draft-ietf-core- observe, (and, for future methods, even less than one response). I think I'd rather discuss this in section 5, though. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-15 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Apr 29 09:17:55 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2503B21F9E1C for ; Mon, 29 Apr 2013 09:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 0rgLN+XiNoEP for ; Mon, 29 Apr 2013 09:17:54 -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 6C5F721F9E1A for ; Mon, 29 Apr 2013 09:17:54 -0700 (PDT) Received: from localhost ([127.0.0.1]:60732 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWqlz-0004CC-A9; Mon, 29 Apr 2013 18:17:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 29 Apr 2013 16:17:51 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/320 Message-ID: <051.0bcb9e2128c0ec3f50de6841ac1a2dfd@trac.tools.ietf.org> X-Trac-Ticket-ID: 320 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130429161754.6C5F721F9E1A@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 09:17:54 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #320: Nail down who does Unicode normalization when (or not) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 16:17:55 -0000 #320: Nail down who does Unicode normalization when (or not) Ted Lemon notes (msg04287a): Section 3.2 P. 19: I'm a little uncomfortable with this text: There is no expectation and no need to perform normalization within a CoAP implementation (except where Unicode strings that are not known to be normalized are imported from sources outside the CoAP protocol). I think what's intended here is right, but you've mentioned what amounts to a strong suggestion, if not a requirement, as a parenthetical note. It seems like what you intended was something like this: There is no expectation and no need to perform normalization within a CoAP implementation, since senders are expected to be implemented with pre- normalized strings. However, strings received from non-CoAP sources SHOULD be normalized where possible. Of course, there's actually no value to normalization in this case if it can't be depended on, and I suspect that you don't want to make that a MUST. So this might be a better way to do it: There is no expectation and no need to perform normalization within a CoAP implementation, since senders are expected to be implemented with pre- normalized strings. Strings received from non-CoAP sources and then forwarded by CoAP senders cannot be assumed to have been normalized, and may not compare correctly with normalized strings representing the same text. I don't have a strong opinion about how this should be done, but it seems like the text as written doesn't give clear guidance. It seems that cross-proxies ought to be able to do normalization, and maybe other proxies could as well, but that's a much bigger change. Carsten says: Unicode normalization is always a sticky point. I think the choice of a point on the continuum between your suggestions (which I both like) needs to be discussed with the WG. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: other | Milestone: post-IESG-1 technical | Version: coap-15 Priority: minor | Keywords: Component: coap | Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Apr 29 09:18: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 08DC121F9E2B for ; Mon, 29 Apr 2013 09:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aGdZe5VIfdB for ; Mon, 29 Apr 2013 09:18:35 -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 4A4FA21F9E26 for ; Mon, 29 Apr 2013 09:18:35 -0700 (PDT) Received: from localhost ([127.0.0.1]:60749 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UWqmf-0005gu-VJ; Mon, 29 Apr 2013 18:18:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 29 Apr 2013 16:18:33 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/321 Message-ID: <051.6bf19250add8dbf26e613d0675ca2fd3@trac.tools.ietf.org> X-Trac-Ticket-ID: 321 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130429161835.4A4FA21F9E26@ietfa.amsl.com> Resent-Date: Mon, 29 Apr 2013 09:18:35 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #321: Point out that Uri-Host doesn't handle user-part. X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 16:18:36 -0000 #321: Point out that Uri-Host doesn't handle user-part. Ted Lemon notes (msg04287b): Section 6.4 Also in 6.4, the text does not account for the case where there's a user part to the authority section of the URI. Carsten says: It is not meant to. This could never occur until we introduced Proxy- Scheme; we need to add text that the use of Proxy-Scheme is not possible in this case. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: editorial | Milestone: post-IESG-1 Priority: minor | Version: coap-15 Component: coap | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From cabo@tzi.org Mon Apr 29 09:47:22 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA3621F9E5F for ; Mon, 29 Apr 2013 09:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.023 X-Spam-Level: X-Spam-Status: No, score=-106.023 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZDhIEPicjWz for ; Mon, 29 Apr 2013 09:47:21 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B156221F9D6B for ; Mon, 29 Apr 2013 09:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r3TGlDRQ016917 for ; Mon, 29 Apr 2013 18:47:13 +0200 (CEST) Received: from [192.168.217.105] (p54893A4B.dip0.t-ipconnect.de [84.137.58.75]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1BFFD3815; Mon, 29 Apr 2013 18:47:13 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Apr 2013 18:47:11 +0200 To: "core@ietf.org (core@ietf.org)" Message-Id: <13D00776-0E41-4BE0-9068-756C599CCD68@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [core] =?utf-8?b?8J+UlDogKG1vc3QpIHBvc3QtSUVTRyB0aWNrZXRzIGFyZSBp?= =?utf-8?q?n?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Apr 2013 16:47:22 -0000 You may have noticed the barrage of tickets resulting from the IESG = review. Tickets #301 to #321 contain proposals for changes that the document = editors didn't just want to go ahead and make on their own*). All of these tickets exist so the WG gets to see and can influence what = is going on in the IESG processing. Some of these are editorial, just with larger changes than we were = comfortable to make on our own. Some of them are technical. There are no breaking changes on the wire = (phew), but a few important decisions to make: Anti-Spoofing: #311: do we all agree on how the length of a token is chosen when there = is a danger of spoofing? Certs: #316: "MUST apply" RFC 5280 section 6 as appropriate when using cert. #318: cert-with-PSK: RSA is out, ECDHE is in Unicode in options: #320: Nail down who does Unicode normalization when (or not) There are more; overview at http://v.gd/PIeABH E.g., we probably need some sharp eyes for #308. If you have any comment, please reply right to the ticket messages on = the mailing list. Replies today or tomorrow are most appreciated. This does not yet cover Adrian Farrel's comments which only came in = today; I hope to have the tickets generated from those tomorrow. We = also expect a review from Sean Turner, who deferred his ballot position. = Of course, every IESG member can always add comments. Gr=FC=DFe, Carsten *) (if you want to see those simple editorial ones, look at the = changesets 1304 to 1335 in = http://trac.tools.ietf.org/wg/core/trac/timeline). If this is too much = detail, all of this will then be in -16. From Ted.Lemon@nominum.com Mon Apr 29 09:55: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 B2B0F21F9E68; Mon, 29 Apr 2013 09:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 mhQJISuWMzJt; Mon, 29 Apr 2013 09:55:12 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB2D21F9E44; Mon, 29 Apr 2013 09:55:12 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUX6l8KEILKGjjbFHpUwDa6m10iV35jEb@postini.com; Mon, 29 Apr 2013 09:55:12 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0B6DC1B8147; Mon, 29 Apr 2013 09:55:12 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 032A7190061; Mon, 29 Apr 2013 09:55:12 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 29 Apr 2013 09:55:05 -0700 From: Ted Lemon To: Carsten Bormann Thread-Topic: [core] Ted Lemon's No Objection on draft-ietf-core-coap-15: (with COMMENT) Thread-Index: AQHOQWWFKy3RLsAaeUWZIqRyW3zBg5jtxN4AgAAiRYA= Date: Mon, 29 Apr 2013 16:55:05 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775166AF4@mbx-01.win.nominum.com> References: <20130425033226.32552.99254.idtracker@ietfa.amsl.com> <457E56CC-B066-4F0D-8941-B97D30C95C18@tzi.org> In-Reply-To: <457E56CC-B066-4F0D-8941-B97D30C95C18@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <71F093F2949CF043B045325C4B55AD8E@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , The IESG , "" Subject: Re: [core] Ted Lemon's No Objection on draft-ietf-core-coap-15: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Apr 2013 16:55:13 -0000 On Apr 29, 2013, at 10:52 AM, Carsten Bormann wrote: > Safe methods is a rather established piece of REST terminology. > I'd rather rename the safe options. > "safe" here is an abbreviation for "safe-to-forward-in-a-proxy-while-not-= understanding-them". > My thesaurus is of no use ... (well, it does suggest "hairy" for > unsafe. hairy and bald?) Well, I have to admit that there is a certain poetry to hairy/bald, but it = may be that some readers would find it odd. Perhaps clear/active? Or in= attentive/attentive? Or optional-to-interpret (oti)/must-interpret (mi)? = Like you, I have nothing good to suggest, but I think this is the right c= hange to make. > 5.10.1: how does the client know that an endpoint hosts multiple > virtual servers in time to leave out the Uri-Host option? Is this > literally just in the case where the hostname appears in the URI t= o be > decomposed as an IP address literal? >=20 > are sufficient for requests to most servers. Explicit Uri-Host = and > Uri-Port Options are typically used when an endpoint hosts multi= ple > virtual servers. >=20 > Indeed, the Uri-Host option can use its default value only when the > URI has an IP address literal. It might be worth saying this. I think a deep think about the document wi= ll make this clear to the reader, but it's always better if you can help th= em to avoid having to do the deep think if it doesn't have useful side effe= cts. > It is hard to provide emphasis for variable names for pseudo-code in > an ASCII-only document. > I replaced the slahes by vertical bars, knowing well that this might > offend mathematicians. [1335] That works for me. The mathematicians will enjoy kicking up a fuss about = it, so I think it's okay for everyone. Thanks for considering these changes! From cabo@tzi.org Mon Apr 29 13:27:05 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C0421F9991; Mon, 29 Apr 2013 13:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.193 X-Spam-Level: X-Spam-Status: No, score=-106.193 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUyc2FolMZyr; Mon, 29 Apr 2013 13:26:59 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4B51821F9977; Mon, 29 Apr 2013 13:26:59 -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 r3TKQMDS004464; Mon, 29 Apr 2013 22:26:23 +0200 (CEST) Received: from [192.168.217.105] (p54893A4B.dip0.t-ipconnect.de [84.137.58.75]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2875B38FC; Mon, 29 Apr 2013 22:26:22 +0200 (CEST) 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: <517E7FF0.9020202@cs.tcd.ie> Date: Mon, 29 Apr 2013 22:26:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <305043E6-984C-4410-A22F-9B08B44219BC@tzi.org> References: <20130425012605.7589.40567.idtracker@ietfa.amsl.com> <517D47CA.1030900@cs.tcd.ie> <517E7FF0.9020202@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1503) Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, The IESG , core@ietf.org Subject: Re: [core] Stephen Farrell's Discuss on draft-ietf-core-coap-15: (with DISCUSS and COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 Apr 2013 20:27:05 -0000 On Apr 29, 2013, at 16:13, Stephen Farrell = wrote: > However, as-is, I think the spec says that a client with a > configured forward proxy just sends all https or coaps URIs > in clear to that proxy and gets responses in clear. Is that > right? I sure hope it doesn't say that. We may never have written anything about this because it seemed obvious. (I know, famous last words.) In 11.2, we are discussing security and caching in a proxy. We could insert something between the first and second paragraph, as in: "The security properties of (a) the exchange toward the proxy, (b) the = handling of the data in the proxy and (c) the exchange from the proxy = onward, all contribute to the overall security properties. Note that = (c) includes the transitive closure of the security properties = encountered in conjunction with any further proxies on the way. = Trivially, a client that chooses a forward proxy needs to ensure that = the security properties it expects from its choice of URI scheme (e.g., = HTTPS or CoAPS) are actually provided by the proxy [c] and that the = exchange towards the proxy [a] and the data handling inside the proxy = [b] are also compatible with these security properties. Similarly, a = reverse proxy that is addressed via CoAPS or HTTPS needs to ensure the = security properties desired by its client are preserved by its own data = handling [b] and on the way towards the origin server [c]. In most = cases, this means that a CoAPS or HTTPS exchange is forwarded as a CoAPS = or HTTPS exchange on the next leg." Or so. Gr=FC=DFe, Carsten From cabo@tzi.org Mon Apr 29 23:53: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 386AC21F9B6A; Mon, 29 Apr 2013 23:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.204 X-Spam-Level: X-Spam-Status: No, score=-106.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdwDJcb7Wckb; Mon, 29 Apr 2013 23:53:30 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 3990021F9B14; Mon, 29 Apr 2013 23:53: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 r3U6rKlt025826; Tue, 30 Apr 2013 08:53:20 +0200 (CEST) Received: from [192.168.217.105] (p54893A4B.dip0.t-ipconnect.de [84.137.58.75]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3916139C6; Tue, 30 Apr 2013 08:53:20 +0200 (CEST) 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: <20130429143451.13168.40760.idtracker@ietfa.amsl.com> Date: Tue, 30 Apr 2013 08:53:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130429143451.13168.40760.idtracker@ietfa.amsl.com> To: "Adrian Farrel" X-Mailer: Apple Mail (2.1503) Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, The IESG , core@ietf.org Subject: Re: [core] Adrian Farrel's Yes on draft-ietf-core-coap-15: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 30 Apr 2013 06:53:34 -0000 Adrian, thank you for this attentive review. I have done some of the changes as simple editorial fixes, these are marked like [1337] below and can be reviewed in http://trac.tools.ietf.org/wg/core/trac/changeset/1337 (Overview in http://trac.tools.ietf.org/wg/core/trac/timeline). Gr=FC=DFe, Carsten = ---------------------------------------------------------------------- COMMENT: = ---------------------------------------------------------------------- I want to thank the authors and WG for producing this = specification. I think it may be one of the more important pieces of work in = recent years. As might be expected with a document of over 100 pages = reviewed by a pedant, I have a list of nits and worries. These are all = enetered as Comments: I hope you will find time to address them and make = the resulting RFC more polished, but none of them comes even close = to a requirement that you change the text, and I am ballotting Yes. --- How quickly we forget! I looked up the spec of a typical home computer around the time = of HTTP v1.0 and discovered that it was not so very different from what = you are scoping your environment to today. In the LWIG terminology document, we define our class 1 as ~ 10 KiB RAM, ~ 100 KiB code. This is more like a 1982 C64 than like a 1990 NeXT (the computer on which the Web started) and certainly not like the mid-1990s home computer (486, Pentium!). HTTP/TCP can be made to work on class 1 platforms with heroic efforts and significant limitations. Add security and some application functionality, and it becomes difficult. This is easier on a class 2 platform, as SEP 2.0 demonstrates. Moore's law doesn't help as much in the embedded space as it does in personal devices. That is not to say that your work is not valid. Far from it! But = I do believe it might be helpful to explore in more detail why you = don't simply run an early, low-function version of HTTP. FWIW, I believe the answer is that you want some of the advanced functions that have been added to HTTP over the years, but do = not want the full family of rich features that may chew memory and = bandwidth. I'm sure there will be lots of articles describing the objectives in = detail. For a start, I can recommend http://dx.doi.org/10.1109/MIC.2012.29 and for some additional background, see our Paris IAB workshop paper http://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf (I need to find time to complete this draft). I think it is a bit difficult to try to obtain WG consensus on a piece of text on why exactly HTTP/TCP doesn't cut it, so I hesitate to expand the text in the spec. --- What about the use of CoAP on the wider Internet? CoAP has a number of problems in common with the DNS protocol that may make both of them hard to use on the wider Internet. More seriously speaking, we have tried to focus on the requirements of the constrained node networks. If CoAP works well for applications that don't have those constraints, that makes us happy, but is not the main objective. Note that constrained node networks already want to talk to the wider Internet, so enabling that is part of the objective. The most important constraint of CoAP is the size of the Message ID, which limits the goodput between two endpoints to about 250 messages per second. If that is not enough, alternative transport mappings should be considered. Those haven't been written up yet. --- A very minor terminology point from Section 1.2 Confirmable Message Some messages require an acknowledgement. These messages = are called "Confirmable". When no packets are lost, each = Confirmable message elicits exactly one return message of type = Acknowledgement or type Reset. Non-confirmable Message Some other messages do not require an acknowledgement. = This is particularly true for messages that are repeated regularly = for application requirements, such as repeated readings from a = sensor. You have picked a form "confirmable" and "non-confirmable" tha = expresses the ability to do something: this message can be confirmed. But you have mapped the form to a description that requires = action: an acknowledgement must be sent. "Can be confirmed" !=3D "A confirmation must be sent" "Cannot be confirmed" !=3D "A conformation does not need to be = sent" I don't believe this is too important because you are defining = the tems, but I do think that the casual reader will not embed your = redefinitions of normal English words, and so will be confused by these terms = in the text. As a non-native speaker I'm well aware of this slight abuse. It did seem expedient and it is not really wrong (you can ACK a Confirmable, but not a Non-confirmable). The other meaning is also very much present in English: payable, taxable, ... Most important, we never found a better word. --- Section 1.2. Also a very minor point. Acknowledgement Message An Acknowledgement message acknowledges that a specific Confirmable Message arrived. It does not indicate success = or failure of any encapsulated request. The fact that and Acknowledgement Message can carry a response = is lost in this definition. Maybe you need (including fixes to your = typos)... Acknowledgement Message An Acknowledgement Message acknowledges that a specific Confirmable Message arrived. Of itself, an = Acknoweledgement Message does not indicate success or failure of any request encapsulated in the Confirmable Message, but the = Acknoweledgement Message may also carry a Piggy-backed response (q.v.). Yes! I put it right in... [1337] (But I used "By itself", because that is easier to understand for me.) --- My feeling was that the Message IDs shown in figures 2 through 6 = were confusing in their randomness. For example, you could spend a = lot of time staring at figures 2 and 3 trying to work out how CON is = encodeded as 0x7d34 while NON is encoded as 0x01a0. Since you want to show Message IDs to show how they correspond = on different parts of the flow, you could have written, e.g., Client Server | | | CON [MsgID1] | +----------------->| | | | ACK [MsgID1] | |<-----------------+ | | I'm a big fan of concreteness. We could then replace '/temperature' with [URI] etc. (There actually is a quick explanation of 0x7d34 as an example in the reference to Figure 2, which I made slightly more explicit. I also added explanation in the reference to Figure 3.) [1338] --- Section 2.1 As CoAP is based on UDP, it also supports the use of multicast = IP I don't think it is based on UDP. I think it runs over UDP. [1338] --- Section 2.3 As CoAP was designed according to the REST architecture and = thus Maybe insert another pointer to [REST]. [1339] --- Section 4.2 A Confirmable message always carries either a request or response and MUST NOT be = empty, unless it is used only to elicit a Reset message. That is a bit of an over-use of "MUST NOT". I think A Confirmable message always carries either a request or response, unless it is used = only to elicit a Reset message in which case it is empty. [1340] --- 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. This paragraph is giving me some worries. I think the initial MAY confuses the CoAP implementation with = the endpoint containing the CoAP implementation. The endpoint may = give up, and may instruct the CoAP implementation to stop retransmitting. = But I think a CoAP implementaiton must not give up unless it is told = to. Well, we do talk about the endpoint giving up? Specifically, we are also talking about the CoAP implementation (message layer) giving up if it has another indication (from the request/response layer) that the message did arrive. The drop from MUST NOT to SHOULD in the final sentence seems = odd. My understanding was that a CoAP implementation MUST always retain = the state to create the ACK for the request. Is this use of SHOULD = a relaxation, and how does it square with the MUST NOT? The SHOULD is probably wrong. This was meant as an implementation method, allowing for others. But the statement already is suitably abstracted from the implementation method. [1341] Here we enter the area populated by FIN_WAIT_2 timeouts... Maybe an RFC 6919 "MUST (BUT YOU KNOW YOU WON'T)" would be most = appropriate. --- Section 4.6 Messages larger than an IP fragment result in undesired packet = fragmentation. s/undesired/undesirable/ ? [1340] --- Section 4.6 A CoAP message, appropriately encapsulated, SHOULD fit within = a single IP packet (i.e., avoid IP fragmentation) and (by = fitting into one UDP payload) obviously MUST fit within a single IP = datagram. s/MUST/will/ did "s/MUST/needs to/" in [1305] based on Pete Resnick's similar = comment. --- Section 12 I am surprised that IANA was relaxed about the use of "reserved" = in Section 12. For example, in 12.1 you have two ranges marked "Reserved" = without any clue to what this means. For example, does it mean that = allocations can be made, that an RFC can dedicate them to a new use, or that = they must never be allocated? No allocations can be made from reserved space. But an RFC can update (or replace) this RFC, and unreserve the space. There is no fundamental difference in effect between "reserved" and "allocated by standards action". However, the latter would mean we have an idea how future standards might want to use the space. We don't, so the space is "reserved". We don't even know what a policy for allocation would be! (Insert metacomment about cognitive dissonance caused by reserved codepoints. Space we can't use! Actually, space that may turn out useful in protocol evolution.) In 12.1.2 you have The Response Codes 96-127 are Reserved for future use. All = other Response Codes are Unassigned. I take "Unassigned" to mean available for assignment according = to the policy for the registry. But "Reserved or future use" means = what? No allocations can be made from reserved space. In 12.2 you have | 0 | (Reserved) | | This is the meaning of "reserved" I think we are used to, and = means will not be made available for allocation. (Although I am puzzled = that you don't include the pointer to this RFC.) The missing pointer is a bug. [1342] From adrian@olddog.co.uk Tue Apr 30 06:43: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 C0C2B21F9B84; Tue, 30 Apr 2013 06:43:06 -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 XmsId6fLwZaj; Tue, 30 Apr 2013 06:43:01 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id AF18321F9B83; Tue, 30 Apr 2013 06:43:00 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3UDgx6G021466; Tue, 30 Apr 2013 14:42:59 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3UDgvgF021444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Apr 2013 14:42:58 +0100 From: "Adrian Farrel" To: "'Carsten Bormann'" References: <20130429143451.13168.40760.idtracker@ietfa.amsl.com> In-Reply-To: Date: Tue, 30 Apr 2013 14:42:59 +0100 Message-ID: <021a01ce45a8$a1415a00$e3c40e00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIkf/YlzuOLrAeEdu4ARBAh9R6evQI9viFqmDBY1OA= Content-Language: en-gb Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, 'The IESG' , core@ietf.org Subject: Re: [core] Adrian Farrel's Yes on draft-ietf-core-coap-15: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 13:43:06 -0000 Hello Carsten, Just a few snips and responses, but nothing earth-shattering. Adrian >> FWIW, I believe the answer is that you want some of the advanced >> functions that have been added to HTTP over the years, but do not want >> the full family of rich features that may chew memory and bandwidth. > > I think it is a bit difficult to try to obtain WG consensus on a piece > of text on why exactly HTTP/TCP doesn't cut it, so I hesitate to > expand the text in the spec. Hmmm, I might have thought that before starting out on CoAP there was some consensus on why you were doing it :-) >> What about the use of CoAP on the wider Internet? > > More seriously speaking, we have tried to focus on the requirements of > the constrained node networks. If CoAP works well for applications > that don't have those constraints, that makes us happy, but is not the > main objective. Note that constrained node networks already want to > talk to the wider Internet, so enabling that is part of the objective. > > The most important constraint of CoAP is the size of the Message ID, > which limits the goodput between two endpoints to about 250 messages > per second. If that is not enough, alternative transport mappings > should be considered. Those haven't been written up yet. I think you might add some commentary. For example: While CoAP has been designed for use in constrained networks it may also be applicable on the wider Internet although this is for future study. >> I am surprised that IANA was relaxed about the use of "reserved" in >> Section 12. > > No allocations can be made from reserved space. > But an RFC can update (or replace) this RFC, and unreserve the space. OK. I get it. Might be clearer to have "Reserved: not to be allocated" Cheers, Adrian From trac+core@trac.tools.ietf.org Tue Apr 30 09:33: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 2988D21F9BA3 for ; Tue, 30 Apr 2013 09:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNGhE1LErvUF for ; Tue, 30 Apr 2013 09:33:31 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 818EC21F9ADF for ; Tue, 30 Apr 2013 09:33:31 -0700 (PDT) Received: from localhost ([127.0.0.1]:45435 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXDUf-0005Jl-Jk; Tue, 30 Apr 2013 18:33:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Tue, 30 Apr 2013 16:33:29 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/316#comment:1 Message-ID: <066.825bc8f4bf25a5360da3ad673f2e5359@trac.tools.ietf.org> References: <051.939317a9997ae4ef232efe7f35cc85d0@trac.tools.ietf.org> X-Trac-Ticket-ID: 316 In-Reply-To: <051.939317a9997ae4ef232efe7f35cc85d0@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130430163331.818EC21F9ADF@ietfa.amsl.com> Resent-Date: Tue, 30 Apr 2013 09:33:31 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #316: MUST apply RFC 5280 section 6 as appropriate 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, 30 Apr 2013 16:33:32 -0000 #316: MUST apply RFC 5280 section 6 as appropriate Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1343]: Close #316 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: other | Status: closed technical | Milestone: post-IESG-1 Priority: major | Version: coap-15 Component: coap | Resolution: fixed Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Apr 30 10:14:18 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E0E21F9C56 for ; Tue, 30 Apr 2013 10:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 G6NyGt4lAqkq for ; Tue, 30 Apr 2013 10:14:16 -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 BAC7321F9C43 for ; Tue, 30 Apr 2013 10:14:11 -0700 (PDT) Received: from localhost ([127.0.0.1]:48728 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXE82-0006jx-4v; Tue, 30 Apr 2013 19:14:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Tue, 30 Apr 2013 17:14:10 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/317#comment:1 Message-ID: <066.a06300af73b016c855a5d4a4e910f7e9@trac.tools.ietf.org> References: <051.40390e78181a5495322700d2f176a59e@trac.tools.ietf.org> X-Trac-Ticket-ID: 317 In-Reply-To: <051.40390e78181a5495322700d2f176a59e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130430171411.BAC7321F9C43@ietfa.amsl.com> Resent-Date: Tue, 30 Apr 2013 10:14:11 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #317: Point out OCSP stapling (TLS Certificate Status Request) as a viable way to get cert status info on a constrained node 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, 30 Apr 2013 17:14:18 -0000 #317: Point out OCSP stapling (TLS Certificate Status Request) as a viable way to get cert status info on a constrained node Comment (by cabo@tzi.org): From [1344]: Make a proposal for text about certificate status checking; see #317 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: editorial | Status: new Priority: minor | Milestone: post-IESG-1 Component: coap | Version: coap-15 Severity: Submitted | Resolution: WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Apr 30 10:19:08 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2255F21F9AB7 for ; Tue, 30 Apr 2013 10:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 HtHXpr4M8SnL for ; Tue, 30 Apr 2013 10:19:02 -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 EF2B921F97ED for ; Tue, 30 Apr 2013 10:19:01 -0700 (PDT) Received: from localhost ([127.0.0.1]:48847 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXECi-0004JS-Hj; Tue, 30 Apr 2013 19:19:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Tue, 30 Apr 2013 17:19:00 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/318#comment:1 Message-ID: <066.fa3d012fe446e27df86e54b1539e9b37@trac.tools.ietf.org> References: <051.05692005f1b2cf79007d08f3eb276f65@trac.tools.ietf.org> X-Trac-Ticket-ID: 318 In-Reply-To: <051.05692005f1b2cf79007d08f3eb276f65@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130430171901.EF2B921F97ED@ietfa.amsl.com> Resent-Date: Tue, 30 Apr 2013 10:19:01 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #318: cert-with-PSK: RSA is out, ECDHE is in 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, 30 Apr 2013 17:19:08 -0000 #318: cert-with-PSK: RSA is out, ECDHE is in Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1345]: Close #318 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: other | Status: closed technical | Milestone: post-IESG-1 Priority: major | Version: coap-15 Component: coap | Resolution: fixed Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From cabo@tzi.org Tue Apr 30 10:29:09 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AF221F9AD8 for ; Tue, 30 Apr 2013 10:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.221 X-Spam-Level: X-Spam-Status: No, score=-106.221 tagged_above=-999 required=5 tests=[AWL=0.028, 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 bzOyiNMvyxgI for ; Tue, 30 Apr 2013 10:29:03 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0684421F9AB3 for ; Tue, 30 Apr 2013 10:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r3UHSuCn027275 for ; Tue, 30 Apr 2013 19:28:56 +0200 (CEST) Received: from [192.168.217.105] (p54893D76.dip0.t-ipconnect.de [84.137.61.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 11B47302D; Tue, 30 Apr 2013 19:28:56 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Apr 2013 19:28:53 +0200 To: "core@ietf.org (core@ietf.org)" Message-Id: <61F5D3B1-0923-4295-933A-E8F448A37062@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [core] Certificate mode in -16 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 30 Apr 2013 17:29:09 -0000 I just made an attempt at addressing the IESG comments on section = 9.1.3.3, X.509 Certificates. I think I'm done with #316 and #318 (and have closed those), but I would = like to hear your input on #317. I'm reproducing the formatted version = of 9.1.3.3 as of [1346] below. The changes are: -- point to RFC5280 section 6 (#316) -- add a paragraph about cert status checking (#317) -- RSA is out, ECDHE is in for cert-with-PSK, too (#318) Gr=FC=DFe, Carsten 9.1.3.3. X.509 Certificates Implementations in Certificate Mode MUST support the mandatory to implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in [RFC5246]. The Authority Name in the certificate is the name that would be used in the Host part of a CoAP URI. It is worth noting that this would typically not be either an IP address or DNS name built in the usual way but would instead be built out of a long term unique identifier for the device such as the EUI-64 [EUI64]. The discovery process used in the system would build up the mapping between IP addresses of the given devices and the Authority Name for each device. Some devices could have more than one Authority and would need more than a single certificate. When a new connection is formed, the certificate from the remote device needs to be verified. If the CoAP node has a source of absolute time, then the node SHOULD check that the validity dates of the certificate are within range. The certificate MUST be validated as appropriate for the security requirements, using functionality equivalent to the algorithm specified in [RFC5280] section 6. If the certificate contains a SubjectAltName, then the Authority Name MUST match at least one of the authority names of any CoAP URI found in a field of URI type in the SubjectAltName set. If there is no SubjectAltName in the certificate, then the Authoritative Name must match the CN found in the certificate using the matching rules defined in [RFC2818] with the exception that certificates with wildcards are not allowed. CoRE support for certificate status checking requires further work. As a mapping of OCSP [RFC2560] onto CoAP is not currently defined and OCSP may also not be easily applicable in all environments, an alternative approach may be using the TLS Certificate Status Request extension ([RFC6066] section 8, also known as "OCSP stapling"), if the limitations of that extension are acceptable. If the system has a shared key in addition to the certificate, then a cipher suite that includes the shared key such as TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA [RFC5489] SHOULD be used. From trac+core@trac.tools.ietf.org Tue Apr 30 11:42:52 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BAF21F9B2F for ; Tue, 30 Apr 2013 11:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 R+J+DTmKxHai for ; Tue, 30 Apr 2013 11:42:51 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 950FC21F9B2C for ; Tue, 30 Apr 2013 11:42:51 -0700 (PDT) Received: from localhost ([127.0.0.1]:54004 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXFVp-0000HR-Lz; Tue, 30 Apr 2013 20:42:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Tue, 30 Apr 2013 18:42:49 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/309#comment:1 Message-ID: <066.edbfef522f8a31fdff95d1a359c0a5e9@trac.tools.ietf.org> References: <051.f585672c1ab4fdc3979451b45ebc3fb9@trac.tools.ietf.org> X-Trac-Ticket-ID: 309 In-Reply-To: <051.f585672c1ab4fdc3979451b45ebc3fb9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130430184251.950FC21F9B2C@ietfa.amsl.com> Resent-Date: Tue, 30 Apr 2013 11:42:51 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #309: URI matching rules may be scheme specific 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, 30 Apr 2013 18:42:52 -0000 #309: URI matching rules may be scheme specific Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1347]: Fix #309, #302; address Ted Lemon's hairy comment -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: other | Status: closed technical | Milestone: post-IESG-1 Priority: minor | Version: coap-15 Component: coap | Resolution: fixed Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Apr 30 11:42: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 75BAA21F9B2F for ; Tue, 30 Apr 2013 11:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFJ-RhI7gMLf for ; Tue, 30 Apr 2013 11:42:52 -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 B72D221F9B2C for ; Tue, 30 Apr 2013 11:42:52 -0700 (PDT) Received: from localhost ([127.0.0.1]:54005 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXFVp-0000Ip-Mv; Tue, 30 Apr 2013 20:42:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Tue, 30 Apr 2013 18:42:49 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/302#comment:1 Message-ID: <066.c9bf4e1f71ffd6e0c523f29b55aa07c9@trac.tools.ietf.org> References: <051.a8274f5d8806b4cb6934402d708a1aac@trac.tools.ietf.org> X-Trac-Ticket-ID: 302 In-Reply-To: <051.a8274f5d8806b4cb6934402d708a1aac@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130430184252.B72D221F9B2C@ietfa.amsl.com> Resent-Date: Tue, 30 Apr 2013 11:42:52 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #302: Define Cache-key properly 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, 30 Apr 2013 18:42:53 -0000 #302: Define Cache-key properly Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1347]: Fix #309, #302; address Ted Lemon's hairy comment -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: post-IESG-1 Component: coap | Version: coap-15 Severity: Submitted | Resolution: fixed WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From Akbar.Rahman@InterDigital.com Tue Apr 30 11:43: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 A428121F9B5E for ; Tue, 30 Apr 2013 11:43: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 j8m2sRLnLSeM for ; Tue, 30 Apr 2013 11:43:53 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED9D21F9B4C for ; Tue, 30 Apr 2013 11:43:53 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Apr 2013 14:43:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Apr 2013 14:43:51 -0400 Message-ID: In-Reply-To: <61F5D3B1-0923-4295-933A-E8F448A37062@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Certificate mode in -16 Thread-Index: Ac5FyIN5CDEhTBTSR26Wf96jmfRhEAACKB4w References: <61F5D3B1-0923-4295-933A-E8F448A37062@tzi.org> From: "Rahman, Akbar" To: "Carsten Bormann" X-OriginalArrivalTime: 30 Apr 2013 18:43:52.0141 (UTC) FILETIME=[A90467D0:01CE45D2] Cc: core@ietf.org Subject: Re: [core] Certificate mode in -16 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 30 Apr 2013 18:43:57 -0000 Hi Carsten, First, thank you for all your hard work in systematically answering the = IESG comments. It is very impressive! I have a question on the (extracted) text below from the X.509 = Certificates text. =20 The Authority Name in the certificate is the name that would be used in the Host part of a CoAP URI. It is worth noting that this would typically not be either an IP address or DNS name built in the usual way but would instead be built out of a long term unique identifier for the device such as the EUI-64 [EUI64]. I don't follow the logic where it is implying above that the host part = of the CoAP URI would NOT be the IP address or DNS name. For example, = this then does not comply to the text in section 6.1 (coap URI Scheme). = Does it? /Akbar -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Carsten Bormann Sent: Tuesday, April 30, 2013 1:29 PM To: core@ietf.org (core@ietf.org) Subject: [core] Certificate mode in -16 I just made an attempt at addressing the IESG comments on section = 9.1.3.3, X.509 Certificates. I think I'm done with #316 and #318 (and have closed those), but I would = like to hear your input on #317. I'm reproducing the formatted version = of 9.1.3.3 as of [1346] below. The changes are: -- point to RFC5280 section 6 (#316) -- add a paragraph about cert status checking (#317) -- RSA is out, ECDHE is in for cert-with-PSK, too (#318) Gr=FC=DFe, Carsten 9.1.3.3. X.509 Certificates Implementations in Certificate Mode MUST support the mandatory to implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in [RFC5246]. The Authority Name in the certificate is the name that would be used in the Host part of a CoAP URI. It is worth noting that this would typically not be either an IP address or DNS name built in the usual way but would instead be built out of a long term unique identifier for the device such as the EUI-64 [EUI64]. The discovery process used in the system would build up the mapping between IP addresses of the given devices and the Authority Name for each device. Some devices could have more than one Authority and would need more than a single certificate. When a new connection is formed, the certificate from the remote device needs to be verified. If the CoAP node has a source of absolute time, then the node SHOULD check that the validity dates of the certificate are within range. The certificate MUST be validated as appropriate for the security requirements, using functionality equivalent to the algorithm specified in [RFC5280] section 6. If the certificate contains a SubjectAltName, then the Authority Name MUST match at least one of the authority names of any CoAP URI found in a field of URI type in the SubjectAltName set. If there is no SubjectAltName in the certificate, then the Authoritative Name must match the CN found in the certificate using the matching rules defined in [RFC2818] with the exception that certificates with wildcards are not allowed. CoRE support for certificate status checking requires further work. As a mapping of OCSP [RFC2560] onto CoAP is not currently defined and OCSP may also not be easily applicable in all environments, an alternative approach may be using the TLS Certificate Status Request extension ([RFC6066] section 8, also known as "OCSP stapling"), if the limitations of that extension are acceptable. If the system has a shared key in addition to the certificate, then a cipher suite that includes the shared key such as TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA [RFC5489] SHOULD be used. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From hannes.tschofenig@gmx.net Tue Apr 30 11:53:47 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA8A21F9B5E for ; Tue, 30 Apr 2013 11:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGr1+EJpPUcj for ; Tue, 30 Apr 2013 11:53:42 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id CE54521F9BA4 for ; Tue, 30 Apr 2013 11:53:29 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M1Cg2-1UI4J62pnk-00tDhn for ; Tue, 30 Apr 2013 20:53:28 +0200 Received: (qmail invoked by alias); 30 Apr 2013 18:53:28 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp029) with SMTP; 30 Apr 2013 20:53:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18r6+AkJxMrr/HACl6gbyGmE6tpszTg5VTigfRdAu lPELliHwgGxMVa Message-ID: <51801322.60802@gmx.net> Date: Tue, 30 Apr 2013 21:53:22 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: core@ietf.org References: <518012B3.3030202@gmx.net> In-Reply-To: <518012B3.3030202@gmx.net> X-Forwarded-Message-Id: <518012B3.3030202@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [core] Fwd: Re: Certificate mode in -16 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 30 Apr 2013 18:53:47 -0000 FYI -------- Original Message -------- Subject: Re: [core] Certificate mode in -16 Date: Tue, 30 Apr 2013 21:51:31 +0300 From: Hannes Tschofenig To: Carsten Bormann CC: hannes.tschofenig@gmx.net Hi Carsten, On 04/30/2013 08:28 PM, Carsten Bormann wrote: > CoRE support for certificate status checking requires further work. > As a mapping of OCSP [RFC2560] onto CoAP is not currently defined and > OCSP may also not be easily applicable in all environments, an > alternative approach may be using the TLS Certificate Status Request > extension ([RFC6066] section 8, also known as "OCSP stapling"), if > the limitations of that extension are acceptable. The issue with OCSP stapling is that it only provides the OCSP response for the server's own certificate, but not the status of intermediate certificates in the chain. Despite the constraint nature it seems that some of the embedded folks,like the Zigbee Alliance, envision a fairly deep certificate hierarchy. So, you might just better go for http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-08 instead. Since the embedded devices often have a nailed up communication relationship an alternative is to use only shared secrets or raw public keys instead (if you care about the communication overhead and the lightweight nature of the CoAP environment). Ciao Hannes From cabo@tzi.org Tue Apr 30 11:58: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 2C13621F9C0D for ; Tue, 30 Apr 2013 11:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.224 X-Spam-Level: X-Spam-Status: No, score=-106.224 tagged_above=-999 required=5 tests=[AWL=0.025, 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 jAcdx1UIlD2E for ; Tue, 30 Apr 2013 11:58:44 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 143C821F9AC6 for ; Tue, 30 Apr 2013 11:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r3UIwcmT003005; Tue, 30 Apr 2013 20:58:38 +0200 (CEST) Received: from [192.168.217.105] (p54893D76.dip0.t-ipconnect.de [84.137.61.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 68477307A; Tue, 30 Apr 2013 20:58:38 +0200 (CEST) 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: <51801322.60802@gmx.net> Date: Tue, 30 Apr 2013 20:58:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <887348ED-2DB1-4981-8095-0986F410552D@tzi.org> References: <518012B3.3030202@gmx.net> <51801322.60802@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1503) Cc: core@ietf.org Subject: Re: [core] Fwd: Re: Certificate mode in -16 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 30 Apr 2013 18:58:49 -0000 On Apr 30, 2013, at 20:53, Hannes Tschofenig = wrote: > So, you might just better go for > = http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-0= 8 > instead. Maybe its best to reference both; it is unfortunate that the situation = here is a bit volatile. Do you know anything about the implementation status of = status_request_v2? Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Tue Apr 30 12:22: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 18FC521F94CC for ; Tue, 30 Apr 2013 12:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 KgVQf7C+KfQq for ; Tue, 30 Apr 2013 12:22:07 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 89D6021F9607 for ; Tue, 30 Apr 2013 12:21:58 -0700 (PDT) Received: from localhost ([127.0.0.1]:56549 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXG7d-0007fG-AB; Tue, 30 Apr 2013 21:21:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Tue, 30 Apr 2013 19:21:53 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/317#comment:2 Message-ID: <066.a97b4610197fc9fa3b57ae5296e048fd@trac.tools.ietf.org> References: <051.40390e78181a5495322700d2f176a59e@trac.tools.ietf.org> X-Trac-Ticket-ID: 317 In-Reply-To: <051.40390e78181a5495322700d2f176a59e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130430192203.89D6021F9607@ietfa.amsl.com> Resent-Date: Tue, 30 Apr 2013 12:21:58 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #317: Point out OCSP stapling (TLS Certificate Status Request) as a viable way to get cert status info on a constrained node 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, 30 Apr 2013 19:22:12 -0000 #317: Point out OCSP stapling (TLS Certificate Status Request) as a viable way to get cert status info on a constrained node Comment (by cabo@tzi.org): From [1348]: Add reference to status_request_v2 (Multiple Certificate Status Extension) as per Hannes' comment; see #317. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: editorial | Status: new Priority: minor | Milestone: post-IESG-1 Component: coap | Version: coap-15 Severity: Submitted | Resolution: WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Apr 30 12:34: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 9D7D221F99E8 for ; Tue, 30 Apr 2013 12:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 2sJFwf5-mPOX for ; Tue, 30 Apr 2013 12:34:04 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id C86C821F983C for ; Tue, 30 Apr 2013 12:34:03 -0700 (PDT) Received: from localhost ([127.0.0.1]:57266 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXGJL-0002qS-EB; Tue, 30 Apr 2013 21:33:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Tue, 30 Apr 2013 19:33:59 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/310#comment:1 Message-ID: <066.b23fffce2e2a84d22be1a66762281c0c@trac.tools.ietf.org> References: <051.187ee374bd1a6d9f570ef59238b48296@trac.tools.ietf.org> X-Trac-Ticket-ID: 310 In-Reply-To: <051.187ee374bd1a6d9f570ef59238b48296@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130430193403.C86C821F983C@ietfa.amsl.com> Resent-Date: Tue, 30 Apr 2013 12:34:03 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #310: Don't dally beyond MAX_TRANSMIT_SPAN during retransmission 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, 30 Apr 2013 19:34:04 -0000 #310: Don't dally beyond MAX_TRANSMIT_SPAN during retransmission Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1349]: Fix #310 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: other | Status: closed technical | Milestone: post-IESG-1 Priority: minor | Version: coap-15 Component: coap | Resolution: fixed Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From zach@sensinode.com Tue Apr 30 12:35: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 EE22E21F9A72 for ; Tue, 30 Apr 2013 12:35:14 -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 jXMmP8Ukmtpl for ; Tue, 30 Apr 2013 12:35:10 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8EE21F9A44 for ; Tue, 30 Apr 2013 12:35:10 -0700 (PDT) Received: from [192.168.1.100] (87-95-85-145.bb.dnainternet.fi [87.95.85.145]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r3UJZ4t5022748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Apr 2013 22:35:05 +0300 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: Date: Tue, 30 Apr 2013 22:35:01 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <15A2B96F-25E1-4262-AA54-F4BB520A0551@sensinode.com> References: <61F5D3B1-0923-4295-933A-E8F448A37062@tzi.org> To: "Rahman, Akbar" X-Mailer: Apple Mail (2.1503) Cc: core@ietf.org Subject: Re: [core] Certificate mode in -16 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 30 Apr 2013 19:35:15 -0000 On Apr 30, 2013, at 9:43 PM, "Rahman, Akbar" = wrote: > I have a question on the (extracted) text below from the X.509 = Certificates text. =20 >=20 > The Authority Name in the certificate is the name that would be used > in the Host part of a CoAP URI. It is worth noting that this would > typically not be either an IP address or DNS name built in the usual > way but would instead be built out of a long term unique identifier > for the device such as the EUI-64 [EUI64]. >=20 > I don't follow the logic where it is implying above that the host part = of the CoAP URI would NOT be the IP address or DNS name. For example, = this then does not comply to the text in section 6.1 (coap URI Scheme). = Does it? In the typical Web certificate world the Authority Name would be your = DNS name and/or IP addresses (the Host part of a CoAP URI). What this is = trying to say is that an endpoint (at least a constrained one) doesn't = typically have a DNS name, and the IP address is usually volatile. So = instead, the way we identify things is with a more stable identifier = such as the EUI-64. This is saying to use this stable identifier as the = Authority Name in the certificate. Of course if you did happen to have a = DNS name, you can use that. So this text is not changing the way we use = the Host part of a CoAP URI. This has come up before, so we probably = need to do some word-smithing to clarify that paragraph. 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 trac+core@trac.tools.ietf.org Tue Apr 30 13:03: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 6F56321F9AEF for ; Tue, 30 Apr 2013 13:03:07 -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.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RqmZxBQy+vO for ; Tue, 30 Apr 2013 13:03:06 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4ED21F97C4 for ; Tue, 30 Apr 2013 13:03:06 -0700 (PDT) Received: from localhost ([127.0.0.1]:59036 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXGl2-0004tb-CO; Tue, 30 Apr 2013 22:02:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, zach@sensinode.com X-Trac-Project: core Date: Tue, 30 Apr 2013 20:02:36 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/304#comment:1 Message-ID: <066.5055698711b82d290edcb8cf981fa1c9@trac.tools.ietf.org> References: <051.448ad98d27c7eb82eda7957a9c0c66e4@trac.tools.ietf.org> X-Trac-Ticket-ID: 304 In-Reply-To: <051.448ad98d27c7eb82eda7957a9c0c66e4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130430200306.8D4ED21F97C4@ietfa.amsl.com> Resent-Date: Tue, 30 Apr 2013 13:03:06 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #304: NON is like separate for CON 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, 30 Apr 2013 20:03:07 -0000 #304: NON is like separate for CON Changes (by zach@sensinode.com): * status: new => closed * resolution: => fixed Comment: Fixed in [1350]: Simple fix for #304 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: post-IESG-1 Component: coap | Version: coap-15 Severity: Submitted | Resolution: fixed WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From Akbar.Rahman@InterDigital.com Tue Apr 30 13:07: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 0D46F21F8443 for ; Tue, 30 Apr 2013 13:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VR51hZmCVKzG for ; Tue, 30 Apr 2013 13:07:46 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1339F21F9AF9 for ; Tue, 30 Apr 2013 13:07:44 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Apr 2013 16:07:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Apr 2013 16:07:08 -0400 Message-ID: In-Reply-To: <15A2B96F-25E1-4262-AA54-F4BB520A0551@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Certificate mode in -16 Thread-Index: Ac5F2ehLH0DOQXQzSjOuruBWQ1tivwAA81EQ References: <61F5D3B1-0923-4295-933A-E8F448A37062@tzi.org> <15A2B96F-25E1-4262-AA54-F4BB520A0551@sensinode.com> From: "Rahman, Akbar" To: "Zach Shelby" X-OriginalArrivalTime: 30 Apr 2013 20:07:09.0060 (UTC) FILETIME=[4B69BC40:01CE45DE] Cc: core@ietf.org Subject: Re: [core] Certificate mode in -16 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 30 Apr 2013 20:07:50 -0000 Hi Zach, Thanks. Yes, I definitely think some word-smithing would be useful. Also, purely for my personal interest, did anyone use EUI-64 in any of the CoAP interops? Or are there any CoAP deployments that you are aware of that use EUI-64? Akbar -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com]=20 Sent: Tuesday, April 30, 2013 3:35 PM To: Rahman, Akbar Cc: Carsten Bormann; core@ietf.org Subject: Re: [core] Certificate mode in -16 On Apr 30, 2013, at 9:43 PM, "Rahman, Akbar" wrote: > I have a question on the (extracted) text below from the X.509 Certificates text. =20 >=20 > The Authority Name in the certificate is the name that would be used > in the Host part of a CoAP URI. It is worth noting that this would > typically not be either an IP address or DNS name built in the usual > way but would instead be built out of a long term unique identifier > for the device such as the EUI-64 [EUI64]. >=20 > I don't follow the logic where it is implying above that the host part of the CoAP URI would NOT be the IP address or DNS name. For example, this then does not comply to the text in section 6.1 (coap URI Scheme). Does it? In the typical Web certificate world the Authority Name would be your DNS name and/or IP addresses (the Host part of a CoAP URI). What this is trying to say is that an endpoint (at least a constrained one) doesn't typically have a DNS name, and the IP address is usually volatile. So instead, the way we identify things is with a more stable identifier such as the EUI-64. This is saying to use this stable identifier as the Authority Name in the certificate. Of course if you did happen to have a DNS name, you can use that. So this text is not changing the way we use the Host part of a CoAP URI. This has come up before, so we probably need to do some word-smithing to clarify that paragraph. 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 trac+core@trac.tools.ietf.org Tue Apr 30 13:15: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 D224321F9B04 for ; Tue, 30 Apr 2013 13:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 gYUhR0a93HTH for ; Tue, 30 Apr 2013 13:15:12 -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 A3D1C21F9682 for ; Tue, 30 Apr 2013 13:15:10 -0700 (PDT) Received: from localhost ([127.0.0.1]:60214 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXGx3-0006Az-Sx; Tue, 30 Apr 2013 22:15:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, zach@sensinode.com X-Trac-Project: core Date: Tue, 30 Apr 2013 20:15:01 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/301#comment:1 Message-ID: <066.3ff058bc37c1376f82a25dbb5c393c76@trac.tools.ietf.org> References: <051.7563e72089a600fb465c5ca371093e32@trac.tools.ietf.org> X-Trac-Ticket-ID: 301 In-Reply-To: <051.7563e72089a600fb465c5ca371093e32@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130430201511.A3D1C21F9682@ietfa.amsl.com> Resent-Date: Tue, 30 Apr 2013 13:15:10 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #301: Once separate, separate forever 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, 30 Apr 2013 20:15:12 -0000 #301: Once separate, separate forever Changes (by zach@sensinode.com): * status: new => closed * resolution: => fixed Comment: Fixed in [1351] -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: other | Status: closed technical | Milestone: post-IESG-1 Priority: minor | Version: coap-15 Component: coap | Resolution: fixed Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Apr 30 13:22:56 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16DC21F9A96 for ; Tue, 30 Apr 2013 13:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 NAOTOLRfBEuD for ; Tue, 30 Apr 2013 13:22:55 -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 8FCD421F9A8F for ; Tue, 30 Apr 2013 13:22:52 -0700 (PDT) Received: from localhost ([127.0.0.1]:60494 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXH48-0002F6-1d; Tue, 30 Apr 2013 22:22:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Tue, 30 Apr 2013 20:22:20 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/303#comment:1 Message-ID: <066.372961c82642b21d7284947411f6571b@trac.tools.ietf.org> References: <051.131a8cf335fc9b5591e5ef3d50ce8ec8@trac.tools.ietf.org> X-Trac-Ticket-ID: 303 In-Reply-To: <051.131a8cf335fc9b5591e5ef3d50ce8ec8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130430202253.8FCD421F9A8F@ietfa.amsl.com> Resent-Date: Tue, 30 Apr 2013 13:22:52 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #303: Clarify that ACKs don't get retransmitted, the CONs do 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, 30 Apr 2013 20:22:56 -0000 #303: Clarify that ACKs don't get retransmitted, the CONs do Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1352]: Try a minimum change to fix #303 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: post-IESG-1 Component: coap | Version: coap-15 Severity: Submitted | Resolution: fixed WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From zach@sensinode.com Tue Apr 30 13:27:11 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D319721F9A95 for ; Tue, 30 Apr 2013 13:27:11 -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 IZRIVf3eJ4yW for ; Tue, 30 Apr 2013 13:27:07 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 07C6921F8AC2 for ; Tue, 30 Apr 2013 13:27:03 -0700 (PDT) Received: from [192.168.1.100] (87-95-85-145.bb.dnainternet.fi [87.95.85.145]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r3UKQTNn028763 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Apr 2013 23:26:30 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: Date: Tue, 30 Apr 2013 23:26:29 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6E3722B6-A66C-4C3A-9CF1-DB2C58903F21@sensinode.com> References: <61F5D3B1-0923-4295-933A-E8F448A37062@tzi.org> <15A2B96F-25E1-4262-AA54-F4BB520A0551@sensinode.com> To: "Rahman, Akbar" X-Mailer: Apple Mail (2.1503) Cc: core@ietf.org Subject: Re: [core] Certificate mode in -16 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 30 Apr 2013 20:27:11 -0000 On Apr 30, 2013, at 11:07 PM, "Rahman, Akbar" = wrote: > Thanks. Yes, I definitely think some word-smithing would be useful. Any chance you could suggest text for that first sentence to make that = really clear? Should we just stop using the analogy to the CoAP URI?=20 > Also, purely for my personal interest, did anyone use EUI-64 in any of > the CoAP interops? Or are there any CoAP deployments that you are = aware > of that use EUI-64? Well, this is talking about the Authority Name of certificates, and = there hasn't been an interop with certificate mode yet. We do have an = implementation of certificate mode where the Authority Name of = constrained nodes has been set as the EUI-64 and other serial numbers, = e.g. IMEI for Cellular devices.=20 I would also note that the Authority Name should be the same as the = Resource Directory Endpoint Name (the OMA LWM2M standard requires this = for authentication when registering), and we have been using EUI-64 and = other serial numbers there for a long time. Zach =20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From trac+core@trac.tools.ietf.org Tue Apr 30 13:37: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 BBC4921F96EB for ; Tue, 30 Apr 2013 13:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 bt+q7Wu0q70w for ; Tue, 30 Apr 2013 13:37:48 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id F3F9521F9668 for ; Tue, 30 Apr 2013 13:37:47 -0700 (PDT) Received: from localhost ([127.0.0.1]:33083 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXHJ3-0005vK-Rt; Tue, 30 Apr 2013 22:37:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, zach@sensinode.com X-Trac-Project: core Date: Tue, 30 Apr 2013 20:37:45 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/314#comment:1 Message-ID: <066.2cdcec1840316a46191f524d40add891@trac.tools.ietf.org> References: <051.5a2a199cb637ebcc8c443de0100e4a6a@trac.tools.ietf.org> X-Trac-Ticket-ID: 314 In-Reply-To: <051.5a2a199cb637ebcc8c443de0100e4a6a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130430203747.F3F9521F9668@ietfa.amsl.com> Resent-Date: Tue, 30 Apr 2013 13:37:47 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #314: Explicitly point out that UDP and DTLS don't mix 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, 30 Apr 2013 20:37:48 -0000 #314: Explicitly point out that UDP and DTLS don't mix Comment (by zach@sensinode.com): Fixed in [1354]. Added the following text to 9.1.1.: This means the response to a DTLS secured request MUST always be DTLS secured using the same security session and epoch. A !NoSec response to a DTLS request MUST be silently ignored. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: editorial | Status: new Priority: minor | Milestone: post-IESG-1 Component: coap | Version: coap-15 Severity: Submitted | Resolution: WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Tue Apr 30 13:38:43 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7084421F96EB for ; Tue, 30 Apr 2013 13:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 A+IDD+q4qUaS for ; Tue, 30 Apr 2013 13:38:43 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id C1B5B21F9A3E for ; Tue, 30 Apr 2013 13:38:38 -0700 (PDT) Received: from localhost ([127.0.0.1]:33087 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXHJM-0000S6-15; Tue, 30 Apr 2013 22:38:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, zach@sensinode.com X-Trac-Project: core Date: Tue, 30 Apr 2013 20:38:04 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/314#comment:2 Message-ID: <066.83f67d8fcc81b7b9196555d33fd53801@trac.tools.ietf.org> References: <051.5a2a199cb637ebcc8c443de0100e4a6a@trac.tools.ietf.org> X-Trac-Ticket-ID: 314 In-Reply-To: <051.5a2a199cb637ebcc8c443de0100e4a6a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130430203838.C1B5B21F9A3E@ietfa.amsl.com> Resent-Date: Tue, 30 Apr 2013 13:38:38 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #314: Explicitly point out that UDP and DTLS don't mix 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, 30 Apr 2013 20:38:43 -0000 #314: Explicitly point out that UDP and DTLS don't mix Changes (by zach@sensinode.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: post-IESG-1 Component: coap | Version: coap-15 Severity: Submitted | Resolution: fixed WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From tho@koanlogic.com Tue Apr 30 13:38: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 83D1621F9A8E for ; Tue, 30 Apr 2013 13:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.479 X-Spam-Level: X-Spam-Status: No, score=0.479 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 uG8srjQ33uSy for ; Tue, 30 Apr 2013 13:38:43 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id F181C21F9A63 for ; Tue, 30 Apr 2013 13:38:38 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id el20so831204lab.32 for ; Tue, 30 Apr 2013 13:38:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=aJ0SFA4fh+v3Sm87mFJqFsMIgpy3W34KufJFh1y+LxM=; b=ALMreOsgZ0Ic1oiCmnuFrhcIOpVQNnyBAfxhOrH9VXFjlzsskJfOEF2uI/RhRl2j2F gufr3TXH6+99tzaH6JpyQNSzldWuFc0LAEtt7DbdBiRy3TwqeL5f+NiRbzrXJh8wYaJf d/UyXrZo26m84h3T0GM5yOn4J9yjMDaGn//LkeOAmJNkpKevkQ5azDn6oBFLeRrCxsx7 lVHtS2PKzXrCXbQ6P+ns5wbVR1QIXbjfAts5nW5JPx8bFeRozwxxGVL5bG/qDjZv3LSZ kstyo7/FJ2rTYHbD0JhX+H9Xuy+ZN2ANkdInq3MpaNfkBGg6MDkn3+cX87OueO7dY5Un M6yQ== MIME-Version: 1.0 X-Received: by 10.112.150.228 with SMTP id ul4mr167347lbb.132.1367354297207; Tue, 30 Apr 2013 13:38:17 -0700 (PDT) Received: by 10.114.93.7 with HTTP; Tue, 30 Apr 2013 13:38:17 -0700 (PDT) X-Originating-IP: [78.150.54.239] In-Reply-To: <6E3722B6-A66C-4C3A-9CF1-DB2C58903F21@sensinode.com> References: <61F5D3B1-0923-4295-933A-E8F448A37062@tzi.org> <15A2B96F-25E1-4262-AA54-F4BB520A0551@sensinode.com> <6E3722B6-A66C-4C3A-9CF1-DB2C58903F21@sensinode.com> Date: Tue, 30 Apr 2013 21:38:17 +0100 Message-ID: From: Thomas Fossati To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnqFfSJjhyKnv73JH7rpvf9TwY6+19kaJSdoKaJDuHFrKXWZW+DER+RS82rbkoCBil9Cese Cc: "core@ietf.org" Subject: Re: [core] Certificate mode in -16 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 30 Apr 2013 20:38:48 -0000 On Tue, Apr 30, 2013 at 9:26 PM, Zach Shelby wrote: > On Apr 30, 2013, at 11:07 PM, "Rahman, Akbar" wrote: > >> Thanks. Yes, I definitely think some word-smithing would be useful. A releated question is whether we need, in case EUI-64 is used as Authority Name, to define a new NameType of type "EUI-64" for SNI. From trac+core@trac.tools.ietf.org Tue Apr 30 14:03: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 5C58721F85C3 for ; Tue, 30 Apr 2013 14:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95cDQ+lQ81k6 for ; Tue, 30 Apr 2013 14:03:13 -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 49DF921F97D1 for ; Tue, 30 Apr 2013 14:00:47 -0700 (PDT) Received: from localhost ([127.0.0.1]:34786 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXHfI-0004iR-LU; Tue, 30 Apr 2013 23:00:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, zach@sensinode.com, cabo@tzi.org X-Trac-Project: core Date: Tue, 30 Apr 2013 21:00:44 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/314#comment:3 Message-ID: <066.cc3862f0c6517ed94b7668d010c9ccb0@trac.tools.ietf.org> References: <051.5a2a199cb637ebcc8c443de0100e4a6a@trac.tools.ietf.org> X-Trac-Ticket-ID: 314 In-Reply-To: <051.5a2a199cb637ebcc8c443de0100e4a6a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, zach@sensinode.com, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130430210048.49DF921F97D1@ietfa.amsl.com> Resent-Date: Tue, 30 Apr 2013 14:00:47 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #314: Explicitly point out that UDP and DTLS don't mix 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, 30 Apr 2013 21:03:14 -0000 #314: Explicitly point out that UDP and DTLS don't mix Comment (by cabo@tzi.org): From [1355]: Move over the text re #314 to the request/response layer section (9.1.2) and slightly clarify it. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: post-IESG-1 Component: coap | Version: coap-15 Severity: Submitted | Resolution: fixed WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From cabo@tzi.org Tue Apr 30 14:12: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 5B5D421F9603 for ; Tue, 30 Apr 2013 14:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.226 X-Spam-Level: X-Spam-Status: No, score=-106.226 tagged_above=-999 required=5 tests=[AWL=0.023, 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 Bp-apsHTBrXS for ; Tue, 30 Apr 2013 14:11:52 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 3356521F9487 for ; Tue, 30 Apr 2013 14:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r3ULBMaG022969; Tue, 30 Apr 2013 23:11:22 +0200 (CEST) Received: from [192.168.217.105] (p54893D76.dip0.t-ipconnect.de [84.137.61.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E18B930AD; Tue, 30 Apr 2013 23:11:21 +0200 (CEST) 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: <051.0bcb9e2128c0ec3f50de6841ac1a2dfd@trac.tools.ietf.org> Date: Tue, 30 Apr 2013 23:11:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <478E5899-E979-4929-B96E-FBEB88E22FFF@tzi.org> References: <051.0bcb9e2128c0ec3f50de6841ac1a2dfd@trac.tools.ietf.org> To: trac+core@grenache.tools.ietf.org X-Mailer: Apple Mail (2.1503) Cc: draft-ietf-core-coap@tools.ietf.org, core@ietf.org Subject: Re: [core] #320: Nail down who does Unicode normalization when (or not) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 30 Apr 2013 21:12:04 -0000 So here is my proposal for the sentenced addressed by #320: There is no expectation and no need to perform normalization within a CoAP implementation, since = senders are expected to be implemented with pre-normalized strings. However, strings received from non-CoAP = sources need to be normalized when it is important that they compare correctly with normalized strings representing the same text. (this is on page 19, in the text that explains what we mean by an option = type "string".) This changes the existing semi-prescriptive "not expected to normalize = except on import" into a simple, true descriptive statement about what = will go wrong if you don't. I think this is exactly what we can do = here. I'll put this in tomorrow if people agree with this approach. Gr=FC=DFe, Carsten From Akbar.Rahman@InterDigital.com Tue Apr 30 14:33: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 03F0821F9A79 for ; Tue, 30 Apr 2013 14:33:34 -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 LynHr-vtsMJ0 for ; Tue, 30 Apr 2013 14:32:35 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 95E1E21F8EE1 for ; Tue, 30 Apr 2013 14:32:29 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Apr 2013 17:32:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Apr 2013 17:32:20 -0400 Message-ID: In-Reply-To: <6E3722B6-A66C-4C3A-9CF1-DB2C58903F21@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Certificate mode in -16 Thread-Index: Ac5F4Sfm3Y8A48tDT5ekF7xgLRGYTwAB9puA References: <61F5D3B1-0923-4295-933A-E8F448A37062@tzi.org> <15A2B96F-25E1-4262-AA54-F4BB520A0551@sensinode.com> <6E3722B6-A66C-4C3A-9CF1-DB2C58903F21@sensinode.com> From: "Rahman, Akbar" To: "Zach Shelby" X-OriginalArrivalTime: 30 Apr 2013 21:32:20.0856 (UTC) FILETIME=[3247E780:01CE45EA] Cc: core@ietf.org Subject: Re: [core] Certificate mode in -16 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 30 Apr 2013 21:33:34 -0000 Hi Zach, How about something like this? The Authority Name in the certificate would be based out of a long term unique identifier for the device such as the EUI-64 [EUI64]. The Authority Name could also be based on the FQDN that was used as the Host part of the CoAP URI. However, the device's IP address should not typically be used as the Authority name as it would change over time. Akbar -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com]=20 Sent: Tuesday, April 30, 2013 4:26 PM To: Rahman, Akbar Cc: Carsten Bormann; core@ietf.org Subject: Re: [core] Certificate mode in -16 On Apr 30, 2013, at 11:07 PM, "Rahman, Akbar" wrote: > Thanks. Yes, I definitely think some word-smithing would be useful. Any chance you could suggest text for that first sentence to make that really clear? Should we just stop using the analogy to the CoAP URI?=20 > Also, purely for my personal interest, did anyone use EUI-64 in any of > the CoAP interops? Or are there any CoAP deployments that you are=20 > aware of that use EUI-64? Well, this is talking about the Authority Name of certificates, and there hasn't been an interop with certificate mode yet. We do have an implementation of certificate mode where the Authority Name of constrained nodes has been set as the EUI-64 and other serial numbers, e.g. IMEI for Cellular devices.=20 I would also note that the Authority Name should be the same as the Resource Directory Endpoint Name (the OMA LWM2M standard requires this for authentication when registering), and we have been using EUI-64 and other serial numbers there for a long time. 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 trac+core@trac.tools.ietf.org Tue Apr 30 14:56:17 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E36121F9A8C for ; Tue, 30 Apr 2013 14:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 czdgOIPDegn8 for ; Tue, 30 Apr 2013 14:56:16 -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 8E47221F9A83 for ; Tue, 30 Apr 2013 14:56:16 -0700 (PDT) Received: from localhost ([127.0.0.1]:38377 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXIX0-0000xU-Ol; Tue, 30 Apr 2013 23:56:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Tue, 30 Apr 2013 21:56:14 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/321#comment:1 Message-ID: <066.15aebd18c476438e24972d925abc03b8@trac.tools.ietf.org> References: <051.6bf19250add8dbf26e613d0675ca2fd3@trac.tools.ietf.org> X-Trac-Ticket-ID: 321 In-Reply-To: <051.6bf19250add8dbf26e613d0675ca2fd3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20130430215616.8E47221F9A83@ietfa.amsl.com> Resent-Date: Tue, 30 Apr 2013 14:56:16 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #321: Point out that Uri-Host doesn't handle user-part. 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, 30 Apr 2013 21:56:17 -0000 #321: Point out that Uri-Host doesn't handle user-part. Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1356]: Fix #321 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: post-IESG-1 Component: coap | Version: coap-15 Severity: Submitted | Resolution: fixed WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From paduffy@cisco.com Tue Apr 30 15:05: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 4295421F9AE6 for ; Tue, 30 Apr 2013 15:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJ0RtefarYy3 for ; Tue, 30 Apr 2013 15:05:20 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3451221F9AE3 for ; Tue, 30 Apr 2013 15:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1558; q=dns/txt; s=iport; t=1367359520; x=1368569120; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=ITRfTS2higXQtiQSAgB49N5ZYlwjuCNij5yHBMKe9Mk=; b=DkeBn6+tZ500qh9KOJgfV++0/R8U4rcaEMAo/03IHqOMiPnWrl2zbr9w o6SNUxZzZuyAjkpbU/KTVOrYGkeL/GAASBloGDBPw0p+DxKQ+xlwWrSwa 6l7FGsqoqVh8jCo6G9pZ+n6gL7byvdBd1ESQFLJ9FIE7x31VS8kEtjiZ7 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFACk/gFGrRDoG/2dsb2JhbABIAQmDB78cfxZ0gh8BAQEEOEARCxgJFg8JAwIBAgFFEwQCAgEBiAcBsH2OY41dAYFCFoM6A5cmhhOLGoMpJA X-IronPort-AV: E=Sophos;i="4.87,584,1363132800"; d="scan'208";a="79969897" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 30 Apr 2013 22:05:18 +0000 Received: from [161.44.66.125] (printer-xx-00a645.cisco.com [161.44.66.125]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3UM5GZk024796 for ; Tue, 30 Apr 2013 22:05:17 GMT Message-ID: <5180401C.2000700@cisco.com> Date: Tue, 30 Apr 2013 18:05:16 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: core@ietf.org References: <61F5D3B1-0923-4295-933A-E8F448A37062@tzi.org> <15A2B96F-25E1-4262-AA54-F4BB520A0551@sensinode.com> <6E3722B6-A66C-4C3A-9CF1-DB2C58903F21@sensinode.com> In-Reply-To: <6E3722B6-A66C-4C3A-9CF1-DB2C58903F21@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [core] Certificate mode in -16 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 22:05:26 -0000 Folks, Re: EUI-64 as the unique device identity. My understanding is that it is far better practice to use a concatention of manufacturer-id, product-code, serial number (or similar) versus the MAC address. You might also consider a review IEEE 802.1ar for secure device identify guidance. OCSP and CRLs are likely to prove challenging to support within an LLN environment. For this reason, Zigbee IP avoids them. Cheers On 4/30/2013 4:26 PM, Zach Shelby wrote: > On Apr 30, 2013, at 11:07 PM, "Rahman, Akbar" wrote: > >> Thanks. Yes, I definitely think some word-smithing would be useful. > Any chance you could suggest text for that first sentence to make that really clear? Should we just stop using the analogy to the CoAP URI? > >> Also, purely for my personal interest, did anyone use EUI-64 in any of >> the CoAP interops? Or are there any CoAP deployments that you are aware >> of that use EUI-64? > Well, this is talking about the Authority Name of certificates, and there hasn't been an interop with certificate mode yet. We do have an implementation of certificate mode where the Authority Name of constrained nodes has been set as the EUI-64 and other serial numbers, e.g. IMEI for Cellular devices. > > I would also note that the Authority Name should be the same as the Resource Directory Endpoint Name (the OMA LWM2M standard requires this for authentication when registering), and we have been using EUI-64 and other serial numbers there for a long time. > > Zach > From cabo@tzi.org Tue Apr 30 15:37:43 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F58621F9AC6 for ; Tue, 30 Apr 2013 15:37:43 -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 q6Fw4TP0xkx8 for ; Tue, 30 Apr 2013 15:37:37 -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 6480821F992E for ; Tue, 30 Apr 2013 15:37: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 r3UMbXZk021072; Wed, 1 May 2013 00:37:33 +0200 (CEST) Received: from [192.168.217.105] (p54893D76.dip0.t-ipconnect.de [84.137.61.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B7BCA30C6; Wed, 1 May 2013 00:37:32 +0200 (CEST) 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: <5180401C.2000700@cisco.com> Date: Wed, 1 May 2013 00:37:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <09EED999-F760-4D0B-BD15-DEC6FA50F1CE@tzi.org> References: <61F5D3B1-0923-4295-933A-E8F448A37062@tzi.org> <15A2B96F-25E1-4262-AA54-F4BB520A0551@sensinode.com> <6E3722B6-A66C-4C3A-9CF1-DB2C58903F21@sensinode.com> <5180401C.2000700@cisco.com> To: paduffy@cisco.com X-Mailer: Apple Mail (2.1503) Cc: core@ietf.org Subject: Re: [core] Certificate mode in -16 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 30 Apr 2013 22:37:43 -0000 On May 1, 2013, at 00:05, Paul Duffy wrote: > OCSP and CRLs are likely to prove challenging to support within an LLN = environment. For this reason, Zigbee IP avoids them. Is it just me, or did I just read: > Lifeboats are likely to prove challenging to support within an ocean = cruise. For this reason, the Titanic avoids them. (I'm not saying I have a solution, but the thing may be a bit more = complex than this sentence makes it look like.) Gr=FC=DFe, Carsten From zach@sensinode.com Tue Apr 30 23:22: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 ACE3421F85CB for ; Tue, 30 Apr 2013 23:22:01 -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 3ZGf8WOgEXg4 for ; Tue, 30 Apr 2013 23:21:57 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 4C69B21F859D for ; Tue, 30 Apr 2013 23:21:56 -0700 (PDT) Received: from [192.168.1.100] (87-95-85-145.bb.dnainternet.fi [87.95.85.145]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r416Lq2V021293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 May 2013 09:21:53 +0300 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: Date: Wed, 1 May 2013 09:21:51 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61F5D3B1-0923-4295-933A-E8F448A37062@tzi.org> <15A2B96F-25E1-4262-AA54-F4BB520A0551@sensinode.com> <6E3722B6-A66C-4C3A-9CF1-DB2C58903F21@sensinode.com> To: Thomas Fossati X-Mailer: Apple Mail (2.1503) Cc: "core@ietf.org" Subject: Re: [core] Certificate mode in -16 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 01 May 2013 06:22:01 -0000 On Apr 30, 2013, at 11:38 PM, Thomas Fossati wrote: > On Tue, Apr 30, 2013 at 9:26 PM, Zach Shelby = wrote: >> On Apr 30, 2013, at 11:07 PM, "Rahman, Akbar" = wrote: >>=20 >>> Thanks. Yes, I definitely think some word-smithing would be useful. >=20 > A releated question is whether we need, in case EUI-64 is used as > Authority Name, to define a new NameType of type "EUI-64" for SNI. Yes, I agree that we eventually will need that, but in a separate draft. = For now CN should be used for this purpose. 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 zach@sensinode.com Tue Apr 30 23:24:56 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5678D21F8689 for ; Tue, 30 Apr 2013 23:24:56 -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 BPdVDOh0H26Z for ; Tue, 30 Apr 2013 23:24:52 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id E688121F853A for ; Tue, 30 Apr 2013 23:24:51 -0700 (PDT) Received: from [192.168.1.100] (87-95-85-145.bb.dnainternet.fi [87.95.85.145]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r416Ojc9021579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 May 2013 09:24:46 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: <5180401C.2000700@cisco.com> Date: Wed, 1 May 2013 09:24:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9F27AD0B-AC50-42C4-936F-34533F97674E@sensinode.com> References: <61F5D3B1-0923-4295-933A-E8F448A37062@tzi.org> <15A2B96F-25E1-4262-AA54-F4BB520A0551@sensinode.com> <6E3722B6-A66C-4C3A-9CF1-DB2C58903F21@sensinode.com> <5180401C.2000700@cisco.com> To: paduffy@cisco.com X-Mailer: Apple Mail (2.1503) Cc: core@ietf.org Subject: Re: [core] Certificate mode in -16 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 01 May 2013 06:24:56 -0000 On May 1, 2013, at 1:05 AM, Paul Duffy wrote: > Re: EUI-64 as the unique device identity. My understanding is that it = is far better practice to use a concatention of manufacturer-id, = product-code, serial number (or similar) versus the MAC address. >=20 > You might also consider a review IEEE 802.1ar for secure device = identify guidance. Right, EUI-64 is just mentioned in that paragraph as an example, I agree = there are better identifiers. Our job in the CoAP specification isn't to = normatively require which to use though. Do you think that an = informative reference to IEEE 802.1ar would be useful in this paragraph?=20= Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From cabo@tzi.org Tue Apr 30 23:31: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 AE81221F8494 for ; Tue, 30 Apr 2013 23:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.23 X-Spam-Level: X-Spam-Status: No, score=-106.23 tagged_above=-999 required=5 tests=[AWL=0.019, 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 WWJmhvydJs+o for ; Tue, 30 Apr 2013 23:31:44 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8382F21F8488 for ; Tue, 30 Apr 2013 23:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r416Vfj0025953; Wed, 1 May 2013 08:31:41 +0200 (CEST) Received: from [192.168.217.105] (p54893D76.dip0.t-ipconnect.de [84.137.61.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E2DBA30DB; Wed, 1 May 2013 08:31:40 +0200 (CEST) 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: Wed, 1 May 2013 08:31:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5CD02602-ABEA-44A7-85FB-C610F5A00CC0@tzi.org> References: <61F5D3B1-0923-4295-933A-E8F448A37062@tzi.org> <15A2B96F-25E1-4262-AA54-F4BB520A0551@sensinode.com> To: "Rahman, Akbar" X-Mailer: Apple Mail (2.1503) Cc: core@ietf.org Subject: Re: [core] Certificate mode in -16 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 01 May 2013 06:31:50 -0000 On Apr 30, 2013, at 22:07, "Rahman, Akbar" = wrote: > did anyone use EUI-64 in any of > the CoAP interops?=20 We will have to wait for the next CoAP interop to do some real CoAP/DTLS = testing. (In fact, I think secure CoAP should be the focus for that.) Maybe in Vancouver this November... Gr=FC=DFe, Carsten