Subject: [P2PSIP] client protocol architectural issues

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 5 Dec 2007 11:17:25 -0800

There has been tons of discussions on the issue of "do we need a
client protocol?" or "why do we need a client protocol?"  We have the
topic again on the agenda this afternoon.

I want to make two assertions:
- we need a client protocol.  There's just a lot of disagreement on
what it looks like.
- most of the peer protocol proposals have a way of integrating
clients at the p2p layer.  there is some question as to what
capabilities are needed at this layer.

The major controversy seems to be over architecture.  Three options include:
1) all P2PSIP clients are SIP devices, all P2PSIP peers are SIP
devices.  Primary communication between a client and peer will be
using the peer as its default outbound proxy, with any SIP extensions
handled at the SIP layer, as in draft-li-p2psip-client-protocol.
2) P2PSIP peers are not necessarily SIP devices.  P2PSIP clients are
SIP devices and may need to interact with a peer using P2P protocol
GET/STORE operations.
3) P2PSIP peers and clients are not necessarily either SIP devices.  A
client may try to participate in the overlay by contributing storage
to help peers or other functions generally associated with overlay
peers without actually participating in all of the peer functionality.

My personal belief is that the primary P2PSIP architecture should be (1).

I think there are justifications for architecture (2), and I think
that most/all of the protocol proposals support this.

I am concerned about (3).  I know that many real P2P deployments
support this type of behavior.  In one sentence, my understanding is
that that primary motivation for these deployments is a way of making
use of devices behind NATs.  I think we (p2psip) have been looking at
different (and more complicated) NAT traversal solutions
(ICE/tunneling) because we believe many of our application scenarios
don't have the same global deployment features, and we are aiming at
topologies where most of our peers are behind NATs.  (unlike
topologies where most devices are in college dorms)

Supporting (3) significantly complicates the protocol (in other
directions than it is already complicated by other requirements such
as NAT traversal).  One of my reasons for being unsure whether we need
it is that for P2PSIP, there are already SIP-level ways of providing
services to the overlay.  In a lot of senses, merely registering an
AoR to peerid/ip mapping is providing services, because one of the
fundamental roles of a SIP device is to provide SIP services.  For the
P2PSIP case, other than resource storage, what are these services that
don't fit within the SIP model?  For applications other than SIP, what
are these services?  Wouldn't any other application have its own
application-level way of offering services?

If there is consensus that it is important for the peer protocol to
support peer/client interaction that allows the clients to provide
storage (and maybe other peer-level functionality), I'm OK with that
as long as it is optional and ideally not in the core draft, something
like draft-zheng-p2psip-client-protocol.

If the need for a "client protocol" for devices that provides
"services" requires a different architecture, I'm very curious what
they are and specific reasons why they exist and are not either
providing SIP services or merely needing to do GET/STORE with the
overlay to register their presence.

Bruce

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

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Wed, 05 Dec 2007 14:34:53 -0500

Bruce:

I like your suggestion for P2PSIP Client protocol. Let me add a little as follows:

a. Let your option (1) be the choice.
b. Let additional methods like GET/STORE.
c. Let it could have storage and other properties.

Items (b) and (c) may be added as a set of separate properties in the name of protocol/feature/capabilities and we may not call them SIP. Because any extensions of SIP for items b and c will NOT have the properties of the SIP protocol for which SIP has been charted. Moreover, we not charted to extend SIP.

The combination items a, b, and c will make a P2P Client (i.e. SIP UA + P2PSIP Client UA) and the combined protocol may be termed as P2PSIP Client protocol.

How about this?

Best regards,
Radhika

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 5 Dec 2007 14:47:44 -0500

I am opt for (3).
I don't see a reason to limit the application of the overlay to SIP.
Why would you care whether GET/PUT is used for SIP or any other
application layer protocol?
Why does option (3) make the peer protocol (and the client protocol)
more complex?
Thanks.

Eunsoo

-- 
Eunsoo

---

From: Ingmar Baumgart <[email-masked]>
Date: Wed, 05 Dec 2007 12:43:49 -0800

