From petithug@acm.org Mon Jun 6 18:32: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 0173611E8096; Mon, 6 Jun 2011 18:32:01 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgDaLp-qFuT2; Mon, 6 Jun 2011 18:32:00 -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 79FE011E8090; Mon, 6 Jun 2011 18:31:56 -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 708D02218B; Tue, 7 Jun 2011 03:31:11 +0200 (CEST) Message-ID: <4DED7F87.2090305@acm.org> Date: Mon, 06 Jun 2011 18:31:51 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110510 Iceowl/1.0b2 Icedove/3.1.10 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 Cc: "vipr@ietf.org" Subject: [P2PSIP] Quotas X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 01:32:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Now that version -15 of RELOAD is out, I am able to restart editing draft-petithuguenin-vipr-reload-usage which is, as its name indicates, a RELOAD usage for VIPR. Most of it can now be implemented with standard RELOAD, excepted for one thing, the quota algorithm. The quota algorithm in VIPR is interesting because it looks like it can be applied to other resources than the one handled by VIPR. This quota works by using a variable that limits, at a responsible peer, the number of resources that can be stored by one storing peer. More precisely, the number of unique resource (of one kind) that a storing node can store in one responsible peer is the quota value divided by the fraction of resources this peer is responsible for (adjusted for the number of replicas and other parameters, but let's forget this for now). The two standard quota parameters in RELOAD only limit the absolute number and or size of the resources that can be stored. The ideal would be to add the VIPR quota inside the RELOAD base spec. Having stuff in base is good because in this case any RELOAD implementation could be used for VIPR (or any other overlay), and - in my opinion - having multiple implementations of RELOAD inside one overlay is what will help an overlay to survive a programmer error. Now I would agree that we should stop adding stuff to base, to have a chance to see it published as an RFC one day, so perhaps an alternative idea is to do the same thing for quotas that I did for access control policy: Use a script in the configuration file to express the quota algorithm associated to a specific Kind-ID. Is there any opinions or questions or comments on this? Note that this email is cross posted with the VIPR working group, but please follow up only in P2PSIP. Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3tf4UACgkQ9RoMZyVa61f0LwCgm4OkWYDf46pZ7GjfPfu93BBJ NcUAnAtLP1kTvzZ51F9jTucTUcTp6f9Y =kM4T -----END PGP SIGNATURE----- From davidbryan@gmail.com Wed Jun 8 09:48:11 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 6A28911E8116 for ; Wed, 8 Jun 2011 09:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4cYxrIteCrj for ; Wed, 8 Jun 2011 09:48:10 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CBC4B228004 for ; Wed, 8 Jun 2011 09:48:09 -0700 (PDT) Received: by wyb29 with SMTP id 29so580917wyb.31 for ; Wed, 08 Jun 2011 09:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type; bh=6+PXgaApVpkf1c6WUtHyAbxalP38bInr4kwM0gY1SFo=; b=hRBHUcyMmW9o/lITElc7O+OG04G2gUZIbN7i01l8H9MS8S2TUpIRw6g4x9FCJUUnLn JoITo0mErN7jrokVutMmxh8nzJYokzcICOLL55snr78nT0xTM0BVZV9T5mQP36/1xgs3 HnnyOBddH4Dn35JgVldAlkMqFc9Ng+H7prdVs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=xpe30KF6tZ02vEiYjb2E9LYCE8+mbWPEURDvwlmJE7yGIkj9c0ajfNf2qEH2J97PmX WSQxowgGdENsBFDdK2kxdKk5o3Rmi0N30moWswSOIHnA9ImUIwFGWYuP7xKa0+KAd/8M v7f58yVgssO9SVSXQphE/6LNJyx/gMqlqu4+Y= MIME-Version: 1.0 Received: by 10.227.202.205 with SMTP id ff13mr7979360wbb.102.1307551688909; Wed, 08 Jun 2011 09:48:08 -0700 (PDT) Sender: davidbryan@gmail.com Received: by 10.227.203.149 with HTTP; Wed, 8 Jun 2011 09:48:08 -0700 (PDT) Date: Wed, 8 Jun 2011 09:48:08 -0700 X-Google-Sender-Auth: pkY2_2kKpUPtoGmnpUBEyVtegzo Message-ID: From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-p2psip-base@tools.ietf.org Subject: [P2PSIP] draft-ietf-p2psip-base publication to be requested 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, 08 Jun 2011 16:48:11 -0000 Unless something major comes up, we plan to request the newest version of the base draft, draft-ietf-p2psip-base-15, be published. I'll put in the request in a week (June 16th or 17th). If there are any further comments from the last call a while ago (or further comments on the comments since then), please send them to the list ASAP. Thanks, David (as chair) From petithug@acm.org Wed Jun 8 12:14: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 AF9E811E8181 for ; Wed, 8 Jun 2011 12:14:07 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSfGa9QDvuoc for ; Wed, 8 Jun 2011 12:14: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 CD96511E8174 for ; Wed, 8 Jun 2011 12:14:06 -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 7ADB52218B; Wed, 8 Jun 2011 21:13:12 +0200 (CEST) Message-ID: <4DEFC9F8.2090609@acm.org> Date: Wed, 08 Jun 2011 12:14:00 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110606 Iceowl/1.0b2 Icedove/3.1.10 MIME-Version: 1.0 To: "David A. Bryan" References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP WG , draft-ietf-p2psip-base@tools.ietf.org Subject: Re: [P2PSIP] draft-ietf-p2psip-base publication to be requested 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, 08 Jun 2011 19:14:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/08/2011 09:48 AM, David A. Bryan wrote: > Unless something major comes up, we plan to request the newest version > of the base draft, draft-ietf-p2psip-base-15, be published. I'll put > in the request in a week (June 16th or 17th). If there are any further > comments from the last call a while ago (or further comments on the > comments since then), please send them to the list ASAP. draft-ietf-p2psip-base-15 fixes all the interoperability issues I found so far, so as far as I am concerned, this version can be published. - -- 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) iEUEARECAAYFAk3vye0ACgkQ9RoMZyVa61fuggCXUqycC43ou0KtNmfe4Ra2KcoU gACdGjILsMXbQRwMQHrQohxk0RTCTcs= =WmNC -----END PGP SIGNATURE----- From petithug@acm.org Wed Jun 8 12:22: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 6BEC911E8174 for ; Wed, 8 Jun 2011 12:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.954 X-Spam-Level: X-Spam-Status: No, score=-101.954 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsIt+5oDGsdI for ; Wed, 8 Jun 2011 12:22: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 B4DC111E8100 for ; Wed, 8 Jun 2011 12:22: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 6AA062218B for ; Wed, 8 Jun 2011 21:22:01 +0200 (CEST) Message-ID: <4DEFCC09.5030007@acm.org> Date: Wed, 08 Jun 2011 12:22:49 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110606 Iceowl/1.0b2 Icedove/3.1.10 MIME-Version: 1.0 CC: p2psip@ietf.org References: <20110528033710.12537.76625.idtracker@ietfa.amsl.com> In-Reply-To: <20110528033710.12537.76625.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] RELOAD support in Wireshark 1.6 [was Re: I-D Action: draft-ietf-p2psip-base-15.txt] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 19:22:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI, version 1.6.0 of Wireshark was released yesterday, with support for RELOAD up to -15. This is a stable version so hopefully this will simplify and accelerate the implementation and deployment of RELOAD. On 05/27/2011 08:37 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. > > Title : 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-15.txt > Pages : 160 > Date : 2011-05-27 > > 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. - -- 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) iEYEARECAAYFAk3vzAgACgkQ9RoMZyVa61fsvACgnyEAQkegmAGyFzGvUIpfoy+f 5wgAoJ+lwiyQzv3qZnUYPxpCrkv/A5gG =gRdu -----END PGP SIGNATURE----- From fluffy@cisco.com Wed Jun 8 13:32: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 C1DAC11E80DA for ; Wed, 8 Jun 2011 13:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 9-9PCTHW5Weu for ; Wed, 8 Jun 2011 13:32:52 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id EE23511E80CE for ; Wed, 8 Jun 2011 13:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=781; q=dns/txt; s=iport; t=1307565171; x=1308774771; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=yOv5Wt3Q6wY77mclGdB8RfI7GwXkqrNdUioeSWWH3XQ=; b=P2v1iFYCa7LkEwB8IGGr6DFsOWOfkSIG8d3+cl70yBmQyIZf/IMkeWGV n3qx3ntlfcwZKGB4THDlnUrNtLKCDg425ucVGIL8I+mpLoeSrjPPTER/O NYUry2ozHFlGDszX4wKxifga7eG2jlBz223droxM/DIF176dGa/ESAxJ5 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACbc702rRDoI/2dsb2JhbABTpjV3iHGgOp11hiMEhn+KHIRNix0 X-IronPort-AV: E=Sophos;i="4.65,339,1304294400"; d="scan'208";a="333005235" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 08 Jun 2011 20:32:51 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p58KWoNZ016098; Wed, 8 Jun 2011 20:32:50 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 8 Jun 2011 14:32:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9D79F577-0906-46FE-9004-9249375C55C2@cisco.com> References: To: "David A. Bryan" X-Mailer: Apple Mail (2.1084) Cc: P2PSIP WG , draft-ietf-p2psip-base@tools.ietf.org Subject: Re: [P2PSIP] draft-ietf-p2psip-base publication to be requested 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, 08 Jun 2011 20:32:52 -0000 I think it is ready to be sent to IESG. There may be some trivial tweaks = to the IANA registration for the xml config file but that can easily = handled as part of IESG processing.=20 On Jun 8, 2011, at 10:48 AM, David A. Bryan wrote: > Unless something major comes up, we plan to request the newest version > of the base draft, draft-ietf-p2psip-base-15, be published. I'll put > in the request in a week (June 16th or 17th). If there are any further > comments from the last call a while ago (or further comments on the > comments since then), please send them to the list ASAP. >=20 > Thanks, >=20 > David (as chair) > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From loopp2psip@gmail.com Thu Jun 9 07:44:25 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 04AFA21F8482 for ; Thu, 9 Jun 2011 07:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ta+ewlgmkH7F for ; Thu, 9 Jun 2011 07:44:24 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 26F1421F847C for ; Thu, 9 Jun 2011 07:44:23 -0700 (PDT) Received: by wyb29 with SMTP id 29so1331523wyb.31 for ; Thu, 09 Jun 2011 07:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:from:to:cc:in-reply-to:references :content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=E9RyZYUILTpdFqJFxdqHaPNCID7/uW3KjSwdGIvfJcQ=; b=wpkjiZwBgrheRpIZWlQEsczlXmjPpugxjRS2XoHdMySnOhq9ZFZnUV7n1prevuiWen vjjNUwMTe7l89ZekH4F0hbQfMsrYK7eW6pY/a1dBoZrK93SQ3qWDZGokTglkNCJSYUwI 8ZbIUt1LWVLqCmyo4FD8HXpsK4ialfJ63U9pg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=cQiHtrjYk4SX7P+YCSMiHD6ZN1ZB0qzXDfAjJOVhF4D1eD+R8aPp1SO8EHvHp3jOM3 b9zaUkvhZQ4sirYZYsgvSLbJRhNwBIt7NFMV+tE0+WKj1U1eXhxdT33NgK5aSriVDwho FjGtAV2otrXAEcnHajJ5P3d22M0yQ5tQtXCko= Received: by 10.227.200.210 with SMTP id ex18mr937286wbb.7.1307630658612; Thu, 09 Jun 2011 07:44:18 -0700 (PDT) Received: from [163.117.205.20] ([163.117.205.20]) by mx.google.com with ESMTPS id c17sm1278963wbh.12.2011.06.09.07.44.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Jun 2011 07:44:14 -0700 (PDT) From: Diego Suarez To: "David A. Bryan" In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Thu, 09 Jun 2011 16:31:18 +0200 Message-ID: <1307629878.30919.87.camel@toedo> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: P2PSIP WG , draft-ietf-p2psip-base@tools.ietf.org Subject: Re: [P2PSIP] draft-ietf-p2psip-base publication to be requested 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, 09 Jun 2011 14:44:25 -0000 Hi, I had in mind writing a draft about this, but since I'm running out of time, I would like to summarize a new certification model for P2PSIP I have been working on, in case it is of interest for the group. Further details can be found in paper: D. Touceda, J. Camara, L. Villalba, and J. Marquez, “Advantages of identity certificate segregation in P2PSIP systems,” Communications, IET, vol. 5, pp. 879–889, Apr. 2011. The idea is to split the certification of users and devices. Devices are identified by PKCs including a nodeID and the PK of the device, while users are identified by PKCs including a username and the PK of the user. Similar models have been used before in other communications systems, such as GSM where devices and users are separately represented by the international mobile equipment identity (IMEI) stored in the phones and the international mobile subscriber identity (IMSI) stored in the user subscriber identity module (SIM), respectively. Motivations of this model are: - Users and devices are different entities performing different roles within a P2PSIP system. Devices are nodes of the P2P overlay network (represented by a nodeID) that offer services (to route messages, to store data, . . .) to the system, while users (represented by an username) utilize these services, usually to establish media communications using SIP. - Support for mobility scenarios where a user may be logged at different devices at the same time using the same PKC. - Support several users to be logged in the same device (like a fixed phone) at the same time. - Support for user independent hard-coded devices. - Interoperability with SIP. SIP certificates are not valid in actual P2PSIP since they don't include a nodeID. cheers Diego Suárez On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote: > Unless something major comes up, we plan to request the newest version > of the base draft, draft-ietf-p2psip-base-15, be published. I'll put > in the request in a week (June 16th or 17th). If there are any further > comments from the last call a while ago (or further comments on the > comments since then), please send them to the list ASAP. > > Thanks, > > David (as chair) > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Thu Jun 9 08:27:12 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 8132F11E80FD; Thu, 9 Jun 2011 08:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 01U5T53luHMz; Thu, 9 Jun 2011 08:27:10 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id B2EA711E80DD; Thu, 9 Jun 2011 08:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3081; q=dns/txt; s=iport; t=1307633230; x=1308842830; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=n+ZBe5DyuLrUjgA5N2VL5JncwrVDtgKWROBpU1V9lLY=; b=TNqZe8KeYpsvyYMX2wAaMzrxISWLlV59BatqcPLfH7IE6ZQNDZrJlnzV lfiZgfWjpMt5pTjFkjqH0z3wGQTLOUFgjcHcSYKy6xXFKv0TQx0IdU6bj hYhOghsoBKz2bP/3h5OoxBWZejL/xW9a5keC080kqjAZbLS6Sg9FvE9z6 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOfl8E2rRDoI/2dsb2JhbABTpjt3qheeH4MdgwYEhwiKIoRNiyQ X-IronPort-AV: E=Sophos;i="4.65,341,1304294400"; d="scan'208";a="462702680" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 09 Jun 2011 15:26:33 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p59FQWbA027977; Thu, 9 Jun 2011 15:26:32 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4DED7F87.2090305@acm.org> Date: Thu, 9 Jun 2011 09:26:32 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3B9C94BB-EA37-4BD3-A4CA-267FC86B4277@cisco.com> References: <4DED7F87.2090305@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: "vipr@ietf.org" , P2PSIP Mailing List Subject: Re: [P2PSIP] [VIPR] Quotas 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, 09 Jun 2011 15:27:12 -0000 I can't put my finger on why, but I get very nervous about suing = downloadable scripts to enforce critical system constraints such as = security and quotas. It just seems like a disaster waiting to happen. = That said, I can't come up with any specific problem of why it would not = work but it makes me feel very uneasy.=20 It does seems reasonable to make this type of quota a general purpose = extension to reload that could be used by things beyond vipr WG stuff.=20= On Jun 6, 2011, at 7:31 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Now that version -15 of RELOAD is out, I am able to restart editing > draft-petithuguenin-vipr-reload-usage which is, as its name indicates, = a RELOAD > usage for VIPR. Most of it can now be implemented with standard = RELOAD, > excepted for one thing, the quota algorithm. >=20 > The quota algorithm in VIPR is interesting because it looks like it = can be > applied to other resources than the one handled by VIPR. This quota = works by > using a variable that limits, at a responsible peer, the number of = resources > that can be stored by one storing peer. More precisely, the number of = unique > resource (of one kind) that a storing node can store in one = responsible peer is > the quota value divided by the fraction of resources this peer is = responsible > for (adjusted for the number of replicas and other parameters, but = let's forget > this for now). The two standard quota parameters in RELOAD only limit = the > absolute number and or size of the resources that can be stored. >=20 > The ideal would be to add the VIPR quota inside the RELOAD base spec. = Having > stuff in base is good because in this case any RELOAD implementation = could be > used for VIPR (or any other overlay), and - in my opinion - having = multiple > implementations of RELOAD inside one overlay is what will help an = overlay to > survive a programmer error. >=20 > Now I would agree that we should stop adding stuff to base, to have a = chance to > see it published as an RFC one day, so perhaps an alternative idea is = to do the > same thing for quotas that I did for access control policy: Use a = script in the > configuration file to express the quota algorithm associated to a = specific Kind-ID. >=20 > Is there any opinions or questions or comments on this? >=20 > Note that this email is cross posted with the VIPR working group, but = please > follow up only in P2PSIP. >=20 > Thanks. >=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 > iEYEARECAAYFAk3tf4UACgkQ9RoMZyVa61f0LwCgm4OkWYDf46pZ7GjfPfu93BBJ > NcUAnAtLP1kTvzZ51F9jTucTUcTp6f9Y > =3DkM4T > -----END PGP SIGNATURE----- > _______________________________________________ > VIPR mailing list > VIPR@ietf.org > https://www.ietf.org/mailman/listinfo/vipr From petithug@acm.org Thu Jun 9 08:48:50 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 50F9311E811B; Thu, 9 Jun 2011 08:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.385 X-Spam-Level: X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfUbe31oPHvz; Thu, 9 Jun 2011 08:48: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 68D9C11E811A; Thu, 9 Jun 2011 08:48: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 21F432218B; Thu, 9 Jun 2011 17:47:52 +0200 (CEST) Message-ID: <4DF0EB5A.5070400@acm.org> Date: Thu, 09 Jun 2011 08:48:42 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110606 Iceowl/1.0b2 Icedove/3.1.10 MIME-Version: 1.0 To: Cullen Jennings References: <4DED7F87.2090305@acm.org> <3B9C94BB-EA37-4BD3-A4CA-267FC86B4277@cisco.com> In-Reply-To: <3B9C94BB-EA37-4BD3-A4CA-267FC86B4277@cisco.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" , P2PSIP Mailing List Subject: Re: [P2PSIP] [VIPR] Quotas 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, 09 Jun 2011 15:48:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/09/2011 08:26 AM, Cullen Jennings wrote: > > I can't put my finger on why, but I get very nervous about suing downloadable scripts to enforce critical system constraints such as security and quotas. It just seems like a disaster waiting to happen. That said, I can't come up with any specific problem of why it would not work but it makes me feel very uneasy. I'll post a separate response on this, in p2psip only. > > It does seems reasonable to make this type of quota a general purpose extension to reload that could be used by things beyond vipr WG stuff. OK, so I'll split the quota algorithm in a separate draft (in the P2PSIP WG) with the same authors list. > > On Jun 6, 2011, at 7:31 PM, Marc Petit-Huguenin wrote: > > Now that version -15 of RELOAD is out, I am able to restart editing > draft-petithuguenin-vipr-reload-usage which is, as its name indicates, a RELOAD > usage for VIPR. Most of it can now be implemented with standard RELOAD, > excepted for one thing, the quota algorithm. > > The quota algorithm in VIPR is interesting because it looks like it can be > applied to other resources than the one handled by VIPR. This quota works by > using a variable that limits, at a responsible peer, the number of resources > that can be stored by one storing peer. More precisely, the number of unique > resource (of one kind) that a storing node can store in one responsible peer is > the quota value divided by the fraction of resources this peer is responsible > for (adjusted for the number of replicas and other parameters, but let's forget > this for now). The two standard quota parameters in RELOAD only limit the > absolute number and or size of the resources that can be stored. > > The ideal would be to add the VIPR quota inside the RELOAD base spec. Having > stuff in base is good because in this case any RELOAD implementation could be > used for VIPR (or any other overlay), and - in my opinion - having multiple > implementations of RELOAD inside one overlay is what will help an overlay to > survive a programmer error. > > Now I would agree that we should stop adding stuff to base, to have a chance to > see it published as an RFC one day, so perhaps an alternative idea is to do the > same thing for quotas that I did for access control policy: Use a script in the > configuration file to express the quota algorithm associated to a specific Kind-ID. > > Is there any opinions or questions or comments on this? > > Note that this email is cross posted with the VIPR working group, but please > follow up only in P2PSIP. - -- 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) iEYEARECAAYFAk3w61kACgkQ9RoMZyVa61cWowCgg9lHq4xRrcdch0PsW2NLmPAI 4dEAn33neMRjBy69CjoG5rD+vQBAuFul =SW6+ -----END PGP SIGNATURE----- From petithug@acm.org Thu Jun 9 09:49: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 ECAF111E8113 for ; Thu, 9 Jun 2011 09:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoHTZgrnty7f for ; Thu, 9 Jun 2011 09:49:08 -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 2AFC011E8178 for ; Thu, 9 Jun 2011 09:49:03 -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 DA17A2218B; Thu, 9 Jun 2011 18:48:08 +0200 (CEST) Message-ID: <4DF0F97C.6010209@acm.org> Date: Thu, 09 Jun 2011 09:49:00 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110606 Iceowl/1.0b2 Icedove/3.1.10 MIME-Version: 1.0 To: Cullen Jennings References: <4DED7F87.2090305@acm.org> <3B9C94BB-EA37-4BD3-A4CA-267FC86B4277@cisco.com> In-Reply-To: <3B9C94BB-EA37-4BD3-A4CA-267FC86B4277@cisco.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] [VIPR] Quotas 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, 09 Jun 2011 16:49:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/09/2011 08:26 AM, Cullen Jennings wrote: > > I can't put my finger on why, but I get very nervous about suing downloadable > scripts to enforce critical system constraints such as security and quotas. > It just seems like a disaster waiting to happen. That said, I can't come up > with any specific problem of why it would not work but it makes me feel very > uneasy. Here's what makes me nervous about this mechanism (and the ideas on this text will probably go into the security section in the next version of draft-petithuguenin-p2psip-access-control): Having a script in the configuration file is - in my opinion - not a security problem by itself. After all the configuration file is written by the same entity that will sign it and as long as the implementer follows the rules in the draft (no side effect when modifying the parameters, only base classes of ECMAScript implemented, etc...), this should not be a problem. It is even possible to deal with less than perfect implementations, as long as they do not accept a configuration file that is not signed correctly - for example the signer can have an active role, by deliberately sending in a ConfigUpdate an incorrectly signed version of the configuration file and blacklisting all the nodes that accepted it in a newly issued configuration file. One of the problems was presented at the mike in Prague by EKR[1]: Because now we have code inside the configuration file and because there is no way to find if this code will eventually stop executing in a reasonable time, we need to put a limit on the CPU used. Note that this is not so much for programming errors but because the set of possible inputs is very large there is no way to test them all. For example, an implementation written in java could be stuck in an infinite loop when using 2.2250738585072012e-308[2] in the Javascript code. Another problem that is not as easy to fix is that having a script in the configuration file introduces a single point of failure. One of the great thing about RELOAD is that it gives a way to design systems that can resist programmer's errors. Programmers make errors and - we had some examples of that recently - these errors can have huge impact. One way to mitigate that is to have multiple, separate, implementations of the same product, to have all of them running in parallel and use one of the implementations that behaves correctly. That is obviously extremely costly and is generally reserved to systems where life can be endangered by a software bug. What RELOAD brings to the table is a less expensive way to do the same thing. If an overlay is running on 4 or 5 different implementations, running on different OS and on different places, then the probability of losing it completely will be infinitesimal. If each implementation is coding the access control policy, then we still limit a coding bug to this implementation, but when the code itself is in the configuration, then an coding bug will impact all the implementations. And that is what make me nervous about this. [1] http://www.ietf.org/proceedings/80/minutes/p2psip.txt [2] http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/ - -- 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) iEYEARECAAYFAk3w+XoACgkQ9RoMZyVa61fNfQCeNWVTydHY4c/9v2wJEAABoi3S rm0AnRshgVFaXz0W/halRU+OXQzg7uPw =d/XW -----END PGP SIGNATURE----- From petithug@acm.org Thu Jun 9 10:05:18 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 59CBB11E81C4 for ; Thu, 9 Jun 2011 10:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWjyv7QXHssZ for ; Thu, 9 Jun 2011 10:05:17 -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 2103D11E8180 for ; Thu, 9 Jun 2011 10:05:17 -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 6BC132218B; Thu, 9 Jun 2011 19:04:22 +0200 (CEST) Message-ID: <4DF0FD49.3020505@acm.org> Date: Thu, 09 Jun 2011 10:05:13 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110606 Iceowl/1.0b2 Icedove/3.1.10 MIME-Version: 1.0 To: Diego Suarez References: <1307629878.30919.87.camel@toedo> In-Reply-To: <1307629878.30919.87.camel@toedo> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: P2PSIP WG Subject: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested] 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, 09 Jun 2011 17:05:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does this model really required modifications in the base document, or can it be designed as an extension? (Unfortunately the paper is not freely available, so it is difficult to know really what is needed for this). On 06/09/2011 07:31 AM, Diego Suarez wrote: > Hi, > > I had in mind writing a draft about this, but since I'm running out of > time, I would like to summarize a new certification model for P2PSIP I > have been working on, in case it is of interest for the group. > Further details can be found in paper: > > D. Touceda, J. Camara, L. Villalba, and J. Marquez, “Advantages of > identity certificate segregation in P2PSIP systems,” Communications, > IET, vol. 5, pp. 879–889, Apr. 2011. > > > The idea is to split the certification of users and devices. Devices are > identified by PKCs including a nodeID and the PK of the device, while > users are identified by PKCs including a username and the PK of the > user. Similar models have been used before in other communications > systems, such as GSM where devices and users are separately represented > by the international mobile equipment identity (IMEI) stored in the > phones and the international mobile subscriber identity (IMSI) stored in > the user subscriber identity module (SIM), respectively. > > Motivations of this model are: > > - Users and devices are different entities performing different > roles within a P2PSIP system. Devices are nodes of the P2P > overlay network (represented by a nodeID) that offer services > (to route messages, to store data, . . .) to the system, while > users (represented by an username) utilize these services, > usually to establish media communications using SIP. > > - Support for mobility scenarios where a user may be logged at different > devices at the same time using the same PKC. > > - Support several users to be logged in the same device (like a fixed > phone) at the same time. > > - Support for user independent hard-coded devices. > > - Interoperability with SIP. SIP certificates are not valid in actual > P2PSIP since they don't include a nodeID. > > cheers > > Diego Suárez > > > On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote: >> Unless something major comes up, we plan to request the newest version >> of the base draft, draft-ietf-p2psip-base-15, be published. I'll put >> in the request in a week (June 16th or 17th). If there are any further >> comments from the last call a while ago (or further comments on the >> comments since then), please send them to the list ASAP. >> >> Thanks, >> >> David (as chair) >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip - -- Marc Petit-Huguenin 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) iEYEARECAAYFAk3w/UMACgkQ9RoMZyVa61ctqACfTdnpLBUDY3GqmcHvcT41ncRS 3r0An3YjUnCnMv4Rg/a91pra/xZFiGj6 =NiCK -----END PGP SIGNATURE----- From loopp2psip@gmail.com Thu Jun 9 10:47: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 1DA6E11E80BB for ; Thu, 9 Jun 2011 10:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nJhWfL0CCSv for ; Thu, 9 Jun 2011 10:47:41 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BD8E411E80BA for ; Thu, 9 Jun 2011 10:47:40 -0700 (PDT) Received: by wyb29 with SMTP id 29so1473916wyb.31 for ; Thu, 09 Jun 2011 10:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:from:to:cc:in-reply-to:references :content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=htq8zfkoX2+ZVqTllZHlFhU/HK04ibGtbvb5G5xvJ7M=; b=URMdJd1RGINYgCGoXe5EeYNjkkAjMUd3tpwTMnxYO94odoRXCrxBkcS17h2MYmCDte DcsQ2z1e3JGU6ouX3f4ENzXK4M080xovVeM+hSQ4/Np2j+YzSkfPKvzdx8wurXvvPUW/ pHc588mZRWk+EORcsxAm65TyVIcnL67bJhoUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=fEI+IMt3cumI2vU+dD2/SRazZSL4gw/jShfP+dm1zKQ72XeTNmJSdnwbu5tP8lZbCc P+6EJ9M5N8CMvIZHCmouYYgvbyEjAK8V/j8/dCk4vrNjQjf07OoxnF3t4Fb7HK8hsA+C Ez++Yu7t3g1mzCtO6O5NPP+zC5zZPnKgiRp7E= Received: by 10.216.69.7 with SMTP id m7mr1101865wed.46.1307641659607; Thu, 09 Jun 2011 10:47:39 -0700 (PDT) Received: from [192.168.1.3] (164.2.20.95.dynamic.jazztel.es [95.20.2.164]) by mx.google.com with ESMTPS id f73sm975633wef.43.2011.06.09.10.47.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Jun 2011 10:47:38 -0700 (PDT) From: Diego Suarez To: Marc Petit-Huguenin In-Reply-To: <4DF0FD49.3020505@acm.org> References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 09 Jun 2011 19:47:29 +0200 Message-ID: <1307641649.5184.17.camel@santeles> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested] 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, 09 Jun 2011 17:47:42 -0000 I think it would require a (slight) modification in the base document. Current P2PSIP certification model is based on a single PKC (including both usernames and nodeIDs) that uniquely identifies a user and her devices. On the other hand, our model is base on a split certification. Devices and users are independent. Each device has its own PKC including a nodeID and a PK. Similarly, each user has her own PKC including her username and a PK. This approach do not prevent a centralized entity (such as an offline CA) to have information related to the devices each user (or company, etc.) has registered, but permits, among other improvements, a user to be connected to the system through devices she has not registered herself such as a phone issued by a telco or a fixed phone in a laboratory shared by all the members of a research group. On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Does this model really required modifications in the base document, or can it be > designed as an extension? (Unfortunately the paper is not freely available, so > it is difficult to know really what is needed for this). > > On 06/09/2011 07:31 AM, Diego Suarez wrote: > > Hi, > > > > I had in mind writing a draft about this, but since I'm running out of > > time, I would like to summarize a new certification model for P2PSIP I > > have been working on, in case it is of interest for the group. > > Further details can be found in paper: > > > > D. Touceda, J. Camara, L. Villalba, and J. Marquez, “Advantages of > > identity certificate segregation in P2PSIP systems,” Communications, > > IET, vol. 5, pp. 879–889, Apr. 2011. > > > > > > The idea is to split the certification of users and devices. Devices are > > identified by PKCs including a nodeID and the PK of the device, while > > users are identified by PKCs including a username and the PK of the > > user. Similar models have been used before in other communications > > systems, such as GSM where devices and users are separately represented > > by the international mobile equipment identity (IMEI) stored in the > > phones and the international mobile subscriber identity (IMSI) stored in > > the user subscriber identity module (SIM), respectively. > > > > Motivations of this model are: > > > > - Users and devices are different entities performing different > > roles within a P2PSIP system. Devices are nodes of the P2P > > overlay network (represented by a nodeID) that offer services > > (to route messages, to store data, . . .) to the system, while > > users (represented by an username) utilize these services, > > usually to establish media communications using SIP. > > > > - Support for mobility scenarios where a user may be logged at different > > devices at the same time using the same PKC. > > > > - Support several users to be logged in the same device (like a fixed > > phone) at the same time. > > > > - Support for user independent hard-coded devices. > > > > - Interoperability with SIP. SIP certificates are not valid in actual > > P2PSIP since they don't include a nodeID. > > > > cheers > > > > Diego Suárez > > > > > > On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote: > >> Unless something major comes up, we plan to request the newest version > >> of the base draft, draft-ietf-p2psip-base-15, be published. I'll put > >> in the request in a week (June 16th or 17th). If there are any further > >> comments from the last call a while ago (or further comments on the > >> comments since then), please send them to the list ASAP. > >> > >> Thanks, > >> > >> David (as chair) > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www.ietf.org/mailman/listinfo/p2psip > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www.ietf.org/mailman/listinfo/p2psip > > > - -- > Marc Petit-Huguenin > 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) > > iEYEARECAAYFAk3w/UMACgkQ9RoMZyVa61ctqACfTdnpLBUDY3GqmcHvcT41ncRS > 3r0An3YjUnCnMv4Rg/a91pra/xZFiGj6 > =NiCK > -----END PGP SIGNATURE----- From michaelc@IDSSOFTWARE.COM Fri Jun 10 22:26: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 78CE79E8009 for ; Fri, 10 Jun 2011 22:26:44 -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 uevp34tdLtpe for ; Fri, 10 Jun 2011 22:26:43 -0700 (PDT) Received: from smtpoutwbe04.prod.mesa1.secureserver.net (smtpoutwbe04.prod.mesa1.secureserver.net [208.109.78.206]) by ietfa.amsl.com (Postfix) with SMTP id 7EFBC9E800B for ; Fri, 10 Jun 2011 22:26:43 -0700 (PDT) Received: (qmail 7347 invoked from network); 11 Jun 2011 05:26:43 -0000 Received: from unknown (HELO gem-wbe32.prod.mesa1.secureserver.net) (64.202.189.144) by smtpoutwbe04.prod.mesa1.secureserver.net with SMTP; 11 Jun 2011 05:26:42 -0000 Received: (qmail 19707 invoked by uid 99); 11 Jun 2011 05:26:42 -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.04 Message-Id: <20110610222641.61e8c06078a3b23a733c71e914c0b9df.8230338564.wbe@email00.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Fri, 10 Jun 2011 22:26:41 -0700 Mime-Version: 1.0 Subject: Re: [P2PSIP] RELOAD support in Wireshark 1.6 [was Re: I-D Action: draft-ietf-p2psip-base-15.txt] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 05:26:44 -0000 FYI, A new feature added to Wireshark 1.6.0 is the ability to dissect RELOAD messages under DTLS if the agreed upon cipher-suite is either RSA-NULL-MD5 (0x0001) or RSA-NULL-SHA (0x0002), even when DTLS is not configured with the client/server private keys. https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3D5863 Take OpenSSL for example, you can make the following call on both sides to take advantage of this feature: SSL_CTX_set_cipher_list(dtls, "NULL-SHA"); This has proven to be very helpful for debugging and inter-op tests. Thanks --Michael=20 > -------- Original Message -------- > Subject: [P2PSIP] RELOAD support in Wireshark 1.6 [was Re: I-D Action: > draft-ietf-p2psip-base-15.txt] > From: Marc Petit-Huguenin > Date: Wed, June 08, 2011 12:22 pm > To:=20 > Cc: p2psip@ietf.org >=20 >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > FYI, version 1.6.0 of Wireshark was released yesterday, with support for = RELOAD > up to -15. This is a stable version so hopefully this will simplify and > accelerate the implementation and deployment of RELOAD. >=20 > On 05/27/2011 08:37 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the Peer-to-Peer Session Initiation P= rotocol Working Group of the IETF. > >=20 > > Title : REsource LOcation And Discovery (RELOAD) Base Protoc= ol > > Author(s) : Cullen Jennings > > Bruce B. Lowekamp > > Eric Rescorla > > Salman A. Baset > > Henning Schulzrinne > > Filename : draft-ietf-p2psip-base-15.txt > > Pages : 160 > > Date : 2011-05-27 > >=20 > > 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 i= s > > a fundamental service of the protocol. RELOAD also allows access > > from "client" nodes that do not need to route traffic or s= tore data > > for others. >=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 > iEYEARECAAYFAk3vzAgACgkQ9RoMZyVa61fsvACgnyEAQkegmAGyFzGvUIpfoy+f > 5wgAoJ+lwiyQzv3qZnUYPxpCrkv/A5gG > =3DgRdu > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From michaelc@IDSSOFTWARE.COM Fri Jun 10 23:25:59 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 67B8821F8496 for ; Fri, 10 Jun 2011 23:25:59 -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 Bgr0axi90H6X for ; Fri, 10 Jun 2011 23:25:58 -0700 (PDT) Received: from smtpoutwbe09.prod.mesa1.secureserver.net (smtpoutwbe09.prod.mesa1.secureserver.net [208.109.78.21]) by ietfa.amsl.com (Postfix) with SMTP id A6C9221F8494 for ; Fri, 10 Jun 2011 23:25:58 -0700 (PDT) Received: (qmail 9689 invoked from network); 11 Jun 2011 06:25:57 -0000 Received: from unknown (HELO gem-wbe24.prod.mesa1.secureserver.net) (64.202.189.227) by smtpoutwbe09.prod.mesa1.secureserver.net with SMTP; 11 Jun 2011 06:25:57 -0000 Received: (qmail 19288 invoked by uid 99); 11 Jun 2011 06:25:57 -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.04 Message-Id: <20110610232556.61e8c06078a3b23a733c71e914c0b9df.a0b4262438.wbe@email00.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Fri, 10 Jun 2011 23:25:56 -0700 Mime-Version: 1.0 Subject: [P2PSIP] Relax base-15 section 10.2 language 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, 11 Jun 2011 06:25:59 -0000 Hi, Section 10.2, second paragraph says, "The node first determines the overlay name. This value is provided by the user or some other out of band provisioning mechanism. The out of band mechanisms may also provide an optional URL for the configuration server." I believe the first sentence should be relaxed as "The node MAY first determines the overlay name." A node should be allowed to start with nothing but an arbitrary (out-of-band) URL to the configuration server, and that the overlay name will be whatever retrieved in the configuration XML. This practice also means the node need not query the DNS or construct the "/.well-known/p2psip-enroll" URL. For example, someone send you an email with a configuration URL. You just click on that URL to join the overlay that someone setup. That overlay name could be a 200 character hex string that would be very painful to type in. Thanks --Michael From michaelc@IDSSOFTWARE.COM Sat Jun 11 23:10: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 54DF111E80C8 for ; Sat, 11 Jun 2011 23:10:42 -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 jJt9Nae0G0Ak for ; Sat, 11 Jun 2011 23:10:41 -0700 (PDT) Received: from smtpoutwbe09.prod.mesa1.secureserver.net (smtpoutwbe09.prod.mesa1.secureserver.net [208.109.78.21]) by ietfa.amsl.com (Postfix) with SMTP id C4A5C11E8079 for ; Sat, 11 Jun 2011 23:10:36 -0700 (PDT) Received: (qmail 30924 invoked from network); 12 Jun 2011 06:10:35 -0000 Received: from unknown (HELO gem-wbe03.prod.mesa1.secureserver.net) (64.202.189.35) by smtpoutwbe09.prod.mesa1.secureserver.net with SMTP; 12 Jun 2011 06:10:35 -0000 Received: (qmail 18604 invoked by uid 99); 12 Jun 2011 06:10:35 -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.04 Message-Id: <20110611231034.61e8c06078a3b23a733c71e914c0b9df.0bb0eab361.wbe@email00.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Sat, 11 Jun 2011 23:10:34 -0700 Mime-Version: 1.0 Subject: [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: Sun, 12 Jun 2011 06:10:42 -0000 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 From petithug@acm.org Tue Jun 14 09:19:40 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 CF1EB1F0C51; Tue, 14 Jun 2011 09:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIyIJyM9J4s2; Tue, 14 Jun 2011 09:19:39 -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 1E1611F0C4F; Tue, 14 Jun 2011 09:19:39 -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 E9BAC2218B; Tue, 14 Jun 2011 18:18:22 +0200 (CEST) Message-ID: <4DF78A16.80103@acm.org> Date: Tue, 14 Jun 2011 09:19:34 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110606 Iceowl/1.0b2 Icedove/3.1.10 MIME-Version: 1.0 Followup-To: p2psip@ietf.org To: P2PSIP Mailing List References: <20110614161309.7045.10925.idtracker@ietfa.amsl.com> In-Reply-To: <20110614161309.7045.10925.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" Subject: Re: [P2PSIP] I-D Action: draft-petithuguenin-p2psip-proportional-quota-00.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 16:19:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This draft describes a new quota mechanism as a RELOAD extension. This extension is used by the VIPR RELOAD usage but has its own I-D because it can be used by other RELOAD usages. Comments, suggestions and questions are welcome. Please follow-up in the p2psip mailing-list. On 06/14/2011 09:13 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Proportional Quota in REsource LOcation And Discovery (RELOAD) > Author(s) : Jonathan Rosenberg > Cullen Jennings > Marc Petit-Huguenin > Filename : draft-petithuguenin-p2psip-proportional-quota-00.txt > Pages : 6 > Date : 2011-06-14 > > This document defines an extension to RELOAD [I-D.ietf-p2psip-base] > that limits the number of a specific kind element that can be stored > by one RELOAD peer. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-petithuguenin-p2psip-proportional-quota-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-petithuguenin-p2psip-proportional-quota-00.txt - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk33ihQACgkQ9RoMZyVa61dWywCfU88PrhJHdy67NWo68yed4j/G K2kAoIa1Piv+l7wzwiffwUc8mbQviSv/ =VV2P -----END PGP SIGNATURE----- From zongning@huawei.com Tue Jun 21 02:50: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 78BAA9E8055 for ; Tue, 21 Jun 2011 02:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.147 X-Spam-Level: X-Spam-Status: No, score=-106.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, 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 AkFVFCc1RI1O for ; Tue, 21 Jun 2011 02:50:56 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id A0D869E802B for ; Tue, 21 Jun 2011 02:50:56 -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 <0LN400L07WOSSR@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 21 Jun 2011 17:50:52 +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 <0LN4000L2WOSSY@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 21 Jun 2011 17:50:52 +0800 (CST) Received: from z63316a ([10.138.41.47]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LN400HS6WOPUM@szxml06-in.huawei.com> for p2psip@ietf.org; Tue, 21 Jun 2011 17:50:52 +0800 (CST) Date: Tue, 21 Jun 2011 17:50:49 +0800 From: Ning Zong To: p2psip@ietf.org Message-id: <006901cc2ff8$b35eef80$1a1cce80$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: Acwv96d4Ajo+e7jBRqi1GGV3z5SWjAAAOkCg Subject: [P2PSIP] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?utf-8?q?for_draft-zong-p2psip-rpr-00=2Etxt?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 09:50:57 -0000 Hi, Folks, An individual draft "An extension to RELOAD to support Relay Peer = Routing" has been submitted to try to fulfill the WG milestone of = "P2PSIP Relay Peer", as follow: http://www.ietf.org/id/draft-zong-p2psip-rpr-00.txt Comments are highly appreciated. BR, Ning Zong -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B46=E6=9C=8821=E6=97=A5 = 17:43 =E6=94=B6=E4=BB=B6=E4=BA=BA: zongning@huawei.com =E6=8A=84=E9=80=81: zhangyunfei@chinamobile.com; jiang.x.f@huawei.com; = Even.roni@huawei.com; zongning@huawei.com =E4=B8=BB=E9=A2=98: New Version Notification for = draft-zong-p2psip-rpr-00.txt A new version of I-D, draft-zong-p2psip-rpr-00.txt has been successfully = submitted by Ning Zong and posted to the IETF repository. Filename: draft-zong-p2psip-rpr Revision: 00 Title: An extension to RELOAD to support Relay Peer Routing Creation date: 2011-06-21 WG ID: Individual Submission Number of pages: 15 Abstract: This document proposes an optional extension to RELOAD to support relay peer routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediary peers and describes the potential cases where this extension can be used. = =20 The IETF Secretariat From zongning@huawei.com Tue Jun 21 02:51:10 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 2309A9E8057 for ; Tue, 21 Jun 2011 02:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.147 X-Spam-Level: X-Spam-Status: No, score=-106.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, 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 VO-AE3sUBGgc for ; Tue, 21 Jun 2011 02:51:09 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC969E8056 for ; Tue, 21 Jun 2011 02:51:09 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN400EW8WMTQN@szxga04-in.huawei.com> for p2psip@ietf.org; Tue, 21 Jun 2011 17:49:41 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LN400ASXWMT7X@szxga04-in.huawei.com> for p2psip@ietf.org; Tue, 21 Jun 2011 17:49:41 +0800 (CST) Received: from z63316a ([10.138.41.47]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LN400IGQWMPW5@szxml04-in.huawei.com> for p2psip@ietf.org; Tue, 21 Jun 2011 17:49:40 +0800 (CST) Date: Tue, 21 Jun 2011 17:49:37 +0800 From: Ning Zong To: p2psip@ietf.org Message-id: <006801cc2ff8$88c7eba0$9a57c2e0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: Acwv94pDYQfE5CJ1T8GPo6ZjgnlaKwAAE+xw Subject: [P2PSIP] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?utf-8?q?for_draft-zong-p2psip-drr-00=2Etxt?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 09:51:10 -0000 Hi, Folks, An individual draft "An extension to RELOAD to support Direct Response = Routing" has been submitted to try to fulfill the WG milestone of = "P2PSIP Direct Response", as follow: http://www.ietf.org/id/draft-zong-p2psip-drr-00.txt Comments are highly appreciated. BR, Ning Zong -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B46=E6=9C=8821=E6=97=A5 = 17:39 =E6=94=B6=E4=BB=B6=E4=BA=BA: zongning@huawei.com =E6=8A=84=E9=80=81: zhangyunfei@chinamobile.com; jiang.x.f@huawei.com; = Even.roni@huawei.com; zongning@huawei.com =E4=B8=BB=E9=A2=98: New Version Notification for = draft-zong-p2psip-drr-00.txt A new version of I-D, draft-zong-p2psip-drr-00.txt has been successfully = submitted by Ning Zong and posted to the IETF repository. Filename: draft-zong-p2psip-drr Revision: 00 Title: An extension to RELOAD to support Direct Response Routing Creation date: 2011-06-21 WG ID: Individual Submission Number of pages: 18 Abstract: This document proposes an optional extension to RELOAD to support direct response routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediary peers and describes the potential cases where this extension can be used. = =20 The IETF Secretariat From petithug@acm.org Tue Jun 21 12:58: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 0EF521F0C65 for ; Tue, 21 Jun 2011 12:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYlORZif0qkD for ; Tue, 21 Jun 2011 12:58: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 8B1791F0C4C for ; Tue, 21 Jun 2011 12:58:10 -0700 (PDT) Received: from [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08] (unknown [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id BBD3E2218B; Tue, 21 Jun 2011 21:56:26 +0200 (CEST) Message-ID: <4E00F7CE.7080402@acm.org> Date: Tue, 21 Jun 2011 12:58:06 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110606 Iceowl/1.0b2 Icedove/3.1.10 MIME-Version: 1.0 To: P2PSIP WG References: <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> In-Reply-To: <1307641649.5184.17.camel@santeles> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 19:58:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I read the paper and this modification makes sense to me (for example without this modification a peer that is purely used for routing and storage purpose, like a bootstrap peer, had to invent a valid, unique, and useless username just to acquire a certificate). So I support its inclusion in draft-ietf-p2psip-base. On 06/09/2011 10:47 AM, Diego Suarez wrote: > I think it would require a (slight) modification in the base document. > Current P2PSIP certification model is based on a single PKC (including > both usernames and nodeIDs) that uniquely identifies a user and her > devices. On the other hand, our model is base on a split certification. > Devices and users are independent. Each device has its own PKC including > a nodeID and a PK. Similarly, each user has her own PKC including her > username and a PK. This approach do not prevent a centralized entity > (such as an offline CA) to have information related to the devices each > user (or company, etc.) has registered, but permits, among other > improvements, a user to be connected to the system through devices she > has not registered herself such as a phone issued by a telco or a fixed > phone in a laboratory shared by all the members of a research group. > > > On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin wrote: > Does this model really required modifications in the base document, or can it be > designed as an extension? (Unfortunately the paper is not freely available, so > it is difficult to know really what is needed for this). > > On 06/09/2011 07:31 AM, Diego Suarez wrote: >>>> Hi, >>>> >>>> I had in mind writing a draft about this, but since I'm running out of >>>> time, I would like to summarize a new certification model for P2PSIP I >>>> have been working on, in case it is of interest for the group. >>>> Further details can be found in paper: >>>> >>>> D. Touceda, J. Camara, L. Villalba, and J. Marquez, Advantages of >>>> identity certificate segregation in P2PSIP systems, Communications, >>>> IET, vol. 5, pp. 879889, Apr. 2011. >>>> >>>> >>>> The idea is to split the certification of users and devices. Devices are >>>> identified by PKCs including a nodeID and the PK of the device, while >>>> users are identified by PKCs including a username and the PK of the >>>> user. Similar models have been used before in other communications >>>> systems, such as GSM where devices and users are separately represented >>>> by the international mobile equipment identity (IMEI) stored in the >>>> phones and the international mobile subscriber identity (IMSI) stored in >>>> the user subscriber identity module (SIM), respectively. >>>> >>>> Motivations of this model are: >>>> >>>> - Users and devices are different entities performing different >>>> roles within a P2PSIP system. Devices are nodes of the P2P >>>> overlay network (represented by a nodeID) that offer services >>>> (to route messages, to store data, . . .) to the system, while >>>> users (represented by an username) utilize these services, >>>> usually to establish media communications using SIP. >>>> >>>> - Support for mobility scenarios where a user may be logged at different >>>> devices at the same time using the same PKC. >>>> >>>> - Support several users to be logged in the same device (like a fixed >>>> phone) at the same time. >>>> >>>> - Support for user independent hard-coded devices. >>>> >>>> - Interoperability with SIP. SIP certificates are not valid in actual >>>> P2PSIP since they don't include a nodeID. >>>> >>>> cheers >>>> >>>> Diego Suárez >>>> >>>> >>>> On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote: >>>>> Unless something major comes up, we plan to request the newest version >>>>> of the base draft, draft-ietf-p2psip-base-15, be published. I'll put >>>>> in the request in a week (June 16th or 17th). If there are any further >>>>> comments from the last call a while ago (or further comments on the >>>>> comments since then), please send them to the list ASAP. >>>>> >>>>> Thanks, >>>>> >>>>> David (as chair) >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip > > - -- Marc Petit-Huguenin 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) iEYEARECAAYFAk4A98wACgkQ9RoMZyVa61deBgCfQVoA50uS7UwhXvwsoYhBaRBC ts0AnjTCVLyK+Wza25vGJ/8n4VgGTVQu =NR2H -----END PGP SIGNATURE----- From petithug@acm.org Tue Jun 21 15:03:34 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 D3C0511E8165 for ; Tue, 21 Jun 2011 15:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QZJy-ZpLE43 for ; Tue, 21 Jun 2011 15:03:34 -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 3D73911E8163 for ; Tue, 21 Jun 2011 15:03:34 -0700 (PDT) Received: from [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08] (unknown [IPv6:2001:55c:4c15:5f80:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 3DE3B2218B for ; Wed, 22 Jun 2011 00:01:46 +0200 (CEST) Message-ID: <4E01152D.8050700@acm.org> Date: Tue, 21 Jun 2011 15:03:25 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110606 Iceowl/1.0b2 Icedove/3.1.10 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] Fwd: I-D Action: draft-petithuguenin-p2psip-reload-bis-00.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 22:03:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I said in a previous email that I no longer have any pending interoperability issues in my list for draft-ietf-p2psip-base, but that does not mean that I think that the document is perfect. On the other hand any modification request on -base is painfully slow so requesting even more modifications is not a good solution. So I put various improvements for RELOAD in a separate draft, draft-petithuguenin-p2psip-reload-bis. The RELOAD authors are welcome to take whatever they like in this draft. Everything else will be proposed as extensions or in reload-bis after RELOAD is published. As by my standard policy, all the stuff in it will soon be either published as free software or implemented in publicly accessible servers (follow the announcements in my blog). Comments, questions and suggestions are welcome. - -------- Original Message -------- Subject: I-D Action: draft-petithuguenin-p2psip-reload-bis-00.txt Date: Tue, 21 Jun 2011 14:46:31 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Proposed Improvements for REsource LOcation And Discovery (RELOAD) Author(s) : Marc Petit-Huguenin Filename : draft-petithuguenin-p2psip-reload-bis-00.txt Pages : 5 Date : 2011-06-21 This document proposes some improvements for [RELOAD]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-petithuguenin-p2psip-reload-bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-petithuguenin-p2psip-reload-bis-00.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4BFSwACgkQ9RoMZyVa61f6cgCeJPCsqbEc02xgYbLX2jD9eUKW JCkAoI/X7GFzOwArX3g2zX7QW9LXU4l5 =pD/5 -----END PGP SIGNATURE----- From davidbryan@gmail.com Tue Jun 28 10:17:15 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 7442C21F85B0 for ; Tue, 28 Jun 2011 10:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRaiMyK-gQxj for ; Tue, 28 Jun 2011 10:17:15 -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 E828121F8596 for ; Tue, 28 Jun 2011 10:17:14 -0700 (PDT) Received: by qyk9 with SMTP id 9so2733091qyk.10 for ; Tue, 28 Jun 2011 10:17:14 -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=pAX1uABPN12O5I+kKtmS6B8NjO9kZmczTQ+LCYJMOSs=; b=V/piwlSyf+tnDqme+g1A1xTNzrtKL1/Yuqxj5yM82o/yv5wBITotFB1+UHs7F87+qJ BiCxKr6BvkwcVL2ji16O5amz7O61Gb8ZPTOpkYzkTjm3lcCQnaP+XZ/QLnPsQ8a/cw/w xLNJ733EfDqsZUks7rMcDRrCQUabS5RFm3nWc= MIME-Version: 1.0 Received: by 10.229.63.103 with SMTP id a39mr1710958qci.60.1309281432649; Tue, 28 Jun 2011 10:17:12 -0700 (PDT) Sender: davidbryan@gmail.com Received: by 10.229.79.72 with HTTP; Tue, 28 Jun 2011 10:17:12 -0700 (PDT) Date: Tue, 28 Jun 2011 10:17:12 -0700 X-Google-Sender-Auth: cN5fg-HpyqvFR1joI6hRF0Bfu6E Message-ID: From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [P2PSIP] Agenda Requests 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, 28 Jun 2011 17:17:15 -0000 We will be putting an agenda together soon. Please send Brian and myself requests for time as soon as possible. Thanks, David