From andre.becker@student.kit.edu Thu Feb 2 14:38:13 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A5521F867A for ; Thu, 2 Feb 2012 14:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UNOI1mHqSjb for ; Thu, 2 Feb 2012 14:38:12 -0800 (PST) Received: from mailout.scc.kit.edu (mailout.scc.kit.edu [129.13.185.202]) by ietfa.amsl.com (Postfix) with ESMTP id 9282721F8668 for ; Thu, 2 Feb 2012 14:38:12 -0800 (PST) Received: from KIT-MSX-03.kit.edu (kit-msx-03.kit.edu [172.21.117.13]) by scc-mailout-02.scc.kit.edu with esmtps (Exim 4.72 #1) id 1Rt5IB-0000EW-3h; Thu, 02 Feb 2012 23:38:11 +0100 Received: from [192.168.0.103] (172.21.117.6) by smtp.kit.edu (172.21.117.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 2 Feb 2012 23:38:10 +0100 Message-ID: <4F2B1051.3090809@student.kit.edu> Date: Thu, 2 Feb 2012 23:38:09 +0100 From: =?ISO-8859-15?Q?Andr=E9_Becker?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-15"; format=flowed Content-Transfer-Encoding: 8bit Subject: [P2PSIP] draft-ietf-p2psip-base-20: fragmentation and via lists X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 22:38:13 -0000 Hi, I'm currently implementing parts of RELOAD as my bachelor thesis and stumbled upon an ambiguity concerning answers to fragmented requests. Section 5.2.2 states: When a peer sends a response to a request using this routing algorithm, it MUST construct the destination list by reversing the order of the entries on the via list. This has the result that the response traverses the same peers as the request traversed, except in reverse order (symmetric routing). However, neither this section nor section 5.7 (which covers fragmentation) clarifies which via list should be used if the message was fragmented. As intermediate nodes handle each fragment independently, different fragments of the same request might take different routes in the overlay. So for the receiving node it remains unclear which via list should be used for the answer. Proposal: Add the following text to section 5.2.2: If the request was fragmented and for that had to be reassembled by the receiving node, the via lists of the fragments may differ. The receiving Node SHOULD use the via list of the last fragment, as determined by the last fragment bit; See Section 5.7 This should be a good approach, because for the last fragment's route the probability is high to still be available. Regards, Andr� From petithug@acm.org Fri Feb 3 09:06:21 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF5721F856A for ; Fri, 3 Feb 2012 09:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.301, 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 OUTTZGA8buvu for ; Fri, 3 Feb 2012 09:06:20 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 754B221F8545 for ; Fri, 3 Feb 2012 09:06:20 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id A66A520143 for ; Fri, 3 Feb 2012 16:51:29 +0000 (UTC) Message-ID: <4F2C1407.9050104@acm.org> Date: Fri, 03 Feb 2012 09:06:15 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: p2psip@ietf.org References: <20120106102358.8631.1310.idtracker@ietfa.amsl.com> In-Reply-To: <20120106102358.8631.1310.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Destination list [was Re: I-D Action: draft-ietf-p2psip-service-discovery-04.txt] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 17:06:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 One more comment on this draft: The RedirServiceProvider resource record has a field to store the Node-ID of the service provider, but I think that it would be better to use a Destination list instead. One of the reasons is that the provider can be a RELOAD client without direct routability (see -base section 3.2.1, second bullet). There is also future extensions that could require a Destination list. So I propose to change the definition to this: struct { RedirServiceProviderExtType type; Destination destination_list<0..2^16-1>; opaque namespace<0..2^16-1>; uint16 level; uint16 node; uint16 length; select (type) { /* This type may be extended */ } extension; } RedirServiceProvider; On 01/06/2012 02:23 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Peer-to-Peer Session > Initiation Protocol Working Group of the IETF. > > Title : Service Discovery Usage for REsource LOcation And > Discovery (RELOAD) Author(s) : Jouni Maenpaa Gonzalo Camarillo > Filename : draft-ietf-p2psip-service-discovery-04.txt Pages : 14 > Date : 2012-01-06 > > REsource LOcation and Discovery (RELOAD) does not define a generic service > discovery mechanism as part of the base protocol. This document defines > how the Recursive Distributed Rendezvous (ReDiR) service discovery > mechanism used in OpenDHT can be applied to RELOAD overlays to provide a > generic service discovery mechanism. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-p2psip-service-discovery-04.txt > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-p2psip-service-discovery-04.txt > > > - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPLBQFAAoJECnERZXWan7Ew54P/RaqTzxzwEe3OOJw3u7/BwWb zDu7g6ViTDjuZMYl6hMW0lPYaDyceAAlltEd+n6lBkmLPVydxaOSi4lF5GbCgHYz R4YPLj7/39fWQtmMtquY4AdsaJd1Skp4JlbtvTqiV9X7VJ+XLdgQRAKeHGMB6QfP pmNAq0K2udUDw8V7JsSW1whdVASBYhywvjzkEX5RRk2xs2ZwLxI649J7SmhWdCGd +MEaOtrI7uOZFJnCEoOlN/WFjqVBexWHmxzAKUHkWeNkiYmkhL3ifYvSCVO1rHeZ f071vvF+wsS6VYhGoDfo8PDm02gRSI3iIczlSFEEsE3VFIBIZMA5D00VOIhF5+7D /o8YNCeCDWLin68QrQhHRnwt7bS8hFtHDVlIjTAY5/42jWVe0VW8267ls/fnEHtl bG/+tmuceQL9RsdVO/R37GJs1LcphPbw12VFBBUVZQWe9FbjxRtl38m3cPNRjHHO yQechYu5mk2Ug/JMprLpWlLgLrV1UVPXsdl+Bbsnnie8qzr4kWfn2/NiXpgtmfiS vgRAysm1l9BpGTz5srMSkHCCftDbG6CoFceHGypiqOWi1lhVrzTHURoX4ohWV+LT XOKWImUEm40Ef4B/nVqtPpmhMDid88xBe7aUqse1nKnOCmOfHXjJDrrhmWGtmjZF mkW3okCjJtU2x1BcfwFb =HN7N -----END PGP SIGNATURE----- From rjsparks@nostrum.com Tue Feb 7 08:18:43 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F0D21F8655 for ; Tue, 7 Feb 2012 08:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, SPF_PASS=-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 5NTXDzmZM4EE for ; Tue, 7 Feb 2012 08:18:43 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 28F1221F87F1 for ; Tue, 7 Feb 2012 08:18:43 -0800 (PST) Received: from unexplicable.local (pool-173-57-95-103.dllstx.fios.verizon.net [173.57.95.103]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q17GIdfP067428 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 7 Feb 2012 10:18:39 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <4F314EE0.9030101@nostrum.com> Date: Tue, 07 Feb 2012 10:18:40 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: p2psip@ietf.org, p2psip-chairs@ietf.org, Marc Petit-Huguenin , Gonzalo Camarillo Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 173.57.95.103 is authenticated by a trusted mechanism) Subject: [P2PSIP] RELOAD testing at IETF83 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:18:43 -0000 Folks - We have made space available for RELOAD interop testing the weekend before IETF83. (Two half day sessions 0900-1300 Saturday and Sunday). Marc Petit-Huguenin will be coordinating the tests. Please let him know if you will be bringing an implementation. Thanks, RjS From petithug@acm.org Fri Feb 10 10:34:21 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6005621F87A9 for ; Fri, 10 Feb 2012 10:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.354 X-Spam-Level: X-Spam-Status: No, score=-102.354 tagged_above=-999 required=5 tests=[AWL=0.246, 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 KhMCBrdhzmto for ; Fri, 10 Feb 2012 10:34:20 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 4208A21F8786 for ; Fri, 10 Feb 2012 10:34:20 -0800 (PST) Received: from [IPv6:2406:a000:f007:6f00:213:d4ff:fe04:3e08] (unknown [IPv6:2406:a000:f007:6f00:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 8030F20289; Fri, 10 Feb 2012 18:18:59 +0000 (UTC) Message-ID: <4F356320.4020003@acm.org> Date: Fri, 10 Feb 2012 10:34:08 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: p2psip@ietf.org References: <4F314EE0.9030101@nostrum.com> In-Reply-To: <4F314EE0.9030101@nostrum.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: reload@implementers.org Subject: Re: [P2PSIP] RELOAD testing at IETF83 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 18:34:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Please let me know if you may be attending the RELOAD interop event in Paris. This is for planning purpose, so please send me an email even if you are not 100% sure about your plans - I need to have an idea of what kind of hardware I need to bring. I will create a private mailing-list for the discussion between the people who will announce their intention of attending. Also please note that you do not need a complete implementation to attend. The list of attendees and the bugs found in individual implementations will be kept confidential. You do not need to attend the IETF meeting to attend the interop event. Thanks. On 02/07/2012 08:18 AM, Robert Sparks wrote: > Folks - > > We have made space available for RELOAD interop testing the weekend before > IETF83. (Two half day sessions 0900-1300 Saturday and Sunday). Marc > Petit-Huguenin will be coordinating the tests. Please let him know if you > will be bringing an implementation. > - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPNWMeAAoJECnERZXWan7ERs4P/15HRXjisz/Yh1wlRa+ePZwJ Wi6Fo7KBkdoGQHF5PCsyzPTYRveKeX4/njtzqkCfAmdhlbJu48uefVGrxuaIScKi 08IYdtbP4SMpY7aKfJyELgjsUjVpGM3tPxvItK1sf1rAof03nMONfP+WwjEySn2y SUSqarvnWHXXRvZb4Sya8HPK6cTGPnjzeznBFq1p+b6x3OGxMLMpzU6JHnDVpZEQ ASTNYNAblMNQmpiidMPADtg2wbo+qEiR1sOPJLrU9q1DMJJnwwXKzMhsipyVxhn2 JQ1GMtxo/HGgMvixsjejBhszNlC7RaavIDqAiaojOtXX1BAwfl7fLWP4+pdnxtB6 idBpVrmR10ptTkrwgNNN8n0thTBZI3euLzAZU8aZrNJvapzTaj9KskavaT154C7F yvHwt+ceZZFAfVyUOVR+tt7uXqFxhIyBJjlsJaxj79BdyThu/PjYSLjc6MRj44QV H1BMK0PSDC/xJ/bFv4kfnqG7voisMw3kACjE0Ieydj++58CMddVQDpzglKZADEjX vWKpgeqGHwkguPm0Kb1YfmadyELYU1e3M+K0nZG+JjDBG8duLSg9PxgNf7ksdIzC xdGDPSJyASV59HuQDMVTtsx9EGqGhctDC8nY1izbGaU9bNs82HZ+4UPFX4uOfOb3 oGkC+z9ZMu6FLQHqqT5A =O95V -----END PGP SIGNATURE----- From michaelc@IDSSOFTWARE.COM Tue Feb 14 17:56:39 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5130621E8021 for ; Tue, 14 Feb 2012 17:56:39 -0800 (PST) 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 v-yZOip0xGqI for ; Tue, 14 Feb 2012 17:56:38 -0800 (PST) Received: from smtpoutwbe08.prod.mesa1.secureserver.net (smtpoutwbe08.prod.mesa1.secureserver.net [208.109.78.210]) by ietfa.amsl.com (Postfix) with SMTP id C265E21E8015 for ; Tue, 14 Feb 2012 17:56:38 -0800 (PST) Received: (qmail 18870 invoked from network); 15 Feb 2012 01:56:37 -0000 Received: from unknown (HELO localhost) (72.167.218.131) by smtpoutwbe08.prod.mesa1.secureserver.net with SMTP; 15 Feb 2012 01:56:37 -0000 Received: (qmail 10638 invoked by uid 99); 15 Feb 2012 01:56:37 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 67.58.151.223 User-Agent: Workspace Webmail 5.6.12 Message-Id: <20120214185636.61e8c06078a3b23a733c71e914c0b9df.6926866742.wbe@email03.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Tue, 14 Feb 2012 18:56:36 -0700 Mime-Version: 1.0 Subject: [P2PSIP] STUN keep-alive in AppAttach(ed) connection X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 01:56:39 -0000 Hi,=0A=0AIn base draft, section 5.5.2.1 (about AppAttach), it states,=0A=0A= "The application using connection set up with this request is=0A respon= sible for providing sufficiently frequent keep traffic for NAT=0A and Fir= ewall keep alive and for deciding when to close the=0A connection."=0A=0A= When such a connection is established by ICE, it means that it is=0Acapable= of multiplexing STUN bind and indication messages with other=0Amessages (a= pplication). Wouldn't it be natural for the RELOAD layer that=0Acompleted t= he ICE check and DTLS to also use STUN indication message to=0Akeep everyth= ing alive (firewall, connection, UDP session, etc.)? which=0Ais identical t= o that of a connection created from the Attach message.=0A=0AThis is an int= er-op issue that must be approved or disapproved by this=0Adraft, so I woul= d like to hear comments from the authors.=0A=0AThank you=0A=0A--Michael=0A From bbl@lowekamp.net Sat Feb 18 10:46:07 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FA921F85E1 for ; Sat, 18 Feb 2012 10:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hr6RDsUIL7CR for ; Sat, 18 Feb 2012 10:46:06 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 748F721F85E7 for ; Sat, 18 Feb 2012 10:46:06 -0800 (PST) Received: by obbwd15 with SMTP id wd15so6558147obb.31 for ; Sat, 18 Feb 2012 10:46:05 -0800 (PST) Received-SPF: pass (google.com: domain of bbl@lowekamp.net designates 10.182.75.102 as permitted sender) client-ip=10.182.75.102; Authentication-Results: mr.google.com; spf=pass (google.com: domain of bbl@lowekamp.net designates 10.182.75.102 as permitted sender) smtp.mail=bbl@lowekamp.net Received: from mr.google.com ([10.182.75.102]) by 10.182.75.102 with SMTP id b6mr9381437obw.9.1329590765870 (num_hops = 1); Sat, 18 Feb 2012 10:46:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.75.102 with SMTP id b6mr7915447obw.9.1329590765815; Sat, 18 Feb 2012 10:46:05 -0800 (PST) Received: by 10.182.159.10 with HTTP; Sat, 18 Feb 2012 10:46:05 -0800 (PST) In-Reply-To: <20120214185636.61e8c06078a3b23a733c71e914c0b9df.6926866742.wbe@email03.secureserver.net> References: <20120214185636.61e8c06078a3b23a733c71e914c0b9df.6926866742.wbe@email03.secureserver.net> Date: Sat, 18 Feb 2012 13:46:05 -0500 Message-ID: From: Bruce Lowekamp To: Michael Chen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnPpF81rx1riqBtSObeM00LcE2/uuu6+GNyDxgdycLdz0w6S8Lh/VSwU5IN/wrWvtWKO/2D Cc: p2psip@ietf.org Subject: Re: [P2PSIP] STUN keep-alive in AppAttach(ed) connection X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 18:46:07 -0000 Michael, IIRC, an earlier draft said that, but there were requests that the keepalive method be left up to the application using it, as that consumer may have its own keepalive method and it might even be hard to convert that application (and its implementation) to work on such a link, so it was changed to the current wording. Basically, any draft that specifies how an application would use a connection established via AppAttach needs to specify its keepalive method. Bruce On Tue, Feb 14, 2012 at 8:56 PM, Michael Chen wr= ote: > Hi, > > In base draft, section 5.5.2.1 (about AppAttach), it states, > > =C2=A0"The application using connection set up with this request is > =C2=A0 responsible for providing sufficiently frequent keep traffic for N= AT > =C2=A0 and Firewall keep alive and for deciding when to close the > =C2=A0 connection." > > When such a connection is established by ICE, it means that it is > capable of multiplexing STUN bind and indication messages with other > messages (application). Wouldn't it be natural for the RELOAD layer that > completed the ICE check and DTLS to also use STUN indication message to > keep everything alive (firewall, connection, UDP session, etc.)? which > is identical to that of a connection created from the Attach message. > > This is an inter-op issue that must be approved or disapproved by this > draft, so I would like to hear comments from the authors. > > Thank you > > --Michael > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From bbl@lowekamp.net Sat Feb 18 10:55:38 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C187421F85B8 for ; Sat, 18 Feb 2012 10:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 c7XfK6ttFal9 for ; Sat, 18 Feb 2012 10:55:38 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F90D21F85AE for ; Sat, 18 Feb 2012 10:55:38 -0800 (PST) Received: by obbwd15 with SMTP id wd15so6564240obb.31 for ; Sat, 18 Feb 2012 10:55:37 -0800 (PST) Received-SPF: pass (google.com: domain of bbl@lowekamp.net designates 10.60.7.102 as permitted sender) client-ip=10.60.7.102; Authentication-Results: mr.google.com; spf=pass (google.com: domain of bbl@lowekamp.net designates 10.60.7.102 as permitted sender) smtp.mail=bbl@lowekamp.net Received: from mr.google.com ([10.60.7.102]) by 10.60.7.102 with SMTP id i6mr5902227oea.9.1329591337974 (num_hops = 1); Sat, 18 Feb 2012 10:55:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.7.102 with SMTP id i6mr5055025oea.9.1329591337916; Sat, 18 Feb 2012 10:55:37 -0800 (PST) Received: by 10.182.159.10 with HTTP; Sat, 18 Feb 2012 10:55:37 -0800 (PST) In-Reply-To: <4F2B1051.3090809@student.kit.edu> References: <4F2B1051.3090809@student.kit.edu> Date: Sat, 18 Feb 2012 13:55:37 -0500 Message-ID: From: Bruce Lowekamp To: =?UTF-8?Q?Andr=C3=A9_Becker?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQncVTWlAg1hYvdU7n/cNIEQRfcG9j6UKhi7iVnUXGPv4ud9za4SlOKkuO2BMCsWDLBCBTS5 Cc: P2PSIP@ietf.org Subject: Re: [P2PSIP] draft-ietf-p2psip-base-20: fragmentation and via lists X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 18:55:38 -0000 Andr=C3=A9, I agree. Added some text to 5.2.2 Bruce On Thu, Feb 2, 2012 at 5:38 PM, Andr=C3=A9 Becker wrote: > Hi, > > I'm currently implementing parts of RELOAD as my bachelor thesis and > stumbled upon an ambiguity concerning answers to fragmented requests. > Section 5.2.2 states: > > =C2=A0 When a peer sends a response to a request using this routing > =C2=A0 algorithm, it MUST construct the destination list by reversing the > =C2=A0 order of the entries on the via list. =C2=A0This has the result th= at the > =C2=A0 response traverses the same peers as the request traversed, except= in > =C2=A0 reverse order (symmetric routing). > > However, neither this section nor section 5.7 (which covers fragmentation= ) > clarifies which via list should be used if the message was fragmented. As > intermediate nodes handle each fragment independently, different fragment= s > of the same request might take different routes in the overlay. So for th= e > receiving node it remains unclear which via list should be used for the > answer. > > Proposal: Add the following text to section 5.2.2: > > =C2=A0 =C2=A0If the request was fragmented and for that had to be reassem= bled by the > =C2=A0 =C2=A0receiving node, the via lists of the fragments may differ. T= he receiving > Node > =C2=A0 =C2=A0SHOULD use the via list of the last fragment, as determined = by the last > =C2=A0 =C2=A0fragment bit; See Section 5.7 > > This should be a good approach, because for the last fragment's route the > probability is high to still be available. > > Regards, > =C2=A0Andr=C3=A9 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From michaelc@idssoftware.com Sun Feb 19 07:28:22 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A707921F858A for ; Sun, 19 Feb 2012 07:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 hqIbr1Fk6cE1 for ; Sun, 19 Feb 2012 07:28:21 -0800 (PST) Received: from p3plsmtpa07-02.prod.phx3.secureserver.net (p3plsmtpa07-02.prod.phx3.secureserver.net [173.201.192.231]) by ietfa.amsl.com (Postfix) with SMTP id DDD6121F8587 for ; Sun, 19 Feb 2012 07:28:20 -0800 (PST) Received: (qmail 16404 invoked from network); 19 Feb 2012 15:28:15 -0000 Received: from unknown (32.175.148.184) by p3plsmtpa07-02.prod.phx3.secureserver.net (173.201.192.231) with ESMTP; 19 Feb 2012 15:28:14 -0000 Message-ID: From: "Michael Chen" To: "Bruce Lowekamp" Date: Sun, 19 Feb 2012 07:27:11 -0800 X-Mailer: Motorola android mail 1.0 MIME-Version: 1.0 X-Priority: 3 References: <20120214185636.61e8c06078a3b23a733c71e914c0b9df.6926866742.wbe@email03.secureserver.net> In-Reply-To: Content-Type: multipart/alternative; boundary="Motorola-A-Mail-rIY5A5Jo52sspq6r" Cc: p2psip@ietf.org Subject: Re: [P2PSIP] STUN keep-alive in AppAttach(ed) connection X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 15:28:22 -0000 --Motorola-A-Mail-rIY5A5Jo52sspq6r Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 QnJ1Y2UsCgpJbiB0aGF0IGNhc2UsIHRoZSBTSVAgdXNhZ2UgbXVzdCBpbmNsdWRlIGEgc2VjdGlv biBmb3Iga2VlcCBhbGl2ZS4gSSBkb24ndCBzZWUgb25lIGluIHRoZSBjdXJyZW50IHNpcC03IGRy YWZ0LgoKQWdhaW4sIHRoaXMgaXMgYSBjcml0aWNhbCBpbnRlci1vcCBpc3N1ZSB0aGF0IG11c3Qg YmUgZGVmaW5lZCBieSB0aGUgd29ya2luZyBncm91cCwgaWYgbm90IGluIGJhc2UsIHRoZW4gaW4g c2lwIHVzYWdlLgoKVGhhbmtzCgotLU1pY2hhZWwKClNlbnQgZnJvbSBteSBNb3Rvcm9sYSBBVFJJ WOKEoiA0RyBvbiBBVCZUCgotLS0tLU9yaWdpbmFsIG1lc3NhZ2UtLS0tLQpGcm9tOiBCcnVjZSBM b3dla2FtcCA8YmJsQGxvd2VrYW1wLm5ldD4KVG86IE1pY2hhZWwgQ2hlbiA8bWljaGFlbGNAaWRz c29mdHdhcmUuY29tPgpDYzogcDJwc2lwQGlldGYub3JnClNlbnQ6IFNhdCwgRmViIDE4LCAyMDEy IDE4OjQ2OjA1IEdNVCswMDowMApTdWJqZWN0OiBSZTogW1AyUFNJUF0gU1RVTiBrZWVwLWFsaXZl IGluIEFwcEF0dGFjaChlZCkgY29ubmVjdGlvbgoKTWljaGFlbCwKCklJUkMsIGFuIGVhcmxpZXIg ZHJhZnQgc2FpZCB0aGF0LCBidXQgdGhlcmUgd2VyZSByZXF1ZXN0cyB0aGF0IHRoZQprZWVwYWxp dmUgbWV0aG9kIGJlIGxlZnQgdXAgdG8gdGhlIGFwcGxpY2F0aW9uIHVzaW5nIGl0LCBhcyB0aGF0 CmNvbnN1bWVyIG1heSBoYXZlIGl0cyBvd24ga2VlcGFsaXZlIG1ldGhvZCBhbmQgaXQgbWlnaHQg ZXZlbiBiZSBoYXJkCnRvIGNvbnZlcnQgdGhhdCBhcHBsaWNhdGlvbiAoYW5kIGl0cyBpbXBsZW1l bnRhdGlvbikgdG8gd29yayBvbiBzdWNoIGEKbGluaywgc28gaXQgd2FzIGNoYW5nZWQgdG8gdGhl IGN1cnJlbnQgd29yZGluZy4gIEJhc2ljYWxseSwgYW55IGRyYWZ0CnRoYXQgc3BlY2lmaWVzIGhv dyBhbiBhcHBsaWNhdGlvbiB3b3VsZCB1c2UgYSBjb25uZWN0aW9uIGVzdGFibGlzaGVkCnZpYSBB cHBBdHRhY2ggbmVlZHMgdG8gc3BlY2lmeSBpdHMga2VlcGFsaXZlIG1ldGhvZC4KCkJydWNlCgoK T24gVHVlLCBGZWIgMTQsIDIwMTIgYXQgODo1NiBQTSwgTWljaGFlbCBDaGVuIDxtaWNoYWVsY0Bp ZHNzb2Z0d2FyZS5jb20+IHdyb3RlOgo+IEhpLAo+Cj4gSW4gYmFzZSBkcmFmdCwgc2VjdGlvbiA1 LjUuMi4xIChhYm91dCBBcHBBdHRhY2gpLCBpdCBzdGF0ZXMsCj4KPiDCoCJUaGUgYXBwbGljYXRp b24gdXNpbmcgY29ubmVjdGlvbiBzZXQgdXAgd2l0aCB0aGlzIHJlcXVlc3QgaXMKPiDCoCByZXNw b25zaWJsZSBmb3IgcHJvdmlkaW5nIHN1ZmZpY2llbnRseSBmcmVxdWVudCBrZWVwIHRyYWZmaWMg Zm9yIE5BVAo+IMKgIGFuZCBGaXJld2FsbCBrZWVwIGFsaXZlIGFuZCBmb3IgZGVjaWRpbmcgd2hl biB0byBjbG9zZSB0aGUKPiDCoCBjb25uZWN0aW9uLiIKPgo+IFdoZW4gc3VjaCBhIGNvbm5lY3Rp b24gaXMgZXN0YWJsaXNoZWQgYnkgSUNFLCBpdCBtZWFucyB0aGF0IGl0IGlzCj4gY2FwYWJsZSBv ZiBtdWx0aXBsZXhpbmcgU1RVTiBiaW5kIGFuZCBpbmRpY2F0aW9uIG1lc3NhZ2VzIHdpdGggb3Ro ZXIKPiBtZXNzYWdlcyAoYXBwbGljYXRpb24pLiBXb3VsZG4ndCBpdCBiZSBuYXR1cmFsIGZvciB0 aGUgUkVMT0FEIGxheWVyIHRoYXQKPiBjb21wbGV0ZWQgdGhlIElDRSBjaGVjayBhbmQgRFRMUyB0 byBhbHNvIHVzZSBTVFVOIGluZGljYXRpb24gbWVzc2FnZSB0bwo+IGtlZXAgZXZlcnl0aGluZyBh bGl2ZSAoZmlyZXdhbGwsIGNvbm5lY3Rpb24sIFVEUCBzZXNzaW9uLCBldGMuKT8gd2hpY2gKPiBp cyBpZGVudGljYWwgdG8gdGhhdCBvZiBhIGNvbm5lY3Rpb24gY3JlYXRlZCBmcm9tIHRoZSBBdHRh Y2ggbWVzc2FnZS4KPgo+IFRoaXMgaXMgYW4gaW50ZXItb3AgaXNzdWUgdGhhdCBtdXN0IGJlIGFw cHJvdmVkIG9yIGRpc2FwcHJvdmVkIGJ5IHRoaXMKPiBkcmFmdCwgc28gSSB3b3VsZCBsaWtlIHRv IGhlYXIgY29tbWVudHMgZnJvbSB0aGUgYXV0aG9ycy4KPgo+IFRoYW5rIHlvdQo+Cj4gLS1NaWNo YWVsCj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ IFAyUFNJUCBtYWlsaW5nIGxpc3QKPiBQMlBTSVBAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcAo= --Motorola-A-Mail-rIY5A5Jo52sspq6r Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PHN0eWxlIHR5cGU9InRleHQvY3NzIj5ib2R5IHt3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7IGJhY2tncm91bmQtY29sb3I6I2ZmZmZmZjt9PC9zdHlsZT48L2hlYWQ+PGJvZHk+PGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTZweCI+QnJ1Y2Us PGJyPjxicj5JbiB0aGF0IGNhc2UsIHRoZSBTSVAgdXNhZ2UgbXVzdCBpbmNsdWRlIGEgc2VjdGlv biBmb3Iga2VlcCBhbGl2ZS4gSSBkb24ndCBzZWUgb25lIGluIHRoZSBjdXJyZW50IHNpcC03IGRy YWZ0Ljxicj48YnI+QWdhaW4sIHRoaXMgaXMgYSBjcml0aWNhbCBpbnRlci1vcCBpc3N1ZSB0aGF0 IG11c3QgYmUgZGVmaW5lZCBieSB0aGUgd29ya2luZyBncm91cCwgaWYgbm90IGluIGJhc2UsIHRo ZW4gaW4gc2lwIHVzYWdlLjxicj48YnI+VGhhbmtzPGJyPjxicj4tLU1pY2hhZWw8YnI+PGJyPjxm b250IGNvbG9yPSIjMzMzMzMzIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxNHB4Ij48Zm9u dCBmYWNlPSJzYW5zLXNlcmlmIj5TZW50IGZyb20gbXkgTW90b3JvbGEgQVRSSVgmIzg0ODI7IDRH IG9uIEFUJmFtcDtUPC9mb250Pjwvc3Bhbj48L2k+PC9mb250PjwvZGl2Pjxicj48YnI+LS0tLS1P cmlnaW5hbCBtZXNzYWdlLS0tLS08YnI+PGJsb2NrcXVvdGUgc3R5bGU9IjsgYm9yZGVyLWxlZnQ6 IDJweCBzb2xpZCByZ2IoMTYsIDE2LCAyNTUpOyBtYXJnaW4tbGVmdDogNXB4OyBwYWRkaW5nLWxl ZnQ6IDVweDsiPjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE0cHgiPjxiPkZyb206IDwvYj5CcnVjZSBMb3dla2FtcCAmbHQ7YmJsQGxvd2VrYW1wLm5ldCZn dDs8Yj48YnI+VG86IDwvYj5NaWNoYWVsIENoZW4gJmx0O21pY2hhZWxjQGlkc3NvZnR3YXJlLmNv bSZndDs8Yj48YnI+Q2M6IDwvYj5wMnBzaXBAaWV0Zi5vcmc8Yj48YnI+U2VudDogPC9iPlNhdCwg RmViIDE4LCAyMDEyIDE4OjQ2OjA1IEdNVCswMDowMDxiPjxicj5TdWJqZWN0OiA8L2I+UmU6IFtQ MlBTSVBdIFNUVU4ga2VlcC1hbGl2ZSBpbiBBcHBBdHRhY2goZWQpIGNvbm5lY3Rpb248YnI+PGJy PjwvZGl2Pk1pY2hhZWwsPGJyPjxicj5JSVJDLCBhbiBlYXJsaWVyIGRyYWZ0IHNhaWQgdGhhdCwg YnV0IHRoZXJlIHdlcmUgcmVxdWVzdHMgdGhhdCB0aGU8YnI+a2VlcGFsaXZlIG1ldGhvZCBiZSBs ZWZ0IHVwIHRvIHRoZSBhcHBsaWNhdGlvbiB1c2luZyBpdCwgYXMgdGhhdDxicj5jb25zdW1lciBt YXkgaGF2ZSBpdHMgb3duIGtlZXBhbGl2ZSBtZXRob2QgYW5kIGl0IG1pZ2h0IGV2ZW4gYmUgaGFy ZDxicj50byBjb252ZXJ0IHRoYXQgYXBwbGljYXRpb24gKGFuZCBpdHMgaW1wbGVtZW50YXRpb24p IHRvIHdvcmsgb24gc3VjaCBhPGJyPmxpbmssIHNvIGl0IHdhcyBjaGFuZ2VkIHRvIHRoZSBjdXJy ZW50IHdvcmRpbmcuICBCYXNpY2FsbHksIGFueSBkcmFmdDxicj50aGF0IHNwZWNpZmllcyBob3cg YW4gYXBwbGljYXRpb24gd291bGQgdXNlIGEgY29ubmVjdGlvbiBlc3RhYmxpc2hlZDxicj52aWEg QXBwQXR0YWNoIG5lZWRzIHRvIHNwZWNpZnkgaXRzIGtlZXBhbGl2ZSBtZXRob2QuPGJyPjxicj5C cnVjZTxicj48YnI+PGJyPk9uIFR1ZSwgRmViIDE0LCAyMDEyIGF0IDg6NTYgUE0sIE1pY2hhZWwg Q2hlbiA8bWljaGFlbGNAaWRzc29mdHdhcmUuY29tPiB3cm90ZTo8YnI+PiBIaSw8YnI+Pjxicj4+ IEluIGJhc2UgZHJhZnQsIHNlY3Rpb24gPGEgaHJlZj0iNS41LjIuMSI+NS41LjIuMTwvYT4gKGFi b3V0IEFwcEF0dGFjaCksIGl0IHN0YXRlcyw8YnI+Pjxicj4+IMKgIlRoZSBhcHBsaWNhdGlvbiB1 c2luZyBjb25uZWN0aW9uIHNldCB1cCB3aXRoIHRoaXMgcmVxdWVzdCBpczxicj4+IMKgIHJlc3Bv bnNpYmxlIGZvciBwcm92aWRpbmcgc3VmZmljaWVudGx5IGZyZXF1ZW50IGtlZXAgdHJhZmZpYyBm b3IgTkFUPGJyPj4gwqAgYW5kIEZpcmV3YWxsIGtlZXAgYWxpdmUgYW5kIGZvciBkZWNpZGluZyB3 aGVuIHRvIGNsb3NlIHRoZTxicj4+IMKgIGNvbm5lY3Rpb24uIjxicj4+PGJyPj4gV2hlbiBzdWNo IGEgY29ubmVjdGlvbiBpcyBlc3RhYmxpc2hlZCBieSBJQ0UsIGl0IG1lYW5zIHRoYXQgaXQgaXM8 YnI+PiBjYXBhYmxlIG9mIG11bHRpcGxleGluZyBTVFVOIGJpbmQgYW5kIGluZGljYXRpb24gbWVz c2FnZXMgd2l0aCBvdGhlcjxicj4+IG1lc3NhZ2VzIChhcHBsaWNhdGlvbikuIFdvdWxkbid0IGl0 IGJlIG5hdHVyYWwgZm9yIHRoZSBSRUxPQUQgbGF5ZXIgdGhhdDxicj4+IGNvbXBsZXRlZCB0aGUg SUNFIGNoZWNrIGFuZCBEVExTIHRvIGFsc28gdXNlIFNUVU4gaW5kaWNhdGlvbiBtZXNzYWdlIHRv PGJyPj4ga2VlcCBldmVyeXRoaW5nIGFsaXZlIChmaXJld2FsbCwgY29ubmVjdGlvbiwgVURQIHNl c3Npb24sIGV0Yy4pPyB3aGljaDxicj4+IGlzIGlkZW50aWNhbCB0byB0aGF0IG9mIGEgY29ubmVj dGlvbiBjcmVhdGVkIGZyb20gdGhlIEF0dGFjaCBtZXNzYWdlLjxicj4+PGJyPj4gVGhpcyBpcyBh biBpbnRlci1vcCBpc3N1ZSB0aGF0IG11c3QgYmUgYXBwcm92ZWQgb3IgZGlzYXBwcm92ZWQgYnkg dGhpczxicj4+IGRyYWZ0LCBzbyBJIHdvdWxkIGxpa2UgdG8gaGVhciBjb21tZW50cyBmcm9tIHRo ZSBhdXRob3JzLjxicj4+PGJyPj4gVGhhbmsgeW91PGJyPj48YnI+PiAtLU1pY2hhZWw8YnI+Pjxi cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPj4g UDJQU0lQIG1haWxpbmcgbGlzdDxicj4+IFAyUFNJUEBpZXRmLm9yZzxicj4+IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcDwvYT48YnI+PC9ibG9ja3F1b3RlPjwvYm9k eT48L2h0bWw+DQo= --Motorola-A-Mail-rIY5A5Jo52sspq6r-- From petithug@acm.org Mon Feb 20 10:18:27 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E9E21F8618 for ; Mon, 20 Feb 2012 10:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.369 X-Spam-Level: X-Spam-Status: No, score=-102.369 tagged_above=-999 required=5 tests=[AWL=0.231, 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 J5hrUhdWWJfl for ; Mon, 20 Feb 2012 10:18:22 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 3895421F8619 for ; Mon, 20 Feb 2012 10:18:22 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id EDB7720A0D; Mon, 20 Feb 2012 18:02:26 +0000 (UTC) Message-ID: <4F428E6A.1020901@acm.org> Date: Mon, 20 Feb 2012 10:18:18 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0 MIME-Version: 1.0 To: p2psip@ietf.org References: <4F314EE0.9030101@nostrum.com> <4F356320.4020003@acm.org> In-Reply-To: <4F356320.4020003@acm.org> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: reload@implementers.org Subject: Re: [P2PSIP] [reload-implementers] RELOAD testing at IETF83 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 18:18:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I did not see much interest in the RELOAD interop in Paris so far. If you think that you will maybe attend, please send me a direct email, you will be able to cancel without problem. I really need to have an idea of the number of people attending for planning purpose. Thanks. On 02/10/2012 10:34 AM, Marc Petit-Huguenin wrote: > Please let me know if you may be attending the RELOAD interop event in > Paris. This is for planning purpose, so please send me an email even if you > are not 100% sure about your plans - I need to have an idea of what kind of > hardware I need to bring. I will create a private mailing-list for the > discussion between the people who will announce their intention of > attending. > > Also please note that you do not need a complete implementation to attend. > The list of attendees and the bugs found in individual implementations will > be kept confidential. You do not need to attend the IETF meeting to attend > the interop event. > > Thanks. > > On 02/07/2012 08:18 AM, Robert Sparks wrote: >> Folks - > >> We have made space available for RELOAD interop testing the weekend >> before IETF83. (Two half day sessions 0900-1300 Saturday and Sunday). >> Marc Petit-Huguenin will be coordinating the tests. Please let him know >> if you will be bringing an implementation. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPQo5oAAoJECnERZXWan7EVdkP/isLthNmqDqyWqPF9aiHIrKx 7Uvfn7jSGl6kQyt8zbsJ/w9bLJC0wPlabXRFmIyUDhWs6M040rKHAaiwjvPW33Pc kjSGkbMSGn50PVu72wbJwGYGSr3f7j/Bg/zm1nV0bBi3EmMuz71JebDrOWE2EMRN NIT1VkeczF6fIVnqaMCC0NeW1sr/gwpHaTOjiF+kHUBcGRNen4MEejGpmdbe8Ure K8YnbdLDMt9AEur5T87/gwuiUx0T/PyPG1rZB6iANeD1P8nVd58QtlY43q70ZWCN t9eQ/QsnwRowxm31NUulUWIZJgROgXN+fm0nAHqNFp4uYvF2iDF5VDOzxNXkLepN yuccZ9rZG1ROZ/hmMvLdLjmY75oVqsArPgePlNegUzfsShHyPRUkQPq1eLTaMdtA uPCYQa6NqoCt1eMdZrrCMGGSnCEDs6q2nYhl28d4lhxL/PPzvWtlxvtBTsh3ylCc 1LXHWVCt0V8guCpaxe23kfAL3ZiuoerXWUfsmwxLMweaG2/Y000rPXF7I2RSimtz /08gXIixhZWwahmkzV6Qc1p6vuMzOR8FpvyVStmuT/2YbDe+NkUvqrm6XQ36sYaP MUxPcoNoo5VQ+fSBG8P43BCxmGcXLz9boiVAm/hdF57YhmlxfYOghkbCUfSZk38T nC5oB1+WVPeI0qxBLwkx =gPS/ -----END PGP SIGNATURE----- From petithug@acm.org Mon Feb 20 11:29:54 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594B121F85E4 for ; Mon, 20 Feb 2012 11:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[AWL=0.227, 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 W8iz+mY91nLz for ; Mon, 20 Feb 2012 11:29:49 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id D56F421F85D7 for ; Mon, 20 Feb 2012 11:29:48 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 5E28C20A0D for ; Mon, 20 Feb 2012 19:13:54 +0000 (UTC) Message-ID: <4F429F29.1020708@acm.org> Date: Mon, 20 Feb 2012 11:29:45 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Anycast in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 19:29:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 At the last meeting of the WG in Taipei, there was discussion about Anycast in RELOAD. I will not summarize the discussion[1], but the conclusion was to send to the list two solutions for discussion: 1. Remove all text about Anycast. 2. Adds the IP address of the server to contact in the PingResponse (for Anycast the Ping transaction becomes an exception, and cannot be sent over DTLS). [1] The slides for this presentations are no longer available on the web site, and the minutes are incorrect. The best way to understand what it is about is to use the recording made by Meetecho under the name "Reload Update": http://ietf82.conf.meetecho.com/index.php/Recorded_Sessions - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPQp8bAAoJECnERZXWan7EAp4P/RttQCF5CCV5oLhGkohkoUwj U1Nn5epYIhmqwblVNL8VBwxNIG/3bz/Gth5YIDbjX55UAEOKzo5k5brnKLv00irs 6zk6GTQAxJFln4vxXw5RJYQgsl4CmNS1c9LCIoLntwOFqwnxIXloQx32xZZsv5Ul 2dUdpgSUA8qIG1F89N7CnZFFVt2Kz6r3fXVUF3OZGJYlEYSpgTJeiZmniVq3UrkB seCSqMhsogUHO8yjLkHPuAsqbyzAeJucn6bcByjn12UDko9x16yr/WYEh/aZqnWQ lmN2bWdBwciQ/cREHQ/Q9h8fvdjHu11gUK2bDU8ultcFTNtDfkpua7DTnqgLefjz mb+0ACmN5ukPOhJLWTVY7aM3emk9PwCQGVfFdxq/ycUb37MrVz/CDdmANI0kUz2c IcGtJkBzOf6GSrQcREkvAO5vIydEqfCk5bhc9N+RteNLHEVh36CMGhAa1mAe5Uyh TifzVOgiInAiB6aVflfukEVZXpFgswniUoEW7fOOihMQYEIcp1vkYIRCcTcDcP0/ tADKEhy1nAUY3WPyJ5tO9+bBs/4cF3x8V7yaTeuyqh9yi35JfQ9wF6FKEy0cs1sJ 8oXscnMKEmvGNdP6cZKtalWzBGsYsbHoVt+CRIxaG7m4lxm3sA6YuK0FlwsO6nmY YtEkf3czBVxjiD6JRLqW =SUj0 -----END PGP SIGNATURE----- From michaelc@idssoftware.com Mon Feb 20 18:20:55 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E5D21E8016 for ; Mon, 20 Feb 2012 18:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SulUvIa9rhkX for ; Mon, 20 Feb 2012 18:20:54 -0800 (PST) Received: from p3plsmtpa01-07.prod.phx3.secureserver.net (p3plsmtpa01-07.prod.phx3.secureserver.net [72.167.82.87]) by ietfa.amsl.com (Postfix) with SMTP id 69DB221F858D for ; Mon, 20 Feb 2012 18:20:54 -0800 (PST) Received: (qmail 8689 invoked from network); 21 Feb 2012 02:20:53 -0000 Received: from unknown (67.58.151.223) by p3plsmtpa01-07.prod.phx3.secureserver.net (72.167.82.87) with ESMTP; 21 Feb 2012 02:20:52 -0000 Message-ID: <62d453c4-e3dd-465c-834f-97c63cac768e@blur> From: "Michael Chen" To: p2psip@ietf.org Date: Mon, 20 Feb 2012 18:20:49 -0800 X-Mailer: Motorola android mail 1.0 MIME-Version: 1.0 X-Priority: 3 References: <4F314EE0.9030101@nostrum.com> <4F356320.4020003@acm.org> <4F428E6A.1020901@acm.org> In-Reply-To: <4F428E6A.1020901@acm.org> Content-Type: multipart/alternative; boundary="Motorola-A-Mail-WkJS8_9zQyFcHJ48" Cc: reload@implementers.org Subject: Re: [P2PSIP] [reload-implementers] RELOAD testing at IETF83 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 02:20:55 -0000 --Motorola-A-Mail-WkJS8_9zQyFcHJ48 Content-Type: text/plain; Format="Flowed"; DelSp="Yes"; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, We are painfully aware of many meaningless and bad designs in the draft being kept by firm hands of key members of this group, often citing "not to break existing implementations out there". Well, where are these existing implementation "out there"? Why aren't they participate in the inter-op? Cisco, Polycom, Skype, Huawei, anyone? Can we predict that couple years from now we all have to implement known bugs in order to inter-operate with Cisco phones or Polycom intercom "out there"? Thank you Michael Chen -----Original message----- From: Marc Petit-Huguenin To: p2psip@ietf.org Cc: reload@implementers.org Sent: Mon, Feb 20, 2012 18:18:18 GMT+00:00 Subject: Re: [P2PSIP] [reload-implementers] RELOAD testing at IETF83 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I did not see much interest in the RELOAD interop in Paris so far. If you think that you will maybe attend, please send me a direct email, you will be able to cancel without problem. I really need to have an idea of the number of people attending for planning purpose. Thanks. On 02/10/2012 10:34 AM, Marc Petit-Huguenin wrote: > Please let me know if you may be attending the RELOAD interop event in > Paris. This is for planning purpose, so please send me an email even if you > are not 100% sure about your plans - I need to have an idea of what kind of > hardware I need to bring. I will create a private mailing-list for the > discussion between the people who will announce their intention of > attending. > > Also please note that you do not need a complete implementation to attend. > The list of attendees and the bugs found in individual implementations will > be kept confidential. You do not need to attend the IETF meeting to attend > the interop event. > > Thanks. > > On 02/07/2012 08:18 AM, Robert Sparks wrote: >> Folks - > >> We have made space available for RELOAD interop testing the weekend >> before IETF83. (Two half day sessions 0900-1300 Saturday and Sunday). >> Marc Petit-Huguenin will be coordinating the tests. Please let him know >> if you will be bringing an implementation. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPQo5oAAoJECnERZXWan7EVdkP/isLthNmqDqyWqPF9aiHIrKx 7Uvfn7jSGl6kQyt8zbsJ/w9bLJC0wPlabXRFmIyUDhWs6M040rKHAaiwjvPW33Pc kjSGkbMSGn50PVu72wbJwGYGSr3f7j/Bg/zm1nV0bBi3EmMuz71JebDrOWE2EMRN NIT1VkeczF6fIVnqaMCC0NeW1sr/gwpHaTOjiF+kHUBcGRNen4MEejGpmdbe8Ure K8YnbdLDMt9AEur5T87/gwuiUx0T/PyPG1rZB6iANeD1P8nVd58QtlY43q70ZWCN t9eQ/QsnwRowxm31NUulUWIZJgROgXN+fm0nAHqNFp4uYvF2iDF5VDOzxNXkLepN yuccZ9rZG1ROZ/hmMvLdLjmY75oVqsArPgePlNegUzfsShHyPRUkQPq1eLTaMdtA uPCYQa6NqoCt1eMdZrrCMGGSnCEDs6q2nYhl28d4lhxL/PPzvWtlxvtBTsh3ylCc 1LXHWVCt0V8guCpaxe23kfAL3ZiuoerXWUfsmwxLMweaG2/Y000rPXF7I2RSimtz /08gXIixhZWwahmkzV6Qc1p6vuMzOR8FpvyVStmuT/2YbDe+NkUvqrm6XQ36sYaP MUxPcoNoo5VQ+fSBG8P43BCxmGcXLz9boiVAm/hdF57YhmlxfYOghkbCUfSZk38T nC5oB1+WVPeI0qxBLwkx =gPS/ -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip --Motorola-A-Mail-WkJS8_9zQyFcHJ48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PHN0eWxlIHR5cGU9InRleHQvY3NzIj5ib2R5IHt3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7IGJhY2tncm91bmQtY29sb3I6I2ZmZmZmZjt9PC9zdHlsZT48L2hlYWQ+PGJvZHk+PGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTZweCI+SGksPGJy Pjxicj5XZSBhcmUgcGFpbmZ1bGx5IGF3YXJlIG9mIG1hbnkgbWVhbmluZ2xlc3MgYW5kIGJhZCBk ZXNpZ25zIGluIHRoZSBkcmFmdCBiZWluZyBrZXB0IGJ5IGZpcm0gaGFuZHMgb2Yga2V5IG1lbWJl cnMgb2YgdGhpcyBncm91cCwgb2Z0ZW4gY2l0aW5nICJub3QgdG8gYnJlYWsgZXhpc3RpbmcgaW1w bGVtZW50YXRpb25zIG91dCB0aGVyZSIuPGJyPjxicj5XZWxsLCB3aGVyZSBhcmUgdGhlc2UgZXhp c3RpbmcgaW1wbGVtZW50YXRpb24gIm91dCB0aGVyZSI/IFdoeSBhcmVuJ3QgdGhleSBwYXJ0aWNp cGF0ZSBpbiB0aGUgaW50ZXItb3A/PGJyPjxicj5DaXNjbywgUG9seWNvbSwgU2t5cGUsIEh1YXdl aSwgYW55b25lPzxicj48YnI+Q2FuIHdlIHByZWRpY3QgdGhhdCBjb3VwbGUgeWVhcnMgZnJvbSBu b3cgd2UgYWxsIGhhdmUgdG8gaW1wbGVtZW50IGtub3duIGJ1Z3MgaW4gb3JkZXIgdG8gaW50ZXIt b3BlcmF0ZSB3aXRoIENpc2NvIHBob25lcyBvciBQb2x5Y29tIGludGVyY29tICJvdXQgdGhlcmUi Pzxicj48YnI+VGhhbmsgeW91PGJyPjxicj5NaWNoYWVsIENoZW48YnI+PC9kaXY+PGJyPi0tLS0t T3JpZ2luYWwgbWVzc2FnZS0tLS0tPGJyPjxibG9ja3F1b3RlIHN0eWxlPSI7IGJvcmRlci1sZWZ0 OiAycHggc29saWQgcmdiKDE2LCAxNiwgMjU1KTsgbWFyZ2luLWxlZnQ6IDVweDsgcGFkZGluZy1s ZWZ0OiA1cHg7Ij48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxNHB4Ij48Yj5Gcm9tOiA8L2I+TWFyYyBQZXRpdC1IdWd1ZW5pbiAmbHQ7cGV0aXRodWdAYWNt Lm9yZyZndDs8Yj48YnI+VG86IDwvYj5wMnBzaXBAaWV0Zi5vcmc8Yj48YnI+Q2M6IDwvYj5yZWxv YWRAaW1wbGVtZW50ZXJzLm9yZzxiPjxicj5TZW50OiA8L2I+TW9uLCBGZWIgMjAsIDIwMTIgMTg6 MTg6MTggR01UKzAwOjAwPGI+PGJyPlN1YmplY3Q6IDwvYj5SZTogW1AyUFNJUF0gW3JlbG9hZC1p bXBsZW1lbnRlcnNdICBSRUxPQUQgdGVzdGluZyBhdCBJRVRGODM8YnI+PGJyPjwvZGl2Pi0tLS0t QkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0tLS08YnI+SGFzaDogU0hBMjU2PGJyPjxicj5JIGRp ZCBub3Qgc2VlIG11Y2ggaW50ZXJlc3QgaW4gdGhlIFJFTE9BRCBpbnRlcm9wIGluIFBhcmlzIHNv IGZhci4gIElmIHlvdTxicj50aGluayB0aGF0IHlvdSB3aWxsIG1heWJlIGF0dGVuZCwgcGxlYXNl IHNlbmQgbWUgYSBkaXJlY3QgZW1haWwsIHlvdSB3aWxsIGJlPGJyPmFibGUgdG8gY2FuY2VsIHdp dGhvdXQgcHJvYmxlbS4gIEkgcmVhbGx5IG5lZWQgdG8gaGF2ZSBhbiBpZGVhIG9mIHRoZSBudW1i ZXI8YnI+b2YgcGVvcGxlIGF0dGVuZGluZyBmb3IgcGxhbm5pbmcgcHVycG9zZS48YnI+PGJyPlRo YW5rcy48YnI+PGJyPk9uIDAyLzEwLzIwMTIgMTA6MzQgQU0sIE1hcmMgUGV0aXQtSHVndWVuaW4g d3JvdGU6PGJyPj4gUGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSBtYXkgYmUgYXR0ZW5kaW5nIHRo ZSBSRUxPQUQgaW50ZXJvcCBldmVudCBpbjxicj4+IFBhcmlzLiBUaGlzIGlzIGZvciBwbGFubmlu ZyBwdXJwb3NlLCBzbyBwbGVhc2Ugc2VuZCBtZSBhbiBlbWFpbCBldmVuIGlmIHlvdTxicj4+IGFy ZSBub3QgMTAwJSBzdXJlIGFib3V0IHlvdXIgcGxhbnMgLSBJIG5lZWQgdG8gaGF2ZSBhbiBpZGVh IG9mIHdoYXQga2luZCBvZjxicj4+IGhhcmR3YXJlIEkgbmVlZCB0byBicmluZy4gIEkgd2lsbCBj cmVhdGUgYSBwcml2YXRlIG1haWxpbmctbGlzdCBmb3IgdGhlPGJyPj4gZGlzY3Vzc2lvbiBiZXR3 ZWVuIHRoZSBwZW9wbGUgd2hvIHdpbGwgYW5ub3VuY2UgdGhlaXIgaW50ZW50aW9uIG9mPGJyPj4g YXR0ZW5kaW5nLjxicj4+IDxicj4+IEFsc28gcGxlYXNlIG5vdGUgdGhhdCB5b3UgZG8gbm90IG5l ZWQgYSBjb21wbGV0ZSBpbXBsZW1lbnRhdGlvbiB0byBhdHRlbmQuIDxicj4+IFRoZSBsaXN0IG9m IGF0dGVuZGVlcyBhbmQgdGhlIGJ1Z3MgZm91bmQgaW4gaW5kaXZpZHVhbCBpbXBsZW1lbnRhdGlv bnMgd2lsbDxicj4+IGJlIGtlcHQgY29uZmlkZW50aWFsLiAgWW91IGRvIG5vdCBuZWVkIHRvIGF0 dGVuZCB0aGUgSUVURiBtZWV0aW5nIHRvIGF0dGVuZDxicj4+IHRoZSBpbnRlcm9wIGV2ZW50Ljxi cj4+IDxicj4+IFRoYW5rcy48YnI+PiA8YnI+PiBPbiAwMi8wNy8yMDEyIDA4OjE4IEFNLCBSb2Jl cnQgU3BhcmtzIHdyb3RlOjxicj4+PiBGb2xrcyAtPGJyPj4gPGJyPj4+IFdlIGhhdmUgbWFkZSBz cGFjZSBhdmFpbGFibGUgZm9yIFJFTE9BRCBpbnRlcm9wIHRlc3RpbmcgdGhlIHdlZWtlbmQ8YnI+ Pj4gYmVmb3JlIElFVEY4My4gKFR3byBoYWxmIGRheSBzZXNzaW9ucyAwOTAwLTEzMDAgU2F0dXJk YXkgYW5kIFN1bmRheSkuPGJyPj4+IE1hcmMgUGV0aXQtSHVndWVuaW4gd2lsbCBiZSBjb29yZGlu YXRpbmcgdGhlIHRlc3RzLiBQbGVhc2UgbGV0IGhpbSBrbm93PGJyPj4+IGlmIHlvdSB3aWxsIGJl IGJyaW5naW5nIGFuIGltcGxlbWVudGF0aW9uLjxicj48YnI+LSAtLSA8YnI+TWFyYyBQZXRpdC1I dWd1ZW5pbjxicj5QZXJzb25hbCBlbWFpbDogbWFyY0BwZXRpdC1odWd1ZW5pbi5vcmc8YnI+UHJv ZmVzc2lvbmFsIGVtYWlsOiBwZXRpdGh1Z0BhY20ub3JnPGJyPkJsb2c6IDxhIGhyZWY9Imh0dHA6 Ly9ibG9nLm1hcmMucGV0aXQtaHVndWVuaW4ub3JnIj5odHRwOi8vYmxvZy5tYXJjLnBldGl0LWh1 Z3VlbmluLm9yZzwvYT48YnI+LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS08YnI+VmVyc2lv bjogR251UEcgdjEuNC4xMSAoR05VL0xpbnV4KTxicj48YnI+aVFJY0JBRUJDQUFHQlFKUFFvNW9B QW9KRUNuRVJaWFdhbjdFVmRrUC9pc0x0aE5tcURxeVdxUEY5YWlISXJLeDxicj43VXZmbjdqU0ds NmtReXQ4emJzSi93OWJMSkMwd1BsYWJYUkZtSXlVRGhXczZNMDQwcktIQWFpd2p2UFczM1BjPGJy PmtqU0drYk1TR241MFBWdTcyd2JKd0dZR1NyM2Y3ai9CZy96bTFuVjBiQmkzRW1NdXo3MUplYkRy T1dFMkVNUk48YnI+TklUMVZrZWN6RjZmSVZucWFNQ0MwTmVXMXNyL2d3cEhhVE9qaUYra0hVQmNH Uk5lbjRNRWVqR3BtZGJlOFVyZTxicj5LOFluYmRMRE10OUFFdXI1VDg3L2d3dWlVeDBUL1B5UEcx clpCNmlBTmVEMVA4blZkNThRdGxZNDNxNzBaV0NOPGJyPnQ5ZVEvUXNud1Jvd3htMzFOVXVsVVdJ WkpnUk9nWE4rZm0wbkFIcU5GcDR1WXZGMmlERjVWRE96eE5Ya0xlcE48YnI+eXVjY1o5clpHMVJP Wi9obU12TGRMam1ZNzVvVnFzQXJQZ2VQbE5lZ1V6ZnNTaEh5UFJVa1FQcTFlTFRhTWR0QTxicj51 UENZUWE2TnFvQ3QxZU1kWnJyQ01HR1NuQ0VEczZxMm5ZaGwyOGQ0bGh4TC9QUHp2V3RseHZ0QlRz aDN5bENjPGJyPjFMWEhXVkN0MFY4Z3VDcGF4ZTIza2ZBTDNaaXVvZXJYV1Vmc213eExNd2VhRzIv WTAwMHJQWEY3STJSU2ltdHo8YnI+LzA4Z1hJaXhoWld3YWhta3pWNlFjMXA2dnVNek9SOEZwdnlW U3RtdVQvMlliRGUrTmtVdnFybTZYUTM2c1lhUDxicj5NVXhQY29Ob281VlErZlNCRzhQNDNCQ3ht R2NYTHo5Ym9pVkFtL2hkRjU3WWhtbHhmWU9naGtiQ1VmU1prMzhUPGJyPm5DNW9CMStXVlBlSTBx eEJMd2t4PGJyPj1nUFMvPGJyPi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLTxicj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5QMlBTSVAgbWFpbGlu ZyBsaXN0PGJyPlAyUFNJUEBpZXRmLm9yZzxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9wMnBzaXA8L2E+PGJyPjwvYmxvY2txdW90ZT48L2JvZHk+PC9odG1sPg0K --Motorola-A-Mail-WkJS8_9zQyFcHJ48-- From roland.bless@kit.edu Tue Feb 21 02:22:23 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4753C21F8627 for ; Tue, 21 Feb 2012 02:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnZNt7iqU1ql for ; Tue, 21 Feb 2012 02:22:22 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 466A121F8609 for ; Tue, 21 Feb 2012 02:22:21 -0800 (PST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1RzmrE-0006pN-OB for ; Tue, 21 Feb 2012 11:22:20 +0100 Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by irams1.ira.uni-karlsruhe.de with esmtp port 25 for id 1RzmrE-0005q8-JZ; Tue, 21 Feb 2012 11:22:04 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 66650A804CE for ; Tue, 21 Feb 2012 11:22:04 +0100 (CET) Message-ID: <4F43704C.3040701@kit.edu> Date: Tue, 21 Feb 2012 11:22:04 +0100 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Lightning/1.0b2 Thunderbird/3.1.19 MIME-Version: 1.0 To: p2psip@ietf.org References: <4F314EE0.9030101@nostrum.com> <4F356320.4020003@acm.org> <4F428E6A.1020901@acm.org> In-Reply-To: <4F428E6A.1020901@acm.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1329819740.350680000 Subject: Re: [P2PSIP] [reload-implementers] RELOAD testing at IETF83 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 10:22:23 -0000 Hi, On 20.02.2012 19:18, Marc Petit-Huguenin wrote: > I did not see much interest in the RELOAD interop in Paris so far. If you > think that you will maybe attend, please send me a direct email, you will be > able to cancel without problem. I really need to have an idea of the number > of people attending for planning purpose. Basically, we are interested, but our implementation isn't probably mature enough for an interop at this IETF (amy at the next one). Furthermore, I'll arrive on Sunday and can't make it on Saturday. Regards, Roland From petithug@acm.org Tue Feb 21 08:51:32 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944F221F884B for ; Tue, 21 Feb 2012 08:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.223, 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 ScC9qY9zHGjH for ; Tue, 21 Feb 2012 08:51:25 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id A65FB21F883D for ; Tue, 21 Feb 2012 08:51:24 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id AEA22202DD; Tue, 21 Feb 2012 16:35:25 +0000 (UTC) Message-ID: <4F43CB88.6010506@acm.org> Date: Tue, 21 Feb 2012 08:51:20 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0 MIME-Version: 1.0 To: Michael Chen References: <4F314EE0.9030101@nostrum.com> <4F356320.4020003@acm.org> <4F428E6A.1020901@acm.org> <62d453c4-e3dd-465c-834f-97c63cac768e@blur> In-Reply-To: <62d453c4-e3dd-465c-834f-97c63cac768e@blur> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: reload@implementers.org, p2psip@ietf.org Subject: Re: [P2PSIP] [reload-implementers] RELOAD testing at IETF83 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 16:51:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/20/2012 06:20 PM, Michael Chen wrote: > Hi, > > We are painfully aware of many meaningless and bad designs in the draft > being kept by firm hands of key members of this group, often citing "not to > break existing implementations out there". > > Well, where are these existing implementation "out there"? Why aren't they > participate in the inter-op? That a very good point. > > Cisco, Polycom, Skype, Huawei, anyone? > > Can we predict that couple years from now we all have to implement known > bugs in order to inter-operate with Cisco phones or Polycom intercom "out > there"? Yes, and the sad part is that there is a mechanism in RELOAD to cope with early implementations: Just increment the version number each time a new I-D breaks interoperability (This is exactly what hyby did for Websockets, which seems to work very well). And BTW, when published as RFC, the RELOAD version *will* increment to 0x10, which means that none of the early implementations will work with this version anyway. > > Thank you > > Michael Chen > > -----Original message----- > > *From: *Marc Petit-Huguenin * To: *p2psip@ietf.org* Cc: > *reload@implementers.org* Sent: *Mon, Feb 20, 2012 18:18:18 GMT+00:00* > Subject: *Re: [P2PSIP] [reload-implementers] RELOAD testing at IETF83 > > I did not see much interest in the RELOAD interop in Paris so far. If you > think that you will maybe attend, please send me a direct email, you will > be able to cancel without problem. I really need to have an idea of the > number of people attending for planning purpose. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPQ8uHAAoJECnERZXWan7EnwMQANcXQMdEapCn4/yGnv7xHOgD nBq+K7ReKkhUclRXWofoMRm2WTenG3Ubeh5SxM3OApDlQI18lD/LXUTMqw9kzx+z FeS5x7U8j6poVL605isog+FAI+39o1+fivd8WwBAEnVZRw+Y7EOoc/wuKPKwWXSr 5G1sb5l2ZCzSNg6xH8FdXt5JdcKhJzq87KHaF4DtLs3/4Cy4UVFZWlkXki35s5d8 /uPWcIgaUt8y/eKUsZOgY4gVMON4DBbugzKBtlnN+mLL4A16ajYz6L+OPnnnFWEU Lnek9krFIbYuZfdFS1JHGpjm01G0IFDPUWox+vQBmhlT+D/HQ33+KLGywknqCEOi iYpwz7hs6K996iDzpdcubbAUgLfqYFqwd7Gokt3pAPQVOq0zTqR8nOGorR9rvMV6 wRIuYChY2bcnXxBJtbVu3fJKRkRX0UBTB2Ed/oDIv+TsGbNC7bp8XyMvSRtaJji/ 4J/3Twi5JVqnxAI1vQMz70c1/q0aePDJmGknArgkLOyMN7ap5hcsUjnNsvOiN0k5 G0DrqvGZbYjGCY4MrstDYJRUZ8SHyI+wIJSw16s/GVwwPVknhyLxra/FJ1NvnX4A K2z2uZNY/hazRZVUS5gU6NpCrX1RbcEQSJkNijrd72NVxZEhORYronXQDSf9nRlG lY6D6yhX8aNOcbWkgI0v =XoR7 -----END PGP SIGNATURE----- From jaime.j.jimenez@ericsson.com Fri Feb 24 03:01:52 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B75221F87B3 for ; Fri, 24 Feb 2012 03:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 DR-+5wGCwjgh for ; Fri, 24 Feb 2012 03:01:51 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 462F121F8746 for ; Fri, 24 Feb 2012 03:01:51 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-44-4f476e1ef39a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id FB.D0.01970.E1E674F4; Fri, 24 Feb 2012 12:01:50 +0100 (CET) Received: from ESESSCMS0358.eemea.ericsson.se ([169.254.1.235]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Fri, 24 Feb 2012 12:01:50 +0100 From: =?iso-8859-1?Q?Jaime_Jim=E9nez_J?= To: "p2psip@ietf.org" Date: Fri, 24 Feb 2012 12:01:49 +0100 Thread-Topic: draft-jimenez-p2psip-coap-reload Thread-Index: Aczy47U5lbt5nhmxRb2okKqNE4/7BA== Message-ID: <98E76AB9-89FA-4BD0-87F7-C49E94D0829B@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_E8365A68-3549-4E83-9691-04DFAE5BA21E"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [P2PSIP] draft-jimenez-p2psip-coap-reload X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 11:01:52 -0000 --Apple-Mail=_E8365A68-3549-4E83-9691-04DFAE5BA21E Content-Type: multipart/alternative; boundary="Apple-Mail=_93F38718-1DCD-46AE-BBD1-15FD08C754CD" --Apple-Mail=_93F38718-1DCD-46AE-BBD1-15FD08C754CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, we just submitted a draft to the p2psip WG that proposes a CoAP Usage = for RELOAD. Constrained Application Protocol (CoAP) is a specialized web transfer = protocol. It realizes the Representational State Transfer (REST) = architecture for the most constrained nodes, such as sensors and = actuators.=20 The CoAP Usage provides the functionality to federate Wireless Sensor = Networks (WSN) in a peer-to-peer fashion. It also provides a rendezvous = service for CoAP Nodes and caching of sensor information.=20 http://tools.ietf.org/id/draft-jimenez-p2psip-coap-reload-00.txt=20 Best Regards, -- Jaime --Apple-Mail=_93F38718-1DCD-46AE-BBD1-15FD08C754CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Constrained Application Protocol = (CoAP) is a specialized web transfer protocol. It realizes the = Representational State Transfer (REST) architecture for the most = constrained nodes, such as sensors and = actuators. 

The CoAP = Usage provides the functionality to federate Wireless Sensor = Networks (WSN) in a peer-to-peer fashion. =  It also provides a rendezvous service for = CoAP Nodes and caching of sensor information. =


Best Regards,
-- = Jaime

= --Apple-Mail=_93F38718-1DCD-46AE-BBD1-15FD08C754CD-- --Apple-Mail=_E8365A68-3549-4E83-9691-04DFAE5BA21E Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICEQCaObzOR9uy6LZk9ciUsJXTMA0GCSqGSIb3DQEBBQUAMDkxETAPBgNVBAoMCEVy aWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDEwHhcNMTExMDA3MDgy NDA3WhcNMTQxMDA3MDgyNDA1WjBqMREwDwYDVQQKDAhFcmljc3NvbjEWMBQGA1UEAwwNSmFpbWUg SmltZW5lejEQMA4GA1UEBRMHZWphamltbjErMCkGCSqGSIb3DQEJARYcamFpbWUuai5qaW1lbmV6 QGVyaWNzc29uLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzS0HqaJg8DzcIQIMn3U7 MMfhgUlP8eETQflo8p6+CtB6QePChaU+7igtsK28NwE3keNwGXAWulJlg4ScqvTHuhQkaCHpq1eZ X18exYkpzI2dw6LIVcJwVauWSIR7TEeuIHzD71ekDDdQGSFYMnhbKc+mTfWCpZ3zT9NH2IGok4kC AwEAAaOCAYgwggGEMIHABgNVHR8EgbgwgbUwgbKgga+ggayGN2h0dHA6Ly9jcmwudHJ1c3QudGVs aWEuY29tL0VyaWNzc29uTkxJbmRpdmlkdWFsQ0EwMS5jcmyGcWxkYXA6Ly9sZGFwLnRydXN0LnRl bGlhLmNvbS9jbj1Fcmljc3NvbiUyME5MJTIwSW5kaXZpZHVhbCUyMENBMDEsbz1Fcmljc3Nvbj9j ZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlMCcGA1UdEQQgMB6BHGphaW1lLmou amltZW5lekBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFLs/X1d9fU7fNptr Jf+FMGSwhLB8MB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAlAPQI4BnKBEx2hYo3J+WU0+ZB38sRl9P39BEZXv6pFeLP1kB 0b/oe20EQshlRuzttkwMoQ2ibW70LM6+dALQ+LzYNXVxH8RUnj7ZsyLHj3kmRiT9oFi0ytayn1+O quoC1njz5q2ULAInUIw5mfKZ0Rldm0TjtmhzMTjTNGyKSHU9fi8Ra+zu6CeXg/wEVSVy6XX9Chqc sL3WkTRea2juYj+xOVnz75nybxfAp9VRdGi7OGc8dOt2rVaf18LnPbgyzNUMUJfKvETHJrT6IG7P zH0lY3o7svmyr01evx/7tFq4pBoq9vYtYCzQ2Jf31WzbJu0HEzgNZAHnAK8AMNqbjDCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICFTCCAhECAQEwTjA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhEAmjm8zkfbsui2ZPXIlLCV0zAJBgUrDgMCGgUAoIIBHTAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAyMjQxMTAxNTBaMCMGCSqG SIb3DQEJBDEWBBTzh3mwB/V1n80OOCvaAjJnEecdtTBdBgkrBgEEAYI3EAQxUDBOMDkxETAPBgNV BAoMCEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEQCaObzO R9uy6LZk9ciUsJXTMF8GCyqGSIb3DQEJEAILMVCgTjA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIG A1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAxAhEAmjm8zkfbsui2ZPXIlLCV0zANBgkq hkiG9w0BAQEFAASBgGzWmFCTKP5urASwQbOPAOfFxZmHbYMxR+EYkHvlJHmuW4LNsHknlQmx+sA8 z2JoDsacgCEa2snXCM4AkhH6FA66nZTuD1N87K/ol1kg20NhbhKs/e37CILJ1beYyPiKnhb4ZO/s MLdN56L0BuBebl0mZd1teKNRUWRInawVLh21AAAAAAAA --Apple-Mail=_E8365A68-3549-4E83-9691-04DFAE5BA21E-- From petithug@acm.org Fri Feb 24 06:50:17 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C105921F86A3 for ; Fri, 24 Feb 2012 06:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.239 X-Spam-Level: X-Spam-Status: No, score=-102.239 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oVIO3a31P29 for ; Fri, 24 Feb 2012 06:50:17 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 736BE21F8664 for ; Fri, 24 Feb 2012 06:50:16 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 2A67C20137; Fri, 24 Feb 2012 14:34:05 +0000 (UTC) Message-ID: <4F47A3A3.1090505@acm.org> Date: Fri, 24 Feb 2012 06:50:11 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0 MIME-Version: 1.0 To: =?UTF-8?B?SmFpbWUgSmltw6luZXogSg==?= References: <98E76AB9-89FA-4BD0-87F7-C49E94D0829B@ericsson.com> In-Reply-To: <98E76AB9-89FA-4BD0-87F7-C49E94D0829B@ericsson.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] draft-jimenez-p2psip-coap-reload X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 14:50:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Some comments: 1. Section 4: ".. is calculated as a SHA-1 hash..." This is defined only for CHORD-RELOAD, other algorithms may use a different way of computing the Resource-ID (unless only CHORD-RELOAD can be used with this usage, in which case it should be explicitly stated). Also, URIs are case insensitive, so they need to be canonicalized before been converted to a Resource-ID. 2. Figure 2: Messages 4 and 5 should be AppAttach. 200 OK has no meaning in RELOAD (messages 6 and 7). 3. Section 7, last paragraph: "The only difference is data_value..." data_value is never used. 4. Section 7, CoAPCaching definition The values to select coap_caching_type are never defined (coap_caching_type should be an enum). 5. Section 7.1 Definition of ProxyCache, SensorEntry [] should be redefined to carry the length (<0..length>) 6. Section 7.1 Definition of SensorEntry [] should be redefined to carry the length (<0..length>) "opaque coap_uri;" should define a length (e.g. opaque coap_uri<0..2^16-1>) 7. Section 7.2 Definition of SensorCache [] should be redefined to carry the length (<0..length>) 8. Section 7.2 "last_awake" definition Perhaps it's simpler to use the same format than RELOAD to store time, i.e. milliseconds since the epoch. 9. Section 7.2 Definition of SensorValue "value" should be redefined as having a length. 10. Section 7.2 "measurement_time" definition Unit is not defined. 11. Section 7.2 "lifetime" definition Unit is not defined. 12. Section 8.1 "...which contains a Node-ID..." CoAPRegistration does not contain a Node-ID. 13. Section 8.1 URI-NODE-MATCH This is a new access control policy, so it needs to be defined. 14. Section 8.1 Definition of CoAPRegistration Because of the fact that some RELOAD client may not be directly routable (second bullet of RELOAD section 3.2.1), I would add a "Destination destination_list<0..2^16-1>;" field. 15. Section 8.1 Definition of CoAPRegistration The () notation for coap_uris is not defined, but the two lines can be replaced by this: opaque coap_uris<0..2^16-1>; There is no explanation on the internal format of coap_uris, for example that the uris must be separated (or terminated?) with ";". 16. Section 8.2 "which contains a Node-ID..." CoAPCaching does not contain a Node-ID (ProxyCache does). 17. Section 8.2 URI-MATCH This is a new access control policy, so it needs to be defined. Nits - ---- - - Section 4: s/registering register/registering/ s/RESOURCE-ID/Resource-ID/ - - Section 5: s/RESOURCE-ID/Resource-ID/ - - Section 7.2: s/NodeID/Node-ID/ On 02/24/2012 03:01 AM, Jaime Jiménez J wrote: > Hello, > > we just submitted a draft to the p2psip WG that proposes a CoAP Usage for > RELOAD. > > Constrained Application Protocol (CoAP) is a specialized web transfer > protocol. It realizes the Representational State Transfer (REST) > architecture for the most constrained nodes, such as sensorsand actuators. > > > The CoAP Usageprovides the functionality to federate Wireless Sensor > Networks (WSN)in a peer-to-peer fashion. It also provides a rendezvous > service for CoAP Nodes and caching of sensor information. > > http://tools.ietf.org/id/draft-jimenez-p2psip-coap-reload-00.txt - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPR6OiAAoJECnERZXWan7E/g4P/16gfK4nFltd97CIvnR8zipo 4LzC8GdzBSokZRv0el3UPzrUUCyBi03jWKvhegwstMAKJfk+S2h7hGp0BP+mC4Db EESrZ9BBfv/6qbW0RJUYrkFzMBUN6EuYc4p+5zs0JpKIqisev/dEI6D6e5oYIKOy Hy4v7NRXdK6lwnPgIknNsdbaM91+MMFHoCcXrcvlVdoHDGDPyae3q4JjZtwpOHaG FDESCxI/Za9v0eCCgBVG6MFMn7fL5gIc7WlQD7i72f9IIMfs55i3ttA/dMz/Lxcv RdctpPCOXk6zrMk+rAQnrePgubUNjU4qd9gm7Ef8BuB4Z8yt8yKrNV4WEerBZ3Fr PN6XCdMkwfYcj/74mVV0jlfC/xUJyTlZ8pQbspz7YcVgr/OCJjwts8RPULWCvT6X qR6rGdwSd+CaTkLfXxqg6WjT5x5pIGkpemJP5cpNJh3InqsgNQ1rVSa7qrkNCYUG aW6IoMKH+jSaTHlyC20TleCWRJpdPkliKu1q5PT8vbDXWzl3riU6D8oQGUXUB1ca PTE4FWXvjdWTfrhmgmZL6a1+rVKqgB2eWdh+o8HRweWxTDnvVmqIf+R1bseKRpHh ItHeWENs0psGVggc0/u/hHfKvNW7Usf0Z92NnqWNnYvvbSzH6z1+Z2mYAfwtvCyF en8J08gcGH17NJ8tdUyw =egUL -----END PGP SIGNATURE----- From jaime.j.jimenez@ericsson.com Tue Feb 28 23:52:16 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD4C21E8075 for ; Tue, 28 Feb 2012 23:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 geW1KyX0M1CQ for ; Tue, 28 Feb 2012 23:52:14 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 95E2921E8057 for ; Tue, 28 Feb 2012 23:52:08 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-d5-4f4dd92762df Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E3.78.01970.729DD4F4; Wed, 29 Feb 2012 08:52:07 +0100 (CET) Received: from ESESSCMS0358.eemea.ericsson.se ([169.254.1.143]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Wed, 29 Feb 2012 08:52:07 +0100 From: =?iso-8859-1?Q?Jaime_Jim=E9nez_J?= To: Marc Petit-Huguenin Date: Wed, 29 Feb 2012 08:52:05 +0100 Thread-Topic: [P2PSIP] draft-jimenez-p2psip-coap-reload Thread-Index: Acz2twg1lOAEhfuqTe6B3c5m/dTRzA== Message-ID: <0F09D93B-D007-42CD-A32E-990C6318B27B@ericsson.com> References: <98E76AB9-89FA-4BD0-87F7-C49E94D0829B@ericsson.com> <4F47A3A3.1090505@acm.org> In-Reply-To: <4F47A3A3.1090505@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_E5E46BE6-04C2-4618-83C5-159A9502605E"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] draft-jimenez-p2psip-coap-reload X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 07:52:16 -0000 --Apple-Mail=_E5E46BE6-04C2-4618-83C5-159A9502605E Content-Type: multipart/alternative; boundary="Apple-Mail=_697D1530-FA18-4BEA-96DB-706A61B40FDA" --Apple-Mail=_697D1530-FA18-4BEA-96DB-706A61B40FDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, Thanks for the comments we'll update the draft as specified. =20 BR, -- Jaime On Feb 24, 2012, at 4:50 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > Some comments: >=20 > 1. Section 4: ".. is calculated as a SHA-1 hash..." >=20 > This is defined only for CHORD-RELOAD, other algorithms may use a = different > way of computing the Resource-ID (unless only CHORD-RELOAD can be used = with > this usage, in which case it should be explicitly stated). >=20 > Also, URIs are case insensitive, so they need to be canonicalized = before been > converted to a Resource-ID. >=20 >=20 > 2. Figure 2: >=20 > Messages 4 and 5 should be AppAttach. >=20 > 200 OK has no meaning in RELOAD (messages 6 and 7). >=20 >=20 > 3. Section 7, last paragraph: "The only difference is data_value..." >=20 > data_value is never used. >=20 >=20 > 4. Section 7, CoAPCaching definition >=20 > The values to select coap_caching_type are never defined = (coap_caching_type > should be an enum). >=20 >=20 > 5. Section 7.1 Definition of ProxyCache, SensorEntry >=20 > [] should be redefined to carry the length (<0..length>) >=20 >=20 > 6. Section 7.1 Definition of SensorEntry >=20 > [] should be redefined to carry the length (<0..length>) >=20 > "opaque coap_uri;" should define a length (e.g. opaque = coap_uri<0..2^16-1>) >=20 >=20 > 7. Section 7.2 Definition of SensorCache >=20 > [] should be redefined to carry the length (<0..length>) >=20 >=20 > 8. Section 7.2 "last_awake" definition >=20 > Perhaps it's simpler to use the same format than RELOAD to store time, = i.e. > milliseconds since the epoch. >=20 >=20 > 9. Section 7.2 Definition of SensorValue >=20 > "value" should be redefined as having a length. >=20 >=20 > 10. Section 7.2 "measurement_time" definition >=20 > Unit is not defined. >=20 >=20 > 11. Section 7.2 "lifetime" definition >=20 > Unit is not defined. >=20 >=20 > 12. Section 8.1 "...which contains a Node-ID..." >=20 > CoAPRegistration does not contain a Node-ID. >=20 >=20 > 13. Section 8.1 URI-NODE-MATCH >=20 > This is a new access control policy, so it needs to be defined. >=20 >=20 > 14. Section 8.1 Definition of CoAPRegistration >=20 > Because of the fact that some RELOAD client may not be directly = routable > (second bullet of RELOAD section 3.2.1), I would add a "Destination > destination_list<0..2^16-1>;" field. >=20 >=20 > 15. Section 8.1 Definition of CoAPRegistration >=20 > The () notation for coap_uris is not defined, but the two lines can be > replaced by this: >=20 > opaque coap_uris<0..2^16-1>; >=20 > There is no explanation on the internal format of coap_uris, for = example that > the uris must be separated (or terminated?) with ";". >=20 >=20 > 16. Section 8.2 "which contains a Node-ID..." >=20 > CoAPCaching does not contain a Node-ID (ProxyCache does). >=20 >=20 > 17. Section 8.2 URI-MATCH >=20 > This is a new access control policy, so it needs to be defined. >=20 >=20 > Nits > - ---- >=20 > - - Section 4: >=20 > s/registering register/registering/ > s/RESOURCE-ID/Resource-ID/ >=20 > - - Section 5: >=20 > s/RESOURCE-ID/Resource-ID/ >=20 > - - Section 7.2: >=20 > s/NodeID/Node-ID/ >=20 >=20 > On 02/24/2012 03:01 AM, Jaime Jim=E9nez J wrote: >> Hello, >>=20 >> we just submitted a draft to the p2psip WG that proposes a CoAP Usage = for >> RELOAD. >>=20 >> Constrained Application Protocol (CoAP) is a specialized web transfer >> protocol. It realizes the Representational State Transfer (REST) >> architecture for the most constrained nodes, such as sensorsand = actuators. >>=20 >>=20 >> The CoAP Usageprovides the functionality to federate Wireless Sensor >> Networks (WSN)in a peer-to-peer fashion. It also provides a = rendezvous >> service for CoAP Nodes and caching of sensor information. >>=20 >> http://tools.ietf.org/id/draft-jimenez-p2psip-coap-reload-00.txt >=20 > - --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) >=20 > iQIcBAEBCAAGBQJPR6OiAAoJECnERZXWan7E/g4P/16gfK4nFltd97CIvnR8zipo > 4LzC8GdzBSokZRv0el3UPzrUUCyBi03jWKvhegwstMAKJfk+S2h7hGp0BP+mC4Db > EESrZ9BBfv/6qbW0RJUYrkFzMBUN6EuYc4p+5zs0JpKIqisev/dEI6D6e5oYIKOy > Hy4v7NRXdK6lwnPgIknNsdbaM91+MMFHoCcXrcvlVdoHDGDPyae3q4JjZtwpOHaG > FDESCxI/Za9v0eCCgBVG6MFMn7fL5gIc7WlQD7i72f9IIMfs55i3ttA/dMz/Lxcv > RdctpPCOXk6zrMk+rAQnrePgubUNjU4qd9gm7Ef8BuB4Z8yt8yKrNV4WEerBZ3Fr > PN6XCdMkwfYcj/74mVV0jlfC/xUJyTlZ8pQbspz7YcVgr/OCJjwts8RPULWCvT6X > qR6rGdwSd+CaTkLfXxqg6WjT5x5pIGkpemJP5cpNJh3InqsgNQ1rVSa7qrkNCYUG > aW6IoMKH+jSaTHlyC20TleCWRJpdPkliKu1q5PT8vbDXWzl3riU6D8oQGUXUB1ca > PTE4FWXvjdWTfrhmgmZL6a1+rVKqgB2eWdh+o8HRweWxTDnvVmqIf+R1bseKRpHh > ItHeWENs0psGVggc0/u/hHfKvNW7Usf0Z92NnqWNnYvvbSzH6z1+Z2mYAfwtvCyF > en8J08gcGH17NJ8tdUyw > =3DegUL > -----END PGP SIGNATURE----- --Apple-Mail=_697D1530-FA18-4BEA-96DB-706A61B40FDA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
-- = Jaime
On Feb 24, 2012, at 4:50 PM, Marc Petit-Huguenin = wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: = SHA256

Some comments:

1. Section 4:  ".. is = calculated as a SHA-1 hash..."

This is defined only for = CHORD-RELOAD, other algorithms may use a different
way of computing = the Resource-ID (unless only CHORD-RELOAD can be used with
this = usage, in which case it should be explicitly stated).

Also, URIs = are case insensitive, so they need to be canonicalized before = been
converted to a Resource-ID.


2. Figure = 2:

Messages 4 and 5 should be AppAttach.

200 OK has no = meaning in RELOAD (messages 6 and 7).


3. Section 7, last = paragraph: "The only difference is data_value..."

data_value is = never used.


4. Section 7, CoAPCaching definition

The = values to select coap_caching_type are never defined = (coap_caching_type
should be an enum).


5. Section 7.1 = Definition of ProxyCache, SensorEntry

[] should be redefined to = carry the length (<0..length>)


6. Section 7.1 = Definition of SensorEntry

[] should be redefined to carry the = length (<0..length>)

"opaque coap_uri;" should define a = length (e.g. opaque coap_uri<0..2^16-1>)


7. Section 7.2 = Definition of SensorCache

[] should be redefined to carry the = length (<0..length>)


8. Section 7.2 "last_awake" = definition

Perhaps it's simpler to use the same format than = RELOAD to store time, i.e.
milliseconds since the = epoch.