I'm still not convinced we need clients. But if we decide to
have clients, I also propose to use (3). We should try to avoid limiting
the peer/client protocol design to P2PSIP.

Regards,
  Ingmar

-- 
Dipl.-Inform. Ingmar Baumgart
Institut für Telematik, Universität Karlsruhe (TH)
Zirkel 2, 76128 Karlsruhe, Germany
Phone: +49 721 608 8281, Fax: +49 721 608 6789

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Wed, 05 Dec 2007 15:51:41 -0500

Inline [RRR]

----- Original Message -----
From: Eunsoo Shim 
Date: Wednesday, December 5, 2007 14:48
Subject: Re: [P2PSIP] client protocol architectural issues
To: Bruce Lowekamp 
Cc: P2PSIP Mailing List 

> Why does option (3) make the peer protocol (and the client protocol)

[RRR] A new protocol requires to redefine most of the properties what SIP has. Moreover, we are not developing P2P protocol per se. It has rather limited objectives per P2PSIP charter.

[RRR] In this respect, P2PSIP Client protocol will also be a baby step (not entirely a new development devoid of SIP per se). 

[RRR] However, I will vote for option (3), if it becomes a truely a subset of P2PSIP protocol. Either way, a P2PSIP client protocol will a lightweight protocol without being a entirely NEW protocol from SIP or P2PSIP point of view.

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 5 Dec 2007 12:58:28 -0800

Neither 1, 2, or 3 restrict the use of the overlay to SIP.

1 simply says that any application protocol, whatever it is, will have
an application protocol way of communicating with a device that knows
about the overlay.

2 says that whatever the application is, the application will be able
to use GET/STORE to provide provides the lookup and CONNECT/TUNNEL
provide connectivity if the target is behind a NAT.

3 says that there is some need for these nodes to interact at a more
basic, non-application way, that is not simply doing location for that
application.  It has nothing to do with non-SIP, it means that
whatever the application is, it's non-application.

Bruce

---

From: ZhengHewen 52048 <[email-masked]>
Date: Thu, 06 Dec 2007 16:31:00 +0800

Hi,

  In the P2PSIP session today(maybe exactly yesterady), we reached an agreement that we need P2PSIP clients, is my understanding correct?
  Since P2PSIP client protocol is the logical subset of P2PSIP peer protocol, I do not think that "Supporting (3) significantly complicates the protocol", maybe I miss something, would you tell me?  
  Personally I am in favor of (2)&(3). Maybe the real world is the combination of (1)~(3), but in (1) SIP is enough.
  By the way, it may be the final result which the peer protocol already support clients just like P2PP.

Thanks,
Hewen

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************

---

From: ZhengHewen 52048 <[email-masked]>
Date: Thu, 06 Dec 2007 16:42:37 +0800

Hi,

  Here are some supplement, any comment is appreciated.
  If we think that the SIP is only an usage over P2P layer as in RELOADv02(ASPv00), SIP is completely irrelevant to P2P layer, then (3) will be the true.

Best regards,
Hewen

----- Original Message -----
From: ZhengHewen 52048 <[email-masked]>
Date: Thursday, December 6, 2007 4:31 pm
Subject: Re: [P2PSIP] client protocol architectural issues

