From ekr@rtfm.com Tue Apr 5 19:43: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 92F293A69AB for ; Tue, 5 Apr 2011 19:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.203 X-Spam-Level: X-Spam-Status: No, score=-104.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396, 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 z5S2z3gYMlXq for ; Tue, 5 Apr 2011 19:43:27 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 08B533A6849 for ; Tue, 5 Apr 2011 19:43:26 -0700 (PDT) Received: by iwn39 with SMTP id 39so1237160iwn.31 for ; Tue, 05 Apr 2011 19:45:10 -0700 (PDT) Received: by 10.231.66.69 with SMTP id m5mr457423ibi.55.1302057910457; Tue, 05 Apr 2011 19:45:10 -0700 (PDT) Received: from [10.29.162.97] ([166.205.138.142]) by mx.google.com with ESMTPS id gy41sm89055ibb.5.2011.04.05.19.45.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 19:45:08 -0700 (PDT) References: <4D93EF77.7000705@idssoftware.com> In-Reply-To: <4D93EF77.7000705@idssoftware.com> Mime-Version: 1.0 (iPhone Mail 8G4) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <22C8D115-DE81-4F38-AFFA-2CF29073234C@rtfm.com> X-Mailer: iPhone Mail (8G4) From: Eric Rescorla Date: Tue, 5 Apr 2011 19:44:59 -0700 To: Michael Chen Cc: "p2psip@ietf.org" 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: Wed, 06 Apr 2011 02:43:31 -0000 Thanks michael. We will get these But really don't you think it's cooler to have an x in your name? Ekr On Mar 30, 2011, at 20:05, Michael Chen wrote: > Hi, >=20 > While looking at the diff between base-12 and 13, I spotted couple simple p= roblems: >=20 > 1) Section 5.5.1.2, the following sentence should get its own "o" bullet. T= here should be altogether 4 bullets: >=20 > o If the peer is overloaded or detects some other kind of error, it > MAY generate an error instead of an AttachReqAns. >=20 > Also, in my proposed language for this section, I have one sentence right b= efore the "*" bullets that is not included in base-13: >=20 > + The tie-breaker heuristic is to compare the Node-IDs of both > + peers as unsigned integers, and >=20 >=20 > No where in this draft talks about one Node-ID "smaller" or "larger" than a= nother Node-ID. I thought this language or something similar can help implem= entors understand the heuristic better. Wrong implementation of this compari= son defeats the heuristic completely. >=20 > 2) Please remove the extra "x" letter in my name in paragraph right above S= ection 15. >=20 > Thanks >=20 > Michael Chen >=20 >=20 > 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 t= o just not sure how to fix them yet and some due to lack of time. The remann= ing open items are >>=20 >>=20 >> We need to update a few things to clarify usage when certificates have mu= ltiple 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 Sig= nerIdentity of the Attach would indicate the node-id that this connection re= presented. The SignerIdentity still has to be one of the node-is in the cert= ificate or the message is rejected. The same approach works for the non cert= ificate based security modes. I realize this paragraph is clear as mud - we w= ill work on better text. I may have misunderstood some of the email on this b= ut I think this is the proposal from Marc, Bruce, and EKR. >>=20 >>=20 >> In section 6.3.4, it is not specified how to encode i into the hash. I'm p= roposing treating it as a uint32 and hashing that. >>=20 >>=20 >>=20 >>> A.39. Section 6.2.2 >>>=20 >>> I am not really sure to understand how the "exists=3DFalse" are synthesi= zed when >>> doing a Fetch on an array. For example if a Store was made for an objec= t with >>> an index of 0xfffffffe, and the Fetch requests the whole array, will the= answer >>> contains 4294967294 "exists=3DFalse" objects? >> Proposal: Yes >>=20 >>> Also how are this synthesized elements signed? >> Proposal: >> The "opaque value<0..2^32-1>;" would just indicate a 0 byte long binary b= log and be encoded per normal. >>=20 >>=20 >>> A.40. Section 6.4.3.2 >>>=20 >>> If exist is False, should the hash_value be the hash value of an empty b= yte >>> array (i.e. da39a3ee5e6b4b0d3255bfef95601890afd80709 for SHA-1) or be om= itted? >> Proposal: >> empty byte array ... keep the code path all the same with no special rule= s for exists =3D=3D False. Keep in mind that you need to "sign" a delete of a= n entry and have that interact properly when a partitioned overlay merges" >>=20 >>=20 >>> A.43. Section 10.1 Element signature >>>=20 >>> What certificate should be used to compute (and verify) the signature fo= r the >>> whole configuration file? >>=20 >> 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 enrollme= nt and be secured that way. >>=20 >>> A.47. Section 6.3 >>>=20 >>> The four policies defined in p2psip-base consistently says that "[a] giv= en 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 wi= ll be >>> different from the signer of the original request and so the test will n= o longer >>> work. Section 6.4.1.1 says that "[a] peer MUST [check that] [e]ach elem= ent 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 signatu= re that >>> must be checked, not the request's. >> So the elements sig need to be checked for sure. The questions is should t= he request sig also be checked before that. Unless we can say how to check i= t, 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 re= l-port >>> productions. Only present for type "relay".' >>>=20 >>> In ICE, the rel address and port are also present for srflx and prflx ca= ndidates. >> my brain hurts. Proposal: go for beer >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >>=20 >>=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From michaelc@IDSSOFTWARE.COM Thu Apr 7 09:08:24 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 1FD673A67FB for ; Thu, 7 Apr 2011 09:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.989 X-Spam-Level: X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, SARE_SUB_ENC_UTF8=0.152] 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 wHgG30Bg67uT for ; Thu, 7 Apr 2011 09:08:20 -0700 (PDT) Received: from smtpoutwbe05.prod.mesa1.secureserver.net (smtpoutwbe05.prod.mesa1.secureserver.net [208.109.78.207]) by core3.amsl.com (Postfix) with SMTP id 9017928C0F1 for ; Thu, 7 Apr 2011 09:08:20 -0700 (PDT) Received: (qmail 20050 invoked from network); 7 Apr 2011 16:10:04 -0000 Received: from unknown (HELO gem-wbe28.prod.mesa1.secureserver.net) (64.202.189.162) by smtpoutwbe05.prod.mesa1.secureserver.net with SMTP; 7 Apr 2011 16:10:04 -0000 Received: (qmail 13897 invoked by uid 99); 7 Apr 2011 16:10:04 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 12.175.188.225 User-Agent: Web-Based Email 5.4.06 Message-Id: <20110407091004.61e8c06078a3b23a733c71e914c0b9df.0592203376.wbe@email00.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Thu, 07 Apr 2011 09:10:04 -0700 Mime-Version: 1.0 Subject: [P2PSIP] =?utf-8?q?Size_of_Signature=2Ealgorithm_and_SignerIdenti?= =?utf-8?q?tyValue=2Ehash=5Falg?= 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, 07 Apr 2011 16:08:24 -0000
Hi,