9. Section 7.2 Definition of = SensorValue

"value" should be redefined as having a = length.


10. Section 7.2 "measurement_time" = definition

Unit is not defined.


11. Section 7.2 = "lifetime" definition

Unit is not defined.


12. Section = 8.1 "...which contains a Node-ID..."

CoAPRegistration does not = contain a Node-ID.


13. Section 8.1 URI-NODE-MATCH

This = is a new access control policy, so it needs to be = defined.


14. Section 8.1 Definition of = CoAPRegistration

Because of the fact that some RELOAD client may = not be directly routable
(second bullet of RELOAD section 3.2.1), I = would add a "Destination
destination_list<0..2^16-1>;" = field.


15. Section 8.1 Definition of = CoAPRegistration

The () notation for coap_uris is not defined, = but the two lines can be
replaced by this:

opaque = coap_uris<0..2^16-1>;

There is no explanation on the = internal format of coap_uris, for example that
the uris must be = separated (or terminated?) with ";".


16. Section 8.2 "which = contains a Node-ID..."

CoAPCaching does not contain a Node-ID = (ProxyCache does).


17. Section 8.2 URI-MATCH

This is a = new access control policy, so it needs to be = defined.


Nits
- ----

- - Section = 4:

s/registering = register/registering/
s/RESOURCE-ID/Resource-ID/

