From bbl@lowekamp.net Fri Mar 4 10:58:25 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00A63A687E for ; Fri, 4 Mar 2011 10:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7INeswidWPT for ; Fri, 4 Mar 2011 10:58:24 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 512FF3A6818 for ; Fri, 4 Mar 2011 10:58:24 -0800 (PST) Received: by iyj8 with SMTP id 8so2501837iyj.31 for ; Fri, 04 Mar 2011 10:59:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.43.59.139 with SMTP id wo11mr467706icb.43.1299265173602; Fri, 04 Mar 2011 10:59:33 -0800 (PST) Received: by 10.42.241.9 with HTTP; Fri, 4 Mar 2011 10:59:33 -0800 (PST) In-Reply-To: <4D6B0E5A.7050509@acm.org> References: <4CEAC54A.2030503@acm.org> <4D2B8BBE.3050303@acm.org> <4D52C465.6020807@acm.org> <4D605801.20704@acm.org> <7A3441F9-EEEE-42F7-A447-A4292F667201@skype.net> <4D615D35.8050507@acm.org> <4D6B0E5A.7050509@acm.org> Date: Fri, 4 Mar 2011 13:59:33 -0500 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] Multiple Node-IDs in certificate [was Re: draft-ietf-p2psip-base-12 (2)] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2011 18:58:25 -0000 On Sun, Feb 27, 2011 at 9:54 PM, Marc Petit-Huguenin wro= te: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 02/27/2011 05:15 PM, Bruce Lowekamp wrote: >> On Sun, Feb 20, 2011 at 1:28 PM, Marc Petit-Huguenin = wrote: > > [...] > >> >> OK, so the Signature extension is mandatory to use multiple Node-IDs in >> certificates. =C2=A0But the IceExtension still seems useless, as, thanks= to the >> Signature extension, we always know the Node-Id on each side of the Atta= ch. >> >> >>> I think the IceExtension would be needed for connection sharing, so >>> since you said you're setting that aside for now, I agree. >> >> Also a client joining the overlay using a certificate with multiple Node= -IDs, >> using the procedure in the second bullet of section 3.2.1 will still hav= e problems. >> >> >>> Assuming the Attach is using SignerIdentity, I don't see any problems >>> with that, since the peer would know the node-id that the node is >>> using. > > Clients that are using the mechanism described in the last paragraph of s= ection > 3.2.1 do not send Attach, so a peer would have to spy on the first messag= e > coming from the connection of this client to extract the Node-ID from the > SignerIdentity and be able to add the connection to the connection table. > I believe the intention has always been that all node connections use an Attach. The only exception is initial bootstrapping (3.4). Those nodes don't send Update. You're doing this because you have clients coded with the address of a peer they should connect through? I think it would still be better to have them doing an attach, either by encoding the peer ID in the same place they learn about the node from or using the ping mechanism in 10.4, followed by an Attach. (I think the draft is a little unclear that any node receiving a message sent to the wildcard simply responds to it) Bruce > - -- > 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) > > iEYEARECAAYFAk1rDlcACgkQ9RoMZyVa61dE/wCfadcwiQFAnaQuOGG6VxOphl+D > Dk4AniSw21hHNXbDm/GM442x+nOB05Fe > =3D6hrr > -----END PGP SIGNATURE----- > From petithug@acm.org Fri Mar 4 11:43:15 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A452F28B56A for ; Fri, 4 Mar 2011 11:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.105 X-Spam-Level: X-Spam-Status: No, score=-102.105 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3URABeWlUT2 for ; Fri, 4 Mar 2011 11:43:14 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 9A3073A6A29 for ; Fri, 4 Mar 2011 11:43:14 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 56AD01DBC4014; Fri, 4 Mar 2011 19:44:23 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 883DD1DBC4012; Fri, 4 Mar 2011 19:44:22 +0000 (UTC) Message-ID: <4D714115.3010605@acm.org> Date: Fri, 04 Mar 2011 11:44:21 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110303 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Bruce Lowekamp References: <4CEAC54A.2030503@acm.org> <4D2B8BBE.3050303@acm.org> <4D52C465.6020807@acm.org> <4D605801.20704@acm.org> <7A3441F9-EEEE-42F7-A447-A4292F667201@skype.net> <4D615D35.8050507@acm.org> <4D6B0E5A.7050509@acm.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Multiple Node-IDs in certificate [was Re: draft-ietf-p2psip-base-12 (2)] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2011 19:43:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/04/2011 10:59 AM, Bruce Lowekamp wrote: > On Sun, Feb 27, 2011 at 9:54 PM, Marc Petit-Huguenin wrote: > On 02/27/2011 05:15 PM, Bruce Lowekamp wrote: >>>> On Sun, Feb 20, 2011 at 1:28 PM, Marc Petit-Huguenin wrote: > > [...] > >>>> >>>> OK, so the Signature extension is mandatory to use multiple Node-IDs in >>>> certificates. But the IceExtension still seems useless, as, thanks to the >>>> Signature extension, we always know the Node-Id on each side of the Attach. >>>> >>>> >>>>> I think the IceExtension would be needed for connection sharing, so >>>>> since you said you're setting that aside for now, I agree. >>>> >>>> Also a client joining the overlay using a certificate with multiple Node-IDs, >>>> using the procedure in the second bullet of section 3.2.1 will still have problems. >>>> >>>> >>>>> Assuming the Attach is using SignerIdentity, I don't see any problems >>>>> with that, since the peer would know the node-id that the node is >>>>> using. > > Clients that are using the mechanism described in the last paragraph of section > 3.2.1 do not send Attach, so a peer would have to spy on the first message > coming from the connection of this client to extract the Node-ID from the > SignerIdentity and be able to add the connection to the connection table. > > >> I believe the intention has always been that all node connections use >> an Attach. This is not what the second bullet of 3.2.1 says. >> The only exception is initial bootstrapping (3.4). Those >> nodes don't send Update. > >> You're doing this because you have clients coded with the address of a >> peer they should connect through? No, I am writing an implementation that will cover 100% of the I-D. It's in the spec, so I am trying to implement it. And I think that the mechanism in the second bullet of 3.2.1 is elegant as it permits to not consider the first connection of a new node as a special case, and so should not be removed from the spec. > I think it would still be better >> to have them doing an attach, either by encoding the peer ID in the >> same place they learn about the node from or using the ping mechanism >> in 10.4, followed by an Attach.(I think the draft is a little >> unclear that any node receiving a message sent to the wildcard simply >> responds to it) Yes. And in my opinion, a node MUST send a Ping with wildcard immediately after any connection is established, so a client does not need to send an Attach. - -- 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) iEYEARECAAYFAk1xQRQACgkQ9RoMZyVa61c6dQCghEB2UkC7ygEs45PvMtx8WIup zVQAoKHRekHKpe8IzJnVoR21AgTsdgXI =JubW -----END PGP SIGNATURE----- From bbl@lowekamp.net Fri Mar 4 12:37:26 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F24D3A6878 for ; Fri, 4 Mar 2011 12:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZaoJnccxjHL for ; Fri, 4 Mar 2011 12:37:25 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 949943A6830 for ; Fri, 4 Mar 2011 12:37:24 -0800 (PST) Received: by iwl42 with SMTP id 42so2623520iwl.31 for ; Fri, 04 Mar 2011 12:38:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.138.69 with SMTP id b5mr1056979icu.378.1299271112424; Fri, 04 Mar 2011 12:38:32 -0800 (PST) Received: by 10.42.241.9 with HTTP; Fri, 4 Mar 2011 12:38:32 -0800 (PST) In-Reply-To: <4D714115.3010605@acm.org> References: <4CEAC54A.2030503@acm.org> <4D2B8BBE.3050303@acm.org> <4D52C465.6020807@acm.org> <4D605801.20704@acm.org> <7A3441F9-EEEE-42F7-A447-A4292F667201@skype.net> <4D615D35.8050507@acm.org> <4D6B0E5A.7050509@acm.org> <4D714115.3010605@acm.org> Date: Fri, 4 Mar 2011 15:38:32 -0500 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] Multiple Node-IDs in certificate [was Re: draft-ietf-p2psip-base-12 (2)] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2011 20:37:26 -0000 On Fri, Mar 4, 2011 at 2:44 PM, Marc Petit-Huguenin wrot= e: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/04/2011 10:59 AM, Bruce Lowekamp wrote: >> On Sun, Feb 27, 2011 at 9:54 PM, Marc Petit-Huguenin = wrote: >> On 02/27/2011 05:15 PM, Bruce Lowekamp wrote: >>>>> On Sun, Feb 20, 2011 at 1:28 PM, Marc Petit-Huguenin wrote: >> >> [...] >> >>>>> >>>>> OK, so the Signature extension is mandatory to use multiple Node-IDs = in >>>>> certificates. =C2=A0But the IceExtension still seems useless, as, tha= nks to the >>>>> Signature extension, we always know the Node-Id on each side of the A= ttach. >>>>> >>>>> >>>>>> I think the IceExtension would be needed for connection sharing, so >>>>>> since you said you're setting that aside for now, I agree. >>>>> >>>>> Also a client joining the overlay using a certificate with multiple N= ode-IDs, >>>>> using the procedure in the second bullet of section 3.2.1 will still = have problems. >>>>> >>>>> >>>>>> Assuming the Attach is using SignerIdentity, I don't see any problem= s >>>>>> with that, since the peer would know the node-id that the node is >>>>>> using. >> >> Clients that are using the mechanism described in the last paragraph of = section >> 3.2.1 do not send Attach, so a peer would have to spy on the first messa= ge >> coming from the connection of this client to extract the Node-ID from th= e >> SignerIdentity and be able to add the connection to the connection table= . >> >> >>> I believe the intention has always been that all node connections use >>> an Attach. > > This is not what the second bullet of 3.2.1 says. > Marc, I'm sorry, but can you quote the text you're referring to? I don't see the word "Attach" in that bullet. You're looking at -12? I like this feature too, but it's intended to allow a client to Attach to a peer other than its responsible peer, rather than route the Attach to its responsible peer. >>> The only exception is initial bootstrapping (3.4). =C2=A0Those >>> nodes don't send Update. >> >>> You're doing this because you have clients coded with the address of a >>> peer they should connect through? > > No, I am writing an implementation that will cover 100% of the I-D. =C2= =A0It's in the > spec, so I am trying to implement it. =C2=A0And I think that the mechanis= m in the > second bullet of 3.2.1 is elegant as it permits to not consider the first > connection of a new node as a special case, and so should not be removed = from > the spec. > Thanks for working on such a thorough implementation. You are definitely identifying numerous issues that people who did implementations awhile ago wouldn't notice, and I appreciate your insights into other possible solutions to some of the problems. Thanks, Bruce >> I think it would still be better >>> to have them doing an attach, either by encoding the peer ID in the >>> same place they learn about the node from or using the ping mechanism >>> in 10.4, followed by an Attach.(I think the draft is a little >>> unclear that any node receiving a message sent to the wildcard simply >>> responds to it) > > Yes. =C2=A0And in my opinion, a node MUST send a Ping with wildcard immed= iately after > any connection is established, so a client does not need to send an Attac= h. > > - -- > 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) > > iEYEARECAAYFAk1xQRQACgkQ9RoMZyVa61c6dQCghEB2UkC7ygEs45PvMtx8WIup > zVQAoKHRekHKpe8IzJnVoR21AgTsdgXI > =3DJubW > -----END PGP SIGNATURE----- > From petithug@acm.org Fri Mar 4 13:08:43 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFDA03A6A17 for ; Fri, 4 Mar 2011 13:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.12 X-Spam-Level: X-Spam-Status: No, score=-102.12 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFRO0zh15nTf for ; Fri, 4 Mar 2011 13:08:42 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id C12DD3A69FA for ; Fri, 4 Mar 2011 13:08:42 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 614341DBC4012; Fri, 4 Mar 2011 21:09:51 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 50E5915BC4002; Fri, 4 Mar 2011 21:09:50 +0000 (UTC) Message-ID: <4D71551D.8000808@acm.org> Date: Fri, 04 Mar 2011 13:09:49 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110303 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Bruce Lowekamp References: <4CEAC54A.2030503@acm.org> <4D2B8BBE.3050303@acm.org> <4D52C465.6020807@acm.org> <4D605801.20704@acm.org> <7A3441F9-EEEE-42F7-A447-A4292F667201@skype.net> <4D615D35.8050507@acm.org> <4D6B0E5A.7050509@acm.org> <4D714115.3010605@acm.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: Re: [P2PSIP] Multiple Node-IDs in certificate [was Re: draft-ietf-p2psip-base-12 (2)] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2011 21:08:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/04/2011 12:38 PM, Bruce Lowekamp wrote: > On Fri, Mar 4, 2011 at 2:44 PM, Marc Petit-Huguenin wrote: > On 03/04/2011 10:59 AM, Bruce Lowekamp wrote: >>>> On Sun, Feb 27, 2011 at 9:54 PM, Marc Petit-Huguenin wrote: >>>> On 02/27/2011 05:15 PM, Bruce Lowekamp wrote: >>>>>>> On Sun, Feb 20, 2011 at 1:28 PM, Marc Petit-Huguenin wrote: >>>> >>>> [...] >>>> >>>>>>> >>>>>>> OK, so the Signature extension is mandatory to use multiple Node-IDs in >>>>>>> certificates. But the IceExtension still seems useless, as, thanks to the >>>>>>> Signature extension, we always know the Node-Id on each side of the Attach. >>>>>>> >>>>>>> >>>>>>>> I think the IceExtension would be needed for connection sharing, so >>>>>>>> since you said you're setting that aside for now, I agree. >>>>>>> >>>>>>> Also a client joining the overlay using a certificate with multiple Node-IDs, >>>>>>> using the procedure in the second bullet of section 3.2.1 will still have problems. >>>>>>> >>>>>>> >>>>>>>> Assuming the Attach is using SignerIdentity, I don't see any problems >>>>>>>> with that, since the peer would know the node-id that the node is >>>>>>>> using. >>>> >>>> Clients that are using the mechanism described in the last paragraph of section >>>> 3.2.1 do not send Attach, so a peer would have to spy on the first message >>>> coming from the connection of this client to extract the Node-ID from the >>>> SignerIdentity and be able to add the connection to the connection table. >>>> >>>> >>>>> I believe the intention has always been that all node connections use >>>>> an Attach. > > This is not what the second bullet of 3.2.1 says. > > >> Marc, > >> I'm sorry, but can you quote the text you're referring to? I don't >> see the word "Attach" in that bullet. You're looking at -12? I like >> this feature too, but it's intended to allow a client to Attach to a >> peer other than its responsible peer, rather than route the Attach to >> its responsible peer. "Clients may insert themselves in the overlay in two ways: [...] o Establish a connection with an arbitrary peer in the overlay (perhaps based on network proximity or an inability to establish a direct connection with the responsible peer). In this case, the client will rely on RELOAD's Destination List feature to ensure reachability. The client can initiate requests, and any node in the overlay that knows the Destination List to its current location can reach it, but the client is not directly reachable using only its Node-ID. If the client is to receive incoming requests from other members of the overlay, the Destination List required to reach it must be learnable via other mechanisms, such as being stored in the overlay by a usage." The word "Attach" is not in this, because it is not used, which is my point. Because there is no Attach, the peer has to spy on the first message sent by the client to extract the Node-ID from the SignerIdentity and "label" the newly created connection in the connection table. Having the client send a wildcard Ping immediately after the connection permits to immediately retrieve the Node-ID and label the connection. Note that I am not saying that it is the right way to fix it - IMO the right way to fix this would be to add an extension in (D)TLS to carry the selected Node-ID in both direction (another solution - not as good as the TLS extension - is to carry it in the FramedMessage. I currently use the initial sequence value as an index in the SubjectAltName list, which has the advantage of been compatible with the current version of the Wireshark dissector, that I cannot update until I see how the SignerIdentity will be modified). - -- 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) iEYEARECAAYFAk1xVRsACgkQ9RoMZyVa61fy+QCeI+Ph8drpZLzOYRUrmkRYWVS+ +aEAnRhriRfitVj7Fplt9R1Iuq5n8ogI =rD51 -----END PGP SIGNATURE----- From petithug@acm.org Sun Mar 6 13:16:41 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 423C028C0CE for ; Sun, 6 Mar 2011 13:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.13 X-Spam-Level: X-Spam-Status: No, score=-102.13 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iX+51fbMMamM for ; Sun, 6 Mar 2011 13:16:40 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 6BEB428B797 for ; Sun, 6 Mar 2011 13:16:40 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 72B2111BC4084; Sun, 6 Mar 2011 21:17:52 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id F1EAF11BC4082 for ; Sun, 6 Mar 2011 21:17:51 +0000 (UTC) Message-ID: <4D73F9FF.8060009@acm.org> Date: Sun, 06 Mar 2011 13:17:51 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110303 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Configuration of Access Control Policy in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 06 Mar 2011 21:16:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://datatracker.ietf.org/doc/draft-petithuguenin-p2psip-access-control/ Abstract: "This document describes an extension to the REsource LOcation And Discovery (RELOAD) base protocol to distribute the code of new Access Control Policies without having to upgrade the RELOAD implementations in an overlay." - -- 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) iEYEARECAAYFAk1z+f4ACgkQ9RoMZyVa61frKgCgk1M1gLFQBdQRguxkLoqxsT13 arQAn0Hu1Njk4dkk9lJEtytnXcmILLN4 =QKWS -----END PGP SIGNATURE----- From prvs=04047654f=Alexander.Knauf@haw-hamburg.de Mon Mar 7 09:21:36 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08EA13A67F3 for ; Mon, 7 Mar 2011 09:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arGwSDmn1qvQ for ; Mon, 7 Mar 2011 09:21:35 -0800 (PST) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by core3.amsl.com (Postfix) with ESMTP id AC1403A67CF for ; Mon, 7 Mar 2011 09:21:34 -0800 (PST) Received: from dehawshub02.mailcluster.haw-hamburg.de ([141.22.200.52]) by mail3.is.haw-hamburg.de with ESMTP/TLS/RC4-MD5; 07 Mar 2011 18:22:47 +0100 Received: from dehawscas02.mailcluster.haw-hamburg.de (141.22.200.34) by DEHAWSHUB02.mailcluster.haw-hamburg.de (141.22.200.52) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 7 Mar 2011 18:22:47 +0100 Received: from [141.22.26.154] (141.22.200.51) by haw-mailer.haw-hamburg.de (141.22.200.80) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 7 Mar 2011 18:22:47 +0100 Message-ID: <4D751465.8000307@haw-hamburg.de> Date: Mon, 7 Mar 2011 18:22:45 +0100 From: Alexander Knauf User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: P2PSIP Mailing List Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Fwd: New Version Notification for draft-knauf-p2psip-share-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 07 Mar 2011 17:21:36 -0000 Hi all, we just submitted a new draft Usage for RELOAD. Please have a look. http://www.ietf.org/id/draft-knauf-p2psip-share-00.txt We are looking forward to your feedback. Regards, Alexander A new version of I-D, draft-knauf-p2psip-share-00.txt has been successfully submitted by Alexander Knauf and posted to the IETF repository. Abstract: This document defines a RELOAD Usage for shared write access to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic primitive for enabling various coordination and notification schemes among distributed peers. Access in ShaRe is controlled by a hierarchical trust delegation scheme maintained within an access list. A new USER-CHAIN-ACL access policy allows authorized peers to write a Shared Resource without owning its corresponding certificate. This specification also adds mechanisms to store Resources with a variable name which is useful whenever peer-independent rendezvous processes are required. The IETF Secretariat. From petithug@acm.org Mon Mar 7 09:49:41 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DF0E3A67F9 for ; Mon, 7 Mar 2011 09:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.148 X-Spam-Level: X-Spam-Status: No, score=-102.148 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u70-2tcomRHm for ; Mon, 7 Mar 2011 09:49:40 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 95C283A67F3 for ; Mon, 7 Mar 2011 09:49:40 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 1B1EC6C984CE; Mon, 7 Mar 2011 17:50:54 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 7FDDD6C984C8; Mon, 7 Mar 2011 17:50:53 +0000 (UTC) Message-ID: <4D751AFC.9060304@acm.org> Date: Mon, 07 Mar 2011 09:50:52 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110303 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Alexander Knauf References: <4D751465.8000307@haw-hamburg.de> In-Reply-To: <4D751465.8000307@haw-hamburg.de> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Fwd: New Version Notification for draft-knauf-p2psip-share-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 07 Mar 2011 17:49:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/07/2011 09:22 AM, Alexander Knauf wrote: > Hi all, > > we just submitted a new draft Usage for RELOAD. Please have a look. > > http://www.ietf.org/id/draft-knauf-p2psip-share-00.txt > > We are looking forward to your feedback. > > Regards, > > Alexander > > A new version of I-D, draft-knauf-p2psip-share-00.txt has been > successfully submitted by Alexander Knauf and posted to the IETF > repository. > > Abstract: > This document defines a RELOAD Usage for shared write access to > RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic > primitive for enabling various coordination and notification schemes > among distributed peers. Access in ShaRe is controlled by a > hierarchical trust delegation scheme maintained within an access > list. A new USER-CHAIN-ACL access policy allows authorized peers to > write a Shared Resource without owning its corresponding certificate. > This specification also adds mechanisms to store Resources with a > variable name which is useful whenever peer-independent rendezvous > processes are required. Does this USER-CHAIN-ACL policy replace the USER-CHAIN-MATCH policy in draft-knauf-p2psip-disco? (I am trying to adapt my own draft-petithuguenin-p2psip-access-control to support all or some of these policies). 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) iEYEARECAAYFAk11GvsACgkQ9RoMZyVa61debgCdHPpxqiYivZrZTmkGFvwdCbo6 3YcAmgLDuQGsgQwP157LDprfjgH7+38/ =KLWP -----END PGP SIGNATURE----- From schmidt@informatik.haw-hamburg.de Mon Mar 7 12:05:54 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD0343A679C for ; Mon, 7 Mar 2011 12:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWTtUvQoDswL for ; Mon, 7 Mar 2011 12:05:53 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id BD38B3A679F for ; Mon, 7 Mar 2011 12:05:49 -0800 (PST) Envelope-to: p2psip@ietf.org Received: from e178059225.adsl.alicedsl.de ([85.178.59.225] helo=[192.168.178.36]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Pwgg3-0008aN-F5 for p2psip@ietf.org; Mon, 07 Mar 2011 21:05:11 +0100 Message-ID: <4D753AE0.5040905@informatik.haw-hamburg.de> Date: Mon, 07 Mar 2011 21:06:56 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: p2psip@ietf.org References: <4D751465.8000307@haw-hamburg.de> <4D751AFC.9060304@acm.org> In-Reply-To: <4D751AFC.9060304@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: p2psip@ietf.org Subject: Re: [P2PSIP] Fwd: New Version Notification for draft-knauf-p2psip-share-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 07 Mar 2011 20:05:54 -0000 Hi Marc, On 07.03.2011 18:50, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/07/2011 09:22 AM, Alexander Knauf wrote: >> Hi all, >> >> we just submitted a new draft Usage for RELOAD. Please have a look. >> >> http://www.ietf.org/id/draft-knauf-p2psip-share-00.txt >> ... > > Does this USER-CHAIN-ACL policy replace the USER-CHAIN-MATCH policy in > draft-knauf-p2psip-disco? > > (I am trying to adapt my own draft-petithuguenin-p2psip-access-control to > support all or some of these policies). > Yes it does. Actually, we have generalized/modified and split this policy in two parts: USER-CHAIN-ACL is a trust delegation scheme to avoid the exchange of private conference keys and have a more general mechanism of controlling a shared access. USER-PATTERN-MATCH (Sect. 6.1) is the remaining part for defining flexible names such as a "pleasant" conference name. draft-knauf-p2psip-disco will be updated in the next days to make use of this new "shared resource". Best, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From petithug@acm.org Mon Mar 7 20:02:30 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B0B13A68E3 for ; Mon, 7 Mar 2011 20:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.155 X-Spam-Level: X-Spam-Status: No, score=-102.155 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTzmWzNgbR0r for ; Mon, 7 Mar 2011 20:02:29 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 47AD73A68DB for ; Mon, 7 Mar 2011 20:02:29 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id 7520115BC4004; Tue, 8 Mar 2011 04:03:43 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id E16BC15BC4002 for ; Tue, 8 Mar 2011 04:03:42 +0000 (UTC) Message-ID: <4D75AA9E.3050502@acm.org> Date: Mon, 07 Mar 2011 20:03:42 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110303 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] draft-ietf-p2psip-base-12 (7) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 08 Mar 2011 04:02:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 More... A.45. Section 9 The hash function is never defined for the chord overlay. A.46. Section 10.3 "application/pkix-cert I think that a reference to RFC 2585 should be added here. Nits: - ---- - - Section 5.3.1.1 The definition of IpAddressPort is missing a "};" at the end of the select. - - Section 5.3.4 The definition of SignerIdentityValue is missing a "};" at the end of the select. - - Section 5.4.2.2 s/public struct/struct/ - - Section 5.5.1.1 The definition of IceCandidate is missing a ";" at the end of the select. - -- 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) iEYEARECAAYFAk11qpoACgkQ9RoMZyVa61fx3wCfZK1U1zOWlSA13OPXoVmhrhsb mZ4AnAz+0E7ny/MI7CRvtKSOJpXg2XD+ =gBto -----END PGP SIGNATURE----- From michaelc@idssoftware.com Mon Mar 7 21:07:36 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D662F3A68D4 for ; Mon, 7 Mar 2011 21:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j91pKaF0jZZH for ; Mon, 7 Mar 2011 21:07:36 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 19EF23A6847 for ; Mon, 7 Mar 2011 21:07:35 -0800 (PST) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PwpAA-0006hu-6J for p2psip@ietf.org; Tue, 08 Mar 2011 00:08:50 -0500 Message-ID: <4D75BABC.30606@idssoftware.com> Date: Mon, 07 Mar 2011 21:12:28 -0800 From: Michael Chen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da940a7eafe40a1bafc9e8debe6715947d789350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Subject: [P2PSIP] Life cycle of AppAttach connections X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 08 Mar 2011 05:07:36 -0000 Hi, The current draft make no mention of the life cycle of connection created by AppAttach. I am thinking about at lease two aspects: 1) How to do keep-alive on connections established via AppAttach. 2) How to terminate a connection established via AppAttach. Any thoughts? --Michael From li.lichun1@zte.com.cn Mon Mar 7 23:34:27 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563013A690F for ; Mon, 7 Mar 2011 23:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtSZ9rB17q00 for ; Mon, 7 Mar 2011 23:34:26 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id B21FF3A6910 for ; Mon, 7 Mar 2011 23:34:25 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35102075036648; Tue, 8 Mar 2011 15:32:58 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 84746.2795080246; Tue, 8 Mar 2011 15:35:34 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p287ZUtX074932; Tue, 8 Mar 2011 15:35:30 +0800 (GMT-8) (envelope-from li.lichun1@zte.com.cn) In-Reply-To: <4D75BABC.30606@idssoftware.com> To: Michael Chen MIME-Version: 1.0 X-KeepSent: 7FF9FA69:B1FA1277-4825784D:0028D249; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: li.lichun1@zte.com.cn Date: Tue, 8 Mar 2011 15:35:25 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-08 15:35:30, Serialize complete at 2011-03-08 15:35:30 Content-Type: multipart/alternative; boundary="=_alternative 0029C05C4825784D_=" X-MAIL: mse01.zte.com.cn p287ZUtX074932 Cc: P2PSIP WG Subject: Re: [P2PSIP] Life cycle of AppAttach connections X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 08 Mar 2011 07:34:27 -0000 This is a multipart message in MIME format. --=_alternative 0029C05C4825784D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 QXBwQXR0YWNoIGhlbHBzIEFwcCAoZS5nLiBTSVApIHRvIGNyZWF0ZSBjb25uZWN0aW9uLiBUaGUg QXBwIGNvbm5lY3Rpb24gaXMgDQptYWludGFpbmVkIGJ5IEFwcC4NCkJ1dCBJIHdvbmRlciBob3cg dG8gYnJlYWsgYSBSRUxPQUQgY29ubmVjdGlvbiBjcmVhdGVkIGJ5IEF0dGFjaC4NCg0KQlINCkxp Y2h1bg0KDQoNCg0KDQpNaWNoYWVsIENoZW4gPG1pY2hhZWxjQGlkc3NvZnR3YXJlLmNvbT4gDQq3 orz+yMs6ICBwMnBzaXAtYm91bmNlc0BpZXRmLm9yZw0KMjAxMS0wMy0wOCAxMzoxMg0KDQrK1bz+ yMsNClAyUFNJUCBXRyA8cDJwc2lwQGlldGYub3JnPg0Ks63LzQ0KDQrW98ziDQpbUDJQU0lQXSBM aWZlIGN5Y2xlIG9mIEFwcEF0dGFjaCBjb25uZWN0aW9ucw0KDQoNCg0KDQoNCg0KSGksDQoNClRo ZSBjdXJyZW50IGRyYWZ0IG1ha2Ugbm8gbWVudGlvbiBvZiB0aGUgbGlmZSBjeWNsZSBvZiBjb25u ZWN0aW9uIGNyZWF0ZWQgDQpieSANCkFwcEF0dGFjaC4gSSBhbSB0aGlua2luZyBhYm91dCBhdCBs ZWFzZSB0d28gYXNwZWN0czoNCg0KMSkgSG93IHRvIGRvIGtlZXAtYWxpdmUgb24gY29ubmVjdGlv bnMgZXN0YWJsaXNoZWQgdmlhIEFwcEF0dGFjaC4NCg0KMikgSG93IHRvIHRlcm1pbmF0ZSBhIGNv bm5lY3Rpb24gZXN0YWJsaXNoZWQgdmlhIEFwcEF0dGFjaC4NCg0KQW55IHRob3VnaHRzPw0KDQot LU1pY2hhZWwNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpQMlBTSVAgbWFpbGluZyBsaXN0DQpQMlBTSVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBT ZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlz IHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwg Y29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJl IG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBk aXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRo aXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRp YWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBl bnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVz c2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRo ZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2 aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 0029C05C4825784D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFwcEF0dGFjaCBoZWxwcyBBcHAg KGUuZy4gU0lQKSB0byBjcmVhdGUNCmNvbm5lY3Rpb24uIFRoZSBBcHAgY29ubmVjdGlvbiBpcyBt YWludGFpbmVkIGJ5IEFwcC48L2ZvbnQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5CdXQgSSB3b25k ZXIgaG93IHRvIGJyZWFrIGEgUkVMT0FEIGNvbm5lY3Rpb248L2ZvbnQ+PC90dD48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+DQpjcmVhdGVkIGJ5IEF0dGFjaC48YnI+DQo8YnI+DQpCUjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+TGljaHVuPGJyPg0KPC9m b250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPk1pY2hh ZWwgQ2hlbiAmbHQ7bWljaGFlbGNAaWRzc29mdHdhcmUuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtwMnBzaXAtYm91 bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4y MDExLTAzLTA4IDEzOjEyPC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPlAyUFNJUCBXRyAmbHQ7cDJwc2lwQGlldGYub3JnJmd0OzwvZm9udD4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM 4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W1AyUFNJ UF0gTGlmZSBjeWNsZSBvZiBBcHBBdHRhY2ggY29ubmVjdGlvbnM8L2ZvbnQ+PC90YWJsZT4NCjxi cj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90 YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkhpLDxicj4NCjxicj4NClRo ZSBjdXJyZW50IGRyYWZ0IG1ha2Ugbm8gbWVudGlvbiBvZiB0aGUgbGlmZSBjeWNsZSBvZiBjb25u ZWN0aW9uIGNyZWF0ZWQNCmJ5IDxicj4NCkFwcEF0dGFjaC4gSSBhbSB0aGlua2luZyBhYm91dCBh dCBsZWFzZSB0d28gYXNwZWN0czo8YnI+DQo8YnI+DQoxKSBIb3cgdG8gZG8ga2VlcC1hbGl2ZSBv biBjb25uZWN0aW9ucyBlc3RhYmxpc2hlZCB2aWEgQXBwQXR0YWNoLjxicj4NCjxicj4NCjIpIEhv dyB0byB0ZXJtaW5hdGUgYSBjb25uZWN0aW9uIGVzdGFibGlzaGVkIHZpYSBBcHBBdHRhY2guPGJy Pg0KPGJyPg0KQW55IHRob3VnaHRzPzxicj4NCjxicj4NCi0tTWljaGFlbDxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KUDJQU0lQIG1haWxp bmcgbGlzdDxicj4NClAyUFNJUEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcDJwc2lwPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+ PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZu YnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlz Jm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWls Jm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lw aWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7 dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3Qm bmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVu dHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhl cnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3Ry YW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5i c3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1 c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZu YnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7 SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwm bmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7 b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2 aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDth cmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRl ci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJz cDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5i c3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 0029C05C4825784D_=-- From davidbryan@gmail.com Wed Mar 9 11:27:11 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722D83A6902 for ; Wed, 9 Mar 2011 11:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.302 X-Spam-Level: X-Spam-Status: No, score=-101.302 tagged_above=-999 required=5 tests=[AWL=1.675, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBD2eoqZKP2J for ; Wed, 9 Mar 2011 11:27:10 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 748F33A6827 for ; Wed, 9 Mar 2011 11:27:10 -0800 (PST) Received: by fxm15 with SMTP id 15so906222fxm.31 for ; Wed, 09 Mar 2011 11:28:26 -0800 (PST) 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=tY1XKFoLu54H1amcNWub7NU34LUXfBMe72NZj3chl+g=; b=xXqWnnDiYXK5eZXRvUpYekfiShqnb+SH7kEn+3njgY8z1RlI6r0szO5gy7hBAIJXcc W+IY3rT7Qsn6/dcp3HDW9y9HggsPqwCg3UcrymIrN3O8+xm9dGztvIuljtsCtLivxh/u ztCPnUVVLs7birvZXX3yVFQvmLcmDv4KNNedg= 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=vFW9LUNx8O5D+E1hms4nGdj4kg74ZaJpwN9yTQ0KkzZs5AnKB6Ksc3yJDpr4oXbo6M B9hqPpfQ9dRxLBm3w7iikDjK0i6xLxskqgFu3fg+68j/wgxA40nSRnQeSfhjjWVYAEg0 dx8CvQeigJwxrq4p6mZ6+djpsWHvF6U+whgcE= MIME-Version: 1.0 Received: by 10.223.87.75 with SMTP id v11mr1601506fal.28.1299698815979; Wed, 09 Mar 2011 11:26:55 -0800 (PST) Sender: davidbryan@gmail.com Received: by 10.223.86.200 with HTTP; Wed, 9 Mar 2011 11:26:55 -0800 (PST) Date: Wed, 9 Mar 2011 14:26:55 -0500 X-Google-Sender-Auth: SQIbNGkNb3Ffouu8oX0_phY7l_0 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.9 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, 09 Mar 2011 19:27:11 -0000 Hi all, Please send agenda requests for P2PSIP to myself AND Brian as soon as possible, definitely before Thursday, Mar. 17. As always, remember that you must have a current draft to request a slot and slots will be issued based on time available, importance to the group's milestones, and amount of list discussion. The session for P2PSIP is scheduled for the last slot on Thursday. David (as chair) From zongning@huawei.com Thu Mar 10 01:40:59 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92DD23A6889 for ; Thu, 10 Mar 2011 01:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.94 X-Spam-Level: X-Spam-Status: No, score=-98.94 tagged_above=-999 required=5 tests=[AWL=1.104, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWkSu5JqwScJ for ; Thu, 10 Mar 2011 01:40:58 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 0E4153A67EF for ; Thu, 10 Mar 2011 01:40:56 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHU00FHA5JJLD@szxga05-in.huawei.com> for p2psip@ietf.org; Thu, 10 Mar 2011 17:40:32 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHU0029R5JJZS@szxga05-in.huawei.com> for p2psip@ietf.org; Thu, 10 Mar 2011 17:40:31 +0800 (CST) Received: from z63316a ([10.138.41.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LHU005XP5JGUS@szxml04-in.huawei.com> for p2psip@ietf.org; Thu, 10 Mar 2011 17:40:31 +0800 (CST) Date: Thu, 10 Mar 2011 17:40:28 +0800 From: Ning Zong To: p2psip@ietf.org Message-id: <007a01cbdf07$30bcdd40$923697c0$@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: AcvfBrUFkAE3kl8vToysEmHjyotPWQAABrTQ Subject: [P2PSIP] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?utf-8?q?for_draft-jiang-p2psip-relay-05?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 10 Mar 2011 09:40:59 -0000 Hi, Folks, A new version of P2PSIP Direction Response & Relay Peer Routing = (DRR&RPR) draft has been submitted as follow: http://www.ietf.org/id/draft-jiang-p2psip-relay-05.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: IETF I-D Submission Tool = [mailto:idsubmission@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B43=E6=9C=8810=E6=97=A5 = 17:35 =E6=94=B6=E4=BB=B6=E4=BA=BA: zongning@huawei.com =E6=8A=84=E9=80=81: jiang.x.f@huawei.com; ron.even.tlv@gmail.com; = zhangyunfei@chinamobile.com =E4=B8=BB=E9=A2=98: New Version Notification for = draft-jiang-p2psip-relay-05 A new version of I-D, draft-jiang-p2psip-relay-05.txt has been = successfully submitted by Ning Zong and posted to the IETF repository. Filename: draft-jiang-p2psip-relay Revision: 05 Title: An extension to RELOAD to support Direct Response and Relay = Peer routing Creation_date: 2011-03-10 WG ID: Independent Submission Number_of_pages: 23 Abstract: This document proposes an optional extension to RELOAD to support direct response and relay peer routing modes. RELOAD recommends symmetric recursive routing for routing messages. The new optional extensions provide a shorter route for responses reducing the overhead on intermediary peers and describe the potential cases where these extensions can be used. = =20 The IETF Secretariat. From petithug@acm.org Thu Mar 10 11:01:56 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7B13A6826 for ; Thu, 10 Mar 2011 11:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.862 X-Spam-Level: X-Spam-Status: No, score=-101.862 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BBth22sTH6X for ; Thu, 10 Mar 2011 11:01:55 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 8AA0B3A6828 for ; Thu, 10 Mar 2011 11:01:55 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id C76C0DBCC046; Thu, 10 Mar 2011 19:03:13 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 3CA5DDBCC044 for ; Thu, 10 Mar 2011 19:03:13 +0000 (UTC) Message-ID: <4D792070.3080907@acm.org> Date: Thu, 10 Mar 2011 11:03:12 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110303 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: P2PSIP Mailing List References: <4D75AA9E.3050502@acm.org> In-Reply-To: <4D75AA9E.3050502@acm.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] draft-ietf-p2psip-base-12 (8) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 10 Mar 2011 19:01:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Another round. That will probably be the last one until the publication of -13 as I am running out of margins for annotations on my copy of -12 :-( A.47. Section 6.3 The four policies defined in p2psip-base consistently says that "[a] given value MUST be written (or overwritten) if and only if the request is signed ..." Additional access control policies defined elsewhere use similar wording. But should not the StoredData signature be used instead of the request signature? When replicating the data, the signer of the StoreRequest will be different from the signer of the original request and so the test will no longer work. Section 6.4.1.1 says that "[a] peer MUST [check that] [e]ach element is signed by a credential which is authorized to write this kind at this Resource-ID.", which seems to confirm that this is the element's signature that must be checked, not the request's. A.48. Section 13.7 The "RELOAD Data Model" registry contains a Code value which is on fact never used anywhere. I think it would be simpler to remove this (like it is done for the Access Control Policies) and redefine DataModel in section 6.2 like this: enum { single_value, array, dictionary } DataModel; BTW, the select in 6.4.2.1 uses "model" instead of "DataModel." A.49. Section 10.1.1 The Data Model, Access Control Policy and Kind names permitted in the schema does not and cannot match the definitions in the various IANA registries, because of the case. E.g. the Data Model registry contains "USER-MATCH" but the schema only accept "user-match". I suggest to replace the definition of "user-match" and other strings by the following: access-control-type |= xsd:token { pattern = "[uU][sS][eE][rR]-[mM][aA][tT][cC][hH]" } - -- 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) iEYEARECAAYFAk15IG4ACgkQ9RoMZyVa61e3YACePsYX2AbyEjSiP9/aZzAenqQx mAUAni0r2QTZkZmQ928gk9CMfvCdnF3v =Q8OV -----END PGP SIGNATURE----- From petithug@acm.org Fri Mar 11 08:39:51 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA0FB3A6A15 for ; Fri, 11 Mar 2011 08:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.151 X-Spam-Level: X-Spam-Status: No, score=-102.151 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IZIthx3dOKC for ; Fri, 11 Mar 2011 08:39:50 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id C468B3A69DF for ; Fri, 11 Mar 2011 08:39:50 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id E7B8CDBCC046; Fri, 11 Mar 2011 16:41:09 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 7944ADBCC044 for ; Fri, 11 Mar 2011 16:41:09 +0000 (UTC) Message-ID: <4D7A50A4.5000606@acm.org> Date: Fri, 11 Mar 2011 08:41:08 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110303 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: P2PSIP Mailing List References: <4D4F31EC.5020009@acm.org> In-Reply-To: <4D4F31EC.5020009@acm.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (5) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 11 Mar 2011 16:39:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/06/2011 03:42 PM, Marc Petit-Huguenin wrote: > More questions and comments... [...] > A.39. Section 6.2.2 > > I am not really sure to understand how the "exists=False" are synthesized when > doing a Fetch on an array. For example if a Store was made for an object with > an index of 0xfffffffe, and the Fetch requests the whole array, will the answer > contains 4294967294 "exists=False" objects? Also how are this synthesized elements signed? - -- 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) iEYEARECAAYFAk16UKMACgkQ9RoMZyVa61cFHwCeM7CApWNnHMnGDnLP/NFfI1Yb 0KEAoKmAfqiwsEIs4nJJIIdz+K5Q7Guy =adf7 -----END PGP SIGNATURE----- From fluffy@cisco.com Sat Mar 12 12:11:41 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6A9C3A6994 for ; Sat, 12 Mar 2011 12:11:41 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Lw7dzoGhr4H for ; Sat, 12 Mar 2011 12:11:34 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6842A3A69CA for ; Sat, 12 Mar 2011 12:11:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1188; q=dns/txt; s=iport; t=1299960774; x=1301170374; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=TZ0Wo4A3zmoTVg3x7JSZLwGv4EMNZKTSAxzmRBHCkIc=; b=hvQbALZR+Lf7sZQU9X5N0qJ7fhgXCO3UrhqEvaNPVWqY421oCgv+nn3z uK8Ok8C6rnWWSD1jrTwrwWhrek9U8GinziQnS85XnyBM+ZJP7geHEEWqP ZCdQTpcjN/866E9p+c8RRWMO31eUmMcQIWm3NzXzo4NMcPn9vr8uQ6NUn o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF5ie02tJXG//2dsb2JhbACmQ3ekXps7hWIEhSuHJ4NO X-IronPort-AV: E=Sophos;i="4.62,308,1297036800"; d="scan'208";a="345197565" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-5.cisco.com with ESMTP; 12 Mar 2011 20:12:54 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2CKCraP018522; Sat, 12 Mar 2011 20:12:53 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D4F31EC.5020009@acm.org> Date: Sat, 12 Mar 2011 13:15:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D4F31EC.5020009@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1082) Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (5) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 12 Mar 2011 20:11:42 -0000 >=20 >=20 > A.41. Section 10.1 expiration definition >=20 > I think that it would be a good idea to say that a Node should wait a = random > time after the expiration time before retrieving the file again from = the > configuration server to not crash it and to let ConfigUpdate do its = job. >=20 Makes sense. I'm going to add the text=20 The peer SHOULD retrieve a new copy of the configuration at a = randomly selected time that is before the expiration time. I'm not all that happy with that text it someone wants to suggest = something better. It does not tell the implementors what range to select = the time over but it's not clear we have to be that specific.=20 > A.42. Section 10.1 client-permitted definition >=20 > I have no idea how an overlay can enforce this. All nodes starts as = clients, so > how an overlay is supposed to know the difference between a real = client and a > client that yet had to do the steps required to become a peer? >=20 Agree. Changed to=20 If it is set to "FALSE" then nodes are not allowed to remain clients = after the initial join. There is currently no way for the overlay to = enforce this. From fluffy@cisco.com Sat Mar 12 12:11:55 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0E643A65A6 for ; Sat, 12 Mar 2011 12:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.599 X-Spam-Level: X-Spam-Status: No, score=-100.599 tagged_above=-999 required=5 tests=[AWL=-10.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puvd5CiG-zxx for ; Sat, 12 Mar 2011 12:11:48 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 020613A6A7C for ; Sat, 12 Mar 2011 12:11:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1124; q=dns/txt; s=iport; t=1299960789; x=1301170389; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=TJom3TvlKxANbcZUOTqBUUAdeQ3j8RugBED8ZJ3To6U=; b=djVU+mYCRzgJXhdIaThWFnBd9PrvAjOHf9E2bOKC4MiSdMptiRYD9M7O 3QUqxXZaj+D9yxXDOvwvdwguhIBjH+bottauuiuP67KP7YlZbTPjzfB5P yKy0p9YC5KDTCXveYQunrirLDUky9RVvpgkvVC9lNNLI5O75UwgAUzkoI w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF5ie02tJXG//2dsb2JhbACmQ3ekXps7hWIEhSuHJ4NO X-IronPort-AV: E=Sophos;i="4.62,308,1297036800"; d="scan'208";a="345197632" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-5.cisco.com with ESMTP; 12 Mar 2011 20:13:08 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2CKCraQ018522; Sat, 12 Mar 2011 20:13:08 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D4F31EC.5020009@acm.org> Date: Sat, 12 Mar 2011 13:15:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <711A0533-B9B7-4DA9-8CDF-788324D07D6F@cisco.com> References: <4D4F31EC.5020009@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1082) Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (5) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 12 Mar 2011 20:11:56 -0000 On Feb 6, 2011, at 4:42 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > More questions and comments... >=20 > A.36. Section 2 "Each Kind is identified with a unique IANA assigned = integer > called a Kind-ID." fixed >=20 > According to 13.6, Kind-IDs in the 0xf0000001 to 0xfffffffe are not = IANA > assigned. Same thing in the second paragraph of 4.1. fixed=20 >=20 > A.37. Section 5.3.3.1 >=20 > Error_In_Progress is missing. fixed >=20 > Also the definition for Error_Config_Too_New does not match 5.3.2.1. Fixed >=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.10 (GNU/Linux) >=20 > iEYEARECAAYFAk1PMeoACgkQ9RoMZyVa61e9jwCffYWuEsxiutkKPIf3PlZdiGpy > mi0An1+8ztwuBfacvkUdZI1TJytrIJBX > =3DcWgV > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Sat Mar 12 12:12:41 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3339A3A69CA for ; Sat, 12 Mar 2011 12:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.266 X-Spam-Level: X-Spam-Status: No, score=-97.266 tagged_above=-999 required=5 tests=[AWL=-6.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtkLuKUoHUEB for ; Sat, 12 Mar 2011 12:12:33 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 207C33A65A6 for ; Sat, 12 Mar 2011 12:12:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1895; q=dns/txt; s=iport; t=1299960834; x=1301170434; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=rmTrHL6OM4+aE09ez3sIkOqptP2tOsmQtF5raW9ZEBM=; b=BaKLyieVVLuUhWRzhs9yNZrlpuuXKLbRsbxJ5XBajiI9eLJViLI1PAo/ Bj6UMnRt9Z3UkjrPic7f8ZFQ/dgenpS9AIzwGXP0n1HZHw7bnttnryoA1 PcNwMpBN5w//9vHpBOPpXaQiXsv6hJtwgWBiaxjK/G18pHEOAs3Moagot E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF5ie02tJXG//2dsb2JhbACmQ3ekXps7hWIEhSuHJ4NO X-IronPort-AV: E=Sophos;i="4.62,308,1297036800"; d="scan'208";a="345197851" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-5.cisco.com with ESMTP; 12 Mar 2011 20:13:54 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2CKCraR018522; Sat, 12 Mar 2011 20:13:53 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D75AA9E.3050502@acm.org> Date: Sat, 12 Mar 2011 13:16:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7855503B-EB2B-4C2A-B0E1-FC2FE11B2E8A@cisco.com> References: <4D75AA9E.3050502@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1082) Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (7) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 12 Mar 2011 20:12:41 -0000 On Mar 7, 2011, at 9:03 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > More... >=20 > A.45. Section 9 >=20 > The hash function is never defined for the chord overlay. Ouch - how embarrassing :-) Added a section 9.2. I think that all = implementation are using the top 128 bits not the bottom but please do = check I got the text the in section 9.2 right.=20 >=20 > A.46. Section 10.3 "application/pkix-cert >=20 > I think that a reference to RFC 2585 should be added here. done >=20 >=20 > Nits: > - ---- >=20 > - - Section 5.3.1.1 The definition of IpAddressPort is missing a "};" = at the end > of the select. fixed=20 >=20 > - - Section 5.3.4 The definition of SignerIdentityValue is missing a = "};" at the > end of the select. Changed to following - check this looks right to you struct { select (identity_type) { case cert_hash; HashAlgorithm hash_alg; // =46rom TLS opaque certificate_hash<0..2^8-1>; /* This structure may be extended with new types if necessary*/ }; } SignerIdentityValue; >=20 > - - Section 5.4.2.2 >=20 > s/public struct/struct/ fixed >=20 > - - Section 5.5.1.1 The definition of IceCandidate is missing a ";" at = the end of > the select. fixed=20 >=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 > iEYEARECAAYFAk11qpoACgkQ9RoMZyVa61fx3wCfZK1U1zOWlSA13OPXoVmhrhsb > mZ4AnAz+0E7ny/MI7CRvtKSOJpXg2XD+ > =3DgBto > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Sat Mar 12 12:12:55 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A56113A65A6 for ; Sat, 12 Mar 2011 12:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=5.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lB9VEGYoGwH6 for ; Sat, 12 Mar 2011 12:12:49 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id EECFE3A6A98 for ; Sat, 12 Mar 2011 12:12:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=703; q=dns/txt; s=iport; t=1299960850; x=1301170450; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=hnkJH3t9B38G42Ighc0Zr9mslOft3dltGlW1cTuDS2o=; b=dx1F4N6QscTBLiDvApfrsaA5SUvylB2tixqy3JryrqExuMZzhpyo4WI6 Pc7FmXuY0nJl6nOzxai/hzUmR1uDVVtzAih8T2aESTjfssiqL4vWPudBL xJC9puDyszK0swec0lDWHXtRQmOoCwn1L8MyK67OI65ZAJvBhQrKez+dn I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF5ie02tJXG//2dsb2JhbACmQ3ekXps7hWIEhSuHJ4NO X-IronPort-AV: E=Sophos;i="4.62,308,1297036800"; d="scan'208";a="345197875" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-5.cisco.com with ESMTP; 12 Mar 2011 20:14:09 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2CKCraS018522; Sat, 12 Mar 2011 20:14:09 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D75BABC.30606@idssoftware.com> Date: Sat, 12 Mar 2011 13:16:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8F0ACEE7-9874-4890-8E98-F12C16E0367E@cisco.com> References: <4D75BABC.30606@idssoftware.com> To: Michael Chen X-Mailer: Apple Mail (2.1082) Cc: P2PSIP WG Subject: Re: [P2PSIP] Life cycle of AppAttach connections X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 12 Mar 2011 20:12:55 -0000 Added text to indicate that this was the applications responsibility. I = think if we try and do anything else, we will end up messing up the = application traffic.=20 On Mar 7, 2011, at 10:12 PM, Michael Chen wrote: > Hi, >=20 > The current draft make no mention of the life cycle of connection = created by AppAttach. I am thinking about at lease two aspects: >=20 > 1) How to do keep-alive on connections established via AppAttach. >=20 > 2) How to terminate a connection established via AppAttach. >=20 > Any thoughts? >=20 > --Michael > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From petithug@acm.org Sun Mar 13 14:48:08 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C9BF3A6906 for ; Sun, 13 Mar 2011 14:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.157 X-Spam-Level: X-Spam-Status: No, score=-102.157 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOTQ9vYwStJG for ; Sun, 13 Mar 2011 14:48:07 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 63CB73A682E for ; Sun, 13 Mar 2011 14:48:07 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 7CDDADBCC046; Sun, 13 Mar 2011 21:49:29 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id DDF6ADBCC044 for ; Sun, 13 Mar 2011 21:49:28 +0000 (UTC) Message-ID: <4D7D3BE7.4080907@acm.org> Date: Sun, 13 Mar 2011 14:49:27 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110303 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: P2PSIP Mailing List References: <4D73F9FF.8060009@acm.org> In-Reply-To: <4D73F9FF.8060009@acm.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [P2PSIP] Configuration of Access Control Policy in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 13 Mar 2011 21:48:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/06/2011 01:17 PM, Marc Petit-Huguenin wrote: > http://datatracker.ietf.org/doc/draft-petithuguenin-p2psip-access-control/ New version available after implementing the examples. Changelog: o Changed reference from JavaScript to ECMAScript. o Changed signature from equals() to equalsHash(). o Fixed the examples following implementation. o Replaced automatic decoding of value by ECMAScript code. o Added the type of each property. o Specified that the code cannot be used to modify the value stored. - -- 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) iEYEARECAAYFAk19O+YACgkQ9RoMZyVa61fnywCeIW3ZsTmamptBeHQMdKK+qKdy uYsAoIDypTMeF29/+N60pCFG785XRK0F =GzxY -----END PGP SIGNATURE----- From prvs=0471cc083=Alexander.Knauf@haw-hamburg.de Mon Mar 14 13:08:27 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11D33A69A3 for ; Mon, 14 Mar 2011 13:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAP0oPqzCZXA for ; Mon, 14 Mar 2011 13:08:27 -0700 (PDT) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by core3.amsl.com (Postfix) with ESMTP id B6E293A6808 for ; Mon, 14 Mar 2011 13:08:26 -0700 (PDT) Received: from dehawshub02.mailcluster.haw-hamburg.de ([141.22.200.52]) by mail6.is.haw-hamburg.de with ESMTP/TLS/RC4-MD5; 14 Mar 2011 21:09:49 +0100 Received: from dehawscas02.mailcluster.haw-hamburg.de (141.22.200.34) by DEHAWSHUB02.mailcluster.haw-hamburg.de (141.22.200.52) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 14 Mar 2011 21:09:50 +0100 Received: from [141.22.26.154] (141.22.200.51) by haw-mailer.haw-hamburg.de (141.22.200.80) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 14 Mar 2011 21:09:49 +0100 Message-ID: <4D7E760F.3030807@haw-hamburg.de> Date: Mon, 14 Mar 2011 21:09:51 +0100 From: Alexander Knauf User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: P2PSIP Mailing List Content-Type: multipart/alternative; boundary="------------030405070907090304060100" Subject: [P2PSIP] Fwd: New Version Notification for draft-knauf-p2psip-disco-02 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 14 Mar 2011 20:08:27 -0000 --------------030405070907090304060100 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Hi all, we just submitted a new version of our Distributed Conferencing draft (DisCo). It is available at: http://tools.ietf.org/id/draft-knauf-p2psip-disco-02.txt We are looking forward to your comments. Best Regards Alexander The following changes have been made from version draft-knauf-p2psip-disco-01. 1. The conference registration is now based on the Shared Resources draft [I-D.knauf-p2psip-share]: * DisCo-Registration Kind now meets the requirements for ShaRe. * Conference creation procedure now uses the ShaRe Access List. * Replaced USER-CHAIN-MATCH access policy for DisCo- Registration. Now uses USER-CHAIN-ACL or USER-PATTERN-MATCH. 2. Allow focus peers behind NAT 3. Added a 'node-id' attribute to the event package XML element. 4. Added a 'node-id' attribute to the event package XML element. 5. Added a 'coordinate' child element to the event package XML element. 6. Corrected typos/wording --------------030405070907090304060100 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit Hi all,

we just submitted a new version of our Distributed Conferencing draft (DisCo).

It is available at:
http://tools.ietf.org/id/draft-knauf-p2psip-disco-02.txt


We are looking forward to your comments.

Best Regards
 Alexander




The following changes have been made from version
   draft-knauf-p2psip-disco-01.

   1.  The conference registration is now based on the Shared Resources
       draft [I-D.knauf-p2psip-share]:

       *  DisCo-Registration Kind now meets the requirements for ShaRe.

       *  Conference creation procedure now uses the ShaRe Access List.

       *  Replaced USER-CHAIN-MATCH access policy for DisCo-
          Registration.  Now uses USER-CHAIN-ACL or USER-PATTERN-MATCH.

   2.  Allow focus peers behind NAT

   3.  Added a 'node-id' attribute to the event package XML <version>
       element.

   4.  Added a 'node-id' attribute to the event package XML <focus>
       element.

   5.  Added a 'coordinate' child element to the event package XML
       <focus> element.

   6.  Corrected typos/wording

--------------030405070907090304060100-- From fluffy@cisco.com Mon Mar 14 16:52:23 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4456F3A6B8B for ; Mon, 14 Mar 2011 16:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=3.700, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sTJyuMIQ7sZ for ; Mon, 14 Mar 2011 16:52:20 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 609CC3A7005 for ; Mon, 14 Mar 2011 16:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1549; q=dns/txt; s=iport; t=1300146824; x=1301356424; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=n9gpVEUU8D+r0Hl9VF3AWABFE/a5H84OqGUEKWlEChU=; b=TqBD1TsTFyhRZMCaLE94H8Zwt0QIu53QIww3aVEKBcOX7QZ1moNDb+1h lmBHEHqNb+ZE+8sV4o+En4ZZpamVRTot2NyCdX/xdxZjbW9arPEKiN9re WFMK2rBV2iWx9Ck7k6qW9MmF5RPclqiQjRu5hDFMod6TZiOHCH0BzOG7h 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADtHfk2tJXHB/2dsb2JhbACmDXelRJxGhWIEhSuHJ4NO X-IronPort-AV: E=Sophos;i="4.62,319,1297036800"; d="scan'208";a="346483622" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-5.cisco.com with ESMTP; 14 Mar 2011 23:53:44 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2ENrdJP006819; Mon, 14 Mar 2011 23:53:44 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D792070.3080907@acm.org> Date: Mon, 14 Mar 2011 17:56:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D75AA9E.3050502@acm.org> <4D792070.3080907@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1082) Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (8) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 14 Mar 2011 23:52:23 -0000 On Mar 10, 2011, at 12:03 PM, Marc Petit-Huguenin wrote: >=20 > A.48. Section 13.7 >=20 > The "RELOAD Data Model" registry contains a Code value which is on = fact never > used anywhere. I think it would be simpler to remove this (like it is = done for > the Access Control Policies) and redefine DataModel in section 6.2 = like this: >=20 > enum { single_value, array, dictionary } DataModel; just removed it=20 >=20 > BTW, the select in 6.4.2.1 uses "model" instead of "DataModel." fixed >=20 >=20 > A.49. Section 10.1.1 >=20 > The Data Model, Access Control Policy and Kind names permitted in the = schema > does not and cannot match the definitions in the various IANA = registries, > because of the case. E.g. the Data Model registry contains = "USER-MATCH" but the > schema only accept "user-match". I suggest to replace the definition = of > "user-match" and other strings by the following: >=20 > access-control-type |=3D xsd:token { pattern =3D > "[uU][sS][eE][rR]-[mM][aA][tT][cC][hH]" } I sort of hate the cause incentive stuff - it just seem to introduce = bugs and some people do it and some mess it up and just use what is in = the examples. Given this is all for machine not human consumptions, I = moved it all to upper cases. If this breaks anyones implementation, lets = talk sort out what to do. I only choose upper case over lower case as it = seemed to match what was in the IANA registries. That contradicts the = relaxNG but I don't think many people had used the relaxNG.=20 From fluffy@cisco.com Mon Mar 14 16:52:34 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB8583A701B for ; Mon, 14 Mar 2011 16:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.216 X-Spam-Level: X-Spam-Status: No, score=-107.216 tagged_above=-999 required=5 tests=[AWL=3.383, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqzZLyneNxWh for ; Mon, 14 Mar 2011 16:52:32 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 509FC3A6B8B for ; Mon, 14 Mar 2011 16:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3271; q=dns/txt; s=iport; t=1300146836; x=1301356436; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=KYD9cwzoLuhjhHjOxkOw1kuukVvUj+EAPr4o5eKDUHM=; b=jESkRF/+mgiiDR4ewJmKU31UUKENaDVK33jGlPyg9htfGHrpOmkaxsgG UTxIZ5OA+xXMeVo5yuMGdncQj4osxoEx+GebOWqQiq0Bl/OzdaYOxTx9X JE5cC7Ux2IMjm1elEi1NB9Hrgg9i10giU1tQ5e061HbH++TnJ6g4xfCwD k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADtHfk2tJXHB/2dsb2JhbACmDXelRJxGhWIEhSuHJ4NO X-IronPort-AV: E=Sophos;i="4.62,319,1297036800"; d="scan'208";a="346483797" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-5.cisco.com with ESMTP; 14 Mar 2011 23:53:56 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2ENrdJQ006819; Mon, 14 Mar 2011 23:53:55 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D2BA199.5080105@acm.org> Date: Mon, 14 Mar 2011 17:56:41 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D2BA199.5080105@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1082) Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (4) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 14 Mar 2011 23:52:34 -0000 On Jan 10, 2011, at 5:17 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > More comments: >=20 > A.30. Section 5.5.4.1 "opaque config_data<0..2^24-1>" >=20 > If a configuration document contains multiple configuration elements = (and I > guess multiple matching signature elements), then should not = config_data been in > fact structured the same way than kinds?, i.e. an XML fragment = containing only > the configuration element and the signature element for this overlay, = extracted > from the multiple configuration elements document? >=20 > See also A.31 below. >=20 > A.31. Section 1.1 'The file can contain multiple "configuration" = elements..." >=20 > This contradicts the RELAX NG grammar in section 10.1.1. In addition, = should > not configuration elements be structured as kind elements are, i.e. = something > like this: >=20 > > > ... > ... > > > ... > ... > > >=20 > In this case, config_data would contain a XML configuration-block = production > (see A.31 above) I changed the grammar to allow > >=20 > ... > ... >=20 > ... > ... >=20 > I like the config-block would be better but it would break existing = stuff so I made the grammar match the existing text which seemed to = allow the above. Thoughts on what we should do here? I have no strong = opinion - fundamentally they are both about the same.=20 >=20 > A.32. Section 10.1 "root-cert: [...] there can be more than one = root-cert element" >=20 > This contradicts the RELAX NG grammar in section 10.1.1. fixed >=20 > A.33. Section 10.1 "enrollment-server: [...] there can be more than = one > enrollment-server element" >=20 > This contradicts the RELAX NG grammar in section 10.1.1. fixed >=20 > A.34. Section 10.1 'multicast-bootstrap: [...] it has an attribute = called > "address" [...] and an attribute called "port"' >=20 > This contradicts the RELAX NG grammar in section 10.1.1 (hostPort). fixed=20 >=20 > A.35. Section 10.1.1 "parameter &=3D element required-kinds { = kind-block* }" >=20 > Because the text in section 10.1. says that "[i]nside each overlay = element, the > required-kinds element can also occur", I think it should be this = instead: >=20 > parameter &=3D element required-kinds { kind-block+ }? >=20 fixed=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.10 (GNU/Linux) >=20 > iEYEARECAAYFAk0roZgACgkQ9RoMZyVa61fN/wCcCZk9KcSDiVZz2u4E+KVfl2Es > w3oAoIYvjgqZv3Lwwt73VSRA03uSlFrg > =3D/1lC > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From Internet-Drafts@ietf.org Mon Mar 14 17:00:03 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B35E63A68AB; Mon, 14 Mar 2011 17:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDxd78WwnqGv; Mon, 14 Mar 2011 17:00:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30EBE3A6F0E; Mon, 14 Mar 2011 17:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110315000002.23483.34973.idtracker@localhost> Date: Mon, 14 Mar 2011 17:00:02 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-base-13.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 00:00:03 -0000 --NextPart 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) : C. Jennings, et al. Filename : draft-ietf-p2psip-base-13.txt Pages : 157 Date : 2011-03-14 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. Legal THIS DOCUMENT AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON AN "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE, DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-p2psip-base-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14165051.I-D@ietf.org> --NextPart-- From fluffy@cisco.com Mon Mar 14 17:39:31 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A7E03A696C for ; Mon, 14 Mar 2011 17:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.699 X-Spam-Level: X-Spam-Status: No, score=-107.699 tagged_above=-999 required=5 tests=[AWL=2.900, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXOezV3ztGSo for ; Mon, 14 Mar 2011 17:39:30 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EF8CE3A68AC for ; Mon, 14 Mar 2011 17:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3763; q=dns/txt; s=iport; t=1300149653; x=1301359253; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=eYQgiruEfJuXH1L5WTBajXW97xalHnez1v/k8sMx20A=; b=NtRhKcSDjljobTTOwa1y7TK45Zy/MhxqMrj/iwcPXYhErROsL4LAQRKU FaaJxiSgIKZuiE+rCTd3VcRbCI1wdlHI+79mZKzupRZdk9K9ciO9QnCSH etZF1T1GMSA2qCegYbF4b96Lh9w4gEFXc7J6rONuNFESCgLUyMxdi0Ez0 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALZSfk2tJXG8/2dsb2JhbACmDnelUpxPhWIEhSuHJ4NO X-IronPort-AV: E=Sophos;i="4.62,319,1297036800"; d="scan'208";a="667108679" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-6.cisco.com with ESMTP; 15 Mar 2011 00:40:53 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2F0eqc0021153 for ; Tue, 15 Mar 2011 00:40:52 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Mar 2011 18:43:37 -0600 Message-Id: To: P2PSIP Mailing List Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [P2PSIP] Isssues not fixed in draft-ietf-p2psip-base-13 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 00:39:31 -0000 There are a few things that did not get fixed in the -13 draft. Some due = to just not sure how to fix them yet and some due to lack of time. The = remanning open items are=20 We need to update a few things to clarify usage when certificates have = multiple node-id. Proposal is to say that, in cases other than when = signaling a bootstrap peer, the first message is an Attach. The node-id = used in the SignerIdentity of the Attach would indicate the node-id that = this connection represented. The SignerIdentity still has to be one of = the node-is in the certificate or the message is rejected. The same = approach works for the non certificate based security modes. I realize = this paragraph is clear as mud - we will work on better text. I may have = misunderstood some of the email on this but I think this is the proposal = from Marc, Bruce, and EKR.=20 In section 6.3.4, it is not specified how to encode i into the hash. I'm = proposing treating it as a uint32 and hashing that.=20 > A.39. Section 6.2.2 >=20 > I am not really sure to understand how the "exists=3DFalse" are = synthesized when > doing a Fetch on an array. For example if a Store was made for an = object with > an index of 0xfffffffe, and the Fetch requests the whole array, will = the answer > contains 4294967294 "exists=3DFalse" objects?=20 Proposal: Yes > Also how are this synthesized elements signed? Proposal:=20 The "opaque value<0..2^32-1>;" would just indicate a 0 byte long binary = blog and be encoded per normal.=20 > A.40. Section 6.4.3.2 >=20 > If exist is False, should the hash_value be the hash value of an empty = byte > array (i.e. da39a3ee5e6b4b0d3255bfef95601890afd80709 for SHA-1) or be = omitted? Proposal:=20 empty byte array ... keep the code path all the same with no special = rules for exists =3D=3D False. Keep in mind that you need to "sign" a = delete of an entry and have that interact properly when a partitioned = overlay merges" > A.43. Section 10.1 Element signature >=20 > What certificate should be used to compute (and verify) the signature = for the > whole configuration file? Proposal:=20 Add a to the configuration that is much like the = but says who can sing the configuration file. IN the case = of the first time you get a configuration file, that could come at same = time as enrollment and be secured that way.=20 > A.47. Section 6.3 >=20 > The four policies defined in p2psip-base consistently says that "[a] = given value > MUST be written (or overwritten) if and only if the request is signed = ..." > Additional access control policies defined elsewhere use similar = wording. >=20 > But should not the StoredData signature be used instead of the request > signature? When replicating the data, the signer of the StoreRequest = will be > different from the signer of the original request and so the test will = no longer > work. Section 6.4.1.1 says that "[a] peer MUST [check that] [e]ach = element is > signed by a credential which is authorized to write this kind at this > Resource-ID.", which seems to confirm that this is the element's = signature that > must be checked, not the request's. So the elements sig need to be checked for sure. The questions is should = the request sig also be checked before that. Unless we can say how to = check it, seems like bad idea. Proposal: remove this or clarify.=20 > A.38. Section 5.5.1.1. 'rel_addr_port corresponds to the rel-addr and = rel-port > productions. Only present for type "relay".' >=20 > In ICE, the rel address and port are also present for srflx and prflx = candidates. my brain hurts. Proposal: go for beer From petithug@acm.org Tue Mar 15 09:02:15 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CDD53A6929 for ; Tue, 15 Mar 2011 09:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.162 X-Spam-Level: X-Spam-Status: No, score=-102.162 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uc9Fg4Z2ZPF2 for ; Tue, 15 Mar 2011 09:02:14 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 5B2513A6D76 for ; Tue, 15 Mar 2011 09:02:14 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id CEF44DBCC046; Tue, 15 Mar 2011 16:03:38 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 01EE7DBCC044; Tue, 15 Mar 2011 16:03:37 +0000 (UTC) Message-ID: <4D7F8DD9.6070006@acm.org> Date: Tue, 15 Mar 2011 09:03:37 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110303 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Cullen Jennings References: <4D4F31EC.5020009@acm.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (5) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 16:02:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/12/2011 12:15 PM, Cullen Jennings wrote: >> >> >> A.41. Section 10.1 expiration definition >> >> I think that it would be a good idea to say that a Node should wait a random >> time after the expiration time before retrieving the file again from the >> configuration server to not crash it and to let ConfigUpdate do its job. >> > > Makes sense. I'm going to add the text > > The peer SHOULD retrieve a new copy of the configuration at a randomly selected time that is before the expiration time. > > I'm not all that happy with that text it someone wants to suggest something better. It does not tell the implementors what range to select the time over but it's not clear we have to be that specific. One of the reason to use the expiration value is to force the clients to reload a new version of the configuration document before the root cert expires. For this reason I would suggest to add something like this: "The expiration time MUST be lower than the highest expiration time of the root certificates listed in the configuration element." As for the range, I would suggest something like this: "The node SHOULD start retrieving a new copy at a time randomly selected between the expiration time minus 10 days and the expiration time. If the copy returned is not newer than the current copy, then the node SHOULD retry at a time randomly selected between the time of the previous attempt and the expiration time, until a new copy is received or the expiration date is reached." - -- 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) iEYEARECAAYFAk1/jdcACgkQ9RoMZyVa61cd5ACfZhfSRUM9sszzU9yoGaxT6KpR +Z8An2O+I4Q7hu71rtCrTBhOmWwSyUzG =7+68 -----END PGP SIGNATURE----- From bortzmeyer@nic.fr Tue Mar 15 09:48:00 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117DC3A6D32 for ; Tue, 15 Mar 2011 09:48:00 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0ONbbwf5L8S for ; Tue, 15 Mar 2011 09:47:59 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) by core3.amsl.com (Postfix) with ESMTP id C27CE3A6C5B for ; Tue, 15 Mar 2011 09:47:58 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 6639D7409E; Tue, 15 Mar 2011 17:49:22 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 62E9E1579BA; Tue, 15 Mar 2011 09:49:00 -0700 (PDT) Date: Tue, 15 Mar 2011 09:49:00 -0700 From: Stephane Bortzmeyer To: P2PSIP WG Message-ID: <20110315164900.GA21958@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Transport: UUCP rules X-Operating-System: Ubuntu 10.04 (lucid) User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [P2PSIP] GNU Free Call Announced X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 16:48:00 -0000 Relevant, I believe. http://planet.gnu.org/gnutelephony/?p=14 GNU Free Call Announced "Free as in freedom, and free as in no cost, too!" GNU Free Call is a new project to develop and deploy secure self-organized communication services worldwide for private use and for public administration. We use the open standard SIP protocol and GNU SIP Witch to create secured peer-to-peer mesh calling networks, and we welcome all participation in our effort. From petithug@acm.org Tue Mar 15 09:50:27 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0E543A6D25 for ; Tue, 15 Mar 2011 09:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.167 X-Spam-Level: X-Spam-Status: No, score=-102.167 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzdsrqBuve0u for ; Tue, 15 Mar 2011 09:50:26 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id B66923A6C5B for ; Tue, 15 Mar 2011 09:50:26 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id E6CA5DBCC048; Tue, 15 Mar 2011 16:51:50 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 57CFFDBCC046; Tue, 15 Mar 2011 16:51:50 +0000 (UTC) Message-ID: <4D7F9925.1080600@acm.org> Date: Tue, 15 Mar 2011 09:51:49 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110303 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Cullen Jennings References: <4D2BA199.5080105@acm.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (4) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 16:50:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/14/2011 04:56 PM, Cullen Jennings wrote: > > On Jan 10, 2011, at 5:17 PM, Marc Petit-Huguenin wrote: > > More comments: > > A.30. Section 5.5.4.1 "opaque config_data<0..2^24-1>" > > If a configuration document contains multiple configuration elements (and I > guess multiple matching signature elements), then should not config_data been in > fact structured the same way than kinds?, i.e. an XML fragment containing only > the configuration element and the signature element for this overlay, extracted > from the multiple configuration elements document? > > See also A.31 below. > > A.31. Section 1.1 'The file can contain multiple "configuration" elements..." > > This contradicts the RELAX NG grammar in section 10.1.1. In addition, should > not configuration elements be structured as kind elements are, i.e. something > like this: > > > > ... > ... > > > ... > ... > > > > In this case, config_data would contain a XML configuration-block production > (see A.31 above) > >> I changed the grammar to allow > > > > ... > ... > > ... > ... > > > >> I like the config-block would be better but it would break existing stuff so I made the grammar match the existing text which seemed to allow the above. Thoughts on what we should do here? I have no strong opinion - fundamentally they are both about the same. Having no config-block makes this fragment valid: But in fact I am withdrawing my suggestion in A.30 to use the config-block in the ConfigUpdateReq, instead of the whole overlay: There is nothing that prevent an implementation to send a document with only one configuration and signature element in the ConfigUpdateReq, even if the document retrieved from the configuration server contains more than one. So my suggestion would be to keep thing as they are, but add text that explain the configuration/signature elements should be interleaved and that a signature element applies only to the configuration element immediately preceding. Perhaps enforcing this in the RelaxNG schema could also be a good thing. - -- 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) iEYEARECAAYFAk1/mSQACgkQ9RoMZyVa61d/dQCeNobyVwaCD6N9Co+gGytx3swd kpkAn0qLyJqgnMuygjIhsfgGZATawC0f =opRp -----END PGP SIGNATURE----- From petithug@acm.org Tue Mar 15 10:21:46 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 998363A6D39 for ; Tue, 15 Mar 2011 10:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.871 X-Spam-Level: X-Spam-Status: No, score=-101.871 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcxMusxpCSrk for ; Tue, 15 Mar 2011 10:21:45 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 68A843A6D76 for ; Tue, 15 Mar 2011 10:21:45 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 6B311DBCC046; Tue, 15 Mar 2011 17:23:07 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 9BC78DBCC044; Tue, 15 Mar 2011 17:23:06 +0000 (UTC) Message-ID: <4D7FA079.3090501@acm.org> Date: Tue, 15 Mar 2011 10:23:05 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110303 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Isssues not fixed in draft-ietf-p2psip-base-13 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 17:21:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Please see below for additional items that are not fixed in -13. I'll respond in separate emails to your proposals. On 03/14/2011 05:43 PM, Cullen Jennings wrote: > > There are a few things that did not get fixed in the -13 draft. Some due to just not sure how to fix them yet and some due to lack of time. The remanning open items are > > > We need to update a few things to clarify usage when certificates have multiple node-id. Proposal is to say that, in cases other than when signaling a bootstrap peer, the first message is an Attach. The node-id used in the SignerIdentity of the Attach would indicate the node-id that this connection represented. The SignerIdentity still has to be one of the node-is in the certificate or the message is rejected. The same approach works for the non certificate based security modes. I realize this paragraph is clear as mud - we will work on better text. I may have misunderstood some of the email on this but I think this is the proposal from Marc, Bruce, and EKR. > > > In section 6.3.4, it is not specified how to encode i into the hash. I'm proposing treating it as a uint32 and hashing that. > > > >> A.39. Section 6.2.2 >> >> I am not really sure to understand how the "exists=False" are synthesized when >> doing a Fetch on an array. For example if a Store was made for an object with >> an index of 0xfffffffe, and the Fetch requests the whole array, will the answer >> contains 4294967294 "exists=False" objects? > > Proposal: Yes > >> Also how are this synthesized elements signed? > > Proposal: > The "opaque value<0..2^32-1>;" would just indicate a 0 byte long binary blog and be encoded per normal. > > >> A.40. Section 6.4.3.2 >> >> If exist is False, should the hash_value be the hash value of an empty byte >> array (i.e. da39a3ee5e6b4b0d3255bfef95601890afd80709 for SHA-1) or be omitted? > > Proposal: > empty byte array ... keep the code path all the same with no special rules for exists == False. Keep in mind that you need to "sign" a delete of an entry and have that interact properly when a partitioned overlay merges" > > >> A.43. Section 10.1 Element signature >> >> What certificate should be used to compute (and verify) the signature for the >> whole configuration file? > > > Proposal: > Add a to the configuration that is much like the but says who can sing the configuration file. IN the case of the first time you get a configuration file, that could come at same time as enrollment and be secured that way. > >> A.47. Section 6.3 >> >> The four policies defined in p2psip-base consistently says that "[a] given value >> MUST be written (or overwritten) if and only if the request is signed ..." >> Additional access control policies defined elsewhere use similar wording. >> >> But should not the StoredData signature be used instead of the request >> signature? When replicating the data, the signer of the StoreRequest will be >> different from the signer of the original request and so the test will no longer >> work. Section 6.4.1.1 says that "[a] peer MUST [check that] [e]ach element is >> signed by a credential which is authorized to write this kind at this >> Resource-ID.", which seems to confirm that this is the element's signature that >> must be checked, not the request's. > > So the elements sig need to be checked for sure. The questions is should the request sig also be checked before that. Unless we can say how to check it, seems like bad idea. Proposal: remove this or clarify. > >> A.38. Section 5.5.1.1. 'rel_addr_port corresponds to the rel-addr and rel-port >> productions. Only present for type "relay".' >> >> In ICE, the rel address and port are also present for srflx and prflx candidates. > > my brain hurts. Proposal: go for beer > A.12 Section 10.3 states that "[t]he SubjectAltName field in the certificate contains the following values: One or more Node-IDs...", but nowhere it is said how to request multiple Node-IDs. Is it an URL parameter of the POST request? An attribute in the Certification Request object? EKR: "Good question. This is an issue that's simply not addressed in the draft., but presumably we'll need to do something like this, yeah. My taste would be for it to be a URL in the POSt." CJ: "It's not really defined in this draft how to have Certificates with multiple node-id. There are some arguments about if multiple node ids are useful or not - The goal here is just to make sure that option is left open if a future extension does this. A parameter on the post URL sounds like a good approach." A.24. Section 10.1.1. "| attribute id { xsd:int })," Does not match 13.6, that is saying that this is an unsigned integer. Should probably use xsd:unsignedInt instead. (the private kind ids, 4026531844 and up, cannot be used with this definition). - -- 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) iEYEARECAAYFAk1/oHcACgkQ9RoMZyVa61fhdQCfcJkRvC8OBng8QJ0EOEk3CY9R 8dYAoKJ3Q8n4SW71Pn499FWEau6k87gm =roHV -----END PGP SIGNATURE----- From petithug@acm.org Tue Mar 15 10:51:39 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 205B73A6A24 for ; Tue, 15 Mar 2011 10:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.162 X-Spam-Level: X-Spam-Status: No, score=-102.162 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9g7H2HcDKxW for ; Tue, 15 Mar 2011 10:51:37 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id A3DEE3A6E1D for ; Tue, 15 Mar 2011 10:51:36 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id B82F6DBCC044; Tue, 15 Mar 2011 17:53:01 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 08E226C9845C; Tue, 15 Mar 2011 17:53:00 +0000 (UTC) Message-ID: <4D7FA77C.6090103@acm.org> Date: Tue, 15 Mar 2011 10:53:00 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110303 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: [P2PSIP] Multiple Node-IDs [was Isssues not fixed in draft-ietf-p2psip-base-13] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 17:51:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/14/2011 05:43 PM, Cullen Jennings wrote: > > There are a few things that did not get fixed in the -13 draft. Some due to > just not sure how to fix them yet and some due to lack of time. The remanning > open items are > > > We need to update a few things to clarify usage when certificates have > multiple node-id. Proposal is to say that, in cases other than when signaling > a bootstrap peer, the first message is an Attach. The node-id used in the > SignerIdentity of the Attach would indicate the node-id that this connection > represented. The SignerIdentity still has to be one of the node-is in the > certificate or the message is rejected. The same approach works for the non > certificate based security modes. I realize this paragraph is clear as mud - > we will work on better text. I may have misunderstood some of the email on > this but I think this is the proposal from Marc, Bruce, and EKR. Here's my proposal: Section 3.2.1: " o Establish a connection with an arbitrary peer in the overlay (perhaps based on network proximity or an inability to establish a direct connection with the responsible peer). In this case, the client will rely on RELOAD's Destination List feature to ensure reachability. The client can initiate requests, and any node in the overlay that knows the Destination List to its current location can reach it, but the client is not directly reachable using only its Node-ID. If the client is to receive incoming requests from other members of the overlay, the Destination List required to reach it must be learnable via other mechanisms, such as being stored in the overlay by a usage. If the certificate used by the client contains multiple Node-IDs, the client MUST immediately send a Ping request with a wildcard Node-ID, so the client and peer can learn each other Node-Id." Section 5.1 " o The first entry on the destination list is an ID for which the peer is responsible. A peer is always responsible for the wildcard Node-ID." Section 5.1.1 " o If the entry is a Resource-ID, then it MUST be the only entry on the destination list. If there are other entries, the message MUST be silently dropped. Otherwise, the message is destined for this node and it passes it up to the upper layers. o If the entry is the wildcard Node-ID, the message is destined for this node and it passes it up to the upper layers." Section 5.3.4: " enum { reservedSignerIdentity(0), cert_hash(1), cert_hash_node_id(2) (255)} SignerIdentityType; struct { select (identity_type) { case cert_hash: HashAlgorithm hash_alg; // From TLS opaque certificate_hash<0..2^8-1>; case cert_hash_node_id: HashAlgorithm hash_alg; // From TLS opaque certificate_hash<0..2^8-1>; NodeId node_id; /* This structure may be extended with new types if necessary*/ }; } SignerIdentityValue; struct { SignerIdentityType identity_type; uint16 length; SignerIdentityValue identity[SignerIdentity.length]; } SignerIdentity; struct { SignatureAndHashAlgorithm algorithm; // From TLS SignerIdentity identity; opaque signature_value<0..2^16-1>; } Signature; The signature construct contains the following values: algorithm The signature algorithm in use. The algorithm definitions are found in the IANA TLS SignatureAlgorithm Registry. All implementations MUST support RSASSA-PKCS1-v1_5 [RFC3447] signatures with SHA-256 hashes. identity The identity used to form the signature. signature_value The value of the signature. The identity format can take two forms, depending if the certificate contains one or more Node-IDs. If the certificate contains only one Node-ID, the cert_hash is used The hash_alg field is used to indicate the algorithm used to produce the hash. The certificate_hash contains the hash of the certificate object (i.e., the DER-encoded certificate). If the certificate contains more than one Node-ID, the cert_hash_node_id form is used, with node_id containing the Node-ID selected." - -- 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) iEYEARECAAYFAk1/p3oACgkQ9RoMZyVa61eNBQCfX+eI0wF1JDA5yEnMQYrf/8hY I/EAniINgUsB4zqYOzOcN62bhNl9tt/N =0+mS -----END PGP SIGNATURE----- From petithug@acm.org Tue Mar 15 11:17:47 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1AA03A6DE3 for ; Tue, 15 Mar 2011 11:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.867 X-Spam-Level: X-Spam-Status: No, score=-101.867 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXa0MexoYa2E for ; Tue, 15 Mar 2011 11:17:47 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 0648A3A6B10 for ; Tue, 15 Mar 2011 11:17:47 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 0A6DDDBCC044; Tue, 15 Mar 2011 18:19:12 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 96B826C9845C; Tue, 15 Mar 2011 18:19:11 +0000 (UTC) Message-ID: <4D7FAD9F.3050204@acm.org> Date: Tue, 15 Mar 2011 11:19:11 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110303 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: [P2PSIP] Synthesized values in array [was Isssues not fixed in draft-ietf-p2psip-base-13] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 18:17:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/14/2011 05:43 PM, Cullen Jennings wrote: > > There are a few things that did not get fixed in the -13 draft. Some due to > just not sure how to fix them yet and some due to lack of time. The remanning > open items are [...] >> A.39. Section 6.2.2 >> >> I am not really sure to understand how the "exists=False" are synthesized >> when doing a Fetch on an array. For example if a Store was made for an >> object with an index of 0xfffffffe, and the Fetch requests the whole array, >> will the answer contains 4294967294 "exists=False" objects? > > Proposal: Yes > >> Also how are this synthesized elements signed? > > Proposal: The "opaque value<0..2^32-1>;" would just indicate a 0 byte long > binary blog and be encoded per normal. > My proposal is to get rid of the synthesized elements. A Fetch returns the array with holes in it but returns the exists=False elements that were sent. This solves a lot of issues (who sign them? What is the storage_time and lifetime of a synthesized element?) - -- 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) iEYEARECAAYFAk1/rYsACgkQ9RoMZyVa61edtgCgnE/yFH4KHQvXUD1oPCdn3U0N yMkAnRgjuhL94v6b5cgHwfj9+Dmx6V/9 =a5dr -----END PGP SIGNATURE----- From petithug@acm.org Tue Mar 15 11:28:26 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED8B63A6E55 for ; Tue, 15 Mar 2011 11:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.159 X-Spam-Level: X-Spam-Status: No, score=-102.159 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZ6O8oGpcd9b for ; Tue, 15 Mar 2011 11:28:24 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 2C5273A6E4F for ; Tue, 15 Mar 2011 11:28:24 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 8C974DBCC044; Tue, 15 Mar 2011 18:29:49 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id D76D46C9845C; Tue, 15 Mar 2011 18:29:48 +0000 (UTC) Message-ID: <4D7FB01C.403@acm.org> Date: Tue, 15 Mar 2011 11:29:48 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110303 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Isssues not fixed in draft-ietf-p2psip-base-13 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 18:28:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/14/2011 05:43 PM, Cullen Jennings wrote: > > There are a few things that did not get fixed in the -13 draft. Some due to > just not sure how to fix them yet and some due to lack of time. The remanning > open items are [...] >> A.47. Section 6.3 >> >> The four policies defined in p2psip-base consistently says that "[a] given >> value MUST be written (or overwritten) if and only if the request is signed >> ..." Additional access control policies defined elsewhere use similar >> wording. >> >> But should not the StoredData signature be used instead of the request >> signature? When replicating the data, the signer of the StoreRequest will >> be different from the signer of the original request and so the test will >> no longer work. Section 6.4.1.1 says that "[a] peer MUST [check that] >> [e]ach element is signed by a credential which is authorized to write this >> kind at this Resource-ID.", which seems to confirm that this is the >> element's signature that must be checked, not the request's. > > So the elements sig need to be checked for sure. The questions is should the > request sig also be checked before that. Unless we can say how to check it, > seems like bad idea. Proposal: remove this or clarify. Well, both need to be verified, the request when it is received and the element just before been inserted in the storage. When a peer receives a Store request because of replication, it will receive a Store request that will probably have a different SignerIdentity for the request and for the elements to store. So my proposal is this: Section 6.3.1: " In the USER-MATCH policy, a given value MUST be written (or overwritten) if and only if the value is signed with a key associated with a certificate whose user name hashes (using the hash function for the overlay) to the Resource-ID for the resource. Recall that the certificate may, depending on the overlay configuration, be self-signed." Section 6.3.2: " In the NODE-MATCH policy, a given value MUST be written (or overwritten) if and only if the value is signed with a key associated with a certificate whose Node-ID hashes (using the hash function for the overlay) to the Resource-ID for the resource." Section 6.3.3: " The USER-NODE-MATCH policy may only be used with dictionary types. In the USER-NODE-MATCH policy, a given value MUST be written (or overwritten) if and only if the value is signed with a key associated with a certificate whose user name hashes (using the hash function for the overlay) to the Resource-ID for the resource. In addition, the dictionary key MUST be equal to the Node-ID in the certificate." Section 6.3.4: " In the NODE-MULTIPLE policy, a given value MUST be written (or overwritten) if and only if the value is signed with a key associated with a certificate containing a Node-ID such that H(Node-ID || i) is equal to the Resource-ID for some small integer value of i. When this policy is in use, the maximum value of i MUST be specified in the kind definition." - -- 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) iEYEARECAAYFAk1/sBsACgkQ9RoMZyVa61fLYQCfd+/Ukci0zRUI586eR5Wr0xqJ 7poAni6D8QlLlAO7jWqieLs1tvgVgNRO =gMPt -----END PGP SIGNATURE----- From ekr@skype.net Tue Mar 15 11:48:11 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3DE23A6A7C for ; Tue, 15 Mar 2011 11:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTTq8ZYeTqW9 for ; Tue, 15 Mar 2011 11:48:10 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id A5DE63A6A26 for ; Tue, 15 Mar 2011 11:48:09 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 1F78A16FF; Tue, 15 Mar 2011 19:49:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=mx; bh=48 0wnm1DHxM9DBiTDeisldZ+YIw=; b=INodLJLPlXgf4ePfhuw3aGT7dyOB9oVKhw KHsf2wD5lus6RryNqUKy5R6+tll1ba2KN1+iyngFa4o51it0jD4c+HKcRYL/4jkf vQIcvtqN805tRX1BOhAumaob58pjibpNdU9mGKPv10us3wgaT2dZ8uf0oabJ0deG Om5tva1ro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=mx; b=No7yYczg9MG6PfPBalnDzT QVmCXwXXGSlK5ILGQM4X75JmMCRYXcv6qZUZptPwLgFoeG7YsA9iHZ8nlbqQDpCi opBlxbcq8YZk2QRxdHQmV0z9h6t9yHKtEY/iSg7vzl76//Jv9jhJHO/PeypFWLCI 3sNo9NpWmhvv7hVuj0tR8= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 1DEA6CF; Tue, 15 Mar 2011 19:49:34 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id D91FA1685A02; Tue, 15 Mar 2011 19:49:31 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6DT+6knBGPF; Tue, 15 Mar 2011 19:49:30 +0100 (CET) Received: from [192.168.1.102] (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by zimbra.skype.net (Postfix) with ESMTPSA id 21E7D1CD4007; Tue, 15 Mar 2011 19:49:23 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Eric Rescorla In-Reply-To: <4D7FAD9F.3050204@acm.org> Date: Tue, 15 Mar 2011 11:50:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <283BCBA5-9C56-460B-A139-82F09EDD5D8C@skype.net> References: <4D7FAD9F.3050204@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1082) Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Synthesized values in array [was Isssues not fixed in draft-ietf-p2psip-base-13] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 18:48:11 -0000 On Mar 15, 2011, at 11:19 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 03/14/2011 05:43 PM, Cullen Jennings wrote: >>=20 >> There are a few things that did not get fixed in the -13 draft. Some = due to >> just not sure how to fix them yet and some due to lack of time. The = remanning >> open items are >=20 > [...] >=20 >>> A.39. Section 6.2.2 >>>=20 >>> I am not really sure to understand how the "exists=3DFalse" are = synthesized >>> when doing a Fetch on an array. For example if a Store was made for = an >>> object with an index of 0xfffffffe, and the Fetch requests the whole = array, >>> will the answer contains 4294967294 "exists=3DFalse" objects? >>=20 >> Proposal: Yes >>=20 >>> Also how are this synthesized elements signed? >>=20 >> Proposal: The "opaque value<0..2^32-1>;" would just indicate a 0 byte = long >> binary blog and be encoded per normal. >>=20 >=20 > My proposal is to get rid of the synthesized elements. A Fetch = returns the > array with holes in it but returns the exists=3DFalse elements that = were sent. >=20 > This solves a lot of issues (who sign them? What is the storage_time = and > lifetime of a synthesized element?) Hi Marc, I think I'm the person who put this text in originally but it's been a = while so I'm trying to reconxtruct my reasoning. Let's ignore arrays for a second and just talk about simple elements. A = requester asks for objects with resource-ids A, B, and C, but B doesn't exist and so he = just gets A and C. Now he has to remember what he asked for and do some set intersection to see = what was and wasn't returned. By contrast, if you get back an answer for every = request, then it's simpler to understand the response. I'm not saying that it's impossible to do the = former, but the latter is easier. Now, when we come to arrays, life is more complicated, since I might ask = for either element i or elements i..j. We could have the rule that we never return = synthesized elements for arrays, or that we only do so for explicit as opposed to = range queries, or that we always do. All of these are consistent, I think. Anyway, you may or may not find the original rationale compelling--I'm = not sure if I still do--but IIRC that was the reason. -Ekr From petithug@acm.org Tue Mar 15 12:34:14 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FE123A6E63 for ; Tue, 15 Mar 2011 12:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.863 X-Spam-Level: X-Spam-Status: No, score=-101.863 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBnJtxgaiFgF for ; Tue, 15 Mar 2011 12:34:13 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 4AE473A6B44 for ; Tue, 15 Mar 2011 12:34:13 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 9704DDBCC044; Tue, 15 Mar 2011 19:35:38 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id C731B6C9845C; Tue, 15 Mar 2011 19:35:36 +0000 (UTC) Message-ID: <4D7FBF88.9070007@acm.org> Date: Tue, 15 Mar 2011 12:35:36 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110303 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Eric Rescorla References: <4D7FAD9F.3050204@acm.org> <283BCBA5-9C56-460B-A139-82F09EDD5D8C@skype.net> In-Reply-To: <283BCBA5-9C56-460B-A139-82F09EDD5D8C@skype.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Synthesized values in array [was Isssues not fixed in draft-ietf-p2psip-base-13] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 15 Mar 2011 19:34:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/15/2011 11:50 AM, Eric Rescorla wrote: > > On Mar 15, 2011, at 11:19 AM, Marc Petit-Huguenin wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 03/14/2011 05:43 PM, Cullen Jennings wrote: >>> >>> There are a few things that did not get fixed in the -13 draft. Some due to >>> just not sure how to fix them yet and some due to lack of time. The remanning >>> open items are >> >> [...] >> >>>> A.39. Section 6.2.2 >>>> >>>> I am not really sure to understand how the "exists=False" are synthesized >>>> when doing a Fetch on an array. For example if a Store was made for an >>>> object with an index of 0xfffffffe, and the Fetch requests the whole array, >>>> will the answer contains 4294967294 "exists=False" objects? >>> >>> Proposal: Yes >>> >>>> Also how are this synthesized elements signed? >>> >>> Proposal: The "opaque value<0..2^32-1>;" would just indicate a 0 byte long >>> binary blog and be encoded per normal. >>> >> >> My proposal is to get rid of the synthesized elements. A Fetch returns the >> array with holes in it but returns the exists=False elements that were sent. >> >> This solves a lot of issues (who sign them? What is the storage_time and >> lifetime of a synthesized element?) > > Hi Marc, > > I think I'm the person who put this text in originally but it's been a while so I'm trying to reconxtruct > my reasoning. > > Let's ignore arrays for a second and just talk about simple elements. A requester asks for > objects with resource-ids A, B, and C, but B doesn't exist and so he just gets A and C. Now > he has to remember what he asked for and do some set intersection to see what was and > wasn't returned. By contrast, if you get back an answer for every request, then it's simpler to > understand the response. I'm not saying that it's impossible to do the former, but the latter > is easier. Aaaah. My reading of the spec was that elements were synthesized only for arrays. Now I get it. "exists=False" is used in fact for two different functions: to remove an existing element, and as a placeholder for no-existence when retrieving data. In this case I withdraw my proposal to get rid of them, but I still have the question about the signer of the synthesized element (also the storage_time and lifetime to use). > > Now, when we come to arrays, life is more complicated, since I might ask for either > element i or elements i..j. We could have the rule that we never return synthesized > elements for arrays, or that we only do so for explicit as opposed to range queries, > or that we always do. All of these are consistent, I think. > > Anyway, you may or may not find the original rationale compelling--I'm not sure if I still do--but > IIRC that was the reason. Yeah, and removing an element could have been done by updating it with lifetime=0, which would have permit to remove the "exists". Anyway, let's keep things as they are. - -- 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) iEYEARECAAYFAk1/v4UACgkQ9RoMZyVa61ed5QCdFaUgzBD9TZwN3EwVMn1JMuyt IlgAn2V5d5cvsgPSR3CVZc1yt6BCnE4O =RsO/ -----END PGP SIGNATURE----- From petithug@acm.org Tue Mar 15 17:39:42 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 048393A6F38 for ; Tue, 15 Mar 2011 17:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DV-I2-1f5sne for ; Tue, 15 Mar 2011 17:39:40 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id AB0A53A68CE for ; Tue, 15 Mar 2011 17:39:40 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 9C45ADBCC046; Wed, 16 Mar 2011 00:41:05 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id AE500DBCC044; Wed, 16 Mar 2011 00:41:04 +0000 (UTC) Message-ID: <4D80071F.7030801@acm.org> Date: Tue, 15 Mar 2011 17:41:03 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110303 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: Cullen Jennings References: <4D7FA079.3090501@acm.org> In-Reply-To: <4D7FA079.3090501@acm.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: [P2PSIP] Two old issues [was Isssues not fixed in draft-ietf-p2psip-base-13] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 00:39:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I found two more issues not fixed in -13 that were in my list but were also reported previously to the mailing-list by someone else. Instead of repeating, here's the last message exchanged on each of these subjects: http://www.ietf.org/mail-archive/web/p2psip/current/msg05792.html http://www.ietf.org/mail-archive/web/p2psip/current/msg05564.html On 03/15/2011 10:23 AM, Marc Petit-Huguenin wrote: > Please see below for additional items that are not fixed in -13. I'll respond > in separate emails to your proposals. > > On 03/14/2011 05:43 PM, Cullen Jennings wrote: > >> There are a few things that did not get fixed in the -13 draft. Some due to just not sure how to fix them yet and some due to lack of time. The remanning open items are > > >> We need to update a few things to clarify usage when certificates have multiple node-id. Proposal is to say that, in cases other than when signaling a bootstrap peer, the first message is an Attach. The node-id used in the SignerIdentity of the Attach would indicate the node-id that this connection represented. The SignerIdentity still has to be one of the node-is in the certificate or the message is rejected. The same approach works for the non certificate based security modes. I realize this paragraph is clear as mud - we will work on better text. I may have misunderstood some of the email on this but I think this is the proposal from Marc, Bruce, and EKR. > > >> In section 6.3.4, it is not specified how to encode i into the hash. I'm proposing treating it as a uint32 and hashing that. > > > >>> A.39. Section 6.2.2 >>> >>> I am not really sure to understand how the "exists=False" are synthesized when >>> doing a Fetch on an array. For example if a Store was made for an object with >>> an index of 0xfffffffe, and the Fetch requests the whole array, will the answer >>> contains 4294967294 "exists=False" objects? > >> Proposal: Yes > >>> Also how are this synthesized elements signed? > >> Proposal: >> The "opaque value<0..2^32-1>;" would just indicate a 0 byte long binary blog and be encoded per normal. > > >>> A.40. Section 6.4.3.2 >>> >>> If exist is False, should the hash_value be the hash value of an empty byte >>> array (i.e. da39a3ee5e6b4b0d3255bfef95601890afd80709 for SHA-1) or be omitted? > >> Proposal: >> empty byte array ... keep the code path all the same with no special rules for exists == False. Keep in mind that you need to "sign" a delete of an entry and have that interact properly when a partitioned overlay merges" > > >>> A.43. Section 10.1 Element signature >>> >>> What certificate should be used to compute (and verify) the signature for the >>> whole configuration file? > > >> Proposal: >> Add a to the configuration that is much like the but says who can sing the configuration file. IN the case of the first time you get a configuration file, that could come at same time as enrollment and be secured that way. > >>> A.47. Section 6.3 >>> >>> The four policies defined in p2psip-base consistently says that "[a] given value >>> MUST be written (or overwritten) if and only if the request is signed ..." >>> Additional access control policies defined elsewhere use similar wording. >>> >>> But should not the StoredData signature be used instead of the request >>> signature? When replicating the data, the signer of the StoreRequest will be >>> different from the signer of the original request and so the test will no longer >>> work. Section 6.4.1.1 says that "[a] peer MUST [check that] [e]ach element is >>> signed by a credential which is authorized to write this kind at this >>> Resource-ID.", which seems to confirm that this is the element's signature that >>> must be checked, not the request's. > >> So the elements sig need to be checked for sure. The questions is should the request sig also be checked before that. Unless we can say how to check it, seems like bad idea. Proposal: remove this or clarify. > >>> A.38. Section 5.5.1.1. 'rel_addr_port corresponds to the rel-addr and rel-port >>> productions. Only present for type "relay".' >>> >>> In ICE, the rel address and port are also present for srflx and prflx candidates. > >> my brain hurts. Proposal: go for beer > > > A.12 Section 10.3 states that "[t]he SubjectAltName field in the certificate > contains the following values: One or more Node-IDs...", but nowhere it is said > how to request multiple Node-IDs. Is it an URL parameter of the POST request? > An attribute in the Certification Request object? > > EKR: "Good question. This is an issue that's simply not addressed in the draft., > but presumably we'll need to do something like this, yeah. My taste would be for > it to be a URL in the POSt." > > CJ: "It's not really defined in this draft how to have Certificates with > multiple node-id. There are some arguments about if multiple node ids are useful > or not - The goal here is just to make sure that option is left open if a future > extension does this. A parameter on the post URL sounds like a good approach." > > > A.24. Section 10.1.1. "| attribute id { xsd:int })," > > Does not match 13.6, that is saying that this is an unsigned integer. Should > probably use xsd:unsignedInt instead. > > (the private kind ids, 4026531844 and up, cannot be used with this definition). > - -- 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) iEYEARECAAYFAk2ABx4ACgkQ9RoMZyVa61eh9gCeOixeQEAI7L7iz3xH+OTJPvLR uu4Aniug3tJHjB1wI6Qf7BPWrBkalLZs =dY6D -----END PGP SIGNATURE----- From davidbryan@gmail.com Wed Mar 16 06:47:45 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 423343A69A6 for ; Wed, 16 Mar 2011 06:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.752 X-Spam-Level: X-Spam-Status: No, score=-101.752 tagged_above=-999 required=5 tests=[AWL=1.225, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mvqmqNojJzW for ; Wed, 16 Mar 2011 06:47:44 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 4609F3A69A5 for ; Wed, 16 Mar 2011 06:47:44 -0700 (PDT) Received: by wwk4 with SMTP id 4so4148347wwk.1 for ; Wed, 16 Mar 2011 06:49:10 -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=hJ6uwRi97GEz2ApZAxVu85VqRn55bFJJ/Oy9eio6YVA=; b=R0PQocwxV8FqFV0YKVvUgHzHRnl1qkW7/701Olenroqa0RBsqp2eMcPYOA5dME6nEB aX1LiWNNHHS7qwi7a4QAtGLnH3V/j3JivXcgVxV9cRrAxQarkhjEwjkeKVPrtw4MzA+y YdE2aWQ+yjDJR+9qXwibEclJMkzApSyjo63gU= 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=JNTE+EOOM2VBzBqgDVQPmPqf7WCnX5bYZVMxkHGF0+olP+YYgWDVU1uYhp2dl9vDn2 6pKDWv4ZCb0hFcN+o07Lbyy8HguQWeXzJR7vuJ4XfWLwMRP7ZE67YbOLNhJfHrle9T/r hNqYx0mrhdjTY4PdmkDPYZ1RIa7MIqRbgFcUs= MIME-Version: 1.0 Received: by 10.227.59.210 with SMTP id m18mr821423wbh.112.1300283350147; Wed, 16 Mar 2011 06:49:10 -0700 (PDT) Sender: davidbryan@gmail.com Received: by 10.227.13.67 with HTTP; Wed, 16 Mar 2011 06:49:10 -0700 (PDT) Date: Wed, 16 Mar 2011 09:49:10 -0400 X-Google-Sender-Auth: h8Sai0pAbiSSdDUfXB9KV3rEpQw Message-ID: From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [P2PSIP] P2PSIP Draft Agenda X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 13:47:45 -0000 The draft agenda for the WG meeting is: P2PSIP Agenda IETF-80 Thu, March 31, 1740-1940, Grand Ballrom draft-ietf-p2psip-base-13, Cullen Jennings, 30 min draft-jiang-p2psip-relay-05, Ning Zong, 10 min draft-knauf-p2psip-disco-02, Alexander Knauf, 15 min draft-peng-p2psip-network-management-scenarios-02, Peng Yongling, 15 min draft-petithuguenin-p2psip-access-control-01, Marc Petit-Huguenin, 15 min draft-zhang-p2psip-bcp-04, Li Gang, 10 min draft-knauf-p2psip-share-00, Alexander Knauf, 15 min Thanks, David (as chair) From dean.willis@softarmor.com Sat Mar 19 10:14:36 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 527283A6931; Sat, 19 Mar 2011 10:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.613 X-Spam-Level: X-Spam-Status: No, score=-103.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVZ5ROh9ZwbC; Sat, 19 Mar 2011 10:14:35 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 3DD0E3A695E; Sat, 19 Mar 2011 10:14:29 -0700 (PDT) Received: by yic13 with SMTP id 13so2297036yic.31 for ; Sat, 19 Mar 2011 10:16:00 -0700 (PDT) Received: by 10.146.50.6 with SMTP id x6mr2281438yax.17.1300554959802; Sat, 19 Mar 2011 10:15:59 -0700 (PDT) Received: from [192.168.89.100] (cpe-66-25-8-214.tx.res.rr.com [66.25.8.214]) by mx.google.com with ESMTPS id c24sm1364136ana.21.2011.03.19.10.15.57 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 19 Mar 2011 10:15:58 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Dean Willis Date: Sat, 19 Mar 2011 12:15:56 -0500 To: Sambasiva Rao MANCHILI X-Mailer: Apple Mail (2.1082) Cc: soc@ietf.org, ietf@ietf.org, sambasiva.manchili@nexustelecom.com, sipcore@ietf.org, tsvwg@ietf.org, p2psip@ietf.org Subject: [P2PSIP] Redirect to sip-implementors: was( Re: SIP UDP packet loss?) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 19 Mar 2011 17:14:36 -0000 You'll probably get a million of these replies, but I'll try and head = them off: Rather than the lists coped here (which deal with a wide variety of = other topics), please try the SIP Implementors List: sip-implementors@lists.cs.columbia.edu Thanks! Sorry to the rest of the folks I'm spamming here. -- Dean Willis= From michaelc@idssoftware.com Wed Mar 30 19:59:51 2011 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32EDF3A6B78 for ; Wed, 30 Mar 2011 19:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=2.300, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LL8uFBpDjIwI for ; Wed, 30 Mar 2011 19:59:49 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 8064E3A69B1 for ; Wed, 30 Mar 2011 19:59:49 -0700 (PDT) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Q588W-0004Bd-8B; Wed, 30 Mar 2011 23:01:28 -0400 Message-ID: <4D93EF77.7000705@idssoftware.com> Date: Wed, 30 Mar 2011 19:05:27 -0800 From: Michael Chen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: p2psip@ietf.org, Cullen Jennings References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da9406d3b887028fb0bd6ccca878b64e753b4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Subject: Re: [P2PSIP] Isssues not fixed in draft-ietf-p2psip-base-13 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 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, 31 Mar 2011 02:59:51 -0000 Hi, While looking at the diff between base-12 and 13, I spotted couple simple problems: 1) Section 5.5.1.2, the following sentence should get its own "o" bullet. There should be altogether 4 bullets: o If the peer is overloaded or detects some other kind of error, it MAY generate an error instead of an AttachReqAns. Also, in my proposed language for this section, I have one sentence right before the "*" bullets that is not included in base-13: + The tie-breaker heuristic is to compare the Node-IDs of both + peers as unsigned integers, and No where in this draft talks about one Node-ID "smaller" or "larger" than another Node-ID. I thought this language or something similar can help implementors understand the heuristic better. Wrong implementation of this comparison defeats the heuristic completely. 2) Please remove the extra "x" letter in my name in paragraph right above Section 15. Thanks Michael Chen On 3/14/2011 4:43 PM, Cullen Jennings wrote: > There are a few things that did not get fixed in the -13 draft. Some due to just not sure how to fix them yet and some due to lack of time. The remanning open items are > > > We need to update a few things to clarify usage when certificates have multiple node-id. Proposal is to say that, in cases other than when signaling a bootstrap peer, the first message is an Attach. The node-id used in the SignerIdentity of the Attach would indicate the node-id that this connection represented. The SignerIdentity still has to be one of the node-is in the certificate or the message is rejected. The same approach works for the non certificate based security modes. I realize this paragraph is clear as mud - we will work on better text. I may have misunderstood some of the email on this but I think this is the proposal from Marc, Bruce, and EKR. > > > In section 6.3.4, it is not specified how to encode i into the hash. I'm proposing treating it as a uint32 and hashing that. > > > >> A.39. Section 6.2.2 >> >> I am not really sure to understand how the "exists=False" are synthesized when >> doing a Fetch on an array. For example if a Store was made for an object with >> an index of 0xfffffffe, and the Fetch requests the whole array, will the answer >> contains 4294967294 "exists=False" objects? > Proposal: Yes > >> Also how are this synthesized elements signed? > Proposal: > The "opaque value<0..2^32-1>;" would just indicate a 0 byte long binary blog and be encoded per normal. > > >> A.40. Section 6.4.3.2 >> >> If exist is False, should the hash_value be the hash value of an empty byte >> array (i.e. da39a3ee5e6b4b0d3255bfef95601890afd80709 for SHA-1) or be omitted? > Proposal: > empty byte array ... keep the code path all the same with no special rules for exists == False. Keep in mind that you need to "sign" a delete of an entry and have that interact properly when a partitioned overlay merges" > > >> A.43. Section 10.1 Element signature >> >> What certificate should be used to compute (and verify) the signature for the >> whole configuration file? > > Proposal: > Add a to the configuration that is much like the but says who can sing the configuration file. IN the case of the first time you get a configuration file, that could come at same time as enrollment and be secured that way. > >> A.47. Section 6.3 >> >> The four policies defined in p2psip-base consistently says that "[a] given value >> MUST be written (or overwritten) if and only if the request is signed ..." >> Additional access control policies defined elsewhere use similar wording. >> >> But should not the StoredData signature be used instead of the request >> signature? When replicating the data, the signer of the StoreRequest will be >> different from the signer of the original request and so the test will no longer >> work. Section 6.4.1.1 says that "[a] peer MUST [check that] [e]ach element is >> signed by a credential which is authorized to write this kind at this >> Resource-ID.", which seems to confirm that this is the element's signature that >> must be checked, not the request's. > So the elements sig need to be checked for sure. The questions is should the request sig also be checked before that. Unless we can say how to check it, seems like bad idea. Proposal: remove this or clarify. > >> A.38. Section 5.5.1.1. 'rel_addr_port corresponds to the rel-addr and rel-port >> productions. Only present for type "relay".' >> >> In ICE, the rel address and port are also present for srflx and prflx candidates. > my brain hurts. Proposal: go for beer > > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > >