Subject: [p2p-sip] P2PSIP Charter ready for IESG

From: fluffy at cisco.com (Cullen Jennings)
Date: Tue, 2 Jan 2007 15:33:27 -0800

I want to put the charter on the IESG agenda this thursday so we can  
discuss it on the next IES call on Jan 11th.

I have talked about it with a lot of people and I would like to make  
a few trivial changes and one significant change. The significant  
change is adding text along lines of:

The initial work will assume the existence of some enrollment process  
that
provides a unique user name, credentials, and an initial set of  
bootstrap nodes
if that is required by the protocols. Developing a non-centralized  
enrollment
process is not in scope.

I think this text is consistent with the current thinking of the  
folks on this list and what we discussed in the BOF. If people are OK  
with this, I would like to include this is the version I send to the  
IESG. The version that goes to IESG next week is not final. Typically  
after going to IESG it will be sent out for IETF wide comment and we  
adjust the text at this point. After this it goes back to the IESG  
for approval as a WG.

I have attached a ascii version of my current working version of the  
charter along with a word document that have change tracking turned  
on. Please have a look and check that this includes all the latest  
changes.

Thanks, Cullen

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Post BOF charter.txt
Url: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20070102/8bb3c656/PostBOFcharter-0001.txt
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Post BOF charter.doc
Type: application/octet-stream
Size: 40448 bytes
Desc: not available
Url : https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20070102/8bb3c656/PostBOFcharter-0001.obj

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 2 Jan 2007 18:56:58 -0800

Sounds good.  Noticed a typo:

"P2PSIP clients differ from P2PSIP peers primarily in that they do not store
information in the overlay, but only use it *located* users and resources."
-- I assume you mean "to locate".

You write:

"P2PSIP clients and peers use the resolution services of the peers as an
alternative to the SIP discovery process of RFC 3263."

I think this is a really helpful definition of scope.  Would it be fair to
say that P2PSIP's goals are more or less limited to the scope of RFC 3263
and topics not covered by RFC 3263 (such as voicemail, metadata storage,
credentials, encryption, and so forth) are similarly out of scope for
P2PSIP?

If so, I notice the statement "Similarly, the group will attempt not to make
design decisions that preclude anonymous communications systems from being
crafted using the protocols defined by this WG."  This seems to go beyond
the scope of RFC 3263, and I'm curious why this is carved out as an
exception.

If we must make that exception, to minimize Quixotic design adventures, I'd
like to see a more precise definition of "anonymous communications" than is
provided by [1].  As it stands, anything short of invisibility to the NSA
fails this requirement, which implies that we can't do anything that the NSA
couldn't conceivably tap -- which means we can't really do anything at all.
I'd like a set of more precisely defined, more realistic requirements if
possible.

Finally, you write:

"The initial work will assume the existence of some enrollment process that
provides a unique user name, credentials, and an initial set of bootstrap
nodes if that is required by the protocols. Developing a non-centralized
enrollment process is not in scope."

I think this is a really great clarification.  To help make our discussion
even more concrete, will we define some kind of interface into this
credential/bootstrap service?  We needn't define precisely how these
services work internally, but without a clear understanding of their
external interface, it's like building on a sand foundation.

-david

PS: Thanks for adding "Approaches based on [multicast/dynamic-DNS]
technologies may be reasonable ways to solve similar problems but that is
not the focus of this WG."  This is also a good clarification.

[1] http://www.p2psip.org/drafts/draft-bryan-sipping-p2p-usecases-00.html

> -----Original Message-----
> From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-
> bounces at cs.columbia.edu] On Behalf Of Cullen Jennings
> Sent: Tuesday, January 02, 2007 3:33 PM
> To: P2P-SIP
> Subject: [p2p-sip] P2PSIP Charter ready for IESG
>

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Wed, 03 Jan 2007 10:17:42 +0100

Cullen Jennings wrote:
> I have talked about it with a lot of people and I would like to make a
> few trivial changes and one significant change. The significant change
> is adding text along lines of:
> 
> The initial work will assume the existence of some enrollment process that
> I think this text is consistent with the current thinking of the folks
> on this list and what we discussed in the BOF. If people are OK with
> this, I would like to include this is the version I send to the IESG.

I agree.  I think the whole text perfectly reflects two years of mail
discussions, of conference calls and of ad-hoc and official BOFs.
Thank you.

-- 
Ciao,
Enrico

---

From: drage at alcatel-lucent.com (Drage, Keith (Keith))
Date: Wed, 3 Jan 2007 13:03:53 +0100

Few minor changes on your changes - assuming the word document is
reasonably definitive (The text file seems to have lost all formatting
and is therefore pretty unreadable).

1)	In the new text:

"P2PSIP clients differ from P2PSIP peers primarily in that they do not
store information in the overlay, but only use it located users and
resources. "

We seem to have a typo that needs correction.

2)	In the new sentence:

"In this way, P2PSIP offers an alternative mechanism for determining the
correct destination for SIP messages."

Change "SIP messages" to "SIP requests".

3)	I am also not sure that "conventional" improves on "traditional"
as an adjective for SIP. They are both equally vague and indeterminate.
If your intent was to be more precise, then this fails.

4)	On the list of deliverables, the list is introduced by: "This
group's primary tasks are to produce:". This text should therefore read
direct into the new text for item 3) - which with the proposal does not
happen. The intro to item 3 should therefore be (assuming people agree
with making it optional): 

"Optionally, a proposed standard defining a P2PSIP Client Protocol for
use by P2PSIP clients, some of which may be behind NATs."

5)	I seem to remember a discussion on the current concents document
that "peer" and "client" should always be preceded by "P2PSIP". Perhaps
a final pass to check the charter terminology with this document.

6)	I also note that on the goals and milestones, in other charter
changes you have been requesting WGLC dates as well as submission to
IESG dates. Perhaps we should add these.

Regards

Keith

> From: p2p-sip-bounces at cs.columbia.edu 
> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Cullen Jennings
> Sent: 02 January 2007 23:33
> To: P2P-SIP
> I want to put the charter on the IESG agenda this thursday so 
> we can discuss it on the next IES call on Jan 11th.
> 
> I have talked about it with a lot of people and I would like 
> to make a few trivial changes and one significant change. The 
> significant change is adding text along lines of:
> 
> The initial work will assume the existence of some enrollment 
> process that provides a unique user name, credentials, and an 
> initial set of bootstrap nodes if that is required by the 
> protocols. Developing a non-centralized enrollment process is 
> not in scope.
> 
> I think this text is consistent with the current thinking of 
> the folks on this list and what we discussed in the BOF. If 
> people are OK with this, I would like to include this is the 
> version I send to the IESG. The version that goes to IESG 
> next week is not final. Typically after going to IESG it will 
> be sent out for IETF wide comment and we adjust the text at 
> this point. After this it goes back to the IESG for approval as a WG.
> 
> I have attached a ascii version of my current working version 
> of the charter along with a word document that have change 
> tracking turned on. Please have a look and check that this 
> includes all the latest changes.
> 
> Thanks, Cullen
> 
> 
>

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Wed, 3 Jan 2007 06:19:48 -0600

Just a couple of agreements with Keith...

> If your intent was to be more precise, then this fails.

I agree with Keith that "conventional" and "traditional" are indeterminate 
and will likely mean something different in 10 years. David Barrett's recent 
note on the P2PSIP seems to understand what we are NOT doing is RFC 3263. Is 
it useful to call "Classic SIP" "RFC 3263 SIP"?

> IESG dates. Perhaps we should add these.

That would be lovely.

Thanks,

Spencer

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Wed, 3 Jan 2007 06:30:29 -0800

I fully agree with the proposed text.

Thanks Cullen for all the work done over the holidays!

Henry

-----Original Message-----

Thanks, Cullen

---

From: michael.slavitch at e2exchange.com (Michael Slavitch)
Date: Wed, 3 Jan 2007 10:26:16 -0500

Excellent work Cullen.

Onwards and upwards.

On 1/2/07, Cullen Jennings <fluffy at cisco.com> wrote:
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20070103/79e13a5f/attachment.html

---

From: eunsooshim at gmail.com (Eunsoo Shim)
Date: Wed, 3 Jan 2007 10:50:49 -0500

The revised charter is very good. Thanks, Cullen.

Just one minor comment.

The text in the charter:
"P2PSIP clients differ from P2PSIP peers primarily in that they do not store
information in the overlay, but only use it located users and resources."

"located users" is a typo, I guess. It should be "to locate users".
"do not store information in the overlay" sounds a little bit confusing. I
guess you meant "do not store information for other nodes of the overlay".
I think routing messages for other nodes in the overlay is more important
difference between peers and clients.

So I'd like to suggest the following.
"P2PSIP clients differ from P2PSIP peers primarily in that they do not route
lookup and overlay maintenance messages, but only use the overlay to locate
users and resources."

Well, if there is a different opinion about whether routing is more
importance difference than storing information, I would not mind having
'storing information' mentioned as the primary difference. It is not worth a
round of discussion.

Thanks.

Eunsoo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20070103/f6f16aa3/attachment-0001.html

---

From: mlepinski at bbn.com (Matt Lepinski)
Date: Wed, 03 Jan 2007 12:44:43 -0500

I agree with Eunsoo that the phrase:

"do not store information in the overlay" is confusing (with regards to 
the differences between clients and peers).