Section 5.3.4 of the base-13 draft needs some work= :

1) The type name SignatureAndHashAlgorithm shoul= d be renamed SignatureAlgorithm to match the same name in TLS. This name ca= used confusion in Wireshark implementation, which treats it as two bytes, o= ne for signature algorithm and one for hash algorithm.

=
2) In TLS, both SignatureAlgorithm and HashAlgorithm are enum that are= never part of any PDU send over the wire. Therefore, their size is not rel= evant to the TLS text. These two are in the RELOAD PDU, so this draft MUST = define their size explicitly to be both uint8. The value of the fields can = still mention TLS.

3) There is no formal defin= ition of the SignerIdentityValue.hash_alg field.

T= hanks

--Michael
 From petithug@acm.org Mon Apr 11 23:54:18 2011 Return-Path: X-Original-To: p2psip@ietfc.amsl.com Delivered-To: p2psip@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 28CCEE075F for ; Mon, 11 Apr 2011 23:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.465 X-Spam-Level: X-Spam-Status: No, score=-100.465 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfaG7UyrkwNm for ; Mon, 11 Apr 2011 23:54:17 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by ietfc.amsl.com (Postfix) with ESMTP id 5C489E070A for ; Mon, 11 Apr 2011 23:54:14 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id A144FDBCC04A; Tue, 12 Apr 2011 06:54:13 +0000 (UTC) Received: from [192.168.48.23] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id D39DADBCC048; Tue, 12 Apr 2011 06:54:12 +0000 (UTC) Message-ID: <4DA3F713.8000808@acm.org> Date: Tue, 12 Apr 2011 08:54:11 +0200 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.4) Gecko/20100718 Icedove/3.1 MIME-Version: 1.0 To: Michael Chen , P2PSIP Mailing List References: <20110407091004.61e8c06078a3b23a733c71e914c0b9df.0592203376.wbe@email00.secureserver.net> In-Reply-To: <20110407091004.61e8c06078a3b23a733c71e914c0b9df.0592203376.wbe@email00.secureserver.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [P2PSIP] Size of Signature.algorithm and SignerIdentityValue.hash_alg X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 06:54:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael, On 04/07/2011 06:10 PM, Michael Chen wrote: > Hi, > > Section 5.3.4 of the base-13 draft needs some work: > > 1) The type name SignatureAndHashAlgorithm should be renamed SignatureAlgorithm > to match the same name in TLS. This name caused confusion in Wireshark > implementation, which treats it as two bytes, one for signature algorithm and > one for hash algorithm. My understanding is the opposite of yours: It's the text that is incorrect, i.e. "The algorithm definitions are found in the IANA TLS SignatureAlgorithm Registry." should be replaced by "The algorithm definitions are found in the IANA TLS SignatureAlgorithm and HashSignature Registries." > > 2) In TLS, both SignatureAlgorithm and HashAlgorithm are enum that are never > part of any PDU send over the wire. Therefore, their size is not relevant to the > TLS text. These two are in the RELOAD PDU, so this draft MUST define their size > explicitly to be both uint8. The value of the fields can still mention TLS. They are both defined in TLS 1.2 section 7.4.1.4.1 with a size of 8 bit [see RELOAD section 5.3.1.1 for the meaning of (255)]: enum { none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) } SignatureAlgorithm; > > 3) There is no formal definition of the SignerIdentityValue.hash_alg field. > - -- 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) iEYEARECAAYFAk2j9wYACgkQ9RoMZyVa61desACfc7F9yfiMCv93nBCYt63nRoIf evwAoJrH1N2JFcKdQw2oYw45EiEQzpUb =ocV0 -----END PGP SIGNATURE----- From michaelc@IDSSOFTWARE.COM Tue Apr 12 11:41:18 2011 Return-Path: X-Original-To: p2psip@ietfc.amsl.com Delivered-To: p2psip@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AE0F1E06BC for ; Tue, 12 Apr 2011 11:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZU1JcLeUkXo for ; Tue, 12 Apr 2011 11:41:16 -0700 (PDT) Received: from smtpoutwbe02.prod.mesa1.secureserver.net (smtpoutwbe02.prod.mesa1.secureserver.net [208.109.78.113]) by ietfc.amsl.com (Postfix) with SMTP id 358EFE067F for ; Tue, 12 Apr 2011 11:41:15 -0700 (PDT) Received: (qmail 11156 invoked from network); 12 Apr 2011 18:41:14 -0000 Received: from unknown (HELO gem-wbe18.prod.mesa1.secureserver.net) (64.202.189.222) by smtpoutwbe02.prod.mesa1.secureserver.net with SMTP; 12 Apr 2011 18:41:14 -0000 Received: (qmail 10263 invoked by uid 99); 12 Apr 2011 18:41:14 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 12.175.188.225 User-Agent: Web-Based Email 5.4.06 Message-Id: <20110412114113.61e8c06078a3b23a733c71e914c0b9df.a75d1daaf7.wbe@email00.secureserver.net> From: "Michael Chen" To: "Marc Petit-Huguenin" Date: Tue, 12 Apr 2011 11:41:13 -0700 Mime-Version: 1.0 Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] =?utf-8?q?Size_of_Signature=2Ealgorithm_and_SignerIdenti?= =?utf-8?q?tyValue=2Ehash=5Falg?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 18:41:19 -0000
