From internet-drafts@ietf.org Fri Jan 6 02:23:59 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 148CA21F88B6; Fri, 6 Jan 2012 02:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AGzGSfqsdjR; Fri, 6 Jan 2012 02:23:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A4621F87A2; Fri, 6 Jan 2012 02:23:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120106102358.8631.1310.idtracker@ietfa.amsl.com> Date: Fri, 06 Jan 2012 02:23:58 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] 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, 06 Jan 2012 10:23:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer-to-Peer Session Initiation Proto= col Working Group of the IETF. Title : Service Discovery Usage for REsource LOcation And Discov= ery (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.t= xt From internet-drafts@ietf.org Fri Jan 6 02:26:48 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 5C04921F894C; Fri, 6 Jan 2012 02:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbIbpPkOQ2AX; Fri, 6 Jan 2012 02:26:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011AA21F8940; Fri, 6 Jan 2012 02:26:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120106102648.9280.89425.idtracker@ietfa.amsl.com> Date: Fri, 06 Jan 2012 02:26:48 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-self-tuning-05.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, 06 Jan 2012 10:26:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer-to-Peer Session Initiation Proto= col Working Group of the IETF. Title : A Self-tuning Distributed Hash Table (DHT) for REsource = LOcation And Discovery (RELOAD) Author(s) : Jouni Maenpaa Gonzalo Camarillo Jani Hautakorpi Filename : draft-ietf-p2psip-self-tuning-05.txt Pages : 21 Date : 2012-01-06 REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) signaling protocol that provides an overlay network service. Peers in a RELOAD overlay network collectively run an overlay algorithm to organize the overlay, and to store and retrieve data. This document describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-self-tuning-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-p2psip-self-tuning-05.txt From petithug@acm.org Mon Jan 9 14:04:11 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 966E911E80C0 for ; Mon, 9 Jan 2012 14:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.804 X-Spam-Level: X-Spam-Status: No, score=-101.804 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 zp5qX2hXjYrD for ; Mon, 9 Jan 2012 14:04:11 -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 E1DEB11E8075 for ; Mon, 9 Jan 2012 14:04:10 -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 C03CD20142 for ; Mon, 9 Jan 2012 21:50:54 +0000 (UTC) Message-ID: <4F0B6457.1070804@acm.org> Date: Mon, 09 Jan 2012 14:04:07 -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 CC: p2psip@ietf.org References: <20120106102358.8631.1310.idtracker@ietfa.amsl.com> In-Reply-To: <20120106102358.8631.1310.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [P2PSIP] 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: Mon, 09 Jan 2012 22:04:11 -0000 Many thanks to the authors, this new version of the draft takes care of all my comments. I will update the Wireshark dissector in the coming week and will post the patch on the reload-implementers mailing list for comments. Will there be a a Last Call soon? LC of this draft and a lot other were promised back in Quebec City. I understand that p2psip-base is blocking everything but its authors seem to have disappear. Perhaps the chairs could consider naming a new editor to take care of things. Some of us have drafts that we really would like to see adopted, and it seems that a very little group of people are blocking the efforts of a larger group of people that are willing to contribute and make RELOAD a success. 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 From petithug@acm.org Mon Jan 16 10:25: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 534B021F86C2; Mon, 16 Jan 2012 10:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=0.263, 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 aeUmXGQZyEYA; Mon, 16 Jan 2012 10:25:42 -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 A78A621F86A2; Mon, 16 Jan 2012 10:25:42 -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 71B1420142; Mon, 16 Jan 2012 18:11:59 +0000 (UTC) Message-ID: <4F146BA2.2080106@acm.org> Date: Mon, 16 Jan 2012 10:25:38 -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: DISPATCH list References: <20120116175444.21776.21853.idtracker@ietfa.amsl.com> In-Reply-To: <20120116175444.21776.21853.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.4 X-Forwarded-Message-Id: <20120116175444.21776.21853.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" , P2PSIP Mailing List Subject: [P2PSIP] Fwd: I-D Action: draft-petithuguenin-dispatch-unique-overlay-01.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: Mon, 16 Jan 2012 18:25:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I would like to request a timeslot in the DISPATCH session in Paris to talk about infrastructure overlays, which is a special class of RELOAD overlays that by their own definition require that only one instance of this overlay exists on the Internet (excluding instances deployed for test and experimentation). This kind of overlay could be useful for stuff like bitcoin or boinc, but the main motivation is to support VIPR, which works only if there is a unique overlay instance. The discussion will be around the problems that infrastructure overlays solve and the list of requirements for the mechanism used to implement it but, although this is not part of the discussion, the new version of the draft contains an appendix explaining one possible solution. - -------- Original Message -------- Subject: I-D Action: draft-petithuguenin-dispatch-unique-overlay-01.txt Date: Mon, 16 Jan 2012 09:54:44 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Infrastructure Overlay Author(s) : Marc Petit-Huguenin Filename : draft-petithuguenin-dispatch-unique-overlay-01.txt Pages : 6 Date : 2012-01-16 This document provides requirements for infrastructure overlays, a special kind of peer-to-peer overlay whose main purpose would be defeated if more than one instance would exist on the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-petithuguenin-dispatch-unique-overlay-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-petithuguenin-dispatch-unique-overlay-01.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPFGudAAoJECnERZXWan7EDnoQAIdc/tgnhObDZP7iEm8XYN9t 9Eop2B6WQCS9KRjMDagjojY7smAdRkof23Tru+4q+jj7W2f+BbL3/EWex2y8/uRS jZC0Z5pgw6hJrwR+UQni8XfuAWuoBJ6Rl9UHlBKRwyiyZn/mJD8Z1aUWO8FIXdLI zM+x2E2FEeuW9HbvDQ19+5JrBce7VplOvyZz2OOZzvkgBQFDYVJIvvpzE26OuGQa I9sz2EedPn+xnpRC5XtKxQDkkRRreB6xDyaM6heqzqldcBbvIyNFDfmHDOkTVQIi qP5eCwB2vHCN+nlKfhm/F2Bx+coFvYJ628rB4rMcoBCa+VuXspyPMhUaXWQhCioc +N17jsF02q31HO/SBE8vMQRPTZcv/t24d5VZhoxTdBAZt420W2eWNXeDpoWobN9c nN7fkFkTfuK4xP6374GieEmfgOquLXMM556DTJN/5c5l7E7So+udSw0ctIjehBrZ VMLI8GRrISv/mIjOV4cW2Wevn+g5Dw0P3Ptg6N2Dd84CkbRqBkqmfLrvpdhkdhWd wN3kCi6vLF3XfGJrnyyVY15KO+Cg3j9uAmVRZj+Nxdm6hngtklQJwHTiKtDGKgCp 7qoVFmJGVCYNpyBbvKETRhSTsAPz8p/ygU2ququExiaa8DW4/jGxB+xMfqpMMvez MhcXnZzLQmSjdv45ZZaQ =aaO4 -----END PGP SIGNATURE----- From internet-drafts@ietf.org Tue Jan 17 18:35:47 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 C66091F0C3F; Tue, 17 Jan 2012 18:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RMd5McxoDLr; Tue, 17 Jan 2012 18:35:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB4521F8628; Tue, 17 Jan 2012 18:35:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120118023532.11398.88769.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2012 18:35:32 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-base-20.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: Wed, 18 Jan 2012 02:35:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer-to-Peer Session Initiation Proto= col Working Group of the IETF. Title : REsource LOcation And Discovery (RELOAD) Base Protocol Author(s) : Cullen Jennings Bruce B. Lowekamp Eric Rescorla Salman A. Baset Henning Schulzrinne Filename : draft-ietf-p2psip-base-20.txt Pages : 166 Date : 2012-01-17 This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-20.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-base-20.txt From internet-drafts@ietf.org Tue Jan 17 18:49: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 BA36521F86BA; Tue, 17 Jan 2012 18:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCGNGAiYnDzH; Tue, 17 Jan 2012 18:49:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D09A21F86B3; Tue, 17 Jan 2012 18:49:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120118024939.14870.77911.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2012 18:49:39 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-sip-07.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: Wed, 18 Jan 2012 02:49:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer-to-Peer Session Initiation Proto= col Working Group of the IETF. Title : A SIP Usage for RELOAD Author(s) : Cullen Jennings Bruce B. Lowekamp Eric Rescorla Salman A. Baset Henning Schulzrinne Filename : draft-ietf-p2psip-sip-07.txt Pages : 13 Date : 2012-01-17 This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD), The SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system. The SIP Usage provides lookup service for AoRs stored in the overlay. The SIP Usage also defines GRUUs that allow the registrations to map an AoR to a specific node reachable through the overlay. The AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-sip-07.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-sip-07.txt From fluffy@cisco.com Tue Jan 17 18:43:35 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 D9D5511E8076 for ; Tue, 17 Jan 2012 18:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.162 X-Spam-Level: X-Spam-Status: No, score=-106.162 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozo8GiOUB20t for ; Tue, 17 Jan 2012 18:43:35 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 730C611E8071 for ; Tue, 17 Jan 2012 18:43:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1463; q=dns/txt; s=iport; t=1326854615; x=1328064215; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=cCBdZ44M9F10kG3s05wj/6k4EOzBCvmXAFZ/vmYEhck=; b=K+pxufLrHneMe0+BUkyrx6U0rblH4Za6bXjxzwUxUtONjdjHClk27uEd hc827S0gB6ykjEtafmMTIDhG+oVNdk1u3P9+e8HmXU0Xnna3Wz8yrqnhS MzeBAMhjM7t37lVF6ZX+9otNZU03Cae5KbXHCaoeb15fUpwOa1psdShUS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACUxFk+rRDoI/2dsb2JhbABErESBBoEFggsBJz9LczWgbAGeW4kuAQEEBAkFAQUJCQICAQENBQQRBQEGAQEGAQUHJQECAQEFAwEBAQECBxAFDiYMRBAFC4E6AQwHAQYMDhUDQII3YwSIO4xWhVGNEA X-IronPort-AV: E=Sophos;i="4.71,527,1320624000"; d="scan'208";a="24188152" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 18 Jan 2012 02:43:35 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0I2hY1V022115; Wed, 18 Jan 2012 02:43:34 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 17 Jan 2012 19:43:34 -0700 Message-Id: <345BA2F8-6486-4E57-AC67-24F24C7D0EB0@cisco.com> To: P2PSIP Mailing List Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 18 Jan 2012 09:16:25 -0800 Subject: [P2PSIP] Update of reload base draft 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, 18 Jan 2012 02:43:36 -0000 We believe this revision addresses the following DISCUSS comments: Jari Arkko Adrian Farrel Robert Sparks Peter Saint-Andre Dan Romascanu Russ Housley Note: we did not address non-DISCUSS comments. We are planning to do that on a subsequent pass. Most of the changes are editorial/clarifying, however, a number were substantive (though generally not breaking). Here's a summary of what we believe the major ones are: * Changed the certificate enrollment protocol to remove the password from the URL. Note that this is a breaking change. * Globally renamed "private id" and "compressed id" to "opaque id" * Specified the details of the overlay name (S 5.3.2) * Nailed down the fragment semantics, harmonizing between the fragment field defn. and the rules for generating fragments. The high bit must always be set and unfragmented packets are represented as the last fragment with an offset of 0. * Specified new requirements for malicious loop prevention: - Configuration servers are supposed to set TTL based on overlay size. - Peers must check that TTL never exceeds the configured maximum. - Peers should check for duplicates in the destination list. * Added a new Error_Invalid_Message generic error code. In terms of schedule, we plan to spin a new draft before the draft deadline that addresses all the DISCUSS comments and as many of the comments as possible. Ekr, Bruce, & Cullen From petithug@acm.org Fri Jan 20 14:32:53 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 4E62E21F8537 for ; Fri, 20 Jan 2012 14:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.297 X-Spam-Level: X-Spam-Status: No, score=-102.297 tagged_above=-999 required=5 tests=[AWL=0.303, 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 MULYNnF37hkY for ; Fri, 20 Jan 2012 14:32:52 -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 2C19B21F863D for ; Fri, 20 Jan 2012 14:32:52 -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 66F2020143; Fri, 20 Jan 2012 22:18:53 +0000 (UTC) Message-ID: <4F19EB90.5090409@acm.org> Date: Fri, 20 Jan 2012 14:32:48 -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: Cullen Jennings References: <345BA2F8-6486-4E57-AC67-24F24C7D0EB0@cisco.com> In-Reply-To: <345BA2F8-6486-4E57-AC67-24F24C7D0EB0@cisco.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Update of reload base draft 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, 20 Jan 2012 22:32:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/17/2012 06:43 PM, Cullen Jennings wrote: > > We believe this revision addresses the following DISCUSS comments: > > Jari Arkko Adrian Farrel Robert Sparks Peter Saint-Andre Dan Romascanu Russ > Housley > > Note: we did not address non-DISCUSS comments. We are planning to do that > on a subsequent pass. > > Most of the changes are editorial/clarifying, however, a number were > substantive (though generally not breaking). Here's a summary of what we > believe the major ones are: > > * Changed the certificate enrollment protocol to remove the password from > the URL. Note that this is a breaking change. > > * Globally renamed "private id" and "compressed id" to "opaque id" > > * Specified the details of the overlay name (S 5.3.2) > > * Nailed down the fragment semantics, harmonizing between the fragment > field defn. and the rules for generating fragments. The high bit must > always be set and unfragmented packets are represented as the last fragment > with an offset of 0. > > * Specified new requirements for malicious loop prevention: > > - Configuration servers are supposed to set TTL based on overlay size. - > Peers must check that TTL never exceeds the configured maximum. - Peers > should check for duplicates in the destination list. > > * Added a new Error_Invalid_Message generic error code. > > In terms of schedule, we plan to spin a new draft before the draft deadline > that addresses all the DISCUSS comments and as many of the comments as > possible. > I hate to be the one complaining again, but because the "final" draft will be released around March 11th, there will be only 2 weeks to review, implement, and try to fix it before the P2PSIP meeting itself and we all know how busy these few weeks before a meeting are. My prediction is that the meeting will be simply a list of issues or fixes that people will have no time to analyze and understand and that this meeting will be, like the one in Taipei, a waste of time. Won't it be more efficient to finish this now, which would give two months to be sure that everything is OK, and declare victory in Paris? - -- 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) iQIcBAEBCAAGBQJPGeuOAAoJECnERZXWan7EIT0QAJz0gd7XjK861AKEpeDkDSd1 QMDlI6QXz+sseYGJozw+OJzrTvulDO1oEGT1m9fbrpHyAgTEOMf+tlf3G6mAMrfi t3+MRuRMp7713+4sgPZ7PDDB2FNxsfK2guzBBwyzVC1Cv5YByrxkhSw/4vnyD801 dwbRed25Nfw/eDKWQH2GjZypE8hFLClkAqjAZcCI49rjJhacePxVLBj3x9xutc4g U0Cfjqts9FFSAlhKL9vnOpzxxxxa/TjtGnuEHwUsPH/sV+pJ8YZzRsAobYWWG61p Lne/fvhGHX3AJkjCf2v88UMDhQDdV04zLt2T585WtjDKdM8PZHQ0yU3/+Ply/pYT 41H1co/Esl13RRLA9hxwp44QpA1LL1c2zTWg+YQAiOagom33RkZ+vShjhwuiqx0Y ak8S3NaFJMCN+qnvfJmxF3gX11sUkSu/PDicMpz1qiHPlh47eaWAjOSYS/Ejy7+I LIk8Tl3J1XOGC02dNAZ0kjsajcM/wseDVCc+ejrwtd1zlwHTU4SdiBVIdA8cZVaz ntQEtX3GJolikLfsmWXiyxR2IZvHVQYI7+wb75xcGadPQAjIIwH9T7dzVlkhPLQT NjbDe5wxghIe8QJ6XLytYmAji+fBtvfGy+rjS6x4SWCSJKojFjInTExcAoKIxpkV y2wRBChN2ghdFlRpnEQo =u8Fs -----END PGP SIGNATURE----- From petithug@acm.org Mon Jan 23 06:38: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 42B2621F8714 for ; Mon, 23 Jan 2012 06:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.313 X-Spam-Level: X-Spam-Status: No, score=-102.313 tagged_above=-999 required=5 tests=[AWL=0.287, 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 V2B5mOhJJLhV for ; Mon, 23 Jan 2012 06:38:26 -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 0D25821F8709 for ; Mon, 23 Jan 2012 06:38:25 -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 46B8A20142; Mon, 23 Jan 2012 14:24:17 +0000 (UTC) Message-ID: <4F1D70DE.6020300@acm.org> Date: Mon, 23 Jan 2012 06:38:22 -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: Cullen Jennings References: <345BA2F8-6486-4E57-AC67-24F24C7D0EB0@cisco.com> <4F19EB90.5090409@acm.org> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Update of reload base draft 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, 23 Jan 2012 14:38:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/22/2012 08:44 PM, Cullen Jennings wrote: > > > On Jan 20, 2012, at 14:32 , Marc Petit-Huguenin wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> On 01/17/2012 06:43 PM, Cullen Jennings wrote: >>> >>> We believe this revision addresses the following DISCUSS comments: >>> >>> Jari Arkko Adrian Farrel Robert Sparks Peter Saint-Andre Dan Romascanu >>> Russ Housley >>> >>> Note: we did not address non-DISCUSS comments. We are planning to do >>> that on a subsequent pass. >>> >>> Most of the changes are editorial/clarifying, however, a number were >>> substantive (though generally not breaking). Here's a summary of what >>> we believe the major ones are: >>> >>> * Changed the certificate enrollment protocol to remove the password >>> from the URL. Note that this is a breaking change. >>> >>> * Globally renamed "private id" and "compressed id" to "opaque id" >>> >>> * Specified the details of the overlay name (S 5.3.2) >>> >>> * Nailed down the fragment semantics, harmonizing between the fragment >>> field defn. and the rules for generating fragments. The high bit must >>> always be set and unfragmented packets are represented as the last >>> fragment with an offset of 0. >>> >>> * Specified new requirements for malicious loop prevention: >>> >>> - Configuration servers are supposed to set TTL based on overlay size. >>> - Peers must check that TTL never exceeds the configured maximum. - >>> Peers should check for duplicates in the destination list. >>> >>> * Added a new Error_Invalid_Message generic error code. >>> >>> In terms of schedule, we plan to spin a new draft before the draft >>> deadline that addresses all the DISCUSS comments and as many of the >>> comments as possible. >>> >> >> I hate to be the one complaining again, but because the "final" draft >> will be released around March 11th, there will be only 2 weeks to >> review, implement, and try to fix it before the P2PSIP meeting itself and >> we all know how busy these few weeks before a meeting are. My prediction >> is that the meeting will be simply a list of issues or fixes that people >> will have no time to analyze and understand and that this meeting will >> be, like the one in Taipei, a waste of time. Won't it be more efficient >> to finish this now, which would give two months to be sure that >> everything is OK, and declare victory in Paris? >> > > > If anyone wants to help, we'd love some help. The problem is several of us > are wrapped up in the W3C WebRTC and IETF RTCWeb interim meetings from now > till Feb 1 so I suspect that there will not be time put into it for the > next 10 days unless someone else does something. My fear is it would take > too long for most people to get up to speed on it. We did try to order the > discusses such that we fixed one that might impact implementations first. > Just after the meeting in Taipei, I was trying to convince someone to come to the RELOAD interop event in Paris. The response was that the implementation will not be ready in time, because they will not start until RELOAD is finished. I understand - when I saw -20 I was ready to do a complete review and to update my code, but after seen your email, I stopped bothering, I'll just wait for -21. Or -22. Or -23, it's a prime number and I like prime numbers. Also I have unpublished drafts that I am holding because it is not possible to present anything new at a WG meeting - what's the point anyway if the response is invariably "we need to finish RELOAD first"? People are now presenting their drafts in samrg, I'll probably do that too, and skip the p2psip meeting. On the other hand I completely understand the pressure of other works and that nobody can sustain the same interest and enthusiasm on a specific subject for the many years that are required to standardize anything. What I do not understand is why the chairs did not step in and named additional editors to this draft. - -- 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) iQIcBAEBCAAGBQJPHXDcAAoJECnERZXWan7EosQP/R2nvcQlO4EzMjGSeet2uTmA 0EAafcLeJyNhgIYjgsLfp9sJFOwjaKUTicuE6A67rv9LbyoCwS8BFzpHb/uim7B+ /4btJAzkjYArwMAvtOTHHVK0ebMEpmP7fUhb7CwaStY7ppW/5sSxpB2ixsBwxrmM 40ENCUgoRPTWkwoXP5gZAY+MVZ1E6PBRPKT/zT8nrcio9eLRzZb2BsdXYuphgmBE Aaac1gfLpzyLrKd1N5A4wPLhyXgYbvWza9hfe7du2S9x5+n52sJPFkxgkZjQEp6m UxtXY661HTkHpxRJicfkP2Dq2v88Mh3oJMuWSFqmACLZji6s5TGCNTIeG0apnB4e qFmhWRbRZQxU4J65bIMZHQIb+8KCaqfqY1GMl7/ppBVK7lKlZeclN8xrwg0+f2mL 7AzIYolHFYvWqMGGWpDZQt88tatNc0JDlhx9xllT+ifoK2jfxAe+N1h0S1VaodGe gdT/WkTP/SGGVr2aBVz2XJNOdCgEMO+QwyEHhTKmzpY/MhCHHOHGqc1kR/G16WC0 ngHK43TaCZgH9BKgxOoVFeczADQQ/D6zY7j7Io+uqr6NtS2899FUzodIDG/Nzioy b7yTyPzZAsJHuRExulHCgBfNLxqPxMFW6GsiDTwPwU9ca7e9lydoBLqGQK56HU+6 xajd84LDaKisemdsy8si =pJUK -----END PGP SIGNATURE----- From petithug@acm.org Mon Jan 23 07:15: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 1637A21F8650 for ; Mon, 23 Jan 2012 07:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.328 X-Spam-Level: X-Spam-Status: No, score=-102.328 tagged_above=-999 required=5 tests=[AWL=0.272, 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 Yiy+0yb-72MP for ; Mon, 23 Jan 2012 07:15:53 -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 4EB7021F86FA for ; Mon, 23 Jan 2012 07:15:53 -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 76E5D20142 for ; Mon, 23 Jan 2012 15:01:45 +0000 (UTC) Message-ID: <4F1D79A6.7080308@acm.org> Date: Mon, 23 Jan 2012 07:15:50 -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 Mailing List X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Minutes, slides from IETF 82? 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, 23 Jan 2012 15:15:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I notice that the slides for the first presentation (P2PSIP base) are not available on the proceedings[1] page for IETF 82, that the links for the Diagnostics and P2PSIP Concepts slides are broken and that the minutes are sill not available. [1] http://www.ietf.org/proceedings/82/p2psip.html - -- 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) iQIcBAEBCAAGBQJPHXmkAAoJECnERZXWan7EGhMP/0dLt6QKy/l6va5A0aI8Utlx jxQZncVvLQAqwSGKyBsaagc4cn6ic24H6qn8x4IaRnHq8ZzCqMFAgYfigoiQdCUd IAdCpVba3bCEYiO9uGTiMNCzdykG2RRxHLGzeub79LMD9Jok48aX+ZeiCe9Tkl8C x/Jdg31/K8NQRIOQ7rSKVIqa7iZ2qw2SSnF49KfShTKVnz2NgWaEkeyZdroMxVlX hE+rSuuZW8oVPdtEmWjDKMY6tHp8nAuuqllbcr/JtHEjHQ9IULFPiHmOcqNIxYzR LIFvMhpV+V6I29Rq4d1WBYD4ywupq+S6AQvu5GA0MRfJ0HfFhENAIZgvSev0lG3K JMXIY0nCa3GbgsPgnmlEnN/8KSZCxB6OJIEFfcY9w3aV/namvqZp783y+ybb65SP E4/iXuHa5F8m1SmUkVYkOD+u4QvX0bpDUlcX5SEfyZT+9ni1+E8TTENBnOUbtACW 6g9g3DxOz+WxSpXSE00aUlgJ7l3H0q9PnmXnSG85W+OryohO6osKViyqk5CNKGnY ++GsW/6s3yYrgbFA0FWoRw/FQ4SwQ5wughrbHf0+FmF8J9Zg1Sef/VHty4jIX0/Z zdkzkFSdVO2hx6IfjfgsYRM/sYBpcpIMVwoQhHBDo491SsB27xuOML8T8Z+zzqOO BzYxbAuQocV4xi6gWAyp =UJjm -----END PGP SIGNATURE----- From petithug@acm.org Mon Jan 23 09:51: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 3C7F321F8664 for ; Mon, 23 Jan 2012 09:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.352 X-Spam-Level: X-Spam-Status: No, score=-102.352 tagged_above=-999 required=5 tests=[AWL=0.248, 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 EuJfQr4KTN2S for ; Mon, 23 Jan 2012 09:51:41 -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 EC5F921F8649 for ; Mon, 23 Jan 2012 09:51:40 -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 78B5C20142; Mon, 23 Jan 2012 17:37:32 +0000 (UTC) Message-ID: <4F1D9E29.2000204@acm.org> Date: Mon, 23 Jan 2012 09:51:37 -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: Cullen Jennings References: <345BA2F8-6486-4E57-AC67-24F24C7D0EB0@cisco.com> <4F19EB90.5090409@acm.org> <4F1D70DE.6020300@acm.org> <7A3488FD-31AE-4877-9CCF-794ED9A31EE7@iii.ca> In-Reply-To: <7A3488FD-31AE-4877-9CCF-794ED9A31EE7@iii.ca> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Update of reload base draft 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, 23 Jan 2012 17:51:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/23/2012 09:16 AM, Cullen Jennings wrote: > > On Jan 23, 2012, at 6:38 , Marc Petit-Huguenin wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> On 01/22/2012 08:44 PM, Cullen Jennings wrote: >>> >>> >>> On Jan 20, 2012, at 14:32 , Marc Petit-Huguenin wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>>> >>>> On 01/17/2012 06:43 PM, Cullen Jennings wrote: >>>>> >>>>> We believe this revision addresses the following DISCUSS comments: >>>>> >>>>> Jari Arkko Adrian Farrel Robert Sparks Peter Saint-Andre Dan >>>>> Romascanu Russ Housley >>>>> >>>>> Note: we did not address non-DISCUSS comments. We are planning to >>>>> do that on a subsequent pass. >>>>> >>>>> Most of the changes are editorial/clarifying, however, a number >>>>> were substantive (though generally not breaking). Here's a summary >>>>> of what we believe the major ones are: >>>>> >>>>> * Changed the certificate enrollment protocol to remove the >>>>> password from the URL. Note that this is a breaking change. >>>>> >>>>> * Globally renamed "private id" and "compressed id" to "opaque id" >>>>> >>>>> * Specified the details of the overlay name (S 5.3.2) >>>>> >>>>> * Nailed down the fragment semantics, harmonizing between the >>>>> fragment field defn. and the rules for generating fragments. The >>>>> high bit must always be set and unfragmented packets are >>>>> represented as the last fragment with an offset of 0. >>>>> >>>>> * Specified new requirements for malicious loop prevention: >>>>> >>>>> - Configuration servers are supposed to set TTL based on overlay >>>>> size. - Peers must check that TTL never exceeds the configured >>>>> maximum. - Peers should check for duplicates in the destination >>>>> list. >>>>> >>>>> * Added a new Error_Invalid_Message generic error code. >>>>> >>>>> In terms of schedule, we plan to spin a new draft before the draft >>>>> deadline that addresses all the DISCUSS comments and as many of >>>>> the comments as possible. >>>>> >>>> >>>> I hate to be the one complaining again, but because the "final" >>>> draft will be released around March 11th, there will be only 2 weeks >>>> to review, implement, and try to fix it before the P2PSIP meeting >>>> itself and we all know how busy these few weeks before a meeting are. >>>> My prediction is that the meeting will be simply a list of issues or >>>> fixes that people will have no time to analyze and understand and >>>> that this meeting will be, like the one in Taipei, a waste of time. >>>> Won't it be more efficient to finish this now, which would give two >>>> months to be sure that everything is OK, and declare victory in >>>> Paris? >>>> >>> >>> >>> If anyone wants to help, we'd love some help. The problem is several of >>> us are wrapped up in the W3C WebRTC and IETF RTCWeb interim meetings >>> from now till Feb 1 so I suspect that there will not be time put into >>> it for the next 10 days unless someone else does something. My fear is >>> it would take too long for most people to get up to speed on it. We did >>> try to order the discusses such that we fixed one that might impact >>> implementations first. >>> >> >> Just after the meeting in Taipei, I was trying to convince someone to >> come to the RELOAD interop event in Paris. The response was that the >> implementation will not be ready in time, because they will not start >> until RELOAD is finished. I understand - when I saw -20 I was ready to >> do a complete review and to update my code, but after seen your email, I >> stopped bothering, I'll just wait for -21. Or -22. Or -23, it's a prime >> number and I like prime numbers. >> > > The draft will be done when it is an RFC. Obviously implementation of > intermedia drafts is good. > > >> Also I have unpublished drafts that I am holding because it is not >> possible to present anything new at a WG meeting - what's the point >> anyway if the response is invariably "we need to finish RELOAD first"? > > People were objecting to new work until the draft had been send to IESG. > That has happened. I don't see any objections to new work in the WG. > > >> People are now presenting their drafts in samrg, I'll probably do that >> too, and skip the p2psip meeting. > > I'd present them anywhere you thought you had the right people to review > them and build consensus around them. For some drafts, samrg may be a great > place - for others - likely a bad place. > > >> >> On the other hand I completely understand the pressure of other works and >> that nobody can sustain the same interest and enthusiasm on a specific >> subject for the many years that are required to standardize anything. > > My first draft on this was published in 2005. Work on pre socialization of > Reload/Vipr/Location Anonymization started well before them. I imagine > that it will be somewhere around 2015 when all the key drafts for Reload / > Vipr will be done and if we go forward with Location Anonymization that > will like be after 2020 before it is an RFC. Given that is the type of time > frame it takes, Cisco prefers for me to on several things in parallel. > Thought this sometimes causes something thing to slow down, it's more > efficient overall. When we decide to have an interim meeting of one WG at > IETF, it slows down work in others WGs. The ADs do their best to strike > some sort of reasonable balance across the area. > >> >> What I do not understand is why the chairs did not step in and named >> additional editors to this draft. > > It would not have helped. If anyone has time or energy to help here - glad > to get them synchronized into doing something that helps get things done > faster. > Well, thanks for putting things in perspective. - -- 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) iQIcBAEBCAAGBQJPHZ4mAAoJECnERZXWan7EYL0QALMhuurY9GEIrc+4Qry/grkA BjDt4Y0RzGVe6ofV62YQiQDCIOg9mRj0+GJzSaI1O0b+iTqGxiAmMpPHq8IvvOjs s6PsdXhotiyD8peHQWncpJRO6hpYqQxV1B+M7g2VH9KDmav7fcvhua846CQ4T6FC hIGWl3tQJSwB0AVZLqUDJSbt4Kuzy2ObM7CMxy2Q2Wjw+UnaVWnCGpM1/i+r4eHx hnRp8ozE3z3fV9+uTwFdXnQzvwxojQ/ZK/X6sJCZw6/J0S9HDPTOSqjGYkfMrK4C hNABYWvdEgBTgtGNPdrOErbJdVP+jcMgNZqOv3EPFxr/QAoudztYutjbdHxxpKTr wspS/0TbXdjHoSQAURop4a+ICRCte4QoYvbBiDYFTXF7TB893FFPlPLcr4xyaPoU bU3kn3P7bqiHdWjpCaxVuJ7uGv4wMgzY4WuTdB0Xjzh6M5BMraLAJTQapDespygz 9TvJw1KVWtw3ewPYSEyu8BVf/D30tbdT/GiBaRarJi2zkjxXHm09tCXUT++qOkji Of35w7HaWsa6vjHLpttK/twjp1l4QLWaqAPV2NmBeiRxhgl407r6FXMhKx3EEG4U RLBVdmeX2d0WzMO3ypTAC21f/iV/HqZFjyP64XZTHAdEiDAJ0xqVUjMDstH2Av7Q S9ZqDjv5kZuuPvZ5SsYS =iEBU -----END PGP SIGNATURE----- From michaelc@IDSSOFTWARE.COM Mon Jan 23 21:04:50 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 7048A11E8075 for ; Mon, 23 Jan 2012 21:04:50 -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 wvU96j3X-9BD for ; Mon, 23 Jan 2012 21:04:49 -0800 (PST) Received: from smtpoutwbe01.prod.mesa1.secureserver.net (smtpoutwbe01.prod.mesa1.secureserver.net [208.109.78.112]) by ietfa.amsl.com (Postfix) with SMTP id CD83611E8073 for ; Mon, 23 Jan 2012 21:04:49 -0800 (PST) Received: (qmail 14535 invoked from network); 24 Jan 2012 05:04:49 -0000 Received: from unknown (HELO localhost) (72.167.218.131) by smtpoutwbe01.prod.mesa1.secureserver.net with SMTP; 24 Jan 2012 05:04:48 -0000 Received: (qmail 3597 invoked by uid 99); 24 Jan 2012 05:04:48 -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.10 Message-Id: <20120123220447.61e8c06078a3b23a733c71e914c0b9df.cbaffa24c6.wbe@email03.secureserver.net> From: "Michael Chen" To: "Cullen Jennings" , "P2PSIP Mailing List" Date: Mon, 23 Jan 2012 22:04:47 -0700 Mime-Version: 1.0 Subject: Re: [P2PSIP] Update of reload base draft 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, 24 Jan 2012 05:04:50 -0000 Cullen,=0A=0ABack in September and October of last year, I posted 6 questio= ns and=0Asuggested corrections to base-19, but all of them went on unanswer= ed. I=0Aalso don't see them being addressed by base-20. These are their sub= ject=0Alines:=0A=0A[P2PSIP] Base draft section 6.4.3.2 Stat Response Defini= tion=0Aclarification, Michael Chen=0A[P2PSIP] Question about base draft sec= tion 9.7.4.2, Michael Chen=0A[P2PSIP] Base section 10.4 clarification, Mich= ael Chen=0A=0A[P2PSIP] Base draft 9.5 bullet 2 needs to be revised, Michael= Chen=0A[P2PSIP] Question about base draft 9.7.4.4 Detecting partitioning,= =0AMichael Chen=0A[P2PSIP] Base draft 9.7.4.1 title does not match its cont= ent, Michael=0AChen=0A=0AWould any of the key members revisit and reply the= m?=0A=0AThanks=0A=0A--Michael=0A=0A> -------- Original Message --------=0A>= Subject: [P2PSIP] Update of reload base draft=0A> From: Cullen Jennings =0A> Date: Tue, January 17, 2012 6:43 pm=0A> To: P2PSIP Mai= ling List =0A> =0A> =0A> We believe this revision addresse= s the following DISCUSS comments:=0A> =0A> Jari Arkko=0A> Adrian Farrel=0A>= Robert Sparks=0A> Peter Saint-Andre=0A> Dan Romascanu=0A> Russ Housley=0A>= =0A> Note: we did not address non-DISCUSS comments. We are planning to=0A>= do that on a subsequent pass.=0A> =0A> Most of the changes are editorial/c= larifying, however, a number=0A> were substantive (though generally not bre= aking). Here's a summary=0A> of what we believe the major ones are:=0A> =0A= > * Changed the certificate enrollment protocol to remove the=0A> password= from the URL. Note that this is a breaking change.=0A> =0A> * Globally ren= amed "private id" and "compressed id" to "opaque id"=0A> =0A> * Specified t= he details of the overlay name (S 5.3.2)=0A> =0A> * Nailed down the fragmen= t semantics, harmonizing between the fragment=0A> field defn. and the rule= s for generating fragments. The high bit must=0A> always be set and unfra= gmented packets are represented as the last=0A> fragment with an offset of= 0.=0A> =0A> * Specified new requirements for malicious loop prevention:=0A= > =0A> - Configuration servers are supposed to set TTL based on=0A> ove= rlay size.=0A> - Peers must check that TTL never exceeds the configured=0A= > maximum.=0A> - Peers should check for duplicates in the destination= =0A> list.=0A> =0A> * Added a new Error_Invalid_Message generic error co= de.=0A> =0A> In terms of schedule, we plan to spin a new draft before the d= raft=0A> deadline that addresses all the DISCUSS comments and as many=0A> o= f the comments as possible.=0A> =0A> Ekr, Bruce, & Cullen=0A> =0A> ________= _______________________________________=0A> P2PSIP mailing list=0A> P2PSIP@= ietf.org=0A> https://www.ietf.org/mailman/listinfo/p2psip=0A From fluffy@cisco.com Tue Jan 24 06:00:29 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 83ED521F853B for ; Tue, 24 Jan 2012 06:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.234 X-Spam-Level: X-Spam-Status: No, score=-106.234 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaeu92ClBcMU for ; Tue, 24 Jan 2012 06:00:28 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C828121F8530 for ; Tue, 24 Jan 2012 06:00:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3318; q=dns/txt; s=iport; t=1327413628; x=1328623228; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=HMTX8gR9Ml6D4efhpl9aDPGetImtRoHRyZrPZ9JxnTs=; b=QoFsyJq4VjBvVvFle4SW4MCDL0V0baBwomGES/tO1g4yoo6ISfmUbwSu /dke0xu6YSm3qfqcf9unEUM55HPiqyf0LWwxoKGZfdwk1nN4WvU8+yt2L j0PwWXYNlYt8Z61wBJVbbxA3DmzSwukJ+Uze/UECVfPLFhI6u0dNVEutv s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHe4Hk+rRDoI/2dsb2JhbABCrjCBBYFyAQEBAwEBAQEPASc0CwUHBAsRAwECGRYnKAgGEyKHWgiaAwGeKwSJDgMGAwYGAgEKAiKCTg8IDxdVAQoBMoI3YwSIP4xekm8 X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="25190687" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 24 Jan 2012 14:00:28 +0000 Received: from sjc-vpn4-294.cisco.com (sjc-vpn4-294.cisco.com [10.21.81.38]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0OE0RuZ032609; Tue, 24 Jan 2012 14:00:27 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <20120123220447.61e8c06078a3b23a733c71e914c0b9df.cbaffa24c6.wbe@email03.secureserver.net> Date: Tue, 24 Jan 2012 06:00:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <50196E7A-8817-48B0-B4EE-B599E7A32E05@cisco.com> References: <20120123220447.61e8c06078a3b23a733c71e914c0b9df.cbaffa24c6.wbe@email03.secureserver.net> To: "Michael Chen" X-Mailer: Apple Mail (2.1251.1) Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Update of reload base draft 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, 24 Jan 2012 14:00:29 -0000 20 only addressed some discusses from some of the IESG and not even all = of theses. It did not deal with comments from IESG or other comments = from the list so we did not get those in but I imagine they are still on = the queue to go look at but thank you for grabbing the subjects. On Jan 23, 2012, at 21:04 , Michael Chen wrote: > Cullen, >=20 > Back in September and October of last year, I posted 6 questions and > suggested corrections to base-19, but all of them went on unanswered. = I > also don't see them being addressed by base-20. These are their = subject > lines: >=20 > [P2PSIP] Base draft section 6.4.3.2 Stat Response Definition > clarification, Michael Chen > [P2PSIP] Question about base draft section 9.7.4.2, Michael Chen > [P2PSIP] Base section 10.4 clarification, Michael Chen >=20 > [P2PSIP] Base draft 9.5 bullet 2 needs to be revised, Michael Chen > [P2PSIP] Question about base draft 9.7.4.4 Detecting partitioning, > Michael Chen > [P2PSIP] Base draft 9.7.4.1 title does not match its content, Michael > Chen >=20 > Would any of the key members revisit and reply them? >=20 > Thanks >=20 > --Michael >=20 >> -------- Original Message -------- >> Subject: [P2PSIP] Update of reload base draft >> From: Cullen Jennings >> Date: Tue, January 17, 2012 6:43 pm >> To: P2PSIP Mailing List >>=20 >>=20 >> We believe this revision addresses the following DISCUSS comments: >>=20 >> Jari Arkko >> Adrian Farrel >> Robert Sparks >> Peter Saint-Andre >> Dan Romascanu >> Russ Housley >>=20 >> Note: we did not address non-DISCUSS comments. We are planning to >> do that on a subsequent pass. >>=20 >> Most of the changes are editorial/clarifying, however, a number >> were substantive (though generally not breaking). Here's a summary >> of what we believe the major ones are: >>=20 >> * Changed the certificate enrollment protocol to remove the >> password from the URL. Note that this is a breaking change. >>=20 >> * Globally renamed "private id" and "compressed id" to "opaque id" >>=20 >> * Specified the details of the overlay name (S 5.3.2) >>=20 >> * Nailed down the fragment semantics, harmonizing between the = fragment >> field defn. and the rules for generating fragments. The high bit = must >> always be set and unfragmented packets are represented as the last >> fragment with an offset of 0. >>=20 >> * Specified new requirements for malicious loop prevention: >>=20 >> - Configuration servers are supposed to set TTL based on >> overlay size. >> - Peers must check that TTL never exceeds the configured >> maximum. >> - Peers should check for duplicates in the destination >> list. >>=20 >> * Added a new Error_Invalid_Message generic error code. >>=20 >> In terms of schedule, we plan to spin a new draft before the draft >> deadline that addresses all the DISCUSS comments and as many >> of the comments as possible. >>=20 >> Ekr, Bruce, & Cullen >>=20 >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@fluffy.im Mon Jan 23 09:16:50 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 6C2EA21F8650 for ; Mon, 23 Jan 2012 09:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkStW401CYh9 for ; Mon, 23 Jan 2012 09:16:49 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 50DD821F843C for ; Mon, 23 Jan 2012 09:16:49 -0800 (PST) Received: by iagf6 with SMTP id f6so4219199iag.31 for ; Mon, 23 Jan 2012 09:16:48 -0800 (PST) Received: by 10.50.168.4 with SMTP id zs4mr10660254igb.28.1327339008755; Mon, 23 Jan 2012 09:16:48 -0800 (PST) Received: from dhcp-171-68-21-10.cisco.com (dhcp-171-68-21-10.cisco.com. [171.68.21.10]) by mx.google.com with ESMTPS id gd2sm17969390igc.1.2012.01.23.09.16.47 (version=SSLv3 cipher=OTHER); Mon, 23 Jan 2012 09:16:48 -0800 (PST) Sender: Cullen Jennings Mime-Version: 1.0 (Apple Message framework v1251.1) From: Cullen Jennings In-Reply-To: <4F1D70DE.6020300@acm.org> Date: Mon, 23 Jan 2012 09:16:47 -0800 Message-Id: <7A3488FD-31AE-4877-9CCF-794ED9A31EE7@iii.ca> References: <345BA2F8-6486-4E57-AC67-24F24C7D0EB0@cisco.com> <4F19EB90.5090409@acm.org> <4F1D70DE.6020300@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1251.1) X-Gm-Message-State: ALoCoQkq0AEUiAxSVxgJETws9X7PGSN1X8hB66gkGdl+BVu0UM2Q44+d40/Q+jrXmZuY507vK5we Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Update of reload base draft 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, 24 Jan 2012 14:21:40 -0000 On Jan 23, 2012, at 6:38 , Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > On 01/22/2012 08:44 PM, Cullen Jennings wrote: >>=20 >>=20 >> On Jan 20, 2012, at 14:32 , Marc Petit-Huguenin wrote: >>=20 >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>>=20 >>> On 01/17/2012 06:43 PM, Cullen Jennings wrote: >>>>=20 >>>> We believe this revision addresses the following DISCUSS comments: >>>>=20 >>>> Jari Arkko Adrian Farrel Robert Sparks Peter Saint-Andre Dan = Romascanu=20 >>>> Russ Housley >>>>=20 >>>> Note: we did not address non-DISCUSS comments. We are planning to = do=20 >>>> that on a subsequent pass. >>>>=20 >>>> Most of the changes are editorial/clarifying, however, a number = were=20 >>>> substantive (though generally not breaking). Here's a summary of = what >>>> we believe the major ones are: >>>>=20 >>>> * Changed the certificate enrollment protocol to remove the = password=20 >>>> from the URL. Note that this is a breaking change. >>>>=20 >>>> * Globally renamed "private id" and "compressed id" to "opaque id" >>>>=20 >>>> * Specified the details of the overlay name (S 5.3.2) >>>>=20 >>>> * Nailed down the fragment semantics, harmonizing between the = fragment >>>> field defn. and the rules for generating fragments. The high bit = must >>>> always be set and unfragmented packets are represented as the last=20= >>>> fragment with an offset of 0. >>>>=20 >>>> * Specified new requirements for malicious loop prevention: >>>>=20 >>>> - Configuration servers are supposed to set TTL based on overlay = size. >>>> - Peers must check that TTL never exceeds the configured maximum. - >>>> Peers should check for duplicates in the destination list. >>>>=20 >>>> * Added a new Error_Invalid_Message generic error code. >>>>=20 >>>> In terms of schedule, we plan to spin a new draft before the draft=20= >>>> deadline that addresses all the DISCUSS comments and as many of the=20= >>>> comments as possible. >>>>=20 >>>=20 >>> I hate to be the one complaining again, but because the "final" = draft >>> will be released around March 11th, there will be only 2 weeks to >>> review, implement, and try to fix it before the P2PSIP meeting = itself and >>> we all know how busy these few weeks before a meeting are. My = prediction >>> is that the meeting will be simply a list of issues or fixes that = people >>> will have no time to analyze and understand and that this meeting = will >>> be, like the one in Taipei, a waste of time. Won't it be more = efficient >>> to finish this now, which would give two months to be sure that >>> everything is OK, and declare victory in Paris? >>>=20 >>=20 >>=20 >> If anyone wants to help, we'd love some help. The problem is several = of us=20 >> are wrapped up in the W3C WebRTC and IETF RTCWeb interim meetings = from now=20 >> till Feb 1 so I suspect that there will not be time put into it for = the >> next 10 days unless someone else does something. My fear is it would = take >> too long for most people to get up to speed on it. We did try to = order the >> discusses such that we fixed one that might impact implementations = first. >>=20 >=20 > Just after the meeting in Taipei, I was trying to convince someone to = come to > the RELOAD interop event in Paris. The response was that the = implementation > will not be ready in time, because they will not start until RELOAD is > finished. I understand - when I saw -20 I was ready to do a complete = review > and to update my code, but after seen your email, I stopped bothering, = I'll > just wait for -21. Or -22. Or -23, it's a prime number and I like = prime numbers. >=20 The draft will be done when it is an RFC. Obviously implementation of = intermedia drafts is good.=20 > Also I have unpublished drafts that I am holding because it is not = possible to > present anything new at a WG meeting - what's the point anyway if the = response > is invariably "we need to finish RELOAD first"? =20 People were objecting to new work until the draft had been send to IESG. = That has happened. I don't see any objections to new work in the WG.=20 > People are now presenting > their drafts in samrg, I'll probably do that too, and skip the p2psip = meeting. I'd present them anywhere you thought you had the right people to review = them and build consensus around them. For some drafts, samrg may be a = great place - for others - likely a bad place. >=20 > On the other hand I completely understand the pressure of other works = and that > nobody can sustain the same interest and enthusiasm on a specific = subject for > the many years that are required to standardize anything. My first draft on this was published in 2005. Work on pre socialization = of Reload/Vipr/Location Anonymization started well before them. I = imagine that it will be somewhere around 2015 when all the key drafts = for Reload / Vipr will be done and if we go forward with Location = Anonymization that will like be after 2020 before it is an RFC. Given = that is the type of time frame it takes, Cisco prefers for me to on = several things in parallel. Thought this sometimes causes something = thing to slow down, it's more efficient overall. When we decide to have = an interim meeting of one WG at IETF, it slows down work in others WGs. = The ADs do their best to strike some sort of reasonable balance across = the area. =20 >=20 > What I do not understand is why the chairs did not step in and named > additional editors to this draft. It would not have helped. If anyone has time or energy to help here - = glad to get them synchronized into doing something that helps get things = done faster.=20 >=20 > - --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org >=20 From petithug@acm.org Mon Jan 30 15:47:51 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 C4BE811E80F7 for ; Mon, 30 Jan 2012 15:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.256 X-Spam-Level: X-Spam-Status: No, score=-102.256 tagged_above=-999 required=5 tests=[AWL=0.344, 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 QhQzqdwsW7YQ for ; Mon, 30 Jan 2012 15:47:50 -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 097C311E80DC for ; Mon, 30 Jan 2012 15:47:50 -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 CB87420142 for ; Mon, 30 Jan 2012 23:33:13 +0000 (UTC) Message-ID: <4F272C22.3030109@acm.org> Date: Mon, 30 Jan 2012 15:47:46 -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 Mailing List X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Minutes for 2012/01/27 conference call 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, 30 Jan 2012 23:47:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 VIPR Design Team conference call on Friday January 27h, from 9:05am to 9:55am PST. o Attendees: Mary Barnes Kurt Bergsbaken Daryl Malas Hakim Mehmood Jon Peterson Marc Petit-Huguenin Michael Procter John Ward Dean Willis o Regrets Muthu Arul Mozhi Perumal o Agenda - - Privacy issue o Action items - - We continue working on VIPR. - - Michael to update his document, please send text. o Minutes Marc: I propose to talk about the privacy problem is 3 steps. First we need to agree that this is really a problem. Option 4, proposed by Richard Barnes, was to not do anything about this. If we agree that this is problem, then the second question is do we agree that this requires modification in RELOAD. Then the 3rd step would be to decide what to do, knowing that doing anything in RELOAD will take a long time. Daryl: If this problem has not shown itself in p2psip, I am curious to know if this problem is unique to VIPR, and then to decide if we want to do any modification to RELOAD. Marc: My original plan was to work on VIPR until December, I extended for 3 months, but after the meeting in Paris I will no longer be able to put as much work on VIPR. So let's be sure that we have some kind of decision at the end of this meeting, so I know if I am going to Paris or not. Marc: So is this privacy issue really a problem? Dean: This is a real problem. You have a 50% chance of being in the first attempt of verifying the connection, and for every registration you increase your odds. Michael: It's right if you stop after the first success. Jon: The reason for doing that relates to things that are still controversial, like SIP intermediaries. From my perspective, it's an interesting problem, but I do not think that it is a showstopper in the sense that I do not think that VIPR is worthless if it has this liability. I would be comfortable with documenting the problem, and measures that mitigates it. And I would also be comfortable with saying is there a way to really do an anonymous DHT, but it's almost a research project. But I certainly do not think that it render useless and that we should go home. Hakim: I agree with everything you said. Marc: Should we put a requirement in the -overview document saying that we must fix this privacy problem, and is it just something that we should work on in the future? Jon: There is specific threat models that we can discuss. There is a difference between someone who register for one number and someone who register for all numbers. For example this is an argument to not go through all registrations. But there is no fix for this, as there is no fix for SIP security issues. Daryl: I agree with that. There is a lot of architectures that VIPR works very well within. Dean: There is potential mitigation that we can build going forward. For example adding a web of trust. Alice calls Bob and successfully validates, then Alice put something in the overlay saying this, then Charlie, who has an existing relationship with Alice might then be more inclined to trust the validation of Bob. This is things that we can address going forward. We can also came with suggestions for RELOAD, and have the RELOAD design change over time, but they will not change RELOAD in this round. But that does not prevent a first version of the protocol to be released. Daryl: I like that approach. To go back to what Jon said, in the early days of SIP, there was concerns around security issues, workarounds were documented, but still people do not implement them - people still are not doing SIP over TLS. Michael: There is plenty of things we can do to attack the problem, but if we continue with the idea that there will be only one VIPR network, globally, that make it a lot harder for us to solve these problems. If we define things that should work with a group of participants, then I think that we can make something that has all the properties for that group of users. But if we focus on one overlay for the whole planet, then these problems will really bite. Jon: I am sure that the designers of VIPR would be reluctant to give up the property that there something that everyone can join and that it is public. I would prefer that we keep that property. Daryl: Are you suggesting to have multiple VIPR networks, and have some sort of inter-domain communication? Jon: Michael is suggesting that it is the public nature of VIPR that is creating all these problems. If you imagine a closed trusted community of enterprises, that would be one way to prevent rogue party to entering and putting bogus registrations. Cullen alluded to a common CA, so if everybody follow a trust anchor, we can trace who everybody who is participating is. Daryl: So it's a federation that's being established. Jon: That does not change RELOAD. Changing RELOAD will not happen in any reasonable time. Daryl: I totally agree. And I agree with the federation that you described. Jon: Michael, do you think that the only way to combating this is to split the overlay, or do you think there is alternatives? Michael: For some of the attacks we can probably work out mitigation while maintaining a single DHT. But I do not think that we can capture all the problems, and I fear that we will end up with one DHT that cause this huge problem. A lot of these problems seems to go away if you deploy in small groups, so maybe one approach is to finish off a version of VIPR that is suitable for groups that prominently trust each other. Jon: Does the current specification mandates a single overlay? Marc: The specification assumes only one DHT. Dean: Even with one VIPR cloud, one could imagine adding information in the overlay to track the relationship between CAs. Marc: This is not a small modification of VIPR. Jon: A lot of the mitigation solutions would be looking at the registrations deciding why one is preferred over the others. Hakim: You could have one more step where the Fetch comes from your trusted domain, so you do not start PVP. Jon: It's like a whitelist, The original design was really to have an introductory system, to be a way to use the PSTN as a bootstrap. We can argue to a point where it's no longer doing what it's supposed to do. Hakim: It's part of the mitigation. At the end the goal is for everybody to use VIPR with confidence, and not undermine privacy and security, but those measures should be recommended, not mandated. Marc: If we can anonymize the PVP connection and the RELOAD transactions, then we can solve this problem without adding more verifications. Hakim: Agreed. Jon: I am not even sure where to start with that. That's almost a research problem. Marc: Yes and the problem is that RELOAD is not the best place to do that currently. Jon: I agree that anonymyzing RELOAD would be great, but that would require a new working group, a different charter, and would complete in 5/7 years. If we want to continue, our job is to figure how to mitigate with the current system. Hakim: Was your comment about anonymizing the IP address? Jon: Yes, because from the source IP address you can find the enterprise. Hakim: If we use TURN and method B, it would hide the source IP address and the Caller-ID. Jon: The problem with TURN is that you do not necessarily trust the people you are asking. You need several hops, to have a reasonable assurance that the nodes you are using are not bad actors. And I suspect that would be a very different model for RELOAD. Michael: You still leak the fact that someone has requested the record for that phone number. Jon: That's why it's important to articulate the whole set of threats. But if your could solve the problem of hiding analytics, the bittorrent community would be so thrilled. Michael: But the point is that with bittorrent, who have the choice to not participate, but with VIPR, you do not. Jon: When I was first reading about this problem, I though about fixing it the other way: is there anyway we can get as many registrations done as possible. There is the interesting property that says that as soon the validation is done, you are no longer vulnerable, until you need a revalidation. But the result for an attacker will be very unpredictable. Michael: I agree. John: We are talking for the point of view of an attacker, but there is all kind of usages for intermediaries. For example I can query the DHT and determine the network topology of my competitors. Jon: The network topology under VIPR is pretty flat. John: We will not get away from the point where there will not be intermediaries. Jon: It's another approach to privacy. Dean : Yes, if there is 3 aggregators in the world, there is not much information leak. Jon: We need to document thoroughly that the threat is first. One is where someone is curious about a particular phone number. Another is to collect information on any number. For each of these threats we need to understand what they can accomplish, do we have any way to detecting it, and finally what change to the design we can make to mitigate that. Daryl: Would this potentially cause a situation where these become just proprietary VIPR. I do not want to say at the end to go to one vendor. Dean: How would we block aggregator choice of delivery? Daryl: The goal is to encourage various vendors to participate, not to create these proprietary aggregations that never talk to each other. Jon: We can add compromising RELOAD to the list of threats. Dean: Do we have something like the voice hammer attack? Marc: There is a quota mechanism in RELOAD, so the more registrations you put on the network, the more hardware you need to contribute. Jon: Yes, these are active attacks. But we should separate the from the passive attacks. The privacy attacks are discoverable, because you can look after the fact. Dean: You can also do self verification of validation, i.e. audit your phone number and if there is strange registrations, make inquiries. Jon: Yes, each time there is a failed validation you can record it, and we can flag the source. Marc: Yes and remember that in RELOAD there is a blacklist mechanism, so the people responsible for the overlay configuration document can prevent specific nodes to join. But note that it is not because a registration fails that the guy at the other side is a bad guy. There is a lot of reasons why a registration can fail and still be a legitimate node. We do not want to go overboard, and create a new attack that prevent the right owner to participate. Jon: Yes, but if every node reports that there is a problem with a particular entity, then there is a consensus that there is a problem. Marc: OK, we have a consensus that we should continue to work on this, and we agree to document the use cases. Michael: Please send text. - -- 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) iQIcBAEBCAAGBQJPJywgAAoJECnERZXWan7E9xEQAIBsIE9/58t4veAuUe0ixg6z Csp7PRhrWC2g1ExMgkaHrchGpBJ751b6PxpMK+CSIKyjWKxcpbZLkEMrUjvD6jog 1SFHGPKUCK4QepWrWPjS9isLQhLLSifp3jZR/nY3mvGqgOfavg6G3gUkk88H9cKQ u18iedJ0cAi278XhZNMJ1qkJ8PGJeIaTKMWo/sGIR2DqrzEbyLNVXJLoaAsryMFs S5BvAClumB79nEV5uHG2GRecpsyKKua4NtlZYY8D3OURJpi1nCKRM4HIgQasalXk Qnham7L780cuKcMHEdFR9uMGldDf9vCoU1p6tTFAVTzXa+UT7K4eAKjNd3MZxzt3 eLi0YPeYkzej0O6MKydUOaIvOtvJmyVcPJCXVs8cHxxU7mqyW4nX7nnG8fcXUwyx 3adzeG2lgfJ0LqOGSc0dLTrXwU+cMSOXLuHrMRBqk4Z8EPhsfvw8TmNZ8yUXXLDC jnWn3FGc2xsaHQY3uzaPIg7COc/b/b11ZJwBmt9mUXEgjvehJXO2RjQ5ulmPqaNg mlmdeOoIzaq+3u/9zbCRcoCA0EP1BUY50RXLSEpsM4/YyOrLfD0kbz04FT2lYWBV u0qM7PW7qi0ezvvOj+mEkOtMfxkr6OnPLdbLBLvUFPtpMm60FbDcDt0dkQwDTk2j tiufVuzHCVINEog6aKbD =zssh -----END PGP SIGNATURE----- From petithug@acm.org Mon Jan 30 15:50:46 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 8DE3B11E80F7 for ; Mon, 30 Jan 2012 15:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.275 X-Spam-Level: X-Spam-Status: No, score=-102.275 tagged_above=-999 required=5 tests=[AWL=0.325, 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 As1JWnX2zv7y for ; Mon, 30 Jan 2012 15:50:45 -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 80AAB11E80EA for ; Mon, 30 Jan 2012 15:50:44 -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 04C7320142 for ; Mon, 30 Jan 2012 23:36:08 +0000 (UTC) Message-ID: <4F272CD2.2080301@acm.org> Date: Mon, 30 Jan 2012 15:50:42 -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 Mailing List References: <4F272C22.3030109@acm.org> In-Reply-To: <4F272C22.3030109@acm.org> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [P2PSIP] Minutes for 2012/01/27 conference call 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, 30 Jan 2012 23:50:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Sorry, wrong mailing-list. On 01/30/2012 03:47 PM, Marc Petit-Huguenin wrote: > VIPR Design Team conference call on Friday January 27h, from 9:05am to > 9:55am PST. > - -- 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) iQIcBAEBCAAGBQJPJyzRAAoJECnERZXWan7E/eQP/3y5YywBjy4dJPL1eHIZz9FM t+8yyZgeDWJ1Jm3IiqS24Uic2tBZNM1Kwkd0ELcEPvGwCCk5EcEO/oMWrjRpTtnu j/u7Rm4ot6MGcGY4h02e+vz1hCIh0udx3NNvRD9OVWIN0n6o2ds9ZhERklvPbN4k Mao/4LPmPoUHX32bgbz7PCzM6E0Uj7lWV2cWYczEgO7+iYcLDmZiTgzt51cLOXUi uO/KdSDPMzvnv5AzxmxMlAuPLdrtDM+0NwVsUnEwPZAn2VowKgWwfN/NCtkLCXTN GU5DL1gKXB3tGLR7hM/w4ciXbnNG4rjvt9f0Fbsw5+1Gzbtu3eXdDTBe9qPjBxEC eHs55zdPemUxfGD4erstGsdN4j8QvfsUYoLAk5uwBvZgf12V8woE9cr5KjGMGZTY 6jf3W3DOan4y8d1pgh+/fN6wYVWljuuUMgJuUBuc0/xPPf4XJs+pm2kXEeM8Psg8 fiZ8BR3J4ArzdYYZq65nW2LfYtp/h76GedHhQ4gevaS6z/1oxSgksPpgJTMuJDWt UR5GYzEvvdC8E4F8Eh3lmnUj6k4rnaSUTPrWAE26wCN+89KELaZxb+xdI3e4eyi3 DVlKMP55DU9jBL1AzOiwsHYLK8Oe43Ta5a1KTSHMX6I7QP2OANGSSDLqKVLm3Z8U haNJx2Lx38YivHObKOPY =PiAQ -----END PGP SIGNATURE-----