> Hi,
> 
>  In the P2PSIP session today(maybe exactly yesterady), we reached 
> an agreement that we need P2PSIP clients, is my understanding correct?
>  Since P2PSIP client protocol is the logical subset of P2PSIP 
> peer protocol, I do not think that "Supporting (3) significantly 
> complicates the protocol", maybe I miss something, would you tell 
> me?  
>  Personally I am in favor of (2)&(3). Maybe the real world is the 
> combination of (1)~(3), but in (1) SIP is enough.
> This email and its attachments contain confidential information 
> from HUAWEI, which is intended only for the person or entity whose 
> address is listed above. Any use of the information contained 
> herein in any way (including, but not limited to, total or partial 
> disclosure, reproduction, or dissemination) by persons other than 
> the intended recipient(s) is prohibited. If you receive this e-
> mail in error, please notify the sender by phone or email 
> immediately and delete it!
> 
> > using the peer as its default outbound proxy, with any SIP 
> extensions> handled at the SIP layer, as in draft-li-p2psip-client-
> protocol.> 2) P2PSIP peers are not necessarily SIP devices.  
> P2PSIP clients are
> > peers without actually participating in all of the peer 
> functionality.> 
> > 
> > 
> > My personal belief is that the primary P2PSIP architecture 
> should 
> > be (1).
> > 
> > that that primary motivation for these deployments is a way of 
> making> use of devices behind NATs.  I think we (p2psip) have been 
> looking at
> > as long as it is optional and ideally not in the core draft, 
> something> like draft-zheng-p2psip-client-protocol.
> >

---

From: "Eunsoo Shim" <[email-masked]>
Date: Thu, 6 Dec 2007 10:02:46 -0500

If this subject has been resolved in the meeting already, please never mind.
Otherwise....

> an application protocol way of communicating with a device that knows
I don't quite understand this sentence.

> whatever the application is, it's non-application.
I don't understand this either.

Would you mind elaborating the above (1) and (3)?
Thanks.

Eunsoo

-- 
Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Thu, 6 Dec 2007 10:04:59 -0500

>   In the P2PSIP session today(maybe exactly yesterady), we reached an agreement that we need P2PSIP clients, is my understanding correct?

Glad to hear this!

>   By the way, it may be the final result which the peer protocol already support clients just like P2PP.

I also think this is going to be the case more often than not.

Thanks.

Eunsoo

-- 
Eunsoo

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Thu, 6 Dec 2007 09:29:45 -0800

>   Since P2PSIP client protocol is the logical subset of P2PSIP peer protocol, I do not think that "Supporting (3) significantly complicates the protocol", maybe I miss something, would you tell me?

Normally when a peer decides it is responsible for a resource id, it
pulls it from its database and returns it.  If the clients are able to
contribute storage (i.e. 3), the peer must realize that it is
responsible, look in its database for the location between itself and
its clients, and route the query to the particular client.  Depending
on the protocol, it may need to do something to the response before
it's routed back to the requester.

The "client protocol" must also now support communication between the
clients and the peer to register their resources, to migrate them
between the peer and the various clients, etc. Possibly including
replication for large numbers of clients, etc.

None of these options are insurmountable (in fact there are existence
proofs).  But they complicate the protocol more than simple support
for get/put (2).

>   By the way, it may be the final result which the peer protocol already support clients just like P2PP.

All of the protocol proposals already support clients, at least 2.

>   If we think that the SIP is only an usage over P2P layer as in RELOADv02(ASPv00), SIP is completely irrelevant to P2P layer, then (3) will be the true.

We agreed that there would be a client protocol and proposals should
be designed to support it, but I believe we decided to defer a
decision as to the exact scope of the features (e.g. 2's minimal
client or 3's more powerful client).

Bruce

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Thu, 6 Dec 2007 09:39:06 -0800

> I don't quite understand this sentence.

For P2PSIP, one option for "clients" is essentially for the peer to be
acting as a proxy for clients that speak only SIP and be totally
unaware of the overlay.  Other protocols will likely have their own
way of using the peer as a client without being aware of the overlay.

> I don't understand this either.

2 is clients use the overlay's get/put.  So they know the overlay
exists and speak the p2p protocol, but don't provide storage to the
overlay, they just use it to resolve lookups.

3 says that the clients will need to do more than just simple get/put.
 Trying to contribute storage to the peer would be the most obvious
example of this.

Bruce

---

From: "Eunsoo Shim" <[email-masked]>
Date: Thu, 6 Dec 2007 13:28:47 -0500

On Dec 6, 2007 12:39 PM, Bruce Lowekamp <[email-masked]> wrote:
> unaware of the overlay.

 Other protocols will likely have their own
> way of using the peer as a client without being aware of the overlay.

This is a problem with removing the concept of Clients in the overlay layer.
If there is the Client node type, application protocols don't need to
have their own way to support  client-like devices.

>  Trying to contribute storage to the peer would be the most obvious

(2) and (3) have nothing to do with whether some nodes in the overlay
layer may or may not be coupled with SIP entities. What you are
talking about is whether the Clients will do in the overlay layer more
than just using the overlay with GET/PUT.

Thanks.

-- 
Eunsoo

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Thu, 6 Dec 2007 11:00:18 -0800

> have their own way to support  client-like devices.

My point is very simple.  Most applications that have been discussed
already exist before a p2p version has been created.  So they already
have this protocol.

> than just using the overlay with GET/PUT.

Exactly.  SIP (since it's what we're chartered for) is just the
primary working example of an application.

Bruce

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 7 Dec 2007 11:38:34 -0500

I don't quite understand how what you wrote below is connected to your
initial proposal that P2PSIP architecture should require all
devices/nodes (Peers and Clients) to be coupled with SIP entities.
Could you explain again the reason of your proposal?
Thanks.

Eunsoo

-- 
Eunsoo

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Mon, 10 Dec 2007 14:23:47 -0500

Radhika,

I think this is something along the lines of what I was thinking.
Even if we do decide that option 3/your c is necessary, I am still
hoping it will not be mandatory to implement, because I would like to
avoid the cost when it's not needed.

I think the question of when a SIP device would want to extend SIP and
when it implement functionality using get/put in a client protocol is
interesting.  You're right that we're not chartered to extend SIP, but
my understanding is that the p2psip wg can refer proposals to sipping.
 My understanding is that if we decide we need event packages on the
lines of draft-li-p2psip-client-protocol-00, then that item would be
taken up by sipping.

Bruce

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Mon, 10 Dec 2007 14:18:24 -0500

Eunsoo,

I'm sorry, I will try to be more clear.

My initial statement was that there are a range of architectural
options, which I listed as:
- option 1: the only p2psip clients are sip devices that speak sip
with p2psip peers
- option 2: there is a get/put client protocol that allows non-sip
interaction between clients and peers
- option 3: there is a more complicated client protocol that allows
"clients" to offer storage or other services to the peers

> My personal belief is that the primary P2PSIP architecture should be (1).

I still support this, for a few reasons.  First, observe that I made
that statement about P2P*SIP* (emphasis added).  It's SIP.  Discussion
of non-SIP is further down.  In a P2P*SIP* architecture, it seems
reasonable to assume that many if not most of the devices will be SIP
devices.  For compatibility with existing SIP devices (which cannot
possibly be peers), they will need a SIP proxy for connectivity, which
will most probably be a P2PSIP device.  So that's SIP being used as a
"client" protocol.  Most devices that can speak the peer protocol, I
will assume will be peers.  There are some arguments for why a P2PSIP
device can't be a peer, as your draft points out, and for almost all
of those scenarios, SIP will work fine.

Now, there are a few deployment scenarios for P2PSIP where for some
reason the clients can't use a P2PSIP peer as their proxy.  Your draft
listed some, and I think there are others.  In those cases, I think
option 2 is necessary.  I think it's necessary, it's just that the
default should be option 1.

I should add that I am assuming that if we choose to support option 2,
p2psip implementations are still free to support option 1, it's just
that the peer protocol is required to support option 2 (client
get/put).

Now, for non-SIP, well, the quick answer is that we're not chartered
to work on non-SIP.  So that's not a question about P2P*SIP*.  But the
longer answer is that I suspect most non-SIP applications will already
have their own protocol, and I still believe that the vast majority of
deployment scenarios should require no more than option 2 (although
there are obviously important applications of option 3 as well).

Bruce

---

From: "lichun li" <[email-masked]>
Date: Tue, 11 Dec 2007 09:25:51 +0800

I also think option 1 and 2 are necessary. Maybe only one type of node is
called as "client" eventually. But there should be more than one type of
node in P2PSIP other than peer.

On Dec 11, 2007 3:18 AM, Bruce Lowekamp <[email-masked]> wrote:

> > > On Dec 6, 2007 10:28 AM, Eunsoo Shim < [email-masked]> wrote:

-- 
Sincerely yours,

Lichun Li
Mobile Life New Media Lab, BUPT
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 11 Dec 2007 09:05:40 -0500

I refer you to the minutes of the IETF70 meeting held last week:
"We will have clients that will have to do at least a get-put, all protocols
will have to do that, and we'll not put a lot more meeting time into that
for now"

We observed that all of the proposed protocols have such an option defined.
That is #2.  We clearly permit #1.

At the moment, we're probably not going to want to spend more time on option
#3.  If the chosen protocol has more, okay, but I don't want to spend
endless cycles debating the merits of proposals for #3.

Some list discussion on the subject is always interesting as long as we
don't divert too much attention from more central issues.  I'd prefer to see
that discussion focused on specifics, rather than generalities, but open
discussion is always welcome.

Brian

________________________________________
From: lichun li [mailto:[email-masked]] 
Sent: Monday, December 10, 2007 8:26 PM
To: Bruce Lowekamp
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] client protocol architectural issues

