From internet-drafts@ietf.org Sun Apr 1 07:52:11 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9A611E8093; Sun, 1 Apr 2012 07:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-E2KGwIbvOR; Sun, 1 Apr 2012 07:52:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4899511E8081; Sun, 1 Apr 2012 07:52:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120401145210.19415.44032.idtracker@ietfa.amsl.com> Date: Sun, 01 Apr 2012 07:52:10 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-service-discovery-05.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 14:52:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer-to-Peer Session Initiation Proto= col Working Group of the IETF. Title : Service Discovery Usage for REsource LOcation And Discov= ery (RELOAD) Author(s) : Jouni Maenpaa Gonzalo Camarillo Filename : draft-ietf-p2psip-service-discovery-05.txt Pages : 15 Date : 2012-04-01 REsource LOcation and Discovery (RELOAD) does not define a generic service discovery mechanism as part of the base protocol. This document defines how the Recursive Distributed Rendezvous (ReDiR) service discovery mechanism used in OpenDHT can be applied to RELOAD overlays to provide a generic service discovery mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-service-discovery-05.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-p2psip-service-discovery-05.t= xt From petithug@acm.org Sun Apr 8 00:46:50 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4937021F84A1 for ; Sun, 8 Apr 2012 00:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.952 X-Spam-Level: X-Spam-Status: No, score=-99.952 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfmaH1rPbUem for ; Sun, 8 Apr 2012 00:46:49 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0A521F849A for ; Sun, 8 Apr 2012 00:46:49 -0700 (PDT) Received: from [192.168.1.11] (AMarseille-256-1-77-48.w90-4.abo.wanadoo.fr [90.4.204.48]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 6C87B20513 for ; Sun, 8 Apr 2012 07:46:46 +0000 (UTC) Message-ID: <4F81425D.802@acm.org> Date: Sun, 08 Apr 2012 09:46:37 +0200 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: p2psip@ietf.org X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] RELOAD Interoperability Testing event in Paris 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, 08 Apr 2012 07:46:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I prepared some slides to summarize the RELOAD interoperability testing event that we had in Paris just before the IETF meeting, but there was not enough time in the WG session to present them. Many thanks to the chairs who agreed to made them part of the proceedings: http://www.ietf.org/proceedings/83/slides/slides-83-p2psip-6.pdf Please do not hesitate to send me questions, comments and suggestions, directly or in the reload@implementers.org mailing-list. Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPgUJbAAoJECnERZXWan7Eh1oQAKs2icDGrYxvcUKSXpxvs6SN WDUgXHWi347fFhffg/irFiO+jAwEx3h2NFMSy30QzfqLPviheOkrrDXSWsr/Q7cf 7IWFcyUhVpKWbAAk7iFYdilUI5msYhunBHSqCIUX2J2SmqpZ4OHEGAiKB8QJTbXY W8JjKICmSi9jIraqI4oyXQTyqnWZl1Sa1OHejcSNGCBs+rv8n/+c3l1YhR3vwql4 0i00HR3gijmbutTROeOEHKyVG5BToP4JPB8gMZc9SWmQI0GivP8Tust5zGAMOc0U CBEZvtd78puZ1nu+RVMo3YFNDGDFgx+36zjw4ju0tP4nR7gBnCldaahCkraA5Cx1 FNp61fGqc3L0ROx4hKZkYN+CYnX/PT/W241jx3tA41Bbi5OAlnpJyp8wSTXGpYgs KRrWeYgttDjL7/vX+B7wzZvE1+HdChR5vAabkMkPMStMwojIcSoznYH7To3BeO8Y MwkAogRsblAD4HkWBdO3JLdcD8sH0k18YUqzs1cap728JijfXvBf3n9l+5UBxQ1A pfv57PUXoWR/nnLioq8NIYEI7sDUjP+eiz1U9fI4jjCCgWYXB0S9QSPMUX2e5Q60 MS9TBmCJqqbzjIyikYw078MUev7c+xupKR378ueEAhMdA7IeXDEENYStnED2M8KQ O98kJ+tkunl2PSBT27ex =S/gs -----END PGP SIGNATURE----- From dean.willis@softarmor.com Tue Apr 10 10:53:28 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480B411E8110 for ; Tue, 10 Apr 2012 10:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.751 X-Spam-Level: X-Spam-Status: No, score=-102.751 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hb0g4dTUmoBw for ; Tue, 10 Apr 2012 10:53:27 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4393311E810D for ; Tue, 10 Apr 2012 10:53:27 -0700 (PDT) Received: by ghbg16 with SMTP id g16so46795ghb.31 for ; Tue, 10 Apr 2012 10:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7TFjRgaHnfq08iVrUvo/jp/uMLV+4Axl7/hJbofkaV0=; b=AlrkwpQnejVF5hriBrNDJtMu+BLCAND0gM3hKIznIbc5KWYAui2zkeikclFQx3YAhD V8YeRubyQvArPyDi51i1wex/jF4/pMvlX6WfeJ6pMeuZAxCzz8LDWMkmFWYf72J1bBYt 7QuNkK3ItWalarqkJgh3ExSzsnFBhEoxQDkMo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=7TFjRgaHnfq08iVrUvo/jp/uMLV+4Axl7/hJbofkaV0=; b=MJBwwjZdSev8v3+rnZOfJvkuHMPJKpO1li1Oh13EFsahaoGiAmc50s/kWtHDejOPxp BzSwi+fvUOG0bfYw/qgCsOS4rcCQyW3enr9Cx1XFK/5U6oiCvA9S9IuXMjtTMCOsb38N LFu1bOPAoafIPwzR53NrQqMxfDpaWkYO+9QKEgzjhG/5ZgNf3vRmPD2YTBJh/Q60Be3g r0/SAUvxgSCeefgYfDbr/UuO9YaMVz0aWzAg2H/bXs35Am0VLt/w8N8Wx5uG1UHg27Zr b5GNWlMzP1W7AX8Gk5sjL+ZxFHKm8cR4yz6cQjGClOMnGfTaLj+PoYxRPWFszq/As8ef sl+Q== MIME-Version: 1.0 Received: by 10.60.12.162 with SMTP id z2mr17093532oeb.47.1334080406604; Tue, 10 Apr 2012 10:53:26 -0700 (PDT) Received: by 10.60.33.199 with HTTP; Tue, 10 Apr 2012 10:53:26 -0700 (PDT) In-Reply-To: <4F81425D.802@acm.org> References: <4F81425D.802@acm.org> Date: Tue, 10 Apr 2012 12:53:26 -0500 Message-ID: From: Dean Willis To: Marc Petit-Huguenin Content-Type: multipart/alternative; boundary=e89a8f83a03bbccb3c04bd56cc3a X-Gm-Message-State: ALoCoQkdKaXG5Ed83YIphNFlKHHfSoo4wLdNHwx9edGJNGUvCtjC7kGxtiW9+aq7YWieUjE9pCQ/ Cc: p2psip@ietf.org Subject: Re: [P2PSIP] RELOAD Interoperability Testing event in Paris 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, 10 Apr 2012 17:53:28 -0000 --e89a8f83a03bbccb3c04bd56cc3a Content-Type: text/plain; charset=ISO-8859-1 Thanks for the summary, Marc. What kind of technical issues were the main blockage to testing? On Sun, Apr 8, 2012 at 2:46 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I prepared some slides to summarize the RELOAD interoperability testing > event > that we had in Paris just before the IETF meeting, but there was not enough > time in the WG session to present them. Many thanks to the chairs who > agreed > to made them part of the proceedings: > > http://www.ietf.org/proceedings/83/slides/slides-83-p2psip-6.pdf > > Please do not hesitate to send me questions, comments and suggestions, > directly or in the reload@implementers.org mailing-list. > > Thanks. > > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBCAAGBQJPgUJbAAoJECnERZXWan7Eh1oQAKs2icDGrYxvcUKSXpxvs6SN > WDUgXHWi347fFhffg/irFiO+jAwEx3h2NFMSy30QzfqLPviheOkrrDXSWsr/Q7cf > 7IWFcyUhVpKWbAAk7iFYdilUI5msYhunBHSqCIUX2J2SmqpZ4OHEGAiKB8QJTbXY > W8JjKICmSi9jIraqI4oyXQTyqnWZl1Sa1OHejcSNGCBs+rv8n/+c3l1YhR3vwql4 > 0i00HR3gijmbutTROeOEHKyVG5BToP4JPB8gMZc9SWmQI0GivP8Tust5zGAMOc0U > CBEZvtd78puZ1nu+RVMo3YFNDGDFgx+36zjw4ju0tP4nR7gBnCldaahCkraA5Cx1 > FNp61fGqc3L0ROx4hKZkYN+CYnX/PT/W241jx3tA41Bbi5OAlnpJyp8wSTXGpYgs > KRrWeYgttDjL7/vX+B7wzZvE1+HdChR5vAabkMkPMStMwojIcSoznYH7To3BeO8Y > MwkAogRsblAD4HkWBdO3JLdcD8sH0k18YUqzs1cap728JijfXvBf3n9l+5UBxQ1A > pfv57PUXoWR/nnLioq8NIYEI7sDUjP+eiz1U9fI4jjCCgWYXB0S9QSPMUX2e5Q60 > MS9TBmCJqqbzjIyikYw078MUev7c+xupKR378ueEAhMdA7IeXDEENYStnED2M8KQ > O98kJ+tkunl2PSBT27ex > =S/gs > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > --e89a8f83a03bbccb3c04bd56cc3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the summary, Marc.