Marc,

> -------- Original Message --------
> = Subject: Re: [P2PSIP] Size of Signat= ure.algorithm and
> SignerIdentityValue.hash_alg
> From: Ma= rc Petit-Huguenin <petithug@acm.org<= /a>>
> Date: Mon, April 11, 2011 11:54 pm
> To: Michael Chen= <michaelc@idssoftware.com>,  P2PSIP Mailing List
> <p2psip@ietf.org>
>
>
> -----BEGIN PGP SIGN= ED MESSAGE-----
> Hash: SHA1
>
> Hi Michael,
> > On 04/07/2011 06:10 PM, Michael Chen wrote:
> > Hi,
> = >
> > Section 5.3.4 of the base-13 draft needs some work:
&g= t; >
> > 1) The type name SignatureAndHashAlgorithm should be r= enamed SignatureAlgorithm
> > to match the same name in TLS. This = name caused confusion in Wireshark
> > implementation, which treat= s it as two bytes, one for signature algorithm and
> > one for has= h algorithm.
>
> My understanding is the opposite of yours: &n= bsp;It's the text that is incorrect, i.e.
>
> "The algorithm d= efinitions are found in the IANA TLS SignatureAlgorithm Registry."
> =
> should be replaced by
>
> "The algorithm definitions = are found in the IANA TLS SignatureAlgorithm and
> HashSignature Regi= stries."
>
> >
> > 2) In TLS, both SignatureAlgori= thm and HashAlgorithm are enum that are never
> > part of any PDU = send over the wire. Therefore, their size is not relevant to the
> &g= t; TLS text. These two are in the RELOAD PDU, so this draft MUST define the= ir size
> > explicitly to be both uint8. The value of the fields c= an still mention TLS.
>
> They are both defined in TLS 1.2 sec= tion 7.4.1.4.1 with a size of 8 bit [see
> RELOAD section 5.3.1.1 for= the meaning of (255)]:
>
>     enum {
>  = ;         none(0), md5(1), sha1(2), sha224(3), sha256(4= ), sha384(5),
>           sha512(6), (255)>       } HashAlgorithm;
>
>    =   enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
> &nbs= p;       SignatureAlgorithm;

My mis= take, I was reading off an old link to the TLS 1.1 text.

