From fluffy@cisco.com Wed Aug 3 23:27:44 2011 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 17CA221F8781 for ; Wed, 3 Aug 2011 23:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.557 X-Spam-Level: X-Spam-Status: No, score=-103.557 tagged_above=-999 required=5 tests=[AWL=-0.958, 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 etlOn090IzCA for ; Wed, 3 Aug 2011 23:27:43 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2C40421F89BE for ; Wed, 3 Aug 2011 23:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=965; q=dns/txt; s=iport; t=1312439277; x=1313648877; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=FWM0CVU7y8WSrQpv0Qh0uYct0R4bKGEr6b5Bq3XVu/c=; b=lla8wWqegs02jaHkYd3bgTnmWR0KvG1hvHoULYf481m9MmwGftAgR4XZ 2Tn8+1v09cTLcALW1N57uYbSh/tnLVgVDRMeW4wzv7oLVTQ5GOCaqbqK/ ZAzlhzrxT/oi43Ctbb3OWIs4yH5FbQX/Uya/WnuAN8JjCdmFcFL9hNvxu E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAN06Ok6rRDoG/2dsb2JhbABCp2R3gUABAQEBAgEBAQEPASc0CwULC0YnMAYTIodKBKJqAZ8BhWNfBIdaiyGRBA X-IronPort-AV: E=Sophos;i="4.67,315,1309737600"; d="scan'208";a="9533855" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-6.cisco.com with ESMTP; 04 Aug 2011 06:27:55 +0000 Received: from sjc-vpn2-915.cisco.com (sjc-vpn2-915.cisco.com [10.21.115.147]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p746Rs9r000628; Thu, 4 Aug 2011 06:27:55 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4E32B623.4080503@ericsson.com> Date: Wed, 3 Aug 2011 23:27:54 -0700 Content-Transfer-Encoding: 7bit Message-Id: <284B7199-2D95-4CF3-8DD4-8FF372692329@cisco.com> References: <4E32B623.4080503@ericsson.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1084) Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] draft-ietf-p2psip-base-17 - Reference to an abandoned draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 06:27:44 -0000 This reference will be removed in version 18 On Jul 29, 2011, at 6:31 , Gonzalo Camarillo wrote: > Hi, > > the RELOAD spec has a reference to the following draft, which seems to > have been abandoned: > > [I-D.pascual-p2psip-clients] > Pascual, V., Matuszewski, M., Shim, E., Zhang, H., and S. > Yongchao, "P2PSIP Clients", > draft-pascual-p2psip-clients-01 (work in progress), > February 2008. > > The authors may want to copy/paste whatever text is relevant from this > draft to the RELOAD spec to avoid the reference. > > http://tools.ietf.org/html/draft-pascual-p2psip-clients-01 > > Cheers, > > Gonzalo > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From bbl@lowekamp.net Thu Aug 4 10:31:01 2011 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 5DAD621F8B89 for ; Thu, 4 Aug 2011 10:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.840, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 hO6vs-u7Ets8 for ; Thu, 4 Aug 2011 10:31:00 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0846C21F8B81 for ; Thu, 4 Aug 2011 10:30:59 -0700 (PDT) Received: by ewy19 with SMTP id 19so1134675ewy.31 for ; Thu, 04 Aug 2011 10:31:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.42.215 with SMTP id j63mr355378eeb.2.1312479070923; Thu, 04 Aug 2011 10:31:10 -0700 (PDT) Received: by 10.14.119.68 with HTTP; Thu, 4 Aug 2011 10:31:10 -0700 (PDT) In-Reply-To: <4E2B1D85.2030908@acm.org> References: <4E2317B6.4090901@acm.org> <4E29DF8E.2050403@acm.org> <4E29E482.3060506@acm.org> <4E2B172E.5020906@acm.org> <4E2B1D85.2030908@acm.org> Date: Thu, 4 Aug 2011 13:31:10 -0400 Message-ID: From: Bruce Lowekamp To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG Subject: Re: [P2PSIP] Signature validation for TURN-SERVICE kind 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, 04 Aug 2011 17:31:01 -0000 I still feel that writing this as a conditional MUST makes this even more awkward (because trying to anticipate future conditions other than shared-secret and being specific seems hard), though I could be persuaded otherwise if enough people feel differently. Bruce New text for 5.3.4: The certificates bucket SHOULD contain all the certificates necessary to verify every signature in both the message and the internal message objects, except for those certificates in a root-cert element of the current configuration file. This is the only location in the message which contains certificates, thus allowing for only a single copy of each certificate to be sent. In systems that have an alternative certificate distribution mechanism, some certificates MAY be omitted. However, unless an alternative mechanism for immediately generating certifcates, such as shared secret security () is used, it is strongly RECOMMENDED that implementors include all referenced certificates, otherwise there is the possibility that messages may not be immediately verifiable because certificates must first be retrieved. NOTE TO IMPLEMENTERS: This requirement implies that a peer storing data is obligated to retain certificates for the data it holds regardless of whether it is responsible for or actually holding the certificates for the Certificate Store usage. And in the turn service section: NOTE TO IMPLEMENTERS: As the access control for this usage is not CERTIFICATE_BY_NODE or CERTIFICATE_BY_USER, the certificates used by TurnServer entries need to be retained as described in . On Sat, Jul 23, 2011 at 3:14 PM, Marc Petit-Huguenin wro= te: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/23/2011 09:03 PM, Bruce Lowekamp wrote: >> On Sat, Jul 23, 2011 at 2:47 PM, Marc Petit-Huguenin = wrote: >> On 07/22/2011 10:58 PM, Marc Petit-Huguenin wrote: >>>>> On 07/22/2011 01:48 PM, Bruce Lowekamp wrote: >>>>>> On Fri, Jul 22, 2011 at 4:37 PM, Marc Petit-Huguenin wrote: >>>>>> On 07/22/2011 01:32 PM, Bruce Lowekamp wrote: >>>>>>>>> >From 5.3.4: >>>>>>>>> >>>>>>>>> The certificates bucket SHOULD contain all the certificates neces= sary >>>>>>>>> =C2=A0 =C2=A0to verify every signature in both the message and th= e internal >>>>>>>>> =C2=A0 =C2=A0message objects. =C2=A0This is the only location in = the message which >>>>>>>>> =C2=A0 =C2=A0contains certificates, thus allowing for only a sing= le copy of each >>>>>>>>> =C2=A0 =C2=A0certificate to be sent. =C2=A0In systems which have = some alternate >>>>>>>>> =C2=A0 =C2=A0certificate distribution mechanism, some certificate= s MAY be omitted. >>>>>>>>> =C2=A0 =C2=A0However, implementors should note that this creates = the possibility >>>>>>>>> =C2=A0 =C2=A0that messages may not be immediately verifiable beca= use certificates >>>>>>>>> =C2=A0 =C2=A0must first be retrieved. >>>>>>>>> >>>>>>>>> >>>>>>>>> This implies that a TURN-SERVICE implementation caches the >>>>>>>>> certificates needed for replication. =C2=A0Will add a note to the >>>>>>>>> TURN-SERVICE description for clarification. >>>>> >>>>>> OK, but isn't this true also for all other kinds that do not use USE= R-MATCH or >>>>>> NODE-MATCH? >>>>> >>>>> >>>>>>> Yes, since 5.3.4 is the definition of the basic SecurityBlock, it >>>>>>> applies to anything using the protocol. =C2=A0Though I would expect= such >>>>>>> usages to be rare. >>>>> >>>>> Well, in addition to the TURN-SERVICE kind, all the kinds defined as = Shared >>>>> resource (draft-knauf-p2psip-share), the VIPR kind and the ReDir kind= . =C2=A0That's >>>>> not rare. >>>>> >>>>>> Do you have any suggestions for how/where to >>>>>>> clarify this point? >>>>> >>>>> IMO, it should be required that each peer stores all the certificates= needed to >>>>> verify all the stored values at this peer. =C2=A0When replicating the= stored values, >>>>> the peer must also send the matching certificates in the GenericCerti= ficate >>>>> field of the SecurityBlock request. >> >> If should be also required that a Fetch returns in the SecurityBlock all= the >> certificates for all the StoredValue it will return. =C2=A0With this the >> CERTIFICATE_BY_NODE and CERTIFICATE_BY_USER kinds are redundant and can = be >> removed from the spec. >> >> >>> This is already covered by 5.3.4. =C2=A0As agreed earlier, we will clar= ify >>> it. =C2=A0Since the two certificate usages aren't really intended to be >>> used to validate messages, I don't see a reason to remove them here. > > OK. > > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk4rHX8ACgkQ9RoMZyVa61cq9wCfbnQU3aIHl7OeGWJma1oxskxE > /lkAn3X6xzxMeqmq7LhDejCvRozcIvGc > =3DmQI0 > -----END PGP SIGNATURE----- > From bbl@lowekamp.net Thu Aug 4 10:31:07 2011 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 EB6AD5E800E for ; Thu, 4 Aug 2011 10:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.787, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 eVbiwrNwSvk6 for ; Thu, 4 Aug 2011 10:31:07 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5F05E800D for ; Thu, 4 Aug 2011 10:31:07 -0700 (PDT) Received: by mail-ew0-f44.google.com with SMTP id 19so1134675ewy.31 for ; Thu, 04 Aug 2011 10:31:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.189.14 with SMTP id b14mr371081een.66.1312479082034; Thu, 04 Aug 2011 10:31:22 -0700 (PDT) Received: by 10.14.119.68 with HTTP; Thu, 4 Aug 2011 10:31:21 -0700 (PDT) In-Reply-To: References: <20110707174850.61e8c06078a3b23a733c71e914c0b9df.97c67717b4.wbe@email00.secureserver.net> Date: Thu, 4 Aug 2011 13:31:21 -0400 Message-ID: From: Bruce Lowekamp To: Michael Chen , Cullen Jennings Content-Type: text/plain; charset=UTF-8 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Configuration sequence number includes 0 or not 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, 04 Aug 2011 17:31:08 -0000 Changed to 0 On Fri, Jul 22, 2011 at 4:42 PM, Bruce Lowekamp wrote: > I believe 10.1 should say 0 to 2^16-2 > > Bruce > > On Thu, Jul 7, 2011 at 8:48 PM, Michael Chen wrote: >> Hi, >> >> The base-15 draft definition for the configuration sequence number in >> section 10.1 says it is a number between 1 and 65534. This conflicts >> with section 5.3.2.1 last sentence, where it describes the wrapping of >> sequence number is setting it to 0 when it reaches 65535. >> >> Was sequence 0 intended for anything? >> >> Thanks >> >> --Michael >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> > From bbl@lowekamp.net Thu Aug 4 10:33:19 2011 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 28AB221F8BAB for ; Thu, 4 Aug 2011 10:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.741, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 ZYmgfarYx7gL for ; Thu, 4 Aug 2011 10:33:18 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 13CDD21F8B01 for ; Thu, 4 Aug 2011 10:33:17 -0700 (PDT) Received: by ewy19 with SMTP id 19so1135841ewy.31 for ; Thu, 04 Aug 2011 10:33:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.100.6 with SMTP id y6mr350770eef.226.1312479212403; Thu, 04 Aug 2011 10:33:32 -0700 (PDT) Received: by 10.14.119.68 with HTTP; Thu, 4 Aug 2011 10:33:32 -0700 (PDT) In-Reply-To: <20110611231034.61e8c06078a3b23a733c71e914c0b9df.0bb0eab361.wbe@email00.secureserver.net> References: <20110611231034.61e8c06078a3b23a733c71e914c0b9df.0bb0eab361.wbe@email00.secureserver.net> Date: Thu, 4 Aug 2011 13:33:32 -0400 Message-ID: From: Bruce Lowekamp To: Michael Chen Content-Type: text/plain; charset=UTF-8 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Config XML using SecurityBlock 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, 04 Aug 2011 17:33:19 -0000 The new text in 5.3.4 says that they should include all certs except for those in a root-cert element. However, as the configuration-signer element specifies who is allowed to sign a config file, the cert bucket in the SecurityBlock may not be empty. Bruce On Sun, Jun 12, 2011 at 2:10 AM, Michael Chen wrote: > Hi, > > Section 10.1, last but one paragraph says, "The configuration file is a > binary file ... is signed using the standard SecurityBlock defined in > Section 5.3.4." > > The SecurityBlock includes the GenericCertificate bucket followed by the > Signature. Don't the elements contain all the necessary > certificates to validate the configuration file? If that is true why > include the GenericCertificate bucket, and why not just the Signature > alone in the base64 encoded and appropriately named element? > > Thanks > > --Michael > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From internet-drafts@ietf.org Thu Aug 4 10:48:14 2011 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 93E8321F8B0F; Thu, 4 Aug 2011 10:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9e-ghDF6-TN; Thu, 4 Aug 2011 10:48:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304DF21F8AF4; Thu, 4 Aug 2011 10:48:14 -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: 3.57 Message-ID: <20110804174814.21630.46792.idtracker@ietfa.amsl.com> Date: Thu, 04 Aug 2011 10:48:14 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-base-18.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, 04 Aug 2011 17:48: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 Proto= col Working Group of the IETF. Title : REsource LOcation And Discovery (RELOAD) Base Protocol Author(s) : Cullen Jennings Bruce B. Lowekamp Eric Rescorla Salman A. Baset Henning Schulzrinne Filename : draft-ietf-p2psip-base-18.txt Pages : 162 Date : 2011-08-04 This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store= data for others. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-18.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-p2psip-base-18.txt From michaelc@IDSSOFTWARE.COM Fri Aug 5 09:48:06 2011 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 A01DC21F8AFD for ; Fri, 5 Aug 2011 09:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jcxNhSMKjFG for ; Fri, 5 Aug 2011 09:48:06 -0700 (PDT) Received: from smtpoutwbe11.prod.mesa1.secureserver.net (smtpoutwbe11.prod.mesa1.secureserver.net [208.109.78.27]) by ietfa.amsl.com (Postfix) with SMTP id 22F9E21F8782 for ; Fri, 5 Aug 2011 09:48:05 -0700 (PDT) Received: (qmail 19990 invoked from network); 5 Aug 2011 16:48:23 -0000 Received: from unknown (HELO gem-wbe14.prod.mesa1.secureserver.net) (64.202.189.101) by smtpoutwbe11.prod.mesa1.secureserver.net with SMTP; 5 Aug 2011 16:48:23 -0000 Received: (qmail 1598 invoked by uid 99); 5 Aug 2011 16:48:23 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 98.119.15.190 User-Agent: Web-Based Email 5.5.15 Message-Id: <20110805094822.61e8c06078a3b23a733c71e914c0b9df.57afc555f6.wbe@email00.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Fri, 05 Aug 2011 09:48:22 -0700 Mime-Version: 1.0 Subject: [P2PSIP] ConfigUpdateReq flooding 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, 05 Aug 2011 16:48:06 -0000 Hi,=0A=0AIn section 5.5.4 of the current p2psip-base draft (up to base-18):= =0A=0A "Whenever a node detects that another node has old configuration da= ta,=0Ait MUST generate a ConfigUpdate request."=0A=0AA request from a peer = with an out-dated config doc may traverse many=0Aforwarding peers. The draf= t may be interpreted as such that all peers in=0Asuch path will send a Conf= igUpdateReq back to this out-dated peer. That=0Ais bad.=0A=0AI suggest the = base draft "RECOMMEND" that only the immediate peer (first=0Ahop) send the = ConfigUpdate request, which is the most efficient and=0Areliable.=0A=0AThan= ks=0A=0A--Michael=0A From michaelc@IDSSOFTWARE.COM Fri Aug 5 18:36:45 2011 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 BEE2711E8080 for ; Fri, 5 Aug 2011 18:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TP377Z5dvq6a for ; Fri, 5 Aug 2011 18:36:45 -0700 (PDT) Received: from smtpoutwbe11.prod.mesa1.secureserver.net (smtpoutwbe11.prod.mesa1.secureserver.net [208.109.78.27]) by ietfa.amsl.com (Postfix) with SMTP id 2557711E807E for ; Fri, 5 Aug 2011 18:36:45 -0700 (PDT) Received: (qmail 18956 invoked from network); 6 Aug 2011 01:37:00 -0000 Received: from unknown (HELO gem-wbe38.prod.mesa1.secureserver.net) (64.202.189.52) by smtpoutwbe11.prod.mesa1.secureserver.net with SMTP; 6 Aug 2011 01:37:00 -0000 Received: (qmail 20657 invoked by uid 99); 6 Aug 2011 01:37:00 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 67.58.151.223 User-Agent: Web-Based Email 5.5.15 Message-Id: <20110805183659.61e8c06078a3b23a733c71e914c0b9df.9e9a87752a.wbe@email00.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Fri, 05 Aug 2011 18:36:59 -0700 Mime-Version: 1.0 Subject: Re: [P2PSIP] ConfigUpdateReq flooding 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, 06 Aug 2011 01:36:45 -0000 =0AFunny how one can understand his own question better afterward. This=0At= opic stems from section 5.3.2.1 of the base draft, 2nd paragraph:=0A=0A "W= hen a **destination** node receives a request, it MUST check that=0Athe con= figuration_sequence field is equal to its own ..."=0A=0AHere are some possi= ble interpretations:=0A=0A1) The phrase "destination node" seems to suggest= that only the=0A"ultimate" destination peer (whom the message was meant fo= r) should=0Acheck/respond/update an out-dated configuration_sequence.=0A=0A= 2) An intermediate peer should forward a knowingly out-dated=0Aconfiguratio= n_sequence number in the forwarding header. Section 5.3.2=0Adoes not say th= at this field should be replaced in every hop.=0A=0AI suggest removing the = word "destination" from the above paragraph and=0Amake it clear that any re= quest with an out-dated configuration_sequence=0Awill never go beyond its f= irst hop (immediate neighbor).=0A=0AThanks=0A=0A--Michael=0A From petithug@acm.org Sun Aug 7 10:23:08 2011 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 7A7A821F86BD for ; Sun, 7 Aug 2011 10:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.049, 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 Rhbvg7Q7RCDD for ; Sun, 7 Aug 2011 10:23:07 -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 C064C21F86B9 for ; Sun, 7 Aug 2011 10:23:07 -0700 (PDT) Received: from [IPv6:2001:55c:4c15:5f80:a800:4ff:fe00:a04] (unknown [IPv6:2001:55c:4c15:5f80:a800:4ff:fe00:a04]) by implementers.org (Postfix) with ESMTPS id AA09F202C8 for ; Sun, 7 Aug 2011 19:20:22 +0200 (CEST) Message-ID: <4E3ECA0E.5070905@acm.org> Date: Sun, 07 Aug 2011 10:23:26 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Interoperability problem in draft-ietf-p2psip-base-18.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, 07 Aug 2011 17:23:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In section 8, the TURN Server usage is named "TURN-SERVICE", same thing in the schema in section 10.1.1, but in the IANA registry in section 13.6, it is named "TURN_SERVICE". - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4+ygwACgkQ9RoMZyVa61ej0ACdH3aSwvm19GFf13bg8qiy7+rQ tPIAoIPMLcWX1mficujSs7swL0tAm+B3 =uybr -----END PGP SIGNATURE----- From internet-drafts@ietf.org Mon Aug 8 20:58:00 2011 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 C090021F8772; Mon, 8 Aug 2011 20:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 RpYFWjmWI7hD; Mon, 8 Aug 2011 20:58:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5F821F871C; Mon, 8 Aug 2011 20:58:00 -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: 3.57 Message-ID: <20110809035800.4911.73300.idtracker@ietfa.amsl.com> Date: Mon, 08 Aug 2011 20:58:00 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-diagnostics-06.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, 09 Aug 2011 03:58:00 -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 : P2PSIP Overlay Diagnostics Author(s) : Song Haibin X. Jiang Roni Even David A. Bryan Filename : draft-ietf-p2psip-diagnostics-06.txt Pages : 29 Date : 2011-08-08 This document describes mechanisms for P2PSIP 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-diagnostics-06.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-diagnostics-06.txt From fluffy@cisco.com Tue Aug 9 14:16:42 2011 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 166625E8016 for ; Tue, 9 Aug 2011 14:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.516 X-Spam-Level: X-Spam-Status: No, score=-103.516 tagged_above=-999 required=5 tests=[AWL=-0.917, 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 Bl5mQIJeY5aa for ; Tue, 9 Aug 2011 14:16:41 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD955E8010 for ; Tue, 9 Aug 2011 14:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1864; q=dns/txt; s=iport; t=1312924631; x=1314134231; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/wnoBkI0zAIKDnD43yPml/ah8sIhfWWWUqS5U0dwx1o=; b=jD8QA5tewIn+5Q+YiQRAeUI6p6sENqNgTHwVextjO4GNVRqHfxDVwBxU tD/beNAa+uNswGnoWSYittt6pVdgDXdwZ6cXy6Bra7MlrzOjsFQHESfok UuF5ewYkwLu1NtffBaDplYLsSxHgQOosV8HLYK4TF6npvUJcLE56BBEAb 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAO2iQU6rRDoG/2dsb2JhbABCpz93gUABAQEBAgEBAQEPASc0CxALRicwBhMih0sEnwcBnlGCRIMjXwSHXIspkQs X-IronPort-AV: E=Sophos;i="4.67,345,1309737600"; d="scan'208";a="11486629" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-4.cisco.com with ESMTP; 09 Aug 2011 21:17:11 +0000 Received: from dhcp-171-68-21-241.cisco.com (dhcp-171-68-21-241.cisco.com [171.68.21.241]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p79LHAkM002041; Tue, 9 Aug 2011 21:17:10 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <20110805183659.61e8c06078a3b23a733c71e914c0b9df.9e9a87752a.wbe@email00.secureserver.net> Date: Tue, 9 Aug 2011 14:17:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8413B5AB-2426-4726-8EBF-A93A79DCAF4C@cisco.com> References: <20110805183659.61e8c06078a3b23a733c71e914c0b9df.9e9a87752a.wbe@email00.secureserver.net> To: Michael Chen X-Mailer: Apple Mail (2.1084) Cc: p2psip@ietf.org Subject: Re: [P2PSIP] ConfigUpdateReq flooding 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, 09 Aug 2011 21:16:42 -0000 The issue is we don't want to mandate that nodes that are purely = forwarding a request have to check the config version. Theses nodes = should be able to forward the request quickly without having to parse = and interpret the whole request. In practice, when a new configuration = files gets put out, it quickly floods the whole network so this is all = pretty much a corner case. Making every message be checked would slow = things down more than a message getting forwarded a few times before the = destination node checked it in the rare case where there is a config = update. Hope that makes sense - it's sort of hard to explain in email.=20= On Aug 5, 2011, at 18:36 , Michael Chen wrote: >=20 > Funny how one can understand his own question better afterward. This > topic stems from section 5.3.2.1 of the base draft, 2nd paragraph: >=20 > "When a **destination** node receives a request, it MUST check that > the configuration_sequence field is equal to its own ..." >=20 > Here are some possible interpretations: >=20 > 1) The phrase "destination node" seems to suggest that only the > "ultimate" destination peer (whom the message was meant for) should > check/respond/update an out-dated configuration_sequence. >=20 > 2) An intermediate peer should forward a knowingly out-dated > configuration_sequence number in the forwarding header. Section 5.3.2 > does not say that this field should be replaced in every hop. >=20 > I suggest removing the word "destination" from the above paragraph and > make it clear that any request with an out-dated = configuration_sequence > will never go beyond its first hop (immediate neighbor). >=20 > Thanks >=20 > --Michael >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Tue Aug 9 14:23:43 2011 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 ED6875E8023 for ; Tue, 9 Aug 2011 14:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.503 X-Spam-Level: X-Spam-Status: No, score=-103.503 tagged_above=-999 required=5 tests=[AWL=-0.904, 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 bZlGOLUQBySD for ; Tue, 9 Aug 2011 14:23:43 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1800E5E8022 for ; Tue, 9 Aug 2011 14:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1143; q=dns/txt; s=iport; t=1312925053; x=1314134653; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=1xcrK/zdTGSYWrG+w3ij8SbcO4SJtdGCZle/5i5jfIk=; b=VplW1ZpWR30QXEIxP8tKBr0oBkUCtoQBRhYI/jop9lWgw2g/bcYMfkBT ej/z1uFY7vqzgiUDqkT7xeVG1Ie5G4iFbM5KOu0o3cjq9gleV7Z5xlJP2 KcNcIgwPokDy/OqQFT1sfbdVqX8pV4PXInRlhgd5AEY4TSUS7rjEn2wdh I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFakQU6rRDoJ/2dsb2JhbABCpz93gUABAQEBAwEBAQ8BJzQLEAtGJzAGEyKHT58DAZ5ShWdfBIdciymRCw X-IronPort-AV: E=Sophos;i="4.67,345,1309737600"; d="scan'208";a="11487841" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-3.cisco.com with ESMTP; 09 Aug 2011 21:24:11 +0000 Received: from dhcp-171-68-21-241.cisco.com (dhcp-171-68-21-241.cisco.com [171.68.21.241]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p79LOAJs007294; Tue, 9 Aug 2011 21:24:10 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4E3ECA0E.5070905@acm.org> Date: Tue, 9 Aug 2011 14:24:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E3ECA0E.5070905@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Interoperability problem in draft-ietf-p2psip-base-18.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, 09 Aug 2011 21:23:44 -0000 Good catch. I will make sure a correction makes it to the RFC. The = questions is which should we use. I'm proposing that we should go with = TURN-SERVICE as I suspect that is what most people implemented. If = anyone has an problem with that, let me know and we can sort out which = to use.=20 On Aug 7, 2011, at 10:23 , Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > In section 8, the TURN Server usage is named "TURN-SERVICE", same = thing in the > schema in section 10.1.1, but in the IANA registry in section 13.6, it = is named > "TURN_SERVICE". >=20 > - --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) >=20 > iEYEARECAAYFAk4+ygwACgkQ9RoMZyVa61ej0ACdH3aSwvm19GFf13bg8qiy7+rQ > tPIAoIPMLcWX1mficujSs7swL0tAm+B3 > =3Duybr > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From gonzalo.camarillo@ericsson.com Wed Aug 10 11:51:46 2011 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 2B99421F8B1D; Wed, 10 Aug 2011 11:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQ5TgBZ7kqiG; Wed, 10 Aug 2011 11:51:45 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAC721F8B1A; Wed, 10 Aug 2011 11:51:43 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-4a-4e42d35f04d2 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B1.58.09774.F53D24E4; Wed, 10 Aug 2011 20:52:15 +0200 (CEST) Received: from [131.160.126.254] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Wed, 10 Aug 2011 20:52:14 +0200 Message-ID: <4E42D35E.8080408@ericsson.com> Date: Wed, 10 Aug 2011 21:52:14 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Gen-ART Subject: [P2PSIP] Gen-ART review of 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, 10 Aug 2011 18:51:46 -0000 Hi, for some reason, I did not receive the following Gen ART review: http://www.ietf.org/mail-archive/web/gen-art/current/msg06582.html I am forwarding it to the P2PSIP list in case the remainder of the intended recipients did not receive it either for some reason. Cheers, Gonzalo From gonzalo.camarillo@ericsson.com Wed Aug 10 23:40:48 2011 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 7FA1621F8726 for ; Wed, 10 Aug 2011 23:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.59 X-Spam-Level: X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDNf-GVSipiZ for ; Wed, 10 Aug 2011 23:40:48 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C724D21F8713 for ; Wed, 10 Aug 2011 23:40:47 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-57-4e437990e84b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8F.2C.20773.099734E4; Thu, 11 Aug 2011 08:41:20 +0200 (CEST) Received: from [131.160.126.254] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Thu, 11 Aug 2011 08:41:20 +0200 Message-ID: <4E437990.5080703@ericsson.com> Date: Thu, 11 Aug 2011 09:41:20 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [P2PSIP] Fwd: Discussing the VIPR-related RELOAD drafts in the VIPR WG 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, 11 Aug 2011 06:40:48 -0000 FYI. Gonzalo -------- Original Message -------- Subject: Discussing the VIPR-related RELOAD drafts in the VIPR WG Date: Thu, 11 Aug 2011 09:40:52 +0300 From: Gonzalo Camarillo To: vipr@ietf.org Folks, in Quebec, we were asked where to discuss the following drafts: http://tools.ietf.org/html/draft-petithuguenin-vipr-reload-usage-02 http://tools.ietf.org/html/draft-petithuguenin-p2psip-proportional-quota-01 Given that both of them relate to VIPR and that the P2PSIP WG is currently focusing on other extensions (in addition to getting the RELOAD spec published), these drafts will be discussed in the VIPR WG from now on. In any case, the drafts will make sure they are reviewed by the P2PSIP WG at an appropriate point in the process. Cheers, Gonzalo From davidbryan@gmail.com Thu Aug 11 16:26:01 2011 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 D81DC11E809B for ; Thu, 11 Aug 2011 16:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 G93td+O0F7RV for ; Thu, 11 Aug 2011 16:26:01 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3C211E809D for ; Thu, 11 Aug 2011 16:26:01 -0700 (PDT) Received: by qyk35 with SMTP id 35so1486438qyk.10 for ; Thu, 11 Aug 2011 16:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=KdMcA9+9oW5nZDGRqeLuVtvHXCTnMSS7bvde8W0rwQs=; b=sGQMAuFFwN6h4Nzm6Wonu+m8z+RZ0uDTjTIi0vsctzrzObrcIdpir286IWFke+oxgf wUAKjRBezs7tiNyXhA4Buw1D2GPGBrGMHSkg0Sya6gfQpVwoPo/BthQ/dznhSLIvLVwb I0T/Eq8P83jZXoyqGjPfAzTuSgK8WZ/+H1mjc= MIME-Version: 1.0 Received: by 10.229.77.158 with SMTP id g30mr155653qck.214.1313105196365; Thu, 11 Aug 2011 16:26:36 -0700 (PDT) Sender: davidbryan@gmail.com Received: by 10.229.80.212 with HTTP; Thu, 11 Aug 2011 16:26:36 -0700 (PDT) Date: Thu, 11 Aug 2011 16:26:36 -0700 X-Google-Sender-Auth: -cS5B1Ob0m7pshcEV-bUdLIePGg Message-ID: From: "David A. Bryan" To: P2PSIP WG Content-Type: multipart/alternative; boundary=002354470c14c8394e04aa432045 Subject: [P2PSIP] Notes and follow up of hums from IETF-81 P2PSIP Meeting 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, 11 Aug 2011 23:26:02 -0000 --002354470c14c8394e04aa432045 Content-Type: text/plain; charset=ISO-8859-1 The minutes from the IETF-81 P2PSIP meeting have been uploaded and are available here: http://www.ietf.org/proceedings/81/minutes/p2psip.txt Please send any comments or corrections to the list. Additionally, the chairs would like to solicit the list to confirm the following consensus reached by hum at the IETF-81 meeting. 1) Hum that the RELOAD base draft (-17) is ready for publication (hum indicated strong consensus) 2) Hum that draft-zong-p2psip-drr-00 and draft-zong-p2psip-rpr-00 be adopted as WG items to address milestones for direct and recursive routing (hum indicated consensus) Again, please send any comments to the list. David (as chair) --002354470c14c8394e04aa432045 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The minutes from the IETF-81 P2PSIP meeting have been uploaded and are avai= lable here:

=A0=A0=A0=A0 http://www.ietf.org/proceedings/81/minutes/p2psip.tx= t

Please send any comments or corrections to the list. Additionally, the = chairs would like to solicit the list to confirm the following consensus re= ached by hum at the IETF-81 meeting.

=A0=A0=A0=A0 1) Hum that the RE= LOAD base draft (-17) is ready for publication (hum indicated strong consen= sus)

=A0=A0=A0=A0 2) Hum that draft-zong-p2psip-drr-00 and draft-zong-p2psip= -rpr-00 be adopted as WG items to address milestones for direct and recursi= ve routing (hum indicated consensus)

Again, please send any comments= to the list.

David (as chair)


--002354470c14c8394e04aa432045-- From michaelc@IDSSOFTWARE.COM Thu Aug 11 22:05:24 2011 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 37DA021F86D2 for ; Thu, 11 Aug 2011 22:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyuXs24x8l7s for ; Thu, 11 Aug 2011 22:05:23 -0700 (PDT) Received: from smtpoutwbe02.prod.mesa1.secureserver.net (smtpoutwbe02.prod.mesa1.secureserver.net [208.109.78.113]) by ietfa.amsl.com (Postfix) with SMTP id 7A40F21F86C0 for ; Thu, 11 Aug 2011 22:05:23 -0700 (PDT) Received: (qmail 22421 invoked from network); 12 Aug 2011 04:58:34 -0000 Received: from unknown (HELO gem-wbe26.prod.mesa1.secureserver.net) (64.202.189.160) by smtpoutwbe02.prod.mesa1.secureserver.net with SMTP; 12 Aug 2011 04:58:33 -0000 Received: (qmail 27159 invoked by uid 99); 12 Aug 2011 04:58:33 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 67.58.151.223 User-Agent: Web-Based Email 5.5.15 Message-Id: <20110811215832.61e8c06078a3b23a733c71e914c0b9df.be92b7c762.wbe@email00.secureserver.net> From: "Michael Chen" To: "Cullen Jennings" Date: Thu, 11 Aug 2011 21:58:32 -0700 Mime-Version: 1.0 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] ConfigUpdateReq flooding 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, 12 Aug 2011 05:05:24 -0000 =0AI suppose the 0xffff sequence number is intended for force-feed a new=0A= configuration to a handful of peers known to the configuration server=0A(al= though such method/policy is not spelled out by the draft). Beyond=0Athat,= section 5.3.2.1 (checking sequence number of a request) is the=0Aonly mean= s defined by this draft to propagate new configuration=0Adocument. It's ha= rdly a corner case.=0A=0AAm I missing something else?=0A=0AThanks=0A=0A--Mi= chael=0A=0A> -------- Original Message --------=0A> Subject: Re: [P2PSIP] C= onfigUpdateReq flooding=0A> From: Cullen Jennings =0A> Da= te: Tue, August 09, 2011 2:17 pm=0A> To: Michael Chen =0A> Cc: p2psip@ietf.org=0A> =0A> =0A> The issue is we don't want to m= andate that nodes that are purely forwarding a request have to check the co= nfig version. Theses nodes should be able to forward the request quickly wi= thout having to parse and interpret the whole request. In practice, when a = new configuration files gets put out, it quickly floods the whole network s= o this is all pretty much a corner case. Making every message be checked wo= uld slow things down more than a message getting forwarded a few times befo= re the destination node checked it in the rare case where there is a config= update. Hope that makes sense - it's sort of hard to explain in email. =0A= > =0A> =0A> On Aug 5, 2011, at 18:36 , Michael Chen wrote:=0A> =0A> > =0A> = > Funny how one can understand his own question better afterward. This=0A> = > topic stems from section 5.3.2.1 of the base draft, 2nd paragraph:=0A> > = =0A> > "When a **destination** node receives a request, it MUST check that= =0A> > the configuration_sequence field is equal to its own ..."=0A> > =0A>= > Here are some possible interpretations:=0A> > =0A> > 1) The phrase "dest= ination node" seems to suggest that only the=0A> > "ultimate" destination p= eer (whom the message was meant for) should=0A> > check/respond/update an o= ut-dated configuration_sequence.=0A> > =0A> > 2) An intermediate peer shoul= d forward a knowingly out-dated=0A> > configuration_sequence number in the = forwarding header. Section 5.3.2=0A> > does not say that this field should = be replaced in every hop.=0A> > =0A> > I suggest removing the word "destina= tion" from the above paragraph and=0A> > make it clear that any request wit= h an out-dated configuration_sequence=0A> > will never go beyond its first = hop (immediate neighbor).=0A> > =0A> > Thanks=0A> > =0A> > --Michael=0A> > = =0A> > _______________________________________________=0A> > P2PSIP mailing= list=0A> > P2PSIP@ietf.org=0A> > https://www.ietf.org/mailman/listinfo/p2p= sip=0A From fluffy@cisco.com Fri Aug 12 14:50:54 2011 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 1DC4611E8094 for ; Fri, 12 Aug 2011 14:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.481 X-Spam-Level: X-Spam-Status: No, score=-103.481 tagged_above=-999 required=5 tests=[AWL=-0.882, 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 0jkPcEHissU3 for ; Fri, 12 Aug 2011 14:50:53 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2059B11E8090 for ; Fri, 12 Aug 2011 14:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3885; q=dns/txt; s=iport; t=1313185891; x=1314395491; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Yu5dxN57NZFD2gyodUxLHJ7jh9Cry3ikCCG2yda1GcY=; b=X8/qrCuFr5/t6ICAyOAWuXpCprH1y12r48IJD5ryMwXHXHkysbH67QqG +YLg3Pon69EX0f0bKr8qOjiawTBXTyNF+WRCNDe+MuJ8VOadHSXtp/wzQ 6tzuZ89nBhyxTS+fsBBkfRe5QCtK2fsuIa4dd0y9CRpWvspwlqHtXu6QD 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHWfRU6rRDoH/2dsb2JhbABBp3l3gUABAQEBAgEBAQEPASc0CwwECxEDAQIBLicoCAYTIodNBJwiAZ5ygkSDJF8Eh1+LMZER X-IronPort-AV: E=Sophos;i="4.67,364,1309737600"; d="scan'208";a="12728865" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-2.cisco.com with ESMTP; 12 Aug 2011 21:51:31 +0000 Received: from sjc-vpn7-577.cisco.com (sjc-vpn7-577.cisco.com [10.21.146.65]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7CLpUST028185; Fri, 12 Aug 2011 21:51:30 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <20110811215832.61e8c06078a3b23a733c71e914c0b9df.be92b7c762.wbe@email00.secureserver.net> Date: Fri, 12 Aug 2011 14:51:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110811215832.61e8c06078a3b23a733c71e914c0b9df.be92b7c762.wbe@email00.secureserver.net> To: Michael Chen X-Mailer: Apple Mail (2.1084) Cc: p2psip@ietf.org Subject: Re: [P2PSIP] ConfigUpdateReq flooding 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, 12 Aug 2011 21:50:54 -0000 Let's just make up some random numbers. Lets say that a config update = happens once a month and most nodes are processing an average of 10 = messages per second - with numbers like that, a 1 in 25 million = messages causes a config update. That's why I called it a corner case = but I agree, corner case is probably the wrong thing to call it - it is = important even if it is rare.=20 There is nothing the forwarding nodes needs to do with any information = in the configuration so it does not matter if it is out of date. But it = is critical that the destination has the right config. So we said the = destination MUST deal with this. If intermediate nodes choose to go load = a new config after seeing theirs is out of date, I don't see any reason = that would not be allowed but seems more like an implementation decision = and an interoperability issue. It seems like some implementation would = not want to do this as slowing down the 25 million messages outweighs = the speeding up the 1 in 25 million case. Regardless of which way you do = it, the new config floods across the overlay very quickly.=20 On Aug 11, 2011, at 21:58 , Michael Chen wrote: >=20 > I suppose the 0xffff sequence number is intended for force-feed a new > configuration to a handful of peers known to the configuration server > (although such method/policy is not spelled out by the draft). Beyond > that, section 5.3.2.1 (checking sequence number of a request) is the > only means defined by this draft to propagate new configuration > document. It's hardly a corner case. >=20 > Am I missing something else? >=20 > Thanks >=20 > --Michael >=20 >> -------- Original Message -------- >> Subject: Re: [P2PSIP] ConfigUpdateReq flooding >> From: Cullen Jennings >> Date: Tue, August 09, 2011 2:17 pm >> To: Michael Chen >> Cc: p2psip@ietf.org >>=20 >>=20 >> The issue is we don't want to mandate that nodes that are purely = forwarding a request have to check the config version. Theses nodes = should be able to forward the request quickly without having to parse = and interpret the whole request. In practice, when a new configuration = files gets put out, it quickly floods the whole network so this is all = pretty much a corner case. Making every message be checked would slow = things down more than a message getting forwarded a few times before the = destination node checked it in the rare case where there is a config = update. Hope that makes sense - it's sort of hard to explain in email.=20= >>=20 >>=20 >> On Aug 5, 2011, at 18:36 , Michael Chen wrote: >>=20 >>>=20 >>> Funny how one can understand his own question better afterward. This >>> topic stems from section 5.3.2.1 of the base draft, 2nd paragraph: >>>=20 >>> "When a **destination** node receives a request, it MUST check that >>> the configuration_sequence field is equal to its own ..." >>>=20 >>> Here are some possible interpretations: >>>=20 >>> 1) The phrase "destination node" seems to suggest that only the >>> "ultimate" destination peer (whom the message was meant for) should >>> check/respond/update an out-dated configuration_sequence. >>>=20 >>> 2) An intermediate peer should forward a knowingly out-dated >>> configuration_sequence number in the forwarding header. Section = 5.3.2 >>> does not say that this field should be replaced in every hop. >>>=20 >>> I suggest removing the word "destination" from the above paragraph = and >>> make it clear that any request with an out-dated = configuration_sequence >>> will never go beyond its first hop (immediate neighbor). >>>=20 >>> Thanks >>>=20 >>> --Michael >>>=20 >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >=20 From petithug@acm.org Sun Aug 14 11:16:13 2011 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 5599B21F89BA for ; Sun, 14 Aug 2011 11:16: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 8rSLSrDdUocM for ; Sun, 14 Aug 2011 11:16: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 9BB4821F8782 for ; Sun, 14 Aug 2011 11:16: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]) by implementers.org (Postfix) with ESMTPS id 696A0202C8 for ; Sun, 14 Aug 2011 20:13:19 +0200 (CEST) Message-ID: <4E481113.3020802@acm.org> Date: Sun, 14 Aug 2011 11:16:51 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Review of draft-ietf-p2psip-concepts-03 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, 14 Aug 2011 18:16:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1. Section 3, third paragraph. To improve the reading flow of section 3 as a whole, I would suggest to replace the first sentence by this: "A P2PSIP Overlay consists of one or more nodes called Peers and may also include Clients." 2. Section 3.5 OPEN ISSUE I would suggest to move this whole section into a "Design Notes" appendix at the end of the document. See also comment 10. 3. Section 4, 2rd paragraph "SIP Redirector" I would suggest to use "SIP Redirect Server" instead, as defined in RFC 3261 Section 6. 4. Section 5: Peer-ID All the other drafts use the "Node-ID" terminology, so why not invert the definition, I.e. define Node-ID and says that this is sometimes called a "Peer-ID"? See also the definition of "Peer" and Section 6.4 that both use "Peer-ID". 5. Section 5: Resource Record Not a comment on this draft, but I like this term more than the terms that are used in other drafts (e.g. PDU in p2psip-sip, or structure in p2psip-service-discovery). I will propose this change when I will review the other drafts. 6. Section 5: Responsible Peer I did not read all the literature on the subject, but I never saw the term "Root Peer" used as synonym for "Responsible Peer." 7. Section 6.4, second paragraph: "The P2PSIP WG..." Replace by "This document..." 8. Section 6.4, third paragraph This paragraph talks about "multicast-bootstrap", but it should also talk about unicast bootstrap (or s/multicast-bootstrap/bootstrap/) 9. Security Section Security section missing. 10. Section 7 Open Issues As an implementer that is constantly confronted to interoperability issues, I think that preserving the reasons why decisions were made is really important and should be part of each RFC as an appendix. This would prevent a lot of guessing when future implementers who never participate in the discussion will start working on this. I have no opinion on the use cases. Nits ==== - - Abstract s/mechansims/mechanisms/ An abstract should not contain references. - - Section 1. s/eselection/selection/ - - Section 3. "Session Initiation Protocol (SIP)" is already defined in Section 2, so using only "SIP" is OK. - - Section 6.1 s/resource-id/Resource-ID/ s/resource record/Resource Record/ - - Section 6.2 s/resource record/Resource Record/ - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5IERIACgkQ9RoMZyVa61cDmACglWMsJRxCvddS/7QtGkNE8NiY pTwAn3o2W24CXP/Wsx98csYNZV3wnrDT =QPgB -----END PGP SIGNATURE----- From petithug@acm.org Mon Aug 15 17:22:49 2011 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 1856511E8108 for ; Mon, 15 Aug 2011 17:22:49 -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 urf7GXqr25+6 for ; Mon, 15 Aug 2011 17:22:47 -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 D0B4121F8BC5 for ; Mon, 15 Aug 2011 17:22:47 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 79E67202C8 for ; Tue, 16 Aug 2011 02:19:52 +0200 (CEST) Message-ID: <4E49B882.7060001@acm.org> Date: Mon, 15 Aug 2011 17:23:30 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Review of draft-ietf-p2psip-sip-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, 16 Aug 2011 00:22:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1. Section 3: SipRegistration structure I would suggest to use "SipRegistration Resource Record" instead, to match the terminology in -concepts. Same thing for SipRegistration PDU in the same section. 2. Section 3: 1st paragraph s/This uses the SIP-REGISTRATION Kind-ID/This uses the SIP-REGISTRATION Kind/ 3. Section 3: opaque contact_prefs<0..2^16-1>; The format of the contact_prefs field is not described. Is it RFC 3840 or RFC 2533 (better in my opinion) or something else? 4. Section 3: Destination destination_list<0..2^16-1>; I think it would be better to have a list of destination_list instead, to be able to register different paths to the destination. This could be useful if a node decides to register as a client to multiple peers, using the procedure in the second bullet of section 3.2.1 of -base. 5. Section 3, second bullet of last list. It says that the storing peer must check that "[t]he certificate contains a Node-ID that is the same as the dictionary key it is being stored at.", which is not exactly true when the certificate contains multiple Node-ID. It would be better to say: "The Node-ID of the signer is the same as the dictionary key it is being stored at." 6. Section 4, first item in list "Check to see if the domain part of the AOR matches the domain name of an overlay of which he is a member." The way I understand this sentence, the "sip:petithug@implementers.org" AOR matches an overlay named "overlay.implementers.org". Was that the intent of this rule, or was the intent that the "sip:petithug@implementers.org" AOR only matches the "implementers.org" overlay? 7. Section 5. "If certificate-based authentication is in use, the responding peer MUST present a certificate with a Node-ID matching the terminal entry in the route list." If this sentence is about the AppAttach itself (and not about the connection created by the AppAttach), isn't that rule already part of -base? 8. Section 6. Second sentence. I do not understand what this sentence means. 9. Section 8.1. "In this section we discuss security issues that are likely to be relevant to any usage of RELOAD." There is no security issues discussed in section 8.1. 10. Section 9 Please change "TBD" by the code point that was already assigned (1, I think), so early implementations can do interoperability testing. Nits ==== - - Abstract s/(RELOAD),/(RELOAD)./ - - Section 2 s/consiered/considered/ - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5JuIEACgkQ9RoMZyVa61d0ewCePDivcNomdXZKytOHibse64y7 RFsAmweGHrv9VVhK79zJrJaPKEFUa4uy =t0WX -----END PGP SIGNATURE----- From p2p.nve.2011@gmail.com Tue Aug 16 23:59:26 2011 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 D479B11E8086; Tue, 16 Aug 2011 23:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.508 X-Spam-Level: X-Spam-Status: No, score=-0.508 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, SUBJ_ALL_CAPS=2.077] 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 HewkvMroBHL2; Tue, 16 Aug 2011 23:59:25 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 99FCC11E8092; Tue, 16 Aug 2011 23:59:25 -0700 (PDT) Received: by pzk33 with SMTP id 33so945798pzk.18 for ; Wed, 17 Aug 2011 00:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=NMrfhnUWX6pTgRJ5uly4+tu/wRDqqzcWy4ECtSu2qcE=; b=J3gbFhaGai/jG+DnJq2lHbr1ICVSwk8Fij/omhOaDdou5OF48/iPreUgucsbsIdWpY PiNKT2OD8Ry9JMsw7ph513rXtGxDo3IgafX0BQi5c5JnNsv4iH9OAv78YQOCXQG5QNsA MKjkm2/d7+hmrYU0DviRmbl4Or9gu3tz1g/ko= MIME-Version: 1.0 Received: by 10.142.14.12 with SMTP id 12mr344967wfn.90.1313564415919; Wed, 17 Aug 2011 00:00:15 -0700 (PDT) Received: by 10.143.63.5 with HTTP; Wed, 17 Aug 2011 00:00:15 -0700 (PDT) Date: Wed, 17 Aug 2011 15:00:15 +0800 Message-ID: From: 2011 p2pnve To: tccc@lists.cs.columbia.edu, p2p@ogf.org, ppsp@ietf.org, p2psip@ietf.org, sam@irtf.org Content-Type: multipart/alternative; boundary=000e0cd20d6666868b04aaae0c4b Subject: [P2PSIP] =?utf-8?b?W0NGUF1bUDJQTuKAi1ZFIDIwMTFdW0RFQUTigItMSU5F?= =?utf-8?q?_EXTENSION=3A_AUGUST_20=2C_2011=5D_THE_5TH_INTERNATIO?= =?utf-8?q?=E2=80=8BNAL_WORKSHOP_ON_PEER-TO-PE=E2=80=8BER_NETWORKED?= =?utf-8?q?_VIRTUAL_ENVIRONMEN=E2=80=8BTS?= 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, 17 Aug 2011 06:59:26 -0000 --000e0cd20d6666868b04aaae0c4b Content-Type: text/plain; charset=ISO-8859-1 [Apologies if you receive multiple copies of this message] * Deadline extended to August 25, 2011 * CALL FOR PAPERS ======================================================================== The 5th International Workshop on Peer-to-Peer Networked Virtual Environments (P2P-NVE 2011) in conjunction with The 17th International Conference on Parallel and Distributed Systems (ICPADS 2011) December 7-9, 2011 Tainan, Taiwan http://acnlab.csie.ncu.edu.tw/P2PNVE2011/ ======================================================================== PURPOSE AND SCOPE Peer-to-peer (P2P) is a computing paradigm based on self-organizing network overlays, in which participating entities play symmetric roles as both servers and clients for accomplish common goals. Compared with the traditional client/server (C/S) paradigm, the P2P paradigm is not vulnerable to a single point of failure and has better scalability and lower installation and management cost. It has been successfully applied to many applications, such as data sharing, storage sharing, bandwidth sharing, collaborative computation, and so on. Many research studies have been devoted to developing efficient, flexible, and secure P2P systems. They call for a workshop to provide a forum for researchers to exchange their ideas about state-of-the-art P2P technologies. Recently, some studies try to apply the P2P paradigm to network virtual environments (NVEs), which is also known as distributed virtual environment (DVEs) or collaborative virtual environment (CVEs), to increase NVE scalability and to reduce NVE management and deployment costs. An NVE is a computer-generated virtual world where multiple users can assume virtual representatives (or avatars) to concurrently interact with each other via networked links. Examples of NVEs include early DARPA SIMNET and DIS systems as well as currently booming Massively Multiplayer Online Games (MMOGs). Typical examples of studies on P2P NVEs are P2P voice chatting, P2P 3D streaming, P2P game state management, and so on. In spite of the success of the studies, we need more studies about state consistency control, persistent data storage, multimedia data dissemination, cheat-prevention, topology mismatching, and virtual world interoperability to construct NVEs of better performance. The 1st, 2nd, 3rd and 4th International Workshop on Peer-to-Peer Networked Virtual Environments were held in conjunction with the 13th, 14th, 15th and 16th International Conference on Parallel and Distributed Systems in 2007, 2008, 2009, and 2010 respectively. To adhere to the theme of P2P-NVE workshops, the theme of P2P-NVE 2011 is to solicit original and previously unpublished new ideas on general P2P schemes as well as on the design and realization of P2P NVEs. The workshop aims to facilitate discussions and idea exchanges by both academics and practitioners. Authors are invited to submit an electronic version of original, unpublished manuscripts, not to exceed 8 double-columned, single-spaced pages, to the workshop. Submitted papers should be in accordance with IEEE Computer Society guidelines, and will be refereed by reviewers in terms of relevance, originality, contribution, correctness, and presentation. All Accepted papers will be published by IEEE Press (indexed by EI) and will be included in IEEE Xplore. Topics of interest include, but are not limited to: * P2P systems and infrastructures * Applications of P2P systems * Performance evaluation of P2P systems * Trust and security issues in P2P systems * Network support for P2P systems * Fault tolerance in P2P systems * Data structures for P2P systems * Efficient P2P resource lookup and sharing * Distributed Hash Tables (DHTs) and related issues * Solutions to topology mismatching for P2P overlays * P2P overlays for NVEs * P2P NVE multicast * P2P NVE interoperability * P2P NVE content distribution * P2P NVE 3D streaming * P2P NVE voice communications * P2P NVE architecture designs * P2P NVE prototypes * P2P NVE consistency control * Persistent storage for P2P NVEs * Security and cheat-prevention mechanisms for P2P games * P2P control for mobile NVEs * P2P NVE applications on mobile devices ========================================== IMPORTANT DATES Submission: August 25, 2011 Notification: September 25, 2011 Camera ready: October 7, 2011 =========================================== PAPER SUBMISSION Authors are invited to submit an electronic version of original, unpublished manuscripts, not to exceed 8 double-columned, single-spaced pages, to the workshop. Submitted papers should be in PDF format in accordance with IEEE Computer Society guidelines, and will be refereed by reviewers in terms of originality, contribution, correctness, and presentation. --000e0cd20d6666868b04aaae0c4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

