From petithug@acm.org Wed May 11 16:31:50 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE62E08B7 for ; Wed, 11 May 2011 16:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.665 X-Spam-Level: X-Spam-Status: No, score=-101.665 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dwrrRy9zGwK for ; Wed, 11 May 2011 16:31:50 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by ietfa.amsl.com (Postfix) with ESMTP id 11384E065A for ; Wed, 11 May 2011 16:31:47 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id B7D90DBE400C; Wed, 11 May 2011 23:31:46 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 5C828DBE400A for ; Wed, 11 May 2011 23:31:46 +0000 (UTC) Message-ID: <4DCB1C61.2070103@acm.org> Date: Wed, 11 May 2011 16:31:45 -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] draft-ietf-p2psip-service-discovery-01 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 23:31:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Some comments on this draft: - - I found this draft difficult to read without reading [ReDIR] before. - - Section 5: "In addition, the Node-ID MUST belong to one of the two intervals..." "...one of the n intervals (n being the ReDIR tree branching factor)..." Also the definition of the access control policy should be modified to work with exists=FALSE items, i.e. items without namespace, level and node fields. - - Section 8: redirBranchingFactor and redirRefreshPeriod These two elements should be declared in an XML namespace (and the redundant redir prefix can then be removed). Also I think that these two elements should be inserted inside the kind element, not inside the configuration element. And finally (but it is a matter of taste) I find "redir-branching-factor" and "redir-refresh-period" more readable. - -- 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) iEYEARECAAYFAk3LHGAACgkQ9RoMZyVa61caswCgoRd/au5cfzBoTQhInT3SjqnQ YzQAn2RxIUZ0K1WarW6PIigvXxd8hIfO =nkqM -----END PGP SIGNATURE----- From petithug@acm.org Fri May 13 10:56:56 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 4F3E3E0825 for ; Fri, 13 May 2011 10:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.665 X-Spam-Level: X-Spam-Status: No, score=-101.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_46=0.6, 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 HGWfNUvotQ6z for ; Fri, 13 May 2011 10:56:55 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by ietfa.amsl.com (Postfix) with ESMTP id B0E29E081A for ; Fri, 13 May 2011 10:56:55 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 0BFA2DBE400E; Fri, 13 May 2011 17:56:55 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id A7D36DBE400A for ; Fri, 13 May 2011 17:56:53 +0000 (UTC) Message-ID: <4DCD70E4.2050403@acm.org> Date: Fri, 13 May 2011 10:56:52 -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] draft-petithuguenin-p2psip-access-control-02 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 17:56:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I waited for base-14 to be released this but as the -base authors are currently unresponsive and I do not think that it is good for discussions to wait the cut-off date to publish documents, I decided to go ahead: https://datatracker.ietf.org/doc/draft-petithuguenin-p2psip-access-control/ The most important with this new version is the availability of a reference implementation, which contains a library that can be used to test new access control policy scripts. To not pollute this mailing list with irrelevant stuff, there will be a blog post (see the URL in my signature) explaining how to use this feature - well, as soon Blogger is no longer in read-only mode. Changelog: o Made clear that an unsigned kind with this extension must be rejected. o Removed the kind.params array, and converted the max-count, max- size and max-node-multiple as Number objects. Fixed the examples. o Removed the parsing of extensions in the kind element. The former system did not work with namespaces or attributes, and the right solution (XPath) is probably too complex. The value of the parameters can still be manually mirrored in the script, so there is perhaps no need for the added complexity. Also fixed the examples. o Reference draft-p2psip-share instance of draft-p2psip-disco. o Added a "Running Code Considerations" section that contain the reference to the reference implementation and script tester. o Nits - -- 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) iEYEARECAAYFAk3NcOAACgkQ9RoMZyVa61cacACdF/nX6Xhc6cSkqT2Y8/LGKNKj pewAnjYrNZ/p7JCOXd8mfkkwPVGJbxB2 =UwIg -----END PGP SIGNATURE----- From petithug@acm.org Fri May 13 16:41:25 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F0AE08A4 for ; Fri, 13 May 2011 16:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.965 X-Spam-Level: X-Spam-Status: No, score=-101.965 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 w6IJXPwQCbMw for ; Fri, 13 May 2011 16:41:25 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA69E081D for ; Fri, 13 May 2011 16:41:25 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 6E12ADBE400C; Fri, 13 May 2011 23:41:24 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 3AE66DBE400A for ; Fri, 13 May 2011 23:41:23 +0000 (UTC) Message-ID: <4DCDC1A2.5030201@acm.org> Date: Fri, 13 May 2011 16:41:22 -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] draft-knauf-p2psip-share-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 23:41:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am trying to find out how to implement the USER-CHAIN-ACL access control policy defined in this I-D as a script, and there is something I do not understand. First of all, I assume that this draft is using the features defined in base-13 and that no modifications in the -base document is needed to develop this policy. My problem is with the 4th paragraph of section 3: "Access Control Policy: To ensure write access to Shared Resource by Authorized Peers, each Usage MUST permit the USER-CHAIN-ACL access policy (see Section 5.4) in addition to its regular access policies (USER-MATCH, USER-NODE-MATCH, etc.)." I do not see in -base how two (or more) Access Control Policies can be used for one Kind. We have the same thing in draft-knauf-p2psip-disco: "Access Control Policy: Authorized focus peers are allowed to write the DisCo-Registration using the USER-CHAIN-ACL access policy. The conference creator (and resource owner) is the only exception: he is allowed to write based on the USER-MATCH or USER-PATTERN- MATCH policy." How a kind (DisCo-Registration in this case) can use two different access control policy? (Note that the configuration schema clearly states that a kind element contains one data-model element and one access-control element). 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) iEYEARECAAYFAk3NwaAACgkQ9RoMZyVa61dlZwCeNlDcg0W7NiYYF7AuiXCmvWkS 6V4AniHrLWAEQjTYb3M3JqQ8jvO5BOD3 =U1x+ -----END PGP SIGNATURE----- From prvs=110cb392e=Alexander.Knauf@haw-hamburg.de Mon May 16 02:41: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 CED5AE0744 for ; Mon, 16 May 2011 02:41:22 -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=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] 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 lVbkpUjOKK-D for ; Mon, 16 May 2011 02:41:22 -0700 (PDT) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id 6A31AE06A3 for ; Mon, 16 May 2011 02:41:20 -0700 (PDT) Received: from dehawshub01.mailcluster.haw-hamburg.de ([141.22.200.36]) by mail6.is.haw-hamburg.de with ESMTP/TLS/RC4-MD5; 16 May 2011 11:41:19 +0200 Received: from dehawscas03.mailcluster.haw-hamburg.de (141.22.200.53) by DEHAWSHUB01.mailcluster.haw-hamburg.de (141.22.200.36) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 16 May 2011 11:41:19 +0200 Received: from [141.22.26.154] (141.22.200.35) by haw-mailer.haw-hamburg.de (141.22.200.80) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 16 May 2011 11:41:19 +0200 Message-ID: <4DD0F13E.7070007@haw-hamburg.de> Date: Mon, 16 May 2011 11:41:18 +0200 From: Alexander Knauf User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: References: <4DCDC1A2.5030201@acm.org> In-Reply-To: <4DCDC1A2.5030201@acm.org> Content-Type: multipart/alternative; boundary="------------050806060204000407000606" Subject: Re: [P2PSIP] draft-knauf-p2psip-share-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 09:41:22 -0000 --------------050806060204000407000606 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi Marc, thanks for your feedback! On 14.05.2011 01:41, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > My problem is with the 4th paragraph of section 3: > > "Access Control Policy: To ensure write access to Shared Resource by > Authorized Peers, each Usage MUST permit the USER-CHAIN-ACL access > policy (see Section 5.4) in addition to its regular access > policies (USER-MATCH, USER-NODE-MATCH, etc.)." > > I do not see in -base how two (or more) Access Control Policies can be used for > one Kind. I also see this conflict in the XML overlay config. document that only allows a single access control policy per Kind. If it would support multiple access policies, something like this: kind-parameter&= element access-control { access-control-type }*<-- note the asterisk, compare with base -13 p.122 the receiver of a store request could iterate over the those policies, trying if any of them is true. > We have the same thing in draft-knauf-p2psip-disco: > > "Access Control Policy: Authorized focus peers are allowed to write > the DisCo-Registration using the USER-CHAIN-ACL access policy. > The conference creator (and resource owner) is the only exception: > he is allowed to write based on the USER-MATCH or USER-PATTERN- > MATCH policy." > > How a kind (DisCo-Registration in this case) can use two different access > control policy? same as above > (Note that the configuration schema clearly states that a kind element contains > one data-model element and one access-control element). If the base document keeps this rule, we have to think about an alternative in ShaRe/DisCo.. regards, Alexander > 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) > > iEYEARECAAYFAk3NwaAACgkQ9RoMZyVa61dlZwCeNlDcg0W7NiYYF7AuiXCmvWkS > 6V4AniHrLWAEQjTYb3M3JqQ8jvO5BOD3 > =U1x+ > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip -- /************************************************* * Alexander Knauf B.Sc. * AG INET * Dept. Informatik * HAW Hamburg * Berliner Tor 7 * D-20099 Hamburg, Germany * Room: 580 * Net: http://inet.cpt.haw-hamburg.de/members/knauf * Phone: +49 40 42875 - 8067 * Fax: +49 40 42875 - 8409 *************************************************/ --------------050806060204000407000606 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi Marc,

thanks for your feedback!


On 14.05.2011 01:41, Marc Petit-Huguenin wrote: 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

My problem is with the 4th paragraph of section 3:

"Access Control Policy:  To ensure write access to Shared Resource by
   Authorized Peers, each Usage MUST permit the USER-CHAIN-ACL access
   policy (see Section 5.4) in addition to its regular access
   policies (USER-MATCH, USER-NODE-MATCH, etc.)."

I do not see in -base how two (or more) Access Control Policies can be used for
one Kind.
I also see this conflict in the XML overlay config. document that only allows a single access control policy per Kind. If it would support multiple access policies, something like this: 

kind-parameter &= element access-control { access-control-type }* <-- note the asterisk, compare with base -13  p.122

the receiver of a store request could iterate over the those policies, trying if any of them is true.

We have the same thing in draft-knauf-p2psip-disco:

"Access Control Policy:  Authorized focus peers are allowed to write
   the DisCo-Registration using the USER-CHAIN-ACL access policy.
   The conference creator (and resource owner) is the only exception:
   he is allowed to write based on the USER-MATCH or USER-PATTERN-
   MATCH policy."

How a kind (DisCo-Registration in this case) can use two different access
control policy?
same as above
(Note that the configuration schema clearly states that a kind element contains
one data-model element and one access-control element).
If the base document keeps this rule, we have to think about an alternative in ShaRe/DisCo..

regards,

Alexander 
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)

iEYEARECAAYFAk3NwaAACgkQ9RoMZyVa61dlZwCeNlDcg0W7NiYYF7AuiXCmvWkS
6V4AniHrLWAEQjTYb3M3JqQ8jvO5BOD3
=U1x+
-----END PGP SIGNATURE-----
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip



-- 
/*************************************************
* Alexander Knauf B.Sc.
* AG INET
* Dept. Informatik
* HAW Hamburg
* Berliner Tor 7
* D-20099 Hamburg, Germany
* Room: 580
* Net: http://inet.cpt.haw-hamburg.de/members/knauf
* Phone: +49 40 42875 - 8067
* Fax: +49 40 42875 - 8409
*************************************************/
--------------050806060204000407000606-- From petithug@acm.org Mon May 16 16:15:44 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4005E07B8 for ; Mon, 16 May 2011 16:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.065 X-Spam-Level: X-Spam-Status: No, score=-102.065 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 cSn09D5jhjVN for ; Mon, 16 May 2011 16:15:40 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by ietfa.amsl.com (Postfix) with ESMTP id 76967E06EF for ; Mon, 16 May 2011 16:15:40 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 5D224DCC4018; Mon, 16 May 2011 23:15:39 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id CD9A9DC44002; Mon, 16 May 2011 23:15:30 +0000 (UTC) Message-ID: <4DD1B011.8060505@acm.org> Date: Mon, 16 May 2011 16:15:29 -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: Alexander Knauf References: <4DCDC1A2.5030201@acm.org> <4DD0F13E.7070007@haw-hamburg.de> In-Reply-To: <4DD0F13E.7070007@haw-hamburg.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: p2psip@ietf.org Subject: Re: [P2PSIP] draft-knauf-p2psip-share-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 23:15:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Alexander, On 05/16/2011 02:41 AM, Alexander Knauf wrote: > Hi Marc, > > thanks for your feedback! > > > On 14.05.2011 01:41, Marc Petit-Huguenin wrote: > My problem is with the 4th paragraph of section 3: > > "Access Control Policy: To ensure write access to Shared Resource by > Authorized Peers, each Usage MUST permit the USER-CHAIN-ACL access > policy (see Section 5.4) in addition to its regular access > policies (USER-MATCH, USER-NODE-MATCH, etc.)." > > I do not see in -base how two (or more) Access Control Policies can be used for > one Kind. >> I also see this conflict in the XML overlay config. document that only allows a >> single access control policy per Kind. If it would support multiple access >> policies, something like this: > >> kind-parameter &= element access-control { access-control-type }* <-- note the asterisk, compare with base -13 p.122 > > >> the receiver of a store request could iterate over the those policies, trying if >> any of them is true. Well, in this case I suggest that you talk to the -base authors to add this behavior in the spec (Note that I am not saying that this is a good idea). I will send a more detailed review (and will update my access control I-D with the modifications needed to implement this) when this is decided. As for the USER-PATTERN-MATCH policy, one problem I see is that the spec does not define strongly enough the resource_name field. The problem here is that when storing a value, a peer does not have access to the definition on this value - and cannot as each kind will have a different definition. This is why you need to say in the spec something like '... MUST define an "opaque <0..2^16-1>" field as the first field within the Kind data structure,...". With this field always defined as being the first in a Kind using USER-PATTERN-MATCH, the policy code will have no problem finding it. Also I think that the variable-resource-names element should be inside the kind element, and that you should also define its namespace. 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) iEYEARECAAYFAk3RsBAACgkQ9RoMZyVa61eSQQCeMf3rao3DihzM6ATcElSIyflM fEEAoIzkoli9Zp8UL82VbOMFRs4N2rMh =BnQ2 -----END PGP SIGNATURE----- From prvs=1145a7fea=Alexander.Knauf@haw-hamburg.de Fri May 20 07:15: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 A1AEEE06EA for ; Fri, 20 May 2011 07:15:41 -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] 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 vv4Pc67UJ9TT for ; Fri, 20 May 2011 07:15:40 -0700 (PDT) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF15E0755 for ; Fri, 20 May 2011 07:15:39 -0700 (PDT) Received: from dehawshub02.mailcluster.haw-hamburg.de ([141.22.200.52]) by mail3.is.haw-hamburg.de with ESMTP/TLS/RC4-MD5; 20 May 2011 16:15:39 +0200 Received: from dehawscas01.mailcluster.haw-hamburg.de (141.22.200.33) by DEHAWSHUB02.mailcluster.haw-hamburg.de (141.22.200.52) with Microsoft SMTP Server (TLS) id 8.1.358.0; Fri, 20 May 2011 16:15:38 +0200 Received: from [192.168.0.105] (141.22.200.55) by haw-mailer.haw-hamburg.de (141.22.200.80) with Microsoft SMTP Server (TLS) id 8.1.358.0; Fri, 20 May 2011 16:15:38 +0200 Message-ID: <4DD67789.4090501@haw-hamburg.de> Date: Fri, 20 May 2011 16:15:37 +0200 From: Alexander Knauf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "p2psip@ietf.org" References: <4DCDC1A2.5030201@acm.org> <4DD0F13E.7070007@haw-hamburg.de> <4DD1B011.8060505@acm.org> In-Reply-To: <4DD1B011.8060505@acm.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [P2PSIP] draft-knauf-p2psip-share-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 14:15:41 -0000 Hi again, On 17.05.2011 01:15, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Alexander, > > On 05/16/2011 02:41 AM, Alexander Knauf wrote: >> Hi Marc, >> >> thanks for your feedback! >> >> >> On 14.05.2011 01:41, Marc Petit-Huguenin wrote: >> My problem is with the 4th paragraph of section 3: >> >> "Access Control Policy: To ensure write access to Shared Resource by >> Authorized Peers, each Usage MUST permit the USER-CHAIN-ACL access >> policy (see Section 5.4) in addition to its regular access >> policies (USER-MATCH, USER-NODE-MATCH, etc.)." >> >> I do not see in -base how two (or more) Access Control Policies can be used for >> one Kind. >>> I also see this conflict in the XML overlay config. document that only allows a >>> single access control policy per Kind. If it would support multiple access >>> policies, something like this: >>> kind-parameter&= element access-control { access-control-type }*<-- note the asterisk, compare with base -13 p.122 >>> the receiver of a store request could iterate over the those policies, trying if >>> any of them is true. > Well, in this case I suggest that you talk to the -base authors to add this > behavior in the spec (Note that I am not saying that this is a good idea). Well, we were discussing alternatives to this and have the idea of some kind of "all-in-one" access control policy. Lets say the USER-CHAIN-ACL could be defined like: "a given value must be written if the request is signed with a private key whose hash..and-so-on" OR "must be written if " We only specify one access policy per Kind that allows two variants for storage access. > I will send a more detailed review (and will update my access control I-D with > the modifications needed to implement this) when this is decided. > > As for the USER-PATTERN-MATCH policy, one problem I see is that the spec does > not define strongly enough the resource_name field. The problem here is that > when storing a value, a peer does not have access to the definition on this > value - and cannot as each kind will have a different definition. This is why > you need to say in the spec something like '... MUST define an "opaque > <0..2^16-1>" field as the first field within the Kind data structure,...". With > this field always defined as being the first in a Kind using USER-PATTERN-MATCH, > the policy code will have no problem finding it. > > Also I think that the variable-resource-names element should be inside the kind > element, and that you should also define its namespace. Thanks for this comment and I agree. We will keep this in mind for next draft version. best regards, Alexander -- /************************************************* * Alexander Knauf B.Sc. * AG INET * Dept. Informatik * HAW Hamburg * Berliner Tor 7 * D-20099 Hamburg, Germany * Room: 580 * Net:http://inet.cpt.haw-hamburg.de/members/knauf * Phone: +49 40 42875 - 8067 * Fax: +49 40 42875 - 8409 *************************************************/ From petithug@acm.org Fri May 20 07:44:23 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 827E4E0651 for ; Fri, 20 May 2011 07:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.115 X-Spam-Level: X-Spam-Status: No, score=-102.115 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 gv+X26Z9OjTU for ; Fri, 20 May 2011 07:44:23 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by ietfa.amsl.com (Postfix) with ESMTP id EB7BEE064E for ; Fri, 20 May 2011 07:44:22 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 0D555DBD401C; Fri, 20 May 2011 14:44:22 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 6FB566C9842E; Fri, 20 May 2011 14:44:21 +0000 (UTC) Message-ID: <4DD67E44.9060908@acm.org> Date: Fri, 20 May 2011 07:44:20 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110510 Iceowl/1.0b2 Icedove/3.1.10 MIME-Version: 1.0 To: Alexander Knauf References: <4DCDC1A2.5030201@acm.org> <4DD0F13E.7070007@haw-hamburg.de> <4DD1B011.8060505@acm.org> <4DD67789.4090501@haw-hamburg.de> In-Reply-To: <4DD67789.4090501@haw-hamburg.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] draft-knauf-p2psip-share-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 14:44:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/20/2011 07:15 AM, Alexander Knauf wrote: > Hi again, > > On 17.05.2011 01:15, Marc Petit-Huguenin wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi Alexander, >> >> On 05/16/2011 02:41 AM, Alexander Knauf wrote: >>> Hi Marc, >>> >>> thanks for your feedback! >>> >>> >>> On 14.05.2011 01:41, Marc Petit-Huguenin wrote: >>> My problem is with the 4th paragraph of section 3: >>> >>> "Access Control Policy: To ensure write access to Shared Resource by >>> Authorized Peers, each Usage MUST permit the USER-CHAIN-ACL access >>> policy (see Section 5.4) in addition to its regular access >>> policies (USER-MATCH, USER-NODE-MATCH, etc.)." >>> >>> I do not see in -base how two (or more) Access Control Policies can be used for >>> one Kind. >>>> I also see this conflict in the XML overlay config. document that only allows a >>>> single access control policy per Kind. If it would support multiple access >>>> policies, something like this: >>>> kind-parameter&= element access-control { access-control-type }*<-- note the >>>> asterisk, compare with base -13 p.122 >>>> the receiver of a store request could iterate over the those policies, >>>> trying if >>>> any of them is true. >> Well, in this case I suggest that you talk to the -base authors to add this >> behavior in the spec (Note that I am not saying that this is a good idea). > Well, we were discussing alternatives to this and have the idea of some kind of > "all-in-one" access control policy. Lets say the USER-CHAIN-ACL could be defined > like: > > "a given value must be written if the request is signed with a private key whose > hash..and-so-on" > OR > "must be written if " > > We only specify one access policy per Kind that allows two variants for storage > access. OK, I think that with that I can write the scripts for the access policies, and be sure that the next version of my draft contains everything to implement them. I'll publish it (and the updated code for the tester) just after you publish your updated draft. 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) iEYEARECAAYFAk3WfkIACgkQ9RoMZyVa61f50QCgndPwhVJn1Te6aJ8ApG6jIAEI tgIAn1AfPkyGw6DiSw2EH6JOnpWFwhmA =YRCz -----END PGP SIGNATURE----- From petithug@acm.org Mon May 23 08:14: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 39F27E06E0 for ; Mon, 23 May 2011 08:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.145 X-Spam-Level: X-Spam-Status: No, score=-102.145 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 8A1GRYQ0tYR3 for ; Mon, 23 May 2011 08:14:31 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by ietfa.amsl.com (Postfix) with ESMTP id A5AF2E0730 for ; Mon, 23 May 2011 08:14:30 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id CC5F8DC04026; Mon, 23 May 2011 14:36:15 +0000 (UTC) Received: from [192.168.1.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id C2201DC04022; Mon, 23 May 2011 14:32:49 +0000 (UTC) Message-ID: <4DDA7010.7030901@acm.org> Date: Mon, 23 May 2011 07:32:48 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110510 Iceowl/1.0b2 Icedove/3.1.10 MIME-Version: 1.0 To: Cullen Jennings References: <4D7FA079.3090501@acm.org> <4D80071F.7030801@acm.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] 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: Mon, 23 May 2011 15:14:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/26/2011 01:38 PM, Cullen Jennings wrote: > > 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" > The confusion here (well, at least for me) is that it is not really clear in the spec that there is no relationship between the storage_time and lifetime field in StoredData. I initially thought that the expiration date/time for a value was storage_time + lifetime. The formula in 6.4.1.1 makes clear that it is the real date/time of storage that is used (like for most I-D/RFCs, the initial intent of the authors is generally lost, and implementers have to do detective work to find out what to do). I think that some of the confusion could be prevented. For example "storage_time: The time when the data was stored..." is obviously not true (it's at best the time the StoreReq was signed, and even that is not always true, see "... the node MAY elect to perform its store using a storage_time that increments..." - BTW the whole sentence looks wrong, probably an "If" is missing at the beginning of it) Also in "lifetime: the validity ... starting from the time of store", "time of store" is ambiguous. Saying "from the time the peer receives the StoreReq" matches with 6.4.1.1 and removes the ambiguity. - -- 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) iEYEARECAAYFAk3acA8ACgkQ9RoMZyVa61dQ8wCgoSxght2bE6tfN7/qvgw1L8Ws h7gAnAx/x81QFazFYlvMZYHW/6vhL+Om =Sqdc -----END PGP SIGNATURE----- From petithug@acm.org Mon May 23 09:09: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 5356DE07A1 for ; Mon, 23 May 2011 09:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.519 X-Spam-Level: X-Spam-Status: No, score=-101.519 tagged_above=-999 required=5 tests=[AWL=-0.546, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MISSING_HEADERS=1.292, 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 Zt+OSplRrKCc for ; Mon, 23 May 2011 09:09:30 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by ietfa.amsl.com (Postfix) with ESMTP id 70C6BE07AC for ; Mon, 23 May 2011 09:09:30 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id C6FEBDC04050; Mon, 23 May 2011 14:49:32 +0000 (UTC) Received: from [192.168.1.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id D007FDC04024 for ; Mon, 23 May 2011 14:46:06 +0000 (UTC) Message-ID: <4DDA732E.2060506@acm.org> Date: Mon, 23 May 2011 07:46:06 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110510 Iceowl/1.0b2 Icedove/3.1.10 MIME-Version: 1.0 CC: P2PSIP Mailing List References: <4D7FA079.3090501@acm.org> <4D80071F.7030801@acm.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Mon, 23 May 2011 16:09:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/26/2011 01:38 PM, Cullen Jennings wrote: > > 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" > The confusion here (well, at least for me) is that it is not really clear in the spec that there is no relationship between the storage_time and lifetime field in StoredData. I initially thought that the expiration date/time for a value was storage_time + lifetime. The formula in 6.4.1.1 makes clear that it is the real date/time of storage that is used (like for most I-D/RFCs, the initial intent of the authors is generally lost, and implementers have to do detective work to find out what to do). I think that some of the confusion could be prevented. For example "storage_time: The time when the data was stored..." is obviously not true (it's at best the time the StoreReq was signed, and even that is not always true, see "... the node MAY elect to perform its store using a storage_time that increments..." - BTW the whole sentence looks wrong, probably an "If" is missing at the beginning of it) Also in "lifetime: the validity ... starting from the time of store", "time of store" is ambiguous. Saying "from the time the peer receives the StoreReq" matches with 6.4.1.1 and removes the ambiguity. - -- 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) iEYEARECAAYFAk3acywACgkQ9RoMZyVa61fQ9wCdGUOEhJVRWy1QqDOmjjivurbh d2wAoJkr/iGU1JIFHGJvOhRQTRAM1kN3 =y9tY -----END PGP SIGNATURE----- From bbl@lowekamp.net Tue May 24 22:43:07 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60934E06EF for ; Tue, 24 May 2011 22:43:07 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbF8mROHGZIc for ; Tue, 24 May 2011 22:43:06 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7637BE06BF for ; Tue, 24 May 2011 22:43:06 -0700 (PDT) Received: by vws12 with SMTP id 12so6681837vws.31 for ; Tue, 24 May 2011 22:43:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.99.106 with SMTP id ep10mr877443vdb.46.1306302185502; Tue, 24 May 2011 22:43:05 -0700 (PDT) Received: by 10.52.109.8 with HTTP; Tue, 24 May 2011 22:43:05 -0700 (PDT) In-Reply-To: <4DDA7010.7030901@acm.org> References: <4D7FA079.3090501@acm.org> <4D80071F.7030801@acm.org> <4DDA7010.7030901@acm.org> Date: Wed, 25 May 2011 01:43:05 -0400 Message-ID: From: Bruce Lowekamp To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] 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: Wed, 25 May 2011 05:43:07 -0000 On Mon, May 23, 2011 at 10:32 AM, Marc Petit-Huguenin wr= ote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/26/2011 01:38 PM, Cullen Jennings wrote: >> >> 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" >> > > The confusion here (well, at least for me) is that it is not really clear= in the > spec that there is no relationship between the storage_time and lifetime = field > in StoredData. =C2=A0I initially thought that the expiration date/time fo= r a value > was storage_time + lifetime. =C2=A0The formula in 6.4.1.1 makes clear tha= t it is the > real date/time of storage that is used (like for most I-D/RFCs, the initi= al > intent of the authors is generally lost, and implementers have to do dete= ctive > work to find out what to do). > > I think that some of the confusion could be prevented. =C2=A0For example > "storage_time: The time when the data was stored..." is obviously not tru= e (it's > at best the time the StoreReq was signed, and even that is not always tru= e, see > "... the node MAY elect to perform its store using a storage_time that > increments..." - BTW the whole sentence looks wrong, probably an "If" is = missing > at the beginning of it) > now reads: The time when the data was stored represented as the number of milliseconds elapsed since midnight Jan 1, 1970 UTC not counting leap seconds. This will have the same values for seconds as standa= rd UNIX time or POSIX time. More information can be found at . Any attempt to store a data value wit= h a storage time before that of a value already stored at this locatio= n MUST generate a Error_Data_Too_Old error. This prevents rollback attacks. The node SHOULD make a best-effort attempt to use a correct clock to determine this number, however, the protocol does not require synchronized clocks: the receiving peer uses the storage time in the previous store, not it= s own clock. Clock values are used so that when clocks are generally synchronized, data may be stored in a single transaction, rather than querying for the value of a counter before performing the actual store. If a node attempting to store new data in response to a user request (rather than as an overlay maintenance operation such as occurs during unpartitioning) is rejected with an Error_Data_Too_O= ld error, the node MAY elect to perform its store using a storage_tim= e that increments the value used with the previous store. This situation may occur when the clocks of nodes storing to this location are not properly synchronized. > Also in "lifetime: the validity ... starting from the time of store", "ti= me of > store" is ambiguous. =C2=A0Saying "from the time the peer receives the St= oreReq" > matches with 6.4.1.1 and removes the ambiguity. > done > - -- > 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) > > iEYEARECAAYFAk3acA8ACgkQ9RoMZyVa61dQ8wCgoSxght2bE6tfN7/qvgw1L8Ws > h7gAnAx/x81QFazFYlvMZYHW/6vhL+Om > =3DSqdc > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From michaelc@IDSSOFTWARE.COM Fri May 27 13:51: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 33C9FE085E for ; Fri, 27 May 2011 13:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 j781YDSMWJBJ for ; Fri, 27 May 2011 13:51:27 -0700 (PDT) Received: from smtpoutwbe10.prod.mesa1.secureserver.net (smtpoutwbe10.prod.mesa1.secureserver.net [208.109.78.26]) by ietfa.amsl.com (Postfix) with SMTP id F028FE085B for ; Fri, 27 May 2011 13:51:25 -0700 (PDT) Received: (qmail 9757 invoked from network); 27 May 2011 20:51:25 -0000 Received: from unknown (HELO gem-wbe32.prod.mesa1.secureserver.net) (64.202.189.144) by smtpoutwbe10.prod.mesa1.secureserver.net with SMTP; 27 May 2011 20:51:25 -0000 Received: (qmail 3031 invoked by uid 99); 27 May 2011 20:51:24 -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.5.01 Message-Id: <20110527135124.61e8c06078a3b23a733c71e914c0b9df.c2a0a4cd55.wbe@email00.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Fri, 27 May 2011 13:51:24 -0700 Mime-Version: 1.0 Subject: [P2PSIP] =?utf-8?q?What_is_the_point_of_SHA256_self-signed_digest?= =?utf-8?q?=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, 27 May 2011 20:51:29 -0000 Hi, In the base-13 draft section 10.1, it mandates the support of SHA1 and SHA256 self-signed digest for generating NodeId. However, in the same section, it also defines the "node-id-length" to be no more than 160 bits (SHA1). This means if SHA256 is used, the NodeId will be truncated to 160 bit or less. Why mandate a crippled SHA256 that offers no added strength than SHA1? Consider removing it altogether. If 128-bit is good enough for NodeId, then 160-bit good enough for self-signed certs. I would also recommend adding language of "recommending" the use of SHA1 for all signer-id-hash in signature for the same reason. It's another topic. Thanks --Michael From ekr@rtfm.com Fri May 27 13:54:35 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 2008EE073F for ; Fri, 27 May 2011 13:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1grDk4S1Okpw for ; Fri, 27 May 2011 13:54:34 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3F536E0718 for ; Fri, 27 May 2011 13:54:34 -0700 (PDT) Received: by wwa36 with SMTP id 36so1549551wwa.13 for ; Fri, 27 May 2011 13:54:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.246.74 with SMTP id p52mr130474wer.41.1306529673322; Fri, 27 May 2011 13:54:33 -0700 (PDT) Received: by 10.216.161.147 with HTTP; Fri, 27 May 2011 13:54:33 -0700 (PDT) In-Reply-To: <20110527135124.61e8c06078a3b23a733c71e914c0b9df.c2a0a4cd55.wbe@email00.secureserver.net> References: <20110527135124.61e8c06078a3b23a733c71e914c0b9df.c2a0a4cd55.wbe@email00.secureserver.net> Date: Fri, 27 May 2011 13:54:33 -0700 Message-ID: From: Eric Rescorla To: Michael Chen Content-Type: text/plain; charset=ISO-8859-1 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] What is the point of SHA256 self-signed digest? 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, 27 May 2011 20:54:35 -0000 On Fri, May 27, 2011 at 1:51 PM, Michael Chen wrote: > Hi, > > In the base-13 draft section 10.1, it mandates the support of SHA1 and > SHA256 self-signed digest for generating NodeId. However, in the same > section, it also defines the "node-id-length" to be no more than 160 > bits (SHA1). This means if SHA256 is used, the NodeId will be truncated > to 160 bit or less. > > Why mandate a crippled SHA256 that offers no added strength than SHA1? I don't believe this is true. There is ample evidence that SHA-1 is substantially weaker than its output length, whereas a truncated SHA-256 is quite possibly (likely?) stronger. -Ekr From internet-drafts@ietf.org Fri May 27 20:23:08 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2B9E06D4; Fri, 27 May 2011 20:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpIctdnfwC5U; Fri, 27 May 2011 20:23:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C39DE066C; Fri, 27 May 2011 20:23:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110528032307.12483.34095.idtracker@ietfa.amsl.com> Date: Fri, 27 May 2011 20:23:07 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-base-14.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 03:23:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer-to-Peer Session Initiation Proto= col Working Group of the IETF. Title : REsource LOcation And Discovery (RELOAD) Base Protocol Author(s) : Cullen Jennings Bruce B. Lowekamp Eric Rescorla Salman A. Baset Henning Schulzrinne Filename : draft-ietf-p2psip-base-14.txt Pages : 160 Date : 2011-05-27 This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store= data for others. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-p2psip-base-14.txt From internet-drafts@ietf.org Fri May 27 20:37:11 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4514AE076A; Fri, 27 May 2011 20:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKssqvSgbL7M; Fri, 27 May 2011 20:37:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9953E0759; Fri, 27 May 2011 20:37:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110528033710.12537.76625.idtracker@ietfa.amsl.com> Date: Fri, 27 May 2011 20:37:10 -0700 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-base-15.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 03:37:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer-to-Peer Session Initiation Proto= col Working Group of the IETF. Title : REsource LOcation And Discovery (RELOAD) Base Protocol Author(s) : Cullen Jennings Bruce B. Lowekamp Eric Rescorla Salman A. Baset Henning Schulzrinne Filename : draft-ietf-p2psip-base-15.txt Pages : 160 Date : 2011-05-27 This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store= data for others. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-15.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-p2psip-base-15.txt From fluffy@cisco.com Fri May 27 20:40:13 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D32FE06E9 for ; Fri, 27 May 2011 20:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.487 X-Spam-Level: X-Spam-Status: No, score=-110.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 zU2+cw9bVyr6 for ; Fri, 27 May 2011 20:40:09 -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 5E575E06D4 for ; Fri, 27 May 2011 20:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1888; q=dns/txt; s=iport; t=1306554009; x=1307763609; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=Ws20X2vY9XLXb169AME4CZxhFH111u4MZg5tEZFhHjE=; b=IWfmxC64IrHtl4R1Pbs9M8NE77BvkVju1isg9YqTWYaEsMvMzlWLUmaF G7PXSyngPrgllJwtK0X7KWVaP+o6Jq9mVlpRJ/BSgEf4QW+ImyCcPUePY z/9hMW+BdM5jxXb4BaAhucXKUPuUXhv3pMfMUNe8ezUiQt7qbwEPWCuyg g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswGAJ1t4E2rRDoI/2dsb2JhbABVmDKOD3eoaZ08hh4EhmKJZYQ9ino X-IronPort-AV: E=Sophos;i="4.65,284,1304294400"; d="scan'208";a="365900182" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 28 May 2011 03:40:08 +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 p4S3e7mW014161; Sat, 28 May 2011 03:40:07 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 27 May 2011 21:40:06 -0600 Message-Id: <48AF46F9-5E4A-4D62-8DE0-EE6916D30F98@cisco.com> To: ietf-types@iana.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: P2PSIP Mailing List Subject: [P2PSIP] Registration of media type application/p2p-overlay+xml X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 03:40:13 -0000 The draft-ietf-p2psip-base-15 contains the following MINE Type = registration. It would appreciate any comments people wanted to send. = Thank you To: ietf-types@iana.org Subject: Registration of media type application/p2p-overlay+xml Type name: application Subtype name: p2p-overlay+xml Required parameters: none Optional parameters: none Encoding considerations: Must be binary encoded. The contents MUST be valid XML compliant with the relax NG grammar specified in RFC- AAAA and use the UTF-8[RFC3629] character encoding. Security considerations: This media type is typically not used to transport information that typically needs to be kept confidential however there are cases where it is integrity of the information is important. For these cases using a digital signature is RECOMMENDED. One way of doing this is specified in RFC-AAAA. In the case when the media includes a "shared-secret" element, then the contents of the file need to be kept confidential or else anyone that can see the shared-secret and effect the RELOAD overlay network. Interoperability considerations: Same as application/xml as defined in [RFC3023]. Published specification: RFC-AAAA Applications that use this media type: The type is used to configure the peer to peer overlay networks defined in RFC-AAAA. Additional information: The syntax for this media type is specified in Section 10.1 of RFC-AAAA. Magic number(s): none File extension(s): relo Macintosh file type code(s): none Person & email address to contact for further information: Cullen Jennings Intended usage: COMMON Restrictions on usage: None Author: Cullen Jennings Change controller: IESG From derhoermi@gmx.net Sat May 28 02:16:21 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 43BA3E0737 for ; Sat, 28 May 2011 02:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cZ0wY6Gbkwy for ; Sat, 28 May 2011 02:16:20 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 08A24E0670 for ; Sat, 28 May 2011 02:16:19 -0700 (PDT) Received: (qmail invoked by alias); 28 May 2011 09:16:17 -0000 Received: from dslb-094-223-152-222.pools.arcor-ip.net (EHLO HIVE) [94.223.152.222] by mail.gmx.net (mp069) with SMTP; 28 May 2011 11:16:17 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19aYqFGdElauibDFDBH4aCwy1zCzlwqyFGwt3LscZ DsbxhHwrDFCVXy From: Bjoern Hoehrmann To: Cullen Jennings Date: Sat, 28 May 2011 11:16:20 +0200 Message-ID: <21f1u6hael1utmpg3svvn2a6s3agncb5ov@hive.bjoern.hoehrmann.de> References: <48AF46F9-5E4A-4D62-8DE0-EE6916D30F98@cisco.com> In-Reply-To: <48AF46F9-5E4A-4D62-8DE0-EE6916D30F98@cisco.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Sat, 28 May 2011 07:40:14 -0700 Cc: ietf-types@iana.org, P2PSIP Mailing List Subject: Re: [P2PSIP] [ietf-types] Registration of media type application/p2p-overlay+xml X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 09:16:21 -0000 * Cullen Jennings wrote: > To: ietf-types@iana.org > > Subject: Registration of media type application/p2p-overlay+xml There is no reason to include this part in the specification. > Type name: application > > Subtype name: p2p-overlay+xml > > Required parameters: none > > Optional parameters: none Why are you using the +xml convention but do not specify the type in a manner consistent with application/xml? Without a very good reason I'd think you should either add the "charset" parameter or drop the "+xml". > Encoding considerations: Must be binary encoded. The contents MUST > be valid XML compliant with the relax NG grammar specified in RFC- > AAAA and use the UTF-8[RFC3629] character encoding. This should either just say "binary" or just reference RFC 3023 as RFC 3023 suggests. > Interoperability considerations: Same as application/xml as defined > in [RFC3023]. If there are no known interoperability issues beyond those of the type application/xml, that is what you should say; the considerations here are certainly not the same. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From peng.yonglin@zte.com.cn Sun May 29 20:13:19 2011 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F09E067F for ; Sun, 29 May 2011 20:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.645 X-Spam-Level: X-Spam-Status: No, score=-93.645 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, PLING_QUERY=1.39, RCVD_DOUBLE_IP_LOOSE=0.76, 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 rdQ0rbIvX1t1 for ; Sun, 29 May 2011 20:13:18 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 55567E0657 for ; Sun, 29 May 2011 20:13:17 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 412302075036648; Mon, 30 May 2011 11:10:13 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 17621.2075036648; Mon, 30 May 2011 11:10:19 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p4U3AFa3048946 for ; Mon, 30 May 2011 11:10:15 +0800 (GMT-8) (envelope-from peng.yonglin@zte.com.cn) To: P2PSIP Mailing List MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: peng.yonglin@zte.com.cn Date: Mon, 30 May 2011 11:17:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-05-30 11:10:17, Serialize complete at 2011-05-30 11:10:17 Content-Type: multipart/alternative; boundary="=_alternative 00116C09482578A0_=" X-MAIL: mse02.zte.com.cn p4U3AFa3048946 Cc: hao.zhenwu@zte.com.cn, meng.yu@zte.com.cn Subject: [P2PSIP] Who knows about the existing specific method of multiple dynamic SNMP managers? Thanks! 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, 30 May 2011 03:13:19 -0000 This is a multipart message in MIME format. --=_alternative 00116C09482578A0_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 QXQgdGhlIGxhc3QgbWVldGluZ6OsdGhlcmUgaXMgZXhwZXJ0IHRoYW5rcyB0aGF0IHRoZXJlIGFy ZSBzb21lIGV4aXN0aW5nIA0KU05NUCB3YXlzIHRvIGhhdmUgbXVsdGlwbGUgbWFuYWdlciBkeW5h bWljYWxseS4gU28gd2Ugd2FudCB0byBrbm93cyB0aGUgDQpzcGVjaWZpYyBtZXRob2QgYWJvdXQg aXQuDQoNClRoYW5rcyENCg0KbWVldGluZyBtaW51dGVzo7oNCiAgICAgICAgICBbRGFuIFJdIFdo ZW4gdXNlIFJFTE9BRCB0byBkZWNpZGUgd2hlcmUgU05NUCBub3RpZmljYXRpb25zIGdvIA0KbmVl ZCBzb21lDQogICAgICAgICAgbWV0aG9kIHRvIHhmZXIgaW5mb3JtYXRpb24gZ2FpbmVkIGFib3V0 IHNlc3Npb24gaW50byBTTk1QIA0KdGFyZ2V0LiBUaGVyZQ0KICAgICAgICAgIGlzIGEgc3RhbmRh cmQgd2F5IHRvIGNvbmZpZ3VyZSB3aXRoIHRoZSB0YXJnZXQgTUlCLg0KICAgICAgICAgIFtQZW5n XSBXZSBhcmUgdGhpbmtpbmcgb2YgYm90aCBkaXJlY3Rpb25zLiBNYW5hZ2VyIG5lZWRzIFJFTE9B RCANCnRvIGZpbmQNCiAgICAgICAgICBub2RlLiBXZSBtYXkgbmVlZCBtb3JlIHRoYW4gb25lIG1h bmFnZXIuIE1heSBiZSBhbiBpc3N1ZSB0byANCnN0YXRpY2FsbHkNCiAgICAgICAgICBjb25maWd1 cmUgaW4gZW5kcG9pbnQNCiAgICAgICAgICBbRGFuUl0gRG9uJ3QgZGlzYWdyZWUgLSBidXQgdGhl cmUgYXJlIHNvbWUgZXhpc3RpbmcgU05NUCB3YXlzIHRvIA0KaGF2ZQ0KICAgICAgICAgIG11bHRp cGxlIG1hbmFnZXIgZHluYW1pY2FsbHksIHRoaXMgaXMgbm93IGFub3RoZXIgbWV0aG9kIGZvciAN CmRpc2NvdmVyaW5nDQogICAgICAgICAgLSBidXQgdGhpcyBpbmZvIG5lZWRzIHRvIGJlIHhmZXJl ZCB0byBwbGFjZXMgd2hlcmUgc3RhbmRhcmQgU05NUCANCmFnZW50cw0KICAgICAgICAgIHdvdWxk IGxvb2sgZm9yIGl0Lg0KIA0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqDQrTyiC8/qO6cGVuZy55b25nbGluQHp0ZS5jb20uY24NCsTaIM/fo7o4MTU0 Mw0KzeIgz9+jujAyNS01Mjg3MTU0Mw0KytYgu/qjujEzNzc2NjM3Mjc0DQq0qyDV5qO6MDI1LTUy ODcyMTg3DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mg b3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJl Y2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFu ZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21t dW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRl ZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQu IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0 aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlz IG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2Fn ZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0g c3lzdGVtLg0K --=_alternative 00116C09482578A0_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkF0IHRoZSBsYXN0IG1lZXRpbmej rHRoZXJlIGlzIGV4cGVydA0KdGhhbmtzIHRoYXQgPC9mb250Pjxmb250IHNpemU9Mj48dHQ+dGhl cmUgYXJlIHNvbWUgZXhpc3RpbmcgU05NUCB3YXlzIHRvDQpoYXZlIG11bHRpcGxlIG1hbmFnZXIg ZHluYW1pY2FsbHk8L3R0PjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Lg0K U28gd2Ugd2FudCB0byBrbm93cyB0aGUgc3BlY2lmaWMgbWV0aG9kIGFib3V0IGl0LjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzITwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+bWVldGluZyBtaW51dGVz o7o8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IFtEYW4gUl0gV2hlbiB1c2UNClJFTE9BRCB0byBkZWNpZGUgd2hlcmUgU05NUCBu b3RpZmljYXRpb25zIGdvIG5lZWQgc29tZTxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7bWV0aG9kIHRvIHhmZXIgaW5mb3JtYXRpb24gZ2FpbmVkIGFib3V0DQpzZXNzaW9u IGludG8gU05NUCB0YXJnZXQuIFRoZXJlPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtpcyBhIHN0YW5kYXJkIHdheSB0byBjb25maWd1cmUgd2l0aA0KdGhlIHRhcmdldCBN SUIuPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbUGVuZ10gV2UgYXJl IHRoaW5raW5nIG9mIGJvdGggZGlyZWN0aW9ucy4NCk1hbmFnZXIgbmVlZHMgUkVMT0FEIHRvIGZp bmQ8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO25vZGUuIFdlIG1heSBu ZWVkIG1vcmUgdGhhbiBvbmUgbWFuYWdlci4NCk1heSBiZSBhbiBpc3N1ZSB0byBzdGF0aWNhbGx5 PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb25maWd1cmUgaW4gZW5k cG9pbnQ8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tEYW5SXSBEb24n dCBkaXNhZ3JlZSAtIGJ1dCB0aGVyZSBhcmUNCnNvbWUgZXhpc3RpbmcgU05NUCB3YXlzIHRvIGhh dmU8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO211bHRpcGxlIG1hbmFn ZXIgZHluYW1pY2FsbHksIHRoaXMgaXMNCm5vdyBhbm90aGVyIG1ldGhvZCBmb3IgZGlzY292ZXJp bmc8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0gYnV0IHRoaXMgaW5m byBuZWVkcyB0byBiZSB4ZmVyZWQgdG8NCnBsYWNlcyB3aGVyZSBzdGFuZGFyZCBTTk1QIGFnZW50 czxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7d291bGQgbG9vayBmb3Ig aXQuPGJyPg0KIDwvdHQ+PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+ DQo8YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq PGJyPg0K08ogvP6junBlbmcueW9uZ2xpbkB6dGUuY29tLmNuPGJyPg0KxNogz9+jujgxNTQzPGJy Pg0KzeIgz9+jujAyNS01Mjg3MTU0Mzxicj4NCsrWILv6o7oxMzc3NjYzNzI3NDxicj4NCrSrINXm o7owMjUtNTI4NzIxODc8YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqPC9mb250Pg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJz cDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2Nv bnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZu YnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXph dGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNw O2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNw O2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5i c3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNj bG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVu aWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5i c3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNw O2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5 Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlk dWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7 YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2Vp dmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZu YnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNw O21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNw O3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZu YnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZu YnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNw O1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJl Pg== --=_alternative 00116C09482578A0_=--