Bruce

On Dec 7, 2007 11:38 AM, Eunsoo Shim <[email-masked]> wrote:
> > > On Dec 6, 2007 12:39 PM, Bruce Lowekamp <[email-masked] >

-- 
Sincerely yours,

Lichun Li

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 11 Dec 2007 07:24:27 -0800

I would like to sincerely congratulate the co-chairs for the excellent handling of the difficult WG meeting. Good job! 

But alas, nobody is perfect and I feel the client issue was handled in a heavy handed manner, showing an early manifest bias against clients and the client protocol.

> but I don't want to spend
> endless cycles debating the merits of proposals for #3

Option 3 is clearly the most interesting since it is the most powerful.

If you put time and company resources into P2P, option 3 is just too important for "I don't want to spend endless cycles debating" and probably just have to do it.

Since amending the WG charter was mentioned, the other applications, beyond SIP must also be taken into consideration, such as distributed directory and range searches as well as other applications that make the P2PSIP "call" more valuable.

My two cents,

Henry

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, December 11, 2007 6:06 AM
To: 'lichun li'; 'Bruce Lowekamp'
Cc: 'P2PSIP Mailing List'
Subject: RE: [P2PSIP] client protocol architectural issues

Brian

Bruce

-- 
Sincerely yours,

Lichun Li

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 11 Dec 2007 10:47:45 -0500

Henry

Like most IETF work group, we're subject to scope creep.  You are suggesting
scope creep; start working on non-SIP p2p before we have p2psip
standardized.

You are free to propose a charter change.  We'll see what support it gets.

Right now, it's out of scope.  It's relevant enough that we'll tolerate some
list discussion, but our scope is p2psip.

Brian 

> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Tuesday, December 11, 2007 10:24 AM
> To: Brian Rosen; lichun li; Bruce Lowekamp
> Cc: P2PSIP Mailing List
> I would like to sincerely congratulate the co-chairs for the excellent
> handling of the difficult WG meeting. Good job!
> 
> But alas, nobody is perfect and I feel the client issue was handled in a
> heavy handed manner, showing an early manifest bias against clients and
> the client protocol.
> 
> If you put time and company resources into P2P, option 3 is just too
> important for "I don't want to spend endless cycles debating" and probably
> just have to do it.
> 
> Since amending the WG charter was mentioned, the other applications,
> beyond SIP must also be taken into consideration, such as distributed
> directory and range searches as well as other applications that make the
> P2PSIP "call" more valuable.
> 
> My two cents,
> 
> Henry
> 
> > > > > For P2PSIP, one option for "clients" is essentially for the peer
> to
> be
> > > > This is a problem with removing the concept of Clients in the
> overlay
> layer.
> > > > > > > 2 says that whatever the application is, the application will
> be
> able
> > > > > > > 3 says that there is some need for these nodes to interact at
> a
> more

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 12 Dec 2007 09:59:11 -0500