[Apologies if you receive multiple copies of thi= s message]

=A0

* Deadline extended to August 25, 2011 *

=A0
=A0
=A0
CALL FOR PAPERS

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The 5th International Workshop on Peer-to-Peer Networked Virtual Environmen= ts (P2P-NVE 2011)

in conjunction with

The 17th International = Conference on Parallel and Distributed Systems (ICPADS 2011)

Decembe= r 7-9, 2011
Tainan, Taiwan

http://acnlab.csie.ncu.edu.tw/P2PNVE2011/
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
PURPOSE AND= SCOPE

Peer-to-peer (P2P) is a computing paradigm based on self-organizing net= work overlays, in which participating entities play symmetric roles as both= servers and clients for accomplish common goals. Compared with the traditi= onal client/server (C/S) paradigm, the P2P paradigm is not vulnerable to a = single point of failure and has better scalability and lower installation a= nd management cost. It has been successfully applied to many applications, = such as data sharing, storage sharing, bandwidth sharing, collaborative com= putation, and so on. Many research studies have been devoted to developing = efficient, flexible, and secure P2P systems. They call for a workshop to pr= ovide a forum for researchers to exchange their ideas about state-of-the-ar= t P2P technologies. Recently, some studies try to apply the P2P paradigm to= network virtual environments (NVEs), which is also known as distributed vi= rtual environment (DVEs) or collaborative virtual environment (CVEs), to in= crease NVE scalability and to reduce NVE management and deployment costs. A= n NVE is a computer-generated virtual world where multiple users can assume= virtual representatives (or avatars) to concurrently interact with each ot= her via networked links. Examples of NVEs include early DARPA SIMNET and DI= S systems as well as currently booming Massively Multiplayer Online Games (= MMOGs). Typical examples of studies on P2P NVEs are P2P voice chatting, P2P= 3D streaming, P2P game state management, and so on. In spite of the succes= s of the studies, we need more studies about state consistency control, per= sistent data storage, multimedia data dissemination, cheat-prevention, topo= logy mismatching, and virtual world interoperability to construct NVEs of b= etter performance.

