Subject: [P2PSIP] Re: [p2p-sip] Comments on draft-willis-p2psip-concepts-03

From: Philip Matthews <[email-masked]>
Date: Fri, 2 Mar 2007 19:55:43 -0500

I have almost finished the -04 revision to the draft,
and I am just making sure I have addressed all your comments.
Inline are my replies to your comments.

- Philip

On 30-Oct-06, at 20:51 , Eric Rescorla wrote:

> $Id: draft-willis-p2psip-concepts-03-rev.txt,v 1.1 2006/10/30  
> 20:44:54 ekr Exp $
>
> GENERAL COMMENTS
> Overall, this document is pretty good, however I think the bit about
> the P2PSIP Peer Protocol versus the P2PSIP Client Protocol is kind of
> confusing.
>
> I definitely agree that there will be two kinds of nodes
>
> - Those which store other people's state data.
> - Those which don't.
>
> The terms you've chosen (Peers and Clients) seem to be as good as any
> for this purpose.
>
> With that said, there are three basic designs:
>
> 1. Clients understand the overlay network, they just don't
>    store data. To take a concrete example from Chord, there's
>    no reason you can't connect to a Chord node, suck down an
>    appropriate finger/routing table and then send messages
>    to other Chord nodes just as if you were a Peer. The
>    only thing you don't do is *register* with the network.
>
> 2. Clients don't understand the overlay network, they just
>    treat some subset of peers as servers to which they can
>    do gets/puts. This is roughly the architecture that OpenDHT
>    implements now.
>
> 3. Clients don't understand the overlay network and just treat
>    it as one big clustered SIP server.
>
> I think the intention here is for this document to be agnostic between
> these three designs (and if it's not, it should be) but I don't think
> it does that that well in a number of cases. In particular,
> the question of whether the client protocol should be SIP sort
> of confuses two queFrom [email-masked] Fri Mar 02 22:06:59 2007
From: Philip Matthews <[email-masked]>
Date: Fri, 2 Mar 2007 19:55:43 -0500
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: [P2PSIP] Re: [p2p-sip] Comments on draft-willis-p2psip-concepts-03

I have almost finished the -04 revision to the draft,
and I am just making sure I have addressed all your comments.
Inline are my replies to your comments.

- Philip

On 30-Oct-06, at 20:51 , Eric Rescorla wrote:

> $Id: draft-willis-p2psip-concepts-03-rev.txt,v 1.1 2006/10/30  
> 20:44:54 ekr Exp $
>
> GENERAL COMMENTS
> Overall, this document is pretty good, however I think the bit about
> the P2PSIP Peer Protocol versus the P2PSIP Client Protocol is kind of
> confusing.
>
> I definitely agree that there will be two kinds of nodes
>
> - Those which store other people's state data.
> - Those which don't.
>
> The terms you've chosen (Peers and Clients) seem to be as good as any
> for this purpose.
>
> With that said, there are three basic designs:
>
> 1. Clients understand the overlay network, they just don't
>    store data. To take a concrete example from Chord, there's
>    no reason you can't connect to a Chord node, suck down an
>    appropriate finger/routing table and then send messages
>    to other Chord nodes just as if you were a Peer. The
>    only thing you don't do is *register* with the network.
>
> 2. Clients don't understand the overlay network, they just
>    treat some subset of peers as servers to which they can
>    do gets/puts. This is roughly the architecture that OpenDHT
>    implements now.
>
> 3. Clients don't understand the overlay network and just treat
>    it as one big clustered SIP server.
>
> I think the intention here is for this document to be agnostic between
> these three designs (and if it's not, it should be) but I don't think
> it does that that well in a number of cases. In particular,
> the question of whether the client protocol should be SIP sort
> of confuses two questions: the fundamental architectural issue
> above with the detail of wire encoding.

I think all three designs are now discussed in a new section on
the possible roles of a client.

>
>
> DETAILED COMMENTS
> S 2.
>       P2PSIP Client:  A node participating in a P2PSIP Overlay that
>       provides neither routing nor route storage and retrieval  
> functions
>       to that P2PSIP Overlay.  The P2PSIP Client interacts with the
>       P2PSIP Overlay by having an association (details TBD) with  
> one or
>       more P2PSIP peers.
>
> This wouldn't be that accurate a description of case (1) above, since
> there isn't an association with any peers. You just have a routing
> table and contact whoever is appropriate.

The text now reads
    P2PSIP Client:  A node participating in a P2PSIP Overlay that is  
less
       capable than a P2PSIP Peer in some way.  The role of a P2PSIP
       Client is still under debate, with a number of competing
       proposals, and some have suggested removing the concept entirely
       (see the discussion on this later in the document).  If clients
       exist, then it has been agreed that they do have the ability to
       add, modify, inspect, and delete information in the overlay.   
Note
       that the term client does not imply that this node is a SIP UAC.
       Some have suggested that the word 'client' be changed to  
something
       else to avoid both this confusion and the implication of a  
client-
       server relationship.

>
>
>    P2PSIP Resource-ID:  A non-human friendly value that uniquely
>       determines which P2PSIP Peer is responsible for storing
>       information about this resource (user).
>
> Well, "uniquely" isn't right here since most such schemes replicate
> for high availability.

The text no longer claims that the the Resource-ID uniquely identifies
a peer. Rather, it uniquely identifies the resource.

>
>     P2PSIP Client Protocol:  The protocol spoken between P2PSIP  
> Clients
>       and the P2PSIP Peer they use to store or retrieve information  
> from
>       the P2P Overlay.
>
> Who says there's just one? See above.

The sentence now reads:
     The protocol spoken between P2PSIP Clients and P2PSIP Peers.

>
>
>       is expected to be a principle topic of the detailed design work.
>
> s/principle/principal/

This sentence was removed in the rewrite.

>
>
> S 3.5.2.
>    P2PSIP Peers directly interact with and contain the routing and
>    storage fabric of the overlay.  P2PSIP Clients simply use the  
> routing
>    and storage facilities provided by the peers to get and put
>    information.  The peers speak the P2PSIP Peer Protocol, which can
>    express all the necessary routing and storage operations  
> required for
>    the overlay.  Clients speak the P2PSIP Client protocol, which is
>    presumably a subset of the peer protocol, and is limited to storage
>    insertion (put) and storage retrieval (get).  Some designs do not
>    require a separate client protocol.
>
> If it's SIP, I don't see how it's a subset of the peer protocol.

There has been a major rewrite in this area, and the new text now  
contains
the following paragraph:
    If the P2PSIP model also contains clients, then a protocol is needed
    for client - peer communication.  Until a better name is found, this
    protocol has been dubbed the P2PSIP Client Protocol.  The details of
    this protocol are also very much under debate.  However, if the
    client protocol exists, then it is agreed that it should be a  
logical
    subset of the peer protocol.  In other words, the syntax of the peer
    and client protocols may be completely different, but any operation
    supported by client protocol is also supported by the peer protocol.
    This implies that clients cannot do anything that peers cannot also
    do.

>
>
> S 3.5.3.
>    To get started, users must be enrolled in the overlay.  We do not
>    have a process or protocol for this, nor are we certain we need a
>    standardized mechanism.  We presume that after enrollment, the user
>    has a distinguished stions: the fundamental architectural issue
> above with the detail of wire encoding.

I think all three designs are now discussed in a new section on
the possible roles of a client.

>
>
> DETAILED COMMENTS
> S 2.
>       P2PSIP Client:  A node participating in a P2PSIP Overlay that
>       provides neither routing nor route storage and retrieval  
> functions
>       to that P2PSIP Overlay.  The P2PSIP Client interacts with the
>       P2PSIP Overlay by having an association (details TBD) with  
> one or
>       more P2PSIP peers.
>
> This wouldn't be that accurate a description of case (1) above, since
> there isn't an association with any peers. You just have a routing
> table and contact whoever is appropriate.

The text now reads
    P2PSIP Client:  A node participating in a P2PSIP Overlay that is  
less
       capable than a P2PSIP Peer in some way.  The role of a P2PSIP
       Client is still under debate, with a number of competing
       proposals, and some have suggested removing the concept entirely
       (see the discussion on this later in the document).  If clients
       exist, then it has been agreed that they do have the ability to
       add, modify, inspect, and delete information in the overlay.   
Note
       that the term client does not imply that this node is a SIP UAC.
       Some have suggested that the word 'client' be changed to  
something
       else to avoid both this confusion and the implication of a  
client-
       server relationship.

>
>
>    P2PSIP Resource-ID:  A non-human friendly value that uniquely
>       determines which P2PSIP Peer is responsible for storing
>       information about this resource (user).
>
> Well, "uniquely" isn't right here since most such schemes replicate
> for high availability.

The text no longer claims that the the Resource-ID uniquely identifies
a peer. Rather, it uniquely identifies the resource.

>
>     P2PSIP Client Protocol:  The protocol spoken between P2PSIP  
> Clients
>       and the P2PSIP Peer they use to store or retrieve information  
> from
>       the P2P Overlay.
>
> Who says there's just one? See above.

The sentence now reads:
     The protocol spoken between P2PSIP Clients and P2PSIP Peers.

>
>
>       is expected to be a principle topic of the detailed design work.
>
> s/principle/principal/

This sentence was removed in the rewrite.

>
>
> S 3.5.2.
>    P2PSIP Peers directly interact with and contain the routing and
>    storage fabric of the overlay.  P2PSIP Clients simply use the  
> routing
>    and storage facilities provided by the peers to get and put
>    information.  The peers speak the P2PSIP Peer Protocol, which can
>    express all the necessary routing and storage operations  
> required for
>    the overlay.  Clients speak the P2PSIP Client protocol, which is
>    presumably a subset of the peer protocol, and is limited to storage
>    insertion (put) and storage retrieval (get).  Some designs do not
>    require a separate client protocol.
>
> If it's SIP, I don't see how it's a subset of the peer protocol.

There has been a major rewrite in this area, and the new text now  
contains
the following paragraph:
    If the P2PSIP model also contains clients, then a protocol is needed
    for client - peer communication.  Until a better name is found, this
    protocol has been dubbed the P2PSIP Client Protocol.  The details of
    this protocol are also very much under debate.  However, if the
    client protocol exists, then it is agreed that it should be a  
logical
    subset of the peer protocol.  In other words, the syntax of the peer
    and client protocols may be completely different, but any operation
    supported by client protocol is also supported by the peer protocol.
    This implies that clients cannot do anything that peers cannot also
    do.

>
>
> S 3.5.3.
>    To get started, users must be enrolled in the overlay.  We do not
>    have a process or protocol for this, nor are we certain we need a
>    standardized mechanism.  We presume that after enrollment, the user
>    has a distinguished name within the overlay (example:
>
> Don't use "distinguished name" here. It's a technical term from
> PKIX and it doesn't mean this. "unique name"?

The text now talks about a "unique name".

>
> S 4.5.
>
>    When forwarding requests, are the bodies of the requests visible to
>    peers?  If so, this creates substantial security problems that the
>    deployers of conventional SIP have been willing to mostly ignore.
>    Can we make peers cryptotransparent (like HTTP proxies) when  
> security
>    is requested?
>
> I don't think I understand what "cryptotransparent" means, and since
> HTTP proxies operate in a bunch of different modes, some quite  
> transparent
> and some quite invasive. Maybe just rename this to "security of  
> requests"
> and remove the last sentence?

I have rewritten this section to remove "cryptotransparency and  
remove the last sentence.

- Philip

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: Dean Willis <[email-masked]>
Date: Sun, 4 Mar 2007 14:00:29 -0600

> The text now talks about a "unique name".

Having originally written the text that said "distinguished name", I  
still think that's what I meant.

A DN identifies an entry in a directory. The namespace of the P2PSIP  
overlay is really just a directory.

While X.520 and LDAP have their own representations of DN (and we  
have RFC 2253 for transforming X.520's ASN.1 representation of DN  
into a string representation and RFC 2247 to show how to use domains  
in a DN), there's nothing that says p2psip can't have it's own  
representation of DN.

However: since we're essentially assuming an identity model based on  
X.509 certificates (which might possibly be self-signed), I see no  
reason why the DN used in p2psip needs to be different from the DN  
used in the certificates used by p2psip (possibly with an RC 2247  
symmetric transformation into domain notation).

--
Dean