I like Eunsoo's proposal:
"P2PSIP clients differ from P2PSIP peers primarily in that they do not 
route lookup and overlay maintenance messages, but only use the overlay 
to locate users and resources."

Or perhaps:
"P2PSIP clients differ from P2PSIP peers in that they use the overly 
only to locate users and resources. In particular, they do not store 
information for other nodes of the overlay, and they do not route lookup 
and overlay maintenance messages."

- Matt Lepinski :->

Eunsoo Shim wrote:

> resources."
> "do not store information in the overlay" sounds a little bit 
> confusing. I guess you meant "do not store information for other nodes 
> of the overlay".
> I think routing messages for other nodes in the overlay is more 
> important difference between peers and clients.
>
> route lookup and overlay maintenance messages, but only use the 
> overlay to locate users and resources."
>
> importance difference than storing information, I would not mind 
> having 'storing information' mentioned as the primary difference. It 
> is not worth a round of discussion.
>
> Thanks.
>
> Eunsoo
>
>
> On 1/2/07, *Cullen Jennings* <fluffy at cisco.com 
> <mailto:fluffy at cisco.com>> wrote:
>
>     p2p-sip at cs.columbia.edu <mailto:p2p-sip at cs.columbia.edu>
>------------------------------------------------------------------------
>

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Wed, 3 Jan 2007 09:49:18 -0800

Thanks everyone for good comments - I will try and get an updated  
copy out tonight.

---

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Wed, 3 Jan 2007 12:51:20 -0500

Matt:
 
Right.
 
The key is that a client does NOT have the "routing" capabilities while a peer does have.
 
This shall be the "key" for differentiation between the two. All others are good, but not so critical.
 
Radhika

________________________________

From: p2p-sip-bounces at cs.columbia.edu on behalf of Matt Lepinski
Sent: Wed 1/3/2007 12:44 PM
To: P2P-SIP
Subject: Re: [p2p-sip] P2PSIP Charter ready for IESG

Or perhaps:

- Matt Lepinski :->

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20070103/905a8a58/attachment.html

---

From: jiang.x.f at huawei.com (JiangXingFeng)
Date: Thu, 04 Jan 2007 10:52:17 +0800

Excellent work, thanks, Cullen!

I agree with Eunsoo that routing is a import difference between peers and
clients. 

Another comment is presented as follows:
"This protocol will define how the P2PSIP peers collectively provide for
user and resource location in a SIP environment with no or minimal
centralized servers." 
>From the above sentence I guess that in some special situations, some
central servers may be needed to put P2PSIP into operation. 

" This document will address how the protocols defined above, along with
existing IETF protocols, can be used to produce systems to locate  a peer or
client, identify appropriate resources to facilitate communications  (for
example media relays), and establish communications between the users of
these peers or clients, without relying on centralized servers. "
In this sentence, it says "without relying on centralized servers".  I think
it is confusing with what the former sentence wants to express.

Maybe we should revise it and make them consistent. 

Regards!
--
Jiang XingFeng

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Wed, 3 Jan 2007 21:20:11 -0800

Thanks for careful read - inline....

> I agree with Eunsoo that routing is a import difference between  

I thought about this long and hard. The definition of a peer and  
client has been a major source of confusion in many of the  
discussions. I went back and looked listened to some of the BOF  
recording and looked at Dean's draft. I think what we have in the  
charter now is consistent with that and I don't feel confident that  
if I change the definition of this that it will still represent what  
everyone means. Basically it has been such a confusing thing, I am  
afraid to touch it any way at this point in time. The term routing  
also has a lot of meanings and it is hard to define how the P2P folks  
use it - we both know what you mean by routing in the overlay network  
but to many folks in IETF that are not involved with this , the term  
routing might conjure up visions of how the IP packet gets from a  
client to a peer which involved layer 3 routing while what you mean  
is more layer 5. We also have the open questions about if the peers  
will do "forwarding" style routing or "redirect" style routing which  
many people do not consider routing at all.

So what I am getting at here is I agree with you Eunsoo that given  
what you mean by routing, peers will do it and clients probably  
won't, but I don't want to add that text to charter right now because  
I think it will cause more confusion than clarification.

> Maybe we should revise it and make them consistent.

I think this somewhat contradicting statement is somewhat deliberate.  
For some types of systems, we are going to need to have a central  
enrollment server - and the gateways to traditional SIP systems may  
also end up being somewhat "central" depending on you definition of  
"central". So in the first case we leave ourselves wiggle room for  
this type of thing. But the second paragraph is about the actual  
overlay protocol that provides the 3263 like functionality. Here we  
don't want to leave ourselves any wiggle room - we are saying this  
truly does have to be non centralized.

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Wed, 3 Jan 2007 21:28:02 -0800