The 1st, 2nd, 3rd and 4th International Workshop on Peer-to-Peer Networ= ked Virtual Environments were held in conjunction with the 13th, 14th, 15th= and 16th International Conference on Parallel and Distributed Systems in 2= 007, 2008, 2009, and 2010 respectively. To adhere to the theme of P2P-NVE w= orkshops, the theme of P2P-NVE 2011 is to solicit original and previously u= npublished new ideas on general P2P schemes as well as on the design and re= alization of P2P NVEs. The workshop aims to facilitate discussions and idea= exchanges by both academics and practitioners. Authors are invited to subm= it an electronic version of original, unpublished manuscripts, not to excee= d 8 double-columned, single-spaced pages, to the workshop. Submitted papers= should be in accordance with IEEE Computer Society guidelines, and will be= refereed by reviewers in terms of relevance, originality, contribution, co= rrectness, and presentation. All Accepted papers will be published by IEEE = Press (indexed by EI) and will be included in IEEE Xplore.


Topics of interest include, but are not limited to:


* = P2P systems and infrastructures
* Applications of P2P systems
* P= erformance evaluation of P2P systems
* Trust and security issues in P2= P systems
* Network support for P2P systems
* Fault tolerance in P2P systems* Data structures for P2P systems
* Efficient P2P resource lookup = and sharing
* Distributed Hash Tables (DHTs) and related issues
* Solutions to topology mismatching for P2P overlays
* P2P overlays = for NVEs
* P2P NVE multicast
* P2P NVE interoperability
* P2= P NVE content distribution
* P2P NVE 3D streaming
* P2P NVE voice= communications
* P2P NVE architecture designs
* P2P NVE prototypes
* P2P NVE c= onsistency control
* Persistent storage for P2P NVEs
* Security a= nd cheat-prevention mechanisms for P2P games
* P2P control for mobile = NVEs
* P2P NVE applications on mobile devices

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
IMPORTANT DATES

Submission: = August 25, 2011
Notification: = September 25, 2011
Camera ready: October 7, 2011
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

PAPER SUBMISSION
Authors are invited to submit an electronic version of original, unpublis= hed manuscripts, not to exceed 8 double-columned, single-spaced pages, to t= he workshop. Submitted papers should be in PDF format in accordance with IE= EE Computer Society guidelines, and will be refereed by reviewers in terms = of originality, contribution, correctness, and presentation.