- - Section = 5:

s/RESOURCE-ID/Resource-ID/

- - Section = 7.2:

s/NodeID/Node-ID/


On 02/24/2012 03:01 AM, Jaime = Jim=E9nez J wrote:
Hello,

we just = submitted a draft to the p2psip WG that proposes a CoAP Usage = for
RELOAD.

Constrained = Application Protocol (CoAP) is a specialized web = transfer
protocol. It realizes = the Representational State Transfer (REST)
architecture for the most constrained nodes, such as = sensorsand actuators.


The CoAP = Usageprovides the functionality to federate Wireless = Sensor
Networks (WSN)in a = peer-to-peer fashion.  It also provides a = rendezvous
service for CoAP = Nodes and caching of sensor information.

= http://tools.ietf.org/id/draft-jimenez-p2psip-coap-reload-00.txt

- --
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Pro= fessional email: petithug@acm.org
Blog: http://blog.marc.petit-huguen= in.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 = (GNU/Linux)

iQIcBAEBCAAGBQJPR6OiAAoJECnERZXWan7E/g4P/16gfK4nFltd97C= IvnR8zipo
4LzC8GdzBSokZRv0el3UPzrUUCyBi03jWKvhegwstMAKJfk+S2h7hGp0BP+mC= 4Db
EESrZ9BBfv/6qbW0RJUYrkFzMBUN6EuYc4p+5zs0JpKIqisev/dEI6D6e5oYIKOyHy4v7NRXdK6lwnPgIknNsdbaM91+MMFHoCcXrcvlVdoHDGDPyae3q4JjZtwpOHaG
FDESC= xI/Za9v0eCCgBVG6MFMn7fL5gIc7WlQD7i72f9IIMfs55i3ttA/dMz/Lxcv
RdctpPCOXk6= zrMk+rAQnrePgubUNjU4qd9gm7Ef8BuB4Z8yt8yKrNV4WEerBZ3Fr
PN6XCdMkwfYcj/74m= VV0jlfC/xUJyTlZ8pQbspz7YcVgr/OCJjwts8RPULWCvT6X
qR6rGdwSd+CaTkLfXxqg6Wj= T5x5pIGkpemJP5cpNJh3InqsgNQ1rVSa7qrkNCYUG
aW6IoMKH+jSaTHlyC20TleCWRJpdP= kliKu1q5PT8vbDXWzl3riU6D8oQGUXUB1ca
PTE4FWXvjdWTfrhmgmZL6a1+rVKqgB2eWdh= +o8HRweWxTDnvVmqIf+R1bseKRpHh
ItHeWENs0psGVggc0/u/hHfKvNW7Usf0Z92NnqWNn= YvvbSzH6z1+Z2mYAfwtvCyF
en8J08gcGH17NJ8tdUyw
=3DegUL
-----END = PGP SIGNATURE-----