Ok here is a updated version of the charter. I think I managed to get  
everyone's comments in other than a few that I replied to separately  
on the list. I think this is good enough to go to IESG and we can  
still revise it before the final version is done. Thanks, everyone  
(and if you catch any outrageous typo's let me know so I can fix them  
- I currently have either too little coffee or too little sleep :-)

Thanks, Cullen

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: P2PSIP-Charter-Jan3.txt
Url: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20070104/72b6fcc0/P2PSIP-Charter-Jan3-0001.txt
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: P2PSIP-charter-Jan3.doc
Type: application/octet-stream
Size: 37888 bytes
Desc: not available
Url : https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20070104/72b6fcc0/P2PSIP-charter-Jan3-0001.obj

---

From: dbarrett at quinthar.com (David Barrett)
Date: Wed, 3 Jan 2007 21:51:43 -0800

Looks great, thanks!

> Sent: Wednesday, January 03, 2007 9:28 PM
> To: P2P-SIP
> Subject: Re: [p2p-sip] P2PSIP Charter ready for IESG (take 2)
> 
>

---

From: jiang.x.f at huawei.com (JiangXingFeng)
Date: Thu, 04 Jan 2007 13:57:09 +0800

Thanks for your explanations which are very convincing to me! 
Maybe it is the best expressions in Charter, since there are a few
technology details are not deterministic at current stage. 
Regards!
--
Jiang XingFeng
> From: Cullen Jennings [mailto:fluffy at cisco.com]
> Sent: Thursday, January 04, 2007 1:20 PM
> To: JiangXingFeng
> Cc: 'Eunsoo Shim'; 'P2P-SIP'

---

From: jean-francois.wauthy at alcatel-lucent.fr (Jean-François Wauthy)
Date: Thu, 04 Jan 2007 11:54:47 +0100

See inline for comments

Cullen Jennings a ?crit :
> that allow _anonynimaztion_ of the IP address of P2PSIP peers by using
> approaches such as onion routing.
>   
I think that may be you fell asleep on your keyboard when you typed 
'anonymization' :-D
> Goals and Milestones:
>
> (Note dates our very draft
>
> Jul 2007 WGLC of P2PSIP overview document 
> Sep 2007 Submit P2PSIP overview document to the IESG (Informational)
>
> Jan 2008 WGLC of P2PSIP Client Protocol document
> Mar 2008 Submit P2PSIP Client Protocol document to the IESG (PS)
>
> Jul 2008 WGLC of P2PSIP Peer Protocol document
> Sep 2008 Submit P2PSIP Peer Protocol document to the IESG (PS)
>
> Apr 2009 WGLC of  P2PSIP usage document 
> May 2009 Submit P2PSIP usage document to the IESG (BCP)
>   
Could you tell me why you put the now optional P2PSIP Client Protocol 
document milestones before the 'mandatory' P2PSIP Peer Protocol document 
ones ? This doesn't reflect the order of the primary tasks developed in 
the charter either.

Regards,

Jean-Fran?ois Wauthy

---

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Thu, 4 Jan 2007 10:53:48 -0500

Cullen:
 
It may be OK not to modify the client and peer definition related to routing for now in the charter.
 
However, when we say "routing" in the context of p2p-SIP, it is in the p2p-SIP layer (i.e., application layer).
 
Radhika

From: p2p-sip-bounces at cs.columbia.edu on behalf of Cullen Jennings
Sent: Thu 1/4/2007 12:20 AM
To: JiangXingFeng
Cc: 'P2P-SIP'
Subject: Re: [p2p-sip] P2PSIP Charter ready for IESG

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20070104/499892c8/attachment.html

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Thu, 4 Jan 2007 10:10:52 -0800

Oh my - thank you ... inline ....

> I think that may be you fell asleep on your keyboard when you typed  

yes

>> Jul 2007 WGLC of P2PSIP overview document Sep 2007 Submit P2PSIP  
>> overview document to the IESG (Informational)
>>
>> Apr 2009 WGLC of  P2PSIP usage document May 2009 Submit P2PSIP  
>> usage document to the IESG (BCP)
>>
> Could you tell me why you put the now optional P2PSIP Client  
> Protocol document milestones before the 'mandatory' P2PSIP Peer  
> Protocol document ones ? This doesn't reflect the order of the  
> primary tasks developed in the charter either.

I don't know what I was typing - I meant to put the Peer protocol  
before the Client protocol since it will be easier to decide if the  
Client protocol is a syntactic subset of the Peer protocol or not  
once we have an idea what the Peer protocol looks like. I view all  
these dates as random numbers pulled out of thin air and hope the WG  
would refine them once they got going so we should not get too worked  
up about the dates right now but I agree I got the order backwards.