--000e0cd20d6666868b04aaae0c4b-- From petithug@acm.org Sat Aug 20 16:59:33 2011 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 0A60921F8661 for ; Sat, 20 Aug 2011 16:59:33 -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 qEJQfQAkHOW6 for ; Sat, 20 Aug 2011 16:59:32 -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 2EDD921F863E for ; Sat, 20 Aug 2011 16:59:28 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id D5F3F202C8 for ; Sun, 21 Aug 2011 01:56:27 +0200 (CEST) Message-ID: <4E504A99.9020602@acm.org> Date: Sat, 20 Aug 2011 17:00:25 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Interoperability problem with lifetime 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, 20 Aug 2011 23:59:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A lifetime value is sent in both FetchKindResponse and StatKindResponse but there is no explanation about what this value should contain. If it is the value that was sent in the StoreReq, then this value is useless for the node that will receive it, as it is not relative to the storage_time field, and so cannot be used to know when to re-store the resource record. So it would make sense that this field contains the *remaining* lifetime for the resource record (using an algorithm similar to what is in section 6.4.1.1), but it is not explicitly said in the spec, so there will be variations in implementations, and interoperability problems for implementations that will count on using this field as the remaining lifetime. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5QSpgACgkQ9RoMZyVa61c5aQCgmEh1sK5e3qYxZVLMK5xpPt35 RQYAnRTseKflyht1DuEJ6Z/NJfdnowWD =bJmD -----END PGP SIGNATURE----- From bbl@lowekamp.net Sun Aug 21 05:46:20 2011 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 715D821F8A23 for ; Sun, 21 Aug 2011 05:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=0.663, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8W1270KahUtW for ; Sun, 21 Aug 2011 05:46:19 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7860121F883A for ; Sun, 21 Aug 2011 05:46:19 -0700 (PDT) Received: by ewy19 with SMTP id 19so1613199ewy.31 for ; Sun, 21 Aug 2011 05:47:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.146.14 with SMTP id q14mr315800eej.82.1313930838835; Sun, 21 Aug 2011 05:47:18 -0700 (PDT) Received: by 10.14.45.78 with HTTP; Sun, 21 Aug 2011 05:47:18 -0700 (PDT) In-Reply-To: <4E504A99.9020602@acm.org> References: <4E504A99.9020602@acm.org> Date: Sun, 21 Aug 2011 08:47:18 -0400 Message-ID: From: Bruce Lowekamp To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Interoperability problem with lifetime 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, 21 Aug 2011 12:46:20 -0000 Marc, I think using "interoperability problem" as the subject of every clarification request is maybe a bit overly dramatic, despite the fact that technically an unclear passage could lead to interop problems. I think it was implied from the definition of the field at the beginning of section 6 and the description of the algorithm for use in StoredData in 6.4.1 how to calculate the lifetime value, but we can add something to the mention of StoredData in 6.4.2 and definition of StoredMetaData in 6.4.3 saying to use the same algorithm every time the lifetime value is used to make it explicit. Bruce On Sat, Aug 20, 2011 at 8:00 PM, Marc Petit-Huguenin wro= te: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > A lifetime value is sent in both FetchKindResponse and StatKindResponse b= ut > there is no explanation about what this value should contain. > > If it is the value that was sent in the StoreReq, then this value is usel= ess for > the node that will receive it, as it is not relative to the storage_time = field, > and so cannot be used to know when to re-store the resource record. =C2= =A0So it would > make sense that this field contains the *remaining* lifetime for the reso= urce > record (using an algorithm similar to what is in section 6.4.1.1), but it= is not > explicitly said in the spec, so there will be variations in implementatio= ns, and > interoperability problems for implementations that will count on using th= is > field as the remaining lifetime. > > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk5QSpgACgkQ9RoMZyVa61c5aQCgmEh1sK5e3qYxZVLMK5xpPt35 > RQYAnRTseKflyht1DuEJ6Z/NJfdnowWD > =3DbJmD > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From p2p.nve.2011@gmail.com Mon Aug 22 07:35:51 2011 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 C452D21F8B18; Mon, 22 Aug 2011 07:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BudtRAIVBUss; Mon, 22 Aug 2011 07:35:51 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0E28721F8B0C; Mon, 22 Aug 2011 07:35:48 -0700 (PDT) Received: by gwb20 with SMTP id 20so3772706gwb.31 for ; Mon, 22 Aug 2011 07:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=4ety/GhcsbdX3XSi8wc625ym25NBXghXvxhq9D6eUG0=; b=ilaGpaSsOUU9Cp4LrNGWVG5lBDSOKeSC9AHGvrR4HMP5FON17pbn50rZHNzCsMPfbv nvnj10CWPGBDMTuSuDeaWn63mHwqV4wc5jM9HuVfj1EqUcnmvWPVqK8lSGMPQl4TEfNw anqfBVAtAftTEdPCWja6aVVIpMAs/m/PYzU8o= MIME-Version: 1.0 Received: by 10.142.51.4 with SMTP id y4mr1642351wfy.107.1314023810349; Mon, 22 Aug 2011 07:36:50 -0700 (PDT) Received: by 10.143.60.11 with HTTP; Mon, 22 Aug 2011 07:36:50 -0700 (PDT) Date: Mon, 22 Aug 2011 22:36:50 +0800 Message-ID: From: 2011 p2pnve To: tccc@lists.cs.columbia.edu, p2p@ogf.org, p2psip@ietf.org, ppsp@ietf.org, sam@irtf.org Content-Type: multipart/alternative; boundary=000e0cd20d86713c7104ab1902f6 Subject: [P2PSIP] [CFP] P2PNVE 2011 [Deadline extended to Aug. 30, 2011 (Firm Deadline)] 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, 22 Aug 2011 14:35:51 -0000 --000e0cd20d86713c7104ab1902f6 Content-Type: text/plain; charset=ISO-8859-1 [Apologies if you receive multiple copies of this message] * Deadline extended to August 30, 2011 (Firm Deadline)* CALL FOR PAPERS ======================================================================== The 5th International Workshop on Peer-to-Peer Networked Virtual Environments (P2P-NVE 2011) in conjunction with The 17th International Conference on Parallel and Distributed Systems (ICPADS 2011) December 7-9, 2011 Tainan, Taiwan http://acnlab.csie.ncu.edu.tw/P2PNVE2011/ ======================================================================== PURPOSE AND SCOPE Peer-to-peer (P2P) is a computing paradigm based on self-organizing network overlays, in which participating entities play symmetric roles as both servers and clients for accomplish common goals. Compared with the traditional client/server (C/S) paradigm, the P2P paradigm is not vulnerable to a single point of failure and has better scalability and lower installation and management cost. It has been successfully applied to many applications, such as data sharing, storage sharing, bandwidth sharing, collaborative computation, and so on. Many research studies have been devoted to developing efficient, flexible, and secure P2P systems. They call for a workshop to provide a forum for researchers to exchange their ideas about state-of-the-art P2P technologies. Recently, some studies try to apply the P2P paradigm to network virtual environments (NVEs), which is also known as distributed virtual environment (DVEs) or collaborative virtual environment (CVEs), to increase NVE scalability and to reduce NVE management and deployment costs. An NVE is a computer-generated virtual world where multiple users can assume virtual representatives (or avatars) to concurrently interact with each other via networked links. Examples of NVEs include early DARPA SIMNET and DIS systems as well as currently booming Massively Multiplayer Online Games (MMOGs). Typical examples of studies on P2P NVEs are P2P voice chatting, P2P 3D streaming, P2P game state management, and so on. In spite of the success of the studies, we need more studies about state consistency control, persistent data storage, multimedia data dissemination, cheat-prevention, topology mismatching, and virtual world interoperability to construct NVEs of better performance. The 1st, 2nd, 3rd and 4th International Workshop on Peer-to-Peer Networked Virtual Environments were held in conjunction with the 13th, 14th, 15th and 16th International Conference on Parallel and Distributed Systems in 2007, 2008, 2009, and 2010 respectively. To adhere to the theme of P2P-NVE workshops, the theme of P2P-NVE 2011 is to solicit original and previously unpublished new ideas on general P2P schemes as well as on the design and realization of P2P NVEs. The workshop aims to facilitate discussions and idea exchanges by both academics and practitioners. Authors are invited to submit an electronic version of original, unpublished manuscripts, not to exceed 8 double-columned, single-spaced pages, to the workshop. Submitted papers should be in accordance with IEEE Computer Society guidelines, and will be refereed by reviewers in terms of relevance, originality, contribution, correctness, and presentation. All Accepted papers will be published by IEEE Press (indexed by EI) and will be included in IEEE Xplore. Topics of interest include, but are not limited to: * P2P systems and infrastructures * Applications of P2P systems * Performance evaluation of P2P systems * Trust and security issues in P2P systems * Network support for P2P systems * Fault tolerance in P2P systems * Data structures for P2P systems * Efficient P2P resource lookup and sharing * Distributed Hash Tables (DHTs) and related issues * Solutions to topology mismatching for P2P overlays * P2P overlays for NVEs * P2P NVE multicast * P2P NVE interoperability * P2P NVE content distribution * P2P NVE 3D streaming * P2P NVE voice communications * P2P NVE architecture designs * P2P NVE prototypes * P2P NVE consistency control * Persistent storage for P2P NVEs * Security and cheat-prevention mechanisms for P2P games * P2P control for mobile NVEs * P2P NVE applications on mobile devices ========================================== IMPORTANT DATES Submission: August 30, 2011 (Firm Deadline) Notification: September 25, 2011 Camera ready: October 7, 2011 =========================================== PAPER SUBMISSION Authors are invited to submit an electronic version of original, unpublished manuscripts, not to exceed 8 double-columned, single-spaced pages, to the workshop. Submitted papers should be in PDF format in accordance with IEEE Computer Society guidelines, and will be refereed by reviewers in terms of originality, contribution, correctness, and presentation. --000e0cd20d86713c7104ab1902f6 Content-Type: text/html; charset=Big5 Content-Transfer-Encoding: quoted-printable

[Apologies if you= receive multiple copies of this message]

 

* Deadline extended to August= 30, 2011 (Firm Deadline)*

 

CALL FOR PAPERS

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
The 5th International Workshop on Peer-to-Peer Networked Vi= rtual Environments (P2P-NVE 2011)

in conjunction with

The 17th International Conference on Parallel and Distributed Systems (ICPA= DS 2011)

December 7-9, 2011
Tainan, Taiwan

http://acnlab.csie.ncu.edu.tw/= P2PNVE2011/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
PURPO= SE AND SCOPE

Peer-to-peer (P2P) is a computing paradigm based on sel= f-organizing network overlays, in which participating entities play symmetr= ic roles as both servers and clients for accomplish common goals. Compared = with the traditional client/server (C/S) paradigm, the P2P paradigm is not = vulnerable to a single point of failure and has better scalability and lowe= r installation and management cost. It has been successfully applied to man= y applications, such as data sharing, storage sharing, bandwidth sharing, c= ollaborative computation, and so on. Many research studies have been devote= d to developing efficient, flexible, and secure P2P systems. They call for = a workshop to provide a forum for researchers to exchange their ideas about= state-of-the-art P2P technologies. Recently, some studies try to apply the= P2P paradigm to network virtual environments (NVEs), which is also known a= s distributed virtual environment (DVEs) or collaborative virtual environme= nt (CVEs), to increase NVE scalability and to reduce NVE management and dep= loyment costs. An NVE is a computer-generated virtual world where multiple = users can assume virtual representatives (or avatars) to concurrently inter= act with each other via networked links. Examples of NVEs include early DAR= PA SIMNET and DIS systems as well as currently booming Massively Multiplaye= r Online Games (MMOGs). Typical examples of studies on P2P NVEs are P2P voi= ce chatting, P2P 3D streaming, P2P game state management, and so on. In spi= te of the success of the studies, we need more studies about state consiste= ncy control, persistent data storage, multimedia data dissemination, cheat-= prevention, topology mismatching, and virtual world interoperability to con= struct NVEs of better performance.

The 1st, 2nd, 3rd and 4th International Workshop on Peer-to-Peer Networ= ked Virtual Environments were held in conjunction with the 13th, 14th, 15th= and 16th International Conference on Parallel and Distributed Systems in 2= 007, 2008, 2009, and 2010 respectively. To adhere to the theme of P2P-NVE w= orkshops, the theme of P2P-NVE 2011 is to solicit original and previously u= npublished new ideas on general P2P schemes as well as on the design and re= alization of P2P NVEs. The workshop aims to facilitate discussions and idea= exchanges by both academics and practitioners. Authors are invited to subm= it an electronic version of original, unpublished manuscripts, not to excee= d 8 double-columned, single-spaced pages, to the workshop. Submitted papers= should be in accordance with IEEE Computer Society guidelines, and will be= refereed by reviewers in terms of relevance, originality, contribution, co= rrectness, and presentation. All Accepted papers will be published by IEEE = Press (indexed by EI) and will be included in IEEE Xplore.


Topics of interest include, but are not limited to:


* &n= bsp; P2P systems and infrastructures
*   Applications of P2P system= s
*   Performance evaluation of P2P systems
*   Trust and s= ecurity issues in P2P systems
*   Network support for P2P systems
*   Fault tolerance in P2P= systems
*   Data structures for P2P systems
*   Efficient = P2P resource lookup and sharing
*   Distributed Hash Tables (DHTs) = and related issues
*   Solutions to topology mismatching for P2P overlays
*   P2P= overlays for NVEs
*   P2P NVE multicast
*   P2P NVE intero= perability
*   P2P NVE content distribution
*   P2P NVE 3D = streaming
*   P2P NVE voice communications
*   P2P NVE architecture designs
*   P2P NVE prototypes
* &= nbsp; P2P NVE consistency control
*   Persistent storage for P2P NV= Es
*   Security and cheat-prevention mechanisms for P2P games
* =   P2P control for mobile NVEs
*   P2P NVE applications on mobile devices

=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IMPORTANT DATES

Submission:              = ; August 30, 2011 (Firm Deadline)
Notification:    = ;        = ;  September 25, 2011
Camera ready:           October 7, 2011
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

PAPER SUBMISSION
Authors are invited to submit an electronic version of original, unpub= lished manuscripts, not to exceed 8 double-columned, single-spaced pages, t= o the workshop. Submitted papers should be in PDF format in accordance with= IEEE Computer Society guidelines, and will be refereed by reviewers in ter= ms of originality, contribution, correctness, and presentation.


 --000e0cd20d86713c7104ab1902f6-- From petithug@acm.org Thu Aug 25 11:14:02 2011 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 1A83A21F8548 for ; Thu, 25 Aug 2011 11:14:02 -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 QPJ+AAyRTCKK for ; Thu, 25 Aug 2011 11:14:01 -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 6BA5121F84DB for ; Thu, 25 Aug 2011 11:14:01 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 78EA8202C8 for ; Thu, 25 Aug 2011 20:10:55 +0200 (CEST) Message-ID: <4E56912F.2010507@acm.org> Date: Thu, 25 Aug 2011 11:15:11 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110820 Iceowl/1.0b2 Icedove/3.1.12 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Slight probability increase that two systems implementing RELOAD do not behave identically 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, 25 Aug 2011 18:14:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (Sorry for the convoluted title, it seems I can no longer say "Interoperability problem") It is about the size of i in section 6.3.4 (and d in section 8). I remember Cullen saying that it is 4 bytes, but it seems that the spec was never updated to reflect that. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5WkSoACgkQ9RoMZyVa61chzgCglyj7Q/f71Htig/ctzQTgCyWE QJgAmwRQZRa3lYAz6K0Jjkn7sfzYptEE =Xz6K -----END PGP SIGNATURE----- From davidbryan@gmail.com Thu Aug 25 15:20:54 2011 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 3092021F85A3 for ; Thu, 25 Aug 2011 15:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 YIe4Q3mAiKTJ for ; Thu, 25 Aug 2011 15:20:53 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B03321F85AB for ; Thu, 25 Aug 2011 15:20:53 -0700 (PDT) Received: by qyk34 with SMTP id 34so3709464qyk.10 for ; Thu, 25 Aug 2011 15:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QMYIoWTYci62swIZw2NWhRm4rcq4I5QWDauCYS3w600=; b=BNct93mZUh8Sg4yjpwzF6tqtiUFqDCnpjX9x3u0fBVvFnuriUGdj9icGhs6ubOlAoc 5Fo6NJhzVbyMh4PLLl6Ju5Eb0UAZyjWo35doG77DCfRNzcDQeymDoTZRIxck5NgZhndo CmFGZdQDer3p0d6wG39+QB33Ylgc4VtpOUB00= MIME-Version: 1.0 Received: by 10.229.240.72 with SMTP id kz8mr420034qcb.114.1314310927544; Thu, 25 Aug 2011 15:22:07 -0700 (PDT) Sender: davidbryan@gmail.com Received: by 10.229.38.142 with HTTP; Thu, 25 Aug 2011 15:22:07 -0700 (PDT) In-Reply-To: <4E481113.3020802@acm.org> References: <4E481113.3020802@acm.org> Date: Thu, 25 Aug 2011 15:22:07 -0700 X-Google-Sender-Auth: I_x5m3StHjzucbZc6gSJhcYFY3o Message-ID: From: "David A. Bryan" To: Marc Petit-Huguenin Content-Type: multipart/alternative; boundary=0016364d2fa7f5f02204ab5bdbaa Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Review of draft-ietf-p2psip-concepts-03 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, 25 Aug 2011 22:20:54 -0000 --0016364d2fa7f5f02204ab5bdbaa Content-Type: text/plain; charset=ISO-8859-1 Thanks for the comments. I'm working on a new version. Many of these are great suggestions and require no comment, but a few comments on a few are inline: 4. Section 5: Peer-ID > > All the other drafts use the "Node-ID" terminology, so why not invert the > definition, I.e. define Node-ID and says that this is sometimes called a > "Peer-ID"? See also the definition of "Peer" and Section 6.4 that both use > "Peer-ID". > Actually,back in the day there was a long discussion on this, and Node-ID was decided (by the group) as the preferred term. Despite that, as things evolved the editors of base used Peer-ID, and it stuck. (particularly unfortunate since RELOAD gives Peer-IDs to clients). In any case, the name has stuck, and I'll definitely make the change. > 6. Section 5: Responsible Peer > > I did not read all the literature on the subject, but I never saw the term > "Root > Peer" used as synonym for "Responsible Peer." > It is used quite a bit in the early academic literature (again going back to when this was first written), but I agree responsible peer is used more now (and is better for an arrangement-agnostic design like RELOAD anyway) 9. Security Section > > Security section missing. > This is an interesting point. Since it has turned out that security is discussed in more detailed context in the specific drafts, do we want something like this in here, and if so, what do we want in this draft? My thought would be either a) we don't have a security section in here or b) we have a generic section on P2P security threats, but although I'm making the other changes, I'm not sure I'll have time to write something like that. Thoughts on that? David (as individual) --0016364d2fa7f5f02204ab5bdbaa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the comments.=A0I'm working on a new version. Many of t= hese are great suggestions and require no comment, but a few comments on a = few are inline:

4. Section 5: Peer-ID

All the other drafts use the "Node-ID" terminology, so why not in= vert the
definition, I.e. define Node-ID and says that this is sometimes called a "Peer-ID"? =A0See also the definition of "Peer" and Sec= tion 6.4 that both use
"Peer-ID".

Actually,back in t= he day there was a long discussion on this, and Node-ID was decided (by the= group) as the preferred term. Despite that, as things evolved the editors = of base used Peer-ID, and it stuck. (particularly unfortunate since RELOAD = gives Peer-IDs to clients). In any case, the name has stuck, and I'll d= efinitely make the change.
=A0
6. Section 5: Responsible Peer

I did not read all the literature on the subject, but I never saw the term = "Root
Peer" used as synonym for "Responsible Peer."

It is used quite a bit in the early academic literatu= re (again going back to when this was first written), but I agree responsib= le peer is used more now (and is better for an arrangement-agnostic design = like RELOAD anyway)

9. Security Section

Security section missing.

This is an in= teresting point. Since it has turned out that security is discussed in more= detailed context in the specific drafts, do we want something like this in= here, and if so, what do we want in this draft? My thought would be either= a) we don't have a security section in here or b) we have a generic se= ction on P2P security threats, but although I'm making the other change= s, I'm not sure I'll have time to write something like that.

Thoughts on that?