> scope creep; start working on non-SIP p2p before we have p2psip
What do you mean by 'non-SIP p2p' and 'p2psip'?

> list discussion, but our scope is p2psip.
I think clients providing a storage function is as relevant to p2psip
as clients not providing a storage function is.

Thanks.

Eunsoo
> > I also think option1 and 2 are necessary.Maybe only one type of node is
> > calledas "client" eventually. Butthere should be more than one type of

-- 
Eunsoo

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 12 Dec 2007 13:26:49 -0500

> From: Eunsoo Shim [mailto:[email-masked]]
> Sent: Wednesday, December 12, 2007 9:59 AM
> To: Brian Rosen
> Cc: Henry Sinnreich; lichun li; Bruce Lowekamp; P2PSIP Mailing List
p2psip <> non-SIP p2p

We're working on the former, not the latter.

> as clients not providing a storage function is.
The consensus at the meeting was:
A client is a peer that does not do routing.  

There is no mention of "storage" in that definition.
Some protocol proposals allowed clients to store or not store.  That's ok,
but not a requirement.

Is that okay?

Brian
> > > don't divert too much attention from more central issues.  I'd prefer
> to
> > > see
> > > > > > On Dec 6, 2007 12:39 PM, Bruce Lowekamp <[email-masked]
> >
> > > wrote:
> > > > > > If there is the Client node type, application protocols don't
> need
> > > to
> > > > > > > > > basic, non-application way, that is not simply doing
> location
> > > for that
> > > > > > > exists and speak the p2p protocol, but don't provide storage
> to
> > > the
> > > > > > talking about is whether the Clients will do in the overlay
> layer
> > > more

---

From: Zheng Hewen <[email-masked]>
Date: Mon, 17 Dec 2007 10:51:25 +0800

Hi,

   Since we now have at least the consensus about P2PSIP client as below:
   (1). A client is a peer that does not do routing;
   (2). We will have clients that will have to do at least a get-put, all protocols will have to do that.

   A proposal is thrown out: the author(s) of the Concept document can update the Concept document to keep compatible with
the consensus, this update will be significantly helpful to develop Peer/client protocol.
   The discussion about P2PSIP client in this WG mail list and the I-D "P2PSIP Clients"