What kind of technic= al issues were the main blockage to testing?

On Sun, Apr 8, 2012 at 2:46 AM, Marc Petit-Huguenin &= lt;petithug@acm.org> wrot= e:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I prepared some slides to summarize the RELOAD interoperability testing eve= nt
that we had in Paris just before the IETF meeting, but there was not enough=
time in the WG session to present them. =A0Many thanks to the chairs who ag= reed
to made them part of the proceedings:

http://www.ietf.org/proceedings/83/slides/slides-83-p2p= sip-6.pdf

Please do not hesitate to send me questions, comments and suggestions,
directly or in the reload@implem= enters.org mailing-list.

Thanks.

- --
Marc Petit-Huguenin
Personal email: marc@petit-hugue= nin.org
Professional email: petithug@acm.org
Blog: htt= p://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJPgUJbAAoJECnERZXWan7Eh1oQAKs2icDGrYxvcUKSXpxvs6SN
WDUgXHWi347fFhffg/irFiO+jAwEx3h2NFMSy30QzfqLPviheOkrrDXSWsr/Q7cf
7IWFcyUhVpKWbAAk7iFYdilUI5msYhunBHSqCIUX2J2SmqpZ4OHEGAiKB8QJTbXY
W8JjKICmSi9jIraqI4oyXQTyqnWZl1Sa1OHejcSNGCBs+rv8n/+c3l1YhR3vwql4
0i00HR3gijmbutTROeOEHKyVG5BToP4JPB8gMZc9SWmQI0GivP8Tust5zGAMOc0U
CBEZvtd78puZ1nu+RVMo3YFNDGDFgx+36zjw4ju0tP4nR7gBnCldaahCkraA5Cx1
FNp61fGqc3L0ROx4hKZkYN+CYnX/PT/W241jx3tA41Bbi5OAlnpJyp8wSTXGpYgs
KRrWeYgttDjL7/vX+B7wzZvE1+HdChR5vAabkMkPMStMwojIcSoznYH7To3BeO8Y
MwkAogRsblAD4HkWBdO3JLdcD8sH0k18YUqzs1cap728JijfXvBf3n9l+5UBxQ1A
pfv57PUXoWR/nnLioq8NIYEI7sDUjP+eiz1U9fI4jjCCgWYXB0S9QSPMUX2e5Q60
MS9TBmCJqqbzjIyikYw078MUev7c+xupKR378ueEAhMdA7IeXDEENYStnED2M8KQ
O98kJ+tkunl2PSBT27ex
=3DS/gs
-----END PGP SIGNATURE-----
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
= https://www.ietf.org/mailman/listinfo/p2psip