=
--Michael
 From petithug@acm.org Fri Apr 22 10:16:54 2011 Return-Path: X-Original-To: p2psip@ietfc.amsl.com Delivered-To: p2psip@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 22ED2E06C0 for ; Fri, 22 Apr 2011 10:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.365 X-Spam-Level: X-Spam-Status: No, score=-101.365 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_36=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVxzr0buAHqh for ; Fri, 22 Apr 2011 10:16:53 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by ietfc.amsl.com (Postfix) with ESMTP id 76FD6E065A for ; Fri, 22 Apr 2011 10:16:53 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id B0CB1DBCC048; Fri, 22 Apr 2011 17:16:52 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 56004DBCC046; Fri, 22 Apr 2011 17:16:51 +0000 (UTC) Message-ID: <4DB1B802.6060902@acm.org> Date: Fri, 22 Apr 2011 10:16:50 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110402 Iceowl/1.0b2 Icedove/3.1.9 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Mandatory extensions in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 17:16:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As discussed during IETF 80, here's the text that I propose to add to RELOAD to specify in the configuration that a node should not attempt to join an overlay if it does not implement a specific set of extensions: Section 10.1 (in the example): " urn:ietf:params:xml:ns:p2p:config-ext1 " Section 10.1 (in the list of elements inside a configuration element): "mandatory-extension: This element contains the name of an XML namespace that a node joining the overlay MUST support. The presence of a mandatory-extension element does not require the extension to be used in the current configuration file, but can indicate that it may be used in the future. Note that the namespace is case-sensitive, as specified in [http://www.w3.org/TR/REC-xml-names/] section 2.3. More than one mandatory-extension element may be present." Section 10.1.1: "parameter &= element mandatory-extension { xsd:string }*" - -- 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) iEYEARECAAYFAk2xt/oACgkQ9RoMZyVa61fXcwCfY/2iCIYHF2WdbLw4TNm6x6cg 89UAoI93gjUOc3runcidnwXBvTcCEjaU =ey3c -----END PGP SIGNATURE----- From denglingli@gmail.com Sun Apr 24 18:26:44 2011 Return-Path: X-Original-To: p2psip@ietfc.amsl.com Delivered-To: p2psip@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6EF11E067B for ; Sun, 24 Apr 2011 18:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XG2G58BJVsO6 for ; Sun, 24 Apr 2011 18:26:44 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfc.amsl.com (Postfix) with ESMTP id 0449BE0669 for ; Sun, 24 Apr 2011 18:26:43 -0700 (PDT) Received: by qyk7 with SMTP id 7so1063452qyk.10 for ; Sun, 24 Apr 2011 18:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=J4znRcJLUMiTdtmYJSJ8cKG6w+om+w8qbRNgA+XKRi4=; b=nGXJ7JFBwV5h0wFF+27hfwVgVXEt2xnzmgvfEkgi5gerLuK91yML+7PcFU43GYZlBi wctOasB4p3hxAFjaMMeo343q3FLPs1Yf4TVC79eyDe7KrgRdwEoMLgj8QUF6lUjqwgdJ qTzKpO0ErLU9R2Pk9YgVBK3APLAKmZ/GzSUwk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=j4KSkv6UK4ohr74aGppH83Zb8ItX0R8w8dJP3DK7j2KTaMIaMqJY/zkO57XPTt5ht5 FbKPvy0ILt2KoCURaW+Hm/pGFDMNOb0CBCD/l3h3TMZmBzoBhwWwXJaUMfAdwyEYowIZ AhB2jOE3sDMoJg0rP8t0ZQYrF5Rv+pKgf46W0= MIME-Version: 1.0 Received: by 10.229.20.19 with SMTP id d19mr2371195qcb.245.1303694803442; Sun, 24 Apr 2011 18:26:43 -0700 (PDT) Received: by 10.229.40.209 with HTTP; Sun, 24 Apr 2011 18:26:43 -0700 (PDT) Date: Mon, 25 Apr 2011 09:26:43 +0800 Message-ID: From: lingli deng To: p2psip@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [P2PSIP] Question about the Leaving procedure for Chord-Reload in Base 13 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 01:31:25 -0000 Hi all, I am concerned about the specific leaving procedure for Chord algorithm described in Chapter 9, which does not address the data migration issue from the leaving peer to the newly responsible peer. Is it assumed that the newly responsible peer is one of the backup peers in Chord? Even if it is the case, there seems to be possibility for loss of data if the leaving peer does not perform data backup right before its exit. Would this be a problem? BR, Lingli Deng From ekr@rtfm.com Tue Apr 26 11:10:08 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9AB6E077C for ; Tue, 26 Apr 2011 11:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.272 X-Spam-Level: X-Spam-Status: No, score=-102.272 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjRSNBdokEwc for ; Tue, 26 Apr 2011 11:10:07 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E8F11E076A for ; Tue, 26 Apr 2011 11:10:06 -0700 (PDT) Received: by iyn15 with SMTP id 15so938241iyn.31 for ; Tue, 26 Apr 2011 11:10:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.179.65 with SMTP id bp1mr1412759icb.60.1303841406276; Tue, 26 Apr 2011 11:10:06 -0700 (PDT) Received: by 10.43.65.206 with HTTP; Tue, 26 Apr 2011 11:10:06 -0700 (PDT) In-Reply-To: <4DA3F713.8000808@acm.org> References: <20110407091004.61e8c06078a3b23a733c71e914c0b9df.0592203376.wbe@email00.secureserver.net> <4DA3F713.8000808@acm.org> Date: Tue, 26 Apr 2011 11:10:06 -0700 Message-ID: From: Eric Rescorla To: Marc Petit-Huguenin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Size of Signature.algorithm and SignerIdentityValue.hash_alg X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 18:10:08 -0000 On Mon, Apr 11, 2011 at 11:54 PM, Marc Petit-Huguenin wr= ote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Michael, > > On 04/07/2011 06:10 PM, Michael Chen wrote: >> Hi, >> >> Section 5.3.4 of the base-13 draft needs some work: >> >> 1) The type name SignatureAndHashAlgorithm should be renamed SignatureAl= gorithm >> to match the same name in TLS. This name caused confusion in Wireshark >> implementation, which treats it as two bytes, one for signature algorith= m and >> one for hash algorithm. > > My understanding is the opposite of yours: =A0It's the text that is incor= rect, i.e. > > "The algorithm definitions are found in the IANA TLS SignatureAlgorithm R= egistry." > > should be replaced by > > "The algorithm definitions are found in the IANA TLS SignatureAlgorithm a= nd > HashSignature Registries." Fixed. >> 2) In TLS, both SignatureAlgorithm and HashAlgorithm are enum that are n= ever >> part of any PDU send over the wire. Therefore, their size is not relevan= t to the >> TLS text. These two are in the RELOAD PDU, so this draft MUST define the= ir size >> explicitly to be both uint8. The value of the fields can still mention T= LS. > > They are both defined in TLS 1.2 section 7.4.1.4.1 with a size of 8 bit [= see > RELOAD section 5.3.1.1 for the meaning of (255)]: > > =A0 =A0enum { > =A0 =A0 =A0 =A0 =A0none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384= (5), > =A0 =A0 =A0 =A0 =A0sha512(6), (255) > =A0 =A0 =A0} HashAlgorithm; > > =A0 =A0 =A0enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) } > =A0 =A0 =A0 =A0SignatureAlgorithm; Agreed. > >> >> 3) There is no formal definition of the SignerIdentityValue.hash_alg fie= ld. >> I believe that there is at TLS 1.2. If you still disagree, please advise. -Ekr > - -- > 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) > > iEYEARECAAYFAk2j9wYACgkQ9RoMZyVa61desACfc7F9yfiMCv93nBCYt63nRoIf > evwAoJrH1N2JFcKdQw2oYw45EiEQzpUb > =3DocV0 > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From ekr@rtfm.com Tue Apr 26 11:13:22 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888E4E07A6 for ; Tue, 26 Apr 2011 11:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.309 X-Spam-Level: X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=0.668, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYJX58AJhGCg for ; Tue, 26 Apr 2011 11:13:22 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id F3B9AE06A6 for ; Tue, 26 Apr 2011 11:13:21 -0700 (PDT) Received: by iyn15 with SMTP id 15so941267iyn.31 for ; Tue, 26 Apr 2011 11:13:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.132.66 with SMTP id c2mr1096109ict.194.1303841601395; Tue, 26 Apr 2011 11:13:21 -0700 (PDT) Received: by 10.43.65.206 with HTTP; Tue, 26 Apr 2011 11:13:21 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Apr 2011 11:13:21 -0700 Message-ID: From: Eric Rescorla To: lingli deng Content-Type: text/plain; charset=ISO-8859-1 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Question about the Leaving procedure for Chord-Reload in Base 13 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 18:13:22 -0000 On Sun, Apr 24, 2011 at 6:26 PM, lingli deng wrote: > Hi all, > > I am concerned about the specific leaving procedure for Chord > algorithm described in Chapter 9, which does not address the data > migration issue from the leaving peer to the newly responsible peer. > Is it assumed that the newly responsible peer is one of the backup > peers in Chord? Yes, that's how Chord works. > Even if it is the case, there seems to be possibility for loss of data > if the leaving peer does not perform data backup right before its > exit. The leaving peer is supposed to replicate the data when it is stored, so in general loss should be minimized. If the client really cares, it can check the replicas to see if the store happens and if not re-store. > Would this be a problem? Well, it can happen, but there's no guarantee that data is never lost, it's just a "with low probability" anyway. IMO no fix is required here. Best, -Ekr > BR, > > Lingli Deng > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From fluffy@cisco.com Tue Apr 26 11:22:51 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D2DE07CE for ; Tue, 26 Apr 2011 11:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.581 X-Spam-Level: X-Spam-Status: No, score=-110.581 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, OBSCURED_EMAIL=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFbFn+fSqW3v for ; Tue, 26 Apr 2011 11:22:49 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 98599E0758 for ; Tue, 26 Apr 2011 11:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1236; q=dns/txt; s=iport; t=1303842169; x=1305051769; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=2hadH4K6USM5zinKU0D1JYoysIhHZn8TUcf6/h6odI0=; b=aIqXwTnSc4T2ZaUXQHlMHqdo+BhxNbr0sII9Gmj28G4+AOSNjDslNyMf NnNZmB+7qOl8IW9ODX7iCjcabyDtazYFXvILuvGPtEvRU/WP2alMv7CeV iXotu7AQ9tM2gQjYRyk3S9R/PIinSsExeZv12CSfDd3ZIL+0xjD93YtTv U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEIMt02rRDoJ/2dsb2JhbAClY3eIcKBGnSqFdgSFfYhEhAyKMw X-IronPort-AV: E=Sophos;i="4.64,270,1301875200"; d="scan'208";a="436723234" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 26 Apr 2011 18:22:49 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3QIMmuJ025457; Tue, 26 Apr 2011 18:22:48 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings X-Priority: 3 In-Reply-To: <187B83D79FF3489BA5971017DA587C3F@ThomasP300> Date: Tue, 26 Apr 2011 12:22:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <56A37EAD-7DCC-4883-85B7-65AC69880CAD@cisco.com> References: <187B83D79FF3489BA5971017DA587C3F@ThomasP300> To: Thomas Kluge X-Mailer: Apple Mail (2.1084) Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Validating Finger Table X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 18:22:51 -0000 Uh ... the draft is clearly wrong.=20 It should be=20 [ n+2^( 128-i ) , n+2^( 128-(i-1) )-1 ] The lower bound is the ideal finger and the upper bound one less than = the ideal finger for previous finger. For your example, this gives the result you proposed as the correct = result.=20 Thanks for catching this - this is fixed in the -14 version.=20 On Mar 25, 2010, at 10:59 AM, Thomas Kluge wrote: > We just probing around this: >=20 > Section 9.6.4.2. Refreshing finger table >=20 > A finger table entry i is valid if it is in the range > [n+2^(128-i), n+2^(128-(i-1))-2^(128-(i+1))]. >=20 > In a theoretical situation of a chord ring with 8 nodes (so 128 = replaced by 3) > and n=3D3, I have the following finger table entries: >=20 > f=3D(7 , 5 , 4) >=20 > the ranges computed using the formula above are: >=20 > (7-9 , 5-6 , 4-4.5) modulo corrected -> (7-1 , 5-6 , 4-4.5) >=20 > We're confused about this, cause we believe the following > is correct: >=20 > (7-2 , 5-6 , 4) >=20 > Whats wrong? >=20 > regards, > Thomas=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Tue Apr 26 12:09:43 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AFDE077C for ; Tue, 26 Apr 2011 12:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.282 X-Spam-Level: X-Spam-Status: No, score=-110.282 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzZoL6pkLa9k for ; Tue, 26 Apr 2011 12:09:42 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id C0656E062B for ; Tue, 26 Apr 2011 12:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1730; q=dns/txt; s=iport; t=1303844982; x=1305054582; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=LlSIIQoVdOKmQUTP5EVZDfu1yVLBf4I8zXVEVBiaLlE=; b=GFJlHNsHIXjtlp49mmqAYdRveljrxXTmMv2SDMEP29z2WpcFwmwMteSM QlCxC2i2lOA5FQzm0TxXGuHVYiZ/ZsxD6PQdWxWNX4t+12q+d/JlLrWDo RgdJM8gkXgv9nJWuj1iFj23z0QYaEvXix0DrnZm+QMkYpqruG9uQ4mXsQ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH8Xt02rRDoI/2dsb2JhbAClY3epaZ0nhXYEhX2IRIQMijM X-IronPort-AV: E=Sophos;i="4.64,270,1301875200"; d="scan'208";a="344916380" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 26 Apr 2011 19:09:35 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3QJ9YaK028760; Tue, 26 Apr 2011 19:09:35 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4DB1B802.6060902@acm.org> Date: Tue, 26 Apr 2011 13:09:34 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DB1B802.6060902@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Mandatory extensions in RELOAD X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 19:09:43 -0000 Add this in -14 of draft.=20 On Apr 22, 2011, at 11:16 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > As discussed during IETF 80, here's the text that I propose to add to = RELOAD to > specify in the configuration that a node should not attempt to join an = overlay > if it does not implement a specific set of extensions: >=20 > Section 10.1 (in the example): >=20 > " urn:ietf:params:xml:ns:p2p:config-ext1 > " >=20 > Section 10.1 (in the list of elements inside a configuration element): >=20 > "mandatory-extension: This element contains the name of an XML = namespace that a > node joining the overlay MUST support. The presence of a = mandatory-extension > element does not require the extension to be used in the current = configuration > file, but can indicate that it may be used in the future. Note that = the > namespace is case-sensitive, as specified in > [http://www.w3.org/TR/REC-xml-names/] section 2.3. More than one > mandatory-extension element may be present." >=20 > Section 10.1.1: >=20 > "parameter &=3D element mandatory-extension { xsd:string }*" >=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 > iEYEARECAAYFAk2xt/oACgkQ9RoMZyVa61fXcwCfY/2iCIYHF2WdbLw4TNm6x6cg > 89UAoI93gjUOc3runcidnwXBvTcCEjaU > =3Dey3c > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Tue Apr 26 13:30:29 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B267E06A6 for ; Tue, 26 Apr 2011 13:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.567 X-Spam-Level: X-Spam-Status: No, score=-110.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVKx1gorSLB1 for ; Tue, 26 Apr 2011 13:30:28 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id B3D09E0763 for ; Tue, 26 Apr 2011 13:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3363; q=dns/txt; s=iport; t=1303849828; x=1305059428; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zjl/ZHRJVPZ+gWKHs/kSsJu1FHcZ8M5Bwkj/AZxPCNM=; b=ZgKcpheI2mYyLfGm+i2FP5iVhjCxHOwR+GBjD1U1Q5fQB9M6ufN2r2FV 5/ERrrIOTsEGi7FkopX+uKLqRbXsVrSMGbYOxg44GBxRmLtz+p5yB/jcg 9qiYfXnIRJjZfI1G4N7LSfMPWIRiH6ZMTGGkV8rAL7sZBRf94UWWnKr07 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADsqt02rRDoG/2dsb2JhbAClZneqQ50ahXYEhX2IRIQMijM X-IronPort-AV: E=Sophos;i="4.64,270,1301875200"; d="scan'208";a="687465687" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 26 Apr 2011 20:30:28 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3QKURSp014953; Tue, 26 Apr 2011 20:30:27 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D7F9925.1080600@acm.org> Date: Tue, 26 Apr 2011 14:30:26 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1710085E-CD86-4CD3-AC88-57EC53326DA0@cisco.com> References: <4D2BA199.5080105@acm.org> <4D7F9925.1080600@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (4) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 20:30:29 -0000 Added some text to fix this but did not enforce in the relaxNG.=20 On Mar 15, 2011, at 10:51 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 03/14/2011 04:56 PM, Cullen Jennings wrote: >>=20 >> On Jan 10, 2011, at 5:17 PM, Marc Petit-Huguenin wrote: >>=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) >>=20 >>> I changed the grammar to allow >>=20 >> >>=20 >> ... >> ... >>=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 > Having no config-block makes this fragment valid: >=20 > > > > > > > >=20 > 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. >=20 > 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. >=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 > iEYEARECAAYFAk1/mSQACgkQ9RoMZyVa61d/dQCeNobyVwaCD6N9Co+gGytx3swd > kpkAn0qLyJqgnMuygjIhsfgGZATawC0f > =3DopRp > -----END PGP SIGNATURE----- From fluffy@cisco.com Tue Apr 26 13:33:27 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736C0E0763 for ; Tue, 26 Apr 2011 13:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.269 X-Spam-Level: X-Spam-Status: No, score=-110.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnF0BL2F0LCl for ; Tue, 26 Apr 2011 13:33:26 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id DD621E06A6 for ; Tue, 26 Apr 2011 13:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=357; q=dns/txt; s=iport; t=1303850006; x=1305059606; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Gs/NKIp7N/HJsi/WALSOEWPiVxHeD/giP08Vmsc7wRE=; b=B9RleNIJlLGbYVi7Ue8GEEtyvbBfYrZS0VJsfW5RpefSvmiH3nRreAtW xgEa9lAMuYX+G1NuMf/W50l59/mLO+1Z+0nV9qXtS1siY0KiO40FHEesG Bi7reFN0qMATuT9JP5jX/Ypi6WBNe220Fvb5FDR5LiIhSQFT2/KE6QGs3 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACgrt02rRDoJ/2dsb2JhbAClZneIcKFInRaFdgSFfYhEhAyKMw X-IronPort-AV: E=Sophos;i="4.64,270,1301875200"; d="scan'208";a="302500787" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2011 20:33:26 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3QKXPG4017995; Tue, 26 Apr 2011 20:33:26 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D7FA079.3090501@acm.org> Date: Tue, 26 Apr 2011 14:33:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3600615F-21D4-4BD5-ADA8-B5DEBE071249@cisco.com> References: <4D7FA079.3090501@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) 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.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 20:33:27 -0000 On Mar 15, 2011, at 11:23 AM, Marc Petit-Huguenin wrote: >=20 > A.24. Section 10.1.1. "| attribute id { xsd:int })," >=20 > Does not match 13.6, that is saying that this is an unsigned integer. = Should > probably use xsd:unsignedInt instead. >=20 > (the private kind ids, 4026531844 and up, cannot be used with this = definition). Fixed. From fluffy@cisco.com Tue Apr 26 13:36:41 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BB7E07C5 for ; Tue, 26 Apr 2011 13:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.556 X-Spam-Level: X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DH0PtBJM+0tz for ; Tue, 26 Apr 2011 13:36:41 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id F3BD3E0787 for ; Tue, 26 Apr 2011 13:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=156; q=dns/txt; s=iport; t=1303850200; x=1305059800; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=NLMh987tSvF+icAazO20YR2Vr1xDGiH3Iuz3yIiZEsc=; b=YxRt+ZdrdChg40uKC2gHyKTlaA+IuB36zaO32YnKLfnXhz9JjYFtpYmT m2Y6Ole8rE7Slk4CKTHKvwgDXPA5mkifE7/7B9d7qomwWNbsaSuUQPzLG bEGfG3Qlh3+NxaMH9ArWT5JdPDt5FJbOm4ugVs5d+bbfnZqtvulWoGkCk w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABYst02rRDoI/2dsb2JhbAClZ3eqP50WhXYEhX2IRIQMijM X-IronPort-AV: E=Sophos;i="4.64,270,1301875200"; d="scan'208";a="302503961" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2011 20:36:40 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3QKadVw006696; Tue, 26 Apr 2011 20:36:40 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D80071F.7030801@acm.org> Date: Tue, 26 Apr 2011 14:36:39 -0600 Content-Transfer-Encoding: 7bit Message-Id: <3B485E3A-DC06-4E37-9D7B-9A3E138F269A@cisco.com> References: <4D7FA079.3090501@acm.org> <4D80071F.7030801@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Two old issues [was Isssues not fixed in draft-ietf-p2psip-base-13] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 20:36:41 -0000 On Mar 15, 2011, at 6:41 PM, Marc Petit-Huguenin wrote: > http://www.ietf.org/mail-archive/web/p2psip/current/msg05564.html Fixed in next version. From fluffy@cisco.com Tue Apr 26 13:38:31 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9ABE0787 for ; Tue, 26 Apr 2011 13:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.558 X-Spam-Level: X-Spam-Status: No, score=-110.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6l7XWw9TnqUU for ; Tue, 26 Apr 2011 13:38:31 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 127F4E06A6 for ; Tue, 26 Apr 2011 13:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=256; q=dns/txt; s=iport; t=1303850311; x=1305059911; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=fdC5r0ca4CYomtyBsFJIrGe8HHnx/xJhnfdnON6uHZo=; b=EVqO8IuT1MoWlHbpMbVQyxj0Y1UI6onuLE/dRPxt/YUi63P8Ky5Q7LD0 87w8n5Al8WZtICGQxJmYNhxMWwycE24jqNJLB4xG5neecnA3vYXG+NTgE TX6J+I+28fRm2vt7Z+Ax29hBNwKWWhIe9RQmEJb/I2SqHM9Xy/caAILW3 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABYst02rRDoI/2dsb2JhbAClZ3eqP50WhXYEhX2IRIQMijM X-IronPort-AV: E=Sophos;i="4.64,270,1301875200"; d="scan'208";a="436809670" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 26 Apr 2011 20:38:30 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3QKcUZ2008936; Tue, 26 Apr 2011 20:38:30 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D80071F.7030801@acm.org> Date: Tue, 26 Apr 2011 14:38:28 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: <4D7FA079.3090501@acm.org> <4D80071F.7030801@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Two old issues [was Isssues not fixed in draft-ietf-p2psip-base-13] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 20:38:32 -0000 On Mar 15, 2011, at 6:41 PM, Marc Petit-Huguenin wrote: > http://www.ietf.org/mail-archive/web/p2psip/current/msg05792.html Covered in section 6.4.1.1. Search for para starting with "When a peer stores data previously stored by another node" From fluffy@cisco.com Tue Apr 26 13:50:33 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E3BE0829 for ; Tue, 26 Apr 2011 13:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.56 X-Spam-Level: X-Spam-Status: No, score=-111.56 tagged_above=-999 required=5 tests=[AWL=1.039, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqG2Pi+Y28y1 for ; Tue, 26 Apr 2011 13:50:32 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id C7F72E076F for ; Tue, 26 Apr 2011 13:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=5298; q=dns/txt; s=iport; t=1303851032; x=1305060632; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=5Qig5Pe0ZDPZxvwoEuH5sZJUlT5zIIaj7gmA2XwG80U=; b=WU3yldAN/3YKX/PBGK1iA8QpJDuNAS4wQrjGLlgHOHSUEFRGPEYGJnQ2 312dJSyWjKGg4vFPcIDcGQcVMqVM06rjQzoMAs5MtEczCnDfR/GcHd0Vz DI/I8BRkViUDNKdBVBAEon8oiw/DzmKVULMB1FHvGNgWQH8SScBncEwzH c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM8vt02rRDoI/2dsb2JhbAClZ3eIcKFinRGFdgSFfYhEhAyKMw X-IronPort-AV: E=Sophos;i="4.64,270,1301875200"; d="scan'208";a="302513431" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2011 20:50:30 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3QKoTS3022121; Tue, 26 Apr 2011 20:50:29 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4D93EF77.7000705@idssoftware.com> Date: Tue, 26 Apr 2011 14:50:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D93EF77.7000705@idssoftware.com> To: Michael Chen X-Mailer: Apple Mail (2.1084) Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Isssues not fixed in draft-ietf-p2psip-base-13 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 20:50:33 -0000 On Mar 30, 2011, at 9:05 PM, Michael Chen wrote: > Hi, >=20 > While looking at the diff between base-12 and 13, I spotted couple = simple problems: >=20 > 1) Section 5.5.1.2, the following sentence should get its own "o" = bullet. There should be altogether 4 bullets: >=20 > o If the peer is overloaded or detects some other kind of error, it > MAY generate an error instead of an AttachReqAns. >=20 Fixed > Also, in my proposed language for this section, I have one sentence = right before the "*" bullets that is not included in base-13: >=20 > + The tie-breaker heuristic is to compare the Node-IDs of both > + peers as unsigned integers, and >=20 >=20 > 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. fixed=20 >=20 > 2) Please remove the extra "x" letter in my name in paragraph right = above Section 15. >=20 > Thanks >=20 fixed > Michael Chen >=20 >=20 > 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 >>=20 >>=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 >>=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 >>=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? >> Proposal: Yes >>=20 >>> 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. >>=20 >>=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: >> 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" >>=20 >>=20 >>> A.43. Section 10.1 Element signature >>>=20 >>> What certificate should be used to compute (and verify) the = signature for the >>> whole configuration file? >>=20 >> 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. >>=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 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >>=20 >>=20 From michaelc@IDSSOFTWARE.COM Thu Apr 28 17:00:18 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A085E0728 for ; Thu, 28 Apr 2011 17:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.033 X-Spam-Level: X-Spam-Status: No, score=-0.033 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAKtHQCLNAJX for ; Thu, 28 Apr 2011 17:00:16 -0700 (PDT) Received: from smtpoutwbe09.prod.mesa1.secureserver.net (smtpoutwbe09.prod.mesa1.secureserver.net [208.109.78.21]) by ietfa.amsl.com (Postfix) with SMTP id 1EA59E0677 for ; Thu, 28 Apr 2011 17:00:15 -0700 (PDT) Received: (qmail 25457 invoked from network); 29 Apr 2011 00:00:15 -0000 Received: from unknown (HELO gem-wbe02.prod.mesa1.secureserver.net) (64.202.189.27) by smtpoutwbe09.prod.mesa1.secureserver.net with SMTP; 29 Apr 2011 00:00:15 -0000 Received: (qmail 12130 invoked by uid 99); 29 Apr 2011 00:00:15 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 12.175.188.225 User-Agent: Web-Based Email 5.4.06 Message-Id: <20110428170015.61e8c06078a3b23a733c71e914c0b9df.296bbc491e.wbe@email00.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Thu, 28 Apr 2011 17:00:15 -0700 Mime-Version: 1.0 Subject: [P2PSIP] =?utf-8?q?Where_is_Julian_Cain=3F?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 00:00:18 -0000 Julian, Marc and I were talking about doing RELOAD inter-op testing. I cc you only to find out your orchidseed.org domain is no longer reachable. If you are still interested, please send me an email. If anybody else wants to join in, feel free to let Marc and I know. BTW, I have submitted some Wireshark enhancements for DTLS and RELOAD that should help everyone implementing RELOAD. I am waiting for Wireshark folks to accept the changes into the 1.5.1 trunk. https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3D5863 Thanks --Michael