From trac+core@trac.tools.ietf.org Wed May 1 02:10: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 6A60421F8E7E for ; Wed, 1 May 2013 02:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 HP+oNf3zUAZL for ; Wed, 1 May 2013 02:10: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 C3F0021F8E7C for ; Wed, 1 May 2013 02:10:12 -0700 (PDT) Received: from localhost ([127.0.0.1]:53865 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXT3D-00089H-5a; Wed, 01 May 2013 11:10: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: Wed, 01 May 2013 09:10:11 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/313#comment:1 Message-ID: <066.e11759a114e89c00de860ab4dcc4f957@trac.tools.ietf.org> References: <051.58ae34f5c17549453dc2b45582e93a3c@trac.tools.ietf.org> X-Trac-Ticket-ID: 313 In-Reply-To: <051.58ae34f5c17549453dc2b45582e93a3c@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: <20130501091012.C3F0021F8E7C@ietfa.amsl.com> Resent-Date: Wed, 1 May 2013 02:10:12 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [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: Wed, 01 May 2013 09:10:13 -0000 #313: Qualify partial discard strategy implementation note: UDP only Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1357]: Fix #313 -- -------------------------+------------------------------------------------- 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 May 1 04:26: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 EDD0621F896B for ; Wed, 1 May 2013 04:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emQihzqAJIgb for ; Wed, 1 May 2013 04:26:50 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5169421F884F for ; Wed, 1 May 2013 04:26:49 -0700 (PDT) Received: from localhost ([127.0.0.1]:35483 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXVBP-0001Xv-TU; Wed, 01 May 2013 13:26: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: Wed, 01 May 2013 11:26:47 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/319#comment:1 Message-ID: <066.6308c58f440ad3ec2e556228c31fc2f1@trac.tools.ietf.org> References: <051.40d5fedc31546d4a0bcb879a368974cd@trac.tools.ietf.org> X-Trac-Ticket-ID: 319 In-Reply-To: <051.40d5fedc31546d4a0bcb879a368974cd@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: <20130501112650.5169421F884F@ietfa.amsl.com> Resent-Date: Wed, 1 May 2013 04:26:49 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [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: Wed, 01 May 2013 11:26:51 -0000 #319: Point out that requests and responses don't always come in pairs Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1358]: Fix #319 -- I actually found a useful way to say this in 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-15 Severity: Submitted | Resolution: fixed WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Wed May 1 04:38:10 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B6B21F8607 for ; Wed, 1 May 2013 04:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 j0Ec-CkK+ORL for ; Wed, 1 May 2013 04:38: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 46A7521F870F for ; Wed, 1 May 2013 04:38:09 -0700 (PDT) Received: from localhost ([127.0.0.1]:35993 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXVMN-0006mv-FN; Wed, 01 May 2013 13:38: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: Wed, 01 May 2013 11:38:07 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/315#comment:1 Message-ID: <066.3d9ff6e6a93b7652fa398018864f16df@trac.tools.ietf.org> References: <051.592cf9722b44f472940a68fdeac17899@trac.tools.ietf.org> X-Trac-Ticket-ID: 315 In-Reply-To: <051.592cf9722b44f472940a68fdeac17899@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: <20130501113809.46A7521F870F@ietfa.amsl.com> Resent-Date: Wed, 1 May 2013 04:38:09 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [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: Wed, 01 May 2013 11:38:10 -0000 #315: Point out security consideration around coap(s) URIs and access control Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1359]: Fix #315 -- -------------------------+------------------------------------------------- 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 May 1 04:42: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 E0C3821F8733 for ; Wed, 1 May 2013 04:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 WdzorwZm2HQd for ; Wed, 1 May 2013 04:42: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 2F4F821F8673 for ; Wed, 1 May 2013 04:42:02 -0700 (PDT) Received: from localhost ([127.0.0.1]:36155 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXVQ8-0006cX-H7; Wed, 01 May 2013 13:42: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: Wed, 01 May 2013 11:42:00 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/312#comment:1 Message-ID: <066.84b5ba8bdf79921fb9e621c5266c8e1b@trac.tools.ietf.org> References: <051.9cbcb77aad3ab5af70308fe0461dd019@trac.tools.ietf.org> X-Trac-Ticket-ID: 312 In-Reply-To: <051.9cbcb77aad3ab5af70308fe0461dd019@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: <20130501114202.2F4F821F8673@ietfa.amsl.com> Resent-Date: Wed, 1 May 2013 04:42:02 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [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: Wed, 01 May 2013 11:42:03 -0000 #312: Discuss spoofing ACKs Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1360]: Fix #312 -- -------------------------+------------------------------------------------- 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 May 1 05:02: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 A4FEB21F8613 for ; Wed, 1 May 2013 05:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 3gqik4PbW11X for ; Wed, 1 May 2013 05:02: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 8404B21F89AF for ; Wed, 1 May 2013 05:02:52 -0700 (PDT) Received: from localhost ([127.0.0.1]:38042 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXVkI-00073z-Ha; Wed, 01 May 2013 14:02:50 +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, 01 May 2013 12:02:50 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/311#comment:1 Message-ID: <066.5dfc9162d0757e444223ea148096e1b3@trac.tools.ietf.org> References: <051.7719f3e037df1610b65b3c8afa6cc970@trac.tools.ietf.org> X-Trac-Ticket-ID: 311 In-Reply-To: <051.7719f3e037df1610b65b3c8afa6cc970@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: <20130501120252.8404B21F89AF@ietfa.amsl.com> Resent-Date: Wed, 1 May 2013 05:02:52 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [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: Wed, 01 May 2013 12:02:55 -0000 #311: Selecting a token length for anti-spoofing Comment (by cabo@tzi.org): From [1361]: More information about randomness in tokens, see #311 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: other | Status: new technical | Milestone: post-IESG-1 Priority: critical | Version: coap-15 Component: coap | Resolution: Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From cabo@tzi.org Wed May 1 05:15: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 3B2FA21F912C for ; Wed, 1 May 2013 05:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.232 X-Spam-Level: X-Spam-Status: No, score=-106.232 tagged_above=-999 required=5 tests=[AWL=0.017, 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 c8k6KVJuru1r for ; Wed, 1 May 2013 05:15: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 CB42121F91B0 for ; Wed, 1 May 2013 05:14: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 r41CEvPa016902 for ; Wed, 1 May 2013 14:14:57 +0200 (CEST) Received: from [192.168.217.105] (p5489335C.dip0.t-ipconnect.de [84.137.51.92]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A8A863165; Wed, 1 May 2013 14:14:57 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 1 May 2013 14:14:56 +0200 To: " (core@ietf.org)" Message-Id: <67E035B3-0C25-4D7E-96CD-31265ACA9B27@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [core] Randomness in Tokens for anti-spoofing (#311) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 12:15:07 -0000 Experience with DNS shows that UDP-based protocols have to spend some = effort protecting against spoofing ("Kaminsky attack"). Both Stephen's and Richard's IESG comments have pointed out that we = don't really help implementers determine good sizes of the Token in = order to provide anti-spoofing properties. In response to this, the current editor draft [1361] says (penultimate = paragraph of 5.3.1): A client sending a request without using transport layer security (Section 9) SHOULD use a non-trivial, randomized token to guard against spoofing of responses (Section 11.4). This protective use of tokens is the reason they are allowed to be up to 8 bytes in size. The actual size of the random component to be used for the Token depends on the security requirements of the client and the level of threat posed by spoofing of responses. A client that is connected to the general Internet SHOULD use at least 32 bits of randomness; keeping in mind that not being directly connected to the Internet is not necessarily sufficient protection against spoofing. (Note that the Message ID adds little in protection as it is usually sequentially assigned, i.e. guessable, and can be circumvented by spoofing a separate response.) Clients that want to optimize the Token length may further want to detect the level of ongoing attacks (e.g., by tallying recent Token mismatches in incoming messages) and adjust the Token length upwards appropriately. [RFC4086] discusses randomness requirements for security. The "at least 32 bits" may seem arbitrary. My motivation: -- The Kaminsky attack has shown that 16 bits is barely enough, even if = suitably random; -- Those who really need more than 32 bits should be using DTLS or are = at least aware of their special security requirements (that's why we say = "at least"). (One could argue that "at least 24 bits" or even "at least 24 to 32 = bits" can also be defended on this basis.) This is an actual technical change, even though it won't impact = interoperability. Before I close #311, I'd really like to hear feedback from the WG = whether the choices here are sensible. Gr=FC=DFe, Carsten From paduffy@cisco.com Wed May 1 05:37: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 9C69421F99F8 for ; Wed, 1 May 2013 05:37:44 -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 XESrgn+xURER for ; Wed, 1 May 2013 05:37:39 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 18E2821F84F2 for ; Wed, 1 May 2013 05:36:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=978; q=dns/txt; s=iport; t=1367411813; x=1368621413; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ARDCHcbHG1mM7ZD78x9vDF0xKsK4xXlJ2+j+w6aCWdE=; b=E6BzeM7E2tUxNsTS5nPBCcwn9P1Xz/Gw92zqUouqsCQApi49sjN1ZQBr xXgoFcgv0I7A7PdPBtALvmclbewzMKXt5RsFgQ5PHz43k6xyjcy5Nb8pF m3mBT2Q6wVQBurwFJGJrYemCUK6OaT5lQ1fDxOxriakCtJI6e82QG7am7 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEFAAIMgVGtJXG9/2dsb2JhbABSgweDJrwnfRZ0gh8BAQEDATIBBUABEAsOCgkWDwkDAgECAUUGDQEFAgEBF4drBr8WjxkHg1ADlyaGE4sagykg X-IronPort-AV: E=Sophos;i="4.87,588,1363132800"; d="scan'208";a="205250743" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 01 May 2013 12:36:52 +0000 Received: from [10.86.255.176] ([10.86.255.176]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r41CapqR019074; Wed, 1 May 2013 12:36:52 GMT Message-ID: <51810C63.7050606@cisco.com> Date: Wed, 01 May 2013 08:36:51 -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: Carsten Bormann 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> <09EED999-F760-4D0B-BD15-DEC6FA50F1CE@tzi.org> In-Reply-To: <09EED999-F760-4D0B-BD15-DEC6FA50F1CE@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: core@ietf.org 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: Wed, 01 May 2013 12:37:44 -0000 On 4/30/2013 6:37 PM, Carsten Bormann wrote: > 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: Its you ;) > >> Lifeboats are likely to prove challenging to support within an ocean cruise. For this reason, the Titanic avoids them. You have the ocean part correct, but you are not sitting on the Titanic. You are on a 16' Sears aluminum skiff with a 2 hp outboard, and a 5 gallon fuel tank. Bon voyage! You are often not going to be able to use the usual set of certificate management mechanisms for IoT as you can for enterprise or consumer computing. I can't say more than that just yet, SEP2 is working a solution. > (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üße, Carsten > > From hannes.tschofenig@gmx.net Wed May 1 06:36: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 A8F1221F9E5E for ; Wed, 1 May 2013 06:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQ2ZhVsB4Qof for ; Wed, 1 May 2013 06:35:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 92D1821F9E56 for ; Wed, 1 May 2013 06:35:50 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.35]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MSXbW-1Uz8kr1p2a-00RWVa for ; Wed, 01 May 2013 15:35:49 +0200 Received: (qmail invoked by alias); 01 May 2013 13:35:49 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp035) with SMTP; 01 May 2013 15:35:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19rdiw/WJtrYjZUFGpLzNUEy6cEf1qv7fQS4Uotb2 cckSolOK50IFQn Message-ID: <51811A2E.10100@gmx.net> Date: Wed, 01 May 2013 16:35:42 +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: Carsten Bormann 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> <09EED999-F760-4D0B-BD15-DEC6FA50F1CE@tzi.org> In-Reply-To: <09EED999-F760-4D0B-BD15-DEC6FA50F1CE@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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 13:36:06 -0000 On 05/01/2013 01:37 AM, Carsten Bormann wrote: >>OCSP and CRLs are likely to prove challenging to support within an LLN environment. For this reason, Zigbee IP avoids them. So, what is the story Zigbee IP provides? No revocation checking? From d.sturek@att.net Wed May 1 07:09:51 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C522121F9402 for ; Wed, 1 May 2013 07:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RN31HWInyRA for ; Wed, 1 May 2013 07:09:46 -0700 (PDT) Received: from nm27.access.bullet.mail.mud.yahoo.com (nm27.access.bullet.mail.mud.yahoo.com [66.94.237.92]) by ietfa.amsl.com (Postfix) with ESMTP id A1A8D21F93E2 for ; Wed, 1 May 2013 07:09:46 -0700 (PDT) Received: from [66.94.237.192] by nm27.access.bullet.mail.mud.yahoo.com with NNFMP; 01 May 2013 14:09:46 -0000 Received: from [98.138.104.97] by tm3.access.bullet.mail.mud.yahoo.com with NNFMP; 01 May 2013 14:09:46 -0000 Received: from [127.0.0.1] by smtp117.sbc.mail.ne1.yahoo.com with NNFMP; 01 May 2013 14:09:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1367417386; bh=Ilg7+esPq1NhWt9ld/zfpvwRc4a1pu+n/tvczLcNiS8=; 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=FuY/DhqMuRO6WxUuvLQy2R5DFL+StpUUSutYKyqrFUTeb6DzgQD+lr0fyB8KvsGCI7TIKck3eBMAJ2awEg6rrYqUld0abCrT43wCme81nuUo8vpFd17iv+akylwVXuPgXcMQDIH1FN7O5WdFeg3GCUaHjsJk23WmRAF4azTW6nI= X-Yahoo-Newman-Id: 329458.80790.bm@smtp117.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Iy1nkVwVM1kLiWnZPaSbX5W9olsnxiqALbLNHSd3yGuv_o8 iyluXXCp33B18OWfldRkIc_k.HCc2nYjgELYtQxFf3tPKFV523Rt5UetNMFl TZNFdb7liUaSnm2Sa4mJN_DHho7itNGMvfrWtXm5AL.19uHeNA.TiYIs_3Sb DrT5XQy6FLY.aF0ypGNm8px9R8U7cyH0LGl_MghdAdvizsrNxEmLQM0VF.II TuJLlDi03TCm.jzfxX8kJyudRVEzkO9TyWQ5qRvkVVDMcMu_g3KmoliaCc_b POU0JwW9wcot8fuEQbI0mh4a9k6h3qrEfs2K9Bct31BWrF1dxtFdEFhqo4m7 fPISPqgiwxfvgva4TA_R6tS.2hShCDQ0qoLNnfmV1a8Dp58eow_HuTBac97S w8yea8vlARoc7vY8DP35kgyqC7dLeOGTzfeCaGADXZVlD1FaBD.I17SALie. xMXAjxKl906c262lZ X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [192.168.0.198] (d.sturek@69.108.51.82 with login) by smtp117.sbc.mail.ne1.yahoo.com with SMTP; 01 May 2013 14:09:46 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.2.130206 Date: Wed, 01 May 2013 07:08:29 -0700 From: Don Sturek To: Hannes Tschofenig , Carsten Bormann Message-ID: Thread-Topic: [core] Certificate mode in -16 In-Reply-To: <51811A2E.10100@gmx.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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 14:09:51 -0000 Hi Hannes, ZigBee IP does not support OCSP, however, we do support blacklisting/whitelisting. Many IoT devices using ZigBee IP do not support update of their certificates, download of new certificates, etc. due to resource limitations. Manufacturers plan to burn in Device Certificates, into devices with 20+ years of lifetime without the ability to change/update certificates. Also, many deployments are in settings without any connectivity to the Internet (imagine a smart appliance purchased into a home without internet access, managed locally by an energy management system). We have created a method to update security (while supporting older devices) but have precluded the use of OCSP for our applications. Don On 5/1/13 6:35 AM, "Hannes Tschofenig" wrote: >On 05/01/2013 01:37 AM, Carsten Bormann wrote: >>>OCSP and CRLs are likely to prove challenging to support within an LLN >>>environment. For this reason, Zigbee IP avoids them. > >So, what is the story Zigbee IP provides? No revocation checking? >_______________________________________________ >core mailing list >core@ietf.org >https://www.ietf.org/mailman/listinfo/core From trac+core@trac.tools.ietf.org Wed May 1 07:19:10 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295F721F9B15 for ; Wed, 1 May 2013 07:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 Isl5FZ2T+s3u for ; Wed, 1 May 2013 07:19: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 32E8521F9B1D for ; Wed, 1 May 2013 07:19:02 -0700 (PDT) Received: from localhost ([127.0.0.1]:46806 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXXs3-0006Qu-6v; Wed, 01 May 2013 16:18: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: Wed, 01 May 2013 14:18:59 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/307#comment:1 Message-ID: <066.fc6335c24e88145c2cb589cbf29a478e@trac.tools.ietf.org> References: <051.aa90bbea462bd49525720f565fc937d9@trac.tools.ietf.org> X-Trac-Ticket-ID: 307 In-Reply-To: <051.aa90bbea462bd49525720f565fc937d9@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: <20130501141904.32E8521F9B1D@ietfa.amsl.com> Resent-Date: Wed, 1 May 2013 07:19:02 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [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: Wed, 01 May 2013 14:19:10 -0000 #307: RFC 2119 usage in 8.2 Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1362]: Minimum change to fix #307 -- -------------------------+------------------------------------------------- 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 May 1 07:24: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 3AE8821F9C87 for ; Wed, 1 May 2013 07:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 SVIk1WIrsxxG for ; Wed, 1 May 2013 07:24: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 9E61721F9C86 for ; Wed, 1 May 2013 07:24:10 -0700 (PDT) Received: from localhost ([127.0.0.1]:47202 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXXx2-00074k-W9; Wed, 01 May 2013 16:24: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: Wed, 01 May 2013 14:24:08 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/306#comment:1 Message-ID: <066.2bcfee1c231ddd218f421399961ea470@trac.tools.ietf.org> References: <051.a9a9c933046ce717a5f65ae69eb46e5e@trac.tools.ietf.org> X-Trac-Ticket-ID: 306 In-Reply-To: <051.a9a9c933046ce717a5f65ae69eb46e5e@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: <20130501142410.9E61721F9C86@ietfa.amsl.com> Resent-Date: Wed, 1 May 2013 07:24:10 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [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: Wed, 01 May 2013 14:24:11 -0000 #306: RFC 2119 usage in 4.5 Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1363]: Use RFC2119 properly in 4.5, fix #306 -- -------------------------+------------------------------------------------- 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 May 1 08:15: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 990E721F974D for ; Wed, 1 May 2013 08:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 KaPyWiJr93F1 for ; Wed, 1 May 2013 08:15: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 65F1421F972C for ; Wed, 1 May 2013 08:15:19 -0700 (PDT) Received: from localhost ([127.0.0.1]:50692 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXYkV-0002m0-RD; Wed, 01 May 2013 17:15: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-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Wed, 01 May 2013 15:15:15 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/305#comment:1 Message-ID: <066.4c7627024a5bf81618134558f09d9684@trac.tools.ietf.org> References: <051.5bed01198eb0fab04aa653806903cbc7@trac.tools.ietf.org> X-Trac-Ticket-ID: 305 In-Reply-To: <051.5bed01198eb0fab04aa653806903cbc7@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: <20130501151519.65F1421F972C@ietfa.amsl.com> Resent-Date: Wed, 1 May 2013 08:15:19 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [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: Wed, 01 May 2013 15:15:34 -0000 #305: Don't use decimal response codes, keep the 3+5 structure throughout Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1364]: Fix #305 -- -------------------------+------------------------------------------------- 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 May 1 08:32: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 0B7DC21F9892 for ; Wed, 1 May 2013 08:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 7qZL75jdCCS4 for ; Wed, 1 May 2013 08:32: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 54CB421F9885 for ; Wed, 1 May 2013 08:32:04 -0700 (PDT) Received: from localhost ([127.0.0.1]:51474 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXZ0j-0005hM-E2; Wed, 01 May 2013 17:32: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, cabo@tzi.org X-Trac-Project: core Date: Wed, 01 May 2013 15:32:01 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/308#comment:1 Message-ID: <066.8be671952f6c92382ca6b40edb51e124@trac.tools.ietf.org> References: <051.da8ada320410274d951a579e32b1c800@trac.tools.ietf.org> X-Trac-Ticket-ID: 308 In-Reply-To: <051.da8ada320410274d951a579e32b1c800@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: <20130501153204.54CB421F9885@ietfa.amsl.com> Resent-Date: Wed, 1 May 2013 08:32:04 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [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: Wed, 01 May 2013 15:32:05 -0000 #308: Make sure all protocol reactions to reserved or prohibited values are defined Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1365]: Fix #308 -- -------------------------+------------------------------------------------- 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 cabo@tzi.org Wed May 1 08:58:19 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602CE21F9891 for ; Wed, 1 May 2013 08:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.007 X-Spam-Level: X-Spam-Status: No, score=-106.007 tagged_above=-999 required=5 tests=[AWL=-0.210, 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 cndXqIWv0aIA for ; Wed, 1 May 2013 08:58:13 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE7E21F988F for ; Wed, 1 May 2013 08:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r41FwAxO012310 for ; Wed, 1 May 2013 17:58:10 +0200 (CEST) Received: from [192.168.217.105] (p5489335C.dip0.t-ipconnect.de [84.137.51.92]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7492E31DD; Wed, 1 May 2013 17:58:10 +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: <13D00776-0E41-4BE0-9068-756C599CCD68@tzi.org> Date: Wed, 1 May 2013 17:58:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9F500BEF-93BB-48AA-9FE4-786C0464E74E@tzi.org> References: <13D00776-0E41-4BE0-9068-756C599CCD68@tzi.org> To: "core@ietf.org (core@ietf.org)" X-Mailer: Apple Mail (2.1503) Subject: Re: [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: Wed, 01 May 2013 15:58:19 -0000 After about 60 SVN commits, covering all the IESG comments that led to = changes in the document, I now believe -16 is ready to submit. Thank you for all the help and the feedback I received. I'm still very open for more feedback on: -- #311 selecting a token length ("Randomness in tokens") -- #317 OCSP stapling/cert status request -- #320 Need for Unicode normalization (see the respective recent threads), but I think all three are covered = well now. To give the Europeans a chance to recover from the very nice Vappu/May = day weather and the Americans a chance to wake up, I'll wait until 2000Z = before submitting -16. Gr=FC=DFe, Carsten From zach@sensinode.com Wed May 1 11:18: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 2F4AC21F98E8 for ; Wed, 1 May 2013 11:18:22 -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 nhkjizfu6eYp for ; Wed, 1 May 2013 11:18:18 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id BEFCF21F98E5 for ; Wed, 1 May 2013 11:18:17 -0700 (PDT) Received: from [192.168.1.102] (188-67-125-230.bb.dnainternet.fi [188.67.125.230]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r41IICU0031324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 May 2013 21:18:14 +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: Wed, 1 May 2013 21:18:12 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8E625FEA-EBEE-4AC8-B17E-1B5644AB0062@sensinode.com> References: <61F5D3B1-0923-4295-933A-E8F448A37062@tzi.org> <15A2B96F-25E1-4262-AA54-F4BB520A0551@sensinode.com> <6E3722B6-A66C-4C3A-9CF1-DB2C58903F21@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 18:18:22 -0000 On May 1, 2013, at 12:32 AM, "Rahman, Akbar" = wrote: > How about something like this? >=20 >=20 > 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. Looks good, I now included this in [1367]. 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 Wed May 1 13:07: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 958EF21F98E0 for ; Wed, 1 May 2013 13:07:34 -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 PfBOp3FgQHwT for ; Wed, 1 May 2013 13:07:34 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id EC54B21F9724 for ; Wed, 1 May 2013 13:07:33 -0700 (PDT) Received: from localhost ([127.0.0.1]:43234 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXdJH-0001yZ-AS; Wed, 01 May 2013 22:07:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Wed, 01 May 2013 20:07:27 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/311#comment:2 Message-ID: <066.92ad68313e4d1bab8f8dcc306e1883d4@trac.tools.ietf.org> References: <051.7719f3e037df1610b65b3c8afa6cc970@trac.tools.ietf.org> X-Trac-Ticket-ID: 311 In-Reply-To: <051.7719f3e037df1610b65b3c8afa6cc970@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: <20130501200733.EC54B21F9724@ietfa.amsl.com> Resent-Date: Wed, 1 May 2013 13:07:33 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [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: Wed, 01 May 2013 20:07:34 -0000 #311: Selecting a token length for anti-spoofing Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in -16. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: other | Status: closed technical | Milestone: post-IESG-1 Priority: critical | Version: coap-15 Component: coap | Resolution: fixed Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Wed May 1 13:08: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 3B4A621F98E8 for ; Wed, 1 May 2013 13:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 cTNgfir4d+Cq for ; Wed, 1 May 2013 13:08: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 EDA4921F98E0 for ; Wed, 1 May 2013 13:08:03 -0700 (PDT) Received: from localhost ([127.0.0.1]:43239 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXdJq-0007FA-KR; Wed, 01 May 2013 22:08:02 +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, 01 May 2013 20:08:02 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/320#comment:2 Message-ID: <066.9c14e484ea99294c5c0c379bed0e75aa@trac.tools.ietf.org> References: <051.0bcb9e2128c0ec3f50de6841ac1a2dfd@trac.tools.ietf.org> X-Trac-Ticket-ID: 320 In-Reply-To: <051.0bcb9e2128c0ec3f50de6841ac1a2dfd@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: <20130501200803.EDA4921F98E0@ietfa.amsl.com> Resent-Date: Wed, 1 May 2013 13:08:03 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: 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 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, 01 May 2013 20:08:06 -0000 #320: Nail down who does Unicode normalization when (or not) Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in -16 -- -------------------------+------------------------------------------------- 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 Wed May 1 13:08: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 3230C21F98E8 for ; Wed, 1 May 2013 13:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 isPhfyGwiQpz for ; Wed, 1 May 2013 13:08: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 B480C21F99A1 for ; Wed, 1 May 2013 13:08:34 -0700 (PDT) Received: from localhost ([127.0.0.1]:43245 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UXdKK-0000nZ-Ja; Wed, 01 May 2013 22:08: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-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Wed, 01 May 2013 20:08:32 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/317#comment:3 Message-ID: <066.67c367adb0b23799b6f77ea6c15ab1e7@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: <20130501200835.B480C21F99A1@ietfa.amsl.com> Resent-Date: Wed, 1 May 2013 13:08:34 -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: Wed, 01 May 2013 20:08:46 -0000 #317: Point out OCSP stapling (TLS Certificate Status Request) as a viable way to get cert status info on a constrained node Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in -16 -- -------------------------+------------------------------------------------- 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 internet-drafts@ietf.org Wed May 1 13:14: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 C1BB521F9AF2; Wed, 1 May 2013 13:14:47 -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 zs9Ibuv9o3WZ; Wed, 1 May 2013 13:14:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3807821F9ADD; Wed, 1 May 2013 13:14:47 -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.44.p4 Message-ID: <20130501201447.29976.24544.idtracker@ietfa.amsl.com> Date: Wed, 01 May 2013 13:14:47 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-16.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 20:14:47 -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-16.txt Pages : 117 Date : 2013-05-01 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 is designed to easily interface 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-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-coap-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed May 1 13:14: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 51EAA21F9AFF for ; Wed, 1 May 2013 13:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.491 X-Spam-Level: X-Spam-Status: No, score=-101.491 tagged_above=-999 required=5 tests=[AWL=-1.110, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GVUGEDGPcv1; Wed, 1 May 2013 13:14:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6528521F9AE2; Wed, 1 May 2013 13:14:47 -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, presnick@qti.qualcomm.com, stephen.farrell@cs.tcd.ie, martin.stiemerling@neclab.eu, rlb@ipv.sx X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130501201447.29976.16731.idtracker@ietfa.amsl.com> Date: Wed, 01 May 2013 13:14:47 -0700 Subject: [core] New Version Notification - draft-ietf-core-coap-16.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 20:14:48 -0000 A new version (-16) has been submitted for draft-ietf-core-coap: http://www.ietf.org/internet-drafts/draft-ietf-core-coap-16.txt 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-16 IETF Secretariat. From hannes.tschofenig@gmx.net Thu May 2 10:44: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 6045621F8F0E for ; Thu, 2 May 2013 10:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.411 X-Spam-Level: X-Spam-Status: No, score=-102.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 cM5TPaKKMYJ8 for ; Thu, 2 May 2013 10:44:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1E721F8D90 for ; Thu, 2 May 2013 10:44:50 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.24]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MKwO6-1UXxYn08G0-0008HL for ; Thu, 02 May 2013 19:44:49 +0200 Received: (qmail invoked by alias); 02 May 2013 17:44:48 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp024) with SMTP; 02 May 2013 19:44:48 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18n3JE5L1EnUMIQdX1tkegMwod1G53JF265l0HIq4 OIa+E4WNjDLwrJ Message-ID: <5182A609.8020208@gmx.net> Date: Thu, 02 May 2013 20:44:41 +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: Don Sturek References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: core@ietf.org 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: Thu, 02 May 2013 17:44:57 -0000 Hi Don, interesting. I guess problems like with DigiNotar, TurkTrust, or Comodo should better not happen with these devices... I was told that there is a fairly deep certificate hierarchy envisioned in the ZigBee IP specs and I am curious whether this is indeed the case. Ciao Hannes On 05/01/2013 05:08 PM, Don Sturek wrote: > Hi Hannes, > > ZigBee IP does not support OCSP, however, we do support > blacklisting/whitelisting. > > Many IoT devices using ZigBee IP do not support update of their > certificates, download of new certificates, etc. due to resource > limitations. Manufacturers plan to burn in Device Certificates, into > devices with 20+ years of lifetime without the ability to change/update > certificates. Also, many deployments are in settings without any > connectivity to the Internet (imagine a smart appliance purchased into a > home without internet access, managed locally by an energy management > system). > > We have created a method to update security (while supporting older > devices) but have precluded the use of OCSP for our applications. > > Don > > > On 5/1/13 6:35 AM, "Hannes Tschofenig" wrote: > >> On 05/01/2013 01:37 AM, Carsten Bormann wrote: >>>> OCSP and CRLs are likely to prove challenging to support within an LLN >>>> environment. For this reason, Zigbee IP avoids them. >> >> So, what is the story Zigbee IP provides? No revocation checking? >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > > From hannes.tschofenig@gmx.net Thu May 2 10:48:53 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F90721F8EDA for ; Thu, 2 May 2013 10:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 d4grxlnx7xXH for ; Thu, 2 May 2013 10:48:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3063D21F91B1 for ; Thu, 2 May 2013 10:48:47 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MFfRr-1UmVw30ReP-00EehI for ; Thu, 02 May 2013 19:48:46 +0200 Received: (qmail invoked by alias); 02 May 2013 17:48:45 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp027) with SMTP; 02 May 2013 19:48:45 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+PAAQDwASPRCHIlB0u/Rvwo4VR6igyzjx6JI73Gc tBegCCMcHNbOAz Message-ID: <5182A6F5.4060709@gmx.net> Date: Thu, 02 May 2013 20:48:37 +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: <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> <9F27AD0B-AC50-42C4-936F-34533F97674E@sensinode.com> In-Reply-To: <9F27AD0B-AC50-42C4-936F-34533F97674E@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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: Thu, 02 May 2013 17:48:53 -0000 Hi Zach, Hi Paul, are you planning to use the same certificate with the device identifiers for application layer protocols (like CoAP) and for network access authentication (in an EAP method)? Ciao Hannes 05/01/2013 09:24 AM, Zach Shelby wrote: > 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. >> >> 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? > > Zach > From cabo@tzi.org Thu May 2 11:11: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 1311921F901D for ; Thu, 2 May 2013 11:11:51 -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 U-8+iOAXQfoi for ; Thu, 2 May 2013 11:11: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 F3E4821F900C for ; Thu, 2 May 2013 11:11: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 r42IBcmQ014257 for ; Thu, 2 May 2013 20:11:38 +0200 (CEST) Received: from [192.168.217.105] (p54893001.dip0.t-ipconnect.de [84.137.48.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 14CB239F1; Thu, 2 May 2013 20:11:38 +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: Date: Thu, 2 May 2013 20:11:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3DE60FEA-5117-434B-A837-E2447433AD7E@tzi.org> References: To: "core@ietf.org (core@ietf.org)" X-Mailer: Apple Mail (2.1503) 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, 02 May 2013 18:11:51 -0000 Additional question to implementers of this ciphersuite: What hash are you using to hash the signed parameters of the server key = exchange? RFC 4492 says: ServerKeyExchange.signed_params.sha_hash SHA(ClientHello.random + ServerHello.random + ServerKeyExchange.params); ... ...SHA in the above template for sha_hash accordingly may denote a hash algorithm other than SHA-1.=20 I would expect that we are using SHA-256 here. Gr=FC=DFe, Carsten From d.sturek@att.net Thu May 2 11:19: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 65DC221F8EA5 for ; Thu, 2 May 2013 11:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 2sSsUTD0C71t for ; Thu, 2 May 2013 11:19:52 -0700 (PDT) Received: from nm20-vm0.access.bullet.mail.sp2.yahoo.com (nm20-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6204521F8E84 for ; Thu, 2 May 2013 11:19:52 -0700 (PDT) Received: from [98.139.44.103] by nm20.access.bullet.mail.sp2.yahoo.com with NNFMP; 02 May 2013 18:19:52 -0000 Received: from [98.138.84.174] by tm8.access.bullet.mail.sp2.yahoo.com with NNFMP; 02 May 2013 18:19:52 -0000 Received: from [127.0.0.1] by smtp108.sbc.mail.ne1.yahoo.com with NNFMP; 02 May 2013 18:19:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1367518792; bh=rnnRdnah0FP/BCgWXSCndBhWOpB9/WgvK1LuW3bnwhM=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=Z1M/SfJRMnzmVystBnPDj9FdEfqCSl0eP8RmVa0830omUPZjWLZGhugZdO+e1TZMloMQDn8LqFaP44Bc5/E/EL7aDv20TvskDVrk6+xcLHA5LDWV3JhXKz0PzGPAORmePAWX6TMj4GXUESeU6k1Ac0I22ei9Va/9TU3HupjRsT8= X-Yahoo-Newman-Id: 231712.46858.bm@smtp108.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: OlYTXWQVM1nKhQXKmMqdXngVnuRDudVZjuq8VrYoNSOXkVJ YZRgcUyi_EUqXZltrfms9qWy1NkDdqL1XiTic_m6zlbOFx8d8Ps3llt51wvw MsLLFC4Aergkv5_oKqyT5xlxzCl1IvsVnB4QdNgWuCkil7wKNvhCSlOyyL1F UD2DtU8qkGSAnsKJknXMzXXqkBcBsU9rR2pFvzkA7P2Fr949PMpvqgdEjqcd cEkB83JtCGjDD6qdRER1QYT7wUol7c0YjwxrMz7tevk.eXGT.yLZ6J.8bOGx dyPHedGeTVETHZn36mEXPmSbdNq7nQ4.66L9K.4.6X03ODDdTzKf_FD8O8pb moez507kv2GWB4Cvji8k_tXYBoPEak_dNY7QPpdxOfSFuyQmJV.2pX.bQOM2 RYXi7asKcLDrcy0u4ghgt_DOjfNepA0Ft9XgvDNyvm8c.LJkObBab3CUf.f5 8.D18a8KVWfhroIqM_g-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [192.168.0.198] (d.sturek@69.108.48.201 with login) by smtp108.sbc.mail.ne1.yahoo.com with SMTP; 02 May 2013 11:19:52 -0700 PDT User-Agent: Microsoft-MacOutlook/14.3.2.130206 Date: Thu, 02 May 2013 11:17:19 -0700 From: Don Sturek To: Carsten Bormann , "core@ietf.org (core@ietf.org)" Message-ID: Thread-Topic: [core] TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 In-Reply-To: <3DE60FEA-5117-434B-A837-E2447433AD7E@tzi.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 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, 02 May 2013 18:19:57 -0000 We use SHA-256 in ZigBee IP...... Don On 5/2/13 11:11 AM, "Carsten Bormann" wrote: >Additional question to implementers of this ciphersuite: > >What hash are you using to hash the signed parameters of the server key >exchange? > >RFC 4492 says: > > ServerKeyExchange.signed_params.sha_hash > SHA(ClientHello.random + ServerHello.random + > ServerKeyExchange.params); > >... > ...SHA in the above template for sha_hash accordingly may denote a > hash algorithm other than SHA-1. > >I would expect that we are using SHA-256 here. > >Gr=FC=DFe, Carsten > >_______________________________________________ >core mailing list >core@ietf.org >https://www.ietf.org/mailman/listinfo/core From zach@sensinode.com Thu May 2 12:05: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 DEDCD21F92F4 for ; Thu, 2 May 2013 12:05:17 -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 WyBLdAqDwkVQ for ; Thu, 2 May 2013 12:05:12 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 916ED21F92CD for ; Thu, 2 May 2013 12:05:11 -0700 (PDT) Received: from [192.168.1.102] (188-67-57-26.bb.dnainternet.fi [188.67.57.26]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r42J56Cn029703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 May 2013 22:05:08 +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: <3DE60FEA-5117-434B-A837-E2447433AD7E@tzi.org> Date: Thu, 2 May 2013 22:05:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2556FC8B-6B6F-4777-8A53-A8A906B14244@sensinode.com> References: <3DE60FEA-5117-434B-A837-E2447433AD7E@tzi.org> 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, 02 May 2013 19:05:18 -0000 Yes, we are using SHA-256 in our CoAP solutions with this suite.=20 Zach On May 2, 2013, at 9:11 PM, Carsten Bormann wrote: > Additional question to implementers of this ciphersuite: >=20 > What hash are you using to hash the signed parameters of the server = key exchange? >=20 > RFC 4492 says: >=20 > ServerKeyExchange.signed_params.sha_hash > SHA(ClientHello.random + ServerHello.random + > = ServerKeyExchange.params); >=20 > ... > ...SHA in the above template for sha_hash accordingly may denote a > hash algorithm other than SHA-1.=20 >=20 > I would expect that we are using SHA-256 here. >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From paduffy@cisco.com Thu May 2 12:21: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 50AF821F8D0D for ; Thu, 2 May 2013 12:21:43 -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 UCJUo6Fk7nHk for ; Thu, 2 May 2013 12:21:38 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0600A21F8C69 for ; Thu, 2 May 2013 12:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1043; q=dns/txt; s=iport; t=1367522489; x=1368732089; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Dfy+GRErniI3UxtYkZCActMkYHoO3EFWT9SPj21/ggI=; b=TGTBAtONDR8FA9/97Vccd0namre64y2e8QzwT0NQNC/DcLl6wm4dILkK vkAs8yHBPa6prrg7qixUK/on7KxN6VvSP17bd88FObdKY9rrZUY2lTBB/ oIaRci5jHaQ0D9t2j3aP32J+s9he8CRvJwJfXRFcj9onuypKAOhj5Ey2W 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAP27glGtJXHA/2dsb2JhbABSgwc3gnC8OH8WdIIfAQEBBAEBAS8BBTYKARALDgoJFg8JAwIBAgEVMAYNAQUCAQEXh3EMwVEEjyYHg1MDlyuGFYN6hyODKQ X-IronPort-AV: E=Sophos;i="4.87,597,1363132800"; d="scan'208";a="205783748" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 02 May 2013 19:21:28 +0000 Received: from [161.44.66.125] (printer-xx-00a645.cisco.com [161.44.66.125]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r42JLR47001629; Thu, 2 May 2013 19:21:28 GMT Message-ID: <5182BCB7.4050102@cisco.com> Date: Thu, 02 May 2013 15:21:27 -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: Carsten Bormann References: <3DE60FEA-5117-434B-A837-E2447433AD7E@tzi.org> <2556FC8B-6B6F-4777-8A53-A8A906B14244@sensinode.com> In-Reply-To: <2556FC8B-6B6F-4777-8A53-A8A906B14244@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 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: Thu, 02 May 2013 19:21:43 -0000 IIRC SHA-256 is used for critical infrastructure apps to provide compliance with NSA SuiteB Crypto and/or NIST SP 800-131A. On 5/2/2013 3:05 PM, Zach Shelby wrote: > Yes, we are using SHA-256 in our CoAP solutions with this suite. > > Zach > > On May 2, 2013, at 9:11 PM, Carsten Bormann wrote: > >> Additional question to implementers of this ciphersuite: >> >> What hash are you using to hash the signed parameters of the server key exchange? >> >> RFC 4492 says: >> >> ServerKeyExchange.signed_params.sha_hash >> SHA(ClientHello.random + ServerHello.random + >> ServerKeyExchange.params); >> >> ... >> ...SHA in the above template for sha_hash accordingly may denote a >> hash algorithm other than SHA-1. >> >> I would expect that we are using SHA-256 here. >> >> Grüße, Carsten >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From robert.cragie@gridmerge.com Thu May 2 13:07: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 249FB21F8D2B for ; Thu, 2 May 2013 13:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 yTWQiyw+Yukj for ; Thu, 2 May 2013 13:07:10 -0700 (PDT) Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id 22E6921F8D27 for ; Thu, 2 May 2013 13:07:10 -0700 (PDT) Received: from [176.26.211.2] (helo=[192.168.0.6]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) id 1UXzmV-000515-JK for core@ietf.org; Thu, 02 May 2013 21:07:07 +0100 Message-ID: <5182C76C.20508@gridmerge.com> Date: Thu, 02 May 2013 21:07:08 +0100 From: Robert Cragie Organization: Gridmerge Ltd. 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: <3DE60FEA-5117-434B-A837-E2447433AD7E@tzi.org> <2556FC8B-6B6F-4777-8A53-A8A906B14244@sensinode.com> <5182BCB7.4050102@cisco.com> In-Reply-To: <5182BCB7.4050102@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030303080807060304070008" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [core] TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 20:07:15 -0000 This is a cryptographically signed message in MIME format. --------------ms030303080807060304070008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable TLS 1.2 specifies SHA-256 as the default hash for use with the PRF it=20 defines as well, so it is expedient to use it. Robert On 02/05/2013 20:21, Paul Duffy wrote: > IIRC SHA-256 is used for critical infrastructure apps to provide=20 > compliance with NSA SuiteB Crypto and/or NIST SP 800-131A. > > > On 5/2/2013 3:05 PM, Zach Shelby wrote: >> Yes, we are using SHA-256 in our CoAP solutions with this suite. >> >> Zach >> >> On May 2, 2013, at 9:11 PM, Carsten Bormann wrote: >> >>> Additional question to implementers of this ciphersuite: >>> >>> What hash are you using to hash the signed parameters of the server=20 >>> key exchange? >>> >>> RFC 4492 says: >>> >>> ServerKeyExchange.signed_params.sha_hash >>> SHA(ClientHello.random + ServerHello.random + >>> ServerKeyExchange.params); >>> >>> ... >>> ...SHA in the above template for sha_hash accordingly may denote a= >>> hash algorithm other than SHA-1. >>> >>> I would expect that we are using SHA-256 here. >>> >>> Gr=FC=DFe, Carsten >>> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --------------ms030303080807060304070008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA1MDIyMDA3MDhaMCMGCSqGSIb3DQEJBDEWBBTLd554piW1DhcY5SoZZVYrY6ohEzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBABPjyXmP/ACTsQhjYJatfG0QbQf6//7q92e9m737dmSx5jqG cu8N2/amjCyYf+4SwfZPZjuY4+EW6F2LN+0NOkZgBYrNt9Cu9opqLM51kK3jxzNFrISpwjjo aB5q7YCHWEplhz0UpoNkBbyPrPs5zb8gvgB8jpnks6jBd2xZr4Bb84qy8lX07R1XGx0JApWT jYzYrnHoBMeLOmpWK2JM2HKpUBzjHPOXnQLR5NgHmdTnOUvYJHlOlTGzNpoKOimA5DG9lekr 1wRdg5za7w0UWoKv7LUKV4iWDM5A++I6PM1DQoRzRv+LoIBOL7tZDun3czQMsBhsJmUdUZSb Zc0DeLsAAAAAAAA= --------------ms030303080807060304070008-- From pda@unistra.fr Fri May 3 02:17: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 3A46D21F958A for ; Fri, 3 May 2013 02:17:37 -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 7IANAc-z+DDN for ; Fri, 3 May 2013 02:17:31 -0700 (PDT) Received: from mailhost.u-strasbg.fr (mailhost-v6.u-strasbg.fr [IPv6:2001:660:2402::201:42]) by ietfa.amsl.com (Postfix) with ESMTP id 7120E21F955E for ; Fri, 3 May 2013 02:17:24 -0700 (PDT) Received: from md15.u-strasbg.fr (md15.u-strasbg.fr [130.79.200.204]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id r439Gu0U062621 for ; Fri, 3 May 2013 11:16:57 +0200 (CEST) (envelope-from pda@unistra.fr) Received: from mailserver.u-strasbg.fr (ms18.u-strasbg.fr [130.79.204.118]) by md15.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id r439GtTm014916 for ; Fri, 3 May 2013 11:16:56 +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 r439GsKW017241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 3 May 2013 11:16:54 +0200 (envelope-from pda@unistra.fr) Date: Fri, 3 May 2013 11:16:54 +0200 From: Pierre DAVID To: core@ietf.org Message-ID: <20130503091654.GA25554@vagabond.ma.maison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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.42]); Fri, 03 May 2013 11:16:57 +0200 (CEST) Subject: [core] Understanding problem X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 May 2013 09:17:37 -0000 Hi, I have an understanding problem in draft-ietf-core-coap-16.txt. 4.3 says that NON messages MUST NOT be acknowledged (but they MAY be resetted). => if I receive a NON addressed to the broadcast/multicast address, I understand that I MAY send back a RST message. 4.4 says that message correlation applies to NON messages => if I understand the previous section, the wording of first sentences of first and last paragraphs could be more precise since one can understand that ACK messages can be related to NON messages. => last paragraph implicitely says that NON messages addressed to broadcast/multicast addresses cannot be resetted since they can not be correlated. This is contrary to the first point. Am I right? Thanks in advance for your lights, Pierre From internet-drafts@ietf.org Sun May 5 07:17: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 90BB021F92EF; Sun, 5 May 2013 07:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.428 X-Spam-Level: X-Spam-Status: No, score=-98.428 tagged_above=-999 required=5 tests=[AWL=-2.111, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, HELO_MISMATCH_COM=0.553, RCVD_IN_XBL=3.033, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t09PhlCEjYsJ; Sun, 5 May 2013 07:17:42 -0700 (PDT) Received: from jlonline.com (pip46.ptt.js.cn [61.155.13.222]) by ietfa.amsl.com (Postfix) with SMTP id C45FE21F92EC; Sun, 5 May 2013 07:17:40 -0700 (PDT) Received: from jlonline.com([10.100.0.22]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id jm9551867943; Sun, 05 May 2013 22:23:28 +0800 Received: from mail.ietf.org([12.22.58.30]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id jm4151818908; Thu, 02 May 2013 04:21:39 +0800 Received: from mail.ietf.org([12.22.58.30]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id AISP action; Thu, 02 May 2013 04:21:39 +0800 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6B721F9AE6; Wed, 1 May 2013 13:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1367439289; bh=+iREvqzTXPujRJt3IN3j/mp7T+V8mqlU8XRSn5xuej4=; h=MIME-Version:From:To:Subject:Message-ID:Date:Cc:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=A7J30hO+3fOt6g4JqZOi4EGZ2WT8Pha3H8OaVcdPasWQkVWPVp+SucLVWIUyhSwYX jdgzI8vapJSSx+7XVbsktbv3FAvHh9E6TRGZjVcFELhVCWoYw2GblWBYWsoipWnXmZ qs38fk3vKrjrtiiw0aZGtOZaA/YAj5D0XXqovrzc= X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1BB521F9AF2; Wed, 1 May 2013 13:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zs9Ibuv9o3WZ; Wed, 1 May 2013 13:14:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3807821F9ADD; Wed, 1 May 2013 13:14:47 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130501201447.29976.24544.idtracker@ietfa.amsl.com> Date: Wed, 01 May 2013 13:14:47 -0700 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-Msg-ID: r1B7d74B X-AIMC-AUTH: (null) X-AIMC-MAILFROM: internet-drafts@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-16.txt X-BeenThere: core@ietf.org Reply-To: internet-drafts@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, 05 May 2013 14:17:46 -0000 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 : Constrained Application Protocol (CoAP) Author(s) : Zach Shelby Klaus Hartke Carsten Bormann Filename : draft-ietf-core-coap-16.txt Pages : 117 Date : 2013-05-01 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 is designed to easily interface 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-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From esko.dijk@philips.com Mon May 6 04:16: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 8B0FB21F910D for ; Mon, 6 May 2013 04:16: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 X6pQMD1U3PES for ; Mon, 6 May 2013 04:16:09 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 457DE21F90FC for ; Mon, 6 May 2013 04:16:07 -0700 (PDT) Received: from mail46-ch1-R.bigfish.com (10.43.68.242) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.23; Mon, 6 May 2013 11:16:07 +0000 Received: from mail46-ch1 (localhost [127.0.0.1]) by mail46-ch1-R.bigfish.com (Postfix) with ESMTP id 380C52A09EA; Mon, 6 May 2013 11:16:07 +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: -28 X-BigFish: VPS-28(zz15d6O9251J542Idb82h217bIdd85kzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1155h) Received: from mail46-ch1 (localhost.localdomain [127.0.0.1]) by mail46-ch1 (MessageSwitch) id 1367838917603061_7878; Mon, 6 May 2013 11:15:17 +0000 (UTC) Received: from CH1EHSMHS015.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.241]) by mail46-ch1.bigfish.com (Postfix) with ESMTP id 871A826043F; Mon, 6 May 2013 11:15:17 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 6 May 2013 11:15:17 +0000 Received: from 011-DB3MMR1-020.MGDPHG.emi.philips.com (10.128.28.101) by 011-DB3MMR1-002.MGDPHG.emi.philips.com (10.128.28.52) with Microsoft SMTP Server (TLS) id 14.2.328.11; Mon, 6 May 2013 11:15:16 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.176]) by 011-DB3MMR1-020.MGDPHG.emi.philips.com ([fe80::65e7:4d4c:4c67:daa9%11]) with mapi id 14.02.0328.011; Mon, 6 May 2013 11:15:16 +0000 From: "Dijk, Esko" To: "trac+core@trac.tools.ietf.org" , "draft-ietf-core-coap@tools.ietf.org" , "cabo@tzi.org" Thread-Topic: [core] #311: Selecting a token length for anti-spoofing Thread-Index: AQHORPDf5SUSkkBD4UqWAwcz7MHCu5j4C+rw Date: Mon, 6 May 2013 11:15:15 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C1B602@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <051.7719f3e037df1610b65b3c8afa6cc970@trac.tools.ietf.org> In-Reply-To: <051.7719f3e037df1610b65b3c8afa6cc970@trac.tools.ietf.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [92.69.207.102] 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] #311: Selecting a token length for anti-spoofing X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 May 2013 11:16:14 -0000 Carsten, thanks for your extensive work in editing and 'ticketizing' the IESG commen= ts. My feedback on -- #311 selecting a token length ("Randomness in tokens"= ): the new text you propose seems to me a good solution to the issues that wer= e noted. Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of cor= e issue tracker Sent: Monday, April 29, 2013 17:47 To: draft-ietf-core-coap@tools.ietf.org; cabo@tzi.org Cc: core@ietf.org Subject: [core] #311: Selecting a token length for anti-spoofing #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 Interne= t. (And please note recent instances where 10's of thousands of insecure d= evices 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 t= he 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 stro= nger. The requirement for a randomized token needs to be a MUST, and the = stack SHOULD limit the number of rejected responses (before closing the re= quest) 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 protect= ion that it makes use of: It can choose the token length based on its secu= rity 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 randomiz= ed), 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 exp= erience with that yet. One issue might be correlating incoming non- match= ing 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 to= ken 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 problem= s, 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 _______________________________________________ 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 golnaz.karbaschi@eolane.com Mon May 6 06:33: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 026D221F8EF2 for ; Mon, 6 May 2013 06:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQXaRGSLBBuI for ; Mon, 6 May 2013 06:33:50 -0700 (PDT) Received: from relay.martec.fr (relay.martec.fr [92.103.79.186]) by ietfa.amsl.com (Postfix) with ESMTP id 3430C21F8EED for ; Mon, 6 May 2013 06:33:23 -0700 (PDT) Received: from webmail.martec.fr (unknown [192.168.20.3]) by relay.martec.fr (Postfix) with ESMTP id 8CC5640C04D for ; Mon, 6 May 2013 15:33:12 +0200 (CEST) Received: from CL563 ([192.168.20.158]) by webmail.martec.fr (Lotus Domino Release 8.5) with ESMTP id 2013050615331220-160980 ; Mon, 6 May 2013 15:33:12 +0200 From: "Golnaz KARBASCHI" To: Date: Mon, 6 May 2013 15:33:07 +0200 Organization: =?us-ascii?Q?eolane?= Message-ID: <005e01ce4a5e$413dbf30$c3b93d90$@karbaschi@eolane.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5KXj5kUdS2dEAuSeKqYjmoPLtXpA== X-MIMETrack: Itemize by SMTP Server on srvm1/martec_sevres/FR(Release 8.5|December 05, 2008) at 06/05/2013 15:33:12, Serialize by Router on srvm1/martec_sevres/FR(Release 8.5|December 05, 2008) at 06/05/2013 15:33:12, Serialize complete at 06/05/2013 15:33:12 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01CE4A6F.04C68F30" Content-Language: fr Subject: [core] Running CoAP over a local BLE network X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 May 2013 13:33:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005F_01CE4A6F.04C68F30 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Hello to All , I have a question about running a COAP application instead of GATT based profiles over a local network with BLE (Bluetooth Low Energy) peripherals. The idea of using CoAP is its http friendly characteristics (RESTfull structure) and its lightness for a constrained based network, like BLE. BUT we do not want to have necessarily the end-to-end IP connections all the way on our local network. Supposing to have a BLE local network like the figure below, with a host node for accessing to the exterior connections (such as internet connection) O--- BLE-----O (HOST) --------- > internet O--- BLE-----| O--- BLE-----| My question is that if we don't care running IPV6 all the way to BLE peripherals (and so don't need to implement a 6lowpan layer), is there still any interest to use CoAP? And if we decided to run CoAP instead of existing structures and profiles of BLE, can CoAP in a network without running IPV6 be implemented on BLE as is? How should it be implemented ? Is it correct to say that CoAP will behave just as a new profile for the BLE network? Meaning that L2CAP takes care of adaptation between CoAP and lower layers (MTU adaptation, etc.) and CoAP plays its role to have a http friendly interface for the network ? Thank you in advance if any one that is familiar with BLE or not (!) can give me more information about this question. Golnaz KARBASCHI ------=_NextPart_000_005F_01CE4A6F.04C68F30 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"

Hello to All , =

 

I have a question about running a COAP = application instead of GATT based profiles over a local network with BLE = (Bluetooth Low Energy) peripherals.

The idea of using CoAP is its http = friendly characteristics (RESTfull structure) and its lightness for a = constrained based network, like BLE. BUT we do not want to have = necessarily the end-to-end IP connections all the way on our local = network.  

 

Supposing to have a BLE local network = like the figure below, with a host node for accessing to the exterior = connections (such as internet connection)

O--- BLE-----O (HOST) = ---------  > = internet

O--- BLE-----|

O--- BLE-----|

 

My question is that if we don't care = running IPV6 all the way to BLE peripherals (and so don't need to = implement a 6lowpan layer), is there still any interest to use = CoAP?

 

And if we decided to run CoAP instead = of existing structures and profiles of BLE, can CoAP in a network = without running IPV6 be implemented on BLE as is? How should it be = implemented ?  Is it = correct to say that CoAP will behave just as a new profile for the BLE = network?

Meaning that L2CAP takes = care of adaptation between CoAP and lower layers (MTU adaptation, etc.) = and CoAP plays its role to have a http friendly

interface for the network ?    =

 

Thank you in advance if any one that = is familiar with BLE or not (!) can give me more information about this = question.

 

Golnaz KARBASCHI

 

------=_NextPart_000_005F_01CE4A6F.04C68F30-- From Akbar.Rahman@InterDigital.com Tue May 7 10:30: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 C7B0F21F86E4 for ; Tue, 7 May 2013 10:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 69MC7F20SRaz for ; Tue, 7 May 2013 10:30:32 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 499FC21F93EB for ; Tue, 7 May 2013 10:30:32 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 May 2013 13:30:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CE4B48.9291B01A" Date: Tue, 7 May 2013 13:30:30 -0400 Message-ID: In-Reply-To: <005e01ce4a5e$413dbf30$c3b93d90$@karbaschi@eolane.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Running CoAP over a local BLE network Thread-Index: Ac5KXj5kUdS2dEAuSeKqYjmoPLtXpAA6B5IA References: <005e01ce4a5e$413dbf30$c3b93d90$@karbaschi@eolane.com> From: "Rahman, Akbar" To: "Golnaz KARBASCHI" X-OriginalArrivalTime: 07 May 2013 17:30:31.0249 (UTC) FILETIME=[92C5D410:01CE4B48] Cc: core@ietf.org Subject: Re: [core] Running CoAP over a local BLE network X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 May 2013 17:30:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CE4B48.9291B01A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Golnaz, =20 I am not familiar with BLE, but with regards to your specific question of: =20 "...can CoAP in a network without running IPV6 be implemented on BLE as is?" =20 =20 My response is: * No, you cannot implement CoAP on a network that is not running IPv6 (or IPv4) * CoAP was meant to run on an UDP/IP protocol stack. There are many critical parts of the CoAP protocol that would break if the underlying layers was not UDP/IP. For example: o Using the IPv6 address as a literal in the host part of the URI ( http://tools.ietf.org/html/draft-ietf-core-coap-16#section-5.10.1 ) o Triggering IP multicast ( http://tools.ietf.org/html/draft-ietf-core-coap-16#section-8 ) o Listening on the UDP port number (http://tools.ietf.org/html/draft-ietf-core-coap-16#section-12.7 ) o Etc. =20 =20 So, to repeat, I do not believe that you can run CoAP on a network that does not have IPv6 (or IPv4) underneath. =20 =20 Hope that helps. =20 =20 Best Regards, =20 =20 Akbar =20 From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Golnaz KARBASCHI Sent: Monday, May 06, 2013 9:33 AM To: core@ietf.org Subject: [core] Running CoAP over a local BLE network =20 Hello to All ,=20 =20 I have a question about running a COAP application instead of GATT based profiles over a local network with BLE (Bluetooth Low Energy) peripherals. The idea of using CoAP is its http friendly characteristics (RESTfull structure) and its lightness for a constrained based network, like BLE. BUT we do not want to have necessarily the end-to-end IP connections all the way on our local network. =20 =20 Supposing to have a BLE local network like the figure below, with a host node for accessing to the exterior connections (such as internet connection) O--- BLE-----O (HOST) --------- > internet O--- BLE-----| O--- BLE-----| =20 My question is that if we don't care running IPV6 all the way to BLE peripherals (and so don't need to implement a 6lowpan layer), is there still any interest to use CoAP? =20 =20 And if we decided to run CoAP instead of existing structures and profiles of BLE, can CoAP in a network without running IPV6 be implemented on BLE as is? How should it be implemented ? Is it correct to say that CoAP will behave just as a new profile for the BLE network?=20 Meaning that L2CAP takes care of adaptation between CoAP and lower layers (MTU adaptation, etc.) and CoAP plays its role to have a http friendly interface for the network ? =20 =20 Thank you in advance if any one that is familiar with BLE or not (!) can give me more information about this question. =20 Golnaz KARBASCHI =20 ------_=_NextPart_001_01CE4B48.9291B01A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Golnaz,

 

I am not familiar with = BLE, but with regards to your specific question = of:

 

“…can CoAP in a network without = running IPV6 be implemented on BLE as is?”

 

 

My response = is:

·         = No, you = cannot implement CoAP on a network that is not running IPv6 (or = IPv4)

·         = CoAP was = meant to run on an UDP/IP protocol stack.  There are many critical = parts of the CoAP protocol that would break if the underlying layers was = not UDP/IP.  For example:

o   = Using the = IPv6 address as a literal in the host part of the URI ( http://tools.ietf.org/html/draft-ietf-core-coap-16#section-5.10.1 = )

o   = Triggering = IP multicast ( htt= p://tools.ietf.org/html/draft-ietf-core-coap-16#section-8 = )

o   = Listening = on the UDP port number (= http://tools.ietf.org/html/draft-ietf-core-coap-16#section-12.7 = )

o   = Etc.

 

 

So, to repeat, I do not = believe that you can run CoAP on a network that does not have IPv6 (or = IPv4) underneath.

 

 

Hope that = helps.

 

 

Best = Regards,

 

 

Akbar

 

From:= = core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Golnaz KARBASCHI
Sent: Monday, May 06, 2013 9:33 = AM
To: core@ietf.org
Subject: [core] Running CoAP = over a local BLE network

 

Hello to = All ,

 

I have a question about running a COAP application = instead of GATT based profiles over a local network with BLE (Bluetooth = Low Energy) peripherals.

The idea = of using CoAP is its http friendly characteristics (RESTfull structure) = and its lightness for a constrained based network, like BLE. BUT we do = not want to have necessarily the end-to-end IP connections all the way = on our local network. 

 

Supposing to have a BLE local network like the = figure below, with a host node for accessing to the exterior connections = (such as internet connection)

O--- = BLE-----O (HOST) ---------  = > internet

O--- = BLE-----|

O--- = BLE-----|

 

My question is that if we don't care running IPV6 = all the way to BLE peripherals (and so don't need to implement a 6lowpan = layer), is there still any interest to use CoAP?

 

 

And if = we decided to run CoAP instead of existing structures and profiles of = BLE, can CoAP in a network without running IPV6 be implemented on BLE as = is? How should it be implemented ?  Is it correct to say that CoAP = will behave just as a new profile for the BLE network?

Meaning that L2CAP takes care of adaptation between = CoAP and lower layers (MTU adaptation, etc.) and CoAP plays its role to = have a http friendly

interface for = the network ?   

 

Thank = you in advance if any one that is familiar with BLE or not (!) can give = me more information about this question.

 

Golnaz = KARBASCHI

 

------_=_NextPart_001_01CE4B48.9291B01A-- From internet-drafts@ietf.org Tue May 7 11:44:33 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE2F21F908B; Tue, 7 May 2013 11:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=0.251, 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 mnYC-Tmsr2p1; Tue, 7 May 2013 11:44:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACDF21F905F; Tue, 7 May 2013 11:44:28 -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.44.p7 Message-ID: <20130507184428.13600.42350.idtracker@ietfa.amsl.com> Date: Tue, 07 May 2013 11:44:28 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-07.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, 07 May 2013 18:44:33 -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-07.txt Pages : 36 Date : 2013-05-07 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Akbar.Rahman@InterDigital.com Tue May 7 11: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 ED9FF21F93D6 for ; Tue, 7 May 2013 11:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 8wx-mVus-N3k for ; Tue, 7 May 2013 11:55:25 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 63CFB21F93BB for ; Tue, 7 May 2013 11:55:25 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 May 2013 14:55:23 -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, 7 May 2013 14:55:23 -0400 Message-ID: In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514E9B828@MBX20.d.ethz.ch> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New "application/coap-group+json" Internet Media Type for Group Communication Thread-Index: AQHON3xetyyyB6vlzUqueNFPo/VPjZjdTWywgAT0MACAACRCQIABORUAgAAjCDCAFnaMcA== 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> <55877B3AFB359744BA0F2140E36F52B514E9B828@MBX20.d.ethz.ch> From: "Rahman, Akbar" To: "Carsten Bormann" , "Kovatsch Matthias" , "Zach Shelby" X-OriginalArrivalTime: 07 May 2013 18:55:23.0835 (UTC) FILETIME=[6E30C8B0:01CE4B54] Cc: core@ietf.org Subject: [core] New "application/coap-group+json" Internet Media Type for Group Communication X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 May 2013 18:55:30 -0000 Hi Carsten/Matthias/Zach, Esko and I have taken a stab at defining the new "application/coap-group+json" Internet Media Type for Group Communication in the updated Group Communications draft: http://tools.ietf.org/html/draft-ietf-core-groupcomm-07#section-7 Can you please review and tell us if you agree with this approach? Best Regards, Akbar -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Kovatsch Matthias Sent: Tuesday, April 23, 2013 7:55 AM To: Dijk, Esko Cc: core@ietf.org Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-06.txt Hmm, that is a good point. The problem here lies more in the number registry 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-shared. A generic client would probably be like a Web browser that has plugins for 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=20 > 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=20 > integrate a generic-JSON-viewer-plus- editor that shows the=20 > 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 solution. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Tue May 7 13:16: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 6348221F8B0A for ; Tue, 7 May 2013 13:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396, 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 oKj7eFQwvA66 for ; Tue, 7 May 2013 13:16:24 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 593AA21F8AD5 for ; Tue, 7 May 2013 13:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r47KGIWx025481; Tue, 7 May 2013 22:16:18 +0200 (CEST) Received: from [192.168.16.58] (unknown [91.234.155.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 04D4131F2; Tue, 7 May 2013 22:16:18 +0200 (CEST) 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> <55877B3AFB359744BA0F2140E36F52B514E9B828@MBX20.d.ethz.ch> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (10B329) From: Carsten Bormann Date: Wed, 8 May 2013 00:16:17 +0400 To: "Rahman, Akbar" Cc: "" Subject: Re: [core] New "application/coap-group+json" Internet Media Type for Group Communication X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 May 2013 20:16:29 -0000 hi akbar, i'm in St. Petersburg right now, but will look at it when i'm back next week= , Sent from my iPad On 07.05.2013, at 22:55, "Rahman, Akbar" wro= te: > Hi Carsten/Matthias/Zach, >=20 >=20 > Esko and I have taken a stab at defining the new > "application/coap-group+json" Internet Media Type for Group > Communication in the updated Group Communications draft: >=20 >=20 > http://tools.ietf.org/html/draft-ietf-core-groupcomm-07#section-7 >=20 >=20 >=20 > Can you please review and tell us if you agree with this approach? >=20 >=20 > Best Regards, >=20 >=20 > Akbar >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > Kovatsch Matthias > Sent: Tuesday, April 23, 2013 7:55 AM > To: Dijk, Esko > Cc: core@ietf.org > Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-06.txt >=20 > Hmm, that is a good point. The problem here lies more in the number > registry for the Content-Format, I suppose. > Maybe we should have something similar to option numbers, so that > specific bits indicate a "+json" or "+xml"? >=20 > In general, it is the point, though, that the media types must be > pre-shared. A generic client would probably be like a Web browser that > has plugins for new types or at least can make a lookup in the registry. >=20 > Ciao > Matthias >=20 >> Suppose we define 'application/coap-group+json' for that, the side=20 >> effect is that a client not knowing this specific content-format can't >=20 >> deduce that it is in fact JSON format. (E.g. the client could=20 >> integrate a generic-JSON-viewer-plus- editor that shows the=20 >> 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 > solution. >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 >=20 From cabo@tzi.org Tue May 7 13: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 F03C321F8C69 for ; Tue, 7 May 2013 13:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 Ua09-PKfvFC5 for ; Tue, 7 May 2013 13:22: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 96E3121F8916 for ; Tue, 7 May 2013 13:22: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 r47KM3af005769; Tue, 7 May 2013 22:22:03 +0200 (CEST) Received: from [192.168.16.58] (unknown [91.234.155.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C438731F6; Tue, 7 May 2013 22:22:02 +0200 (CEST) References: <005e01ce4a5e$413dbf30$c3b93d90$@karbaschi@eolane.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-80EB3AC8-A62C-4E19-AF3E-C01B0536387E Message-Id: X-Mailer: iPad Mail (10B329) From: Carsten Bormann Date: Wed, 8 May 2013 00:22:03 +0400 To: "Rahman, Akbar" Cc: "core@ietf.org" , Golnaz KARBASCHI Subject: Re: [core] Running CoAP over a local BLE network X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 May 2013 20:22:12 -0000 --Apple-Mail-80EB3AC8-A62C-4E19-AF3E-C01B0536387E Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable While this (can't run CoAP directly on BLE L2CAP) is true today, we do have p= roposals for various alternative transport bindings (including SMS), so if t= his is a sensible thing to do, we could look into it. On the BLE level, the= obvious choking point is channel allocation. I'd like to understand the us= ecase some more, and build more of an opinion when I'm back in Germany next w= eek...=20 Sent from my iPad On 07.05.2013, at 21:30, "Rahman, Akbar" wro= te: > Hi Golnaz, > =20 > I am not familiar with BLE, but with regards to your specific question of:= > =20 > =93=85can CoAP in a network without running IPV6 be implemented on BLE as i= s?=94 > =20 > =20 > My response is: > =B7 No, you cannot implement CoAP on a network that is not running= IPv6 (or IPv4) > =B7 CoAP was meant to run on an UDP/IP protocol stack. There are m= any critical parts of the CoAP protocol that would break if the underlying l= ayers was not UDP/IP. For example: > o Using the IPv6 address as a literal in the host part of the URI ( http= ://tools.ietf.org/html/draft-ietf-core-coap-16#section-5.10.1 ) > o Triggering IP multicast ( http://tools.ietf.org/html/draft-ietf-core-c= oap-16#section-8 ) > o Listening on the UDP port number (http://tools.ietf.org/html/draft-iet= f-core-coap-16#section-12.7 ) > o Etc. > =20 > =20 > So, to repeat, I do not believe that you can run CoAP on a network that do= es not have IPv6 (or IPv4) underneath. > =20 > =20 > Hope that helps. > =20 > =20 > Best Regards, > =20 > =20 > Akbar > =20 > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Go= lnaz KARBASCHI > Sent: Monday, May 06, 2013 9:33 AM > To: core@ietf.org > Subject: [core] Running CoAP over a local BLE network > =20 > Hello to All , > =20 > I have a question about running a COAP application instead of GATT based p= rofiles over a local network with BLE (Bluetooth Low Energy) peripherals. > The idea of using CoAP is its http friendly characteristics (RESTfull stru= cture) and its lightness for a constrained based network, like BLE. BUT we d= o not want to have necessarily the end-to-end IP connections all the way on o= ur local network.=20 > =20 > Supposing to have a BLE local network like the figure below, with a host n= ode for accessing to the exterior connections (such as internet connection) > O--- BLE-----O (HOST) --------- > internet > O--- BLE-----| > O--- BLE-----| > =20 > My question is that if we don't care running IPV6 all the way to BLE perip= herals (and so don't need to implement a 6lowpan layer), is there still any i= nterest to use CoAP? > =20 > =20 > And if we decided to run CoAP instead of existing structures and profiles o= f BLE, can CoAP in a network without running IPV6 be implemented on BLE as i= s? How should it be implemented ? Is it correct to say that CoAP will behav= e just as a new profile for the BLE network? > Meaning that L2CAP takes care of adaptation between CoAP and lower layers (= MTU adaptation, etc.) and CoAP plays its role to have a http friendly > interface for the network ? =20 > =20 > Thank you in advance if any one that is familiar with BLE or not (!) can g= ive me more information about this question. > =20 > Golnaz KARBASCHI > =20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --Apple-Mail-80EB3AC8-A62C-4E19-AF3E-C01B0536387E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
While this (can't run CoAP directly on= BLE L2CAP) is true today, we do have proposals for various alternative tran= sport bindings (including SMS), so if this is a sensible thing to do, we cou= ld look into it.  On the BLE level, the obvious choking point is channe= l allocation.  I'd like to understand the usecase some more, and build m= ore of an opinion when I'm back in Germany next week... 

Sent fr= om my iPad

On 07.05.2013, at 21:30, "Rahman, Akbar" <Akbar.Rahman@InterDigital.com= > wrote:

Hi Golnaz,

 

=

I am not familiar with B= LE, but with regards to your specific question of:

 

=E2=80=9C=E2=80=A6can C= oAP in a network without running IPV6 be implemented on BLE as is?=E2=80=9D<= span style=3D"color:#1F497D">

 

 

My response is:

<= p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level1 l= fo1">=C2=B7         = No, you cannot imp= lement CoAP on a network that is not running IPv6 (or IPv4)

=C2=B7         <= /span>CoAP was mea= nt to run on an UDP/IP protocol stack.  There are many critical parts o= f the CoAP protocol that would break if the underlying layers was not UDP/IP= .  For example:

o   Using the IPv6 address as a literal in the host part of the U= RI ( http://tools.ietf.org/html/draft-ietf-core-coap-16#section-5.10.1= )

o&n= bsp;  = Triggering IP multicast ( http://tools.ietf.org/html/draft-ietf-core-coap-16#se= ction-8 )

<= span style=3D"mso-list:Ignore">o   Listening on the UDP port number (http://tools.ietf.org/html/dr= aft-ietf-core-coap-16#section-12.7 )

o   Etc.

 

 

So, to repeat, I do not believ= e that you can run CoAP on a network that does not have IPv6 (or IPv4) under= neath.

 

 

Hope that helps.

=  

 

Best Regards,

<= p class=3D"MsoNormal"> =

 

Akbar

 = ;

From: core-bounces@ie= tf.org [mailto:core-bounces@iet= f.org] On Behalf Of Golnaz KARBASCHI
Sent: Monday, May 0= 6, 2013 9:33 AM
To: core@ietf.org=
Subject: [core] Running CoAP over a local BLE network

 

Hello to All ,

=  

I have a question about runni= ng a COAP application instead of GATT based profiles over a local network wi= th BLE (Bluetooth Low Energy) peripherals.

The idea of using CoAP is its http friendly characteristics (RESTfull= structure) and its lightness for a constrained based network, like BLE. BUT= we do not want to have necessarily the end-to-end IP connections all the wa= y on our local network. 

 = ;

Supposing to have a BLE local netw= ork like the figure below, with a host node for accessing to the exterior co= nnections (such as internet connection)

O--- BLE-----O (HOST) ---------&= nbsp; > internet

O--- BLE-----|

O--- BLE-----|

 

My question= is that if we don't care running IPV6 all the way to BLE peripherals (and s= o don't need to implement a 6lowpan layer), is there still any interest to u= se CoAP?

 

 

And if we= decided to run CoAP instead of existing structures and profiles of BLE, can= CoAP in a network without running IPV6 be implemented on BLE as is? How sho= uld it be implemented ?  Is it correct to say that CoAP will behave jus= t as a new profile for the BLE network?

Meaning that L2CAP takes care of adaptation between CoAP and lower laye= rs (MTU adaptation, etc.) and CoAP plays its role to have a http friendly

interface for the network ?  = ; 

 

Thank you in advance if any one that is familiar with BL= E or not (!) can give me more information about this question.

 

Golnaz KARBASCHI

 

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
= --Apple-Mail-80EB3AC8-A62C-4E19-AF3E-C01B0536387E-- From esko.dijk@philips.com Wed May 8 01:35: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 135C321F8506 for ; Wed, 8 May 2013 01:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vv7JSViOREZR for ; Wed, 8 May 2013 01:35:29 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id B586221F8960 for ; Wed, 8 May 2013 01:35:29 -0700 (PDT) Received: from mail60-co9-R.bigfish.com (10.236.132.248) by CO9EHSOBE033.bigfish.com (10.236.130.96) with Microsoft SMTP Server id 14.1.225.23; Wed, 8 May 2013 08:35:28 +0000 Received: from mail60-co9 (localhost [127.0.0.1]) by mail60-co9-R.bigfish.com (Postfix) with ESMTP id BD5102C06BA; Wed, 8 May 2013 08:35:28 +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: -7 X-BigFish: VPS-7(zz15d6O9251Jc85fhdb82h217bIdd85kzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz18c673hz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1155h) Received: from mail60-co9 (localhost.localdomain [127.0.0.1]) by mail60-co9 (MessageSwitch) id 1368002126820245_9943; Wed, 8 May 2013 08:35:26 +0000 (UTC) Received: from CO9EHSMHS017.bigfish.com (unknown [10.236.132.244]) by mail60-co9.bigfish.com (Postfix) with ESMTP id BC11B58004E; Wed, 8 May 2013 08:35:26 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS017.bigfish.com (10.236.130.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 8 May 2013 08:35:26 +0000 Received: from 011-DB3MMR1-015.MGDPHG.emi.philips.com (10.128.28.99) by 011-DB3MMR1-005.MGDPHG.emi.philips.com (10.128.28.55) with Microsoft SMTP Server (TLS) id 14.2.328.11; Wed, 8 May 2013 08:35:10 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.161]) by 011-DB3MMR1-015.MGDPHG.emi.philips.com ([10.128.28.99]) with mapi id 14.02.0328.011; Wed, 8 May 2013 08:35:04 +0000 From: "Dijk, Esko" To: "core (core@ietf.org)" Thread-Topic: HTTP/CoAP default embedded URI mapping: requirements Thread-Index: Ac5LxRKffh+8eXAXRw+5UEqFuHNPMA== Date: Wed, 8 May 2013 08:35:03 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C20FFF@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_031DD135F9160444ABBE3B0C36CED618C20FFF011DB3MPN2082MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] HTTP/CoAP default embedded URI mapping: requirements X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 May 2013 08:35:36 -0000 --_000_031DD135F9160444ABBE3B0C36CED618C20FFF011DB3MPN2082MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, the authors of draft-castellani-core-http-mapping discussed solutions for a= default URI mapping for reverse HTTP-to-CoAP cross-protocol proxies. In ot= her words, how to embed a CoAP URI into a HTTP URI. Because multiple soluti= ons were identified, we decided to draw up some requirements to compare any= solutions that may be proposed. Below is the current list of requirements (roughly from highest importance = to lowest): R1. Syntactic correctness of the HTTP URI (e.g. handle percent-encoding whe= n needed); R2. HTTP URI must be able include all elements of a CoAP URI (e.g. coap(s) scheme, hostname, host literals IPv4/IPv6, port, path, qu= ery components, characters allowed in CoAP URI) R3. The mapping operation must produce a string that can be directly used b= y a proxy as input to the process of core-coap section 6.4. "Decomposing UR= Is into Options". R4. HTTP URI should be easily readable/writable by humans, if possible; (e.g. easy to read the CoAP URI embedded in it; avoid multiple levels o= f percent encoding, etc.) R5. HTTP cache friendliness of the mapping solution, i.e. maximize the cach= ing of CoAP resources by HTTP intermediaries; (e.g. a solution where entire CoAP URI is provided as a single query par= ameter is bad in this respect) R6. Normalised form: preferably there should be only one "normal"/default w= ay to encode the URI (e.g. so that we don't end up with multiple different cache entries for= the same CoAP resource in intermediaries.); R7. HTTP URI should be as short as possible. Any input on these requirements is welcome. We'll send a selection of our p= roposals to the list shortly. Esko & co-authors ________________________________ 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_031DD135F9160444ABBE3B0C36CED618C20FFF011DB3MPN2082MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

the authors of draft-castellani-core-http-mapping di= scussed solutions for a default URI mapping for reverse HTTP-to-CoAP cross-= protocol proxies. In other words, how to embed a CoAP URI into a HTTP URI. = Because multiple solutions were identified, we decided to draw up some requirements to compare any solutions that may = be proposed.

 

Below is the current list of requirements (roughly f= rom highest importance to lowest):

 

R1. Syntactic correctness of the HTTP URI (e.g. hand= le percent-encoding when needed);

 

R2. HTTP URI must be able include all elements of a = CoAP URI

    (e.g. coap(s) scheme, hostna= me, host literals IPv4/IPv6, port, path, query components, characters allow= ed in CoAP URI)

 

R3. The mapping operation must produce a string that= can be directly used by a proxy as input to the process of core-coap secti= on 6.4. "Decomposing URIs into Options".

 

R4. HTTP URI should be easily readable/writable by h= umans, if possible;

    (e.g. easy to read the CoAP URI e= mbedded in it; avoid multiple levels of percent encoding, etc.)

 

R5. HTTP cache friendliness of the mapping solution,= i.e. maximize the caching of CoAP resources by HTTP intermediaries;

   (e.g. a solution where entire CoAP URI = is provided as a single query parameter is bad in this respect)

 

R6. Normalised form: preferably there should be only= one "normal"/default way to encode the URI

    (e.g. so that we don't end up wit= h multiple different cache entries for the same CoAP resource in intermedia= ries.);

 

R7. HTTP URI should be as short as possible.

 

Any input on these requirements is welcome. We’= ;ll send a selection of our proposals to the list shortly.

 

Esko & co-authors

 

 

 


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_031DD135F9160444ABBE3B0C36CED618C20FFF011DB3MPN2082MGDP_-- From carlesgo@entel.upc.edu Wed May 8 01:49:47 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6530F21F8E77 for ; Wed, 8 May 2013 01:49:47 -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 wvzGJkewqyUR for ; Wed, 8 May 2013 01:49:41 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3118721F8E6D for ; Wed, 8 May 2013 01:49:41 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id r488nbpd022967; Wed, 8 May 2013 10:49:38 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 314D92CBD0E; Wed, 8 May 2013 10:49:32 +0200 (CEST) Received: from 95.120.59.189 by webmail.entel.upc.edu with HTTP; Wed, 8 May 2013 10:49:32 +0200 Message-ID: <60acadb5c7fc8630b8d94853086e6cfa.squirrel@webmail.entel.upc.edu> In-Reply-To: References: <005e01ce4a5e$413dbf30$c3b93d90$@karbaschi@eolane.com> Date: Wed, 8 May 2013 10:49:32 +0200 From: "Carles Gomez Montenegro" To: "Golnaz KARBASCHI" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Wed, 08 May 2013 10:49:38 +0200 (CEST) Cc: "core@ietf.org" Subject: Re: [core] Running CoAP over a local BLE network X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 May 2013 08:49:47 -0000 Hi Golnaz, I would also like to know more about the use case. On the side of advantages of your proposal, I understand that you would avoid the (compressed) IPv6 and UDP headers in the transmitted packets. This would save the addition of at least 6/7 bytes to each CoAP layer packet, which would be significant savings. The header overhead including BLE headers would decrease by at least 30% if your CoAP packets (plus IPv6/UDP headers) fit in a single BLE Data Channel PDU (i.e. have a maximum size of 23 bytes). If those packets slightly exceed 23 bytes, the savings would be much greater. Another advantage is that you would avoid as well the implementation of 6LoWPAN/IPv6/UDP. However, the peripherals you mention would miss the opportunity of being Internet citizens. And the hosts in your figure would have to perform some form of protocol translation or adaptation. As Carsten said, another issue would be which L2CAP channel identifier(s) should be used to indicate that the protocol on top of L2CAP is CoAP. Use of L2CAP channel IDs is regulated by the Bluetooth SIG. The IPv6 over BLE draft almost passed IESG, but there is a pending DISCUSS, which will be (hopefully) solved once it is clear which L2CAP channel identifier(s) can be used for IPv6. Fortunately, the Bluetooth SIG found it worth to launch a working group in order to provide the necessary functionality to allow IPv6 over BLE, and this includes a decision on the channel identifier(s) for IPv6. However, this process has required (and will still require) some time to reach completion. Hope this helps! Carles > While this (can't run CoAP directly on BLE L2CAP) is true today, we do > have proposals for various alternative transport bindings (including SMS), > so if this is a sensible thing to do, we could look into it. On the BLE > level, the obvious choking point is channel allocation. I'd like to > understand the usecase some more, and build more of an opinion when I'm > back in Germany next week... > > Sent from my iPad > > On 07.05.2013, at 21:30, "Rahman, Akbar" > wrote: > >> Hi Golnaz, >> >> I am not familiar with BLE, but with regards to your specific question >> of: >> >> “…can CoAP in a network without running IPV6 be implemented on BLE as >> is?” >> >> >> My response is: >> · No, you cannot implement CoAP on a network that is not running >> IPv6 (or IPv4) >> · CoAP was meant to run on an UDP/IP protocol stack. There are >> many critical parts of the CoAP protocol that would break if the >> underlying layers was not UDP/IP. For example: >> o Using the IPv6 address as a literal in the host part of the URI ( >> http://tools.ietf.org/html/draft-ietf-core-coap-16#section-5.10.1 ) >> o Triggering IP multicast ( >> http://tools.ietf.org/html/draft-ietf-core-coap-16#section-8 ) >> o Listening on the UDP port number >> (http://tools.ietf.org/html/draft-ietf-core-coap-16#section-12.7 ) >> o Etc. >> >> >> So, to repeat, I do not believe that you can run CoAP on a network that >> does not have IPv6 (or IPv4) underneath. >> >> >> Hope that helps. >> >> >> Best Regards, >> >> >> Akbar >> >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of >> Golnaz KARBASCHI >> Sent: Monday, May 06, 2013 9:33 AM >> To: core@ietf.org >> Subject: [core] Running CoAP over a local BLE network >> >> Hello to All , >> >> I have a question about running a COAP application instead of GATT based >> profiles over a local network with BLE (Bluetooth Low Energy) >> peripherals. >> The idea of using CoAP is its http friendly characteristics (RESTfull >> structure) and its lightness for a constrained based network, like BLE. >> BUT we do not want to have necessarily the end-to-end IP connections all >> the way on our local network. >> >> Supposing to have a BLE local network like the figure below, with a host >> node for accessing to the exterior connections (such as internet >> connection) >> O--- BLE-----O (HOST) --------- > internet >> O--- BLE-----| >> O--- BLE-----| >> >> My question is that if we don't care running IPV6 all the way to BLE >> peripherals (and so don't need to implement a 6lowpan layer), is there >> still any interest to use CoAP? >> >> >> And if we decided to run CoAP instead of existing structures and >> profiles of BLE, can CoAP in a network without running IPV6 be >> implemented on BLE as is? How should it be implemented ? Is it correct >> to say that CoAP will behave just as a new profile for the BLE network? >> Meaning that L2CAP takes care of adaptation between CoAP and lower >> layers (MTU adaptation, etc.) and CoAP plays its role to have a http >> friendly >> interface for the network ? >> >> Thank you in advance if any one that is familiar with BLE or not (!) can >> give me more information about this question. >> >> Golnaz KARBASCHI >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From trac+core@trac.tools.ietf.org Wed May 8 04:27: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 B0EA121F926E for ; Wed, 8 May 2013 04:27: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=[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 H4OUegE24uvH for ; Wed, 8 May 2013 04:27: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 CCD3721F9239 for ; Wed, 8 May 2013 04:27:34 -0700 (PDT) Received: from localhost ([127.0.0.1]:59071 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Ua2Wu-0007N8-60; Wed, 08 May 2013 13:27:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Wed, 08 May 2013 11:27:28 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/300#comment:1 Message-ID: <075.f140701397e594b024d79ecfd59c9ea1@trac.tools.ietf.org> References: <060.8f42cd858e81ce968cf05a558a0a45c5@trac.tools.ietf.org> X-Trac-Ticket-ID: 300 In-Reply-To: <060.8f42cd858e81ce968cf05a558a0a45c5@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: <20130508112734.CCD3721F9239@ietfa.amsl.com> Resent-Date: Wed, 8 May 2013 04:27:34 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [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: Wed, 08 May 2013 11:27:35 -0000 #300: Clarify semantics of group management JSON format Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: fixed in groupcomm-07 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: closed enhancement | Milestone: Priority: major | Version: Component: groupcomm | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From esko.dijk@philips.com Wed May 8 04:39: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 4CAD721F91B0 for ; Wed, 8 May 2013 04:39:02 -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=-1.999, 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 EkAYhpV2ygph for ; Wed, 8 May 2013 04:38:57 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0189.outbound.messaging.microsoft.com [213.199.154.189]) by ietfa.amsl.com (Postfix) with ESMTP id BC79021F8E56 for ; Wed, 8 May 2013 04:38:56 -0700 (PDT) Received: from mail63-db8-R.bigfish.com (10.174.8.246) by DB8EHSOBE004.bigfish.com (10.174.4.67) with Microsoft SMTP Server id 14.1.225.23; Wed, 8 May 2013 11:38:55 +0000 Received: from mail63-db8 (localhost [127.0.0.1]) by mail63-db8-R.bigfish.com (Postfix) with ESMTP id A54966C0399; Wed, 8 May 2013 11:38:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -35 X-BigFish: VPS-35(zz15d6O9371I9251J542I179dN217bIdd85kzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1155h) Received: from mail63-db8 (localhost.localdomain [127.0.0.1]) by mail63-db8 (MessageSwitch) id 1368013084573131_24149; Wed, 8 May 2013 11:38:04 +0000 (UTC) Received: from DB8EHSMHS016.bigfish.com (unknown [10.174.8.254]) by mail63-db8.bigfish.com (Postfix) with ESMTP id 87B95A8022E; Wed, 8 May 2013 11:38:04 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB8EHSMHS016.bigfish.com (10.174.4.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 8 May 2013 11:38:02 +0000 Received: from 011-DB3MMR1-021.MGDPHG.emi.philips.com (10.128.28.103) by 011-DB3MMR1-010.MGDPHG.emi.philips.com (10.128.28.49) with Microsoft SMTP Server (TLS) id 14.2.328.11; Wed, 8 May 2013 11:38:00 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.161]) by 011-DB3MMR1-021.MGDPHG.emi.philips.com ([fe80::f066:9203:e7da:3658%11]) with mapi id 14.02.0328.011; Wed, 8 May 2013 11:38:00 +0000 From: "Dijk, Esko" To: "Rahman, Akbar" , Carsten Bormann , "Kovatsch Matthias" , Zach Shelby Thread-Topic: New "application/coap-group+json" Internet Media Type for Group Communication Thread-Index: AQHOS1Ru/FFvyttvJkqiTwIAtw0ar5j7KWRg Date: Wed, 8 May 2013 11:38:01 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C230E3@011-DB3MPN2-082.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><031DD135F9160444ABBE3B0C36CED618C14EF3@011-DB3MPN2-083.MGDPHG.emi.philips.com> <55877B3AFB359744BA0F2140E36F52B514E9B828@MBX20.d.ethz.ch> 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 Cc: "core@ietf.org" Subject: Re: [core] New "application/coap-group+json" Internet Media Type for Group Communication X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 May 2013 11:39:02 -0000 Additional note: the syntax of the current media type uses standard IPv6 ad= dress notation in the values of the "ip" fields. One improvement could be to replace this with an easier to parse representa= tion, for example a 16-byte fixed length sequence in hexadecimal, i.e. 32 c= haracters always. That would avoid the need for a fully functional IPv6 add= ress notation parser in constrained nodes. Esko -----Original Message----- From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com] Sent: Tuesday, May 07, 2013 20:55 To: Carsten Bormann; Kovatsch Matthias; Zach Shelby Cc: core@ietf.org; Dijk, Esko Subject: New "application/coap-group+json" Internet Media Type for Group Co= mmunication Hi Carsten/Matthias/Zach, Esko and I have taken a stab at defining the new "application/coap-group+js= on" Internet Media Type for Group Communication in the updated Group Commun= ications draft: http://tools.ietf.org/html/draft-ietf-core-groupcomm-07#section-7 Can you please review and tell us if you agree with this approach? Best Regards, Akbar -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Kov= atsch Matthias Sent: Tuesday, April 23, 2013 7:55 AM To: Dijk, Esko Cc: core@ietf.org Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-06.txt 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 solution. _______________________________________________ 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 ietf-secretariat-reply@ietf.org Thu May 9 10:06: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 5865B21F861B for ; Thu, 9 May 2013 10:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.103, 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 jCGwm+d2untJ; Thu, 9 May 2013 10:06:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A655F21F9354; Thu, 9 May 2013 10:06:52 -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.p7 Message-ID: <20130509170652.11854.86920.idtracker@ietfa.amsl.com> Date: Thu, 09 May 2013 10:06:52 -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, 09 May 2013 17:06:53 -0000 IANA review state changed to IANA - Not OK ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-coap/ From stokcons@xs4all.nl Fri May 10 02:26: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 415FF21F8B0A for ; Fri, 10 May 2013 02:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[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 obkOxbEi-TaT for ; Fri, 10 May 2013 02:26:16 -0700 (PDT) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6074721F8A48 for ; Fri, 10 May 2013 02:26:16 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube3.xs4all.net [194.109.20.199]) by smtp-vbr4.xs4all.nl (8.13.8/8.13.8) with ESMTP id r4A9QE4L062028 for ; Fri, 10 May 2013 11:26:14 +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); Fri, 10 May 2013 11:26:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 10 May 2013 11:26:13 +0200 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: Message-ID: <9ad0c2c16e0df580f08df86a8fa87ab6@xs4all.nl> X-Sender: stokcons@xs4all.nl (5DfIaUMqIhL+hVhWTAx3q5P/o6tpx5Px) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [core] shelby-core-interfaces-05 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: Fri, 10 May 2013 09:26:22 -0000 Hi Zach and Matthieu, looking at ways to use core-interfaces I stumbled on an ambiguity in the binding methods: The document specifies: polling, observe, and push. For the latter it specifies PUT without indication whether this a PUT sending a confirmable or a non-confirmable messages. Non-confirmable messages are preferably sent wehen the destination is a multicast group. I would suggest a distinction netween a push and a distribute mode: - Push to be used with PUT and confirmable unicast message - Distribute to be used with PUT and non-confirmable multicast message. Or any other combination of syntax and semantics. Or a clarification that the text already includes both cases without ambiguity Many thanks, peter -- Peter van der Stok mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 From zach@sensinode.com Fri May 10 03:07: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 2B82821F8E3C for ; Fri, 10 May 2013 03:07:02 -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 FRbx+IFtoGOh for ; Fri, 10 May 2013 03:06: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 3CFFC21F8D0B for ; Fri, 10 May 2013 03:06:55 -0700 (PDT) Received: from [10.128.9.198] (line-21396.dyn.kponet.fi [213.145.192.6]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r4AA6qTm030515 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 May 2013 13:06:52 +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: <9ad0c2c16e0df580f08df86a8fa87ab6@xs4all.nl> Date: Fri, 10 May 2013 13:06:53 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9ad0c2c16e0df580f08df86a8fa87ab6@xs4all.nl> To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.1503) Cc: Core Subject: Re: [core] shelby-core-interfaces-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 10 May 2013 10:07:02 -0000 Peter, Sounds reasonable that we could clarify that. I think the current = binding mechanism works fine. Probably what we should define is that a = push binding with a unicast address is always sent confirmable and with = a multicast address is always sent non-confirmable. I don't think we = need a new "distributed" mode as such. The URL in the target of the link = already carries the IP address (or FQDN that will be resolved to one).=20= Zach=20 On May 10, 2013, at 12:26 PM, peter van der Stok = wrote: > Hi Zach and Matthieu, >=20 > looking at ways to use core-interfaces I stumbled on an ambiguity in = the binding methods: > The document specifies: polling, observe, and push. > For the latter it specifies PUT without indication whether this a PUT = sending a confirmable or a non-confirmable messages. > Non-confirmable messages are preferably sent wehen the destination is = a multicast group. >=20 > I would suggest a distinction netween a push and a distribute mode: > - Push to be used with PUT and confirmable unicast message > - Distribute to be used with PUT and non-confirmable multicast = message. >=20 > Or any other combination of syntax and semantics. >=20 > Or a clarification that the text already includes both cases without = ambiguity >=20 > Many thanks, >=20 > peter >=20 > --=20 > Peter van der Stok > mailto: consultancy@vanderstok.org > www: www.vanderstok.org > tel NL: +31(0)492474673 F: +33(0)966015248 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=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 stokcons@xs4all.nl Fri May 10 03:12: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 04B2021F8F12 for ; Fri, 10 May 2013 03:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[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 URJVrWTYhfCX for ; Fri, 10 May 2013 03:12:45 -0700 (PDT) Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) by ietfa.amsl.com (Postfix) with ESMTP id B41DD21F8721 for ; Fri, 10 May 2013 03:12:44 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube3.xs4all.net [194.109.20.199]) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id r4AACcrY029022; Fri, 10 May 2013 12:12:38 +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); Fri, 10 May 2013 12:12:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 10 May 2013 12:12:38 +0200 From: peter van der Stok To: Zach Shelby Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: References: <9ad0c2c16e0df580f08df86a8fa87ab6@xs4all.nl> Message-ID: <9c86a35e16e6e5f344525409621b3d8c@xs4all.nl> X-Sender: stokcons@xs4all.nl (yOkrOn3xw7ykj3TobOonL46FPO9fDthz) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Core Subject: Re: [core] shelby-core-interfaces-05 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: Fri, 10 May 2013 10:12:50 -0000 Zach, OK, works for me. The suggested relation covers my known use cases. Peter Zach Shelby schreef op 2013-05-10 12:06: > Peter, > > Sounds reasonable that we could clarify that. I think the current > binding mechanism works fine. Probably what we should define is that a > push binding with a unicast address is always sent confirmable and > with a multicast address is always sent non-confirmable. I don't think > we need a new "distributed" mode as such. The URL in the target of the > link already carries the IP address (or FQDN that will be resolved to > one). > > Zach > > On May 10, 2013, at 12:26 PM, peter van der Stok > wrote: > >> Hi Zach and Matthieu, >> >> looking at ways to use core-interfaces I stumbled on an ambiguity in >> the binding methods: >> The document specifies: polling, observe, and push. >> For the latter it specifies PUT without indication whether this a PUT >> sending a confirmable or a non-confirmable messages. >> Non-confirmable messages are preferably sent wehen the destination is >> a multicast group. >> >> I would suggest a distinction netween a push and a distribute mode: >> - Push to be used with PUT and confirmable unicast message >> - Distribute to be used with PUT and non-confirmable multicast >> message. >> >> Or any other combination of syntax and semantics. >> >> Or a clarification that the text already includes both cases without >> ambiguity >> >> Many thanks, >> >> peter >> >> -- >> Peter van der Stok >> mailto: consultancy@vanderstok.org >> www: www.vanderstok.org >> tel NL: +31(0)492474673 F: +33(0)966015248 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From kovatsch@inf.ethz.ch Sun May 12 06:31: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 8EB6F21F869C for ; Sun, 12 May 2013 06:31:59 -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 esdkX0GWLtVT for ; Sun, 12 May 2013 06:31:55 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7853C21F869A for ; Sun, 12 May 2013 06:31:52 -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; Sun, 12 May 2013 15:31:37 +0200 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS21.d.ethz.ch ([fe80::55ba:c4a5:d8a7:ab62%10]) with mapi id 14.02.0298.004; Sun, 12 May 2013 15:31:49 +0200 From: "Kovatsch Matthias" To: "Dijk, Esko" , "Rahman, Akbar" , Carsten Bormann , Zach Shelby Thread-Topic: New "application/coap-group+json" Internet Media Type for Group Communication Thread-Index: AQHOS1RwExVgWH0idU+RKN+FUQ2KR5j7CM2AgAZ2JvA= Date: Sun, 12 May 2013 13:31:47 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514EC6C67@MBX10.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> <55877B3AFB359744BA0F2140E36F52B514E9B828@MBX20.d.ethz.ch> <031DD135F9160444ABBE3B0C36CED618C230E3@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618C230E3@011-DB3MPN2-082.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: [213.101.211.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org" Subject: Re: [core] New "application/coap-group+json" Internet Media Type for Group Communication X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 May 2013 13:31:59 -0000 Dear Akbar and Esko This looks like a good direction to me. Maybe we can make it more explicit = that the media type defines the processing rules, not the resource type. I = have a proposal below.=20 Another question that arose: Why must group affiliation be configured with = single JSON group objects in multiple POSTs? Could we not just add several = at once with one POST? (fragmentation aside; maybe as an implementation not= e...) What is actually the status about "+json" suffixes in media types? I saw th= at it was kind of refused a while ago, so maybe it is sufficient to registe= r "application/coap-group"? Proposed draft texts for 3.6: ---8<--- [...] CoAP endpoints implementing this optional mechanism MUST support the "Group Configuration" Internet Media Type (application/coap-group+json). A resource offering this representation can be annotated for direct discovery using the resource type (rt) [RFC6690] "core.gp" where "gp" is shorthand for "group". An authorized controller uses this media type to query/manage group membership of a CoAP server as defined in the following. The "Group Configuration" has a JSON-based content format. A (unicast) GET on a resource accepting this format returns a JSON array of group objects, each group object formatted as shown below: [...] A (unicast) POST with a "Group Configuration" media type as payload adds the CoAP endpoint to the defined group(s). For this, it adds the specified IP multicast addresses to its network interface configuration. This also updates the resource by adding the specified group object(s) to the existing ones: [...] A (unicast) PUT with a "Group Configuration" media type as payload will replace all current group memberships with the new ones defined in the PUT request. After a change effected on the resource, the endpoint MUST effect registration/de-registration from the corresponding IP multicast groups as soon as possible. A (unicast) DELETE will delete all group memberships and the endpoint MUST effect de-registration from corresponding IP multicast groups as soon as possible. =09 [...] --->8--- Ciao Matthias > -----Original Message----- > From: Dijk, Esko [mailto:esko.dijk@philips.com] > Sent: Wednesday, May 08, 2013 13:38 > To: Rahman, Akbar; Carsten Bormann; Kovatsch Matthias; Zach Shelby > Cc: core@ietf.org > Subject: RE: New "application/coap-group+json" Internet Media Type for > Group Communication >=20 > Additional note: the syntax of the current media type uses standard IPv6 > address notation in the values of the "ip" fields. > One improvement could be to replace this with an easier to parse > representation, for example a 16-byte fixed length sequence in hexadecima= l, > i.e. 32 characters always. That would avoid the need for a fully function= al IPv6 > address notation parser in constrained nodes. >=20 > Esko >=20 > -----Original Message----- > From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com] > Sent: Tuesday, May 07, 2013 20:55 > To: Carsten Bormann; Kovatsch Matthias; Zach Shelby > Cc: core@ietf.org; Dijk, Esko > Subject: New "application/coap-group+json" Internet Media Type for Group > Communication >=20 > Hi Carsten/Matthias/Zach, >=20 >=20 > Esko and I have taken a stab at defining the new "application/coap- > group+json" Internet Media Type for Group Communication in the updated > Group Communications draft: >=20 >=20 > http://tools.ietf.org/html/draft-ietf-core-groupcomm-07#section-7 >=20 >=20 >=20 > Can you please review and tell us if you agree with this approach? >=20 >=20 > Best Regards, >=20 >=20 > Akbar >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > Kovatsch Matthias > Sent: Tuesday, April 23, 2013 7:55 AM > To: Dijk, Esko > Cc: core@ietf.org > Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-06.txt >=20 > Hmm, that is a good point. The problem here lies more in the number > registry for the Content-Format, I suppose. > Maybe we should have something similar to option numbers, so that specifi= c > bits indicate a "+json" or "+xml"? >=20 > In general, it is the point, though, that the media types must be pre-sha= red. > A generic client would probably be like a Web browser that has plugins fo= r > new types or at least can make a lookup in the registry. >=20 > Ciao > Matthias >=20 > > Suppose we define 'application/coap-group+json' for that, the side > > effect is that a client not knowing this specific content-format can't >=20 > > 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 > solution. >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notif= ied > that any use, forwarding, dissemination, or reproduction of this message = is > strictly prohibited and may be unlawful. If you are not the intended reci= pient, > please contact the sender by return e-mail and destroy all copies of the > original message. From esko.dijk@philips.com Mon May 13 05:18: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 5CFFB21F957D for ; Mon, 13 May 2013 05:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LLwYdd4DJnO for ; Mon, 13 May 2013 05:18:10 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id A542421F95DB for ; Mon, 13 May 2013 05:18:07 -0700 (PDT) Received: from mail80-co9-R.bigfish.com (10.236.132.253) by CO9EHSOBE003.bigfish.com (10.236.130.66) with Microsoft SMTP Server id 14.1.225.23; Mon, 13 May 2013 12:18:06 +0000 Received: from mail80-co9 (localhost [127.0.0.1]) by mail80-co9-R.bigfish.com (Postfix) with ESMTP id BA797120790; Mon, 13 May 2013 12:18:06 +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: -7 X-BigFish: VPS-7(zz15d6O9251Jc85fhdb82h217bIdd85kzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz17326ah18c673h8275bhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1155h) Received: from mail80-co9 (localhost.localdomain [127.0.0.1]) by mail80-co9 (MessageSwitch) id 1368447484386304_16679; Mon, 13 May 2013 12:18:04 +0000 (UTC) Received: from CO9EHSMHS018.bigfish.com (unknown [10.236.132.250]) by mail80-co9.bigfish.com (Postfix) with ESMTP id 51B55E0764; Mon, 13 May 2013 12:18:04 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS018.bigfish.com (10.236.130.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 13 May 2013 12:18:04 +0000 Received: from 011-DB3MMR1-023.MGDPHG.emi.philips.com (10.128.28.107) by 011-DB3MMR1-009.MGDPHG.emi.philips.com (10.128.28.48) with Microsoft SMTP Server (TLS) id 14.2.328.11; Mon, 13 May 2013 12:17:54 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.161]) by 011-DB3MMR1-023.MGDPHG.emi.philips.com ([fe80::e485:97aa:9b41:86e3%11]) with mapi id 14.02.0328.011; Mon, 13 May 2013 12:17:34 +0000 From: "Dijk, Esko" To: "core (core@ietf.org)" Thread-Topic: HTTP-CoAP default URI mapping: some draft proposals Thread-Index: Ac5P0diKwuFDFUSHQoafxpmnmeVw4A== Date: Mon, 13 May 2013 12:17:33 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C2BC0E@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_031DD135F9160444ABBE3B0C36CED618C2BC0E011DB3MPN2082MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] HTTP-CoAP default URI mapping: some draft proposals X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 13 May 2013 12:18:16 -0000 --_000_031DD135F9160444ABBE3B0C36CED618C2BC0E011DB3MPN2082MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, below I've listed a number of proposals that the authors of draft-castellan= i-core-http-mapping discussed. The formal specification of the solutions (i= n terms of URI template) is mostly missing, but hopefully the examples make= the main ideas clear. Each example shows a http URI, with which a HTTP-CoA= P cross-protocol proxy at host 'proxy.example.com' is called. After the arr= ow (->) the extracted CoAP URI is shown, via which the CoAP server at 'serv= er.coap.example.com' is called by the proxy. After the solutions there's a short table showing my personal (not with my = co-authors) first analysis of how each solution meets the requirements. The= requirements were posted on May 8th to the list. Any feedback is welcomed! regards, Esko --- Solution #0: placeholder proposal in draft-bormann-core-cross-reverse-conve= ntion-00 URI template: tbd Example: http://proxy.example.com/.well-known/core-translate/1.2.3.4_4567/foo/= bar?a=3D3&b=3D5 -> coap://1.2.3.4:4567/foo/bar?a=3D3&b=3D5 Notes: how to include IPv6 literals was not defined. CoAP scheme is derived= from HTTP scheme (http or https). '_{Port}' part is optional. Solution #1: adding IPv6 support to #0 URI Template: /.well-known/core-translate/{authority-encoded}/{path}?{query} Notes: the proxy will percent-decode the {authority-encoded} to {authority}= before constructing the COAP URI. CoAP scheme is derived from HTTP scheme = (http or https). Examples: http://proxy.example.com/.well-known/core-translate/%5B2001= ::23:25%5D:4567/foo/bar?a=3D3&b=3D5 -> coap://[2001::23:25]:4567/foo/bar?a=3D3&b=3D5 http://proxy.example.com/.well-known/core-translate/server.= coap.example.com:4567/foo/bar?a=3D3&b=3D5 -> coap://server.coap.example.com:4567/foo/bar?a=3D3&b=3D5 http://proxy.example.com/.well-known/core-translate/server.= coap.example.com/foo/bar?a=3D3&b=3D5 -> coap://server.coap.example.com/foo/bar?a=3D3&b=3D5 http://proxy.example.com/.well-known/core-translate/1.2.3.4= :4567/foo/bar?a=3D3&b=3D5 -> coap://1.2.3.4:4567/foo/bar?a=3D3&b=3D5 Solution #2: Split CoAP URI in parts and put parts in query arguments URI Template: /.well-known/core-translate/host=3D{host}&port=3D{port}&path=3D{path}?{quer= y} Note: the query parts 'host', 'port' , 'path' and 'query' are all optional= in the URI. http://proxy.example.com/.well-known/core-translate?host=3D%5B1234::5678%5D= &port=3D4567&path=3D/foo/bar?a=3D3&b=3D5 -> coap://[1234::5678]:4567/foo/bar?a=3D3&b=3D5 Solution #3: Entire CoAP URI as single query parameter Inspired by certain web services that put http callback URIs in URI-query p= arameters. URI template: tbd Example: http://proxy.example.com/.well-known/core-translate?uri=3Dcoap%3A%2F%2F%5B1= 234%3A%3A5678%5D%3A4567%2Ffoo%2Fbar%3Fb%3Dbefore_colon%253Aafter_colon -> coap://[1234::5678]:4567/foo/bar?b=3Dbefore_colon%3Aafter_col= on Solution #4: split CoAP URI in parts and put these parts in path components URI template: /.well-known/core-translate/{scheme}/{+host}/{port}/{+path_abempty}/{+query= } where: scheme =3D "coap" / "coaps" / "" host =3D matches production defined in RFC 3986 Sec. 3.2.2. NOTE: need to percent-encode '[' and ']' in IP-literal port =3D matches production defined in RFC 3986 Sec. 3.2.3. path_abempty =3D matches production defined in RFC 3986 Sec. 3.3. NOTE: need to percent-encode any '/' occurrence query =3D matches production defined in RFC 3986 Sec. 3.4. NOTE: need to percent-encode any '/' and '?' occurrence CoAP URI is reconstructed as per RFC 3986 Sec. 5.3. carrying out the following substitutions before going through the algorithm: - if scheme is the empty string, make it "coap"; - if port is the empty string, make it "5683"; [[ - if path-abempty is the empty string, make it "/"; -- possibly not need= ed ]] Example: http://proxy.example.com/.well-known/core-translate/coap/server.coap.exampl= e.com/4567/foo%2Fbar/a=3D3&b=3D5 -> coap://server.coap.example.com:4567/foo/bar?a=3D3&b=3D5 --- URI mapping requirements Note for the current requirements : there's currently no requirement that t= he HTTP client should somehow communicate, in the HTTP request, specific Co= AP Option values to the proxy, e.g. whether the proxy should use the Observ= e option or not in a CoAP request. We assume, for now, that is correct. R1. Syntactic correctness of the HTTP URI (e.g. handle percent-encoding whe= n needed); R2. HTTP URI must be able include all elements of a CoAP URI (e.g. coap(s) scheme, hostname, host literals IPv4/IPv6, port, path, qu= ery components, characters allowed in CoAP URI) R3. The mapping operation must produce a string that can be directly used b= y a proxy as input to the process of core-coap section 6.4. "Decomposing UR= Is into Options". R4. HTTP URI should be easily readable/writable by humans, if possible; (e.g. easy to read the CoAP URI embedded in it; avoid multiple levels o= f percent encoding, etc.) R5. HTTP cache friendliness of the mapping solution, i.e. maximize the cach= ing of CoAP resources by HTTP intermediaries; (e.g. a solution where entire CoAP URI is provided as a single query par= ameter is bad in this respect) R6. Normalised form: preferably there should be only one "normal"/default w= ay to encode the URI (e.g. so that we don't end up with multiple different cache entries for= the same CoAP resource in intermediaries.); R7. HTTP URI should be as short as possible. #0 #1 #2 #3 #4 R1 + + + + + R2 - + + + + R3 + + + + + (where details need to be defined for each solution) R4 + + o - o R5 + + - - + R6 R7 + + - - +/o ^ tentative best option, #1 ________________________________ 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_031DD135F9160444ABBE3B0C36CED618C2BC0E011DB3MPN2082MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

below I’ve listed a number of proposals tha= t the authors of draft-castellani-core-http-mapping discussed. The formal s= pecification of the solutions (in terms of URI template) is mostly missing,= but hopefully the examples make the main ideas clear. Each example shows a http URI, with which a HTTP-CoAP cross-p= rotocol proxy at host ‘proxy.example.com’ is called. After the = arrow (->) the extracted CoAP URI is shown, via which the CoAP server at= ‘server.coap.example.com’ is called by the proxy.

 

After the solutions there’s a short table s= howing my personal (not with my co-authors) first analysis of how each solu= tion meets the requirements. The requirements were posted on May 8th to the list.

Any feedback is welcomed!

 

regards,

Esko

 

---

 

Solution #0: placeholder proposal in draft-bor= mann-core-cross-reverse-convention-00

 

URI template: tbd

 

Example:

      http://proxy.examp= le.com/.well-known/core-translate/1.2.3.4_4567/foo/bar?a=3D3&b=3D5

-> coap://1.2.3.4:4567/foo/bar?a=3D3&b=3D5=

 

Notes: how to include IPv6 literals was not defin= ed. CoAP scheme is derived from HTTP scheme (http or https). ‘_{Port}= ’ part is optional.

 

 

Solution #1: adding IPv6 support to #0

 

URI Template:

/.well-known/core-translate/{authority-encoded}/{= path}?{query}

 

Notes: the proxy will percent-decode the {authori= ty-encoded} to {authority} before constructing the COAP URI. CoAP scheme is= derived from HTTP scheme (http or https).

 

Examples:

        &= nbsp;       http://proxy.example.com/.well-kn= own/core-translate/%5B2001::23:25%5D:4567/foo/bar?a=3D3&b=3D5

->        &= nbsp;   coap://[2001::23:25]:4567/foo/bar?a=3D3&b=3D5

 

        &= nbsp;       http://proxy.example.com/.well-kn= own/core-translate/server.coap.example.com:4567/foo/bar?a=3D3&b=3D5

->        &= nbsp;   coap://server.coap.example.com:4567/foo/bar?a=3D3&b= =3D5

 

        &= nbsp;       http://proxy.example.com/.well-kn= own/core-translate/server.coap.example.com/foo/bar?a=3D3&b=3D5

->        &= nbsp;   coap://server.coap.example.com/foo/bar?a=3D3&b=3D5

 

        &= nbsp;       http://proxy.example.com/.well-kn= own/core-translate/1.2.3.4:4567/foo/bar?a=3D3&b=3D5

->        &= nbsp;   coap://1.2.3.4:4567/foo/bar?a=3D3&b=3D5

 

 

Solution #2: Split CoAP URI in parts and put p= arts in query arguments

 

URI Template:

/.well-known/core-translate/host=3D{host}&por= t=3D{port}&path=3D{path}?{query}

 

Note: the query parts ‘host’, ‘= port’  , ‘path’ and ‘query’ are all opti= onal in the URI.

 

http://proxy.example.com/.well-known/core-transla= te?host=3D%5B1234::5678%5D&port=3D4567&path=3D/foo/bar?a=3D3&b= =3D5

->       &n= bsp;    coap://[1234::5678]:4567/foo/bar?a=3D3&b=3D5

 

Solution #3: Entire CoAP URI as single query p= arameter

Inspired by certain web services that put http ca= llback URIs in URI-query parameters.

 

URI template: tbd

 

Example:

http://proxy.example.c= om/.well-known/core-translate?uri=3Dcoap%3A%2F%2F%5B1234%3A%3A5678%5D%3A456= 7%2Ffoo%2Fbar%3Fb%3Dbefore_colon%253Aafter_colon

->       &n= bsp;    coap://[1234::5678]:4567/foo/bar?b=3Dbefore_colon%3A= after_colon

 

 

Solution #4: split CoAP URI in parts and put t= hese parts in path components

 

URI template:

/.well-known/core-translate/{scheme}/{+host}/= {port}/{+path_abempty}/{+query}

 

where:

  scheme      =   =3D "coap" / "coaps" / ""

 

  host      &n= bsp;   =3D matches production defined in RFC 3986 Sec. 3.2.2.

        &= nbsp;         NOTE: need to percent= -encode '[' and ']' in IP-literal

 

  port      &n= bsp;   =3D matches production defined in RFC 3986 Sec. 3.2.3.

 

  path_abempty  =3D matches production = defined in RFC 3986 Sec. 3.3.

        &= nbsp;         NOTE: need to percent= -encode any '/' occurrence

 

  query      &= nbsp;  =3D matches production defined in RFC 3986 Sec. 3.4.

         =          NOTE: need to percent= -encode any '/' and '?' occurrence

 

  CoAP URI is reconstructed as per RFC 3986 = Sec. 5.3. carrying out the

  following substitutions before going throu= gh the algorithm:

 

  - if scheme is the empty string, make it &= quot;coap";

  - if port is the empty string, make it &qu= ot;5683";

[[ - if path-abempty is the empty string, make it= "/"; -- possibly not needed ]]

 

Example:

http://proxy.example.com/= .well-known/core-translate/coap/server.coap.example.com/4567/foo%2Fbar/a=3D= 3&b=3D5

->        &= nbsp;   coap://server.coap.example.com:4567/foo/bar?a=3D3&b= =3D5

 

---

 

URI mapping requirements

 

Note for the current requirements : there&= #8217;s currently no requirement that the HTTP client should somehow commun= icate, in the HTTP request, specific CoAP Option values to the proxy, e.g. = whether the proxy should use the Observe option or not in a CoAP request. We assume, for now, that is correct.

 

R1. Syntactic correctness of the HTTP URI (e.g. hand= le percent-encoding when needed);

 

R2. HTTP URI must be able include all elements of a = CoAP URI

    (e.g. coap(s) scheme, hostna= me, host literals IPv4/IPv6, port, path, query components, characters allow= ed in CoAP URI)

 

R3. The mapping operation must produce a string that= can be directly used by a proxy as input to the process of core-coap secti= on 6.4. "Decomposing URIs into Options".

 

R4. HTTP URI should be easily readable/writable by h= umans, if possible;

    (e.g. easy to read the CoAP URI e= mbedded in it; avoid multiple levels of percent encoding, etc.)

 

R5. HTTP cache friendliness of the mapping solution,= i.e. maximize the caching of CoAP resources by HTTP intermediaries;

   (e.g. a solution where entire CoAP URI = is provided as a single query parameter is bad in this respect)

 

R6. Normalised form: preferably there should be only= one "normal"/default way to encode the URI

    (e.g. so that we don't end up wit= h multiple different cache entries for the same CoAP resource in intermedia= ries.);

 

R7. HTTP URI should be as short as possible.

 

=    #0 #1 #2 #3 #4

= R1  +  +  +  +  +

= R2  -  +  +  +  +

= R3  +  +  +  +  +  (where= details need to be defined for each solution)

= R4  +  +  o  -  o

= R5  +  +  -  -  +

= R6  <to be checked>

= R7  +  +  -  -  +/o

        &nbs= p;            ^

=      tentative best option, #1

=  

=  

 

 


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_031DD135F9160444ABBE3B0C36CED618C2BC0E011DB3MPN2082MGDP_-- From cabo@tzi.org Mon May 13 05: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 289E121F957D for ; Mon, 13 May 2013 05:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.649 X-Spam-Level: X-Spam-Status: No, score=-105.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGOfLggjP+mI for ; Mon, 13 May 2013 05:58: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 1088C21F94FF for ; Mon, 13 May 2013 05:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r4DCweRI014133; Mon, 13 May 2013 14:58:40 +0200 (CEST) Received: from [192.168.217.105] (p5489192F.dip0.t-ipconnect.de [84.137.25.47]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7272D3727; Mon, 13 May 2013 14:58:39 +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: <031DD135F9160444ABBE3B0C36CED618C2BC0E@011-DB3MPN2-082.MGDPHG.emi.philips.com> Date: Mon, 13 May 2013 14:58:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <08B9AB24-8B84-444B-AD11-C787195754EC@tzi.org> References: <031DD135F9160444ABBE3B0C36CED618C2BC0E@011-DB3MPN2-082.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1503) Cc: "core \(core@ietf.org\)" Subject: Re: [core] HTTP-CoAP default URI mapping: some draft proposals X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 13 May 2013 12:58:49 -0000 Esko, thanks for exploring this space some more. I'm intrigued by this aspect: On May 13, 2013, at 14:17, "Dijk, Esko" wrote: > communicate, in the HTTP request, specific CoAP Option values When I designed the URI scheme for coap.me, this was a requirement. But where do you put those options? There is a need to retain = transparency for the path and the query. I finally came up with something that looks like this: http://coap.me/etag=3D9032625142006256669/coap://coap.me/ (the 9032625142006256669 is just a goedelized byte string here. There is also syntax to specify the method, a payload (!), and = non-confirmable use, which probably is very specific to the diagnostic = purpose of coap.me.) Gr=FC=DFe, Carsten From stephen.farrell@cs.tcd.ie Mon May 13 09:16: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 75F1121F940D; Mon, 13 May 2013 09:16:31 -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 FShCPdzS5vY6; Mon, 13 May 2013 09:16:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC77C21F9408; Mon, 13 May 2013 09:16:28 -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.p7 Message-ID: <20130513161628.26413.53782.idtracker@ietfa.amsl.com> Date: Mon, 13 May 2013 09:16:28 -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-16: (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, 13 May 2013 16:16:31 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-core-coap-16: 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 (still:-) end up balloting yes for his. = Just one DISCUSS point remaining. (1) Cleared, but see comment below (2) Cleared. = (3) Cleader, but see comment below. (4) Cleared, but see comment below. (5) Cleared. (6) Cleared. (7) Cleared. (8) Cleared. (9) Cleared. (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? We had some mail exchanges about that, but I'm not sure I'm ok with the outcome so I'd like to DISCUSS this some more. (And did any of that get into = -16? Not sure.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- --- former discuss points (1) I think you made a change to 5.6 for this but I still think (now at COMMENT level) that it'd be really good to say that CoAP is currently well defined only for URI schemes like coap(s) and http(s) but maybe not others. Basically, you need a scheme://host:port syntax or else you have to do some more specification work to get CoAP interop. (3) You now say "SHOULD use 32 bits of randomness" which is ok. I think it might be worth adding that CoAP nodes that might be targetted with many guesses SHOULD also = detect and react to that. Text of discuss (3) was: 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. This is no longer a DISCUSS because you said that the WG figure its ok and given you say to randomise at the start (of what?) then its marginal. = --- old comments below, sorta checked against -16 = intro, 2nd para: better to not talk about the WG name and its work really, but about the resulting protocol intro, last para: more sales pitch language 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. - I think in a mail Carsten said its 250/second max or = something, I still think this'd be great information to say explicitly early on in the spec since it might prevent someone spending a lot of effort before they find out that CoAP doesn't work for their use-case. 7.1 - what if I want to only do discovery via DTLS? What does "support" mean for port 5683 then? Carsten said that you do need to still listen on 5683 even if you only want to do work on . I'm not so happy about that but its not DISCUSS level. 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? Carsten responded: "yep, that's what we want" and I'm ok with that, if not convinced. From Akbar.Rahman@InterDigital.com Mon May 13 13:35: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 3105D21F8BBA for ; Mon, 13 May 2013 13:35:21 -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 hJuNRF-3bLl6 for ; Mon, 13 May 2013 13:35:17 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC7C21F92EC for ; Mon, 13 May 2013 13:35:15 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 16:35:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 May 2013 16:35:13 -0400 Message-ID: In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514EC6C67@MBX10.d.ethz.ch> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New "application/coap-group+json" Internet Media Type for Group Communication Thread-Index: AQHOS1RwExVgWH0idU+RKN+FUQ2KR5j7CM2AgAZ2JvCAAhn+8A== 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> <55877B3AFB359744BA0F2140E36F52B514E9B828@MBX20.d.ethz.ch> <031DD135F9160444ABBE3B0C36CED618C230E3@011-DB3MPN2-082.MGDPHG.emi.philips.com> <55877B3AFB359744BA0F2140E36F52B514EC6C67@MBX10.d.ethz.ch> From: "Rahman, Akbar" To: "Kovatsch Matthias" X-OriginalArrivalTime: 13 May 2013 20:35:14.0236 (UTC) FILETIME=[5F39EFC0:01CE5019] Cc: core@ietf.org Subject: Re: [core] New "application/coap-group+json" Internet Media Type for Group Communication X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 13 May 2013 20:35:21 -0000 Hi Matthias, Thank you for your detailed review and helpful suggestions. Some initial feedback is as follows: ---- Snip-1 ------- What is actually the status about "+json" suffixes in media types? I saw that it was kind of refused a while ago, so maybe it is sufficient to register "application/coap-group"? RESPONSE - If you look in http://www.iana.org/assignments/media-types/application you will see that there are some successfully registered "...+json" types. However, I am personally, open to either approach. Hopefully, Carsten can also give us some guidance on what is the best approach for this topic. ---- End of Snip-1 ------- AND ---- Snip-2 ------- Proposed draft texts for 3.6: RESPONSE - Very nice. I will incorporate this into the next revision of the I-D. ---- End of Snip-2 ------- Best Regards, Akbar -----Original Message----- From: Kovatsch Matthias [mailto:kovatsch@inf.ethz.ch]=20 Sent: Sunday, May 12, 2013 9:32 AM To: Dijk, Esko; Rahman, Akbar; Carsten Bormann; Zach Shelby Cc: core@ietf.org Subject: RE: New "application/coap-group+json" Internet Media Type for Group Communication Dear Akbar and Esko This looks like a good direction to me. Maybe we can make it more explicit that the media type defines the processing rules, not the resource type. I have a proposal below.=20 Another question that arose: Why must group affiliation be configured with single JSON group objects in multiple POSTs? Could we not just add several at once with one POST? (fragmentation aside; maybe as an implementation note...) What is actually the status about "+json" suffixes in media types? I saw that it was kind of refused a while ago, so maybe it is sufficient to register "application/coap-group"? Proposed draft texts for 3.6: ---8<--- [...] CoAP endpoints implementing this optional mechanism MUST support the "Group Configuration" Internet Media Type (application/coap-group+json). A resource offering this representation can be annotated for direct discovery using the resource type (rt) [RFC6690] "core.gp" where "gp" is shorthand for "group". An authorized controller uses this media type to query/manage group membership of a CoAP server as defined in the following. The "Group Configuration" has a JSON-based content format. A (unicast) GET on a resource accepting this format returns a JSON array of group objects, each group object formatted as shown below: [...] A (unicast) POST with a "Group Configuration" media type as payload adds the CoAP endpoint to the defined group(s). For this, it adds the specified IP multicast addresses to its network interface configuration. This also updates the resource by adding the specified group object(s) to the existing ones: [...] A (unicast) PUT with a "Group Configuration" media type as payload will replace all current group memberships with the new ones defined in the PUT request. After a change effected on the resource, the endpoint MUST effect registration/de-registration from the corresponding IP multicast groups as soon as possible. A (unicast) DELETE will delete all group memberships and the endpoint MUST effect de-registration from corresponding IP multicast groups as soon as possible. =09 [...] --->8--- Ciao Matthias > -----Original Message----- > From: Dijk, Esko [mailto:esko.dijk@philips.com] > Sent: Wednesday, May 08, 2013 13:38 > To: Rahman, Akbar; Carsten Bormann; Kovatsch Matthias; Zach Shelby > Cc: core@ietf.org > Subject: RE: New "application/coap-group+json" Internet Media Type for > Group Communication >=20 > Additional note: the syntax of the current media type uses standard=20 > IPv6 address notation in the values of the "ip" fields. > One improvement could be to replace this with an easier to parse=20 > representation, for example a 16-byte fixed length sequence in=20 > hexadecimal, i.e. 32 characters always. That would avoid the need for=20 > a fully functional IPv6 address notation parser in constrained nodes. >=20 > Esko >=20 > -----Original Message----- > From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com] > Sent: Tuesday, May 07, 2013 20:55 > To: Carsten Bormann; Kovatsch Matthias; Zach Shelby > Cc: core@ietf.org; Dijk, Esko > Subject: New "application/coap-group+json" Internet Media Type for=20 > Group Communication >=20 > Hi Carsten/Matthias/Zach, >=20 >=20 > Esko and I have taken a stab at defining the new "application/coap- > group+json" Internet Media Type for Group Communication in the updated > Group Communications draft: >=20 >=20 > http://tools.ietf.org/html/draft-ietf-core-groupcomm-07#section-7 >=20 >=20 >=20 > Can you please review and tell us if you agree with this approach? >=20 >=20 > Best Regards, >=20 >=20 > Akbar >=20 >=20 > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf=20 > Of Kovatsch Matthias > Sent: Tuesday, April 23, 2013 7:55 AM > To: Dijk, Esko > Cc: core@ietf.org > Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-06.txt >=20 > Hmm, that is a good point. The problem here lies more in the number=20 > registry for the Content-Format, I suppose. > Maybe we should have something similar to option numbers, so that=20 > specific bits indicate a "+json" or "+xml"? >=20 > In general, it is the point, though, that the media types must be pre-shared. > A generic client would probably be like a Web browser that has plugins > for new types or at least can make a lookup in the registry. >=20 > Ciao > Matthias >=20 > > Suppose we define 'application/coap-group+json' for that, the side=20 > > effect is that a client not knowing this specific content-format=20 > > can't >=20 > > deduce that it is in fact JSON format. (E.g. the client could=20 > > integrate a generic-JSON-viewer-plus- editor that shows the=20 > > 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 > solution. >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core >=20 > ________________________________ > The information contained in this message may be confidential and=20 > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are=20 > hereby notified that any use, forwarding, dissemination, or=20 > reproduction of this message is strictly prohibited and may be=20 > unlawful. If you are not the intended recipient, please contact the=20 > sender by return e-mail and destroy all copies of the original message. From Bert.Greevenbosch@huawei.com Mon May 13 18:19: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 9648B11E80D9 for ; Mon, 13 May 2013 18:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.094 X-Spam-Level: X-Spam-Status: No, score=-0.094 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_SAVELE=2.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdRYPuqm4m4O for ; Mon, 13 May 2013 18:19:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4D65511E80A2 for ; Mon, 13 May 2013 18:19:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARI71925; Tue, 14 May 2013 01:19:26 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 14 May 2013 02:19:05 +0100 Received: from SZXEML452-HUB.china.huawei.com (10.82.67.195) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 14 May 2013 02:19:25 +0100 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.35]) by szxeml452-hub.china.huawei.com ([10.82.67.195]) with mapi id 14.01.0323.007; Tue, 14 May 2013 09:19:19 +0800 From: Bert Greevenbosch To: "Dijk, Esko" , "core (core@ietf.org)" Thread-Topic: HTTP-CoAP default URI mapping: some draft proposals Thread-Index: Ac5P0diKwuFDFUSHQoafxpmnmeVw4AAbRkoA Date: Tue, 14 May 2013 01:19:18 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D7271BD@szxeml558-mbx.china.huawei.com> References: <031DD135F9160444ABBE3B0C36CED618C2BC0E@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618C2BC0E@011-DB3MPN2-082.MGDPHG.emi.philips.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: multipart/alternative; boundary="_000_46A1DF3F04371240B504290A071B4DB63D7271BDszxeml558mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [core] HTTP-CoAP default URI mapping: some draft proposals X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 14 May 2013 01:19:35 -0000 --_000_46A1DF3F04371240B504290A071B4DB63D7271BDszxeml558mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRXNrbywNCg0KVGhhbmsgeW91IGZvciB5b3VyIGV4dGVuc2l2ZSBkZXNjcmlwdGlvbiBvZiB0 aGUgb3B0aW9ucyBhbmQgcmVxdWlyZW1lbnRzLg0KDQpJIHBvbmRlciBiZXR3ZWVuICMxIGFuZCAj NC4gSSB0aGluayAjMSBpcyBlYXNpZXIgdG8gcGFyc2UsIGJ1dCBpdCBtaXNzZXMgdGhlIHNjaGVt ZSBpbmRpY2F0aW9uIGFzIGlzIHBvc3NpYmxlIGluICM0LiBUaGUgc2NoZW1lIGluZGljYXRvciBu ZWVkcyBhIGJpdCBleHRyYSBjb21wbGV4aXR5IHRob3VnaCwgYXMgdGhlIHBhcnNlciBuZWVkcyB0 byBkZXRlcm1pbmUgd2hldGhlciB0aGUgSFRUUCBVUkkgY29tcG9uZW50IGlzIGEgc2NoZW1lIGlu ZGljYXRvciwgb3IgdGhlIGRvbWFpbiBuYW1lIHBhcnQuIEkgZ3Vlc3MgdGhlcmUgd2lsbCBuZXZl ciBiZSBkb21haW4gbmFtZXMgImNvYXAiIGFuZCAiY29hcHMiIChJIGhvcGUgdGhlc2UgZG9tYWlu IG5hbWVzIGFyZSBmb3JiaWRkZW4/KSBzbyB3ZSBzaG91bGQgYmUgc2FmZSB3aXRoIHRoYXQuDQoN CklmIHdlIGhhdmUgYSBkZWZhdWx0IGNvYXAgc2NoZW1lLCBJIHRoaW5rIGNvbnN0cnVjdHMgbGlr ZQ0KaHR0cDovL3Byb3h5LmV4YW1wbGUuY29tLy53ZWxsLWtub3duL2NvcmUtdHJhbnNsYXRlLy9z ZXJ2ZXIuY29hcC5leGFtcGxlLmNvbS80NTY3L2ZvbyUyRmJhci9hPTMmYj01DQpzaG91bGQgYmUg Zm9yYmlkZGVuLg0KDQpBbm90aGVyIHByb2JsZW0gaXMgaG93IHRvIGhhbmRsZSB0aGUgZGVmYXVs dCBwb3J0IDU2ODMuIERvZXMgaXQgbmVlZCB0byBiZSBpbmNsdWRlZCBpbiB0aGUgSFRUUCBVUkkg b3Igbm90PyBJIHRoaW5rIHdlIHNob3VsZCBiZSBjbGVhciBvbiB0aGlzLCBzdWNoIHRoYXQgdGhl cmUgaXMgbm8gYW1iaWd1aXR5IHdoZXRoZXIgdHdvIGRpZmZlcmVudCBIVFRQIFVSSXMgcG9pbnQg dG8gdGhlIHNhbWUgcmVzb3VyY2Ugb3Igbm90LiBJIGd1ZXNzIGluIHNjaGVtZSAjNCB3ZSBzaG91 bGQgbWFuZGF0ZSBpbmNsdXNpb24gb2YgdGhlIHBvcnQgbnVtYmVyIGluIHRoZSBIVFRQIFVSSSwg YXMgb3RoZXJ3aXNlIHRoZSBwb3J0IG51bWJlciBjYW4gYmUgY29uZnVzZWQgd2l0aCB0aGUgcGF0 aCBjb21wb25lbnQuDQoNCkJlc3QgcmVnYXJkcywNCkJlcnQNCg0KDQpGcm9tOiBjb3JlLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBE aWprLCBFc2tvDQpTZW50OiAyMDEzxOo11MIxM8jVIDIwOjE4DQpUbzogY29yZSAoY29yZUBpZXRm Lm9yZykNClN1YmplY3Q6IFtjb3JlXSBIVFRQLUNvQVAgZGVmYXVsdCBVUkkgbWFwcGluZzogc29t ZSBkcmFmdCBwcm9wb3NhbHMNCg0KDQpEZWFyIGFsbCwNCg0KDQoNCmJlbG93IEmhr3ZlIGxpc3Rl ZCBhIG51bWJlciBvZiBwcm9wb3NhbHMgdGhhdCB0aGUgYXV0aG9ycyBvZiBkcmFmdC1jYXN0ZWxs YW5pLWNvcmUtaHR0cC1tYXBwaW5nIGRpc2N1c3NlZC4gVGhlIGZvcm1hbCBzcGVjaWZpY2F0aW9u IG9mIHRoZSBzb2x1dGlvbnMgKGluIHRlcm1zIG9mIFVSSSB0ZW1wbGF0ZSkgaXMgbW9zdGx5IG1p c3NpbmcsIGJ1dCBob3BlZnVsbHkgdGhlIGV4YW1wbGVzIG1ha2UgdGhlIG1haW4gaWRlYXMgY2xl YXIuIEVhY2ggZXhhbXBsZSBzaG93cyBhIGh0dHAgVVJJLCB3aXRoIHdoaWNoIGEgSFRUUC1Db0FQ IGNyb3NzLXByb3RvY29sIHByb3h5IGF0IGhvc3Qgoa5wcm94eS5leGFtcGxlLmNvbaGvIGlzIGNh bGxlZC4gQWZ0ZXIgdGhlIGFycm93ICgtPikgdGhlIGV4dHJhY3RlZCBDb0FQIFVSSSBpcyBzaG93 biwgdmlhIHdoaWNoIHRoZSBDb0FQIHNlcnZlciBhdCChrnNlcnZlci5jb2FwLmV4YW1wbGUuY29t oa8gaXMgY2FsbGVkIGJ5IHRoZSBwcm94eS4NCg0KDQoNCkFmdGVyIHRoZSBzb2x1dGlvbnMgdGhl cmWhr3MgYSBzaG9ydCB0YWJsZSBzaG93aW5nIG15IHBlcnNvbmFsIChub3Qgd2l0aCBteSBjby1h dXRob3JzKSBmaXJzdCBhbmFseXNpcyBvZiBob3cgZWFjaCBzb2x1dGlvbiBtZWV0cyB0aGUgcmVx dWlyZW1lbnRzLiBUaGUgcmVxdWlyZW1lbnRzIHdlcmUgcG9zdGVkIG9uIE1heSA4dGggdG8gdGhl IGxpc3QuDQoNCkFueSBmZWVkYmFjayBpcyB3ZWxjb21lZCENCg0KDQoNCnJlZ2FyZHMsDQoNCkVz a28NCg0KDQoNCi0tLQ0KDQoNCg0KU29sdXRpb24gIzA6IHBsYWNlaG9sZGVyIHByb3Bvc2FsIGlu IGRyYWZ0LWJvcm1hbm4tY29yZS1jcm9zcy1yZXZlcnNlLWNvbnZlbnRpb24tMDANCg0KDQoNClVS SSB0ZW1wbGF0ZTogdGJkDQoNCg0KDQpFeGFtcGxlOg0KDQogICAgICBodHRwOi8vcHJveHkuZXhh bXBsZS5jb20vLndlbGwta25vd24vY29yZS10cmFuc2xhdGUvMS4yLjMuNF80NTY3L2Zvby9iYXI/ YT0zJmI9NQ0KDQotPiBjb2FwOi8vMS4yLjMuNDo0NTY3L2Zvby9iYXI/YT0zJmI9NQ0KDQoNCg0K Tm90ZXM6IGhvdyB0byBpbmNsdWRlIElQdjYgbGl0ZXJhbHMgd2FzIG5vdCBkZWZpbmVkLiBDb0FQ IHNjaGVtZSBpcyBkZXJpdmVkIGZyb20gSFRUUCBzY2hlbWUgKGh0dHAgb3IgaHR0cHMpLiChrl97 UG9ydH2hryBwYXJ0IGlzIG9wdGlvbmFsLg0KDQoNCg0KDQoNClNvbHV0aW9uICMxOiBhZGRpbmcg SVB2NiBzdXBwb3J0IHRvICMwDQoNCg0KDQpVUkkgVGVtcGxhdGU6DQoNCi8ud2VsbC1rbm93bi9j b3JlLXRyYW5zbGF0ZS97YXV0aG9yaXR5LWVuY29kZWR9L3twYXRofT97cXVlcnl9DQoNCg0KDQpO b3RlczogdGhlIHByb3h5IHdpbGwgcGVyY2VudC1kZWNvZGUgdGhlIHthdXRob3JpdHktZW5jb2Rl ZH0gdG8ge2F1dGhvcml0eX0gYmVmb3JlIGNvbnN0cnVjdGluZyB0aGUgQ09BUCBVUkkuIENvQVAg c2NoZW1lIGlzIGRlcml2ZWQgZnJvbSBIVFRQIHNjaGVtZSAoaHR0cCBvciBodHRwcykuDQoNCg0K DQpFeGFtcGxlczoNCg0KICAgICAgICAgICAgICAgIGh0dHA6Ly9wcm94eS5leGFtcGxlLmNvbS8u d2VsbC1rbm93bi9jb3JlLXRyYW5zbGF0ZS8lNUIyMDAxOjoyMzoyNSU1RDo0NTY3L2Zvby9iYXI/ YT0zJmI9NQ0KDQotPiAgICAgICAgICAgIGNvYXA6Ly9bMjAwMTo6MjM6MjVdOjQ1NjcvZm9vL2Jh cj9hPTMmYj01DQoNCg0KDQogICAgICAgICAgICAgICAgaHR0cDovL3Byb3h5LmV4YW1wbGUuY29t Ly53ZWxsLWtub3duL2NvcmUtdHJhbnNsYXRlL3NlcnZlci5jb2FwLmV4YW1wbGUuY29tOjQ1Njcv Zm9vL2Jhcj9hPTMmYj01DQoNCi0+ICAgICAgICAgICAgY29hcDovL3NlcnZlci5jb2FwLmV4YW1w bGUuY29tOjQ1NjcvZm9vL2Jhcj9hPTMmYj01DQoNCg0KDQogICAgICAgICAgICAgICAgaHR0cDov L3Byb3h5LmV4YW1wbGUuY29tLy53ZWxsLWtub3duL2NvcmUtdHJhbnNsYXRlL3NlcnZlci5jb2Fw LmV4YW1wbGUuY29tL2Zvby9iYXI/YT0zJmI9NQ0KDQotPiAgICAgICAgICAgIGNvYXA6Ly9zZXJ2 ZXIuY29hcC5leGFtcGxlLmNvbS9mb28vYmFyP2E9MyZiPTUNCg0KDQoNCiAgICAgICAgICAgICAg ICBodHRwOi8vcHJveHkuZXhhbXBsZS5jb20vLndlbGwta25vd24vY29yZS10cmFuc2xhdGUvMS4y LjMuNDo0NTY3L2Zvby9iYXI/YT0zJmI9NQ0KDQotPiAgICAgICAgICAgIGNvYXA6Ly8xLjIuMy40 OjQ1NjcvZm9vL2Jhcj9hPTMmYj01DQoNCg0KDQoNCg0KU29sdXRpb24gIzI6IFNwbGl0IENvQVAg VVJJIGluIHBhcnRzIGFuZCBwdXQgcGFydHMgaW4gcXVlcnkgYXJndW1lbnRzDQoNCg0KDQpVUkkg VGVtcGxhdGU6DQoNCi8ud2VsbC1rbm93bi9jb3JlLXRyYW5zbGF0ZS9ob3N0PXtob3N0fSZwb3J0 PXtwb3J0fSZwYXRoPXtwYXRofT97cXVlcnl9DQoNCg0KDQpOb3RlOiB0aGUgcXVlcnkgcGFydHMg oa5ob3N0oa8sIKGucG9ydKGvICAsIKGucGF0aKGvIGFuZCChrnF1ZXJ5oa8gYXJlIGFsbCBvcHRp b25hbCBpbiB0aGUgVVJJLg0KDQoNCg0KaHR0cDovL3Byb3h5LmV4YW1wbGUuY29tLy53ZWxsLWtu b3duL2NvcmUtdHJhbnNsYXRlP2hvc3Q9JTVCMTIzNDo6NTY3OCU1RCZwb3J0PTQ1NjcmcGF0aD0v Zm9vL2Jhcj9hPTMmYj01DQoNCi0+ICAgICAgICAgICAgY29hcDovL1sxMjM0Ojo1Njc4XTo0NTY3 L2Zvby9iYXI/YT0zJmI9NQ0KDQoNCg0KU29sdXRpb24gIzM6IEVudGlyZSBDb0FQIFVSSSBhcyBz aW5nbGUgcXVlcnkgcGFyYW1ldGVyDQoNCkluc3BpcmVkIGJ5IGNlcnRhaW4gd2ViIHNlcnZpY2Vz IHRoYXQgcHV0IGh0dHAgY2FsbGJhY2sgVVJJcyBpbiBVUkktcXVlcnkgcGFyYW1ldGVycy4NCg0K DQoNClVSSSB0ZW1wbGF0ZTogdGJkDQoNCg0KDQpFeGFtcGxlOg0KDQpodHRwOi8vcHJveHkuZXhh bXBsZS5jb20vLndlbGwta25vd24vY29yZS10cmFuc2xhdGU/dXJpPWNvYXAlM0ElMkYlMkYlNUIx MjM0JTNBJTNBNTY3OCU1RCUzQTQ1NjclMkZmb28lMkZiYXIlM0ZiJTNEYmVmb3JlX2NvbG9uJTI1 M0FhZnRlcl9jb2xvbg0KDQotPiAgICAgICAgICAgIGNvYXA6Ly9bMTIzNDo6NTY3OF06NDU2Ny9m b28vYmFyP2I9YmVmb3JlX2NvbG9uJTNBYWZ0ZXJfY29sb24NCg0KDQoNCg0KDQpTb2x1dGlvbiAj NDogc3BsaXQgQ29BUCBVUkkgaW4gcGFydHMgYW5kIHB1dCB0aGVzZSBwYXJ0cyBpbiBwYXRoIGNv bXBvbmVudHMNCg0KDQoNClVSSSB0ZW1wbGF0ZToNCg0KLy53ZWxsLWtub3duL2NvcmUtdHJhbnNs YXRlL3tzY2hlbWV9L3sraG9zdH0ve3BvcnR9L3srcGF0aF9hYmVtcHR5fS97K3F1ZXJ5fQ0KDQoN Cg0Kd2hlcmU6DQoNCiAgc2NoZW1lICAgICAgICA9ICJjb2FwIiAvICJjb2FwcyIgLyAiIg0KDQoN Cg0KICBob3N0ICAgICAgICAgID0gbWF0Y2hlcyBwcm9kdWN0aW9uIGRlZmluZWQgaW4gUkZDIDM5 ODYgU2VjLiAzLjIuMi4NCg0KICAgICAgICAgICAgICAgICAgTk9URTogbmVlZCB0byBwZXJjZW50 LWVuY29kZSAnWycgYW5kICddJyBpbiBJUC1saXRlcmFsDQoNCg0KDQogIHBvcnQgICAgICAgICAg PSBtYXRjaGVzIHByb2R1Y3Rpb24gZGVmaW5lZCBpbiBSRkMgMzk4NiBTZWMuIDMuMi4zLg0KDQoN Cg0KICBwYXRoX2FiZW1wdHkgID0gbWF0Y2hlcyBwcm9kdWN0aW9uIGRlZmluZWQgaW4gUkZDIDM5 ODYgU2VjLiAzLjMuDQoNCiAgICAgICAgICAgICAgICAgIE5PVEU6IG5lZWQgdG8gcGVyY2VudC1l bmNvZGUgYW55ICcvJyBvY2N1cnJlbmNlDQoNCg0KDQogIHF1ZXJ5ICAgICAgICAgPSBtYXRjaGVz IHByb2R1Y3Rpb24gZGVmaW5lZCBpbiBSRkMgMzk4NiBTZWMuIDMuNC4NCg0KICAgICAgICAgICAg ICAgICAgTk9URTogbmVlZCB0byBwZXJjZW50LWVuY29kZSBhbnkgJy8nIGFuZCAnPycgb2NjdXJy ZW5jZQ0KDQoNCg0KICBDb0FQIFVSSSBpcyByZWNvbnN0cnVjdGVkIGFzIHBlciBSRkMgMzk4NiBT ZWMuIDUuMy4gY2Fycnlpbmcgb3V0IHRoZQ0KDQogIGZvbGxvd2luZyBzdWJzdGl0dXRpb25zIGJl Zm9yZSBnb2luZyB0aHJvdWdoIHRoZSBhbGdvcml0aG06DQoNCg0KDQogIC0gaWYgc2NoZW1lIGlz IHRoZSBlbXB0eSBzdHJpbmcsIG1ha2UgaXQgImNvYXAiOw0KDQogIC0gaWYgcG9ydCBpcyB0aGUg ZW1wdHkgc3RyaW5nLCBtYWtlIGl0ICI1NjgzIjsNCg0KW1sgLSBpZiBwYXRoLWFiZW1wdHkgaXMg dGhlIGVtcHR5IHN0cmluZywgbWFrZSBpdCAiLyI7IC0tIHBvc3NpYmx5IG5vdCBuZWVkZWQgXV0N Cg0KRXhhbXBsZToNCmh0dHA6Ly9wcm94eS5leGFtcGxlLmNvbS8ud2VsbC1rbm93bi9jb3JlLXRy YW5zbGF0ZS9jb2FwL3NlcnZlci5jb2FwLmV4YW1wbGUuY29tLzQ1NjcvZm9vJTJGYmFyL2E9MyZi PTUNCg0KLT4gICAgICAgICAgICBjb2FwOi8vc2VydmVyLmNvYXAuZXhhbXBsZS5jb206NDU2Ny9m b28vYmFyP2E9MyZiPTUNCg0KLS0tDQoNClVSSSBtYXBwaW5nIHJlcXVpcmVtZW50cw0KDQoNCk5v dGUgZm9yIHRoZSBjdXJyZW50IHJlcXVpcmVtZW50cyA6IHRoZXJloa9zIGN1cnJlbnRseSBubyBy ZXF1aXJlbWVudCB0aGF0IHRoZSBIVFRQIGNsaWVudCBzaG91bGQgc29tZWhvdyBjb21tdW5pY2F0 ZSwgaW4gdGhlIEhUVFAgcmVxdWVzdCwgc3BlY2lmaWMgQ29BUCBPcHRpb24gdmFsdWVzIHRvIHRo ZSBwcm94eSwgZS5nLiB3aGV0aGVyIHRoZSBwcm94eSBzaG91bGQgdXNlIHRoZSBPYnNlcnZlIG9w dGlvbiBvciBub3QgaW4gYSBDb0FQIHJlcXVlc3QuIFdlIGFzc3VtZSwgZm9yIG5vdywgdGhhdCBp cyBjb3JyZWN0Lg0KDQpSMS4gU3ludGFjdGljIGNvcnJlY3RuZXNzIG9mIHRoZSBIVFRQIFVSSSAo ZS5nLiBoYW5kbGUgcGVyY2VudC1lbmNvZGluZyB3aGVuIG5lZWRlZCk7DQoNClIyLiBIVFRQIFVS SSBtdXN0IGJlIGFibGUgaW5jbHVkZSBhbGwgZWxlbWVudHMgb2YgYSBDb0FQIFVSSQ0KICAgIChl LmcuIGNvYXAocykgc2NoZW1lLCBob3N0bmFtZSwgaG9zdCBsaXRlcmFscyBJUHY0L0lQdjYsIHBv cnQsIHBhdGgsIHF1ZXJ5IGNvbXBvbmVudHMsIGNoYXJhY3RlcnMgYWxsb3dlZCBpbiBDb0FQIFVS SSkNCg0KUjMuIFRoZSBtYXBwaW5nIG9wZXJhdGlvbiBtdXN0IHByb2R1Y2UgYSBzdHJpbmcgdGhh dCBjYW4gYmUgZGlyZWN0bHkgdXNlZCBieSBhIHByb3h5IGFzIGlucHV0IHRvIHRoZSBwcm9jZXNz IG9mIGNvcmUtY29hcCBzZWN0aW9uIDYuNC4gIkRlY29tcG9zaW5nIFVSSXMgaW50byBPcHRpb25z Ii4NCg0KUjQuIEhUVFAgVVJJIHNob3VsZCBiZSBlYXNpbHkgcmVhZGFibGUvd3JpdGFibGUgYnkg aHVtYW5zLCBpZiBwb3NzaWJsZTsNCiAgICAoZS5nLiBlYXN5IHRvIHJlYWQgdGhlIENvQVAgVVJJ IGVtYmVkZGVkIGluIGl0OyBhdm9pZCBtdWx0aXBsZSBsZXZlbHMgb2YgcGVyY2VudCBlbmNvZGlu ZywgZXRjLikNCg0KUjUuIEhUVFAgY2FjaGUgZnJpZW5kbGluZXNzIG9mIHRoZSBtYXBwaW5nIHNv bHV0aW9uLCBpLmUuIG1heGltaXplIHRoZSBjYWNoaW5nIG9mIENvQVAgcmVzb3VyY2VzIGJ5IEhU VFAgaW50ZXJtZWRpYXJpZXM7DQogICAoZS5nLiBhIHNvbHV0aW9uIHdoZXJlIGVudGlyZSBDb0FQ IFVSSSBpcyBwcm92aWRlZCBhcyBhIHNpbmdsZSBxdWVyeSBwYXJhbWV0ZXIgaXMgYmFkIGluIHRo aXMgcmVzcGVjdCkNCg0KUjYuIE5vcm1hbGlzZWQgZm9ybTogcHJlZmVyYWJseSB0aGVyZSBzaG91 bGQgYmUgb25seSBvbmUgIm5vcm1hbCIvZGVmYXVsdCB3YXkgdG8gZW5jb2RlIHRoZSBVUkkNCiAg ICAoZS5nLiBzbyB0aGF0IHdlIGRvbid0IGVuZCB1cCB3aXRoIG11bHRpcGxlIGRpZmZlcmVudCBj YWNoZSBlbnRyaWVzIGZvciB0aGUgc2FtZSBDb0FQIHJlc291cmNlIGluIGludGVybWVkaWFyaWVz Lik7DQoNClI3LiBIVFRQIFVSSSBzaG91bGQgYmUgYXMgc2hvcnQgYXMgcG9zc2libGUuDQoNCiAg ICMwICMxICMyICMzICM0DQpSMSAgKyAgKyAgKyAgKyAgKw0KUjIgIC0gICsgICsgICsgICsNClIz ICArICArICArICArICArICAod2hlcmUgZGV0YWlscyBuZWVkIHRvIGJlIGRlZmluZWQgZm9yIGVh Y2ggc29sdXRpb24pDQpSNCAgKyAgKyAgbyAgLSAgbw0KUjUgICsgICsgIC0gIC0gICsNClI2ICA8 dG8gYmUgY2hlY2tlZD4NClI3ICArICArICAtICAtICArL28NCiAgICAgICAgICAgICAgICAgICAg IF4NCiAgICAgdGVudGF0aXZlIGJlc3Qgb3B0aW9uLCAjMQ0KDQoNCg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg bWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFuZCBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBh cHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRk cmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJl IGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24s IG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBh bmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kg YWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCg== --_000_46A1DF3F04371240B504290A071B4DB63D7271BDszxeml558mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Esko,

 

Thank you for your extensive description of the opti= ons and requirements.

 

I ponder between #1 and #4. I think #1 is easier to = parse, but it misses the scheme indication as is possible in #4. The scheme= indicator needs a bit extra complexity though, as the parser needs to dete= rmine whether the HTTP URI component is a scheme indicator, or the domain name part. I guess there will never b= e domain names "coap" and "coaps" (I hope these domain = names are forbidden?) so we should be safe with that.

 

If we have a default coap scheme, I think constructs= like

http://proxy.example.com/.well-known/core-translate/= /server.coap.example.com/4567/foo%2Fbar/a=3D3&b=3D5

should be forbidden.

 

Another problem is how to handle the default port 56= 83. Does it need to be included in the HTTP URI or not? I think we should b= e clear on this, such that there is no ambiguity whether two different HTTP= URIs point to the same resource or not. I guess in scheme #4 we should mandate inclusion of the port number i= n the HTTP URI, as otherwise the port number can be confused with the path = component.

 

Best regards,

Bert

 

 

From: core-bou= nces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Dijk, Esko
Sent: 2013=C4=EA5=D4=C213=C8=D5 20:18
To: core (core@ietf.org)
Subject: [core] HTTP-CoAP default URI mapping: some draft proposals<= o:p>

 

Dear all,

 

below I=A1=AFve listed a number of proposals that= the authors of draft-castellani-core-http-mapping discussed. The formal sp= ecification of the solutions (in terms of URI template) is mostly missing, = but hopefully the examples make the main ideas clear. Each example shows a http URI, with which a HTTP-CoAP cross-p= rotocol proxy at host =A1=AEproxy.example.com=A1=AF is called. After the ar= row (->) the extracted CoAP URI is shown, via which the CoAP server at = =A1=AEserver.coap.example.com=A1=AF is called by the proxy.

 

After the solutions there=A1=AFs a short table sh= owing my personal (not with my co-authors) first analysis of how each solut= ion meets the requirements. The requirements were posted on May 8th to the list.

Any feedback is welcomed!

 

regards,

Esko

 

---

 

Solution #0: placeholder proposal in draft-bor= mann-core-cross-reverse-convention-00

 

URI template: tbd

 

Example:

      http://proxy.examp= le.com/.well-known/core-translate/1.2.3.4_4567/foo/bar?a=3D3&b=3D5=

-> coap://1.2.3.4:4567/foo/bar?a=3D3&b=3D5=

 

Notes: how to include IPv6 literals was not defin= ed. CoAP scheme is derived from HTTP scheme (http or https). =A1=AE_{Port}= =A1=AF part is optional.

 

 

Solution #1: adding IPv6 support to #0

 

URI Template:

/.well-known/core-translate/{authority-encoded}/{= path}?{query}

 

Notes: the proxy will percent-decode the {authori= ty-encoded} to {authority} before constructing the COAP URI. CoAP scheme is= derived from HTTP scheme (http or https).

 

Examples:

        &= nbsp;       http://proxy.example.com/.well-kn= own/core-translate/%5B2001::23:25%5D:4567/foo/bar?a=3D3&b=3D5

->        &= nbsp;   coap://[2001::23:25]:4567/foo/bar?a=3D3&b=3D5

 

        &= nbsp;       http://proxy.example.com/.well-kn= own/core-translate/server.coap.example.com:4567/foo/bar?a=3D3&b=3D5

->        &= nbsp;   coap://server.coap.example.com:4567/foo/bar?a=3D3&b= =3D5

 

        &= nbsp;       http://proxy.example.com/.well-kn= own/core-translate/server.coap.example.com/foo/bar?a=3D3&b=3D5

->        &= nbsp;   coap://server.coap.example.com/foo/bar?a=3D3&b=3D5

 

        &= nbsp;       http://proxy.example.com/.well-kn= own/core-translate/1.2.3.4:4567/foo/bar?a=3D3&b=3D5

->        &= nbsp;   coap://1.2.3.4:4567/foo/bar?a=3D3&b=3D5

 

 

Solution #2: Split CoAP URI in parts and put p= arts in query arguments

 

URI Template:

/.well-known/core-translate/host=3D{host}&por= t=3D{port}&path=3D{path}?{query}

 

Note: the query parts =A1=AEhost=A1=AF, =A1=AEpor= t=A1=AF  , =A1=AEpath=A1=AF and =A1=AEquery=A1=AF are all optional in = the URI.

 

http://proxy.example.com/.well-known/core-transla= te?host=3D%5B1234::5678%5D&port=3D4567&path=3D/foo/bar?a=3D3&b= =3D5

->       &n= bsp;    coap://[1234::5678]:4567/foo/bar?a=3D3&b=3D5

 

Solution #3: Entire CoAP URI as single query p= arameter

Inspired by certain web services that put http ca= llback URIs in URI-query parameters.

 

URI template: tbd

 

Example:

http://proxy.example= .com/.well-known/core-translate?uri=3Dcoap%3A%2F%2F%5B1234%3A%3A5678%5D%3A4= 567%2Ffoo%2Fbar%3Fb%3Dbefore_colon%253Aafter_colon

->       &n= bsp;    coap://[1234::5678]:4567/foo/bar?b=3Dbefore_colon%3A= after_colon

 

 

Solution #4: split CoAP URI in parts and put t= hese parts in path components

 

URI template:

/.well-known/core-translate/{scheme}/{+host}/= {port}/{+path_abempty}/{+query}

 

where:

  scheme      =   =3D "coap" / "coaps" / ""

 

  host      &n= bsp;   =3D matches production defined in RFC 3986 Sec. 3.2.2.

        &= nbsp;         NOTE: need to percent= -encode '[' and ']' in IP-literal

 

  port      &n= bsp;   =3D matches production defined in RFC 3986 Sec. 3.2.3.

 

  path_abempty  =3D matches production = defined in RFC 3986 Sec. 3.3.

        &= nbsp;         NOTE: need to percent= -encode any '/' occurrence

 

  query      &= nbsp;  =3D matches production defined in RFC 3986 Sec. 3.4.=

         =          NOTE: need to percent= -encode any '/' and '?' occurrence

 

  CoAP URI is reconstructed as per RFC 3986 = Sec. 5.3. carrying out the

  following substitutions before going throu= gh the algorithm:

 

  - if scheme is the empty string, make it &= quot;coap";

  - if port is the empty string, make it &qu= ot;5683";

[[ - if path-abempty is the empty string, make it= "/"; -- possibly not needed ]]

 

Example:

http://proxy.example.co= m/.well-known/core-translate/coap/server.coap.example.com/4567/foo%2Fbar/a= =3D3&b=3D5

->        &= nbsp;   coap://server.coap.example.com:4567/foo/bar?a=3D3&b= =3D5

 

---

 

URI mapping requirements

 

Note for the current requirements : there= =A1=AFs currently no requirement that the HTTP client should somehow commun= icate, in the HTTP request, specific CoAP Option values to the proxy, e.g. = whether the proxy should use the Observe option or not in a CoAP request. We assume, for now, that is correct.=

 

R1. Syntactic correctness of the HTTP URI (e.g. hand= le percent-encoding when needed);

 

R2. HTTP URI must be able include all elements of a = CoAP URI

    (e.g. coap(s) scheme, hostna= me, host literals IPv4/IPv6, port, path, query components, characters allow= ed in CoAP URI)

 

R3. The mapping operation must produce a string that= can be directly used by a proxy as input to the process of core-coap secti= on 6.4. "Decomposing URIs into Options".

 

R4. HTTP URI should be easily readable/writable by h= umans, if possible;

    (e.g. easy to read the CoAP URI e= mbedded in it; avoid multiple levels of percent encoding, etc.)<= /p>

 

R5. HTTP cache friendliness of the mapping solution,= i.e. maximize the caching of CoAP resources by HTTP intermediaries;

   (e.g. a solution where entire CoAP URI = is provided as a single query parameter is bad in this respect)<= /p>

 

R6. Normalised form: preferably there should be only= one "normal"/default way to encode the URI

    (e.g. so that we don't end up wit= h multiple different cache entries for the same CoAP resource in intermedia= ries.);

 

R7. HTTP URI should be as short as possible.

 

=    #0 #1 #2 #3 #4

= R1  +  +  +  +  +<= /o:p>

= R2  -  +  +  +  +

= R3  +  +  +  +  +  (where= details need to be defined for each solution)

= R4  +  +  o  -  o

= R5  +  +  -  -  +

= R6  <to be checked>

= R7  +  +  -  -  +/o<= /p>

        &nbs= p;            ^=

=      tentative best option, #1

=  

=  

 

 

 

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

--_000_46A1DF3F04371240B504290A071B4DB63D7271BDszxeml558mbxchi_-- From cabo@tzi.org Mon May 13 23:38: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 B6CBB21F9021; Mon, 13 May 2013 23:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.187 X-Spam-Level: X-Spam-Status: No, score=-107.187 tagged_above=-999 required=5 tests=[AWL=-0.938, 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 BQRUPNvzDU0o; Mon, 13 May 2013 23:38:02 -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 A349321F8F87; Mon, 13 May 2013 23:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r4E6bKpL005051; Tue, 14 May 2013 08:37:21 +0200 (CEST) Received: from [192.168.217.105] (p5489192F.dip0.t-ipconnect.de [84.137.25.47]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 482353AA5; Tue, 14 May 2013 08:37: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: <20130513161628.26413.53782.idtracker@ietfa.amsl.com> Date: Tue, 14 May 2013 08:37:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7371C0ED-09BD-4E9D-A1D7-48489563ACF0@tzi.org> References: <20130513161628.26413.53782.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-16: (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, 14 May 2013 06:38:07 -0000 On May 13, 2013, at 18:16, "Stephen Farrell" = wrote: > (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? We had some mail exchanges about that, > but I'm not sure I'm ok with the outcome so I'd like to > DISCUSS this some more. (And did any of that get into=20 > -16? Not sure.) So what should we do? In my original reply, I tried to express that I'm not aware of a = technical solution here. The underlying problem is that it is not defined which security = properties an https (or coaps) URI is supposed to have. More amicably stated, it is the endpoint originating the https (or = coaps) request that defines those security properties based on some = context outside that URI. So if a client asks a proxy to originate such = a request, it also delegates setting up the specific security properties = to that proxy. E.g., the proxy is the one to select its set of trusted = root certificates, and it may even be able to select a client = certificate and other security parameters (httpauth...) based on the = authorization status of the original requestor mediated through the = security policies of the proxy. In all cases, the proxy is part of the security chain. Using a random = proxy the security properties of which have not been established gives = you no security whatsoever. We could say that much in section 5.7, at = the start of section 10, or in section 11.2. In any case, these = considerations are not specific to section 10 -- this may just merit an = additional mention that the CONNECT-based security model of https does = not carry over to CoAP cross-proxying. Mixing secure and insecure legs on the way to an origin server may be = quite appropriate based on the security properties of those legs -- = e.g., converting from https to http is quite common with reverse proxies = in a load balancing server farm. Again, this is something that requires = consideration of the whole chain. In any case, I wouldn't want to = forbid a proxy "upgrading" security (i.e., using https/coaps to forward = a request that it received via http/coap), and I wouldn't want to forbid = an originating node upgrading security on the leg to the proxy, even if = it knows that the next leg will base its security properties not on = https/coaps but something else (an initial coaps leg may also be = required simply because DTLS is the way the CoAP client authenticates to = the proxy). Gr=FC=DFe, Carsten From stephen.farrell@cs.tcd.ie Tue May 14 03:18: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 2B02A21F8FFC; Tue, 14 May 2013 03:18:29 -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 8RO59xLt773X; Tue, 14 May 2013 03:18:24 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id AE0BD21F8651; Tue, 14 May 2013 03:18:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B93FEBE8B; Tue, 14 May 2013 11:17:52 +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 b4yzxWLUm4rg; Tue, 14 May 2013 11:17:52 +0100 (IST) Received: from [IPv6:2001:770:10:203:ed12:4bfb:e53a:48e] (unknown [IPv6:2001:770:10:203:ed12:4bfb:e53a:48e]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8D3BBBE87; Tue, 14 May 2013 11:17:52 +0100 (IST) Message-ID: <51920F50.80804@cs.tcd.ie> Date: Tue, 14 May 2013 11:17:52 +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: <20130513161628.26413.53782.idtracker@ietfa.amsl.com> <7371C0ED-09BD-4E9D-A1D7-48489563ACF0@tzi.org> In-Reply-To: <7371C0ED-09BD-4E9D-A1D7-48489563ACF0@tzi.org> 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-16: (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, 14 May 2013 10:18:29 -0000 Hi Carsten, On 05/14/2013 07:37 AM, Carsten Bormann wrote: > On May 13, 2013, at 18:16, "Stephen Farrell" wrote: > >> (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? We had some mail exchanges about that, >> but I'm not sure I'm ok with the outcome so I'd like to >> DISCUSS this some more. (And did any of that get into >> -16? Not sure.) > > So what should we do? First, clarity. I'm not sure I'm entirely clear on what's what here. Then we can go from there. Let me see if my understanding of forward proxies at least is correct: (1) a CoAP node with no forward proxy MUST try directly connect to the authority in a coaps URL via DTLS. (2) a CoAP node with no forward proxy does nothing with an https URL - if it does something then its being an HTTP node and RFC 2818 applies not the CoAP spec. (3) A CoAP node with a forward proxy MUST send all coaps and https requests in clear to that (one?) forward proxy on port 5683. (4) There is no provision for "don't proxy for these domains" as there is in web browsers. Though that's not a part of HTTP, maybe it, or something like that, ought be part of CoAP? Do people implement that kind of thing anyway? (5) A forward proxy (p1) that receives a request MUST try connect directly to the authority from the coaps or https URL via (D)TLS if p1 has no forward proxy. If p1 also has a forward proxy configured then p1 MUST also forward the request in clear to 5683. So only the last forward proxy ever attempts (D)TLS. And nobody earlier in the chain can tell which is the last proxy. Nor can the (D)TLS server tell if the (D)TLS client is a proxy. (6) CoAP coaps/https proxying breaks (D)TLS client authentication. If client authentication in (D)TLS is requested by the (D)TLS server, then with CoAP the only relevant client private key is the one that the "last proxy" has. Is the above correct? If not, where am I wrong? I think once I have a correct understanding of the above then I'll be able to think about reverse proxies, esp. cases where the reverse proxy is in front of a bunch of challenged CoAP nodes. (Which I guess is pretty different from how HTTPS reverse proxies are deployed when they're acting as TLS accellerators/load-balancers.) So far, I'm thinking that DTLS as used with CoAP maybe has a lot in common with ESP in IPsec, e.g., assuming no change is made to the protocol, perhaps there's a need for a security policy DB. But let's make sure I'm not confused first, since I am often confused;-) Ta, S. PS: I (dis)agree with various bits of text below, but let's make sure we're on the same page before we go there. > In my original reply, I tried to express that I'm not aware of a technical solution here. > > The underlying problem is that it is not defined which security properties an https (or coaps) URI is supposed to have. > > More amicably stated, it is the endpoint originating the https (or coaps) request that defines those security properties based on some context outside that URI. So if a client asks a proxy to originate such a request, it also delegates setting up the specific security properties to that proxy. E.g., the proxy is the one to select its set of trusted root certificates, and it may even be able to select a client certificate and other security parameters (httpauth...) based on the authorization status of the original requestor mediated through the security policies of the proxy. > > In all cases, the proxy is part of the security chain. Using a random proxy the security properties of which have not been established gives you no security whatsoever. We could say that much in section 5.7, at the start of section 10, or in section 11.2. In any case, these considerations are not specific to section 10 -- this may just merit an additional mention that the CONNECT-based security model of https does not carry over to CoAP cross-proxying. > > Mixing secure and insecure legs on the way to an origin server may be quite appropriate based on the security properties of those legs -- e.g., converting from https to http is quite common with reverse proxies in a load balancing server farm. Again, this is something that requires consideration of the whole chain. In any case, I wouldn't want to forbid a proxy "upgrading" security (i.e., using https/coaps to forward a request that it received via http/coap), and I wouldn't want to forbid an originating node upgrading security on the leg to the proxy, even if it knows that the next leg will base its security properties not on https/coaps but something else (an initial coaps leg may also be required simply because DTLS is the way the CoAP client authenticates to the proxy). > > Grüße, Carsten > From cabo@tzi.org Tue May 14 04:53: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 8967121F8EEC; Tue, 14 May 2013 04:53:20 -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 sPyookVQwXIS; Tue, 14 May 2013 04:53:14 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 48BF621F86B2; Tue, 14 May 2013 04:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r4EBqW4N016454; Tue, 14 May 2013 13:52:33 +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 503233E51; Tue, 14 May 2013 13:52: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: <51920F50.80804@cs.tcd.ie> Date: Tue, 14 May 2013 13:52:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <028B263B-40A0-4236-91F7-1B9BC89B6438@tzi.org> References: <20130513161628.26413.53782.idtracker@ietfa.amsl.com> <7371C0ED-09BD-4E9D-A1D7-48489563ACF0@tzi.org> <51920F50.80804@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-16: (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, 14 May 2013 11:53:20 -0000 Hi Stephen, indeed, discussing this based on concrete examples probably works best. > Let me see if my understanding of forward proxies at > least is correct: >=20 > (1) a CoAP node with no forward proxy MUST try directly > connect to the authority in a coaps URL via DTLS. Yes. > (2) a CoAP node with no forward proxy does nothing with > an https URL - if it does something then its being an > HTTP node and RFC 2818 applies not the CoAP spec. Yes. > (3) A CoAP node with a forward proxy MUST send all > coaps and https requests in clear to that (one?) > forward proxy on port 5683. We haven't defined how a CoAP node acquires a forward proxy and what = URIs that then pertains to. The thinking is indeed that this will be a client-local function. I would expect the forward proxies for coaps and https URIs to be = configured with security (i.e., via coaps). This is necessary if there is any authentication required towards the = proxy. Does the current text imply that requests to a forward proxy always go = in NoSec mode? That would be a bug. > (4) There is no provision for "don't proxy for these > domains" as there is in web browsers. Though that's > not a part of HTTP, maybe it, or something like that, > ought be part of CoAP? Do people implement that kind > of thing anyway? I haven't done a survey of what people are doing with forward proxies. My personal experience is mainly with cross-proxying, and there is = little use there for a "don't proxy for these domains". We don't even = expect to use domain names in many very constrained nodes, so one likely = configuration would be "use the proxy if a regname authority is present, = go direct if there is an IP literal". > (5) A forward proxy (p1) that receives a request MUST > try connect directly to the authority from the coaps > or https URL via (D)TLS if p1 has no forward proxy. Indeed, that is implied by the URI scheme. (Again, the open issue is what the security parameters are for that = instance of (D)TLS.) > If p1 also has a forward proxy configured then p1 > MUST also forward the request in clear to 5683. (See above.) > So only > the last forward proxy ever attempts (D)TLS. (See above.) > And nobody > earlier in the chain can tell which is the last proxy. Indeed. > Nor can the (D)TLS server tell if the (D)TLS client > is a proxy. Right. Something like forwarded-for would enable that. However: 1) We haven't had the requirement stated yet, 2) this would probably be the most complicated CoAP option we have, 3) when that was discussed in the hallways, HTTP's Forwarded: was still = up in the air, > (6) CoAP coaps/https proxying breaks (D)TLS client > authentication. If client authentication in (D)TLS is > requested by the (D)TLS server, then with CoAP the only > relevant client private key is the one that the "last > proxy" has. It "breaks" (D)TLS client authentication if that is intended for = end-to-end use. It actually enables client authentication if the proxy is a gateway = between two security domains, i.e. it authenticates its client in one = way and then maps this to an appropriate client identity for the origin = server. > Is the above correct? If not, where am I wrong? >=20 > I think once I have a correct understanding of the above > then I'll be able to think about reverse proxies, esp. > cases where the reverse proxy is in front of a bunch > of challenged CoAP nodes. (Which I guess is pretty different > from how HTTPS reverse proxies are deployed when they're > acting as TLS accellerators/load-balancers.) Certainly different, but in both cases the proxy/load balancer may have = the role to "protect" the origin servers >=20 > So far, I'm thinking that DTLS as used with CoAP maybe > has a lot in common with ESP in IPsec, e.g., assuming > no change is made to the protocol, perhaps there's a > need for a security policy DB. But let's make sure I'm > not confused first, since I am often confused;-) A proxy that is gatewaying between two security domains certainly needs = some form of policy table. But this will be in terms of client and server identities and URIs, not = in terms of IP addresses and ports. Gr=FC=DFe, Carsten From golnaz.karbaschi@eolane.com Tue May 14 04:53: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 1D43C21F86B2 for ; Tue, 14 May 2013 04:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngP1Uu5plnIN for ; Tue, 14 May 2013 04:53:17 -0700 (PDT) Received: from relay.martec.fr (relay.martec.fr [92.103.79.186]) by ietfa.amsl.com (Postfix) with ESMTP id 2973921F901F for ; Tue, 14 May 2013 04:52:31 -0700 (PDT) Received: from webmail.martec.fr (unknown [192.168.20.3]) by relay.martec.fr (Postfix) with ESMTP id D740740C131; Tue, 14 May 2013 13:52:29 +0200 (CEST) Received: from CL563 ([192.168.20.158]) by webmail.martec.fr (Lotus Domino Release 8.5) with ESMTP id 2013051413522973-3415 ; Tue, 14 May 2013 13:52:29 +0200 From: "Golnaz KARBASCHI" To: "'Carsten Bormann'" , "'Rahman, Akbar'" , References: <005e01ce4a5e$413dbf30$c3b93d90$@karbaschi@eolane.com> In-Reply-To: Date: Tue, 14 May 2013 13:52:25 +0200 Organization: =?UTF-8?Q?=C3=A9olane?= Message-ID: <006d01ce5099$830033d0$89009b70$@karbaschi@eolane.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5LYI1OMBZWLuH0S/WoXKSojTjlyQFIuKlw X-MIMETrack: Itemize by SMTP Server on srvm1/martec_sevres/FR(Release 8.5|December 05, 2008) at 14/05/2013 13:52:29, Serialize by Router on srvm1/martec_sevres/FR(Release 8.5|December 05, 2008) at 14/05/2013 13:52:29, Serialize complete at 14/05/2013 13:52:29 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006E_01CE50AA.468903D0" Content-Language: fr Cc: core@ietf.org Subject: Re: [core] Running CoAP over a local BLE network X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 14 May 2013 11:53:21 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_006E_01CE50AA.468903D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Carsten and Akbar, =20 Thank you for your answers.=20 =20 Yes, I agree that there are some parts of CoAP that are defined = specifically to work with IP, but there may be some use-cases (like = mine) that cannot run the IP all the way to the end points. I think this = is a good motivation for starting drafts like : coap with alternative = transports (thanks to Bill !): = = http://datatracker.ietf.org/doc/draft-silverajan-core-coap-alternative-tr= ansports/). =20 Well, the question was raised in order to know if there is still any = interest to implement CoAP over these kinds of networks that do not care = about end-to-end IP connections , but need to be compatible with other = CoAP networks or at least have http connections to exterior.=20 As Carels mentioned too, ignoring IP over our internal network leads to = significant saving in overhead but may require installing an = adaption/proxy at Host level. Another motivation of removing IP over our LowPAN is that the ongoing = draft (IPV6 over BLE) is still not complete ! =20 =20 Our use case is a wireless BAN (Body Area Network) autonomous en battery = and with BLE peripherals from a main gateway to some sensors and other = embedded constrained devices. The gateway communicates wirelessly with a = Host (as shown again in the fig below) which potentially is connected = to internet. =20 O--- BLE-----O (HOST) --------- > internet O--- BLE-----| O--- BLE-----| =20 Effectively, the pb. of CoAP directly over BLE and instead of GATT is = related to Bluetooth compliance issues, such as defining a new channel = identifier, etc. But as suggested, it can be applied to BLE as a new = service over the existing GATT profile, Though, at this point I am not = certain that it is a straightforward task to do !.=20 =20 =20 Regards, =20 Golnaz Karbaschi=20 =20 De : Carsten Bormann [mailto:cabo@tzi.org]=20 Envoy=C3=A9 : mardi 7 mai 2013 22:22 =C3=80 : Rahman, Akbar Cc : Golnaz KARBASCHI; core@ietf.org Objet : Re: [core] Running CoAP over a local BLE network =20 While this (can't run CoAP directly on BLE L2CAP) is true today, we do = have proposals for various alternative transport bindings (including = SMS), so if this is a sensible thing to do, we could look into it. On = the BLE level, the obvious choking point is channel allocation. I'd = like to understand the usecase some more, and build more of an opinion = when I'm back in Germany next week...=20 Sent from my iPad On 07.05.2013, at 21:30, "Rahman, Akbar" = wrote: Hi Golnaz, =20 I am not familiar with BLE, but with regards to your specific question = of: =20 =E2=80=9C=E2=80=A6can CoAP in a network without running IPV6 be = implemented on BLE as is?=E2=80=9D =20 =20 My response is: =C2=B7 No, you cannot implement CoAP on a network that is not = running IPv6 (or IPv4) =C2=B7 CoAP was meant to run on an UDP/IP protocol stack. There = are many critical parts of the CoAP protocol that would break if the = underlying layers was not UDP/IP. For example: o Using the IPv6 address as a literal in the host part of the URI ( = http://tools.ietf.org/html/draft-ietf-core-coap-16#section-5.10.1 ) o Triggering IP multicast ( = http://tools.ietf.org/html/draft-ietf-core-coap-16#section-8 ) o Listening on the UDP port number = (http://tools.ietf.org/html/draft-ietf-core-coap-16#section-12.7 ) o Etc. =20 =20 So, to repeat, I do not believe that you can run CoAP on a network that = does not have IPv6 (or IPv4) underneath. =20 =20 Hope that helps. =20 =20 Best Regards, =20 =20 Akbar =20 From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Golnaz KARBASCHI Sent: Monday, May 06, 2013 9:33 AM To: core@ietf.org Subject: [core] Running CoAP over a local BLE network =20 Hello to All ,=20 =20 I have a question about running a COAP application instead of GATT based = profiles over a local network with BLE (Bluetooth Low Energy) = peripherals. The idea of using CoAP is its http friendly characteristics (RESTfull = structure) and its lightness for a constrained based network, like BLE. = BUT we do not want to have necessarily the end-to-end IP connections all = the way on our local network. =20 =20 Supposing to have a BLE local network like the figure below, with a host = node for accessing to the exterior connections (such as internet = connection) O--- BLE-----O (HOST) --------- > internet O--- BLE-----| O--- BLE-----| =20 My question is that if we don't care running IPV6 all the way to BLE = peripherals (and so don't need to implement a 6lowpan layer), is there = still any interest to use CoAP? =20 =20 And if we decided to run CoAP instead of existing structures and = profiles of BLE, can CoAP in a network without running IPV6 be = implemented on BLE as is? How should it be implemented ? Is it correct = to say that CoAP will behave just as a new profile for the BLE network?=20 Meaning that L2CAP takes care of adaptation between CoAP and lower = layers (MTU adaptation, etc.) and CoAP plays its role to have a http = friendly interface for the network ? =20 =20 Thank you in advance if any one that is familiar with BLE or not (!) can = give me more information about this question. =20 Golnaz KARBASCHI =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ------=_NextPart_000_006E_01CE50AA.468903D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"

Hi Carsten and = Akbar,

 

Thank you for your answers. =

 

Yes, I agree that there are = some parts of CoAP that are defined specifically to work with IP, but = there may be some use-cases (like mine) that cannot run the IP all the = way to the end points. I think this is a good motivation for starting = drafts like : coap with alternative transports (thanks to Bill = !):

http://datatracker.ietf.org/doc/draft-silveraj= an-core-coap-alternative-transports/).

 

Well, the question was raised = in order to know if there is still any interest to implement CoAP = over these kinds of networks that do not care about end-to-end IP = connections , but need to be compatible with other CoAP networks or at = least have http connections to exterior.

As Carels mentioned too, = ignoring IP over our internal network leads to significant saving in = overhead but may require installing an adaption/proxy at Host = level.

Another motivation of = removing IP over our LowPAN is that the ongoing draft (IPV6 over BLE) is = still not complete ! =C2=A0

 

Our use case is a wireless = BAN (Body Area Network) autonomous en battery and with BLE peripherals = from a main gateway to some sensors and other embedded constrained = devices. The gateway communicates wirelessly with a Host =C2=A0(as shown = again in the fig below) which potentially is connected to = internet.=C2=A0

=C2=A0O--- = BLE-----O (HOST) = ---------  > internet

O--- = BLE-----|

O--- = BLE-----|

 

Effectively, the pb. of CoAP = directly over BLE and instead of GATT is related to Bluetooth compliance = issues, such as defining a new channel identifier, etc.=C2=A0 But as = suggested, it can be applied to BLE as a new service over the existing = GATT profile, Though, =C2=A0at this point I am not certain that it is a = straightforward task to do !.

 

 

Regards,

=

 

Golnaz Karbaschi =

 

De : Carsten = Bormann [mailto:cabo@tzi.org]
Envoy=C3=A9 : mardi 7 mai = 2013 22:22
=C3=80 : Rahman, Akbar
Cc : = Golnaz KARBASCHI; core@ietf.org
Objet : Re: [core] = Running CoAP over a local BLE = network

 

While = this (can't run CoAP directly on BLE L2CAP) is true today, we do have = proposals for various alternative transport bindings (including SMS), so = if this is a sensible thing to do, we could look into it.  On the = BLE level, the obvious choking point is channel allocation.  I'd = like to understand the usecase some more, and build more of an opinion = when I'm back in Germany next week... 

Sent from my = iPad


On 07.05.2013, at 21:30, = "Rahman, Akbar" <Akbar.Rahman@InterDigital.c= om> wrote:

Hi = Golnaz,

 

I am not familiar with = BLE, but with regards to your specific question = of:

 

=E2=80=9C=E2=80=A6can CoAP in a network = without running IPV6 be implemented on BLE as = is?=E2=80=9D

 

 

My response = is:

=C2=B7         = No, you = cannot implement CoAP on a network that is not running IPv6 (or = IPv4)

=C2=B7         = CoAP was = meant to run on an UDP/IP protocol stack.  There are many critical = parts of the CoAP protocol that would break if the underlying layers was = not UDP/IP.  For example:

o   Using the IPv6 address as a literal in the host = part of the URI ( http://tools.ietf.org/html/draft-ietf-core-coap-16#section-5.10.1 = )

o   Triggering IP multicast ( htt= p://tools.ietf.org/html/draft-ietf-core-coap-16#section-8 = )

o   Listening on the UDP port number (= http://tools.ietf.org/html/draft-ietf-core-coap-16#section-12.7 = )

o   Etc.

 

 

So, to repeat, I do not = believe that you can run CoAP on a network that does not have IPv6 (or = IPv4) underneath.

 

 

Hope that = helps.

 

 

Best = Regards,

 

 

Akbar

 

From:= = core-bounces@ietf.org [mailto:core-bounces@ietf.org] = On Behalf Of Golnaz KARBASCHI
Sent: Monday, May 06, = 2013 9:33 AM
To: core@ietf.org
Subject: = [core] Running CoAP over a local BLE = network

 

Hello to All , =

 <= /p>

I have a question about = running a COAP application instead of GATT based profiles over a local = network with BLE (Bluetooth Low Energy) = peripherals.

The idea of using CoAP = is its http friendly characteristics (RESTfull structure) and its = lightness for a constrained based network, like BLE. BUT we do not want = to have necessarily the end-to-end IP connections all the way on our = local network. 

 <= /p>

Supposing to have a BLE = local network like the figure below, with a host node for accessing to = the exterior connections (such as internet = connection)

O--- = BLE-----O (HOST) ---------  = > internet

O--- = BLE-----|

O--- = BLE-----|

 <= /p>

My question is that if = we don't care running IPV6 all the way to BLE peripherals (and so don't = need to implement a 6lowpan layer), is there still any interest to use = CoAP?

 <= /p>

 <= /p>

And if we decided to run = CoAP instead of existing structures and profiles of BLE, can CoAP in a = network without running IPV6 be implemented on BLE as is? How should it = be implemented ?  Is it correct to say that CoAP will behave just = as a new profile for the BLE network?

Meaning that L2CAP takes = care of adaptation between CoAP and lower layers (MTU adaptation, etc.) = and CoAP plays its role to have a http friendly

interface for the = network ?   

 <= /p>

Thank you in advance if = any one that is familiar with BLE or not (!) can give me more = information about this question.

 <= /p>

Golnaz = KARBASCHI

 

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

<= /body> ------=_NextPart_000_006E_01CE50AA.468903D0-- From esko.dijk@philips.com Tue May 14 07:36: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 0885C21F8F03 for ; Tue, 14 May 2013 07:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIQFVzMdYjxm for ; Tue, 14 May 2013 07:36:24 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 492A921F8EE3 for ; Tue, 14 May 2013 07:36:23 -0700 (PDT) Received: from mail17-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Tue, 14 May 2013 14:36:22 +0000 Received: from mail17-tx2 (localhost [127.0.0.1]) by mail17-tx2-R.bigfish.com (Postfix) with ESMTP id 37BAB361140; Tue, 14 May 2013 14:36:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VPS-31(zz98dI15d6O9251Jc89bh148cI542I1447Idb82h217bIdd85kzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1730fah1033IL177df4h17326ahf69b8h8275bhz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1155h) Received: from mail17-tx2 (localhost.localdomain [127.0.0.1]) by mail17-tx2 (MessageSwitch) id 1368542179851956_7939; Tue, 14 May 2013 14:36:19 +0000 (UTC) Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.239]) by mail17-tx2.bigfish.com (Postfix) with ESMTP id 97491460047; Tue, 14 May 2013 14:36:19 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 14 May 2013 14:36:15 +0000 Received: from 011-DB3MMR1-018.MGDPHG.emi.philips.com (10.128.28.104) by 011-DB3MMR1-005.MGDPHG.emi.philips.com (10.128.28.55) with Microsoft SMTP Server (TLS) id 14.2.328.11; Tue, 14 May 2013 14:36:35 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.161]) by 011-DB3MMR1-018.MGDPHG.emi.philips.com ([10.128.28.104]) with mapi id 14.02.0328.011; Tue, 14 May 2013 14:36:04 +0000 From: "Dijk, Esko" To: Carsten Bormann Thread-Topic: [core] HTTP-CoAP default URI mapping: some draft proposals Thread-Index: Ac5P0diKwuFDFUSHQoafxpmnmeVw4AAB7rcAADV7mNA= Date: Tue, 14 May 2013 14:36:11 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C2D22A@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618C2BC0E@011-DB3MPN2-082.MGDPHG.emi.philips.com> <08B9AB24-8B84-444B-AD11-C787195754EC@tzi.org> In-Reply-To: <08B9AB24-8B84-444B-AD11-C787195754EC@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.102.41] 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] HTTP-CoAP default URI mapping: some draft proposals X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 14 May 2013 14:36:31 -0000 Thanks for the pointer; it seems that including CoAP specific options is us= eful for diagnostic purposes. Perhaps that is going to be less used for general protocol translation (i.e= . as a default mapping for non-diagnostic applications). But we could add a= requirement to at least allow, or be prepared, for inclusion of CoAP optio= ns/method-codes/etc. in the HTTP URI. If the goal is to do any CoAP operations from the browser URL line, then in= deed you need to include parameters for method, payload, etc. (There are also various HTTP libraries that can only do HTTP GET!) Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Monday, May 13, 2013 14:59 To: Dijk, Esko Cc: core (core@ietf.org) Subject: Re: [core] HTTP-CoAP default URI mapping: some draft proposals Esko, thanks for exploring this space some more. I'm intrigued by this aspect: On May 13, 2013, at 14:17, "Dijk, Esko" wrote: > communicate, in the HTTP request, specific CoAP Option values When I designed the URI scheme for coap.me, this was a requirement. But where do you put those options? There is a need to retain transparency= for the path and the query. I finally came up with something that looks like this: http://coap.me/etag=3D9032625142006256669/coap://coap.me/ (the 9032625142006256669 is just a goedelized byte string here. There is also syntax to specify the method, a payload (!), and non-confirma= ble use, which probably is very specific to the diagnostic purpose of coap.= me.) 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 esko.dijk@philips.com Tue May 14 08:03: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 70B1C21F915A for ; Tue, 14 May 2013 08:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.369 X-Spam-Level: X-Spam-Status: No, score=-5.369 tagged_above=-999 required=5 tests=[AWL=-0.631, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7QYO2pViY4r for ; Tue, 14 May 2013 08:03:27 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id E64DF21F90B9 for ; Tue, 14 May 2013 08:03:26 -0700 (PDT) Received: from mail151-co9-R.bigfish.com (10.236.132.237) by CO9EHSOBE016.bigfish.com (10.236.130.79) with Microsoft SMTP Server id 14.1.225.23; Tue, 14 May 2013 15:03:25 +0000 Received: from mail151-co9 (localhost [127.0.0.1]) by mail151-co9-R.bigfish.com (Postfix) with ESMTP id DF4152A00F4; Tue, 14 May 2013 15:03:25 +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: -28 X-BigFish: VPS-28(zz15d6O9251J1432Ic85ahdb82h217bIdd85kzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah18c673h18de19h8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1155h) Received: from mail151-co9 (localhost.localdomain [127.0.0.1]) by mail151-co9 (MessageSwitch) id 1368543802229351_3239; Tue, 14 May 2013 15:03:22 +0000 (UTC) Received: from CO9EHSMHS004.bigfish.com (unknown [10.236.132.233]) by mail151-co9.bigfish.com (Postfix) with ESMTP id 2A4DA6076B; Tue, 14 May 2013 15:03:22 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS004.bigfish.com (10.236.130.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 14 May 2013 15:03:20 +0000 Received: from 011-DB3MMR1-020.MGDPHG.emi.philips.com (10.128.28.101) by 011-DB3MMR1-007.MGDPHG.emi.philips.com (10.128.28.57) with Microsoft SMTP Server (TLS) id 14.2.328.11; Tue, 14 May 2013 15:02:48 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.161]) by 011-DB3MMR1-020.MGDPHG.emi.philips.com ([fe80::65e7:4d4c:4c67:daa9%11]) with mapi id 14.02.0328.011; Tue, 14 May 2013 15:02:55 +0000 From: "Dijk, Esko" To: Bert Greevenbosch , "core (core@ietf.org)" Thread-Topic: HTTP-CoAP default URI mapping: some draft proposals Thread-Index: Ac5P0diKwuFDFUSHQoafxpmnmeVw4AAbRkoAABxenkA= Date: Tue, 14 May 2013 15:02:54 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618C2D247@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618C2BC0E@011-DB3MPN2-082.MGDPHG.emi.philips.com> <46A1DF3F04371240B504290A071B4DB63D7271BD@szxeml558-mbx.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D7271BD@szxeml558-mbx.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [188.207.102.41] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618C2D247011DB3MPN2082MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] HTTP-CoAP default URI mapping: some draft proposals X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 14 May 2013 15:03:34 -0000 --_000_031DD135F9160444ABBE3B0C36CED618C2D247011DB3MPN2082MGDP_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable > but it misses the scheme indication as is possible Yes, indicating the scheme explicitly is also useful perhaps. I was just th= inking whether it is then allowed then to do a =1B$B!F=1B(Bhttp=1B$B!G=1B(B= (non-secured) request to fetch a =1B$B!F=1B(Bcoaps=1B$B!G=1B(B (secured) r= esource? Maybe we should look at that in light of the recent IESG DISCUSS (Stephen F= arell). There are arguments going in both directions. > I guess in scheme #4 we should mandate inclusion of the port number in th= e HTTP URI That=1B$B!G=1B(Bs possible; I think the current solution is to allow an emp= ty string also (which gives // in the path. Is that an issue?) Esko From: Bert Greevenbosch [mailto:Bert.Greevenbosch@huawei.com] Sent: Tuesday, May 14, 2013 03:19 To: Dijk, Esko; core (core@ietf.org) Subject: RE: HTTP-CoAP default URI mapping: some draft proposals Hi Esko, Thank you for your extensive description of the options and requirements. I ponder between #1 and #4. I think #1 is easier to parse, but it misses th= e scheme indication as is possible in #4. The scheme indicator needs a bit = extra complexity though, as the parser needs to determine whether the HTTP = URI component is a scheme indicator, or the domain name part. I guess there= will never be domain names "coap" and "coaps" (I hope these domain names a= re forbidden?) so we should be safe with that. If we have a default coap scheme, I think constructs like http://proxy.example.com/.well-known/core-translate//server.coap.example.co= m/4567/foo%2Fbar/a=3D3&b=3D5 should be forbidden. Another problem is how to handle the default port 5683. Does it need to be = included in the HTTP URI or not? I think we should be clear on this, such t= hat there is no ambiguity whether two different HTTP URIs point to the same= resource or not. I guess in scheme #4 we should mandate inclusion of the p= ort number in the HTTP URI, as otherwise the port number can be confused wi= th the path component. Best regards, Bert From: core-bounces@ietf.org [mailto:core-boun= ces@ietf.org] On Behalf Of Dijk, Esko Sent: 2013=1B$BG/=1B(B5=1B$B7n=1B(B13=1B$BF|=1B(B 20:18 To: core (core@ietf.org) Subject: [core] HTTP-CoAP default URI mapping: some draft proposals Dear all, below I=1B$B!G=1B(Bve listed a number of proposals that the authors of draf= t-castellani-core-http-mapping discussed. The formal specification of the s= olutions (in terms of URI template) is mostly missing, but hopefully the ex= amples make the main ideas clear. Each example shows a http URI, with which= a HTTP-CoAP cross-protocol proxy at host =1B$B!F=1B(Bproxy.example.com=1B$= B!G=1B(B is called. After the arrow (->) the extracted CoAP URI is shown, v= ia which the CoAP server at =1B$B!F=1B(Bserver.coap.example.com=1B$B!G=1B(B= is called by the proxy. After the solutions there=1B$B!G=1B(Bs a short table showing my personal (n= ot with my co-authors) first analysis of how each solution meets the requir= ements. The requirements were posted on May 8th to the list. Any feedback is welcomed! regards, Esko --- Solution #0: placeholder proposal in draft-bormann-core-cross-reverse-conve= ntion-00 URI template: tbd Example: http://proxy.example.com/.well-known/core-translate/1.2.3.4_4567/foo/= bar?a=3D3&b=3D5 -> coap://1.2.3.4:4567/foo/bar?a=3D3&b=3D5 Notes: how to include IPv6 literals was not defined. CoAP scheme is derived= from HTTP scheme (http or https). =1B$B!F=1B(B_{Port}=1B$B!G=1B(B part is = optional. Solution #1: adding IPv6 support to #0 URI Template: /.well-known/core-translate/{authority-encoded}/{path}?{query} Notes: the proxy will percent-decode the {authority-encoded} to {authority}= before constructing the COAP URI. CoAP scheme is derived from HTTP scheme = (http or https). Examples: http://proxy.example.com/.well-known/core-translate/%5B2001= ::23:25%5D:4567/foo/bar?a=3D3&b=3D5 -> coap://[2001::23:25]:4567/foo/bar?a=3D3&b=3D5 http://proxy.example.com/.well-known/core-translate/server.= coap.example.com:4567/foo/bar?a=3D3&b=3D5 -> coap://server.coap.example.com:4567/foo/bar?a=3D3&b=3D5 http://proxy.example.com/.well-known/core-translate/server.= coap.example.com/foo/bar?a=3D3&b=3D5 -> coap://server.coap.example.com/foo/bar?a=3D3&b=3D5 http://proxy.example.com/.well-known/core-translate/1.2.3.4= :4567/foo/bar?a=3D3&b=3D5 -> coap://1.2.3.4:4567/foo/bar?a=3D3&b=3D5 Solution #2: Split CoAP URI in parts and put parts in query arguments URI Template: /.well-known/core-translate/host=3D{host}&port=3D{port}&path=3D{path}?{quer= y} Note: the query parts =1B$B!F=1B(Bhost=1B$B!G=1B(B, =1B$B!F=1B(Bport=1B$B!G= =1B(B , =1B$B!F=1B(Bpath=1B$B!G=1B(B and =1B$B!F=1B(Bquery=1B$B!G=1B(B are= all optional in the URI. http://proxy.example.com/.well-known/core-translate?host=3D%5B1234::5678%5D= &port=3D4567&path=3D/foo/bar?a=3D3&b=3D5 -> coap://[1234::5678]:4567/foo/bar?a=3D3&b=3D5 Solution #3: Entire CoAP URI as single query parameter Inspired by certain web services that put http callback URIs in URI-query p= arameters. URI template: tbd Example: http://proxy.example.com/.well-known/core-translate?uri=3Dcoap%3A%2F%2F%5B1= 234%3A%3A5678%5D%3A4567%2Ffoo%2Fbar%3Fb%3Dbefore_colon%253Aafter_colon -> coap://[1234::5678]:4567/foo/bar?b=3Dbefore_colon%3Aafter_col= on Solution #4: split CoAP URI in parts and put these parts in path components URI template: /.well-known/core-translate/{scheme}/{+host}/{port}/{+path_abempty}/{+query= } where: scheme =3D "coap" / "coaps" / "" host =3D matches production defined in RFC 3986 Sec. 3.2.2. NOTE: need to percent-encode '[' and ']' in IP-literal port =3D matches production defined in RFC 3986 Sec. 3.2.3. path_abempty =3D matches production defined in RFC 3986 Sec. 3.3. NOTE: need to percent-encode any '/' occurrence query =3D matches production defined in RFC 3986 Sec. 3.4. NOTE: need to percent-encode any '/' and '?' occurrence CoAP URI is reconstructed as per RFC 3986 Sec. 5.3. carrying out the following substitutions before going through the algorithm: - if scheme is the empty string, make it "coap"; - if port is the empty string, make it "5683"; [[ - if path-abempty is the empty string, make it "/"; -- possibly not need= ed ]] Example: http://proxy.example.com/.well-known/core-translate/coap/server.coap.exampl= e.com/4567/foo%2Fbar/a=3D3&b=3D5 -> coap://server.coap.example.com:4567/foo/bar?a=3D3&b=3D5 --- URI mapping requirements Note for the current requirements : there=1B$B!G=1B(Bs currently no require= ment that the HTTP client should somehow communicate, in the HTTP request, = specific CoAP Option values to the proxy, e.g. whether the proxy should use= the Observe option or not in a CoAP request. We assume, for now, that is c= orrect. R1. Syntactic correctness of the HTTP URI (e.g. handle percent-encoding whe= n needed); R2. HTTP URI must be able include all elements of a CoAP URI (e.g. coap(s) scheme, hostname, host literals IPv4/IPv6, port, path, qu= ery components, characters allowed in CoAP URI) R3. The mapping operation must produce a string that can be directly used b= y a proxy as input to the process of core-coap section 6.4. "Decomposing UR= Is into Options". R4. HTTP URI should be easily readable/writable by humans, if possible; (e.g. easy to read the CoAP URI embedded in it; avoid multiple levels o= f percent encoding, etc.) R5. HTTP cache friendliness of the mapping solution, i.e. maximize the cach= ing of CoAP resources by HTTP intermediaries; (e.g. a solution where entire CoAP URI is provided as a single query par= ameter is bad in this respect) R6. Normalised form: preferably there should be only one "normal"/default w= ay to encode the URI (e.g. so that we don't end up with multiple different cache entries for= the same CoAP resource in intermediaries.); R7. HTTP URI should be as short as possible. #0 #1 #2 #3 #4 R1 + + + + + R2 - + + + + R3 + + + + + (where details need to be defined for each solution) R4 + + o - o R5 + + - - + R6 R7 + + - - +/o ^ tentative best option, #1 ________________________________ 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_031DD135F9160444ABBE3B0C36CED618C2D247011DB3MPN2082MGDP_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

> but it misses the scheme indication as is possi= ble

Yes, indicating the scheme explicitly is also useful= perhaps. I was just thinking whether it is then allowed then to do a =1B$B= !F=1B(Bhttp=1B$B!G=1B(B (non-secured) request to fetch a =1B$B!F=1B(Bcoaps= =1B$B!G=1B(B (secured) resource?

Maybe we should look at that in light of the recent = IESG DISCUSS (Stephen Farell). There are arguments going in both directions= .

 

> I guess in= scheme #4 we should mandate inclusion of the port number in the HTTP URI

That=1B$B!G=1B(Bs possible; I think the current solu= tion is to allow an empty string also (which gives // in the path. Is that = an issue?)

 

Esko=

 

From: Bert Gre= evenbosch [mailto:Bert.Greevenbosch@huawei.com]
Sent: Tuesday, May 14, 2013 03:19
To: Dijk, Esko; core (core@ietf.org)
Subject: RE: HTTP-CoAP default URI mapping: some draft proposals

 

Hi Esko,

 

Thank you for your extensive description of the opti= ons and requirements.

 

I ponder between #1 and #4. I think #1 is easier to = parse, but it misses the scheme indication as is possible in #4. The scheme= indicator needs a bit extra complexity though, as the parser needs to dete= rmine whether the HTTP URI component is a scheme indicator, or the domain name part. I guess there will never b= e domain names "coap" and "coaps" (I hope these domain = names are forbidden?) so we should be safe with that.

 

If we have a default coap scheme, I think constructs= like

http://p= roxy.example.com/.well-known/core-translate//server.coap.example.com/4567/f= oo%2Fbar/a=3D3&b=3D5

should be forbidden.

 

Another problem is how to handle the default port 56= 83. Does it need to be included in the HTTP URI or not? I think we should b= e clear on this, such that there is no ambiguity whether two different HTTP= URIs point to the same resource or not. I guess in scheme #4 we should mandate inclusion of the port number i= n the HTTP URI, as otherwise the port number can be confused with the path = component.

 

Best regards,

Bert

 

 

From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Dijk, Esko
Sent: 2013=1B$BG/=1B(B5=1B$B7n=1B(B13=1B$BF|=1B(B 20:18
To: core (core@ietf.org)
Subject: [core] HTTP-CoAP default URI mapping: some draft proposals<= o:p>

 

Dear all,

 

below I=1B$B!G=1B(Bve listed a number of proposal= s that the authors of draft-castellani-core-http-mapping discussed. The for= mal specification of the solutions (in terms of URI template) is mostly mis= sing, but hopefully the examples make the main ideas clear. Each example shows a http URI, with which a HTTP-CoAP cross-p= rotocol proxy at host =1B$B!F=1B(Bproxy.example.com=1B$B!G=1B(B is called. = After the arrow (->) the extracted CoAP URI is shown, via which the CoAP= server at =1B$B!F=1B(Bserver.coap.example.com=1B$B!G=1B(B is called by the= proxy.

 

After the solutions there=1B$B!G=1B(Bs a short ta= ble showing my personal (not with my co-authors) first analysis of how each= solution meets the requirements. The requirements were posted on May 8th to the list.

Any feedback is welcomed!

 

regards,

Esko

 

---

 

Solution #0: placeholder proposal in draft-bor= mann-core-cross-reverse-convention-00

 

URI template: tbd

 

Example:

      http://proxy.example.com/.well-known/core-translate/1.2.3.4_4567/foo/bar?a= =3D3&b=3D5

-> coap://1.2.3.4:4567/foo/bar?a=3D3&b=3D5=

 

Notes: how to include IPv6 literals was not defin= ed. CoAP scheme is derived from HTTP scheme (http or https). =1B$B!F=1B(B_{= Port}=1B$B!G=1B(B part is optional.

 

 

Solution #1: adding IPv6 support to #0

 

URI Template:

/.well-known/core-translate/{authority-encoded}/{= path}?{query}

 

Notes: the proxy will percent-decode the {authori= ty-encoded} to {authority} before constructing the COAP URI. CoAP scheme is= derived from HTTP scheme (http or https).

 

Examples:

        &= nbsp;       http://proxy.example.com/.well-known/core-translate/%5B2001::23:25%5D:4567/= foo/bar?a=3D3&b=3D5

->        &= nbsp;   coap://[2001::23:25]:4567/foo/bar?a=3D3&b=3D5

 

        &= nbsp;       http://proxy.example.com/.well-known/core-translate/server.coap.example.com= :4567/foo/bar?a=3D3&b=3D5

->        &= nbsp;   coap://server.coap.example.com:4567/foo/bar?a=3D3&b= =3D5

 

        &= nbsp;       http://proxy.example.com/.well-known/core-translate/server.coap.example.com= /foo/bar?a=3D3&b=3D5

->        &= nbsp;   coap://server.coap.example.com/foo/bar?a=3D3&b=3D5

 

        &= nbsp;       http://proxy.example.com/.well-known/core-translate/1.2.3.4:4567/foo/bar?a= =3D3&b=3D5

->        &= nbsp;   coap://1.2.3.4:4567/foo/bar?a=3D3&b=3D5

 

 

Solution #2: Split CoAP URI in parts and put p= arts in query arguments

 

URI Template:

/.well-known/core-translate/host=3D{host}&por= t=3D{port}&path=3D{path}?{query}

 

Note: the query parts =1B$B!F=1B(Bhost=1B$B!G=1B(= B, =1B$B!F=1B(Bport=1B$B!G=1B(B  , =1B$B!F=1B(Bpath=1B$B!G=1B(B and = =1B$B!F=1B(Bquery=1B$B!G=1B(B are all optional in the URI.

 

http://proxy.example.com/.well-known/core-translate?host=3D= %5B1234::5678%5D&port=3D4567&path=3D/foo/bar?a=3D3&b=3D5

->       &n= bsp;    coap://[1234::5678]:4567/foo/bar?a=3D3&b=3D5

 

Solution #3: Entire CoAP URI as single query p= arameter

Inspired by certain web services that put http ca= llback URIs in URI-query parameters.

 

URI template: tbd

 

Example:

http://proxy.e= xample.com/.well-known/core-translate?uri=3Dcoap%3A%2F%2F%5B1234%3A%3A5678%= 5D%3A4567%2Ffoo%2Fbar%3Fb%3Dbefore_colon%253Aafter_colon

->       &n= bsp;    coap://[1234::5678]:4567/foo/bar?b=3Dbefore_colon%3A= after_colon

 

 

Solution #4: split CoAP URI in parts and put t= hese parts in path components

 

URI template:

/.well-known/core-translate/{scheme}/{+host}/= {port}/{+path_abempty}/{+query}

 

where:

  scheme      =   =3D "coap" / "coaps" / ""

 

  host      &n= bsp;   =3D matches production defined in RFC 3986 Sec. 3.2.2.

        &= nbsp;         NOTE: need to percent= -encode '[' and ']' in IP-literal

 

  port      &n= bsp;   =3D matches production defined in RFC 3986 Sec. 3.2.3.

 

  path_abempty  =3D matches production = defined in RFC 3986 Sec. 3.3.

        &= nbsp;         NOTE: need to percent= -encode any '/' occurrence

 

  query      &= nbsp;  =3D matches production defined in RFC 3986 Sec. 3.4.=

         =          NOTE: need to percent= -encode any '/' and '?' occurrence

 

  CoAP URI is reconstructed as per RFC 3986 = Sec. 5.3. carrying out the

  following substitutions before going throu= gh the algorithm:

 

  - if scheme is the empty string, make it &= quot;coap";

  - if port is the empty string, make it &qu= ot;5683";

[[ - if path-abempty is the empty string, make it= "/"; -- possibly not needed ]]

 

Example:

http://proxy.example.com/.well-known/core-translate= /coap/server.coap.example.com/4567/foo%2Fbar/a=3D3&b=3D5=

->        &= nbsp;   coap://server.coap.example.com:4567/foo/bar?a=3D3&b= =3D5

 

---

 

URI mapping requirements

 

Note for the current requirements : there= =1B$B!G=1B(Bs currently no requirement that the HTTP client should somehow = communicate, in the HTTP request, specific CoAP Option values to the proxy,= e.g. whether the proxy should use the Observe option or not in a CoAP request. We assume, for now, that is correct.=

 

R1. Syntactic correctness of the HTTP URI (e.g. hand= le percent-encoding when needed);

 

R2. HTTP URI must be able include all elements of a = CoAP URI

    (e.g. coap(s) scheme, hostna= me, host literals IPv4/IPv6, port, path, query components, characters allow= ed in CoAP URI)

 

R3. The mapping operation must produce a string that= can be directly used by a proxy as input to the process of core-coap secti= on 6.4. "Decomposing URIs into Options".

 

R4. HTTP URI should be easily readable/writable by h= umans, if possible;

    (e.g. easy to read the CoAP URI e= mbedded in it; avoid multiple levels of percent encoding, etc.)<= /p>

 

R5. HTTP cache friendliness of the mapping solution,= i.e. maximize the caching of CoAP resources by HTTP intermediaries;

   (e.g. a solution where entire CoAP URI = is provided as a single query parameter is bad in this respect)<= /p>

 

R6. Normalised form: preferably there should be only= one "normal"/default way to encode the URI

    (e.g. so that we don't end up wit= h multiple different cache entries for the same CoAP resource in intermedia= ries.);

 

R7. HTTP URI should be as short as possible.

 

=    #0 #1 #2 #3 #4

= R1  +  +  +  +  +<= /o:p>

= R2  -  +  +  +  +

= R3  +  +  +  +  +  (where= details need to be defined for each solution)

= R4  +  +  o  -  o

= R5  +  +  -  -  +

= R6  <to be checked>

= R7  +  +  -  -  +/o<= /p>

        &nbs= p;            ^=

=      tentative best option, #1

=  

=  

 

 

 

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

--_000_031DD135F9160444ABBE3B0C36CED618C2D247011DB3MPN2082MGDP_-- From carlesgo@entel.upc.edu Tue May 14 10:21: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 D794C21F90FC for ; Tue, 14 May 2013 10:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7quNqngyxu-9 for ; Tue, 14 May 2013 10:20:59 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by ietfa.amsl.com (Postfix) with ESMTP id DA49521F90EA for ; Tue, 14 May 2013 10:20:51 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id r4EHKno0008104 for ; Tue, 14 May 2013 19:20:49 +0200 Received: from webmail.entel.upc.edu (www-entel.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 8C9FF2CBD0E for ; Tue, 14 May 2013 19:20:43 +0200 (CEST) Received: from 10.189.135.246 by webmail.entel.upc.edu with HTTP; Tue, 14 May 2013 19:20:43 +0200 Message-ID: In-Reply-To: <006d01ce5099$830033d0$89009b70$@karbaschi@eolane.com> References: <005e01ce4a5e$413dbf30$c3b93d90$@karbaschi@eolane.com> <006d01ce5099$830033d0$89009b70$@karbaschi@eolane.com> Date: Tue, 14 May 2013 19:20:43 +0200 From: "Carles Gomez Montenegro" To: core@ietf.org User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Tue, 14 May 2013 19:20:49 +0200 (CEST) Subject: Re: [core] Running CoAP over a local BLE network X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 14 May 2013 17:21:14 -0000 Hi Golnaz, > Another motivation of removing IP over our LowPAN is that the ongoing > draft (IPV6 over BLE) is still not complete ! The last pending IESG DISCUSS on the draft is which L2CAP Channel ID(s) may be used for 6LoWPAN. Besides this, I think there will be no further changes to the draft. > Effectively, the pb. of CoAP directly over BLE and instead of GATT is > related to Bluetooth compliance issues, such as defining a new channel > identifier, etc. But as suggested, it can be applied to BLE as a new > service over the existing GATT profile, Though, at this point I am not > certain that it is a straightforward task to do !. I have not analyzed in detail this approach, but one first comment I have is that there would be some (possibly large) degree of functionality duplication between GATT/ATT and CoAP on top of it. Isn't GATT/ATT alone good enough for the peripherals in your use case? Regards, Carles From golnaz.karbaschi@eolane.com Wed May 15 04:23: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 8B0E821F8F15 for ; Wed, 15 May 2013 04:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 311iDU+0ElvQ for ; Wed, 15 May 2013 04:23:47 -0700 (PDT) Received: from relay.martec.fr (relay.martec.fr [92.103.79.186]) by ietfa.amsl.com (Postfix) with ESMTP id 41ED221F8EB9 for ; Wed, 15 May 2013 04:23:46 -0700 (PDT) Received: from webmail.martec.fr (unknown [192.168.20.3]) by relay.martec.fr (Postfix) with ESMTP id 15B0440C132; Wed, 15 May 2013 13:23:45 +0200 (CEST) Received: from CL563 ([192.168.20.158]) by webmail.martec.fr (Lotus Domino Release 8.5) with ESMTP id 2013051513234500-5401 ; Wed, 15 May 2013 13:23:45 +0200 From: "Golnaz KARBASCHI" To: "'Carles Gomez Montenegro'" , References: <005e01ce4a5e$413dbf30$c3b93d90$@karbaschi@eolane.com> <006d01ce5099$830033d0$89009b70$@karbaschi@eolane.com> In-Reply-To: Date: Wed, 15 May 2013 13:23:40 +0200 Organization: =?us-ascii?Q?eolane?= Message-ID: <00bf01ce515e$a95579d0$fc006d70$@karbaschi@eolane.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5Qx10KNiJntfevRamK6RaOoNfYsgAf4YeA X-MIMETrack: Itemize by SMTP Server on srvm1/martec_sevres/FR(Release 8.5|December 05, 2008) at 15/05/2013 13:23:45, Serialize by Router on srvm1/martec_sevres/FR(Release 8.5|December 05, 2008) at 15/05/2013 13:23:45, Serialize complete at 15/05/2013 13:23:45 X-TNEFEvaluated: 1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Content-Language: fr Subject: Re: [core] Running CoAP over a local BLE network X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 15 May 2013 11:23:52 -0000 Hi Carels, >> Another motivation of removing IP over our LowPAN is that the ongoing >> draft (IPV6 over BLE) is still not complete ! > The last pending IESG DISCUSS on the draft is which L2CAP Channel ID(s) may be used for 6LoWPAN. Besides this, I think >there will be no further changes to the draft. [Golnaz] Yes, it is in the pending state waiting for BT SIG to decide about Channel ID. But for this reason, there is no commercial stable stack that supports IPV6+BLE. So may be good for prototyping . > Effectively, the pb. of CoAP directly over BLE and instead of GATT is > related to Bluetooth compliance issues, such as defining a new channel > identifier, etc. But as suggested, it can be applied to BLE as a new > service over the existing GATT profile, Though, at this point I am > not certain that it is a straightforward task to do !. >I have not analyzed in detail this approach, but one first comment I have is that there would be some (possibly large) >degree of functionality duplication between GATT/ATT and CoAP on top of it. Isn't GATT/ATT alone good enough for the >peripherals in your use case? [Golnaz] > Actually GATT/ATT is good enough for data exchange in our use case. The only reason for looking at CoAP is benefiting from its interoperability with other CoAP networks and also its compatibility with http connections. Regards, Golnaz From tsavo.stds@gmail.com Wed May 15 04:52: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 6370B21F8A53 for ; Wed, 15 May 2013 04:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ot9wrI10o7Ko for ; Wed, 15 May 2013 04:52:17 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 85D6021F8793 for ; Wed, 15 May 2013 04:52:16 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so1524819wgh.12 for ; Wed, 15 May 2013 04:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=tqvkQ82n9wgRN/tlrWXEEDYUKaifVGC8A/c5VIfdC6o=; b=WjISDnxu/nvLJsgZmIEsrY3QTjpEvOFmYlZhw6CAknAnsX8OWLGJMrehWM6EZHpVb6 sDSFMaYsX0ZxlFLoe0RTIuOB3+vI5v1V2i6fQB/SO6ly6ujANUZgP0fYBJcdaeGGgibg UQLGvwnVCtMm+Yrf+bDzUouUgJalAaDHbEbMc1ITn27Xor0RvMkDGXmMJa6uPTNVNdtc V5q6LqLNtBZdDmz6tIZLTU1OBBhS+4uJxWTrgQvqwJ5nXvkqkI/q1eRIEjfku38yyIRx 5Fn8FzF2rL4w1oRWA4Rzee1tL3KFkk37H6fwKrZSuPafMyduhSmBLpJuPOzU2i7GKdE8 p2xg== MIME-Version: 1.0 X-Received: by 10.194.174.228 with SMTP id bv4mr3600464wjc.47.1368618728750; Wed, 15 May 2013 04:52:08 -0700 (PDT) Received: by 10.194.240.36 with HTTP; Wed, 15 May 2013 04:52:08 -0700 (PDT) Received: by 10.194.240.36 with HTTP; Wed, 15 May 2013 04:52:08 -0700 (PDT) In-Reply-To: <519225be.85f8420a.7287.ffffd4c7SMTPIN_ADDED_BROKEN@mx.google.com> References: <519225be.85f8420a.7287.ffffd4c7SMTPIN_ADDED_BROKEN@mx.google.com> Date: Wed, 15 May 2013 14:52:08 +0300 Message-ID: From: Teemu Savolainen To: Golnaz KARBASCHI Content-Type: multipart/alternative; boundary=089e01493d5e2903d604dcc06121 Cc: core@ietf.org Subject: Re: [core] Running CoAP over a local BLE network X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 15 May 2013 11:52:17 -0000 --089e01493d5e2903d604dcc06121 Content-Type: text/plain; charset=ISO-8859-1 While I do have interest to think about CoAP over BLE.. > Another motivation of removing IP over our LowPAN is that the ongoing draft (IPV6 over BLE) is still not complete ! .. I do not think this to be sound reason, as highly likely IPv6 over BLE is standard faster than any other standardized approach for transmitting CoAP over BLE.. All other approaches would start from scratch in BT SIG and by the time process has been gone through, IPv6 would be out of the pipeline already. Best regards, Teemu --089e01493d5e2903d604dcc06121 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

While I do have interest to think about CoAP over BLE..

> Another motivation of removing IP over our LowPAN is th= at the ongoing draft (IPV6 over BLE) is still not complete ! =A0

.. I do not think this to be sound reason, as highly likely = IPv6 over BLE is standard faster than any other standardized approach for t= ransmitting CoAP over BLE.. All other approaches would start from scratch i= n BT SIG and by the time process has been gone through, IPv6 would be out o= f the pipeline already.

Best regards,

Teemu

--089e01493d5e2903d604dcc06121-- From Markus.Isomaki@nokia.com Wed May 15 06:02: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 D4B7421F85EF for ; Wed, 15 May 2013 06:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUXz1Z94pXjA for ; Wed, 15 May 2013 06:02:34 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7648B21F8FFA for ; Wed, 15 May 2013 06:02:34 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r4FD2OY3019785; Wed, 15 May 2013 16:02:27 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 May 2013 16:02:25 +0300 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.167]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0328.011; Wed, 15 May 2013 13:02:17 +0000 From: To: , Thread-Topic: [core] Running CoAP over a local BLE network Thread-Index: AQHOUWKqgBeKkZJfl0Gs/Ct7ISSemZkGMapA Date: Wed, 15 May 2013 13:02:15 +0000 Message-ID: References: <519225be.85f8420a.7287.ffffd4c7SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IpJzChw7VTBzdB8QDAfArAD+QwYISkNUQY7DxDA1W0K/AmxcfuThgHMMew/Zx0OuVMHMRdSz/bMcakFxe0ZR0o4tG1dA911RM4L3idHLc84TrafNmZPA2iF7/uNDX6pWqTqdev7s47b7SEDEHTPIk0MfB0DujfrJEpoigY67/BAirjsM1V3UxVfHCcXUiPWC+vCTnofWkPVc6awhGYdfRh/x3aB0Uo1iZ7JVYyhh8AjISnWPJ4FQL5TcsDuQozXj1w== x-originating-ip: [91.152.111.11] Content-Type: multipart/alternative; boundary="_000_E44893DD4E290745BB608EB23FDDB76209FE9FC0008AM1MPN1043mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 15 May 2013 13:02:25.0643 (UTC) FILETIME=[724F23B0:01CE516C] X-Nokia-AV: Clean Cc: core@ietf.org Subject: Re: [core] Running CoAP over a local BLE network X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 15 May 2013 13:02:40 -0000 --_000_E44893DD4E290745BB608EB23FDDB76209FE9FC0008AM1MPN1043mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I can see two main approaches for CoAP over BLE that each have unique advan= tages: 1.) CoAP over GATT over BLE: This is a kludge of layers above layers, bu= t its unique advantage is that you could implement it with today's off-the-= shelf BLE HW and SW stacks that often only offer GATT-based third party API= s. CoAP over GATT could be transparently mapped to CoAP/UDP/IP or as beind = developed in CoRE WG to HTTP/TCP/IP. 2.) CoAP over 6LoWPAN over BLE: This is the end-to-end IP solution, and = something both IETF and BT SIG are alrady standardizing, so it has the adva= ntages associated with IP and 6LoWPAN-based efficiency (low overhead), and = if the BLE vendors care about CoAP and/or IP this is the standard they shou= ld primarily follow. CoAP over BLE might IMHO fall into the middle: You still would not be able = to implement it as a third party "app" on top of existing BLE GATT stacks e= .g. in a smartphone or a tablet with BLE support, and you would not get it = standardized faster than 6LoWPAN over BLE. So it would not have neither spe= ed nor generality advantages. Having said that, these are just my assumptions and if they can be realisti= cally challenged, it might be worthwhile to look into this further. Markus From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of ext= Teemu Savolainen Sent: 15 May, 2013 14:52 To: Golnaz KARBASCHI Cc: core@ietf.org Subject: Re: [core] Running CoAP over a local BLE network While I do have interest to think about CoAP over BLE.. > Another motivation of removing IP over our LowPAN is that the ongoing dra= ft (IPV6 over BLE) is still not complete ! .. I do not think this to be sound reason, as highly likely IPv6 over BLE i= s standard faster than any other standardized approach for transmitting CoA= P over BLE.. All other approaches would start from scratch in BT SIG and by= the time process has been gone through, IPv6 would be out of the pipeline = already. Best regards, Teemu --_000_E44893DD4E290745BB608EB23FDDB76209FE9FC0008AM1MPN1043mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

I can see two main approa= ches for CoAP over BLE that each have unique advantages:<= /p>

1.)&nb= sp;   CoAP over GATT ov= er BLE: This is a kludge of layers above layers, but its unique advantage i= s that you could implement it with today’s off-the-shelf BLE HW and SW stacks that often only offer GATT-based third party APIs. Co= AP over GATT could be transparently mapped to CoAP/UDP/IP or as beind devel= oped in CoRE WG to HTTP/TCP/IP.

2.)&nb= sp;   CoAP over 6LoWPAN= over BLE: This is the end-to-end IP solution, and something both IETF and = BT SIG are alrady standardizing, so it has the advantages associated with IP and 6LoWPAN-based efficiency (low overhead), and if the= BLE vendors care about CoAP and/or IP this is the standard they should pri= marily follow.

 <= /p>

CoAP over BLE might IMHO = fall into the middle: You still would not be able to implement it as a thir= d party “app” on top of existing BLE GATT stacks e.g. in a smartphone or a tablet with BLE support, and you would not get it standa= rdized faster than 6LoWPAN over BLE. So it would not have neither speed nor= generality advantages.

 <= /p>

Having said that, these a= re just my assumptions and if they can be realistically challenged, it migh= t be worthwhile to look into this further.

 <= /p>

Markus<= /p>

 <= /p>

 <= /p>

From: core-bounces@ietf.org [mailto:core-bounces@ie= tf.org] On Behalf Of ext Teemu Savolainen
Sent: 15 May, 2013 14:52
To: Golnaz KARBASCHI
Cc: core@ietf.org
Subject: Re: [core] Running CoAP over a local BLE network=

 

While I do have interest to think about CoAP over BLE..

> Another motivation of removing IP over our LowPAN is that the ongoi= ng draft (IPV6 over BLE) is still not complete !  

.. I do not think this to be sound reason, as highly likely IPv6 over BL= E is standard faster than any other standardized approach for transmitting = CoAP over BLE.. All other approaches would start from scratch in BT SIG and= by the time process has been gone through, IPv6 would be out of the pipeline already.

Best regards,

Teemu

--_000_E44893DD4E290745BB608EB23FDDB76209FE9FC0008AM1MPN1043mg_-- From bilhanan.silverajan@tut.fi Wed May 15 07:10: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 8C60821F85D6 for ; Wed, 15 May 2013 07:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9+ct2XQvU8L for ; Wed, 15 May 2013 07:10:29 -0700 (PDT) Received: from mail.cs.tut.fi (mail.cs.tut.fi [130.230.4.42]) by ietfa.amsl.com (Postfix) with SMTP id F16CE21F84F2 for ; Wed, 15 May 2013 07:10:27 -0700 (PDT) Received: from amavis2.cs.tut.fi (amavis2.cs.tut.fi [130.230.4.70]) by mail.cs.tut.fi (Postfix) with ESMTP id DCEB591B; Wed, 15 May 2013 17:10:25 +0300 (EEST) Received: from mail.cs.tut.fi ([130.230.4.42]) by amavis2.cs.tut.fi (amavis2.cs.tut.fi [130.230.4.70]) (amavisd-maia, port 10024) with ESMTP id 29806-17; Wed, 15 May 2013 17:10:24 +0300 (EEST) Received: from [192.168.252.185] (dyn-182-12.public.tut.fi [130.230.182.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id 621EB91A; Wed, 15 May 2013 17:10:24 +0300 (EEST) Message-ID: <5193974F.2000207@tut.fi> Date: Wed, 15 May 2013 17:10:23 +0300 From: Bill Silverajan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Golnaz KARBASCHI References: <005e01ce4a5e$413dbf30$c3b93d90$@karbaschi@eolane.com> <006d01ce5099$830033d0$89009b70$@karbaschi@eolane.com> In-Reply-To: <006d01ce5099$830033d0$89009b70$@karbaschi@eolane.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.2 Cc: core@ietf.org Subject: Re: [core] Running CoAP over a local BLE network X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 15 May 2013 14:10:34 -0000 Hi Golnaz, On 14/5/2013 2:52 PM, Golnaz KARBASCHI wrote: > Hi Carsten and Akbar, > > > > Thank you for your answers. > > > > Yes, I agree that there are some parts of CoAP that are defined specifically to work with IP, but there may be some use-cases (like mine) that cannot run the IP all the way to the end points. I think this is a good motivation for starting drafts like : coap with alternative transports (thanks to Bill !): > > http://datatracker.ietf.org/doc/draft-silverajan-core-coap-alternative-transports/). > > Thanks firstly for the endorsement of our draft :-) Indeed, one of the main intentions of the work was to have a slightly out-of-the-box re-think about what it means to do REST-based resource retrieval using CoAP, and decoupling it from the underlying transport. > > Well, the question was raised in order to know if there is still any interest to implement CoAP over these kinds of networks that do not care about end-to-end IP connections , but need to be compatible with other CoAP networks or at least have http connections to exterior. > There has been interest about doing that with CoAP, and another draft (https://datatracker.ietf.org/doc/draft-becker-core-coap-sms-gprs/) providing substantial evidence that CoAP's benefits can be employed over networks not worrying about end-to-end IP, and instead focusing on end-to-end CoAP (if it can be called that). > As Carels mentioned too, ignoring IP over our internal network leads to significant saving in overhead but may require installing an adaption/proxy at Host level. > > Another motivation of removing IP over our LowPAN is that the ongoing draft (IPV6 over BLE) is still not complete ! > > > > Our use case is a wireless BAN (Body Area Network) autonomous en battery and with BLE peripherals from a main gateway to some sensors and other embedded constrained devices. The gateway communicates wirelessly with a Host (as shown again in the fig below) which potentially is connected to internet. > > O--- BLE-----O (HOST) --------- > internet > > O--- BLE-----| > > O--- BLE-----| > > > > Effectively, the pb. of CoAP directly over BLE and instead of GATT is related to Bluetooth compliance issues, such as defining a new channel identifier, etc. But as suggested, it can be applied to BLE as a new service over the existing GATT profile, Though, at this point I am not certain that it is a straightforward task to do !. > The advantage of deploying CoAP over BLE (assuming L2CAP) is that L2CAP semantics and behaviour can mimic that of UDP. It's trivial to implement this in lab-based proof of concept prototypes. Unfortunately as discussed earlier, it's not something that can be realistically deployed in products, for all the reasons mentioned. As I see it, the choices are: CoAP over 6LowPAN adaptation layer over BLE, or CoAP over GATT over BLE. In both cases, an adaptation layer will be necessary for standards compliance and will introduce overhead and possibly an overlap of functionality, either with the underlying BLE stack or with how resources and attributes are represented. So it's either end-to-end IP or end-to-end REST, depending on which you prefer. If the CoAP + GATT solution is chosen, at least these issues should be considered: * Can you integrate the CoAP resource identification into the service/characteristic model of GATT? In this case, it's worth to consider whether your abstraction is really CoAP over GATT, or a CoAP-GATT proxy. * Can you extend CoAP group communication/service discovery to leverage, again, the GATT/ATT profiles and what are its implications towards active discovery using SDP over BR/EDR * Can you unambiguously identify the resource being served with CoAP to point to the correct 16-bit handle, uuid, ble address and so on so that any other CoAP end point might retrieve the resource regardless of what transport is being used? I don't have any empirical evidence to support one approach over the other, in terms of performance, signalling, efficiency, etc unfortunately. However, at least until the 6LowPAN over BLE work is finalised and standardised, perhaps there's a larger number of devkits /sdks supporting service prototyping over GATT? Regards, Bill -- | Bilhanan Silverajan Tel: +358 (0)40 849 0757 | | Tampere University of Technology, Finland | From rlb@ipv.sx Wed May 15 09:06: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 B94F921F901B for ; Wed, 15 May 2013 09:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.062 X-Spam-Level: X-Spam-Status: No, score=-1.062 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 mOL7PIwKBZW9 for ; Wed, 15 May 2013 09:06:00 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8310321F9017 for ; Wed, 15 May 2013 09:06:00 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id va2so2208222obc.13 for ; Wed, 15 May 2013 09:06:00 -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=LNNzhAL5gRkt5pxFIuuzXTTGEXX1StvCMDCwL2cEC00=; b=R/JBVMFdEhp6qN1FOzp+ijHyr9yUqB59qimXBK9mrVirz8ccsqMmaudJoOnq9+jdFG yG5tTSSA9UKdcTmsnPFW7WixhysusDgTmQcy7GgvAnCbvvPY20BwNnBAa/tbRSBqPlmR r38ziyObsGRv/D5jKXNBEiCjgwOxk76y6EF1klUoagIBFON3MmG4Dws8p3a2qA3VZIQD AYkTGNKFjJetLZjZCL2kK6A3sgMiW8dARlNrAOWLTpM/8ouoL+3Y4QmTUyYPV+p5Mc4W P5ZmMkGk9QWKdRKaIaxexpmMXetMI7bpB8OctnP+7kN3hBM58nn79Bd0mBkvf9ks+rdY P7Qw== MIME-Version: 1.0 X-Received: by 10.60.35.100 with SMTP id g4mr8397723oej.53.1368633960026; Wed, 15 May 2013 09:06:00 -0700 (PDT) Received: by 10.60.141.132 with HTTP; Wed, 15 May 2013 09:05:59 -0700 (PDT) X-Originating-IP: [128.89.254.24] In-Reply-To: <0EB9BEF9-AF13-4ADF-858D-38B7418D7232@tzi.org> References: <20130425032117.15766.38491.idtracker@ietfa.amsl.com> <0EB9BEF9-AF13-4ADF-858D-38B7418D7232@tzi.org> Date: Wed, 15 May 2013 17:05:59 +0100 Message-ID: From: Richard Barnes To: Carsten Bormann Content-Type: multipart/alternative; boundary=089e013c68a003e67604dcc3edd6 X-Gm-Message-State: ALoCoQmGDA+1NBVsQvhxBmifhVeHUODZML9M1aOKNUyJKFOy4pMRW+RO+i3eCpWjGTwJsQrYIr5O X-Mailman-Approved-At: Wed, 15 May 2013 09:50:20 -0700 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: Wed, 15 May 2013 16:06:04 -0000 --089e013c68a003e67604dcc3edd6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, Carsten. The new text on token length and mitigations helps a lot. I would still prefer that the 32 bit minimum be a MUST, but it's close enough that I've cleared. --Richard On Mon, Apr 29, 2013 at 10:57 AM, Carsten Bormann wrote: > 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 t= o > plan for it. > Whatever we define now is likely to be wrong when we actually know what w= e > 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, includin= g > 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.) > > 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. > > Good idea! > [1329] > > This might > be a bad idea, but: Did the WG consider allowing an ACK to contai= n > 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.) > > --089e013c68a003e67604dcc3edd6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks, Carsten. =A0The new text on token length and mitig= ations helps a lot. =A0I would still prefer that the 32 bit minimum be a MU= ST, but it's close enough that I've cleared.

--Richard


On Mon, Apr 29, 2013 at 10:57 AM, Carsten Bormann <cabo@tzi.org>= wrote:
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 th= e
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

=A0 =A0 =A0 =A0 -----------------------------------------------------------= -----------
=A0 =A0 =A0 =A0 DISCUSS:
=A0 =A0 =A0 =A0 -----------------------------------------------------------= -----------

=A0 =A0 =A0 =A0 Overall, this is a very nicely written specification. =A0Th= anks! =A0There's
=A0 =A0 =A0 =A0 just one point I think needs action on before I switch to a= "YES"
=A0 =A0 =A0 =A0 position.

=A0 =A0 =A0 =A0 In Section 5.3.1, "A client sending a request..."= . =A0This needs to be
=A0 =A0 =A0 =A0 stronger. =A0The requirement for a randomized token needs t= o be a MUST, and
=A0 =A0 =A0 =A0 the stack SHOULD limit the number of rejected responses (be= fore closing
=A0 =A0 =A0 =A0 the request) based on the length of the token (e.g., 2**(TK= L/2)).

(See also Stephen's most recent reply:
http://www.ietf.org/mail-archive/web/core/current/msg043= 02.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 th= e 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. =A0We don't have=
experience with that yet. =A0One issue might be correlating incoming
non-matching responses to a specific request. =A0As with any lockdown
mechanism, the potential for DoS (or pure malfunction) also needs to
be considered. =A0A client that keeps some state can tally recent
non-matching responses to derive a "current attack level"; this m= ight
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 "clou= d"
side as well.)

-> Ticket

=A0 =A0 =A0 =A0 -----------------------------------------------------------= -----------
=A0 =A0 =A0 =A0 COMMENT:
=A0 =A0 =A0 =A0 -----------------------------------------------------------= -----------

=A0 =A0 =A0 =A0 In Section 2.2., are requests and responses in 1-1 correspo= ndence? =A0Or
=A0 =A0 =A0 =A0 can a single request receive more than one response?

Section 2.2 doesn't explain that, but, indeed, a request might re= ceive
more than one response, which we use for multicast and
draft-ietf-core-observe, (and, for future methods, even less than one
response). =A0I think I'd rather discuss this in section 5, though.

-> Ticket

=A0 =A0 =A0 =A0 In Section 3, why is version number 1 and not 0? =A0What= 9;s the plan here,
=A0 =A0 =A0 =A0 do we get 3 or 4 versions out of this?


(A version number 4 could be represented modulo 4, i.e. as 0. =A0But:= )

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 i= s likely to change the message layout enough that it's not even clear w= hat 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 un= knowns.
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.


=A0 =A0 =A0 =A0 In Section 4.3, would it make sense to have something stron= ger than MAY
=A0 =A0 =A0 =A0 for cases where future messages are likely to be screwed up= , e.g., where
=A0 =A0 =A0 =A0 CoAP syntax is malformed? =A0(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.)

=A0 =A0 =A0 =A0 From Section 4.2 and 4.3, I generated a table mapping messa= ge types to
=A0 =A0 =A0 =A0 request/response/empty:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0CON NON ACK RST
=A0 =A0 =A0 =A0 Request =A0 =A0 X =A0 X =A0 ? =A0 !
=A0 =A0 =A0 =A0 Response =A0 =A0X =A0 X =A0 X =A0 !
=A0 =A0 =A0 =A0 Empty =A0 =A0 =A0 ! =A0 ! =A0 X =A0 X
=A0 =A0 =A0 =A0 Might be helpful to include something like that as a summar= y.

Good idea!
[1329]

=A0 =A0 =A0 =A0 This might
=A0 =A0 =A0 =A0 be a bad idea, but: Did the WG consider allowing an ACK to = contain a
=A0 =A0 =A0 =A0 request? =A0In the case where a CON contains a response and= the client
=A0 =A0 =A0 =A0 wants to send another request, it would save a message to p= ut the request
=A0 =A0 =A0 =A0 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. =A0That 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.)


--089e013c68a003e67604dcc3edd6-- From spencer@wonderhamster.org Wed May 15 10:47:19 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFE821F89E8; Wed, 15 May 2013 10:47:19 -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 3yy+7BA6Qyyz; Wed, 15 May 2013 10:47:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC4421F8CBF; Wed, 15 May 2013 10:47:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Spencer Dawkins" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130515174718.15782.5640.idtracker@ietfa.amsl.com> Date: Wed, 15 May 2013 10:47:18 -0700 Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Spencer Dawkins' Discuss on draft-ietf-core-coap-16: (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, 15 May 2013 17:47:19 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-core-coap-16: 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: ---------------------------------------------------------------------- Note that I plan to ballot Yes, after we resolve these questions. = I have three points - the first one is the one I'm most curious about. = In 4.8.1. Changing The Parameters It is recommended that an application environment use consistent values for these parameters. I'm thinking about this in an IOT/M2M context where it's somewhere between inconvenient and impossible to change parameters on all the deployed devices at once. I understand that configuring these parameters is out of scope for the doc, so assume changing the parameters is out of scope as well. If you start deploying new devices into that environment with significantly different parameters, is it more likely that performance would suffer, or that something would break? (I don't care what the answer is, I'd just like for the reader to have one - do you HAVE to get the parameters right the first time, or do you WANT to get them right, but you can deploy new devices with different parameters and let the old devices be removed/replaced over time?) This one is on the edge of being a Comment: = In 5.10.5. Max-Age The value is intended to be current at the time of transmission. Servers that provide resources with strict tolerances on the value of Max-Age SHOULD update the value before each retransmission. Will servers know that resources they serve have strict tolerances? The answer may be "yes", I'm just asking. If not, I'm wondering if this should be a MUST. This one is on the edge of being a comment: = In 7.2. Resource Discovery The discovery of resources offered by a CoAP endpoint is extremely important in machine-to-machine applications where there are no humans in the loop and static interfaces result in fragility. A CoAP endpoint SHOULD support the CoRE Link Format of discoverable resources as described in [RFC6690]. Is it obvious that this is a SHOULD? Is CoRE Link Format necessary for resource discovery, or can you also accomplish this with humans if they're in the loop? I'm just trying to wrap my head around "it's extremely important but implementations might not do it". ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think this specification is well-written, it's important, and a lot of people will need to read it - that's why I'm being picky on comments. Martin already has a DISCUSS about some of the more transport-ish topics (support for UDP-lite, etc.). I'm sympathetic, but didn't restate them. If Martin is happy, I'll be happy. = In this text: Constrained networks like 6LoWPAN support the expensive fragmentation of IPv6 packets into small link-layer frames. Is "support" the right word here? I'm not understanding "support the expensive fragmentation". In this text: Although CoAP could be used for compressing simple HTTP interfaces Is "compressing ... interfaces" the right way to say this? I've seen other reviewers mention "short messages" in "CoAP is based on the exchange of short messages", but it may also be worth clearly distinguishing "short message" from "SMS" ("short message service") - as I understand it, the two phrases have nothing in common, but they are both used in the document (at the beginning of Section 3, and even in the same paragraph) without qualification. Response codes correspond to a small subset of HTTP response codes with a few CoAP specific codes added, as defined in Section 5.9. I get this, but I'm wondering if it's worth thinking about whether these similar but unrelated namespaces can semi-collide (if HTTP is extended to include a 328 response code, is it OK for CoAP to define a 3.28 response code that means nothing like what HTTP 328 means?) Given that 404 and 4.04 are similar, for example, I'd expect some implementers to guess what less common CoAP response codes are, based on HTTP response codes, rather than check carefully. That's an obscure comment, but I thought I should ask. In 6.4. Decomposing URIs into Options, is "fail this algorithm" clear? It might be a term of art for HTTP folk, but I'm not familiar with it. 4. If |url| has a component, then fail this algorithm. In 8.1. Messaging Layer 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. Doesn't this tell me that the MUST NOT is not required for interoperability? I'm only quibbling about the use of 2119 language. On a related point, if there was a sentence that started out "to keep Bad Thing X from happening, ..." that would be helpful. There's similar language in 8.2. Request/Response Layer When a server is aware that a request arrived via multicast, the server MAY always ignore the request, in particular if it doesn't have anything useful to respond (e.g., if it only has an empty payload or an error response). but MAY is pretty weak anyway (maybe "can always ignore the request", to avoid the 2119 question?). In 11.3. Risk of amplification This is particularly a problem in nodes that enable NoSec access, that are accessible from an attacker and can access potential victims (e.g. on the general Internet), as the UDP protocol provides no way to verify the source address given in the request packet. An attacker need only place the IP address of the victim in the source address of a suitable request packet to generate a larger packet directed at the victim. Such large amplification factors SHOULD NOT be done in the response if the request is not authenticated. I don't understand what the SHOULD NOT means in practice. Is this saying the server shouldn't return large resources for NoSec requests (whatever "large" means), or ? If this is saying the same thing as the text on using "slicing/blocking mode" two paragraphs, down, it would be clearer to combine these points in a single paragraph. From Martin.Stiemerling@neclab.eu Wed May 15 12:34:19 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83D821F8709; Wed, 15 May 2013 12:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 LS9g4c6l6E2F; Wed, 15 May 2013 12:34:15 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id E048A21F86F4; Wed, 15 May 2013 12:34:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 2FA8E1041B3; Wed, 15 May 2013 21:34:10 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtYo-k0RJDOh; Wed, 15 May 2013 21:34:10 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 114671041A8; Wed, 15 May 2013 21:33:45 +0200 (CEST) Received: from [10.7.0.105] (10.7.0.105) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 May 2013 21:33:24 +0200 Message-ID: <5193E302.7010101@neclab.eu> Date: Wed, 15 May 2013 21:33:22 +0200 From: Martin Stiemerling 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: <20130424092228.10345.76059.idtracker@ietfa.amsl.com> <8C88F8A7-9B07-4D82-8EA8-89794BD32EFC@tzi.org> In-Reply-To: <8C88F8A7-9B07-4D82-8EA8-89794BD32EFC@tzi.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.7.0.105] 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: Wed, 15 May 2013 19:34:19 -0000 Hi Carsten, all, On 04/25/2013 01:26 PM, Carsten Bormann wrote: > 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üße, Carsten > > ---------------------------------------------------------------------- > 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. > > Indeed, this will require active attention by the WG. > Fortunately, researchers are looking at this, and I expect > additional results to become available soon. Good to know! > > 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. This means UDP-lite and UDP zero should not be used for COAP. How about adding this clarifying text to Section 1.1. "Features": OLD o UDP [RFC0768] binding with optional reliability supporting unicast and multicast requests. NEW o UDP [RFC0768] binding with optional reliability supporting unicast and multicast requests. UDP-lite [RFC3828] and UDP zero checksum [RFC 6936] are not supported by 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. > > IPv4 simply hasn't received a lot of attention here. The more It worries me that IPv4 has not received a lot of attention. It is a general issue of the draft or just in this single place? > 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. I think I can live with the discussions of the issue in the draft. > > 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). > > 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]. Is there a particular reason why DF is not used in COAP? Thanks for adding the reference to RFC 4821! > > 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. > > 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. I agree to your points and also the difficulties in using, or even receiving, ICMP error messages, but a recommendation to take them into account when handling network errors would be beneficial for the protocol. This part looks underspecified, especially since the a larger than 1280 byte MTU can also cause issues in IPv6 networks. Not documenting it all looks rather incomplete. An incomplete text proposal: "COAP implementations should take ICMP error messages into account when handling error conditions in the transmission of COAP messages." I'm not sure where this would fit best in the draft. > > 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. > > 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. Ah, I have missed the reference to S 9.1 in RFC 2616. Cleared. > > 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. Ok. > > 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). > > (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). This is a huge issue, as the message receiver does not have any means to reduce the message size to an degree where it can process it. This issue is orthogonal to control the sending rate of the sender. A Standards Track protocol needs have measures to ensure that the receiver can tune how much data is sent at once to it. > > 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. > > 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. Is this limitation documented in the draft? > We don't think much more can be or should be done here. > > ---------------------------------------------------------------------- > 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). > > 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. You mean socket as in power socket? Anyhow, it is a comment only :) > > 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? The link-level could indicate the congestion level on a specific link, for instance. However, I can see that this is something that will be learned over time. > > 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. FWIW: Section 4.6 discusses MTUs and I am not sure where short messages are discussed over there. Short can be anything, even 500 bytes might be considered short. > > 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. Ok, but I would add a statement why randomized message IDs are need to make a secure protocol. E.g. "It is strongly recommended that the initial variable value is randomized, in order to make off path attacks to the protocol less likely." > > 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]. Ok. > > 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’t 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.) Fine with me. > > 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? > > 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. Fine with me. However, do you have a document where the WG lists the open issues to be explored? That would be awesome to have in order to revisit the open issues after a while. Thanks, Martin -- martin.stiemerling@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 From presnick@qti.qualcomm.com Wed May 15 20:28: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 E7F6211E80F7; Wed, 15 May 2013 20:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 NhWF+NH60RVU; Wed, 15 May 2013 20:27:54 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 3039211E80FC; Wed, 15 May 2013 20:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1368674874; x=1400210874; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/5RBbIACgSYYdQs7U6O20L4ahk4I04wmkY2bAXL2Y+Q=; b=knwV0V98LPaeYshhL6kim2yTNi0JM5e8fbJzVmUl+cpFAZsLsFDhi72N tq5izvmECgupQf82NQgxRwIwObZkemoPyF7G3MtvH3bir/F//d36mKFeP DKZ8TtMWgI+5NOXKJelmqYDq4k0Z0h0WAjZQjmlsPxyL7gVezBadCfGq5 s=; X-IronPort-AV: E=Sophos;i="4.87,681,1363158000"; d="scan'208";a="40141043" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP; 15 May 2013 20:27:53 -0700 X-IronPort-AV: E=Sophos;i="4.87,681,1363158000"; d="scan'208";a="474764965" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 May 2013 20:27:53 -0700 Received: from android-4d3df2140fc96964.wlan.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 15 May 2013 20:27:52 -0700 Message-ID: <51945238.80408@qti.qualcomm.com> Date: Wed, 15 May 2013 20:27:52 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Carsten Bormann References: <20130422222215.25364.10312.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] X-Mailman-Approved-At: Wed, 15 May 2013 22:49:48 -0700 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, 16 May 2013 03:28:01 -0000 Sorry for not replying to this sooner. I saw -16; thanks for your work on the doc. I'll update the ballot and clear what needs clearing in a bit (I'll try to get that done tonight), but wanted to respond to some of the points in here: On 4/25/13 6:23 AM, Carsten Bormann wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > 4.1: > 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].) > I actually liked Barry's suggested text, but this is fine. (And I'm also OK with the "MUST NOT send/MUST treat as a format error"; I understand what it's saying.) > 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. > "Reject" in this sense is an internal state change. That's confusing to me, as the normal sense of the English word implies a party that "hears about" the rejection. (It's hard to me to think of a circumstance where someone or something was "rejected" and only the rejector ever knew about it.) In your use, "ignore" is one possible form of rejection. That's just weird. If you're going to do this, I'd define terms up front. Maybe even capitalize "Reject" wherever you use it. Either way, in both 4.2 and 4.3, "MUST reject" is probably wrong (since that's an internal state and nothing a protocol requirement is useful for) and "MAY involve sending" is a strange construction. I can suggest text if you want. That said, though I feel strongly that this should be fixed for clarity sake, I just got done defending the idea that there's no need to DISCUSS such a thing, so I will move this to a comment. > 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. > From a protocol point of view, you are of course right -- if the > options is elective, it can always be ignored. > From 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. > This seems really problematic from a client perspective. I have no way as a client to say, "I really can only accept format X, and if you can't make format X, I don't want something else", and I have no way to distinguish that from "I would prefer format X, but am willing to take whatever you can give me." For the former, I have to be prepared to throw things away. For the latter, I have to be willing to send two requests, the first with Accept (potentially getting back 4.06), and then a re-request without Accept. Which one of the above are current clients doing? If it's the former, then I suggest making this into an implementation note, and I would even consider getting rid of the 4.06 response code for this use case, since it is nearly useless, and probably harmful. If it's the latter, then these SHOULDs ought to be MUSTs and the option should be critical so that clients can stop doing that. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 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. > I suppose clients aren't required to do anything with the RST, and they do need to deal with random responses anyway, so no harm in having this. And clients who are capable of responding to this will improve things. OK. > 3: > > 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.) > Crap. I can't count. OK. > 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. > > This requires some surgery but is probably a good idea. > -> Ticket > What you've got in -16 is fine, though I'll suggest some text in the updated ballot; take it if you like it. > 4.2: > > "be empty" is a technical term here for code=0. > Oh. That's a bummer. "Empty" is definitely confusing. "Null" or "Noop" probably would have been better. But again, if (like Reject) this is already well understood, probably just to define it clearly and move on. > 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. > I'll have a read through the new text and send suggestions if needed. > 4.6: > 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.) > Hah! Exactly right! I'm not going to jump up and down about this. But it still seems icky to me. > 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.) > That's fine. I understood it was explanatory; I just didn't think the explanation was all that helpful. > [I'd rather write those in RFC4648 base32hex.] > :-) > 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] > Aside from my inability to get the number straight, I also have my fingers so trained to talk about email "Resent-*" fields that I can no longer type the word "reset" with a capital R and not sneak the "n" in there. > Editorial change in [1307] (added a "likely"). > I think the "likely" gets you back into the problem. In what circumstance would the client *not* send the Reset? > 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... > Right. I meant put it in the high four bits of the most significant byte. > 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. > Well, the second half of the "why" is not a problem; it can be a SHOULD even if you don't know precisely what the exceptions are. But I don't understand why it is not a protocol requirement. Seems like it could cause interoperability problems if it's missing. > 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. > It already says that it is "the maximum time". I stand by my comment: You're defining the option semantics, not requiring anything. > 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"... > What SHOULD I implement to accomplish this awareness? And what do I do with this awareness once I accomplish it? Again, I don't get what this means. As I said, I'll try to get the ballot updated ASAP. Thanks for your answers and your updates to the document. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From turners@ieca.com Wed May 15 23:29: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 2528E21F90EE; Wed, 15 May 2013 23:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.723 X-Spam-Level: X-Spam-Status: No, score=-101.723 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, FRT_FOLLOW1=1.332, FRT_FOLLOW2=0.422, 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 8dlFyW9jjgzE; Wed, 15 May 2013 23:29:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B71B21F90BB; Wed, 15 May 2013 23:29:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Sean Turner" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130516062941.27229.92525.idtracker@ietfa.amsl.com> Date: Wed, 15 May 2013 23:29:41 -0700 Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Sean Turner's Discuss on draft-ietf-core-coap-16: (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, 16 May 2013 06:29:42 -0000 Sean Turner has entered the following ballot position for draft-ietf-core-coap-16: 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: ---------------------------------------------------------------------- Thanks for a clear draft. Makes things so much easier to review. Just want to discuss a couple of things before moving to yes (hopefully). 0) s9.1.3.2: Before I get in to the nitty-gritty of the specific concerns I have with DTLS use of Raw Public Keys, I have to ask whether use of the DTLS client_certificate_url extension was considered? If raw public keys is just about size then that'd work wouldn't it. If you're about dumping processing of paths, then that's another thing. 1) s9.1.3.2.1: What's really hung me up on this draft is the raw public key option. Primarily, the TLS draft is not quite done yet; I'm still in discussions with the authors. Two issues that affect your draft: a) By draft-ietf-tls-oob-pubkey taking a pass on specifying all of the ways an identity can be bound to a public key, it leaves it up to the application to specify that mechanism. This binding is important because you can't get peer authentication without it; I'm really worried that if this mode gets widely deployed people will say they have "DTLS security" but few (if any) are actually do the work necessary to bind the identity to the key. So, you specify that binding in the provisioning section (good ;) but I want to make sure that it's clear who's doing what to whom: i) s9.1.3.2.1: For machines it's perfect appropriate to generate the key and install it because we doubt it'll be able to do that well enough right (i.e., crummy entropy sources)? I want to make it clear that that's been done by the manufacturer. In this mode the device has an asymmetric key pair but without an X.509 certificate (called a raw public key). = to: In this mode the device has an asymmetric key pair but without an X.509 certificate (called a raw public key); the asymmetric key paid is generated by the manufacturer and installed on the device. ii) s9.1.3.2.1: This draft does that binding using Stephen's naming thing with hashes, but I want to make sure that it's clear who is identifier, it now says: An identifier is calculated from the public key as described in Section 2 of [RFC6920]. = Is it the = An identifier is calculated by the endpoint from from the public key as described in Section 2 of [RFC6920]. = b) draft-ietf-tls-oob-pubkey is likely to take a pass on specifying a mechanism for revoking the public key and identity binding. Note that ocsp-/multi-ocsp staplingwon't work because there's no way to request information about a certificate that you don't have information about. = I'm not trying to gold plate the security mechanism here but I think we need some words on how revocation for this mode will be handled. = However, I suspect you'll want to use the ACLs....there's a mechanism for including ACLs during provisioning but is there a way to update them later? What happens if a new node gets installed or removed? Is there a requirement for ACLs to be supported; the text has a SHOULD but that seems to be about ACL provisioning support not ACL support. 2) s9.1.3.2: Another TLS-related issue: When referring to TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 please include the MTI curve(s). Ever so glad that conservative curves are being used. In the following, I assumed you'd want the one must and the two mays but I can understand if you don't. I'd argue you do have algorithm agility with DTLS so you could get away with just the MUST ad not the MAYs. Unrelated to you, but I thought I'd let you know about: the curve requirements will almost certainly be removed from the mcgrew draft at my direction because no other D/TLS EC cipher suite specifies an MTI curve. = There's support for conservative curves, but not enough interest in starting to add MTI curves instead of the application picking them. Note the Zigbee folks also point to the mcgrew draft but it seems their drafts already include the curves so we ought to be good to go on both fronts. I think we need to be clear that choosing this particular cipher suite that it means an implementation needs to support the extensions defined in RFC 4492 - or if it doesn't. I'm assuming you want it to so I'm going to propose some tweaking: OLD: 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], [RFC5246], [RFC4492]. = NEW: 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]. The key used MUST be ECDSA-capable; the curve secp256r1 MUST be supported, and the curves secp384r1 and secp521r1 MAY be supported [RFC4492]; these curves are equivalent to the NIST P-256, P-384, and P-521 curves. Implementations MUST use/support (?) the Supported Elliptic Curves Extension and Supported Point Format extensions [RFC4492]; the uncompressed point format MUST be supported; [RFC6090] can be used as an implementation method. The mcgrew draft had the following instead of the last sentence so I'm open to whichever but I think something about the folllowing needs to be added: o The uncompressed point format MUST be supported. Other point formats MAY be used. o The client SHOULD offer the elliptic_curves extension and the server SHOULD expect to receive it. o The client MAY offer the ec_point_formats extension, but the server need not expect to receive it. o [RFC6090] MAY be used as an implementation method. = And then, I think we need to specify how the MTI would look: namely by adding the following on to the end of the paragraph. When the mandatory to implement DTLS cipher suite and curve and used the SubjectPublicKeyInfo indicates an algorithm of id-ecPublicKey with the namedCurves object identifier set to secp256r1 [RFC5480]. If secp384r1 or secp521r1 are used the those object identifiers [RFC5480] are included instead. = = That way everybody knows what values go in the SPKI of the oob-pubkey draft. Note they tried to change that field recently and I had to remind them not to. 3) s9: I know we're all about be liberal in what you accept, but in this context that might be challengeing; this bit: ... all modes of DTLS may not be applicable. Some DTLS cipher suites can add significant implementation complexity as well as some initial handshake overhead needed when setting up the security association. Made me wonder whether you considered which other DTLS extensions might be useful in addition to the EC ones and SNI as well as what extensions should be profiled out? For example, max_fragment_length looks pretty useful in this context as well as certificate_url. But does heartbeat make any sense? 4) s8: I think you need to make it pretty darn clear in s8 that multi-cast is an unsecured "mode" as specified in this document. It's kind of buried in s9. 5) s9.1.2: (worried about a DoS attack) Do you mean that responses to secured-CoAP messages returned unsecured are silently discarded/ignored or rejected and then that kicks off an error code response? 6) s9.1.3.1: Did you consider whether there should be an application profile for the psk_identity_hint (see Section 5 [RFC4279]) - i.e., is there a standard format for CoAP that should be defined? 7) s9.1.3.3: When you say "the Certificate must be validated" I'm just checking that you're think there's going to be a certificate chain? If there's no chain the validation rules in 5280 don't apply. 8) s9: If you're going to allow more than two entities to share the preshared keys I think it's worth pointing out you really can't get peer authentication with either CoAP or DTLS. The description in s9 and elsewhere seems to imply that more than one peer might share the same key. 9) Either in s9 or s11 we need to say something about devices with bad entropy sources not bothering to make keys because they won't be of any use. If they've got bad entropy sources the manufacturer or whoever should be making the keys. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 0) s1.2: Is the "CoAP-to-CoAP proxy" definition missing? s5.7 refers to s1.2 for the definition but that term is not in s1.2. 1) s7.1: I think this is munged: A server is discovered by a client by the client knowing or 2) s9: In the NoSec option is worth also pointing to the link layer security (IEEE 802.15.4)? 3) s9.1: Because there's no s9.2 (I assume that might have been an IPsec-secured CoAP section at one point) you can drop the header. 4) s9.1.3.3: The 1st paragraph is about certificates but it only indicates the TLS cipher suite needed to be supported. It should say what values go in the certificate to support the cipher suite. = Basically, need to point to RFC 5480 and say include values X. I'd suggest: OLD: Implementations in Certificate Mode MUST support the mandatory to implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in [RFC5246]. = NEW (adding some more stuff + references): Implementations in Certificate Mode MUST support the mandatory to implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in [RFC5246]. Namely, the certificate includes a SubjectPublicKeyInfo that indicates an algorithm of id-ecPublicKey with namedCurves secp256r1, secp384r1, or secp521r1 [RFC5480]; the public key format is uncompressed [RFC5480]; if included the key usage extension indicates digitalSignature. 5) s9.1.3.3: Going with the thought that there's a chain, we also need to say what algorithms can be used to sign the certificate. I assume we want the use same algorithm for both the TLS_ECDHE_PSK and TLS_ECDHE_ECDSA certificate so text is needed at the end of the paragraph to indicate that: Certificates MUST be signed with ECDSA [RFC6090], and it MUST use SHA-256, SHA-384, or SHA-512 [SHS]. It is RECOMMENDED that the curve match the hash function's output matches the length of the elliptic curve order. = On the fist bit: You could lock it down to just one curve if that's what you decide to do based on comment #5. = On the second bit: if the curve and the hash size line up then you can use RFC 6090 and we - really - want that. Not sure if the above is too cryptic ;) 6) s9.1.3.3: Maybe a typo MUST instead of must: 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. 7) s9.1.3.3: r/further work./further study. From golnaz.karbaschi@eolane.com Thu May 16 02:07: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 3A88E21F90EA for ; Thu, 16 May 2013 02:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3mHGrhkowU9 for ; Thu, 16 May 2013 02:07:17 -0700 (PDT) Received: from relay.martec.fr (relay.martec.fr [92.103.79.186]) by ietfa.amsl.com (Postfix) with ESMTP id D393821F8F0A for ; Thu, 16 May 2013 02:07:14 -0700 (PDT) Received: from webmail.martec.fr (unknown [192.168.20.3]) by relay.martec.fr (Postfix) with ESMTP id 1F48940C12B; Thu, 16 May 2013 11:07:12 +0200 (CEST) Received: from CL563 ([192.168.20.158]) by webmail.martec.fr (Lotus Domino Release 8.5) with ESMTP id 2013051611071191-7093 ; Thu, 16 May 2013 11:07:11 +0200 From: "Golnaz KARBASCHI" To: "'Teemu Savolainen'" References: <519225be.85f8420a.7287.ffffd4c7SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Thu, 16 May 2013 11:07:07 +0200 Organization: =?iso-8859-1?Q?=E9olane?= Message-ID: <00f501ce5214$c04dc9b0$40e95d10$@karbaschi@eolane.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5RYr0C1/AN+5roRxG8cstEeU0ZVAAri4bQ X-MIMETrack: Itemize by SMTP Server on srvm1/martec_sevres/FR(Release 8.5|December 05, 2008) at 16/05/2013 11:07:11, Serialize by Router on srvm1/martec_sevres/FR(Release 8.5|December 05, 2008) at 16/05/2013 11:07:12, Serialize complete at 16/05/2013 11:07:12 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F6_01CE5225.83D699B0" Content-Language: fr Cc: core@ietf.org Subject: Re: [core] Running CoAP over a local BLE network X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 16 May 2013 09:07:22 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00F6_01CE5225.83D699B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hello,=20 =20 I totally agree that in the standard of IPV6 over BLE is the = best/fastest approach for having an end-to-end standard and http friendly connections = all over the network.=20 =20 So I think, in our use case, before finalizing 6lowpan over BLE and = having commercial sdks on the rfc, as Carels mentioned too, it seems that the = best choice is using the existing GATT/ATT over our BLE peripherals, as it = gives us bidirectional signaling (client server structure) and the big = advantage of already standardized protocol. Well, of course we miss the = opportunity of having direct internet connections all the way on our LowPan. =20 Best regards, Golnaz=20 =20 =20 =20 De : Teemu Savolainen [mailto:tsavo.stds@gmail.com]=20 Envoy=E9 : mercredi 15 mai 2013 13:52 =C0 : Golnaz KARBASCHI Cc : core@ietf.org; Rahman, Akbar; Carsten Bormann Objet : Re: [core] Running CoAP over a local BLE network =20 While I do have interest to think about CoAP over BLE.. > Another motivation of removing IP over our LowPAN is that the ongoing draft (IPV6 over BLE) is still not complete ! =20 .. I do not think this to be sound reason, as highly likely IPv6 over = BLE is standard faster than any other standardized approach for transmitting = CoAP over BLE.. All other approaches would start from scratch in BT SIG and = by the time process has been gone through, IPv6 would be out of the = pipeline already. Best regards, Teemu ------=_NextPart_000_00F6_01CE5225.83D699B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"

Hello,

 

I totally agree that in the standard of IPV6 over BLE is the = best/fastest approach for having an end-to-end standard and http = friendly connections all over the network.

 

So I think, in our use case, before finalizing 6lowpan over BLE and = having commercial sdks on the rfc, as Carels mentioned too, it seems = that the best choice is using the existing GATT/ATT over our BLE = peripherals, as it gives us bidirectional signaling (client server = structure) and the big advantage of already standardized protocol. Well, = of course we miss the opportunity of having direct internet connections = all the way on our LowPan.

 

Best regards,

Golnaz

 

 

 

De : Teemu = Savolainen [mailto:tsavo.stds@gmail.com]
Envoy=E9 : = mercredi 15 mai 2013 13:52
=C0 : Golnaz = KARBASCHI
Cc : core@ietf.org; Rahman, Akbar; Carsten = Bormann
Objet : Re: [core] Running CoAP over a local BLE = network

 

While I do have interest to = think about CoAP over BLE..

> Another motivation of = removing IP over our LowPAN is that the ongoing draft (IPV6 over BLE) is = still not complete !  

.. I do not think this to = be sound reason, as highly likely IPv6 over BLE is standard faster than = any other standardized approach for transmitting CoAP over BLE.. All = other approaches would start from scratch in BT SIG and by the time = process has been gone through, IPv6 would be out of the pipeline = already.

Best = regards,

Teemu

------=_NextPart_000_00F6_01CE5225.83D699B0-- From golnaz.karbaschi@eolane.com Thu May 16 02:23: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 396A721F8F33 for ; Thu, 16 May 2013 02:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bASrUuus0Rdr for ; Thu, 16 May 2013 02:23:43 -0700 (PDT) Received: from relay.martec.fr (relay.martec.fr [92.103.79.186]) by ietfa.amsl.com (Postfix) with ESMTP id E685721F9133 for ; Thu, 16 May 2013 02:23:42 -0700 (PDT) Received: from webmail.martec.fr (unknown [192.168.20.3]) by relay.martec.fr (Postfix) with ESMTP id 1F49640C131; Thu, 16 May 2013 11:23:41 +0200 (CEST) Received: from CL563 ([192.168.20.158]) by webmail.martec.fr (Lotus Domino Release 8.5) with ESMTP id 2013051611234080-7157 ; Thu, 16 May 2013 11:23:40 +0200 From: "Golnaz KARBASCHI" To: "'Bill Silverajan'" References: <005e01ce4a5e$413dbf30$c3b93d90$@karbaschi@eolane.com> <006d01ce5099$830033d0$89009b70$@karbaschi@eolane.com> <5193974F.2000207@tut.fi> In-Reply-To: <5193974F.2000207@tut.fi> Date: Thu, 16 May 2013 11:23:36 +0200 Organization: =?us-ascii?Q?eolane?= Message-ID: <00fa01ce5217$0dc2f8d0$2948ea70$@karbaschi@eolane.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5RdfCaTiVZhF1TS9SVzRhMPx8XyAAmfL+A X-MIMETrack: Itemize by SMTP Server on srvm1/martec_sevres/FR(Release 8.5|December 05, 2008) at 16/05/2013 11:23:40, Serialize by Router on srvm1/martec_sevres/FR(Release 8.5|December 05, 2008) at 16/05/2013 11:23:41, Serialize complete at 16/05/2013 11:23:41 X-TNEFEvaluated: 1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Content-Language: fr Cc: core@ietf.org Subject: Re: [core] Running CoAP over a local BLE network X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 16 May 2013 09:23:48 -0000 Hi Bill, The advantage of deploying CoAP over BLE (assuming L2CAP) is that L2CAP semantics and behaviour can mimic that of UDP. It's trivial to implement this in lab-based proof of concept prototypes. Unfortunately as discussed earlier, it's not something that can be realistically deployed in products, for all the reasons mentioned. [Golnaz] right ! I agree ! CoAP over 6LowPAN adaptation layer over BLE, or CoAP over GATT over BLE. In both cases, an adaptation layer will be necessary for standards compliance and will introduce overhead and possibly an overlap of functionality, either with the underlying BLE stack or with how resources and attributes are represented. So it's either end-to-end IP or end-to-end REST, depending on which you prefer. [Golnaz] I think, if we can, end-to-end IP is the better solution, specially if having end-to-end REST is not free to get and needs manipulation for integrating CoAP into GATT services. Then, in some scenarios, like ours, some nodes cannot take advantage of having direct IP connections. I think in this case, for choosing one of these approaches the best way is comparing the applied overhead and duplications and efficiency by each of them. After all, both still remain prototyping solutions before deploying in real products. regards, Golnaz -- | Bilhanan Silverajan Tel: +358 (0)40 849 0757 | | Tampere University of Technology, Finland | From jari.arkko@piuha.net Thu May 16 06:51: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 2D1CC21F92EC; Thu, 16 May 2013 06:51:41 -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 yR+DN4zzMSE3; Thu, 16 May 2013 06:51:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F2B21F92A5; Thu, 16 May 2013 06:51:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Jari Arkko" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130516135140.11326.91126.idtracker@ietfa.amsl.com> Date: Thu, 16 May 2013 06:51:40 -0700 Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Jari Arkko's Yes on draft-ietf-core-coap-16: (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, 16 May 2013 13:51:41 -0000 Jari Arkko has entered the following ballot position for draft-ietf-core-coap-16: 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: ---------------------------------------------------------------------- Thank you for this important work and well written specification. While there are aspects that I would personally have done differently and some fine-tuning of the spec could continue, I believe the document is ready to move to an RFC. I also believe it that is a much-awaited spec and very useful to the Internet community in its current state. I do agree with some of the points raised in other reviews, and those need to be addressed. I did have one specific additional suggestion worth bringing up here. Dan Romascanu did a Gen-ART review and raised the issue that the parameter changes discussed in S4.8.1 are security sensitive, i.e., changes in the parameters may cause security/denial-of-service issues. This should be noted somewhere in the S11. I'd make a brief observation that it is security sensitive and should be addressed in any system that allows configuration of these parameters. = Here's what Dan wrote: 3. Section 4.8 defines a number of CoAP protocol parameters and derived parameters that according to 4.8.1 may be changed. Some of these parameters have limitations and their changes may affect the basic functionality of the nodes, the interaction between nodes or between nodes and servers, as well as the functioning in constrained environments. However there is no risk analysis in Section 11 (Security Considerations) about the threats related to mis-configuration of the modes and un-appropriate or malevolent changes in these parameters, and recommendations of security counter-measures on this respect. From bclaise@cisco.com Thu May 16 07:25: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 07BBB21F8EDA; Thu, 16 May 2013 07:25:35 -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 xdeaRCgxA1sh; Thu, 16 May 2013 07:25:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF77321F8F0A; Thu, 16 May 2013 07:25:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Benoit Claise" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130516142533.24641.57954.idtracker@ietfa.amsl.com> Date: Thu, 16 May 2013 07:25:33 -0700 Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Benoit Claise's No Objection on draft-ietf-core-coap-16: (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, 16 May 2013 14:25:35 -0000 Benoit Claise has entered the following ballot position for draft-ietf-core-coap-16: 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 lacked some time to review the draft details. However, after a discussion with Joel Jaeggli, and with the OPS DIR review from Mehmet, I trust that the OPS aspects have been taken care of. From ietf-secretariat-reply@ietf.org Thu May 16 10:21: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 3F6EA21F8CE9 for ; Thu, 16 May 2013 10:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.069, 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 bMQqNpA93c96; Thu, 16 May 2013 10:21:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C7721F89C3; Thu, 16 May 2013 10:21:52 -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.45 Message-ID: <20130516172152.21934.1422.idtracker@ietfa.amsl.com> Date: Thu, 16 May 2013 10:21:52 -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, 16 May 2013 17:21:54 -0000 State changed to IESG Evaluation - Defer::Revised I-D Needed from IESG Eval= uation - Defer ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-core-coap/ From trac+core@trac.tools.ietf.org Thu May 16 14:21: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 ECD1221F8EDA for ; Thu, 16 May 2013 14:21: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 JwvKbn2rPkt7 for ; Thu, 16 May 2013 14:21: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 E001D21F8A4E for ; Thu, 16 May 2013 14:21:12 -0700 (PDT) Received: from localhost ([127.0.0.1]:51759 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Ud5bq-0003kw-PT; Thu, 16 May 2013 23:21:10 +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, 16 May 2013 21:21:10 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/322 Message-ID: <051.acab664a5a1d198d8eb1b3af78e562ea@trac.tools.ietf.org> X-Trac-Ticket-ID: 322 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: <20130516212113.E001D21F8A4E@ietfa.amsl.com> Resent-Date: Thu, 16 May 2013 14:21:12 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #322: Clarify that security SHOULD be used for issuing secure requests to a proxy 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, 16 May 2013 21:21:16 -0000 #322: Clarify that security SHOULD be used for issuing secure requests to a proxy Stephen Farrell notes (msg04415): Section 5.7 (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? We had some mail exchanges about that, but I'm not sure I'm ok with the outcome so I'd like to DISCUSS this some more. (And did any of that get into -16? Not sure.) Carsten says: Further discussion indicates that it is probably not possible to "solve" this in a general sense, but it may be worth to explicitly mandate for requests sent via a proxy: »When a client uses a proxy to make a request that will use a secure URI scheme (e.g., coaps or https), the request towards the proxy SHOULD be sent using DTLS security except where equivalent lower layer security is used for the leg between the client and the proxy.« (Note that CoAP's general rules then also make sure the response is sent back from the proxy to the client via DTLS.) While nailing this down this looks like a technical change, I'm pretty sure that we always intended this as the obvious way to implement sending secure requests to a proxy. I propose to add this text to the end of section 5.7 and add a pointer to 5.7 to the first paragraph of 10.1. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: other | Milestone: post-IESG-1 technical | Version: coap-16 Priority: minor | Keywords: Component: coap | Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From cabo@tzi.org Thu May 16 23:29: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 06E1D21F86BB; Thu, 16 May 2013 23:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.475 X-Spam-Level: X-Spam-Status: No, score=-106.475 tagged_above=-999 required=5 tests=[AWL=-0.226, 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 MXiQNrnllCug; Thu, 16 May 2013 23:29: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 B2DE521F8B2B; Thu, 16 May 2013 23:29: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 r4H6TBVK015280; Fri, 17 May 2013 08:29:11 +0200 (CEST) Received: from [192.168.217.105] (p54891B94.dip0.t-ipconnect.de [84.137.27.148]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 12D0531B5; Fri, 17 May 2013 08:29:11 +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: <20130516062941.27229.92525.idtracker@ietfa.amsl.com> Date: Fri, 17 May 2013 08:29:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130516062941.27229.92525.idtracker@ietfa.amsl.com> To: Sean Turner 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] Sean Turner's Discuss on draft-ietf-core-coap-16: (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: Fri, 17 May 2013 06:29:27 -0000 Sean, thank you for the juicy review -- this was well worth the wait; we are = still busy processing the finer points and will have a response soon. One quick question: > 2) s9.1.3.2: Another TLS-related issue: >=20 > When referring to TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 please include = the > MTI curve(s). Ever so glad that conservative curves are being used. = In > the following, I assumed you'd want the one must and the two mays but = I > can understand if you don't. I'd argue you do have algorithm agility > with DTLS so you could get away with just the MUST ad not the MAYs. draft-mcgrew-tls-aes-ccm-ecc-06 says: The curves and hash algorithms that must be supported are as follows: An implementation that includes either TLS_ECDHE_ECDSA_WITH_AES_128_CCM or TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 MUST support secp256r1 and SHA- 256. An implementation that includes either TLS_ECDHE_ECDSA_WITH_AES_256_CCM or TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 MUST support secp384r1 and SHA- 384, and MAY support secp521r1 and SHA-512. Implementations that use other curves and hash functions SHOULD select them so that AES-128 is used with a curve and a hash function supporting a 128-bit security level, and AES-256 is used with a curve and a hash function supporting a 192-bit or 256-bit security level. Exceptions for the "SHOULD" are not given, but it seems to me that leads = us to stick with secp256r1 for AES-128. This means the MUST, but not the MAYs (which would then be used with, = say, TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8). Gr=FC=DFe, Carsten From zach@sensinode.com Fri May 17 01:52: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 765A921F8EA4; Fri, 17 May 2013 01:52:18 -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 x2VzVxwVMyxo; Fri, 17 May 2013 01:52:14 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0FC21F8EAD; Fri, 17 May 2013 01:52:13 -0700 (PDT) Received: from [10.128.9.198] (line-21396.dyn.kponet.fi [213.145.192.6]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r4H8q6I1005094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 May 2013 11:52:06 +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: Fri, 17 May 2013 11:52:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8883F2C7-A3EE-4EF2-874F-48AD05BA7D5A@sensinode.com> References: <20130516062941.27229.92525.idtracker@ietfa.amsl.com> To: Carsten Bormann X-Mailer: Apple Mail (2.1503) Cc: draft-ietf-core-coap@tools.ietf.org, Sean Turner , core-chairs@tools.ietf.org, The IESG , core@ietf.org Subject: Re: [core] Sean Turner's Discuss on draft-ietf-core-coap-16: (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: Fri, 17 May 2013 08:52:18 -0000 On May 17, 2013, at 9:29 AM, Carsten Bormann wrote: > Exceptions for the "SHOULD" are not given, but it seems to me that = leads us to stick with secp256r1 for AES-128. This is in practice what we're all using commercially right now anyways. 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 Sat May 18 02: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 B881421F93BF; Sat, 18 May 2013 02:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.437 X-Spam-Level: X-Spam-Status: No, score=-106.437 tagged_above=-999 required=5 tests=[AWL=-0.188, 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 RAaNMhottFA7; Sat, 18 May 2013 02:05:20 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 8856B21F93B9; Sat, 18 May 2013 02:05: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 r4I95Hla017013; Sat, 18 May 2013 11:05:17 +0200 (CEST) Received: from [192.168.217.105] (p548920D6.dip0.t-ipconnect.de [84.137.32.214]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DCB1736B9; Sat, 18 May 2013 11:05:16 +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: <5193E302.7010101@neclab.eu> Date: Sat, 18 May 2013 11:05:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130424092228.10345.76059.idtracker@ietfa.amsl.com> <8C88F8A7-9B07-4D82-8EA8-89794BD32EFC@tzi.org> <5193E302.7010101@neclab.eu> 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: Sat, 18 May 2013 09:05:26 -0000 Hi Martin, thanks for the update. We probably need to think about ICMP processing (beyond packet too big) = some more. We certainly want to heed the lessons learned from TCP, e.g. as = documented in RFC 5927. (We also have to account for the abysmal platform support for ICMP = errors in UDP implementations;=20 I remember having had to fork the platform for my own CoAP = implementation to handle those properly). Do you have a specific example of ICMP processing rules in a UDP-based = protocol specification that we could use as a model? (E.g., of RFC 1035, RFC 2865, RFC 3530, none mention ICMP at all. It is easy, but maybe not very useful, to add something like section = 18.4 of RFC 3261.) Some more detailed responses below. Gr=FC=DFe, Carsten This means UDP-lite and UDP zero should not be used for COAP. How about adding this clarifying text to Section 1.1. = "Features": OLD o UDP [RFC0768] binding with optional reliability supporting = unicast and multicast requests. NEW o UDP [RFC0768] binding with optional reliability supporting = unicast and multicast requests. UDP-lite [RFC3828] and UDP zero = checksum [RFC 6936] are not supported by COAP. At this rate, we probably should be saying that we don't support SCTP and DCCP, too :-) (We actually do say this about SCTP in the initial paragraph of 3. I've added UDP-lite/UDP-zero as a parenthesis to this). [1371] It worries me that IPv4 has not received a lot of attention. It = is a general issue of the draft or just in this single place? IPv4 just isn't in the focus of much of CoAP's implementer community. So, yes, I would expect IPv4-specific issues to have received less attention than IPv6-specific issues. Fortunately, above UDP there isn't that much difference apart from the address format (covered by RFC 3986) and the MTU issues discussed here, so I don't expect the limited attention by implementers to be a big problem. 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]. Is there a particular reason why DF is not used in COAP? Keeping PMTUD state is hard in a very constrained implementation, and there may be no obvious way for an application to react to it. And, before adding state for MTU info, you would probably try to keep RTT information around. For constrained networks I would also probably implement something like ALFI before looking at the IP-layer fragmentation information. I agree to your points and also the difficulties in using, or = even receiving, ICMP error messages, but a recommendation to take them = into account when handling network errors would be beneficial for the = protocol. This part looks underspecified, especially since the a larger = than 1280 byte MTU can also cause issues in IPv6 networks. Not documenting it all looks rather incomplete. An incomplete text proposal: "COAP implementations should take ICMP error messages into = account when handling error conditions in the transmission of COAP = messages." Indeed, this would need some of the usual exhortations about how ICMP messages are insecure etc. I'm not sure where this would fit best in the draft. 4.6 would be the right place for packet too big (and it is kind of covered by the reference to 4821 already), but the other ICMP messages are harder to react to. (E.g., a client may not want to give up on a single routing error.) Hmm. -> 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. 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). (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). This is a huge issue, as the message receiver does not have any means to reduce the message size to an degree where it can process it. Ah. We do have 4.13 "Request Entity Too Large". 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. Is this limitation documented in the draft? Done in [1372] (based on Stephen Farrell's comment.) = ---------------------------------------------------------------------- COMMENT: = ---------------------------------------------------------------------- 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. FWIW: Section 4.6 discusses MTUs and I am not sure where short = messages are discussed over there. Short can be anything, even 500 bytes = might be considered short. Spencer Dawkins also didn't like the "short messages" (because it can be confused with SMS). So I changed it into "compact messages". [1373] (I do still think the discussion of what we expect with respect to message sizes in 4.6 is comprehensive.) 4) randomization of message IDs [...] 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. Ok, but I would add a statement why randomized message IDs are = need to make a secure protocol. E.g. "It is strongly recommended that = the initial variable value is randomized, in order to make off path = attacks to the protocol less likely." Good point. [1370] 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. Fine with me. However, do you have a document where the WG lists the open = issues to be explored? That would be awesome to have in order to revisit = the open issues after a while. The CoRE roadmap (draft-bormann-core-roadmap) is trying to be this document, but it needs more work to fully meet this role. From Akbar.Rahman@InterDigital.com Sat May 18 08:27: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 D232921F8F32 for ; Sat, 18 May 2013 08:27:14 -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 ftYWqPv1wZxi for ; Sat, 18 May 2013 08:27:09 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id B01BB21F8F0C for ; Sat, 18 May 2013 08:27:09 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 18 May 2013 11:27:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 18 May 2013 11:27:07 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] New "application/coap-group+json" Internet Media Type for Group Communication Thread-Index: Ac5TkiBHKtlYmuJQRR+rsKtiaA1xgQASY2xw References: From: "Rahman, Akbar" To: "Zach Shelby" X-OriginalArrivalTime: 18 May 2013 15:27:08.0463 (UTC) FILETIME=[28E993F0:01CE53DC] Cc: core@ietf.org Subject: Re: [core] New "application/coap-group+json" Internet Media Type for Group Communication X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 May 2013 15:27:14 -0000 Hi Zach, Thanks for your feedback! We will wait to see if Carsten or anybody else has any other comments. Then we will do a quick update of the draft to close the issue. Best Regards, Akbar -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com]=20 Sent: Saturday, May 18, 2013 2:36 AM To: Rahman, Akbar Cc: Dijk, Esko Subject: Re: [core] New "application/coap-group+json" Internet Media Type for Group Communication Hi, Well, +json is fine, however that really only makes sense when you have multiple formats. e.g. +xml and +json. In this case, we only have a single format, so maybe it would just make sense to call it application/coap-group. This is anyways more specific.=20 Zach From derhoermi@gmx.net Sat May 18 08:48: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 0ECE521F852D for ; Sat, 18 May 2013 08:48:47 -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 f6rKG2ANJXxd for ; Sat, 18 May 2013 08:48:42 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 59C2621F84B1 for ; Sat, 18 May 2013 08:48:42 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.1]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MKOUK-1Uc5DK4Bra-001kfQ for ; Sat, 18 May 2013 17:48:41 +0200 Received: (qmail invoked by alias); 18 May 2013 15:48:40 -0000 Received: from p5B230BA7.dip0.t-ipconnect.de (EHLO netb.Speedport_W_700V) [91.35.11.167] by mail.gmx.net (mp001) with SMTP; 18 May 2013 17:48:40 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19Izu5Dl+pINhEa7ZblQGekERh1qZlJw6OaILlP2g IBRJhF3edzyPJc From: Bjoern Hoehrmann To: "Kovatsch Matthias" Date: Sat, 18 May 2013 17:48:38 +0200 Message-ID: References: <031DD135F9160444ABBE3B0C36CED618C14BD2@011-DB3MPN2-083.MGDPHG.emi.philips.com><55877B3AFB359744BA0F2140E36F52B514E9AB83@MBX20.d.ethz.ch><031DD135F9160444ABBE3B0C36CED618C14EF3@011-DB3MPN2-083.MGDPHG.emi.philips.com> <55877B3AFB359744BA0F2140E36F52B514E9B828@MBX20.d.ethz.ch> <031DD135F9160444ABBE3B0C36CED618C230E3@011-DB3MPN2-082.MGDPHG.emi.philips.com> <55877B3AFB359744BA0F2140E36F52B514EC6C67@MBX10.d.ethz.ch> In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514EC6C67@MBX10.d.ethz.ch> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "core@ietf.org" Subject: Re: [core] New "application/coap-group+json" Internet Media Type for Group Communication X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 May 2013 15:48:47 -0000 * Kovatsch Matthias wrote: >What is actually the status about "+json" suffixes in media types? I saw >that it was kind of refused a while ago, so maybe it is sufficient to >register "application/coap-group"? The `+json` suffix is defined and registered in RFC 6839, and it makes a lot of sense to use it for JSON-based formats, as it makes it easy for applications to recognise such entities as JSON, e.g. pretty printers in network analysis tools. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From zach@sensinode.com Sun May 19 13:14: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 0F38721F8EBB for ; Sun, 19 May 2013 13:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miSSPkhFLgCw for ; Sun, 19 May 2013 13:14:51 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id D2AF421F8E46 for ; Sun, 19 May 2013 13:14:50 -0700 (PDT) Received: from [172.20.10.4] (85-156-215-41.elisa-mobile.fi [85.156.215.41]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r4JKEgZ9017359 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 19 May 2013 23:14:43 +0300 From: Zach Shelby Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sun, 19 May 2013 23:14:41 +0300 To: "core@ietf.org (core@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [core] CoAP tutorial X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 19 May 2013 20:14:55 -0000 Hi, As we are completing publication of the CoAP RFC, it is a good time for = the working group to help out with educating people about CoAP. I have = posted my latest tutorials about CoAP and OMA Lightweight M2M on = Slideshare, hopefully people find these useful: http://www.slideshare.net/zdshelby/coap-tutorial http://www.slideshare.net/zdshelby/oma-lightweightm2-mtutorial=EF=BB=BF If there are other tutorials, articles or other useful material out = there, please let us know!=20 I also noticed we have a Wikipedia page, at least the list of = implementations is pretty detailed. If someone could expand the = technical description of the protocol that would be awesome: http://en.wikipedia.org/wiki/Constrained_Application_Protocol Regards, Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From cabo@tzi.org Sun May 19 16:06: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 DCB0521F8E93 for ; Sun, 19 May 2013 16:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.411 X-Spam-Level: X-Spam-Status: No, score=-106.411 tagged_above=-999 required=5 tests=[AWL=-0.162, 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 6rMQL7V4eIZc for ; Sun, 19 May 2013 16:06: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 A799221F8ECB for ; Sun, 19 May 2013 16:06: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 r4JN5tAb026129; Mon, 20 May 2013 01:05:55 +0200 (CEST) Received: from [192.168.217.105] (p54891FCC.dip0.t-ipconnect.de [84.137.31.204]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 554B938D4; Mon, 20 May 2013 01:05:55 +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: Mon, 20 May 2013 01:05:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <62DE0479-324F-4575-9D06-5157E75BD89C@tzi.org> References: To: Zach Shelby X-Mailer: Apple Mail (2.1503) Cc: "core@ietf.org \(core@ietf.org\)" Subject: [core] List of CoAP implementations (Re: CoAP tutorial) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 19 May 2013 23:06:09 -0000 On May 19, 2013, at 22:14, Zach Shelby wrote: > list of implementations is pretty detailed Oops. Most of these still list outdated, non-interoperable versions of = CoAP. I know we are a bit further than that... Can people who know the details about the status of implementations = please update the list there? Gr=FC=DFe, Carsten From zach@sensinode.com Sun May 19 23:47: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 E5A4821F9021 for ; Sun, 19 May 2013 23:47:24 -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 h208h2Hdzqji for ; Sun, 19 May 2013 23:47: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 412D021F9019 for ; Sun, 19 May 2013 23:46:58 -0700 (PDT) Received: from [10.32.112.100] ([193.185.69.17]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r4K6ktN5019305 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 20 May 2013 09:46:56 +0300 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <8A5869E9-8AE2-4358-B1D3-7960B9F99630@sensinode.com> Date: Mon, 20 May 2013 09:46:56 +0300 To: "core@ietf.org (core@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [core] Correct tutorial link X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 May 2013 06:47:30 -0000 And my OMA Lightweight tutorial had a broken link, this is the correct one: http://www.slideshare.net/zdshelby/oma-lightweightm2-mtutorial 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 From Akbar.Rahman@InterDigital.com Mon May 20 11:05: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 217E721F9600 for ; Mon, 20 May 2013 11:05:42 -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 DTrGNpqVJ24Z for ; Mon, 20 May 2013 11:05:38 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id BE08621F95F1 for ; Mon, 20 May 2013 11:05:37 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 May 2013 14:05:36 -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: Mon, 20 May 2013 14:05:35 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] New "application/coap-group+json" Internet Media Type for Group Communication Thread-Index: Ac5T3z7zDxoSNtNaTOyU8sfahuRnOABpVEoA References: <031DD135F9160444ABBE3B0C36CED618C14BD2@011-DB3MPN2-083.MGDPHG.emi.philips.com><55877B3AFB359744BA0F2140E36F52B514E9AB83@MBX20.d.ethz.ch><031DD135F9160444ABBE3B0C36CED618C14EF3@011-DB3MPN2-083.MGDPHG.emi.philips.com> <55877B3AFB359744BA0F2140E36F52B514E9B828@MBX20.d.ethz.ch> <031DD135F9160444ABBE3B0C36CED618C230E3@011-DB3MPN2-082.MGDPHG.emi.philips.com> <55877B3AFB359744BA0F2140E36F52B514EC6C67@MBX10.d.ethz.ch> From: "Rahman, Akbar" To: "Bjoern Hoehrmann" X-OriginalArrivalTime: 20 May 2013 18:05:36.0450 (UTC) FILETIME=[A0F0C220:01CE5584] Cc: core@ietf.org Subject: Re: [core] New "application/coap-group+json" Internet Media Type for Group Communication X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 May 2013 18:05:42 -0000 Thanks for the good reference, Bjorn. -----Original Message----- From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net]=20 Sent: Saturday, May 18, 2013 11:49 AM To: Kovatsch Matthias Cc: Dijk, Esko; Rahman, Akbar; Carsten Bormann; Zach Shelby; = core@ietf.org Subject: Re: [core] New "application/coap-group+json" Internet Media = Type for Group Communication * Kovatsch Matthias wrote: >What is actually the status about "+json" suffixes in media types? I=20 >saw that it was kind of refused a while ago, so maybe it is sufficient=20 >to register "application/coap-group"? The `+json` suffix is defined and registered in RFC 6839, and it makes a = lot of sense to use it for JSON-based formats, as it makes it easy for = applications to recognise such entities as JSON, e.g. pretty printers in = network analysis tools. -- Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 = http://bjoern.hoehrmann.de Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 = =B7 http://www.bjoernsworld.de 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 = http://www.websitedev.de/=20 From trac+core@trac.tools.ietf.org Mon May 20 12:11: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 2604121F9677 for ; Mon, 20 May 2013 12:11:18 -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 HqlABXvngCEq for ; Mon, 20 May 2013 12:11:17 -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 DCE6B21F9691 for ; Mon, 20 May 2013 12:11:07 -0700 (PDT) Received: from localhost ([127.0.0.1]:47867 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UeVU8-0007qI-1z; Mon, 20 May 2013 21:11: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, cabo@tzi.org X-Trac-Project: core Date: Mon, 20 May 2013 19:11:04 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/323 Message-ID: <051.63589cd06f69ed6c22b3b45441be5003@trac.tools.ietf.org> X-Trac-Ticket-ID: 323 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: <20130520191107.DCE6B21F9691@ietfa.amsl.com> Resent-Date: Mon, 20 May 2013 12:11:07 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #323: Discuss constrained node security considerations, including entropy 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, 20 May 2013 19:11:18 -0000 #323: Discuss constrained node security considerations, including entropy Sean Turner notes (msg04433d9): Section 11 9) Either in s9 or s11 we need to say something about devices with bad entropy sources not bothering to make keys because they won't be of any use. If they've got bad entropy sources the manufacturer or whoever should be making the keys. Carsten says: Good point. So far we talk about entropy only in 9.1.3.1. There are other considerations about constrained nodes (e.g., susceptibility to timing attacks) that may be worth mentioning. I'll propose adding a section 11.6 with some of these considerations. Strawman text: 11.6 Constrained node considerations Implementors on constrained nodes often find themselves without a good source of entropy [RFC4086]. If that is the case, the node MUST NOT be used for processes that require good entropy, such as key generation. Instead, keys should be generated externally and added to the device during manufacturing or commissioning. Due to their low processing power, constrained nodes are particularly susceptible to timing attacks. Special care must be taken in implementation of cryptographic primitives. Large numbers of constrained nodes will be installed in exposed environments and will have little resistance to tampering, including recovery of keying materials. This needs to be considered when defining the scope of credentials assigned to them. In particular, assigning a shared key to a group of nodes may make any single constrained node a target for subverting the entire group. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: other | Milestone: post-IESG-1 technical | Version: coap-16 Priority: minor | Keywords: Component: coap | Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon May 20 12:17: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 1476C21F969E for ; Mon, 20 May 2013 12:17:26 -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 jokr5F9TV0WL for ; Mon, 20 May 2013 12:17: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 64C9121F961B for ; Mon, 20 May 2013 12:17:25 -0700 (PDT) Received: from localhost ([127.0.0.1]:48310 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UeVaF-0000Ko-0H; Mon, 20 May 2013 21:17:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 20 May 2013 19:17:22 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/324 Message-ID: <051.dec31a5931cb4696925344dd724d4a85@trac.tools.ietf.org> X-Trac-Ticket-ID: 324 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: <20130520191725.64C9121F961B@ietfa.amsl.com> Resent-Date: Mon, 20 May 2013 12:17:25 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #324: Discuss key pair generation for RPK 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, 20 May 2013 19:17:26 -0000 #324: Discuss key pair generation for RPK Sean Turner notes (msg04433d1ai): Section 9.1.3.2.1 i) s9.1.3.2.1: For machines it's perfect appropriate to generate the key and install it because we doubt it'll be able to do that well enough right (i.e., crummy entropy sources)? I want to make it clear that that's been done by the manufacturer. In this mode the device has an asymmetric key pair but without an X.509 certificate (called a raw public key). to: In this mode the device has an asymmetric key pair but without an X.509 certificate (called a raw public key); the asymmetric key paid is generated by the manufacturer and installed on the device. Carsten says: Well, it is probably more appropriate to suggest this than to state it as a fact. (It is certainly not a requirement, as there are other ways to do provisioning.) See also the new section 11.6 (#323). Strawman text: ...; e.g., the asymmetric key pair is generated by the manufacturer and installed on the device (see also Section 11.6). -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: other | Milestone: post-IESG-1 technical | Version: coap-16 Priority: minor | Keywords: Component: coap | Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon May 20 12:40: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 0E0C921F96B2 for ; Mon, 20 May 2013 12:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.722 X-Spam-Level: X-Spam-Status: No, score=-101.722 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, FRT_FOLLOW1=1.332, FRT_FOLLOW2=0.422, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Od1gGlZuCNWX for ; Mon, 20 May 2013 12:40: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 E4FA221F96B1 for ; Mon, 20 May 2013 12:40:20 -0700 (PDT) Received: from localhost ([127.0.0.1]:49548 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UeVwQ-0002Pj-O2; Mon, 20 May 2013 21:40:18 +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, 20 May 2013 19:40:18 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/325 Message-ID: <051.fb27520c8fa2e3ba5cf748888757b052@trac.tools.ietf.org> X-Trac-Ticket-ID: 325 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: <20130520194020.E4FA221F96B1@ietfa.amsl.com> Resent-Date: Mon, 20 May 2013 12:40:20 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #325: Define curve for keys and certs 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, 20 May 2013 19:40:22 -0000 #325: Define curve for keys and certs Sean Turner notes (msg04433d2): Section 9.1.3.2.1 2) s9.1.3.2: Another TLS-related issue: When referring to TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 please include the MTI curve(s). Ever so glad that conservative curves are being used. In the following, I assumed you'd want the one must and the two mays but I can understand if you don't. I'd argue you do have algorithm agility with DTLS so you could get away with just the MUST ad not the MAYs. Unrelated to you, but I thought I'd let you know about: the curve requirements will almost certainly be removed from the mcgrew draft at my direction because no other D/TLS EC cipher suite specifies an MTI curve. There's support for conservative curves, but not enough interest in starting to add MTI curves instead of the application picking them. Note the Zigbee folks also point to the mcgrew draft but it seems their drafts already include the curves so we ought to be good to go on both fronts. I think we need to be clear that choosing this particular cipher suite that it means an implementation needs to support the extensions defined in RFC 4492 - or if it doesn't. I'm assuming you want it to so I'm going to propose some tweaking: OLD: 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], [RFC5246], [RFC4492]. NEW: 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]. The key used MUST be ECDSA-capable; the curve secp256r1 MUST be supported, and the curves secp384r1 and secp521r1 MAY be supported [RFC4492]; these curves are equivalent to the NIST P-256, P-384, and P-521 curves. Implementations MUST use/support (?) the Supported Elliptic Curves Extension and Supported Point Format extensions [RFC4492]; the uncompressed point format MUST be supported; [RFC6090] can be used as an implementation method. The mcgrew draft had the following instead of the last sentence so I'm open to whichever but I think something about the folllowing needs to be added: o The uncompressed point format MUST be supported. Other point formats MAY be used. o The client SHOULD offer the elliptic_curves extension and the server SHOULD expect to receive it. o The client MAY offer the ec_point_formats extension, but the server need not expect to receive it. o [RFC6090] MAY be used as an implementation method. And then, I think we need to specify how the MTI would look: namely by adding the following on to the end of the paragraph. When the mandatory to implement DTLS cipher suite and curve and used the SubjectPublicKeyInfo indicates an algorithm of id-ecPublicKey with the namedCurves object identifier set to secp256r1 [RFC5480]. If secp384r1 or secp521r1 are used the those object identifiers [RFC5480] are included instead. That way everybody knows what values go in the SPKI of the oob-pubkey draft. Note they tried to change that field recently and I had to remind them not to. Carsten says: draft-mcgrew-tls-aes-ccm-ecc-06 says: » The curves and hash algorithms that must be supported are as follows: An implementation that includes either TLS_ECDHE_ECDSA_WITH_AES_128_CCM or TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 MUST support secp256r1 and SHA- 256. An implementation that includes either TLS_ECDHE_ECDSA_WITH_AES_256_CCM or TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 MUST support secp384r1 and SHA- 384, and MAY support secp521r1 and SHA-512. Implementations that use other curves and hash functions SHOULD select them so that AES-128 is used with a curve and a hash function supporting a 128-bit security level, and AES-256 is used with a curve and a hash function supporting a 192-bit or 256-bit security level. « Exceptions for the "SHOULD" are not given, but it seems to me that leads us to stick with secp256r1 for AES-128. This means the MUST, but not the MAYs (which would then be used with, say, TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8). We also had some interoperability problems where it wasn't quite clear which hash function should be used for ECDHE; it is probably worth nailing this down here as well. Strawman text: »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]. The key used MUST be ECDSA-capable. The curve secp256r1 MUST be supported [RFC4492]; this curve is equivalent to the NIST P-256 curve. The hash function used is SHA-256. Implementations MUST support (?) the Supported Elliptic Curves Extension and Supported Point Format extensions [RFC4492]; the uncompressed point format MUST be supported; [RFC6090] can be used as an implementation method.« In comment 4, Sean Turner also says: 4) s9.1.3.3: The 1st paragraph is about certificates but it only indicates the TLS cipher suite needed to be supported. It should say what values go in the certificate to support the cipher suite. Basically, need to point to RFC 5480 and say include values X. I'd suggest: OLD: Implementations in Certificate Mode MUST support the mandatory to implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in [RFC5246]. NEW (adding some more stuff + references): Implementations in Certificate Mode MUST support the mandatory to implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in [RFC5246]. Namely, the certificate includes a SubjectPublicKeyInfo that indicates an algorithm of id-ecPublicKey with namedCurves secp256r1, secp384r1, or secp521r1 [RFC5480]; the public key format is uncompressed [RFC5480]; if included the key usage extension indicates digitalSignature. Carsten says: Strawman text under the previous considerations: »Implementations in Certificate 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]. Namely, the certificate includes a SubjectPublicKeyInfo that indicates an algorithm of id-ecPublicKey with namedCurves secp256r1 [RFC5480]; the public key format is uncompressed [RFC5480]; the hash algorithm is SHA-256; if included the key usage extension indicates digitalSignature.« -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: other | Milestone: post-IESG-1 technical | Version: coap-16 Priority: major | Keywords: Component: coap | Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon May 20 12:43:55 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1B521F96EC for ; Mon, 20 May 2013 12:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.38 X-Spam-Level: X-Spam-Status: No, score=-102.38 tagged_above=-999 required=5 tests=[AWL=0.219, 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 olSbznaek7oM for ; Mon, 20 May 2013 12:43: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 23EC021F96EB for ; Mon, 20 May 2013 12:43:54 -0700 (PDT) Received: from localhost ([127.0.0.1]:49870 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UeVzt-0005Pt-2T; Mon, 20 May 2013 21:43: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, 20 May 2013 19:43:53 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/326 Message-ID: <051.00f753610c3e1a807ab108f35c6719cc@trac.tools.ietf.org> X-Trac-Ticket-ID: 326 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: <20130520194354.23EC021F96EB@ietfa.amsl.com> Resent-Date: Mon, 20 May 2013 12:43:54 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #326: Who defines the application profile for PSK identity hints? 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, 20 May 2013 19:43:55 -0000 #326: Who defines the application profile for PSK identity hints? Sean Turner notes (msg04433d2): Section 9.1.3.1 6) s9.1.3.1: Did you consider whether there should be an application profile for the psk_identity_hint (see Section 5 [RFC4279]) - i.e., is there a standard format for CoAP that should be defined? Carsten says: I don't think the WG has discussed if there can be a single RFC 4279 application profile for all DTLS PSK usage in CoAP or whether these would be specific to particular commissioning models. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: other | Milestone: post-IESG-1 technical | Version: coap-16 Priority: minor | Keywords: Component: coap | Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon May 20 12:53: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 9786021F96DE for ; Mon, 20 May 2013 12:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 YDvUFjvbaHN9 for ; Mon, 20 May 2013 12:53: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 CE98621F96D5 for ; Mon, 20 May 2013 12:53:55 -0700 (PDT) Received: from localhost ([127.0.0.1]:50704 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UeW9Z-0004I0-CA; Mon, 20 May 2013 21:53:53 +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, 20 May 2013 19:53:53 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/325#comment:1 Message-ID: <066.20e3a6c901ba454a76cd53f69d6b04b1@trac.tools.ietf.org> References: <051.fb27520c8fa2e3ba5cf748888757b052@trac.tools.ietf.org> X-Trac-Ticket-ID: 325 In-Reply-To: <051.fb27520c8fa2e3ba5cf748888757b052@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: <20130520195355.CE98621F96D5@ietfa.amsl.com> Resent-Date: Mon, 20 May 2013 12:53:55 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #325: Define curve for keys and certs 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, 20 May 2013 19:53:56 -0000 #325: Define curve for keys and certs Comment (by cabo@tzi.org): Sean Turner also says (comment 5): 5) s9.1.3.3: Going with the thought that there's a chain, we also need to say what algorithms can be used to sign the certificate. I assume we want the use same algorithm for both the TLS_ECDHE_PSK and TLS_ECDHE_ECDSA certificate so text is needed at the end of the paragraph to indicate that: Certificates MUST be signed with ECDSA [RFC6090], and it MUST use SHA-256, SHA-384, or SHA-512 [SHS]. It is RECOMMENDED that the curve match the hash function's output matches the length of the elliptic curve order. On the first bit: You could lock it down to just one curve if that's what you decide to do based on comment 5. On the second bit: if the curve and the hash size line up then you can use RFC 6090 and we - really - want that. Not sure if the above is too cryptic ;) Carsten says: Strawman text under the previous considerations: »Certificates MUST be signed with ECDSA [RFC6090] using secp256r1, and it MUST use SHA-256.« -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: other | Status: new technical | Milestone: post-IESG-1 Priority: major | Version: coap-16 Component: coap | Resolution: Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From cabo@tzi.org Mon May 20 12:56: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 ED4BE21F96AC for ; Mon, 20 May 2013 12:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.39 X-Spam-Level: X-Spam-Status: No, score=-106.39 tagged_above=-999 required=5 tests=[AWL=-0.141, 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 sluHyRT38D1X for ; Mon, 20 May 2013 12:56: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 D64E621F96A1 for ; Mon, 20 May 2013 12:56:29 -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 r4KJuQxW020441 for ; Mon, 20 May 2013 21:56:26 +0200 (CEST) Received: from [192.168.217.105] (p54892542.dip0.t-ipconnect.de [84.137.37.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B31153AC8; Mon, 20 May 2013 21:56:24 +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: <5182C76C.20508@gridmerge.com> Date: Mon, 20 May 2013 21:56:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9BC8D56A-36C0-452B-9392-A607D9F7FA31@tzi.org> References: <3DE60FEA-5117-434B-A837-E2447433AD7E@tzi.org> <2556FC8B-6B6F-4777-8A53-A8A906B14244@sensinode.com> <5182BCB7.4050102@cisco.com> <5182C76C.20508@gridmerge.com> To: "core@ietf.org (core@ietf.org)" X-Mailer: Apple Mail (2.1503) 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: Mon, 20 May 2013 19:56:35 -0000 Could those who have DTLS implementations please have a very, very close = look at Ticket #325? http://trac.tools.ietf.org/wg/core/trac/ticket/325 Gr=FC=DFe, Carsten From zach@sensinode.com Mon May 20 13:01:52 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969C121F936E for ; Mon, 20 May 2013 13:01:52 -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 0rVMxeQ3N50S for ; Mon, 20 May 2013 13:01:48 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 92B7A21F9301 for ; Mon, 20 May 2013 13:01:47 -0700 (PDT) Received: from [10.32.114.74] ([193.185.69.17]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r4KK1ent022968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 May 2013 23:01:41 +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: <066.20e3a6c901ba454a76cd53f69d6b04b1@trac.tools.ietf.org> Date: Mon, 20 May 2013 23:01:40 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5B1D3589-5BD6-4526-8FBF-E04F80E66C8E@sensinode.com> References: <051.fb27520c8fa2e3ba5cf748888757b052@trac.tools.ietf.org> <066.20e3a6c901ba454a76cd53f69d6b04b1@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] #325: Define curve for keys and certs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 May 2013 20:01:52 -0000 On May 20, 2013, at 10:53 PM, core issue tracker = wrote: > #325: Define curve for keys and certs >=20 >=20 > Comment (by cabo@tzi.org): >=20 > Sean Turner also says (comment 5): >=20 > 5) s9.1.3.3: Going with the thought that there's a chain, we = also > need to > say what algorithms can be used to sign the certificate. I = assume > we > want the use same algorithm for both the TLS_ECDHE_PSK and > TLS_ECDHE_ECDSA certificate so text is needed at the end of = the > paragraph > to indicate that: >=20 > Certificates MUST be signed with ECDSA [RFC6090], and it MUST > use SHA-256, SHA-384, or SHA-512 [SHS]. It is RECOMMENDED = that > the curve match the hash function's output matches the length = of > the elliptic curve order. >=20 > On the first bit: You could lock it down to just one curve if > that's what > you decide to do based on comment 5. >=20 > On the second bit: if the curve and the hash size line up then = you > can > use RFC 6090 and we - really - want that. Not sure if the = above > is too > cryptic ;) >=20 > Carsten says: >=20 > Strawman text under the previous considerations: >=20 > =BBCertificates MUST be signed with ECDSA [RFC6090] using > secp256r1, and it MUST use SHA-256.=AB I think this is exactly the right thing to do. It is is aligned with = ZigBee IP, and at least exactly what we are doing with DTLS. I would = recommend text like this, as it minimises interoperability headaches and = keeps implementations as simple as possible. 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 Mon May 20 13:05: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 8E5D421F8F0C for ; Mon, 20 May 2013 13:05:12 -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 TSZgwtAGeP2b for ; Mon, 20 May 2013 13:05:08 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id AC57221F95EB for ; Mon, 20 May 2013 13:05:07 -0700 (PDT) Received: from [10.32.114.74] ([193.185.69.17]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r4KK53hU023458 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 May 2013 23:05:03 +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: <051.00f753610c3e1a807ab108f35c6719cc@trac.tools.ietf.org> Date: Mon, 20 May 2013 23:05:03 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <19F96CA5-D77D-4DFC-AA23-E6FDEE851A60@sensinode.com> References: <051.00f753610c3e1a807ab108f35c6719cc@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] #326: Who defines the application profile for PSK identity hints? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 May 2013 20:05:12 -0000 On May 20, 2013, at 10:43 PM, core issue tracker = wrote: > #326: Who defines the application profile for PSK identity hints? >=20 > Sean Turner notes (msg04433d2): >=20 > Section 9.1.3.1 >=20 > 6) s9.1.3.1: Did you consider whether there should be an application > profile for the psk_identity_hint (see Section 5 [RFC4279]) - i.e., is > there a standard format for CoAP that should be defined? >=20 > Carsten says: >=20 > I don't think the WG has discussed if there can be a single RFC 4279 > application profile for all DTLS PSK usage in CoAP or whether these = would > be specific to particular commissioning models. This is commissioning model specific in my opinion. For example in OMA = Lightweight M2M we define that the psk_identity_hint is not used at all, = as the security settings are configured per endpoint already.=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 trac+core@trac.tools.ietf.org Mon May 20 13:10:10 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102D621F870F for ; Mon, 20 May 2013 13:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 gVrb3efV6w9l for ; Mon, 20 May 2013 13:10: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 D6B6421F85CB for ; Mon, 20 May 2013 13:10:08 -0700 (PDT) Received: from localhost ([127.0.0.1]:52183 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UeWPD-0002mM-8V; Mon, 20 May 2013 22:10:03 +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, 20 May 2013 20:10:03 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/327 Message-ID: <051.0f1d7cc7afdf750452ef5f5ee29513a1@trac.tools.ietf.org> X-Trac-Ticket-ID: 327 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: <20130520201008.D6B6421F85CB@ietfa.amsl.com> Resent-Date: Mon, 20 May 2013 13:10:08 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #327: Discuss processing of ICMP errors 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, 20 May 2013 20:10:10 -0000 #327: Discuss processing of ICMP errors Martin Stiemerling notes (msg04431): Section 4.2 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. [Carsten:] 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. [Martin:] I agree to your points and also the difficulties in using, or even receiving, ICMP error messages, but a recommendation to take them into account when handling network errors would be beneficial for the protocol. This part looks underspecified, especially since the a larger than 1280 byte MTU can also cause issues in IPv6 networks. Not documenting it all looks rather incomplete. An incomplete text proposal: "COAP implementations should take ICMP error messages into account when handling error conditions in the transmission of COAP messages." I'm not sure where this would fit best in the draft. Carsten says: This would probably fit into section 4.2. [msg04442:] We probably need to think about ICMP processing (beyond packet too big) some more. We certainly want to heed the lessons learned from TCP, e.g. as documented in RFC 5927. (We also have to account for the abysmal platform support for ICMP errors in UDP implementations; I remember having had to fork the platform for my own CoAP implementation to handle those properly). (E.g., of RFC 1035, RFC 2865, RFC 3530, none mention ICMP at all. It is easy, but maybe not very useful, to add something like section 18.4 of RFC 3261.) [RFC 3261 section 18.4:] If the transport user asks for a message to be sent over an unreliable transport, and the result is an ICMP error, the behavior depends on the type of ICMP error. Host, network, port or protocol unreachable errors, or parameter problem errors SHOULD cause the transport layer to inform the transport user of a failure in sending. Source quench and TTL exceeded ICMP errors SHOULD be ignored. Draft proposed text: (add at the end of 4.2:) Another reason for giving up retransmission MAY be the receipt of ICMP errors. If it is desired to take account of ICMP errors, to mitigate potential spoofing attacks, implementations SHOULD take care to check the information about the original datagram in the ICMP message, including port numbers and CoAP header information such as message type and code, Message ID, and Token; if this is not possible due to limitations of the UDP service API, ICMP errors SHOULD be ignored. Packet Too Big errors [RFC4443] ("fragmentation needed and DF set" for IPv4 [RFC0792]) cannot properly occur and SHOULD be ignored if the implementation note in section 4.6 is followed; otherwise, they SHOULD feed into a path MTU discovery algorithm [RFC4821]. Source Quench and Time Exceeded ICMP messages SHOULD be ignored. Host, network, port or protocol unreachable errors, or parameter problem errors MAY, after appropriate vetting, be used to inform the application of a failure in sending. Carsten says: I'm not yet entirely happy with the ratio of useful guidance to word count here. Significant analysis of UDP APIs may be required to make this work in any practical sense. I'm not aware of anyone having done this yet. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: other | Milestone: post-WGLC-1 technical | Version: coap-16 Priority: minor | Keywords: Component: coap | Severity: In WG Last | Call | -------------------------+------------------------------------------------- Ticket URL: core From cabo@tzi.org Mon May 20 13:35: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 0224D21F9512; Mon, 20 May 2013 13:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.375 X-Spam-Level: X-Spam-Status: No, score=-106.375 tagged_above=-999 required=5 tests=[AWL=-0.126, 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 LpqEbb1JNsgO; Mon, 20 May 2013 13:35: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 C7B1621F8ADF; Mon, 20 May 2013 13:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r4KKZklu029641; Mon, 20 May 2013 22:35:46 +0200 (CEST) Received: from [192.168.217.105] (p54892542.dip0.t-ipconnect.de [84.137.37.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A7F3F3AE3; Mon, 20 May 2013 22:35:45 +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: <20130515174718.15782.5640.idtracker@ietfa.amsl.com> Date: Mon, 20 May 2013 22:35:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <37E4033F-A13E-4E80-8BB4-3364F6ED3B84@tzi.org> References: <20130515174718.15782.5640.idtracker@ietfa.amsl.com> To: Spencer Dawkins 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] Spencer Dawkins' Discuss on draft-ietf-core-coap-16: (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, 20 May 2013 20:35:57 -0000 Spencer, thank you for this attentive review. I have done some of the changes as simple editorial fixes, these are marked like [1373] below and can be reviewed in http://trac.tools.ietf.org/wg/core/trac/changeset/1373 (Overview in http://trac.tools.ietf.org/wg/core/trac/timeline). Gr=FC=DFe, Carsten = ---------------------------------------------------------------------- DISCUSS: = ---------------------------------------------------------------------- Note that I plan to ballot Yes, after we resolve these = questions.=20 I have three points - the first one is the one I'm most curious = about.=20 In 4.8.1. Changing The Parameters It is recommended that an application environment use consistent values for these = parameters. I'm thinking about this in an IOT/M2M context where it's = somewhere between inconvenient and impossible to change parameters on all = the deployed devices at once. I understand that configuring these = parameters is out of scope for the doc, so assume changing the parameters = is out of scope as well. Yes. The assumption is that implementations better don't start changing the parameters until there is a good way to do so. If you start deploying new devices into that environment with significantly different parameters, is it more likely that = performance would suffer, or that something would break? (I don't care what = the answer is, I'd just like for the reader to have one - do you = HAVE to get the parameters right the first time, or do you WANT to get them = right, but you can deploy new devices with different parameters and let = the old devices be removed/replaced over time?) The answer is different for each parameter and for the direction in which you change it. I don't think we can provide all the definitive answers in this document. This one is on the edge of being a Comment:=20 In 5.10.5. Max-Age The value is intended to be current at the time of = transmission. Servers that provide resources with strict tolerances on the = value of Max-Age SHOULD update the value before each retransmission. Will servers know that resources they serve have strict tolerances? Yes. It is typically in the nature of a resource to be replaced periodically (e.g., the ECB exchange rate -- this has a very specific Max-Age) or be on a more unpredictable basis. In the CoRE model, servers generally should be aware about the nature of the resources they are serving. The answer may be "yes", I'm just asking. If not, I'm wondering if = this should be a MUST. Because both the condition on the SHOULD and the desired behavior are very much local matter, a MUST won't have a much different outcome here. Maybe the SHOULD should be turned into a non-RFC 2119 implementation guidance recommendation. This one is on the edge of being a comment:=20 In 7.2. Resource Discovery The discovery of resources offered by a CoAP endpoint is = extremely important in machine-to-machine applications where there are = no humans in the loop and static interfaces result in fragility. = A CoAP endpoint SHOULD support the CoRE Link Format of discoverable resources as described in [RFC6690]. Is it obvious that this is a SHOULD? Is CoRE Link Format = necessary for resource discovery, or can you also accomplish this with humans = if they're in the loop? I'm just trying to wrap my head around = "it's extremely important but implementations might not do it". This is more of a policy statement, a statement of expectation: If you want to be part of the CoRE ecosystem, do CoAP and do RFC 6690, because that will maximize interoperability. So this may be another SHOULD abuse. (But it does impact interoperability!) = ---------------------------------------------------------------------- COMMENT: = ---------------------------------------------------------------------- I think this specification is well-written, it's important, and = a lot of people will need to read it - that's why I'm being picky on = comments. Martin already has a DISCUSS about some of the more = transport-ish topics (support for UDP-lite, etc.). I'm sympathetic, but didn't = restate them. If Martin is happy, I'll be happy.=20 In this text: Constrained networks like 6LoWPAN support the expensive fragmentation of IPv6 packets = into small link-layer frames. Is "support" the right word here? I'm not understanding "support = the expensive fragmentation". 6LoWPAN has a mechanism for ("supports") sending IPv6 packets that are larger than the link layer packet size. This mechanism is expensive in the sense that it reduces performance similar to the way fragmentation often does. In this text: Although CoAP could be used for compressing simple HTTP interfaces Is "compressing ... interfaces" the right way to say this? No. [1385] I've seen other reviewers mention "short messages" in "CoAP is = based on the exchange of short messages", but it may also be worth = clearly distinguishing "short message" from "SMS" ("short message = service") - as I understand it, the two phrases have nothing in common, but = they are both used in the document (at the beginning of Section 3, and = even in the same paragraph) without qualification. Oh. Good catch. [1373] Response codes correspond to a small subset of HTTP response codes with a few = CoAP specific codes added, as defined in Section 5.9. I get this, but I'm wondering if it's worth thinking about = whether these similar but unrelated namespaces can semi-collide (if HTTP is = extended to include a 328 response code, is it OK for CoAP to define a 3.28 = response code that means nothing like what HTTP 328 means?) Given that = 404 and 4.04 are similar, for example, I'd expect some implementers to = guess what less common CoAP response codes are, based on HTTP response = codes, rather than check carefully. That's an obscure comment, but I thought I = should ask. We already deviate from a strict one-to-one correspondence with HTTP (e.g., we have a 2.05 where HTTP uses 200). So "correspond" may indeed be too strong. [1386] In 6.4. Decomposing URIs into Options, is "fail this algorithm" = clear? It might be a term of art for HTTP folk, but I'm not familiar = with it. 4. If |url| has a component, then fail this = algorithm. Indeed, this is hixiefied speak (right out of text in the versions of the websockets spec that were current when we wrote this, and still in HTML5). It might be shorter to just say "fail", but the intent is not for the node to blow up in smoke, but to specifically fail the algorithm defined in this section (as explained in the introduction to 6.4). In 8.1. Messaging Layer 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. Doesn't this tell me that the MUST NOT is not required for interoperability? I'm only quibbling about the use of 2119 language. This hand-waving is a reaction on a specific restriction of the POSIX = API that I don't wish on anyone. "Please avoid using RFC3542-challenged environments. But if you have to (.NET?)..." On a related point, if there was a sentence that started out "to keep = Bad Thing X from happening, ..." that would be helpful. Good point. [1387] There's similar language in 8.2. Request/Response Layer When a server is aware that a request arrived via multicast, = the server MAY always ignore the request, in particular if it = doesn't have anything useful to respond (e.g., if it only has an empty payload or an error response). but MAY is pretty weak anyway (maybe "can always ignore the = request", to avoid the 2119 question?). This is trying to say that the peer has to be able to cope with the "MAY"-type behaviour described, so it does affect interoperability and I think 2119 language is appropriate here. In 11.3. Risk of amplification This is particularly a problem in nodes that enable NoSec = access, that are accessible from an attacker and can access potential = victims (e.g. on the general Internet), as the UDP protocol provides = no way to verify the source address given in the request packet. An attacker need only place the IP address of the victim in the = source address of a suitable request packet to generate a larger = packet directed at the victim. Such large amplification factors = SHOULD NOT be done in the response if the request is not authenticated. I don't understand what the SHOULD NOT means in practice. Is = this saying the server shouldn't return large resources for NoSec requests = (whatever "large" means), or ? If this is saying the same thing as the = text on using "slicing/blocking mode" two paragraphs, down, it would be = clearer to combine these points in a single paragraph. Well, it is leading into it, and you just have to read one more paragraph before it comes... (I'm still optimistic that at least some implementers read a whole section before writing code.) [ceterum censeo deploy BCP38...] From ietf-secretariat-reply@ietf.org Mon May 20 16:41: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 0D2D721F96A2 for ; Mon, 20 May 2013 16:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.066, 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 gpTcKCO6wfZ7 for ; Mon, 20 May 2013 16:41:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A4121F96A4 for ; Mon, 20 May 2013 16:41:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130520234121.29152.96315.idtracker@ietfa.amsl.com> Date: Mon, 20 May 2013 16:41:21 -0700 From: IETF Secretariat Subject: [core] Milestones changed for core WG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 May 2013 23:41:23 -0000 Changed milestone "CoAP protocol specification with mapping to HTTP Rest API submitted to IESG as PS", set due date to December 2012 from December 2012, resolved as "Done", added draft-ietf-core-coap to milestone. Changed milestone "Blockwise transfers in CoAP submitted to IESG", set due date to February 2013 from February 2013. Changed milestone "Observing Resources in CoAP submitted to IESG", set due date to February 2013 from February 2013. Changed milestone "Group Communication for CoAP submitted to IESG", set due date to April 2013 from April 2013. Changed milestone "HOLD (date TBD) Constrained security bootstrapping specification submitted to IESG", set due date to December 2099 from December 2099. URL: http://datatracker.ietf.org/wg/core/charter/ From cabo@tzi.org Mon May 20 16:46: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 C3C1F21F9630 for ; Mon, 20 May 2013 16:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.362 X-Spam-Level: X-Spam-Status: No, score=-106.362 tagged_above=-999 required=5 tests=[AWL=-0.113, 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 MG7T-bp5dIXh for ; Mon, 20 May 2013 16:46: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 95EA421F9698 for ; Mon, 20 May 2013 16:46: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 r4KNke1b004833 for ; Tue, 21 May 2013 01:46:40 +0200 (CEST) Received: from [192.168.217.105] (p54892542.dip0.t-ipconnect.de [84.137.37.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A17103B27; Tue, 21 May 2013 01:46:40 +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: <20130520234121.29152.96315.idtracker@ietfa.amsl.com> Date: Tue, 21 May 2013 01:46:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130520234121.29152.96315.idtracker@ietfa.amsl.com> To: "core@ietf.org (core@ietf.org)" X-Mailer: Apple Mail (2.1503) Subject: Re: [core] Milestones changed for core WG X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 May 2013 23:46:50 -0000 Since the timing of this E-Mail may be confusing, a little bit of = explanation: I just tried out the new datatracker functionality that now allows the = WG chairs to tick off charter milestones via the Web interface. Of course, the submission (and thus fulfillment of the milestone) = already happened on 2013-03-13; we just never ticked off the item in the = charter. Gr=FC=DFe, Carsten From andrewmcgr@google.com Mon May 20 17:24: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 93EAF21F9714 for ; Mon, 20 May 2013 17:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 qNxeBP+UGCz7 for ; Mon, 20 May 2013 17:24:15 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id EBDD121F9711 for ; Mon, 20 May 2013 17:24:14 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id ox1so18564veb.8 for ; Mon, 20 May 2013 17:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=UssxD5bAZMh+BF5TsBfPctjr+V5+ceENknFkiX2mqBw=; b=f2/vDp8GR9u/gRY+NLH+gmTg7h9UZi55w1T9MfLaqNc8QFPWMwyks0PyfrEXrwLHgo OP3W5lA92fIxpv/b68lsRjyWOyK5khgpVg74EkhxBecYNGAye70qos+wK1FqsHf2T0fJ nib1O5K5C3t2KYjka7GQf1vmr6szw9yb3iNLnfgBT4w87iD0KJI0Ll82BYJ+QGTO4lmm lKSSnZiehvYgITw7PcOHu/0+JOvYCZQF30aOCBMQBbb7l4m3gDWBZRx4aPMkyf3CZNme +KkyyFv1KfFv655/MaThEcqk955hqypNYVbFwafSDIGU/F64k6cxXRFA2+whOHtVDchn pMTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=UssxD5bAZMh+BF5TsBfPctjr+V5+ceENknFkiX2mqBw=; b=YDHE9ZpebOwMt2eXzelRlUBCdhsyqHOsHcMzDPh/3yMjbeXbKyq78Rjr8Wf2ONpWBF usg6mvHPkj8I3rRag+hlUEszi0h5sszcJB1NuAYap7C0GdxQUs2q+cokel+iPLPRh1oz y4Ufq1eAb6L9EK/M3JLVeLLJaF6TXcvmZ70AtD9JCKjnGrvDQwt4A9Ih/CrzjLsbcPds f8WD5Iq7VM7vOYzxlLuZ/n6XUBz3GxEIjFBh78psleVnZ5EvjTBok9hSnCqZRbITTQMj CiM70BoJAeKxXyCvxlhk3kZVcr02yqF90GfkqJi6R+BvCVvDtr7otXqwZlasrKHcmN8i bZ+Q== MIME-Version: 1.0 X-Received: by 10.58.133.81 with SMTP id pa17mr34824494veb.37.1369095854316; Mon, 20 May 2013 17:24:14 -0700 (PDT) Received: by 10.220.238.82 with HTTP; Mon, 20 May 2013 17:24:14 -0700 (PDT) Date: Tue, 21 May 2013 10:24:14 +1000 Message-ID: From: Andrew Mcgregor To: core@ietf.org Content-Type: multipart/alternative; boundary=047d7b6730040f7be804dd2f7829 X-Gm-Message-State: ALoCoQn3KmggO2sZIWUK9NR7hFKQ8iQCycxxD+GYeIrSeCRzt6YbeaI8C41thZ+XC2FRvUKNA1SJoNglFrYqYDy2BEczXXMScg/q363PYdSOySYNiu74MotT2QrEMpMwvXBB7XVOT64V7VP4fZSuOb+JY2udt5979eXcv47VOcLCyfrqWAVwaExNqJQ+tRy7cY6Jmw4/rhPr X-Mailman-Approved-At: Mon, 20 May 2013 17:26:15 -0700 Subject: [core] draft-castellani-core-http-mapping: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 May 2013 00:24:15 -0000 --047d7b6730040f7be804dd2f7829 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Consensus of the room in Orlando was to adopt draft-castellani-core-http-mapping as a working group document. This email is a call for confirmation of that consensus. Please respond if you support the adoption of this document. The charter says "The WG will define a mapping from CoAP to an HTTP REST API; this mapping will not depend on a specific application." We have the normative parts covered in core-coap, but additional elucidation for implementers seems worthwhile. =95 Sep 2013 Submission to IESG of "Best Practices for HTTP-CoAP Mapping Implementation" for Informational (We can discuss if a non-BCP should have "Best Practices" in the title, but the objective is to provide examples of good usage for implementers, not to give strong recommendations.) --=20 Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 --047d7b6730040f7be804dd2f7829 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Consensus of the room in Orlando was to adopt=A0draft-cas= tellani-core-http-mapping as a working group document. =A0This emai= l is a call for confirmation of that consensus. =A0Please respond if you su= pport the adoption of this document.

The charter says &q= uot;The WG will define a mapping from CoAP to
an HTTP REST API; this mapping will not depend on a specific
applica= tion." =A0We have the normative parts covered in core-coap, but=
additional elucidation for implementers seems worthwhile.

=95 Sep 2013 Submission to IESG of "Best Practices for HTTP-CoAP Mapp= ing
=A0 Implementation" for Informational

(We can discuss if a non-BCP should have "Best Practices" in the=
title, but the objective is to provide examples of good usage forim= plementers, not to give strong recommendations.)

--
Andrew McGregor=A0|=A0SRE=A0|=A0andrewmcgr@= google.com=A0|=A0= +61 4 8143 7128
--047d7b6730040f7be804dd2f7829-- From andrewmcgr@google.com Mon May 20 17:25: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 7D67721F9711 for ; Mon, 20 May 2013 17:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 OHiBrmMzhR5R for ; Mon, 20 May 2013 17:25:44 -0700 (PDT) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D4FB221F95E4 for ; Mon, 20 May 2013 17:25:43 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id cz11so18974veb.6 for ; Mon, 20 May 2013 17:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=Oo6D4li0dfbmNNehlZPjHZPcvOwyA5bUAlB48UYnjmQ=; b=EDqYaLAfBpBMPie/9XpfAKA3E67zYMghQ/MBsbkvJfLk2U9xoUOamVYpTIgw8rG6lL eE62o1w2rWrVBut88sX6wjdEU6lG26LJTKPj6YyH9j5EExMEDaAhe73ZLZa0UELDY6Xw w+6F8GojYqbUqzd6ajY1r9EeTxpPUOHXERaXXZVrdEma5mqRXSPnCr82J5Qt1LFuHgQf dxveOEPzuIoE3oSwoUudf0AUXUvaFfCqvSTLXAWpD7zECAYzNKwowr6UH7Zy7DP2GAvY 9+qhCMwwg8+sRxkDRd1wvINW0Ljm38ZZc1Kh55eqo5bofEeNlOUnjrXa04s7QU9senX5 COFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=Oo6D4li0dfbmNNehlZPjHZPcvOwyA5bUAlB48UYnjmQ=; b=pd1Q93yCqyt2WtOR4oPGoLY/7IjPeuuiub2oUUEmnX2VI/iJLE7p/+GW17gANZcxsg tSh5ECGX5Yv9PVPgjavjXpC8nxeF6g/ar5VoRqjsso2TjQy3zoPq7YLlWhPgnPZ75s5d XnfDKtU2qeEAxp0XzFGXA2+VKo1NU/BiE4WXdkrwqyrg1l+RFtpLplPtLaNVwsfG69hM wc4d1pkARga8chDwVsZq/3L1V8sqjmQZHqyBTVFtToSBCqKj5NT2rGyWU3+qHc1FCSWt Xz3R+2FSHuFL/eCIShj+qBCLqRCEfP06M9vevz4okEaOzp/OqPSme/V/RXVhjz/mZIK1 yCFA== MIME-Version: 1.0 X-Received: by 10.52.171.135 with SMTP id au7mr2982191vdc.126.1369095943091; Mon, 20 May 2013 17:25:43 -0700 (PDT) Received: by 10.220.238.82 with HTTP; Mon, 20 May 2013 17:25:43 -0700 (PDT) Date: Tue, 21 May 2013 10:25:43 +1000 Message-ID: From: Andrew Mcgregor To: core@ietf.org Content-Type: multipart/alternative; boundary=089e0160cdf65a1b5c04dd2f7d1e X-Gm-Message-State: ALoCoQnLC3oM+3PnrgoW5T+O9gl/8/TBD9oo2qCTsWGqy35P5eMmqWA5YtZa9f0Cf0da8JDVOT4+PKmxHxl/srzMYvL469jmdUZvW4CWfUDgoXJE0sEIgnYhvPzZf5Kgq9pwQ5z7dZlvGL99Z+TDUrDLVqQHy18fFBMnHrPN5ilFO3070kqUausUEmKbTRObF3CRiu4kvAaw X-Mailman-Approved-At: Mon, 20 May 2013 17:26:15 -0700 Subject: [core] draft-shelby-core-resource-directory: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 May 2013 00:25:44 -0000 --089e0160cdf65a1b5c04dd2f7d1e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Consensus of the room in Orlando was to adopt draft-shelby-core-resource- directory as a working group document. This email is a call for confirmation of that consensus. Please respond if you support the adoption of this document. >From the charter: 5) A definition of how to use CoAP to advertise about or query for a Device's description. This description may include the device name and a list of its Resources, each with a URL, an interface description URI (pointing e.g. to a Web Application Description Language (WADL) document) and an optional name or identifier. The name taxonomy used for this description will be consistent with other IETF work, e.g. draft-cheshire-dnsext-dns-sd. RFC 6690 has some of this; the resource directory would add protocol elements on top of CoAP that enhance the "advertise about or query for" aspect. =95 Feb 2014 Submission to IESG of "CoRE Resource Directory" for Proposed Standard --=20 Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 --089e0160cdf65a1b5c04dd2f7d1e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Consensus of the room in Orlando was to adopt=A0d= raft-shelby-core-resource-directory=A0as a working group do= cument. =A0This email is a call for confirmation of that consensus. =A0Plea= se respond if you support the adoption of this document.

From the charter:

<= span style=3D"font-family:arial,sans-serif;font-size:12.727272033691406px">= =A0 =A0 5) A definition of how to use CoAP to advertise about or query for = a
=A0 =A0 Device's description. This description may include the device = name and
=A0 =A0 a list of its Resources, each with a URL, an interface description= URI
=A0 =A0 (pointing e.g. to a Web Application Description Language (WADL)
=A0 =A0 document) and an optional name or identifier. The name taxonomy= used
=A0 =A0 for this description will be consistent with other IETF work,
=A0 =A0 e.g. draft-cheshire-dnsext-dns-sd.

<= span style=3D"font-family:arial,sans-serif;font-size:12.727272033691406px">= RFC 6690 has some of this; the resource directory would add protocol=
elements on top of CoAP that enhance the "advertise about or query
for" aspect.

=95 Feb 2014 Submission to IESG of "CoRE Resource Directory" for=
=A0 Proposed Standard
--
Andrew McGregor=A0|=A0SRE=A0|=A0andrewmcgr@google.com=A0|=A0+61 4 8143 7128
--089e0160cdf65a1b5c04dd2f7d1e-- From andrewmcgr@google.com Mon May 20 17:27: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 ED3D921F9731 for ; Mon, 20 May 2013 17:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.500, 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 pBBnIPWUnx9v for ; Mon, 20 May 2013 17:27:41 -0700 (PDT) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2DF21F9721 for ; Mon, 20 May 2013 17:27:35 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id gf12so18386vcb.27 for ; Mon, 20 May 2013 17:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=z+IUSKkH5CDkeu7wduYp9sYf8iRA4h9fW/b0/clGgKk=; b=pGo6C3wWmjFytufq7pDJDpXMQ7lbBne4ORov8URSi/PsDKWs13aL0QGhZGdbBKz1rd iXr6l+wf85BCBiWIXeXBTc2zQ7Hkkj6yVZPfplHYUEO1cXQrP2zOZV1PvMPP4UcvdCOW 55FElUDYtSI8Gwb4oDRW8h49FmQnjaOjB4brwcZYkQ2UmCWzXXwrsyOFwgi4boj7wzwc wkmqJxtllBRBSn3g+RiodrbApRa6OGZHrEtwJujUA1fG+o+qkU0KOAc0ml5FlIV32lFJ RBg3zeNXFDEkOl33/U7u6zHKNAKbdKr9g6r2EbYR3pMvFXmF6UcVOoUFIfbMKNvCvc1q D/Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=z+IUSKkH5CDkeu7wduYp9sYf8iRA4h9fW/b0/clGgKk=; b=OiYGm6nmTOY2lzhvKhYyF7eHX3AjmoNEjUfewI6ry0AyslFfbd8laCNF8XqzeReYCx GqlO9CIKy65Va9agK+/lvJtHcxvKXPzqjxPC8Y7SiZzqTYNUZf7n3iNNVWxqBHbt3ybE NkK27RQTzS+97RX9C3ijxSbTL52JU2ZzntwtHnu6SCPkwk5P2b6POGmElxd0C/hjAKsL i0Vc9Agstd9lasReo5C2xkIDwojTuMZfiIweGoPcIEwCcXbJqXL45iTBKXAW7a15ZHjn GLj1KxMY21ksB7R7A9aCdilgF9LTFnq4qjyMpfncwu9rbt7EhpyYk16ncZUz+e4Vs30a UpNQ== MIME-Version: 1.0 X-Received: by 10.221.4.131 with SMTP id oc3mr12374817vcb.49.1369096055500; Mon, 20 May 2013 17:27:35 -0700 (PDT) Received: by 10.220.238.82 with HTTP; Mon, 20 May 2013 17:27:35 -0700 (PDT) Date: Tue, 21 May 2013 10:27:35 +1000 Message-ID: From: Andrew Mcgregor To: core@ietf.org Content-Type: multipart/alternative; boundary=089e01293fe20d561204dd2f84a4 X-Gm-Message-State: ALoCoQm3Y2ynfIjgSEwIulSD7Mtl/WB6xZp1gRMYp3P+zDREeiQzbt+kGg2Y65Qurp8oq1EdWxXBinEroL/qyAONl0JmZGoz+CT8AiX2N/MJQYhCYF9Lqwt0Q9SuzSL6BhHTI81fq4BQL7dgOIMSXYnP/gqug8+jSrg5m6NN9MO5ZZqbrKLgfozO25VufZXZ4pRi3C5KBvkM X-Mailman-Approved-At: Mon, 20 May 2013 17:28:48 -0700 Subject: [core] draft-bormann-core-links-json: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 May 2013 00:27:47 -0000 --089e01293fe20d561204dd2f84a4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Consensus of the room in Orlando was to adopt draft-bormann-core-links-json= as a working group document. This email is a call for confirmation of that consensus. Please respond if you support the adoption of this document. >From the charter: 5) A definition of how to use CoAP to advertise about or query for a Device's description. This description may include the device name and a list of its Resources, each with a URL, an interface description URI (pointing e.g. to a Web Application Description Language (WADL) document) and an optional name or identifier. The name taxonomy used for this description will be consistent with other IETF work, e.g. draft-cheshire-dnsext-dns-sd. This is for making the resource discovery information available to backends. On a technical level, this is a no-brainer. =95 May 2013 Submission to IESG of "Representing CoRE Link Collections in JSON" for Proposed Standard --=20 Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 --089e01293fe20d561204dd2f84a4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Consensus of the room in Orlando was to adopt=A0d= raft-bormann-core-links-json=A0as a working group document. =A0This= email is a call for confirmation of that consensus. =A0Please respond if y= ou support the adoption of this document.

From the charter:

<= span style=3D"font-family:arial,sans-serif;font-size:12.727272033691406px">= =A0 =A0 5) A definition of how to use CoAP to advertise about or query for = a
=A0 =A0 Device's description. This description may include the device = name and
=A0 =A0 a list of its Resources, each with a URL, an interface description= URI
=A0 =A0 (pointing e.g. to a Web Application Description Language (WADL)
=A0 =A0 document) and an optional name or identifier. The name taxonomy= used
=A0 =A0 for this description will be consistent with other IETF work,
=A0 =A0 e.g. draft-cheshire-dnsext-dns-sd.

<= span style=3D"font-family:arial,sans-serif;font-size:12.727272033691406px">= This is for making the resource discovery=A0information available t= o backends. =A0On a technical level, this is a=A0no-brainer.=

<= span style=3D"font-family:arial,sans-serif;font-size:12.727272033691406px">= =95 May 2013 Submission to IESG of "Representing CoRE Link Collections=
=A0 in JSON" for Proposed Standard

<= /div>--
= Andrew McGregor=A0|= =A0SRE=A0|=A0andrewmcgr@google.com= =A0|=A0+61 4 8143 712= 8
--089e01293fe20d561204dd2f84a4-- From andrewmcgr@google.com Mon May 20 17:28: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 D56F921F9733 for ; Mon, 20 May 2013 17:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 uwtOz80YU76B for ; Mon, 20 May 2013 17:28:41 -0700 (PDT) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 337F821F972E for ; Mon, 20 May 2013 17:28:41 -0700 (PDT) Received: by mail-vb0-f49.google.com with SMTP id q12so17597vbe.36 for ; Mon, 20 May 2013 17:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=RDb/mcEpeM4Iby0y97EVq9rytwb83KiZe6aPXLnqyjE=; b=mBx2HaHUOzILmovjI1XWwpb164g7ExXDi7mC9x72GiYCzMm2SbrizrXPdW3mgw0rI9 pHu6OMhmkYP/fjj5+8ZTHpFPH+VhudtTjh+MA2lWFZVfAYmoWJAw2UriZIINrHJGAwbu EDcf9AC7+tT7a92Z2R5W/8Mogh3gLV1sF460ae+gcdVjzpCo7Vq08wDCvheh8z45bZ8M CfenacjGQVSU2vmKsRcbFJ51ZbmZRI0UFaRKOccZUQt1ef+hh1SoBJe3U2oeS4BVp9bI 55yQoY/209k6eq9SuVWj24/85y5KOlxn8SQp1W0nHyN1MUJzWcq6hBo7PFg6/s41TqOH Acow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=RDb/mcEpeM4Iby0y97EVq9rytwb83KiZe6aPXLnqyjE=; b=FmE/ym09PHeRh2ZCAqzt5Z3B1V0o/hZeUonaHVOiDfqU4xFLlrhXcErm3qBBf66mJe X/70cDHmOGUSfSMsWFCqCFbvavI9KD22+DkSu4KX6E5u3SLyooC9rjltYY/NoR8/4bHt IwM0W35y7M9PTGGF8qP3yR2g8r8WwquRqpWp7t1HT5fZL4wZKGPp4YTCCprGOAKDLMvH Piz4SWa2Jzk0yN8CEUHgXH4HlmIwgm26XuB12rZozV/k4vUsPTPF5dMmak/6UhOkeF/6 0Bt+n/8FFGuOolij/UVDl9SBmOnWOZbt5iCw2mOA5Q4/qCoD7vbZiL0iSV+NE93o+OAC x8/w== MIME-Version: 1.0 X-Received: by 10.52.95.227 with SMTP id dn3mr2638904vdb.111.1369096120478; Mon, 20 May 2013 17:28:40 -0700 (PDT) Received: by 10.220.238.82 with HTTP; Mon, 20 May 2013 17:28:40 -0700 (PDT) Date: Tue, 21 May 2013 10:28:40 +1000 Message-ID: From: Andrew Mcgregor To: core@ietf.org Content-Type: multipart/alternative; boundary=20cf307d04aeecd3e704dd2f87a0 X-Gm-Message-State: ALoCoQm/M1H6AuPpEPH0irtwmpkqbzCpuYlXQrvg9/MZWvOtXGATi3IESO4L8kbA8kWU8nG6t1ZdOAs/uWWPFVYiets3C/BLnmclYDqXdftEoXSBSJB4pSAf48guvCadO1PPc3QwCu+4MHAUNsQaXXA+qiVNP3uWfA8FNVYcndz/q0TqrSpPdvKhDIky4niRNEwmEqP8GOHv X-Mailman-Approved-At: Mon, 20 May 2013 17:28:48 -0700 Subject: [core] draft-shelby-core-interfaces: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 May 2013 00:28:42 -0000 --20cf307d04aeecd3e704dd2f87a0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Consensus of the room in Orlando was to adopt draft-shelby-core-interfaces = as a working group document. This email is a call for confirmation of that consensus. Please respond if you support the adoption of this document. Since REST is not yet in wide use in the microcontroller community, documenting some examples of good CoAP design will be beneficial. In particular, it is not widely understood how to map certain concepts such as batching or binding to REST. We don't have an explicit charter item for documenting this, but it is natural to have explanatory material with the base specification. (LWIG is not the right group for this as this is not about protocol implementation, but about design of REST interfaces.) =95 Dec 2013 Submission to IESG of "CoRE Interfaces" for Informational (Again, the objective is to provide examples of good usage for implementers, not to standardize or even give strong recommendations.) Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 --20cf307d04aeecd3e704dd2f87a0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Consensus of the room in Orlando was to adopt=A0d= raft-shelby-core-interfaces=A0as a working group document. =A0This = email is a call for confirmation of that consensus. =A0Please respond if yo= u support the adoption of this document.

Since REST is not yet in wide use in the microcontroll= er community,
documenting some examples of good CoAP design will be beneficial. =A0In
particular, it is not widely understood how to map certain concepts=
<= span style=3D"font-family:arial,sans-serif;font-size:12.727272033691406px">= such as batching or binding to REST. =A0We don't have an explicit
charter item for documenting this, but it is natural to have
explana= tory material with the base specification. =A0(LWIG is not the
right group for this as this is not about protocol implementation, but
about design of REST interfaces.)

=95 Dec 2013 Submission to IESG of "CoRE Interfaces" for Informa= tional

<= span style=3D"font-family:arial,sans-serif;font-size:12.727272033691406px">= (Again, the objective is to provide examples of good usage for
implementers, not to standardize or even give strong recommendations.)

An= drew McGregor=A0|=A0S= RE=A0|=A0andrewmcgr@google.com=A0|<= /span>=A0+61 4 8143 7128
--20cf307d04aeecd3e704dd2f87a0-- From cabo@tzi.org Mon May 20 17:36: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 A960F21F9740; Mon, 20 May 2013 17:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.466 X-Spam-Level: X-Spam-Status: No, score=-105.466 tagged_above=-999 required=5 tests=[AWL=-0.971, BAYES_00=-2.599, FRT_FOLLOW1=1.332, FRT_FOLLOW2=0.422, 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 1PZRBYui73Bn; Mon, 20 May 2013 17:36:09 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9184221F9080; Mon, 20 May 2013 17:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r4L0a3DV000822; Tue, 21 May 2013 02:36:03 +0200 (CEST) Received: from [192.168.217.105] (p54892542.dip0.t-ipconnect.de [84.137.37.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3FDA23B2B; Tue, 21 May 2013 02:36:02 +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: Tue, 21 May 2013 02:36:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <67597EC5-A3C6-4E12-A4CA-40A85100657F@tzi.org> References: <20130516062941.27229.92525.idtracker@ietfa.amsl.com> To: Sean Turner 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] Sean Turner's Discuss on draft-ietf-core-coap-16: (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, 21 May 2013 00:36:18 -0000 On May 17, 2013, at 08:29, Carsten Bormann wrote: > thank you for the juicy review -- this was well worth the wait; we are = still busy processing the finer points and will have a response soon. Finally, here is that response. Tickets #323 to #326 are in response to this; there is also another = security-related ticket (#322); we will probably process these in the = course of this week. This should lead to a -17 by early next week. Gr=FC=DFe, Carsten = ---------------------------------------------------------------------- DISCUSS: = ---------------------------------------------------------------------- Thanks for a clear draft. Makes things so much easier to = review. Just want to discuss a couple of things before moving to yes = (hopefully). 0) s9.1.3.2: Before I get in to the nitty-gritty of the specific = concerns I have with DTLS use of Raw Public Keys, I have to ask whether = use of the DTLS client_certificate_url extension was considered? If raw = public keys is just about size then that'd work wouldn't it. If you're = about dumping processing of paths, then that's another thing. The motivation for RPK usage is mainly about avoiding having to include certificate processing in constrained nodes, but also about a rough fit between classic certificates and some deployment models. (We do have a certificate mode though, and *that* might benefit from client_certificate_url, but see below.) I seem to remember we discussed client_certificate_url as an optimization strategy briefly at least on the hallways (I cannot find a record on the mailing list). Adding state logic to retrieve the certs from the URLs didn't seem attractive to the implementers involved. So we haven't spent the energy to discuss whether section 11.3 of RFC 6066 affects our area of application much, and how we would set the parameters mentioned there. Clearly, adding SHA-1 just for this (we are clean SHA-256 otherwise) is another turn-off. 1) s9.1.3.2.1: What's really hung me up on this draft is the raw = public key option. Primarily, the TLS draft is not quite done yet; I'm = still in discussions with the authors. Two issues that affect your = draft: a) By draft-ietf-tls-oob-pubkey taking a pass on = specifying all of the ways an identity can be bound to a public key, it = leaves it up to the application to specify that mechanism. This binding is = important because you can't get peer authentication without it; I'm really = worried that if this mode gets widely deployed people will say they have = "DTLS security" but few (if any) are actually do the work necessary to = bind the identity to the key. So, you specify that binding = in the provisioning section (good ;) but I want to make sure that it's = clear who's doing what to whom: i) s9.1.3.2.1: For machines it's perfect appropriate to generate = the key and install it because we doubt it'll be able to do that well = enough right (i.e., crummy entropy sources)? I want to make it clear = that that's been done by the manufacturer. In this mode the device has an asymmetric key pair but without = an X.509 certificate (called a raw public key). to: In this mode the device has an asymmetric key pair but without = an X.509 certificate (called a raw public key); the asymmetric key paid is generated by the manufacturer and installed on the = device. Well, it is probably more appropriate to suggest this than to state it as a fact. (It is certainly not a requirement, as there are other ways to do provisioning.) See also the new section 11.6. Strawman text: ...; e.g., the asymmetric key pair is generated by the manufacturer and installed on the device. -> #324 ii) s9.1.3.2.1: This draft does that binding using Stephen's = naming thing with hashes, but I want to make sure that it's clear who is = identifier, it now says: An identifier is calculated from the public key as described in Section 2 of [RFC6920].=20 Is it the=20 An identifier is calculated by the endpoint from from the public key as described in Section 2 of [RFC6920].=20 Indeed. [1381] b) draft-ietf-tls-oob-pubkey is likely to take a pass on = specifying a mechanism for revoking the public key and identity binding. = Note that ocsp-/multi-ocsp staplingwon't work because there's no way to = request information about a certificate that you don't have information = about. =20 I'm not trying to gold plate the security mechanism here but I = think we need some words on how revocation for this mode will be handled.=20= However, I suspect you'll want to use the ACLs....there's a = mechanism for including ACLs during provisioning but is there a way to update = them later? What happens if a new node gets installed or removed? = Is there a requirement for ACLs to be supported; the text has a SHOULD but = that seems to be about ACL provisioning support not ACL support. Indeed, in practice RPK requires you to do the same thing as PSK: You need to keep an ACL list on both the DTLS Client and Server. The only way to "revoke" an RPK is to remove it from your ACL. This is exactly what commercial systems are doing. Clarified somewhat in [1382]. 2) s9.1.3.2: Another TLS-related issue: When referring to TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 please = include the MTI curve(s). Ever so glad that conservative curves are being = used. In the following, I assumed you'd want the one must and the two = mays but I can understand if you don't. I'd argue you do have algorithm = agility with DTLS so you could get away with just the MUST ad not the = MAYs. Unrelated to you, but I thought I'd let you know about: the = curve requirements will almost certainly be removed from the mcgrew = draft at my direction because no other D/TLS EC cipher suite specifies an = MTI curve.=20 There's support for conservative curves, but not enough interest = in starting to add MTI curves instead of the application picking = them. Note the Zigbee folks also point to the mcgrew draft but it seems = their drafts already include the curves so we ought to be good to go on both = fronts. I think we need to be clear that choosing this particular cipher = suite that it means an implementation needs to support the extensions = defined in RFC 4492 - or if it doesn't. I'm assuming you want it to so = I'm going to propose some tweaking: OLD: 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], [RFC5246], [RFC4492].=20 NEW: 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]. The key used MUST be ECDSA-capable; the curve secp256r1 MUST be supported, and the curves secp384r1 and secp521r1 MAY be supported [RFC4492]; these curves are equivalent to the NIST P-256, P-384, and P-521 curves. Implementations MUST use/support (?) the Supported Elliptic Curves Extension and Supported Point Format extensions [RFC4492]; the uncompressed point format MUST be supported; [RFC6090] can be used as an implementation method. The mcgrew draft had the following instead of the last sentence = so I'm open to whichever but I think something about the folllowing = needs to be added: o The uncompressed point format MUST be supported. Other point formats MAY be used. o The client SHOULD offer the elliptic_curves extension and the server SHOULD expect to receive it. o The client MAY offer the ec_point_formats extension, but the server need not expect to receive it. o [RFC6090] MAY be used as an implementation method. And then, I think we need to specify how the MTI would look: = namely by adding the following on to the end of the paragraph. When the mandatory to implement DTLS cipher suite and curve and used the SubjectPublicKeyInfo indicates an algorithm of id-ecPublicKey with the namedCurves object identifier set to secp256r1 [RFC5480]. If secp384r1 or secp521r1 are used the those object identifiers [RFC5480] are included instead.=20 That way everybody knows what values go in the SPKI of the = oob-pubkey draft. Note they tried to change that field recently and I had = to remind them not to. -> #325 3) s9: I know we're all about be liberal in what you accept, = but in this context that might be challengeing; this bit: ... all modes of DTLS may not be applicable. Some DTLS cipher suites can add significant implementation complexity as well as some initial handshake overhead needed when setting up the security association. Made me wonder whether you considered which other DTLS = extensions might be useful in addition to the EC ones and SNI as well as what = extensions should be profiled out? For example, max_fragment_length looks = pretty useful in this context as well as certificate_url. But does = heartbeat make any sense? No, we didn't spend energy vetting the set of extensions. There is considerable interest in the CoRE community to do more work about DTLS in constrained environments. I would expect more documents to come out of that, which will clarify the appropriate options. 4) s8: I think you need to make it pretty darn clear in s8 that multi-cast is an unsecured "mode" as specified in this document. = It's kind of buried in s9. Now also discussed in 8.1. [1379] 5) s9.1.2: (worried about a DoS attack) Do you mean that = responses to secured-CoAP messages returned unsecured are silently = discarded/ignored or rejected and then that kicks off an error code response? Other IESG members have already commented that we use the term "Rejected" in a surprising way. Here, a piggy-backed response from an unexpected endpoint would simply be discarded (or, if it is using a Confirmable message, elicit a Reset). 6) s9.1.3.1: Did you consider whether there should be an = application profile for the psk_identity_hint (see Section 5 [RFC4279]) - = i.e., is there a standard format for CoAP that should be defined? I don't think the WG has discussed if there can be a single RFC 4279 application profile for all DTLS PSK usage in CoAP or whether these would be specific to particular commissioning models. -> #326 7) s9.1.3.3: When you say "the Certificate must be validated" = I'm just checking that you're think there's going to be a certificate = chain? If there's no chain the validation rules in 5280 don't apply. 9.1.3.3 is about the Certificate Mode, in which we indeed do expect to have a certificate chain. 8) s9: If you're going to allow more than two entities to share = the preshared keys I think it's worth pointing out you really can't = get peer authentication with either CoAP or DTLS. The description in s9 = and elsewhere seems to imply that more than one peer might share the = same key. The implication seemed kind of obvious, but it sure can't hurt to point it out explicitly. [1376] 9) Either in s9 or s11 we need to say something about devices = with bad entropy sources not bothering to make keys because they won't be = of any use. If they've got bad entropy sources the manufacturer or = whoever should be making the keys. Good point. So far we talk about entropy only in 9.1.3.1. There are other considerations about constrained nodes (e.g., susceptibility to timing attacks) that may be worth mentioning. I'll propose adding a section 11.6 with some of these considerations. -> #323 = ---------------------------------------------------------------------- COMMENT: = ---------------------------------------------------------------------- 0) s1.2: Is the "CoAP-to-CoAP proxy" definition missing? s5.7 = refers to s1.2 for the definition but that term is not in s1.2. Added. [1377] 1) s7.1: I think this is munged: A server is discovered by a client by the client knowing or (It parses for me.) I put the "knowing or" into a parenthesis to clarify. [1375] 2) s9: In the NoSec option is worth also pointing to the link = layer security (IEEE 802.15.4)? Added (with an exhortation about key management). [1378] 3) s9.1: Because there's no s9.2 (I assume that might have been = an IPsec-secured CoAP section at one point) you can drop the = header. Renumbering a spec at this stage of widespread discussion is expensive -- all comments that refer to a section lose their footing. I'd try to avoid this now (and maybe do it at the RFC editor stage). 4) s9.1.3.3: The 1st paragraph is about certificates but it only indicates the TLS cipher suite needed to be supported. It = should say what values go in the certificate to support the cipher suite.=20= Basically, need to point to RFC 5480 and say include values X. = I'd suggest: OLD: Implementations in Certificate Mode MUST support the mandatory = to implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in [RFC5246]. NEW (adding some more stuff + references): Implementations in Certificate Mode MUST support the mandatory = to implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in [RFC5246]. Namely, the certificate includes a SubjectPublicKeyInfo that indicates an algorithm of = id-ecPublicKey with namedCurves secp256r1, secp384r1, or secp521r1 [RFC5480]; the public key format is uncompressed [RFC5480]; if included the key usage extension indicates digitalSignature. Included in: -> #325 5) s9.1.3.3: Going with the thought that there's a chain, we = also need to say what algorithms can be used to sign the certificate. I = assume we want the use same algorithm for both the TLS_ECDHE_PSK and TLS_ECDHE_ECDSA certificate so text is needed at the end of the = paragraph to indicate that: Certificates MUST be signed with ECDSA [RFC6090], and it MUST use SHA-256, SHA-384, or SHA-512 [SHS]. It is RECOMMENDED that the curve match the hash function's output matches the length of the elliptic curve order.=20 On the fist bit: You could lock it down to just one curve if = that's what you decide to do based on comment #5. =20 On the second bit: if the curve and the hash size line up then = you can use RFC 6090 and we - really - want that. Not sure if the above = is too cryptic ;) Included in: -> #325 6) s9.1.3.3: Maybe a typo MUST instead of must: 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. [1383] 7) s9.1.3.3: r/further work./further study. [1374] From Akbar.Rahman@InterDigital.com Mon May 20 20:49: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 8BD3121F8A14 for ; Mon, 20 May 2013 20:49:55 -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, 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 fY+mk5JDW9Ax for ; Mon, 20 May 2013 20:49:50 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1887621F8A6B for ; Mon, 20 May 2013 20:49:47 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 May 2013 23:49:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CE55D6.3C4B3F2C" Date: Mon, 20 May 2013 23:49:47 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] draft-shelby-core-resource-directory: call for adoption Thread-Index: Ac5VuhshktZQGQGJQq2XAAKuosju+wAG/3lg References: From: "Rahman, Akbar" To: "Andrew Mcgregor" , X-OriginalArrivalTime: 21 May 2013 03:49:46.0764 (UTC) FILETIME=[3C8E3CC0:01CE55D6] Subject: Re: [core] draft-shelby-core-resource-directory: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 May 2013 03:49:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CE55D6.3C4B3F2C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 =20 =20 Akbar =20 From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Andrew Mcgregor Sent: Monday, May 20, 2013 8:26 PM To: core@ietf.org Subject: [core] draft-shelby-core-resource-directory: call for adoption =20 Consensus of the room in Orlando was to adopt draft-shelby-core-resource-directory as a working group document. This email is a call for confirmation of that consensus. Please respond if you support the adoption of this document. >From the charter: 5) A definition of how to use CoAP to advertise about or query for a Device's description. This description may include the device name and a list of its Resources, each with a URL, an interface description URI (pointing e.g. to a Web Application Description Language (WADL) document) and an optional name or identifier. The name taxonomy used for this description will be consistent with other IETF work, e.g. draft-cheshire-dnsext-dns-sd. RFC 6690 has some of this; the resource directory would add protocol elements on top of CoAP that enhance the "advertise about or query for" aspect. * Feb 2014 Submission to IESG of "CoRE Resource Directory" for Proposed Standard --=20 Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 ------_=_NextPart_001_01CE55D6.3C4B3F2C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

 

Akbar

 

From:= = core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Andrew Mcgregor
Sent: Monday, May 20, 2013 8:26 = PM
To: core@ietf.org
Subject: [core] = draft-shelby-core-resource-directory: call for = adoption

 

Consensus of = the room in Orlando was to = adopt draft-shelby-core-resource-directory as a working group = document.  This email is a call for confirmation of that consensus. =  Please respond if you support the adoption of this = document.


From the = charter:

    5) A definition of how to use CoAP to = advertise about or query for a
    Device's description. = This description may include the device name and
    a list = of its Resources, each with a URL, an interface description = URI
    (pointing e.g. to a Web Application Description = Language (WADL)
    document) and an optional name or = identifier. The name taxonomy used
    for this description = will be consistent with other IETF work,
    e.g. = draft-cheshire-dnsext-dns-sd.

RFC 6690 has some of this; the = resource directory would add protocol
elements on top of CoAP that = enhance the "advertise about or query
for" = aspect.

• Feb 2014 Submission to IESG of "CoRE = Resource Directory" for
  Proposed = Standard

-- =

Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 = 7128

------_=_NextPart_001_01CE55D6.3C4B3F2C-- From Akbar.Rahman@InterDigital.com Mon May 20 20:50: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 9E95921F970E for ; Mon, 20 May 2013 20:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCI1yDS1hXuW for ; Mon, 20 May 2013 20:50:12 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id CD36821F969C for ; Mon, 20 May 2013 20:50:04 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 May 2013 23:50:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CE55D6.46B2663B" Date: Mon, 20 May 2013 23:50:05 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] draft-bormann-core-links-json: call for adoption Thread-Index: Ac5VundlWz6JaPXeQxi2/5ixae5jQQAG8k4A References: From: "Rahman, Akbar" To: "Andrew Mcgregor" , X-OriginalArrivalTime: 21 May 2013 03:50:04.0264 (UTC) FILETIME=[46FC8680:01CE55D6] Subject: Re: [core] draft-bormann-core-links-json: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 May 2013 03:50:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CE55D6.46B2663B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 =20 Akbar =20 From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Andrew Mcgregor Sent: Monday, May 20, 2013 8:28 PM To: core@ietf.org Subject: [core] draft-bormann-core-links-json: call for adoption =20 Consensus of the room in Orlando was to adopt draft-bormann-core-links-json as a working group document. This email is a call for confirmation of that consensus. Please respond if you support the adoption of this document. =20 >From the charter: 5) A definition of how to use CoAP to advertise about or query for a Device's description. This description may include the device name and a list of its Resources, each with a URL, an interface description URI (pointing e.g. to a Web Application Description Language (WADL) document) and an optional name or identifier. The name taxonomy used for this description will be consistent with other IETF work, e.g. draft-cheshire-dnsext-dns-sd. This is for making the resource discovery information available to backends. On a technical level, this is a no-brainer. * May 2013 Submission to IESG of "Representing CoRE Link Collections in JSON" for Proposed Standard =20 --=20 Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 ------_=_NextPart_001_01CE55D6.46B2663B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

Akbar

 

From:= = core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Andrew Mcgregor
Sent: Monday, May 20, 2013 8:28 = PM
To: core@ietf.org
Subject: [core] = draft-bormann-core-links-json: call for = adoption

 

Consensus of = the room in Orlando was to = adopt draft-bormann-core-links-json as a working group = document.  This email is a call for confirmation of that consensus. =  Please respond if you support the adoption of this = document.

 

From the = charter:

    5) A definition of how to use CoAP to = advertise about or query for a
    Device's description. = This description may include the device name and
    a list = of its Resources, each with a URL, an interface description = URI
    (pointing e.g. to a Web Application Description = Language (WADL)
    document) and an optional name or = identifier. The name taxonomy used
    for this description = will be consistent with other IETF work,
    e.g. = draft-cheshire-dnsext-dns-sd.

This is for making the resource = discovery information available to backends.  On a technical = level, this is a no-brainer.

• May 2013 Submission to = IESG of "Representing CoRE Link Collections
  in JSON" = for Proposed Standard

 

-- =

Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 = 7128

------_=_NextPart_001_01CE55D6.46B2663B-- From Akbar.Rahman@InterDigital.com Mon May 20 20:50: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 C3B3121F971C for ; Mon, 20 May 2013 20:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQYcl8vMm4Hw for ; Mon, 20 May 2013 20:50:21 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3A221F9700 for ; Mon, 20 May 2013 20:50:21 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 May 2013 23:50:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CE55D6.50A71C3A" Date: Mon, 20 May 2013 23:50:21 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] draft-shelby-core-interfaces: call for adoption Thread-Index: Ac5Vupq9RLcCgWoBQHCw4LcMc3FzcgAG7AZA References: From: "Rahman, Akbar" To: "Andrew Mcgregor" , X-OriginalArrivalTime: 21 May 2013 03:50:20.0998 (UTC) FILETIME=[50F5EE60:01CE55D6] Subject: Re: [core] draft-shelby-core-interfaces: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 May 2013 03:50:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CE55D6.50A71C3A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 =20 Akbar =20 From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Andrew Mcgregor Sent: Monday, May 20, 2013 8:29 PM To: core@ietf.org Subject: [core] draft-shelby-core-interfaces: call for adoption =20 Consensus of the room in Orlando was to adopt draft-shelby-core-interfaces as a working group document. This email is a call for confirmation of that consensus. Please respond if you support the adoption of this document. =20 Since REST is not yet in wide use in the microcontroller community, documenting some examples of good CoAP design will be beneficial. In particular, it is not widely understood how to map certain concepts such as batching or binding to REST. We don't have an explicit charter item for documenting this, but it is natural to have explanatory material with the base specification. (LWIG is not the right group for this as this is not about protocol implementation, but about design of REST interfaces.) * Dec 2013 Submission to IESG of "CoRE Interfaces" for Informational (Again, the objective is to provide examples of good usage for implementers, not to standardize or even give strong recommendations.) =20 Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 ------_=_NextPart_001_01CE55D6.50A71C3A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

Akbar

 

From:= = core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Andrew Mcgregor
Sent: Monday, May 20, 2013 8:29 = PM
To: core@ietf.org
Subject: [core] = draft-shelby-core-interfaces: call for = adoption

 

Consensus of = the room in Orlando was to = adopt draft-shelby-core-interfaces as a working group = document.  This email is a call for confirmation of that consensus. =  Please respond if you support the adoption of this = document.

 

Since REST is = not yet in wide use in the microcontroller community,
documenting = some examples of good CoAP design will be beneficial. =  In
particular, it is not widely understood how to map certain = concepts
such as batching or binding to REST.  We don't have an = explicit
charter item for documenting this, but it is natural to = have
explanatory material with the base specification.  (LWIG is = not the
right group for this as this is not about protocol = implementation, but
about design of REST interfaces.)

• = Dec 2013 Submission to IESG of "CoRE Interfaces" for = Informational

(Again, the objective is to provide examples of = good usage for
implementers, not to standardize or even give strong = recommendations.)

 

Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 = 7128

------_=_NextPart_001_01CE55D6.50A71C3A-- From Akbar.Rahman@InterDigital.com Mon May 20 20:50: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 5E38F21F96FE for ; Mon, 20 May 2013 20:50: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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1bRbdt6jvIq for ; Mon, 20 May 2013 20:50:43 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 95D1E21F9700 for ; Mon, 20 May 2013 20:50:42 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 May 2013 23:50:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CE55D6.5D4CDAF4" Date: Mon, 20 May 2013 23:50:43 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] draft-castellani-core-http-mapping: call for adoption Thread-Index: Ac5VuhnYw/UGDwgbRy2/+yDGzE43bQAHDwiQ References: From: "Rahman, Akbar" To: "Andrew Mcgregor" , X-OriginalArrivalTime: 21 May 2013 03:50:42.0216 (UTC) FILETIME=[5D9B8A80:01CE55D6] Subject: Re: [core] draft-castellani-core-http-mapping: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 May 2013 03:50:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CE55D6.5D4CDAF4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 =20 Akbar =20 From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Andrew Mcgregor Sent: Monday, May 20, 2013 8:24 PM To: core@ietf.org Subject: [core] draft-castellani-core-http-mapping: call for adoption =20 Consensus of the room in Orlando was to adopt draft-castellani-core-http-mapping as a working group document. This email is a call for confirmation of that consensus. Please respond if you support the adoption of this document. =20 The charter says "The WG will define a mapping from CoAP to an HTTP REST API; this mapping will not depend on a specific application." We have the normative parts covered in core-coap, but additional elucidation for implementers seems worthwhile. * Sep 2013 Submission to IESG of "Best Practices for HTTP-CoAP Mapping Implementation" for Informational (We can discuss if a non-BCP should have "Best Practices" in the title, but the objective is to provide examples of good usage for implementers, not to give strong recommendations.) =20 --=20 Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 ------_=_NextPart_001_01CE55D6.5D4CDAF4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

Akbar

 

From:= = core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Andrew Mcgregor
Sent: Monday, May 20, 2013 8:24 = PM
To: core@ietf.org
Subject: [core] = draft-castellani-core-http-mapping: call for = adoption

 

Consensus of the room in Orlando was to = adopt draft-castella= ni-core-http-mapping as a working group document.  This email is a = call for confirmation of that consensus.  Please respond if you = support the adoption of this document.

 

The charter = says "The WG will define a mapping from CoAP to
an HTTP REST = API; this mapping will not depend on a specific
application." =  We have the normative parts covered in core-coap, = but
additional elucidation for implementers seems = worthwhile.

• Sep 2013 Submission to IESG of "Best = Practices for HTTP-CoAP Mapping
  Implementation" for = Informational

(We can discuss if a non-BCP should have "Best = Practices" in the
title, but the objective is to provide = examples of good usage for
implementers, not to give strong = recommendations.)

 

-- =

Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 = 7128

------_=_NextPart_001_01CE55D6.5D4CDAF4-- From spencer@wonderhamster.org Mon May 20 23:16: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 3FA7421F9709; Mon, 20 May 2013 23:16:06 -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 lXyGKvCjziXA; Mon, 20 May 2013 23:16:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8EC321F96FC; Mon, 20 May 2013 23:16:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Spencer Dawkins" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130521061604.16833.88106.idtracker@ietfa.amsl.com> Date: Mon, 20 May 2013 23:16:04 -0700 Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Spencer Dawkins' Yes on draft-ietf-core-coap-16: (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, 21 May 2013 06:16:06 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-core-coap-16: 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: ---------------------------------------------------------------------- On 5/20/2013 3:35 PM, Carsten Bormann wrote: > Spencer, > = > thank you for this attentive review. > I have done some of the changes as simple editorial fixes, these are > marked like [1373] below and can be reviewed in > http://trac.tools.ietf.org/wg/core/trac/changeset/1373 > (Overview in http://trac.tools.ietf.org/wg/core/trac/timeline). Hi, Carsten, Thank you for the quick and careful response. = We've discussed my DISCUSS, so I'm changing my ballot position to YES (but please make Martin happy on his transport-ish DISCUSS :-). = I have a couple of places where I've suggested text that seems clearer to me, but I moved these to COMMENTs on my ballot. > Gr=C3=BC=C3=9Fe, Carsten > = > = ---------------------------------------------------------------------- > DISCUSS: > = ---------------------------------------------------------------------- > = > Note that I plan to ballot Yes, after we resolve these questions. > = > I have three points - the first one is the one I'm most curious about. > = > In 4.8.1. Changing The Parameters > = > It is recommended that an > application environment use consistent values for these parameters. > = > I'm thinking about this in an IOT/M2M context where it's somewhere > between inconvenient and impossible to change parameters on all the > deployed devices at once. I understand that configuring these parameters > is out of scope for the doc, so assume changing the parameters is out of > scope as well. > = > Yes. The assumption is that implementations better don't start > changing the parameters until there is a good way to do so. > = > If you start deploying new devices into that environment with > significantly different parameters, is it more likely that performance > would suffer, or that something would break? (I don't care what the > answer is, I'd just like for the reader to have one - do you HAVE to get > the parameters right the first time, or do you WANT to get them right, > but you can deploy new devices with different parameters and let the old > devices be removed/replaced over time?) > = > The answer is different for each parameter and for the direction in > which you change it. I don't think we can provide all the definitive > answers in this document. For "changing the parameters" above ... I think what you're saying in your response to me is more helpful than the way I read the text in -16. If I'm understanding correctly, the situation is = - the specification doesn't include a way to change parameters without a "flag day", and = - if an application environment uses consistent parameters, everything will work, but = - if an application environment doesn't use consistent parameters, what happens next is out of scope for this specification (and, for extra credit, is unpredictable) As a COMMENT, I'd be more comfortable if = It is recommended that an application environment use consistent values for these parameters. continued to say "Operation with inconsistent values in an application environment is outside the scope of this specification", or something like that. = As an aside, also as a COMMENT ... I am now noticing that the specification has "recommended" in lower case. If you were telling me it's "RECOMMENDED =3D SHOULD =3D do it this way unless you're sure what you're doing, and if you think you know what you're doing, but you break it, you own it", I'd be more comfortable. That's consistent with the way I read this text in 2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. = > This one is on the edge of being a Comment: > = > In 5.10.5. Max-Age > = > The value is intended to be current at the time of transmission. > Servers that provide resources with strict tolerances on the value of > Max-Age SHOULD update the value before each retransmission. > = > Will servers know that resources they serve have strict > tolerances? > = > Yes. It is typically in the nature of a resource to be replaced > periodically (e.g., the ECB exchange rate -- this has a very specific > Max-Age) or be on a more unpredictable basis. In the CoRE model, > servers generally should be aware about the nature of the resources > they are serving. > = > The > answer may be "yes", I'm just asking. If not, I'm wondering if this > should be a MUST. > = > Because both the condition on the SHOULD and the desired behavior are > very much local matter, a MUST won't have a much different outcome > here. Maybe the SHOULD should be turned into a non-RFC 2119 > implementation guidance recommendation. Your explanation was very helpful to me. I'm fine with SHOULD as 2119 language here - that matches what I'm hearing you say. > This one is on the edge of being a comment: > = > In 7.2. Resource Discovery > = > The discovery of resources offered by a CoAP endpoint is extremely > important in machine-to-machine applications where there are no > humans in the loop and static interfaces result in fragility. A CoAP > endpoint SHOULD support the CoRE Link Format of discoverable > resources as described in [RFC6690]. > = > Is it obvious that this is a SHOULD? Is CoRE Link Format necessary for > resource discovery, or can you also accomplish this with humans if > they're in the loop? I'm just trying to wrap my head around "it's > extremely important but implementations might not do it". > = > This is more of a policy statement, a statement of expectation: If you > want to be part of the CoRE ecosystem, do CoAP and do RFC 6690, > because that will maximize interoperability. So this may be another > SHOULD abuse. (But it does impact interoperability!) This is very helpful. What I wasn't getting was whether there was any way other than CoRE Link Format to discover resources when there are no humans in the loop. Again, as a COMMENT, I'm reading this response as "SHOULD support the CoRE Link Format of discoverable resources as described in [RFC6690] if there are no humans in the loop, to maximize interoperability". Am I getting that right? = And if this is a statement of expectation, I'm OK with SHOULD, if the working group thinks that's appropriate. > = ---------------------------------------------------------------------- > COMMENT: > = ---------------------------------------------------------------------- > = > I think this specification is well-written, it's important, and a lot of > people will need to read it - that's why I'm being picky on comments. > = > Martin already has a DISCUSS about some of the more transport-ish topics > (support for UDP-lite, etc.). I'm sympathetic, but didn't restate them. > If Martin is happy, I'll be happy. > = > In this text: > Constrained networks like > 6LoWPAN support the expensive fragmentation of IPv6 packets into > small link-layer frames. > = > Is "support" the right word here? I'm not understanding "support the > expensive fragmentation". > = > 6LoWPAN has a mechanism for ("supports") sending IPv6 packets that are > larger than the link layer packet size. This mechanism is expensive > in the sense that it reduces performance similar to the way > fragmentation often does. So I should be reading this as something like "Constrained networks like 6LoWPAN support the fragmentation of IPv6 packets into small link-layer frames, but this mechanism is expensive in that it reduces performance"? > = > In this text: > Although CoAP could be used for > compressing simple HTTP interfaces > = > Is "compressing ... interfaces" the right way to say this? > = > No. [1385] Ack. > I've seen other reviewers mention "short messages" in "CoAP is based on > the exchange of short messages", but it may also be worth clearly > distinguishing "short message" from "SMS" ("short message service") - as > I understand it, the two phrases have nothing in common, but they are > both used in the document (at the beginning of Section 3, and even in the > same paragraph) without qualification. > = > Oh. Good catch. [1373] Ack. > Response codes > correspond to a small subset of HTTP response codes with a few CoAP > specific codes added, as defined in Section 5.9. > = > I get this, but I'm wondering if it's worth thinking about whether these > similar but unrelated namespaces can semi-collide (if HTTP is extended to > include a 328 response code, is it OK for CoAP to define a 3.28 response > code that means nothing like what HTTP 328 means?) Given that 404 and > 4.04 are similar, for example, I'd expect some implementers to guess what > less common CoAP response codes are, based on HTTP response codes, rather > than check carefully. That's an obscure comment, but I thought I should > ask. > = > We already deviate from a strict one-to-one correspondence with HTTP > (e.g., we have a 2.05 where HTTP uses 200). So "correspond" may > indeed be too strong. [1386] Ack. > In 6.4. Decomposing URIs into Options, is "fail this algorithm" clear? > It might be a term of art for HTTP folk, but I'm not familiar with it. > = > 4. If |url| has a component, then fail this algorithm. > = > Indeed, this is hixiefied speak (right out of text in the versions of > the websockets spec that were current when we wrote this, and still in > HTML5). It might be shorter to just say "fail", but the intent is not > for the node to blow up in smoke, but to specifically fail the > algorithm defined in this section (as explained in the introduction to > 6.4). No, I think you're doing this right (thanks for the clue!). > In 8.1. Messaging Layer > = > 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. > = > Doesn't this tell me that the MUST NOT is not required for > interoperability? I'm only quibbling about the use of 2119 > language. > = > This hand-waving is a reaction on a specific restriction of the POSIX API > that I don't wish on anyone. "Please avoid using RFC3542-challenged > environments. But if you have to (.NET?)..." > = > On a > related point, if there was a sentence that started out "to keep Bad > Thing X from happening, ..." that would be helpful. > = > Good point. [1387] Ack. = > There's similar language in 8.2. Request/Response Layer > = > When a server is aware that a request arrived via multicast, the > server MAY always ignore the request, in particular if it doesn't > have anything useful to respond (e.g., if it only has an empty > payload or an error response). > = > but MAY is pretty weak anyway (maybe "can always ignore the request", to > avoid the 2119 question?). > = > This is trying to say that the peer has to be able to cope with the > "MAY"-type behaviour described, so it does affect interoperability and > I think 2119 language is appropriate here. I understand why you're using 2119 language now. I'm not sure I understand how the requirement for the peer is different from either the request or response getting lost. I'm reading the spec as saying that multicast requests are sent as non-confirmable at the messaging layer, so if there's no confirmation at the messaging layer and no response from the server at the request/response layer, does the peer see any difference between hearing nothing back because something was lost, and hearing nothing back because the server had nothing to say? > In 11.3. Risk of amplification > = > This is particularly a problem in nodes that enable NoSec access, > that are accessible from an attacker and can access potential victims > (e.g. on the general Internet), as the UDP protocol provides no way > to verify the source address given in the request packet. = An > attacker need only place the IP address of the victim in the source > address of a suitable request packet to generate a larger packet > directed at the victim. Such large amplification factors SHOULD NOT > be done in the response if the request is not authenticated. > = > I don't understand what the SHOULD NOT means in practice. Is this saying > the server shouldn't return large resources for NoSec requests (whatever > "large" means), or ? If this is saying the same thing as the text on > using "slicing/blocking mode" two paragraphs, down, it would be clearer > to combine these points in a single paragraph. > = > Well, it is leading into it, and you just have to read one more > paragraph before it comes... (I'm still optimistic that at least some > implementers read a whole section before writing code.) > [ceterum censeo deploy BCP38...] My apologies for not being clearer in my comment. = I'm looking at this text: This is particularly a problem in nodes that enable NoSec access, that are accessible from an attacker and can access potential victims (e.g. on the general Internet), as the UDP protocol provides no way to verify the source address given in the request packet. An attacker need only place the IP address of the victim in the source address of a suitable request packet to generate a larger packet directed at the victim. Such large amplification factors SHOULD NOT be done in the response if the request is not authenticated. [annoyingly distracting paragraph deleted here] A CoAP server can reduce the amount of amplification it provides to an attacker by using slicing/blocking modes of CoAP [I-D.ietf-core-block] and offering large resource representations only in relatively small slices. E.g., for a 1000 byte resource, a 10-byte request might result in an 80-byte response (with a 64-byte block) instead of a 1016-byte response, considerably reducing the amplification provided. and I'm not seeing = - the SHOULD NOT, which is conditional on whether the request is authenticated, and = - the subsequent suggestion to use slicing/blocking, which is not conditional on authentication, seamlessly hooked together. = Is the intention that the recommendation to use slicing/blocking be conditional on authentication, or should the server always use slicing/blocking whether the request is authenticated or not? Is that clearer? ("writing text is hard" :-) Spencer From stokcons@xs4all.nl Mon May 20 23:33: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 8470321F971C for ; Mon, 20 May 2013 23:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[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 czA3pCBfr1Ch for ; Mon, 20 May 2013 23:33:25 -0700 (PDT) Received: from smtp-vbr15.xs4all.nl (smtp-vbr15.xs4all.nl [194.109.24.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3A29321F86F0 for ; Mon, 20 May 2013 23:33:24 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube6.xs4all.net [194.109.20.204]) by smtp-vbr15.xs4all.nl (8.13.8/8.13.8) with ESMTP id r4L6XNVH080966 for ; Tue, 21 May 2013 08:33:23 +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, 21 May 2013 08:33:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 21 May 2013 08:33:23 +0200 From: peter van der Stok To: Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: References: Message-ID: <58036cd11d2ebdb9d3ee4c9a3d76e569@xs4all.nl> X-Sender: stokcons@xs4all.nl (1ImIRueRSbfhxIUop8rNCVTz96bWO+Zp) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [core] draft-castellani-core-http-mapping: call for adoption 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, 21 May 2013 06:33:30 -0000 +1 Peter van der stok Rahman, Akbar schreef op 2013-05-21 05:50: > +1 > > Akbar > > FROM: core-bounces@ietf.org [mailto:core-bounces@ietf.org] ON BEHALF > OF Andrew Mcgregor > SENT: Monday, May 20, 2013 8:24 PM > TO: core@ietf.org > SUBJECT: [core] draft-castellani-core-http-mapping: call for adoption > > Consensus of the room in Orlando was to adopt > draft-castellani-core-http-mapping as a working group document. This > email is a call for confirmation of that consensus. Please respond if > you support the adoption of this document. > > The charter says "The WG will define a mapping from CoAP to > an HTTP REST API; this mapping will not depend on a specific > application." We have the normative parts covered in core-coap, but > additional elucidation for implementers seems worthwhile. > > * Sep 2013 Submission to IESG of "Best Practices for HTTP-CoAP Mapping > Implementation" for Informational > > (We can discuss if a non-BCP should have "Best Practices" in the > title, but the objective is to provide examples of good usage for > implementers, not to give strong recommendations.) > > -- > > Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From stokcons@xs4all.nl Mon May 20 23:38: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 8E41421F972D for ; Mon, 20 May 2013 23:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[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 dKHoNAJF8Dg1 for ; Mon, 20 May 2013 23:38:16 -0700 (PDT) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by ietfa.amsl.com (Postfix) with ESMTP id 29B0021F971D for ; Mon, 20 May 2013 23:38:16 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube6.xs4all.net [194.109.20.204]) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id r4L6cEPX003737 for ; Tue, 21 May 2013 08:38:14 +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, 21 May 2013 08:38:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 21 May 2013 08:38:14 +0200 From: peter van der Stok To: Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: References: Message-ID: X-Sender: stokcons@xs4all.nl (hhqqv3g8/BtFhexbFLWcv/dvueB5XGrL) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [core] draft-shelby-core-interfaces: call for adoption 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, 21 May 2013 06:38:21 -0000 +1 However, the scope and purpose of the document should be a bit clearer. I see it as a base document that can be referred to by other documents that provide additional coap based services. Having only ONE protocol with related security handling for many coap based services can be beneficial for the total amount of code in the coap based nodes. Peter van der Stok Rahman, Akbar schreef op 2013-05-21 05:50: > +1 > > Akbar > > FROM: core-bounces@ietf.org [mailto:core-bounces@ietf.org] ON BEHALF > OF Andrew Mcgregor > SENT: Monday, May 20, 2013 8:29 PM > TO: core@ietf.org > SUBJECT: [core] draft-shelby-core-interfaces: call for adoption > > Consensus of the room in Orlando was to adopt > draft-shelby-core-interfaces as a working group document. This email > is a call for confirmation of that consensus. Please respond if you > support the adoption of this document. > > Since REST is not yet in wide use in the microcontroller community, > documenting some examples of good CoAP design will be beneficial. In > particular, it is not widely understood how to map certain concepts > such as batching or binding to REST. We don't have an explicit > charter item for documenting this, but it is natural to have > explanatory material with the base specification. (LWIG is not the > right group for this as this is not about protocol implementation, but > about design of REST interfaces.) > > * Dec 2013 Submission to IESG of "CoRE Interfaces" for Informational > > (Again, the objective is to provide examples of good usage for > implementers, not to standardize or even give strong recommendations.) > > Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From stokcons@xs4all.nl Mon May 20 23: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 2141221F96FB for ; Mon, 20 May 2013 23:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[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 QFUDmafbGxCC for ; Mon, 20 May 2013 23:47:36 -0700 (PDT) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by ietfa.amsl.com (Postfix) with ESMTP id CC28321F9709 for ; Mon, 20 May 2013 23:47:35 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube6.xs4all.net [194.109.20.204]) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id r4L6lYEv067054 for ; Tue, 21 May 2013 08:47:34 +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, 21 May 2013 08:47:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 21 May 2013 08:47:34 +0200 From: peter van der Stok To: Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: References: Message-ID: X-Sender: stokcons@xs4all.nl (PT/WI5N7v7GfcLlPLF25+sP6v4HR/O3u) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [core] draft-shelby-core-resource-directory: call for adoption 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, 21 May 2013 06:47:41 -0000 I certainly support this, but with the remark that relation to DNS and DNS-SD should be clarified in the document. This concerns how to handle name resolution with respect to information stored in resource directory and text from lynn draft about conversion of attribute values to RR in DNS Peter van der Stok Rahman, Akbar schreef op 2013-05-21 05:49: > +1 > > Akbar > > FROM: core-bounces@ietf.org [mailto:core-bounces@ietf.org] ON BEHALF > OF Andrew Mcgregor > SENT: Monday, May 20, 2013 8:26 PM > TO: core@ietf.org > SUBJECT: [core] draft-shelby-core-resource-directory: call for > adoption > > Consensus of the room in Orlando was to adopt > draft-shelby-core-resource-directory as a working group document. This > email is a call for confirmation of that consensus. Please respond if > you support the adoption of this document. > > From the charter: > > 5) A definition of how to use CoAP to advertise about or query for a > Device's description. This description may include the device name > and > a list of its Resources, each with a URL, an interface description > URI > (pointing e.g. to a Web Application Description Language (WADL) > document) and an optional name or identifier. The name taxonomy used > for this description will be consistent with other IETF work, > e.g. draft-cheshire-dnsext-dns-sd. > > RFC 6690 has some of this; the resource directory would add protocol > elements on top of CoAP that enhance the "advertise about or query > for" aspect. > > * Feb 2014 Submission to IESG of "CoRE Resource Directory" for > Proposed Standard > > -- > > Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From stokcons@xs4all.nl Tue May 21 00:04: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 CF30521F9727 for ; Tue, 21 May 2013 00:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[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 8kKyx0U4aBYa for ; Tue, 21 May 2013 00:04:12 -0700 (PDT) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE1121F9726 for ; Tue, 21 May 2013 00:04:12 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube6.xs4all.net [194.109.20.204]) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id r4L74A6a067474 for ; Tue, 21 May 2013 09:04:10 +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, 21 May 2013 09:04:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 21 May 2013 09:04:10 +0200 From: peter van der Stok To: Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: References: Message-ID: <5bc6a98b6f42ec654e7e5fd7d0675f83@xs4all.nl> X-Sender: stokcons@xs4all.nl (Esbr04iJe8u0HZewryfqO00eb922ZF0g) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [core] draft-bormann-core-links-json: call for adoption 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, 21 May 2013 07:04:18 -0000 I don't know. Could the contents of links-json not be combined with core-interfaces? I can imagine that we have other documents defining the json contents for different management subjects Peter van der stok Rahman, Akbar schreef op 2013-05-21 05:50: > +1 > > Akbar > > FROM: core-bounces@ietf.org [mailto:core-bounces@ietf.org] ON BEHALF > OF Andrew Mcgregor > SENT: Monday, May 20, 2013 8:28 PM > TO: core@ietf.org > SUBJECT: [core] draft-bormann-core-links-json: call for adoption > > Consensus of the room in Orlando was to adopt > draft-bormann-core-links-json as a working group document. This email > is a call for confirmation of that consensus. Please respond if you > support the adoption of this document. > > From the charter: > > 5) A definition of how to use CoAP to advertise about or query for a > Device's description. This description may include the device name > and > a list of its Resources, each with a URL, an interface description > URI > (pointing e.g. to a Web Application Description Language (WADL) > document) and an optional name or identifier. The name taxonomy used > for this description will be consistent with other IETF work, > e.g. draft-cheshire-dnsext-dns-sd. > > This is for making the resource discovery information available to > backends. On a technical level, this is a no-brainer. > > * May 2013 Submission to IESG of "Representing CoRE Link Collections > in JSON" for Proposed Standard > > -- > > Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Tue May 21 01:40: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 18D1C21F90DF for ; Tue, 21 May 2013 01:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.723 X-Spam-Level: X-Spam-Status: No, score=-106.723 tagged_above=-999 required=5 tests=[AWL=-0.474, 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 1xywWlkMrUnf for ; Tue, 21 May 2013 01:40: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 04BAE21F90BB for ; Tue, 21 May 2013 01:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r4L8enig017416; Tue, 21 May 2013 10:40: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 9CE703CCB; Tue, 21 May 2013 10:40: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: <5bc6a98b6f42ec654e7e5fd7d0675f83@xs4all.nl> Date: Tue, 21 May 2013 10:40:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <954F147E-F9E8-471A-B973-E7A5FB9E2349@tzi.org> References: <5bc6a98b6f42ec654e7e5fd7d0675f83@xs4all.nl> To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.1503) Cc: core@ietf.org Subject: Re: [core] draft-bormann-core-links-json: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 May 2013 08:40:58 -0000 On May 21, 2013, at 09:04, peter van der Stok = wrote: > Could the contents of links-json not be combined with core-interfaces? Core-Interfaces is meant as an informational document describing good = approaches, while links-json actually defines a format. > I can imagine that we have other documents defining the json contents = for different management subjects Right, but they are on quite different timelines. Generally I'd expect all future documents defining a format to define = the (or a) JSON version, if that is desired. links-json just fills in that gap retroactively for 6690. Gr=FC=DFe, Carsten From stokcons@xs4all.nl Tue May 21 01:56: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 94EE721F9670 for ; Tue, 21 May 2013 01:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[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 LMYzVMdOL3xc for ; Tue, 21 May 2013 01:56:03 -0700 (PDT) Received: from smtp-vbr15.xs4all.nl (smtp-vbr15.xs4all.nl [194.109.24.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2652421F96B7 for ; Tue, 21 May 2013 01:56:02 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube6.xs4all.net [194.109.20.204]) by smtp-vbr15.xs4all.nl (8.13.8/8.13.8) with ESMTP id r4L8u1ma005205; Tue, 21 May 2013 10:56:01 +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, 21 May 2013 10:56:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 21 May 2013 10:56:01 +0200 From: peter van der Stok To: Carsten Bormann Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: <954F147E-F9E8-471A-B973-E7A5FB9E2349@tzi.org> References: <5bc6a98b6f42ec654e7e5fd7d0675f83@xs4all.nl> <954F147E-F9E8-471A-B973-E7A5FB9E2349@tzi.org> Message-ID: X-Sender: stokcons@xs4all.nl (dBrDtIIFr1y6hIH+B4ZThWE+PlWpafeK) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Cc: core@ietf.org Subject: Re: [core] draft-bormann-core-links-json: call for adoption 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, 21 May 2013 08:56:09 -0000 Starts to make sense. So, you partially agree about core-interfaces being the base document (informationally or not). Will other "links-exi" documents then also be based on core-interfaces? Or do we need still another document? I mention this need for some generally understood structure beforehand, because at the moment writing a document about for example "coap based management" takes some thinking about which documents (just from core) are relevant and possibly normative. Greetings, peter Carsten Bormann schreef op 2013-05-21 10:40: > On May 21, 2013, at 09:04, peter van der Stok > wrote: > >> Could the contents of links-json not be combined with >> core-interfaces? > > Core-Interfaces is meant as an informational document describing good > approaches, while links-json actually defines a format. > >> I can imagine that we have other documents defining the json contents >> for different management subjects > > Right, but they are on quite different timelines. > Generally I'd expect all future documents defining a format to define > the (or a) JSON version, if that is desired. > links-json just fills in that gap retroactively for 6690. > > Grüße, Carsten From turners@ieca.com Tue May 21 12:08: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 1CD8111E80A3 for ; Tue, 21 May 2013 12:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfoPZIzyWKK6 for ; Tue, 21 May 2013 12:08:21 -0700 (PDT) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [67.18.53.18]) by ietfa.amsl.com (Postfix) with ESMTP id 36CCC21F92E7 for ; Tue, 21 May 2013 12:08:19 -0700 (PDT) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id B85B34EA04CC0; Tue, 21 May 2013 14:08:12 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway07.websitewelcome.com (Postfix) with ESMTP id A99114EA04C86 for ; Tue, 21 May 2013 14:08:12 -0500 (CDT) Received: from [173.73.135.101] (port=64626 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Uerv0-0004Cj-Df; Tue, 21 May 2013 14:08:18 -0500 Message-ID: <519BC621.4070403@ieca.com> Date: Tue, 21 May 2013 15:08:17 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Carsten Bormann References: <20130516062941.27229.92525.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:64626 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, The IESG , core@ietf.org Subject: Re: [core] Sean Turner's Discuss on draft-ietf-core-coap-16: (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, 21 May 2013 19:08:28 -0000 On 5/17/13 2:29 AM, Carsten Bormann wrote: > Sean, > > thank you for the juicy review -- this was well worth the wait; we are still busy processing the finer points and will have a response soon. Wish I could have been quicker. > One quick question: > >> 2) s9.1.3.2: Another TLS-related issue: >> >> When referring to TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 please include the >> MTI curve(s). Ever so glad that conservative curves are being used. In >> the following, I assumed you'd want the one must and the two mays but I >> can understand if you don't. I'd argue you do have algorithm agility >> with DTLS so you could get away with just the MUST ad not the MAYs. > > draft-mcgrew-tls-aes-ccm-ecc-06 says: > > The curves and hash algorithms that must be supported are as follows: > > An implementation that includes either > TLS_ECDHE_ECDSA_WITH_AES_128_CCM or > TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 MUST support secp256r1 and SHA- > 256. > An implementation that includes either > TLS_ECDHE_ECDSA_WITH_AES_256_CCM or > TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 MUST support secp384r1 and SHA- > 384, and MAY support secp521r1 and SHA-512. > > Implementations that use other curves and hash functions SHOULD > select them so that AES-128 is used with a curve and a hash function > supporting a 128-bit security level, and AES-256 is used with a curve > and a hash function supporting a 192-bit or 256-bit security level. > > Exceptions for the "SHOULD" are not given, but it seems to me that leads us to stick with secp256r1 for AES-128. > This means the MUST, but not the MAYs (which would then be used with, say, TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8). I'd be happy with you just picking the one MUST: secp256r1 for AES-128. spt From trac+core@trac.tools.ietf.org Tue May 21 14:33:25 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03EB321F90CD for ; Tue, 21 May 2013 14:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 kvqH8ZmiICCX for ; Tue, 21 May 2013 14:33: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 311F521F8793 for ; Tue, 21 May 2013 14:33:23 -0700 (PDT) Received: from localhost ([127.0.0.1]:47532 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UeuBJ-00075b-Ig; Tue, 21 May 2013 23:33: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, zach@sensinode.com, hauke@hauke-m.de X-Trac-Project: core Date: Tue, 21 May 2013 21:33:17 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/325#comment:3 Message-ID: <066.20d35cb6974c083daf906706e7042b39@trac.tools.ietf.org> References: <051.fb27520c8fa2e3ba5cf748888757b052@trac.tools.ietf.org> X-Trac-Ticket-ID: 325 In-Reply-To: <051.fb27520c8fa2e3ba5cf748888757b052@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, zach@sensinode.com, hauke@hauke-m.de, 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: <20130521213324.311F521F8793@ietfa.amsl.com> Resent-Date: Tue, 21 May 2013 14:33:23 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #325: Define curve for keys and certs 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, 21 May 2013 21:33:25 -0000 #325: Define curve for keys and certs Comment (by hauke@hauke-m.de): The ECC code we implemented is optimized for a specific curve to save space and improve performance on a constrained device. We currently only support the secp256r1 curve and SHA-256, because these are the mandatory ones. I think most implementations for constrained device will just implement one hash algorithm and one curve or make this chooseable at compile time. It would be nice to have a default value for the curve and the hash algorithm in use for a given cipher, so we do not have to support the TLS extensions for this. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: other | Status: new technical | Milestone: post-IESG-1 Priority: major | Version: coap-16 Component: coap | Resolution: Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From Bert.Greevenbosch@huawei.com Tue May 21 23: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 EA5CA21F919D for ; Tue, 21 May 2013 23:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.363 X-Spam-Level: X-Spam-Status: No, score=-3.363 tagged_above=-999 required=5 tests=[AWL=-0.968, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 jOFB4sHKpwgY for ; Tue, 21 May 2013 23:15:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9DE21F8EA6 for ; Tue, 21 May 2013 23:15:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARP55537; Wed, 22 May 2013 06:15:04 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 22 May 2013 07:14:49 +0100 Received: from SZXEML449-HUB.china.huawei.com (10.82.67.192) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 22 May 2013 14:14:58 +0800 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.152]) by szxeml449-hub.china.huawei.com ([10.82.67.192]) with mapi id 14.01.0323.007; Wed, 22 May 2013 14:14:53 +0800 From: Bert Greevenbosch To: "core@ietf.org" Thread-Topic: [core] draft-castellani-core-http-mapping: call for adoption Thread-Index: AQHOVbnYaxOZdX4MH0Sk8fscpJ3e2pkOeyyAgAI+tAA= Date: Wed, 22 May 2013 06:14:52 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D762BEF@szxeml558-mbx.china.huawei.com> References: 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: multipart/alternative; boundary="_000_46A1DF3F04371240B504290A071B4DB63D762BEFszxeml558mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [core] draft-castellani-core-http-mapping: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 22 May 2013 06:15:12 -0000 --_000_46A1DF3F04371240B504290A071B4DB63D762BEFszxeml558mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 KzENCg0KQmVydA0KDQpGcm9tOiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjb3JlLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSYWhtYW4sIEFrYmFyDQpTZW50OiAyMDEzxOo1 1MIyMcjVIDExOjUxDQpUbzogQW5kcmV3IE1jZ3JlZ29yOyBjb3JlQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW2NvcmVdIGRyYWZ0LWNhc3RlbGxhbmktY29yZS1odHRwLW1hcHBpbmc6IGNhbGwgZm9y IGFkb3B0aW9uDQoNCisxDQoNCkFrYmFyDQoNCkZyb206IGNvcmUtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHJldyBNY2dyZWdv cg0KU2VudDogTW9uZGF5LCBNYXkgMjAsIDIwMTMgODoyNCBQTQ0KVG86IGNvcmVAaWV0Zi5vcmcN ClN1YmplY3Q6IFtjb3JlXSBkcmFmdC1jYXN0ZWxsYW5pLWNvcmUtaHR0cC1tYXBwaW5nOiBjYWxs IGZvciBhZG9wdGlvbg0KDQpDb25zZW5zdXMgb2YgdGhlIHJvb20gaW4gT3JsYW5kbyB3YXMgdG8g YWRvcHQgZHJhZnQtY2FzdGVsbGFuaS1jb3JlLWh0dHAtbWFwcGluZyBhcyBhIHdvcmtpbmcgZ3Jv dXAgZG9jdW1lbnQuICBUaGlzIGVtYWlsIGlzIGEgY2FsbCBmb3IgY29uZmlybWF0aW9uIG9mIHRo YXQgY29uc2Vuc3VzLiAgUGxlYXNlIHJlc3BvbmQgaWYgeW91IHN1cHBvcnQgdGhlIGFkb3B0aW9u IG9mIHRoaXMgZG9jdW1lbnQuDQoNClRoZSBjaGFydGVyIHNheXMgIlRoZSBXRyB3aWxsIGRlZmlu ZSBhIG1hcHBpbmcgZnJvbSBDb0FQIHRvDQphbiBIVFRQIFJFU1QgQVBJOyB0aGlzIG1hcHBpbmcg d2lsbCBub3QgZGVwZW5kIG9uIGEgc3BlY2lmaWMNCmFwcGxpY2F0aW9uLiIgIFdlIGhhdmUgdGhl IG5vcm1hdGl2ZSBwYXJ0cyBjb3ZlcmVkIGluIGNvcmUtY29hcCwgYnV0DQphZGRpdGlvbmFsIGVs dWNpZGF0aW9uIGZvciBpbXBsZW1lbnRlcnMgc2VlbXMgd29ydGh3aGlsZS4NCg0KKiBTZXAgMjAx MyBTdWJtaXNzaW9uIHRvIElFU0cgb2YgIkJlc3QgUHJhY3RpY2VzIGZvciBIVFRQLUNvQVAgTWFw cGluZw0KICBJbXBsZW1lbnRhdGlvbiIgZm9yIEluZm9ybWF0aW9uYWwNCg0KKFdlIGNhbiBkaXNj dXNzIGlmIGEgbm9uLUJDUCBzaG91bGQgaGF2ZSAiQmVzdCBQcmFjdGljZXMiIGluIHRoZQ0KdGl0 bGUsIGJ1dCB0aGUgb2JqZWN0aXZlIGlzIHRvIHByb3ZpZGUgZXhhbXBsZXMgb2YgZ29vZCB1c2Fn ZSBmb3INCmltcGxlbWVudGVycywgbm90IHRvIGdpdmUgc3Ryb25nIHJlY29tbWVuZGF0aW9ucy4p DQoNCi0tDQpBbmRyZXcgTWNHcmVnb3IgfCBTUkUgfCBhbmRyZXdtY2dyQGdvb2dsZS5jb208bWFp bHRvOmFuZHJld21jZ3JAZ29vZ2xlLmNvbT4gfCArNjEgNCA4MTQzIDcxMjgNCg== --_000_46A1DF3F04371240B504290A071B4DB63D762BEFszxeml558mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

+1

 

Bert

 <= /p>

From: core-bou= nces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Rahman, Akbar
Sent: 2013=C4=EA5=D4=C221=C8=D5 11:51
To: Andrew Mcgregor; core@ietf.org
Subject: Re: [core] draft-castellani-core-http-mapping: call for ado= ption

 

+1<= /p>

 <= /p>

Akbar

 <= /p>

From: core-bou= nces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Andrew Mcgregor
Sent: Monday, May 20, 2013 8:24 PM
To: core@ietf.org
Subject: [core] draft-castellani-core-http-mapping: call for adoptio= n

 

Consensus of the room in Orlando was to adopt <= span style=3D"font-size:9.5pt;font-family:"Arial","sans-seri= f"">draft-castellani-core-http-mapping as a working group document. &n= bsp;This email is a call for confirmation of that consensus.  Please respond if you support the adoption of this document.

 

The charter says "The WG will define = a mapping from CoAP to
an HTTP REST API; this mapping will not depend on a specific
application."  We have the normative parts covered in core-coap, = but
additional elucidation for implementers seems worthwhile.

• Sep 2013 Submission to IESG of "Best Practices for HTTP-CoAP M= apping
  Implementation" for Informational

(We can discuss if a non-BCP should have "Best Practices" in the<= br> title, but the objective is to provide examples of good usage for
implementers, not to give strong recommendations.)

 

--

And= rew McGregor |=  SRE |&nb= sp;andrewmcgr@go= ogle.com |=  +61 4 8143 7128

--_000_46A1DF3F04371240B504290A071B4DB63D762BEFszxeml558mbxchi_-- From Bert.Greevenbosch@huawei.com Tue May 21 23:16:50 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D554E21F9354 for ; Tue, 21 May 2013 23:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.121 X-Spam-Level: X-Spam-Status: No, score=-3.121 tagged_above=-999 required=5 tests=[AWL=-0.726, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 8wdkotGj+ilk for ; Tue, 21 May 2013 23:16:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0A78121F8EA6 for ; Tue, 21 May 2013 23:16:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATA44562; Wed, 22 May 2013 06:15:11 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 22 May 2013 07:14:51 +0100 Received: from SZXEML451-HUB.china.huawei.com (10.82.67.194) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 22 May 2013 07:15:00 +0100 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.152]) by szxeml451-hub.china.huawei.com ([10.82.67.194]) with mapi id 14.01.0323.007; Wed, 22 May 2013 14:14:54 +0800 From: Bert Greevenbosch To: "core@ietf.org" Thread-Topic: [core] draft-shelby-core-resource-directory: call for adoption Thread-Index: AQHOVbnWG8UvoXuV20S+MiTF76ZA75kOeumAgAI/1zA= Date: Wed, 22 May 2013 06:14:53 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D762BF6@szxeml558-mbx.china.huawei.com> References: 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: multipart/alternative; boundary="_000_46A1DF3F04371240B504290A071B4DB63D762BF6szxeml558mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [core] draft-shelby-core-resource-directory: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 22 May 2013 06:16:51 -0000 --_000_46A1DF3F04371240B504290A071B4DB63D762BF6szxeml558mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 KzENCg0KQmVydA0KDQpGcm9tOiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjb3JlLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSYWhtYW4sIEFrYmFyDQpTZW50OiAyMDEzxOo1 1MIyMcjVIDExOjUwDQpUbzogQW5kcmV3IE1jZ3JlZ29yOyBjb3JlQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW2NvcmVdIGRyYWZ0LXNoZWxieS1jb3JlLXJlc291cmNlLWRpcmVjdG9yeTogY2FsbCBm b3IgYWRvcHRpb24NCg0KKzENCg0KDQpBa2Jhcg0KDQpGcm9tOiBjb3JlLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmRyZXcgTWNn cmVnb3INClNlbnQ6IE1vbmRheSwgTWF5IDIwLCAyMDEzIDg6MjYgUE0NClRvOiBjb3JlQGlldGYu b3JnDQpTdWJqZWN0OiBbY29yZV0gZHJhZnQtc2hlbGJ5LWNvcmUtcmVzb3VyY2UtZGlyZWN0b3J5 OiBjYWxsIGZvciBhZG9wdGlvbg0KDQpDb25zZW5zdXMgb2YgdGhlIHJvb20gaW4gT3JsYW5kbyB3 YXMgdG8gYWRvcHQgZHJhZnQtc2hlbGJ5LWNvcmUtcmVzb3VyY2UtZGlyZWN0b3J5IGFzIGEgd29y a2luZyBncm91cCBkb2N1bWVudC4gIFRoaXMgZW1haWwgaXMgYSBjYWxsIGZvciBjb25maXJtYXRp b24gb2YgdGhhdCBjb25zZW5zdXMuICBQbGVhc2UgcmVzcG9uZCBpZiB5b3Ugc3VwcG9ydCB0aGUg YWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudC4NCg0KRnJvbSB0aGUgY2hhcnRlcjoNCg0KICAgIDUp IEEgZGVmaW5pdGlvbiBvZiBob3cgdG8gdXNlIENvQVAgdG8gYWR2ZXJ0aXNlIGFib3V0IG9yIHF1 ZXJ5IGZvciBhDQogICAgRGV2aWNlJ3MgZGVzY3JpcHRpb24uIFRoaXMgZGVzY3JpcHRpb24gbWF5 IGluY2x1ZGUgdGhlIGRldmljZSBuYW1lIGFuZA0KICAgIGEgbGlzdCBvZiBpdHMgUmVzb3VyY2Vz LCBlYWNoIHdpdGggYSBVUkwsIGFuIGludGVyZmFjZSBkZXNjcmlwdGlvbiBVUkkNCiAgICAocG9p bnRpbmcgZS5nLiB0byBhIFdlYiBBcHBsaWNhdGlvbiBEZXNjcmlwdGlvbiBMYW5ndWFnZSAoV0FE TCkNCiAgICBkb2N1bWVudCkgYW5kIGFuIG9wdGlvbmFsIG5hbWUgb3IgaWRlbnRpZmllci4gVGhl IG5hbWUgdGF4b25vbXkgdXNlZA0KICAgIGZvciB0aGlzIGRlc2NyaXB0aW9uIHdpbGwgYmUgY29u c2lzdGVudCB3aXRoIG90aGVyIElFVEYgd29yaywNCiAgICBlLmcuIGRyYWZ0LWNoZXNoaXJlLWRu c2V4dC1kbnMtc2QuDQoNClJGQyA2NjkwIGhhcyBzb21lIG9mIHRoaXM7IHRoZSByZXNvdXJjZSBk aXJlY3Rvcnkgd291bGQgYWRkIHByb3RvY29sDQplbGVtZW50cyBvbiB0b3Agb2YgQ29BUCB0aGF0 IGVuaGFuY2UgdGhlICJhZHZlcnRpc2UgYWJvdXQgb3IgcXVlcnkNCmZvciIgYXNwZWN0Lg0KDQoq IEZlYiAyMDE0IFN1Ym1pc3Npb24gdG8gSUVTRyBvZiAiQ29SRSBSZXNvdXJjZSBEaXJlY3Rvcnki IGZvcg0KICBQcm9wb3NlZCBTdGFuZGFyZA0KLS0NCkFuZHJldyBNY0dyZWdvciB8IFNSRSB8IGFu ZHJld21jZ3JAZ29vZ2xlLmNvbTxtYWlsdG86YW5kcmV3bWNnckBnb29nbGUuY29tPiB8ICs2MSA0 IDgxNDMgNzEyOA0K --_000_46A1DF3F04371240B504290A071B4DB63D762BF6szxeml558mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

+1

 

Bert

 <= /p>

From: core-bou= nces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Rahman, Akbar
Sent: 2013=C4=EA5=D4=C221= =C8=D5 11:50
To: Andrew Mcgregor; core@ietf.org
Subject: Re: [core] draft-shelby-core-resource-directory: call for a= doption

 

+1<= /p>

 <= /p>

 <= /p>

Akbar

 <= /p>

From: core-bou= nces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Andrew Mcgregor
Sent: Monday, May 20, 2013 8:26 PM
To: core@ietf.org
Subject: [core] draft-shelby-core-resource-directory: call for adopt= ion

 

Consensus of the room in Orlando was to ad= opt draft-shelby-core-resource-directory as a working group docum= ent.  This email is a call for confirmation of that consensus.  P= lease respond if you support the adoption of this document.


>From the charter:

    5) A definition of how to use CoAP to advertise about or quer= y for a
    Device's description. This description may include the device= name and
    a list of its Resources, each with a URL, an interface descri= ption URI
    (pointing e.g. to a Web Application Description Language (WAD= L)
    document) and an optional name or identifier. The name taxono= my used
    for this description will be consistent with other IETF work,=
    e.g. draft-cheshire-dnsext-dns-sd.

RFC 6690 has some of this; the resource directory would add protocol
elements on top of CoAP that enhance the "advertise about or query
for" aspect.

• Feb 2014 Submission to IESG of "CoRE Resource Directory" = for
  Proposed Standard

--

And= rew McGregor |=  SRE |&nb= sp;andrewmcgr@go= ogle.com |=  +61 4 8143 7128

--_000_46A1DF3F04371240B504290A071B4DB63D762BF6szxeml558mbxchi_-- From cabo@tzi.org Tue May 21 23:16: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 D6CE821F93AB for ; Tue, 21 May 2013 23:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.269 X-Spam-Level: X-Spam-Status: No, score=-106.269 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 dm5Tn9rwKGtc for ; Tue, 21 May 2013 23:16:54 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B3D2821F93A3 for ; Tue, 21 May 2013 23:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r4M6Gnk6017775; Wed, 22 May 2013 08:16:49 +0200 (CEST) Received: from [192.168.217.105] (p54892E88.dip0.t-ipconnect.de [84.137.46.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4D0843313; Wed, 22 May 2013 08:16: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: <066.20d35cb6974c083daf906706e7042b39@trac.tools.ietf.org> Date: Wed, 22 May 2013 08:16:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8ED1AA60-C79B-4E3A-A017-C18957726BE0@tzi.org> References: <051.fb27520c8fa2e3ba5cf748888757b052@trac.tools.ietf.org> <066.20d35cb6974c083daf906706e7042b39@trac.tools.ietf.org> To: hauke@hauke-m.de X-Mailer: Apple Mail (2.1503) Cc: core@ietf.org Subject: Re: [core] #325: Define curve for keys and certs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 22 May 2013 06:17:00 -0000 On May 21, 2013, at 23:33, "core issue tracker" = wrote: > #325: Define curve for keys and certs >=20 >=20 > Comment (by hauke@hauke-m.de): >=20 > The ECC code we implemented is optimized for a specific curve to save > space and improve performance on a constrained device. We currently = only > support the secp256r1 curve and SHA-256, because these are the = mandatory > ones. >=20 > I think most implementations for constrained device will just = implement > one hash algorithm and one curve or make this chooseable at compile = time. I read this as supporting the text proposed in the ticket. > It would be nice to have a default value for the curve and the hash > algorithm in use for a given cipher, so we do not have to support the = TLS > extensions for this. Now this one is interesting. I completely agree with the sentiment. But how would we get those defaults in? The DTLS protocol operates independently from any application semantics, = so simply saying "DTLS for CoAP works that way" is out. Making the curve default to secp256r1 for all of = TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 would run counter to the = curve-independent direction that the draft seems to be taking. (The hash algorithm already should be the default; it seems to me not = being explicit about that is just an oversight in the draft.) How onerous are those TLS extensions? Can you give us an example about = the code and message size? Gr=FC=DFe, Carsten From Bert.Greevenbosch@huawei.com Tue May 21 23:30: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 D719721F920B for ; Tue, 21 May 2013 23:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 OvEJZvp4mDJe for ; Tue, 21 May 2013 23:30:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B40A821F9260 for ; Tue, 21 May 2013 23:30:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARP56705; Wed, 22 May 2013 06:30:35 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 22 May 2013 07:30:25 +0100 Received: from SZXEML455-HUB.china.huawei.com (10.82.67.198) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 22 May 2013 07:30:34 +0100 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.152]) by SZXEML455-HUB.china.huawei.com ([10.82.67.198]) with mapi id 14.01.0323.007; Wed, 22 May 2013 14:28:07 +0800 From: Bert Greevenbosch To: "core@ietf.org" , Carsten Bormann Thread-Topic: [core] draft-bormann-core-links-json: call for adoption Thread-Index: AQHOVbo2DK9z2tUim0ims+KLnpAu2JkOev6AgAI+keA= Date: Wed, 22 May 2013 06:28:06 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D762C0F@szxeml558-mbx.china.huawei.com> References: 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: multipart/alternative; boundary="_000_46A1DF3F04371240B504290A071B4DB63D762C0Fszxeml558mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [core] draft-bormann-core-links-json: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 22 May 2013 06:30:43 -0000 --_000_46A1DF3F04371240B504290A071B4DB63D762C0Fszxeml558mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 KzENCg0KTm90IHN1cmUgaWYgSSBhZ3JlZSB3aXRoIHRoZSBmYWN0IHRoYXQgaXQgaXMgb25seSBz dWl0YWJsZSBvdXRzaWRlIHRoZSBjb25zdHJhaW50IGVudmlyb25tZW50IHRob3VnaDsgdGhlIEpT T04gdmFyaWFudCBzZWVtcyBlYXN5IGVub3VnaCB0byBwYXJzZS4gSG93IHRvIGF2b2lkIElPUCB0 cm91YmxlIGR1ZSB0byB0d28gZW5kcG9pbnRzIHVzaW5nIHRoZSBkaWZmZXJlbnQgZm9ybWF0cz8N Cg0KU29tZSB0aGluZ3MgZm9yIGNvbnNpZGVyYXRpb246DQotIENoYW5nZSAiLndlbGwta25vd24v Y29yZSIgdG8gIi53ZWxsLWtub3duL2psaW5rIiBvciBzb21ldGhpbmc/DQotIFJlZ2lzdGVyIG5l dyBtaW1lIHR5cGU/DQotIERvZXMgdGhpcyBhbGxvdyBtdWx0aXZhbHVlIGF0dHJpYnV0ZXMsIGUu Zy4gdGhyb3VnaCBhcnJheXM/IERlZmluaXRlbHkgcG9zc2libGUgaW4gSlNPTiwgYnV0IGl0IHdv dWxkIGJyZWFrIGVhc3kgY29udmVyc2lvbiB0byB0aGUgY29udmVudGlvbmFsIGxpbmsgZm9ybWF0 Lg0KLSBJbiBKQ0FSRCwgd2Ugc3RhcnRlZCB3aXRoIGEgc2ltaWxhciBjb25zdHJ1Y3Rpb24uIEhv d2V2ZXIgd2UgbGF0ZXIgY2hhbmdlZCB0byBhIGNvbnN0cnVjdGlvbiBvZiB7Im5hbWUiLCAicGFy YW1ldGVyIiwgInR5cGUiLCAidmFsdWUifSB0byBhbGxvdyBtb3JlIGZsZXhpYmlsaXR5IGFuZCBz aWduYWxsaW5nLCBlc3BlY2lhbGx5IGNvbmNlcm5pbmcgdGhlIHR5cGUgKGUuZy4gc3RyaW5nIG9y IGludGVnZXIpIG9mIHRoZSB2YWx1ZS4NCg0KQmVydA0KDQoNCkZyb206IGNvcmUtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJhaG1h biwgQWtiYXINClNlbnQ6IDIwMTPE6jXUwjIxyNUgMTE6NTANClRvOiBBbmRyZXcgTWNncmVnb3I7 IGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbY29yZV0gZHJhZnQtYm9ybWFubi1jb3JlLWxp bmtzLWpzb246IGNhbGwgZm9yIGFkb3B0aW9uDQoNCisxDQoNCkFrYmFyDQoNCkZyb206IGNvcmUt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEFuZHJldyBNY2dyZWdvcg0KU2VudDogTW9uZGF5LCBNYXkgMjAsIDIwMTMgODoyOCBQTQ0K VG86IGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFtjb3JlXSBkcmFmdC1ib3JtYW5uLWNvcmUtbGlu a3MtanNvbjogY2FsbCBmb3IgYWRvcHRpb24NCg0KQ29uc2Vuc3VzIG9mIHRoZSByb29tIGluIE9y bGFuZG8gd2FzIHRvIGFkb3B0IGRyYWZ0LWJvcm1hbm4tY29yZS1saW5rcy1qc29uIGFzIGEgd29y a2luZyBncm91cCBkb2N1bWVudC4gIFRoaXMgZW1haWwgaXMgYSBjYWxsIGZvciBjb25maXJtYXRp b24gb2YgdGhhdCBjb25zZW5zdXMuICBQbGVhc2UgcmVzcG9uZCBpZiB5b3Ugc3VwcG9ydCB0aGUg YWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudC4NCg0KRnJvbSB0aGUgY2hhcnRlcjoNCg0KICAgIDUp IEEgZGVmaW5pdGlvbiBvZiBob3cgdG8gdXNlIENvQVAgdG8gYWR2ZXJ0aXNlIGFib3V0IG9yIHF1 ZXJ5IGZvciBhDQogICAgRGV2aWNlJ3MgZGVzY3JpcHRpb24uIFRoaXMgZGVzY3JpcHRpb24gbWF5 IGluY2x1ZGUgdGhlIGRldmljZSBuYW1lIGFuZA0KICAgIGEgbGlzdCBvZiBpdHMgUmVzb3VyY2Vz LCBlYWNoIHdpdGggYSBVUkwsIGFuIGludGVyZmFjZSBkZXNjcmlwdGlvbiBVUkkNCiAgICAocG9p bnRpbmcgZS5nLiB0byBhIFdlYiBBcHBsaWNhdGlvbiBEZXNjcmlwdGlvbiBMYW5ndWFnZSAoV0FE TCkNCiAgICBkb2N1bWVudCkgYW5kIGFuIG9wdGlvbmFsIG5hbWUgb3IgaWRlbnRpZmllci4gVGhl IG5hbWUgdGF4b25vbXkgdXNlZA0KICAgIGZvciB0aGlzIGRlc2NyaXB0aW9uIHdpbGwgYmUgY29u c2lzdGVudCB3aXRoIG90aGVyIElFVEYgd29yaywNCiAgICBlLmcuIGRyYWZ0LWNoZXNoaXJlLWRu c2V4dC1kbnMtc2QuDQoNClRoaXMgaXMgZm9yIG1ha2luZyB0aGUgcmVzb3VyY2UgZGlzY292ZXJ5 IGluZm9ybWF0aW9uIGF2YWlsYWJsZSB0byBiYWNrZW5kcy4gIE9uIGEgdGVjaG5pY2FsIGxldmVs LCB0aGlzIGlzIGEgbm8tYnJhaW5lci4NCg0KKiBNYXkgMjAxMyBTdWJtaXNzaW9uIHRvIElFU0cg b2YgIlJlcHJlc2VudGluZyBDb1JFIExpbmsgQ29sbGVjdGlvbnMNCiAgaW4gSlNPTiIgZm9yIFBy b3Bvc2VkIFN0YW5kYXJkDQoNCi0tDQpBbmRyZXcgTWNHcmVnb3IgfCBTUkUgfCBhbmRyZXdtY2dy QGdvb2dsZS5jb208bWFpbHRvOmFuZHJld21jZ3JAZ29vZ2xlLmNvbT4gfCArNjEgNCA4MTQzIDcx MjgNCg== --_000_46A1DF3F04371240B504290A071B4DB63D762C0Fszxeml558mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

+1

 

Not sure if I agree with the fact that = it is only suitable outside the constraint environment though; the JSON var= iant seems easy enough to parse. How to avoid IOP trouble due to two endpoints using the different formats?

 

Some things for consideration:

- Change ".well-known/core" t= o ".well-known/jlink" or something?

- Register new mime type?

- Does this allow multivalue attributes= , e.g. through arrays? Definitely possible in JSON, but it would break easy= conversion to the conventional link format.

- In JCARD, we started with a similar c= onstruction. However we later changed to a construction of {"name"= ;, "parameter", "type", "value"} to allow mor= e flexibility and signalling, especially concerning the type (e.g. string or integer) of the value.=

 

Bert

 

 <= /p>

From: core-bou= nces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Rahman, Akbar
Sent: 2013=C4=EA5=D4=C221=C8=D5 11:50
To: Andrew Mcgregor; core@ietf.org
Subject: Re: [core] draft-bormann-core-links-json: call for adoption=

 

+1<= /p>

 <= /p>

Akbar

 <= /p>

From: core-bou= nces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Andrew Mcgregor
Sent: Monday, May 20, 2013 8:28 PM
To: core@ietf.org
Subject: [core] draft-bormann-core-links-json: call for adoption

 

Consensus of the room in Orlando was to ad= opt draft-bormann-core-links-json as a working group document. &n= bsp;This email is a call for confirmation of that consensus.  Please r= espond if you support the adoption of this document.

 

From the charter:

    5) A definition of how to use CoAP to advertise about or quer= y for a
    Device's description. This description may include the device= name and
    a list of its Resources, each with a URL, an interface descri= ption URI
    (pointing e.g. to a Web Application Description Language (WAD= L)
    document) and an optional name or identifier. The name taxono= my used
    for this description will be consistent with other IETF work,=
    e.g. draft-cheshire-dnsext-dns-sd.

This is for making the resource discovery information available to bac= kends.  On a technical level, this is a no-brainer.

• May 2013 Submission to IESG of "Representing CoRE Link Collect= ions
  in JSON" for Proposed Standard

 

--

And= rew McGregor |=  SRE |&nb= sp;andrewmcgr@go= ogle.com |=  +61 4 8143 7128

--_000_46A1DF3F04371240B504290A071B4DB63D762C0Fszxeml558mbxchi_-- From cabo@tzi.org Wed May 22 00:13: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 B938421F9339 for ; Wed, 22 May 2013 00:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.042 X-Spam-Level: X-Spam-Status: No, score=-105.042 tagged_above=-999 required=5 tests=[AWL=-1.243, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWJg6nxb9bPq for ; Wed, 22 May 2013 00:13: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 978FC21F9232 for ; Wed, 22 May 2013 00:13: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 r4M7DM2a027734; Wed, 22 May 2013 09:13:22 +0200 (CEST) Received: from [192.168.217.105] (p54892E88.dip0.t-ipconnect.de [84.137.46.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 43DF2335F; Wed, 22 May 2013 09:13:22 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=gb18030 From: Carsten Bormann In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D762C0F@szxeml558-mbx.china.huawei.com> Date: Wed, 22 May 2013 09:13:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <46A1DF3F04371240B504290A071B4DB63D762C0F@szxeml558-mbx.china.huawei.com> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1503) Cc: "core@ietf.org" Subject: Re: [core] draft-bormann-core-links-json: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 22 May 2013 07:13:43 -0000 On May 22, 2013, at 08:28, Bert Greevenbosch = wrote: > +1 > =20 > Not sure if I agree with the fact that it is only suitable outside the = constraint environment though; the JSON variant seems easy enough to = parse. How to avoid IOP trouble due to two endpoints using the different = formats? I'd say: stick with RFC 6690 in the constrained environment... > Some things for consideration: > - Change ".well-known/core" to ".well-known/jlink" or something? Again, I don't argue for moving over the constrained nodes to JSON = links. > - Register new mime type? Yep: application/link-format+json (Section 3; the IANA boilerplate has to filled in, next). > - Does this allow multivalue attributes, e.g. through arrays? = Definitely possible in JSON, but it would break easy conversion to the = conventional link format. Yes, it does (and no, it wouldn't break link-format or RFC 5988): If a Link attribute ("parmname") is present more than once in a "link-value", its values are then represented as a JSON array of JSON string values; this array becomes the value of the JSON name/value pair where the attribute name is the JSON name.=20 (Section 2). > - In JCARD, we started with a similar construction. However we later = changed to a construction of {"name", "parameter", "type", "value"} to = allow more flexibility and signalling, especially concerning the type = (e.g. string or integer) of the value. I think the jcardcal format is constrained by the need to do = round-tripping into the legacy format, so you want to make the type = information explicit. I'm not sure we have the same considerations here. (Also, since link-format attributes are RFC 5988 attributes and thus = always string values, we follow this by even handling "ct" as a string: [{"href":"/sensors","ct":"40","title":"Sensor Index"},{"href":"/ sensors/temp","rt":"temperature-c","if":"sensor"},{"href":"/sensors/ light","rt":"light-lux","if":"sensor"},{"href":"http:// www.example.com/sensors/t123","anchor":"/sensors/ temp","rel":"describedby"},{"href":"/t","anchor":"/sensors/ temp","rel":"alternate"}] ) Gr=A8=B9=810=898e, Carsten From kovatsch@inf.ethz.ch Wed May 22 02:33:10 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E34C21F9647 for ; Wed, 22 May 2013 02:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1AKu0lm4YWq for ; Wed, 22 May 2013 02:33:04 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id 369AB21F9645 for ; Wed, 22 May 2013 02:33:02 -0700 (PDT) Received: from CAS12.d.ethz.ch (172.31.38.212) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 22 May 2013 11:32:51 +0200 Received: from MBX20.d.ethz.ch ([fe80::81a7:b7a5:50c0:df0d]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%10]) with mapi id 14.02.0298.004; Wed, 22 May 2013 11:32:57 +0200 From: "Kovatsch Matthias" To: Andrew Mcgregor , "core@ietf.org" Thread-Topic: [core] draft-shelby-core-resource-directory: call for adoption Thread-Index: AQHOVbnW7g5X6ePI8UGwO7/7EdLXr5kQ8yYw Date: Wed, 22 May 2013 09:32:55 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514EE7436@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: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B514EE7436MBX20dethzch_" MIME-Version: 1.0 Subject: Re: [core] draft-shelby-core-resource-directory: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 22 May 2013 09:33:10 -0000 --_000_55877B3AFB359744BA0F2140E36F52B514EE7436MBX20dethzch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Matthias From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of And= rew Mcgregor Sent: Tuesday, May 21, 2013 2:26 To: core@ietf.org Subject: [core] draft-shelby-core-resource-directory: call for adoption Consensus of the room in Orlando was to adopt draft-shelby-core-resource-di= rectory as a working group document. This email is a call for confirmation= of that consensus. Please respond if you support the adoption of this doc= ument. >From the charter: 5) A definition of how to use CoAP to advertise about or query for a Device's description. This description may include the device name and a list of its Resources, each with a URL, an interface description URI (pointing e.g. to a Web Application Description Language (WADL) document) and an optional name or identifier. The name taxonomy used for this description will be consistent with other IETF work, e.g. draft-cheshire-dnsext-dns-sd. RFC 6690 has some of this; the resource directory would add protocol elements on top of CoAP that enhance the "advertise about or query for" aspect. * Feb 2014 Submission to IESG of "CoRE Resource Directory" for Proposed Standard -- Andrew McGregor | SRE | andrewmcgr@google.com= | +61 4 8143 7128 --_000_55877B3AFB359744BA0F2140E36F52B514EE7436MBX20dethzch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

Matthias

 <= /p>

 <= /p>

From: core-bou= nces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Andrew Mcgregor
Sent: Tuesday, May 21, 2013 2:26
To: core@ietf.org
Subject: [core] draft-shelby-core-resource-directory: call for adopt= ion

 

Consensus of the room in Orlando was to ad= opt draft-shelby-core-resource-directory as a working group docum= ent.  This email is a call for confirmation of that consensus.  P= lease respond if you support the adoption of this document.


>From the charter:

    5) A definition of how to use CoAP to advertise about or quer= y for a
    Device's description. This description may include the device= name and
    a list of its Resources, each with a URL, an interface descri= ption URI
    (pointing e.g. to a Web Application Description Language (WAD= L)
    document) and an optional name or identifier. The name taxono= my used
    for this description will be consistent with other IETF work,=
    e.g. draft-cheshire-dnsext-dns-sd.

RFC 6690 has some of this; the resource directory would add protocol
elements on top of CoAP that enhance the "advertise about or query
for" aspect.

• Feb 2014 Submission to IESG of "CoRE Resource Directory" = for
  Proposed Standard

--

And= rew McGregor |=  SRE |&nb= sp;andrewmcgr@go= ogle.com |=  +61 4 8143 7128

--_000_55877B3AFB359744BA0F2140E36F52B514EE7436MBX20dethzch_-- From trac+core@trac.tools.ietf.org Wed May 22 02:45:19 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483EF21F9635 for ; Wed, 22 May 2013 02:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 JrUsIfmZyr7u for ; Wed, 22 May 2013 02:45:18 -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 58EA121F881C for ; Wed, 22 May 2013 02:45:01 -0700 (PDT) Received: from localhost ([127.0.0.1]:42248 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Uf5bM-000586-Vr; Wed, 22 May 2013 11:44: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, zach@sensinode.com, hauke@hauke-m.de, kovatsch@inf.ethz.ch X-Trac-Project: core Date: Wed, 22 May 2013 09:44:56 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/325#comment:4 Message-ID: <066.a994341d99d0ac1576116eeeaf6f28d8@trac.tools.ietf.org> References: <051.fb27520c8fa2e3ba5cf748888757b052@trac.tools.ietf.org> X-Trac-Ticket-ID: 325 In-Reply-To: <051.fb27520c8fa2e3ba5cf748888757b052@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, zach@sensinode.com, hauke@hauke-m.de, kovatsch@inf.ethz.ch, 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: <20130522094502.58EA121F881C@ietfa.amsl.com> Resent-Date: Wed, 22 May 2013 02:45:01 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #325: Define curve for keys and certs 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, 22 May 2013 09:45:19 -0000 #325: Define curve for keys and certs Comment (by kovatsch@inf.ethz.ch): We definitely need text on which hash function to use, as this is not clear at the moment. Defining a MUST for SHA-256 looks good to me. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: other | Status: new technical | Milestone: post-IESG-1 Priority: major | Version: coap-16 Component: coap | Resolution: Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From kovatsch@inf.ethz.ch Wed May 22 03:05: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 84FE721F9607 for ; Wed, 22 May 2013 03:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrZZqLYjzfER for ; Wed, 22 May 2013 03:05:43 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id D608821F93B1 for ; Wed, 22 May 2013 03:05:42 -0700 (PDT) Received: from CAS21.d.ethz.ch (172.31.51.111) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 22 May 2013 12:05:35 +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; Wed, 22 May 2013 12:05:41 +0200 From: "Kovatsch Matthias" To: Andrew Mcgregor , "core@ietf.org" Thread-Topic: [core] draft-bormann-core-links-json: call for adoption Thread-Index: AQHOVbotWGQjJnIEwEGIonasgHGRWpkQ+bvQ Date: Wed, 22 May 2013 10:05:41 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514EE74B0@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: multipart/alternative; boundary="_000_55877B3AFB359744BA0F2140E36F52B514EE74B0MBX20dethzch_" MIME-Version: 1.0 Subject: Re: [core] draft-bormann-core-links-json: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 22 May 2013 10:05:49 -0000 --_000_55877B3AFB359744BA0F2140E36F52B514EE74B0MBX20dethzch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 I think this is useful for building larger "Cloud services" around constrai= ned devices and M2M applications. I do not see a direct connection to core-= interfaces, though. In Orlando Carsten recalled the original incentive for writing up this form= at. Unfortunately, the minutes etherpad keeps resetting my connection attem= pts and I cannot recall the outcome. Anyone can? :) Ciao Matthias From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of And= rew Mcgregor Sent: Tuesday, May 21, 2013 2:28 To: core@ietf.org Subject: [core] draft-bormann-core-links-json: call for adoption Consensus of the room in Orlando was to adopt draft-bormann-core-links-json= as a working group document. This email is a call for confirmation of tha= t consensus. Please respond if you support the adoption of this document. >From the charter: 5) A definition of how to use CoAP to advertise about or query for a Device's description. This description may include the device name and a list of its Resources, each with a URL, an interface description URI (pointing e.g. to a Web Application Description Language (WADL) document) and an optional name or identifier. The name taxonomy used for this description will be consistent with other IETF work, e.g. draft-cheshire-dnsext-dns-sd. This is for making the resource discovery information available to backends= . On a technical level, this is a no-brainer. * May 2013 Submission to IESG of "Representing CoRE Link Collections in JSON" for Proposed Standard -- Andrew McGregor | SRE | andrewmcgr@google.com= | +61 4 8143 7128 --_000_55877B3AFB359744BA0F2140E36F52B514EE74B0MBX20dethzch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

I think this is useful fo= r building larger “Cloud services” around constrained devices a= nd M2M applications. I do not see a direct connection to core-interfaces, though.

 <= /p>

In Orlando Carsten recall= ed the original incentive for writing up this format. Unfortunately, the mi= nutes etherpad keeps resetting my connection attempts and I cannot recall the outcome. Anyone can? :)

 <= /p>

Ciao

Matthias

 <= /p>

 <= /p>

From: core-bou= nces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Andrew Mcgregor
Sent: Tuesday, May 21, 2013 2:28
To: core@ietf.org
Subject: [core] draft-bormann-core-links-json: call for adoption

 

Consensus of the room in Orlando was to ad= opt draft-bormann-core-links-json as a working group document. &n= bsp;This email is a call for confirmation of that consensus.  Please r= espond if you support the adoption of this document.

 

From the charter:

    5) A definition of how to use CoAP to advertise about or quer= y for a
    Device's description. This description may include the device= name and
    a list of its Resources, each with a URL, an interface descri= ption URI
    (pointing e.g. to a Web Application Description Language (WAD= L)
    document) and an optional name or identifier. The name taxono= my used
    for this description will be consistent with other IETF work,=
    e.g. draft-cheshire-dnsext-dns-sd.

This is for making the resource discovery information available to bac= kends.  On a technical level, this is a no-brainer.

• May 2013 Submission to IESG of "Representing CoRE Link Collect= ions
  in JSON" for Proposed Standard

 

--

And= rew McGregor |=  SRE |&nb= sp;andrewmcgr@go= ogle.com |=  +61 4 8143 7128

--_000_55877B3AFB359744BA0F2140E36F52B514EE74B0MBX20dethzch_-- From cabo@tzi.org Wed May 22 03:37: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 726DD21F8EEC for ; Wed, 22 May 2013 03:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.184 X-Spam-Level: X-Spam-Status: No, score=-106.184 tagged_above=-999 required=5 tests=[AWL=0.065, 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 3NYAEGNZBAib for ; Wed, 22 May 2013 03:37:10 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5089521F8EBB for ; Wed, 22 May 2013 03:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r4MAb3Fv003186; Wed, 22 May 2013 12:37:03 +0200 (CEST) Received: from [192.168.217.105] (p54892E88.dip0.t-ipconnect.de [84.137.46.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A884A35AE; Wed, 22 May 2013 12:37:02 +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: <55877B3AFB359744BA0F2140E36F52B514EE74B0@MBX20.d.ethz.ch> Date: Wed, 22 May 2013 12:37:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <69A59031-FB53-42EC-A61D-FBBFCF189E39@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514EE74B0@MBX20.d.ethz.ch> To: "Kovatsch Matthias" X-Mailer: Apple Mail (2.1503) Cc: "core@ietf.org" Subject: Re: [core] draft-bormann-core-links-json: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 22 May 2013 10:37:15 -0000 On May 22, 2013, at 12:05, "Kovatsch Matthias" = wrote: > In Orlando Carsten recalled the original incentive for writing up this = format. Unfortunately, the minutes etherpad keeps resetting my = connection attempts and I cannot recall the outcome. Anyone can? :) The minutes are at: http://www.ietf.org/proceedings/86/minutes/minutes-86-core Specifically: > draft-bormann-core-links-json [65:00, 123] >=20 > Objective: > - Gauge interest by WG >=20 > Carsten quickly recaps the reasons for = draft-bormann-core-links-json-02. > - Kerry: relation to current RFC4627bis work? > Carsten doesn't think there is a relation. This uses JSON as is. > (We are assuming that there is never semantic information on the > sequence of link-format attributes.) > - Zach: thinks this should be standardized, maybe not necessarily in = CoRE. > - Carsten: calls for consensus. 5 have read a version of it. 5 think > IETF should do it. 3 think document is a good start for this. 3 > willing to review. > - Matthias: not sure whether CoRE is the place to work on this in > IETF. Well, maybe the audio is more useful... = (http://www.ietf.org/audio/ietf86/ietf86-caribbean6-20130312-1300-pm1.mp3,= if you actually look into it, start at 65:00). Gr=FC=DFe, Carsten From cabo@tzi.org Wed May 22 03:57: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 2896121F9626 for ; Wed, 22 May 2013 03:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.188 X-Spam-Level: X-Spam-Status: No, score=-106.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwg1VwcqLZzl for ; Wed, 22 May 2013 03:57: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 1290921F9609 for ; Wed, 22 May 2013 03:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r4MAvjZ1010691; Wed, 22 May 2013 12:57:45 +0200 (CEST) Received: from [192.168.217.105] (p54892E88.dip0.t-ipconnect.de [84.137.46.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C15A435E1; Wed, 22 May 2013 12:57:44 +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: <69A59031-FB53-42EC-A61D-FBBFCF189E39@tzi.org> Date: Wed, 22 May 2013 12:57:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4E4A7BCC-A658-4E1E-8DC8-C88D82737E8E@tzi.org> References: <55877B3AFB359744BA0F2140E36F52B514EE74B0@MBX20.d.ethz.ch> <69A59031-FB53-42EC-A61D-FBBFCF189E39@tzi.org> To: "Kovatsch Matthias" X-Mailer: Apple Mail (2.1503) Cc: "core@ietf.org" Subject: Re: [core] draft-bormann-core-links-json: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 22 May 2013 10:57:55 -0000 On May 22, 2013, at 12:37, Carsten Bormann wrote: > Well, maybe the audio is more useful... = (http://www.ietf.org/audio/ietf86/ietf86-caribbean6-20130312-1300-pm1.mp3,= if you actually look into it, start at 65:00). Oops, the file name in the minutes was wrong (fixed); make that = ietf86-caribbean5-20130313-1300-pm1.mp3 What I said: -- It is sad that we have different serializations for things -- On the backend, web-app, services side, it is quite usual these days = to find information in JSON format -- It is useful to have a single [i.e., standard] way to express = link-format information in JSON -- As a side-effect, we create good precedent for application developers = to represent link-format information in the same way in different = applications. We make it simpler for application developers to think about = link-format because they know how it looks like in JSON. But that is a = side effect. Switching to the how from the why: -- That is not rocket science -- [showing slide] this is essentially the = technical content of the draft. -- The main decision is what name are we using for the Path component of = the link. -- We settled on href because this is already taken so there can't be a = conflict. -- One little detail: Content-Format (ct) looks like a number in = link-format, but looks like a string in the JSON. We don't have a distinction between number and string in the = link-format... so we are treating everything as a string. Gr=FC=DFe, Carsten From kovatsch@inf.ethz.ch Wed May 22 04:50:27 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0BA621F9607 for ; Wed, 22 May 2013 04:50: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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpUjL5NQ3u3h for ; Wed, 22 May 2013 04:50:21 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id BC74D21F95E7 for ; Wed, 22 May 2013 04:50:19 -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; Wed, 22 May 2013 13:50:06 +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; Wed, 22 May 2013 13:50:12 +0200 From: "Kovatsch Matthias" To: Carsten Bormann Thread-Topic: [core] draft-bormann-core-links-json: call for adoption Thread-Index: AQHOVbotWGQjJnIEwEGIonasgHGRWpkQ+bvQ///p34CAAAXHAIAALlOQ Date: Wed, 22 May 2013 11:50:11 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514EE765F@MBX20.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B514EE74B0@MBX20.d.ethz.ch> <69A59031-FB53-42EC-A61D-FBBFCF189E39@tzi.org> <4E4A7BCC-A658-4E1E-8DC8-C88D82737E8E@tzi.org> In-Reply-To: <4E4A7BCC-A658-4E1E-8DC8-C88D82737E8E@tzi.org> 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 Cc: "core@ietf.org" Subject: Re: [core] draft-bormann-core-links-json: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 22 May 2013 11:50:27 -0000 Thank you very much for digging that up! > What I said: > -- It is sad that we have different serializations for things > -- On the backend, web-app, services side, it is quite usual these days t= o find > information in JSON format > -- It is useful to have a single [i.e., standard] way to express link-for= mat > information in JSON > -- As a side-effect, we create good precedent for application developers = to > represent link-format information in the same way in different applicatio= ns. > We make it simpler for application developers to think about link-form= at > because they know how it looks like in JSON. But that is a side effect. Yes, that perfectly matches the experience we are currently making in a "Cl= oud + Internet of Things" project. There is some appeal to make this format= more general, but pushing it forward within CoRE sounds good (as it is pre= tty simple there). Ciao Matthias From kovatsch@inf.ethz.ch Wed May 22 06:44: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 44E0221F85C0 for ; Wed, 22 May 2013 06:44:30 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvWNvCG80tsR for ; Wed, 22 May 2013 06:44:26 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) by ietfa.amsl.com (Postfix) with ESMTP id AE54021F90DF for ; Wed, 22 May 2013 06:44:25 -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; Wed, 22 May 2013 15:44:09 +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; Wed, 22 May 2013 15:44:16 +0200 From: "Kovatsch Matthias" To: Zach Shelby , "core@ietf.org WG" Thread-Topic: [core] Fwd: New Version Notification for draft-shelby-core-resource-directory-05.txt Thread-Index: AQHOE6XNkp3KdorFAESwYk0teFZTYZkRoC1A Date: Wed, 22 May 2013 13:44:15 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514EE7819@MBX20.d.ethz.ch> References: <20130225221311.17677.1216.idtracker@ietfa.amsl.com> <4E6A77E7-7F78-41B5-BE13-A261D6EA836C@sensinode.com> In-Reply-To: <4E6A77E7-7F78-41B5-BE13-A261D6EA836C@sensinode.com> 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] Fwd: New Version Notification for draft-shelby-core-resource-directory-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 13:44:30 -0000 Dear Zach, dear list I was looking at the draft to clean up the experimental implementation incl= uded in Californium. Thereby I stumbled over the following things: 4. Simple Directory Discovery: I think it should be clearer that POSTed links do not end up in the RD's /.= well-known/core resource as absolute URIs. Giving a Location in the 2.01 Cr= eated response should fix that. Some reference to the lifetime of the RD en= try and the possibility of periodic validation might be useful here. 5.1. Discovery: The IP part overlaps with "4.1. Finding a Directory Server." Maybe this can= be separated into a common section before the simple and function set RD. "discovering the RD using the CoRE Link Format (also see Section 4.1)" is a= lso a bit confusing. I guess this is referring to multicast discovery, so t= his should be mentioned directly (possibly in this new section mentioned ab= ove). 5. Resource Directory Function Set: I was wondering what should happen when someone performs a GET on the EP lo= cation, e.g., GET /rd/4521. Can we provide something useful there? Otherwise the document should hint t= hat GET should be disallowed in this context. 7. RD Lookup Function Set: The link in the responses to the domain lookup feels odd. Or maybe it= is artificially pressing the domain list into the Link Format... I would at least expect links to the rd-lookup where the domain information= can be used (analogous to a ct attribute where the requester can also pick= from a list): ;d=3D"domain1 domain2" Should "d" and the other attributes (ep, gp) be proper link-extensions? I g= uess we have to, if we want application/link-format to define the RESTful i= nteraction including the filtering with attributes. How does "gp" relate to draft-ietf-core-groupcomm? 9. Security Considerations: A forward reference or the mentioning of access control should already be p= rovided in the function set definitions. These random numbers under /rd/ lu= red me into thinking of them as access tokens. But they are quite bad for t= his purpose... General: The sub-resources of rd-lookup defined by a URI Template somehow conflict w= ith my current understanding of REST. (Sorry for bringing up this topic aga= in...) ./res, ./ep, and ./d are never linked from anywhere and cannot be discovere= d. So it is a classic service coupling. Should we just live with that or ca= n we fix this somehow, e.g., with separate rt attributes and entries in /.w= ell-known/core? Otherwise the RD is quite nicely built around the CoRE Link Format media ty= pe. Ciao Matthias > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > Zach Shelby > Sent: Monday, February 25, 2013 23:17 > To: core@ietf.org WG > Subject: [core] Fwd: New Version Notification for draft-shelby-core- > resource-directory-05.txt >=20 > I have posted a new version of the RD draft, now including group support, > alignment with the OMA Lightweight M2M standards work and improved > interfaces. Thanks to Esko and Peter for help with the group support. >=20 > Regards, > Zach >=20 > Begin forwarded message: >=20 > > From: internet-drafts@ietf.org > > Subject: New Version Notification for > > draft-shelby-core-resource-directory-05.txt > > Date: February 25, 2013 11:13:11 PM GMT+01:00 > > To: zach@sensinode.com > > Cc: srdjan.krco@ericsson.com, cabo@tzi.org > > > > > > A new version of I-D, draft-shelby-core-resource-directory-05.txt > > has been successfully submitted by Zach Shelby and posted to the IETF > > repository. > > > > Filename: draft-shelby-core-resource-directory > > Revision: 05 > > Title: CoRE Resource Directory > > Creation date: 2013-02-25 > > Group: Individual Submission > > Number of pages: 27 > > URL: http://www.ietf.org/internet-drafts/draft-shelby-core- > resource-directory-05.txt > > Status: http://datatracker.ietf.org/doc/draft-shelby-core-reso= urce- > directory > > Htmlized: http://tools.ietf.org/html/draft-shelby-core-resource- > directory-05 > > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-shelby-core-r= esource- > directory-05 > > > > Abstract: > > In many M2M applications, direct discovery of resources is not > > practical due to sleeping nodes, disperse networks, or networks where > > multicast traffic is inefficient. These problems can be solved by > > employing an entity called a Resource Directory (RD), which hosts > > descriptions of resources held on other servers, allowing lookups to > > be performed for those resources. This document specifies the web > > interfaces that a Resource Directory supports in order for web > > servers to discover the RD and to register, maintain, lookup and > > remove resources descriptions. Furthermore, new link attributes > > useful in conjunction with an RD are defined. > > > > > > > > > > The IETF Secretariat > > >=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 >=20 >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Wed May 22 12:35: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 23E4B21F96AD; Wed, 22 May 2013 12:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.207 X-Spam-Level: X-Spam-Status: No, score=-106.207 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kS9hrJurIH2Z; Wed, 22 May 2013 12:35:54 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1845821F96AB; Wed, 22 May 2013 12:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r4MJZhAb014085; Wed, 22 May 2013 21:35:43 +0200 (CEST) Received: from [192.168.217.105] (p54891D40.dip0.t-ipconnect.de [84.137.29.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 46B9E3988; Wed, 22 May 2013 21:35: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: Wed, 22 May 2013 21:35:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <94615427-3EA3-4487-8057-FECB2841291E@tzi.org> References: <20130522162039.28519.8235.idtracker@ietfa.amsl.com> To: "core@ietf.org (core@ietf.org)" , " WG" X-Mailer: Apple Mail (2.1503) Subject: [core] Fwd: Last Call: (Terminology for Constrained Node Networks) to Informational RFC X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 22 May 2013 19:35:59 -0000 This draft is intended to be useful for the entire constrained = node/network cluster. The present IETF last-call has already been forwarded to 6lowpan and = coman, so I'm forwarding it to core and roll. Gr=FC=DFe, Carsten Begin forwarded message: > From: The IESG > Subject: Last Call: (Terminology = for Constrained Node Networks) to Informational RFC > Date: May 22, 2013 18:20:39 +0200 > To: IETF-Announce > Cc: lwip@ietf.org > Reply-To: ietf@ietf.org >=20 >=20 > The IESG has received a request from the Light-Weight Implementation > Guidance WG (lwig) to consider the following document: > - 'Terminology for Constrained Node Networks' > as Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-06-05. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > The Internet Protocol Suite is increasingly used on small devices > with severe constraints, creating constrained node networks. This > document provides a number of basic terms that have turned out to be > useful in the standardization work for constrained environments. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-lwig-terminology/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-lwig-terminology/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 >=20 From trac+core@trac.tools.ietf.org Wed May 22 14: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 2C02B11E811B for ; Wed, 22 May 2013 14:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgDts78uNSHa for ; Wed, 22 May 2013 14: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 50CB011E8110 for ; Wed, 22 May 2013 14:22:35 -0700 (PDT) Received: from localhost ([127.0.0.1]:35437 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UfGUU-0000UE-BL; Wed, 22 May 2013 23: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: Wed, 22 May 2013 21:22:34 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/322#comment:1 Message-ID: <066.d4184e6246540c315a5be85435742ad1@trac.tools.ietf.org> References: <051.acab664a5a1d198d8eb1b3af78e562ea@trac.tools.ietf.org> X-Trac-Ticket-ID: 322 In-Reply-To: <051.acab664a5a1d198d8eb1b3af78e562ea@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: <20130522212236.50CB011E8110@ietfa.amsl.com> Resent-Date: Wed, 22 May 2013 14:22:35 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #322: Clarify that security SHOULD be used for issuing secure requests to a proxy 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, 22 May 2013 21:22:37 -0000 #322: Clarify that security SHOULD be used for issuing secure requests to a proxy Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1389]: Fix #322 -- -------------------------+------------------------------------------------- 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-16 Component: coap | Resolution: fixed Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From hauke@hauke-m.de Thu May 23 03:33: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 A71E911E8190 for ; Thu, 23 May 2013 03:33:42 -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 gqN81WegWlN2 for ; Thu, 23 May 2013 03:33:42 -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 0803311E8132 for ; Thu, 23 May 2013 03:33:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hauke-m.de (Postfix) with ESMTP id 4914F8F61; Thu, 23 May 2013 12:33:40 +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 uA5TeVzYpBZ8; Thu, 23 May 2013 12:33:35 +0200 (CEST) Received: from [134.102.113.159] (eduroam-pool7-0415.wlan.uni-bremen.de [134.102.113.159]) by hauke-m.de (Postfix) with ESMTPSA id C66A4857F; Thu, 23 May 2013 12:33:34 +0200 (CEST) Message-ID: <519DF07C.2000808@hauke-m.de> Date: Thu, 23 May 2013 12:33:32 +0200 From: Hauke Mehrtens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Carsten Bormann References: <051.fb27520c8fa2e3ba5cf748888757b052@trac.tools.ietf.org> <066.20d35cb6974c083daf906706e7042b39@trac.tools.ietf.org> <8ED1AA60-C79B-4E3A-A017-C18957726BE0@tzi.org> In-Reply-To: <8ED1AA60-C79B-4E3A-A017-C18957726BE0@tzi.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] #325: Define curve for keys and certs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 23 May 2013 10:33:42 -0000 On 05/22/2013 08:16 AM, Carsten Bormann wrote: > On May 21, 2013, at 23:33, "core issue tracker" wrote: > >> #325: Define curve for keys and certs >> >> >> Comment (by hauke@hauke-m.de): >> >> The ECC code we implemented is optimized for a specific curve to save >> space and improve performance on a constrained device. We currently only >> support the secp256r1 curve and SHA-256, because these are the mandatory >> ones. >> >> I think most implementations for constrained device will just implement >> one hash algorithm and one curve or make this chooseable at compile time. > > I read this as supporting the text proposed in the ticket. Yes that's correct. >> It would be nice to have a default value for the curve and the hash >> algorithm in use for a given cipher, so we do not have to support the TLS >> extensions for this. > > Now this one is interesting. > I completely agree with the sentiment. > But how would we get those defaults in? > The DTLS protocol operates independently from any application semantics, so simply saying "DTLS for CoAP works that way" is out. > Making the curve default to secp256r1 for all of TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 would run counter to the curve-independent direction that the draft seems to be taking. > (The hash algorithm already should be the default; it seems to me not being explicit about that is just an oversight in the draft.) > > How onerous are those TLS extensions? Can you give us an example about the code and message size? The code used for creating and parsing the elliptic_curves TLS extension is not that huge to justify a new exception in the DTLS standard for this cipher algorithm or this use case. This TLS extension extends the Client Hello and the Server Hello by 6 bytes in case just one curve is supported. What about the signature_algorithms TLS extension, for me it was not clear if I have to add this extension or not when using TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 I removed it because Californium did not liked it. ;-) Hauke From lishitao@huawei.com Fri May 24 02:28: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 6DA2621F93BA for ; Fri, 24 May 2013 02:28:08 -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 7WWyxGbSKX76 for ; Fri, 24 May 2013 02:28:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7092B21F933B for ; Fri, 24 May 2013 02:28:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATD03391; Fri, 24 May 2013 09:28:01 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 24 May 2013 10:27:37 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 24 May 2013 10:27:52 +0100 Received: from NKGEML501-MBX.china.huawei.com ([169.254.1.244]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Fri, 24 May 2013 17:27:47 +0800 From: Lishitao To: "consultancy@vanderstok.org" , "core@ietf.org" Thread-Topic: [core] draft-shelby-core-interfaces: call for adoption Thread-Index: AQHOVbo7Lgt3NIRG30mDsuEGNBlyY5kOexGAgAAu6ACABVsCcA== Date: Fri, 24 May 2013 09:27:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [core] draft-shelby-core-interfaces: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 May 2013 09:28:08 -0000 First, I would like to say, this is a useful draft. It really gives some he= lp and guidance when implementing M2M applications in the real world.=20 But, I have concerns about section 5.9 "Resource Observation Attributes" in= the interface draft. I believe the best solution to express the observation condition is to use = options, instead of using query parameters contained in the URI. See the following draft for the detailed solution: http://tools.ietf.org/id/draft-li-core-conditional-observe-03.txt I remember that we discussed this before in PairsF2F meeting, and there was= no conclusion yet. http://www.ietf.org/proceedings/83/minutes/minutes-83-core.txt And I think more discussion is needed for this feature. And I hope we can m= ove this section out before accepting it as WG draft. Note that the authors currently updating the draft and will upload it very = soon. Regards Shitao > -----Original Message----- > From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of > peter van der Stok > Sent: Tuesday, May 21, 2013 2:38 PM > To: core@ietf.org > Subject: Re: [core] draft-shelby-core-interfaces: call for adoption >=20 > +1 >=20 > However, the scope and purpose of the document should be a bit clearer. > I see it as a base document that can be referred to by other documents > that provide additional coap based services. >=20 > Having only ONE protocol with related security handling for many coap > based services can be beneficial for the total amount of code in the > coap based nodes. >=20 > Peter van der Stok >=20 > Rahman, Akbar schreef op 2013-05-21 05:50: > > +1 > > > > Akbar > > > > FROM: core-bounces@ietf.org [mailto:core-bounces@ietf.org] ON BEHALF > > OF Andrew Mcgregor > > SENT: Monday, May 20, 2013 8:29 PM > > TO: core@ietf.org > > SUBJECT: [core] draft-shelby-core-interfaces: call for adoption > > > > Consensus of the room in Orlando was to adopt > > draft-shelby-core-interfaces as a working group document. This email > > is a call for confirmation of that consensus. Please respond if you > > support the adoption of this document. > > > > Since REST is not yet in wide use in the microcontroller community, > > documenting some examples of good CoAP design will be beneficial. In > > particular, it is not widely understood how to map certain concepts > > such as batching or binding to REST. We don't have an explicit > > charter item for documenting this, but it is natural to have > > explanatory material with the base specification. (LWIG is not the > > right group for this as this is not about protocol implementation, but > > about design of REST interfaces.) > > > > * Dec 2013 Submission to IESG of "CoRE Interfaces" for Informational > > > > (Again, the objective is to provide examples of good usage for > > implementers, not to standardize or even give strong recommendations.) > > > > Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From zach@sensinode.com Fri May 24 02:43: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 2924121F95D7 for ; Fri, 24 May 2013 02:43:43 -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 lp7wJ-73NMs6 for ; Fri, 24 May 2013 02:43:39 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC1421F957D for ; Fri, 24 May 2013 02:43:38 -0700 (PDT) Received: from [10.128.11.124] (line-21396.dyn.kponet.fi [213.145.192.6]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r4O9hSO6015945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 May 2013 12:43:29 +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: Fri, 24 May 2013 12:43:29 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9B18C869-84FE-49E3-B1BF-31886A7922FF@sensinode.com> References: To: Lishitao X-Mailer: Apple Mail (2.1503) Cc: "core@ietf.org" Subject: Re: [core] draft-shelby-core-interfaces: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 May 2013 09:43:43 -0000 Hi Shitao, Thanks for the feedback, I am aware of the work on using options for = this purpose. However, there are several reasons why I do believe the URI is the = correct place for this, and that we should definitely include this = feature in CoRE interfaces. 1. The Origin Server and the Resource, should be in control over any = semantics regarding the resource representation. Working with parameters = that affect the representation of the resource, MUST be handled as part = of the REST interface. Confusing that into the CoAP options, which = should be agnostic to what is inside the resource representation, would = be the wrong thing to do. What happens if e.g. your resource = representation is a more complex JSON object - how are you going to work = on thresholds with CoAP options then?=20 2. Other standards, e.g. OMA LWM2M are already using this same URI = attribute model for controlling observations. It would be best that we = try to align multiple standards using CoAP to do this in the same way = where possible. 3. You are not going to have a one-size-fits-all with observations = conditionals, doing this through REST allows us to provide at least one = standard model. But it also allows implementations to evolve the REST = interface as needed. Just because we have a REST design that *can* be = used for controlling conditionals on resource types defined in CoRE = Interfaces, it does not mean that is the only way to do it. Other = resource types could inherit or extend this model, and others could do = something different. 4. Finally, CoRE is about constrained RESTful environments, not just = CoAP. Both the Resource Directory and CoRE Interfaces drafts are mostly = usable over HTTP as well, as we want to have people in IoT doing things = in the same way, also when HTTP is useful. By designing these generic = interfaces using REST, that allows this re-use. Now, that is not exclusive of someone using CoAP options to control = observe conditionals, however a lot more thought would need to go into = that. At least for me there are plenty of unanswered questions to that = approach.=20 Zach On May 24, 2013, at 12:27 PM, Lishitao wrote: > First, I would like to say, this is a useful draft. It really gives = some help and guidance when implementing M2M applications in the real = world.=20 >=20 > But, I have concerns about section 5.9 "Resource Observation = Attributes" in the interface draft. >=20 > I believe the best solution to express the observation condition is to = use options, instead of using query parameters contained in the URI. >=20 > See the following draft for the detailed solution: > http://tools.ietf.org/id/draft-li-core-conditional-observe-03.txt >=20 > I remember that we discussed this before in PairsF2F meeting, and = there was no conclusion yet. > http://www.ietf.org/proceedings/83/minutes/minutes-83-core.txt >=20 > And I think more discussion is needed for this feature. And I hope we = can move this section out before accepting it as WG draft. >=20 > Note that the authors currently updating the draft and will upload it = very soon. >=20 > Regards > Shitao >=20 >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of >> peter van der Stok >> Sent: Tuesday, May 21, 2013 2:38 PM >> To: core@ietf.org >> Subject: Re: [core] draft-shelby-core-interfaces: call for adoption >>=20 >> +1 >>=20 >> However, the scope and purpose of the document should be a bit = clearer. >> I see it as a base document that can be referred to by other = documents >> that provide additional coap based services. >>=20 >> Having only ONE protocol with related security handling for many coap >> based services can be beneficial for the total amount of code in the >> coap based nodes. >>=20 >> Peter van der Stok >>=20 >> Rahman, Akbar schreef op 2013-05-21 05:50: >>> +1 >>>=20 >>> Akbar >>>=20 >>> FROM: core-bounces@ietf.org [mailto:core-bounces@ietf.org] ON BEHALF >>> OF Andrew Mcgregor >>> SENT: Monday, May 20, 2013 8:29 PM >>> TO: core@ietf.org >>> SUBJECT: [core] draft-shelby-core-interfaces: call for adoption >>>=20 >>> Consensus of the room in Orlando was to adopt >>> draft-shelby-core-interfaces as a working group document. This email >>> is a call for confirmation of that consensus. Please respond if you >>> support the adoption of this document. >>>=20 >>> Since REST is not yet in wide use in the microcontroller community, >>> documenting some examples of good CoAP design will be beneficial. In >>> particular, it is not widely understood how to map certain concepts >>> such as batching or binding to REST. We don't have an explicit >>> charter item for documenting this, but it is natural to have >>> explanatory material with the base specification. (LWIG is not the >>> right group for this as this is not about protocol implementation, = but >>> about design of REST interfaces.) >>>=20 >>> * Dec 2013 Submission to IESG of "CoRE Interfaces" for Informational >>>=20 >>> (Again, the objective is to provide examples of good usage for >>> implementers, not to standardize or even give strong = recommendations.) >>>=20 >>> Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 >>> _______________________________________________ >>> 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 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From robert.cragie@gridmerge.com Fri May 24 05:36: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 29C5921F9232 for ; Fri, 24 May 2013 05:36:27 -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 TiYWsQcP603I for ; Fri, 24 May 2013 05:36:17 -0700 (PDT) Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id 50BAE21F91CA for ; Fri, 24 May 2013 05:36:16 -0700 (PDT) Received: from [94.116.21.145] (helo=[10.38.242.84]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) id 1UfrEC-0000dB-FM for core@ietf.org; Fri, 24 May 2013 13:36:12 +0100 Message-ID: <519F5EBC.60807@gridmerge.com> Date: Fri, 24 May 2013 13:36:12 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: core@ietf.org References: <051.fb27520c8fa2e3ba5cf748888757b052@trac.tools.ietf.org> <066.20d35cb6974c083daf906706e7042b39@trac.tools.ietf.org> <8ED1AA60-C79B-4E3A-A017-C18957726BE0@tzi.org> <519DF07C.2000808@hauke-m.de> In-Reply-To: <519DF07C.2000808@hauke-m.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030504020007040405030608" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [core] #325: Define curve for keys and certs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 12:36:27 -0000 This is a cryptographically signed message in MIME format. --------------ms030504020007040405030608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable We used the following extensions for TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8=20 when testing ZigBee IP: * elliptic_curves * ec_points_format * signature_algorithms Wireshark decodes it thus: Extension: elliptic_curves Type: elliptic_curves (0x000a) Length: 4 Elliptic Curves Length: 2 Elliptic curves (1 curve) Elliptic curve: secp256r1 (0x0017) Extension: ec_point_formats Type: ec_point_formats (0x000b Length: 2 EC point formats Length: 1 Elliptic curves point formats (1) EC point format: uncompressed (0) Extension: signature_algorithms Type: signature_algorithms (0x000d) Length: 4 Data (4 bytes): 00 02 04 03 The signature_algorithms field further decodes to sha256, ecdsa Robert On 23/05/2013 11:33, Hauke Mehrtens wrote: > On 05/22/2013 08:16 AM, Carsten Bormann wrote: >> On May 21, 2013, at 23:33, "core issue tracker" wrote: >> >>> #325: Define curve for keys and certs >>> >>> >>> Comment (by hauke@hauke-m.de): >>> >>> The ECC code we implemented is optimized for a specific curve to save= >>> space and improve performance on a constrained device. We currently o= nly >>> support the secp256r1 curve and SHA-256, because these are the mandat= ory >>> ones. >>> >>> I think most implementations for constrained device will just impleme= nt >>> one hash algorithm and one curve or make this chooseable at compile t= ime. >> I read this as supporting the text proposed in the ticket. > Yes that's correct. > >>> It would be nice to have a default value for the curve and the hash >>> algorithm in use for a given cipher, so we do not have to support the= TLS >>> extensions for this. >> Now this one is interesting. >> I completely agree with the sentiment. >> But how would we get those defaults in? >> The DTLS protocol operates independently from any application semantic= s, so simply saying "DTLS for CoAP works that way" is out. >> Making the curve default to secp256r1 for all of TLS_ECDHE_ECDSA_WITH_= AES_128_CCM_8 would run counter to the curve-independent direction that t= he draft seems to be taking. >> (The hash algorithm already should be the default; it seems to me not = being explicit about that is just an oversight in the draft.) >> >> How onerous are those TLS extensions? Can you give us an example abou= t the code and message size? > The code used for creating and parsing the elliptic_curves TLS extensio= n > is not that huge to justify a new exception in the DTLS standard for > this cipher algorithm or this use case. This TLS extension extends the > Client Hello and the Server Hello by 6 bytes in case just one curve is > supported. > > What about the signature_algorithms TLS extension, for me it was not > clear if I have to add this extension or not when using > TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 I removed it because Californium did= > not liked it. ;-) > > Hauke > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --------------ms030504020007040405030608 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA1MjQxMjM2MTJaMCMGCSqGSIb3DQEJBDEWBBRo51/RlRoLoI3Ap1zaDZ5GkkvrKTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAG27sMa5chUFwDAsgiqoJG+9Io8W5J4ipb0SO0SleajMcptq ZLqqnZL14hSkUN0l+puiujEXRTVgIG/1DXraJzKhjNt+DXGPUaP+ZDZt5OXl1nmlk2Cnkcb3 vElMNpiPldofKq5ALvPd2J/k47N6W8Jou5PdadnTyF5iftZaugCYNX9M0Uma79IuiMkXGKFp 5MDibR62QEBDqe9enUmalTuLdVsa4n/YOq7ao0TEqqZp8+2GoAp9maoHvqiIZzJ2aCuJbQhZ cqAlM2vFAfbjGaygl6C9AejuEZlQVmrw2R5/pU7QfAjlWtNxqY8mmV+57Lrtu7tXxeBIxTdo zPzpCnMAAAAAAAA= --------------ms030504020007040405030608-- From zach@sensinode.com Fri May 24 07:55:12 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8D921F8E72 for ; Fri, 24 May 2013 07:55:09 -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 8UCT5Od0xWYZ for ; Fri, 24 May 2013 07:54:59 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 2078221F8E06 for ; Fri, 24 May 2013 07:54:58 -0700 (PDT) Received: from [192.168.1.101] (188-67-76-50.bb.dnainternet.fi [188.67.76.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r4OEsrGU019643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 May 2013 17:54:54 +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: <519F5EBC.60807@gridmerge.com> Date: Fri, 24 May 2013 17:54:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5ABDA06C-956D-491C-8241-F243A10ED19E@sensinode.com> References: <051.fb27520c8fa2e3ba5cf748888757b052@trac.tools.ietf.org> <066.20d35cb6974c083daf906706e7042b39@trac.tools.ietf.org> <8ED1AA60-C79B-4E3A-A017-C18957726BE0@tzi.org> <519DF07C.2000808@hauke-m.de> <519F5EBC.60807@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1503) Cc: core@ietf.org Subject: Re: [core] #325: Define curve for keys and certs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 May 2013 14:55:12 -0000 Robert, Thanks. This matches what ticket #325 is saying CoAP implementations = using this Cipher suite MUST support. The proposed text in #325 also = says that other curve settings MAY be used. So I think we are fine with = that ticket.=20 I would also love to have a way to "defaut" these MUST settings in the = handshake, however I agree with Carsten that might not work with all = DTLS implementations (without including the extensions). What is your = opinion? We are currently working on a new DTLS for IoT working group proposal, = and we plan on having a BOF in Berlin. The mailing list for this new = group will be announced very soon. One work item proposed will be = profiling DTLS for IoT applications (mainly for CoAP). This could be one = of the things that could be possible defined in that profile. In the = mean time, we do have a Google doc with information on the activity: = https://docs.google.com/document/d/1Gw00WXRgjJJQJMv9seVpuXuLtIDYKhHE-7pX4e= Do3g8 Zach On May 24, 2013, at 3:36 PM, Robert Cragie = wrote: > We used the following extensions for = TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 when testing ZigBee IP: >=20 > * elliptic_curves > * ec_points_format > * signature_algorithms >=20 > Wireshark decodes it thus: >=20 > Extension: elliptic_curves > Type: elliptic_curves (0x000a) > Length: 4 > Elliptic Curves Length: 2 > Elliptic curves (1 curve) > Elliptic curve: secp256r1 (0x0017) >=20 > Extension: ec_point_formats > Type: ec_point_formats (0x000b > Length: 2 > EC point formats Length: 1 > Elliptic curves point formats (1) > EC point format: uncompressed (0) >=20 > Extension: signature_algorithms > Type: signature_algorithms (0x000d) > Length: 4 > Data (4 bytes): 00 02 04 03 >=20 > The signature_algorithms field further decodes to sha256, ecdsa >=20 > Robert >=20 >=20 > On 23/05/2013 11:33, Hauke Mehrtens wrote: >> On 05/22/2013 08:16 AM, Carsten Bormann wrote: >>> On May 21, 2013, at 23:33, "core issue tracker" = wrote: >>>=20 >>>> #325: Define curve for keys and certs >>>>=20 >>>>=20 >>>> Comment (by hauke@hauke-m.de): >>>>=20 >>>> The ECC code we implemented is optimized for a specific curve to = save >>>> space and improve performance on a constrained device. We currently = only >>>> support the secp256r1 curve and SHA-256, because these are the = mandatory >>>> ones. >>>>=20 >>>> I think most implementations for constrained device will just = implement >>>> one hash algorithm and one curve or make this chooseable at compile = time. >>> I read this as supporting the text proposed in the ticket. >> Yes that's correct. >>=20 >>>> It would be nice to have a default value for the curve and the hash >>>> algorithm in use for a given cipher, so we do not have to support = the TLS >>>> extensions for this. >>> Now this one is interesting. >>> I completely agree with the sentiment. >>> But how would we get those defaults in? >>> The DTLS protocol operates independently from any application = semantics, so simply saying "DTLS for CoAP works that way" is out. >>> Making the curve default to secp256r1 for all of = TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 would run counter to the = curve-independent direction that the draft seems to be taking. >>> (The hash algorithm already should be the default; it seems to me = not being explicit about that is just an oversight in the draft.) >>>=20 >>> How onerous are those TLS extensions? Can you give us an example = about the code and message size? >> The code used for creating and parsing the elliptic_curves TLS = extension >> is not that huge to justify a new exception in the DTLS standard for >> this cipher algorithm or this use case. This TLS extension extends = the >> Client Hello and the Server Hello by 6 bytes in case just one curve = is >> supported. >>=20 >> What about the signature_algorithms TLS extension, for me it was not >> clear if I have to add this extension or not when using >> TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 I removed it because Californium = did >> not liked it. ;-) >>=20 >> Hauke >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core >>=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From zach@sensinode.com Fri May 24 08:03: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 36FF921F880F for ; Fri, 24 May 2013 08:03:09 -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 CG65WT1xTwzp for ; Fri, 24 May 2013 08:03:05 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id F33A621F87D1 for ; Fri, 24 May 2013 08:03:04 -0700 (PDT) Received: from [192.168.1.101] (188-67-76-50.bb.dnainternet.fi [188.67.76.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r4OF31U7020731 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 May 2013 18:03:02 +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: Fri, 24 May 2013 18:03:01 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <15C704CA-839F-41CE-99C8-73DA52A0CBFB@sensinode.com> References: To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.1503) Cc: core@ietf.org Subject: Re: [core] draft-shelby-core-resource-directory: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 May 2013 15:03:09 -0000 Peter, I agree, as discussed in Orlando, we should integrate the DNS-SD mapping = to this document.=20 Thanks, Zach=20 On May 21, 2013, at 9:47 AM, peter van der Stok = wrote: > I certainly support this, but with the remark that relation to DNS and = DNS-SD should be clarified in the document. > This concerns how to handle name resolution with respect to = information stored in resource directory > and text from lynn draft about conversion of attribute values to RR in = DNS >=20 > Peter van der Stok >=20 > Rahman, Akbar schreef op 2013-05-21 05:49: >> +1 >> Akbar >> FROM: core-bounces@ietf.org [mailto:core-bounces@ietf.org] ON BEHALF >> OF Andrew Mcgregor >> SENT: Monday, May 20, 2013 8:26 PM >> TO: core@ietf.org >> SUBJECT: [core] draft-shelby-core-resource-directory: call for = adoption >> Consensus of the room in Orlando was to adopt >> draft-shelby-core-resource-directory as a working group document. = This >> email is a call for confirmation of that consensus. Please respond if >> you support the adoption of this document. >> =46rom the charter: >> 5) A definition of how to use CoAP to advertise about or query for a >> Device's description. This description may include the device name = and >> a list of its Resources, each with a URL, an interface description = URI >> (pointing e.g. to a Web Application Description Language (WADL) >> document) and an optional name or identifier. The name taxonomy used >> for this description will be consistent with other IETF work, >> e.g. draft-cheshire-dnsext-dns-sd. >> RFC 6690 has some of this; the resource directory would add protocol >> elements on top of CoAP that enhance the "advertise about or query >> for" aspect. >> * Feb 2014 Submission to IESG of "CoRE Resource Directory" for >> Proposed Standard >> -- >> Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From zach@sensinode.com Fri May 24 08:05:25 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F2D21F8D41 for ; Fri, 24 May 2013 08:05:25 -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 896KACVrCC3N for ; Fri, 24 May 2013 08:05:21 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 0625521F8F7A for ; Fri, 24 May 2013 08:05:17 -0700 (PDT) Received: from [192.168.1.101] (188-67-76-50.bb.dnainternet.fi [188.67.76.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r4OF5FqO021008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 May 2013 18:05:16 +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: Fri, 24 May 2013 18:05:16 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1C54709C-9F2F-4D39-9E36-CBEDD0A668F9@sensinode.com> References: To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.1503) Cc: core@ietf.org Subject: Re: [core] draft-shelby-core-interfaces: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 May 2013 15:05:25 -0000 On May 21, 2013, at 9:38 AM, peter van der Stok = wrote: > However, the scope and purpose of the document should be a bit = clearer. > I see it as a base document that can be referred to by other documents = that provide additional coap based services. Yes. It defines a REST design paradigm that can just simply be used by a = developer, or referenced by other documents/standards building REST = interfaces over CoAP. We can surely (as a WG) explain the scope and = purpose better.=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 floris.vandenabeele@intec.ugent.be Fri May 24 09:25: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 928A421F8CA0 for ; Fri, 24 May 2013 09:25:26 -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 SGmWoE8KpXoG for ; Fri, 24 May 2013 09:25:21 -0700 (PDT) Received: from smtp3.ugent.be (smtp3.ugent.be [157.193.49.127]) by ietfa.amsl.com (Postfix) with ESMTP id 5216D21F9512 for ; Fri, 24 May 2013 09:25:17 -0700 (PDT) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp3.ugent.be (Postfix) with ESMTP id 674D8C3EF; Fri, 24 May 2013 18:25:10 +0200 (CEST) X-Virus-Scanned: by UGent DICT Received: from smtp3.ugent.be ([157.193.49.127]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id R4V9tWH5nGiR; Fri, 24 May 2013 18:25:08 +0200 (CEST) Received: from mail2.intec.ugent.be (mail2.intec.ugent.be [157.193.214.245]) by smtp3.ugent.be (Postfix) with ESMTP id 9D63FC3FD; Fri, 24 May 2013 18:25:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail2.intec.ugent.be (Postfix) with ESMTP id 903BB1F; Fri, 24 May 2013 18:25:08 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at intec.ugent.be Received: from mail2.intec.ugent.be ([127.0.0.1]) by localhost (mail2.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5PD8-PKT9gl; Fri, 24 May 2013 18:25:08 +0200 (CEST) Received: from [157.193.135.210] (dhcp-zdpt-210.intec.ugent.be [157.193.135.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fvdabeele) by mail2.intec.ugent.be (Postfix) with ESMTPSA id 7D36F1E; Fri, 24 May 2013 18:25:08 +0200 (CEST) Message-ID: <519F9464.6010704@intec.ugent.be> Date: Fri, 24 May 2013 18:25:08 +0200 From: Floris Van den Abeele User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Zach Shelby References: <9B18C869-84FE-49E3-B1BF-31886A7922FF@sensinode.com> In-Reply-To: <9B18C869-84FE-49E3-B1BF-31886A7922FF@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at jchkm3 with ID 519F9464.001 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 519F9464.001 from mail2.intec.ugent.be/mail2.intec.ugent.be/157.193.214.245/mail2.intec.ugent.be/ X-j-chkmail-Score: MSGID : 519F9464.001 on smtp3.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: "core@ietf.org" Subject: Re: [core] draft-shelby-core-interfaces: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 May 2013 16:25:26 -0000 Hi Zach & all, It seems to me that the approach in the interfaces draft limits the values that a REST resource will actually publish to the 'entire world'? Say that 2 clients want to observe the same resource with different conditions, with the current approach this isn't possible. A 'REST-compatible way' to solve this (there might be other, better ideas) could be to create a new temporary (sub)resource (e.g. /temp/1, /temp/2) in response to the PUT requests for every client and let the client observe the 'tailor-made' sub-resource. Whether this is feasible for constrained devices, I am unsure. Are you using more than 1 client in your deployments? Another critique that I wanted to make is that there might be overlap with the URI-query parameters the resource itself actually wants to use (related to me reply to your point #3). I was also wondering why the draft decided to move to a separate PUT request for specifying the conditions? Why didn't you keep it in the observe request as in previous versions? The above suggestion could justify the separate request, although a POST instead of a PUT request would be better suited here. Cheers, Floris Op 24-05-13 11:43, Zach Shelby schreef: > Hi Shitao, > > Thanks for the feedback, I am aware of the work on using options for this purpose. > > However, there are several reasons why I do believe the URI is the correct place for this, and that we should definitely include this feature in CoRE interfaces. > > 1. The Origin Server and the Resource, should be in control over any semantics regarding the resource representation. Working with parameters that affect the representation of the resource, MUST be handled as part of the REST interface. Confusing that into the CoAP options, which should be agnostic to what is inside the resource representation, would be the wrong thing to do. What happens if e.g. your resource representation is a more complex JSON object - how are you going to work on thresholds with CoAP options then? The logic to filter a more complex JSON object according to a URI-query option or an other option (like the Condition option) would be exactly the same in both casing; I'm afraid I'm missing the latter point. In the conditional observe draft the representation of the resource is actually only altered on a per-client basis; so if you would observe the resource with a different source endpoint you would still see that the resource's representation isn't limited to what the conditions specify. Only the notifications that are sent to the client are filtered according to the conditions. > > 2. Other standards, e.g. OMA LWM2M are already using this same URI attribute model for controlling observations. It would be best that we try to align multiple standards using CoAP to do this in the same way where possible. I agree that it would be best to keep standards aligned where possible. Would you mind sending the specific OMA standard to me (off-list)? So far I have only found the 'LWM2M-4 Information Reporting' interface. > 3. You are not going to have a one-size-fits-all with observations conditionals, doing this through REST allows us to provide at least one standard model. But it also allows implementations to evolve the REST interface as needed. Just because we have a REST design that *can* be used for controlling conditionals on resource types defined in CoRE Interfaces, it does not mean that is the only way to do it. Other resource types could inherit or extend this model, and others could do something different. One of the goals of the conditional observe draft is to avoid ending up with a plethora of incompatible/non-interoperable conditions. Although this discussion isn't related to using CoAP options vs URI queries for condition signalling; I think that we as a WG should try to define a set of 'common' conditions and refer readers of the interfaces draft to this documentation. In light of these points, I would say that the section could still use some additional work/refining. It isn't substantial enough for me to block WG adoption though; so +1 for WG adoptation. > 4. Finally, CoRE is about constrained RESTful environments, not just CoAP. Both the Resource Directory and CoRE Interfaces drafts are mostly usable over HTTP as well, as we want to have people in IoT doing things in the same way, also when HTTP is useful. By designing these generic interfaces using REST, that allows this re-use. I agree. Although some mechanisms like observe and block divert from this principle, so at a minimum I find it difficult where to draw the line. > Now, that is not exclusive of someone using CoAP options to control observe conditionals, however a lot more thought would need to go into that. At least for me there are plenty of unanswered questions to that approach. > > Zach > > On May 24, 2013, at 12:27 PM, Lishitao wrote: > >> First, I would like to say, this is a useful draft. It really gives some help and guidance when implementing M2M applications in the real world. >> >> But, I have concerns about section 5.9 "Resource Observation Attributes" in the interface draft. >> >> I believe the best solution to express the observation condition is to use options, instead of using query parameters contained in the URI. >> >> See the following draft for the detailed solution: >> http://tools.ietf.org/id/draft-li-core-conditional-observe-03.txt >> >> I remember that we discussed this before in PairsF2F meeting, and there was no conclusion yet. >> http://www.ietf.org/proceedings/83/minutes/minutes-83-core.txt >> >> And I think more discussion is needed for this feature. And I hope we can move this section out before accepting it as WG draft. >> >> Note that the authors currently updating the draft and will upload it very soon. >> >> Regards >> Shitao >> >>> -----Original Message----- >>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of >>> peter van der Stok >>> Sent: Tuesday, May 21, 2013 2:38 PM >>> To: core@ietf.org >>> Subject: Re: [core] draft-shelby-core-interfaces: call for adoption >>> >>> +1 >>> >>> However, the scope and purpose of the document should be a bit clearer. >>> I see it as a base document that can be referred to by other documents >>> that provide additional coap based services. >>> >>> Having only ONE protocol with related security handling for many coap >>> based services can be beneficial for the total amount of code in the >>> coap based nodes. >>> >>> Peter van der Stok >>> >>> Rahman, Akbar schreef op 2013-05-21 05:50: >>>> +1 >>>> >>>> Akbar >>>> >>>> FROM: core-bounces@ietf.org [mailto:core-bounces@ietf.org] ON BEHALF >>>> OF Andrew Mcgregor >>>> SENT: Monday, May 20, 2013 8:29 PM >>>> TO: core@ietf.org >>>> SUBJECT: [core] draft-shelby-core-interfaces: call for adoption >>>> >>>> Consensus of the room in Orlando was to adopt >>>> draft-shelby-core-interfaces as a working group document. This email >>>> is a call for confirmation of that consensus. Please respond if you >>>> support the adoption of this document. >>>> >>>> Since REST is not yet in wide use in the microcontroller community, >>>> documenting some examples of good CoAP design will be beneficial. In >>>> particular, it is not widely understood how to map certain concepts >>>> such as batching or binding to REST. We don't have an explicit >>>> charter item for documenting this, but it is natural to have >>>> explanatory material with the base specification. (LWIG is not the >>>> right group for this as this is not about protocol implementation, but >>>> about design of REST interfaces.) >>>> >>>> * Dec 2013 Submission to IESG of "CoRE Interfaces" for Informational >>>> >>>> (Again, the objective is to provide examples of good usage for >>>> implementers, not to standardize or even give strong recommendations.) >>>> >>>> Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From Richard.Kelsey@silabs.com Fri May 24 15:11: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 9401A21F8A74 for ; Fri, 24 May 2013 15:11:07 -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 xBcZ+lydaoBV for ; Fri, 24 May 2013 15:11:01 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with ESMTP id 1E32021F969A for ; Fri, 24 May 2013 15:10:59 -0700 (PDT) Received: from mxsause01.silabs.com ([66.193.122.70]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKUZ/lcGDBZgPYdCtMgjT+EqhpY3n56HWY@postini.com; Fri, 24 May 2013 15:11:01 PDT Received: from EXCAUS010.silabs.com (unknown [10.100.0.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mxsause01.silabs.com (Postfix) with ESMTP id 8D203FF11A; Fri, 24 May 2013 17:10:49 -0500 (CDT) Received: from kelsey-ws (10.4.148.23) by EXCAUS010.silabs.com (10.100.0.59) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 24 May 2013 17:10:49 -0500 Date: Fri, 24 May 2013 18:13:50 -0400 Message-ID: <87r4gw2fhd.fsf@kelsey-ws.hq.ember.com> From: Richard Kelsey To: Zach Shelby In-Reply-To: <5ABDA06C-956D-491C-8241-F243A10ED19E@sensinode.com> (message from Zach Shelby on Fri, 24 May 2013 17:54:54 +0300) X-Auto-Response-Suppress: DR, OOF, AutoReply References: <051.fb27520c8fa2e3ba5cf748888757b052@trac.tools.ietf.org> <066.20d35cb6974c083daf906706e7042b39@trac.tools.ietf.org> <8ED1AA60-C79B-4E3A-A017-C18957726BE0@tzi.org> <519DF07C.2000808@hauke-m.de> <519F5EBC.60807@gridmerge.com> <5ABDA06C-956D-491C-8241-F243A10ED19E@sensinode.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.4.148.23] X-Mailman-Approved-At: Fri, 24 May 2013 15:24:02 -0700 Cc: core@ietf.org Subject: Re: [core] #325: Define curve for keys and certs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 May 2013 22:11:07 -0000 > From: Zach Shelby > Date: Fri, 24 May 2013 17:54:54 +0300 > > I would also love to have a way to "defaut" these MUST settings in the > handshake, however I agree with Carsten that might not work with all > DTLS implementations (without including the extensions). What is your > opinion? Zach, I wouldn't worry too much about trying to avoid including these as options. They add something like 23 bytes to one not-too-large handshake message. This seems like a small price to pay for general interoperability. The record layer seems like a better target for optimization, given that you will likely send a lot more application messages than handshake messages. -Richard Kelsey [...] > On May 24, 2013, at 3:36 PM, Robert Cragie wrote: > > > We used the following extensions for TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 when testing ZigBee IP: > > > > * elliptic_curves > > * ec_points_format > > * signature_algorithms > > > > Wireshark decodes it thus: > > > > Extension: elliptic_curves > > Type: elliptic_curves (0x000a) > > Length: 4 > > Elliptic Curves Length: 2 > > Elliptic curves (1 curve) > > Elliptic curve: secp256r1 (0x0017) > > > > Extension: ec_point_formats > > Type: ec_point_formats (0x000b > > Length: 2 > > EC point formats Length: 1 > > Elliptic curves point formats (1) > > EC point format: uncompressed (0) > > > > Extension: signature_algorithms > > Type: signature_algorithms (0x000d) > > Length: 4 > > Data (4 bytes): 00 02 04 03 > > > > The signature_algorithms field further decodes to sha256, ecdsa > > > > Robert > > This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication. Thank you. From cabo@tzi.org Fri May 24 15:48: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 D193411E8136 for ; Fri, 24 May 2013 15:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.218 X-Spam-Level: X-Spam-Status: No, score=-106.218 tagged_above=-999 required=5 tests=[AWL=0.031, 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 rlOslE3k-fyV for ; Fri, 24 May 2013 15:47: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 8EDBA11E8134 for ; Fri, 24 May 2013 15:47: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 r4OMlmWg007331 for ; Sat, 25 May 2013 00:47:48 +0200 (CEST) Received: from [192.168.217.105] (p548901BB.dip0.t-ipconnect.de [84.137.1.187]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 828CC381F; Sat, 25 May 2013 00:47:47 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sat, 25 May 2013 00:47:45 +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] Outstanding tickets on core-coap-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: Fri, 24 May 2013 22:48:04 -0000 I think we have had a good discussion on #325, so we should be ready to = close that ticket after the authors generate a little more text. I plan to include the list Robert provided as an implementation note. #323, #324 have strawman text that we can use and that should be fine. #326 has a reply that indicates a direction; the authors still have to = generate some text for that, but that should be easy. #327 has strawman text that may not be great, but if we want to give = advice on ICMP errors, it is likely the best advice we can give. I'd like to hear some opinions from implementers on the list before = closing this. I expect to cover a bit more of the extensive editorial feedback from = the IESG, as well. My plan is to have -17 submitted by the end of the weekend, so that we = can work next week on clearing more of the IESG DISCUSSes. Shortcut to the bug tracker: http://i-e.tf/,,core/9 Gr=FC=DFe, Carsten From lishitao@huawei.com Fri May 24 18:55: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 0E92921F84CD for ; Fri, 24 May 2013 18:55:14 -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 19pZynNMPOOd for ; Fri, 24 May 2013 18:55:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 019FD21F8481 for ; Fri, 24 May 2013 18:55:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARS24952; Sat, 25 May 2013 01:55:06 +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; Sat, 25 May 2013 02:54:48 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 25 May 2013 02:55:05 +0100 Received: from NKGEML501-MBX.china.huawei.com ([169.254.1.244]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Sat, 25 May 2013 09:55:01 +0800 From: Lishitao To: Zach Shelby Thread-Topic: [core] draft-shelby-core-interfaces: call for adoption Thread-Index: AQHOVbo7Lgt3NIRG30mDsuEGNBlyY5kOexGAgAAu6ACABVsCcP//j76AgAGM2NA= Date: Sat, 25 May 2013 01:55:01 +0000 Message-ID: References: <9B18C869-84FE-49E3-B1BF-31886A7922FF@sensinode.com> In-Reply-To: <9B18C869-84FE-49E3-B1BF-31886A7922FF@sensinode.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org" Subject: Re: [core] draft-shelby-core-interfaces: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 May 2013 01:55:14 -0000 > -----Original Message----- > From: Zach Shelby [mailto:zach@sensinode.com] > Sent: Friday, May 24, 2013 5:43 PM > To: Lishitao > Cc: consultancy@vanderstok.org; core@ietf.org > Subject: Re: [core] draft-shelby-core-interfaces: call for adoption >=20 > Hi Shitao, >=20 > Thanks for the feedback, I am aware of the work on using options for this > purpose. >=20 > However, there are several reasons why I do believe the URI is the correc= t > place for this, and that we should definitely include this feature in CoR= E > interfaces. >=20 > 1. The Origin Server and the Resource, should be in control over any sema= ntics > regarding the resource representation. Working with parameters that affec= t > the representation of the resource, MUST be handled as part of the REST > interface. Confusing that into the CoAP options, which should be agnostic= to > what is inside the resource representation, would be the wrong thing to d= o. > What happens if e.g. your resource representation is a more complex JSON > object - how are you going to work on thresholds with CoAP options then? >=20 I am not quite understand about this, if the resource represents using JSO= N instead of link format, the client just needs to understand=20 about the JSON format before sending any request. It is not a problem only = for observe.=20 And since the JSON object for resource representation is still under workin= g, it needs a way to solve this problem if it has. > 2. Other standards, e.g. OMA LWM2M are already using this same URI > attribute model for controlling observations. It would be best that we tr= y to > align multiple standards using CoAP to do this in the same way where poss= ible. > I think OMA LWM2M just defines the requirements and its structure. The deta= il about how to use coap is out of scope.=20 > 3. You are not going to have a one-size-fits-all with observations condit= ionals, > doing this through REST allows us to provide at least one standard model.= But it > also allows implementations to evolve the REST interface as needed. Just > because we have a REST design that *can* be used for controlling conditio= nals > on resource types defined in CoRE Interfaces, it does not mean that is th= e only > way to do it. Other resource types could inherit or extend this model, an= d > others could do something different. Yes, using option is one of the possible solution, and can solve most of th= e problems, URI-query also has its limits. > 4. Finally, CoRE is about constrained RESTful environments, not just CoAP= . Both > the Resource Directory and CoRE Interfaces drafts are mostly usable over > HTTP as well, as we want to have people in IoT doing things in the same w= ay, > also when HTTP is useful. By designing these generic interfaces using RES= T, > that allows this re-use. > HTTP does not has observe mechanism(something like HTTP streaming may provi= de the almost same function, but not using the same mechanism), So I don't think that is a problem, anyway you need a way for interworking = between coap and HTTP. Not all the HTTP staff can be used in coap, and vice= versa. > Now, that is not exclusive of someone using CoAP options to control obser= ve > conditionals, however a lot more thought would need to go into that. At l= east > for me there are plenty of unanswered questions to that approach. > Yes, I also believe that conditional observe is not an easy issue, our draf= t has not cover all the problems.=20 And it is also not that easy to describe clear just in one clause. So I str= ongly recommend that moves the conditional observe part from the interface = draft, then we can study together to solve that problem. shitao > Zach >=20 > On May 24, 2013, at 12:27 PM, Lishitao wrote: >=20 > > First, I would like to say, this is a useful draft. It really gives som= e help and > guidance when implementing M2M applications in the real world. > > > > But, I have concerns about section 5.9 "Resource Observation Attributes= " in > the interface draft. > > > > I believe the best solution to express the observation condition is to = use > options, instead of using query parameters contained in the URI. > > > > See the following draft for the detailed solution: > > http://tools.ietf.org/id/draft-li-core-conditional-observe-03.txt > > > > I remember that we discussed this before in PairsF2F meeting, and there= was > no conclusion yet. > > http://www.ietf.org/proceedings/83/minutes/minutes-83-core.txt > > > > And I think more discussion is needed for this feature. And I hope we c= an > move this section out before accepting it as WG draft. > > > > Note that the authors currently updating the draft and will upload it v= ery > soon. > > > > Regards > > Shitao > > > >> -----Original Message----- > >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf O= f > >> peter van der Stok > >> Sent: Tuesday, May 21, 2013 2:38 PM > >> To: core@ietf.org > >> Subject: Re: [core] draft-shelby-core-interfaces: call for adoption > >> > >> +1 > >> > >> However, the scope and purpose of the document should be a bit clearer= . > >> I see it as a base document that can be referred to by other documents > >> that provide additional coap based services. > >> > >> Having only ONE protocol with related security handling for many coap > >> based services can be beneficial for the total amount of code in the > >> coap based nodes. > >> > >> Peter van der Stok > >> > >> Rahman, Akbar schreef op 2013-05-21 05:50: > >>> +1 > >>> > >>> Akbar > >>> > >>> FROM: core-bounces@ietf.org [mailto:core-bounces@ietf.org] ON BEHALF > >>> OF Andrew Mcgregor > >>> SENT: Monday, May 20, 2013 8:29 PM > >>> TO: core@ietf.org > >>> SUBJECT: [core] draft-shelby-core-interfaces: call for adoption > >>> > >>> Consensus of the room in Orlando was to adopt > >>> draft-shelby-core-interfaces as a working group document. This email > >>> is a call for confirmation of that consensus. Please respond if you > >>> support the adoption of this document. > >>> > >>> Since REST is not yet in wide use in the microcontroller community, > >>> documenting some examples of good CoAP design will be beneficial. In > >>> particular, it is not widely understood how to map certain concepts > >>> such as batching or binding to REST. We don't have an explicit > >>> charter item for documenting this, but it is natural to have > >>> explanatory material with the base specification. (LWIG is not the > >>> right group for this as this is not about protocol implementation, bu= t > >>> about design of REST interfaces.) > >>> > >>> * Dec 2013 Submission to IESG of "CoRE Interfaces" for Informational > >>> > >>> (Again, the objective is to provide examples of good usage for > >>> implementers, not to standardize or even give strong recommendations.= ) > >>> > >>> Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com @SensinodeIoT > Mobile: +358 40 7796297 > Twitter: @zach_shelby > LinkedIn: http://fi.linkedin.com/in/zachshelby > 6LoWPAN Book: http://6lowpan.net >=20 >=20 >=20 From rdroms.ietf@gmail.com Sat May 25 03:45: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 1B64221F8FBA for ; Sat, 25 May 2013 03:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 vSs9IF-sY-Ef for ; Sat, 25 May 2013 03:45:11 -0700 (PDT) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7513621F9092 for ; Sat, 25 May 2013 03:45:09 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id x7so3008574qeu.23 for ; Sat, 25 May 2013 03:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; bh=hnSDgz0Qq3Cg8AYc0sMhhv6gbluqPWLwVjYGcAwlnns=; b=zkBN2Bbpbj6EyoxyiWb/pFiibxLm3HjharuRZe+Zj042ocAd+8NXmeqf4iJ4n9bZmN AjJRz4AqwbqtRxyM4iGTQNnlA4ug1mBu0Xay2hrFBE+CAxY3HxaOm/zncSuezS//2HOT oqpFb/+DfxOyXVKtcbL/RxXnBHWQAUkFQf0ShYqMmpZpZuuVZnGtgaKa4xZxmBqX/ydl feGaXvDTNyOQNAWq/thA0Dn5huBY8n3l+Kl/ANr3ZliVNvre0QIvAQoMP6ImHWMZwmcp ViKj+ZABR6YY0+RJHhdfHSAZW8CjMMvoyzCrBwPu5Nh+pRhuuShXggjZ7F6/8WDoQKuZ 3PvA== X-Received: by 10.224.165.146 with SMTP id i18mr19715590qay.33.1369478708989; Sat, 25 May 2013 03:45:08 -0700 (PDT) Received: from ?IPv6:2001:420:2481:20:1dc0:7216:c62a:4749? ([2001:420:2481:20:1dc0:7216:c62a:4749]) by mx.google.com with ESMTPSA id bc5sm17574653qeb.3.2013.05.25.03.45.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 May 2013 03:45:08 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 25 May 2013 06:45:07 -0400 References: <20130524181840.1900.71091.idtracker@ietfa.amsl.com> To: core@ietf.org Message-Id: <468D7C9F-1DD7-4214-869E-E231CC7AD8F0@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [core] Fwd: New Non-WG Mailing List: 6lo -- Mailing list for discussion of a WG for Internet Area issues in IPv6 over constrained node networks X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 May 2013 10:45:11 -0000 FYI... Begin forwarded message: > From: IETF Secretariat > Subject: New Non-WG Mailing List: 6lo -- Mailing list for discussion = of a WG for Internet Area issues in IPv6 over constrained node networks > Date: May 24, 2013 2:18:40 PM EDT > To: IETF Announcement List > Cc: 6lo@ietf.org, rdroms.ietf@gmail.com, cabo@tzi.org >=20 >=20 > A new IETF non-working group email list has been created. >=20 > List address: 6lo@ietf.org > Archive: http://www.ietf.org/mail-archive/web/6lo/ > To subscribe: https://www.ietf.org/mailman/listinfo/6lo >=20 > Purpose: Since it was set up in 2005, the 6LoWPAN WG has created = specifications > for building IPv6 networks out of devices that use the IEEE 802.15.4 > wireless network standard. This work has culminated in the recent > publication of RFC 6775, 6LoWPAN-ND, and the 6LoWPAN WG is shutting = down. >=20 > This does not mean the work in this space is done. Indeed, 6LoWPAN > produced one more document that isn't even about 802.15.4: > draft-ietf-6lowpan-btle-12.txt, the equivalent of 6LoWPAN for the low > energy mode of the Bluetooth 4.0 specification, is now in IESG > processing, waiting for the assignment of a number from the Bluetooth > SIG. A number of related drafts want to apply 6LoWPAN technology to > other constrained node network layer 2 specifications: >=20 > -- draft-brandt-6man-lowpanz-00.txt > -- draft-ietf-6man-6lobac-01.txt > -- draft-mariager-6lowpan-v6over-dect-ule-02.txt >=20 > Also, some additional specifications are generally regarded as useful > complements of the existing 6LoWPAN work: >=20 > -- draft-schoenw-6lowpan-mib-03.txt > -- draft-bormann-6lowpan-ghc-05.txt > -- draft-kelsey-intarea-mesh-link-establishment-05.txt > -- draft-bormann-6lowpan-roadmap-03.txt >=20 > Beyond that, some older proposals that the 6LoWPAN WG has not picked > up are receiving new attention: >=20 > -- draft-thubert-6lowpan-backbone-router-03.txt > -- draft-thubert-roll-forwarding-frags-01.txt >=20 > Finally, there are some architectural issues raised by 6LoWPAN's use > of adaptation layer fragmentation on top of a lossy radio: >=20 > -- draft-bormann-intarea-alfi-02.txt >=20 > As can be seen, these drafts have been addressed to a zoo of working > groups, including the sunsetting 6LoWPAN WG, the 6MAN WG, INTAREA, and > even ROLL, with the addressed WG often changing over the lifetime of a > draft. It is probably more productive to focus most of this closely > related work on a specific WG. >=20 > One clear candidate is the 6man WG. However, that WG has a number of > other duties in maintaining IPv6 that make it subscribing to its > mailing list too onerous to the group of experts interested in > constrained node networking. It is probably worth separating out the > 6man-related work that focuses on constrained node networks. There > are, however, architectural aspects that are indeed best left in 6man > or even INTAREA. The 6Lo mailing list has been set up to organize the > discussion of a charter for a potential working group that focuses on > IP-over-foo standardization (adaptation layers) for constrained node > networks, working closely with the INT area working groups and other > IETF WGs focused on constrained node networks. >=20 > For additional information, please contact the list administrators. From trac+core@trac.tools.ietf.org Sat May 25 13:59: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 4BAD421F8D90 for ; Sat, 25 May 2013 13:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 yE9-s+aLks19 for ; Sat, 25 May 2013 13:58:59 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B683121F8D70 for ; Sat, 25 May 2013 13:58:59 -0700 (PDT) Received: from localhost ([127.0.0.1]:38562 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UgLYH-0004hh-GS; Sat, 25 May 2013 22:58: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: Sat, 25 May 2013 20:58:57 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/323#comment:1 Message-ID: <066.5e20be4b0782c5b5f38bf8d5500f58e7@trac.tools.ietf.org> References: <051.63589cd06f69ed6c22b3b45441be5003@trac.tools.ietf.org> X-Trac-Ticket-ID: 323 In-Reply-To: <051.63589cd06f69ed6c22b3b45441be5003@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: <20130525205859.B683121F8D70@ietfa.amsl.com> Resent-Date: Sat, 25 May 2013 13:58:59 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #323: Discuss constrained node security considerations, including entropy X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 20:59:00 -0000 #323: Discuss constrained node security considerations, including entropy Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1390]: Fix #323 -- -------------------------+------------------------------------------------- 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-16 Component: coap | Resolution: fixed Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sat May 25 14:03: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 5879821F8D90 for ; Sat, 25 May 2013 14:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 qtxqQmS8sZ8a for ; Sat, 25 May 2013 14:03: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 C18C121F8D70 for ; Sat, 25 May 2013 14:03:15 -0700 (PDT) Received: from localhost ([127.0.0.1]:39102 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UgLcP-0005bP-S0; Sat, 25 May 2013 23:03:13 +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: Sat, 25 May 2013 21:03:13 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/324#comment:1 Message-ID: <066.4377cd615f81a192ddd393d3cb217959@trac.tools.ietf.org> References: <051.dec31a5931cb4696925344dd724d4a85@trac.tools.ietf.org> X-Trac-Ticket-ID: 324 In-Reply-To: <051.dec31a5931cb4696925344dd724d4a85@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: <20130525210315.C18C121F8D70@ietfa.amsl.com> Resent-Date: Sat, 25 May 2013 14:03:15 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #324: Discuss key pair generation for RPK X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 21:03:16 -0000 #324: Discuss key pair generation for RPK Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1391]: Fix #324 -- -------------------------+------------------------------------------------- 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-16 Component: coap | Resolution: fixed Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sat May 25 14:10: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 20EE721F8696 for ; Sat, 25 May 2013 14:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyYWcD5egYZD for ; Sat, 25 May 2013 14:10: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 8D74321F8617 for ; Sat, 25 May 2013 14:10:31 -0700 (PDT) Received: from localhost ([127.0.0.1]:39401 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UgLjL-0005Op-HZ; Sat, 25 May 2013 23:10:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, zach@sensinode.com, cabo@tzi.org X-Trac-Project: core Date: Sat, 25 May 2013 21:10:23 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/326#comment:2 Message-ID: <066.82cf6a59cddb33b0afb77c1e3369613c@trac.tools.ietf.org> References: <051.00f753610c3e1a807ab108f35c6719cc@trac.tools.ietf.org> X-Trac-Ticket-ID: 326 In-Reply-To: <051.00f753610c3e1a807ab108f35c6719cc@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: <20130525211031.8D74321F8617@ietfa.amsl.com> Resent-Date: Sat, 25 May 2013 14:10:31 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #326: Who defines the application profile for PSK identity hints? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 21:10:32 -0000 #326: Who defines the application profile for PSK identity hints? Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1392]: Fix #326 -- -------------------------+------------------------------------------------- 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-16 Component: coap | Resolution: fixed Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From cabo@tzi.org Sat May 25 14:34: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 94ABF21F8DFC; Sat, 25 May 2013 14:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.22 X-Spam-Level: X-Spam-Status: No, score=-106.22 tagged_above=-999 required=5 tests=[AWL=0.029, 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 ktAPbqKPbxrE; Sat, 25 May 2013 14:34: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 80C4B21F8D41; Sat, 25 May 2013 14:34: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 r4PLYUVM018765; Sat, 25 May 2013 23:34:30 +0200 (CEST) Received: from [192.168.217.105] (p548914E3.dip0.t-ipconnect.de [84.137.20.227]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id ED98339CF; Sat, 25 May 2013 23:34:29 +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: <20130521061604.16833.88106.idtracker@ietfa.amsl.com> Date: Sat, 25 May 2013 23:34:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7FD0D21A-CFAB-4BAA-B1AD-667BD05F6EE2@tzi.org> References: <20130521061604.16833.88106.idtracker@ietfa.amsl.com> To: "Spencer Dawkins" 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] Spencer Dawkins' Yes on draft-ietf-core-coap-16: (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: Sat, 25 May 2013 21:34:43 -0000 Hi Spencer, thank you for clearing your DISCUSS early. The chart looks much more hope-inspiring with only four DISCUSSes :-) I believe your remaining comments are covered by the changesets 1393 to = 1396 (which will turn up in -17 soon); with maybe one exception: On May 21, 2013, at 08:16, "Spencer Dawkins" = wrote: >>=20 >> This is trying to say that the peer has to be able to cope with the >> "MAY"-type behaviour described, so it does affect interoperability = and >> I think 2119 language is appropriate here. >=20 > I understand why you're using 2119 language now. I'm not sure I > understand how the requirement for the peer is different from either = the > request or response getting lost. The main difference is that retransmission/saturation is a good strategy = against random packet loss, but not against willful disregard. So it is important to point out this = expected behavior. Gr=FC=DFe, Carsten From spencer@wonderhamster.org Sat May 25 16:19: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 AB46D21F87CD; Sat, 25 May 2013 16:19:32 -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 E3efEkwAxHkW; Sat, 25 May 2013 16:19:26 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id BE19E21F87CB; Sat, 25 May 2013 16:19:26 -0700 (PDT) Received: from [192.168.1.74] (99-108-174-213.lightspeed.rcsntx.sbcglobal.net [99.108.174.213]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MVw6S-1UvlvI3Vs0-00XMVY; Sat, 25 May 2013 19:19:14 -0400 Message-ID: <51A146F1.2090504@wonderhamster.org> Date: Sat, 25 May 2013 18:19:13 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Carsten Bormann References: <20130521061604.16833.88106.idtracker@ietfa.amsl.com> <7FD0D21A-CFAB-4BAA-B1AD-667BD05F6EE2@tzi.org> In-Reply-To: <7FD0D21A-CFAB-4BAA-B1AD-667BD05F6EE2@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:SmAGcHJNMEUHhLEwVGKwLl+AalNkLGj5WRuLlX46lBL V1BGykxaYre19M8mT2lcdZ15ZU+l+a9lu69TgPM0DAFmzzAr02 JIGTrxZwTyXeHTXH21V/OnUGxutsaKEduDlIo77YlVquaCRjpQ q2/YvjHArJO2z04P/s+ojs30sTS/BJSvnWf2EDbZxTtz3tJRc8 4eu3BxvaTQANWgnHa7jWov+K5y8L8ucGeNvDexspnnWsl8I+BB ByCuVH5gMjvt8exGPVLXnx2dh7ZIGl1Hq+Mreer7tr8JCf3hIX bs6F9qowCeSsa6O2pw2V3xFSG0NCKO0W399kDh5RiMc1PLBrh+ KTSdZj1vUwaFyGaf4oPvX0rROdXul+Euh5tisBV2P Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, The IESG , core@ietf.org Subject: Re: [core] Spencer Dawkins' Yes on draft-ietf-core-coap-16: (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: Sat, 25 May 2013 23:19:32 -0000 On 5/25/2013 4:34 PM, Carsten Bormann wrote: Notice: you're deep into AD Education Mode, and I've already balloted YES, and I'm not planning to be That Guy who ballots a second DISCUSS on a document from his first telechat as an AD :p But let's assume that you're still reading ... >>> This is trying to say that the peer has to be able to cope with the >>> "MAY"-type behaviour described, so it does affect interoperability and >>> I think 2119 language is appropriate here. >> >> I understand why you're using 2119 language now. I'm not sure I >> understand how the requirement for the peer is different from either the >> request or response getting lost. > > The main difference is that retransmission/saturation is a good strategy against random packet loss, but not > against willful disregard. So it is important to point out this expected behavior. OK, that helps. I may not be asking my question in a helpful way. Let me try again - Is the peer expected to deal with random packet loss (whether lost requests or lost responses), and expected to deal with a server who (MAY) ignores a request? What does the peer see, if the server decides to (MAY) ignore the request (because it came in as multicast, if I'm understanding correctly), that's different from random packet loss? If the peer sees something different, what the document is saying makes sense. If the peer doesn't see something different, I'm not understanding what's going on. Is that clearer? Thanks, Spencer From cabo@tzi.org Sun May 26 11:48: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 5FA2621F8EFE; Sun, 26 May 2013 11:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.22 X-Spam-Level: X-Spam-Status: No, score=-106.22 tagged_above=-999 required=5 tests=[AWL=0.029, 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 3B4welibniu0; Sun, 26 May 2013 11:48:36 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC8621F8EEC; Sun, 26 May 2013 11:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r4QImNY3000107; Sun, 26 May 2013 20:48:23 +0200 (CEST) Received: from [192.168.217.105] (p548947FC.dip0.t-ipconnect.de [84.137.71.252]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7DC143B96; Sun, 26 May 2013 20:48: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: <51A146F1.2090504@wonderhamster.org> Date: Sun, 26 May 2013 20:48:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8CDAA36E-3C50-4BF8-9FE5-4715B227CCE1@tzi.org> References: <20130521061604.16833.88106.idtracker@ietfa.amsl.com> <7FD0D21A-CFAB-4BAA-B1AD-667BD05F6EE2@tzi.org> <51A146F1.2090504@wonderhamster.org> To: Spencer Dawkins 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] Spencer Dawkins' Yes on draft-ietf-core-coap-16: (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: Sun, 26 May 2013 18:48:42 -0000 On May 26, 2013, at 01:19, Spencer Dawkins = wrote: > On 5/25/2013 4:34 PM, Carsten Bormann wrote: >=20 > Notice: you're deep into AD Education Mode, and I've already balloted = YES, and I'm not planning to be That Guy who ballots a second DISCUSS on = a document from his first telechat as an AD :p >=20 > But let's assume that you're still reading ... >=20 >>>> This is trying to say that the peer has to be able to cope with the >>>> "MAY"-type behaviour described, so it does affect interoperability = and >>>> I think 2119 language is appropriate here. >>>=20 >>> I understand why you're using 2119 language now. I'm not sure I >>> understand how the requirement for the peer is different from either = the >>> request or response getting lost. >>=20 >> The main difference is that retransmission/saturation is a good = strategy against random packet loss, but not >> against willful disregard. So it is important to point out this = expected behavior. >=20 > OK, that helps. >=20 > I may not be asking my question in a helpful way. Let me try again - >=20 > Is the peer expected to deal with random packet loss (whether lost = requests or lost responses), and expected to deal with a server who = (MAY) ignores a request? Yes, yes. "deal with" is maybe a bit ambiguous. The client is likely to factor in the random packet loss by repeating = the request, either regularly (say, every 30 minutes) or, if filling in = the gaps needs to be quicker, as a short saturation burst (at 1 byte/s). The client needs to factor in the refusal to answer by asking questions = that servers do want to answer. Completely different strategy. > What does the peer see, if the server decides to (MAY) ignore the = request (because it came in as multicast, if I'm understanding = correctly), that's different from random packet loss? For random loss, the client may see 1 answer for 3 requests. For = refusal, it won't see anything. For a new request, the client will likely not know about the servers = that don't answer, so it can't see a difference. Hence repetition/saturation. (If it does know about a server, it is much better off to address it via = unicast.) > If the peer sees something different, what the document is saying = makes sense. If the peer doesn't see something different, I'm not = understanding what's going on. The likelihood of seeing all servers that do answer goes to 1 = asymptotically with continued repetition (unless there are systematic = losses, which I hope is not a property of the multicast distribution = system). The likelihood of seeing a server that just doesn't answer = stays at 0. Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Sun May 26 12:21: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 A1D3D21F89EB for ; Sun, 26 May 2013 12:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 uubAWarjGrWk for ; Sun, 26 May 2013 12:21: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 151F321F89D5 for ; Sun, 26 May 2013 12:21:34 -0700 (PDT) Received: from localhost ([127.0.0.1]:57575 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UggVZ-00045O-5r; Sun, 26 May 2013 21:21: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: Sun, 26 May 2013 19:21:33 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/327#comment:1 Message-ID: <066.751a0bdfa3cdec0f40e15648d6a6f665@trac.tools.ietf.org> References: <051.0f1d7cc7afdf750452ef5f5ee29513a1@trac.tools.ietf.org> X-Trac-Ticket-ID: 327 In-Reply-To: <051.0f1d7cc7afdf750452ef5f5ee29513a1@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: <20130526192135.151F321F89D5@ietfa.amsl.com> Resent-Date: Sun, 26 May 2013 12:21:34 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #327: Discuss processing of ICMP errors 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, 26 May 2013 19:21:35 -0000 #327: Discuss processing of ICMP errors Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1397]: Fix #327 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: other | Status: closed technical | Milestone: post-WGLC-1 Priority: minor | Version: coap-16 Component: coap | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Sun May 26 13:25: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 DF86221F95F9 for ; Sun, 26 May 2013 13:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwTPHvcbFv2u for ; Sun, 26 May 2013 13:25:37 -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 4A2DE21F95EF for ; Sun, 26 May 2013 13:25:37 -0700 (PDT) Received: from localhost ([127.0.0.1]:34065 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UghVC-0004L9-0i; Sun, 26 May 2013 22:25: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, zach@sensinode.com, hauke@hauke-m.de, kovatsch@inf.ethz.ch X-Trac-Project: core Date: Sun, 26 May 2013 20:25:13 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/325#comment:5 Message-ID: <066.8f308768dc31c4b6e837e50b787dd4b7@trac.tools.ietf.org> References: <051.fb27520c8fa2e3ba5cf748888757b052@trac.tools.ietf.org> X-Trac-Ticket-ID: 325 In-Reply-To: <051.fb27520c8fa2e3ba5cf748888757b052@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, zach@sensinode.com, hauke@hauke-m.de, kovatsch@inf.ethz.ch, 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: <20130526202537.4A2DE21F95EF@ietfa.amsl.com> Resent-Date: Sun, 26 May 2013 13:25:37 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #325: Define curve for keys and certs 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, 26 May 2013 20:25:38 -0000 #325: Define curve for keys and certs Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1398]: Fix #325 -- -------------------------+------------------------------------------------- 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-16 Component: coap | Resolution: fixed Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From internet-drafts@ietf.org Sun May 26 13:31: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 D91CC21F91A5; Sun, 26 May 2013 13:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.079, 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 ixOsflnUhUV8; Sun, 26 May 2013 13:31:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B290B21F9603; Sun, 26 May 2013 13:31:29 -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.50 Message-ID: <20130526203129.4649.99291.idtracker@ietfa.amsl.com> Date: Sun, 26 May 2013 13:31:29 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-17.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, 26 May 2013 20:31:31 -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-17.txt Pages : 119 Date : 2013-05-26 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 is designed to easily interface 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-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-coap-17 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun May 26 13:31: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 4890921F9600 for ; Sun, 26 May 2013 13:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.076, 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 avF1CkJFIWTS; Sun, 26 May 2013 13:31:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDCB21F9610; Sun, 26 May 2013 13:31:29 -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, presnick@qti.qualcomm.com, stephen.farrell@cs.tcd.ie, martin.stiemerling@neclab.eu, turners@ieca.com X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130526203129.4649.1199.idtracker@ietfa.amsl.com> Date: Sun, 26 May 2013 13:31:29 -0700 Subject: [core] New Version Notification - draft-ietf-core-coap-17.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, 26 May 2013 20:31:31 -0000 A new version (-17) has been submitted for draft-ietf-core-coap: http://www.ietf.org/internet-drafts/draft-ietf-core-coap-17.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-17 IETF Secretariat. From cabo@tzi.org Sun May 26 13:46: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 0B83921F9610 for ; Sun, 26 May 2013 13:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.995 X-Spam-Level: X-Spam-Status: No, score=-105.995 tagged_above=-999 required=5 tests=[AWL=-0.198, 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 Hx9zmrigP+Q1 for ; Sun, 26 May 2013 13:46:24 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4562F21F960C for ; Sun, 26 May 2013 13:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r4QKjc9Y024783; Sun, 26 May 2013 22:45:38 +0200 (CEST) Received: from [192.168.217.105] (p548947FC.dip0.t-ipconnect.de [84.137.71.252]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 19F4E3BD3; Sun, 26 May 2013 22:45: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: <20130526203129.4649.1199.idtracker@ietfa.amsl.com> Date: Sun, 26 May 2013 22:45:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3FC7E365-98FF-4E34-BF5D-535FCA8F9070@tzi.org> References: <20130526203129.4649.1199.idtracker@ietfa.amsl.com> To: "core@ietf.org (core@ietf.org)" X-Mailer: Apple Mail (2.1503) Cc: core-chairs@tools.ietf.org, presnick@qti.qualcomm.com, draft-ietf-core-coap@tools.ietf.org, turners@ieca.com, "barryleiba@computer.org Leiba" Subject: [core] =?utf-8?q?=F0=9F=94=94_New_Version_-_draft-ietf-core-coap-?= =?utf-8?q?17=2Etxt?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 26 May 2013 20:46:30 -0000 With the final ticket resulting from the IESG DISCUSS positions, #325, = closed in the WG's SVN repository, I have submitted = draft-ietf-core-coap-17 today. There haven't been breaking changes since coap-13 half a year ago, but = there have been a lot of clarifications, and we have nailed down a = number of important choices such as focusing in on secp256r1 with #325. = I can understand that the WG is wearing out a bit given the level of = detail we are working at, but this is an important phase in the = completion of a high-quality document. There is hope: The shape of the dots on the i's is approaching ASME = Y14.5 levels of roundness, and we should be close to clearing the IESG = discusses. Gr=FC=DFe, Carsten From stephen.farrell@cs.tcd.ie Sun May 26 13:54: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 34E2C21F9600; Sun, 26 May 2013 13:54:36 -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 ZYbrcqvR8dja; Sun, 26 May 2013 13:54:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E671721F8B04; Sun, 26 May 2013 13:54:30 -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.50 Message-ID: <20130526205430.21154.61294.idtracker@ietfa.amsl.com> Date: Sun, 26 May 2013 13:54:30 -0700 Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, core@ietf.org Subject: [core] Stephen Farrell's Yes on draft-ietf-core-coap-17: (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: Sun, 26 May 2013 20:54:36 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-core-coap-17: 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: ---------------------------------------------------------------------- Thanks for addressing my discuss points. I've left the comments in below from last time, but didn't check 'em against -17. --- former discuss points (1) I think you made a change to 5.6 for this but I still think (now at COMMENT level) that it'd be really good to say that CoAP is currently well defined only for URI schemes like coap(s) and http(s) but maybe not others. Basically, you need a scheme://host:port syntax or else you have to do some more specification work to get CoAP interop. (3) You now say "SHOULD use 32 bits of randomness" which is ok. I think it might be worth adding that CoAP nodes that might be targetted with many guesses SHOULD also = detect and react to that. Text of discuss (3) was: 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. This is no longer a DISCUSS because you said that the WG figure its ok and given you say to randomise at the start (of what?) then its marginal. = --- old comments below, sorta checked against -16 = intro, 2nd para: better to not talk about the WG name and its work really, but about the resulting protocol intro, last para: more sales pitch language 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. - I think in a mail Carsten said its 250/second max or = something, I still think this'd be great information to say explicitly early on in the spec since it might prevent someone spending a lot of effort before they find out that CoAP doesn't work for their use-case. 7.1 - what if I want to only do discovery via DTLS? What does "support" mean for port 5683 then? Carsten said that you do need to still listen on 5683 even if you only want to do work on . I'm not so happy about that but its not DISCUSS level. 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? Carsten responded: "yep, that's what we want" and I'm ok with that, if not convinced. From spencer@wonderhamster.org Sun May 26 15:13: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 5880B21F94CC; Sun, 26 May 2013 15:13:08 -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 eKEoUr99J6wH; Sun, 26 May 2013 15:13:02 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 74A9721F942B; Sun, 26 May 2013 15:13:02 -0700 (PDT) Received: from [192.168.1.74] (99-108-174-213.lightspeed.rcsntx.sbcglobal.net [99.108.174.213]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0Ljr9d-1U9rKp24Mr-00c6Fk; Sun, 26 May 2013 18:12:52 -0400 Message-ID: <51A288E2.8040502@wonderhamster.org> Date: Sun, 26 May 2013 17:12:50 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Carsten Bormann References: <20130521061604.16833.88106.idtracker@ietfa.amsl.com> <7FD0D21A-CFAB-4BAA-B1AD-667BD05F6EE2@tzi.org> <51A146F1.2090504@wonderhamster.org> <8CDAA36E-3C50-4BF8-9FE5-4715B227CCE1@tzi.org> In-Reply-To: <8CDAA36E-3C50-4BF8-9FE5-4715B227CCE1@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:7olyr025h5jRsD9dAyR69Yb3BasczstK3n4tCwvnSuz hFQabd5FjbIK/1p31so5qfvk/7dlkUt6A+hmhTZBYZwVWjvJl+ WIT3dfB4wrnB36wPZzCDhc0j2J14N1wKhvhD1SjOoHeEBcG8fs Biw0Zg3pdOBq9j6sLNPq46XV3Hg44kEB4v3Z9yUe1RHxGgUXF9 lA3tTKFlMXg8iODSGFe4a7LO5wq6u92yxQSPFlKRyELCcQrXGG M3u7tRoSYI20fInlT+xe+xR0eQpydbPnkKP+0M1/kQxNeEPpst hMfcqvM80QsnmWQHW20Xjm0CJf52QXtN5q+8Lzeb3hlU9lybde UVSOSjoVR5BmHxVIjEJG7DDHafITExD8ZeOpICwds Cc: draft-ietf-core-coap@tools.ietf.org, core-chairs@tools.ietf.org, The IESG , core@ietf.org Subject: Re: [core] Spencer Dawkins' Yes on draft-ietf-core-coap-16: (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: Sun, 26 May 2013 22:13:08 -0000 On 5/26/2013 1:48 PM, Carsten Bormann wrote: > (If it does know about a server, it is much better off to address it via unicast.) I finally managed to ask a question that resulted in this answer :-) Makes perfect sense. No action required on this one. Spencer From zach@sensinode.com Mon May 27 00:14: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 EB4A221F9375 for ; Mon, 27 May 2013 00:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myK1Vf2AHwtB for ; Mon, 27 May 2013 00:14:13 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 644DC21F93E0 for ; Mon, 27 May 2013 00:14:11 -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 r4R7E8rU022504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 May 2013 10:14:09 +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: <519F9464.6010704@intec.ugent.be> Date: Mon, 27 May 2013 10:14:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <747155C4-794D-4A58-9750-AE27BB7BEA77@sensinode.com> References: <9B18C869-84FE-49E3-B1BF-31886A7922FF@sensinode.com> <519F9464.6010704@intec.ugent.be> To: Floris Van den Abeele X-Mailer: Apple Mail (2.1503) Cc: core@ietf.org Subject: Re: [core] draft-shelby-core-interfaces: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 27 May 2013 07:14:17 -0000 Floris, On May 24, 2013, at 7:25 PM, Floris Van den Abeele = wrote: > Hi Zach & all, >=20 > It seems to me that the approach in the interfaces draft limits the = values that a REST resource will actually publish to the 'entire world'? = Say that 2 clients want to observe the same resource with different = conditions, with the current approach this isn't possible. A = 'REST-compatible way' to solve this (there might be other, better ideas) = could be to create a new temporary (sub)resource (e.g. /temp/1, /temp/2) = in response to the PUT requests for every client and let the client = observe the 'tailor-made' sub-resource. Whether this is feasible for = constrained devices, I am unsure. Are you using more than 1 client in = your deployments? Yes, I do agree this is an improvement we need to document for this = design. For many contained devices, I would expect that the values from = multiple clients are aggregated so that multiple sets of state are not = needed. For more capable nodes, we could do what you propose above or = just let the server hold multiple sets of resources, one for each = endpoint. For example in the OMA Lightweight M2M standard we are using = multiple subscribing clients and the approach is the second one. > Another critique that I wanted to make is that there might be overlap = with the URI-query parameters the resource itself actually wants to use = (related to me reply to your point #3). Sure, but CoRE Interfaces defines the REST interface already for = sensors, parameters and actuators, and these query parameters are part = of that interface. If you would want to apply these conditionals to a = different REST interface you could, but then they become part of that = REST interface. I don't really see an issue there as the inclusion of = those query parameters is explicit. > I was also wondering why the draft decided to move to a separate PUT = request for specifying the conditions? Why didn't you keep it in the = observe request as in previous versions? The above suggestion could = justify the separate request, although a POST instead of a PUT request = would be better suited here. This was actually a decision made due to a problem pointed out by the = working group. The old design where the query string was included with = the Observe GET was incompatible with Caching, as the URI of the Observe = GET defines the cache entry. This is a non-starter as Observe is very = useful for maintaining Cache entries.=20 The ability to handle separate sets of conditionals for clients is a = nice bonus, and sure, we might evolve the interface to make use of POST = for that purpose.=20 This is exactly the point of making this a WG document, then we can = evolve the document together as a WG. The whole point of CoRE Interfaces = is to give good guidance and a starting place for REST interfaces over = CoAP (sure, and HTTP) that can be used as-is or re-used and extended. Thanks, Zach >=20 > Cheers, > Floris >=20 > Op 24-05-13 11:43, Zach Shelby schreef: >> Hi Shitao, >>=20 >> Thanks for the feedback, I am aware of the work on using options for = this purpose. >>=20 >> However, there are several reasons why I do believe the URI is the = correct place for this, and that we should definitely include this = feature in CoRE interfaces. >>=20 >> 1. The Origin Server and the Resource, should be in control over any = semantics regarding the resource representation. Working with parameters = that affect the representation of the resource, MUST be handled as part = of the REST interface. Confusing that into the CoAP options, which = should be agnostic to what is inside the resource representation, would = be the wrong thing to do. What happens if e.g. your resource = representation is a more complex JSON object - how are you going to work = on thresholds with CoAP options then? > The logic to filter a more complex JSON object according to a = URI-query option or an other option (like the Condition option) would be = exactly the same in both casing; I'm afraid I'm missing the latter = point. In the conditional observe draft the representation of the = resource is actually only altered on a per-client basis; so if you would = observe the resource with a different source endpoint you would still = see that the resource's representation isn't limited to what the = conditions specify. Only the notifications that are sent to the client = are filtered according to the conditions. >>=20 >> 2. Other standards, e.g. OMA LWM2M are already using this same URI = attribute model for controlling observations. It would be best that we = try to align multiple standards using CoAP to do this in the same way = where possible. > I agree that it would be best to keep standards aligned where = possible. Would you mind sending the specific OMA standard to me = (off-list)? So far I have only found the 'LWM2M-4 Information Reporting' = interface. >> 3. You are not going to have a one-size-fits-all with observations = conditionals, doing this through REST allows us to provide at least one = standard model. But it also allows implementations to evolve the REST = interface as needed. Just because we have a REST design that *can* be = used for controlling conditionals on resource types defined in CoRE = Interfaces, it does not mean that is the only way to do it. Other = resource types could inherit or extend this model, and others could do = something different. > One of the goals of the conditional observe draft is to avoid ending = up with a plethora of incompatible/non-interoperable conditions. = Although this discussion isn't related to using CoAP options vs URI = queries for condition signalling; I think that we as a WG should try to = define a set of 'common' conditions and refer readers of the interfaces = draft to this documentation. >=20 > In light of these points, I would say that the section could still use = some additional work/refining. It isn't substantial enough for me to = block WG adoption though; so +1 for WG adoptation. >> 4. Finally, CoRE is about constrained RESTful environments, not just = CoAP. Both the Resource Directory and CoRE Interfaces drafts are mostly = usable over HTTP as well, as we want to have people in IoT doing things = in the same way, also when HTTP is useful. By designing these generic = interfaces using REST, that allows this re-use. > I agree. Although some mechanisms like observe and block divert from = this principle, so at a minimum I find it difficult where to draw the = line. >> Now, that is not exclusive of someone using CoAP options to control = observe conditionals, however a lot more thought would need to go into = that. At least for me there are plenty of unanswered questions to that = approach. >>=20 >> Zach >>=20 >> On May 24, 2013, at 12:27 PM, Lishitao wrote: >>=20 >>> First, I would like to say, this is a useful draft. It really gives = some help and guidance when implementing M2M applications in the real = world. >>>=20 >>> But, I have concerns about section 5.9 "Resource Observation = Attributes" in the interface draft. >>>=20 >>> I believe the best solution to express the observation condition is = to use options, instead of using query parameters contained in the URI. >>>=20 >>> See the following draft for the detailed solution: >>> http://tools.ietf.org/id/draft-li-core-conditional-observe-03.txt >>>=20 >>> I remember that we discussed this before in PairsF2F meeting, and = there was no conclusion yet. >>> http://www.ietf.org/proceedings/83/minutes/minutes-83-core.txt >>>=20 >>> And I think more discussion is needed for this feature. And I hope = we can move this section out before accepting it as WG draft. >>>=20 >>> Note that the authors currently updating the draft and will upload = it very soon. >>>=20 >>> Regards >>> Shitao >>>=20 >>>> -----Original Message----- >>>> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On = Behalf Of >>>> peter van der Stok >>>> Sent: Tuesday, May 21, 2013 2:38 PM >>>> To: core@ietf.org >>>> Subject: Re: [core] draft-shelby-core-interfaces: call for adoption >>>>=20 >>>> +1 >>>>=20 >>>> However, the scope and purpose of the document should be a bit = clearer. >>>> I see it as a base document that can be referred to by other = documents >>>> that provide additional coap based services. >>>>=20 >>>> Having only ONE protocol with related security handling for many = coap >>>> based services can be beneficial for the total amount of code in = the >>>> coap based nodes. >>>>=20 >>>> Peter van der Stok >>>>=20 >>>> Rahman, Akbar schreef op 2013-05-21 05:50: >>>>> +1 >>>>>=20 >>>>> Akbar >>>>>=20 >>>>> FROM: core-bounces@ietf.org [mailto:core-bounces@ietf.org] ON = BEHALF >>>>> OF Andrew Mcgregor >>>>> SENT: Monday, May 20, 2013 8:29 PM >>>>> TO: core@ietf.org >>>>> SUBJECT: [core] draft-shelby-core-interfaces: call for adoption >>>>>=20 >>>>> Consensus of the room in Orlando was to adopt >>>>> draft-shelby-core-interfaces as a working group document. This = email >>>>> is a call for confirmation of that consensus. Please respond if = you >>>>> support the adoption of this document. >>>>>=20 >>>>> Since REST is not yet in wide use in the microcontroller = community, >>>>> documenting some examples of good CoAP design will be beneficial. = In >>>>> particular, it is not widely understood how to map certain = concepts >>>>> such as batching or binding to REST. We don't have an explicit >>>>> charter item for documenting this, but it is natural to have >>>>> explanatory material with the base specification. (LWIG is not the >>>>> right group for this as this is not about protocol implementation, = but >>>>> about design of REST interfaces.) >>>>>=20 >>>>> * Dec 2013 Submission to IESG of "CoRE Interfaces" for = Informational >>>>>=20 >>>>> (Again, the objective is to provide examples of good usage for >>>>> implementers, not to standardize or even give strong = recommendations.) >>>>>=20 >>>>> Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From zach@sensinode.com Mon May 27 00:31: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 6A25121F8B45 for ; Mon, 27 May 2013 00:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 OM0sZCPPdj6h for ; Mon, 27 May 2013 00:31:13 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id CC8F121F84CD for ; Mon, 27 May 2013 00:31:12 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r4R7VAf6027386 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 May 2013 10:31:11 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514EE7819@MBX20.d.ethz.ch> Date: Mon, 27 May 2013 10:26:10 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130225221311.17677.1216.idtracker@ietfa.amsl.com> <4E6A77E7-7F78-41B5-BE13-A261D6EA836C@sensinode.com> <55877B3AFB359744BA0F2140E36F52B514EE7819@MBX20.d.ethz.ch> To: Kovatsch Matthias X-Mailer: Apple Mail (2.1503) Cc: "core@ietf.org WG" Subject: Re: [core] New Version Notification for draft-shelby-core-resource-directory-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 07:31:20 -0000 Hi Matthias, On May 22, 2013, at 4:44 PM, Kovatsch Matthias = wrote: > Dear Zach, > dear list >=20 > I was looking at the draft to clean up the experimental implementation = included in Californium. Thereby I stumbled over the following things: >=20 > 4. Simple Directory Discovery: > I think it should be clearer that POSTed links do not end up in the = RD's /.well-known/core resource as absolute URIs. Giving a Location in = the 2.01 Created response should fix that. Some reference to the = lifetime of the RD entry and the possibility of periodic validation = might be useful here. Yes, let's do that.=20 > 5.1. Discovery: > The IP part overlaps with "4.1. Finding a Directory Server." Maybe = this can be separated into a common section before the simple and = function set RD. > "discovering the RD using the CoRE Link Format (also see Section 4.1)" = is also a bit confusing. I guess this is referring to multicast = discovery, so this should be mentioned directly (possibly in this new = section mentioned above). Agreed. We added the simple discovery afterwards when merging in = Carsten's draft. The integration could definitely be better. > 5. Resource Directory Function Set: > I was wondering what should happen when someone performs a GET on the = EP location, e.g., GET /rd/4521. > Can we provide something useful there? Otherwise the document should = hint that GET should be disallowed in this context. Should be disallowed.=20 > 7. RD Lookup Function Set: > The link in the responses to the domain lookup feels odd. Or = maybe it is artificially pressing the domain list into the Link = Format... > I would at least expect links to the rd-lookup where the domain = information can be used (analogous to a ct attribute where the requester = can also pick from a list): >=20 > ;d=3D"domain1 domain2" OK, let's look at this and other ways to improve that. > Should "d" and the other attributes (ep, gp) be proper = link-extensions? I guess we have to, if we want application/link-format = to define the RESTful interaction including the filtering with = attributes. > How does "gp" relate to draft-ietf-core-groupcomm? Yes, all those parameters need to be registered. However, we are missing = a registry :-/ Someone needs to write an App Area proposal to make an = Web Linking attribute registry as that is a more general IETF thing.=20 For registration (and lookup) parameters we should define our own = registry.=20 > 9. Security Considerations: > A forward reference or the mentioning of access control should already = be provided in the function set definitions. These random numbers under = /rd/ lured me into thinking of them as access tokens. But they are quite = bad for this purpose=85 Oh no, they are not access tokens for sure. That just gives the RD the = freedom to organise its internal storage as it liked. What the RD = returns as the Location: is really up to the RD.=20 > General: > The sub-resources of rd-lookup defined by a URI Template somehow = conflict with my current understanding of REST. (Sorry for bringing up = this topic again...) > ./res, ./ep, and ./d are never linked from anywhere and cannot be = discovered. So it is a classic service coupling. Should we just live = with that or can we fix this somehow, e.g., with separate rt attributes = and entries in /.well-known/core? Let's think about that, I am flexible regarding this one. =20 > Otherwise the RD is quite nicely built around the CoRE Link Format = media type. Thanks for the implementation-oriented review, much appreciated! Looks = like this would give us our first set of Tickets as a WG document :-)=20 Zach >=20 > Ciao > Matthias >=20 >=20 >> -----Original Message----- >> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf = Of >> Zach Shelby >> Sent: Monday, February 25, 2013 23:17 >> To: core@ietf.org WG >> Subject: [core] Fwd: New Version Notification for draft-shelby-core- >> resource-directory-05.txt >>=20 >> I have posted a new version of the RD draft, now including group = support, >> alignment with the OMA Lightweight M2M standards work and improved >> interfaces. Thanks to Esko and Peter for help with the group support. >>=20 >> Regards, >> Zach >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for >>> draft-shelby-core-resource-directory-05.txt >>> Date: February 25, 2013 11:13:11 PM GMT+01:00 >>> To: zach@sensinode.com >>> Cc: srdjan.krco@ericsson.com, cabo@tzi.org >>>=20 >>>=20 >>> A new version of I-D, draft-shelby-core-resource-directory-05.txt >>> has been successfully submitted by Zach Shelby and posted to the = IETF >>> repository. >>>=20 >>> Filename: draft-shelby-core-resource-directory >>> Revision: 05 >>> Title: CoRE Resource Directory >>> Creation date: 2013-02-25 >>> Group: Individual Submission >>> Number of pages: 27 >>> URL: = http://www.ietf.org/internet-drafts/draft-shelby-core- >> resource-directory-05.txt >>> Status: = http://datatracker.ietf.org/doc/draft-shelby-core-resource- >> directory >>> Htmlized: = http://tools.ietf.org/html/draft-shelby-core-resource- >> directory-05 >>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-shelby-core-resource- >> directory-05 >>>=20 >>> Abstract: >>> In many M2M applications, direct discovery of resources is not >>> practical due to sleeping nodes, disperse networks, or networks = where >>> multicast traffic is inefficient. These problems can be solved by >>> employing an entity called a Resource Directory (RD), which hosts >>> descriptions of resources held on other servers, allowing lookups = to >>> be performed for those resources. This document specifies the web >>> interfaces that a Resource Directory supports in order for web >>> servers to discover the RD and to register, maintain, lookup and >>> remove resources descriptions. Furthermore, new link attributes >>> useful in conjunction with an RD are defined. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>>=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 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From zach@sensinode.com Mon May 27 00:51: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 D9F2221F8B60 for ; Mon, 27 May 2013 00:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 y-tBDdtEVUOH for ; Mon, 27 May 2013 00:51:09 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC6321F87D1 for ; Mon, 27 May 2013 00:51:08 -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 r4R7ocxI000838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 May 2013 10:50:39 +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: Mon, 27 May 2013 10:50:39 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B18C869-84FE-49E3-B1BF-31886A7922FF@sensinode.com> To: Lishitao X-Mailer: Apple Mail (2.1503) Cc: "core@ietf.org" Subject: Re: [core] draft-shelby-core-interfaces: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 27 May 2013 07:51:14 -0000 Hi Shitao, We can just leave the WG to decide if they find a REST interface for = conditionals useful as guidance, if enough people find it useful, then = we should leave it in. The authors added it in the first place simply = because we were asked to. I take it you don't find it useful, that is = fine.=20 I am seeing lots of people doing this already using REST. Giving = developers advice as to a workable model for doing that would be useful = for the community in general, and I think that is the purpose of CoRE = Interfaces. For example the Cache issue is something easy to overlook = without some advice. On May 25, 2013, at 4:55 AM, Lishitao wrote: >> 1. The Origin Server and the Resource, should be in control over any = semantics >> regarding the resource representation. Working with parameters that = affect >> the representation of the resource, MUST be handled as part of the = REST >> interface. Confusing that into the CoAP options, which should be = agnostic to >> what is inside the resource representation, would be the wrong thing = to do. >> What happens if e.g. your resource representation is a more complex = JSON >> object - how are you going to work on thresholds with CoAP options = then? >>=20 > I am not quite understand about this, if the resource represents using = JSON instead of link format, the client just needs to understand=20 > about the JSON format before sending any request. It is not a problem = only for observe.=20 >=20 > And since the JSON object for resource representation is still under = working, it needs a way to solve this problem if it has. I am referring to the Media Type of the resource representations = returned by an Observable resource. The REST conditionals work because = we know exactly what the Media Type is (text/plain), because it is = defined as part of the REST interfaces in the draft. We are also able to = make use of SenML as a batch format as the conditionals are per = sub-resource, and not linked with the Observe GET. This just won't work with CoAP Options. You have no control over what = the Media Type is. The resource could return EXI, some specialised = binary data, JSON or anything. The only thing you can practically do = with a CoAP Option here is to control periodicity, which is not linked = with resource representations.=20 >> 2. Other standards, e.g. OMA LWM2M are already using this same URI >> attribute model for controlling observations. It would be best that = we try to >> align multiple standards using CoAP to do this in the same way where = possible. >>=20 > I think OMA LWM2M just defines the requirements and its structure. The = detail about how to use coap is out of scope.=20 That standard defines the complete REST interface using CoAP between a = device and a service. And it uses the CoRE Interfaces model for REST = based observe conditionals.=20 >> 3. You are not going to have a one-size-fits-all with observations = conditionals, >> doing this through REST allows us to provide at least one standard = model. But it >> also allows implementations to evolve the REST interface as needed. = Just >> because we have a REST design that *can* be used for controlling = conditionals >> on resource types defined in CoRE Interfaces, it does not mean that = is the only >> way to do it. Other resource types could inherit or extend this = model, and >> others could do something different. >=20 > Yes, using option is one of the possible solution, and can solve most = of the problems, URI-query also has its limits. >=20 >> 4. Finally, CoRE is about constrained RESTful environments, not just = CoAP. Both >> the Resource Directory and CoRE Interfaces drafts are mostly usable = over >> HTTP as well, as we want to have people in IoT doing things in the = same way, >> also when HTTP is useful. By designing these generic interfaces using = REST, >> that allows this re-use. >>=20 >=20 > HTTP does not has observe mechanism(something like HTTP streaming may = provide the almost same function, but not using the same mechanism), > So I don't think that is a problem, anyway you need a way for = interworking between coap and HTTP. Not all the HTTP staff can be used = in coap, and vice versa. Think about an HTTP-CoAP proxy. We are using these all the time to = access CoAP resources, and although HTTP does not have Observe, the = proxy may often use Observe to update the proxy. The nice thing about = the REST approach to conditionals is that it works transparently over = HTTP through the proxy. Thus an HTTP based client can fully configure = the observe behaviour of a CoAP resource.=20 Regards, Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From stokcons@xs4all.nl Mon May 27 05:11: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 770F621F9060 for ; Mon, 27 May 2013 05:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.474 X-Spam-Level: *** X-Spam-Status: No, score=3.474 tagged_above=-999 required=5 tests=[AWL=1.519, BAYES_20=-0.74, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_54=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 S7kNIb8mpz1U for ; Mon, 27 May 2013 05:11:03 -0700 (PDT) Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by ietfa.amsl.com (Postfix) with ESMTP id BB4A821F8C20 for ; Mon, 27 May 2013 05:11:02 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube10.xs4all.net [194.109.20.208]) by smtp-vbr1.xs4all.nl (8.13.8/8.13.8) with ESMTP id r4RCAvgw086583 for ; Mon, 27 May 2013 14:11:01 +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, 27 May 2013 14:10:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 27 May 2013 14:10:57 +0200 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: Message-ID: <9b18c865110682240b47c61ef7043334@xs4all.nl> X-Sender: stokcons@xs4all.nl (vu2i9bm44X+UrflfiW1Y87M+UTWBvQWH) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [core] core-interfaces-05 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, 27 May 2013 12:11:08 -0000 Hi Zach et al. Reading through the document I came up with two questions concerning the scope of the document. In the examples of section 5, the content formats are text and senml+json. Is that meant as a standardization restriction or are xml and exi also allowed as content formats? Some additional text or examples in xml may be welcome to get scope clearer. The subsections of section 5 treat the structuring of links in a list, batch and discuss binding tables. They concern the manipulation of the resource structure. However the subsections on actuator, RO parameter, parameter and sensor restrict the interfaces of the devices which are described (accessed). According to me that should be the subject of other documents which describe concrete Function sets for a given "standardized" set of devices. Appendix A is just fine for me because it makes earlier text more concrete and is tagged as example text. Greetings Peter -- Peter van der Stok mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 From jeroen.hoebeke@intec.ugent.be Mon May 27 07:45: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 180A821F9671 for ; Mon, 27 May 2013 07:45:30 -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 s2aJKH1tBRQO for ; Mon, 27 May 2013 07:45:23 -0700 (PDT) Received: from smtp2.ugent.be (smtp2.ugent.be [157.193.49.126]) by ietfa.amsl.com (Postfix) with ESMTP id ABA0021F938E for ; Mon, 27 May 2013 07:45:17 -0700 (PDT) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp2.ugent.be (Postfix) with ESMTP id 84FB412C42F; Mon, 27 May 2013 16:45:16 +0200 (CEST) X-Virus-Scanned: by UGent DICT Received: from smtp2.ugent.be ([157.193.49.126]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id jSwU376qZawd; Mon, 27 May 2013 16:45:16 +0200 (CEST) Received: from dhcp-zdpt-153.intec.ugent.be (dhcp-zdpt-153.intec.ugent.be [157.193.135.153]) (Authenticated sender: jjhoebek) by smtp2.ugent.be (Postfix) with ESMTPSA id 3FA4012C3F2; Mon, 27 May 2013 16:45:16 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=us-ascii From: Jeroen Hoebeke In-Reply-To: Date: Mon, 27 May 2013 16:45:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5FCD5B5A-FB40-4408-AF61-7464CA8825AC@intec.ugent.be> References: <9B18C869-84FE-49E3-B1BF-31886A7922FF@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1503) X-Miltered: at jchkm1 with ID 51A3717C.000 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 51A3717C.000 from dhcp-zdpt-153.intec.ugent.be/dhcp-zdpt-153.intec.ugent.be/157.193.135.153/dhcp-zdpt-153.intec.ugent.be/ X-j-chkmail-Score: MSGID : 51A3717C.000 on smtp2.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: "core@ietf.org" Subject: Re: [core] draft-shelby-core-interfaces: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 27 May 2013 14:45:30 -0000 Hi Zach, Thanks for the feedback. >>> 1. The Origin Server and the Resource, should be in control over any = semantics >>> regarding the resource representation. Working with parameters that = affect >>> the representation of the resource, MUST be handled as part of the = REST >>> interface. Conditional observe does not affect the representation of the resource, = it affects the notifications you receive (when, which). Of course, the = ability to conditionally observe a resource does depend on the = underlying data type (e.g. xsd:integer). How this data type is = represented does not matter. For every data type, you can think of several interesting conditions. It = would indeed be nice if this group can give guidance on how to provide = this conditional observe functionality in a resource agnostic way (be it = using a URI query or CoAP option) and with a scope that is broader than = what is in the current core-interfaces draft.=20 Based on our experience implementing and evaluation the conditional = observe draft, we can contribute to this discussion. For example, one = reason the conditional observed draft has chosen to use of a CoAP option = is that it overwrites default observe behaviour: - a client can select if notifications should be confirmable or not - if the resource state does not change and max-age expires, no = notification is sent. As a result, you only get the events of interest = (and not the notifications that would be needed in order to have = eventual consistency - especially not in case max-age is set to very low = values or even zero to disable caching). In that respect, the approach you have chosen is different. =20 Kind regards, Jeroen From internet-drafts@ietf.org Mon May 27 07:46: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 930BB21F8CEC; Mon, 27 May 2013 07:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.233, 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 t52k2m2bTeJ2; Mon, 27 May 2013 07:46:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D7221F9675; Mon, 27 May 2013 07:46:28 -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.50 Message-ID: <20130527144628.18867.54550.idtracker@ietfa.amsl.com> Date: Mon, 27 May 2013 07:46:28 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-08.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, 27 May 2013 14:46:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-08.txt Pages : 36 Date : 2013-05-27 Abstract: CoAP is a RESTful transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document provides guidance for how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Akbar.Rahman@InterDigital.com Mon May 27 07:56: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 BB27921F90FD for ; Mon, 27 May 2013 07:56:46 -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 n57wY9N3f4SS for ; Mon, 27 May 2013 07:56:41 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3516221F966B for ; Mon, 27 May 2013 07:56:28 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 May 2013 10:56:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 May 2013 10:56:26 -0400 Message-ID: In-Reply-To: <20130527144628.18867.54550.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] I-D Action: draft-ietf-core-groupcomm-08.txt Thread-Index: Ac5a6UwrxyHLmSZdT96eLrNync/O+wAAAuLQ References: <20130527144628.18867.54550.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: X-OriginalArrivalTime: 27 May 2013 14:56:26.0711 (UTC) FILETIME=[5CDC4670:01CE5AEA] Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-08.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, 27 May 2013 14:56:48 -0000 Hi All, Esko and I have updated the Groupcomm I-D to address the following based on mailing list discussions: Changes from ietf-07 to ietf-08: o Updated text in section 3.6 (Configuring Group Membership in Endpoints) to make it more explicit that the Internet Media Type is used in the processing rules (#299). o Addressed various comments from Peter van der Stok (#296). o Various editorial updates for improved readability including defining all acronyms. The authors to intend to do a final update by then end of this week based on: - Double checking the requirements language (#271) - Checking off line with Peter van der Stok that we have addressed all his comments (#296) Any comments in the meantime are of course welcomed! Best Regards, Akbar & Esko. -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, May 27, 2013 10:46 AM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-08.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-08.txt Pages : 36 Date : 2013-05-27 Abstract: CoAP is a RESTful transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document provides guidance for how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-08 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 trac+core@trac.tools.ietf.org Mon May 27 08:41: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 34D1F21F9682 for ; Mon, 27 May 2013 08:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.11 X-Spam-Level: X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVtuGbeXnEJT for ; Mon, 27 May 2013 08:41: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 5B1FC21F8CB4 for ; Mon, 27 May 2013 08:41:14 -0700 (PDT) Received: from localhost ([127.0.0.1]:58309 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UgzXq-00016l-8H; Mon, 27 May 2013 17:41: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-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 27 May 2013 15:41:09 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/299#comment:1 Message-ID: <075.9ac003172f4f6bca5d71dc3ad1ac4b40@trac.tools.ietf.org> References: <060.4297d5cdaa7cf5b347c3eb8fc5264bfe@trac.tools.ietf.org> X-Trac-Ticket-ID: 299 In-Reply-To: <060.4297d5cdaa7cf5b347c3eb8fc5264bfe@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: <20130527154115.5B1FC21F8CB4@ietfa.amsl.com> Resent-Date: Mon, 27 May 2013 08:41:14 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [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, 27 May 2013 15:41:17 -0000 #299: Introduce new hypermedia type / content-format for group management Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Done in groupcomm-08 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: closed enhancement | Milestone: Priority: major | Version: Component: groupcomm | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon May 27 08:45: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 ECB3B21F968F for ; Mon, 27 May 2013 08:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=0.745, 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 p+s8CK1iZhbR for ; Mon, 27 May 2013 08:45: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 0A72221F9671 for ; Mon, 27 May 2013 08:45:40 -0700 (PDT) Received: from localhost ([127.0.0.1]:58674 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Ugzc4-0002uv-Vq; Mon, 27 May 2013 17:45: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-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 27 May 2013 15:45:32 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/328 Message-ID: <060.e70219b6025ef24281c1ce1564b7cc54@trac.tools.ietf.org> X-Trac-Ticket-ID: 328 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: <20130527154540.0A72221F9671@ietfa.amsl.com> Resent-Date: Mon, 27 May 2013 08:45:40 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #328: Allow multicast POST under specific conditions 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, 27 May 2013 15:45:41 -0000 #328: Allow multicast POST under specific conditions Currently groupcomm-08 forbids use of multicast POST because it is a non- idempotent method used in an unreliable network situation without delivery guarantees. Text to be added that in specific conditions multicast POST would be allowed. Example text: “Group communication MAY be used for non-idempotent methods (i.e., CoAP POST) if the resource being POSTed is designed to support the lossy nature of multicast. This is because not all group members are guaranteed to receive the multicast request, and the sender cannot readily find out which group members did not receive it.†-- -------------------------+------------------------------------------------- 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 zach@sensinode.com Mon May 27 12:16: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 57ABD21F8EA4 for ; Mon, 27 May 2013 12:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0t0oiMrVIxi for ; Mon, 27 May 2013 12:16:11 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 39F7221F8EFE for ; Mon, 27 May 2013 12:16:11 -0700 (PDT) Received: from [10.37.49.6] ([77.95.242.69]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r4RJG6dx011348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 May 2013 22:16:07 +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: <9b18c865110682240b47c61ef7043334@xs4all.nl> Date: Mon, 27 May 2013 22:16:06 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <491EE379-DF50-46B9-9DE5-3E461FEDEEEF@sensinode.com> References: <9b18c865110682240b47c61ef7043334@xs4all.nl> To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.1503) Cc: Core Subject: Re: [core] core-interfaces-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 27 May 2013 19:16:15 -0000 On May 27, 2013, at 3:10 PM, peter van der Stok = wrote: > Hi Zach et al. >=20 > Reading through the document I came up with two questions concerning = the scope of the document. >=20 > In the examples of section 5, the content formats are text and = senml+json. > Is that meant as a standardization restriction or are xml and exi also = allowed as content formats? > Some additional text or examples in xml may be welcome to get scope = clearer. Sure, we can add examples for the use of senml+xml or senml-exi.=20 > The subsections of section 5 treat the structuring of links in a list, = batch and discuss binding tables. > They concern the manipulation of the resource structure. These provide pretty generic interface descriptions for those purposes, = however e.g. batch only works with simple text/plain resources. It fits = together nicely with the other interface descriptions defined in the = document (or something similar). > However the subsections on actuator, RO parameter, parameter and = sensor restrict the interfaces of the devices which are described = (accessed). > According to me that should be the subject of other documents which = describe concrete Function sets for a given "standardized" set of = devices. Well, you need some building blocks to start with, without restricting = what interfaces a device can provide. That is the point of those = interface descriptions, they give someone defining a function set some = basic interfaces that *could* be used. Someone defining a function set = of course needs to define the resources in the function set, their = resource types, and possibly new interface descriptions for more complex = purposes. So we're not in any way restricting what a device uses for its = resources.=20 I don't see the IETF being in the business of defining device or = application specific function sets. There are other organisations such = as OMA, the IPSO Alliance, ZigBee (e.g. SEP2.0) and OASIS that do that = kind of definition work. But we definitely can give some simple REST = design tools to work with.=20 > Appendix A is just fine for me because it makes earlier text more = concrete and is tagged as example text. I agreed, having a concrete examples helps.=20 Thanks, Zach >=20 > Greetings >=20 > Peter >=20 > --=20 > Peter van der Stok > mailto: consultancy@vanderstok.org > www: www.vanderstok.org > tel NL: +31(0)492474673 F: +33(0)966015248 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=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 Mon May 27 12:29:07 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D8B21F96DD for ; Mon, 27 May 2013 12:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, 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 lzY8NmoOlbye for ; Mon, 27 May 2013 12:29:03 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 2479521F96D0 for ; Mon, 27 May 2013 12:29:02 -0700 (PDT) Received: from [10.37.49.6] ([77.95.242.69]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r4RJSncp012803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 May 2013 22:28:51 +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: <5FCD5B5A-FB40-4408-AF61-7464CA8825AC@intec.ugent.be> Date: Mon, 27 May 2013 22:28:49 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9BA14860-EE30-483F-A29B-9FB63DB865D9@sensinode.com> References: <9B18C869-84FE-49E3-B1BF-31886A7922FF@sensinode.com> <5FCD5B5A-FB40-4408-AF61-7464CA8825AC@intec.ugent.be> To: Jeroen Hoebeke X-Mailer: Apple Mail (2.1503) Cc: "core@ietf.org" Subject: Re: [core] draft-shelby-core-interfaces: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 27 May 2013 19:29:07 -0000 On May 27, 2013, at 5:45 PM, Jeroen Hoebeke = wrote: > Thanks for the feedback. >=20 >>>> 1. The Origin Server and the Resource, should be in control over = any semantics >>>> regarding the resource representation. Working with parameters that = affect >>>> the representation of the resource, MUST be handled as part of the = REST >>>> interface. >=20 > Conditional observe does not affect the representation of the = resource, it affects the notifications you receive (when, which). Of = course, the ability to conditionally observe a resource does depend on = the underlying data type (e.g. xsd:integer). How this data type is = represented does not matter. I actually think of a notification being sent each time a resource = changes, and thus conditionals affect when a resource changes. But that = is philosophical :-) > For every data type, you can think of several interesting conditions. = It would indeed be nice if this group can give guidance on how to = provide this conditional observe functionality in a resource agnostic = way (be it using a URI query or CoAP option) and with a scope that is = broader than what is in the current core-interfaces draft.=20 We could eventually do that. Although we probably need some more = experience of what people actually need. This is an area where it is = really easy to invent a lot of complex and fancy solutions, so we should = be very careful. CoRE Interfaces is separate from that work however. This gives *a* = design pattern for a simple set of REST interfaces that can be used = *right now*. That is valuable regardless of new mechanisms we might = introduce in the future. If some day we introduce a more advanced = mechanism, we can give advice on how to use it. Right now however, we = only have CoAP and Observe. =20 > Based on our experience implementing and evaluation the conditional = observe draft, we can contribute to this discussion. For example, one = reason the conditional observed draft has chosen to use of a CoAP option = is that it overwrites default observe behaviour: > - a client can select if notifications should be confirmable or not > - if the resource state does not change and max-age expires, no = notification is sent. As a result, you only get the events of interest = (and not the notifications that would be needed in order to have = eventual consistency - especially not in case max-age is set to very low = values or even zero to disable caching). > In that respect, the approach you have chosen is different. =20 I am sure there are several ways to solve the problem. Thanks, 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 Mon May 27 12:31: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 CAE2221F8BC0 for ; Mon, 27 May 2013 12:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 vKCptTxK9pE1 for ; Mon, 27 May 2013 12:31:11 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 8659321F8B64 for ; Mon, 27 May 2013 12:31:11 -0700 (PDT) Received: from [10.37.49.6] ([77.95.242.69]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r4RJV6Lr013066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 May 2013 22:31:07 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: Date: Mon, 27 May 2013 22:31:06 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <01CA5860-76E9-4FB6-8C95-C0F285AD87BF@sensinode.com> References: To: Andrew Mcgregor X-Mailer: Apple Mail (2.1503) Cc: core@ietf.org Subject: Re: [core] draft-castellani-core-http-mapping: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 27 May 2013 19:31:15 -0000 I support the adoption of this draft.=20 Zach On May 21, 2013, at 3:24 AM, Andrew Mcgregor = wrote: > Consensus of the room in Orlando was to adopt = draft-castellani-core-http-mapping as a working group document. This = email is a call for confirmation of that consensus. Please respond if = you support the adoption of this document. >=20 > The charter says "The WG will define a mapping from CoAP to > an HTTP REST API; this mapping will not depend on a specific > application." We have the normative parts covered in core-coap, but > additional elucidation for implementers seems worthwhile. >=20 > =95 Sep 2013 Submission to IESG of "Best Practices for HTTP-CoAP = Mapping > Implementation" for Informational >=20 > (We can discuss if a non-BCP should have "Best Practices" in the > title, but the objective is to provide examples of good usage for > implementers, not to give strong recommendations.) >=20 > --=20 > Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From zach@sensinode.com Mon May 27 12:32: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 E6EF621F8BC0 for ; Mon, 27 May 2013 12:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 QjFoktDKhKm3 for ; Mon, 27 May 2013 12:32:17 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id A466D21F8CE9 for ; Mon, 27 May 2013 12:32:16 -0700 (PDT) Received: from [10.37.49.6] ([77.95.242.69]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r4RJWCx0013174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 May 2013 22:32:14 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: Date: Mon, 27 May 2013 22:32:13 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andrew Mcgregor X-Mailer: Apple Mail (2.1503) Cc: core@ietf.org Subject: Re: [core] draft-bormann-core-links-json: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 27 May 2013 19:32:21 -0000 I support the adoption of this draft. Zach On May 21, 2013, at 3:27 AM, Andrew Mcgregor = wrote: > Consensus of the room in Orlando was to adopt = draft-bormann-core-links-json as a working group document. This email = is a call for confirmation of that consensus. Please respond if you = support the adoption of this document. >=20 > =46rom the charter: >=20 > 5) A definition of how to use CoAP to advertise about or query for = a > Device's description. This description may include the device name = and > a list of its Resources, each with a URL, an interface description = URI > (pointing e.g. to a Web Application Description Language (WADL) > document) and an optional name or identifier. The name taxonomy = used > for this description will be consistent with other IETF work, > e.g. draft-cheshire-dnsext-dns-sd. >=20 > This is for making the resource discovery information available to = backends. On a technical level, this is a no-brainer. >=20 > =95 May 2013 Submission to IESG of "Representing CoRE Link Collections > in JSON" for Proposed Standard >=20 > --=20 > Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From presnick@qti.qualcomm.com Mon May 27 17:05: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 BADAB21F8681; Mon, 27 May 2013 17:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, 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 E4WmtLtEM1Xr; Mon, 27 May 2013 17:05:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0FA721F8624; Mon, 27 May 2013 17:05:50 -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.50 Message-ID: <20130528000550.22016.24374.idtracker@ietfa.amsl.com> Date: Mon, 27 May 2013 17:05:50 -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-17: (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, 28 May 2013 00:05:51 -0000 Pete Resnick has entered the following ballot position for draft-ietf-core-coap-17: 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'm still worried about 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. The possibility that a server could potentially not send back a 4.06 seems really problematic from a client perspective. I have no way as a client to say, "I really can only accept format X, and if you can't make format X, I don't want something else", and I have no way to distinguish that from "I would prefer format X, but am willing to take whatever you can give me." For the former, I have to be prepared to throw things away. For the latter, I have to be willing to send two requests, the first with Accept (potentially getting back 4.06), and then a re-request without Accept. Which one of the above are current clients doing? If it's the former, then I suggest making this into an implementation note, and I would even consider getting rid of the 4.06 response code for this use case, since it is nearly useless, and probably harmful. If it's the latter, then these SHOULDs ought to be MUSTs and the option should be critical so that clients can stop doing that. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- By section number: 3. Code: 8-bit unsigned integer, split into a 3-bit class (most significant bits) and a 5-bit detail (least significant bits), documented as c.dd where c is a digit from 0 to 7 for the 3-bit subfield and dd are two digits from 00 to 31 for the 5-bit subfield. Indicates if the message carries a request (0.01-0.31) or a response (2.00-5.31), or is empty (0.00). (All other code values are reserved.) I suggest changing the last two sentences above to: "The class can indicate a request (0), a success response (2), a client error response (4), or a server error response (5). (All other class values are reserved.)" = 4.1: Personally, I find the word "empty" confusing here. "Null" or "Noop" probably would have been better. If this use is already well understood, it's probably best to define it clearly. Capitalizing "Empty" might help. 4.2/4.3: "Reject" in the sense it is talked about in these sections is an internal state change. That's confusing to me, as the normal sense of the English word implies a party that "hears about" the rejection. (It's hard to me to think of a circumstance where someone or something was "rejected" and only the rejector ever knew about it.) In your use, "silently ignore" is one possible form of rejection. That's just weird. If you're going to do this, I'd define the term up front. Maybe even capitalize "Reject" wherever you use it. Either way, in both 4.2 and 4.3, "MUST reject" is probably wrong (since that's an internal state and nothing a protocol requirement is useful for) and "MAY involve sending" is a strange construction. 4.5: I think the MAYs confuse things and might encourage implementers to take that path. Instead of: This rule MAY be relaxed in case the Confirmable message transports a request that is idempotent (see Section 5.1) or can be handled in an idempotent fashion. Examples for relaxed message deduplication: = I suggest: "Exceptions to this are when the Confirmable message transports a request that is idempotent (see Section 5.1) or can be handled in an idempotent fashion. Examples of these exceptions:". Also: As a general rule that MAY be relaxed based on the specific semantics of a message, the recipient SHOULD silently ignore any duplicated Non-confirmable message, and SHOULD process any request or response in the message only once. = I suggest: "The recipient SHOULD silently ignore any duplicated Non-confirmable message, and SHOULD process any request or response in the message only once, though the specific semantics of the message might dictate an exception." 4.6: I feel like this section is really one big 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 protocol instructions. 5.3.2: Change "the client will likely send a Reset message so it does not receive any more retransmissions" to "the client will send". A client that has lost state that receives what it will see as a random CON message will always send back a Reset. 5.4.6: If it were me, I would have put the NoCacheKey bits in the high four bits of the most significant byte 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: 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. 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 likepeng@huawei.com Mon May 27 20:03: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 7B07221F9362 for ; Mon, 27 May 2013 20:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 2cYIrE+phrJF for ; Mon, 27 May 2013 20:03:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4812E21F935A for ; Mon, 27 May 2013 20:03:35 -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 ATF75011; Tue, 28 May 2013 03:03:33 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 28 May 2013 04:03:05 +0100 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 28 May 2013 04:03:31 +0100 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.200]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.007; Tue, 28 May 2013 11:03:25 +0800 From: Likepeng To: Zach Shelby , Jeroen Hoebeke Thread-Topic: [core] draft-shelby-core-interfaces: call for adoption Thread-Index: AQHOVbow0gX0K64CdkSzliurgWWqM5kOexGAgAAu6ACABOZcAIAABGSAgAEPcoCAA4gGgIAAc+IAgABPL4CAAQP0wA== Date: Tue, 28 May 2013 03:03:24 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F232262A8F@szxeml525-mbx.china.huawei.com> References: <9B18C869-84FE-49E3-B1BF-31886A7922FF@sensinode.com> <5FCD5B5A-FB40-4408-AF61-7464CA8825AC@intec.ugent.be> <9BA14860-EE30-483F-A29B-9FB63DB865D9@sensinode.com> In-Reply-To: <9BA14860-EE30-483F-A29B-9FB63DB865D9@sensinode.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org" Subject: Re: [core] draft-shelby-core-interfaces: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 May 2013 03:03:40 -0000 PiBJdCB3b3VsZCBpbmRlZWQgYmUgbmljZSBpZiB0aGlzIGdyb3VwIGNhbiBnaXZlIGd1aWRhbmNl IG9uIGhvdyB0byBwcm92aWRlIHRoaXMgY29uZGl0aW9uYWwgb2JzZXJ2ZSBmdW5jdGlvbmFsaXR5 IGluIGEgcmVzb3VyY2UgYWdub3N0aWMgd2F5IChiZSBpdCB1c2luZyBhIFVSSSBxdWVyeSBvciBD b0FQIG9wdGlvbikgYW5kIHdpdGggYSBzY29wZSB0aGF0IGlzIGJyb2FkZXIgdGhhbiB3aGF0IGlz IGluIHRoZSBjdXJyZW50IGNvcmUtaW50ZXJmYWNlcyBkcmFmdC4NCg0KSSBhZ3JlZSB0aGF0IHRo ZSBjb25kaXRpb25hbCBvYnNlcnZlIGZ1bmN0aW9uYWxpdHkgc2hvdWxkIGJlIGRvbmUgaW4gYSBy ZXNvdXJjZSBhZ25vc3RpYyB3YXkuIA0KDQpDdXJyZW50bHksIG9ic2VydmUgaXMgZGVzaWduZWQg YXMgYW4gb3B0aW9uLCBhbmQgSSB0aGluayBpdCB3aWxsIGJlIGJldHRlciB0byBkZXNpZ24gdGhl IG9ic2VydmUgY29uZGl0aW9ucyBhcyBvcHRpb25zLCB0b2dldGhlciB3aXRoIHRoZSBvYnNlcnZl IG9wdGlvbi4NCg0KV2UgaGF2ZSBpbXBsZW1lbnRlZCBjb25kaXRpb25hbCBvYnNlcnZlIGJhc2Vk IG9uIG9wdGlvbnMsIGFuZCBpdCB3b3JrcyBxdWl0ZSB3ZWxsLg0KDQpLaW5kIFJlZ2FyZHMNCktl cGVuZw0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogY29yZS1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFphY2ggU2hlbGJ5DQq3osvNyrG8 5DogMjAxM8TqNdTCMjjI1SAzOjI5DQrK1bz+yMs6IEplcm9lbiBIb2ViZWtlDQqzrcvNOiBjb3Jl QGlldGYub3JnDQrW98ziOiBSZTogW2NvcmVdIGRyYWZ0LXNoZWxieS1jb3JlLWludGVyZmFjZXM6 IGNhbGwgZm9yIGFkb3B0aW9uDQoNCk9uIE1heSAyNywgMjAxMywgYXQgNTo0NSBQTSwgSmVyb2Vu IEhvZWJla2UgPGplcm9lbi5ob2ViZWtlQGludGVjLnVnZW50LmJlPiB3cm90ZToNCg0KPiBUaGFu a3MgZm9yIHRoZSBmZWVkYmFjay4NCj4gDQo+Pj4+IDEuIFRoZSBPcmlnaW4gU2VydmVyIGFuZCB0 aGUgUmVzb3VyY2UsIHNob3VsZCBiZSBpbiBjb250cm9sIG92ZXIgYW55IHNlbWFudGljcw0KPj4+ PiByZWdhcmRpbmcgdGhlIHJlc291cmNlIHJlcHJlc2VudGF0aW9uLiBXb3JraW5nIHdpdGggcGFy YW1ldGVycyB0aGF0IGFmZmVjdA0KPj4+PiB0aGUgcmVwcmVzZW50YXRpb24gb2YgdGhlIHJlc291 cmNlLCBNVVNUIGJlIGhhbmRsZWQgYXMgcGFydCBvZiB0aGUgUkVTVA0KPj4+PiBpbnRlcmZhY2Uu DQo+IA0KPiBDb25kaXRpb25hbCBvYnNlcnZlIGRvZXMgbm90IGFmZmVjdCB0aGUgcmVwcmVzZW50 YXRpb24gb2YgdGhlIHJlc291cmNlLCBpdCBhZmZlY3RzIHRoZSBub3RpZmljYXRpb25zIHlvdSBy ZWNlaXZlICh3aGVuLCB3aGljaCkuIE9mIGNvdXJzZSwgdGhlIGFiaWxpdHkgdG8gY29uZGl0aW9u YWxseSBvYnNlcnZlIGEgcmVzb3VyY2UgZG9lcyBkZXBlbmQgb24gdGhlIHVuZGVybHlpbmcgZGF0 YSB0eXBlIChlLmcuIHhzZDppbnRlZ2VyKS4gSG93IHRoaXMgZGF0YSB0eXBlIGlzIHJlcHJlc2Vu dGVkIGRvZXMgbm90IG1hdHRlci4NCg0KSSBhY3R1YWxseSB0aGluayBvZiBhIG5vdGlmaWNhdGlv biBiZWluZyBzZW50IGVhY2ggdGltZSBhIHJlc291cmNlIGNoYW5nZXMsIGFuZCB0aHVzIGNvbmRp dGlvbmFscyBhZmZlY3Qgd2hlbiBhIHJlc291cmNlIGNoYW5nZXMuIEJ1dCB0aGF0IGlzIHBoaWxv c29waGljYWwgOi0pDQoNCj4gRm9yIGV2ZXJ5IGRhdGEgdHlwZSwgeW91IGNhbiB0aGluayBvZiBz ZXZlcmFsIGludGVyZXN0aW5nIGNvbmRpdGlvbnMuIEl0IHdvdWxkIGluZGVlZCBiZSBuaWNlIGlm IHRoaXMgZ3JvdXAgY2FuIGdpdmUgZ3VpZGFuY2Ugb24gaG93IHRvIHByb3ZpZGUgdGhpcyBjb25k aXRpb25hbCBvYnNlcnZlIGZ1bmN0aW9uYWxpdHkgaW4gYSByZXNvdXJjZSBhZ25vc3RpYyB3YXkg KGJlIGl0IHVzaW5nIGEgVVJJIHF1ZXJ5IG9yIENvQVAgb3B0aW9uKSBhbmQgd2l0aCBhIHNjb3Bl IHRoYXQgaXMgYnJvYWRlciB0aGFuIHdoYXQgaXMgaW4gdGhlIGN1cnJlbnQgY29yZS1pbnRlcmZh Y2VzIGRyYWZ0LiANCg0KV2UgY291bGQgZXZlbnR1YWxseSBkbyB0aGF0LiBBbHRob3VnaCB3ZSBw cm9iYWJseSBuZWVkIHNvbWUgbW9yZSBleHBlcmllbmNlIG9mIHdoYXQgcGVvcGxlIGFjdHVhbGx5 IG5lZWQuIFRoaXMgaXMgYW4gYXJlYSB3aGVyZSBpdCBpcyByZWFsbHkgZWFzeSB0byBpbnZlbnQg YSBsb3Qgb2YgY29tcGxleCBhbmQgZmFuY3kgc29sdXRpb25zLCBzbyB3ZSBzaG91bGQgYmUgdmVy eSBjYXJlZnVsLg0KDQpDb1JFIEludGVyZmFjZXMgaXMgc2VwYXJhdGUgZnJvbSB0aGF0IHdvcmsg aG93ZXZlci4gVGhpcyBnaXZlcyAqYSogZGVzaWduIHBhdHRlcm4gZm9yIGEgc2ltcGxlIHNldCBv ZiBSRVNUIGludGVyZmFjZXMgdGhhdCBjYW4gYmUgdXNlZCAqcmlnaHQgbm93Ki4gVGhhdCBpcyB2 YWx1YWJsZSByZWdhcmRsZXNzIG9mIG5ldyBtZWNoYW5pc21zIHdlIG1pZ2h0IGludHJvZHVjZSBp biB0aGUgZnV0dXJlLiBJZiBzb21lIGRheSB3ZSBpbnRyb2R1Y2UgYSBtb3JlIGFkdmFuY2VkIG1l Y2hhbmlzbSwgd2UgY2FuIGdpdmUgYWR2aWNlIG9uIGhvdyB0byB1c2UgaXQuIFJpZ2h0IG5vdyBo b3dldmVyLCB3ZSBvbmx5IGhhdmUgQ29BUCBhbmQgT2JzZXJ2ZS4gIA0KDQo+IEJhc2VkIG9uIG91 ciBleHBlcmllbmNlIGltcGxlbWVudGluZyBhbmQgZXZhbHVhdGlvbiB0aGUgY29uZGl0aW9uYWwg b2JzZXJ2ZSBkcmFmdCwgd2UgY2FuIGNvbnRyaWJ1dGUgdG8gdGhpcyBkaXNjdXNzaW9uLiBGb3Ig ZXhhbXBsZSwgb25lIHJlYXNvbiB0aGUgY29uZGl0aW9uYWwgb2JzZXJ2ZWQgZHJhZnQgaGFzIGNo b3NlbiB0byB1c2Ugb2YgYSBDb0FQIG9wdGlvbiBpcyB0aGF0IGl0IG92ZXJ3cml0ZXMgZGVmYXVs dCBvYnNlcnZlIGJlaGF2aW91cjoNCj4gLSBhIGNsaWVudCBjYW4gc2VsZWN0IGlmIG5vdGlmaWNh dGlvbnMgc2hvdWxkIGJlIGNvbmZpcm1hYmxlIG9yIG5vdA0KPiAtIGlmIHRoZSByZXNvdXJjZSBz dGF0ZSBkb2VzIG5vdCBjaGFuZ2UgYW5kIG1heC1hZ2UgZXhwaXJlcywgbm8gbm90aWZpY2F0aW9u IGlzIHNlbnQuIEFzIGEgcmVzdWx0LCB5b3Ugb25seSBnZXQgdGhlIGV2ZW50cyBvZiBpbnRlcmVz dCAoYW5kIG5vdCB0aGUgbm90aWZpY2F0aW9ucyB0aGF0IHdvdWxkIGJlIG5lZWRlZCBpbiBvcmRl ciB0byBoYXZlIGV2ZW50dWFsIGNvbnNpc3RlbmN5IC0gZXNwZWNpYWxseSBub3QgaW4gY2FzZSBt YXgtYWdlIGlzIHNldCB0byB2ZXJ5IGxvdyB2YWx1ZXMgb3IgZXZlbiB6ZXJvIHRvIGRpc2FibGUg Y2FjaGluZykuDQo+IEluIHRoYXQgcmVzcGVjdCwgdGhlIGFwcHJvYWNoIHlvdSBoYXZlIGNob3Nl biBpcyBkaWZmZXJlbnQuICANCg0KSSBhbSBzdXJlIHRoZXJlIGFyZSBzZXZlcmFsIHdheXMgdG8g c29sdmUgdGhlIHByb2JsZW0uDQoNClRoYW5rcywNClphY2gNCg0KLS0gDQpaYWNoIFNoZWxieSwg Q2hpZWYgTmVyZCwgU2Vuc2lub2RlIEx0ZC4NCmh0dHA6Ly93d3cuc2Vuc2lub2RlLmNvbSBAU2Vu c2lub2RlSW9UDQpNb2JpbGU6ICszNTggNDAgNzc5NjI5Nw0KVHdpdHRlcjogQHphY2hfc2hlbGJ5 DQpMaW5rZWRJbjogaHR0cDovL2ZpLmxpbmtlZGluLmNvbS9pbi96YWNoc2hlbGJ5DQo2TG9XUEFO IEJvb2s6IGh0dHA6Ly82bG93cGFuLm5ldA0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0K From floris.vandenabeele@intec.ugent.be Tue May 28 00:36: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 A408921F8517 for ; Tue, 28 May 2013 00:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfsMm5GqeEEK for ; Tue, 28 May 2013 00:36:30 -0700 (PDT) Received: from smtp1.ugent.be (smtp1.ugent.be [157.193.71.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1456A21F852D for ; Tue, 28 May 2013 00:36:25 -0700 (PDT) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp1.ugent.be (Postfix) with ESMTP id 80D768687; Tue, 28 May 2013 09:36:20 +0200 (CEST) X-Virus-Scanned: by UGent DICT Received: from smtp1.ugent.be ([157.193.71.182]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id uEAqv7xwwpSk; Tue, 28 May 2013 09:36:20 +0200 (CEST) Received: from mail2.intec.ugent.be (mail2.intec.ugent.be [157.193.214.245]) by smtp1.ugent.be (Postfix) with ESMTP id DC11480D3; Tue, 28 May 2013 09:36:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail2.intec.ugent.be (Postfix) with ESMTP id A4C891F; Tue, 28 May 2013 09:36:19 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at intec.ugent.be Received: from mail2.intec.ugent.be ([127.0.0.1]) by localhost (mail2.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Dx-RKg1LGXr; Tue, 28 May 2013 09:36:19 +0200 (CEST) Received: from [157.193.135.210] (dhcp-zdpt-210.intec.ugent.be [157.193.135.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fvdabeele) by mail2.intec.ugent.be (Postfix) with ESMTPSA id 8B4041E; Tue, 28 May 2013 09:36:19 +0200 (CEST) Message-ID: <51A45E73.80101@intec.ugent.be> Date: Tue, 28 May 2013 09:36:19 +0200 From: Floris Van den Abeele User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Zach Shelby References: <15C704CA-839F-41CE-99C8-73DA52A0CBFB@sensinode.com> In-Reply-To: <15C704CA-839F-41CE-99C8-73DA52A0CBFB@sensinode.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at jchkm1 with ID 51A45E73.001 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 51A45E73.001 from mail2.intec.ugent.be/mail2.intec.ugent.be/157.193.214.245/mail2.intec.ugent.be/ X-j-chkmail-Score: MSGID : 51A45E73.001 on smtp1.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: core@ietf.org Subject: Re: [core] draft-shelby-core-resource-directory: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 May 2013 07:36:37 -0000 +1 Floris Op vr 24 mei 2013 17:03:01 CEST, Zach Shelby schreef: > Peter, > > I agree, as discussed in Orlando, we should integrate the DNS-SD mapping to this document. > > Thanks, > Zach > > On May 21, 2013, at 9:47 AM, peter van der Stok wrote: > >> I certainly support this, but with the remark that relation to DNS and DNS-SD should be clarified in the document. >> This concerns how to handle name resolution with respect to information stored in resource directory >> and text from lynn draft about conversion of attribute values to RR in DNS >> >> Peter van der Stok >> >> Rahman, Akbar schreef op 2013-05-21 05:49: >>> +1 >>> Akbar >>> FROM: core-bounces@ietf.org [mailto:core-bounces@ietf.org] ON BEHALF >>> OF Andrew Mcgregor >>> SENT: Monday, May 20, 2013 8:26 PM >>> TO: core@ietf.org >>> SUBJECT: [core] draft-shelby-core-resource-directory: call for adoption >>> Consensus of the room in Orlando was to adopt >>> draft-shelby-core-resource-directory as a working group document. This >>> email is a call for confirmation of that consensus. Please respond if >>> you support the adoption of this document. >>> From the charter: >>> 5) A definition of how to use CoAP to advertise about or query for a >>> Device's description. This description may include the device name and >>> a list of its Resources, each with a URL, an interface description URI >>> (pointing e.g. to a Web Application Description Language (WADL) >>> document) and an optional name or identifier. The name taxonomy used >>> for this description will be consistent with other IETF work, >>> e.g. draft-cheshire-dnsext-dns-sd. >>> RFC 6690 has some of this; the resource directory would add protocol >>> elements on top of CoAP that enhance the "advertise about or query >>> for" aspect. >>> * Feb 2014 Submission to IESG of "CoRE Resource Directory" for >>> Proposed Standard >>> -- >>> Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core > From zach@sensinode.com Tue May 28 01:53: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 62FD121F93E1; Tue, 28 May 2013 01:53: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 PHjYumJygOlp; Tue, 28 May 2013 01:53: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 DDB2E21F93BF; Tue, 28 May 2013 01:53:51 -0700 (PDT) Received: from dyn2980.panoulu.local (nat1.panoulu.net [212.50.147.98]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r4S8rnQI022014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 May 2013 11:53:50 +0300 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <65006D2B-833D-435B-9E17-5D8A3A9207F7@sensinode.com> Date: Tue, 28 May 2013 11:53:51 +0300 To: "core@ietf.org WG" , "6lowpan@ietf.org WG" <6lowpan@ietf.org> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [core] DTLS for IoT working group effort X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 May 2013 08:53:57 -0000 We are working on a new working group effort focused on making the use = of DTLS even better for Internet of Things applications using CoAP. This = group would first focus on efficient profiling of DTLS and multicast = support using the DTLS record layer. If security for IoT is interesting for you, please join our mailing = list: https://www.ietf.org/mailman/listinfo/dtls-iot We are planning to hold a BOF in Berlin. The group is hosting a Google = Doc with our background information, proposed Charter and action items.=20= Regards, Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From stokcons@xs4all.nl Tue May 28 03:43: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 5B72521F9681 for ; Tue, 28 May 2013 03:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.225 X-Spam-Level: ** X-Spam-Status: No, score=2.225 tagged_above=-999 required=5 tests=[AWL=1.529, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_53=0.6, J_CHICKENPOX_54=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 aOi1riDJpR-c for ; Tue, 28 May 2013 03:43:25 -0700 (PDT) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by ietfa.amsl.com (Postfix) with ESMTP id 52EF021F9680 for ; Tue, 28 May 2013 03:43:24 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube1.xs4all.net [194.109.20.195]) by smtp-vbr7.xs4all.nl (8.13.8/8.13.8) with ESMTP id r4SAhN04091149 for ; Tue, 28 May 2013 12:43:23 +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, 28 May 2013 12:43:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 28 May 2013 12:43:23 +0200 From: peter van der Stok To: Core Organization: vanderstok consultancy Mail-Reply-To: Message-ID: <977bf7a9609775e0909d40cbcff838d6@xs4all.nl> X-Sender: stokcons@xs4all.nl (bm4dnwGRBccamuIP2H6LJtMJFLjyuhiz) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [core] Fwd: Re: core-interfaces-05 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, 28 May 2013 10:43:30 -0000 Hi Zach, To clarify the scope of the draft, and reacting to: >> However the subsections on actuator, RO parameter, parameter and >> sensor restrict the interfaces of the devices which are described >> (accessed). >> According to me that should be the subject of other documents which >> describe concrete Function sets for a given "standardized" set of >> devices. > Well, you need some building blocks to start with, without > restricting what interfaces a device can provide. That is the point of > those interface descriptions, they give someone defining a function > set some basic interfaces that *could* be used. Someone defining a > function set of course needs to define the resources in the function > set, their resource types, and possibly new interface descriptions for > more complex purposes. So we're not in any way restricting what a > device uses for its resources. If I understand correctly, link-list, batch, linked batch and binding tables are proposals for standardization but sensor, actuator and parameter are examples. I would suggest to put them in different sections. And I think the section suggests restricting the use of the device, for example by specifying that a POST can only do a toggle on a device. It is certainly interesting to suggest examples of device interfaces, but completeness will be difficult to attain, and the suggestion for standardization should be removed. Question, are you aiming at an Informational document? > I don't see the IETF being in the business of defining device or > application specific function sets. There are other organisations such > as OMA, the IPSO Alliance, ZigBee (e.g. SEP2.0) and OASIS that do that > kind of definition work. But we definitely can give some simple REST > design tools to work with. I definitely agree that other SDOs should do the standardization of concrete devices and Function sets. But design tooling is different from interface example specification, in my view. Are you suggesting design patterns with relations between resources specified in the binding tables? Peter Zach Shelby schreef op 2013-05-27 21:16: > On May 27, 2013, at 3:10 PM, peter van der Stok > wrote: > >> Hi Zach et al. >> Reading through the document I came up with two questions concerning >> the scope of the document. >> In the examples of section 5, the content formats are text and >> senml+json. >> Is that meant as a standardization restriction or are xml and exi >> also allowed as content formats? >> Some additional text or examples in xml may be welcome to get scope >> clearer. > Sure, we can add examples for the use of senml+xml or senml-exi. > >> The subsections of section 5 treat the structuring of links in a >> list, batch and discuss binding tables. >> They concern the manipulation of the resource structure. > These provide pretty generic interface descriptions for those > purposes, however e.g. batch only works with simple text/plain > resources. It fits together nicely with the other interface > descriptions defined in the document (or something similar). > >> However the subsections on actuator, RO parameter, parameter and >> sensor restrict the interfaces of the devices which are described >> (accessed). >> According to me that should be the subject of other documents which >> describe concrete Function sets for a given "standardized" set of >> devices. > Well, you need some building blocks to start with, without > restricting what interfaces a device can provide. That is the point of > those interface descriptions, they give someone defining a function > set some basic interfaces that *could* be used. Someone defining a > function set of course needs to define the resources in the function > set, their resource types, and possibly new interface descriptions for > more complex purposes. So we're not in any way restricting what a > device uses for its resources. > I don't see the IETF being in the business of defining device or > application specific function sets. There are other organisations such > as OMA, the IPSO Alliance, ZigBee (e.g. SEP2.0) and OASIS that do that > kind of definition work. But we definitely can give some simple REST > design tools to work with. > >> Appendix A is just fine for me because it makes earlier text more >> concrete and is tagged as example text. > I agreed, having a concrete examples helps. > Thanks, > Zach > >> Greetings >> Peter >> -- >> Peter van der Stok >> mailto: consultancy@vanderstok.org >> www: www.vanderstok.org >> tel NL: +31(0)492474673 F: +33(0)966015248 >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core From zach@sensinode.com Tue May 28 05:12: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 A76EE21F96F7 for ; Tue, 28 May 2013 05:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J40tqeBK4aGO for ; Tue, 28 May 2013 05:12:25 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 8864F21F96EF for ; Tue, 28 May 2013 05:12:24 -0700 (PDT) Received: from [192.168.0.41] (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 r4SCCLQW019368 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 May 2013 15:12:21 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: <977bf7a9609775e0909d40cbcff838d6@xs4all.nl> Date: Tue, 28 May 2013 15:12:22 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <95CC4635-E34A-4B3D-A054-DEEC8A8D1EB0@sensinode.com> References: <977bf7a9609775e0909d40cbcff838d6@xs4all.nl> To: consultancy@vanderstok.org X-Mailer: Apple Mail (2.1503) Cc: Core Subject: Re: [core] core-interfaces-05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 May 2013 12:12:29 -0000 Peter, Let me quote the WG adoption mail that Andrew sent: "Since REST is not yet in wide use in the microcontroller community, documenting some examples of good CoAP design will be beneficial. In particular, it is not widely understood how to map certain concepts such as batching or binding to REST. We don't have an explicit charter item for documenting this, but it is natural to have explanatory material with the base specification. (LWIG is not the right group for this as this is not about protocol implementation, but about design of REST interfaces.) =95 Dec 2013 Submission to IESG of "CoRE Interfaces" for Informational (Again, the objective is to provide examples of good usage for implementers, not to standardize or even give strong recommendations.)" So we are talking about an informational document here. So we really = can't categorise batch, link etc. as "more informational" and sensor, = actuator, parameter as "less informational". In the end they all give = REST design guidelines that people may find useful and re-use :-)=20 The same goes for giving an example of handling Observe parameters with = a REST interface. It is useful informational guidance, as people are = already doing this anyways.=20 Zach=20 On May 28, 2013, at 1:43 PM, peter van der Stok = wrote: >=20 > Hi Zach, >=20 > To clarify the scope of the draft, and reacting to: >=20 >>> However the subsections on actuator, RO parameter, parameter and = sensor restrict the interfaces of the devices which are described = (accessed). >>> According to me that should be the subject of other documents which = describe concrete Function sets for a given "standardized" set of = devices. >> Well, you need some building blocks to start with, without >> restricting what interfaces a device can provide. That is the point = of >> those interface descriptions, they give someone defining a function >> set some basic interfaces that *could* be used. Someone defining a >> function set of course needs to define the resources in the function >> set, their resource types, and possibly new interface descriptions = for >> more complex purposes. So we're not in any way restricting what a >> device uses for its resources. >=20 > If I understand correctly, link-list, batch, linked batch and binding = tables are proposals for standardization > but sensor, actuator and parameter are examples. I would suggest to = put them in different sections. > And I think the section suggests restricting the use of the device, = for example by specifying that a POST can only do a toggle on a device. > It is certainly interesting to suggest examples of device interfaces, = but completeness will be difficult to attain, and the suggestion for = standardization should be removed. Question, are you aiming at an = Informational document? >=20 >> I don't see the IETF being in the business of defining device or >> application specific function sets. There are other organisations = such >> as OMA, the IPSO Alliance, ZigBee (e.g. SEP2.0) and OASIS that do = that >> kind of definition work. But we definitely can give some simple REST >> design tools to work with. >=20 > I definitely agree that other SDOs should do the standardization of = concrete devices and Function sets. > But design tooling is different from interface example specification, = in my view. Are you suggesting design patterns with relations between = resources specified in the binding tables? >=20 > Peter >=20 > Zach Shelby schreef op 2013-05-27 21:16: >> On May 27, 2013, at 3:10 PM, peter van der Stok = wrote: >>> Hi Zach et al. >>> Reading through the document I came up with two questions concerning = the scope of the document. >>> In the examples of section 5, the content formats are text and = senml+json. >>> Is that meant as a standardization restriction or are xml and exi = also allowed as content formats? >>> Some additional text or examples in xml may be welcome to get scope = clearer. >> Sure, we can add examples for the use of senml+xml or senml-exi. >>> The subsections of section 5 treat the structuring of links in a = list, batch and discuss binding tables. >>> They concern the manipulation of the resource structure. >> These provide pretty generic interface descriptions for those >> purposes, however e.g. batch only works with simple text/plain >> resources. It fits together nicely with the other interface >> descriptions defined in the document (or something similar). >>> However the subsections on actuator, RO parameter, parameter and = sensor restrict the interfaces of the devices which are described = (accessed). >>> According to me that should be the subject of other documents which = describe concrete Function sets for a given "standardized" set of = devices. >> Well, you need some building blocks to start with, without >> restricting what interfaces a device can provide. That is the point = of >> those interface descriptions, they give someone defining a function >> set some basic interfaces that *could* be used. Someone defining a >> function set of course needs to define the resources in the function >> set, their resource types, and possibly new interface descriptions = for >> more complex purposes. So we're not in any way restricting what a >> device uses for its resources. >> I don't see the IETF being in the business of defining device or >> application specific function sets. There are other organisations = such >> as OMA, the IPSO Alliance, ZigBee (e.g. SEP2.0) and OASIS that do = that >> kind of definition work. But we definitely can give some simple REST >> design tools to work with. >>> Appendix A is just fine for me because it makes earlier text more = concrete and is tagged as example text. >> I agreed, having a concrete examples helps. >> Thanks, >> Zach >>> Greetings >>> Peter >>> -- >>> Peter van der Stok >>> mailto: consultancy@vanderstok.org >>> www: www.vanderstok.org >>> tel NL: +31(0)492474673 F: +33(0)966015248 >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From trac+core@trac.tools.ietf.org Tue May 28 14:05: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 B1F1821F90D2 for ; Tue, 28 May 2013 14:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.227 X-Spam-Level: X-Spam-Status: No, score=-102.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 bVl7z+5niNf5 for ; Tue, 28 May 2013 14:05: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 0721521F90CC for ; Tue, 28 May 2013 14:05:35 -0700 (PDT) Received: from localhost ([127.0.0.1]:41644 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UhR5I-0007Gd-Fg; Tue, 28 May 2013 23:05: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-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Tue, 28 May 2013 21:05:32 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/core/trac/ticket/329 Message-ID: <051.a3e75005a1d094b7caa780c27d4f7b89@trac.tools.ietf.org> X-Trac-Ticket-ID: 329 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: <20130528210536.0721521F90CC@ietfa.amsl.com> Resent-Date: Tue, 28 May 2013 14:05:35 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #329: Ambiguity of Accept option still considered a problem 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, 28 May 2013 21:05:36 -0000 #329: Ambiguity of Accept option still considered a problem Pete Resnick notes (msg04531): Section 5.10.4 I'm still worried about 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. The possibility that a server could potentially not send back a 4.06 seems really problematic from a client perspective. I have no way as a client to say, "I really can only accept format X, and if you can't make format X, I don't want something else", and I have no way to distinguish that from "I would prefer format X, but am willing to take whatever you can give me." For the former, I have to be prepared to throw things away. For the latter, I have to be willing to send two requests, the first with Accept (potentially getting back 4.06), and then a re-request without Accept. Which one of the above are current clients doing? If it's the former, then I suggest making this into an implementation note, and I would even consider getting rid of the 4.06 response code for this use case, since it is nearly useless, and probably harmful. If it's the latter, then these SHOULDs ought to be MUSTs and the option should be critical so that clients can stop doing that. Carsten says: One thing we most likely don't want to change is that Accept is elective. So a client always has to be prepared to throw a response away. The only option to make Accept fully predictable is to get rid of 4.06. So far, we didn't really care that much about that full predictability. Should we go for it based on this DISCUSS? (Accept also was the last option we changed...) Translated into HTTP terms, our Accept then always includes a ", *" at the end. We definitely need WG input on this one to make a decision. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: protocol | Milestone: post-IESG-1 defect | Version: Priority: major | Keywords: Component: coap | Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: core From Akbar.Rahman@InterDigital.com Wed May 29 06:31: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 2A78C21F8B60 for ; Wed, 29 May 2013 06:31:40 -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 BWH9kg-6j42J for ; Wed, 29 May 2013 06:31:29 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF7821F9092 for ; Wed, 29 May 2013 06:31:20 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 May 2013 09:31:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 May 2013 09:31:18 -0400 Message-ID: In-Reply-To: <051.a3e75005a1d094b7caa780c27d4f7b89@trac.tools.ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] #329: Ambiguity of Accept option still considered a problem Thread-Index: Ac5b51IXPyyO1s8nQC2PG7QPC4tiUQAiPZ1A References: <051.a3e75005a1d094b7caa780c27d4f7b89@trac.tools.ietf.org> From: "Rahman, Akbar" To: X-OriginalArrivalTime: 29 May 2013 13:31:19.0320 (UTC) FILETIME=[CD71C180:01CE5C70] Cc: core@ietf.org Subject: Re: [core] #329: Ambiguity of Accept option still considered a problem X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 May 2013 13:31:40 -0000 Hi Carsten, Regarding your question: The only option to make Accept fully predictable is to get rid of 4.06. So far, we didn't really care that much about that full predictability. Should we go for it based on this DISCUSS? =20 It makes sense to me, so I am fine with this approach as a WG member. =20 One clarification question though. In HTTP is the behavior fully equivalent (i.e. the HTTP version of Accept is fully predictable)? Best Regards, Akbar -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of core issue tracker Sent: Tuesday, May 28, 2013 5:06 PM To: draft-ietf-core-coap@tools.ietf.org; cabo@tzi.org Cc: core@ietf.org Subject: [core] #329: Ambiguity of Accept option still considered a problem #329: Ambiguity of Accept option still considered a problem Pete Resnick notes (msg04531): Section 5.10.4 I'm still worried about 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. The possibility that a server could potentially not send back a 4.06 seems really problematic from a client perspective. I have no way as a client to say, "I really can only accept format X, and if you can't make format X, I don't want something else", and I have no way to distinguish that from "I would prefer format X, but am willing to take whatever you can give me." For the former, I have to be prepared to throw things away. For the latter, I have to be willing to send two requests, the first with Accept (potentially getting back 4.06), and then a re-request without Accept. Which one of the above are current clients doing? If it's the former, then I suggest making this into an implementation note, and I would even consider getting rid of the 4.06 response code for this use case, since it is nearly useless, and probably harmful. If it's the latter, then these SHOULDs ought to be MUSTs and the option should be critical so that clients can stop doing that. Carsten says: One thing we most likely don't want to change is that Accept is elective. So a client always has to be prepared to throw a response away. The only option to make Accept fully predictable is to get rid of 4.06. So far, we didn't really care that much about that full predictability. Should we go for it based on this DISCUSS? (Accept also was the last option we changed...) Translated into HTTP terms, our Accept then always includes a ", *" at the end. We definitely need WG input on this one to make a decision. --=20 -------------------------+---------------------------------------------- -------------------------+--- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: protocol | Milestone: post-IESG-1 defect | Version: Priority: major | Keywords: Component: coap | Severity: Submitted | WG Document | -------------------------+---------------------------------------------- -------------------------+--- Ticket URL: core _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Wed May 29 07:14: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 F1DC521F8FB6 for ; Wed, 29 May 2013 07:14:43 -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 PPeka3Ivaffe for ; Wed, 29 May 2013 07:14: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 BA79021F8F06 for ; Wed, 29 May 2013 07:14: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 r4TEEZsX027640; Wed, 29 May 2013 16:14:35 +0200 (CEST) Received: from [192.168.217.105] (p54890019.dip0.t-ipconnect.de [84.137.0.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5D6DB3FBA; Wed, 29 May 2013 16:14:35 +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, 29 May 2013 16:14:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <051.a3e75005a1d094b7caa780c27d4f7b89@trac.tools.ietf.org> To: "Rahman, Akbar" X-Mailer: Apple Mail (2.1503) Cc: core@ietf.org Subject: Re: [core] #329: Ambiguity of Accept option still considered a problem X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 29 May 2013 14:14:44 -0000 > One clarification question though. In HTTP is the behavior fully > equivalent (i.e. the HTTP version of Accept is fully predictable)? Good point! Section 14.1 of RFC 2616 says: If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response. So this is a SHOULD (in HTTP, practically all header fields are the = equivalent of our elective). Section 5.3.2 in draft-ietf-httpbis-p2-semantics-22.txt weakens this to: If an Accept header field is present in a request and none of the available representations for the response have a media type that is listed as acceptable, the origin server MAY either honor the Accept header field by sending a 406 (Not Acceptable) response or disregard the Accept header field by treating the response as if it is not subject to content negotiation. In HTTP, the client can exclude the 406 case by adding "*" to the Accept = header field. Otherwise, the situation seems to be similar to our status quo.=20 Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Wed May 29 07:25: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 BA49621F9012 for ; Wed, 29 May 2013 07:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 WMFhAbbdFjv3 for ; Wed, 29 May 2013 07:25:44 -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 EAFCF21F905B for ; Wed, 29 May 2013 07:25:43 -0700 (PDT) Received: from localhost ([127.0.0.1]:57474 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UhhJk-00007t-Rb; Wed, 29 May 2013 16:25: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-coap@tools.ietf.org, kovatsch@inf.ethz.ch X-Trac-Project: core Date: Wed, 29 May 2013 14:25:32 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/329#comment:1 Message-ID: <066.7fcfce93944df67d37ec5059d1a2cedf@trac.tools.ietf.org> References: <051.a3e75005a1d094b7caa780c27d4f7b89@trac.tools.ietf.org> X-Trac-Ticket-ID: 329 In-Reply-To: <051.a3e75005a1d094b7caa780c27d4f7b89@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, kovatsch@inf.ethz.ch, 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: <20130529142543.EAFCF21F905B@ietfa.amsl.com> Resent-Date: Wed, 29 May 2013 07:25:43 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #329: Ambiguity of Accept option still considered a problem 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, 29 May 2013 14:25:44 -0000 #329: Ambiguity of Accept option still considered a problem Comment (by kovatsch@inf.ethz.ch): To recall: We changed Accept to be non-repeatable because otherwise it causes quite some problems with intermediaries and caching. I see Accept as "I want exactly this format." The client can pick from the "cf" list in the Link Format of the resource (or it is even predefined in some profile). The inefficient looping with different Accept options is only a fallback---and constrained devices usually do not support that many formats. With Accept being elective, I agree that 4.06 is kind of useless. The clients must provide code to check the actual Content-Format anyway and might even elide the check for 4.06. However, I think it has some value for debugging. I think we rather need a "the client MUST check if the Content-Format in the response matches the Accept value of the request." (Additional comment: I currently only return 4.06 when the resource actually supports multiple formats. When a resource only supports one, I ignore Accept and respond with that.) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: protocol | Status: new defect | Milestone: post-IESG-1 Priority: major | Version: Component: coap | Resolution: Severity: Submitted | WG Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From internet-drafts@ietf.org Wed May 29 08:15: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 2BBCF21F90CD; Wed, 29 May 2013 08:15:14 -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.056, 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 sKHLElnWT+1t; Wed, 29 May 2013 08:15:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3128B21F8F0E; Wed, 29 May 2013 08:15:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130529151513.18985.74962.idtracker@ietfa.amsl.com> Date: Wed, 29 May 2013 08:15:13 -0700 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 15:15:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-09.txt Pages : 37 Date : 2013-05-29 Abstract: CoAP is a RESTful transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document provides guidance for how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Akbar.Rahman@InterDigital.com Wed May 29 08:24: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 702C021F9421 for ; Wed, 29 May 2013 08:24:11 -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 hc+c7yir1yr5 for ; Wed, 29 May 2013 08:24:07 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5AB21F9423 for ; Wed, 29 May 2013 08:24:02 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 May 2013 11:24:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 May 2013 11:24:01 -0400 Message-ID: In-Reply-To: <20130529151513.18985.74962.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] I-D Action: draft-ietf-core-groupcomm-09.txt Thread-Index: Ac5cf6vrT+kSIp+mS4aOmMllEXE3MQAACFJg References: <20130529151513.18985.74962.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: "Carsten Bormann" , "Andrew Mcgregor" X-OriginalArrivalTime: 29 May 2013 15:24:02.0300 (UTC) FILETIME=[8C7E9BC0:01CE5C80] Cc: core@ietf.org Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 15:24:11 -0000 Hi Carsten/Andrew, Esko and I have updated the Groupcomm I-D to address the following: Changes from ietf-08 to ietf-09: o Cleaned up requirements language in general. Also, requirements language are now only used in section 3 (Protocol Considerations) and section 6 (Security Considerations). Requirements language has been removed from other sections to keep them to a minimum (#271). o Addressed final comment from Peter van der Stok to define what "IP stack" meant (#296). Following the lead of CoAP-17, we know refer instead to "APIs such as IPV6_RECVPKTINFO [RFC3542]". o Changed text in section 3.4 (Group Methods) to allow multicast POST under specific conditions and highlighting the risks with using it (#328). o Various editorial updates for improved readability. The recommendation at the end of the Orlando IETF meeting was: o Draft to be updated within a month, do a quick check on the mailing list, and then WGLC We believe that this condition has been met (i.e. with the 4 revisions of the draft after Orlando and associated mailing list discussions). Please advise us on the next steps (i.e. start of WGLC, or if you feel that more updates need to be done to the draft). Our opinion is that it would be nice to have the draft finish WGLC by the time we meet in Berlin. Best Regards, Akbar & Esko. -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Wednesday, May 29, 2013 11:15 AM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-09.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-09.txt Pages : 37 Date : 2013-05-29 Abstract: CoAP is a RESTful transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document provides guidance for how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-09 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 ycma610103@gmail.com Thu May 30 01:50: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 7E8D121F97E5 for ; Thu, 30 May 2013 01:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFxKPeZf1Ga1 for ; Thu, 30 May 2013 01:50:07 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id F175121F97E4 for ; Thu, 30 May 2013 01:50:06 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id b11so13605130iee.11 for ; Thu, 30 May 2013 01:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/Zc24AuAHVF2xCdiWa251tR20SdGqockVaNhn5/hrfE=; b=bocXbh/hHaKwjvKhCYTc6btMY5dJZ2snUqb6Vz3Asq1jQpIqVqZACp2xRMQGS9TY0R 8i2MdmHGQOo5uci/OyrwEej07rRNRHM94CkMlVMPqekBJke0Bd43zm1TmZ96xVGku41E mk7BU/UaYInHBQ1DvVxW8c9VoXYGoV0HT/Xvnx5ioXFbrKaB9Pq1NtKcBGiZvhLpyaus eFcgyd3hgXmFQ/oaW3Jg0F8rkn/TUGeAGy9zqVQqSK+zzqbKiRHW7HD4aKPxCtT6NaAj 8CWXuGrRR6J1mw08Ws0vKEaZ9jBrdotqXYMlt5pyUJucraBdlbfEMg3T2p9DB4a33OT9 6fDQ== MIME-Version: 1.0 X-Received: by 10.50.153.47 with SMTP id vd15mr8999955igb.92.1369903806360; Thu, 30 May 2013 01:50:06 -0700 (PDT) Received: by 10.42.171.2 with HTTP; Thu, 30 May 2013 01:50:06 -0700 (PDT) In-Reply-To: <01CA5860-76E9-4FB6-8C95-C0F285AD87BF@sensinode.com> References: <01CA5860-76E9-4FB6-8C95-C0F285AD87BF@sensinode.com> Date: Thu, 30 May 2013 16:50:06 +0800 Message-ID: From: ma yc To: Zach Shelby Content-Type: multipart/alternative; boundary=089e0149532cc1800c04ddeb95f2 Cc: "core@ietf.org" Subject: Re: [core] draft-castellani-core-http-mapping: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 30 May 2013 08:50:08 -0000 --089e0149532cc1800c04ddeb95f2 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable =A3=AB1 Yuanchen 2013/5/28 Zach Shelby > I support the adoption of this draft. > > Zach > > On May 21, 2013, at 3:24 AM, Andrew Mcgregor > wrote: > > > Consensus of the room in Orlando was to adopt > draft-castellani-core-http-mapping as a working group document. This ema= il > is a call for confirmation of that consensus. Please respond if you > support the adoption of this document. > > > > The charter says "The WG will define a mapping from CoAP to > > an HTTP REST API; this mapping will not depend on a specific > > application." We have the normative parts covered in core-coap, but > > additional elucidation for implementers seems worthwhile. > > > > * Sep 2013 Submission to IESG of "Best Practices for HTTP-CoAP Mapping > > Implementation" for Informational > > > > (We can discuss if a non-BCP should have "Best Practices" in the > > title, but the objective is to provide examples of good usage for > > implementers, not to give strong recommendations.) > > > > -- > > Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > -- > 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 > --089e0149532cc1800c04ddeb95f2 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
=A3=AB1

Yuanchen


2013/5/28 Zach Shelby <= span dir=3D"ltr"><zach@sensinode.com>
I support the adoption of this draft.

Zach

On May 21, 2013, at 3:24 AM, Andrew Mcgregor <andrewmcgr@google.com> wrote:

> Consensus of the room in Orlando was to adopt draft-castellani-core-ht= tp-mapping as a working group document.  This email is a call for conf= irmation of that consensus.  Please respond if you support the adoptio= n of this document.
>
> The charter says "The WG will define a mapping from CoAP to
> an HTTP REST API; this mapping will not depend on a specific
> application."  We have the normative parts covered in core-c= oap, but
> additional elucidation for implementers seems worthwhile.
>
> • Sep 2013 Submission to IESG of "Best Practices for HTTP-Co= AP Mapping
>   Implementation" for Informational
>
> (We can discuss if a non-BCP should have "Best Practices" in= the
> title, but the objective is to provide examples of good usage for
> implementers, not to give strong recommendations.)
>
> --
> Andrew McGregor | SRE | andre= wmcgr@google.com | +61 4 8143 7128
> _________________________________= ______________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

--
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://6lowp= an.net




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

--089e0149532cc1800c04ddeb95f2-- From trac+core@trac.tools.ietf.org Thu May 30 03:17: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 8A6A821F9679 for ; Thu, 30 May 2013 03:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjDxVLQB5u9e for ; Thu, 30 May 2013 03:17: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 4045821F9677 for ; Thu, 30 May 2013 03:17:55 -0700 (PDT) Received: from localhost ([127.0.0.1]:58067 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Uhzvd-000126-Pa; Thu, 30 May 2013 12:17: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: esko.dijk@philips.com X-Trac-Project: core Date: Thu, 30 May 2013 10:17:53 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/271#comment:3 Message-ID: <075.0e8593ac9a627faf7802621bf9e06fcd@trac.tools.ietf.org> References: <060.098bc8881df48568161fdd11a361f525@trac.tools.ietf.org> X-Trac-Ticket-ID: 271 In-Reply-To: <060.098bc8881df48568161fdd11a361f525@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #271: Review groupcomm requirements language X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 10:17:57 -0000 #271: Review groupcomm requirements language Changes (by esko.dijk@philips.com): * status: assigned => closed * resolution: => fixed -- -----------------------------------+------------------------------------ Reporter: esko.dijk@philips.com | Owner: esko.dijk@philips.com Type: task | Status: closed Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------------+------------------------------------ Ticket URL: core From trac+core@trac.tools.ietf.org Thu May 30 03:18: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 B711F21F96D5 for ; Thu, 30 May 2013 03:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 H0xwwHwn+VRv for ; Thu, 30 May 2013 03:18:46 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id EED0221F9677 for ; Thu, 30 May 2013 03:18:40 -0700 (PDT) Received: from localhost ([127.0.0.1]:58088 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UhzwI-0008OO-EI; Thu, 30 May 2013 12:18: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-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Thu, 30 May 2013 10:18:34 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/296#comment:1 Message-ID: <075.ad5f8d8dd00b836f9c9c017ce99b6ec0@trac.tools.ietf.org> References: <060.dbca848cf7a32945871723581b121bd4@trac.tools.ietf.org> X-Trac-Ticket-ID: 296 In-Reply-To: <060.dbca848cf7a32945871723581b121bd4@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: <20130530101840.EED0221F9677@ietfa.amsl.com> Resent-Date: Thu, 30 May 2013 03:18:40 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [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: Thu, 30 May 2013 10:18:47 -0000 #296: Process review comments PvdS of Tue 2013-02-12 11:13 Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: finalized in groupcomm-09 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu May 30 03:20: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 AF73F21F95E9 for ; Thu, 30 May 2013 03:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 t8gEJMCyxPpS for ; Thu, 30 May 2013 03:20: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 8C4D021F955C for ; Thu, 30 May 2013 03:20:20 -0700 (PDT) Received: from localhost ([127.0.0.1]:58173 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Uhzxy-0006IS-RZ; Thu, 30 May 2013 12:20:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Thu, 30 May 2013 10:20:18 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/328#comment:1 Message-ID: <075.c6165ba8440aac3997fe95741e94d2ed@trac.tools.ietf.org> References: <060.e70219b6025ef24281c1ce1564b7cc54@trac.tools.ietf.org> X-Trac-Ticket-ID: 328 In-Reply-To: <060.e70219b6025ef24281c1ce1564b7cc54@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: <20130530102020.8C4D021F955C@ietfa.amsl.com> Resent-Date: Thu, 30 May 2013 03:20:20 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #328: Allow multicast POST under specific conditions 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, 30 May 2013 10:20:24 -0000 #328: Allow multicast POST under specific conditions Comment (by esko.dijk@philips.com): done in groupcomm-09 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: new enhancement | Milestone: Priority: major | Version: Component: groupcomm | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu May 30 03:20: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 4584421F96FD for ; Thu, 30 May 2013 03:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 K9nuKdOtGHA4 for ; Thu, 30 May 2013 03:20: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 5A25021F96FC for ; Thu, 30 May 2013 03:20:27 -0700 (PDT) Received: from localhost ([127.0.0.1]:58190 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Uhzy4-0008NR-Gq; Thu, 30 May 2013 12:20: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: Thu, 30 May 2013 10:20:24 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/328#comment:2 Message-ID: <075.b1e7f4d99977872f38fce0d65b814644@trac.tools.ietf.org> References: <060.e70219b6025ef24281c1ce1564b7cc54@trac.tools.ietf.org> X-Trac-Ticket-ID: 328 In-Reply-To: <060.e70219b6025ef24281c1ce1564b7cc54@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: <20130530102027.5A25021F96FC@ietfa.amsl.com> Resent-Date: Thu, 30 May 2013 03:20:27 -0700 (PDT) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #328: Allow multicast POST under specific conditions 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, 30 May 2013 10:20:28 -0000 #328: Allow multicast POST under specific conditions Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: closed enhancement | Milestone: Priority: major | Version: Component: groupcomm | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From mkomu@cs.hut.fi Thu May 30 04: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 D42E121F930C for ; Thu, 30 May 2013 04:58:00 -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 6Vnu0mp95pCv for ; Thu, 30 May 2013 04:57:46 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id A896921F92FB for ; Thu, 30 May 2013 04:57:45 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id 21873308D72 for ; Thu, 30 May 2013 14:57:38 +0300 (EEST) Message-ID: <51A73EB2.9030802@cs.hut.fi> Date: Thu, 30 May 2013 14:57:38 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: core@ietf.org References: <15C704CA-839F-41CE-99C8-73DA52A0CBFB@sensinode.com> <51A45E73.80101@intec.ugent.be> In-Reply-To: <51A45E73.80101@intec.ugent.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [core] draft-shelby-core-resource-directory: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 30 May 2013 11:58:00 -0000 +1 On 05/28/2013 10:36 AM, Floris Van den Abeele wrote: > +1 > > Floris > Op vr 24 mei 2013 17:03:01 CEST, Zach Shelby schreef: >> Peter, >> >> I agree, as discussed in Orlando, we should integrate the DNS-SD >> mapping to this document. >> >> Thanks, >> Zach >> >> On May 21, 2013, at 9:47 AM, peter van der Stok >> wrote: >> >>> I certainly support this, but with the remark that relation to DNS >>> and DNS-SD should be clarified in the document. >>> This concerns how to handle name resolution with respect to >>> information stored in resource directory >>> and text from lynn draft about conversion of attribute values to RR >>> in DNS >>> >>> Peter van der Stok >>> >>> Rahman, Akbar schreef op 2013-05-21 05:49: >>>> +1 >>>> Akbar >>>> FROM: core-bounces@ietf.org [mailto:core-bounces@ietf.org] ON BEHALF >>>> OF Andrew Mcgregor >>>> SENT: Monday, May 20, 2013 8:26 PM >>>> TO: core@ietf.org >>>> SUBJECT: [core] draft-shelby-core-resource-directory: call for adoption >>>> Consensus of the room in Orlando was to adopt >>>> draft-shelby-core-resource-directory as a working group document. This >>>> email is a call for confirmation of that consensus. Please respond if >>>> you support the adoption of this document. >>>> From the charter: >>>> 5) A definition of how to use CoAP to advertise about or query for a >>>> Device's description. This description may include the device name and >>>> a list of its Resources, each with a URL, an interface description URI >>>> (pointing e.g. to a Web Application Description Language (WADL) >>>> document) and an optional name or identifier. The name taxonomy used >>>> for this description will be consistent with other IETF work, >>>> e.g. draft-cheshire-dnsext-dns-sd. >>>> RFC 6690 has some of this; the resource directory would add protocol >>>> elements on top of CoAP that enhance the "advertise about or query >>>> for" aspect. >>>> * Feb 2014 Submission to IESG of "CoRE Resource Directory" for >>>> Proposed Standard >>>> -- >>>> Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 >>>> _______________________________________________ >>>> 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 >> > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > From ycma610103@gmail.com Thu May 30 18:18:07 2013 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECC321F992B for ; Thu, 30 May 2013 18:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hp8ukishcKFt for ; Thu, 30 May 2013 18:18:06 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8EC21F9927 for ; Thu, 30 May 2013 18:18:06 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id tp5so2436400ieb.34 for ; Thu, 30 May 2013 18:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vXj0vpzqkikQdY2rOZtc7vs3ROu/hKe1zbDAfBC2lYo=; b=BpUbXYnCC9dsUEFiQkKxTzhXsizYIGz3c2b8Dy+hI2XYBBFSgRW4VoWGWqHU7PhLiq vLACBX8qoYyNr+F/O7qW0Ehb2f8iVCgM9KTx8ibXab9QwiphytW5PhHu2xZltRBd9h3z oCs8030bJ+hgt8lvKsztEMXYOXs8BMgUqMSV90/MkwQ9CjhGNd5gn0c4fCj8Lpk207iV gXmmlJGc2ifk/xihs5VlC4yLA20aqMv27c2LRGEDppPgU992ynu71H3Jil0irvDY4bHZ QB7NFt1zGVUbYbqdHWhtXVv3ENOK2GSXF1UZ1YhNnfl7qMKjr9XmtVeD5S3cgdAX9bqi CM3w== MIME-Version: 1.0 X-Received: by 10.50.25.102 with SMTP id b6mr622062igg.27.1369963085903; Thu, 30 May 2013 18:18:05 -0700 (PDT) Received: by 10.42.171.2 with HTTP; Thu, 30 May 2013 18:18:05 -0700 (PDT) In-Reply-To: <51A73EB2.9030802@cs.hut.fi> References: <15C704CA-839F-41CE-99C8-73DA52A0CBFB@sensinode.com> <51A45E73.80101@intec.ugent.be> <51A73EB2.9030802@cs.hut.fi> Date: Fri, 31 May 2013 09:18:05 +0800 Message-ID: From: ma yc To: Miika Komu Content-Type: multipart/alternative; boundary=047d7bd768bc17885304ddf96354 Cc: "core@ietf.org" Subject: Re: [core] draft-shelby-core-resource-directory: call for adoption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 31 May 2013 01:18:07 -0000 --047d7bd768bc17885304ddf96354 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable =A3=AB1 2013/5/30 Miika Komu > +1 > > > On 05/28/2013 10:36 AM, Floris Van den Abeele wrote: > >> +1 >> >> Floris >> Op vr 24 mei 2013 17:03:01 CEST, Zach Shelby schreef: >> >>> Peter, >>> >>> I agree, as discussed in Orlando, we should integrate the DNS-SD >>> mapping to this document. >>> >>> Thanks, >>> Zach >>> >>> On May 21, 2013, at 9:47 AM, peter van der Stok >>> wrote: >>> >>> I certainly support this, but with the remark that relation to DNS >>>> and DNS-SD should be clarified in the document. >>>> This concerns how to handle name resolution with respect to >>>> information stored in resource directory >>>> and text from lynn draft about conversion of attribute values to RR >>>> in DNS >>>> >>>> Peter van der Stok >>>> >>>> Rahman, Akbar schreef op 2013-05-21 05:49: >>>> >>>>> +1 >>>>> Akbar >>>>> FROM: core-bounces@ietf.org [mailto:core-bounces@ietf.org] ON BEHALF >>>>> OF Andrew Mcgregor >>>>> SENT: Monday, May 20, 2013 8:26 PM >>>>> TO: core@ietf.org >>>>> SUBJECT: [core] draft-shelby-core-resource-**directory: call for >>>>> adoption >>>>> Consensus of the room in Orlando was to adopt >>>>> draft-shelby-core-resource-**directory as a working group document. >>>>> This >>>>> email is a call for confirmation of that consensus. Please respond if >>>>> you support the adoption of this document. >>>>> From the charter: >>>>> 5) A definition of how to use CoAP to advertise about or query for a >>>>> Device's description. This description may include the device name an= d >>>>> a list of its Resources, each with a URL, an interface description UR= I >>>>> (pointing e.g. to a Web Application Description Language (WADL) >>>>> document) and an optional name or identifier. The name taxonomy used >>>>> for this description will be consistent with other IETF work, >>>>> e.g. draft-cheshire-dnsext-dns-sd. >>>>> RFC 6690 has some of this; the resource directory would add protocol >>>>> elements on top of CoAP that enhance the "advertise about or query >>>>> for" aspect. >>>>> * Feb 2014 Submission to IESG of "CoRE Resource Directory" for >>>>> Proposed Standard >>>>> -- >>>>> Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128 >>>>> ______________________________**_________________ >>>>> 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 >>>> >>> >>> ______________________________**_________________ >> 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 > --047d7bd768bc17885304ddf96354 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
=A3=AB1


2013/5/30 Miika Komu <mkomu@cs.hut.fi>
+1


On 05/28/2013 10:36 AM, Floris Van den Abeele wrote:
+1

Floris
Op vr 24 mei 2013 17:03:01 CEST, Zach Shelby schreef:
Peter,

I agree, as discussed in Orlando, we should integrate the DNS-SD
mapping to this document.

Thanks,
Zach

On May 21, 2013, at 9:47 AM, peter van der Stok <stokcons@xs4all.nl>
wrote:

I certainly support this, but with the remark that relation to DNS
and DNS-SD should be clarified in the document.
This concerns how to handle name resolution with respect to
information stored in resource directory
and text from lynn draft about conversion of attribute values to RR
in DNS

Peter van der Stok

Rahman, Akbar schreef op 2013-05-21 05:49:
+1
Akbar
FROM: core-bounc= es@ietf.org [mailto:core-bounces@ietf.org] ON BEHALF
OF Andrew Mcgregor
SENT: Monday, May 20, 2013 8:26 PM
TO: core@ietf.org SUBJECT: [core] draft-shelby-core-resource-directory: call for adopt= ion
Consensus of the room in Orlando was to adopt
draft-shelby-core-resource-directory as a working group document. Th= is
email is a call for confirmation of that consensus. Please respond if
you support the adoption of this document.
 From the charter:
5) A definition of how to use CoAP to advertise about or query for a
Device's description. This description may include the device name and<= br> a list of its Resources, each with a URL, an interface description URI
(pointing e.g. to a Web Application Description Language (WADL)
document) and an optional name or identifier. The name taxonomy used
for this description will be consistent with other IETF work,
e.g. draft-cheshire-dnsext-dns-sd.
RFC 6690 has some of this; the resource directory would add protocol
elements on top of CoAP that enhance the "advertise about or query
for" aspect.
* Feb 2014 Submission to IESG of "CoRE Resource Directory" for Proposed Standard
--
Andrew McGregor | SRE | andrewmcgr@google.com | +61 4 8143 7128
_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
core@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/core

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


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

--047d7bd768bc17885304ddf96354--