From internet-drafts@ietf.org Mon Feb 4 00:51:29 2013 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 387A021F85FD; Mon, 4 Feb 2013 00:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HN8C--OMKptQ; Mon, 4 Feb 2013 00:51:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE89B21F85FE; Mon, 4 Feb 2013 00:51:28 -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: 4.37 Message-ID: <20130204085128.10582.76426.idtracker@ietfa.amsl.com> Date: Mon, 04 Feb 2013 00:51:28 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-10.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, 04 Feb 2013 08:51:29 -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 Protocol = Working Group of the IETF. Title : P2P Overlay Diagnostics Author(s) : Haibin Song Jiang Xingfeng Roni Even David A. Bryan Filename : draft-ietf-p2psip-diagnostics-10.txt Pages : 31 Date : 2013-02-04 Abstract: This document describes mechanisms for P2P overlay diagnostics. It defines extensions to the RELOAD P2PSIP base protocol RELOAD [I-D.ietf-p2psip-base] to collect diagnostic information, and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics in a P2PSIP overlay networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-diagnostics-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From haibin.song@huawei.com Mon Feb 4 01:00:25 2013 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 A773D21F85AE for ; Mon, 4 Feb 2013 01:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kY2g5XqPA47Y for ; Mon, 4 Feb 2013 01:00:25 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BA95B21F85AD for ; Mon, 4 Feb 2013 01:00:19 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APK34156; Mon, 04 Feb 2013 09:00:19 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 4 Feb 2013 08:59:30 +0000 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 4 Feb 2013 09:00:18 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.101]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Mon, 4 Feb 2013 17:00:11 +0800 From: "Songhaibin (A)" To: P2PSIP WG Thread-Topic: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-10.txt Thread-Index: AQHOArTmNrR0hfvDXUaSolqO9AWzLZhpZIIw Date: Mon, 4 Feb 2013 09:00:10 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Rosen, Brian" Subject: [P2PSIP] FW: I-D Action: draft-ietf-p2psip-diagnostics-10.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, 04 Feb 2013 09:00:25 -0000 Hi guys, We have made quite a few changes to the p2psip diagnostics draft, now we be= lieve it has solved the comments from the WGLC with solutions from last IET= F meeting consensus. Maybe a second WGLC is needed for more sufficient revi= ew.=20 BR, -Haibin > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf = Of > internet-drafts@ietf.org > Sent: Monday, February 04, 2013 4:51 PM > To: i-d-announce@ietf.org > Cc: p2psip@ietf.org > Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-10.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Peer-to-Peer Session Initiation Protoco= l Working > Group of the IETF. >=20 > Title : P2P Overlay Diagnostics > Author(s) : Haibin Song > Jiang Xingfeng > Roni Even > David A. Bryan > Filename : draft-ietf-p2psip-diagnostics-10.txt > Pages : 31 > Date : 2013-02-04 >=20 > Abstract: > This document describes mechanisms for P2P overlay diagnostics. It > defines extensions to the RELOAD P2PSIP base protocol RELOAD > [I-D.ietf-p2psip-base] to collect diagnostic information, and details > the protocol specifications for these extensions. Useful diagnostic > information for connection and node status monitoring is also > defined. The document also describes the usage scenarios and > provides examples of how these methods are used to perform > diagnostics in a P2PSIP overlay networks. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-10 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-diagnostics-10 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From cjbc@it.uc3m.es Mon Feb 4 15:42:10 2013 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 F2A8E21F8B3A for ; Mon, 4 Feb 2013 15:42:09 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdVgZRV-LTGb for ; Mon, 4 Feb 2013 15:42:07 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 4F37421F8A89 for ; Mon, 4 Feb 2013 15:42:07 -0800 (PST) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D3325894A79; Tue, 5 Feb 2013 00:42:05 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [192.168.1.190] (82.158.126.26.dyn.user.ono.com [82.158.126.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id BE1BE766223; Tue, 5 Feb 2013 00:42:05 +0100 (CET) Message-ID: <1360021325.4214.18.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Songhaibin (A)" Date: Tue, 05 Feb 2013 00:42:05 +0100 In-Reply-To: References: Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19614.003 X-TM-AS-Result: No--26.065-7.0-31-1 X-imss-scan-details: No--26.065-7.0-31-1 Cc: "Rosen, Brian" , P2PSIP WG Subject: Re: [P2PSIP] FW: I-D Action: draft-ietf-p2psip-diagnostics-10.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es 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, 04 Feb 2013 23:42:10 -0000 Hi Haibin, Let us check it. We'll probably go for a second WGLC. Thanks, Carlos & Brian On Mon, 2013-02-04 at 09:00 +0000, Songhaibin (A) wrote: > Hi guys, > > We have made quite a few changes to the p2psip diagnostics draft, now we believe it has solved the comments from the WGLC with solutions from last IETF meeting consensus. Maybe a second WGLC is needed for more sufficient review. > > BR, > -Haibin > > > -----Original Message----- > > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: Monday, February 04, 2013 4:51 PM > > To: i-d-announce@ietf.org > > Cc: p2psip@ietf.org > > Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-10.txt > > > > > > 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 : P2P Overlay Diagnostics > > Author(s) : Haibin Song > > Jiang Xingfeng > > Roni Even > > David A. Bryan > > Filename : draft-ietf-p2psip-diagnostics-10.txt > > Pages : 31 > > Date : 2013-02-04 > > > > Abstract: > > This document describes mechanisms for P2P overlay diagnostics. It > > defines extensions to the RELOAD P2PSIP base protocol RELOAD > > [I-D.ietf-p2psip-base] to collect diagnostic information, and details > > the protocol specifications for these extensions. Useful diagnostic > > information for connection and node status monitoring is also > > defined. The document also describes the usage scenarios and > > provides examples of how these methods are used to perform > > diagnostics in a P2PSIP overlay networks. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-10 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-diagnostics-10 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip From iesg-secretary@ietf.org Tue Feb 5 20:21:09 2013 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 26FA921F8A22; Tue, 5 Feb 2013 20:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrouKS94jK-L; Tue, 5 Feb 2013 20:21:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9D421F8519; Tue, 5 Feb 2013 20:21:08 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130206042108.14054.8941.idtracker@ietfa.amsl.com> Date: Tue, 05 Feb 2013 20:21:08 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] Last Call: (REsource LOcation And Discovery (RELOAD) Base Protocol) to Proposed Standard X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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, 06 Feb 2013 04:21:09 -0000 The IESG has received a request from the Peer-to-Peer Session Initiation Protocol WG (p2psip) to consider the following document: - 'REsource LOcation And Discovery (RELOAD) Base Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-02-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Note that this is the second IETF LC on this draft. The document was revised in response to comments made during its IESG review. There were no real semantic or functional changes -- just clarifications in the wording, adding of references, and making word use and capitalization more consistent throughout the document. Abstract 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 needs to 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-p2psip-base/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-p2psip-base/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1191/ From cjbc@it.uc3m.es Thu Feb 7 02:22:44 2013 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 E340121F8472 for ; Thu, 7 Feb 2013 02:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drJJFioEXDGG for ; Thu, 7 Feb 2013 02:22:44 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 20ED421F845D for ; Thu, 7 Feb 2013 02:22:43 -0800 (PST) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9B504FA88DE; Thu, 7 Feb 2013 11:22:42 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 863229D29EA; Thu, 7 Feb 2013 11:22:42 +0100 (CET) Message-ID: <1360232562.4155.31.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: p2psip@ietf.org Date: Thu, 07 Feb 2013 11:22:42 +0100 Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19620.002 X-TM-AS-Result: No--19.538-7.0-31-1 X-imss-scan-details: No--19.538-7.0-31-1 Cc: p2psip-chairs@tools.ietf.org Subject: [P2PSIP] Milestones update and WG draft adoption call X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es 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, 07 Feb 2013 10:22:45 -0000 Dear all, During the last meeting there was consensus on adding a new milestone in our charter for a document on "Configuration of Access Control Policy in RELOAD" and adopting draft-petithuguenin-p2psip-access-control as WG document. Hereby we are asking about comments about adding this new milestone to our charter and also starting a consensus call on adopting draft-petithuguenin-p2psip-access-control-05 as WG document. More details about this document below: Title : Configuration of Access Control Policy in REsource LOcation And Discovery (RELOAD) Base Protocol Author(s) : Marc Petit-Huguenin Filename : draft-petithuguenin-p2psip-access-control-05.txt Pages : 12 Date : 2012-10-22 Abstract: This document describes an extension to the REsource LOcation And Discovery (RELOAD) base protocol to distribute the code of new Access Control Policies without having to upgrade the RELOAD implementations in an overlay. Last, but not least, since our milestones were a bit outdated, we want to also update them. Please find below an updated proposal. Please, send your comments about the milestones update and the WG adoption by Friday 15th. Thanks, Carlos & Brian Proposed (updated charter) Goals and Milestones Done WGLC of P2PSIP Peer Protocol document Done WGLC of P2PSIP Diagnostics document Done WGLC of P2PSIP Direct Response Draft Done WGLC of P2PSIP Relay Response Draft Feb 2013 Submit -00 draft on Configuration of Access Control Policy in RELOAD Feb 2013 Submit P2PSIP Peer Protocol document to the IESG (PS) Feb 2013 WGLC of P2PSIP Self-Tuning document Feb 2013 WGLC of P2PSIP Service Discovery document Jul 2013 WGLC of P2PSIP SIP Usage document Jul 2013 WGLC of P2PSIP Concepts document Jul 2013 Submit P2PSIP Diagnostics document to the IESG (PS) Jul 2013 Submit P2PSIP Self-Tuning document to the IESG (PS) Jul 2013 Submit P2PSIP Service Discovery document to the IESG (PS) Oct 2013 Submit P2PSIP Concepts document to the IESG (Informational) Oct 2013 Submit P2PSIP SIP Usage document to the IESG (PS) From haibin.song@huawei.com Thu Feb 7 17:19:55 2013 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 5227A1F0D09 for ; Thu, 7 Feb 2013 17:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGpG0oGZo5Wn for ; Thu, 7 Feb 2013 17:19:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D71D91F0D08 for ; Thu, 7 Feb 2013 17:19:53 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOG60174; Fri, 08 Feb 2013 01:19:53 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 8 Feb 2013 01:18:53 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 8 Feb 2013 01:19:52 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.101]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Fri, 8 Feb 2013 09:19:45 +0800 From: "Songhaibin (A)" To: "cjbc@it.uc3m.es" , "p2psip@ietf.org" Thread-Topic: [P2PSIP] Milestones update and WG draft adoption call Thread-Index: AQHOBR0W4B0EGim2B02QY03b6VOMephvKk9g Date: Fri, 8 Feb 2013 01:19:44 +0000 Message-ID: References: <1360232562.4155.31.camel@acorde.it.uc3m.es> In-Reply-To: <1360232562.4155.31.camel@acorde.it.uc3m.es> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.75] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "p2psip-chairs@tools.ietf.org" Subject: Re: [P2PSIP] Milestones update and WG draft adoption 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: Fri, 08 Feb 2013 01:19:55 -0000 I support both the draft adoption and the milestone change. -Haibin > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf = Of > Carlos Jes=FAs Bernardos Cano > Sent: Thursday, February 07, 2013 6:23 PM > To: p2psip@ietf.org > Cc: p2psip-chairs@tools.ietf.org > Subject: [P2PSIP] Milestones update and WG draft adoption call >=20 > Dear all, >=20 > During the last meeting there was consensus on adding a new milestone in > our charter for a document on "Configuration of Access Control > Policy in RELOAD" and adopting draft-petithuguenin-p2psip-access-control > as WG document. >=20 > Hereby we are asking about comments about adding this new milestone to > our charter and also starting a consensus call on adopting > draft-petithuguenin-p2psip-access-control-05 as WG document. More > details about this document below: >=20 > Title : Configuration of Access Control Policy in > REsource LOcation And Discovery (RELOAD) Base Protocol > Author(s) : Marc Petit-Huguenin > Filename : > draft-petithuguenin-p2psip-access-control-05.txt > Pages : 12 > Date : 2012-10-22 >=20 > Abstract: > This document describes an extension to the REsource LOcation And > Discovery (RELOAD) base protocol to distribute the code of new Access > Control Policies without having to upgrade the RELOAD implementations > in an overlay. >=20 > Last, but not least, since our milestones were a bit outdated, we want > to also update them. Please find below an updated proposal. >=20 > Please, send your comments about the milestones update and the WG > adoption by Friday 15th. >=20 > Thanks, >=20 > Carlos & Brian >=20 > Proposed (updated charter) >=20 > Goals and Milestones >=20 > Done WGLC of P2PSIP Peer Protocol document > Done WGLC of P2PSIP Diagnostics document > Done WGLC of P2PSIP Direct Response Draft > Done WGLC of P2PSIP Relay Response Draft > Feb 2013 Submit -00 draft on Configuration of Access Control > Policy in RELOAD > Feb 2013 Submit P2PSIP Peer Protocol document to the IESG (PS) > Feb 2013 WGLC of P2PSIP Self-Tuning document > Feb 2013 WGLC of P2PSIP Service Discovery document > Jul 2013 WGLC of P2PSIP SIP Usage document > Jul 2013 WGLC of P2PSIP Concepts document > Jul 2013 Submit P2PSIP Diagnostics document to the IESG (PS) > Jul 2013 Submit P2PSIP Self-Tuning document to the IESG (PS) > Jul 2013 Submit P2PSIP Service Discovery document to the IESG > (PS) > Oct 2013 Submit P2PSIP Concepts document to the IESG > (Informational) > Oct 2013 Submit P2PSIP SIP Usage document to the IESG (PS) >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From prvs=7449f0c68=schmidt@informatik.haw-hamburg.de Fri Feb 8 08:31:03 2013 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 59C6121F8750 for ; Fri, 8 Feb 2013 08:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tU7kuq87zzv0 for ; Fri, 8 Feb 2013 08:31:02 -0800 (PST) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id 350D921F8AB4 for ; Fri, 8 Feb 2013 08:31:01 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 08 Feb 2013 17:30:59 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id E8F0D1066AE5 for ; Fri, 8 Feb 2013 17:30:59 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21736-05 for ; Fri, 8 Feb 2013 17:30:59 +0100 (CET) Received: from [192.168.1.37] (unknown [91.112.103.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 41AD51066AE2 for ; Fri, 8 Feb 2013 17:30:59 +0100 (CET) Message-ID: <51152842.2080905@informatik.haw-hamburg.de> Date: Fri, 08 Feb 2013 17:30:58 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: p2psip@ietf.org References: <1360232562.4155.31.camel@acorde.it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Subject: Re: [P2PSIP] Milestones update and WG draft adoption 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: Fri, 08 Feb 2013 16:31:03 -0000 +1 Thomas On 08.02.2013 02:19, Songhaibin (A) wrote: > I support both the draft adoption and the milestone change. > > -Haibin > >> -----Original Message----- >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of >> Carlos Jesús Bernardos Cano >> Sent: Thursday, February 07, 2013 6:23 PM >> To: p2psip@ietf.org >> Cc: p2psip-chairs@tools.ietf.org >> Subject: [P2PSIP] Milestones update and WG draft adoption call >> >> Dear all, >> >> During the last meeting there was consensus on adding a new milestone in >> our charter for a document on "Configuration of Access Control >> Policy in RELOAD" and adopting draft-petithuguenin-p2psip-access-control >> as WG document. >> >> Hereby we are asking about comments about adding this new milestone to >> our charter and also starting a consensus call on adopting >> draft-petithuguenin-p2psip-access-control-05 as WG document. More >> details about this document below: >> >> Title : Configuration of Access Control Policy in >> REsource LOcation And Discovery (RELOAD) Base Protocol >> Author(s) : Marc Petit-Huguenin >> Filename : >> draft-petithuguenin-p2psip-access-control-05.txt >> Pages : 12 >> Date : 2012-10-22 >> >> Abstract: >> This document describes an extension to the REsource LOcation And >> Discovery (RELOAD) base protocol to distribute the code of new Access >> Control Policies without having to upgrade the RELOAD implementations >> in an overlay. >> >> Last, but not least, since our milestones were a bit outdated, we want >> to also update them. Please find below an updated proposal. >> >> Please, send your comments about the milestones update and the WG >> adoption by Friday 15th. >> >> Thanks, >> >> Carlos & Brian >> >> Proposed (updated charter) >> >> Goals and Milestones >> >> Done WGLC of P2PSIP Peer Protocol document >> Done WGLC of P2PSIP Diagnostics document >> Done WGLC of P2PSIP Direct Response Draft >> Done WGLC of P2PSIP Relay Response Draft >> Feb 2013 Submit -00 draft on Configuration of Access Control >> Policy in RELOAD >> Feb 2013 Submit P2PSIP Peer Protocol document to the IESG (PS) >> Feb 2013 WGLC of P2PSIP Self-Tuning document >> Feb 2013 WGLC of P2PSIP Service Discovery document >> Jul 2013 WGLC of P2PSIP SIP Usage document >> Jul 2013 WGLC of P2PSIP Concepts document >> Jul 2013 Submit P2PSIP Diagnostics document to the IESG (PS) >> Jul 2013 Submit P2PSIP Self-Tuning document to the IESG (PS) >> Jul 2013 Submit P2PSIP Service Discovery document to the IESG >> (PS) >> Oct 2013 Submit P2PSIP Concepts document to the IESG >> (Informational) >> Oct 2013 Submit P2PSIP SIP Usage document to the IESG (PS) >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From waehlisch@ieee.org Fri Feb 8 08:38:57 2013 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 964D121F8A90 for ; Fri, 8 Feb 2013 08:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oF7uVLCyVGTg for ; Fri, 8 Feb 2013 08:38:56 -0800 (PST) Received: from mail1.rz.htw-berlin.de (mail1.rz.htw-berlin.de [141.45.10.101]) by ietfa.amsl.com (Postfix) with ESMTP id 80A2D21F86AE for ; Fri, 8 Feb 2013 08:38:56 -0800 (PST) Envelope-to: p2psip@ietf.org Received: from [91.112.103.38] (helo=mw-PC) by mail1.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1U3qyU-0009S6-8U for p2psip@ietf.org; Fri, 08 Feb 2013 17:38:55 +0100 Date: Fri, 8 Feb 2013 17:38:46 +0100 From: Matthias Waehlisch To: p2psip@ietf.org In-Reply-To: <51152842.2080905@informatik.haw-hamburg.de> Message-ID: References: <1360232562.4155.31.camel@acorde.it.uc3m.es> <51152842.2080905@informatik.haw-hamburg.de> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="116858226-25175-1360341526=:9232" X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: p2psip@ietf.org Subject: Re: [P2PSIP] Milestones update and WG draft adoption 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: Fri, 08 Feb 2013 16:38:57 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --116858226-25175-1360341526=:9232 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE I support the adoption of this document. Cheers matthias --=20 Matthias Waehlisch =2E Freie Universitaet Berlin, Inst. fuer Informatik, AG CST =2E Takustr. 9, D-14195 Berlin, Germany =2E. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net On Fri, 8 Feb 2013, Thomas C. Schmidt wrote: > +1 >=20 > Thomas >=20 > On 08.02.2013 02:19, Songhaibin (A) wrote: > > I support both the draft adoption and the milestone change. > >=20 > > -Haibin > >=20 > > > -----Original Message----- > > > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Beh= alf > > > Of > > > Carlos Jes=FAs Bernardos Cano > > > Sent: Thursday, February 07, 2013 6:23 PM > > > To: p2psip@ietf.org > > > Cc: p2psip-chairs@tools.ietf.org > > > Subject: [P2PSIP] Milestones update and WG draft adoption call > > >=20 > > > Dear all, > > >=20 > > > During the last meeting there was consensus on adding a new milestone= in > > > our charter for a document on "Configuration of Access Control > > > Policy in RELOAD" and adopting draft-petithuguenin-p2psip-access-cont= rol > > > as WG document. > > >=20 > > > Hereby we are asking about comments about adding this new milestone t= o > > > our charter and also starting a consensus call on adopting > > > draft-petithuguenin-p2psip-access-control-05 as WG document. More > > > details about this document below: > > >=20 > > > Title : Configuration of Access Control Policy in > > > REsource LOcation And Discovery (RELOAD) Base Protocol > > > Author(s) : Marc Petit-Huguenin > > > Filename : > > > draft-petithuguenin-p2psip-access-control-05.txt > > > Pages : 12 > > > Date : 2012-10-22 > > >=20 > > > Abstract: > > > This document describes an extension to the REsource LOcation And > > > Discovery (RELOAD) base protocol to distribute the code of new Ac= cess > > > Control Policies without having to upgrade the RELOAD implementat= ions > > > in an overlay. > > >=20 > > > Last, but not least, since our milestones were a bit outdated, we wan= t > > > to also update them. Please find below an updated proposal. > > >=20 > > > Please, send your comments about the milestones update and the WG > > > adoption by Friday 15th. > > >=20 > > > Thanks, > > >=20 > > > Carlos & Brian > > >=20 > > > Proposed (updated charter) > > >=20 > > > Goals and Milestones > > >=20 > > > Done WGLC of P2PSIP Peer Protocol document > > > Done WGLC of P2PSIP Diagnostics document > > > Done WGLC of P2PSIP Direct Response Draft > > > Done WGLC of P2PSIP Relay Response Draft > > > Feb 2013 Submit -00 draft on Configuration of Access Control > > > Policy in RELOAD > > > Feb 2013 Submit P2PSIP Peer Protocol document to the IESG (PS) > > > Feb 2013 WGLC of P2PSIP Self-Tuning document > > > Feb 2013 WGLC of P2PSIP Service Discovery document > > > Jul 2013 WGLC of P2PSIP SIP Usage document > > > Jul 2013 WGLC of P2PSIP Concepts document > > > Jul 2013 Submit P2PSIP Diagnostics document to the IESG (PS) > > > Jul 2013 Submit P2PSIP Self-Tuning document to the IESG (PS) > > > Jul 2013 Submit P2PSIP Service Discovery document to the IESG > > > (PS) > > > Oct 2013 Submit P2PSIP Concepts document to the IESG > > > (Informational) > > > Oct 2013 Submit P2PSIP SIP Usage document to the IESG (PS) > > >=20 > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip > >=20 >=20 >=20 --116858226-25175-1360341526=:9232-- From dean.willis@softarmor.com Mon Feb 11 10:31:31 2013 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 97A4E21F8972 for ; Mon, 11 Feb 2013 10:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vS0U7hyU4RoX for ; Mon, 11 Feb 2013 10:31:29 -0800 (PST) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id CD96B21F8A96 for ; Mon, 11 Feb 2013 10:31:29 -0800 (PST) Received: by mail-oa0-f53.google.com with SMTP id m1so6615768oag.12 for ; Mon, 11 Feb 2013 10:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=hFtSMK++Og3RVn9mpODs9Rsc64pvTT+Ua39peKOiKoE=; b=bmY5W4CbP7vIvWWhehjSn/I67LbDA+3sUfef+mHO4bFRCNxZiKGb+FvnuJE+kz8tpp SK3BvHVvYx3EoE3UIEoHwpFkHRSAvlJDQhxWFS6LfuJg76+SukndAXY3c7Mx93N9HsFz g4AfdNDeIryN2Xjn3uM5nhnqLgyswlcntEZl0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=hFtSMK++Og3RVn9mpODs9Rsc64pvTT+Ua39peKOiKoE=; b=hfTM0ascnoAW6o6svnvAubkECwDtaDg5j4xWPJ0uiYVpISFZgghzeQtWtvOlX2dYVW kbA8BJz16wmOAi3R3+X9VNhD7KXGcvDxu4dAwdpinLxneasi1zAkAbPKUnblgZ9d/+M5 XkOC3cs0Cyh6ABPEK3KxYKfWJpSX+S6dMcE/FEEf5w0lpbrautj0ZedXlxDWtwpw93PA M3g8h07D2YrRjHSZOVzh22fFP+3/dK5AGZYStiY9TDyRR1x2sfew3t0egQAMDWO6HQri YTBhnGuQN3iVhvAT0UKzKhWhf9IKmUi/TaQX94jeSTZmOZ4SlKfmlCxyaNJTtBozX1qA qAmQ== X-Received: by 10.60.21.101 with SMTP id u5mr11654426oee.71.1360607489312; Mon, 11 Feb 2013 10:31:29 -0800 (PST) Received: from [192.168.2.114] (cpe-72-181-157-19.tx.res.rr.com. [72.181.157.19]) by mx.google.com with ESMTPS id v2sm49848071obl.10.2013.02.11.10.31.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 10:31:28 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dean Willis In-Reply-To: <1360232562.4155.31.camel@acorde.it.uc3m.es> Date: Mon, 11 Feb 2013 12:31:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <14E63994-EE48-4FA0-89E0-9D116422A821@softarmor.com> References: <1360232562.4155.31.camel@acorde.it.uc3m.es> To: cjbc@it.uc3m.es X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlgrWq2HA8YMKf2aiO5p+2UZyZrgLi1mIMAi8552scrG7M8iXdbvAKgF7n1hVWUBsH1Fy7G Cc: p2psip-chairs@tools.ietf.org, p2psip@ietf.org Subject: Re: [P2PSIP] Milestones update and WG draft adoption 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, 11 Feb 2013 18:31:31 -0000 Yes, and yes. On Feb 7, 2013, at 4:22 AM, Carlos Jes=FAs Bernardos Cano = wrote: > Dear all, >=20 > During the last meeting there was consensus on adding a new milestone = in > our charter for a document on "Configuration of Access Control > Policy in RELOAD" and adopting = draft-petithuguenin-p2psip-access-control > as WG document. >=20 > Hereby we are asking about comments about adding this new milestone to > our charter and also starting a consensus call on adopting > draft-petithuguenin-p2psip-access-control-05 as WG document. More > details about this document below: >=20 > Title : Configuration of Access Control Policy in > REsource LOcation And Discovery (RELOAD) Base Protocol > Author(s) : Marc Petit-Huguenin > Filename : > draft-petithuguenin-p2psip-access-control-05.txt > Pages : 12 > Date : 2012-10-22 >=20 > Abstract: > This document describes an extension to the REsource LOcation And > Discovery (RELOAD) base protocol to distribute the code of new = Access > Control Policies without having to upgrade the RELOAD = implementations > in an overlay. >=20 > Last, but not least, since our milestones were a bit outdated, we want > to also update them. Please find below an updated proposal. >=20 > Please, send your comments about the milestones update and the WG > adoption by Friday 15th. >=20 > Thanks, >=20 > Carlos & Brian >=20 > Proposed (updated charter) >=20 > Goals and Milestones >=20 > Done WGLC of P2PSIP Peer Protocol document > Done WGLC of P2PSIP Diagnostics document > Done WGLC of P2PSIP Direct Response Draft > Done WGLC of P2PSIP Relay Response Draft > Feb 2013 Submit -00 draft on Configuration of Access Control > Policy in RELOAD > Feb 2013 Submit P2PSIP Peer Protocol document to the IESG (PS) > Feb 2013 WGLC of P2PSIP Self-Tuning document > Feb 2013 WGLC of P2PSIP Service Discovery document > Jul 2013 WGLC of P2PSIP SIP Usage document > Jul 2013 WGLC of P2PSIP Concepts document > Jul 2013 Submit P2PSIP Diagnostics document to the IESG (PS) > Jul 2013 Submit P2PSIP Self-Tuning document to the IESG (PS) > Jul 2013 Submit P2PSIP Service Discovery document to the IESG > (PS) > Oct 2013 Submit P2PSIP Concepts document to the IESG > (Informational) > Oct 2013 Submit P2PSIP SIP Usage document to the IESG (PS) >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From petithug@acm.org Thu Feb 14 10:59:45 2013 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 57E2921F855F for ; Thu, 14 Feb 2013 10:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04x6KegJiXNQ for ; Thu, 14 Feb 2013 10:59:44 -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 26ADE21F855D for ; Thu, 14 Feb 2013 10:59:44 -0800 (PST) Received: from [IPv6:2601:9:4b80:32:852b:b885:3f6f:c264] (unknown [IPv6:2601:9:4b80:32:852b:b885:3f6f:c264]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 3CCC220492; Thu, 14 Feb 2013 18:59:42 +0000 (UTC) Message-ID: <511D341E.6060905@acm.org> Date: Thu, 14 Feb 2013 10:59:42 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <1359673911.4472.18.camel@acorde.it.uc3m.es> In-Reply-To: <1359673911.4472.18.camel@acorde.it.uc3m.es> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: p2psip-chairs@tools.ietf.org, p2psip@ietf.org Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06 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, 14 Feb 2013 18:59:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I did a review of this draft, and I have some concerns. First of all some parts of the I-D are verbatim copy of the text in the original paper. Is that OK? Probably because some of the text comes from a research paper, it was very difficult to understand fro me, and I am not sure that I yet understood everything - I still have to write an implementation of this, and unfortunately to not have enough time to do so before the end of the WGLC. On the other hand, I know that RELOAD.NET has an implementation, so I guess it is implementable. But I was not able to make sense of something in the example in section 7: Why is the 4th peer added to level 0? Bullet 4 in Section 4.3 says "Node N MUST continue [repeating steps 2 and 3] until it reaches either the root or a level a which n.id is not the lowest or highest Node-ID in the interval I(level, n.id)". In this case 4 is not the lowest or highest Node-ID in the interval (lowest is 2, highest is 7), so why is it added to this node? BTW a similar example for the service lookup would be useful. More comments: - - Section 3, 3 paragraph: "contains a list of Node-IDs" Technically each node is a Dictionary whose keys are Node-IDs and values contain a list of Destinations. - - Section 4.1 s/detination_list/destination_list/ - - Section 4.1 namespace is an opaque value but the charset and conversion between character string and byte string for the namespace is not defined. - - Section 8 The document says that the redir namespace is added to the element, meaning that all nodes MUST understand ReDIR, but isn't that against one of the goal of ReDIR, which is that by using standard Store/Fetch, only a node wishing to store or fetch has to implement ReDIR? - - Section 10.3 I think that we need a bit more explanation on what the turn-server and voice-mail service providers are. On 01/31/2013 03:11 PM, Carlos Jesús Bernardos Cano wrote: > Hi, > > Hereby we are issuing a WGLC for draft-ietf-p2psip-service-discovery-06. > > The WGLC will be open till the 15th of February. We kindly ask the WG to > review the document and provide comments. > > If you have no comments and think the document is ready to be submitted to > IESG, please do send a note stating that to the WG ML. > > Additional information about the document is below: > > Title : Service Discovery Usage for REsource LOcation And > Discovery (RELOAD) Author(s) : Jouni Maenpaa Gonzalo Camarillo > Filename : draft-ietf-p2psip-service-discovery-06.txt Pages : 15 > Date : 2012-10-01 > > Abstract: 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. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-p2psip-service-discovery > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-p2psip-service-discovery-06 > > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRHTQcAAoJECnERZXWan7EmukP/A1P3JutcxuDooxYPFjty3ua lhhbiJTd7PLEs9jsaG9hKHjuDi2qu0BNp9Ss+ki+ybtXBNKaJwkrqNqwB3R+dXpx Q7zamHvCUJekNmybG2kpc5IUP2MxhDzYp3paocOdF/vdWYE+re3u9WqBN1JNuCwk E6GmfEIgw28p5wKldHPCGQrRYx6QnszsQc7F3+siFrsSEzRww7ATpUXjMCVxUfWU KTmBh0H+9+PhoXeH6leue2v0Y5Xb1lD8HU6WmrssWYrd9rXgc3s26kzsUrATJCKc bj7M6uiKIzUDFwaj13U6bPbldVeJWd+DhWCR2k4Y3rJIfj5bdp55ApDZnF/14v91 i/w0hnqnuiT/KEDuW+E7jsKwXq/ILKIDZqonyFlF7KuGUT3HGi9WFkc7AnkaOi5U qgsuFEYjxkUqAbTAO7nwa9YtGX0qKHhH5SkzWpITTabu48c5FKqG0vAVpGce8z3K AyqtwNXAz9nIL6ZwJNg9L8tLhLBQS1lePeSiN7pog4jsKD51VaT7Y1iMysA2OqRs Nw70wF7TYh4EikCHsECPQBEI/a+cJEQSro0I4kHGGttVcEdrDqM4xdfaFYN+Ag1b vHEf3Zzv/x820fjbfN1eoySj/qFU7Mcuw8Rik//J63HKZbmGdbaYsdrHasgaDIqk TgSsgGCf6d5FX9TFFNvd =u3Pi -----END PGP SIGNATURE----- From cjbc@it.uc3m.es Thu Feb 14 13:28:23 2013 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 44CE821F8534 for ; Thu, 14 Feb 2013 13:28:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4qTca0oDNQM for ; Thu, 14 Feb 2013 13:28:22 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 69FFB21F8464 for ; Thu, 14 Feb 2013 13:28:21 -0800 (PST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 27C98CC60F6; Thu, 14 Feb 2013 22:28:20 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [192.168.1.3] (82.158.126.26.dyn.user.ono.com [82.158.126.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 0BFAACC60F3; Thu, 14 Feb 2013 22:28:20 +0100 (CET) Message-ID: <1360877299.4271.40.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: p2psip@ietf.org Date: Thu, 14 Feb 2013 22:28:19 +0100 Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19638.002 X-TM-AS-Result: No--7.130-7.0-31-1 X-imss-scan-details: No--7.130-7.0-31-1 Cc: p2psip-chairs@tools.ietf.org Subject: [P2PSIP] Soliciting agenda items for IETF 86 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es 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, 14 Feb 2013 21:28:24 -0000 Hello, The P2PSIP WG is scheduled to meet at IETF 86 on MONDAY, March 11, 2013 from 1540-1710 (Afternoon Session II) at the Caribbean 6 room. If you need an agenda slot at the WG meeting, please send a request to the chairs (p2psip-chairs@tools.ietf.org). Please indicate: 1. Name of the I-D. 2. Relevance to the P2PSIP WG charter. 3. Amount of time needed. 4. Name of the presenter. Thanks, Chairs From cjbc@it.uc3m.es Thu Feb 14 13:30:24 2013 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 EC08C21F8651 for ; Thu, 14 Feb 2013 13:30:23 -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=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnZ1hExVzQtc for ; Thu, 14 Feb 2013 13:30:23 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id B39E421F85C3 for ; Thu, 14 Feb 2013 13:30:22 -0800 (PST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B1801CADCB7; Thu, 14 Feb 2013 22:30:21 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [192.168.1.3] (82.158.126.26.dyn.user.ono.com [82.158.126.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 92214CACD2F; Thu, 14 Feb 2013 22:30:21 +0100 (CET) Message-ID: <1360877421.4271.42.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: P2PSIP WG Date: Thu, 14 Feb 2013 22:30:21 +0100 In-Reply-To: References: Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19638.002 X-TM-AS-Result: No--31.328-7.0-31-1 X-imss-scan-details: No--31.328-7.0-31-1 Cc: "Rosen, Brian" Subject: Re: [P2PSIP] FW: I-D Action: draft-ietf-p2psip-diagnostics-10.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es 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, 14 Feb 2013 21:30:24 -0000 Hi folks, Please review the doc, as several changes have been made. If you believe it's ready to go, please affirmatively say so. If you believe we need to do more review, please say that. If you find problems, of course we want to hear them. Thanks, Brian & Carlos On Mon, 2013-02-04 at 09:00 +0000, Songhaibin (A) wrote: > Hi guys, > > We have made quite a few changes to the p2psip diagnostics draft, now we believe it has solved the comments from the WGLC with solutions from last IETF meeting consensus. Maybe a second WGLC is needed for more sufficient review. > > BR, > -Haibin > > > -----Original Message----- > > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: Monday, February 04, 2013 4:51 PM > > To: i-d-announce@ietf.org > > Cc: p2psip@ietf.org > > Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-10.txt > > > > > > 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 : P2P Overlay Diagnostics > > Author(s) : Haibin Song > > Jiang Xingfeng > > Roni Even > > David A. Bryan > > Filename : draft-ietf-p2psip-diagnostics-10.txt > > Pages : 31 > > Date : 2013-02-04 > > > > Abstract: > > This document describes mechanisms for P2P overlay diagnostics. It > > defines extensions to the RELOAD P2PSIP base protocol RELOAD > > [I-D.ietf-p2psip-base] to collect diagnostic information, and details > > the protocol specifications for these extensions. Useful diagnostic > > information for connection and node status monitoring is also > > defined. The document also describes the usage scenarios and > > provides examples of how these methods are used to perform > > diagnostics in a P2PSIP overlay networks. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-10 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-diagnostics-10 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip From petithug@acm.org Thu Feb 14 14:48:20 2013 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 9B3EA21F86E7 for ; Thu, 14 Feb 2013 14:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVFwDHCbupuH for ; Thu, 14 Feb 2013 14:48:19 -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 B229821F866F for ; Thu, 14 Feb 2013 14:48:18 -0800 (PST) Received: from [IPv6:2601:9:4b80:32:852b:b885:3f6f:c264] (unknown [IPv6:2601:9:4b80:32:852b:b885:3f6f:c264]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 8EAE720492; Thu, 14 Feb 2013 22:48:16 +0000 (UTC) Message-ID: <511D69B0.7070000@acm.org> Date: Thu, 14 Feb 2013 14:48:16 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <1360877299.4271.40.camel@acorde.it.uc3m.es> In-Reply-To: <1360877299.4271.40.camel@acorde.it.uc3m.es> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: p2psip-chairs@tools.ietf.org, p2psip@ietf.org Subject: Re: [P2PSIP] Soliciting agenda items for IETF 86 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, 14 Feb 2013 22:48:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I spent most of my available time since Atlanta working on -base, so I am extremely late in updating my own drafts. Here's, by priority order the drafts I would like to present: 1. draft-ietf-p2psip-reload-access-control; in (new) charter; 10 minutes. This will be mostly two slides to remind people what this is about, one slide to explain the differences (new example) and a call for reviews. 2. draft-petithuguenin-p2psip-reload-one-to-many; document split from -base; 15 minutes. When working on version -01, I found that I need some direction from the WG on how to manage the security issues related to Anycast. So I would like to present these and see what the group prefers. I'll send an email to the list to start the discussion before the IETF meeting. 3. draft-petithuguenin-p2psip-reload-interconnect; not in charter; 10 minutes. A new draft written in collaboration with Joscha Schneider that proposes an architecture to interconnect RELOAD overlays. Joscha will request a time slot to present in detail in Berlin, but we would like a little bit of time to talk about few decisions in the design of RELOAD 1.0 that prevent to use it as specified for this document. If time permits I'd like to give an update on draft-petithuguenin-p2psip-reload-anonymous, but that not a priority. draft-petithuguenin-p2psip-reload-eku will have to wait for Berlin as I should have asked a review from PKIX, to see what they think of it, but forgot to do so. Oh, and one slide, either in the chairs' slides or mine's, to announce the RELOAD interop in Berlin would be great. Thanks. On 02/14/2013 01:28 PM, Carlos Jesús Bernardos Cano wrote: > Hello, > > The P2PSIP WG is scheduled to meet at IETF 86 on MONDAY, March 11, 2013 > from 1540-1710 (Afternoon Session II) at the Caribbean 6 room. > > If you need an agenda slot at the WG meeting, please send a request to the > chairs (p2psip-chairs@tools.ietf.org). > > Please indicate: > > 1. Name of the I-D. 2. Relevance to the P2PSIP WG charter. 3. Amount of > time needed. 4. Name of the presenter. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRHWmvAAoJECnERZXWan7E9OIP/07l6I2KrvpSRX0k/Xh+z+wW uBIDWXSSGBDXLyhlno1AZEODyhpM+R66rr08Pp2XC4fPliRnE2Rg7KmKB0mhqWie e+dqL23G0D/bZo4syXQ3HJKNOTqUPR10uLjJhATssbiwAmJ0mi3gkqSI9pHbycuJ nO0kROrvn+ivrwvIld+mkHMNzc0LyLwKFaNw+2mQ8TSikwpKqWsD1dO4vXI5tMc2 ad7l+K8AD4TeLWyfvIo81w5rLdAClCGwq8fxcCrdreyLFG/w1akBx9Am/AMp+6ZJ C+aRGsIYyGKNz60PvWzOzVEGsNLMJJ35zw/FWdhbBHMLR7N1z6GU+MFt6QGhEKsO Rn+OTRslQAWYkQSkwVm42b1I/kMiLAm/ag9StpRyFlE4+A4iTz/h1duiE3NJ1PTo XvucYMo3EuxHU4nQlNDbp4BRRu6BgiZFSQw4ZM2D2F6f8JHEQ7oUSHM7dax5hhdk yWyLlBYP8VU7A5bbKVDd7SyzgTWPkiYgvLNndZ05tJXPf46ew8/3pW8FqiYtKtU6 WdKswZq0gm7VhjnmgsufT8hkI1+z1hDX3/0R0j14FH5SKxv7RStE0d21qrf+G3dS 3bBw0U+lNAtAaimrTGTSwbf0cseldh5s2INPH7SmrBBsw/osIW7cTZkgDaZj+7jG 52Y749R0cvKiLQde9ALx =AHTz -----END PGP SIGNATURE----- From petithug@acm.org Thu Feb 14 18:06:05 2013 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 F0D0E21F86A8 for ; Thu, 14 Feb 2013 18:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7zubJ0xbOXx for ; Thu, 14 Feb 2013 18:06:04 -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 BE54921F86A2 for ; Thu, 14 Feb 2013 18:06:03 -0800 (PST) Received: from [IPv6:2601:9:4b80:32:852b:b885:3f6f:c264] (unknown [IPv6:2601:9:4b80:32:852b:b885:3f6f:c264]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 5A00B20492 for ; Fri, 15 Feb 2013 02:06:02 +0000 (UTC) Message-ID: <511D980A.2080504@acm.org> Date: Thu, 14 Feb 2013 18:06:02 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: P2PSIP WG References: <1360877421.4271.42.camel@acorde.it.uc3m.es> In-Reply-To: <1360877421.4271.42.camel@acorde.it.uc3m.es> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [P2PSIP] FW: I-D Action: draft-ietf-p2psip-diagnostics-10.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, 15 Feb 2013 02:06:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Section 8 answers my concern about security, although the section will need a formal schema. AFAIC this draft is ready to be submitted to the IESG. I also reviewed the other changes and noticed that most of the nits I suggested were not applied. In addition I noticed that some references need an update: I-D.zheng-p2psip-diagnose I-D.ietf-behave-rfc3489bis I-D.ietf-mmusic-ice and perhaps more. Globally the whole document still feel like it needs some editing. On 02/14/2013 01:30 PM, Carlos Jesús Bernardos Cano wrote: > Hi folks, > > Please review the doc, as several changes have been made. If you believe > it's ready to go, please affirmatively say so. If you believe we need to do > more review, please say that. > > If you find problems, of course we want to hear them. > > Thanks, > > Brian & Carlos > > On Mon, 2013-02-04 at 09:00 +0000, Songhaibin (A) wrote: >> Hi guys, >> >> We have made quite a few changes to the p2psip diagnostics draft, now we >> believe it has solved the comments from the WGLC with solutions from last >> IETF meeting consensus. Maybe a second WGLC is needed for more sufficient >> review. >> >> BR, -Haibin >> >>> -----Original Message----- From: p2psip-bounces@ietf.org >>> [mailto:p2psip-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >>> Sent: Monday, February 04, 2013 4:51 PM To: i-d-announce@ietf.org Cc: >>> p2psip@ietf.org Subject: [P2PSIP] I-D Action: >>> draft-ietf-p2psip-diagnostics-10.txt >>> >>> >>> 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 : P2P Overlay Diagnostics Author(s) : Haibin >>> Song Jiang Xingfeng Roni Even David A. Bryan Filename : >>> draft-ietf-p2psip-diagnostics-10.txt Pages : 31 Date >>> : 2013-02-04 >>> >>> Abstract: This document describes mechanisms for P2P overlay >>> diagnostics. It defines extensions to the RELOAD P2PSIP base protocol >>> RELOAD [I-D.ietf-p2psip-base] to collect diagnostic information, and >>> details the protocol specifications for these extensions. Useful >>> diagnostic information for connection and node status monitoring is >>> also defined. The document also describes the usage scenarios and >>> provides examples of how these methods are used to perform diagnostics >>> in a P2PSIP overlay networks. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-10 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-diagnostics-10 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ P2PSIP mailing list >>> P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ P2PSIP mailing list > P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRHZgIAAoJECnERZXWan7Eg3UP/3TbamxxlmzLI9ZN9MQijJpL 7LqsDSTFpK20hlZTj5zXVgI/wBOJVLC3fRmWDXB94NalUiENLQUFxBenXvLvBK+k 592fp12gR3oZaTblBFcLz/+Dh4v3dj4lXRbAXODBDYN0FbErmDiSGexScKBWpgCc C3e1WVsk6YCsEWAyAvWn+oBfvV8WQVEyBZUNnLgWzF+gv0FZ6dmVQGoalpWVBrZE fjWnL+RTFaXROimHFKSt6XpRVfW5wNDLiDJdlCSWehWz21FOrFthMFejaULsG3Y6 yNqUkayjhJO39hJDZjP0KGKaQrX4dD8Q2Jezrld0QyudYgcZQmlMjmlb+aYENoDP Lu5zeXAPXik62/D5dw64eh9htMfd9lOI9bZ8p7FJxPSw2H79hVGCJ9GChGmVE5p1 kC6tK50K614foVRWpgg9QeuVRhQW4iDJJz+4ItOv7KjpdkR5XbNZyP9TZ28O/J3B cl00SLUxbl8t8lCj/VpKJ8IEuQmr24HEWZPtOEcYTxIqM6OdBVRRZUgrbcBujKfY vEQmOQ5x1CRTsz+xUD04+WLItm5z/MF+iMJdBi1HwKf3eJIoiIQauE+W0lGsXrF5 hrOfgrkSKbWeAxfJB4JYQqOpMH219eaz4K0+1/pb6eUpMRdAj13gWqXshb7ED/1Q /S+Tg8mEG5dtu1veJ6P6 =iRZw -----END PGP SIGNATURE----- From j.schneider@hs-mannheim.de Fri Feb 15 02:29:21 2013 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 BFD5721F8610 for ; Fri, 15 Feb 2013 02:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEH10xT9ordE for ; Fri, 15 Feb 2013 02:29:20 -0800 (PST) Received: from hs-mannheim.de (mailnode.rz.fh-mannheim.de [141.19.1.96]) by ietfa.amsl.com (Postfix) with ESMTP id 627EB21F8563 for ; Fri, 15 Feb 2013 02:29:19 -0800 (PST) Received: from [141.19.96.81] (account schneiderj@hs-mannheim.de [141.19.96.81] verified) by hs-mannheim.de (CommuniGate Pro SMTP 5.3.15) with ESMTPSA id 18937317; Fri, 15 Feb 2013 11:27:19 +0100 Message-ID: <511E0E0B.6070103@hs-mannheim.de> Date: Fri, 15 Feb 2013 11:29:31 +0100 From: Joscha Schneider User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <1359673911.4472.18.camel@acorde.it.uc3m.es> <511D341E.6060905@acm.org> In-Reply-To: <511D341E.6060905@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: p2psip-chairs@tools.ietf.org, p2psip@ietf.org Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06 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, 15 Feb 2013 10:29:21 -0000 I can confirm that the draft might need some improvements to make the implementation easier. I did a basic implementation but I'm not quite sure that I handled everything correct. Especially the definition of the successor seams a bit unclear for me. A simple example: Only a single service provider with Node-ID 2 provides a service. Node with ID 7 performs a lookup... How should it be handled? I implemented it as follows: in case a lookup reveals only a single service provider it must be the direct successor. Further notice, due to the periodically triggered re-registration the consistency of the ReDiR tree can not be always ensured. Theoretically this can lead to failed lookup processes. This derives from the fact that each new service provider registration might affect the re-registration of the former service providers which again might affect the re-registrations of other service providers. more inline... Regards Joscha Am 14.02.2013 19:59, schrieb Marc Petit-Huguenin: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I did a review of this draft, and I have some concerns. > > First of all some parts of the I-D are verbatim copy of the text in the > original paper. Is that OK? > > Probably because some of the text comes from a research paper, it was very > difficult to understand fro me, and I am not sure that I yet understood > everything - I still have to write an implementation of this, and > unfortunately to not have enough time to do so before the end of the WGLC. On > the other hand, I know that RELOAD.NET has an implementation, so I guess it is > implementable. > > But I was not able to make sense of something in the example in section 7: > Why is the 4th peer added to level 0? Bullet 4 in Section 4.3 says "Node N > MUST continue [repeating steps 2 and 3] until it reaches either the root or a > level a which n.id is not the lowest or highest Node-ID in the interval > I(level, n.id)". In this case 4 is not the lowest or highest Node-ID in the > interval (lowest is 2, highest is 7), so why is it added to this node? I think the example is simply following the rules. At level 1 peer 4 is the lowest. So go up and fetch and store. But if i reveal correct that fact caused a few headaches for me too. Why does the store does not depend on the information that was fetched before? > BTW a similar example for the service lookup would be useful. > > More comments: > > - - Section 3, 3 paragraph: "contains a list of Node-IDs" > > Technically each node is a Dictionary whose keys are Node-IDs and values > contain a list of Destinations. > > - - Section 4.1 > > s/detination_list/destination_list/ > > - - Section 4.1 > > namespace is an opaque value but the charset and conversion between character > string and byte string for the namespace is not defined. confirm > > - - Section 8 > > The document says that the redir namespace is added to the > element, meaning that all nodes MUST understand ReDIR, > but isn't that against one of the goal of ReDIR, which is that by using > standard Store/Fetch, only a node wishing to store or fetch has to implement > ReDIR? I think at least the RedirServiceProvider Data Structure must be supported. And also the Access Control Rules. But the algorithm might not be mandatory needed. > - - Section 10.3 > > I think that we need a bit more explanation on what the turn-server and > voice-mail service providers are. > > > On 01/31/2013 03:11 PM, Carlos Jesús Bernardos Cano wrote: >> Hi, >> >> Hereby we are issuing a WGLC for draft-ietf-p2psip-service-discovery-06. >> >> The WGLC will be open till the 15th of February. We kindly ask the WG to >> review the document and provide comments. >> >> If you have no comments and think the document is ready to be submitted to >> IESG, please do send a note stating that to the WG ML. >> >> Additional information about the document is below: >> >> Title : Service Discovery Usage for REsource LOcation And >> Discovery (RELOAD) Author(s) : Jouni Maenpaa Gonzalo Camarillo >> Filename : draft-ietf-p2psip-service-discovery-06.txt Pages : 15 >> Date : 2012-10-01 >> >> Abstract: 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. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-p2psip-service-discovery >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-p2psip-service-discovery-06 >> >> > > - -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBCAAGBQJRHTQcAAoJECnERZXWan7EmukP/A1P3JutcxuDooxYPFjty3ua > lhhbiJTd7PLEs9jsaG9hKHjuDi2qu0BNp9Ss+ki+ybtXBNKaJwkrqNqwB3R+dXpx > Q7zamHvCUJekNmybG2kpc5IUP2MxhDzYp3paocOdF/vdWYE+re3u9WqBN1JNuCwk > E6GmfEIgw28p5wKldHPCGQrRYx6QnszsQc7F3+siFrsSEzRww7ATpUXjMCVxUfWU > KTmBh0H+9+PhoXeH6leue2v0Y5Xb1lD8HU6WmrssWYrd9rXgc3s26kzsUrATJCKc > bj7M6uiKIzUDFwaj13U6bPbldVeJWd+DhWCR2k4Y3rJIfj5bdp55ApDZnF/14v91 > i/w0hnqnuiT/KEDuW+E7jsKwXq/ILKIDZqonyFlF7KuGUT3HGi9WFkc7AnkaOi5U > qgsuFEYjxkUqAbTAO7nwa9YtGX0qKHhH5SkzWpITTabu48c5FKqG0vAVpGce8z3K > AyqtwNXAz9nIL6ZwJNg9L8tLhLBQS1lePeSiN7pog4jsKD51VaT7Y1iMysA2OqRs > Nw70wF7TYh4EikCHsECPQBEI/a+cJEQSro0I4kHGGttVcEdrDqM4xdfaFYN+Ag1b > vHEf3Zzv/x820fjbfN1eoySj/qFU7Mcuw8Rik//J63HKZbmGdbaYsdrHasgaDIqk > TgSsgGCf6d5FX9TFFNvd > =u3Pi > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From petithug@acm.org Fri Feb 15 08:51:08 2013 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 9B8BE21F87CA for ; Fri, 15 Feb 2013 08:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYxK5rJOOk9a for ; Fri, 15 Feb 2013 08:51:07 -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 8F58821F851C for ; Fri, 15 Feb 2013 08:51:07 -0800 (PST) Received: from [IPv6:2601:9:4b80:32:41f3:2c5b:5b9c:ed3e] (unknown [IPv6:2601:9:4b80:32:41f3:2c5b:5b9c:ed3e]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id D75C02045D; Fri, 15 Feb 2013 16:51:05 +0000 (UTC) Message-ID: <511E6779.80706@acm.org> Date: Fri, 15 Feb 2013 08:51:05 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Joscha Schneider References: <1359673911.4472.18.camel@acorde.it.uc3m.es> <511D341E.6060905@acm.org> <511E0E0B.6070103@hs-mannheim.de> In-Reply-To: <511E0E0B.6070103@hs-mannheim.de> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: p2psip-chairs@tools.ietf.org, p2psip@ietf.org Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06 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, 15 Feb 2013 16:51:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 One comment below. On 02/15/2013 02:29 AM, Joscha Schneider wrote: > I can confirm that the draft might need some improvements to make the > implementation easier. I did a basic implementation but I'm not quite sure > that I handled everything correct. > > Especially the definition of the successor seams a bit unclear for me. A > simple example: Only a single service provider with Node-ID 2 provides a > service. Node with ID 7 performs a lookup... How should it be handled? I > implemented it as follows: in case a lookup reveals only a single service > provider it must be the direct successor. > > Further notice, due to the periodically triggered re-registration the > consistency of the ReDiR tree can not be always ensured. Theoretically this > can lead to failed lookup processes. This derives from the fact that each > new service provider registration might affect the re-registration of the > former service providers which again might affect the re-registrations of > other service providers. > > more inline... > > Regards Joscha > > Am 14.02.2013 19:59, schrieb Marc Petit-Huguenin: I did a review of this > draft, and I have some concerns. > [...] > > - Section 8 > > The document says that the redir namespace is added to the > element, meaning that all nodes MUST understand > ReDIR, but isn't that against one of the goal of ReDIR, which is that by > using standard Store/Fetch, only a node wishing to store or fetch has to > implement ReDIR? >> I think at least the RedirServiceProvider Data Structure must be >> supported. And also the Access Control Rules. But the algorithm might not >> be mandatory needed. The RedirServiceProvider Data Structure does not need to be understood by the peer storing it, but you are right about the Access Control rule. My own draft about storing the Access Control rule solves this problem but, even if it is accepted as WG item, we do not want to add a normative reference to it. So I withdraw what I said - redir needs to be a a mandatory extension at least until new access control policies no longer have to be hardcoded. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRHmd3AAoJECnERZXWan7E/9oP/3Xg287LlkSKl6F2BaHXHsdc 0gS1S5BOCmJhT+q1YyCDnH0T3MPxkFJYRkEnxKNiaeQl+IUFD5AjBIDCtk/yvwb3 WNc7RueobmpypUVe/b5L/zGGTpK9jBUiguBBTw/YAiYvsp1VinBVLu7xnQGnHnA9 bWgErqYT8/w6d7r/ZgYLHl0md5mCGUihIpS0jOXxBwbUDHbK51DlE2nZmezZ5q3b zLl7duUCqNn14RKkYMA0IReRLHtgNytJDHTbXT8hwESN6qNnKfXotm3sPT0I1BMN XDgPbFfKFBVOj8o3pPVs/9A+vxLdEJ2pXJoqhIFAir4GYF9BEXhCMgqUSdFdZoXC PEh9/YO1jvx4eSP011whfOSBv86F1nZf+9yWseBJS4IVuYhYQPXLk8ip10N0aK5K VUbDCWwD5Jn93N7lLNuS9wrQJrj3Vhw/4kLNBQ3mhl4Xr+mgXkKmme6fbzQjlnTG /zk3n04xKK/bSSGdb2zcCE6mwPJjnhkHBJMc55jCu1SPBEoTH60cU1Jf6ZV5oWtc 6HbUeBBnLRlIytNrfGS80LF59xMZknGpcJHhob65Ank1x2boVlh4bJ326x0vZqZ0 bOr2O8DTvN8H6R4T+BJmcykH4AtZXbao7C5/IwidGUPPnGvurJoUiGWwJB8uA0tz SyqHcoGQsS7CcRcOV49/ =qNZD -----END PGP SIGNATURE----- From petithug@acm.org Fri Feb 15 13:14:43 2013 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 0BA6F21F861C for ; Fri, 15 Feb 2013 13:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwsVi2jKP1ou for ; Fri, 15 Feb 2013 13:14: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 24AFB21F861A for ; Fri, 15 Feb 2013 13:14:42 -0800 (PST) Received: from [IPv6:2601:9:4b80:32:41f3:2c5b:5b9c:ed3e] (unknown [IPv6:2601:9:4b80:32:41f3:2c5b:5b9c:ed3e]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id C4CF82045D for ; Fri, 15 Feb 2013 21:14:40 +0000 (UTC) Message-ID: <511EA541.50205@acm.org> Date: Fri, 15 Feb 2013 13:14:41 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: p2psip@ietf.org References: <1359673918.4472.19.camel@acorde.it.uc3m.es> In-Reply-To: <1359673918.4472.19.camel@acorde.it.uc3m.es> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-self-tuning-07 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, 15 Feb 2013 21:14:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I did a review of this draft and that is a well written and useful document that should be submitted to the IESG. I found only one nit (section 7: s/extension&rt;/extension>/) Also I would like to see a code assigned in Section 9.1. that is not already in use. Without it it is difficult to test interoperability between implementations. On 01/31/2013 03:11 PM, Carlos Jesús Bernardos Cano wrote: > Hi, > > Hereby we are issuing a WGLC for draft-ietf-p2psip-self-tuning-07. > > The WGLC will be open till the 15th of February. We kindly ask the WG to > review the document and provide comments. > > If you have no comments and think the document is ready to be submitted to > IESG, please do send a note stating that to the WG ML. > > Additional information about the document is below: > > Title : A Self-tuning Distributed Hash Table (DHT) for REsource > LOcation And Discovery (RELOAD) Author(s) : Jouni Maenpaa Gonzalo > Camarillo Filename : draft-ietf-p2psip-self-tuning-07.txt Pages > : 20 Date : 2013-01-20 > > Abstract: 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. > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-p2psip-self-tuning > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-p2psip-self-tuning-07 > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRHqU3AAoJECnERZXWan7E03UP/jYEko8Kq08/4LjG8mAsfOZO OZy5H+WXrL80krzGNxufcix6MEEssRakpEcEHjVvm6CdyYGNp5pOICinW1zeqTcQ y/b5pP+ZaL7ekpdPgYH2L+OBD4gJZDjqQGtmQQMR2ReCx2tY3zN0RJpzzPTm0hlG pSfRh4W9YhYSkzya2DnfW8Uh7GVcAMBs5JjVE8wvmhLvaFqWKIGCFuLj6t82o9SA PmKk5JiFfqaEeH6aBKmvCiwanUqtheEizBctyQkBvYbshhYQweIM4/o7Lizhek1J b+DZZ9YS6gyT+T+IdVySgyfW0zRXUnPyRDSgpcOU8Ppr0HazKyVOGL4DrbjPQiv3 9wQw+ksC6lwDn0Cy17xDvwXBPT2C+KbJRgf72B1ZyMg+EyO4D0/9nT/znbiQj4JC Hlxkp+mp+LFlsp1MEbPreTPQlOrrKu4A+DddvY1S30U0jfb6UMXTruv/kKzK8LYr FJERSzKUMHO7XSMeDhiHmNPO9QK0uwOno8DNB2cnS6XIm+NKMN+ALJdygqNxFhmw ecm0nUe5P02HT2gGfDsKPZUGSd1hKzgRQKxPwJuD2kx4OKZ4ZgLEjbCH0c/5Q5/D FN5T/MDqL9C0lJdc1TaHQotPKpZ5nNyR5yLPPWPzbgqr3n7WxEei3g0JJ2J0FDUH rFCgtOczV85tMpEfWEEB =dIns -----END PGP SIGNATURE----- From cjbc@it.uc3m.es Sat Feb 16 03:19:32 2013 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 1925C21F86D2 for ; Sat, 16 Feb 2013 03:19:32 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iu5gUQ0Ep53h for ; Sat, 16 Feb 2013 03:19:31 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 28D1A21F86AF for ; Sat, 16 Feb 2013 03:19:30 -0800 (PST) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A9A9688324D; Sat, 16 Feb 2013 12:19:29 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [192.168.1.190] (82.158.126.26.dyn.user.ono.com [82.158.126.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 9015F86C05B; Sat, 16 Feb 2013 12:19:29 +0100 (CET) Message-ID: <1361013565.4246.1.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: p2psip@ietf.org Date: Sat, 16 Feb 2013 12:19:26 +0100 In-Reply-To: <1360232562.4155.31.camel@acorde.it.uc3m.es> References: <1360232562.4155.31.camel@acorde.it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19640.006 X-TM-AS-Result: No--30.311-7.0-31-1 X-imss-scan-details: No--30.311-7.0-31-1 Cc: p2psip-chairs@tools.ietf.org Subject: Re: [P2PSIP] Milestones update and WG draft adoption call X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es 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, 16 Feb 2013 11:19:32 -0000 Dear all, Based on the feedback from the group we are going to ask the secretariat to update our charter milestones. Marc, please submit the draft as draft-ietf-p2psip-reload-access-control-00. Thanks, Carlos On Thu, 2013-02-07 at 11:22 +0100, Carlos Jesús Bernardos Cano wrote: > Dear all, > > During the last meeting there was consensus on adding a new milestone in > our charter for a document on "Configuration of Access Control > Policy in RELOAD" and adopting draft-petithuguenin-p2psip-access-control > as WG document. > > Hereby we are asking about comments about adding this new milestone to > our charter and also starting a consensus call on adopting > draft-petithuguenin-p2psip-access-control-05 as WG document. More > details about this document below: > > Title : Configuration of Access Control Policy in > REsource LOcation And Discovery (RELOAD) Base Protocol > Author(s) : Marc Petit-Huguenin > Filename : > draft-petithuguenin-p2psip-access-control-05.txt > Pages : 12 > Date : 2012-10-22 > > Abstract: > This document describes an extension to the REsource LOcation And > Discovery (RELOAD) base protocol to distribute the code of new Access > Control Policies without having to upgrade the RELOAD implementations > in an overlay. > > Last, but not least, since our milestones were a bit outdated, we want > to also update them. Please find below an updated proposal. > > Please, send your comments about the milestones update and the WG > adoption by Friday 15th. > > Thanks, > > Carlos & Brian > > Proposed (updated charter) > > Goals and Milestones > > Done WGLC of P2PSIP Peer Protocol document > Done WGLC of P2PSIP Diagnostics document > Done WGLC of P2PSIP Direct Response Draft > Done WGLC of P2PSIP Relay Response Draft > Feb 2013 Submit -00 draft on Configuration of Access Control > Policy in RELOAD > Feb 2013 Submit P2PSIP Peer Protocol document to the IESG (PS) > Feb 2013 WGLC of P2PSIP Self-Tuning document > Feb 2013 WGLC of P2PSIP Service Discovery document > Jul 2013 WGLC of P2PSIP SIP Usage document > Jul 2013 WGLC of P2PSIP Concepts document > Jul 2013 Submit P2PSIP Diagnostics document to the IESG (PS) > Jul 2013 Submit P2PSIP Self-Tuning document to the IESG (PS) > Jul 2013 Submit P2PSIP Service Discovery document to the IESG > (PS) > Oct 2013 Submit P2PSIP Concepts document to the IESG > (Informational) > Oct 2013 Submit P2PSIP SIP Usage document to the IESG (PS) > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From internet-drafts@ietf.org Sat Feb 16 08:20:12 2013 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 67A7D21F8967; Sat, 16 Feb 2013 08:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIGkrwXhGEt7; Sat, 16 Feb 2013 08:20:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58CA21F8775; Sat, 16 Feb 2013 08:20:11 -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: 4.40 Message-ID: <20130216162011.3156.11757.idtracker@ietfa.amsl.com> Date: Sat, 16 Feb 2013 08:20:11 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-access-control-00.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: Sat, 16 Feb 2013 16:20:13 -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 Protocol = Working Group of the IETF. Title : Configuration of Access Control Policy in REsource LOcat= ion And Discovery (RELOAD) Base Protocol Author(s) : Marc Petit-Huguenin Filename : draft-ietf-p2psip-access-control-00.txt Pages : 13 Date : 2013-02-16 Abstract: This document describes an extension to the REsource LOcation And Discovery (RELOAD) base protocol to distribute the code of new Access Control Policies without having to upgrade the RELOAD implementations in an overlay. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-access-control There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-access-control-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From petithug@acm.org Sat Feb 16 08:33:20 2013 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 B131421F8933 for ; Sat, 16 Feb 2013 08:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXBOyzS+Hycf for ; Sat, 16 Feb 2013 08:33: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 D4A4221F8899 for ; Sat, 16 Feb 2013 08:33:19 -0800 (PST) Received: from [IPv6:2601:9:4b80:32:6d64:5f4d:a268:f873] (unknown [IPv6:2601:9:4b80:32:6d64:5f4d:a268:f873]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 6C63520148 for ; Sat, 16 Feb 2013 16:33:18 +0000 (UTC) Message-ID: <511FB4CD.703@acm.org> Date: Sat, 16 Feb 2013 08:33:17 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: p2psip@ietf.org References: <20130216162011.3156.11757.idtracker@ietfa.amsl.com> In-Reply-To: <20130216162011.3156.11757.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-access-control-00.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: Sat, 16 Feb 2013 16:33:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Here's the changelog: - - Removed inconsistency in the terminology section. - - Updated the IANA section and added reference to RFC 3688. - - Removed "This is probably not legal..." in the security section. - - Renamed "access-control-code" to simply "code" as it has to be prefixed by the namespace anyway, so there is no risk of conflict. I still have to finish the implementation of the access control policy for ShaRe - I will submit a new version before the deadline if I find the time to finish that and update the reference implementation. Comments, questions and suggestions welcome. On 02/16/2013 08:20 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 : Configuration of Access Control Policy in REsource > LOcation And Discovery (RELOAD) Base Protocol Author(s) : Marc > Petit-Huguenin Filename : draft-ietf-p2psip-access-control-00.txt > Pages : 13 Date : 2013-02-16 > > Abstract: This document describes an extension to the REsource LOcation And > Discovery (RELOAD) base protocol to distribute the code of new Access > Control Policies without having to upgrade the RELOAD implementations in > an overlay. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-p2psip-access-control > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-p2psip-access-control-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRH7S7AAoJECnERZXWan7E9zQQALTvxphYHiUk25i1aj8ZwqKy tW2AZVMMDfpY1GtgddeXhEqcNswXplRXFAU59qdKkCtIL/ptuLRlD8GCmAXIjt9a 5Mu4A+VJWwUj+Pee2ykS++16FtGPZgu5KcD/6vdYkYLcNrU2cURs4WssVSDB6WSI Z26RbVGSpr83FzOOw7kT2zfelPkmJe5HLhsjcuzfG+C00TpYwm3pwvBE/5mBVPKf Uf+QCJVSkGaPNjorx5WJAZ+AphLWNLY2yUpkFSVdTLUQ861CftqN7agbX0Vik653 L2aOtZHx+rO6A+LrHU4Jcwc+Pl3esRUXbuLFzg0sOOcHjw0yQ1431rqJFu5yxRLo ZcMhsOV9d8DlCNfX+kzJo2l0CN9yePeuV9IB/CfzfXmn+CLxDcxXVLR42kJv+qwX eMqGTuTuhUC+6uEP/q2VTWPoSNiXQj/6KkzUXDyXnChP4YXZFJhOXEpIc2gKV4Np zC9x+aJR9e4cbMHdvXKsJv0ydqO3ZR5hnAO25LXFozCXRcj06vxoX0xbaGTqTSCm 0ldwofaJkvwhnHwVaoLMNxCe94vKsQSYLP1OfwZOCDPrAlSvIXroZ63iS3KUZ8bf xsDpGnSH69jyPD95yrIL6FmohlZWXAi/XwU/28Pqf1GhpJ7BTtMcjqEQ2459TAU5 r7X+15b/B+eKWlY978ml =6hme -----END PGP SIGNATURE----- From jouni.maenpaa@ericsson.com Sat Feb 16 09:55:56 2013 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 C44A821F8970 for ; Sat, 16 Feb 2013 09:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APCg1mQV2bat for ; Sat, 16 Feb 2013 09:55:55 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D41BA21F8964 for ; Sat, 16 Feb 2013 09:55:54 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-f0-511fc829bda9 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id CD.1B.19728.928CF115; Sat, 16 Feb 2013 18:55:53 +0100 (CET) Received: from ESESSMB305.ericsson.se ([169.254.5.61]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0318.004; Sat, 16 Feb 2013 18:55:53 +0100 From: =?iso-8859-1?Q?Jouni_M=E4enp=E4=E4?= To: Marc Petit-Huguenin , Joscha Schneider Thread-Topic: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06 Thread-Index: AQHOCuV2i3CDhCh/50uVYPVOI0rEM5h6qB+AgABqnICAAbIJQA== Date: Sat, 16 Feb 2013 17:55:53 +0000 Message-ID: <27112A697EB8204D9943EAB8A0E16B710753ED3E@ESESSMB305.ericsson.se> References: <1359673911.4472.18.camel@acorde.it.uc3m.es> <511D341E.6060905@acm.org> <511E0E0B.6070103@hs-mannheim.de> <511E6779.80706@acm.org> In-Reply-To: <511E6779.80706@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvja7mCflAg3OPNS1+Td3CZvH/+SkW iyU3zzBaXFhzl8mBxePyFW+PQ8fvMHksWfKTyePL5c9sASxRXDYpqTmZZalF+nYJXBkTlzYy FTwKrpj5VqeBsculi5GTQ0LAROJDwzM2CFtM4sK99UA2F4eQwCFGibM/TzBBOIsZJY7++MgE UsUm4C5x+OZPVhBbRCBa4vfVk+wgNrNAhsSuuT8YQWxhAVeJTX0zoWrcJJ52fWeCsJ0k1nzc zQxiswioSmxp+goW5xXwlbh7YTM7xLJJjBKNpw+xgCQ4gYq+XL0HNogR6Lzvp9YwQSwTl7j1 ZD4TxNkCEkv2nGeGsEUlXj7+B1TPAWQrSizvl4Mo15O4MXUKG4StLbFs4WtmiL2CEidnPmGZ wCg2C8nUWUhaZiFpmYWkZQEjyypG9tzEzJz0cqNNjMBIOrjlt+oOxjvnRA4xSnOwKInzhrte CBASSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAuE1s8p3NX+celLv9dYreR67+h4uOJB2ec5P3 SvBpxw6RjGevOJg2eG2MkfjcVdrwYs5x248HHj/8/zOktWRflVLTvgu3Him4/DK9GfpNL1Zz V9+fla0WR9St8u5u3Hazvia4wsmr5NCMHbEx67fei3hzY/MB7l651Kz529jOpumx5657L7ia rV6JpTgj0VCLuag4EQAj3rHIcgIAAA== Cc: "p2psip-chairs@tools.ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06 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, 16 Feb 2013 17:55:56 -0000 Hi Marc and Joscha, Thanks for the comments! Answers inline. Regards, Jouni -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of= Joscha Schneider Sent: 15. helmikuuta 2013 12:30 To: Marc Petit-Huguenin Cc: p2psip-chairs@tools.ietf.org; p2psip@ietf.org Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06 I can confirm that the draft might need some improvements to make the imple= mentation easier. I did a basic implementation but I'm not quite sure that I handled everythi= ng correct. [Jouni]: I'll try to improve the text in the next version of the draft. Especially the definition of the successor seams a bit unclear for me. A si= mple example: Only a single service provider with Node-ID 2 provides a service. Node with= ID 7 performs a lookup... How should it be handled? I implemented it as follows: in case a lookup rev= eals only a single service provider it must be the direct successor. [Jouni]: What would happen in this case is that the upward walk of the serv= ice lookup reaches the root level because no successor can be found from th= e lower levels in the tree. In my implementation, when this happens, I'm se= lecting either the closest successor at the root level or, if there is no s= uccessor, select one of the available service providers randomly (or pick t= he only service provider if there is only one like you are doing in your im= plementation). Anyway, I'll add text to clarify this to the next version of= the draft. Further notice, due to the periodically triggered re-registration the consi= stency of the ReDiR tree can not be always ensured. Theoretically this can = lead to failed lookup processes. This derives from the fact that each new service provider registration migh= t affect the re-registration of the former service providers which again mi= ght affect the re-registrations of other service providers. [Jouni]: Not sure about this. I could be wrong, but why would the re-regist= ration of a service provider affect the re-registrations of other service p= roviders? I mean, when a service provider X re-registers or registers, it s= imply stores its own record at different levels in the ReDiR tree as a part= of the upward and downward walks. This re-registration process does not in= fluence the (re-)registrations of other service providers. Or did I underst= and your comment incorrectly? more inline... Regards Joscha Am 14.02.2013 19:59, schrieb Marc Petit-Huguenin: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I did a review of this draft, and I have some concerns. > > First of all some parts of the I-D are verbatim copy of the text in=20 > the original paper. Is that OK? [Jouni]: I guess the main reason for that is that ReDiR is pretty complex t= o describe. So we took a safe bet and tried to reuse some of the text (the = algorithm description) from the paper. But since there are also comments th= at the text is difficult to follow, I'll make an attempt to reformulate it = in the next version of the draft. > Probably because some of the text comes from a research paper, it was=20 > very difficult to understand fro me, and I am not sure that I yet=20 > understood everything - I still have to write an implementation of=20 > this, and unfortunately to not have enough time to do so before the=20 > end of the WGLC. On the other hand, I know that RELOAD.NET has an=20 > implementation, so I guess it is implementable. [Jouni]: I have also implemented the draft and think I got the implementati= on right. So if you have any further questions about things that are unclea= r, let me know and I can check the code to see how that specific thing was = implemented (and clarify the same issue in the draft if necessary). > But I was not able to make sense of something in the example in section 7= : > Why is the 4th peer added to level 0? Bullet 4 in Section 4.3 says=20 > "Node N MUST continue [repeating steps 2 and 3] until it reaches=20 > either the root or a level a which n.id is not the lowest or highest=20 > Node-ID in the interval I(level, n.id)". In this case 4 is not the=20 > lowest or highest Node-ID in the interval (lowest is 2, highest is 7), so= why is it added to this node? I think the example is simply following the rules. At level 1 peer 4 is the= lowest. So go up and fetch and store. [Jouni]: That's correct. Node 4 starts from the starting level, which is le= vel 2. It stores its record on level 2. Since Node-ID 4 is the lowest (only= ) Node-ID in its interval, the upward walk continues to level 1. At level 1= , Node-ID 4 is also the lowest Node-ID in its interval and thus the upward = walk continues all the way to the root level. Node 4 stores its record in t= hat level. Since Node-ID is neither the lowest nor highest Node-ID, the upw= ard walk stops at level 0 (although it would stop anyway at level 0 since i= t is of course not possible to go further up in the tree). > But if i reveal correct that fact caused a few headaches for=20 > me too. Why does the store does not depend on the information=20 > that was fetched before? [Jouni]: That is how it goes - if there has been a decision that the upward= walk shall continue to the next level, a record is stored at that level 'a= utomatically', regardless of the contents of the tree node. The contents of= the tree node (i.e., whether n.id is sandwiched or not) will influence the= decision on whether to stop the upward walk or continue it. The idea in th= e upward and downward walks is to ensure that the tree is populated densely= enough so that service lookups will finish without requiring too many Fetc= h operations. > BTW a similar example for the service lookup would be useful. [Jouni]: Ok, I'll add an example in the next version of the draft. > More comments: > > - - Section 3, 3 paragraph: "contains a list of Node-IDs" > > Technically each node is a Dictionary whose keys are Node-IDs and=20 > values contain a list of Destinations. [Jouni]: Ok, I'll modify this in the next version of the draft. > - - Section 4.1 > > s/detination_list/destination_list/ [Jouni]: Ok, will change this one also in the next version of the draft. > - - Section 4.1 > > namespace is an opaque value but the charset and conversion between=20 > character string and byte string for the namespace is not defined. confirm [Jouni]: Would specifying that it is an opaque UTF-8 encoded string be enou= gh? > > - - Section 8 > > The document says that the redir namespace is added to the=20 > element, meaning that all nodes MUST understand=20 > ReDIR, but isn't that against one of the goal of ReDIR, which is that=20 > by using standard Store/Fetch, only a node wishing to store or fetch=20 > has to implement ReDIR? I think at least the RedirServiceProvider Data Structure must be supported.= And also the Access Control Rules. But the algorithm might not be mandatory needed. The RedirServiceProvider Data Structure does not need to be understood by t= he peer storing it, but you are right about the Access Control rule. My ow= n draft about storing the Access Control rule solves this problem but, even= if it is accepted as WG item, we do not want to add a normative reference = to it. So I withdraw what I said - redir needs to be a a mandatory extension at le= ast until new access control policies no longer have to be hardcoded. [Jouni]: Ok, so if I understood correctly, it is ok to leave the text as it= is. > - - Section 10.3 > > I think that we need a bit more explanation on what the turn-server=20 > and voice-mail service providers are. [Jouni]: I could remove the voice-mail service provider from the next versi= on of the draft as I don't have a good explanation for that. For turn-serve= r I will add some text. > On 01/31/2013 03:11 PM, Carlos Jes=FAs Bernardos Cano wrote: >> Hi, >> >> Hereby we are issuing a WGLC for draft-ietf-p2psip-service-discovery-06. >> >> The WGLC will be open till the 15th of February. We kindly ask the WG=20 >> to review the document and provide comments. >> >> If you have no comments and think the document is ready to be=20 >> submitted to IESG, please do send a note stating that to the WG ML. >> >> Additional information about the document is below: >> >> Title : Service Discovery Usage for REsource LOcation And >> Discovery (RELOAD) Author(s) : Jouni Maenpaa Gonzalo Camarillo >> Filename : draft-ietf-p2psip-service-discovery-06.txt Pages : 15 >> Date : 2012-10-01 >> >> Abstract: REsource LOcation and Discovery (RELOAD) does not define a=20 >> generic service discovery mechanism as part of the base protocol. =20 >> This document defines how the Recursive Distributed Rendezvous=20 >> (ReDiR) service discovery mechanism used in OpenDHT can be applied to=20 >> RELOAD overlays to provide a generic service discovery mechanism. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-p2psip-service-discovery >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-p2psip-service-discovery-06 >> >> > > - -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBCAAGBQJRHTQcAAoJECnERZXWan7EmukP/A1P3JutcxuDooxYPFjty3ua > lhhbiJTd7PLEs9jsaG9hKHjuDi2qu0BNp9Ss+ki+ybtXBNKaJwkrqNqwB3R+dXpx > Q7zamHvCUJekNmybG2kpc5IUP2MxhDzYp3paocOdF/vdWYE+re3u9WqBN1JNuCwk > E6GmfEIgw28p5wKldHPCGQrRYx6QnszsQc7F3+siFrsSEzRww7ATpUXjMCVxUfWU > KTmBh0H+9+PhoXeH6leue2v0Y5Xb1lD8HU6WmrssWYrd9rXgc3s26kzsUrATJCKc > bj7M6uiKIzUDFwaj13U6bPbldVeJWd+DhWCR2k4Y3rJIfj5bdp55ApDZnF/14v91 > i/w0hnqnuiT/KEDuW+E7jsKwXq/ILKIDZqonyFlF7KuGUT3HGi9WFkc7AnkaOi5U > qgsuFEYjxkUqAbTAO7nwa9YtGX0qKHhH5SkzWpITTabu48c5FKqG0vAVpGce8z3K > AyqtwNXAz9nIL6ZwJNg9L8tLhLBQS1lePeSiN7pog4jsKD51VaT7Y1iMysA2OqRs > Nw70wF7TYh4EikCHsECPQBEI/a+cJEQSro0I4kHGGttVcEdrDqM4xdfaFYN+Ag1b > vHEf3Zzv/x820fjbfN1eoySj/qFU7Mcuw8Rik//J63HKZbmGdbaYsdrHasgaDIqk > TgSsgGCf6d5FX9TFFNvd > =3Du3Pi > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip= From internet-drafts@ietf.org Sat Feb 16 10:49:13 2013 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 8864021F89AA; Sat, 16 Feb 2013 10:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6TG6vuqxk6V; Sat, 16 Feb 2013 10:49:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE9F21F89B5; Sat, 16 Feb 2013 10:49:13 -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: 4.40 Message-ID: <20130216184913.27513.49348.idtracker@ietfa.amsl.com> Date: Sat, 16 Feb 2013 10:49:13 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-service-discovery-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: Sat, 16 Feb 2013 18:49:13 -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 Protocol = 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-07.txt Pages : 16 Date : 2013-02-16 Abstract: REsource LOcation and Discovery (RELOAD) does not define a generic service discovery mechanism as a 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-service-discovery There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-service-discovery-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-service-discovery-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jouni.maenpaa@ericsson.com Sat Feb 16 10:53:11 2013 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 ABF4C21F8D32; Sat, 16 Feb 2013 10:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cl4NCzckr11S; Sat, 16 Feb 2013 10:53:11 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5D19A21F8D2F; Sat, 16 Feb 2013 10:53:10 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-d6-511fd5957fe2 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id BC.84.32353.595DF115; Sat, 16 Feb 2013 19:53:09 +0100 (CET) Received: from ESESSMB305.ericsson.se ([169.254.5.61]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0318.004; Sat, 16 Feb 2013 19:53:08 +0100 From: =?iso-8859-1?Q?Jouni_M=E4enp=E4=E4?= To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [P2PSIP] I-D Action: draft-ietf-p2psip-service-discovery-07.txt Thread-Index: AQHODHZo1tmOfHwlVk2uPVRVgurUQph81GQQ Date: Sat, 16 Feb 2013 18:53:08 +0000 Message-ID: <27112A697EB8204D9943EAB8A0E16B710753EDC8@ESESSMB305.ericsson.se> References: <20130216184913.27513.49348.idtracker@ietfa.amsl.com> In-Reply-To: <20130216184913.27513.49348.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvje7Uq/KBBjNe81ss2fWc2eLD3VyL JTfPMDoweyxZ8pMpgDGKyyYlNSezLLVI3y6BK2Pt7EtsBbf5KlqPzGZsYPzD3cXIySEhYCKx 7+widghbTOLCvfVsXYxcHEIChxgltjxbzwThLGaUOPDjBDNIFZuAu8Thmz9ZQWwRgRyJu7+f snQxcnAwC6hLHHsfABIWFvCRWDHpIxNEia/ElBlXocqNJLZevMoIYrMIqEr0LvnICtLKC1Qz 9544SFhIwFHize/rYOWcAk4SE99cZAGxGYFu+35qDdhIZgFxiVtP5jNB3CwgsWTPeWYIW1Ti 5eN/YCMlBBQllvfLQZTrSdyYOoUNwtaWWLbwNVg5r4CgxMmZT1gmMIrNQjJ1FpKWWUhaZiFp WcDIsoqRPTcxMye93HwTIzA6Dm75bbCDcdN9sUOM0hwsSuK84a4XAoQE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUwhuz5pzTj7sGonf1MU9td7yv21vKXrerJ4dtTXLxKe6Hj/HXHor6/6X7/ puujYP/H+7zW5rz1oXxbvnSt3v9Wck/czksX/oYt+iRcUvePzzbG89t0854Jej+K5e+obN/s mO/99eHyxY/2F8Q8Wu/yPH3/eVmZ0vjoQwZeQXvtNvLtv7rvzuJDa5VYijMSDbWYi4oTARQn C3BcAgAA Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-service-discovery-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: Sat, 16 Feb 2013 18:53:11 -0000 Hi, This new version of draft-ietf-p2psip-service-discovery attempts to address= the comments received during the WGLC. Regards, Jouni -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of= internet-drafts@ietf.org Sent: 16. helmikuuta 2013 20:49 To: i-d-announce@ietf.org Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-service-discovery-07.txt 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 Protocol = 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-07.txt Pages : 16 Date : 2013-02-16 Abstract: REsource LOcation and Discovery (RELOAD) does not define a generic service discovery mechanism as a 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-service-discovery There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-service-discovery-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-service-discovery-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From jouni.maenpaa@ericsson.com Sat Feb 16 11:18:25 2013 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 3F10F21F8899 for ; Sat, 16 Feb 2013 11:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEznX89622ra for ; Sat, 16 Feb 2013 11:18:24 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id EBA9821F887D for ; Sat, 16 Feb 2013 11:18:23 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-4b-511fdb7e8586 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 4B.EE.19728.E7BDF115; Sat, 16 Feb 2013 20:18:22 +0100 (CET) Received: from ESESSMB305.ericsson.se ([169.254.5.61]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0318.004; Sat, 16 Feb 2013 20:18:22 +0100 From: =?iso-8859-1?Q?Jouni_M=E4enp=E4=E4?= To: Marc Petit-Huguenin , "p2psip@ietf.org" Thread-Topic: [P2PSIP] WGLC for draft-ietf-p2psip-self-tuning-07 Thread-Index: AQHOC8F9aOF+ALovmU+/3oiB2OZhWZh83RFA Date: Sat, 16 Feb 2013 19:18:22 +0000 Message-ID: <27112A697EB8204D9943EAB8A0E16B710753EE0E@ESESSMB305.ericsson.se> References: <1359673918.4472.19.camel@acorde.it.uc3m.es> <511EA541.50205@acm.org> In-Reply-To: <511EA541.50205@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+JvjW7dbflAgwkLDC2W3DzDaHFhzV0m ByaPy1e8PZYs+ckUwBTFZZOSmpNZllqkb5fAlbHw7jOmgltSFVufRzcwPhLrYuTkkBAwkZg8 qYcRwhaTuHBvPVsXIxeHkMAhRolpHxpYIJzFjBL/ttxiBqliE3CXOHzzJyuILSIQKPFt9i02 EFtYwF7ixtmZzBBxB4lX964C1XAA2UYSW/6qgZgsAqoSK6frgVTwCvhKbJu+D6xaSCBY4tLp 9SwgNidQyddPm8GmMwLd8/3UGiYQm1lAXOLWk/lMEHcKSCzZc54ZwhaVePn4H9gmCQFFieX9 chDlehI3pk5hg7C1JZYtfM0MsVZQ4uTMJywTGEVnIZk6C0nLLCQts5C0LGBkWcXInpuYmZNe brSJERgDB7f8Vt3BeOecyCFGaQ4WJXHecNcLAUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY E1uPd2fPOlpiYzdnvciJOf0l8j/48moZ0+s7M5KKJ3UfX8/erv7jSuzfYxI5aaaPAk5USv5S u+bNdK9V/Mj16KP1tQUOm2QyvW59zNbWcdjo+NPv+Pqj1+J83f4xibr7B1bPffIqJmTT1V3u DtE9zXfVH91aHjjhzNlzFlrX2k+r7Ale63FIiaU4I9FQi7moOBEA2feaRU8CAAA= Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-self-tuning-07 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, 16 Feb 2013 19:18:25 -0000 Hi, Thanks for the comments! They will be addressed in the next version of the = draft. Regards, Jouni -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of= Marc Petit-Huguenin Sent: 15. helmikuuta 2013 23:15 To: p2psip@ietf.org Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-self-tuning-07 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I did a review of this draft and that is a well written and useful document= that should be submitted to the IESG. I found only one nit (section 7: s/extension&rt;/extension>/) Also I would like to see a code assigned in Section 9.1. that is not alread= y in use. Without it it is difficult to test interoperability between impl= ementations. On 01/31/2013 03:11 PM, Carlos Jes=FAs Bernardos Cano wrote: > Hi, >=20 > Hereby we are issuing a WGLC for draft-ietf-p2psip-self-tuning-07. >=20 > The WGLC will be open till the 15th of February. We kindly ask the WG=20 > to review the document and provide comments. >=20 > If you have no comments and think the document is ready to be=20 > submitted to IESG, please do send a note stating that to the WG ML. >=20 > Additional information about the document is below: >=20 > Title : A Self-tuning Distributed Hash Table (DHT) for REsource > LOcation And Discovery (RELOAD) Author(s) : Jouni Maenpaa Gonzalo > Camarillo Filename : draft-ietf-p2psip-self-tuning-07.txt Pages > : 20 Date : 2013-01-20 >=20 > Abstract: REsource LOcation And Discovery (RELOAD) is a peer-to-peer=20 > (P2P) signaling protocol that provides an overlay network service. =20 > Peers in a RELOAD overlay network collectively run an overlay=20 > algorithm to organize the overlay, and to store and retrieve data. =20 > This document describes how the default topology plugin of RELOAD can=20 > be extended to support self-tuning, that is, to adapt to changing=20 > operating conditions such as churn and network size. >=20 > The IETF datatracker status page for this draft is:=20 > https://datatracker.ietf.org/doc/draft-ietf-p2psip-self-tuning >=20 > There's also a htmlized version available at:=20 > http://tools.ietf.org/html/draft-ietf-p2psip-self-tuning-07 >=20 - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRHqU3AAoJECnERZXWan7E03UP/jYEko8Kq08/4LjG8mAsfOZO OZy5H+WXrL80krzGNxufcix6MEEssRakpEcEHjVvm6CdyYGNp5pOICinW1zeqTcQ y/b5pP+ZaL7ekpdPgYH2L+OBD4gJZDjqQGtmQQMR2ReCx2tY3zN0RJpzzPTm0hlG pSfRh4W9YhYSkzya2DnfW8Uh7GVcAMBs5JjVE8wvmhLvaFqWKIGCFuLj6t82o9SA PmKk5JiFfqaEeH6aBKmvCiwanUqtheEizBctyQkBvYbshhYQweIM4/o7Lizhek1J b+DZZ9YS6gyT+T+IdVySgyfW0zRXUnPyRDSgpcOU8Ppr0HazKyVOGL4DrbjPQiv3 9wQw+ksC6lwDn0Cy17xDvwXBPT2C+KbJRgf72B1ZyMg+EyO4D0/9nT/znbiQj4JC Hlxkp+mp+LFlsp1MEbPreTPQlOrrKu4A+DddvY1S30U0jfb6UMXTruv/kKzK8LYr FJERSzKUMHO7XSMeDhiHmNPO9QK0uwOno8DNB2cnS6XIm+NKMN+ALJdygqNxFhmw ecm0nUe5P02HT2gGfDsKPZUGSd1hKzgRQKxPwJuD2kx4OKZ4ZgLEjbCH0c/5Q5/D FN5T/MDqL9C0lJdc1TaHQotPKpZ5nNyR5yLPPWPzbgqr3n7WxEei3g0JJ2J0FDUH rFCgtOczV85tMpEfWEEB =3DdIns -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From internet-drafts@ietf.org Sat Feb 16 11:20:51 2013 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 4FB1621F8994; Sat, 16 Feb 2013 11:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhVLHU0BMi0g; Sat, 16 Feb 2013 11:20:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D2E21F88E6; Sat, 16 Feb 2013 11:20:50 -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: 4.40 Message-ID: <20130216192050.14673.59154.idtracker@ietfa.amsl.com> Date: Sat, 16 Feb 2013 11:20:50 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-self-tuning-08.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: Sat, 16 Feb 2013 19:20:51 -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 Protocol = 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 Filename : draft-ietf-p2psip-self-tuning-08.txt Pages : 21 Date : 2013-02-16 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-self-tuning There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-self-tuning-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-self-tuning-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jouni.maenpaa@ericsson.com Sat Feb 16 11:23:33 2013 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 B27D121F8994 for ; Sat, 16 Feb 2013 11:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.749 X-Spam-Level: X-Spam-Status: No, score=-5.749 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXZorpyMKBOa for ; Sat, 16 Feb 2013 11:23:33 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7640F21F8970 for ; Sat, 16 Feb 2013 11:23:32 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-8c-511fdcb348b4 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E9.5F.10459.3BCDF115; Sat, 16 Feb 2013 20:23:31 +0100 (CET) Received: from ESESSMB305.ericsson.se ([169.254.5.61]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0318.004; Sat, 16 Feb 2013 20:23:30 +0100 From: =?iso-8859-1?Q?Jouni_M=E4enp=E4=E4?= To: "p2psip@ietf.org" Thread-Topic: [P2PSIP] I-D Action: draft-ietf-p2psip-self-tuning-08.txt Thread-Index: AQHODHrSL9S0n+EZJkqHR1nnhTj7Eph83NYQ Date: Sat, 16 Feb 2013 19:23:30 +0000 Message-ID: <27112A697EB8204D9943EAB8A0E16B710753EE63@ESESSMB305.ericsson.se> References: <20130216192050.14673.59154.idtracker@ietfa.amsl.com> In-Reply-To: <20130216192050.14673.59154.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvje7mO/KBBquPqVgsuXmG0YHRY8mS n0wBjFFcNimpOZllqUX6dglcGXt6ZjIWHOKvWLHrCXMD41GeLkZODgkBE4m+L/1MELaYxIV7 69m6GLk4hAQOMUosmN7GDOEsZpR48uIBM0gVm4C7xOGbP1lBbBEBdYnrs84AdXBwCAu4SSyd yQ0RdpdY/uMeG4RtJNFw4DpYCYuAqsSivlSQMK+Ar8S/RRvZQWwhAUeJ7sPbwG7gFHCSmHF1 JyOIzQh0z/dTa8DizALiEreezIe6U0BiyZ7zzBC2qMTLx/9YQcZLCChKLO+XgyjXk7gxdQob hK0tsWzha2aItYISJ2c+YZnAKDoLydRZSFpmIWmZhaRlASPLKkb23MTMnPRyw02MwJA/uOW3 7g7GU+dEDjFKc7AoifOGuV4IEBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCYV5/8z6TpkPKJ +wcfB6bKaLsL/u65yR/3+B+f9dzkWU+epv6Z9e7MnJiWyxbbhDL/n+JWk7raMee//DKVZQ6p UZXBivbGsk9bJScl/ikOmbry0WNfj6tBsl/LH76YeC2A/eyiXZFSSoXG5WohW9M0Gx1OXG96 f/OTx9tfp7zzDtgf0L2xoaVOiaU4I9FQi7moOBEATzsuykcCAAA= Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-self-tuning-08.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: Sat, 16 Feb 2013 19:23:33 -0000 Hi, This new version of draft-ietf-p2psip-self-tuning-08 addresses the comments= received during the WGLC. Regards, Jouni -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of= internet-drafts@ietf.org Sent: 16. helmikuuta 2013 21:21 To: i-d-announce@ietf.org Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-self-tuning-08.txt 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 Protocol = 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 Filename : draft-ietf-p2psip-self-tuning-08.txt Pages : 21 Date : 2013-02-16 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-self-tuning There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-self-tuning-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-self-tuning-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From internet-drafts@ietf.org Sat Feb 16 17:21:03 2013 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 0582221F87AC; Sat, 16 Feb 2013 17:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51up8o0EaEWB; Sat, 16 Feb 2013 17:21:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615F421F884A; Sat, 16 Feb 2013 17:21:02 -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: 4.40 Message-ID: <20130217012102.4535.12518.idtracker@ietfa.amsl.com> Date: Sat, 16 Feb 2013 17:21:02 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-drr-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: Sun, 17 Feb 2013 01:21:03 -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 Protocol = Working Group of the IETF. Title : An extension to RELOAD to support Direct Response Routing Author(s) : Ning Zong Xingfeng Jiang Roni Even Yunfei Zhang Filename : draft-ietf-p2psip-drr-04.txt Pages : 18 Date : 2013-02-16 Abstract: This document proposes an optional extension to RELOAD to support direct response routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediary peers and describes the potential cases where this extension can be used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-drr There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-drr-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-drr-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sat Feb 16 17:22:43 2013 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 B092821F88EA; Sat, 16 Feb 2013 17:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V48KM5jMZiHV; Sat, 16 Feb 2013 17:22:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B2621F8994; Sat, 16 Feb 2013 17:22:43 -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: 4.40 Message-ID: <20130217012243.4553.58268.idtracker@ietfa.amsl.com> Date: Sat, 16 Feb 2013 17:22:43 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-rpr-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: Sun, 17 Feb 2013 01:22:43 -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 Protocol = Working Group of the IETF. Title : An extension to RELOAD to support Relay Peer Routing Author(s) : Ning Zong Xingfeng Jiang Roni Even Yunfei Zhang Filename : draft-ietf-p2psip-rpr-04.txt Pages : 15 Date : 2013-02-16 Abstract: This document proposes an optional extension to RELOAD to support relay peer routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediary peers and describes the potential cases where this extension can be used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-rpr There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-rpr-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-rpr-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zongning@huawei.com Sat Feb 16 17:30:26 2013 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 A738221F8994 for ; Sat, 16 Feb 2013 17:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id im7Gw8i9OYMM for ; Sat, 16 Feb 2013 17:30:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AAA0521F8628 for ; Sat, 16 Feb 2013 17:30:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APU28039; Sun, 17 Feb 2013 01:30:24 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 17 Feb 2013 01:29:48 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 17 Feb 2013 01:30:21 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.101]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Sun, 17 Feb 2013 09:30:14 +0800 From: Zongning To: "cjbc@it.uc3m.es" , Roni Even Thread-Topic: [P2PSIP] Review of DRR and RPR documents Thread-Index: AQHN+JbQ+lELkghHqEm4neGtHGOlyJhUzD8AgAA7sQCAKGHKcA== Date: Sun, 17 Feb 2013 01:30:13 +0000 Message-ID: References: <1358855465.4174.24.camel@acorde.it.uc3m.es> <008a01cdf8a1$c767bca0$563735e0$@gmail.com> <1358873012.4174.54.camel@acorde.it.uc3m.es> In-Reply-To: <1358873012.4174.54.camel@acorde.it.uc3m.es> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.50] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Review of DRR and RPR documents 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, 17 Feb 2013 01:30:26 -0000 Hi, Carlos and all. We have submitted new revision of DRR draft and RPR draft. The main change = is that we did some wording in RPR draft to avoid referring to DRR as norma= tive reference. As said, we still have some duplication in the two drafts because we want t= o keep them independent to each other. Further comments and suggestions are welcome. Thanks. -Ning > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf = Of > Carlos Jes=FAs Bernardos Cano > Sent: Wednesday, January 23, 2013 12:44 AM > To: Roni Even > Cc: draft-ietf-p2psip-rpr@tools.ietf.org; draft-ietf-p2psip-drr@tools.iet= f.org; > p2psip@ietf.org > Subject: Re: [P2PSIP] Review of DRR and RPR documents >=20 > Hi Roni, >=20 > Thanks for the prompt reaction. >=20 > If the split/merging discussion has already taken place, I don't want to > bring it again, but I just found a bit artificial the separation in two > documents (and now I see why). I see the point of implementation > compliance with one RFC and not the other, but current text in RPR > refers to protocol extensions defined in DRR, so we are not there > either. >=20 > As I see it (personal opinion) if we want to keep two separate > documents, we still need some additional work on the wording of them, > and we might end up duplicating some content. The merging approach would > make the text cleaner, but would have the problem you pointed out. >=20 > Thanks, >=20 > Carlos >=20 > On Tue, 2013-01-22 at 15:09 +0200, Roni Even wrote: > > Hi Carlos, > > Thanks for the review, we will look at the comments as for merging the > documents. Originally it was one document and it was a WG decision to spl= it it > to allow implementation to be compliant with an RFC if they want only to > support DRR or RPR > > Roni Even > > > > -----Original Message----- > > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behal= f > Of Carlos Jes?s Bernardos Cano > > Sent: 22 January, 2013 1:51 PM > > To: p2psip@ietf.org > > Cc: draft-ietf-p2psip-drr@tools.ietf.org; draft-ietf-p2psip-rpr@tools.i= etf.org > > Subject: [P2PSIP] Review of DRR and RPR documents > > > > Hi, > > > > As agreed during the last meeting, I've performed a review of > draft-ietf-p2psip-drr and draft-ietf-p2psip-rpr documents, prior to shipp= ing > them to the IESG for publication. My reviews are attached to this e-mail = (I > added comments to the PDF version of each draft, hope this is fine). > > > > I'd like authors to go through the comments before sending the document= s to > the IESG. There might be some issues that need to be brought to the WG fo= r > discussion. > > > > I'd also like to ask the WG for opinion on one particular aspect. I'm w= ondering > if it would be better to merge both documents into a single one. Currentl= y, both > documents make quite a lot of cross-references, but still there is duplic= ate text > in both of them, so I'd be more in favor of merging (personal opinion). P= lease, > comment on this on the mailing list. > > > > Thanks, > > > > Carlos > > >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From haibin.song@huawei.com Sun Feb 17 00:37:35 2013 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 9C37621F8427 for ; Sun, 17 Feb 2013 00:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlyqSugmo4iI for ; Sun, 17 Feb 2013 00:37:34 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 99B4921F841B for ; Sun, 17 Feb 2013 00:37:33 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AON40858; Sun, 17 Feb 2013 08:37:31 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 17 Feb 2013 08:36:55 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 17 Feb 2013 08:37:30 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.101]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Sun, 17 Feb 2013 16:37:25 +0800 From: "Songhaibin (A)" To: Marc Petit-Huguenin , P2PSIP WG Thread-Topic: [P2PSIP] FW: I-D Action: draft-ietf-p2psip-diagnostics-10.txt Thread-Index: AQHOCyEL3dS2qabNrUGrdyODnxMys5h9vGqw Date: Sun, 17 Feb 2013 08:37:24 +0000 Message-ID: References: <1360877421.4271.42.camel@acorde.it.uc3m.es> <511D980A.2080504@acm.org> In-Reply-To: <511D980A.2080504@acm.org> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.75] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [P2PSIP] FW: I-D Action: draft-ietf-p2psip-diagnostics-10.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: Sun, 17 Feb 2013 08:37:35 -0000 VGhhbmsgeW91IHZlcnkgbXVjaCwgTWFyYyEgSSdtIHNvcnJ5IHRoYXQgdGhlIG5pdHMgeW91ciBy YWlzZWQgd2VyZSBub3QgYWRkcmVzc2VkLiBXaGVuIHdlIHVwZGF0ZSB0aGUgZG9jdW1lbnQsIHdl IGZvY3VzZWQgb24gdGhlIG1haW4gY29uY2VybnMgYnV0IGZvcmdvdCB0aGVzZSB0aW55IG5pdHMu IE5vdyBJJ20gZWRpdGluZyB0aGUgZG9jdW1lbnQgb2ZmbGluZSBhbmQgd2FpdCBmb3IgdGhlIGlu c3RydWN0aW9ucyBmcm9tIHRoZSBjaGFpcnMuDQoNCkJSLA0KLUhhaWJpbg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHAycHNpcC1ib3VuY2VzQGlldGYub3JnIFttYWls dG86cDJwc2lwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBNYXJjIFBldGl0LUh1 Z3VlbmluDQo+IFNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMTUsIDIwMTMgMTA6MDYgQU0NCj4gVG86 IFAyUFNJUCBXRw0KPiBTdWJqZWN0OiBSZTogW1AyUFNJUF0gRlc6IEktRCBBY3Rpb246IGRyYWZ0 LWlldGYtcDJwc2lwLWRpYWdub3N0aWNzLTEwLnR4dA0KPiANCj4gLS0tLS1CRUdJTiBQR1AgU0lH TkVEIE1FU1NBR0UtLS0tLQ0KPiBIYXNoOiBTSEEyNTYNCj4gDQo+IFNlY3Rpb24gOCBhbnN3ZXJz IG15IGNvbmNlcm4gYWJvdXQgc2VjdXJpdHksIGFsdGhvdWdoIHRoZSBzZWN0aW9uIHdpbGwgbmVl ZCBhDQo+IGZvcm1hbCBzY2hlbWEuICBBRkFJQyB0aGlzIGRyYWZ0IGlzIHJlYWR5IHRvIGJlIHN1 Ym1pdHRlZCB0byB0aGUgSUVTRy4NCj4gDQo+IEkgYWxzbyByZXZpZXdlZCB0aGUgb3RoZXIgY2hh bmdlcyBhbmQgbm90aWNlZCB0aGF0IG1vc3Qgb2YgdGhlIG5pdHMgSQ0KPiBzdWdnZXN0ZWQgd2Vy ZSBub3QgYXBwbGllZC4gIEluIGFkZGl0aW9uIEkgbm90aWNlZCB0aGF0IHNvbWUgcmVmZXJlbmNl cyBuZWVkDQo+IGFuIHVwZGF0ZToNCj4gDQo+IEktRC56aGVuZy1wMnBzaXAtZGlhZ25vc2UNCj4g SS1ELmlldGYtYmVoYXZlLXJmYzM0ODliaXMNCj4gSS1ELmlldGYtbW11c2ljLWljZQ0KPiANCj4g YW5kIHBlcmhhcHMgbW9yZS4NCj4gDQo+IEdsb2JhbGx5IHRoZSB3aG9sZSBkb2N1bWVudCBzdGls bCBmZWVsIGxpa2UgaXQgbmVlZHMgc29tZSBlZGl0aW5nLg0KPiANCj4gT24gMDIvMTQvMjAxMyAw MTozMCBQTSwgQ2FybG9zIEplc8O6cyBCZXJuYXJkb3MgQ2FubyB3cm90ZToNCj4gPiBIaSBmb2xr cywNCj4gPg0KPiA+IFBsZWFzZSByZXZpZXcgdGhlIGRvYywgYXMgc2V2ZXJhbCBjaGFuZ2VzIGhh dmUgYmVlbiBtYWRlLiAgSWYgeW91IGJlbGlldmUNCj4gPiBpdCdzIHJlYWR5IHRvIGdvLCBwbGVh c2UgYWZmaXJtYXRpdmVseSBzYXkgc28uIElmIHlvdSBiZWxpZXZlIHdlIG5lZWQgdG8gZG8NCj4g PiBtb3JlIHJldmlldywgcGxlYXNlIHNheSB0aGF0Lg0KPiA+DQo+ID4gSWYgeW91IGZpbmQgcHJv YmxlbXMsIG9mIGNvdXJzZSB3ZSB3YW50IHRvIGhlYXIgdGhlbS4NCj4gPg0KPiA+IFRoYW5rcywN Cj4gPg0KPiA+IEJyaWFuICYgQ2FybG9zDQo+ID4NCj4gPiBPbiBNb24sIDIwMTMtMDItMDQgYXQg MDk6MDAgKzAwMDAsIFNvbmdoYWliaW4gKEEpIHdyb3RlOg0KPiA+PiBIaSBndXlzLA0KPiA+Pg0K PiA+PiBXZSBoYXZlIG1hZGUgcXVpdGUgYSBmZXcgY2hhbmdlcyB0byB0aGUgcDJwc2lwIGRpYWdu b3N0aWNzIGRyYWZ0LCBub3cgd2UNCj4gPj4gYmVsaWV2ZSBpdCBoYXMgc29sdmVkIHRoZSBjb21t ZW50cyBmcm9tIHRoZSBXR0xDIHdpdGggc29sdXRpb25zIGZyb20gbGFzdA0KPiA+PiBJRVRGIG1l ZXRpbmcgY29uc2Vuc3VzLiBNYXliZSBhIHNlY29uZCBXR0xDIGlzIG5lZWRlZCBmb3IgbW9yZSBz dWZmaWNpZW50DQo+ID4+IHJldmlldy4NCj4gPj4NCj4gPj4gQlIsIC1IYWliaW4NCj4gPj4NCj4g Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IHAycHNpcC1ib3VuY2VzQGlldGYu b3JnDQo+ID4+PiBbbWFpbHRvOnAycHNpcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+ID4+PiBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDA0 LCAyMDEzIDQ6NTEgUE0gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZyBDYzoNCj4gPj4+IHAycHNp cEBpZXRmLm9yZyBTdWJqZWN0OiBbUDJQU0lQXSBJLUQgQWN0aW9uOg0KPiA+Pj4gZHJhZnQtaWV0 Zi1wMnBzaXAtZGlhZ25vc3RpY3MtMTAudHh0DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IEEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cw0KPiA+Pj4gZGlyZWN0b3JpZXMuIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFBl ZXItdG8tUGVlciBTZXNzaW9uDQo+ID4+PiBJbml0aWF0aW9uIFByb3RvY29sIFdvcmtpbmcgR3Jv dXAgb2YgdGhlIElFVEYuDQo+ID4+Pg0KPiA+Pj4gVGl0bGUgICAgICAgICAgIDogUDJQIE92ZXJs YXkgRGlhZ25vc3RpY3MgQXV0aG9yKHMpICAgICAgIDogSGFpYmluDQo+ID4+PiBTb25nIEppYW5n IFhpbmdmZW5nIFJvbmkgRXZlbiBEYXZpZCBBLiBCcnlhbiBGaWxlbmFtZSAgICAgICAgOg0KPiA+ Pj4gZHJhZnQtaWV0Zi1wMnBzaXAtZGlhZ25vc3RpY3MtMTAudHh0IFBhZ2VzICAgICAgICAgICA6 IDMxIERhdGUNCj4gPj4+IDogMjAxMy0wMi0wNA0KPiA+Pj4NCj4gPj4+IEFic3RyYWN0OiBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyBtZWNoYW5pc21zIGZvciBQMlAgb3ZlcmxheQ0KPiA+Pj4gZGlh Z25vc3RpY3MuICBJdCBkZWZpbmVzIGV4dGVuc2lvbnMgdG8gdGhlIFJFTE9BRCBQMlBTSVAgYmFz ZSBwcm90b2NvbA0KPiA+Pj4gUkVMT0FEIFtJLUQuaWV0Zi1wMnBzaXAtYmFzZV0gdG8gY29sbGVj dCBkaWFnbm9zdGljIGluZm9ybWF0aW9uLCBhbmQNCj4gPj4+IGRldGFpbHMgdGhlIHByb3RvY29s IHNwZWNpZmljYXRpb25zIGZvciB0aGVzZSBleHRlbnNpb25zLiAgVXNlZnVsDQo+ID4+PiBkaWFn bm9zdGljIGluZm9ybWF0aW9uIGZvciBjb25uZWN0aW9uIGFuZCBub2RlIHN0YXR1cyBtb25pdG9y aW5nIGlzDQo+ID4+PiBhbHNvIGRlZmluZWQuICBUaGUgZG9jdW1lbnQgYWxzbyBkZXNjcmliZXMg dGhlIHVzYWdlIHNjZW5hcmlvcyBhbmQNCj4gPj4+IHByb3ZpZGVzIGV4YW1wbGVzIG9mIGhvdyB0 aGVzZSBtZXRob2RzIGFyZSB1c2VkIHRvIHBlcmZvcm0gZGlhZ25vc3RpY3MNCj4gPj4+IGluIGEg UDJQU0lQIG92ZXJsYXkgbmV0d29ya3MuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IFRoZSBJRVRGIGRh dGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiA+Pj4gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1wMnBzaXAtZGlhZ25vc3RpY3MNCj4g Pj4+DQo+ID4+PiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoN Cj4gPj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcDJwc2lwLWRpYWdu b3N0aWNzLTEwDQo+ID4+Pg0KPiA+Pj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g aXMgYXZhaWxhYmxlIGF0Og0KPiA+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi1wMnBzaXAtZGlhZ25vc3RpY3MtMTANCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gSW50 ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiA+ Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gPj4+DQo+ID4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBQMlBTSVAgbWFpbGlu Zw0KPiBsaXN0DQo+ID4+PiBQMlBTSVBAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9wMnBzaXANCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18gUDJQU0lQIG1haWxpbmcNCj4gbGlzdA0KPiA+IFAy UFNJUEBpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNp cA0KPiA+DQo+IA0KPiANCj4gLSAtLQ0KPiBNYXJjIFBldGl0LUh1Z3VlbmluDQo+IEVtYWlsOiBt YXJjQHBldGl0LWh1Z3VlbmluLm9yZw0KPiBCbG9nOiBodHRwOi8vYmxvZy5tYXJjLnBldGl0LWh1 Z3VlbmluLm9yZw0KPiBQcm9maWxlOiBodHRwOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9wZXRpdGh1 Zw0KPiAtLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQ0KPiBWZXJzaW9uOiBHbnVQRyB2MS40 LjEyIChHTlUvTGludXgpDQo+IA0KPiBpUUljQkFFQkNBQUdCUUpSSFpnSUFBb0pFQ25FUlpYV2Fu N0VnM1VQLzNUYmFteHhsbXpMSTlaTjlNUWlqSnBMDQo+IDdMcXNEU1RGcEsyMGhsWlRqNXpYVmdJ L3dCT0pWTEMzZlJtV0RYQjk0TmFsVWlFTkxRVUZ4QmVuWHZMdkJLK2sNCj4gNTkyZnAxMmdSM29a YVRibEJGY0x6LytEaDR2M2RqNGxYUmJBWE9EQkRZTjBGYkVybURpU0dleFNjS0JXcGdDYw0KPiBD M2UxV1ZzazZZQ3NFV0F5QXZXbitvQmZ2VjhXUVZFeUJaVU5uTGdXekYrZ3YwRlo2ZG1WUUdvYWxw V1YNCj4gQnJaRQ0KPiBmalduTCtSVEZhWFJPaW1IRktTdDZYcFJWZlc1d05ETGlESmRsQ1NXZWhX ejIxRk9yRnRoTUZlamFVTHNHM1k2DQo+IHlOcVVrYXlqaEpPMzloSkRaalAwS0dLYVFyWDRkRDhR MkplenJsZDBReXVkWWdjWlFtbE1qbWxiK2FZRU5vRFANCj4gTHU1emVYQVBYaWs2Mi9ENWR3NjRl aDlodE1mZDlsT0k5Ylo4cDdGSnhQU3cySDc5aFZHQ0o5R0NoR21WRTVwMQ0KPiBrQzZ0SzUwSzYx NGZvVlJXcGdnOVFldVZSaFFXNGlESkp6KzRJdE92N0tqcGRrUjVYYk5aeVA5VFoyOE8vSjNCDQo+ IGNsMDBTTFV4Ymw4dDhsQ2ovVnBLSjhJRXVRbXIyNEhFV1pQdE9FY1lUeElxTTZPZEJWUlJaVWdy YmNCdWpLZlkNCj4gdkVRbU9RNXgxQ1JUc3oreFVEMDQrV0xJdG01ei9NRitpTUpkQmkxSHdLZjNl SklvaUlRYXVFK1cwbEdzWHJGNQ0KPiBock9mZ3JrU0tiV2VBeGZKQjRKWVFxT3BNSDIxOWVhejRL MCsxL3BiNmVVcE1SZEFqMTNnV3FYc2hiN0VELzFRDQo+IC9TK1RnOG1FRzVkdHUxdmVKNlA2DQo+ ID1pUlp3DQo+IC0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBQMlBTSVAgbWFpbGluZyBsaXN0DQo+ IFAyUFNJUEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3AycHNpcA0K From petithug@acm.org Sun Feb 17 08:44:53 2013 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 9011121E8034 for ; Sun, 17 Feb 2013 08:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrC41woKaNBW for ; Sun, 17 Feb 2013 08:44: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 AD1CA21F8A93 for ; Sun, 17 Feb 2013 08:44:52 -0800 (PST) Received: from [IPv6:2601:9:4b80:32:d1b:cbb8:ca78:d477] (unknown [IPv6:2601:9:4b80:32:d1b:cbb8:ca78:d477]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 8DEDB204B0 for ; Sun, 17 Feb 2013 16:44:50 +0000 (UTC) Message-ID: <51210903.108@acm.org> Date: Sun, 17 Feb 2013 08:44:51 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: P2PSIP Mailing List References: <20130217164312.17648.47102.idtracker@ietfa.amsl.com> In-Reply-To: <20130217164312.17648.47102.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [P2PSIP] I-D Action: draft-petithuguenin-p2psip-reload-sctp-00.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: Sun, 17 Feb 2013 16:44:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 FYI. On 02/17/2013 08:43 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : SCTP Overlay link for REsource LOcation And Discovery > (RELOAD) Author(s) : Marc Petit-Huguenin Filename : > draft-petithuguenin-p2psip-reload-sctp-00.txt Pages : 4 Date > : 2013-02-17 > > Abstract: This document defines two new Overlay Link protocols to be used > with REsource LOcation And Discovery (RELOAD), both using SCTP. The > Overlay Link protocol DTLS-SCTP-NO-ICE uses DTLS on top of native SCTP for > overlays that do not require the use of ICE. The Overlay Link protocol > DTLS-SCTP-UDP uses DTLS on top of an UDP encapsulation of SCTP for overlays > that require the use of ICE. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-petithuguenin-p2psip-reload-sctp > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-petithuguenin-p2psip-reload-sctp-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRIQkBAAoJECnERZXWan7EWjMP/AuOIUJaGhBqDnWUBUH8gXB2 LnB9nZuePRG850C2JucXjUieNimzEqsL9IcDbLzf6cmfpxygZrpfVUufxqzYq6et r14X1phdc5fkiYrkFloLKcAyPXhX8JsjeQhsvd14salW90F62nX/W9xpPUiA6b4C RNYvcAuuQbhlkllwxNcC6EUJLX2GNBGgKI9SzORc0gjuzhxH+hlKi7DM8HZefbIY 27Y+AN5TrHYEAPRa2aa5jcZYYcnSqnUP+lM5UByJmXAVTryB1ptgJjlf6UkrUt6m llo3lsqQ2T96nqfFHqa1y3Rh4wvBsFOQw8odYqQkqJSVvNOTzX5HPPKbA8eGe82q 518xblWkbe2rPY5xxupru8yhQRjQ8vnPqGIEPliAF6dEn3J1NKxPwXfDG1jof9pF 4Liu91qG+M59Ud4xQsg2hYh14QCStlWLTcAijL4+IdVj3wmaqUkPmTA6vuWoYonm 3P0FqO2t7lMRHOhYQ61VNK6y0KFt+uSBOC+VINTyJj1IyNyBWjXhetBSu4+EQqvP tRFEDws1HOSj2NRzdOe/3nfC68UeAOdgVSYxPO4X9D3+xIaTBQMDURBOvaeQRiU+ jWfo9Mrqy2GiT8upv6B7rvCqXAab04kTNRGGIhJ67JelfKXM3c648erprqN/1Fzg Achm5Fkdhf2e4t1iepKS =W9J1 -----END PGP SIGNATURE----- From cjbc@it.uc3m.es Mon Feb 18 01:16:51 2013 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 03E8021F87AD for ; Mon, 18 Feb 2013 01:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvWg5nChA3QA for ; Mon, 18 Feb 2013 01:16:49 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 1B12321F8519 for ; Mon, 18 Feb 2013 01:16:46 -0800 (PST) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8E570FA98DC; Mon, 18 Feb 2013 10:16:45 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 61B68FA98AF; Mon, 18 Feb 2013 10:16:45 +0100 (CET) Message-ID: <1361179005.4189.10.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Zongning Date: Mon, 18 Feb 2013 10:16:45 +0100 In-Reply-To: References: <1358855465.4174.24.camel@acorde.it.uc3m.es> <008a01cdf8a1$c767bca0$563735e0$@gmail.com> <1358873012.4174.54.camel@acorde.it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19644.006 X-TM-AS-Result: No--39.821-7.0-31-1 X-imss-scan-details: No--39.821-7.0-31-1 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Review of DRR and RPR documents X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es 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, 18 Feb 2013 09:16:51 -0000 Dear Ning, OK, thanks for the updates. Let me take a look and post my revision. Carlos On Sun, 2013-02-17 at 01:30 +0000, Zongning wrote: > Hi, Carlos and all. > > We have submitted new revision of DRR draft and RPR draft. The main change is that we did some wording in RPR draft to avoid referring to DRR as normative reference. > As said, we still have some duplication in the two drafts because we want to keep them independent to each other. > Further comments and suggestions are welcome. > Thanks. > > -Ning > > > -----Original Message----- > > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of > > Carlos Jesús Bernardos Cano > > Sent: Wednesday, January 23, 2013 12:44 AM > > To: Roni Even > > Cc: draft-ietf-p2psip-rpr@tools.ietf.org; draft-ietf-p2psip-drr@tools.ietf.org; > > p2psip@ietf.org > > Subject: Re: [P2PSIP] Review of DRR and RPR documents > > > > Hi Roni, > > > > Thanks for the prompt reaction. > > > > If the split/merging discussion has already taken place, I don't want to > > bring it again, but I just found a bit artificial the separation in two > > documents (and now I see why). I see the point of implementation > > compliance with one RFC and not the other, but current text in RPR > > refers to protocol extensions defined in DRR, so we are not there > > either. > > > > As I see it (personal opinion) if we want to keep two separate > > documents, we still need some additional work on the wording of them, > > and we might end up duplicating some content. The merging approach would > > make the text cleaner, but would have the problem you pointed out. > > > > Thanks, > > > > Carlos > > > > On Tue, 2013-01-22 at 15:09 +0200, Roni Even wrote: > > > Hi Carlos, > > > Thanks for the review, we will look at the comments as for merging the > > documents. Originally it was one document and it was a WG decision to split it > > to allow implementation to be compliant with an RFC if they want only to > > support DRR or RPR > > > Roni Even > > > > > > -----Original Message----- > > > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf > > Of Carlos Jes?s Bernardos Cano > > > Sent: 22 January, 2013 1:51 PM > > > To: p2psip@ietf.org > > > Cc: draft-ietf-p2psip-drr@tools.ietf.org; draft-ietf-p2psip-rpr@tools.ietf.org > > > Subject: [P2PSIP] Review of DRR and RPR documents > > > > > > Hi, > > > > > > As agreed during the last meeting, I've performed a review of > > draft-ietf-p2psip-drr and draft-ietf-p2psip-rpr documents, prior to shipping > > them to the IESG for publication. My reviews are attached to this e-mail (I > > added comments to the PDF version of each draft, hope this is fine). > > > > > > I'd like authors to go through the comments before sending the documents to > > the IESG. There might be some issues that need to be brought to the WG for > > discussion. > > > > > > I'd also like to ask the WG for opinion on one particular aspect. I'm wondering > > if it would be better to merge both documents into a single one. Currently, both > > documents make quite a lot of cross-references, but still there is duplicate text > > in both of them, so I'd be more in favor of merging (personal opinion). Please, > > comment on this on the mailing list. > > > > > > Thanks, > > > > > > Carlos > > > > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip From j.schneider@hs-mannheim.de Mon Feb 18 03:21:05 2013 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 2E86A21F88D8 for ; Mon, 18 Feb 2013 03:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+kaGbIAc3q6 for ; Mon, 18 Feb 2013 03:21:02 -0800 (PST) Received: from hs-mannheim.de (mailnode.rz.fh-mannheim.de [141.19.1.96]) by ietfa.amsl.com (Postfix) with ESMTP id 7E21221F883F for ; Mon, 18 Feb 2013 03:21:00 -0800 (PST) Received: from [141.19.96.81] (account schneiderj@hs-mannheim.de [141.19.96.81] verified) by hs-mannheim.de (CommuniGate Pro SMTP 5.3.15) with ESMTPSA id 18953030; Mon, 18 Feb 2013 12:18:57 +0100 Message-ID: <51220EA9.2060200@hs-mannheim.de> Date: Mon, 18 Feb 2013 12:21:13 +0100 From: Joscha Schneider User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jouni_M=E4enp=E4=E4?= References: <1359673911.4472.18.camel@acorde.it.uc3m.es> <511D341E.6060905@acm.org> <511E0E0B.6070103@hs-mannheim.de> <511E6779.80706@acm.org> <27112A697EB8204D9943EAB8A0E16B710753ED3E@ESESSMB305.ericsson.se> In-Reply-To: <27112A697EB8204D9943EAB8A0E16B710753ED3E@ESESSMB305.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "p2psip-chairs@tools.ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06 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, 18 Feb 2013 11:21:05 -0000 two comments inline regards joscha Am 16.02.2013 18:55, schrieb Jouni Mäenpää: > Hi Marc and Joscha, > > Thanks for the comments! Answers inline. > > Regards, > Jouni > > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of Joscha Schneider > Sent: 15. helmikuuta 2013 12:30 > To: Marc Petit-Huguenin > Cc: p2psip-chairs@tools.ietf.org; p2psip@ietf.org > Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06 > > I can confirm that the draft might need some improvements to make the implementation easier. > I did a basic implementation but I'm not quite sure that I handled everything correct. > > [Jouni]: I'll try to improve the text in the next version of the draft. > > Especially the definition of the successor seams a bit unclear for me. A simple example: > Only a single service provider with Node-ID 2 provides a service. Node with ID 7 performs a lookup... > How should it be handled? I implemented it as follows: in case a lookup reveals only a single service provider it must be the direct successor. > > [Jouni]: What would happen in this case is that the upward walk of the service lookup reaches the root level because no successor can be found from the lower levels in the tree. In my implementation, when this happens, I'm selecting either the closest successor at the root level or, if there is no successor, select one of the available service providers randomly (or pick the only service provider if there is only one like you are doing in your implementation). Anyway, I'll add text to clarify this to the next version of the draft. > > Further notice, due to the periodically triggered re-registration the consistency of the ReDiR tree can not be always ensured. Theoretically this can lead to failed lookup processes. > This derives from the fact that each new service provider registration might affect the re-registration of the former service providers which again might affect the re-registrations of other service providers. > > [Jouni]: Not sure about this. I could be wrong, but why would the re-registration of a service provider affect the re-registrations of other service providers? I mean, when a service provider X re-registers or registers, it simply stores its own record at different levels in the ReDiR tree as a part of the upward and downward walks. This re-registration process does not influence the (re-)registrations of other service providers. Or did I understand your comment incorrectly? I'll try to make an example: Two service provider are even in Level 4 in the same interval. First service prover (X) stops registration downwalk at level 2 because it's the only one. Second service provider (Y) goes down to level 3 to finish its downwalk. X starts re-registration. Now the downwalk need to go down to level 4 as level 2 and 3 are shared Y. Now Y starts re-registration. Goes down to level 5 as level 3 and 4 are shared now. X re-registers again. goes down to level 5. Finally both service providers have found the leaves and the tree is consistent. In between, service lookups might go down to a level at which no service provider information is stored (yet). > more inline... > > Regards > Joscha > > Am 14.02.2013 19:59, schrieb Marc Petit-Huguenin: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> I did a review of this draft, and I have some concerns. >> >> First of all some parts of the I-D are verbatim copy of the text in >> the original paper. Is that OK? > [Jouni]: I guess the main reason for that is that ReDiR is pretty complex to describe. So we took a safe bet and tried to reuse some of the text (the algorithm description) from the paper. But since there are also comments that the text is difficult to follow, I'll make an attempt to reformulate it in the next version of the draft. > >> Probably because some of the text comes from a research paper, it was >> very difficult to understand fro me, and I am not sure that I yet >> understood everything - I still have to write an implementation of >> this, and unfortunately to not have enough time to do so before the >> end of the WGLC. On the other hand, I know that RELOAD.NET has an >> implementation, so I guess it is implementable. > [Jouni]: I have also implemented the draft and think I got the implementation right. So if you have any further questions about things that are unclear, let me know and I can check the code to see how that specific thing was implemented (and clarify the same issue in the draft if necessary). > >> But I was not able to make sense of something in the example in section 7: >> Why is the 4th peer added to level 0? Bullet 4 in Section 4.3 says >> "Node N MUST continue [repeating steps 2 and 3] until it reaches >> either the root or a level a which n.id is not the lowest or highest >> Node-ID in the interval I(level, n.id)". In this case 4 is not the >> lowest or highest Node-ID in the interval (lowest is 2, highest is 7), so why is it added to this node? > I think the example is simply following the rules. At level 1 peer 4 is the lowest. So go up and fetch and store. > > [Jouni]: That's correct. Node 4 starts from the starting level, which is level 2. It stores its record on level 2. Since Node-ID 4 is the lowest (only) Node-ID in its interval, the upward walk continues to level 1. At level 1, Node-ID 4 is also the lowest Node-ID in its interval and thus the upward walk continues all the way to the root level. Node 4 stores its record in that level. Since Node-ID is neither the lowest nor highest Node-ID, the upward walk stops at level 0 (although it would stop anyway at level 0 since it is of course not possible to go further up in the tree). > >> But if i reveal correct that fact caused a few headaches for >> me too. Why does the store does not depend on the information >> that was fetched before? > [Jouni]: That is how it goes - if there has been a decision that the upward walk shall continue to the next level, a record is stored at that level 'automatically', regardless of the contents of the tree node. The contents of the tree node (i.e., whether n.id is sandwiched or not) will influence the decision on whether to stop the upward walk or continue it. The idea in the upward and downward walks is to ensure that the tree is populated densely enough so that service lookups will finish without requiring too many Fetch operations. But does this make sense? If I recall correct the registration information of node 3 and 4 in Level 0 in the draft example will never be used in lookup processes. As far as I understood at most two service provider entries are needed (lowest and highest) in each tree node to make the algorithm work. All sandwiched service provider information is not needed. Most of them will also expire and not be renewed in the re-registration process in case other service providers have registered in the meantime. I think this 'automatic' store process makes the tree just a bit more wired and the algorithm mode difficult to understand. Or do you see a resonable reason for this behaviour that I don't see. >> BTW a similar example for the service lookup would be useful. > [Jouni]: Ok, I'll add an example in the next version of the draft. > >> More comments: >> >> - - Section 3, 3 paragraph: "contains a list of Node-IDs" >> >> Technically each node is a Dictionary whose keys are Node-IDs and >> values contain a list of Destinations. > [Jouni]: Ok, I'll modify this in the next version of the draft. > >> - - Section 4.1 >> >> s/detination_list/destination_list/ > [Jouni]: Ok, will change this one also in the next version of the draft. > >> - - Section 4.1 >> >> namespace is an opaque value but the charset and conversion between >> character string and byte string for the namespace is not defined. > confirm > > [Jouni]: Would specifying that it is an opaque UTF-8 encoded string be enough? > >> - - Section 8 >> >> The document says that the redir namespace is added to the >> element, meaning that all nodes MUST understand >> ReDIR, but isn't that against one of the goal of ReDIR, which is that >> by using standard Store/Fetch, only a node wishing to store or fetch >> has to implement ReDIR? > I think at least the RedirServiceProvider Data Structure must be supported. And also the Access Control Rules. > But the algorithm might not be mandatory needed. > > The RedirServiceProvider Data Structure does not need to be understood by the peer storing it, but you are right about the Access Control rule. My own draft about storing the Access Control rule solves this problem but, even if it is accepted as WG item, we do not want to add a normative reference to it. > > So I withdraw what I said - redir needs to be a a mandatory extension at least until new access control policies no longer have to be hardcoded. > > [Jouni]: Ok, so if I understood correctly, it is ok to leave the text as it is. > >> - - Section 10.3 >> >> I think that we need a bit more explanation on what the turn-server >> and voice-mail service providers are. > [Jouni]: I could remove the voice-mail service provider from the next version of the draft as I don't have a good explanation for that. For turn-server I will add some text. > >> On 01/31/2013 03:11 PM, Carlos Jesús Bernardos Cano wrote: >>> Hi, >>> >>> Hereby we are issuing a WGLC for draft-ietf-p2psip-service-discovery-06. >>> >>> The WGLC will be open till the 15th of February. We kindly ask the WG >>> to review the document and provide comments. >>> >>> If you have no comments and think the document is ready to be >>> submitted to IESG, please do send a note stating that to the WG ML. >>> >>> Additional information about the document is below: >>> >>> Title : Service Discovery Usage for REsource LOcation And >>> Discovery (RELOAD) Author(s) : Jouni Maenpaa Gonzalo Camarillo >>> Filename : draft-ietf-p2psip-service-discovery-06.txt Pages : 15 >>> Date : 2012-10-01 >>> >>> Abstract: 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. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-p2psip-service-discovery >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-p2psip-service-discovery-06 >>> >>> >> - -- >> Marc Petit-Huguenin >> Email: marc@petit-huguenin.org >> Blog: http://blog.marc.petit-huguenin.org >> Profile: http://www.linkedin.com/in/petithug >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.12 (GNU/Linux) >> >> iQIcBAEBCAAGBQJRHTQcAAoJECnERZXWan7EmukP/A1P3JutcxuDooxYPFjty3ua >> lhhbiJTd7PLEs9jsaG9hKHjuDi2qu0BNp9Ss+ki+ybtXBNKaJwkrqNqwB3R+dXpx >> Q7zamHvCUJekNmybG2kpc5IUP2MxhDzYp3paocOdF/vdWYE+re3u9WqBN1JNuCwk >> E6GmfEIgw28p5wKldHPCGQrRYx6QnszsQc7F3+siFrsSEzRww7ATpUXjMCVxUfWU >> KTmBh0H+9+PhoXeH6leue2v0Y5Xb1lD8HU6WmrssWYrd9rXgc3s26kzsUrATJCKc >> bj7M6uiKIzUDFwaj13U6bPbldVeJWd+DhWCR2k4Y3rJIfj5bdp55ApDZnF/14v91 >> i/w0hnqnuiT/KEDuW+E7jsKwXq/ILKIDZqonyFlF7KuGUT3HGi9WFkc7AnkaOi5U >> qgsuFEYjxkUqAbTAO7nwa9YtGX0qKHhH5SkzWpITTabu48c5FKqG0vAVpGce8z3K >> AyqtwNXAz9nIL6ZwJNg9L8tLhLBQS1lePeSiN7pog4jsKD51VaT7Y1iMysA2OqRs >> Nw70wF7TYh4EikCHsECPQBEI/a+cJEQSro0I4kHGGttVcEdrDqM4xdfaFYN+Ag1b >> vHEf3Zzv/x820fjbfN1eoySj/qFU7Mcuw8Rik//J63HKZbmGdbaYsdrHasgaDIqk >> TgSsgGCf6d5FX9TFFNvd >> =u3Pi >> -----END PGP SIGNATURE----- >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From michaelc@idssoftware.com Mon Feb 18 08:17:01 2013 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 789A021F8C11 for ; Mon, 18 Feb 2013 08:17:01 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3J96Qf-so6D for ; Mon, 18 Feb 2013 08:17:00 -0800 (PST) Received: from p3plwbeout03-04.prod.phx3.secureserver.net (p3plsmtp03-04-2.prod.phx3.secureserver.net [72.167.218.216]) by ietfa.amsl.com (Postfix) with ESMTP id 6889621F8C00 for ; Mon, 18 Feb 2013 08:16:52 -0800 (PST) Received: from localhost ([72.167.218.245]) by p3plwbeout03-04.prod.phx3.secureserver.net with bizsmtp id 1sGq1l0015JG3DC01sGqqP; Mon, 18 Feb 2013 09:16:50 -0700 X-SID: 1sGq1l0015JG3DC01 Received: (qmail 30093 invoked by uid 99); 18 Feb 2013 16:16:50 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 67.58.151.228 User-Agent: Workspace Webmail 5.6.32 Message-Id: <20130218091649.59ca11a9ba9389561a029f06442e67fa.0af47b212b.wbe@email03.secureserver.net> From: "Michael Chen" To: "Cullen Jennings \(fluffy\)" , "p2psip@ietf.org List" Date: Mon, 18 Feb 2013 09:16:49 -0700 Mime-Version: 1.0 Cc: Dean Willis Subject: Re: [P2PSIP] New version of reload base 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, 18 Feb 2013 16:17:01 -0000 Hi,=0A=0AI found these two issues I raised long ago were neither discussed = nor=0Aaddressed:=0A=0A Base draft 9.5 bullet 2 needs to be revised=0A h= ttp://www.ietf.org/mail-archive/web/p2psip/current/msg06065.html=0A=0A Que= stion about base draft 9.7.4.4 Detecting partitioning=0A http://www.ietf= .org/mail-archive/web/p2psip/current/msg06064.html=0A=0AThe topic number ha= s since been changed to 10.5 and 10.7.4.4=0Arespectively.=0A=0AThanks=0A=0A= --Michael=0A=0A> -------- Original Message --------=0A> Subject: [P2PSIP] N= ew version of reload base=0A> From: "Cullen Jennings (fluffy)" =0A> Date: Sat, January 19, 2013 11:04 am=0A> To: "p2psip@ietf.org Li= st" =0A> Cc: Dean Willis =0A> = =0A> =0A> There is a new version of reload base at=0A> =0A> http://www.ietf= .org/id/draft-ietf-p2psip-base-24.txt=0A> =0A> Dean is shepherding this thr= ough IESG and might have more to add but I think this addresses all the IES= G review. I think the only technical changes have all been discussed in the= WG meetings. Please do have a look at the diff from what was in the IETF L= C and let us know if there are any concerns with this version. =0A> =0A> I = would like to say a special thanks to Marc and Dean who really helped work = thought the many comments. =0A> =0A> Cullen=0A> =0A> ______________________= _________________________=0A> P2PSIP mailing list=0A> P2PSIP@ietf.org=0A> h= ttps://www.ietf.org/mailman/listinfo/p2psip From petithug@acm.org Mon Feb 18 10:04:28 2013 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 AD9B321F8AA3 for ; Mon, 18 Feb 2013 10:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asOFLEmxqU9J for ; Mon, 18 Feb 2013 10:04:28 -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 A3F0421F8A99 for ; Mon, 18 Feb 2013 10:04:27 -0800 (PST) Received: from [IPv6:2601:9:4b80:32:9df5:1f24:fc1a:c007] (unknown [IPv6:2601:9:4b80:32:9df5:1f24:fc1a:c007]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id B26BD20139; Mon, 18 Feb 2013 18:04:25 +0000 (UTC) Message-ID: <51226D2A.60000@acm.org> Date: Mon, 18 Feb 2013 10:04:26 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Michael Chen References: <20130218091649.59ca11a9ba9389561a029f06442e67fa.0af47b212b.wbe@email03.secureserver.net> In-Reply-To: <20130218091649.59ca11a9ba9389561a029f06442e67fa.0af47b212b.wbe@email03.secureserver.net> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Cullen Jennings \(fluffy\)" , "p2psip@ietf.org List" , Dean Willis Subject: Re: [P2PSIP] New version of reload base 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, 18 Feb 2013 18:04:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Michael, On 02/18/2013 08:16 AM, Michael Chen wrote: > Hi, > > I found these two issues I raised long ago were neither discussed nor > addressed: > > Base draft 9.5 bullet 2 needs to be revised > http://www.ietf.org/mail-archive/web/p2psip/current/msg06065.html Somehow I missed it in your email from 7/24/2012 and did not present it in Vancouver. Sorry for that. I'll prepare a patchset later today so Cullen can review it. > > Question about base draft 9.7.4.4 Detecting partitioning > http://www.ietf.org/mail-archive/web/p2psip/current/msg06064.html > This topic was discussed in Vancouver (slide 6): http://www.ietf.org/proceedings/84/slides/slides-84-p2psip-6.pdf The result of the discussion was "Slide 6: Cullen thinks there is nothing to update in the draft.That needs to be checked with Michael." https://www.ietf.org/proceedings/84/minutes/minutes-84-p2psip I sent you a direct email on 8/1/2012 so you can check the decisions. > The topic number has since been changed to 10.5 and 10.7.4.4 respectively. > > Thanks > > --Michael > >> -------- Original Message -------- Subject: [P2PSIP] New version of >> reload base From: "Cullen Jennings (fluffy)" Date: >> Sat, January 19, 2013 11:04 am To: "p2psip@ietf.org List" >> Cc: Dean Willis >> >> >> There is a new version of reload base at >> >> http://www.ietf.org/id/draft-ietf-p2psip-base-24.txt >> >> Dean is shepherding this through IESG and might have more to add but I >> think this addresses all the IESG review. I think the only technical >> changes have all been discussed in the WG meetings. Please do have a look >> at the diff from what was in the IETF LC and let us know if there are any >> concerns with this version. >> >> I would like to say a special thanks to Marc and Dean who really helped >> work thought the many comments. >> - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRIm0oAAoJECnERZXWan7EBTAP/3IZaUChglc/2A13L4rggrq1 7fUvb63b+U6zCS31CnfzCjQAEimmdZBhLI1LjupIxnbe4LlzeF8Ux+P2Hbm92bQJ ETa7rHDTRo5ymsCI4npYOur2t1nvM1euf+XbGAaOTuwxqJ/SkPbWgTF+z6ujtIxE GN8GfALa4RZ5LB4Anl7PVTukj96rWDyK0mu44O6cPfEIKxrO29avTJqZAvxBhFlJ A9qYbQ8yiA1Fh0v+jzLWkJcg0k491jrciYSy4P8TeIIAaciKshG9nsrG5Uva2pVD bO9QGWf/x+B2UTS54RdglcJIz4skWyCga0ZbJmM5yxOWi7yKKZF9z+UBrBPlTNvV XrST7546hzc41vuklqicnxKmr79w8Z/AK5ltdvhSBpvOvsxSQtAhp2pwf2sYteON K1/Bofzvlzf9s4v/fjJaxbLMv4hVyc9RlQUJ1qV8MU4JricGi6tFdpUxIVpXWGp2 F0xtZqDxcS2ORhOKXYT74T9SyvNlwam/usj5cRdVeRn4NIHQlvVn9tBIQNujXymy fiIHeu1aIcdcAV11OuORPhP79nTRZkg1ou99BeJOlAyv8W4cqS6RpUmgQzGc01Za Ia5cevxfrUJULTjju+MhVeik3VEZuq7xECkPDP7s4z1PubSp6FwflAgU9t66QKCx 1PxcpsnaKW/Rg95kemV7 =tZ/s -----END PGP SIGNATURE----- From jouni.maenpaa@ericsson.com Mon Feb 18 11:24:49 2013 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 AF3F921F87A5 for ; Mon, 18 Feb 2013 11:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9vpLU7LZw4R for ; Mon, 18 Feb 2013 11:24:45 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFCB21F876E for ; Mon, 18 Feb 2013 11:24:41 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-e0-51227ff87fd0 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E2.C7.32353.8FF72215; Mon, 18 Feb 2013 20:24:40 +0100 (CET) Received: from ESESSMB305.ericsson.se ([169.254.5.61]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 20:24:39 +0100 From: =?iso-8859-1?Q?Jouni_M=E4enp=E4=E4?= To: Joscha Schneider Thread-Topic: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06 Thread-Index: AQHODcoPi3CDhCh/50uVYPVOI0rEM5h/+rYQ Date: Mon, 18 Feb 2013 19:24:39 +0000 Message-ID: <27112A697EB8204D9943EAB8A0E16B7107545D2D@ESESSMB305.ericsson.se> References: <1359673911.4472.18.camel@acorde.it.uc3m.es> <511D341E.6060905@acm.org> <511E0E0B.6070103@hs-mannheim.de> <511E6779.80706@acm.org> <27112A697EB8204D9943EAB8A0E16B710753ED3E@ESESSMB305.ericsson.se> <51220EA9.2060200@hs-mannheim.de> In-Reply-To: <51220EA9.2060200@hs-mannheim.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje6PeqVAg8mLTCx+Td3CZvH/+SkW iyU3zzBaXFhzl8mBxePyFW+PQ8fvMHksWfKTyePL5c9sASxRXDYpqTmZZalF+nYJXBkvP3Qx F+wrqTi28CVLA+PVuC5GTg4JAROJ1+fesEPYYhIX7q1n62Lk4hASOMQo8fH1TnYIZzGjRHNX FxtIFZuAu8Thmz9ZQWwRAUOJ//MusoIUMQtMYJTY+XkbI0hCWMBVYlPfTKgiN4mnXd+ZIGwj iYP/V4PFWQRUJZZsfcUCYvMK+EqsffeaGWLbL0aJ7/8OgjVwCuhJdK1fDHYfI9B930+tAYsz C4hL3HoynwnibgGJJXvOM0PYohIvH/8DWsABZCtKLO+XgyjXk7gxdQobhK0tsWzha2aIvYIS J2c+YZnAKDYLydRZSFpmIWmZhaRlASPLKkb23MTMnPRy802MwGg6uOW3wQ7GTffFDjFKc7Ao ifOGu14IEBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cC4P1XyiRFjlceNwLULX6jPuLnKuf7Q vPVLzznPfabvfWDuHSOHD2FMC65NX7SoX0tYxHHFghnnl9xrUHt3qqN2xfLV/1o9vx2ct0/2 gmPtnIoFR+cIvg12MegIvhlqZKf6NWjSjV0z9+h9r/6QO+X5LZ6XkTHZrVLv+14/Nf7ScMDv C8/1Dda8gkosxRmJhlrMRcWJAPyC5Lh0AgAA Cc: "p2psip-chairs@tools.ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06 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, 18 Feb 2013 19:24:49 -0000 Hi Joscha, Thanks for the comments! Answering the first comment inline, need some more= time to check the second comment. Regards, Jouni -----Original Message----- From: Joscha Schneider [mailto:j.schneider@hs-mannheim.de]=20 Sent: 18. helmikuuta 2013 13:21 To: Jouni M=E4enp=E4=E4 Cc: Marc Petit-Huguenin; p2psip-chairs@tools.ietf.org; p2psip@ietf.org Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06 two comments inline regards joscha Am 16.02.2013 18:55, schrieb Jouni M=E4enp=E4=E4: > Hi Marc and Joscha, > > Thanks for the comments! Answers inline. > > Regards, > Jouni > > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On=20 > Behalf Of Joscha Schneider > Sent: 15. helmikuuta 2013 12:30 > To: Marc Petit-Huguenin > Cc: p2psip-chairs@tools.ietf.org; p2psip@ietf.org > Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06 > > I can confirm that the draft might need some improvements to make the imp= lementation easier. > I did a basic implementation but I'm not quite sure that I handled everyt= hing correct. > > [Jouni]: I'll try to improve the text in the next version of the draft. > > Especially the definition of the successor seams a bit unclear for me. A = simple example: > Only a single service provider with Node-ID 2 provides a service. Node wi= th ID 7 performs a lookup... > How should it be handled? I implemented it as follows: in case a lookup r= eveals only a single service provider it must be the direct successor. > > [Jouni]: What would happen in this case is that the upward walk of the se= rvice lookup reaches the root level because no successor can be found from = the lower levels in the tree. In my implementation, when this happens, I'm = selecting either the closest successor at the root level or, if there is no= successor, select one of the available service providers randomly (or pick= the only service provider if there is only one like you are doing in your = implementation). Anyway, I'll add text to clarify this to the next version = of the draft. > > Further notice, due to the periodically triggered re-registration the con= sistency of the ReDiR tree can not be always ensured. Theoretically this ca= n lead to failed lookup processes. > This derives from the fact that each new service provider registration mi= ght affect the re-registration of the former service providers which again = might affect the re-registrations of other service providers. > > [Jouni]: Not sure about this. I could be wrong, but why would the re-regi= stration of a service provider affect the re-registrations of other service= providers? I mean, when a service provider X re-registers or registers, it= simply stores its own record at different levels in the ReDiR tree as a pa= rt of the upward and downward walks. This re-registration process does not = influence the (re-)registrations of other service providers. Or did I under= stand your comment incorrectly? > I'll try to make an example: Two service provider are even in Level 4 in = the same interval. First service prover (X) stops registration downwalk at = level 2 because it's the only one. Second service provider (Y) goes down to= level 3 to finish its downwalk. X starts re-registration. Now the downwalk= need to go down to level 4 as level 2 and 3 are shared Y.=20 Now Y starts re-registration. Goes down to level 5 as level 3 and 4 are sha= red now. X re-registers again. goes down to level 5. Finally both service p= roviders have found the leaves and the tree is consistent. In between, serv= ice lookups might go down to a level at which no service provider informati= on is stored (yet). [Jouni]: Ok, I think you're right, that can happen. How often do you think = it would occur? The default branching factor of the ReDiR tree is 10. I gue= ss that the Node-IDs of the service providers that are (re-)registering at = the same time would need to be very close to each other in order for the se= rvice providers to end up into the same interval at two levels of the tree = (with the default branching factor of 10, level 2 has 1000 intervals, level= 3 10000, level 5, 100000, etc.).=20 I guess there might also be other similar situations, though, such as when = a RedirServiceProvider record expires within a given interval at some level= just before a service lookup for which that record is the closest successo= r reaches that level and interval, and before the re-registration stores a = new RedirServiceProvider record in that interval. This situation should be = quite rare, though. One potential strategy for dealing with the situations above is to fail the= service lookup procedure and retry it - if the temporary inconsistency has= been fixed by a re-registration between the old and new service lookup, th= e new service lookup will succeed. Another strategy that we are using in our ReDiR implementation is that we a= re temporarily (for the duration of a service lookup) caching/storing the R= edirServiceProvider entries fetched during that specific service lookup at = the peer that is carrying out the service lookup. Thus, if for whatever rea= son the service lookup would happen to go down to a level at which no servi= ce provider information is stored, the peer that is carrying out the search= can go through the locally cached RedirServiceProvider entries to find the= closest successor of the search key from among the cached entries. This st= rategy would allow one to recover from the scenarios described above. Do yo= u think it would help if we described this strategy in the draft? Do you ha= ve some other potential solutions in mind? > more inline... > > Regards > Joscha > > Am 14.02.2013 19:59, schrieb Marc Petit-Huguenin: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> I did a review of this draft, and I have some concerns. >> >> First of all some parts of the I-D are verbatim copy of the text in=20 >> the original paper. Is that OK? > [Jouni]: I guess the main reason for that is that ReDiR is pretty complex= to describe. So we took a safe bet and tried to reuse some of the text (th= e algorithm description) from the paper. But since there are also comments = that the text is difficult to follow, I'll make an attempt to reformulate i= t in the next version of the draft. > >> Probably because some of the text comes from a research paper, it was=20 >> very difficult to understand fro me, and I am not sure that I yet=20 >> understood everything - I still have to write an implementation of=20 >> this, and unfortunately to not have enough time to do so before the=20 >> end of the WGLC. On the other hand, I know that RELOAD.NET has an=20 >> implementation, so I guess it is implementable. > [Jouni]: I have also implemented the draft and think I got the implementa= tion right. So if you have any further questions about things that are uncl= ear, let me know and I can check the code to see how that specific thing wa= s implemented (and clarify the same issue in the draft if necessary). > >> But I was not able to make sense of something in the example in section = 7: >> Why is the 4th peer added to level 0? Bullet 4 in Section 4.3 says=20 >> "Node N MUST continue [repeating steps 2 and 3] until it reaches=20 >> either the root or a level a which n.id is not the lowest or highest=20 >> Node-ID in the interval I(level, n.id)". In this case 4 is not the=20 >> lowest or highest Node-ID in the interval (lowest is 2, highest is 7), s= o why is it added to this node? > I think the example is simply following the rules. At level 1 peer 4 is t= he lowest. So go up and fetch and store. > > [Jouni]: That's correct. Node 4 starts from the starting level, which is = level 2. It stores its record on level 2. Since Node-ID 4 is the lowest (on= ly) Node-ID in its interval, the upward walk continues to level 1. At level= 1, Node-ID 4 is also the lowest Node-ID in its interval and thus the upwar= d walk continues all the way to the root level. Node 4 stores its record in= that level. Since Node-ID is neither the lowest nor highest Node-ID, the u= pward walk stops at level 0 (although it would stop anyway at level 0 since= it is of course not possible to go further up in the tree). > >> But if i reveal correct that fact caused a few headaches for me too.=20 >> Why does the store does not depend on the information that was=20 >> fetched before? > [Jouni]: That is how it goes - if there has been a decision that the upwa= rd walk shall continue to the next level, a record is stored at that level = 'automatically', regardless of the contents of the tree node. The contents = of the tree node (i.e., whether n.id is sandwiched or not) will influence t= he decision on whether to stop the upward walk or continue it. The idea in = the upward and downward walks is to ensure that the tree is populated dense= ly enough so that service lookups will finish without requiring too many Fe= tch operations. But does this make sense? If I recall correct the registration information = of node 3 and 4 in Level 0 in the draft example will never be used in looku= p processes. As far as I understood at most two service provider entries ar= e needed (lowest and highest) in each tree node to make the algorithm work.= All sandwiched service provider information is not needed. Most of them wi= ll also expire and not be renewed in the re-registration process in case ot= her service providers have registered in the meantime. I think this 'automa= tic' store process makes the tree just a bit more wired and the algorithm m= ode difficult to understand. Or do you see a resonable reason for this beha= viour that I don't see. >> BTW a similar example for the service lookup would be useful. > [Jouni]: Ok, I'll add an example in the next version of the draft. > >> More comments: >> >> - - Section 3, 3 paragraph: "contains a list of Node-IDs" >> >> Technically each node is a Dictionary whose keys are Node-IDs and=20 >> values contain a list of Destinations. > [Jouni]: Ok, I'll modify this in the next version of the draft. > >> - - Section 4.1 >> >> s/detination_list/destination_list/ > [Jouni]: Ok, will change this one also in the next version of the draft. > >> - - Section 4.1 >> >> namespace is an opaque value but the charset and conversion between=20 >> character string and byte string for the namespace is not defined. > confirm > > [Jouni]: Would specifying that it is an opaque UTF-8 encoded string be en= ough? > >> - - Section 8 >> >> The document says that the redir namespace is added to the=20 >> element, meaning that all nodes MUST understand=20 >> ReDIR, but isn't that against one of the goal of ReDIR, which is that=20 >> by using standard Store/Fetch, only a node wishing to store or fetch=20 >> has to implement ReDIR? > I think at least the RedirServiceProvider Data Structure must be supporte= d. And also the Access Control Rules. > But the algorithm might not be mandatory needed. > > The RedirServiceProvider Data Structure does not need to be understood by= the peer storing it, but you are right about the Access Control rule. My = own draft about storing the Access Control rule solves this problem but, ev= en if it is accepted as WG item, we do not want to add a normative referenc= e to it. > > So I withdraw what I said - redir needs to be a a mandatory extension at = least until new access control policies no longer have to be hardcoded. > > [Jouni]: Ok, so if I understood correctly, it is ok to leave the text as = it is. > >> - - Section 10.3 >> >> I think that we need a bit more explanation on what the turn-server=20 >> and voice-mail service providers are. > [Jouni]: I could remove the voice-mail service provider from the next ver= sion of the draft as I don't have a good explanation for that. For turn-ser= ver I will add some text. > >> On 01/31/2013 03:11 PM, Carlos Jes=FAs Bernardos Cano wrote: >>> Hi, >>> >>> Hereby we are issuing a WGLC for draft-ietf-p2psip-service-discovery-06= . >>> >>> The WGLC will be open till the 15th of February. We kindly ask the=20 >>> WG to review the document and provide comments. >>> >>> If you have no comments and think the document is ready to be=20 >>> submitted to IESG, please do send a note stating that to the WG ML. >>> >>> Additional information about the document is below: >>> >>> Title : Service Discovery Usage for REsource LOcation And >>> Discovery (RELOAD) Author(s) : Jouni Maenpaa Gonzalo Camarillo >>> Filename : draft-ietf-p2psip-service-discovery-06.txt Pages : 15 >>> Date : 2012-10-01 >>> >>> Abstract: REsource LOcation and Discovery (RELOAD) does not define a=20 >>> 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=20 >>> to RELOAD overlays to provide a generic service discovery mechanism. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-p2psip-service-discovery >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-p2psip-service-discovery-06 >>> >>> >> - -- >> Marc Petit-Huguenin >> Email: marc@petit-huguenin.org >> Blog: http://blog.marc.petit-huguenin.org >> Profile: http://www.linkedin.com/in/petithug >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.12 (GNU/Linux) >> >> iQIcBAEBCAAGBQJRHTQcAAoJECnERZXWan7EmukP/A1P3JutcxuDooxYPFjty3ua >> lhhbiJTd7PLEs9jsaG9hKHjuDi2qu0BNp9Ss+ki+ybtXBNKaJwkrqNqwB3R+dXpx >> Q7zamHvCUJekNmybG2kpc5IUP2MxhDzYp3paocOdF/vdWYE+re3u9WqBN1JNuCwk >> E6GmfEIgw28p5wKldHPCGQrRYx6QnszsQc7F3+siFrsSEzRww7ATpUXjMCVxUfWU >> KTmBh0H+9+PhoXeH6leue2v0Y5Xb1lD8HU6WmrssWYrd9rXgc3s26kzsUrATJCKc >> bj7M6uiKIzUDFwaj13U6bPbldVeJWd+DhWCR2k4Y3rJIfj5bdp55ApDZnF/14v91 >> i/w0hnqnuiT/KEDuW+E7jsKwXq/ILKIDZqonyFlF7KuGUT3HGi9WFkc7AnkaOi5U >> qgsuFEYjxkUqAbTAO7nwa9YtGX0qKHhH5SkzWpITTabu48c5FKqG0vAVpGce8z3K >> AyqtwNXAz9nIL6ZwJNg9L8tLhLBQS1lePeSiN7pog4jsKD51VaT7Y1iMysA2OqRs >> Nw70wF7TYh4EikCHsECPQBEI/a+cJEQSro0I4kHGGttVcEdrDqM4xdfaFYN+Ag1b >> vHEf3Zzv/x820fjbfN1eoySj/qFU7Mcuw8Rik//J63HKZbmGdbaYsdrHasgaDIqk >> TgSsgGCf6d5FX9TFFNvd >> =3Du3Pi >> -----END PGP SIGNATURE----- >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From petithug@acm.org Mon Feb 18 12:23:41 2013 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 E8AFB21F8C56 for ; Mon, 18 Feb 2013 12:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxXib2pDFmPG for ; Mon, 18 Feb 2013 12:23:39 -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 BDCA621F8C4C for ; Mon, 18 Feb 2013 12:23:38 -0800 (PST) Received: from [IPv6:2601:9:4b80:32:9df5:1f24:fc1a:c007] (unknown [IPv6:2601:9:4b80:32:9df5:1f24:fc1a:c007]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 39CE720139; Mon, 18 Feb 2013 20:23:37 +0000 (UTC) Message-ID: <51228DCA.40606@acm.org> Date: Mon, 18 Feb 2013 12:23:38 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Michael Chen References: <20130218091649.59ca11a9ba9389561a029f06442e67fa.0af47b212b.wbe@email03.secureserver.net> <51226D2A.60000@acm.org> In-Reply-To: <51226D2A.60000@acm.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Cullen Jennings \(fluffy\)" , "p2psip@ietf.org List" , Dean Willis Subject: Re: [P2PSIP] New version of reload base 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, 18 Feb 2013 20:23:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/18/2013 10:04 AM, Marc Petit-Huguenin wrote: > Hi Michael, > > On 02/18/2013 08:16 AM, Michael Chen wrote: >> Hi, > >> I found these two issues I raised long ago were neither discussed nor >> addressed: > >> Base draft 9.5 bullet 2 needs to be revised >> http://www.ietf.org/mail-archive/web/p2psip/current/msg06065.html > > Somehow I missed it in your email from 7/24/2012 and did not present it in > Vancouver. Sorry for that. > > I'll prepare a patchset later today so Cullen can review it. > After checking on my laptop, I found that that was in slide 5 in the presentation, that is still present in the libreoffice file but somehow disappeared when I generated the pdf file for the presentation. That explains the gap in the slide numbers... - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRIo3JAAoJECnERZXWan7EgdkP/20r9xvj8HfML/vEq175wJzg Pq6JcKLBOGkJmabUyKp+0E/V/83mBuSTdd6KSNe6tfy29SWtyYwCzxgGa9vFN3/9 VeYTGPRKq7VuHAz9btVBfvJ+85dchgzXN9lnjGit8+68pvrXybFmWFmbH2wEgXOU K/EgVMc/O2bsSDQP5ufN0H1CiNt7fwHBf4uQKSOKsAYXsWSDMCnzST5I5jGDCRDn +2vClcucbQrLBMO9MUcNiswjPseNk7S+3gg9a09gI/wCsCNqXzB4SsG/aiiyXU9V R5rK//XnLqk+kIAcXq0LLyDOSYMNNGaGtXdbr+rMq7dla/+h0XuW/lk+bVKQjXEd bxH4ZxUIfpTh/DcvhNNRxJWJoglY9z7hR5TJLa0d30hgVtikIKin5oUFa6v4OW5p Oa3dg7YuJVRRFHFBQIBxOFoPXKkKMb1LZB2NIbtHHwOQWTZmjf+dv9AuQjoQluKf jT+REJ2I9bMP0YfKR97BYwahhuMHUS/hS7sMrnbkK198YKciH10xbq/Scr8MLOnQ 6JOZLbicwJh9IEhUpURO8xNMJXNokvmfqNZkohOoW0wVe7qjdRwofPIkg8/iJXQm o7DG/XCE/cuuSUAhODyyMgXe8SgAlK0JHB8pOhGjn/inWIQ4jViOHgTBFTkG1Epo cA7CC6GlM+CwriRWflgt =WIHh -----END PGP SIGNATURE----- From roland.bless@kit.edu Tue Feb 19 18:32:28 2013 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 2612621F886B; Tue, 19 Feb 2013 18:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.268 X-Spam-Level: X-Spam-Status: No, score=-5.268 tagged_above=-999 required=5 tests=[AWL=-0.831, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xd7q9Axk8CZY; Tue, 19 Feb 2013 18:32:26 -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 41DAD21F87BA; Tue, 19 Feb 2013 18:32:25 -0800 (PST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1U7zTg-0003cs-Pm; Wed, 20 Feb 2013 03:32:22 +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 id 1U7zTg-00012p-1e; Wed, 20 Feb 2013 03:32:12 +0100 Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 474AAA80682; Wed, 20 Feb 2013 03:32:11 +0100 (CET) Message-ID: <512435A9.1090507@kit.edu> Date: Wed, 20 Feb 2013 03:32:09 +0100 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: IETF Discussion References: <20130206042108.14054.8941.idtracker@ietfa.amsl.com> In-Reply-To: <20130206042108.14054.8941.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1361327543.009862000 Cc: p2psip@ietf.org, "iesg@ietf.org" Subject: Re: [P2PSIP] Last Call: (REsource LOcation And Discovery (RELOAD) Base Protocol) to Proposed Standard 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, 20 Feb 2013 02:32:28 -0000 Hi, On 06.02.2013 05:21, The IESG wrote: > The IESG has received a request from the Peer-to-Peer Session Initiation > Protocol WG (p2psip) to consider the following document: > - 'REsource LOcation And Discovery (RELOAD) Base Protocol' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-02-19. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. Sorry for the late comments, but I re-read the whole draft which took some time. There are still some clarifications necessary as well as some inconsistencies left. Unfortunately, my comments from June, 19th were not addressed yet. https://www.ietf.org/mail-archive/web/p2psip/current/msg06229.html Polina Goltsman also found many issues listed below while working on an implementation. The list is long, but the good news is that it's mainly clarifications that are missing. Major issues: 1) sec. 6.3.2: length field in Forwarding Header covers what exactly? it is not really clear whether the length field counts the whole message or in case of fragmentation only the fragment size. When reading Sec 6.7 is seems that the former is meant, but the definition could and should be clearer. Similarly, sec. 6.7 should be clear about this, e.g., describing that all Forwarding Headers are identical for fragments of the same message with exception of the fragment field. 2) sec. 7.4.1.1: replica number handling is unclear it is unclear how replica numbers are incremented (e.g., per peer) and what receiving peers should actually do with this number. Is it important to store the value or would a boolean be sufficient so that the peer knows that it's a replica? 3) sec. 6.5.2: transport protocol set for AppAttach Applications may require use of other transport protocols than those defined in OverlayLinkType (TLS/DTLS, what about plain UDP, SCTP, DCCP, etc.), but currently, this seems to be not possible (do the considerations of sec. 6.5.1.6 apply here?). 4) sec. 6.3.4: How can a different signature algorithm be used if not all implementations support it? There is no possibility to provide the feedback, that the signature algorithm is not acceptable at a particular node. 5) sec. 10.5: handling of parallel JOIN requests and use of peer_ready it is not clear what should happen if two JNs try to join at the same time at the same AP (can they be processed in parallel or should they be processed in sequence). Furthermore, when MUST/SHOULD a JN send peer_ready Update - in step 9? Minor issues: citations are put first, followed by comments starting with # sec. 1.1 ======== old: storage rather than for bulk storage of large objects. Records are stored under numeric addresses which occupy the same space as node new: storage rather than for bulk storage of large objects. Records are stored under numeric addresses, called Resource-IDs, which occupy the same space as node # Resource-IDs are used in 1.2.2 but not introduced sec. 1.2 ======== Message Transport: Handles end-to-end reliability, manages request ... # What are the interactions with Forwarding and Link Management and the Topology Plugin old: Forwarding and Link Management Layer: Stores and implements the routing table by providing packet forwarding services between nodes. It also handles establishing new links between nodes, including setting up connections across NATs using ICE. # It may be confusing to say "routing table" here, since this # is usually associated with the topology plugin. So IMHO # it is the Connection Table, not the routing table. # Furthermore, I propose the following change: old: including setting up connections across NATs using ICE. new: including setting up connections for overlay links across NATs using ICE. old: directly between nodes. TLS [RFC5246] and DTLS [RFC6347] are the currently defined "link layer" protocols used by RELOAD for hop- new: currently defined "overlay link layer" protocols used by RELOAD for hop- # avoids confusion with the classic ISO/OSI link layer (layer 2) old: In addition to the above components, nodes communicate with a central new: In addition to the above components, nodes may communicate with a central # while it may be the default case, it is not strictly required sec. 1.3 ======== old: RELOAD also provides an optional shared secret based admission control feature using shared secrets and TLS-PSK. In order to form a new: RELOAD also provides an optional shared secret based admission control feature using shared secrets and TLS-PSK/TLS-SRP. In order to # TLS-SRP should be mentioned here, too sec. 2 ====== old: Terms used in this document are defined inline when used and are also new: Terms in this document are defined inline when used and are also # avoid double "used" old: Bootstrap Node: A network node used by Joining Nodes to help locate the Admitting Peer. new: Bootstrap Node: A network node used by Joining Nodes to help accessing the overlay by forwarding messages to peers. # The bootstrap node does not locate the Admitting Peer, but the JN locates # the AP by routing a message to its own Resource-ID old: Connection Table: The set of nodes to which a node is directly connected, which include nodes that are not yet available for routing. new: Connection Table: Contains connection information for the set of nodes to which a node is directly connected, which include nodes that are not yet available for routing. # it is a data structure ... Node-ID: A value of fixed but configurable length that uniquely identifies a node. Node-IDs of all 0s and all 1s are reserved and are invalid Node-IDs. A value of zero is not used in the wire protocol but can be used to indicate an invalid node in implementations and APIs. The Node-ID of all 1s is used on the wire protocol as a wildcard. # what means "invalid" exactly? A wildcard can be used at least on # the wire so it is not invalid being used as destination Node-IDs. # So the above definition is slightly contradictory. old: Responsible Peer: The peer that is responsible for a specific resource, as defined by the plugin algorithm. new: Responsible Peer: The peer that is responsible for a specific resource, as defined by the topology plugin algorithm. old: Usage: An usage is the definition of a set of data structures (data Kinds) that an application wants to store in the overlay. An usage may also define a set of network protocols (application IDs) new: Usage: A usage is the definition of a set of data structures (data Kinds) that an application wants to store in the overlay. A usage may also define a set of network protocols (application IDs) # Typo: 2x An usage -> A usage sec. 3.1 ======== old: o To determine its position in the overlay topology (if the overlay is structured; topology plugins do not need to be structured). new: o To determine its position in the overlay topology (if the overlay is structured; overlays do not need to be structured). # a structured topology plugin is not the same as a structured overlay o To determine the set of resources for which the node is responsible. # this isn't necessarily true for unstructured overlays? old: The general principle here is that the security mechanisms (TLS at new: The general principle here is that the security mechanisms ((D)TLS at sec. 3.2 ======== entity. From the perspective of a peer, a client is a node that has connected to the overlay, but has not yet taken steps to insert # an additional reference to the Connection Table would be nice sec. 3.2.1 ========== clients that choose this option need to process Update messages # Update messages are not introduced yet, so a forward reference to # section 6.4.2.3 would be helpful performing an Attach. A client wishing to connect using this mechanism with a certificate with multiple Node-IDs can use a Ping (Section 6.5.3) to probe the Node-ID of the node to which it is connected before doing the Attach (Section 6.5.1). # At this point it is not really clear why this step is necessary. # Certificates with multiple Node-IDs were not explained yet. # Furthermore, the reference to Section 6.5.1 should be moved # to the previous sentence. sec. 3.3 ======== old: This section will discuss the capabilities of RELOAD's routing layer, new: This section discusses the capabilities of RELOAD's routing layer, old: Resource-based routing: RELOAD supports routing messages based solely on the name of the resource. Such messages are delivered new: Resource-based routing: RELOAD supports routing messages based solely on the name of the resource or Resource-ID. Such messages old: Clients: RELOAD supports requests from and to clients that do not participate in overlay routing, located via either of the mechanisms described above. new: Clients: RELOAD supports requests from and to clients that do not participate in overlay routing. # the addition is not really necessary and may be confusing old: Destination Lists: While in principle it is possible to just inject a message into the overlay with a single Node-ID as the new: Destination Lists: While in principle it is possible to just inject a message into the overlay with a single Node-ID or a single Resource-ID as the # Resource-ID is also a possible destination old: The basic routing mechanism used by RELOAD is Symmetric Recursive. new: The basic routing mode used by RELOAD is Symmetric Recursive Routing (SRR, cf. Section 6.2) # I would prefer to use the term "mode" (as on p. 28) and it should be # consistent with the text in section 6.2 old: opaque ID X1 which maps internally to [A, B] (perhaps by being an encryption of [A, B] and forwards to Z with only X1 as the via list. new: opaque ID X1 which maps internally to [A, B] (perhaps by being an encryption of [A, B]) and forwards to Z with only X1 as the via list. # simple typo old: RELOAD also supports a basic Iterative "routing" mode (where the new: RELOAD also supports a basic Iterative routing mode (where the old: Iterative "routing" is implemented using the RouteQuery method, which new: Iterative routing is implemented using the RouteQuery method, which old: requests this behavior. Note that iterative "routing" is selected new: requests this behavior. Note that Iterative routing is selected sec. 3.4 ======== pairs. The result is a connection between A and B. At this point, A and B MAY send messages directly between themselves without going through other overlay peers. In other words, A and B are on each other's connection tables. They MAY then execute an Update process, # MAY is RFC 2119 terminology, which is defined in section 5 # Besides Update process a Join process is also possible. order to support this case, some small number of "bootstrap nodes" typically need to be publicly accessible so that new peers can # what "publicly accessible" means exactly is not defined # typically need to be publicly accessible (i.e., not behind a NAT or # firewall) ... old: The second case is when a client connects to a peer at an arbitrary IP address, rather than to its responsible peer, as described in the new: The second case is when a client connects to a peer at an arbitrary node-ID, rather than to its responsible peer, as described in the # since responsible peer may depend on the overlay topology, node-ID # seems to be a better fit here sec. 3.5.2 ========== old: When a new peer wishes to join the Overlay Instance, it will need a Node-ID that it is allowed to use and a set of credentials which new: When a new peer wishes to join the Overlay Instance, it needs a Node-ID that it is allowed to use and a set of credentials which # not really sure about this change as non-native speaker match that Node-ID. When an enrollment server is used, the Node-ID used is the Node-ID found in the certificate received from the # the mode with self-signed certificates is missing and should be # mentioned also here "bootstrap node". Because this is the first connection the peer makes, these nodes will need public IP addresses so that they can be # may also work if the bootstrap node is directly reachable, e.g., # in the same domain # in this paragraph and the following paragraph "Once a peer" # is used three times past adjacencies which have public IP address and attempt to use them # inconsistent use of term "adjacencies"/adjacent within the document # different meanings as follows: # 1.) all directly connected nodes (i.e., all nodes in the Connection Table), e.g., sec. 3.5.2 and 6.4.2.3 # 2.) all peers in the routing table # 3.) adjacent according to the overlay topology, e.g. sec. 6.4.2.1 sec. 4 ====== limits on size, on the values which may be stored. For many Kinds, the set may be restricted to a single value; some sets may be allowed # what set? sec. 4.1.2. =========== old: responsibility if the responsible peer fail [Chord]. new: responsibility if the responsible peer fails [Chord]. sec. 6 ====== old: messages. We then describe the symmetric recursive routing model, which is RELOAD's default routing algorithm. We then define the new: messages. We then describe the symmetric recursive routing mode, which is RELOAD's default routing mode. We then define the # IMHO the term mode fits best, the routing algorithm is defined # within the topology plugin sec. 6.1. ========= old: peer SHOULD generate an appropriate error but local policy can new: peer SHOULD generate an appropriate error message but local policy can Once the peer has determined that the message is correctly formatted # what does "correctly formatted" mean exactly? sec. 6.1.1. =========== this node so it MUST verify the signature as described in Section 7.1 and MUST pass it up to the upper layers. "Upper layers" is used here to mean the components above the "Overlay Link Service Boundary" line in the figure in Section 1.2. # this is somewhat confusing. The text describes what the # Forwarding and link management component does, but what # other components are meant here? state, e.g., by unpacking any opaque IDS. # I think any is incorrect, since other IDs are # not inserted by this node and so it cannot "unpack" those, # but only its own opaque IDs sec. 6.1.2. =========== the first entry on the destination list is in the peer's connection table, then it MUST forward the message to that peer directly. # This is probably motivated by clients. A hint to this fact # may help. old: destination list, it would detect that I is a opaque ID, recover the new: destination list, it would detect that I is an opaque ID, recover the # Typo fix old: called List Compression. Possibilities for a opaque ID include a new: called List Compression. Possibilities for an opaque ID include a # Typo fix An intermediate node receiving a request from another node MUST return a response to this request with a destination list equal to the concatenation of the Node-ID of the node that sent the request with the via list in the request. The intermediate node normally # 1.) unclear why an _intermediate_ peer should return a response # (if it is not the destination node), # 2.) the via list must be reversed before concatenating the Node-ID # so: old: with the via list in the request. The intermediate node normally new: with the reversed via list in the request. The intermediate node normally sec. 6.1.3. =========== old: compressed via list), the peer MUST replace that entry with the original via list that it replaced and then re-examine the new: compressed via list), the peer MUST replace that entry with the reversed original via list that it replaced and then re-examine the # the via list must be reversed for responses... sec. 6.2. ========= old: This Section defines RELOAD's Symmetric Recursive Routing (SRR) algorithm, which is the default algorithm used by nodes to route messages through the overlay. All implementations MUST implement this routing algorithm. An overlay MAY be configured to use alternative routing algorithms, and alternative routing algorithms MAY be selected on a per-message basis. I.e., a node in an overlay which supports SRR and some other routing algorithm called XXX might use SRR some of the time and XXX some of the time. new: This Section defines RELOAD's Symmetric Recursive Routing (SRR) mode, which is the default mode used by nodes to route messages through the overlay. All implementations MUST implement this routing mode. An overlay MAY be configured to use alternative routing modes, and alternative routing modes MAY be selected on a per-message basis. I.e., a node in an overlay which supports SRR and some other routing mode called XXX might use SRR some of the time and XXX some of the time. # better use mode for consistency (algorithm is contained in the # topology plugin sec. 6.2.1. =========== old: node MAY also construct a more complicated destination list for source routing. new: node MAY also construct a more complicated destination list for (loose) source routing. Once the message is constructed, the node sends the message to some adjacent peer. If the first entry on the destination list is directly connected, then the message MUST be routed down that connection. Otherwise, the topology plugin MUST be consulted to determine the appropriate next hop. # adjacent peer should be adjacent node, since it may be a client # directly connected means: a valid entry in the Connection Table # exists? this should be mentioned here... sec. 6.2.2. =========== # a hint that the same Transaction-ID as in the request MUST be used # could be added. sec. 6.3.1.1. ============= Unless a given structure that uses a select explicitly allows for unknown types in the select, any unknown type SHOULD be treated as an # How is that allowance specified in the specification? Is it by the comment # /* This structure can be extended */ sec. 6.3.2. =========== receive message with a TTL greater than the current value of initial-ttl (or the 100 default) MUST discard the message and send an "Error_TTL_Exceeded" error. # what if the initial-ttl is larger than 100 and the TTL is >100 but # < initial-ttl? The condition "or the 100 default" holds old: used to indicate the fragment offset; see Section 6.7. new: used to indicate the fragment offset in bytes; see Section 6.7. old: length: The count in bytes of the size of the message, including the header. new: length: The count in bytes of the size of the whole unfragmented message, including the header. # as already mentioned in the beginning this should be more precise destinations which the message should pass through. The destination list is constructed by the message originator. The # is it allowed that intermediate peers add destinations? if not, please # state so old: next. The list shrinks as the message traverses each listed peer. new: next. The list may shrink as the message traverses each listed peer. # it need not be always the case that the list shrinks with each traversed peer sec. 6.3.2.2. ============= old: structure with a DestinationType of opaque_id_type and a opaque_id new: structure with a DestinationType of opaque_id_type and an opaque_id # typo fix old: opaque A compressed list of Node-IDs and an eventual Resource-ID. Because this value was compressed by one of the peers, it is only meaningful to that peer and cannot be decoded by other peers. Thus, it is represented as an opaque string. resource The Resource-ID of the resource which is desired. This type MUST only appear in the final location of a destination list and MUST NOT appear in a via list. It is meaningless to try to route through a resource. new: resource The Resource-ID of the resource which is desired. This type MUST only appear in the final location of a destination list and MUST NOT appear in a via list. It is meaningless to try to route through a resource. opaque_id_type A compressed list of Node-IDs and an eventual Resource-ID. Because this value was compressed by one of the peers, it is only meaningful to that peer and cannot be decoded by other peers. Thus, it is represented as an opaque string. # 1.) match the order in the select # 2.) it must be opaque_id_type, not opaque sec. 6.3.2.3 ============ flags Three flags are defined FORWARD_CRITICAL(0x01), DESTINATION_CRITICAL(0x02), and RESPONSE_COPY(0x04). These flags MUST NOT be set in a response. If the FORWARD_CRITICAL flag is # What is the correct reaction if these flags are set in a response? # (returning an Error_Invalid_Message or ignore?) sec. 6.3.3.1 ============ old: A node processing a request MUST return its status in the message_code field. If the request was a success, then the message new: A node processing a request MUST return its status in the message_code field of a response. If the request was a success, then the message # clarification? Error_Request_Timeout: A response to the request has not been received in a suitable amount of time. The requesting node MAY resend the request at a later time. # not clear when this will ever be used. Which node should send # this error message? All RELOAD messages MUST be signed. Intermediate nodes do not verify signatures. Upon receipt (and fragment reassembly if needed) the destination node MUST verify the signature and the authorizing certificate. If the signature fails, the implementation SHOULD simply drop the message and MUST NOT process it. This check provides # What happens if none {0,0} is given? Then no Node-ID is present... sec. 6.4.2. =========== What happens if these messages (like Join, Leave) are accidentally sent to a Client? Do the send an Invalid Message back? A new peer (but one that already has credentials) uses the JoinReq message to join the overlay. The JoinReq is sent to the responsible peer depending on the routing mechanism described in the topology Is the destination address now the Resource-ID or the Node-ID of the "responsible peer"? Because joins may only be executed between nodes which are directly adjacent, receiving peers MUST verify that any JoinReq they receive # 1.) should be peers rather than nodes # 2.) directly adjacent means here: directly adjacent in the overlay # topology (could otherwise be misunderstood as being directly # connected) # 3.) what must happen if the verification fails? adjacent, receiving peers MUST verify that any LeaveReq they receive arrives from a transport channel that is bound to the Node-ID to be # what happens if that verification fails? old: assumed by the leaving peer.) This also prevents replay attacks new: assumed by the leaving peer. This also prevents replay attacks # Typo fix sec. 6.4.2.3 ============ the state change. In general, peers send Update messages to all their adjacencies whenever they detect a topology shift. # A hint to the Connection Table and Clients would clarify sec. 6.4.2.4. ============= old: X. A RouteQuery can also request that the receiving peer initiate an new: X. A RouteQuery can also request that the receiving peer initiates an old: One important use of the RouteQuery request is to support iterative routing. The sender selects one of the peers in its routing table # add reference to Section 3.3. sec. 6.4.2.4.1 ============== destination The destination which the requester is interested in. This may be any valid destination object, including a Node-ID, opaque ID, or Resource-ID. # Does opaque ID make sense here? sec. 6.5.1 ========== A node sends an Attach request when it wishes to establish a direct TCP or UDP connection to another node for the purpose of sending # TCP/TLS or DTLS? old: node A has Attached to node B, but not received any Updates from B, new: node A has attached to node B, but not received any Updates from B, # Typo channel but MUST NOT route messages through B to other peers via that channel. The process of Attaching is separate from the process of # Is that also true for clients? sec. 6.5.1.1 ============ old: } AttachReqAns; The values contained in AttachReqAns are: new: } AttachReq; The values contained in AttachReq are: old: A single AttachReqAns MUST NOT include both candidates whose new: A single AttachReq MUST NOT include both candidates whose # consistency! sec. 6.5.1.2. ============= old: 6.5.1.2. Response Definition new: 6.5.1.2. Response Definition The AttachAns message hast the same format as the AttachReq message. #s/AttachReqAns/AttachAns/ in the whole paragraph. sec. 6.5.1.3. ============= An agent follows the ICE specification as described in [RFC5245] with # agent was not defined in the RELOAD context so far. sec. 6.5.4.2. ============= old: o The configuration document is correctly digitally signed (see Section 11 for details on signatures. new: o The configuration document is correctly digitally signed (see Section 11 for details on signatures). old: one listed in the current configuration file). Details on kind- signer field in the configuration file is described in Section 11.1. new: one listed in the current configuration file). Details on kind- signer field in the configuration file are described in Section 11.1. # typos sec. 6.6.2 ========== old: Each connection has it own sequence number space. Initially the new: Each connection and direction has it own sequence number space. Initially the sec. 6.6.3.1 ============ A node MUST NOT have more than one unacknowledged message on the DTLS connection at a time. Note that because retransmissions of the same message are given new sequence numbers, there may be multiple unacknowledged sequence numbers in use. # Since retransmissions violate the first sentence, it may be better # to use: old: A node MUST NOT have more than one unacknowledged message on the DTLS connection at a time. Note that because retransmissions of the same new: A node MUST NOT have more than one unacknowledged message on the DTLS connection at a time, except for retransmissions. Note that because from the routing table. The link MAY be restored to the routing table if ACKs resume before the connection is closed, as described # this should read Connection Table twice? sec. 6.7 ========= and fragments it, each fragment has a full copy of the Forwarding # 1.) clarification would be good that the length field is covering the # total msg length and which field are different in the "copies" # (at least the fragment field) # 2.) what happens if overlapping fragments are received? Feedback on sections 7 and greater will follow in a separate mail later today. Regards, Roland From michaelc@idssoftware.com Wed Feb 20 05:53:35 2013 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 1D46121F84DA for ; Wed, 20 Feb 2013 05:53:35 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMA9YQDtMCV8 for ; Wed, 20 Feb 2013 05:53:34 -0800 (PST) Received: from p3plwbeout03-02.prod.phx3.secureserver.net (p3plsmtp03-02-2.prod.phx3.secureserver.net [72.167.218.214]) by ietfa.amsl.com (Postfix) with ESMTP id 5A52921F84D8 for ; Wed, 20 Feb 2013 05:53:34 -0800 (PST) Received: from localhost ([72.167.218.243]) by p3plwbeout03-02.prod.phx3.secureserver.net with bizsmtp id 2dtZ1l0015FgiYg01dtZTy; Wed, 20 Feb 2013 06:53:33 -0700 X-SID: 2dtZ1l0015FgiYg01 Received: (qmail 6879 invoked by uid 99); 20 Feb 2013 13:53:33 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 67.58.151.228 User-Agent: Workspace Webmail 5.6.32 Message-Id: <20130220065333.59ca11a9ba9389561a029f06442e67fa.6dcc5a80b8.wbe@email03.secureserver.net> From: "Michael Chen" To: "Marc Petit-Huguenin" Date: Wed, 20 Feb 2013 06:53:33 -0700 Mime-Version: 1.0 Cc: "Cullen Jennings \(fluffy\)" , "p2psip@ietf.org List" , Dean Willis Subject: Re: [P2PSIP] New version of reload base 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, 20 Feb 2013 13:53:35 -0000 Hi Marc and Cullen,=0A=0A> -------- Original Message --------=0A> Subject: = Re: [P2PSIP] New version of reload base=0A> From: Marc Petit-Huguenin =0A> Date: Mon, February 18, 2013 10:04 am=0A> To: Michael Che= n =0A> Cc: "Cullen Jennings (fluffy)" , "p2psip@ietf.org=0A> List" , Dean Willis =0A> =0A> =0A> -----BEGIN PGP SIGNED MESSAGE-----=0A> H= ash: SHA256=0A> =0A> Hi Michael,=0A> =0A> On 02/18/2013 08:16 AM, Michael C= hen wrote:=0A> > Hi,=0A> > =0A> > I found these two issues I raised long ag= o were neither discussed nor =0A> > addressed:=0A> > =0A> > Base draft 9.5 = bullet 2 needs to be revised =0A> > http://www.ietf.org/mail-archive/web/p2= psip/current/msg06065.html=0A> =0A> Somehow I missed it in your email from = 7/24/2012 and did not present it in=0A> Vancouver. Sorry for that.=0A> =0A= > I'll prepare a patchset later today so Cullen can review it.=0A> =0A> > = =0A> > Question about base draft 9.7.4.4 Detecting partitioning =0A> > http= ://www.ietf.org/mail-archive/web/p2psip/current/msg06064.html=0A> > =0A> = =0A> This topic was discussed in Vancouver (slide 6):=0A> =0A> http://www.i= etf.org/proceedings/84/slides/slides-84-p2psip-6.pdf=0A> =0A> The result of= the discussion was "Slide 6: Cullen thinks there is nothing to=0A> update = in the draft.That needs to be checked with Michael."=0A> =0A> https://www.i= etf.org/proceedings/84/minutes/minutes-84-p2psip=0A> =0A> I sent you a dire= ct email on 8/1/2012 so you can check the decisions.=0A=0AI can only find M= arc's August 5, 2012 post about this:=0A=0A> -------- Original Message ----= ----=0A> Subject: Re: [P2PSIP] Draft of meeting minutes uploaded=0A> From: = Marc Petit-Huguenin =0A> Date: Sun, August 05, 2012 10:31= am=0A> To: cjbc@it.uc3m.es=0A> Cc: P2PSIP WG =0A> =0A...= =0A> =0A> 3.4. "Slide 6: Cullen thinks there is nothing to update in the dr= aft. Marc=0A> agrees. That needs to be checked with Michale."=0A> =0A> I do= not remember agreeing with this (but I agreed that Michael should listen= =0A> to Cullen's explanations).=0A =0ACullen, do you recall your explanatio= ns? Sorry for not following up last=0Asummer.=0A =0AThanks=0A=0A--Michael= From roland.bless@kit.edu Wed Feb 20 08:36:09 2013 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 7DB3521F8816; Wed, 20 Feb 2013 08:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.918 X-Spam-Level: X-Spam-Status: No, score=-4.918 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qI5N0129hnut; Wed, 20 Feb 2013 08:36:06 -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 D038C21F87FB; Wed, 20 Feb 2013 08:36:04 -0800 (PST) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 id 1U8Ce8-0000J5-Ot; Wed, 20 Feb 2013 17:36:03 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 99068A80682; Wed, 20 Feb 2013 17:35:52 +0100 (CET) Message-ID: <5124FB68.4030208@kit.edu> Date: Wed, 20 Feb 2013 17:35:52 +0100 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: IETF Discussion References: <20130206042108.14054.8941.idtracker@ietfa.amsl.com> <512435A9.1090507@kit.edu> In-Reply-To: <512435A9.1090507@kit.edu> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1361378163.879749000 Cc: "Goltsman, Polina" , p2psip@ietf.org Subject: Re: [P2PSIP] Last Call: (REsource LOcation And Discovery (RELOAD) Base Protocol) to Proposed Standard 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, 20 Feb 2013 16:36:09 -0000 Hi again, [this time with all comments, including chapters 7 and 10, no changes in the first part so you can jump to [**CONT**] if you are looking for the new stuff] Sorry for the late comments, but I re-read the whole draft which took some time. There are still some clarifications necessary as well as some inconsistencies left. Unfortunately, my comments from June, 19th were not addressed yet. https://www.ietf.org/mail-archive/web/p2psip/current/msg06229.html Polina Goltsman also found many issues listed below while working on an implementation. The list is long, but the good news is that it's mainly clarifications that are missing. Major issues: 1) sec. 6.3.2: length field in Forwarding Header covers what exactly? it is not really clear whether the length field counts the whole message or in case of fragmentation only the fragment size. When reading Sec 6.7 is seems that the former is meant, but the definition could and should be clearer. Similarly, sec. 6.7 should be clear about this, e.g., describing that all Forwarding Headers are identical for fragments of the same message with exception of the fragment field. 2) sec. 7.4.1.1: replica number handling is unclear it is unclear how replica numbers are incremented (e.g., per peer) and what receiving peers should actually do with this number. Is it important to store the value or would a boolean be sufficient so that the peer knows that it's a replica? 3) sec. 6.5.2: transport protocol set for AppAttach Applications may require use of other transport protocols than those defined in OverlayLinkType (TLS/DTLS, what about plain UDP, SCTP, DCCP, etc.), but currently, this seems to be not possible (do the considerations of sec. 6.5.1.6 apply here?). 4) sec. 6.3.4: How can a different signature algorithm be used if not all implementations support it? There is no possibility to provide the feedback, that the signature algorithm is not acceptable at a particular node. 5) sec. 10.5: handling of parallel JOIN requests and use of peer_ready it is not clear what should happen if two JNs try to join at the same time at the same AP (can they be processed in parallel or should they be processed in sequence). Furthermore, when MUST/SHOULD a JN send peer_ready Update - in step 9? Minor issues: citations are put first, followed by comments starting with # sec. 1.1 ======== old: storage rather than for bulk storage of large objects. Records are stored under numeric addresses which occupy the same space as node new: storage rather than for bulk storage of large objects. Records are stored under numeric addresses, called Resource-IDs, which occupy the same space as node # Resource-IDs are used in 1.2.2 but not introduced sec. 1.2 ======== Message Transport: Handles end-to-end reliability, manages request ... # What are the interactions with Forwarding and Link Management and the Topology Plugin old: Forwarding and Link Management Layer: Stores and implements the routing table by providing packet forwarding services between nodes. It also handles establishing new links between nodes, including setting up connections across NATs using ICE. # It may be confusing to say "routing table" here, since this # is usually associated with the topology plugin. So IMHO # it is the Connection Table, not the routing table. # Furthermore, I propose the following change: old: including setting up connections across NATs using ICE. new: including setting up connections for overlay links across NATs using ICE. old: directly between nodes. TLS [RFC5246] and DTLS [RFC6347] are the currently defined "link layer" protocols used by RELOAD for hop- new: currently defined "overlay link layer" protocols used by RELOAD for hop- # avoids confusion with the classic ISO/OSI link layer (layer 2) old: In addition to the above components, nodes communicate with a central new: In addition to the above components, nodes may communicate with a central # while it may be the default case, it is not strictly required sec. 1.3 ======== old: RELOAD also provides an optional shared secret based admission control feature using shared secrets and TLS-PSK. In order to form a new: RELOAD also provides an optional shared secret based admission control feature using shared secrets and TLS-PSK/TLS-SRP. In order to # TLS-SRP should be mentioned here, too sec. 2 ====== old: Terms used in this document are defined inline when used and are also new: Terms in this document are defined inline when used and are also # avoid double "used" old: Bootstrap Node: A network node used by Joining Nodes to help locate the Admitting Peer. new: Bootstrap Node: A network node used by Joining Nodes to help accessing the overlay by forwarding messages to peers. # The bootstrap node does not locate the Admitting Peer, but the JN locates # the AP by routing a message to its own Resource-ID old: Connection Table: The set of nodes to which a node is directly connected, which include nodes that are not yet available for routing. new: Connection Table: Contains connection information for the set of nodes to which a node is directly connected, which include nodes that are not yet available for routing. # it is a data structure ... Node-ID: A value of fixed but configurable length that uniquely identifies a node. Node-IDs of all 0s and all 1s are reserved and are invalid Node-IDs. A value of zero is not used in the wire protocol but can be used to indicate an invalid node in implementations and APIs. The Node-ID of all 1s is used on the wire protocol as a wildcard. # what means "invalid" exactly? A wildcard can be used at least on # the wire so it is not invalid being used as destination Node-IDs. # So the above definition is slightly contradictory. old: Responsible Peer: The peer that is responsible for a specific resource, as defined by the plugin algorithm. new: Responsible Peer: The peer that is responsible for a specific resource, as defined by the topology plugin algorithm. old: Usage: An usage is the definition of a set of data structures (data Kinds) that an application wants to store in the overlay. An usage may also define a set of network protocols (application IDs) new: Usage: A usage is the definition of a set of data structures (data Kinds) that an application wants to store in the overlay. A usage may also define a set of network protocols (application IDs) # Typo: 2x An usage -> A usage sec. 3.1 ======== old: o To determine its position in the overlay topology (if the overlay is structured; topology plugins do not need to be structured). new: o To determine its position in the overlay topology (if the overlay is structured; overlays do not need to be structured). # a structured topology plugin is not the same as a structured overlay o To determine the set of resources for which the node is responsible. # this isn't necessarily true for unstructured overlays? old: The general principle here is that the security mechanisms (TLS at new: The general principle here is that the security mechanisms ((D)TLS at sec. 3.2 ======== entity. From the perspective of a peer, a client is a node that has connected to the overlay, but has not yet taken steps to insert # an additional reference to the Connection Table would be nice sec. 3.2.1 ========== clients that choose this option need to process Update messages # Update messages are not introduced yet, so a forward reference to # section 6.4.2.3 would be helpful performing an Attach. A client wishing to connect using this mechanism with a certificate with multiple Node-IDs can use a Ping (Section 6.5.3) to probe the Node-ID of the node to which it is connected before doing the Attach (Section 6.5.1). # At this point it is not really clear why this step is necessary. # Certificates with multiple Node-IDs were not explained yet. # Furthermore, the reference to Section 6.5.1 should be moved # to the previous sentence. sec. 3.3 ======== old: This section will discuss the capabilities of RELOAD's routing layer, new: This section discusses the capabilities of RELOAD's routing layer, old: Resource-based routing: RELOAD supports routing messages based solely on the name of the resource. Such messages are delivered new: Resource-based routing: RELOAD supports routing messages based solely on the name of the resource or Resource-ID. Such messages old: Clients: RELOAD supports requests from and to clients that do not participate in overlay routing, located via either of the mechanisms described above. new: Clients: RELOAD supports requests from and to clients that do not participate in overlay routing. # the addition is not really necessary and may be confusing old: Destination Lists: While in principle it is possible to just inject a message into the overlay with a single Node-ID as the new: Destination Lists: While in principle it is possible to just inject a message into the overlay with a single Node-ID or a single Resource-ID as the # Resource-ID is also a possible destination old: The basic routing mechanism used by RELOAD is Symmetric Recursive. new: The basic routing mode used by RELOAD is Symmetric Recursive Routing (SRR, cf. Section 6.2) # I would prefer to use the term "mode" (as on p. 28) and it should be # consistent with the text in section 6.2 old: opaque ID X1 which maps internally to [A, B] (perhaps by being an encryption of [A, B] and forwards to Z with only X1 as the via list. new: opaque ID X1 which maps internally to [A, B] (perhaps by being an encryption of [A, B]) and forwards to Z with only X1 as the via list. # simple typo old: RELOAD also supports a basic Iterative "routing" mode (where the new: RELOAD also supports a basic Iterative routing mode (where the old: Iterative "routing" is implemented using the RouteQuery method, which new: Iterative routing is implemented using the RouteQuery method, which old: requests this behavior. Note that iterative "routing" is selected new: requests this behavior. Note that Iterative routing is selected sec. 3.4 ======== pairs. The result is a connection between A and B. At this point, A and B MAY send messages directly between themselves without going through other overlay peers. In other words, A and B are on each other's connection tables. They MAY then execute an Update process, # MAY is RFC 2119 terminology, which is defined in section 5 # Besides Update process a Join process is also possible. order to support this case, some small number of "bootstrap nodes" typically need to be publicly accessible so that new peers can # what "publicly accessible" means exactly is not defined # typically need to be publicly accessible (i.e., not behind a NAT or # firewall) ... old: The second case is when a client connects to a peer at an arbitrary IP address, rather than to its responsible peer, as described in the new: The second case is when a client connects to a peer at an arbitrary node-ID, rather than to its responsible peer, as described in the # since responsible peer may depend on the overlay topology, node-ID # seems to be a better fit here sec. 3.5.2 ========== old: When a new peer wishes to join the Overlay Instance, it will need a Node-ID that it is allowed to use and a set of credentials which new: When a new peer wishes to join the Overlay Instance, it needs a Node-ID that it is allowed to use and a set of credentials which # not really sure about this change as non-native speaker match that Node-ID. When an enrollment server is used, the Node-ID used is the Node-ID found in the certificate received from the # the mode with self-signed certificates is missing and should be # mentioned also here "bootstrap node". Because this is the first connection the peer makes, these nodes will need public IP addresses so that they can be # may also work if the bootstrap node is directly reachable, e.g., # in the same domain # in this paragraph and the following paragraph "Once a peer" # is used three times past adjacencies which have public IP address and attempt to use them # inconsistent use of term "adjacencies"/adjacent within the document # different meanings as follows: # 1.) all directly connected nodes (i.e., all nodes in the Connection Table), e.g., sec. 3.5.2 and 6.4.2.3 # 2.) all peers in the routing table # 3.) adjacent according to the overlay topology, e.g. sec. 6.4.2.1 sec. 4 ====== limits on size, on the values which may be stored. For many Kinds, the set may be restricted to a single value; some sets may be allowed # what set? sec. 4.1.2. =========== old: responsibility if the responsible peer fail [Chord]. new: responsibility if the responsible peer fails [Chord]. sec. 6 ====== old: messages. We then describe the symmetric recursive routing model, which is RELOAD's default routing algorithm. We then define the new: messages. We then describe the symmetric recursive routing mode, which is RELOAD's default routing mode. We then define the # IMHO the term mode fits best, the routing algorithm is defined # within the topology plugin sec. 6.1. ========= old: peer SHOULD generate an appropriate error but local policy can new: peer SHOULD generate an appropriate error message but local policy can Once the peer has determined that the message is correctly formatted # what does "correctly formatted" mean exactly? sec. 6.1.1. =========== this node so it MUST verify the signature as described in Section 7.1 and MUST pass it up to the upper layers. "Upper layers" is used here to mean the components above the "Overlay Link Service Boundary" line in the figure in Section 1.2. # this is somewhat confusing. The text describes what the # Forwarding and link management component does, but what # other components are meant here? state, e.g., by unpacking any opaque IDS. # I think any is incorrect, since other IDs are # not inserted by this node and so it cannot "unpack" those, # but only its own opaque IDs sec. 6.1.2. =========== the first entry on the destination list is in the peer's connection table, then it MUST forward the message to that peer directly. # This is probably motivated by clients. A hint to this fact # may help. old: destination list, it would detect that I is a opaque ID, recover the new: destination list, it would detect that I is an opaque ID, recover the # Typo fix old: called List Compression. Possibilities for a opaque ID include a new: called List Compression. Possibilities for an opaque ID include a # Typo fix An intermediate node receiving a request from another node MUST return a response to this request with a destination list equal to the concatenation of the Node-ID of the node that sent the request with the via list in the request. The intermediate node normally # 1.) unclear why an _intermediate_ peer should return a response # (if it is not the destination node), # 2.) the via list must be reversed before concatenating the Node-ID # so: old: with the via list in the request. The intermediate node normally new: with the reversed via list in the request. The intermediate node normally sec. 6.1.3. =========== old: compressed via list), the peer MUST replace that entry with the original via list that it replaced and then re-examine the new: compressed via list), the peer MUST replace that entry with the reversed original via list that it replaced and then re-examine the # the via list must be reversed for responses... sec. 6.2. ========= old: This Section defines RELOAD's Symmetric Recursive Routing (SRR) algorithm, which is the default algorithm used by nodes to route messages through the overlay. All implementations MUST implement this routing algorithm. An overlay MAY be configured to use alternative routing algorithms, and alternative routing algorithms MAY be selected on a per-message basis. I.e., a node in an overlay which supports SRR and some other routing algorithm called XXX might use SRR some of the time and XXX some of the time. new: This Section defines RELOAD's Symmetric Recursive Routing (SRR) mode, which is the default mode used by nodes to route messages through the overlay. All implementations MUST implement this routing mode. An overlay MAY be configured to use alternative routing modes, and alternative routing modes MAY be selected on a per-message basis. I.e., a node in an overlay which supports SRR and some other routing mode called XXX might use SRR some of the time and XXX some of the time. # better use mode for consistency (algorithm is contained in the # topology plugin sec. 6.2.1. =========== old: node MAY also construct a more complicated destination list for source routing. new: node MAY also construct a more complicated destination list for (loose) source routing. Once the message is constructed, the node sends the message to some adjacent peer. If the first entry on the destination list is directly connected, then the message MUST be routed down that connection. Otherwise, the topology plugin MUST be consulted to determine the appropriate next hop. # adjacent peer should be adjacent node, since it may be a client # directly connected means: a valid entry in the Connection Table # exists? this should be mentioned here... sec. 6.2.2. =========== # a hint that the same Transaction-ID as in the request MUST be used # could be added. sec. 6.3.1.1. ============= Unless a given structure that uses a select explicitly allows for unknown types in the select, any unknown type SHOULD be treated as an # How is that allowance specified in the specification? Is it by the comment # /* This structure can be extended */ sec. 6.3.2. =========== receive message with a TTL greater than the current value of initial-ttl (or the 100 default) MUST discard the message and send an "Error_TTL_Exceeded" error. # what if the initial-ttl is larger than 100 and the TTL is >100 but # < initial-ttl? The condition "or the 100 default" holds old: used to indicate the fragment offset; see Section 6.7. new: used to indicate the fragment offset in bytes; see Section 6.7. old: length: The count in bytes of the size of the message, including the header. new: length: The count in bytes of the size of the whole unfragmented message, including the header. # as already mentioned in the beginning this should be more precise destinations which the message should pass through. The destination list is constructed by the message originator. The # is it allowed that intermediate peers add destinations? if not, please # state so old: next. The list shrinks as the message traverses each listed peer. new: next. The list may shrink as the message traverses each listed peer. # it need not be always the case that the list shrinks with each traversed peer sec. 6.3.2.2. ============= old: structure with a DestinationType of opaque_id_type and a opaque_id new: structure with a DestinationType of opaque_id_type and an opaque_id # typo fix old: opaque A compressed list of Node-IDs and an eventual Resource-ID. Because this value was compressed by one of the peers, it is only meaningful to that peer and cannot be decoded by other peers. Thus, it is represented as an opaque string. resource The Resource-ID of the resource which is desired. This type MUST only appear in the final location of a destination list and MUST NOT appear in a via list. It is meaningless to try to route through a resource. new: resource The Resource-ID of the resource which is desired. This type MUST only appear in the final location of a destination list and MUST NOT appear in a via list. It is meaningless to try to route through a resource. opaque_id_type A compressed list of Node-IDs and an eventual Resource-ID. Because this value was compressed by one of the peers, it is only meaningful to that peer and cannot be decoded by other peers. Thus, it is represented as an opaque string. # 1.) match the order in the select # 2.) it must be opaque_id_type, not opaque sec. 6.3.2.3 ============ flags Three flags are defined FORWARD_CRITICAL(0x01), DESTINATION_CRITICAL(0x02), and RESPONSE_COPY(0x04). These flags MUST NOT be set in a response. If the FORWARD_CRITICAL flag is # What is the correct reaction if these flags are set in a response? # (returning an Error_Invalid_Message or ignore?) sec. 6.3.3.1 ============ old: A node processing a request MUST return its status in the message_code field. If the request was a success, then the message new: A node processing a request MUST return its status in the message_code field of a response. If the request was a success, then the message # clarification? Error_Request_Timeout: A response to the request has not been received in a suitable amount of time. The requesting node MAY resend the request at a later time. # not clear when this will ever be used. Which node should send # this error message? All RELOAD messages MUST be signed. Intermediate nodes do not verify signatures. Upon receipt (and fragment reassembly if needed) the destination node MUST verify the signature and the authorizing certificate. If the signature fails, the implementation SHOULD simply drop the message and MUST NOT process it. This check provides # What happens if none {0,0} is given? Then no Node-ID is present... sec. 6.4.2. =========== What happens if these messages (like Join, Leave) are accidentally sent to a Client? Do the send an Invalid Message back? A new peer (but one that already has credentials) uses the JoinReq message to join the overlay. The JoinReq is sent to the responsible peer depending on the routing mechanism described in the topology Is the destination address now the Resource-ID or the Node-ID of the "responsible peer"? Because joins may only be executed between nodes which are directly adjacent, receiving peers MUST verify that any JoinReq they receive # 1.) should be peers rather than nodes # 2.) directly adjacent means here: directly adjacent in the overlay # topology (could otherwise be misunderstood as being directly # connected) # 3.) what must happen if the verification fails? adjacent, receiving peers MUST verify that any LeaveReq they receive arrives from a transport channel that is bound to the Node-ID to be # what happens if that verification fails? old: assumed by the leaving peer.) This also prevents replay attacks new: assumed by the leaving peer. This also prevents replay attacks # Typo fix sec. 6.4.2.3 ============ the state change. In general, peers send Update messages to all their adjacencies whenever they detect a topology shift. # A hint to the Connection Table and Clients would clarify sec. 6.4.2.4. ============= old: X. A RouteQuery can also request that the receiving peer initiate an new: X. A RouteQuery can also request that the receiving peer initiates an old: One important use of the RouteQuery request is to support iterative routing. The sender selects one of the peers in its routing table # add reference to Section 3.3. sec. 6.4.2.4.1 ============== destination The destination which the requester is interested in. This may be any valid destination object, including a Node-ID, opaque ID, or Resource-ID. # Does opaque ID make sense here? sec. 6.5.1 ========== A node sends an Attach request when it wishes to establish a direct TCP or UDP connection to another node for the purpose of sending # TCP/TLS or DTLS? old: node A has Attached to node B, but not received any Updates from B, new: node A has attached to node B, but not received any Updates from B, # Typo channel but MUST NOT route messages through B to other peers via that channel. The process of Attaching is separate from the process of # Is that also true for clients? sec. 6.5.1.1 ============ old: } AttachReqAns; The values contained in AttachReqAns are: new: } AttachReq; The values contained in AttachReq are: old: A single AttachReqAns MUST NOT include both candidates whose new: A single AttachReq MUST NOT include both candidates whose # consistency! sec. 6.5.1.2. ============= old: 6.5.1.2. Response Definition new: 6.5.1.2. Response Definition The AttachAns message hast the same format as the AttachReq message. #s/AttachReqAns/AttachAns/ in the whole paragraph. sec. 6.5.1.3. ============= An agent follows the ICE specification as described in [RFC5245] with # agent was not defined in the RELOAD context so far. sec. 6.5.4.2. ============= old: o The configuration document is correctly digitally signed (see Section 11 for details on signatures. new: o The configuration document is correctly digitally signed (see Section 11 for details on signatures). old: one listed in the current configuration file). Details on kind- signer field in the configuration file is described in Section 11.1. new: one listed in the current configuration file). Details on kind- signer field in the configuration file are described in Section 11.1. # typos sec. 6.6.2 ========== old: Each connection has it own sequence number space. Initially the new: Each connection and direction has it own sequence number space. Initially the sec. 6.6.3.1 ============ A node MUST NOT have more than one unacknowledged message on the DTLS connection at a time. Note that because retransmissions of the same message are given new sequence numbers, there may be multiple unacknowledged sequence numbers in use. # Since retransmissions violate the first sentence, it may be better # to use: old: A node MUST NOT have more than one unacknowledged message on the DTLS connection at a time. Note that because retransmissions of the same new: A node MUST NOT have more than one unacknowledged message on the DTLS connection at a time, except for retransmissions. Note that because from the routing table. The link MAY be restored to the routing table if ACKs resume before the connection is closed, as described # this should read Connection Table twice? sec. 6.7 ========= and fragments it, each fragment has a full copy of the Forwarding # 1.) clarification would be good that the length field is covering the # total msg length and which field are different in the "copies" # (at least the fragment field) # 2.) what happens if overlapping fragments are received? [**CONT**] sec. 7 ====== data may be stored in a single transaction, rather than querying for the value of a counter before the actual store. # a reader may wonder which counter is meant here - slightly confusing. # I assume that the text assumes a hypothetical different design that # uses counters as an alternative to timestamps? If a node attempting to store new data in response to a user request (rather than as an overlay maintenance operation such as occurs when healing the overlay from a partition) is rejected with an Error_Data_Too_Old error, the node MAY elect to perform its store using a storage_time that increments the value used with the previous store. # I don't understand what "using a storage_time that increments the # value used with the previous store" actually means. In this case # it is assumed that the requesting node has already the storage_time # of the previous store available or must it send a StatReq first? # In the former case it could simply check if localtime > storage_time # before sending the request. By what amount should the value be incremented? sec. 7.4 ======== old: o Store values in the overlay o Fetch values from the overlay o Stat: get metadata about values in the overlay o Find the values stored at an individual peer new: o Store: store values in the overlay o Fetch: get values from the overlay o Stat: get metadata about values in the overlay o Find: get values stored at an individual peer # just consistency sec. 7.4.1.1 ============ which represents a sequence of stored values for a given Kind. The same Kind-ID MUST NOT be used twice in a given store request. Each # what is the proper reaction if this condition is violated by a sending node? replica_number The number of this replica. When a storing peer saves replicas to other peers each peer is assigned a replica number starting from 1 and sent in the Store message. This field is set to 0 when a node is storing its own data. This allows peers to distinguish replica writes from original writes. # must it be "When a storing (responsible) peer saves replicas to"? # IMHO this description is too vague, since # as stated in 2) at the beginning of this mail it is not clear # how to assign the replica numbers when storing replicas. # Let's assume responsible peer X stores replicas at neighbors # A and C: gets A replica number 1 and C replica number 2? # if node B replaces neighbor C, does B get replica number 3 or number 2? # if the responsible peer X is replaced by a new node Y, Y will get # get the data from peer X, but how should X change its replica number? # Can Y simply start sending replicas beginning at 1? # I couldn't find any place in the document where it would make a # difference between replica number 2 and replica number 42 old: kind The Kind-ID. Implementations MUST reject requests corresponding to unknown Kinds. new: kind The Kind-ID. Implementations MUST reject (Error_Unknown_Kind) requests corresponding to unknown Kinds. # hint on the correct error message for this check old: values The value or values to be stored. This may contain one or more stored_data values depending on the data model associated with new: values The value or values to be stored. This may contain one or more StoredData values depending on the data model associated with # consistency old: o The signatures over each individual data element (if any) are new: o The signatures over each individual StoredData element (if any) are # consistency o For original (non-replica) stores, the peer MUST check that if the generation counter is non-zero, it equals the current value of the generation counter for this Kind. This feature allows the generation counter to be used in a way similar to the HTTP Etag feature. # what is the proper reaction in case the check fails? A reference to the # mentioned HTTP Etag feature would also be nice. o The storage time values are greater than that of any value which would be replaced by this Store. o The size and number of the stored values is consistent with the limits specified in the overlay configuration. # what is the reaction in case the checks fail? If all these checks succeed, the peer MUST attempt to store the data # this seems to suggest that the list is complete, though more checks are # describe in the following section 7.4.1.2. Maybe it's more consistent # to have them described in one place. sec.7.4.1.2. ============= replicas The list of other peers at which the data was/will be replicated. In overlays and applications where the responsible peer is intended to store redundant copies, this allows the storing node to independently verify that the replicas have in fact been stored. It does this verification by using the Stat method (see Section 7.4.3). Note that the storing node is not required to perform this verification. # what is meant by the term "storing node"? Is this the responsible node # who actually stores the data or is it the node who originated the # StoreReq? This may be inconsistent with the rest of the document. # Moreover, it is not clear that this implies a certain order. Must # the responsible node having successfully finished storing the replicas # before returning the replicas? If any type of request tries to access a data Kind that the peer does not know about, an Error_Unknown_Kind MUST be generated. The # The reaction is defined differently for StoreReq, FetchReq, StatReq # and FindReq: # - StoreReq: send back Error_Unknown_Kind # - FetchReq: "Implementations SHOULD reject requests corresponding to # unknown Kinds unless specifically configured otherwise." # -> what means "reject" exactly? # - StatReq: no hint given how to behave # - FindReq: "If a Kind-ID is not known, then the corresponding Resource-ID MUST be 0." -> Cannot distinguish from the case where a Resource-ID is not known: # "The closest Resource-ID to the specified Resource-ID. This is 0 # if no Resource-ID is known." # # Is the intention to trigger Configuration update requests? # cf. StoreReq: A node which # receives this error MUST generate a ConfigUpdate message which # contains the appropriate Kind definition (assuming that in fact a # Kind was used which was defined in the configuration document). sec. 7.4.1.3 ============= remove a value, the owner stores a new DataValue with "exists" set to False: exists = False value = {} (0 length) # what happens if a value is given? # Ignore the value or reject with an error invalid message? sec. 7.4.2.2. ============= old: uint64 generation; new: uint64 generation_counter; and old: generation the generation counter for this Kind. new: generation_counter the generation counter for this Kind. # consistency sec. 7.4.4.1: ============= kinds The desired Kind-IDs. Each value MUST only appear once, and if not the request MUST be rejected with an error. # What is the error code? sec. 7.4.4.2: ============= The response is simply a series of FindKindData elements, one per Kind, concatenated end-to-end. The contents of each element are: # unclear what end-to-end means here? sec. 10 ======= protocol. A short list of differences: # A further difference is the fact that CHORD uses hashes of IP addresses # while in RELOAD nodes get assigned Node-IDs and the routing table # does not contain "underlay addresses" sec. 10.1 ========= old: and n+1, with all arithmetic being done modulo 2^{k}, where k is the length of the Node-ID in bits, so that node 2^{k} - 1 is directly new: and n+1, with all arithmetic being done modulo 2^(k), where k is the length of the Node-ID in bits, so that node 2^(k) - 1 is directly # consistency with other formulas... sec. 10.3 ========= If a peer is not responsible for a Resource-ID k, but is directly connected to a node with Node-ID k, then it MUST route the message to # what means "directly connected" here? Is it an entry in the ConnectionTable # or RoutingTable? I guess the former in order to cover routing to Clients sec. 10.5 ========= 1. JN MUST connect to its chosen bootstrap node. # it is unclear what "connect" exactly means. This is actually # described in Sec. 11.4: # "When contacting a bootstrap node, the joining node MUST first form # the DTLS or TLS connection to the bootstrap node and then sends an # Attach request over this connection with the destination Node-ID set # to the joining node's Node-ID." # So my suggestion is to explain it a little but more or to put a forward # reference to section 11.4. 2. JN SHOULD send an Attach request to the admitting peer (AP) for Node-ID n. The "send_update" flag can be used to acquire the routing table for AP. # This is inconsistent with Section 12 stating # "JN then sends an Attach through that peer to a resource ID of itself (JN)." # (Node ID n vs. Resource-ID n) # # Moreover, it is not clear how the JN finds the AP. This is explained in #Section 12: # to one of the bootstrap nodes. JN then sends an Attach through that # peer to a resource ID of itself (JN). It gets routed to the # admitting peer (AP) because JN is not yet part of the overlay. When # I suggest to change it to: 2. JN SHOULD send an Attach request to Resource-ID of itself (JN) in order to contact the Admitting peer (AP) for Node-ID n. The "send_update" flag can be used to acquire the routing table from AP. # Question: should it be "acquire the routing table of AP" or "acquire the # routing table from AP"? 3. JN SHOULD send Attach requests to initiate connections to each of the peers in the neighbor table as well as to the desired finger table entries. Note that this does not populate their routing tables, but only their connection tables, so JN will not get messages that it is expected to route to other nodes. # here it is unclear that the Attach requests are sent via the AP # and what "desired" finger table entries means, e.g., in contrast to all? # why are we having two SHOULDs instead of two MUSTs, since 10.7 states: # A peer MUST maintain an association (via Attach) to every member of # its neighbor set. A peer MUST attempt to maintain at least three In order to set up its i'th finger table entry, JN MUST send an Attach to peer n+2^(128-i). This will be routed to a peer in # instead of peer n+2^(128-i) better resource-ID n+2^(128-i)? # How should an AP react if it detects that a JN sent # the Join to the wrong AP (not responsible at all or not # anymore)? sec. 10.7. ========== A peer MUST maintain an association (via Attach) to every member of its neighbor set. A peer MUST attempt to maintain at least three # why only to the neighbor set and not the whole routing table? Sec. 10.7.1: ============ Every time a connection to a peer in the neighbor table is lost (as determined by connectivity pings or the failure of some request), the # I think that "connectivity pings" means periodically sent Pings to all # members of the Connection Table by the Link Management Layer as # mentioned in sec. 6.5. A reference may help here. # However, I couldn't find out how often such "connectivity pings" should # be sent (the chord-ping-interval is only related to pinging finger table # entries). # It is unclear to me why (sec. 10.7.1) the spec states: # "peer MUST remove the entry from its neighbor table and replace it # with the best match it has from the other peers in its routing table. # If using reactive recovery, it then sends an immediate Update to all # nodes in its Neighbor Table." # so the peer replaces the failed entry with one of its fingers, # which is maybe a poor choice, and sends this information to # its neighbors. IMHO it makes much more sense to request routing # information from the neighbors in order to get a better replacement # for the lost peer, instead of "confusing" the neighbors with more # inaccurate routing information. If the neighbor failure affects the peer's range of responsible IDs, then the Update MUST be sent to all nodes in its Connection Table. # a short hint that it's the Connection Table instead of the Neighbor Table # due to Clients would be nice If connectivity is lost to all successor peers in the neighbor table, then this peer SHOULD behave as if it is joining the network and MUST use Pings to find a peer and send it a Join. If connectivity is lost # Only Join or Attach and Join? Sec. 10.7.2.: ============= If a finger table entry is found to have failed, all references to # how is it determined to have "failed"? 10.7.1 is only # related to neighbor failures...does the same definition # apply here? Sec. 10.7.3.: ============= If the neighbor failure affects the peer's range of responsible IDs, then the Update MUST be sent to all nodes in its Connection Table. # add hint that it's Connection Table due to Clients interval" element (denominated in seconds.) A peer SHOULD randomly offset these Update requests so they do not occur all at once. # This is a little bit too imprecise. # How should this be done? A typical mechanism # is using a randomly chosen offset from an interval [0.5*Tp,1.5*Tp] # where Tp is the target period, cf. # S. Floyd, V. Jacobson, „The Synchronization of Periodic Routing # Messages“, IEEE/ACM Transactions on Networking, Vol. 2, No. 2, April, # 1994, http://portal.acm.org/citation.cfm?id=187045 Sec: 10.7.4.2.: ============== A peer SHOULD NOT send Ping requests looking for new finger table entries more often than the configuration element "chord-ping- interval", which defaults to 3600 seconds (one per hour). # This paragraph should probably moved some paragraphs down as it # has been stated yet that a peer should actually send Ping requests # at all (this is explained in the subsequent paragraphs). Sec 12: ======== # throughout the figures: "Update" should be "UpdateReq" # and Attach should be AttachReq? # Otherwise it's not consistent with the use of Attach vs. AttachReq/AttachAns Neighbor Table and Connection Table are written sometimes in lower case and sometimes in upper case style. I'm sure that the RFC editor will ask for consistency in writing... That's all for now... Regards, Roland From cjbc@it.uc3m.es Wed Feb 20 09:26:20 2013 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 2A01621F8686 for ; Wed, 20 Feb 2013 09:26:20 -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=[AWL=0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKUVDfiitb3r for ; Wed, 20 Feb 2013 09:26:17 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 12B3C21F85D7 for ; Wed, 20 Feb 2013 09:26:16 -0800 (PST) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1FFD1894AE9 for ; Wed, 20 Feb 2013 18:26:15 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 0B5F1894A2A for ; Wed, 20 Feb 2013 18:26:15 +0100 (CET) Message-ID: <1361381174.4177.2.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "p2psip@ietf.org" Date: Wed, 20 Feb 2013 18:26:14 +0100 Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19650.000 X-TM-AS-Result: No--1.280-7.0-31-1 X-imss-scan-details: No--1.280-7.0-31-1 Subject: [P2PSIP] Milestones updated X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es 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, 20 Feb 2013 17:26:20 -0000 Hi, Just to let you know that the milestones have just been updated: http://datatracker.ietf.org/wg/p2psip/charter/ Thanks, Brian & Carlos From dean.willis@softarmor.com Wed Feb 20 15:56:05 2013 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 A9A3D21F882D for ; Wed, 20 Feb 2013 15:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.071 X-Spam-Level: X-Spam-Status: No, score=-102.071 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJLCu-cEhP3I for ; Wed, 20 Feb 2013 15:56:03 -0800 (PST) Received: from mail-vb0-f41.google.com (mail-vb0-f41.google.com [209.85.212.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5A52821F881A for ; Wed, 20 Feb 2013 15:56:03 -0800 (PST) Received: by mail-vb0-f41.google.com with SMTP id l22so5459198vbn.28 for ; Wed, 20 Feb 2013 15:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=EPqDSZUBhkIIKBz7W86DfQPv32AtSZv7duHmNRgvbVk=; b=gPIuBV3L7Ljefwjx5b6IEfGeu5smGv3rDxdoonAGiocCZYUExsghaXuFDEL5cJfs2z dqdFVuw5T77eWLsF7TGCqJdXJSSBvEVVbPgzRssPdwHjQlLP8KohWH5cKHxJD7Ac1WXG tmoNRRynx1/7ts08101QZwvA1T7kq4umXz0Eg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=EPqDSZUBhkIIKBz7W86DfQPv32AtSZv7duHmNRgvbVk=; b=d8HKi1rfZpmywVdwMZ1TlgPcjgfZOg9H5T4/3ShhvERCNNCQBqbTOPOkg0k8Q0CfWh MOt6o/TTNKVkW/3lrDicRn/UNfod+hKjztI6H3Jg8AsvWnNlH1btDM9hIU1QY0Ww3Svo L905XZ9w5YmRDhZSkNJ9FbWG4RDal4FkkyTRnr2X0pkJLe9WNmpi2Pc4uCtgkhr8ZOg+ 1GdCVRpXCc/4qNZIusyD7Gbpardd+pK1aqtl6dy2MnEaQuxUnefAwg0+eMS34ptrxjDH puVp7o/+iq6wFqMzXGLWn6lqgDC35T0tgeZQkHEX8UxJWXwpmrotVzQBW5bga++r89/I wkYA== MIME-Version: 1.0 X-Received: by 10.220.156.68 with SMTP id v4mr28234888vcw.10.1361404559345; Wed, 20 Feb 2013 15:55:59 -0800 (PST) Received: by 10.58.46.17 with HTTP; Wed, 20 Feb 2013 15:55:59 -0800 (PST) Date: Wed, 20 Feb 2013 17:55:59 -0600 Message-ID: From: Dean Willis To: p2psip@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnqZj06d4urTE5x+jzK3LVwVA/IFEd4LeH/neN9+OPVoLYWm24+rkzHQL9RFWkxAXl0S36I Subject: [P2PSIP] Roland Bless's IETF LC Comments on draft-ietf-p2psip-base 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, 20 Feb 2013 23:56:05 -0000 For your entertainment. ---------- Forwarded message ---------- From: Roland Bless Date: Tue, Feb 19, 2013 at 8:32 PM Subject: Re: [P2PSIP] Last Call: (REsource LOcation And Discovery (RELOAD) Base Protocol) to Proposed Standard To: IETF Discussion Cc: p2psip@ietf.org, "iesg@ietf.org" Hi, On 06.02.2013 05:21, The IESG wrote: > The IESG has received a request from the Peer-to-Peer Session Initiation > Protocol WG (p2psip) to consider the following document: > - 'REsource LOcation And Discovery (RELOAD) Base Protocol' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-02-19. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. Sorry for the late comments, but I re-read the whole draft which took some time. There are still some clarifications necessary as well as some inconsistencies left. Unfortunately, my comments from June, 19th were not addressed yet. https://www.ietf.org/mail-archive/web/p2psip/current/msg06229.html Polina Goltsman also found many issues listed below while working on an implementation. The list is long, but the good news is that it's mainly clarifications that are missing. Major issues: 1) sec. 6.3.2: length field in Forwarding Header covers what exactly? it is not really clear whether the length field counts the whole message or in case of fragmentation only the fragment size. When reading Sec 6.7 is seems that the former is meant, but the definition could and should be clearer. Similarly, sec. 6.7 should be clear about this, e.g., describing that all Forwarding Headers are identical for fragments of the same message with exception of the fragment field. 2) sec. 7.4.1.1: replica number handling is unclear it is unclear how replica numbers are incremented (e.g., per peer) and what receiving peers should actually do with this number. Is it important to store the value or would a boolean be sufficient so that the peer knows that it's a replica? 3) sec. 6.5.2: transport protocol set for AppAttach Applications may require use of other transport protocols than those defined in OverlayLinkType (TLS/DTLS, what about plain UDP, SCTP, DCCP, etc.), but currently, this seems to be not possible (do the considerations of sec. 6.5.1.6 apply here?). 4) sec. 6.3.4: How can a different signature algorithm be used if not all implementations support it? There is no possibility to provide the feedback, that the signature algorithm is not acceptable at a particular node. 5) sec. 10.5: handling of parallel JOIN requests and use of peer_ready it is not clear what should happen if two JNs try to join at the same time at the same AP (can they be processed in parallel or should they be processed in sequence). Furthermore, when MUST/SHOULD a JN send peer_ready Update - in step 9? Minor issues: citations are put first, followed by comments starting with # sec. 1.1 ======== old: storage rather than for bulk storage of large objects. Records are stored under numeric addresses which occupy the same space as node new: storage rather than for bulk storage of large objects. Records are stored under numeric addresses, called Resource-IDs, which occupy the same space as node # Resource-IDs are used in 1.2.2 but not introduced sec. 1.2 ======== Message Transport: Handles end-to-end reliability, manages request ... # What are the interactions with Forwarding and Link Management and the Topology Plugin old: Forwarding and Link Management Layer: Stores and implements the routing table by providing packet forwarding services between nodes. It also handles establishing new links between nodes, including setting up connections across NATs using ICE. # It may be confusing to say "routing table" here, since this # is usually associated with the topology plugin. So IMHO # it is the Connection Table, not the routing table. # Furthermore, I propose the following change: old: including setting up connections across NATs using ICE. new: including setting up connections for overlay links across NATs using ICE. old: directly between nodes. TLS [RFC5246] and DTLS [RFC6347] are the currently defined "link layer" protocols used by RELOAD for hop- new: currently defined "overlay link layer" protocols used by RELOAD for hop- # avoids confusion with the classic ISO/OSI link layer (layer 2) old: In addition to the above components, nodes communicate with a central new: In addition to the above components, nodes may communicate with a central # while it may be the default case, it is not strictly required sec. 1.3 ======== old: RELOAD also provides an optional shared secret based admission control feature using shared secrets and TLS-PSK. In order to form a new: RELOAD also provides an optional shared secret based admission control feature using shared secrets and TLS-PSK/TLS-SRP. In order to # TLS-SRP should be mentioned here, too sec. 2 ====== old: Terms used in this document are defined inline when used and are also new: Terms in this document are defined inline when used and are also # avoid double "used" old: Bootstrap Node: A network node used by Joining Nodes to help locate the Admitting Peer. new: Bootstrap Node: A network node used by Joining Nodes to help accessing the overlay by forwarding messages to peers. # The bootstrap node does not locate the Admitting Peer, but the JN locates # the AP by routing a message to its own Resource-ID old: Connection Table: The set of nodes to which a node is directly connected, which include nodes that are not yet available for routing. new: Connection Table: Contains connection information for the set of nodes to which a node is directly connected, which include nodes that are not yet available for routing. # it is a data structure ... Node-ID: A value of fixed but configurable length that uniquely identifies a node. Node-IDs of all 0s and all 1s are reserved and are invalid Node-IDs. A value of zero is not used in the wire protocol but can be used to indicate an invalid node in implementations and APIs. The Node-ID of all 1s is used on the wire protocol as a wildcard. # what means "invalid" exactly? A wildcard can be used at least on # the wire so it is not invalid being used as destination Node-IDs. # So the above definition is slightly contradictory. old: Responsible Peer: The peer that is responsible for a specific resource, as defined by the plugin algorithm. new: Responsible Peer: The peer that is responsible for a specific resource, as defined by the topology plugin algorithm. old: Usage: An usage is the definition of a set of data structures (data Kinds) that an application wants to store in the overlay. An usage may also define a set of network protocols (application IDs) new: Usage: A usage is the definition of a set of data structures (data Kinds) that an application wants to store in the overlay. A usage may also define a set of network protocols (application IDs) # Typo: 2x An usage -> A usage sec. 3.1 ======== old: o To determine its position in the overlay topology (if the overlay is structured; topology plugins do not need to be structured). new: o To determine its position in the overlay topology (if the overlay is structured; overlays do not need to be structured). # a structured topology plugin is not the same as a structured overlay o To determine the set of resources for which the node is responsible. # this isn't necessarily true for unstructured overlays? old: The general principle here is that the security mechanisms (TLS at new: The general principle here is that the security mechanisms ((D)TLS at sec. 3.2 ======== entity. From the perspective of a peer, a client is a node that has connected to the overlay, but has not yet taken steps to insert # an additional reference to the Connection Table would be nice sec. 3.2.1 ========== clients that choose this option need to process Update messages # Update messages are not introduced yet, so a forward reference to # section 6.4.2.3 would be helpful performing an Attach. A client wishing to connect using this mechanism with a certificate with multiple Node-IDs can use a Ping (Section 6.5.3) to probe the Node-ID of the node to which it is connected before doing the Attach (Section 6.5.1). # At this point it is not really clear why this step is necessary. # Certificates with multiple Node-IDs were not explained yet. # Furthermore, the reference to Section 6.5.1 should be moved # to the previous sentence. sec. 3.3 ======== old: This section will discuss the capabilities of RELOAD's routing layer, new: This section discusses the capabilities of RELOAD's routing layer, old: Resource-based routing: RELOAD supports routing messages based solely on the name of the resource. Such messages are delivered new: Resource-based routing: RELOAD supports routing messages based solely on the name of the resource or Resource-ID. Such messages old: Clients: RELOAD supports requests from and to clients that do not participate in overlay routing, located via either of the mechanisms described above. new: Clients: RELOAD supports requests from and to clients that do not participate in overlay routing. # the addition is not really necessary and may be confusing old: Destination Lists: While in principle it is possible to just inject a message into the overlay with a single Node-ID as the new: Destination Lists: While in principle it is possible to just inject a message into the overlay with a single Node-ID or a single Resource-ID as the # Resource-ID is also a possible destination old: The basic routing mechanism used by RELOAD is Symmetric Recursive. new: The basic routing mode used by RELOAD is Symmetric Recursive Routing (SRR, cf. Section 6.2) # I would prefer to use the term "mode" (as on p. 28) and it should be # consistent with the text in section 6.2 old: opaque ID X1 which maps internally to [A, B] (perhaps by being an encryption of [A, B] and forwards to Z with only X1 as the via list. new: opaque ID X1 which maps internally to [A, B] (perhaps by being an encryption of [A, B]) and forwards to Z with only X1 as the via list. # simple typo old: RELOAD also supports a basic Iterative "routing" mode (where the new: RELOAD also supports a basic Iterative routing mode (where the old: Iterative "routing" is implemented using the RouteQuery method, which new: Iterative routing is implemented using the RouteQuery method, which old: requests this behavior. Note that iterative "routing" is selected new: requests this behavior. Note that Iterative routing is selected sec. 3.4 ======== pairs. The result is a connection between A and B. At this point, A and B MAY send messages directly between themselves without going through other overlay peers. In other words, A and B are on each other's connection tables. They MAY then execute an Update process, # MAY is RFC 2119 terminology, which is defined in section 5 # Besides Update process a Join process is also possible. order to support this case, some small number of "bootstrap nodes" typically need to be publicly accessible so that new peers can # what "publicly accessible" means exactly is not defined # typically need to be publicly accessible (i.e., not behind a NAT or # firewall) ... old: The second case is when a client connects to a peer at an arbitrary IP address, rather than to its responsible peer, as described in the new: The second case is when a client connects to a peer at an arbitrary node-ID, rather than to its responsible peer, as described in the # since responsible peer may depend on the overlay topology, node-ID # seems to be a better fit here sec. 3.5.2 ========== old: When a new peer wishes to join the Overlay Instance, it will need a Node-ID that it is allowed to use and a set of credentials which new: When a new peer wishes to join the Overlay Instance, it needs a Node-ID that it is allowed to use and a set of credentials which # not really sure about this change as non-native speaker match that Node-ID. When an enrollment server is used, the Node-ID used is the Node-ID found in the certificate received from the # the mode with self-signed certificates is missing and should be # mentioned also here "bootstrap node". Because this is the first connection the peer makes, these nodes will need public IP addresses so that they can be # may also work if the bootstrap node is directly reachable, e.g., # in the same domain # in this paragraph and the following paragraph "Once a peer" # is used three times past adjacencies which have public IP address and attempt to use them # inconsistent use of term "adjacencies"/adjacent within the document # different meanings as follows: # 1.) all directly connected nodes (i.e., all nodes in the Connection Table), e.g., sec. 3.5.2 and 6.4.2.3 # 2.) all peers in the routing table # 3.) adjacent according to the overlay topology, e.g. sec. 6.4.2.1 sec. 4 ====== limits on size, on the values which may be stored. For many Kinds, the set may be restricted to a single value; some sets may be allowed # what set? sec. 4.1.2. =========== old: responsibility if the responsible peer fail [Chord]. new: responsibility if the responsible peer fails [Chord]. sec. 6 ====== old: messages. We then describe the symmetric recursive routing model, which is RELOAD's default routing algorithm. We then define the new: messages. We then describe the symmetric recursive routing mode, which is RELOAD's default routing mode. We then define the # IMHO the term mode fits best, the routing algorithm is defined # within the topology plugin sec. 6.1. ========= old: peer SHOULD generate an appropriate error but local policy can new: peer SHOULD generate an appropriate error message but local policy can Once the peer has determined that the message is correctly formatted # what does "correctly formatted" mean exactly? sec. 6.1.1. =========== this node so it MUST verify the signature as described in Section 7.1 and MUST pass it up to the upper layers. "Upper layers" is used here to mean the components above the "Overlay Link Service Boundary" line in the figure in Section 1.2. # this is somewhat confusing. The text describes what the # Forwarding and link management component does, but what # other components are meant here? state, e.g., by unpacking any opaque IDS. # I think any is incorrect, since other IDs are # not inserted by this node and so it cannot "unpack" those, # but only its own opaque IDs sec. 6.1.2. =========== the first entry on the destination list is in the peer's connection table, then it MUST forward the message to that peer directly. # This is probably motivated by clients. A hint to this fact # may help. old: destination list, it would detect that I is a opaque ID, recover the new: destination list, it would detect that I is an opaque ID, recover the # Typo fix old: called List Compression. Possibilities for a opaque ID include a new: called List Compression. Possibilities for an opaque ID include a # Typo fix An intermediate node receiving a request from another node MUST return a response to this request with a destination list equal to the concatenation of the Node-ID of the node that sent the request with the via list in the request. The intermediate node normally # 1.) unclear why an _intermediate_ peer should return a response # (if it is not the destination node), # 2.) the via list must be reversed before concatenating the Node-ID # so: old: with the via list in the request. The intermediate node normally new: with the reversed via list in the request. The intermediate node normally sec. 6.1.3. =========== old: compressed via list), the peer MUST replace that entry with the original via list that it replaced and then re-examine the new: compressed via list), the peer MUST replace that entry with the reversed original via list that it replaced and then re-examine the # the via list must be reversed for responses... sec. 6.2. ========= old: This Section defines RELOAD's Symmetric Recursive Routing (SRR) algorithm, which is the default algorithm used by nodes to route messages through the overlay. All implementations MUST implement this routing algorithm. An overlay MAY be configured to use alternative routing algorithms, and alternative routing algorithms MAY be selected on a per-message basis. I.e., a node in an overlay which supports SRR and some other routing algorithm called XXX might use SRR some of the time and XXX some of the time. new: This Section defines RELOAD's Symmetric Recursive Routing (SRR) mode, which is the default mode used by nodes to route messages through the overlay. All implementations MUST implement this routing mode. An overlay MAY be configured to use alternative routing modes, and alternative routing modes MAY be selected on a per-message basis. I.e., a node in an overlay which supports SRR and some other routing mode called XXX might use SRR some of the time and XXX some of the time. # better use mode for consistency (algorithm is contained in the # topology plugin sec. 6.2.1. =========== old: node MAY also construct a more complicated destination list for source routing. new: node MAY also construct a more complicated destination list for (loose) source routing. Once the message is constructed, the node sends the message to some adjacent peer. If the first entry on the destination list is directly connected, then the message MUST be routed down that connection. Otherwise, the topology plugin MUST be consulted to determine the appropriate next hop. # adjacent peer should be adjacent node, since it may be a client # directly connected means: a valid entry in the Connection Table # exists? this should be mentioned here... sec. 6.2.2. =========== # a hint that the same Transaction-ID as in the request MUST be used # could be added. sec. 6.3.1.1. ============= Unless a given structure that uses a select explicitly allows for unknown types in the select, any unknown type SHOULD be treated as an # How is that allowance specified in the specification? Is it by the comment # /* This structure can be extended */ sec. 6.3.2. =========== receive message with a TTL greater than the current value of initial-ttl (or the 100 default) MUST discard the message and send an "Error_TTL_Exceeded" error. # what if the initial-ttl is larger than 100 and the TTL is >100 but # < initial-ttl? The condition "or the 100 default" holds old: used to indicate the fragment offset; see Section 6.7. new: used to indicate the fragment offset in bytes; see Section 6.7. old: length: The count in bytes of the size of the message, including the header. new: length: The count in bytes of the size of the whole unfragmented message, including the header. # as already mentioned in the beginning this should be more precise destinations which the message should pass through. The destination list is constructed by the message originator. The # is it allowed that intermediate peers add destinations? if not, please # state so old: next. The list shrinks as the message traverses each listed peer. new: next. The list may shrink as the message traverses each listed peer. # it need not be always the case that the list shrinks with each traversed peer sec. 6.3.2.2. ============= old: structure with a DestinationType of opaque_id_type and a opaque_id new: structure with a DestinationType of opaque_id_type and an opaque_id # typo fix old: opaque A compressed list of Node-IDs and an eventual Resource-ID. Because this value was compressed by one of the peers, it is only meaningful to that peer and cannot be decoded by other peers. Thus, it is represented as an opaque string. resource The Resource-ID of the resource which is desired. This type MUST only appear in the final location of a destination list and MUST NOT appear in a via list. It is meaningless to try to route through a resource. new: resource The Resource-ID of the resource which is desired. This type MUST only appear in the final location of a destination list and MUST NOT appear in a via list. It is meaningless to try to route through a resource. opaque_id_type A compressed list of Node-IDs and an eventual Resource-ID. Because this value was compressed by one of the peers, it is only meaningful to that peer and cannot be decoded by other peers. Thus, it is represented as an opaque string. # 1.) match the order in the select # 2.) it must be opaque_id_type, not opaque sec. 6.3.2.3 ============ flags Three flags are defined FORWARD_CRITICAL(0x01), DESTINATION_CRITICAL(0x02), and RESPONSE_COPY(0x04). These flags MUST NOT be set in a response. If the FORWARD_CRITICAL flag is # What is the correct reaction if these flags are set in a response? # (returning an Error_Invalid_Message or ignore?) sec. 6.3.3.1 ============ old: A node processing a request MUST return its status in the message_code field. If the request was a success, then the message new: A node processing a request MUST return its status in the message_code field of a response. If the request was a success, then the message # clarification? Error_Request_Timeout: A response to the request has not been received in a suitable amount of time. The requesting node MAY resend the request at a later time. # not clear when this will ever be used. Which node should send # this error message? All RELOAD messages MUST be signed. Intermediate nodes do not verify signatures. Upon receipt (and fragment reassembly if needed) the destination node MUST verify the signature and the authorizing certificate. If the signature fails, the implementation SHOULD simply drop the message and MUST NOT process it. This check provides # What happens if none {0,0} is given? Then no Node-ID is present... sec. 6.4.2. =========== What happens if these messages (like Join, Leave) are accidentally sent to a Client? Do the send an Invalid Message back? A new peer (but one that already has credentials) uses the JoinReq message to join the overlay. The JoinReq is sent to the responsible peer depending on the routing mechanism described in the topology Is the destination address now the Resource-ID or the Node-ID of the "responsible peer"? Because joins may only be executed between nodes which are directly adjacent, receiving peers MUST verify that any JoinReq they receive # 1.) should be peers rather than nodes # 2.) directly adjacent means here: directly adjacent in the overlay # topology (could otherwise be misunderstood as being directly # connected) # 3.) what must happen if the verification fails? adjacent, receiving peers MUST verify that any LeaveReq they receive arrives from a transport channel that is bound to the Node-ID to be # what happens if that verification fails? old: assumed by the leaving peer.) This also prevents replay attacks new: assumed by the leaving peer. This also prevents replay attacks # Typo fix sec. 6.4.2.3 ============ the state change. In general, peers send Update messages to all their adjacencies whenever they detect a topology shift. # A hint to the Connection Table and Clients would clarify sec. 6.4.2.4. ============= old: X. A RouteQuery can also request that the receiving peer initiate an new: X. A RouteQuery can also request that the receiving peer initiates an old: One important use of the RouteQuery request is to support iterative routing. The sender selects one of the peers in its routing table # add reference to Section 3.3. sec. 6.4.2.4.1 ============== destination The destination which the requester is interested in. This may be any valid destination object, including a Node-ID, opaque ID, or Resource-ID. # Does opaque ID make sense here? sec. 6.5.1 ========== A node sends an Attach request when it wishes to establish a direct TCP or UDP connection to another node for the purpose of sending # TCP/TLS or DTLS? old: node A has Attached to node B, but not received any Updates from B, new: node A has attached to node B, but not received any Updates from B, # Typo channel but MUST NOT route messages through B to other peers via that channel. The process of Attaching is separate from the process of # Is that also true for clients? sec. 6.5.1.1 ============ old: } AttachReqAns; The values contained in AttachReqAns are: new: } AttachReq; The values contained in AttachReq are: old: A single AttachReqAns MUST NOT include both candidates whose new: A single AttachReq MUST NOT include both candidates whose # consistency! sec. 6.5.1.2. ============= old: 6.5.1.2. Response Definition new: 6.5.1.2. Response Definition The AttachAns message hast the same format as the AttachReq message. #s/AttachReqAns/AttachAns/ in the whole paragraph. sec. 6.5.1.3. ============= An agent follows the ICE specification as described in [RFC5245] with # agent was not defined in the RELOAD context so far. sec. 6.5.4.2. ============= old: o The configuration document is correctly digitally signed (see Section 11 for details on signatures. new: o The configuration document is correctly digitally signed (see Section 11 for details on signatures). old: one listed in the current configuration file). Details on kind- signer field in the configuration file is described in Section 11.1. new: one listed in the current configuration file). Details on kind- signer field in the configuration file are described in Section 11.1. # typos sec. 6.6.2 ========== old: Each connection has it own sequence number space. Initially the new: Each connection and direction has it own sequence number space. Initially the sec. 6.6.3.1 ============ A node MUST NOT have more than one unacknowledged message on the DTLS connection at a time. Note that because retransmissions of the same message are given new sequence numbers, there may be multiple unacknowledged sequence numbers in use. # Since retransmissions violate the first sentence, it may be better # to use: old: A node MUST NOT have more than one unacknowledged message on the DTLS connection at a time. Note that because retransmissions of the same new: A node MUST NOT have more than one unacknowledged message on the DTLS connection at a time, except for retransmissions. Note that because from the routing table. The link MAY be restored to the routing table if ACKs resume before the connection is closed, as described # this should read Connection Table twice? sec. 6.7 ========= and fragments it, each fragment has a full copy of the Forwarding # 1.) clarification would be good that the length field is covering the # total msg length and which field are different in the "copies" # (at least the fragment field) # 2.) what happens if overlapping fragments are received? Feedback on sections 7 and greater will follow in a separate mail later today. Regards, Roland From internet-drafts@ietf.org Wed Feb 20 17:37:38 2013 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 2CE4A21F8CEC; Wed, 20 Feb 2013 17:37:38 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ad-acNu-1yH3; Wed, 20 Feb 2013 17:37:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A2221F8CF2; Wed, 20 Feb 2013 17:37:37 -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: 4.40 Message-ID: <20130221013737.2838.85478.idtracker@ietfa.amsl.com> Date: Wed, 20 Feb 2013 17:37:37 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-base-25.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: Thu, 21 Feb 2013 01:37:38 -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 Protocol = 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-25.txt Pages : 174 Date : 2013-02-20 Abstract: 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 needs to 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-base There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-base-25 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-base-25 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From dean.willis@softarmor.com Wed Feb 20 21:03:29 2013 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 4F0EF21F87CD for ; Wed, 20 Feb 2013 21:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.89 X-Spam-Level: X-Spam-Status: No, score=-101.89 tagged_above=-999 required=5 tests=[AWL=-0.725, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QcArZwTmAFv for ; Wed, 20 Feb 2013 21:03:27 -0800 (PST) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by ietfa.amsl.com (Postfix) with ESMTP id A4A1821F87B3 for ; Wed, 20 Feb 2013 21:03:27 -0800 (PST) Received: by mail-vb0-f45.google.com with SMTP id p1so5523003vbi.18 for ; Wed, 20 Feb 2013 21:03:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=cSU51/8MDUngZRCpsoDKxPU8fQNiOzwwA1YOGw/TY7g=; b=S/qtE+x6SiUagp7PoQJ7QLVa2Kw/d7VDguznUuCD+TKVDpDjWEg0lKMss3aIEC4x8c 4ukSLF7LdGN99TCtxU1ICwlxm6dex8y7TMBxK9jHI+c8ZLTqy5PZ+1PXPsogpOC2/RHa 3lpsikZIUIgtDYoLtzjcHyo4QYK7vsXX8Tl84= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=cSU51/8MDUngZRCpsoDKxPU8fQNiOzwwA1YOGw/TY7g=; b=DQJMMfFfnmQ1xKVzl1+u6Mta4R8CceLw6m2Xm7mZlv4Z3vxNin8aHG+lOsI8kSZcRe 2mK0fg/UflhbzlnLtk62tChn3PYEsKzdSAUOzBrkFHvKHmWwMWlZur5MYPs5bGr9fKm6 4aAtgabrGwC4SECXePp40o4bB0co5+xSDu+K8SvBMwsDo/E/quYYXUnI3QmHPdo4H2+Z UOPc2/B2aWHw2XoHtUWymHiQLS6Qx5YCHvYj3wDCburPavBETzEzAPd3qifUoS8Lab3Y 3n8xntfp3pAMw0dppOKusIqPj0ixHmUQzX/41ZiJY6BjRvqYjNdCcY94b+Rw8/1s6poE kuWA== MIME-Version: 1.0 X-Received: by 10.52.21.8 with SMTP id r8mr13210476vde.130.1361423006841; Wed, 20 Feb 2013 21:03:26 -0800 (PST) Received: by 10.58.46.17 with HTTP; Wed, 20 Feb 2013 21:03:26 -0800 (PST) Date: Wed, 20 Feb 2013 23:03:26 -0600 Message-ID: From: Dean Willis To: p2psip-chairs@tools.ietf.org, iesg@iesg.org, p2psip@ietf.org, Marc Petit-Huguenin , Cullen Jennings , Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQltJ7ldegAD3sj37oQIWfZMqDK89qAAgXMlphnv4dvelI89vBnF5CNlaDEBGpdcwqTO5PZc Subject: [P2PSIP] Revisions to draft-ietf-p2psip-base-24 made in response to 2nd IETF LC 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, 21 Feb 2013 05:03:29 -0000 a 2nd IETF last call closed on this document Tuesday. Following IETF LC, changes have been made to the draft-ietf-pp2psip-base document to accommodate tha majority of critical comments made during the IETF LC period. It should be noted that additional comments were following IETF LC received from Roland Bless and Polina Goltsman. The latter of these was quite lengthy, running to approximately one hundred twenty three points, and the contributor will be added to the Acknowledgements. The editorial team extracted what appeared to be the most critical of these and made textual modifications as needed. Work is continuing on the remainder; they are believed to be nits of the "a" versus "an" level; worth doing, but not affecting IESG review. We expect to provide these before submission to the RFC Ed. Revisions are described below. IANA Considerations: -------------------------------- 1) Text in 14.7 saying "Code points in this registry" was replaced with "New entries in this registry", as they aren't code points. 2) Text added in 14.10 clarifying that the entries in this registry are 8-bit integers (0-255) as described in 6.5.1.1 This should not impact IANA actions. Pete Resnick - ------------ 1) "6.3.4 - No discussion of wildcard in this section. Does there need to be?" Because 6.3.4 is the section about SecurityBlock, I guess that "wildcard" refers to wildcard certificate. It is not possible to define a wildcard RELOAD certificate because neither the reload URI or the rfc822Name supports a wildcard, but under the current rules, there is nothing that prevents adding a dns: to the SAN or a wildcard to the subject. So to remove ambiguity, the following text was added in section 11.3: "The SubjectAltName field in the certificate MUST NOT contain any other identities than listed above. The subject distinguished name in the certificate MUST be empty." 2) "6.5 - Not clear to me why this document settles on ICE (or anything lower layer). Seems like it could have been abstracted out and left to a different layer. I'm kind of disappointed that all of section 6.5 (and maybe sections 6.6 and 9) is not a separate document. (I understand that this is the WG wanted to do it. Just registering my complaint, but I won't make a fuss.)" No change. We sympathize with Pete's desire to layer things differently, but ... Stephen Farrell - --------------- 3) "I do have one question: is the overlay-reliability-timer in the configuration defined in 11.1 supposed to override the "15 second" timer ("Maximum Request Lifetime") defined in section 2 and and used in various places, if the value of the overlay-reliability-timer is more than 15000?" The definition was modified like this: "Maximum Request Lifetime: The maximum time a request will wait for a response. This value is equal to the overlay-reliability-timer value defined in Section 11.1 multiplied by the number of transmissions, as defined in Section 6.2.1, and so defaults to 15 seconds." Stewart Bryant - -------------- 4) "I understand that the example using port "6100" is an error and will be corrected in the next version to the assigned port." The text was modified like this: "...As an example, here is the wire representation of the IPv4 address "192.0.2.1" with port "6084". 01 ; type = IPv4 06 ; length = 6 c0 00 02 01 ; address = 192.0.2.1 17 c4 ; port = 6084" Wesley Eddy - ----------- 5) "The document seems to be schizophrenic about Head of Line blocking. The section 6.5.1.6 text on why TCP is not a desirable Overlay Link Protocol notes Head of Line blocking as the primary reason to prefer another protocol, yet the stop and wait algorithm in 6.6.3.1 for use over DTLS, says that only one message can be unacknowledged at a time, so it's unclear how this avoid Head of Line blocking issues (if at all). It seems like you seay HoL issues are worth avoiding, and then define operation only over transports with HoL issues (TCP and the DTLS-based ones)." The following text was added in 6.5.1.6.: "Note that none of the protocols defined in this document meets these conditions, but it is expected that new Overlay link protocols defined in the future will fill this gap." Also two new Overlay Link protocols using SCTP are defined in a newly published draft (draft-petithuguenin-p2psip-reload-sctp). 6) "As noted by Michael Scharf, the RTO computation text in section 5.6.3.1.1 has a confused (or confusing) citation of RFC 6298 and may lead to instability in presence of RTT variations." (That an old discuss but the modification never went into the document) The new text is: "overlay-reliability-timer Default value for the end-to-end retransmission timer for messages, in milliseconds. If not present, the default value is 3000. The value MUST be at least 200 milliseconds, which means the minimum time delay before dropping a link is 1000 milliseconds." Russ Housely: -------------------- Address comments from revised Gen-Art review by Mary Barnes 1) Gen-Art Comment: In Section 11.5, 3rd para, the document says: "it can note the Node-ID in the response and use this Node-ID to start sending requests". Is the use of the Node-ID MAY or a MUST? There was no section 11.5 in -24; the text in question is in 11.4 The text has been revised as: When contacting a bootstrap node, the joining node MUST first form the DTLS or TLS connection to the bootstrap node and then send an Attach request over this connection with the destination Resource-ID set to the joining node's Node-ID. 2) Gen-Art Comment: Section 1.2.1, 2nd paragraph: I don't understand the example as to why a single application requires multiple usages - i.e, why voicemail? Isn't the intent to say that an application might need to use both SIP and XMPP - i.e., you wouldn't define a "usage" for an application, would you? [While Cullen responded to this comment with an explanation, there was no change to clarify the text and Marc's response didn't help clarify my concern]" -24 text: The architecture diagram shows both a SIP usage and an XMPP usage. A single application may require multiple usages; for example a softphone application may also require a voicemail usage. A usage may define multiple Kinds of data that are stored in the overlay and may also rely on Kinds originally defined by other usages. -25 text: The architecture diagram shows both a SIP usage and an XMPP usage. A single application may require multiple usages; for example a voicemail feature in a softphone application that stores links to the messages in the overlay would require a different usage than the type of rendezvous service of XMPP or SIP. A usage may define multiple Kinds of data that are stored in the overlay and may also rely on Kinds originally defined by other usages. The example here is that single application (e.g., a softphone application) might require multiple RELOAD usages, (e.g, one RELOAD usage for storing voicemail and another RELOAD usage for SIP rendezvous services). We think the text is adequately clear. 3) Gen-Art comment: Section 3.3, 2nd paragraph after the capability bullet list, next to last sentence. There is at least an article missing from this sentence and it reads rather awkwardly. Perhaps changing to something like: OLD: If there is a failure on the reverse path caused by topology change since the request was sent, this will be handled by the end-to-end retransmission of the response as described in Section 6.2.1. NEW: Note that a failure on the reverse path caused by a topology change after the request was sent, will be handled by the end-to-end retransmission of the response as described in Section 6.2.1." Text was revised to: Note that a failure on the reverse path caused by a topology change after the request was sent will be handled by the end-to-end retransmission of the response as described in Section 6.2.1. 4) Gen-Art Comment: "- [-17] Section 3.3, last paragraph. Add a reference to 5.4.2.4 after "RouteQuery method"" Reference was added in -25 5) Gen-Art Comment: Section 3.4, last paragraph, 3rd sentence: "that the specified by the algorithm" should be something like "than specified by the algorithm"." Revised text: However, a peer needs to try to maintain the specified Routing Table defined by the topology plugin algorithm and needs to form new connections if it detects that it has fewer direct connections than specified by the algorithm. 6) Gen-Art Comment Section 6.6: All my previous concerns were addressed, except, the Note to implementors paragraph still seems out of context - it should be deleted or this section should be restructured so it is in context. Text was restructured in -25 7) Gen-Art Comment Section 12, Second paragraph, 3rd sentence says that "It gets routed to the admitting peer (AP), yet the flow shows that the message first gets routed to the PP and then onto AP. It would be helpful if that were clarified. [Note: Marc's response indicated that he thought this was fixed in the -23, however, the diff shows no changes to that specific text between the -17 and the -24 ]" The call flow diagram was revised to match the text. 8) Gen-Art Nits "- Section 1.2.5, 2nd para, last sentence: this sentence is a bit tough to interpret on a first read. I would suggest rewording something like the following: OLD: This layer is to the Message Transport Layer as link- level congestion control and retransmission in modern wireless networks is to Internet transport protocols. NEW: The relation of this layer to the Message Transport Layer "is similar to"|"can be likened to" the relation of the link- level congestion control and retransmission in modern wireless networks to Internet transport protocols. Section 3.4, last paragraph, 4th sentence: "in accord" -> "in accordance" Section 10.1, 2nd paragraph, 5th sentence: "can be thought of a doubly-linked list" -> "can be thought of as a doubly-linked list" Section 15, last paragraph: "help resolve" -> "helped resolve"" Text was modified as suggested. Roland Bless -------------------- 1) Under 10.5 Joining, add forward reference to 11.4 Revised: JN MUST connect to its chosen bootstrap node as specified in Section 11.4. 2) in 10.5 element 2, change "Acquire the routing table for" to "Acquire the routing table of". Done. 3) in 10.5 element 3: JP SHOULD send Attach requests to initiate connections to each of the peers in the neighbor table as well as to the desired finger table entries. Note that this does not populate their routing tables, but only their connection tables, so JP will not get messages that it is expected to route to other nodes." here it is unclear that the Attach requests are sent via the AP and what "desired" finger table entries means, e.g., in contrast to all?" Revised to: 3. JN SHOULD send Attach requests to initiate connections to each of the peers in the Neighbor Table as well as to the desired Finger Table entries. Note that this does not populate their Routing Tables, but only their Connection Tables, so JN will not get messages that it is expected to route to other nodes. 4) Sec. 10.7.2.: "If a finger table entry is found to have failed," how is it determined to have "failed"? 10.7.1 is only related to neighbor failures...does the same definition apply here?" Copied definition from 10.7.1 to 10.7.2:; 10.7.2. Handling Finger Table Entry Failure If a Finger Table entry is found to have failed (as determined by connectivity pings or the failure of some request), all references to the failed peer MUST be removed from the Finger Table and replaced with the closest preceding peer from the Finger Table or Neighbor Table. 5) Sec: 10.7.4.2.: "A peer SHOULD NOT send Ping requests looking for new finger table entries more often than the configuration element "chord-ping- interval", which defaults to 3600 seconds (one per hour)." This paragraph should probably moved some paragraphs down as it has been stated yet that a peer should actually send Ping requests at all (this is explained in the subsequent paragraphs)." Restructured as suggested. 6) Sec 12: throughout the figures: "Update" should be "UpdateReq" and Attach should be AttachReq?" Revised as suggested. 7) Inconsistent capitalization of Neighbor Table and Connection Table Reviewed for consistency. Polina Goltsman ------------------------ 1) PG Major issue 1: sec. 6.3.2: length field in Forwarding Header covers what exactly? it is not really clear whether the length field counts the whole message or in case of fragmentation only the fragment size. When reading Sec 6.7 is seems that the former is meant, but the definition could and should be clearer. Similarly, sec. 6.7 should be clear about this, e.g., describing that all Forwarding Headers are identical for fragments of the same message with exception of the fragment field. Revised: Any node along the path can fragment the message but only the final destination reassembles the fragments. When a node takes a packet and fragments it, each fragment has a full copy of the Forwarding Header but the data after the Forwarding Header is broken up in appropriate sized chunks. The size of the payload chunks needs to take into account space to allow the via and destination lists to grow. Each fragment MUST contain a full copy of the via list, destination list, and ForwardingOptions and MUST contain at least 256 bytes of the message body. If these elements cannot fit within the MTU of the underlying datagram protocol, RELOAD fragmentation is not performed and IP-layer fragmentation is allowed to occur. The length field MUST contain the size of the message after fragmentation. When a message MUST be fragmented, it SHOULD be split into equal-sized fragments that are no larger than the PMTU of the next overlay link minus 32 bytes. This is to allow the via list to grow before further fragmentation is required. 2) PG Major issue 2: sec. 7.4.1.1: replica number handling is unclear it is unclear how replica numbers are incremented (e.g., per peer) and what receiving peers should actually do with this number. Is it important to store the value or would a boolean be sufficient so that the peer knows that it's a replica?" Revised: Added text explaining that replica numbers are allocated and interpreted by the topology plugin. Explained how CHORD-RELOAD interprets the replica numbers. 3) PG Minor issue 1: Resource-ID used before introduction Added explicative text in 1.1: The RELOAD network is not only a messaging network. It is also a storage network, albeit one designed for small-scale transient storage rather than for bulk storage of large objects. Records are stored under numeric addresses, called Resource-IDs, which occupy the same space as node identifiers. Peers are responsible for storing the data associated with some set of addresses as determined by their Node-ID. For instance, we might say that every peer is responsible for storing any data value which has an address less than or equal to its own Node-ID, but greater than the next lowest Node-ID. Thus, Node-20 would be responsible for storing values 11-20 4) PG Minor Issue 2: Language in Forwarding and Link Management Layer definition clumsy. Revised as suggested to: Forwarding and Link Management Layer: Stores and implements the Routing Table by providing packet forwarding services between nodes. It also handles establishing new links between nodes, including setting up connections for overlay links across NATs using ICE. 5) PG Minor Issue 3: Change "link layer" to "overlay link layer" in definition of "overlay link layer". Changed as suggested. 6) PG Minor Issue 4: Add "may" to last para of 1.2 Changed "nodes communicate with a central provisioning infrastructure" to "nodes may communicate with a central provisioning infrastructure" 7) PG Minor Issue 5: in 1.3 change TLS-PSK to TLS-PSK/TLS-SRP Done. 8) PG Minor Issue 6: Change in Terminology definition Changed "Terms in used this document are defined inline when used" to "Terms in this document are defined inline when used" 9) PG Minor Issue 7: Definition of Bootstrap node Was: Bootstrap Node: A network node used by Joining Nodes to help locate the Admitting Peer Suggested change: Bootstrap Node: A network node used by Joining Nodes to help accessing the overlay by forwarding messages to peers Retained original definition following review between editors and authors. 10) PG Minor Issue 8: Clarify definition of Connection Table Changed as suggested to: Connection Table: Contains connection information for the set of nodes to which a node is directly connected, which include nodes that are not yet available for routing. 11) PG Minor Issue 9: Clarify "invalid" in definition of Node-OD New text: Node-ID: A value of fixed but configurable length that uniquely identifies a node. Node-IDs of all 0s and all 1s are reserved; a value of zero is not used in the wire protocol but can be used to indicate an invalid node in implementations and APIs; the Node-ID of all 1s is used on the wire protocol as a wildcard. 12) PG Minor Issue 10: Change "plugin algorithm" to "topology plugin algorithm" in definition of Responsible Peer. Changed as suggested. 13) PG Minor Issue 11: Change "An Usage" to "A Usage" in definition of Usage Changed as suggested. There were also several small changes made as discussed on the P2PSIP mailing list. From dean.willis@softarmor.com Wed Feb 20 21:13:17 2013 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 0F83321E8091 for ; Wed, 20 Feb 2013 21:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.683 X-Spam-Level: X-Spam-Status: No, score=-101.683 tagged_above=-999 required=5 tests=[AWL=-0.518, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8msgM0+5jL9 for ; Wed, 20 Feb 2013 21:13:15 -0800 (PST) Received: from mail-vb0-f47.google.com (mail-vb0-f47.google.com [209.85.212.47]) by ietfa.amsl.com (Postfix) with ESMTP id DB5D421F841D for ; Wed, 20 Feb 2013 21:13:14 -0800 (PST) Received: by mail-vb0-f47.google.com with SMTP id e21so5441939vbm.20 for ; Wed, 20 Feb 2013 21:13:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=OkAoyBTz/S4INEJQMwDFfQL0cEtQsmavOfp+pOlyqp0=; b=DJ36CsGjis/gSTMZDTrt6/QK2AHh0PikpRM4ODTFh++nqThl5J21fS42SXuFmTjONz 26nTZEgNpr6I0VtJtol6MC4/9YsFt2+twTnfZj5CbgM2NYk0u2G/QMlYFjNBC+aLRNtS u7hykqTyWFtLziV6mmPtfAz917J34eDM8MNC4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=OkAoyBTz/S4INEJQMwDFfQL0cEtQsmavOfp+pOlyqp0=; b=i6cUutiiFfg21w8LZcTF9ytb9DR6xctPs2wOBK+Brj0/VEn7mUsbPFPffagZij8WNb qJtnl4zvaWM+R/CQV8Msgbgcd729iIX2lfnbqu0pac13rwCjzPka8DzwlmgbaufmaZ+R U254Qwt1tIet5zI6F35FVppHRoZzRkMNYJoBnRk765tIjBkVHkWDS7jPrpNEIZxDtqRY eZnwzWu8Vc0gBn/8J1ii6abTiVnz9F5V7jOdFProdNg2XkGz+RQF/IwN9SYoNdmfkDJS q3M2BGrZBY101P3pfmqM/8mnKPi8upFj9RvBhhQQUVD8ZDxZ/XZcRTyzuclFR6Id937e AQNQ== MIME-Version: 1.0 X-Received: by 10.52.67.164 with SMTP id o4mr25351275vdt.42.1361423594098; Wed, 20 Feb 2013 21:13:14 -0800 (PST) Received: by 10.58.46.17 with HTTP; Wed, 20 Feb 2013 21:13:14 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Feb 2013 23:13:14 -0600 Message-ID: From: Dean Willis To: p2psip@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkiBr7WzKApCwfqso+eWuRemptH+7kDBzgA6RdMx1vkzHTpfP2Cu7L2vfWYhl1sDGryct6y Subject: Re: [P2PSIP] Roland Bless's IETF LC Comments on draft-ietf-p2psip-base 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, 21 Feb 2013 05:13:17 -0000 Well, that was redundant; Roland already sent it to the list. Never mind! Concentrate on the changes we made in response instead.... On Wed, Feb 20, 2013 at 5:55 PM, Dean Willis wrote: > For your entertainment. > > > ---------- Forwarded message ---------- > From: Roland Bless > Date: Tue, Feb 19, 2013 at 8:32 PM > Subject: Re: [P2PSIP] Last Call: > (REsource LOcation And Discovery (RELOAD) Base Protocol) to Proposed > Standard > To: IETF Discussion > Cc: p2psip@ietf.org, "iesg@ietf.org" > > > Hi, > > On 06.02.2013 05:21, The IESG wrote: >> The IESG has received a request from the Peer-to-Peer Session Initiation >> Protocol WG (p2psip) to consider the following document: >> - 'REsource LOcation And Discovery (RELOAD) Base Protocol' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2013-02-19. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. > > Sorry for the late comments, but I re-read the whole draft which took > some time. There are still some clarifications > necessary as well as some inconsistencies left. > Unfortunately, my comments from June, 19th were not addressed yet. > https://www.ietf.org/mail-archive/web/p2psip/current/msg06229.html > > Polina Goltsman also found many issues listed below while working on an > implementation. The list is long, but the good news is that it's > mainly clarifications that are missing. > > Major issues: > > 1) sec. 6.3.2: > length field in Forwarding Header covers what exactly? it is not > really clear whether the length field counts the whole message or in > case of fragmentation only the fragment size. When reading Sec 6.7 is > seems that the former is meant, but the definition could and should be > clearer. Similarly, sec. 6.7 should be clear about this, e.g., > describing that all Forwarding Headers are identical for fragments of > the same message with exception of the fragment field. > > 2) sec. 7.4.1.1: replica number handling is unclear > it is unclear how replica numbers are incremented (e.g., per > peer) and what receiving peers should actually do with this number. > Is it important to store the value or would a boolean be sufficient > so that the peer knows that it's a replica? > > 3) sec. 6.5.2: transport protocol set for AppAttach > Applications may require use of other transport protocols than > those defined in OverlayLinkType (TLS/DTLS, what about plain UDP, > SCTP, DCCP, etc.), > but currently, this seems to be not possible (do the considerations > of sec. 6.5.1.6 > apply here?). > > 4) sec. 6.3.4: > How can a different signature algorithm be used if not all > implementations > support it? There is no possibility to provide the feedback, that the > signature algorithm is not acceptable at a particular node. > > 5) sec. 10.5: handling of parallel JOIN requests and use of peer_ready > it is not clear what should happen if two JNs try to join at the same > time at the same AP (can they be processed in parallel or should they > be processed in sequence). > Furthermore, when MUST/SHOULD a JN send peer_ready Update - in step 9? > > > Minor issues: > citations are put first, followed by comments starting with # > > sec. 1.1 > ======== > old: > storage rather than for bulk storage of large objects. Records are > stored under numeric addresses which occupy the same space as node > new: > storage rather than for bulk storage of large objects. Records are > stored under numeric addresses, called Resource-IDs, which occupy > the same space as node > > # Resource-IDs are used in 1.2.2 but not introduced > > sec. 1.2 > ======== > Message Transport: Handles end-to-end reliability, manages request > ... > > # What are the interactions with Forwarding and Link Management and > the Topology Plugin > > old: > Forwarding and Link Management Layer: Stores and implements the > routing table by providing packet forwarding services between > nodes. It also handles establishing new links between nodes, > including setting up connections across NATs using ICE. > > # It may be confusing to say "routing table" here, since this > # is usually associated with the topology plugin. So IMHO > # it is the Connection Table, not the routing table. > # Furthermore, I propose the following change: > old: > including setting up connections across NATs using ICE. > new: > including setting up connections for overlay links across > NATs using ICE. > > old: > directly between nodes. TLS [RFC5246] and DTLS [RFC6347] are the > currently defined "link layer" protocols used by RELOAD for hop- > new: > currently defined "overlay link layer" protocols used by RELOAD > for hop- > > # avoids confusion with the classic ISO/OSI link layer (layer 2) > > old: > In addition to the above components, nodes communicate with a central > new: > In addition to the above components, nodes may communicate with a central > > # while it may be the default case, it is not strictly required > > sec. 1.3 > ======== > old: > RELOAD also provides an optional shared secret based admission > control feature using shared secrets and TLS-PSK. In order to form a > new: > RELOAD also provides an optional shared secret based admission > control feature using shared secrets and TLS-PSK/TLS-SRP. In order to > > # TLS-SRP should be mentioned here, too > > sec. 2 > ====== > old: > Terms used in this document are defined inline when used and are also > new: > Terms in this document are defined inline when used and are also > > # avoid double "used" > > old: > Bootstrap Node: A network node used by Joining Nodes to help locate > the Admitting Peer. > new: > Bootstrap Node: A network node used by Joining Nodes to help accessing > the overlay by forwarding messages to peers. > > # The bootstrap node does not locate the Admitting Peer, but the JN locates > # the AP by routing a message to its own Resource-ID > > old: > Connection Table: The set of nodes to which a node is directly > connected, which include nodes that are not yet available for > routing. > new: > Connection Table: Contains connection information for the set of > nodes to which a node is directly connected, which include nodes > that are not yet available for routing. > > # it is a data structure ... > > Node-ID: A value of fixed but configurable length that uniquely > identifies a node. Node-IDs of all 0s and all 1s are reserved and > are invalid Node-IDs. A value of zero is not used in the wire > protocol but can be used to indicate an invalid node in > implementations and APIs. The Node-ID of all 1s is used on the > wire protocol as a wildcard. > > # what means "invalid" exactly? A wildcard can be used at least on > # the wire so it is not invalid being used as destination Node-IDs. > # So the above definition is slightly contradictory. > > old: > Responsible Peer: The peer that is responsible for a specific > resource, as defined by the plugin algorithm. > new: > Responsible Peer: The peer that is responsible for a specific > resource, as defined by the topology plugin algorithm. > > old: > Usage: An usage is the definition of a set of data structures (data > Kinds) that an application wants to store in the overlay. An > usage may also define a set of network protocols (application IDs) > new: > Usage: A usage is the definition of a set of data structures (data > Kinds) that an application wants to store in the overlay. A > usage may also define a set of network protocols (application IDs) > > # Typo: 2x An usage -> A usage > > sec. 3.1 > ======== > old: > o To determine its position in the overlay topology (if the overlay > is structured; topology plugins do not need to be structured). > new: > o To determine its position in the overlay topology (if the overlay > is structured; overlays do not need to be structured). > > # a structured topology plugin is not the same as a structured overlay > > o To determine the set of resources for which the node is > responsible. > > # this isn't necessarily true for unstructured overlays? > > old: > The general principle here is that the security mechanisms (TLS at > new: > The general principle here is that the security mechanisms ((D)TLS at > > sec. 3.2 > ======== > entity. From the perspective of a peer, a client is a node that has > connected to the overlay, but has not yet taken steps to insert > > # an additional reference to the Connection Table would be nice > > sec. 3.2.1 > ========== > clients that choose this option need to process Update messages > > # Update messages are not introduced yet, so a forward reference to > # section 6.4.2.3 would be helpful > > performing an Attach. A client wishing to connect using this > mechanism with a certificate with multiple Node-IDs can use a Ping > (Section 6.5.3) to probe the Node-ID of the node to which it is > connected before doing the Attach (Section 6.5.1). > > # At this point it is not really clear why this step is necessary. > # Certificates with multiple Node-IDs were not explained yet. > # Furthermore, the reference to Section 6.5.1 should be moved > # to the previous sentence. > > sec. 3.3 > ======== > old: > This section will discuss the capabilities of RELOAD's routing layer, > new: > This section discusses the capabilities of RELOAD's routing layer, > > old: > Resource-based routing: RELOAD supports routing messages based > solely on the name of the resource. Such messages are delivered > new: > Resource-based routing: RELOAD supports routing messages based > solely on the name of the resource or Resource-ID. Such messages > > old: > Clients: RELOAD supports requests from and to clients that do not > participate in overlay routing, located via either of the > mechanisms described above. > new: > Clients: RELOAD supports requests from and to clients that do not > participate in overlay routing. > > # the addition is not really necessary and may be confusing > > old: > Destination Lists: While in principle it is possible to just > inject a message into the overlay with a single Node-ID as the > new: > Destination Lists: While in principle it is possible to just > inject a message into the overlay with a single Node-ID or > a single Resource-ID as the > > # Resource-ID is also a possible destination > > old: > The basic routing mechanism used by RELOAD is Symmetric Recursive. > new: > The basic routing mode used by RELOAD is Symmetric Recursive Routing > (SRR, > cf. Section 6.2) > > # I would prefer to use the term "mode" (as on p. 28) and it should be > # consistent with the text in section 6.2 > > old: > opaque ID X1 which maps internally to [A, B] (perhaps by being an > encryption of [A, B] and forwards to Z with only X1 as the via list. > new: > opaque ID X1 which maps internally to [A, B] (perhaps by being an > encryption of [A, B]) and forwards to Z with only X1 as the via list. > > # simple typo > > old: > RELOAD also supports a basic Iterative "routing" mode (where the > new: > RELOAD also supports a basic Iterative routing mode (where the > > old: > Iterative "routing" is implemented using the RouteQuery method, which > new: > Iterative routing is implemented using the RouteQuery method, which > > old: > requests this behavior. Note that iterative "routing" is selected > new: > requests this behavior. Note that Iterative routing is selected > > sec. 3.4 > ======== > > pairs. The result is a connection between A and B. At this point, A > and B MAY send messages directly between themselves without going > through other overlay peers. In other words, A and B are on each > other's connection tables. They MAY then execute an Update process, > > # MAY is RFC 2119 terminology, which is defined in section 5 > # Besides Update process a Join process is also possible. > > order to support this case, some small number of "bootstrap nodes" > typically need to be publicly accessible so that new peers can > > # what "publicly accessible" means exactly is not defined > # typically need to be publicly accessible (i.e., not behind a NAT or > # firewall) ... > > old: > The second case is when a client connects to a peer at an arbitrary > IP address, rather than to its responsible peer, as described in the > new: > The second case is when a client connects to a peer at an arbitrary > node-ID, rather than to its responsible peer, as described in the > > # since responsible peer may depend on the overlay topology, node-ID > # seems to be a better fit here > > sec. 3.5.2 > ========== > old: > When a new peer wishes to join the Overlay Instance, it will need a > Node-ID that it is allowed to use and a set of credentials which > new: > When a new peer wishes to join the Overlay Instance, it needs a > Node-ID that it is allowed to use and a set of credentials which > > # not really sure about this change as non-native speaker > > match that Node-ID. When an enrollment server is used, the Node-ID > used is the Node-ID found in the certificate received from the > > # the mode with self-signed certificates is missing and should be > # mentioned also here > > "bootstrap node". Because this is the first connection the peer > makes, these nodes will need public IP addresses so that they can be > > # may also work if the bootstrap node is directly reachable, e.g., > # in the same domain > # in this paragraph and the following paragraph "Once a peer" > # is used three times > > past adjacencies which have public IP address and attempt to use them > > # inconsistent use of term "adjacencies"/adjacent within the document > # different meanings as follows: > # 1.) all directly connected nodes (i.e., all nodes in the Connection > Table), e.g., sec. 3.5.2 and 6.4.2.3 > # 2.) all peers in the routing table > # 3.) adjacent according to the overlay topology, e.g. sec. 6.4.2.1 > > sec. 4 > ====== > limits on size, on the values which may be stored. For many Kinds, > the set may be restricted to a single value; some sets may be allowed > > # what set? > > sec. 4.1.2. > =========== > old: > responsibility if the responsible peer fail [Chord]. > new: > responsibility if the responsible peer fails [Chord]. > > sec. 6 > ====== > old: > messages. We then describe the symmetric recursive routing model, > which is RELOAD's default routing algorithm. We then define the > new: > messages. We then describe the symmetric recursive routing mode, > which is RELOAD's default routing mode. We then define the > > # IMHO the term mode fits best, the routing algorithm is defined > # within the topology plugin > > sec. 6.1. > ========= > old: > peer SHOULD generate an appropriate error but local policy can > new: > peer SHOULD generate an appropriate error message but local policy can > > Once the peer has determined that the message is correctly formatted > > # what does "correctly formatted" mean exactly? > > sec. 6.1.1. > =========== > this node so it MUST verify the signature as described in > Section 7.1 and MUST pass it up to the upper layers. "Upper > layers" is used here to mean the components above the "Overlay > Link Service Boundary" line in the figure in Section 1.2. > > # this is somewhat confusing. The text describes what the > # Forwarding and link management component does, but what > # other components are meant here? > > state, e.g., by unpacking any opaque IDS. > > # I think any is incorrect, since other IDs are > # not inserted by this node and so it cannot "unpack" those, > # but only its own opaque IDs > > sec. 6.1.2. > =========== > the first entry on the destination list is in the peer's connection > table, then it MUST forward the message to that peer directly. > > # This is probably motivated by clients. A hint to this fact > # may help. > > old: > destination list, it would detect that I is a opaque ID, recover the > new: > destination list, it would detect that I is an opaque ID, recover the > > # Typo fix > > old: > called List Compression. Possibilities for a opaque ID include a > new: > called List Compression. Possibilities for an opaque ID include a > # Typo fix > > An intermediate node receiving a request from another node MUST > return a response to this request with a destination list equal to > the concatenation of the Node-ID of the node that sent the request > with the via list in the request. The intermediate node normally > > # 1.) unclear why an _intermediate_ peer should return a response > # (if it is not the destination node), > # 2.) the via list must be reversed before concatenating the Node-ID > # so: > old: > with the via list in the request. The intermediate node normally > new: > with the reversed via list in the request. The intermediate node > normally > > sec. 6.1.3. > =========== > old: > compressed via list), the peer MUST replace that entry with the > original via list that it replaced and then re-examine the > new: > compressed via list), the peer MUST replace that entry with the > reversed original via list that it replaced and then re-examine the > > # the via list must be reversed for responses... > > sec. 6.2. > ========= > > old: > This Section defines RELOAD's Symmetric Recursive Routing (SRR) > algorithm, which is the default algorithm used by nodes to route > messages through the overlay. All implementations MUST implement > this routing algorithm. An overlay MAY be configured to use > alternative routing algorithms, and alternative routing algorithms > MAY be selected on a per-message basis. I.e., a node in an overlay > which supports SRR and some other routing algorithm called XXX might > use SRR some of the time and XXX some of the time. > new: > This Section defines RELOAD's Symmetric Recursive Routing (SRR) > mode, which is the default mode used by nodes to route > messages through the overlay. All implementations MUST implement > this routing mode. An overlay MAY be configured to use > alternative routing modes, and alternative routing modes > MAY be selected on a per-message basis. I.e., a node in an overlay > which supports SRR and some other routing mode called XXX might > use SRR some of the time and XXX some of the time. > > # better use mode for consistency (algorithm is contained in the > # topology plugin > > sec. 6.2.1. > =========== > old: > node MAY also construct a more complicated destination list for > source routing. > new: > node MAY also construct a more complicated destination list for > (loose) source routing. > > Once the message is constructed, the node sends the message to some > adjacent peer. If the first entry on the destination list is > directly connected, then the message MUST be routed down that > connection. Otherwise, the topology plugin MUST be consulted to > determine the appropriate next hop. > > # adjacent peer should be adjacent node, since it may be a client > # directly connected means: a valid entry in the Connection Table > # exists? this should be mentioned here... > > sec. 6.2.2. > =========== > # a hint that the same Transaction-ID as in the request MUST be used > # could be added. > > sec. 6.3.1.1. > ============= > Unless a given structure that uses a select explicitly allows for > unknown types in the select, any unknown type SHOULD be treated as an > > # How is that allowance specified in the specification? Is it by the comment > # /* This structure can be extended */ > > sec. 6.3.2. > =========== > receive message with a TTL greater than the current value of > initial-ttl (or the 100 default) MUST discard the message and send > an "Error_TTL_Exceeded" error. > > # what if the initial-ttl is larger than 100 and the TTL is >100 but > # < initial-ttl? The condition "or the 100 default" holds > > old: > used to indicate the fragment offset; see Section 6.7. > new: > used to indicate the fragment offset in bytes; see Section 6.7. > > old: > length: The count in bytes of the size of the message, including the > header. > new: > length: The count in bytes of the size of the whole unfragmented > message, > including the header. > > # as already mentioned in the beginning this should be more precise > > > destinations which the message should pass through. The > destination list is constructed by the message originator. The > > # is it allowed that intermediate peers add destinations? if not, please > # state so > > old: > next. The list shrinks as the message traverses each listed peer. > new: > next. The list may shrink as the message traverses each listed peer. > > # it need not be always the case that the list shrinks with each > traversed peer > > sec. 6.3.2.2. > ============= > old: > structure with a DestinationType of opaque_id_type and a opaque_id > new: > structure with a DestinationType of opaque_id_type and an opaque_id > > # typo fix > > old: > opaque > A compressed list of Node-IDs and an eventual Resource-ID. > Because this value was compressed by one of the peers, it is only > meaningful to that peer and cannot be decoded by other peers. > Thus, it is represented as an opaque string. > > resource > The Resource-ID of the resource which is desired. This type MUST > only appear in the final location of a destination list and MUST > NOT appear in a via list. It is meaningless to try to route > through a resource. > new: > resource > The Resource-ID of the resource which is desired. This type MUST > only appear in the final location of a destination list and MUST > NOT appear in a via list. It is meaningless to try to route > through a resource. > > opaque_id_type > A compressed list of Node-IDs and an eventual Resource-ID. > Because this value was compressed by one of the peers, it is only > meaningful to that peer and cannot be decoded by other peers. > Thus, it is represented as an opaque string. > > # 1.) match the order in the select > # 2.) it must be opaque_id_type, not opaque > > sec. 6.3.2.3 > ============ > flags > Three flags are defined FORWARD_CRITICAL(0x01), > DESTINATION_CRITICAL(0x02), and RESPONSE_COPY(0x04). These flags > MUST NOT be set in a response. If the FORWARD_CRITICAL flag is > > # What is the correct reaction if these flags are set in a response? > # (returning an Error_Invalid_Message or ignore?) > > sec. 6.3.3.1 > ============ > old: > A node processing a request MUST return its status in the > message_code field. If the request was a success, then the message > new: > A node processing a request MUST return its status in the > message_code field of a response. If the request was a success, then > the message > > # clarification? > > Error_Request_Timeout: A response to the request has not been > received in a suitable amount of time. The requesting node MAY > resend the request at a later time. > > # not clear when this will ever be used. Which node should send > # this error message? > > All RELOAD messages MUST be signed. Intermediate nodes do not verify > signatures. Upon receipt (and fragment reassembly if needed) the > destination node MUST verify the signature and the authorizing > certificate. If the signature fails, the implementation SHOULD > simply drop the message and MUST NOT process it. This check provides > > # What happens if none {0,0} is given? Then no Node-ID is present... > > sec. 6.4.2. > =========== > What happens if these messages (like Join, Leave) are accidentally sent > to a Client? > Do the send an Invalid Message back? > > A new peer (but one that already has credentials) uses the JoinReq > message to join the overlay. The JoinReq is sent to the responsible > peer depending on the routing mechanism described in the topology > > Is the destination address now the Resource-ID or the Node-ID > of the "responsible peer"? > > Because joins may only be executed between nodes which are directly > adjacent, receiving peers MUST verify that any JoinReq they receive > > # 1.) should be peers rather than nodes > # 2.) directly adjacent means here: directly adjacent in the overlay > # topology (could otherwise be misunderstood as being directly > # connected) > # 3.) what must happen if the verification fails? > > adjacent, receiving peers MUST verify that any LeaveReq they receive > arrives from a transport channel that is bound to the Node-ID to be > > # what happens if that verification fails? > > old: > assumed by the leaving peer.) This also prevents replay attacks > new: > assumed by the leaving peer. This also prevents replay attacks > > # Typo fix > > sec. 6.4.2.3 > ============ > the state change. In general, peers send Update messages to all > their adjacencies whenever they detect a topology shift. > > # A hint to the Connection Table and Clients would clarify > > sec. 6.4.2.4. > ============= > old: > X. A RouteQuery can also request that the receiving peer initiate an > new: > X. A RouteQuery can also request that the receiving peer initiates an > > old: > One important use of the RouteQuery request is to support iterative > routing. The sender selects one of the peers in its routing table > > # add reference to Section 3.3. > > sec. 6.4.2.4.1 > ============== > destination > The destination which the requester is interested in. This may be > any valid destination object, including a Node-ID, opaque ID, or > Resource-ID. > > # Does opaque ID make sense here? > > sec. 6.5.1 > ========== > A node sends an Attach request when it wishes to establish a direct > TCP or UDP connection to another node for the purpose of sending > > # TCP/TLS or DTLS? > > old: > node A has Attached to node B, but not received any Updates from B, > new: > node A has attached to node B, but not received any Updates from B, > > # Typo > > channel but MUST NOT route messages through B to other peers via that > channel. The process of Attaching is separate from the process of > # Is that also true for clients? > > sec. 6.5.1.1 > ============ > old: > } AttachReqAns; > > The values contained in AttachReqAns are: > > new: > } AttachReq; > > The values contained in AttachReq are: > > old: > A single AttachReqAns MUST NOT include both candidates whose > new: > A single AttachReq MUST NOT include both candidates whose > > # consistency! > > sec. 6.5.1.2. > ============= > old: > 6.5.1.2. Response Definition > > new: > 6.5.1.2. Response Definition > > The AttachAns message hast the same format as the AttachReq message. > > > #s/AttachReqAns/AttachAns/ in the whole paragraph. > > sec. 6.5.1.3. > ============= > > An agent follows the ICE specification as described in [RFC5245] with > > # agent was not defined in the RELOAD context so far. > > sec. 6.5.4.2. > ============= > old: > o The configuration document is correctly digitally signed (see > Section 11 for details on signatures. > new: > o The configuration document is correctly digitally signed (see > Section 11 for details on signatures). > > old: > one listed in the current configuration file). Details on kind- > signer field in the configuration file is described in Section 11.1. > new: > one listed in the current configuration file). Details on kind- > signer field in the configuration file are described in Section 11.1. > > # typos > > sec. 6.6.2 > ========== > old: > Each connection has it own sequence number space. Initially the > new: > Each connection and direction has it own sequence number space. > Initially the > > sec. 6.6.3.1 > ============ > A node MUST NOT have more than one unacknowledged message on the DTLS > connection at a time. Note that because retransmissions of the same > message are given new sequence numbers, there may be multiple > unacknowledged sequence numbers in use. > > # Since retransmissions violate the first sentence, it may be better > # to use: > old: > A node MUST NOT have more than one unacknowledged message on the DTLS > connection at a time. Note that because retransmissions of the same > new: > A node MUST NOT have more than one unacknowledged message on the DTLS > connection at a time, except for retransmissions. Note that because > > from the routing table. The link MAY be restored to the routing > table if ACKs resume before the connection is closed, as described > > # this should read Connection Table twice? > > sec. 6.7 > ========= > and fragments it, each fragment has a full copy of the Forwarding > > # 1.) clarification would be good that the length field is covering the > # total msg length and which field are different in the "copies" > # (at least the fragment field) > # 2.) what happens if overlapping fragments are received? > > > Feedback on sections 7 and greater will follow in a separate mail > later today. > > Regards, > Roland From michaelc@idssoftware.com Thu Feb 21 06:57:29 2013 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 8E0C421F8E54 for ; Thu, 21 Feb 2013 06:57:29 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dkg67Iqdgf8c for ; Thu, 21 Feb 2013 06:57:28 -0800 (PST) Received: from p3plwbeout03-02.prod.phx3.secureserver.net (p3plsmtp03-02-2.prod.phx3.secureserver.net [72.167.218.214]) by ietfa.amsl.com (Postfix) with ESMTP id C871821F8E57 for ; Thu, 21 Feb 2013 06:57:28 -0800 (PST) Received: from localhost ([72.167.218.244]) by p3plwbeout03-02.prod.phx3.secureserver.net with bizsmtp id 32xT1l0015GyNsw012xTYj; Thu, 21 Feb 2013 07:57:27 -0700 X-SID: 32xT1l0015GyNsw01 Received: (qmail 2128 invoked by uid 99); 21 Feb 2013 14:57:27 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 67.58.151.228 User-Agent: Workspace Webmail 5.6.32 Message-Id: <20130221075726.59ca11a9ba9389561a029f06442e67fa.45782498ef.wbe@email03.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Thu, 21 Feb 2013 07:57:26 -0700 Mime-Version: 1.0 Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-base-25.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: Thu, 21 Feb 2013 14:57:29 -0000 Marc,=0A=0AThanks for the revision to section 10.5 bullet 2 and section 11.= 4.=0AHowever, just notice two places related to this that need the followin= g=0Achanges to match bullet 2:=0A=0ASection 11.4 paragraph 2:=0A Old: "sen= ds an Attach request over this connection with the=0Adestination Resource-I= D set to the joining node's Node-ID."=0A New: "sends an Attach request ove= r this connection with the=0Adestination Resource-ID set to the joining nod= e's Node-ID plus 1."=0A=0ASection 12 paragraph 2:=0A Old: "JN then sends a= n Attach through that peer to a Resource-ID of=0Aitself (JN)."=0A New: "JN= then sends an Attach through that peer to a Resource-ID of=0Aits Node-ID p= lus 1 (JN+1)."=0A=0ASection 12 diagram after paragraph 2:=0A Old: "AttachR= eq Dest=3DJN" 2 occurrences=0A New: "AttachReq Dest=3DJN+1" 2 replacem= ents=0A=0AThanks=0A=0A--Michael=0A=0A> -------- Original Message --------= =0A> Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-base-25.txt=0A> From: = internet-drafts@ietf.org=0A> Date: Wed, February 20, 2013 5:37 pm=0A> To: i= -d-announce@ietf.org=0A> Cc: p2psip@ietf.org=0A> =0A> =0A> A New Internet-D= raft is available from the on-line Internet-Drafts directories.=0A> This d= raft is a work item of the Peer-to-Peer Session Initiation Protocol Working= Group of the IETF.=0A> =0A> =09Title : REsource LOcation And Dis= covery (RELOAD) Base Protocol=0A> =09Author(s) : Cullen Jennings=0A> = Bruce B. Lowekamp=0A> E= ric Rescorla=0A> Salman A. Baset=0A> = Henning Schulzrinne=0A> =09Filename : draft-ietf-p2psi= p-base-25.txt=0A> =09Pages : 174=0A> =09Date : 2013-02= -20=0A> =0A> Abstract:=0A> This specification defines REsource LOcation = And Discovery (RELOAD),=0A> a peer-to-peer (P2P) signaling protocol for = use on the Internet. A=0A> P2P signaling protocol provides its clients = with an abstract storage=0A> and messaging service between a set of coop= erating peers that form=0A> the overlay network. RELOAD is designed to = support a P2P Session=0A> Initiation Protocol (P2PSIP) network, but can = be utilized by other=0A> applications with similar requirements by defin= ing new usages that=0A> specify the kinds of data that needs to be store= d for a particular=0A> application. RELOAD defines a security model bas= ed on a certificate=0A> enrollment service that provides unique identiti= es. NAT traversal is=0A> a fundamental service of the protocol. RELOAD= also allows access=0A> from "client" nodes that do not need to route tr= affic or store data=0A> for others.=0A> =0A> =0A> The IETF datatracker s= tatus page for this draft is:=0A> https://datatracker.ietf.org/doc/draft-ie= tf-p2psip-base=0A> =0A> There's also a htmlized version available at:=0A> h= ttp://tools.ietf.org/html/draft-ietf-p2psip-base-25=0A> =0A> A diff from th= e previous version is available at:=0A> http://www.ietf.org/rfcdiff?url2=3D= draft-ietf-p2psip-base-25=0A> =0A> =0A> Internet-Drafts are also available = by anonymous FTP at:=0A> ftp://ftp.ietf.org/internet-drafts/=0A> =0A> _____= __________________________________________=0A> P2PSIP mailing list=0A> P2PS= IP@ietf.org=0A> https://www.ietf.org/mailman/listinfo/p2psip From internet-drafts@ietf.org Sat Feb 23 00:47:58 2013 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 B33BF21F8861; Sat, 23 Feb 2013 00:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgkMcQsq1iPw; Sat, 23 Feb 2013 00:47:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC7321F8883; Sat, 23 Feb 2013 00:47: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: 4.40 Message-ID: <20130223084758.22086.19545.idtracker@ietfa.amsl.com> Date: Sat, 23 Feb 2013 00:47:58 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-service-discovery-08.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: Sat, 23 Feb 2013 08:47:58 -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 Protocol = 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-08.txt Pages : 18 Date : 2013-02-23 Abstract: REsource LOcation and Discovery (RELOAD) does not define a generic service discovery mechanism as a 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-service-discovery There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-service-discovery-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-service-discovery-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jouni.maenpaa@ericsson.com Sat Feb 23 00:50:34 2013 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 032C521F8883 for ; Sat, 23 Feb 2013 00:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.709 X-Spam-Level: X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EougWzPbgDmX for ; Sat, 23 Feb 2013 00:50:33 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id AA82B21F8861 for ; Sat, 23 Feb 2013 00:50:32 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-5f-512882d7c452 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B8.51.10459.7D288215; Sat, 23 Feb 2013 09:50:31 +0100 (CET) Received: from ESESSMB305.ericsson.se ([169.254.5.61]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0318.004; Sat, 23 Feb 2013 09:50:31 +0100 From: =?iso-8859-1?Q?Jouni_M=E4enp=E4=E4?= To: "p2psip@ietf.org" Thread-Topic: [P2PSIP] I-D Action: draft-ietf-p2psip-service-discovery-08.txt Thread-Index: AQHOEaJ9yrLvRBmSZEG625MRbFX5MpiHIfzQ Date: Sat, 23 Feb 2013 08:50:30 +0000 Message-ID: <27112A697EB8204D9943EAB8A0E16B710754C5A6@ESESSMB305.ericsson.se> References: <20130223084758.22086.19545.idtracker@ietfa.amsl.com> In-Reply-To: <20130223084758.22086.19545.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvje71Jo1AgysdZhZLbp5hdGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoI5LxgLXvJVnNnzgLGBsYOni5GTQ0LAROL32m5WCFtM4sK9 9WxdjFwcQgKHGCVat+xnhnAWM0rs336PCaSKTcBd4vDNn2AdIgLqEtdnnWEDsYUFfCTW75zK DhH3lZh79DtUjZFE/+r7zCA2i4CqxLGu5yxdjBwcvEA1T+5YgoSFBBwlbi1bD9bKKeAkcfJz H9hIRqCDvp9aA7aWWUBc4taT+UwQhwpILNlznhnCFpV4+fgf1AOKEu1PGxgh6vUkbkydwgZh a0ssW/garJ5XQFDi5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxciem5iZk15uuIkRGPYHt/zW 3cF46pzIIUZpDhYlcd4w1wsBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhrjy7UKtjKsK9Y yHXFzntupy7abGrd3NzJF1c1sX5tlqb+ZIkM5rl8U+I0zn7J2J/TufTy85Jpvq/2tL/aanUp 9/aDi8XNliG3ZXi0yjnWc9SUTfQq7J1umNcfNUeCf9YKp/dnQnUPtDA480x3f8AgVt0+3TMi OXVFFP+ly0Jf0gRmuV31uarEUpyRaKjFXFScCAAOTGnmSQIAAA== Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-service-discovery-08.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: Sat, 23 Feb 2013 08:50:34 -0000 Hi, This new version of draft-ietf-p2psip-service-discovery attempts to address= all the remaining comments received during the WGLC. Regards, Jouni -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of= internet-drafts@ietf.org Sent: 23. helmikuuta 2013 10:48 To: i-d-announce@ietf.org Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-service-discovery-08.txt 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 Protocol = 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-08.txt Pages : 18 Date : 2013-02-23 Abstract: REsource LOcation and Discovery (RELOAD) does not define a generic service discovery mechanism as a 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-service-discovery There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-service-discovery-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-service-discovery-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From jouni.maenpaa@ericsson.com Sat Feb 23 01:00:04 2013 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 01A5421F8D0B for ; Sat, 23 Feb 2013 01:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0uhutNw5BB6 for ; Sat, 23 Feb 2013 01:00:02 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C396921F8DCB for ; Sat, 23 Feb 2013 01:00:01 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-0a-5128851039f4 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id AD.F1.10459.01588215; Sat, 23 Feb 2013 10:00:00 +0100 (CET) Received: from ESESSMB305.ericsson.se ([169.254.5.61]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0318.004; Sat, 23 Feb 2013 10:00:00 +0100 From: =?iso-8859-1?Q?Jouni_M=E4enp=E4=E4?= To: "p2psip-chairs@tools.ietf.org" , "p2psip@ietf.org" , Joscha Schneider Thread-Topic: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06 Thread-Index: AQHODcoPi3CDhCh/50uVYPVOI0rEM5h/+rYQgAcwEaA= Date: Sat, 23 Feb 2013 08:59:59 +0000 Message-ID: <27112A697EB8204D9943EAB8A0E16B710754C5D7@ESESSMB305.ericsson.se> References: <1359673911.4472.18.camel@acorde.it.uc3m.es> <511D341E.6060905@acm.org> <511E0E0B.6070103@hs-mannheim.de> <511E6779.80706@acm.org> <27112A697EB8204D9943EAB8A0E16B710753ED3E@ESESSMB305.ericsson.se> <51220EA9.2060200@hs-mannheim.de> <27112A697EB8204D9943EAB8A0E16B7107545D2D@ESESSMB305.ericsson.se> In-Reply-To: <27112A697EB8204D9943EAB8A0E16B7107545D2D@ESESSMB305.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvja5Aq0agwd95eha/pm5hs/j//BSL xZKbZxgdmD0OHb/D5LFkyU8mjy+XP7MFMEdx2aSk5mSWpRbp2yVwZax/cY+14HR1xYW1/9ga GC+ldDFyckgImEjs/reDEcIWk7hwbz1bFyMXh5DAIUaJmReamCCcxYwST28/YgapYhNwlzh8 8ycrSEJEYCajxJqlh9lAEsICrhKb+maygtgiAm4ST7u+M0HYVhLzrh5kAbFZBFQleraeAYpz cPAK+EqsbLWAWLCPSeLmlfNgNZwCfhLrNp4Bm8kIdNL3U2vA5jALiEvcejKfCeJUAYkle84z Q9iiEi8f/2OFsBUl2p82MELU60ncmDqFDcLWlli28DVYPa+AoMTJmU9YJjCKzkIydhaSlllI WmYhaVnAyLKKkT03MTMnvdxwEyMwRg5u+a27g/HUOZFDjNIcLErivGGuFwKEBNITS1KzU1ML Uovii0pzUosPMTJxcEo1MGpzvw7wXKp+yoz1c1TcouZF50VcLM5dLRC5a192RureFy2nwI3L EhUvNCT+1FjxRG5t8a/Qby2Fk31C3OI3mc+5pOtuXjyfY4Xz8juNsX79cfPb1264sWbe2yML luhNS1CzUTyzre6X1eets8vXJx8Orbh3yNPzluXW+T+Vb9aYvHjtbMida67EUpyRaKjFXFSc CAC873ydXwIAAA== Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06 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, 23 Feb 2013 09:00:04 -0000 Hi, The comments below have now been addressed in version -08 of the draft. The= changes in the new version include: - The temporary local caching mechanism for RedirServiceProvider records fe= tched during a service lookup operation that is described below was added t= o the draft - The text was clarified further=20 - New examples were added to clarify how ReDiR tree nodes are numbered and = how intervals are assigned to tree nodes Regards, Jouni -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of= Jouni M=E4enp=E4=E4 Sent: 18. helmikuuta 2013 21:25 To: Joscha Schneider Cc: p2psip-chairs@tools.ietf.org; p2psip@ietf.org Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06 Hi Joscha, Thanks for the comments! Answering the first comment inline, need some more= time to check the second comment. Regards, Jouni -----Original Message----- From: Joscha Schneider [mailto:j.schneider@hs-mannheim.de] Sent: 18. helmikuuta 2013 13:21 To: Jouni M=E4enp=E4=E4 Cc: Marc Petit-Huguenin; p2psip-chairs@tools.ietf.org; p2psip@ietf.org Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06 two comments inline regards joscha Am 16.02.2013 18:55, schrieb Jouni M=E4enp=E4=E4: > Hi Marc and Joscha, > > Thanks for the comments! Answers inline. > > Regards, > Jouni > > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On=20 > Behalf Of Joscha Schneider > Sent: 15. helmikuuta 2013 12:30 > To: Marc Petit-Huguenin > Cc: p2psip-chairs@tools.ietf.org; p2psip@ietf.org > Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06 > > I can confirm that the draft might need some improvements to make the imp= lementation easier. > I did a basic implementation but I'm not quite sure that I handled everyt= hing correct. > > [Jouni]: I'll try to improve the text in the next version of the draft. > > Especially the definition of the successor seams a bit unclear for me. A = simple example: > Only a single service provider with Node-ID 2 provides a service. Node wi= th ID 7 performs a lookup... > How should it be handled? I implemented it as follows: in case a lookup r= eveals only a single service provider it must be the direct successor. > > [Jouni]: What would happen in this case is that the upward walk of the se= rvice lookup reaches the root level because no successor can be found from = the lower levels in the tree. In my implementation, when this happens, I'm = selecting either the closest successor at the root level or, if there is no= successor, select one of the available service providers randomly (or pick= the only service provider if there is only one like you are doing in your = implementation). Anyway, I'll add text to clarify this to the next version = of the draft. > > Further notice, due to the periodically triggered re-registration the con= sistency of the ReDiR tree can not be always ensured. Theoretically this ca= n lead to failed lookup processes. > This derives from the fact that each new service provider registration mi= ght affect the re-registration of the former service providers which again = might affect the re-registrations of other service providers. > > [Jouni]: Not sure about this. I could be wrong, but why would the re-regi= stration of a service provider affect the re-registrations of other service= providers? I mean, when a service provider X re-registers or registers, it= simply stores its own record at different levels in the ReDiR tree as a pa= rt of the upward and downward walks. This re-registration process does not = influence the (re-)registrations of other service providers. Or did I under= stand your comment incorrectly? > I'll try to make an example: Two service provider are even in Level 4 in = the same interval. First service prover (X) stops registration downwalk at = level 2 because it's the only one. Second service provider (Y) goes down to= level 3 to finish its downwalk. X starts re-registration. Now the downwalk= need to go down to level 4 as level 2 and 3 are shared Y.=20 Now Y starts re-registration. Goes down to level 5 as level 3 and 4 are sha= red now. X re-registers again. goes down to level 5. Finally both service p= roviders have found the leaves and the tree is consistent. In between, serv= ice lookups might go down to a level at which no service provider informati= on is stored (yet). [Jouni]: Ok, I think you're right, that can happen. How often do you think = it would occur? The default branching factor of the ReDiR tree is 10. I gue= ss that the Node-IDs of the service providers that are (re-)registering at = the same time would need to be very close to each other in order for the se= rvice providers to end up into the same interval at two levels of the tree = (with the default branching factor of 10, level 2 has 1000 intervals, level= 3 10000, level 5, 100000, etc.).=20 I guess there might also be other similar situations, though, such as when = a RedirServiceProvider record expires within a given interval at some level= just before a service lookup for which that record is the closest successo= r reaches that level and interval, and before the re-registration stores a = new RedirServiceProvider record in that interval. This situation should be = quite rare, though. One potential strategy for dealing with the situations above is to fail the= service lookup procedure and retry it - if the temporary inconsistency has= been fixed by a re-registration between the old and new service lookup, th= e new service lookup will succeed. Another strategy that we are using in our ReDiR implementation is that we a= re temporarily (for the duration of a service lookup) caching/storing the R= edirServiceProvider entries fetched during that specific service lookup at = the peer that is carrying out the service lookup. Thus, if for whatever rea= son the service lookup would happen to go down to a level at which no servi= ce provider information is stored, the peer that is carrying out the search= can go through the locally cached RedirServiceProvider entries to find the= closest successor of the search key from among the cached entries. This st= rategy would allow one to recover from the scenarios described above. Do yo= u think it would help if we described this strategy in the draft? Do you ha= ve some other potential solutions in mind? > more inline... > > Regards > Joscha > > Am 14.02.2013 19:59, schrieb Marc Petit-Huguenin: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> I did a review of this draft, and I have some concerns. >> >> First of all some parts of the I-D are verbatim copy of the text in=20 >> the original paper. Is that OK? > [Jouni]: I guess the main reason for that is that ReDiR is pretty complex= to describe. So we took a safe bet and tried to reuse some of the text (th= e algorithm description) from the paper. But since there are also comments = that the text is difficult to follow, I'll make an attempt to reformulate i= t in the next version of the draft. > >> Probably because some of the text comes from a research paper, it was=20 >> very difficult to understand fro me, and I am not sure that I yet=20 >> understood everything - I still have to write an implementation of=20 >> this, and unfortunately to not have enough time to do so before the=20 >> end of the WGLC. On the other hand, I know that RELOAD.NET has an=20 >> implementation, so I guess it is implementable. > [Jouni]: I have also implemented the draft and think I got the implementa= tion right. So if you have any further questions about things that are uncl= ear, let me know and I can check the code to see how that specific thing wa= s implemented (and clarify the same issue in the draft if necessary). > >> But I was not able to make sense of something in the example in section = 7: >> Why is the 4th peer added to level 0? Bullet 4 in Section 4.3 says=20 >> "Node N MUST continue [repeating steps 2 and 3] until it reaches=20 >> either the root or a level a which n.id is not the lowest or highest=20 >> Node-ID in the interval I(level, n.id)". In this case 4 is not the=20 >> lowest or highest Node-ID in the interval (lowest is 2, highest is 7), s= o why is it added to this node? > I think the example is simply following the rules. At level 1 peer 4 is t= he lowest. So go up and fetch and store. > > [Jouni]: That's correct. Node 4 starts from the starting level, which is = level 2. It stores its record on level 2. Since Node-ID 4 is the lowest (on= ly) Node-ID in its interval, the upward walk continues to level 1. At level= 1, Node-ID 4 is also the lowest Node-ID in its interval and thus the upwar= d walk continues all the way to the root level. Node 4 stores its record in= that level. Since Node-ID is neither the lowest nor highest Node-ID, the u= pward walk stops at level 0 (although it would stop anyway at level 0 since= it is of course not possible to go further up in the tree). > >> But if i reveal correct that fact caused a few headaches for me too.=20 >> Why does the store does not depend on the information that was=20 >> fetched before? > [Jouni]: That is how it goes - if there has been a decision that the upwa= rd walk shall continue to the next level, a record is stored at that level = 'automatically', regardless of the contents of the tree node. The contents = of the tree node (i.e., whether n.id is sandwiched or not) will influence t= he decision on whether to stop the upward walk or continue it. The idea in = the upward and downward walks is to ensure that the tree is populated dense= ly enough so that service lookups will finish without requiring too many Fe= tch operations. But does this make sense? If I recall correct the registration information = of node 3 and 4 in Level 0 in the draft example will never be used in looku= p processes. As far as I understood at most two service provider entries ar= e needed (lowest and highest) in each tree node to make the algorithm work.= All sandwiched service provider information is not needed. Most of them wi= ll also expire and not be renewed in the re-registration process in case ot= her service providers have registered in the meantime. I think this 'automa= tic' store process makes the tree just a bit more wired and the algorithm m= ode difficult to understand. Or do you see a resonable reason for this beha= viour that I don't see. >> BTW a similar example for the service lookup would be useful. > [Jouni]: Ok, I'll add an example in the next version of the draft. > >> More comments: >> >> - - Section 3, 3 paragraph: "contains a list of Node-IDs" >> >> Technically each node is a Dictionary whose keys are Node-IDs and=20 >> values contain a list of Destinations. > [Jouni]: Ok, I'll modify this in the next version of the draft. > >> - - Section 4.1 >> >> s/detination_list/destination_list/ > [Jouni]: Ok, will change this one also in the next version of the draft. > >> - - Section 4.1 >> >> namespace is an opaque value but the charset and conversion between=20 >> character string and byte string for the namespace is not defined. > confirm > > [Jouni]: Would specifying that it is an opaque UTF-8 encoded string be en= ough? > >> - - Section 8 >> >> The document says that the redir namespace is added to the=20 >> element, meaning that all nodes MUST understand=20 >> ReDIR, but isn't that against one of the goal of ReDIR, which is that=20 >> by using standard Store/Fetch, only a node wishing to store or fetch=20 >> has to implement ReDIR? > I think at least the RedirServiceProvider Data Structure must be supporte= d. And also the Access Control Rules. > But the algorithm might not be mandatory needed. > > The RedirServiceProvider Data Structure does not need to be understood by= the peer storing it, but you are right about the Access Control rule. My = own draft about storing the Access Control rule solves this problem but, ev= en if it is accepted as WG item, we do not want to add a normative referenc= e to it. > > So I withdraw what I said - redir needs to be a a mandatory extension at = least until new access control policies no longer have to be hardcoded. > > [Jouni]: Ok, so if I understood correctly, it is ok to leave the text as = it is. > >> - - Section 10.3 >> >> I think that we need a bit more explanation on what the turn-server=20 >> and voice-mail service providers are. > [Jouni]: I could remove the voice-mail service provider from the next ver= sion of the draft as I don't have a good explanation for that. For turn-ser= ver I will add some text. > >> On 01/31/2013 03:11 PM, Carlos Jes=FAs Bernardos Cano wrote: >>> Hi, >>> >>> Hereby we are issuing a WGLC for draft-ietf-p2psip-service-discovery-06= . >>> >>> The WGLC will be open till the 15th of February. We kindly ask the=20 >>> WG to review the document and provide comments. >>> >>> If you have no comments and think the document is ready to be=20 >>> submitted to IESG, please do send a note stating that to the WG ML. >>> >>> Additional information about the document is below: >>> >>> Title : Service Discovery Usage for REsource LOcation And >>> Discovery (RELOAD) Author(s) : Jouni Maenpaa Gonzalo Camarillo >>> Filename : draft-ietf-p2psip-service-discovery-06.txt Pages : 15 >>> Date : 2012-10-01 >>> >>> Abstract: REsource LOcation and Discovery (RELOAD) does not define a=20 >>> 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=20 >>> to RELOAD overlays to provide a generic service discovery mechanism. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-p2psip-service-discovery >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-p2psip-service-discovery-06 >>> >>> >> - -- >> Marc Petit-Huguenin >> Email: marc@petit-huguenin.org >> Blog: http://blog.marc.petit-huguenin.org >> Profile: http://www.linkedin.com/in/petithug >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.12 (GNU/Linux) >> >> iQIcBAEBCAAGBQJRHTQcAAoJECnERZXWan7EmukP/A1P3JutcxuDooxYPFjty3ua >> lhhbiJTd7PLEs9jsaG9hKHjuDi2qu0BNp9Ss+ki+ybtXBNKaJwkrqNqwB3R+dXpx >> Q7zamHvCUJekNmybG2kpc5IUP2MxhDzYp3paocOdF/vdWYE+re3u9WqBN1JNuCwk >> E6GmfEIgw28p5wKldHPCGQrRYx6QnszsQc7F3+siFrsSEzRww7ATpUXjMCVxUfWU >> KTmBh0H+9+PhoXeH6leue2v0Y5Xb1lD8HU6WmrssWYrd9rXgc3s26kzsUrATJCKc >> bj7M6uiKIzUDFwaj13U6bPbldVeJWd+DhWCR2k4Y3rJIfj5bdp55ApDZnF/14v91 >> i/w0hnqnuiT/KEDuW+E7jsKwXq/ILKIDZqonyFlF7KuGUT3HGi9WFkc7AnkaOi5U >> qgsuFEYjxkUqAbTAO7nwa9YtGX0qKHhH5SkzWpITTabu48c5FKqG0vAVpGce8z3K >> AyqtwNXAz9nIL6ZwJNg9L8tLhLBQS1lePeSiN7pog4jsKD51VaT7Y1iMysA2OqRs >> Nw70wF7TYh4EikCHsECPQBEI/a+cJEQSro0I4kHGGttVcEdrDqM4xdfaFYN+Ag1b >> vHEf3Zzv/x820fjbfN1eoySj/qFU7Mcuw8Rik//J63HKZbmGdbaYsdrHasgaDIqk >> TgSsgGCf6d5FX9TFFNvd >> =3Du3Pi >> -----END PGP SIGNATURE----- >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From internet-drafts@ietf.org Sun Feb 24 13:59:14 2013 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 F03C221F9101; Sun, 24 Feb 2013 13:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2no7rmau06wz; Sun, 24 Feb 2013 13:59:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F30221F90F6; Sun, 24 Feb 2013 13:59:13 -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: 4.40 Message-ID: <20130224215913.21154.16664.idtracker@ietfa.amsl.com> Date: Sun, 24 Feb 2013 13:59:13 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-share-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: Sun, 24 Feb 2013 21:59:14 -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 Protocol = Working Group of the IETF. Title : A Usage for Shared Resources in RELOAD (ShaRe) Author(s) : Alexander Knauf Thomas C. Schmidt Gabriel Hege Matthias Waehlisch Filename : draft-ietf-p2psip-share-01.txt Pages : 24 Date : 2013-02-24 Abstract: This document defines a RELOAD Usage for managing shared write access to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic primitive for enabling various coordination and notification schemes among distributed peers. Access in ShaRe is controlled by a hierarchical trust delegation scheme maintained within an access list. A new USER-CHAIN-ACL access policy allows authorized peers to write a Shared Resource without owning its corresponding certificate. This specification also adds mechanisms to store Resources with a variable name which is useful whenever peer-independent rendezvous processes are required. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-share There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-share-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-share-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=7609c466f=schmidt@informatik.haw-hamburg.de Sun Feb 24 14:11:22 2013 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 3552B21F911F for ; Sun, 24 Feb 2013 14:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pGoh0v48JSv for ; Sun, 24 Feb 2013 14:11:21 -0800 (PST) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id CFB2421F8610 for ; Sun, 24 Feb 2013 14:11:14 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 24 Feb 2013 23:11:13 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 9B0AC1066AE7 for ; Sun, 24 Feb 2013 23:11:13 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22214-07 for ; Sun, 24 Feb 2013 23:11:12 +0100 (CET) Received: from [192.168.152.252] (rrcs-67-52-140-5.west.biz.rr.com [67.52.140.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 983031066AE4 for ; Sun, 24 Feb 2013 23:11:11 +0100 (CET) Message-ID: <512A8FFC.4050603@informatik.haw-hamburg.de> Date: Sun, 24 Feb 2013 14:11:08 -0800 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: p2psip@ietf.org References: <20130224215913.21154.67944.idtracker@ietfa.amsl.com> In-Reply-To: <20130224215913.21154.67944.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130224215913.21154.67944.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Subject: [P2PSIP] Fwd: New Version Notification for draft-ietf-p2psip-share-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: Sun, 24 Feb 2013 22:11:22 -0000 Hi, we've updated the ShaRe document, addressing all open issues: o Clarified use of identities in ACLs o Specified use of Posix regular expressions in configuration document o Added IANA considerations o Editorial improvements o Updated References The document appears pretty converged from our side (special thanks to Marc!) - please have a look. Cheers, Thomas -------- Original Message -------- Subject: New Version Notification for draft-ietf-p2psip-share-01.txt Date: Sun, 24 Feb 2013 13:59:13 -0800 From: internet-drafts@ietf.org To: schmidt@informatik.haw-hamburg.de CC: hege@daviko.com, alexanderknauf@gmail.com, mw@link-lab.net A new version of I-D, draft-ietf-p2psip-share-01.txt has been successfully submitted by Thomas C. Schmidt and posted to the IETF repository. Filename: draft-ietf-p2psip-share Revision: 01 Title: A Usage for Shared Resources in RELOAD (ShaRe) Creation date: 2013-02-24 Group: p2psip Number of pages: 24 URL: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-share-01.txt Status: http://datatracker.ietf.org/doc/draft-ietf-p2psip-share Htmlized: http://tools.ietf.org/html/draft-ietf-p2psip-share-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-share-01 Abstract: This document defines a RELOAD Usage for managing shared write access to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic primitive for enabling various coordination and notification schemes among distributed peers. Access in ShaRe is controlled by a hierarchical trust delegation scheme maintained within an access list. A new USER-CHAIN-ACL access policy allows authorized peers to write a Shared Resource without owning its corresponding certificate. This specification also adds mechanisms to store Resources with a variable name which is useful whenever peer-independent rendezvous processes are required. The IETF Secretariat From internet-drafts@ietf.org Sun Feb 24 16:23:37 2013 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 186D921F9160; Sun, 24 Feb 2013 16:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LT432I1FI4WV; Sun, 24 Feb 2013 16:23:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B6921F915E; Sun, 24 Feb 2013 16:23:36 -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: 4.40 Message-ID: <20130225002336.5179.42475.idtracker@ietfa.amsl.com> Date: Sun, 24 Feb 2013 16:23:36 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-base-26.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, 25 Feb 2013 00:23:37 -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 Protocol = 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-26.txt Pages : 186 Date : 2013-02-24 Abstract: 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 needs to 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-base There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-base-26 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-base-26 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From roland.bless@kit.edu Mon Feb 25 08:16:40 2013 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 1C2B221F9536 for ; Mon, 25 Feb 2013 08:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[AWL=-0.712, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45It1yCMbXwO for ; Mon, 25 Feb 2013 08:16:38 -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 D3D3D21F9533 for ; Mon, 25 Feb 2013 08:16:36 -0800 (PST) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 id 1UA0j4-0008A5-P8; Mon, 25 Feb 2013 17:16:35 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 91017A80729; Mon, 25 Feb 2013 17:16:26 +0100 (CET) Message-ID: <512B8E5A.7060400@kit.edu> Date: Mon, 25 Feb 2013 17:16:26 +0100 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Dean Willis References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1361808995.077107000 Cc: Cullen Jennings , "Goltsman, Polina" , p2psip@ietf.org, Marc Petit-Huguenin , p2psip-chairs@tools.ietf.org Subject: Re: [P2PSIP] Revisions to draft-ietf-p2psip-base-24 made in response to 2nd IETF LC 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, 25 Feb 2013 16:16:40 -0000 Hi, Thanks for reviewing our long list of comments (just to clarify: there was no clear distinction between Polina's comments and comments made by me, i.e. it just was a common list, some issues found by her some by me - not sure how you made a distinction :-). However, we still are not fully happy with the current version and want to propose some clearer wording: > 1) PG Major issue 1: sec. 6.3.2: > length field in Forwarding Header covers what exactly? it is not > really clear whether the length field counts the whole message or in > case of fragmentation only the fragment size. When reading Sec 6.7 is > seems that the former is meant, but the definition could and should be > clearer. Similarly, sec. 6.7 should be clear about this, e.g., > describing that all Forwarding Headers are identical for fragments of > the same message with exception of the fragment field. > > Revised: Our point was, that according to the version 24 of the draft, interpretations of ForwardingHeader::Length field as 1) total length of the message or 2) length of a fragment were equally valid, and that the decision on which interpretation to use, couldn't be left to the implementation. We actually interpreted it as possibility 1) while it is now 2)... In versions 25/26, the exact interpretation of length as being the length of fragment is now present but we think it could be more precise nevertheless: Sec 6.3.2. ========== old: length: The count in bytes of the size of the message including the header, after the eventual fragmentation. new: length: The count in bytes of the size of the message including the header. If the message is fragmented, this is the size of the current fragment (including the header), not the total message length before fragmentation. Sec 6.7 ======= old: If these elements cannot fit within the MTU of the underlying datagram protocol, RELOAD fragmentation is not performed and IP-layer fragmentation is allowed to occur. The length field MUST contain the size of the message after fragmentation. When a message MUST be fragmented, it SHOULD be split into equal-sized fragments that are no larger than the PMTU of the next overlay link minus 32 bytes. This is to allow the via list to grow before further fragmentation is required. new: If these elements cannot fit within the MTU of the underlying datagram protocol, RELOAD fragmentation is not performed and IP-layer fragmentation is allowed to occur. When a message MUST be fragmented, it SHOULD be split into equal-sized fragments that are no larger than the PMTU of the next overlay link minus 32 bytes. This is to allow the via list to grow before further fragmentation is required. The length field in the ForwardingHeader MUST contain the size of the fragment. > 2) PG Major issue 2: sec. 7.4.1.1: replica number handling is unclear > it is unclear how > replica numbers are incremented (e.g., per peer) and what receiving peers > should actually do with this number. Is it important to store the value or > would a boolean be sufficient so that the peer knows that it's a > replica?" > > Revised: > > Added text explaining that replica numbers are allocated and > interpreted by the topology plugin. > > Explained how CHORD-RELOAD interprets the replica numbers. Unfortunately, we don't consider this issue as being resolved. 1. Does the _Storage_ have to save replica numbers or are they discarded, after processing the StoreReq? The draft describes, how individual data elements are stored in StoredDataValue structure, but it doesn't explicitly state, what other values MUST be stored. It is obvious, that the generation counter is stored, but we can't figure out, whether we should store replica numbers. Moreover, a reminder to store certificates for data values would be nice. 2. Why do you require incrementing the numbers, when it is only required, that they are non-zero? If the value has to be incremented, how should it be assigned when the StoreReq is initiated by a topology shift, rather than the original store. Please review the example from our previous e-mail: > # Let's assume responsible peer X stores replicas at neighbors > # A and C: does A get replica number 1 and C replica number 2? > # if node B replaces neighbor C, does B get replica number 3 or number 2? > # if the responsible peer X is replaced by a new node Y, Y will get > # get the data from peer X, but how should X change its replica number? > # Can Y simply start sending replicas beginning at 1? 3. (minor) old: replica_number The number of this replica. When a storing peer saves replicas to other peers each peer is assigned a replica number starting from 1[*] and sent in the Store message. This field is set to 0 when a node is storing its own data.[**] This allows peers to distinguish replica writes from original writes. Different topologies may choose to allocate or interpret the replica number differently (see [***] Section 10.4). new: replica_number The number of this replica. This field is set to 0 when a node is storing its own data. When a storing peer saves replicas to other peers, the replica number must be set to a non-zero value. This allows peers to distinguish replica writes from original writes. Different topologies may choose to allocate or interpret the replica number differently (for CHORD-RELOAD see Section 10.4). # [*] 'starting from 1' still implies the sequential order (1 2 3 ...). The Topology Plugin shouldn't be forced to use it. # [**] sentences number 2 and 3 are reordered. # [***] CHORD-RELOAD is only one option for topology plugin, the reference should mention this. Unfortunately, one further editorial issue was missing from our original list: Sec 7. There is one subtle point about signature computation on arrays. If the storing node uses the append feature (where the index=0xffffffff), then the index in the StoredData that is returned will not match that used by the storing node, which would break the signature. In order to avoid this issue, the index value in the array is set to zero before the signature is computed. This implies that malicious storing nodes can reorder array entries without being detected. This text is written in Sec. 7.4.2.2 [Fetch] Response Definition, but it rather belongs to section 7.1. At the place where it is now, it can be easily overlooked, and it is really important that this is implemented (especially, since certificate storage is an array.) Furthermore, we would be really grateful if you can consider our other 3 major issues: [major issue nr. 3]. > 3) sec. 6.5.2: transport protocol set for AppAttach. Applications may > require use of other transport protocols than those defined in Overlay- > LinkType (TLS/DTLS, what about plain UDP, SCTP, DCCP, etc.), but > currently, this seems to be not possible (do the considerations > of sec. 6.5.1.6 apply here?). [major issue nr. 4]. > 4) sec. 6.3.4: > How can a different signature algorithm be used if not all implementations > support it? There is no possibility to provide the feedback, that the signature > algorithm is not acceptable at a particular node. According to section 6.3.4, implementations MUST support RSA signatures with SHA256 hashes. Does this imply that they must support only these values, or may they choose to support other values from IANA TLS Registry (http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-15)? If they may, the supported values are not possibly not homogeneously supported across nodes in one overlay. Currently, there is no way for one node to determine, if its valid signature was rejected by another node, because the latter didn't support the used signature algorithm. The possible solutions include: 1. unless specified by an extension, support only RSA signatures with SHA256 hashes. 2. add a configuration parameter, on what signature and hash algorithms must be supported and may be used. If one node can't support some of the values, it may not join the overlay. 3. have a dedicated error message for this situation. [major issue nr. 5]. 5) sec. 10.5: handling of parallel JOIN requests and use of peer_ready it is not clear what should happen if two JNs try to join at the same time at the same AP (can they be processed in parallel or should they be processed in sequence). Furthermore, when MUST/SHOULD a JN send peer_ready Update - in step 9? On 21.02.2013 06:03, Dean Willis wrote: > Roland Bless > -------------------- > > 1) Under 10.5 Joining, add forward reference to 11.4 > > Revised: > > JN MUST connect to its chosen bootstrap node as specified in Section 11.4. OK. > 2) in 10.5 element 2, change "Acquire the routing table for" to > "Acquire the routing table of". > > Done. OK. > 3) in 10.5 element 3: > JP SHOULD send Attach requests to initiate connections to each of > the peers in the neighbor table as well as to the desired finger > table entries. Note that this does not populate their routing > tables, but only their connection tables, so JP will not get > messages that it is expected to route to other nodes." > here it is unclear that the Attach requests are sent via the AP > and what "desired" finger table entries means, e.g., in contrast to > all?" > > Revised to: > > 3. JN SHOULD send Attach requests to initiate connections to each of > the peers in the Neighbor Table as well as to the desired Finger > Table entries. Note that this does not populate their Routing > Tables, but only their Connection Tables, so JN will not get > messages that it is expected to route to other nodes. This fixes only upper/lower case, but doesn't answer my questions. > 4) Sec. 10.7.2.: > "If a finger table entry is found to have failed," > how is it determined to have "failed"? 10.7.1 is only > related to neighbor failures...does the same definition > apply here?" > > Copied definition from 10.7.1 to 10.7.2:; > > 10.7.2. Handling Finger Table Entry Failure > > If a Finger Table entry is found to have failed (as determined by > connectivity pings or the failure of some request), all references to > the failed peer MUST be removed from the Finger Table and replaced > with the closest preceding peer from the Finger Table or Neighbor > Table. OK. > 5) Sec: 10.7.4.2.: > "A peer SHOULD NOT send Ping requests looking for new finger table > entries more often than the configuration element "chord-ping- > interval", which defaults to 3600 seconds (one per hour)." > This paragraph should probably moved some paragraphs down as it > has been stated yet that a peer should actually send Ping requests > at all (this is explained in the subsequent paragraphs)." > > Restructured as suggested. OK. > 6) Sec 12: > throughout the figures: "Update" should be "UpdateReq" > and Attach should be AttachReq?" > > Revised as suggested. OK. Figure 6 may also indicate use of the flag peer_ready? What does TP stand for? > 7) Inconsistent capitalization of Neighbor Table and Connection Table > > Reviewed for consistency. Ok. > Polina Goltsman > ------------------------ > > 1) PG Major issue 1: sec. 6.3.2: > length field in Forwarding Header covers what exactly? it is not > really clear whether the length field counts the whole message or in > case of fragmentation only the fragment size. When reading Sec 6.7 is > seems that the former is meant, but the definition could and should be > clearer. Similarly, sec. 6.7 should be clear about this, e.g., > describing that all Forwarding Headers are identical for fragments of > the same message with exception of the fragment field. > > Revised: > > Any node along the path can fragment the message but only the final > destination reassembles the fragments. When a node takes a packet > and fragments it, each fragment has a full copy of the Forwarding > Header but the data after the Forwarding Header is broken up in > appropriate sized chunks. The size of the payload chunks needs to > take into account space to allow the via and destination lists to > grow. Each fragment MUST contain a full copy of the via list, > destination list, and ForwardingOptions and MUST contain at least 256 > bytes of the message body. If these elements cannot fit within the > MTU of the underlying datagram protocol, RELOAD fragmentation is not > performed and IP-layer fragmentation is allowed to occur. The length > field MUST contain the size of the message after fragmentation. When > a message MUST be fragmented, it SHOULD be split into equal-sized > fragments that are no larger than the PMTU of the next overlay link > minus 32 bytes. This is to allow the via list to grow before further > fragmentation is required. See above. > 2) PG Major issue 2: sec. 7.4.1.1: replica number handling is unclear > it is unclear how > replica numbers are incremented (e.g., per peer) and what receiving peers > should actually do with this number. Is it important to store the value or > would a boolean be sufficient so that the peer knows that it's a > replica?" > > Revised: > > Added text explaining that replica numbers are allocated and > interpreted by the topology plugin. > > Explained how CHORD-RELOAD interprets the replica numbers. See above. > 3) PG Minor issue 1: Resource-ID used before introduction > > Added explicative text in 1.1: > > The RELOAD network is not only a messaging network. It is also a > storage network, albeit one designed for small-scale transient > storage rather than for bulk storage of large objects. Records are > stored under numeric addresses, called Resource-IDs, which occupy the > same space as node identifiers. Peers are responsible for storing > the data associated with some set of addresses as determined by their > Node-ID. For instance, we might say that every peer is responsible > for storing any data value which has an address less than or equal to > its own Node-ID, but greater than the next lowest Node-ID. Thus, > Node-20 would be responsible for storing values 11-20 Ok. > 4) PG Minor Issue 2: Language in Forwarding and Link Management Layer > definition clumsy. > > Revised as suggested to: > > Forwarding and Link Management Layer: Stores and implements the > Routing Table by providing packet forwarding services between > nodes. It also handles establishing new links between nodes, > including setting up connections for overlay links across NATs > using ICE. Still, I don't think that "Routing Table" is correct here as this belongs to the Topology Plugin. Must be "Connection Table". > 5) PG Minor Issue 3: Change "link layer" to "overlay link layer" in > definition of "overlay link layer". > > Changed as suggested. OK. > 6) PG Minor Issue 4: Add "may" to last para of 1.2 > > Changed "nodes communicate with a central provisioning infrastructure" > to "nodes may communicate with a central provisioning infrastructure" OK. > 7) PG Minor Issue 5: in 1.3 change TLS-PSK to TLS-PSK/TLS-SRP > > Done. OK. > 8) PG Minor Issue 6: Change in Terminology definition > > Changed "Terms in used this document are defined inline when used" to > "Terms in this document are defined inline when used" OK. > 9) PG Minor Issue 7: Definition of Bootstrap node > > Was: > > Bootstrap Node: A network node used by Joining Nodes to help locate > the Admitting Peer > > Suggested change: > > Bootstrap Node: A network node used by Joining Nodes to help > accessing the overlay by forwarding messages to peers > > Retained original definition following review between editors and authors. I still think that "locate" is not the best wording here. > 10) PG Minor Issue 8: Clarify definition of Connection Table > > Changed as suggested to: > > Connection Table: Contains connection information for the set of > nodes to which a node is directly connected, which include nodes > that are not yet available for routing. OK. > 11) PG Minor Issue 9: Clarify "invalid" in definition of Node-OD > > New text: > > Node-ID: A value of fixed but configurable length that uniquely > identifies a node. Node-IDs of all 0s and all 1s are reserved; a > value of zero is not used in the wire protocol but can be used to > indicate an invalid node in implementations and APIs; the Node-ID > of all 1s is used on the wire protocol as a wildcard. OK. > 12) PG Minor Issue 10: Change "plugin algorithm" to "topology plugin > algorithm" in definition of Responsible Peer. > > Changed as suggested. OK. > 13) PG Minor Issue 11: Change "An Usage" to "A Usage" in definition of Usage > > Changed as suggested. OK. Regards, Roland and Polina From internet-drafts@ietf.org Mon Feb 25 09:27:56 2013 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 128C621F92E4; Mon, 25 Feb 2013 09:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jdqf2ZwN7Mq2; Mon, 25 Feb 2013 09:27:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38D921F92D3; Mon, 25 Feb 2013 09:27:54 -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: 4.40 Message-ID: <20130225172754.27510.71805.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 09:27:54 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-sip-09.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, 25 Feb 2013 17:27:56 -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 Protocol = 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 Thomas C. Schmidt Filename : draft-ietf-p2psip-sip-09.txt Pages : 19 Date : 2013-02-25 Abstract: 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 and includes a lookup service for Address of Records (AORs) stored in the overlay. It also defines Globally Routable User Agent Uris (GRUUs) that allow the registrations to map an AOR to a specific node reachable through the overlay. After such initial contact of a peer, the AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-sip There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-p2psip-sip-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-p2psip-sip-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From schmidt@informatik.haw-hamburg.de Mon Feb 25 09:34:06 2013 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 4943421F9048 for ; Mon, 25 Feb 2013 09:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.249 X-Spam-Level: X-Spam-Status: No, score=-104.249 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NLDIwTiZjJ2 for ; Mon, 25 Feb 2013 09:34:05 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id A8F6021F8FD9 for ; Mon, 25 Feb 2013 09:34:05 -0800 (PST) Envelope-to: p2psip@ietf.org Received: from rrcs-67-52-140-5.west.biz.rr.com ([67.52.140.5] helo=[192.168.152.252]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1UA1wC-0004hE-66 for p2psip@ietf.org; Mon, 25 Feb 2013 18:34:04 +0100 Message-ID: <512BA087.20802@informatik.haw-hamburg.de> Date: Mon, 25 Feb 2013 09:33:59 -0800 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: p2psip@ietf.org References: <20130225172755.27510.88698.idtracker@ietfa.amsl.com> In-Reply-To: <20130225172755.27510.88698.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130225172755.27510.88698.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: p2psip@ietf.org Subject: [P2PSIP] Fwd: New Version Notification for draft-ietf-p2psip-sip-09.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, 25 Feb 2013 17:34:06 -0000 Hi all, we did an additional update of the SIP usage draft. This mainly accounts for the feedback of Marc, adding o support of SIPS o specification of regex syntax in the config document and improved a list of details. Please x-ray and support convergence. Cheers, Thomas -------- Original Message -------- Subject: New Version Notification for draft-ietf-p2psip-sip-09.txt Date: Mon, 25 Feb 2013 09:27:55 -0800 From: internet-drafts@ietf.org To: schmidt@informatik.haw-hamburg.de CC: fluffy@cisco.com, ekr@rtfm.com, bbl@lowekamp.net, salman@cs.columbia.edu, hgs@cs.columbia.edu A new version of I-D, draft-ietf-p2psip-sip-09.txt has been successfully submitted by Thomas C. Schmidt and posted to the IETF repository. Filename: draft-ietf-p2psip-sip Revision: 09 Title: A SIP Usage for RELOAD Creation date: 2013-02-25 Group: p2psip Number of pages: 19 URL: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-sip-09.txt Status: http://datatracker.ietf.org/doc/draft-ietf-p2psip-sip Htmlized: http://tools.ietf.org/html/draft-ietf-p2psip-sip-09 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-sip-09 Abstract: 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 and includes a lookup service for Address of Records (AORs) stored in the overlay. It also defines Globally Routable User Agent Uris (GRUUs) that allow the registrations to map an AOR to a specific node reachable through the overlay. After such initial contact of a peer, the AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. The IETF Secretariat From petithug@acm.org Mon Feb 25 13:06:47 2013 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 5269021E80D6 for ; Mon, 25 Feb 2013 13:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4Aqj0l7bLr1 for ; Mon, 25 Feb 2013 13:06: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 803F821E809F for ; Mon, 25 Feb 2013 13:06:40 -0800 (PST) Received: from [IPv6:2601:9:4b80:32:69cb:6b3f:dfaa:1476] (unknown [IPv6:2601:9:4b80:32:69cb:6b3f:dfaa:1476]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 483A620515; Mon, 25 Feb 2013 21:06:39 +0000 (UTC) Message-ID: <512BD261.9090706@acm.org> Date: Mon, 25 Feb 2013 13:06:41 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: =?UTF-8?B?Sm91bmkgTcOkZW5ww6TDpA==?= References: <20130216192050.14673.59154.idtracker@ietfa.amsl.com> <27112A697EB8204D9943EAB8A0E16B710753EE63@ESESSMB305.ericsson.se> In-Reply-To: <27112A697EB8204D9943EAB8A0E16B710753EE63@ESESSMB305.ericsson.se> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-self-tuning-08.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, 25 Feb 2013 21:06:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I confirm that all my comments are addressed in this version. Thanks. On 02/16/2013 11:23 AM, Jouni Mäenpää wrote: > Hi, > > This new version of draft-ietf-p2psip-self-tuning-08 addresses the > comments received during the WGLC. > > Regards, Jouni > > -----Original Message----- From: p2psip-bounces@ietf.org > [mailto:p2psip-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: 16. helmikuuta 2013 21:21 To: i-d-announce@ietf.org Cc: > p2psip@ietf.org Subject: [P2PSIP] I-D Action: > draft-ietf-p2psip-self-tuning-08.txt > > > 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 : A Self-tuning Distributed Hash Table (DHT) for REsource > LOcation And Discovery (RELOAD) Author(s) : Jouni Maenpaa Gonzalo > Camarillo Filename : draft-ietf-p2psip-self-tuning-08.txt Pages : 21 > Date : 2013-02-16 > > Abstract: 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. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-p2psip-self-tuning > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-p2psip-self-tuning-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-self-tuning-08 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ P2PSIP mailing list > P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list > P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRK9JfAAoJECnERZXWan7EfaIQAK7U3HpdozflqJUz9WdlCy8P PQ0FwaFfSVBrydqUIqkodh3R1vzjfYlN5uXWulT7W9a1VsNTK0PDV9jIl/P3Dqs7 rqxhrbH8QE1WJfDyRWeZsilPEuuzA0xOStg3qz9CxD4eCyCMI0RL+KKovUE42i0X w9v4o3QuwPeo/bMCli3umMu4MRuCp2DXl2bfM1OusfkuYx51nFmhbJDSpfMvKwS4 /OPa7v9Ipp+68IAaLjodMvLaPm/X6AkvqLM4kVmC1Q4DPASmznA3fa4U57BVBlA8 ux2pyqKgGIYFUfZ9/zbQQn4Khlnjkwx8vNGANhDFf4qoJ6msPBQkzJc7GmgT9XsP H9ZD0RbjoRi61DCoSi647M7USBTp7mjSeugJK46OEy/leQ/hMW9WpA9/Pg1tbES6 n/DQm2sE4AOtlzz4gMHuT98463uHPYcUi76OsH8KNawlE5249BgtqcNeae/RoayE DOke2RpLB4E2XaWxTkapFWHi8mHtDjQn7NTDt1cFAsdGB5mPYtDEoB4n+bnhkSd+ XwKvqH9WWNPXqaKSIR3edpyKDyAhYalAXKxQ5qAABxb9pUHZX4UxcCZeXK5gTzQU 6Zqd0pFw/vl7gZSPyCerMKeFu0opRQA6u/TeKgnie6vT5RDdAii2lAt99Fj+jeqS MUx7oHTrDx2jA1ZLN07m =vtmv -----END PGP SIGNATURE----- From iesg-secretary@ietf.org Mon Feb 25 13:17:37 2013 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 BA7DE21F934E; Mon, 25 Feb 2013 13:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8vq--gAB39K; Mon, 25 Feb 2013 13:17:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A4921F9348; Mon, 25 Feb 2013 13:17:36 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225211736.11910.23475.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 13:17:36 -0800 Cc: p2psip chair , p2psip mailing list , RFC Editor Subject: [P2PSIP] Protocol Action: 'REsource LOcation And Discovery (RELOAD) Base Protocol' to Proposed Standard (draft-ietf-p2psip-base-26.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, 25 Feb 2013 21:17:37 -0000 The IESG has approved the following document: - 'REsource LOcation And Discovery (RELOAD) Base Protocol' (draft-ietf-p2psip-base-26.txt) as Proposed Standard This document is the product of the Peer-to-Peer Session Initiation Protocol Working Group. The IESG contact persons are Gonzalo Camarillo and Robert Sparks. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-p2psip-base/ Technical Summary This document defines a protocol to manage a secure Peer-to-Peer (P2P) connection structure for use by Session Initiation Protocol (SIP) and other devices which allows these devices to function with minimal central servers. The protocol provides functionality to allow devices to securely form, join, leave, and maintain an overlay of peers. It also allows devices to establish connections between each other, and to collectively augment or replace the location and connection establishment capabilities of traditional client-server SIP in a P2P context. The overlay algorithm layer uses a plugin architecture to accommodate alternative technologies using DHT or other mechanisms. This document specifies a DHT based on CHORD as mandatory-to-implement to ensure interoperability. Diagnostics and tuning of the protocol are being developed by the working group in separate drafts. Working Group Summary This document is a WG document that has WG consensus. Document Quality The document went through an IESG last call and many comments were made by IESG and Gen-Art reviewers. The RAI Area Directors asked guest editors to assist in comment resolution, and Marc Petit-Huguenin and Dean Willis set up a work process where every IESG and Gen-Art comment was entered as an issue in a github issue tracker, with github then being used to track and review document changes. Document authors Cullen Jennings and Eric Rescorla participated in the revision process, with any needful questions being taken to the P2PSIP mailing list for discussion. All DISCUSS and most lesser comments are believed by the editors to have been addressed in the -25 version of the document. Note that there is ongoing debate about the application of RFC 2119 language in the document. The Gen-Art reviewer and one editor preferred a style with extensive use of RFC 2119 language for all normative text. Following an extended discussion on the IETF mailing list, a compromise style has been a pplied to the document. Personnel David Bryan is the document shepherd. Gonzalo Camarillo is the responsible AD. From iesg-secretary@ietf.org Mon Feb 25 13:17:38 2013 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 1AFB521F934E for ; Mon, 25 Feb 2013 13:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QpaqBSDcvMs; Mon, 25 Feb 2013 13:17:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2EF521F935F; Mon, 25 Feb 2013 13:17:36 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.40 X-IETF-Draft-string: draft-ietf-p2psip-base X-IETF-Draft-revision: 26 Message-ID: <20130225211736.11910.59958.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 13:17:36 -0800 Cc: p2psip chair , p2psip mailing list , RFC Editor Subject: [P2PSIP] Protocol Action: 'REsource LOcation And Discovery (RELOAD) Base Protocol' to Proposed Standard (draft-ietf-p2psip-base-26.txt) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org 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, 25 Feb 2013 21:17:38 -0000 The IESG has approved the following document: - 'REsource LOcation And Discovery (RELOAD) Base Protocol' (draft-ietf-p2psip-base-26.txt) as Proposed Standard This document is the product of the Peer-to-Peer Session Initiation Protocol Working Group. The IESG contact persons are Gonzalo Camarillo and Robert Sparks. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-p2psip-base/ Technical Summary This document defines a protocol to manage a secure Peer-to-Peer (P2P) connection structure for use by Session Initiation Protocol (SIP) and other devices which allows these devices to function with minimal central servers. The protocol provides functionality to allow devices to securely form, join, leave, and maintain an overlay of peers. It also allows devices to establish connections between each other, and to collectively augment or replace the location and connection establishment capabilities of traditional client-server SIP in a P2P context. The overlay algorithm layer uses a plugin architecture to accommodate alternative technologies using DHT or other mechanisms. This document specifies a DHT based on CHORD as mandatory-to-implement to ensure interoperability. Diagnostics and tuning of the protocol are being developed by the working group in separate drafts. Working Group Summary This document is a WG document that has WG consensus. Document Quality The document went through an IESG last call and many comments were made by IESG and Gen-Art reviewers. The RAI Area Directors asked guest editors to assist in comment resolution, and Marc Petit-Huguenin and Dean Willis set up a work process where every IESG and Gen-Art comment was entered as an issue in a github issue tracker, with github then being used to track and review document changes. Document authors Cullen Jennings and Eric Rescorla participated in the revision process, with any needful questions being taken to the P2PSIP mailing list for discussion. All DISCUSS and most lesser comments are believed by the editors to have been addressed in the -25 version of the document. Note that there is ongoing debate about the application of RFC 2119 language in the document. The Gen-Art reviewer and one editor preferred a style with extensive use of RFC 2119 language for all normative text. Following an extended discussion on the IETF mailing list, a compromise style has been a pplied to the document. Personnel David Bryan is the document shepherd. Gonzalo Camarillo is the responsible AD. From petithug@acm.org Tue Feb 26 09:50:31 2013 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 E86D221F8793 for ; Tue, 26 Feb 2013 09:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNJ31y9pVE6v for ; Tue, 26 Feb 2013 09:50:31 -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 B849221F8740 for ; Tue, 26 Feb 2013 09:50:30 -0800 (PST) Received: from [IPv6:2601:9:4b80:32:21c7:2154:4ebf:7150] (unknown [IPv6:2601:9:4b80:32:21c7:2154:4ebf:7150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 7BC80204B0 for ; Tue, 26 Feb 2013 17:50:29 +0000 (UTC) Message-ID: <512CF5E8.5000604@acm.org> Date: Tue, 26 Feb 2013 09:50:32 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: P2PSIP Mailing List References: <20130114232302.20758.60139.idtracker@ietfa.amsl.com> <50F49761.7000408@acm.org> In-Reply-To: <50F49761.7000408@acm.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Bootstrap redirection authentication [was Re: Fwd: I-D Action: draft-petithuguenin-p2psip-reload-one-to-many-00.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: Tue, 26 Feb 2013 17:50:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I did not release a new version of this draft because as I was working on improving it I discovered some issues and I was not able to decide on the right solution. So I will present this in Orlando if I get presentation time, but I would like to start the discussion now. The problem with Anycast is that there is no guarantee on the long term that the same physical endpoint will be reached when using such address. This is not a problem for short-term association, and even TCP is known to work fine in this case. But in some cases (RELOAD section 3.2.1 second bullet) a client can establish a long-term association with a bootstrap server, and this association may fail. So the solution used in -one-to-many-00 is to first send a STUN binding to the Anycast address which will be answered with a 300 redirect that contains a Unicast address that can be used for long term association. This also works fine with multicast and broadcast. No problem so far. The problem is that it is relatively easy to redirect the client to the wrong IP address, which is why this kind of mechanism requires some form of authentication, so the client knows that the answer is from the real server. Note that the client will anyway quickly discover that the IP address does not use a correct certificate, so perhaps this attack is harmless. One solution is to use the long-term authentication mechanism of STUN, using the same username and password that was used to acquire the RELOAD certificate. The client checks the MESSAGE-INTEGRITY in the response to verify that the server really knows the password. I do not really like this solution, because it requires to distribute and synchronize the usernames/passwords on a lot of different servers. Another solution may be to use the fact that the bootstrap servers are contacted after a certificate is retrieved from the enrollment server (although an implementation may want to query the real address in parallel) to establish a DTLS connection with the Anycast address, using this newly acquired certificate, and then send the STUN Binding over it. That's my preferred solution, but that looks a little bit complex for that purpose (although it does not add more code to an implementation, as DTLS is required for RELOAD anyway). Another issue: I was surprised to discover that it is forbidden by RFC 2373 to use an anycast address as source address of an IPv6 packet. I am not sure to understand all this, but it seems that the response in this case would be filtered by some NATs, which is the problem that we wanted to fix in the first place. OTOH, users of IPv6 NATs will get exactly what they deserve. Comments? On 01/14/2013 03:40 PM, Marc Petit-Huguenin wrote: > As agreed in Vancouver[1, this is a new draft that take all the > multicast/anycast and broadcast stuff that is removed in -base-24 and try > to make it working with anycast. Note that the solution proposed does not > require naked Ping, and that make bootstrap nodes easier to implement. > > Comments, suggestions and questions as always are welcome. > > > [1] https://www.ietf.org/proceedings/84/minutes/minutes-84-p2psip > > -------- Original Message -------- Subject: I-D Action: > draft-petithuguenin-p2psip-reload-one-to-many-00.txt Date: Mon, 14 Jan 2013 > 15:23:02 -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 : Anycast, Multicast or Broadcast Bootstrap Nodes for > REsource LOcation And Discovery (RELOAD) Author(s) : Marc > Petit-Huguenin Filename : > draft-petithuguenin-p2psip-reload-one-to-many-00.txt Pages : 6 > Date : 2013-01-14 > > Abstract: This document describes an extension to REsource LOcation And > Discovery (RELOAD) that permits to contact a bootstrap node using an > Anycast, Multicast or Broadcast IP address. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-petithuguenin-p2psip-reload-one-to-many > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-petithuguenin-p2psip-reload-one-to-many-00 > > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRLPXmAAoJECnERZXWan7EKFQQAKgahaJFIiHfF++LFFKpT6o+ awtKMCQzTOneZB4B9mZ6lghysUMe8ASu+aC/K7OKDyOHeIZIKKsizl0reQqKjQk7 lnuAtQJ/0H5fK0DMGdOeV20gJd9H7sKo/TJ/ZTx0OX32NwKGPfkkWn0mScaTGFMp ZAIhW2YzN+lu/3MZoBN9akeP8tkaNGXuK5Dz6Yi5JJy9l3aDE9MVCP2084NAxjrJ EpTPARyywTB/fhAUyRh2MQtuJkA3zu+PrRPIaStgVs8jpPyuHb1YTPjtQ0KeOR4y wS6bWQao1VNRaEDoIzhykw5mn7VR0Hw/aF8SBMdfnAuGo1gdukG6gMYeHQfikd3m Ore/qZvAlynExxGZygcCw4I0BS7TefTW/lAx3vEbrwtDt42+LW90cNLJJ6mvr/5f L3tD4wopnJos7Qwr6qB3PIkmg9ClkwOtAbksAVsrB3w9XG6ZU72fhmjRG4FPM3K0 49Kvf1wA9mo2lgf+SGoMEZP4EeYa/5gSEmV3aag6rFV1FvLb4aSfzZPUnafUi6cd MGENHidK3dEmRmHRlGGaNxW8vMRDRvT44XtWyeIp8LEzi2k/Lwu08EpVeD3NNoSM +3RxUXzvYEPgiQbb34XoLtuLDTVDVa1SEn4XTiX5EAdFyNs8JtPavyUdess/GKAt 4V48koqGrY0j4kCTkgLk =Oazn -----END PGP SIGNATURE----- From prvs=762e8e9c2=schmidt@informatik.haw-hamburg.de Tue Feb 26 11:22:41 2013 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 D768921F87FB for ; Tue, 26 Feb 2013 11:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.916 X-Spam-Level: X-Spam-Status: No, score=-102.916 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dN7R7XDJVBzF for ; Tue, 26 Feb 2013 11:22:40 -0800 (PST) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id E67BC21F8746 for ; Tue, 26 Feb 2013 11:22:39 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 26 Feb 2013 20:22:38 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id B5AE61068729; Tue, 26 Feb 2013 20:22:38 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01174-02; Tue, 26 Feb 2013 20:22:36 +0100 (CET) Received: from [192.168.152.192] (rrcs-67-52-140-5.west.biz.rr.com [67.52.140.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 749201068722; Tue, 26 Feb 2013 20:22:35 +0100 (CET) Message-ID: <512D0B77.3080404@informatik.haw-hamburg.de> Date: Tue, 26 Feb 2013 11:22:31 -0800 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <20130114232302.20758.60139.idtracker@ietfa.amsl.com> <50F49761.7000408@acm.org> <512CF5E8.5000604@acm.org> In-Reply-To: <512CF5E8.5000604@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Bootstrap redirection authentication [was Re: Fwd: I-D Action: draft-petithuguenin-p2psip-reload-one-to-many-00.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: Tue, 26 Feb 2013 19:22:42 -0000 Hi Marc, just a short remark on the use of IPv6 Anycast addresses: RFC2373 is deprecated by RFC4291 and this newer document removes the restrictions on using Anycast as a source address. So this one issue should be gone ;) Cheers Thomas On 26.02.2013 09:50, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I did not release a new version of this draft because as I was working on > improving it I discovered some issues and I was not able to decide on the > right solution. So I will present this in Orlando if I get presentation time, > but I would like to start the discussion now. > > The problem with Anycast is that there is no guarantee on the long term that > the same physical endpoint will be reached when using such address. This is > not a problem for short-term association, and even TCP is known to work fine > in this case. But in some cases (RELOAD section 3.2.1 second bullet) a client > can establish a long-term association with a bootstrap server, and this > association may fail. So the solution used in -one-to-many-00 is to first > send a STUN binding to the Anycast address which will be answered with a 300 > redirect that contains a Unicast address that can be used for long term > association. This also works fine with multicast and broadcast. No problem > so far. > > The problem is that it is relatively easy to redirect the client to the wrong > IP address, which is why this kind of mechanism requires some form of > authentication, so the client knows that the answer is from the real server. > Note that the client will anyway quickly discover that the IP address does not > use a correct certificate, so perhaps this attack is harmless. > > One solution is to use the long-term authentication mechanism of STUN, using > the same username and password that was used to acquire the RELOAD > certificate. The client checks the MESSAGE-INTEGRITY in the response to > verify that the server really knows the password. I do not really like this > solution, because it requires to distribute and synchronize the > usernames/passwords on a lot of different servers. > > Another solution may be to use the fact that the bootstrap servers are > contacted after a certificate is retrieved from the enrollment server > (although an implementation may want to query the real address in parallel) to > establish a DTLS connection with the Anycast address, using this newly > acquired certificate, and then send the STUN Binding over it. That's my > preferred solution, but that looks a little bit complex for that purpose > (although it does not add more code to an implementation, as DTLS is required > for RELOAD anyway). > > Another issue: I was surprised to discover that it is forbidden by RFC 2373 > to use an anycast address as source address of an IPv6 packet. I am not sure > to understand all this, but it seems that the response in this case would be > filtered by some NATs, which is the problem that we wanted to fix in the first > place. OTOH, users of IPv6 NATs will get exactly what they deserve. > > Comments? > > On 01/14/2013 03:40 PM, Marc Petit-Huguenin wrote: >> As agreed in Vancouver[1, this is a new draft that take all the >> multicast/anycast and broadcast stuff that is removed in -base-24 and try >> to make it working with anycast. Note that the solution proposed does not >> require naked Ping, and that make bootstrap nodes easier to implement. >> >> Comments, suggestions and questions as always are welcome. >> >> >> [1] https://www.ietf.org/proceedings/84/minutes/minutes-84-p2psip >> >> -------- Original Message -------- Subject: I-D Action: >> draft-petithuguenin-p2psip-reload-one-to-many-00.txt Date: Mon, 14 Jan 2013 >> 15:23:02 -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 : Anycast, Multicast or Broadcast Bootstrap Nodes for >> REsource LOcation And Discovery (RELOAD) Author(s) : Marc >> Petit-Huguenin Filename : >> draft-petithuguenin-p2psip-reload-one-to-many-00.txt Pages : 6 >> Date : 2013-01-14 >> >> Abstract: This document describes an extension to REsource LOcation And >> Discovery (RELOAD) that permits to contact a bootstrap node using an >> Anycast, Multicast or Broadcast IP address. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-petithuguenin-p2psip-reload-one-to-many >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-petithuguenin-p2psip-reload-one-to-many-00 >> >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> > > - -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBCAAGBQJRLPXmAAoJECnERZXWan7EKFQQAKgahaJFIiHfF++LFFKpT6o+ > awtKMCQzTOneZB4B9mZ6lghysUMe8ASu+aC/K7OKDyOHeIZIKKsizl0reQqKjQk7 > lnuAtQJ/0H5fK0DMGdOeV20gJd9H7sKo/TJ/ZTx0OX32NwKGPfkkWn0mScaTGFMp > ZAIhW2YzN+lu/3MZoBN9akeP8tkaNGXuK5Dz6Yi5JJy9l3aDE9MVCP2084NAxjrJ > EpTPARyywTB/fhAUyRh2MQtuJkA3zu+PrRPIaStgVs8jpPyuHb1YTPjtQ0KeOR4y > wS6bWQao1VNRaEDoIzhykw5mn7VR0Hw/aF8SBMdfnAuGo1gdukG6gMYeHQfikd3m > Ore/qZvAlynExxGZygcCw4I0BS7TefTW/lAx3vEbrwtDt42+LW90cNLJJ6mvr/5f > L3tD4wopnJos7Qwr6qB3PIkmg9ClkwOtAbksAVsrB3w9XG6ZU72fhmjRG4FPM3K0 > 49Kvf1wA9mo2lgf+SGoMEZP4EeYa/5gSEmV3aag6rFV1FvLb4aSfzZPUnafUi6cd > MGENHidK3dEmRmHRlGGaNxW8vMRDRvT44XtWyeIp8LEzi2k/Lwu08EpVeD3NNoSM > +3RxUXzvYEPgiQbb34XoLtuLDTVDVa1SEn4XTiX5EAdFyNs8JtPavyUdess/GKAt > 4V48koqGrY0j4kCTkgLk > =Oazn > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From petithug@acm.org Tue Feb 26 11:29:59 2013 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 76FAE21F84F0 for ; Tue, 26 Feb 2013 11:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYG3JIyRhLuI for ; Tue, 26 Feb 2013 11:29:58 -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 14DE121F84BC for ; Tue, 26 Feb 2013 11:29:58 -0800 (PST) Received: from [IPv6:2601:9:4b80:32:21c7:2154:4ebf:7150] (unknown [IPv6:2601:9:4b80:32:21c7:2154:4ebf:7150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 07AE7204B0; Tue, 26 Feb 2013 19:29:56 +0000 (UTC) Message-ID: <512D0D37.5010406@acm.org> Date: Tue, 26 Feb 2013 11:29:59 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: "Thomas C. Schmidt" References: <20130114232302.20758.60139.idtracker@ietfa.amsl.com> <50F49761.7000408@acm.org> <512CF5E8.5000604@acm.org> <512D0B77.3080404@informatik.haw-hamburg.de> In-Reply-To: <512D0B77.3080404@informatik.haw-hamburg.de> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Bootstrap redirection authentication [was Re: Fwd: I-D Action: draft-petithuguenin-p2psip-reload-one-to-many-00.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: Tue, 26 Feb 2013 19:29:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/26/2013 11:22 AM, Thomas C. Schmidt wrote: > Hi Marc, > > just a short remark on the use of IPv6 Anycast addresses: > > RFC2373 is deprecated by RFC4291 and this newer document removes the > restrictions on using Anycast as a source address. > > So this one issue should be gone ;) Great, thanks. > > Cheers > > Thomas > > On 26.02.2013 09:50, Marc Petit-Huguenin wrote: I did not release a new > version of this draft because as I was working on improving it I discovered > some issues and I was not able to decide on the right solution. So I will > present this in Orlando if I get presentation time, but I would like to > start the discussion now. > > The problem with Anycast is that there is no guarantee on the long term > that the same physical endpoint will be reached when using such address. > This is not a problem for short-term association, and even TCP is known to > work fine in this case. But in some cases (RELOAD section 3.2.1 second > bullet) a client can establish a long-term association with a bootstrap > server, and this association may fail. So the solution used in > -one-to-many-00 is to first send a STUN binding to the Anycast address > which will be answered with a 300 redirect that contains a Unicast address > that can be used for long term association. This also works fine with > multicast and broadcast. No problem so far. > > The problem is that it is relatively easy to redirect the client to the > wrong IP address, which is why this kind of mechanism requires some form > of authentication, so the client knows that the answer is from the real > server. Note that the client will anyway quickly discover that the IP > address does not use a correct certificate, so perhaps this attack is > harmless. > > One solution is to use the long-term authentication mechanism of STUN, > using the same username and password that was used to acquire the RELOAD > certificate. The client checks the MESSAGE-INTEGRITY in the response to > verify that the server really knows the password. I do not really like > this solution, because it requires to distribute and synchronize the > usernames/passwords on a lot of different servers. > > Another solution may be to use the fact that the bootstrap servers are > contacted after a certificate is retrieved from the enrollment server > (although an implementation may want to query the real address in parallel) > to establish a DTLS connection with the Anycast address, using this newly > acquired certificate, and then send the STUN Binding over it. That's my > preferred solution, but that looks a little bit complex for that purpose > (although it does not add more code to an implementation, as DTLS is > required for RELOAD anyway). > > Another issue: I was surprised to discover that it is forbidden by RFC > 2373 to use an anycast address as source address of an IPv6 packet. I am > not sure to understand all this, but it seems that the response in this > case would be filtered by some NATs, which is the problem that we wanted to > fix in the first place. OTOH, users of IPv6 NATs will get exactly what > they deserve. > > Comments? > > On 01/14/2013 03:40 PM, Marc Petit-Huguenin wrote: >>>> As agreed in Vancouver[1, this is a new draft that take all the >>>> multicast/anycast and broadcast stuff that is removed in -base-24 and >>>> try to make it working with anycast. Note that the solution proposed >>>> does not require naked Ping, and that make bootstrap nodes easier to >>>> implement. >>>> >>>> Comments, suggestions and questions as always are welcome. >>>> >>>> >>>> [1] https://www.ietf.org/proceedings/84/minutes/minutes-84-p2psip >>>> >>>> -------- Original Message -------- Subject: I-D Action: >>>> draft-petithuguenin-p2psip-reload-one-to-many-00.txt Date: Mon, 14 >>>> Jan 2013 15:23:02 -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 : Anycast, Multicast or Broadcast Bootstrap Nodes >>>> for REsource LOcation And Discovery (RELOAD) Author(s) : Marc >>>> Petit-Huguenin Filename : >>>> draft-petithuguenin-p2psip-reload-one-to-many-00.txt Pages >>>> : 6 Date : 2013-01-14 >>>> >>>> Abstract: This document describes an extension to REsource LOcation >>>> And Discovery (RELOAD) that permits to contact a bootstrap node using >>>> an Anycast, Multicast or Broadcast IP address. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-petithuguenin-p2psip-reload-one-to-many >>>> >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-petithuguenin-p2psip-reload-one-to-many-00 >>>> >>>> >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> > >> _______________________________________________ P2PSIP mailing list >> P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip >> > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRLQ02AAoJECnERZXWan7E/F0QAJ2qysycQK5q+OFMPE90TrPH L1Q+y4nJtBQ2HOog4wAqW1ZyK9edwXtkDDFycqF0zBiGKa5Tvq/g+CLgEyew4Kip AiXhKjroqHFlhsVyf0qq+xFmRfBpNqPEbId44AzIK0INsAgSgcCQWQ2Ufn5kyrLd 4F4of5flFLfekSOBZkA08PdDwsr5jhcGS/ccadiCecXnWHxdgfbDRjNTHSdoaqCM W2JzM9soaJEbyOy7uj09lihfnwb+/rsANNTINmUbqOYMfubXp+6dY6D+7w3+rhTe tyNDJxMwvTeNUaMqnkulB84oM9FtEgkrtITnFnzvCF0k6x0ZrLbH0un7AVex8FyW HmQyAl7s8Mqlb8xwL3vOEQqSa4euCGW9vSHqF9zu6omvoBRP6u8finKBMclygFij VNByf3kBk9zAvhLG/1BE0TdbR5UCtsq6Fv0YmJEXFaHMVggTqMM7SW1q1RFuRKiD rD0O6cKmlRus77wz4RhOK1lFlgLej+1tcFQSdKTzY1j12MeNpZhD3t60yI5c4cC1 Bpq+Bgz7lJ++3AISAQQQhqDghtvaWo+GaPrXtWgHYnYgu2/3PzigdE7IzmE00kYr kccKk/OgjwfvUhfTqqLLgIuHVR4VW7Jo8Nj+Sl5xOcU7n4p9Nt6X4m7XG74EV4QG xy87M7jwHY1M2MiU1/9F =0mBG -----END PGP SIGNATURE----- From petithug@acm.org Tue Feb 26 11:58:10 2013 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 19E4221F86B2 for ; Tue, 26 Feb 2013 11:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.819 X-Spam-Level: X-Spam-Status: No, score=-101.819 tagged_above=-999 required=5 tests=[AWL=-0.719, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NeB+t3tCwJFJ for ; Tue, 26 Feb 2013 11:58:08 -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 2D9BD21F87D6 for ; Tue, 26 Feb 2013 11:58:02 -0800 (PST) Received: from [IPv6:2601:9:4b80:32:21c7:2154:4ebf:7150] (unknown [IPv6:2601:9:4b80:32:21c7:2154:4ebf:7150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 11237204B0; Tue, 26 Feb 2013 19:58:00 +0000 (UTC) Message-ID: <512D13CB.9040606@acm.org> Date: Tue, 26 Feb 2013 11:58:03 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: =?UTF-8?B?Sm91bmkgTcOkZW5ww6TDpA==?= References: <1359673911.4472.18.camel@acorde.it.uc3m.es> <511D341E.6060905@acm.org> <511E0E0B.6070103@hs-mannheim.de> <511E6779.80706@acm.org> <27112A697EB8204D9943EAB8A0E16B710753ED3E@ESESSMB305.ericsson.se> <51220EA9.2060200@hs-mannheim.de> <27112A697EB8204D9943EAB8A0E16B7107545D2D@ESESSMB305.ericsson.se> <27112A697EB8204D9943EAB8A0E16B710754C5D7@ESESSMB305.ericsson.se> In-Reply-To: <27112A697EB8204D9943EAB8A0E16B710754C5D7@ESESSMB305.ericsson.se> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "p2psip-chairs@tools.ietf.org" , "p2psip@ietf.org" Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06 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, 26 Feb 2013 19:58:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 This new version addresses all my comments, and is really better at explaining how Redir works. Thanks. On 02/23/2013 12:59 AM, Jouni Mäenpää wrote: > Hi, > > The comments below have now been addressed in version -08 of the draft. The > changes in the new version include: > > - The temporary local caching mechanism for RedirServiceProvider records > fetched during a service lookup operation that is described below was added > to the draft - The text was clarified further - New examples were added to > clarify how ReDiR tree nodes are numbered and how intervals are assigned to > tree nodes > > Regards, Jouni > > -----Original Message----- From: p2psip-bounces@ietf.org > [mailto:p2psip-bounces@ietf.org] On Behalf Of Jouni Mäenpää Sent: 18. > helmikuuta 2013 21:25 To: Joscha Schneider Cc: > p2psip-chairs@tools.ietf.org; p2psip@ietf.org Subject: Re: [P2PSIP] WGLC > for draft-ietf-p2psip-service-discovery-06 > > Hi Joscha, > > Thanks for the comments! Answering the first comment inline, need some more > time to check the second comment. > > Regards, Jouni > > -----Original Message----- From: Joscha Schneider > [mailto:j.schneider@hs-mannheim.de] Sent: 18. helmikuuta 2013 13:21 To: > Jouni Mäenpää Cc: Marc Petit-Huguenin; p2psip-chairs@tools.ietf.org; > p2psip@ietf.org Subject: Re: [P2PSIP] WGLC for > draft-ietf-p2psip-service-discovery-06 > > two comments inline > > regards joscha > > > Am 16.02.2013 18:55, schrieb Jouni Mäenpää: >> Hi Marc and Joscha, >> >> Thanks for the comments! Answers inline. >> >> Regards, Jouni >> >> -----Original Message----- From: p2psip-bounces@ietf.org >> [mailto:p2psip-bounces@ietf.org] On Behalf Of Joscha Schneider Sent: 15. >> helmikuuta 2013 12:30 To: Marc Petit-Huguenin Cc: >> p2psip-chairs@tools.ietf.org; p2psip@ietf.org Subject: Re: [P2PSIP] WGLC >> for draft-ietf-p2psip-service-discovery-06 >> >> I can confirm that the draft might need some improvements to make the >> implementation easier. I did a basic implementation but I'm not quite >> sure that I handled everything correct. >> >> [Jouni]: I'll try to improve the text in the next version of the draft. >> >> Especially the definition of the successor seams a bit unclear for me. A >> simple example: Only a single service provider with Node-ID 2 provides a >> service. Node with ID 7 performs a lookup... How should it be handled? I >> implemented it as follows: in case a lookup reveals only a single service >> provider it must be the direct successor. >> >> [Jouni]: What would happen in this case is that the upward walk of the >> service lookup reaches the root level because no successor can be found >> from the lower levels in the tree. In my implementation, when this >> happens, I'm selecting either the closest successor at the root level or, >> if there is no successor, select one of the available service providers >> randomly (or pick the only service provider if there is only one like you >> are doing in your implementation). Anyway, I'll add text to clarify this >> to the next version of the draft. >> >> Further notice, due to the periodically triggered re-registration the >> consistency of the ReDiR tree can not be always ensured. Theoretically >> this can lead to failed lookup processes. This derives from the fact that >> each new service provider registration might affect the re-registration >> of the former service providers which again might affect the >> re-registrations of other service providers. >> >> [Jouni]: Not sure about this. I could be wrong, but why would the >> re-registration of a service provider affect the re-registrations of >> other service providers? I mean, when a service provider X re-registers >> or registers, it simply stores its own record at different levels in the >> ReDiR tree as a part of the upward and downward walks. This >> re-registration process does not influence the (re-)registrations of >> other service providers. Or did I understand your comment incorrectly? > >> I'll try to make an example: Two service provider are even in Level 4 in >> the same interval. First service prover (X) stops registration downwalk >> at level 2 because it's the only one. Second service provider (Y) goes >> down to level 3 to finish its downwalk. X starts re-registration. Now the >> downwalk need to go down to level 4 as level 2 and 3 are shared Y. > Now Y starts re-registration. Goes down to level 5 as level 3 and 4 are > shared now. X re-registers again. goes down to level 5. Finally both > service providers have found the leaves and the tree is consistent. In > between, service lookups might go down to a level at which no service > provider information is stored (yet). > > [Jouni]: Ok, I think you're right, that can happen. How often do you think > it would occur? The default branching factor of the ReDiR tree is 10. I > guess that the Node-IDs of the service providers that are (re-)registering > at the same time would need to be very close to each other in order for the > service providers to end up into the same interval at two levels of the > tree (with the default branching factor of 10, level 2 has 1000 intervals, > level 3 10000, level 5, 100000, etc.). > > I guess there might also be other similar situations, though, such as when > a RedirServiceProvider record expires within a given interval at some level > just before a service lookup for which that record is the closest successor > reaches that level and interval, and before the re-registration stores a > new RedirServiceProvider record in that interval. This situation should be > quite rare, though. > > One potential strategy for dealing with the situations above is to fail the > service lookup procedure and retry it - if the temporary inconsistency has > been fixed by a re-registration between the old and new service lookup, the > new service lookup will succeed. > > Another strategy that we are using in our ReDiR implementation is that we > are temporarily (for the duration of a service lookup) caching/storing the > RedirServiceProvider entries fetched during that specific service lookup at > the peer that is carrying out the service lookup. Thus, if for whatever > reason the service lookup would happen to go down to a level at which no > service provider information is stored, the peer that is carrying out the > search can go through the locally cached RedirServiceProvider entries to > find the closest successor of the search key from among the cached entries. > This strategy would allow one to recover from the scenarios described > above. Do you think it would help if we described this strategy in the > draft? Do you have some other potential solutions in mind? > >> more inline... >> >> Regards Joscha >> >> Am 14.02.2013 19:59, schrieb Marc Petit-Huguenin: > I did a review of this draft, and I have some concerns. > > First of all some parts of the I-D are verbatim copy of the text in the > original paper. Is that OK? >>> [Jouni]: I guess the main reason for that is that ReDiR is pretty >>> complex to describe. So we took a safe bet and tried to reuse some of >>> the text (the algorithm description) from the paper. But since there >>> are also comments that the text is difficult to follow, I'll make an >>> attempt to reformulate it in the next version of the draft. >>> > Probably because some of the text comes from a research paper, it was very > difficult to understand fro me, and I am not sure that I yet understood > everything - I still have to write an implementation of this, and > unfortunately to not have enough time to do so before the end of the WGLC. > On the other hand, I know that RELOAD.NET has an implementation, so I guess > it is implementable. >>> [Jouni]: I have also implemented the draft and think I got the >>> implementation right. So if you have any further questions about things >>> that are unclear, let me know and I can check the code to see how that >>> specific thing was implemented (and clarify the same issue in the draft >>> if necessary). >>> > But I was not able to make sense of something in the example in section 7: > Why is the 4th peer added to level 0? Bullet 4 in Section 4.3 says "Node N > MUST continue [repeating steps 2 and 3] until it reaches either the root or > a level a which n.id is not the lowest or highest Node-ID in the interval > I(level, n.id)". In this case 4 is not the lowest or highest Node-ID in > the interval (lowest is 2, highest is 7), so why is it added to this node? >>> I think the example is simply following the rules. At level 1 peer 4 is >>> the lowest. So go up and fetch and store. >>> >>> [Jouni]: That's correct. Node 4 starts from the starting level, which >>> is level 2. It stores its record on level 2. Since Node-ID 4 is the >>> lowest (only) Node-ID in its interval, the upward walk continues to >>> level 1. At level 1, Node-ID 4 is also the lowest Node-ID in its >>> interval and thus the upward walk continues all the way to the root >>> level. Node 4 stores its record in that level. Since Node-ID is neither >>> the lowest nor highest Node-ID, the upward walk stops at level 0 >>> (although it would stop anyway at level 0 since it is of course not >>> possible to go further up in the tree). >>> > But if i reveal correct that fact caused a few headaches for me too. Why > does the store does not depend on the information that was fetched before? >>> [Jouni]: That is how it goes - if there has been a decision that the >>> upward walk shall continue to the next level, a record is stored at >>> that level 'automatically', regardless of the contents of the tree >>> node. The contents of the tree node (i.e., whether n.id is sandwiched >>> or not) will influence the decision on whether to stop the upward walk >>> or continue it. The idea in the upward and downward walks is to ensure >>> that the tree is populated densely enough so that service lookups will >>> finish without requiring too many Fetch operations. >> But does this make sense? If I recall correct the registration >> information of node 3 and 4 in Level 0 in the draft example will never be >> used in lookup processes. As far as I understood at most two service >> provider entries are needed (lowest and highest) in each tree node to >> make the algorithm work. All sandwiched service provider information is >> not needed. Most of them will also expire and not be renewed in the >> re-registration process in case other service providers have registered >> in the meantime. I think this 'automatic' store process makes the tree >> just a bit more wired and the algorithm mode difficult to understand. Or >> do you see a resonable reason for this behaviour that I don't see. > BTW a similar example for the service lookup would be useful. >>> [Jouni]: Ok, I'll add an example in the next version of the draft. >>> > More comments: > > - Section 3, 3 paragraph: "contains a list of Node-IDs" > > Technically each node is a Dictionary whose keys are Node-IDs and values > contain a list of Destinations. >>> [Jouni]: Ok, I'll modify this in the next version of the draft. >>> > - Section 4.1 > > s/detination_list/destination_list/ >>> [Jouni]: Ok, will change this one also in the next version of the >>> draft. >>> > - Section 4.1 > > namespace is an opaque value but the charset and conversion between > character string and byte string for the namespace is not defined. >>> confirm >>> >>> [Jouni]: Would specifying that it is an opaque UTF-8 encoded string be >>> enough? >>> > - Section 8 > > The document says that the redir namespace is added to the > element, meaning that all nodes MUST understand > ReDIR, but isn't that against one of the goal of ReDIR, which is that by > using standard Store/Fetch, only a node wishing to store or fetch has to > implement ReDIR? >>> I think at least the RedirServiceProvider Data Structure must be >>> supported. And also the Access Control Rules. But the algorithm might >>> not be mandatory needed. >>> >>> The RedirServiceProvider Data Structure does not need to be understood >>> by the peer storing it, but you are right about the Access Control >>> rule. My own draft about storing the Access Control rule solves this >>> problem but, even if it is accepted as WG item, we do not want to add a >>> normative reference to it. >>> >>> So I withdraw what I said - redir needs to be a a mandatory extension >>> at least until new access control policies no longer have to be >>> hardcoded. >>> >>> [Jouni]: Ok, so if I understood correctly, it is ok to leave the text >>> as it is. >>> > - Section 10.3 > > I think that we need a bit more explanation on what the turn-server and > voice-mail service providers are. >>> [Jouni]: I could remove the voice-mail service provider from the next >>> version of the draft as I don't have a good explanation for that. For >>> turn-server I will add some text. >>> > On 01/31/2013 03:11 PM, Carlos Jesús Bernardos Cano wrote: >>>>> Hi, >>>>> >>>>> Hereby we are issuing a WGLC for >>>>> draft-ietf-p2psip-service-discovery-06. >>>>> >>>>> The WGLC will be open till the 15th of February. We kindly ask the >>>>> WG to review the document and provide comments. >>>>> >>>>> If you have no comments and think the document is ready to be >>>>> submitted to IESG, please do send a note stating that to the WG >>>>> ML. >>>>> >>>>> Additional information about the document is below: >>>>> >>>>> Title : Service Discovery Usage for REsource LOcation >>>>> And Discovery (RELOAD) Author(s) : Jouni Maenpaa Gonzalo >>>>> Camarillo Filename : >>>>> draft-ietf-p2psip-service-discovery-06.txt Pages : 15 Date >>>>> : 2012-10-01 >>>>> >>>>> Abstract: 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. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-p2psip-service-discovery >>>>> >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-p2psip-service-discovery-06 >>>>> >>>>> >>> _______________________________________________ P2PSIP mailing list >>> P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip >> _______________________________________________ P2PSIP mailing list >> P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list > P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list > P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRLRPDAAoJECnERZXWan7ESQAQAKp49csNIYytMJ9NdACdQBTW S6MXxhymlmDWOjsj6OjYUKb1NOFbT5pbs4sM5eJ22v+DyTWOoQ/YWu+hnShPL9zV pfOgn66TzL2KsAI0xkKB7QhyYIUmH9ODrf3NPcs8u3FUw4exXGInh9Y96hq0pMfD KeH/UTVOQ4W2O860xpogWaoGOJ89fhqRT9B4HD36uw97MD/hh5KbZ9i7/RhxhtKa G0ayNXzyxziql3LRMBe8ty31+/T4/L6JK9TJVLrK1xnEg2yRmQslbFgVeNQhd3U6 uEIPKuDJRP04IKQ3OwLTvmteg3q16GJLMDsTFcD6C0i02701BNwP5WI2XuFXQBEp JoPtFnAvLS8KrdjgpIO4cXXYfTbjcskRh9261M58iv7o9WGQEefsk/rvp4oVY+xd Cb+j6uN4dI3DDU7oiYd6yyCNnHrLqgEXZ/PtkhgBhvGmvE50/bHmGbPZjRmYr8JC 8CyUbsmDx66N9BPt9MBH0zQtI+RtWhIzdFYgYSFeyywWrVfAAuXxcuhOPpqq1R3J pec45/i8XM4nIwL9HudFnNDpL+LU7CWkR08JTpjJb3ObPE5PlKF7hyXe0Q74MSJl a5skclkWEqoqqjIIz76Cua87B0MlE2sOW6wDfeB9sIlDt1hgaDQyX9pkQrUwbvJ8 TUSqWkHed1zr3ImnQxu3 =Q3Od -----END PGP SIGNATURE----- From cjbc@it.uc3m.es Wed Feb 27 10:45:30 2013 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 4793B21F89CE for ; Wed, 27 Feb 2013 10:45:30 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhoYJ+6gvgL3 for ; Wed, 27 Feb 2013 10:45:28 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 4F92F21F898B for ; Wed, 27 Feb 2013 10:45:21 -0800 (PST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B84FDCD4E5E; Wed, 27 Feb 2013 19:45:15 +0100 (CET) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [172.24.10.191] (public.eurecom.fr [193.55.113.196]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 88FB6CD4E5D; Wed, 27 Feb 2013 19:45:15 +0100 (CET) Message-ID: <1361990714.4326.28.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: P2PSIP WG Date: Wed, 27 Feb 2013 19:45:14 +0100 Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19674.001 X-TM-AS-Result: No--14.992-7.0-31-1 X-imss-scan-details: No--14.992-7.0-31-1 Cc: p2psip-chairs@tools.ietf.org Subject: [P2PSIP] Draft agenda posted for IETF86 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es 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, 27 Feb 2013 18:45:30 -0000 Hi all, You can find a first version of the agenda for Orlando at the end of this e-mail. Note that most updated version can always be found at: http://www.ietf.org/proceedings/86/agenda/agenda-86-p2psip If we missed any request or assigned a wrong slot, please let us know. Note that the presentation slots may change by +-5 min or so. -- Brian and Carlos ------------------------------------------------------------------------- Agenda of the P2PSIP WG meeting at IETF 86 MONDAY, March 11, 2013 1540-1710 (Afternoon Session II), Caribbean 6 Conflicts: history, netconf, pce, oauth, tsvwg ------------------------------------------------------------------------- 15:40 Administrativia ........................................... 5 min B. Rosen, CJ. Bernardos 15:45 WG Status Update .......................................... 20 min B. Rosen, CJ. Bernardos 16:05 A SIP Usage for RELOAD .................................... 10 min o draft-ietf-p2psip-sip-09 * Presenter: Thomas C. Schmidt 16:15 A Usage for Shared Resources in RELOAD (ShaRe) ............ 10 min o draft-ietf-p2psip-share-01 * Presenter: Thomas C. Schmidt 16:25 Configuration of Access Control Policy in RELOAD .......... 10 min o draft-ietf-p2psip-access-control-00 * Presenter: Marc Petit-Huguenin 16:35 Anycast, Multicast or Broadcast Bootstrap Nodes for RELOAD 15 min o draft-petithuguenin-p2psip-reload-one-to-many-00 * Presenter: Marc Petit-Huguenin 16:50 SCTP Overlay link for for RELOAD .......................... 10 min o draft-petithuguenin-p2psip-reload-sctp-00 * Presenter: Marc Petit-Huguenin 17:00 Anonymization for RELOAD .................................. 5 min o draft-petithuguenin-p2psip-reload-anonymous-02 * Presenter: Marc Petit-Huguenin 17:05 Next steps ................................................ 5 min B. Rosen, CJ. Bernardos -------------------------------------------------------------------------