(http://tools.ietf.org/wg/p2psip/draft-pascual-p2psip-clients-00.txt) will provide helpful information.
   Any comment is appreciated.

Best regards,
Hewen

> Sent: 2007?12?13? 2:27
> To: 'Eunsoo Shim'
> Cc: 'Henry Sinnreich'; 'P2PSIP Mailing List'
> > > You are free to propose a charter change.  We'll see what
> support it
> > gets.
> > >
> > > Right now, it's out of scope.  It's relevant enough that we'll
> > > tolerate
> > some
> Some protocol proposals allowed clients to store or not
> store.  That's ok, but not a requirement.
>
> Is that okay?
>
> Brian
> >
> > Thanks.
> >
> > Eunsoo
> > >
> > > > I would like to sincerely congratulate the co-chairs for the
> > > > excellent handling of the difficult WG meeting. Good job!
> > > >
> > > > But alas, nobody is perfect and I feel the client issue was
> > > > handled in
> > a
> > > > heavy handed manner, showing an early manifest bias against
> > > > clients
> > and
> > > > the client protocol.
> > > >
> > > > If you put time and company resources into P2P, option
> 3 is just
> > > > too important for "I don't want to spend endless cycles
> debating"
> > > > and
> > probably
> > > > just have to do it.
> > > >
> > > > Since amending the WG charter was mentioned, the other
> > > > applications, beyond SIP must also be taken into consideration,
> > > > such as distributed directory and range searches as
> well as other
> > > > applications that make
> > the
> > > > "We will have clients that will have to do at least a
> get-put, all
> > > > protocols will have to do that, and we'll not put a lot more
> > > > meeting time into
> > that
> > > > for now"
> > > >
> > > > We observed that all of the proposed protocols have
> such an option
> > > > defined.
> > > > At the moment, we're probably not going to want to
> spend more time
> > > > on option #3.  If the chosen protocol has more, okay,
> but I don't
> > > > want to spend endless cycles debating the merits of
> proposals for
> > > > #3.
> > > >
> > > > Some list discussion on the subject is always
> interesting as long
> > > > as
> > we
> > > > that discussion focused on specifics, rather than generalities,
> > > > but
> > open
> > > > I also think option1 and 2 are necessary.Maybe only one type of
> > > > node
> > is
> > > > calledas "client" eventually. Butthere should be more than one
> > > > type of node in P2PSIP other than peer.
> > > >
> > > >
> > > > - option 3: there is a more complicated client protocol that
> > > > allows "clients" to offer storage or other services to the peers
> > > >
> > > >
> > > > > should be
> > > > (1).
> > > > I still support this, for a few reasons. First, observe that I
> > > > made that statement about P2P*SIP* (emphasis added). It's SIP.
> > > > Discussion of non-SIP is further down. In a P2P*SIP*
> architecture,
> > > > it seems reasonable to assume that many if not most of
> the devices
> > > > will be SIP devices. For compatibility with existing
> SIP devices
> > > > (which cannot possibly be peers), they will need a SIP
> proxy for
> > > > connectivity, which will most probably be a P2PSIP device. So
> > > > that's SIP being used as a "client" protocol. Most devices that
> > > > can speak the peer protocol, I will assume will be peers. There
> > > > are some arguments for why a P2PSIP device can't be a peer, as
> > > > your draft points out, and for almost all of those
> scenarios, SIP will work fine.
> > > >
> > > > Now, there are a few deployment scenarios for P2PSIP where for
> > > > some reason the clients can't use a P2PSIP peer as their proxy.
> > > > Your draft listed some, and I think there are others. In those
> > > > cases, I think option 2 is necessary. I think it's
> necessary, it's
> > > > just that the default should be option 1.
> > > >
> > > > I should add that I am assuming that if we choose to support
> > > > option 2, p2psip implementations are still free to
> support option
> > > > 1, it's just that the peer protocol is required to
> support option
> > > > 2 (client get/put).
> > > >
> > > > Now, for non-SIP, well, the quick answer is that we're not
> > > > chartered to work on non-SIP. So that's not a question about
> > > > P2P*SIP*. But the longer answer is that I suspect most non-SIP
> > > > applications will already have their own protocol, and I still
> > > > believe that the vast majority of deployment scenarios should
> > > > require no more than option 2 (although there are
> obviously important applications of option 3 as well).
> > > >
> > > > Bruce
> > > >
> > > >
> > > > > I don't quite understand how what you wrote below is
> connected
> > > > > to
> > your
> > > > > On Dec 6, 2007 2:00 PM, Bruce Lowekamp
> <[email-masked]>
> > wrote:
> > > > > > > > For P2PSIP, one option for "clients" is essentially for
> > > > > > > > the
> > peer
> > > > to
> > > > be
> > > > > > > > way of using the peer as a client without being
> aware of
> > > > > > > > the
> > > > overlay.
> > > > > > > >
> > > > > > >
> > > > > > > > > > 2 says that whatever the application is, the
> > > > > > > > > > application
> > will
> > > > be
> > > > able
> > > > > > > > > > 3 says that there is some need for these nodes to
> > > > > > > > > > interact
> > at
> > > > a
> > > > more
> > > > > > > > > > application. It has nothing to do with non-SIP, it
> > > > > > > > > > means
> > that
> > > > > > > > 3 says that the clients will need to do more than just
> > > > > > > > simple
> > > > get/put.
> > > > > > > > Trying to contribute storage to the peer would
> be the most
> > > > obvious
> > > > > > > > example of this.
> > > > > > > >
> > > > > > >
> > > > > > > (2) and (3) have nothing to do with whether some nodes in
> > > > > > > the
> > > > overlay
> > > > > > > layer may or may not be coupled with SIP
> entities. What you
> > > > > > > are talking about is whether the Clients will do in the
> > > > > > > overlay
> > layer
> > > > more