--e89a8f83a03bbccb3c04bd56cc3a-- From roland.bless@kit.edu Fri Apr 13 10:25:20 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A210E21F87A5 for ; Fri, 13 Apr 2012 10:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-2.800, BAYES_05=-1.11, HELO_EQ_DE=0.35, MANGLED_PILL=2.3, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mB0khIk7oDUS for ; Fri, 13 Apr 2012 10:25:19 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 89EF821F8587 for ; Fri, 13 Apr 2012 10:25:18 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1SIkFD-0004tw-Om; Fri, 13 Apr 2012 19:25:17 +0200 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 1SIkFA-0000w7-SL; Fri, 13 Apr 2012 19:25:08 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 6E907A80B63; Fri, 13 Apr 2012 19:25:08 +0200 (CEST) Message-ID: <4F886174.6080105@kit.edu> Date: Fri, 13 Apr 2012 19:25:08 +0200 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: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1334337917.369040000 Cc: fluffy@cisco.com Subject: [P2PSIP] Review RELOAD Chord Spec chapter 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, 13 Apr 2012 17:25:20 -0000 Hi, as promised at the last IETF meeting I reviewed the chapter that Cullen asked for (was chapter 9 in draft-20, and is chapter 10 in draft-21). I didn't actually implement it yet, however, I wanted to share my preliminary findings. Overall, the description seems to be detailed enough to implement it, though some nits should be corrected. Maybe I'll provide an update in the next few days. The variable N is used inconsistently. It's not clear whether it is denoting the number of peers, objects or N=2^128, sometimes it is used as peer number (e.g., 10.7.3. "When a peer, N,"). It is easier to follow the description if this is used consistently. p. 108: " o RELOAD uses a 128 bit hash instead of a 160 bit hash, as RELOAD is not designed to be used in networks with close to or more than 2^128 nodes (and it is hard to see how one would assemble such a network)." The reasoning here is a little bit odd since the address space size is more related to how many objects one can store and the number of objects can very much larger than the number of actually existing nodes. sec. 9.1: minor: It would be helpful to describe that neighbor table and finger table only contain Node-IDs and that the mapping to locators is done by using the Attach procedure via the overlay (such entries will be kept in the Connection Table then?!). " Fundamentally, the chord data structure ": this is somewhat confusing since it is not clear what you mean by "the chord data structure", because it was not defined. In this context it seems to mean the logical data structure across all nodes and not a particular data structure inside a single node. This may confuse readers since "the chord data structure" is nothing that actually needs to be implemented. May 9.1 is also the section where you could state that N=2^128? sec. 9.3: "The routing table is the union of the neighbor table and the finger table." It should be clarified that this is only meant conceptually (one shouldn't implement it that way). "The routing table is conceptually the union of the neighbor table and the finger table." sec. 9.4: typo old: " success response. It MUST then sends a Store request to its" new: " success response. It MUST then send a Store request to its" 9.5: (p.110) " 4. JP MUST enter all the peers it has contacted into its routing table." presumably only successfully contacted peers should be entered into the routing table, so maybe better: " 4. JP MUST enter all the peers it has successfully contacted into its routing table." p.111: " 7. ... AP can now forget any data which is assigned to JP and not AP." I think that this should be kept as long as AP is in the replica set (cf. 9.7.3) Major: "In order to set up its finger table entry for peer i, JP simply sends an Attach to peer (n+2^(128-i)." should be changed to: "In order to set up its finger table entry for peer at finger index i (i.e., finger[i]), JP simply sends an Attach to peer n+2^(127-i)." as finger[0] should point to node n+2^127, i.e. halfway round the ring, otherwise n+2^128-0 would point to n itself. sec. 9.7.1: p. 113, typo? old: " If the neighbor failure effects the peer's range of responsible IDs," new: " If the neighbor failure affects the peer's range of responsible IDs," sec. 9.7.3: change throughout the section N to n Major: sec. 9.7.4.2: " entries in the finger table. A finger table entry i is valid if it is in the range [ n+2^( 128-i ) , n+2^( 128-(i-1) )-1 ]. Invalid" new: " entries in the finger table. A finger table entry at index i (finger[i]) is valid if it is in the range [ n+2^( 127-i ) , n+2^( 127-(i-1) )-1 ]. Invalid" So finger[127] will be the successor. Regards, Roland From fluffy@cisco.com Fri Apr 13 13:49:15 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7EA21F86F3 for ; Fri, 13 Apr 2012 13:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.887 X-Spam-Level: X-Spam-Status: No, score=-103.887 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MANGLED_PILL=2.3, RCVD_IN_DNSWL_HI=-8, SARE_SPEC_REPLICA_OBFU=1.812, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGWKKr149pSl for ; Fri, 13 Apr 2012 13:49:14 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id F08F621F86EE for ; Fri, 13 Apr 2012 13:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=5784; q=dns/txt; s=iport; t=1334350154; x=1335559754; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=cEFGFLDIMaze/6w/1Q+jutBzuxGIhgOJgbMivYbO83E=; b=a4tktnemHV+l/Oa9/bkXN40CePxdqHCT7oPPTlN2j6iGPQ3miphex/Ox 3bju209nCc1VrMUcfDDTnO+T+dXT82lH4sx9TEAU7u5ebbAqmQzwIPTAS 57u2WFkwrDNyjDaUEq0yloLTuqR8CwisJOiujmXFUf0UXLqOJPppJofqT w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AokGALyQiE+rRDoI/2dsb2JhbABDDoMasXuBB4IJAQEBAwEBAQEPASc0CwULC0YnMAYTIodnBAyeRZgVkGZjBIhajRKFcohbgWmCMFaBPQ X-IronPort-AV: E=Sophos;i="4.75,419,1330905600"; d="scan'208";a="37908600" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 13 Apr 2012 20:49:13 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3DKnD4N017824; Fri, 13 Apr 2012 20:49:13 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4F886174.6080105@kit.edu> Date: Fri, 13 Apr 2012 14:49:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F886174.6080105@kit.edu> To: Roland Bless X-Mailer: Apple Mail (2.1084) Cc: P2PSIP WG Subject: Re: [P2PSIP] Review RELOAD Chord Spec chapter 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, 13 Apr 2012 20:49:15 -0000 Thanks for the review, comments inline but all of theses changes look = good and I have made all of them.=20 I did not submit a new version to the drafts directory ytet but I = checked in the changes and you can see the diff at=20 = http://svn.resiprocate.org/rep/ietf-drafts/p2psip/draft-ietf-p2psip-base.d= iff.html or get the new version of the draft at = http://svn.resiprocate.org/rep/ietf-drafts/p2psip/draft-ietf-p2psip-base.t= xt There is one comment inline in the email that I'd really appreciate it = if you could look at the change I made and see if it looks right to you.=20= Once again, thanks for the careful review of this.=20 On Apr 13, 2012, at 11:25 AM, Roland Bless wrote: > Hi, >=20 > as promised at the last IETF meeting I reviewed the > chapter that Cullen asked for (was chapter 9 in draft-20, > and is chapter 10 in draft-21). I didn't actually > implement it yet, however, I wanted to share my preliminary > findings. >=20 > Overall, the description seems to be detailed enough to implement it, > though some nits should be corrected. Maybe I'll provide an update in = the next few days. >=20 >=20 > The variable N is used inconsistently. It's not clear whether > it is denoting the number of peers, objects or N=3D2^128, sometimes > it is used as peer number (e.g., 10.7.3. "When a peer, N,"). It is > easier to follow the description if this is used consistently. The places N was being used for a specific peer, I moved the N to X to = help clarify this.=20 >=20 > p. 108: > " o RELOAD uses a 128 bit hash instead of a 160 bit hash, as RELOAD = is > not designed to be used in networks with close to or more than > 2^128 nodes (and it is hard to see how one would assemble such a > network)." >=20 > The reasoning here is a little bit odd since the address space > size is more related to how many objects one can store and the > number of objects can very much larger than the number of > actually existing nodes. clarified. this is a bit complicated in Reload as the size the Node-ID = does not need to the be the same size as Resource-ID.=20 >=20 > sec. 9.1: >=20 > minor: > It would be helpful to describe that neighbor table and > finger table only contain Node-IDs and that the mapping > to locators is done by using the Attach procedure via > the overlay (such entries will be kept in the > Connection Table then?!). added >=20 > " Fundamentally, the chord data structure ": > this is somewhat confusing since it is not clear what you mean > by "the chord data structure", because it was not defined. > In this context it seems to mean the logical data structure > across all nodes and not a particular data structure inside a > single node. This may confuse readers since "the chord data structure" > is nothing that actually needs to be implemented. fixed=20 >=20 > May 9.1 is also the section where you could state that N=3D2^128? fixed >=20 > sec. 9.3: > "The routing table is the union of the neighbor table and the finger > table." >=20 > It should be clarified that this is only meant conceptually > (one shouldn't implement it that way). > "The routing table is conceptually the union of the neighbor table = and > the finger table." fixed >=20 > sec. 9.4: typo > old: > " success response. It MUST then sends a Store request to its" > new: > " success response. It MUST then send a Store request to its" >=20 fixed=20 > 9.5: (p.110) > " 4. JP MUST enter all the peers it has contacted into its routing > table." > presumably only successfully contacted peers should be entered into > the routing table, so maybe better: > " 4. JP MUST enter all the peers it has successfully contacted into > its routing table." fixed > p.111: > " 7. ... AP can now forget any data which is assigned to JP and not = AP." > I think that this should be kept as long as AP is in the replica set > (cf. 9.7.3) fixed >=20 > Major: > "In order to set up its finger table entry for peer i, JP simply = sends > an Attach to peer (n+2^(128-i)." > should be changed to: > "In order to set up its finger table entry for peer at finger index = i > (i.e., finger[i]), JP simply sends an Attach to peer n+2^(127-i)." > as finger[0] should point to node n+2^127, i.e. halfway round the = ring, > otherwise n+2^128-0 would point to n itself. This is ( and related stuff in 9.7.4.2) is the change I really want you = to check.=20 Look at how I clarified this and check you think I got it right. The = arrays start at 0 or 1 and been a point of confusion several times in = the past on this and it does not matter as long as it is clear. Check = with respect to section 9.7.4.2 too.=20 >=20 > sec. 9.7.1: > p. 113, typo? > old: > " If the neighbor failure effects the peer's range of responsible = IDs," > new: > " If the neighbor failure affects the peer's range of responsible = IDs," fixed >=20 > sec. 9.7.3: > change throughout the section N to n Look at how I clarified this too.=20 >=20 > Major: > sec. 9.7.4.2: > " entries in the finger table. A finger table entry i is valid if it > is in the range [ n+2^( 128-i ) , n+2^( 128-(i-1) )-1 ]. Invalid" > new: > " entries in the finger table. A finger table entry at index i = (finger[i]) > is valid if it is in the range [ n+2^( 127-i ) , n+2^( 127-(i-1) )-1 = ]. Invalid" >=20 > So finger[127] will be the successor. check fix here too=20 >=20 > Regards, > Roland >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From roland.bless@kit.edu Fri Apr 13 15:44:28 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DED11E813A for ; Fri, 13 Apr 2012 15:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.96 X-Spam-Level: X-Spam-Status: No, score=-2.96 tagged_above=-999 required=5 tests=[AWL=-1.423, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_12=0.6, MANGLED_PILL=2.3, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgMbEKQf7Rhk for ; Fri, 13 Apr 2012 15:44:27 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6B41211E8135 for ; Fri, 13 Apr 2012 15:44:26 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1SIpE3-0001lI-5E; Sat, 14 Apr 2012 00:44:25 +0200 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 1SIpE2-0007xB-Ug; Sat, 14 Apr 2012 00:44:19 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 8594DA80B63; Sat, 14 Apr 2012 00:44:18 +0200 (CEST) Message-ID: <4F88AC42.7000807@kit.edu> Date: Sat, 14 Apr 2012 00:44:18 +0200 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: Cullen Jennings References: <4F886174.6080105@kit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1334357065.262665000 Cc: P2PSIP WG Subject: Re: [P2PSIP] Review RELOAD Chord Spec chapter 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, 13 Apr 2012 22:44:28 -0000 Hi Cullen, On 13.04.2012 22:49, Cullen Jennings wrote: > There is one comment inline in the email that I'd really appreciate > it if you could look at the change I made and see if it looks right > to you. See comments below and inline. > The places N was being used for a specific peer, I moved the N to X > to help clarify this. looks ok. >> p. 108: " o RELOAD uses a 128 bit hash instead of a 160 bit >> hash, as RELOAD is not designed to be used in networks with close >> to or more than 2^128 nodes (and it is hard to see how one would >> assemble such a network)." >> >> The reasoning here is a little bit odd since the address space size >> is more related to how many objects one can store and the number of >> objects can very much larger than the number of actually existing >> nodes. > > clarified. this is a bit complicated in Reload as the size the > Node-ID does not need to the be the same size as Resource-ID. Change is ok, but for section 10 they actually have the same size (as probably for all structured KBR schemes). "For this Chord based topology plugin, the size of the Resource-ID is 128 bits." >> sec. 9.1: >> >> minor: It would be helpful to describe that neighbor table and >> finger table only contain Node-IDs and that the mapping to locators >> is done by using the Attach procedure via the overlay (such entries >> will be kept in the Connection Table then?!). > added "The neighbor and finger tables have a logical Node-ID but the actually mapping of a IP level addressing information to reach that Node-ID is kept in the connection table." I'm not a native speaker, but I'd rather propose: "The neighbor and finger table entries contain logical Node-IDs as values but the actual mapping of an IP level addressing information to reach that Node-ID is kept in the connection table." >> " Fundamentally, the chord data structure ": this is somewhat >> confusing since it is not clear what you mean by "the chord data >> structure", because it was not defined. In this context it seems to >> mean the logical data structure across all nodes and not a >> particular data structure inside a single node. This may confuse >> readers since "the chord data structure" is nothing that actually >> needs to be implemented. > > fixed ok. >> May 9.1 is also the section where you could state that N=2^128? > fixed ok. >> It should be clarified that this is only meant conceptually (one >> shouldn't implement it that way). "The routing table is >> conceptually the union of the neighbor table and the finger >> table." > > fixed ok. >> sec. 9.4: typo old: " success response. It MUST then sends a >> Store request to its" new: " success response. It MUST then send >> a Store request to its" >> > > fixed ok. >> 9.5: (p.110) " 4. JP MUST enter all the peers it has contacted >> into its routing table." presumably only successfully contacted >> peers should be entered into the routing table, so maybe better: " >> 4. JP MUST enter all the peers it has successfully contacted into >> its routing table." > > fixed ok. >> p.111: " 7. ... AP can now forget any data which is assigned to JP >> and not AP." I think that this should be kept as long as AP is in >> the replica set (cf. 9.7.3) > > fixed ok. >> Major: "In order to set up its finger table entry for peer i, JP >> simply sends an Attach to peer (n+2^(128-i)." should be changed >> to: "In order to set up its finger table entry for peer at finger >> index i (i.e., finger[i]), JP simply sends an Attach to peer >> n+2^(127-i)." as finger[0] should point to node n+2^127, i.e. >> halfway round the ring, otherwise n+2^128-0 would point to n >> itself. > > This is ( and related stuff in 9.7.4.2) is the change I really want > you to check. New formulation with i'th finger is much better (though still a bit confusing since the finger[i] notation is mentioned in the overview and also the original Chord paper), but the particular sentence is not quite correct. "In order to set up its i'th finger table entry for peer i, JP simply sends an Attach to peer (n+2^(128-i)." The i'th finger this is usually not for peer i and there is a superfluous "(". So better correct to: "In order to set up its i'th finger table entry, JP simply sends an Attach to peer n+2^(128-i)." > Look at how I clarified this and check you think I got it right. The > arrays start at 0 or 1 and been a point of confusion several times in > the past on this and it does not matter as long as it is clear. Check > with respect to section 9.7.4.2 too. Yep. Clearer now. >> sec. 9.7.1: p. 113, typo? old: " If the neighbor failure effects >> the peer's range of responsible IDs," new: " If the neighbor >> failure affects the peer's range of responsible IDs," > > fixed ok. >> sec. 9.7.3: change throughout the section N to n > > Look at how I clarified this too. looks good. >> Major: sec. 9.7.4.2: " entries in the finger table. A finger >> table entry i is valid if it is in the range [ n+2^( 128-i ) , >> n+2^( 128-(i-1) )-1 ]. Invalid" new: " entries in the finger >> table. A finger table entry at index i (finger[i]) is valid if it >> is in the range [ n+2^( 127-i ) , n+2^( 127-(i-1) )-1 ]. Invalid" >> >> So finger[127] will be the successor. > > check fix here too That's ok now. Regards, Roland From petithug@acm.org Fri Apr 20 05:51:42 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2536021F877E for ; Fri, 20 Apr 2012 05:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuQyHsU1GkcJ for ; Fri, 20 Apr 2012 05:51:41 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 234EE21F875A for ; Fri, 20 Apr 2012 05:51:41 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 34E8A201C0; Fri, 20 Apr 2012 12:51:39 +0000 (UTC) Message-ID: <4F915BD9.10306@acm.org> Date: Fri, 20 Apr 2012 05:51:37 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: Dean Willis References: <4F81425D.802@acm.org> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: p2psip@ietf.org Subject: Re: [P2PSIP] RELOAD Interoperability Testing event in Paris X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 12:51:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Dean, Sorry for the delay in responding. The first technical issue was my fault - I forgot to bring with me various private RSA keys that were needed for my implementation, so I had to cancel my participation on the first day (flaky network in the hotel, before the NOC did its magic, did not help either). At the end it did not matter as we discovered on the second day that it would have been impossible to test anything without an Internet connection, because it is hard to deploy an enrollment server without it. So the lesson for next time is that Internet is a requirement for all the testing. Because we canceled the first day, and because on the first day nothing ever work in a testing event, we did not had enough time to finish all the testing we wanted to do. In fact we continued to do some testing during the IETF meeting week. Here the lesson is that two days of testing are mandatory. The third technical issue was about Wireshark. Wireshark requires to install the private key of all the participants, and even for a small test like this, that was challenging (and in my case would have been impossible as my private key was stored in a smartcard). I have some idea on how to solve this problem, but this mailing-list is probably not the right place to talk about it. Thanks. On 04/10/2012 10:53 AM, Dean Willis wrote: > Thanks for the summary, Marc. > > What kind of technical issues were the main blockage to testing? > > On Sun, Apr 8, 2012 at 2:46 AM, Marc Petit-Huguenin > wrote: > > I prepared some slides to summarize the RELOAD interoperability testing > event that we had in Paris just before the IETF meeting, but there was not > enough time in the WG session to present them. Many thanks to the chairs > who agreed to made them part of the proceedings: > > http://www.ietf.org/proceedings/83/slides/slides-83-p2psip-6.pdf > > Please do not hesitate to send me questions, comments and suggestions, > directly or in the reload@implementers.org > mailing-list. > - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPkVvUAAoJECnERZXWan7ETBoP/3jriVL3OtPvDOWD3sMT11q1 KdGRz6SXALndPIdBbo9pIj31Hb/oBa6jQCGLpPvqKeyh/AMCz6uu+CfJgt7CDgYt efkLM5Yumo21loK7SbZ6tBGpSGFAbtSNdaIe6RUduMMgVXwxFKpTlyVSoN6AoLDa 5mNpAQ88HfR6yJ+f/gVJGaeb3bl0ANUwNq6Abf+gRQhWSDLcvxO6KqzIvXDjW3bZ Pi5xzeEQ5K4w7nHiu++ITrNt+KiOd1kBvwOKmfHyvSNfjLV+8+Mlu2F3jYM3KI1q nefMwxRd3pyVYDnmbWDQS15e5YJYlvin8gvG8dR9/tEf24VZUCpgvbu9TWtQnN8d bTvgPNyJzRLg4iZJU6549rOehOBiy0h6dZ3ZZuA2FZa/yb0InM8lXlm/o4thA7tM r/yzXVhszSasSbbQDR2T32cBh79bASM4UkINNuebpMaRyy076Gz3BpvcKpUWJ5Ca LTrMQnmuXhO6H/sZM4VwSAZO/QsWpy6jfhASP66XdPRYBsQCARJYcwBy0CPisyRZ Rx7SWcQdpYgtYHXjiLukScKQVZovGNRA4tiR9Xi7QTrMvjpcw/+o/zRZl2yzqyQS zichI35R8D85nNLlgX1xyU0ZZb+6/eDwjF9T4hGcSlTVJbC7vVFCt0L4yTlHIlmf VJMQrm5x8J/EZa2LeLmG =HOYm -----END PGP SIGNATURE----- From petithug@acm.org Fri Apr 20 06:26:13 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCA921F86DB for ; Fri, 20 Apr 2012 06:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGsC8fE7h7IL for ; Fri, 20 Apr 2012 06:26:12 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id A1D6621F86D5 for ; Fri, 20 Apr 2012 06:26:12 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 86F10201C0; Fri, 20 Apr 2012 13:26:11 +0000 (UTC) Message-ID: <4F9163F1.2090105@acm.org> Date: Fri, 20 Apr 2012 06:26:09 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: P2PSIP Mailing List , reload@implementers.org X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] RELOAD interop in North America X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 13:26:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I am thinking of organizing another RELOAD Interop Testing event at the end of this year in North America. I have an eventual sponsor that could provide the place and connectivity in Las Vegas NV, but before going further in the discussions, I need to have a idea of the potential participation. So if you are interested in participating in this event, please send me a direct email. Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPkWPwAAoJECnERZXWan7EbwoP/R+F855LT9OQo+z5w9Oh2X4b eVoKOL8kfehUAjG/kIV14XihBpftchzpHbOM0Oed/N4sH4CdAY5rZ9a+Wo3d1+F7 MR89YCR4XhyRr0Z+7M8exvf5JA7RnHu22rhkB0cSGcx2hXQnv1NhMNfO3NguMwjy nlzbaSJnztLs1xsbuUNGSywr+K+y240zaaBIauy4tdYpNcaz6NO2fnCnwMl0tP9+ JhM6qJVt+d9g2r6ANI0+TOJehQJrzIZiZ+XWfewGC1nxys6yr0P1POhvZfcEUi5E Eh4rnnTqrOCzrsuwdBQ/tz5wcS/DEglcMCSS1M6njztrmBym0aivuIS/b1Gjf1dh 1gu69Ch2T2RBn7UWRaVb3x3Kx2xqoJ0I7Z3SALXTZayTpMrjRuT1AOESe3XJLBul qdFChSpW16sIFL7vqM/SYyzRsQw5Ir9Aznbj3FaIKSewMJLEQDBw/VpM+AEwJTSw RPDuGAg5eF7G6sHB6CRtwdQ+IM0xdvLxlM+UDKqeuY6Ka+7rUgElfAhQJKp1YPiH qaJ7RrbppIH7ooX2vd3oZRobAjI6G6hGgtO6uIXXUx/+p1K3zghzf48XVFivlg01 lVldFITHCFL9eckAa9KT+9KCAFZr3GXyInPhdbakl2g+f+b4KLHdX6QWzb3pCCYC XA1GdOAyOW18mDcnzXR5 =UzlF -----END PGP SIGNATURE----- From michaelc@idssoftware.com Tue Apr 24 12:27:43 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E3721E8096 for ; Tue, 24 Apr 2012 12:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opR8Yum1VtDm for ; Tue, 24 Apr 2012 12:27:42 -0700 (PDT) Received: from m1plsmtpa01-01.prod.mesa1.secureserver.net (m1plsmtpa01-01.prod.mesa1.secureserver.net [64.202.165.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9139F21E8012 for ; Tue, 24 Apr 2012 12:27:42 -0700 (PDT) Received: from [10.9.0.73] ([67.58.151.223]) by m1plsmtpa01-01.prod.mesa1.secureserver.net with id 1vTh1j00A4pSoLK01vThPd; Tue, 24 Apr 2012 12:27:42 -0700 Message-ID: <4199fd66-59aa-4ddc-a588-0fec057a2b36@blur> From: "Michael Chen" To: "Marc Petit-Huguenin", "P2PSIP Mailing List", reload@implementers.org Date: Tue, 24 Apr 2012 12:27:40 -0700 X-Mailer: Motorola android mail 1.0 MIME-Version: 1.0 X-Priority: 3 References: <4F9163F1.2090105@acm.org> In-Reply-To: <4F9163F1.2090105@acm.org> Content-Type: multipart/alternative; boundary="Motorola-A-Mail-meRBct3N0SnjVrOv" Subject: Re: [P2PSIP] RELOAD interop in North America X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 19:27:43 -0000 --Motorola-A-Mail-meRBct3N0SnjVrOv Content-Type: text/plain; Format="Flowed"; DelSp="Yes"; charset="US-ASCII" Content-Transfer-Encoding: 7bit Marc, I will participate in the Vegas interop. Although we should all setup internet facing reload peers, so we can do testing on our own before then. Thanks --Michael -----Original message----- From: Marc Petit-Huguenin To: P2PSIP Mailing List , reload@implementers.org Sent: Fri, Apr 20, 2012 13:26:09 GMT+00:00 Subject: [P2PSIP] RELOAD interop in North America -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I am thinking of organizing another RELOAD Interop Testing event at the end of this year in North America. I have an eventual sponsor that could provide the place and connectivity in Las Vegas NV, but before going further in the discussions, I need to have a idea of the potential participation. So if you are interested in participating in this event, please send me a direct email. Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPkWPwAAoJECnERZXWan7EbwoP/R+F855LT9OQo+z5w9Oh2X4b eVoKOL8kfehUAjG/kIV14XihBpftchzpHbOM0Oed/N4sH4CdAY5rZ9a+Wo3d1+F7 MR89YCR4XhyRr0Z+7M8exvf5JA7RnHu22rhkB0cSGcx2hXQnv1NhMNfO3NguMwjy nlzbaSJnztLs1xsbuUNGSywr+K+y240zaaBIauy4tdYpNcaz6NO2fnCnwMl0tP9+ JhM6qJVt+d9g2r6ANI0+TOJehQJrzIZiZ+XWfewGC1nxys6yr0P1POhvZfcEUi5E Eh4rnnTqrOCzrsuwdBQ/tz5wcS/DEglcMCSS1M6njztrmBym0aivuIS/b1Gjf1dh 1gu69Ch2T2RBn7UWRaVb3x3Kx2xqoJ0I7Z3SALXTZayTpMrjRuT1AOESe3XJLBul qdFChSpW16sIFL7vqM/SYyzRsQw5Ir9Aznbj3FaIKSewMJLEQDBw/VpM+AEwJTSw RPDuGAg5eF7G6sHB6CRtwdQ+IM0xdvLxlM+UDKqeuY6Ka+7rUgElfAhQJKp1YPiH qaJ7RrbppIH7ooX2vd3oZRobAjI6G6hGgtO6uIXXUx/+p1K3zghzf48XVFivlg01 lVldFITHCFL9eckAa9KT+9KCAFZr3GXyInPhdbakl2g+f+b4KLHdX6QWzb3pCCYC XA1GdOAyOW18mDcnzXR5 =UzlF -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip --Motorola-A-Mail-meRBct3N0SnjVrOv Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PHN0eWxlIHR5cGU9InRleHQvY3NzIj5ib2R5IHt3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7IGJhY2tncm91bmQtY29sb3I6I2ZmZmZmZjt9PC9zdHlsZT48L2hlYWQ+PGJvZHk+PGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTZweCI+TWFyYyw8 YnI+PGJyPkkgd2lsbCBwYXJ0aWNpcGF0ZSBpbiB0aGUgVmVnYXMgaW50ZXJvcC4gQWx0aG91Z2gg d2Ugc2hvdWxkIGFsbCBzZXR1cCBpbnRlcm5ldCBmYWNpbmcgcmVsb2FkIHBlZXJzLCBzbyB3ZSBj YW4gZG8gdGVzdGluZyBvbiBvdXIgb3duIGJlZm9yZSB0aGVuLjxicj48YnI+VGhhbmtzPGJyPjxi cj4tLU1pY2hhZWw8L2Rpdj48YnI+PGJyPi0tLS0tT3JpZ2luYWwgbWVzc2FnZS0tLS0tPGJyPjxi bG9ja3F1b3RlIHN0eWxlPSI7IGJvcmRlci1sZWZ0OiAycHggc29saWQgcmdiKDE2LCAxNiwgMjU1 KTsgbWFyZ2luLWxlZnQ6IDVweDsgcGFkZGluZy1sZWZ0OiA1cHg7Ij48ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4Ij48Yj5Gcm9tOiA8L2I+TWFyYyBQ ZXRpdC1IdWd1ZW5pbiAmbHQ7cGV0aXRodWdAYWNtLm9yZyZndDs8Yj48YnI+VG86IDwvYj5QMlBT SVAgTWFpbGluZyBMaXN0ICZsdDtwMnBzaXBAaWV0Zi5vcmcmZ3Q7LCAgcmVsb2FkQGltcGxlbWVu dGVycy5vcmc8Yj48YnI+U2VudDogPC9iPkZyaSwgQXByIDIwLCAyMDEyIDEzOjI2OjA5IEdNVCsw MDowMDxiPjxicj5TdWJqZWN0OiA8L2I+W1AyUFNJUF0gUkVMT0FEIGludGVyb3AgaW4gTm9ydGgg QW1lcmljYTxicj48YnI+PC9kaXY+LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLTxi cj5IYXNoOiBTSEEyNTY8YnI+PGJyPkkgYW0gdGhpbmtpbmcgb2Ygb3JnYW5pemluZyBhbm90aGVy IFJFTE9BRCBJbnRlcm9wIFRlc3RpbmcgZXZlbnQgYXQgdGhlIGVuZCBvZjxicj50aGlzIHllYXIg aW4gTm9ydGggQW1lcmljYS4gIEkgaGF2ZSBhbiBldmVudHVhbCBzcG9uc29yIHRoYXQgY291bGQg cHJvdmlkZSB0aGU8YnI+cGxhY2UgYW5kIGNvbm5lY3Rpdml0eSBpbiBMYXMgVmVnYXMgTlYsIGJ1 dCBiZWZvcmUgZ29pbmcgZnVydGhlciBpbiB0aGU8YnI+ZGlzY3Vzc2lvbnMsIEkgbmVlZCB0byBo YXZlIGEgaWRlYSBvZiB0aGUgcG90ZW50aWFsIHBhcnRpY2lwYXRpb24uPGJyPjxicj5TbyBpZiB5 b3UgYXJlIGludGVyZXN0ZWQgaW4gcGFydGljaXBhdGluZyBpbiB0aGlzIGV2ZW50LCBwbGVhc2Ug c2VuZCBtZSBhPGJyPmRpcmVjdCBlbWFpbC48YnI+PGJyPlRoYW5rcy48YnI+PGJyPi0gLS0gPGJy Pk1hcmMgUGV0aXQtSHVndWVuaW48YnI+UGVyc29uYWwgZW1haWw6IG1hcmNAcGV0aXQtaHVndWVu aW4ub3JnPGJyPlByb2Zlc3Npb25hbCBlbWFpbDogcGV0aXRodWdAYWNtLm9yZzxicj5CbG9nOiA8 YSBocmVmPSJodHRwOi8vYmxvZy5tYXJjLnBldGl0LWh1Z3VlbmluLm9yZyI+aHR0cDovL2Jsb2cu bWFyYy5wZXRpdC1odWd1ZW5pbi5vcmc8L2E+PGJyPi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0t LS0tPGJyPlZlcnNpb246IEdudVBHIHYxLjQuMTIgKEdOVS9MaW51eCk8YnI+PGJyPmlRSWNCQUVC Q0FBR0JRSlBrV1B3QUFvSkVDbkVSWlhXYW43RWJ3b1AvUitGODU1TFQ5T1FvK3o1dzlPaDJYNGI8 YnI+ZVZvS09MOGtmZWhVQWpHL2tJVjE0WGloQnBmdGNoenBIYk9NME9lZC9ONHNINENkQVk1clo5 YStXbzNkMStGNzxicj5NUjg5WUNSNFhoeVJyMForN004ZXh2ZjVKQTdSbkh1MjJyaGtCMGNTR2N4 MmhYUW52MU5oTU5mTzNOZ3VNd2p5PGJyPm5semJhU0puenRMczF4c2J1VU5HU3l3citLK3kyNDB6 YWFCSWF1eTR0ZFlwTmNhejZOTzJmbkNud01sMHRQOSs8YnI+SmhNNnFKVnQrZDlnMnI2QU5JMCtU T0plaFFKcnpJWmlaK1hXZmV3R0Mxbnh5czZ5cjBQMVBPaHZaZmNFVWk1RTxicj5FaDRybm5UcXJP Q3pyc3V3ZEJRL3R6NXdjUy9ERWdsY01DU1MxTTZuanp0cm1CeW0wYWl2dUlTL2IxR2pmMWRoPGJy PjFndTY5Q2gyVDJSQm43VVdSYVZiM3gzS3gyeHFvSjBJN1ozU0FMWFRaYXlUcE1yalJ1VDFBT0VT ZTNYSkxCdWw8YnI+cWRGQ2hTcFcxNnNJRkw3dnFNL1NZeXpSc1F3NUlyOUF6bmJqM0ZhSUtTZXdN SkxFUURCdy9WcE0rQUV3SlRTdzxicj5SUER1R0FnNWVGN0c2c0hCNkNSdHdkUStJTTB4ZHZMeGxN K1VES3FldVk2S2ErN3JVZ0VsZkFoUUpLcDFZUGlIPGJyPnFhSjdScmJwcElIN29vWDJ2ZDNvWlJv YkFqSTZHNmhHZ3RPNnVJWFhVeC8rcDFLM3pnaHpmNDhYVkZpdmxnMDE8YnI+bFZsZEZJVEhDRkw5 ZWNrQWE5S1QrOUtDQUZacjNHWHlJblBoZGJha2wyZytmK2I0S0xIZFg2UVd6YjNwQ0NZQzxicj5Y QTFHZE9BeU9XMThtRGNuelhSNTxicj49VXpsRjxicj4tLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0t LS08YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ UDJQU0lQIG1haWxpbmcgbGlzdDxicj5QMlBTSVBAaWV0Zi5vcmc8YnI+PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXAiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwPC9hPjxicj48L2Jsb2NrcXVvdGU+PC9ib2R5Pjwv aHRtbD4NCg== --Motorola-A-Mail-meRBct3N0SnjVrOv-- From petithug@acm.org Tue Apr 24 12:32:19 2012 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3F421E8013 for ; Tue, 24 Apr 2012 12:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyBr7ZNck3lg for ; Tue, 24 Apr 2012 12:32:18 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 9A25021E8011 for ; Tue, 24 Apr 2012 12:32:18 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id A54C6201BE; Tue, 24 Apr 2012 19:32:16 +0000 (UTC) Message-ID: <4F96FFBF.9070503@acm.org> Date: Tue, 24 Apr 2012 12:32:15 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: Michael Chen References: <4F9163F1.2090105@acm.org> <4199fd66-59aa-4ddc-a588-0fec057a2b36@blur> In-Reply-To: <4199fd66-59aa-4ddc-a588-0fec057a2b36@blur> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: reload@implementers.org, P2PSIP Mailing List Subject: Re: [P2PSIP] RELOAD interop in North America X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 19:32:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/24/2012 12:27 PM, Michael Chen wrote: > Marc, > > I will participate in the Vegas interop. Thanks. > Although we should all setup internet facing reload peers, so we can do > testing on our own before then. Yes, I am working on this. The config/enrollment servers will be up and running before May 27. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPlv+9AAoJECnERZXWan7EHJ0P/AnBukVgiIDgi5NfeWnzRcW4 1ko9bOEQpLMZa7WffXIvXBahrP0ldkN9n127Qfc1JJa3STix4KsXQuB7OY1YVXlF gQAzjqWwbj57DTZFjdGdpEgPCai92Cu/14N8BgaNNnngUkEZb7adwOLhElsRgEa/ YeC5UsziaOd85Hif9KC5Xp91RRqtvAE2K9YgtFPzqZ6aeYIgeKuM1bBMCwrWFJBo MpA5BL8pYudu1H58laDpAHT0sjAkePSRpZ01EkBckG8p1dQVo/WVMgfp8K1RnSkR T/i9k9nncLkpSfPjtZ2sFmN4LFc0dYBkgavS9ALt0JcywsZTC7NkB9oaywXoYN6L WfpcloruudTNdjCKeBq5UO6qYwmosEgWYNXwu91nBZM/WZgYZY7FK5M6BURKykmy rjUYPW8TNawDa3RsixyZzxitAupbpw/9LCWQDI0KObSaewOWUksN7G4IydukeXhl XFqrQlrm44GlgPmn2Duhi4vUU5hcQYsxkZ17hQd3GWPN3qcMwPUnE4zr4Titvala nTa2CpH2XSL2P41/PJK5PX8pORCeOjbFW3wRbkZCTu0DOlG/4TsCAELtDVq5Jhon yKL9lWjOGD4RHAPEvGWvq9eNiQaO3J9X3Tu6JYhIIFGVhZI/BmRKFrFojlhBcCLb lQqEFVmBKCnkTBgy1j3a =EOqU -----END PGP SIGNATURE-----