David (as in= dividual)
--0016364d2fa7f5f02204ab5bdbaa-- From bbl@lowekamp.net Thu Aug 25 15:55:57 2011 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 524D621F8751 for ; Thu, 25 Aug 2011 15:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6u4UbCxxKOEZ for ; Thu, 25 Aug 2011 15:55:56 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3182621F855D for ; Thu, 25 Aug 2011 15:55:56 -0700 (PDT) Received: by ewy19 with SMTP id 19so1339568ewy.31 for ; Thu, 25 Aug 2011 15:57:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.9.96 with SMTP id 72mr156354ees.114.1314313029993; Thu, 25 Aug 2011 15:57:09 -0700 (PDT) Received: by 10.14.53.5 with HTTP; Thu, 25 Aug 2011 15:57:09 -0700 (PDT) In-Reply-To: References: <4E481113.3020802@acm.org> Date: Thu, 25 Aug 2011 18:57:09 -0400 Message-ID: From: Bruce Lowekamp To: "David A. Bryan" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Review of draft-ietf-p2psip-concepts-03 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, 25 Aug 2011 22:55:57 -0000 On Thu, Aug 25, 2011 at 6:22 PM, David A. Bryan wrote= : >> 4. Section 5: Peer-ID >> >> All the other drafts use the "Node-ID" terminology, so why not invert th= e >> definition, I.e. define Node-ID and says that this is sometimes called a >> "Peer-ID"? =C2=A0See also the definition of "Peer" and Section 6.4 that = both >> use >> "Peer-ID". > > Actually,back in the day there was a long discussion on this, and Node-ID > was decided (by the group) as the preferred term. Despite that, as things > evolved the editors of base used Peer-ID, and it stuck. (particularly > unfortunate since RELOAD gives Peer-IDs to clients). In any case, the nam= e > has stuck, and I'll definitely make the change. Just to make sure, I think the explanation was backward. The group decided to use the term "Peer-ID" but as we edited the base draft, we got tired of writing the phrase "Peer-ID of a peer or Client-ID of a client" and just used "Node-ID" because it was clearer. Bruce From petithug@acm.org Thu Aug 25 15:56:52 2011 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 A021921F8BCB for ; Thu, 25 Aug 2011 15:56:52 -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 N+KEkyTAvAJ7 for ; Thu, 25 Aug 2011 15:56:52 -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 EAD3921F8BC5 for ; Thu, 25 Aug 2011 15:56:51 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 3022C202C8; Fri, 26 Aug 2011 00:53:46 +0200 (CEST) Message-ID: <4E56D37B.4000208@acm.org> Date: Thu, 25 Aug 2011 15:58:03 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110820 Iceowl/1.0b2 Icedove/3.1.12 MIME-Version: 1.0 To: "David A. Bryan" References: <4E481113.3020802@acm.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Review of draft-ietf-p2psip-concepts-03 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, 25 Aug 2011 22:56:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/25/2011 03:22 PM, David A. Bryan wrote: > Thanks for the comments. I'm working on a new version. Many of these are great > suggestions and require no comment, but a few comments on a few are inline: > [...] > > 9. Security Section > > Security section missing. > > > This is an interesting point. Since it has turned out that security is discussed > in more detailed context in the specific drafts, do we want something like this > in here, and if so, what do we want in this draft? My thought would be either a) > we don't have a security section in here or b) we have a generic section on P2P > security threats, but although I'm making the other changes, I'm not sure I'll > have time to write something like that. > > Thoughts on that? My comment was more about the fact that such section is mandatory, according to RFC 2223. Because this spec is for "Peer to Peer SIP", not "Peer to Peer", I do not think that a generic section on P2P security threats is needed. Perhaps it is OK to just say that the security sections of p2psip-base and p2psip-sip cover everything. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5W03kACgkQ9RoMZyVa61ezpQCfa+8o9EJYiAcKzhV5JtdO30lo fdoAn3apUi8oq09fvLJyiR+UEZddO6Oc =ZHdU -----END PGP SIGNATURE----- From fluffy@cisco.com Thu Aug 25 17:05:14 2011 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 2EB9021F8BF0 for ; Thu, 25 Aug 2011 17:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.136 X-Spam-Level: X-Spam-Status: No, score=-103.136 tagged_above=-999 required=5 tests=[AWL=-1.137, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 KSqO4zS9QmGu for ; Thu, 25 Aug 2011 17:05:13 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9006C21F8BA9 for ; Thu, 25 Aug 2011 17:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1432; q=dns/txt; s=iport; t=1314317188; x=1315526788; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=kxs7KAQlGH4JO3NQIeIGO2PdhKLgNjE3OCy9UZ0IwqA=; b=gSZgctEeRcScKmB5RUeKh486grleNhR+3K5KqBclPoKD9+mtxQQY7bCZ /M1pb072HB4s9ijWN/HcaRffi/rrt8lTQKwA7Wkcz56sO6AgCJbP51IC9 Uz2nEIiD/in8pWZ8Gt2ox8tliZ0WoVRqCMKlQTyG1OKAjuul9nWWgqUY4 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEnjVk6rRDoH/2dsb2JhbABDqA93gUEBAQQSASc/EEYLVwY1onoBnw6FbGAEh2GLOIUNjA0 X-IronPort-AV: E=Sophos;i="4.68,283,1312156800"; d="scan'208";a="16620490" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-6.cisco.com with ESMTP; 26 Aug 2011 00:06:28 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7Q06Qru012178; Fri, 26 Aug 2011 00:06:27 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4E56912F.2010507@acm.org> Date: Thu, 25 Aug 2011 18:06:26 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E56912F.2010507@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: P2PSIP Mailing List Subject: [P2PSIP] Interoperability problem Was: Slight probability increase that two systems implementing RELOAD do not behave identically 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, 26 Aug 2011 00:05:14 -0000 On Aug 25, 2011, at 12:15 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > (Sorry for the convoluted title, it seems I can no longer say = "Interoperability > problem") >=20 > It is about the size of i in section 6.3.4 (and d in section 8). I = remember > Cullen saying that it is 4 bytes, but it seems that the spec was never = updated > to reflect that. Uh, I think the resolution was the other way around for one and as you = say for the other. Let me separate the two.. First for the size of i, in section 6.3.4. The max value of this is = controlled by the max-node-multiple values with is limited in the XML = grammar to xsd:int. It never shows up on the wire so I think this is = defined as 4 bytes. Given the need to interate through all values up to = the limit computing a hash each time, people will need to stick to small = values.=20 On the other one, d in section 8, I think we decided on 8 bits was = enough. Back in draft-ietf-p2psip-base-13 the relax NG for turn-density = defined it as and xsd:int which did not match the unit8 in for d in = section 8 but we moved the XML grammar to be xsd:unsignedByte in = version 14 of the draft. =20 So, I think we decided 4 bytes for the first and 1 byte for the second. = I think the doc is consistent with that. Is there a part that is = inconsistent where I need to update it.=20 Cullen From stephane.ml.bryant@gmail.com Thu Aug 25 23:20:36 2011 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 D588921F8AF8 for ; Thu, 25 Aug 2011 23:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q4ZEEW0F7YX for ; Thu, 25 Aug 2011 23:20:36 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1007B21F8AE1 for ; Thu, 25 Aug 2011 23:20:35 -0700 (PDT) Received: by wwf5 with SMTP id 5so2097749wwf.13 for ; Thu, 25 Aug 2011 23:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:x-enigmail-version:content-type:content-transfer-encoding; bh=3UzMi1PYZHGlF1q+sCdaWeLpUiJWnzbkW/Ibyue1ghY=; b=qxjFE4tEi5fItCzduM77vluSNnH81JaxEXgTBuABz3499bJt1SGMUIugPSiqDgQAYJ /VBvpMc/7qrBKS29I9/MnyW6160kAbxAwImhV7p5D6MALcErMdBcViljv12VgIfxViAU xoiFP9xB98ZMhSEWQ9sWRyj5cDkauR0Wn0JYs= Received: by 10.227.202.209 with SMTP id ff17mr521763wbb.78.1314339710719; Thu, 25 Aug 2011 23:21:50 -0700 (PDT) Received: from ?IPv6:2a01:e35:39c8:8ae0:21d:baff:fef1:8a0e? ([2a01:e35:39c8:8ae0:21d:baff:fef1:8a0e]) by mx.google.com with ESMTPS id fh17sm1025150wbb.54.2011.08.25.23.21.49 (version=SSLv3 cipher=OTHER); Thu, 25 Aug 2011 23:21:49 -0700 (PDT) Sender: stephane bryant Message-ID: <4E573B78.8000506@glycon.org> Date: Fri, 26 Aug 2011 08:21:44 +0200 From: =?ISO-8859-1?Q?st=E9phane_bryant?= Organization: StonyFish, Inc User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: p2psip@ietf.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] minor ambiguities in draft-ietf-p2psip-base-18 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, 26 Aug 2011 06:20:36 -0000 Hello, I have found what seems to be two typos or ambiguities in draft-ietf-p2psip-base-18: * In section 8 (TURN Server Usage), the TurnServer structure is defined as: struct { uint8 iteration; IpAddressAndPort server_address; } TurnServer; However, IpAddressAndPort, is not defined anywhere, what is defined instead, in 5.3.1.1 (Common Definitions) is IpAddressPort * In section 5.5.1.1 (Request Definition, for Attach), in the description of the IceCandidate structure it says: << rel_addr_port corresponds to the rel-addr and rel-port productions. Only present for type "relay". >> However, in the structure itself, we have: << select (type){ case host: ; /* Nothing */ case srflx: case prflx: case relay: IpAddressPort rel_addr_port; }; >> The rel_addr_port is therefore present for the types srflx, prflx, and relay. Regards stephane bryant From stephane.ml.bryant@gmail.com Fri Aug 26 08:17:28 2011 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 9E14D21F8829 for ; Fri, 26 Aug 2011 08:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzzYsBLrCu1w for ; Fri, 26 Aug 2011 08:17:28 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id E0BE021F8779 for ; Fri, 26 Aug 2011 08:17:27 -0700 (PDT) Received: by wwf5 with SMTP id 5so2420998wwf.13 for ; Fri, 26 Aug 2011 08:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:x-enigmail-version:content-type:content-transfer-encoding; bh=Ae7Oc/Akhc+P9lVE6Yk++sEJ6VDyXshb9mEiO1v45+Y=; b=YrZGViHCulvd91RP7KrcGNag83Z2hhz/KMEGvrqPhgT42m27T6WM7BuAsLrWPRcH/4 V0parJPaVp9T/Yj2XYATwKRk/vPW3fjpdxxr5ma+F1uoenTwXJCPVSkpCXMH2HadFgOp FwNHefw7n2BaFNazpvez8eK4dv5W1hWR1IMcE= Received: by 10.227.145.139 with SMTP id d11mr471267wbv.60.1314371923613; Fri, 26 Aug 2011 08:18:43 -0700 (PDT) Received: from ?IPv6:2a01:e35:39c8:8ae0:21d:baff:fef1:8a0e? ([2a01:e35:39c8:8ae0:21d:baff:fef1:8a0e]) by mx.google.com with ESMTPS id fj19sm1384468wbb.15.2011.08.26.08.18.40 (version=SSLv3 cipher=OTHER); Fri, 26 Aug 2011 08:18:41 -0700 (PDT) Sender: stephane bryant Message-ID: <4E57B94C.50707@glycon.org> Date: Fri, 26 Aug 2011 17:18:36 +0200 From: =?ISO-8859-1?Q?st=E9phane_bryant?= Organization: StonyFish, Inc User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: p2psip@ietf.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] flag issue in draft-zong-p2psip-drr-00 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, 26 Aug 2011 15:17:28 -0000 Hello, I am currently working on adding wireshark dissectors for the WG drafts, and i stumbled upon an issue in draft-zong-p2psip-drr-00: In section section 6.2.1 (State-keeping Flag) it defines the flag: flag : 0x3 IGNORE-STATE-KEEPING However, this flag enters in conflict with 2 predefined flags for the ForwardingOption structure: FORWARD_CRITICAL(0x01), DESTINATION_CRITICAL(0x02) (Unless there is a semantic rule linking them, implication or mutual exclusion). As soon as this issue will be cleared, i will add the dissector. Regards, Stephane From Even.roni@huawei.com Fri Aug 26 09:58:58 2011 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 9363121F8B9A for ; Fri, 26 Aug 2011 09:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.874 X-Spam-Level: X-Spam-Status: No, score=-105.874 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gk4RD388ONcN for ; Fri, 26 Aug 2011 09:58:58 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id F0B2F21F8BC5 for ; Fri, 26 Aug 2011 09:58:57 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQJ00M23OKDZI@szxga03-in.huawei.com> for p2psip@ietf.org; Sat, 27 Aug 2011 01:00:13 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQJ0022BOKDLB@szxga03-in.huawei.com> for p2psip@ietf.org; Sat, 27 Aug 2011 01:00:13 +0800 (CST) Received: from windows8d787f9 ([109.64.200.234]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LQJ003X3OK7H8@szxml12-in.huawei.com>; Sat, 27 Aug 2011 01:00:13 +0800 (CST) Date: Fri, 26 Aug 2011 19:59:09 +0300 From: Roni Even In-reply-to: <4E57B94C.50707@glycon.org> To: =?ISO-8859-1?Q?'st=E9phane_bryant'?= , p2psip@ietf.org Message-id: <016201cc6411$7d4e3200$77ea9600$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=ISO-8859-1 Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcxkA5EpgsG5hghETJGgW4ahtiAMpgAC907Q References: <4E57B94C.50707@glycon.org> Subject: Re: [P2PSIP] flag issue in draft-zong-p2psip-drr-00 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, 26 Aug 2011 16:58:58 -0000 Hi Stephane, This is a good point the DRR draft should specify what is the behavior if FORWARD_CRITICAL(0x01) or DESTINATION_CRITICAL(0x02) also appears in the message. I think that the right behavior is to obey the FORWARD_CRITICAL(0x01)/ DESTINATION_CRITICAL(0x02) defined behavior. "If the FORWARD_CRITICAL flag is set, any node that would forward the message but does not understand this options MUST reject the request with an error_Unsupported_Forwarding_Option error response. If the DESTINATION_CRITICAL flag is set, any node that generates a response to the message but does not understand the forwarding option MUST reject the request with an Error_Unsupported_Forwarding_Option error response." I think that DRR should recommend that the RESPONSE_COPY flag SHOULD be set to false while the FORWARD_CRITICAL and DESTINATION_CRITICAL SHOULD be set to true. (This text appeared in http://tools.ietf.org/html/draft-ietf-p2psip-base-10#page-47 Roni Even > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > Behalf Of st?phane bryant > Sent: Friday, August 26, 2011 6:19 PM > To: p2psip@ietf.org > Subject: [P2PSIP] flag issue in draft-zong-p2psip-drr-00 > > Hello, > > I am currently working on adding wireshark dissectors > for the WG drafts, and i stumbled upon an issue > in draft-zong-p2psip-drr-00: > > In section section 6.2.1 (State-keeping Flag) it > defines the flag: > flag : 0x3 IGNORE-STATE-KEEPING > > However, this flag enters in conflict with 2 > predefined flags for the ForwardingOption structure: > FORWARD_CRITICAL(0x01), DESTINATION_CRITICAL(0x02) > > (Unless there is a semantic rule linking them, > implication or mutual exclusion). > > As soon as this issue will be cleared, i will > add the dissector. > > Regards, > Stephane > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From petithug@acm.org Fri Aug 26 12:58:49 2011 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 A874821F8C3A for ; Fri, 26 Aug 2011 12:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AN3m57-ib+lH for ; Fri, 26 Aug 2011 12:58: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 06D7D21F8BF3 for ; Fri, 26 Aug 2011 12:58:49 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id DA4E3202C8; Fri, 26 Aug 2011 21:55:40 +0200 (CEST) Message-ID: <4E57FB41.70705@acm.org> Date: Fri, 26 Aug 2011 13:00:01 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110820 Iceowl/1.0b2 Icedove/3.1.12 MIME-Version: 1.0 To: Cullen Jennings References: <4E56912F.2010507@acm.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Interoperability problem Was: Slight probability increase that two systems implementing RELOAD do not behave identically 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, 26 Aug 2011 19:58:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/25/2011 05:06 PM, Cullen Jennings wrote: > > On Aug 25, 2011, at 12:15 PM, Marc Petit-Huguenin wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> (Sorry for the convoluted title, it seems I can no longer say >> "Interoperability problem") >> >> It is about the size of i in section 6.3.4 (and d in section 8). I >> remember Cullen saying that it is 4 bytes, but it seems that the spec was >> never updated to reflect that. > > Uh, I think the resolution was the other way around for one and as you say > for the other. Let me separate the two.. > > First for the size of i, in section 6.3.4. The max value of this is > controlled by the max-node-multiple values with is limited in the XML grammar > to xsd:int. It never shows up on the wire so I think this is defined as 4 > bytes. Given the need to interate through all values up to the limit > computing a hash each time, people will need to stick to small values. > > On the other one, d in section 8, I think we decided on 8 bits was enough. > Back in draft-ietf-p2psip-base-13 the relax NG for turn-density defined it as > and xsd:int which did not match the unit8 in for d in section 8 but we moved > the XML grammar to be xsd:unsignedByte in version 14 of the draft. > > So, I think we decided 4 bytes for the first and 1 byte for the second. I > think the doc is consistent with that. Is there a part that is inconsistent > where I need to update it. If you are 100% sure that no implementer will ever read the spec differently than you did here, then the doc does not need update. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5X+zwACgkQ9RoMZyVa61ddYwCeMP51NflZTZOgREemAwNRGhBa 15UAn2zRo7l67j1jnhEkEWnMKwFwEFsL =6dHy -----END PGP SIGNATURE----- From p2p.nve.2011@gmail.com Sun Aug 28 08:05:01 2011 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 7D9DF21F8B90; Sun, 28 Aug 2011 08:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=1.732, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwbfg3qgb9SX; Sun, 28 Aug 2011 08:05:00 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3C57D21F8B5B; Sun, 28 Aug 2011 08:05:00 -0700 (PDT) Received: by pzk33 with SMTP id 33so16451256pzk.18 for ; Sun, 28 Aug 2011 08:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=bbwjsiESM9XRoIzp/Jz1065WNvnpnudliWV8SrialBQ=; b=aErGJoYMKHB06lRxQTZ98sW2jIr3KlOZBimBNddHf5/Yf/77HnmsXWbc3iRbqmj+qY a3u56yVSUfZu7SJu6uPL7uIXRYAJGLbToV79ASfVCdfjFF76O8LqKWkDKrfS1WPaXWSO Ok9fbECmATPFcJBvCDxQ0zDkSB3vgdR/6DK0Y= MIME-Version: 1.0 Received: by 10.142.233.15 with SMTP id f15mr764304wfh.335.1314543982247; Sun, 28 Aug 2011 08:06:22 -0700 (PDT) Received: by 10.143.60.11 with HTTP; Sun, 28 Aug 2011 08:06:22 -0700 (PDT) Date: Sun, 28 Aug 2011 23:06:22 +0800 Message-ID: From: 2011 p2pnve To: tccc@lists.cs.columbia.edu, p2p@ogf.org, p2psip@ietf.org, ppsp@ietf.org, sam@irtf.org Content-Type: multipart/alternative; boundary=000e0cd23b9e1a7de704ab921f15 Subject: [P2PSIP] [Last CFP] P2PNVE 2011 [Deadline extended to Aug. 30, 2011 (Firm Deadline)] 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, 28 Aug 2011 15:05:01 -0000 --000e0cd23b9e1a7de704ab921f15 Content-Type: text/plain; charset=ISO-8859-1 [Apologies if you receive multiple copies of this message] * Deadline extended to August 30, 2011 (Firm Deadline)* CALL FOR PAPERS ======================================================================== The 5th International Workshop on Peer-to-Peer Networked Virtual Environments (P2P-NVE 2011) in conjunction with The 17th International Conference on Parallel and Distributed Systems (ICPADS 2011) December 7-9, 2011 Tainan, Taiwan http://acnlab.csie.ncu.edu.tw/P2PNVE2011/ ======================================================================== PURPOSE AND SCOPE Peer-to-peer (P2P) is a computing paradigm based on self-organizing network overlays, in which participating entities play symmetric roles as both servers and clients for accomplish common goals. Compared with the traditional client/server (C/S) paradigm, the P2P paradigm is not vulnerable to a single point of failure and has better scalability and lower installation and management cost. It has been successfully applied to many applications, such as data sharing, storage sharing, bandwidth sharing, collaborative computation, and so on. Many research studies have been devoted to developing efficient, flexible, and secure P2P systems. They call for a workshop to provide a forum for researchers to exchange their ideas about state-of-the-art P2P technologies. Recently, some studies try to apply the P2P paradigm to network virtual environments (NVEs), which is also known as distributed virtual environment (DVEs) or collaborative virtual environment (CVEs), to increase NVE scalability and to reduce NVE management and deployment costs. An NVE is a computer-generated virtual world where multiple users can assume virtual representatives (or avatars) to concurrently interact with each other via networked links. Examples of NVEs include early DARPA SIMNET and DIS systems as well as currently booming Massively Multiplayer Online Games (MMOGs). Typical examples of studies on P2P NVEs are P2P voice chatting, P2P 3D streaming, P2P game state management, and so on. In spite of the success of the studies, we need more studies about state consistency control, persistent data storage, multimedia data dissemination, cheat-prevention, topology mismatching, and virtual world interoperability to construct NVEs of better performance. The 1st, 2nd, 3rd and 4th International Workshop on Peer-to-Peer Networked Virtual Environments were held in conjunction with the 13th, 14th, 15th and 16th International Conference on Parallel and Distributed Systems in 2007, 2008, 2009, and 2010 respectively. To adhere to the theme of P2P-NVE workshops, the theme of P2P-NVE 2011 is to solicit original and previously unpublished new ideas on general P2P schemes as well as on the design and realization of P2P NVEs. The workshop aims to facilitate discussions and idea exchanges by both academics and practitioners. Authors are invited to submit an electronic version of original, unpublished manuscripts, not to exceed 8 double-columned, single-spaced pages, to the workshop. Submitted papers should be in accordance with IEEE Computer Society guidelines, and will be refereed by reviewers in terms of relevance, originality, contribution, correctness, and presentation. All Accepted papers will be published by IEEE Press (indexed by EI) and will be included in IEEE Xplore. Topics of interest include, but are not limited to: * P2P systems and infrastructures * Applications of P2P systems * Performance evaluation of P2P systems * Trust and security issues in P2P systems * Network support for P2P systems * Fault tolerance in P2P systems * Data structures for P2P systems * Efficient P2P resource lookup and sharing * Distributed Hash Tables (DHTs) and related issues * Solutions to topology mismatching for P2P overlays * P2P overlays for NVEs * P2P NVE multicast * P2P NVE interoperability * P2P NVE content distribution * P2P NVE 3D streaming * P2P NVE voice communications * P2P NVE architecture designs * P2P NVE prototypes * P2P NVE consistency control * Persistent storage for P2P NVEs * Security and cheat-prevention mechanisms for P2P games * P2P control for mobile NVEs * P2P NVE applications on mobile devices ========================================== IMPORTANT DATES Submission: August 30, 2011 (Firm Deadline) Notification: September 25, 2011 Camera ready: October 7, 2011 =========================================== PAPER SUBMISSION Authors are invited to submit an electronic version of original, unpublished manuscripts, not to exceed 8 double-columned, single-spaced pages, to the workshop. Submitted papers should be in PDF format in accordance with IEEE Computer Society guidelines, and will be refereed by reviewers in terms of originality, contribution, correctness, and presentation. --000e0cd23b9e1a7de704ab921f15 Content-Type: text/html; charset=Big5 Content-Transfer-Encoding: quoted-printable

[Apologie= s if you receive multiple copies of this message]

 

* Deadlin= e extended to August 30, 2011 (Firm Deadline)*

 

CALL FOR = PAPERS

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The 5th Intern= ational Workshop on Peer-to-Peer Networked Virtual Environments (P2P-NVE 20= 11)

in conjunction with

The 17th International Conference on Paralle= l and Distributed Systems (ICPADS 2011)

December 7-9, 2011
Tainan= , Taiwan

http://acnlab.csie.ncu.edu.tw/P2PNVE2011/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
PURPO= SE AND SCOPE

Peer-to-peer (P2P) is a computing paradigm based on sel= f-organizing network overlays, in which participating entities play symmetr= ic roles as both servers and clients for accomplish common goals. Compared = with the traditional client/server (C/S) paradigm, the P2P paradigm is not = vulnerable to a single point of failure and has better scalability and lowe= r installation and management cost. It has been successfully applied to man= y applications, such as data sharing, storage sharing, bandwidth sharing, c= ollaborative computation, and so on. Many research studies have been devote= d to developing efficient, flexible, and secure P2P systems. They call for = a workshop to provide a forum for researchers to exchange their ideas about= state-of-the-art P2P technologies. Recently, some studies try to apply the= P2P paradigm to network virtual environments (NVEs), which is also known a= s distributed virtual environment (DVEs) or collaborative virtual environme= nt (CVEs), to increase NVE scalability and to reduce NVE management and dep= loyment costs. An NVE is a computer-generated virtual world where multiple = users can assume virtual representatives (or avatars) to concurrently inter= act with each other via networked links. Examples of NVEs include early DAR= PA SIMNET and DIS systems as well as currently booming Massively Multiplaye= r Online Games (MMOGs). Typical examples of studies on P2P NVEs are P2P voi= ce chatting, P2P 3D streaming, P2P game state management, and so on. In spi= te of the success of the studies, we need more studies about state consiste= ncy control, persistent data storage, multimedia data dissemination, cheat-= prevention, topology mismatching, and virtual world interoperability to con= struct NVEs of better performance.

The 1st, 2nd, 3rd and 4th International Workshop on Peer-to-Peer Networ= ked Virtual Environments were held in conjunction with the 13th, 14th, 15th= and 16th International Conference on Parallel and Distributed Systems in 2= 007, 2008, 2009, and 2010 respectively. To adhere to the theme of P2P-NVE w= orkshops, the theme of P2P-NVE 2011 is to solicit original and previously u= npublished new ideas on general P2P schemes as well as on the design and re= alization of P2P NVEs. The workshop aims to facilitate discussions and idea= exchanges by both academics and practitioners. Authors are invited to subm= it an electronic version of original, unpublished manuscripts, not to excee= d 8 double-columned, single-spaced pages, to the workshop. Submitted papers= should be in accordance with IEEE Computer Society guidelines, and will be= refereed by reviewers in terms of relevance, originality, contribution, co= rrectness, and presentation. All Accepted papers will be published by IEEE = Press (indexed by EI) and will be included in IEEE Xplore.


Topics of interest include, but are not limited to:


* &n= bsp; P2P systems and infrastructures
*   Applications of P2P system= s
*   Performance evaluation of P2P systems
*   Trust and s= ecurity issues in P2P systems
*   Network support for P2P systems
*   Fault tolerance in P2P= systems
*   Data structures for P2P systems
*   Efficient = P2P resource lookup and sharing
*   Distributed Hash Tables (DHTs) = and related issues
*   Solutions to topology mismatching for P2P overlays
*   P2P= overlays for NVEs
*   P2P NVE multicast
*   P2P NVE intero= perability
*   P2P NVE content distribution
*   P2P NVE 3D = streaming
*   P2P NVE voice communications
*   P2P NVE architecture designs
*   P2P NVE prototypes
* &= nbsp; P2P NVE consistency control
*   Persistent storage for P2P NV= Es
*   Security and cheat-prevention mechanisms for P2P games
* =   P2P control for mobile NVEs
*   P2P NVE applications on mobile devices

=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IMPORTANT DATES

Submission: &nb= sp;             August 30, 2011 (Firm De= adline)
Notification:           &= nbsp;  September 25, 2011
Camera ready:           October 7, 2011
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

PAPER SUBMISSION
Authors are invited to submit an electronic version of original, unpub= lished manuscripts, not to exceed 8 double-columned, single-spaced pages, t= o the workshop. Submitted papers should be in PDF format in accordance with= IEEE Computer Society guidelines, and will be refereed by reviewers in ter= ms of originality, contribution, correctness, and presentation.

 

 --000e0cd23b9e1a7de704ab921f15-- From stephane.ml.bryant@gmail.com Mon Aug 29 11:04:19 2011 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 6C74121F8C6D for ; Mon, 29 Aug 2011 11:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMpI72sFFK3I for ; Mon, 29 Aug 2011 11:04:18 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id D60BF21F8C73 for ; Mon, 29 Aug 2011 11:04:16 -0700 (PDT) Received: by wwe5 with SMTP id 5so2665332wwe.1 for ; Mon, 29 Aug 2011 11:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=2IclkP1pBiW5EI8HFnNhgMBOZ4xubmu9nXvOjLztnSo=; b=NiikY6hd/SQyZu1H3iqCz01OPoAp6Ap+cPnB7pgPXloZYHRRaBdJiG8IZyvl1F4Whi nMXbczd9jta2siIIy1GwVyQVMGRCtDbg26cGcNfNC7aOKVC7EKZtRvH50RHNgDO7FskL hUwnHl5I3kWRIAs8gYu4qH5l5RQMH7JL3IWt8= Received: by 10.227.207.146 with SMTP id fy18mr3848026wbb.13.1314641141364; Mon, 29 Aug 2011 11:05:41 -0700 (PDT) Received: from ?IPv6:2a01:e35:39c8:8ae0:21d:baff:fef1:8a0e? ([2a01:e35:39c8:8ae0:21d:baff:fef1:8a0e]) by mx.google.com with ESMTPS id eq21sm3940401wbb.35.2011.08.29.11.05.39 (version=SSLv3 cipher=OTHER); Mon, 29 Aug 2011 11:05:39 -0700 (PDT) Sender: stephane bryant Message-ID: <4E5BD4EE.2090909@glycon.org> Date: Mon, 29 Aug 2011 20:05:34 +0200 From: =?ISO-8859-1?Q?st=E9phane_bryant?= Organization: StonyFish, Inc User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Roni Even References: <4E57B94C.50707@glycon.org> <016201cc6411$7d4e3200$77ea9600$%roni@huawei.com> In-Reply-To: <016201cc6411$7d4e3200$77ea9600$%roni@huawei.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: p2psip@ietf.org Subject: Re: [P2PSIP] flag issue in draft-zong-p2psip-drr-00 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, 29 Aug 2011 18:04:19 -0000 Hi Roni, I guess i was not too clear. What i meant is much simpler: RESPONSE_COPY=0x03=FORWARD_CRITICAL(0x1)|DESTINATION_CRITICAL(0x2) Is the flags member defined in ForwardingOptions in section 5.3.2.3 of the draft-ietf-p2psip-base-18 document bit-based or value-based ? From the definitions in the base document (0x1, 0x2, 0x4 are being used), it would seem that it is bit-based. In such a case, the current RESPONSE_COPY value, 0x03, is problematic. stephane On 08/26/2011 06:59 PM, Roni Even wrote: > Hi Stephane, > > This is a good point the DRR draft should specify what is the behavior if > FORWARD_CRITICAL(0x01) or DESTINATION_CRITICAL(0x02) also appears in the > message. I think that the right behavior is to obey the > FORWARD_CRITICAL(0x01)/ DESTINATION_CRITICAL(0x02) defined behavior. > > "If the FORWARD_CRITICAL flag is set, any node that would forward the > message but does not understand this options MUST reject the request with an > error_Unsupported_Forwarding_Option error response. If the > DESTINATION_CRITICAL flag is set, any node that generates a response to the > message but does not understand the forwarding option MUST reject the > request with an Error_Unsupported_Forwarding_Option error response." > > I think that DRR should recommend that the RESPONSE_COPY flag SHOULD be set > to false while the FORWARD_CRITICAL and DESTINATION_CRITICAL SHOULD be set > to true. (This text appeared in > http://tools.ietf.org/html/draft-ietf-p2psip-base-10#page-47 > > Roni Even > >> -----Original Message----- >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On >> Behalf Of st?phane bryant >> Sent: Friday, August 26, 2011 6:19 PM >> To: p2psip@ietf.org >> Subject: [P2PSIP] flag issue in draft-zong-p2psip-drr-00 >> >> Hello, >> >> I am currently working on adding wireshark dissectors >> for the WG drafts, and i stumbled upon an issue >> in draft-zong-p2psip-drr-00: >> >> In section section 6.2.1 (State-keeping Flag) it >> defines the flag: >> flag : 0x3 IGNORE-STATE-KEEPING >> >> However, this flag enters in conflict with 2 >> predefined flags for the ForwardingOption structure: >> FORWARD_CRITICAL(0x01), DESTINATION_CRITICAL(0x02) >> >> (Unless there is a semantic rule linking them, >> implication or mutual exclusion). >> >> As soon as this issue will be cleared, i will >> add the dissector. >> >> Regards, >> Stephane >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > From stephane.ml.bryant@gmail.com Mon Aug 29 11:28:42 2011 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 84C6D21F8CC2 for ; Mon, 29 Aug 2011 11:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wi1jwtFZf7-h for ; Mon, 29 Aug 2011 11:28:42 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A55F521F8CB0 for ; Mon, 29 Aug 2011 11:28:41 -0700 (PDT) Received: by wwf5 with SMTP id 5so3962285wwf.13 for ; Mon, 29 Aug 2011 11:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:x-enigmail-version:content-type:content-transfer-encoding; bh=XHVAvUUIy4IPmSvVPoaREFZ9Q1KzldRDnMvCMin2gf0=; b=UvzSdiR/B7gD01tuXwtgNGN4E/uAiXqQc6npdtxde1WKeqj1zs2YnqlqLgd94Hb2Ff /EZQJATx+NFPYn6hWXcRDxCVJwvkMB/BvokJtCuAkXoZs3Je4tpgO2dLzKZjcEE8ilka VY9m7g3AN+3b0C4GBZI+w7l4qvIZRI/9ki01g= Received: by 10.227.182.8 with SMTP id ca8mr4073579wbb.88.1314642605397; Mon, 29 Aug 2011 11:30:05 -0700 (PDT) Received: from ?IPv6:2a01:e35:39c8:8ae0:21d:baff:fef1:8a0e? ([2a01:e35:39c8:8ae0:21d:baff:fef1:8a0e]) by mx.google.com with ESMTPS id ew4sm3959174wbb.8.2011.08.29.11.30.03 (version=SSLv3 cipher=OTHER); Mon, 29 Aug 2011 11:30:03 -0700 (PDT) Sender: stephane bryant Message-ID: <4E5BDA64.8040104@glycon.org> Date: Mon, 29 Aug 2011 20:28:52 +0200 From: =?ISO-8859-1?Q?st=E9phane_bryant?= Organization: StonyFish, Inc User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: p2psip@ietf.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] message extensions/forwarding options code conflicts 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, 29 Aug 2011 18:28:42 -0000 Hello, *the extension exp-ext (draft-ietf-p2psip-base-18, section 13.14), draft-ietf-p2psip-self-tuning-04 (draft-ietf-p2psip-self-tuning-04, section 9,1), Diagnostic_Ping (draft-ietf-p2psip-diagnostics-06) all share the same code (0x1). *the options exp-forward (draft-ietf-p2psip-base-18, section 13.12) and extensive_routing_mode (draft-zong-p2psip-drr, section 9) also shared the same type: 0x1 regards stephane bryant From Even.roni@huawei.com Mon Aug 29 12:32:55 2011 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 711E121F8CFC for ; Mon, 29 Aug 2011 12:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.903 X-Spam-Level: X-Spam-Status: No, score=-105.903 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lilf4LYAr7xG for ; Mon, 29 Aug 2011 12:32:54 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9951221F8CEE for ; Mon, 29 Aug 2011 12:32:54 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQP00GE9FP6NJ@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 30 Aug 2011 03:34:18 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQP009JTFP6VW@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 30 Aug 2011 03:34:18 +0800 (CST) Received: from windows8d787f9 (bzq-109-64-200-234.red.bezeqint.net [109.64.200.234]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LQP00CCWFP0M4@szxml12-in.huawei.com>; Tue, 30 Aug 2011 03:34:18 +0800 (CST) Date: Mon, 29 Aug 2011 22:32:53 +0300 From: Roni Even In-reply-to: <4E5BD4EE.2090909@glycon.org> To: =?ISO-8859-1?Q?'st=E9phane_bryant'?= Message-id: <030701cc6682$765d9d50$6318d7f0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=ISO-8859-1 Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcxmdkeUPbCY/u2/SvuPORi4dyZY+gAC2rtA References: <4E57B94C.50707@glycon.org> <016201cc6411$7d4e3200$77ea9600$%roni@huawei.com> <4E5BD4EE.2090909@glycon.org> Cc: p2psip@ietf.org Subject: Re: [P2PSIP] flag issue in draft-zong-p2psip-drr-00 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, 29 Aug 2011 19:32:55 -0000 Hi Stephane, Thanks, I assume that it was meant to be bit-based. I looked again at the document It should be defined as 0x8. I also stated that we need to have the FORWARD_CRITICAL and DESTINATION_CRITICAL set to true, but this is not requited since the node information of the source to where the response should go is in the forwarding option. So we just need to change the flag to 0x8 Roni > -----Original Message----- > From: stephane bryant [mailto:stephane.ml.bryant@gmail.com] On Behalf > Of st?phane bryant > Sent: Monday, August 29, 2011 9:06 PM > To: Roni Even > Cc: p2psip@ietf.org; 'Ning Zong' > Subject: Re: [P2PSIP] flag issue in draft-zong-p2psip-drr-00 > > Hi Roni, > > I guess i was not too clear. What i meant is much simpler: > > RESPONSE_COPY=0x03=FORWARD_CRITICAL(0x1)|DESTINATION_CRITICAL(0x2) > > Is the flags member defined in ForwardingOptions in section > 5.3.2.3 of the draft-ietf-p2psip-base-18 document > bit-based or value-based ? From the definitions in the base > document (0x1, 0x2, 0x4 are being used), it would seem > that it is bit-based. > In such a case, the current RESPONSE_COPY value, 0x03, is problematic. > > stephane > > > > On 08/26/2011 06:59 PM, Roni Even wrote: > > Hi Stephane, > > > > This is a good point the DRR draft should specify what is the > behavior if > > FORWARD_CRITICAL(0x01) or DESTINATION_CRITICAL(0x02) also appears > in the > > message. I think that the right behavior is to obey the > > FORWARD_CRITICAL(0x01)/ DESTINATION_CRITICAL(0x02) defined behavior. > > > > "If the FORWARD_CRITICAL flag is set, any node that would forward the > > message but does not understand this options MUST reject the request > with an > > error_Unsupported_Forwarding_Option error response. If the > > DESTINATION_CRITICAL flag is set, any node that generates a response > to the > > message but does not understand the forwarding option MUST reject the > > request with an Error_Unsupported_Forwarding_Option error response." > > > > I think that DRR should recommend that the RESPONSE_COPY flag SHOULD > be set > > to false while the FORWARD_CRITICAL and DESTINATION_CRITICAL SHOULD > be set > > to true. (This text appeared in > > http://tools.ietf.org/html/draft-ietf-p2psip-base-10#page-47 > > > > Roni Even > > > >> -----Original Message----- > >> From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > >> Behalf Of st?phane bryant > >> Sent: Friday, August 26, 2011 6:19 PM > >> To: p2psip@ietf.org > >> Subject: [P2PSIP] flag issue in draft-zong-p2psip-drr-00 > >> > >> Hello, > >> > >> I am currently working on adding wireshark dissectors > >> for the WG drafts, and i stumbled upon an issue > >> in draft-zong-p2psip-drr-00: > >> > >> In section section 6.2.1 (State-keeping Flag) it > >> defines the flag: > >> flag : 0x3 IGNORE-STATE-KEEPING > >> > >> However, this flag enters in conflict with 2 > >> predefined flags for the ForwardingOption structure: > >> FORWARD_CRITICAL(0x01), DESTINATION_CRITICAL(0x02) > >> > >> (Unless there is a semantic rule linking them, > >> implication or mutual exclusion). > >> > >> As soon as this issue will be cleared, i will > >> add the dissector. > >> > >> Regards, > >> Stephane > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www.ietf.org/mailman/listinfo/p2psip > > > > From stephane.ml.bryant@gmail.com Wed Aug 31 00:45:05 2011 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 195F521F8C6F for ; Wed, 31 Aug 2011 00:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaH5a0TPcJBg for ; Wed, 31 Aug 2011 00:45:04 -0700 (PDT) Received: from mail-ey0-f174.google.com (mail-ey0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id DDC0821F8C58 for ; Wed, 31 Aug 2011 00:45:03 -0700 (PDT) Received: by eyx24 with SMTP id 24so332508eyx.19 for ; Wed, 31 Aug 2011 00:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:x-enigmail-version:content-type:content-transfer-encoding; bh=7EBL4HRovYP1UYwPQoMbNFUGBbVX/kSfRBJ9ctjkqwk=; b=PNXjf6FrLcboLlglnv99/dTOKFrfCNxMyHdfaGltR/uI0RJvIU6bzPeo0B1akBX7Yh 5nrITGK3if0aKVGKFevyNZYhYOPbmSoc98fYSB844tBnZat5MHe9rTmgvlq+hTnFDjJh 8SUwuJvzviegsr4Y3ZWETZNkkY3b6V+x3dTFM= Received: by 10.14.23.211 with SMTP id v59mr52917eev.192.1314776792840; Wed, 31 Aug 2011 00:46:32 -0700 (PDT) Received: from ?IPv6:2a01:e35:39c8:8ae0:21d:baff:fef1:8a0e? ([2a01:e35:39c8:8ae0:21d:baff:fef1:8a0e]) by mx.google.com with ESMTPS id a53sm4357534eeb.62.2011.08.31.00.46.31 (version=SSLv3 cipher=OTHER); Wed, 31 Aug 2011 00:46:31 -0700 (PDT) Sender: stephane bryant Message-ID: <4E5DE6D1.3070702@glycon.org> Date: Wed, 31 Aug 2011 09:46:25 +0200 From: =?ISO-8859-1?Q?st=E9phane_bryant?= Organization: StonyFish, Inc User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: p2psip@ietf.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] structure definition issue in draft-zong-p2psip-drr-00 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, 31 Aug 2011 07:45:05 -0000 Hello, In draft-zong-p2psip-drr-00, section 6.2.2. Extensive Routing Mode, the ExtensiveRoutingModeOption structure is defined thus: struct { RouteMode routemode; OverlayLink transport; IpAddressPort ipaddressport; Destination destination<1..2>; } ExtensiveRoutingModeOption; however the convention for variable length fields is designed to represent the length in bytes of the field, the range allowing to also derive the size of the length field. <1..2> does not work. My take is that it should be <0...2^16>. I am currently adding new parsing capabilities to the wireshark dissector: as soon as this is defined i will add capabilities for this draft. regards stephane bryant