= --Apple-Mail=_697D1530-FA18-4BEA-96DB-706A61B40FDA-- --Apple-Mail=_E5E46BE6-04C2-4618-83C5-159A9502605E Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICEQCaObzOR9uy6LZk9ciUsJXTMA0GCSqGSIb3DQEBBQUAMDkxETAPBgNVBAoMCEVy aWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDEwHhcNMTExMDA3MDgy NDA3WhcNMTQxMDA3MDgyNDA1WjBqMREwDwYDVQQKDAhFcmljc3NvbjEWMBQGA1UEAwwNSmFpbWUg SmltZW5lejEQMA4GA1UEBRMHZWphamltbjErMCkGCSqGSIb3DQEJARYcamFpbWUuai5qaW1lbmV6 QGVyaWNzc29uLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzS0HqaJg8DzcIQIMn3U7 MMfhgUlP8eETQflo8p6+CtB6QePChaU+7igtsK28NwE3keNwGXAWulJlg4ScqvTHuhQkaCHpq1eZ X18exYkpzI2dw6LIVcJwVauWSIR7TEeuIHzD71ekDDdQGSFYMnhbKc+mTfWCpZ3zT9NH2IGok4kC AwEAAaOCAYgwggGEMIHABgNVHR8EgbgwgbUwgbKgga+ggayGN2h0dHA6Ly9jcmwudHJ1c3QudGVs aWEuY29tL0VyaWNzc29uTkxJbmRpdmlkdWFsQ0EwMS5jcmyGcWxkYXA6Ly9sZGFwLnRydXN0LnRl bGlhLmNvbS9jbj1Fcmljc3NvbiUyME5MJTIwSW5kaXZpZHVhbCUyMENBMDEsbz1Fcmljc3Nvbj9j ZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlMCcGA1UdEQQgMB6BHGphaW1lLmou amltZW5lekBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFLs/X1d9fU7fNptr Jf+FMGSwhLB8MB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAlAPQI4BnKBEx2hYo3J+WU0+ZB38sRl9P39BEZXv6pFeLP1kB 0b/oe20EQshlRuzttkwMoQ2ibW70LM6+dALQ+LzYNXVxH8RUnj7ZsyLHj3kmRiT9oFi0ytayn1+O quoC1njz5q2ULAInUIw5mfKZ0Rldm0TjtmhzMTjTNGyKSHU9fi8Ra+zu6CeXg/wEVSVy6XX9Chqc sL3WkTRea2juYj+xOVnz75nybxfAp9VRdGi7OGc8dOt2rVaf18LnPbgyzNUMUJfKvETHJrT6IG7P zH0lY3o7svmyr01evx/7tFq4pBoq9vYtYCzQ2Jf31WzbJu0HEzgNZAHnAK8AMNqbjDCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICFTCCAhECAQEwTjA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhEAmjm8zkfbsui2ZPXIlLCV0zAJBgUrDgMCGgUAoIIBHTAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAyMjkwNzUyMDZaMCMGCSqG SIb3DQEJBDEWBBQE+J7PzP52PFrohNHSgj8WBniWIjBdBgkrBgEEAYI3EAQxUDBOMDkxETAPBgNV BAoMCEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEQCaObzO R9uy6LZk9ciUsJXTMF8GCyqGSIb3DQEJEAILMVCgTjA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIG A1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAxAhEAmjm8zkfbsui2ZPXIlLCV0zANBgkq hkiG9w0BAQEFAASBgD+sQW116kjUcjiamAHw7HkCfbaRmU3JHZK2WIyNBLx87eSJkBEHkje3Pt0R vRZ2uIqcA6OmydHU8gderHW0Hev4HTBO22JncdgRDEbVnbqo+iCb0GiJ60P1kLh/6h29M7wRZfca 99XTQv4akWMKMaOEEJNILWG2IqGRKrYdEmcTAAAAAAAA --Apple-Mail=_E5E46BE6-04C2-4618-83C5-159A9502605E-- From petithug@acm.org Wed Feb 29 07:47:18 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C735121F8716 for ; Wed, 29 Feb 2012 07:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.39 X-Spam-Level: X-Spam-Status: No, score=-102.39 tagged_above=-999 required=5 tests=[AWL=0.210, 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 C+n66483GNIX for ; Wed, 29 Feb 2012 07:47:18 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 0A92421F84DA for ; Wed, 29 Feb 2012 07:47:18 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id B224A2043C; Wed, 29 Feb 2012 15:30:48 +0000 (UTC) Message-ID: <4F4E4881.6000807@acm.org> Date: Wed, 29 Feb 2012 07:47:13 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0 MIME-Version: 1.0 To: Roland Bless References: <4F314EE0.9030101@nostrum.com> <4F356320.4020003@acm.org> <4F428E6A.1020901@acm.org> <4F43704C.3040701@kit.edu> In-Reply-To: <4F43704C.3040701@kit.edu> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: p2psip@ietf.org Subject: Re: [P2PSIP] [reload-implementers] RELOAD testing at IETF83 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 15:47:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Roland, On 02/21/2012 02:22 AM, Roland Bless wrote: > Hi, > > On 20.02.2012 19:18, Marc Petit-Huguenin wrote: >> I did not see much interest in the RELOAD interop in Paris so far. If >> you think that you will maybe attend, please send me a direct email, you >> will be able to cancel without problem. I really need to have an idea of >> the number of people attending for planning purpose. > > Basically, we are interested, but our implementation isn't probably mature > enough for an interop at this IETF (amy at the next one). Furthermore, I'll > arrive on Sunday and can't make it on Saturday. > If you arrive before 1:00pm the Sunday, please stop by anyway. Knowing other implementers can only help to organize future interop events. Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPTkiAAAoJECnERZXWan7Ef9IP/0JoeEasvNpNYBmNhiAl21Ga dnJEK/HaXZONeqPU2EDQKv8/qktj3ulezDoJm6Tx4ym2itmdIrcKeKFBf5DB/8jQ XWry4FAhd3m/y9ItWu/6CN9N9DwaEw1NMqCcBDg+UgeTM4GbjVSvc9N74p7Y1qQY Xqavmh3YNEbHMkh7+C7fXDiziPOBBUU0Q+6twFIWgBb4ctFpSiuQLrdcwBp7LX95 DHPviuD2HJgbOmPXA6I9fy9HufJ9+HXKpklgtoeywkdaRHR69wHDNwYlRuNepLLE oct5waapkoyXQjkQosBBeS4t/VkY7OcYEyQe+qwH1EVrDH//pEQ2Gy+/yh6Utqjn u5ZWwkpNzZ9dDv6aDEP1TFbxdjSST8u8+WjkMHalYFQ6NOsvCFsFHC07scpbtMNC G60/voeiaD7mzWoWcnPZ7b7uXtnDeg0El0b+/tixZkTM/71dLWL6RLtfbgaDcZE1 Ku13rPvzk9TBnZZIOBiD6ryPALArpmjIaXL5Z0GCDp8Lqz9Rw/JMuTKL+Ux7JlQ/ 6JPKtHpNtybgtF5GCIliWovQdaykLT9Mo7AmKTCqoqHL+dI0Y0F1znlXhgZPOZ/w E3ED+QGXRt2MtbWzof/ExxeKRwuRTJimTdiV/TL0jok3JJuZI/QV722JE/xJ40iO /U6ZmxA6d3W0+ySdEws5 =af2d -----END PGP SIGNATURE-----