Subject: [p2p-sip] Revised Draft Charter for P2PSIP

From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 20 Sep 2006 15:01:09 -0500

Eunsoo, David, Bryan, Cullen and I have gone around on the charter  
several times, hoping to build-in what we learned at the last ad-hoc  
and from IESG comments received.

Here's where I think we're at. It's MUCH smaller than what we started  
with, and I feel fairly good about it.

Peer-to-Peer Session Initiation Protocol (P2PSIP)

Chairs:
TBD

RAI Area Director(s):
Cullen Jennings
Jon Peterson

RAI Area Advisor:
Cullen Jennings

Mailing Lists:
General Discussion: p2p-sip at cs.columbia.edu
Subscribe at: http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip
Archive at: http://lists.cs.columbia.edu/pipermail/p2p-sip/

Description of the Working Group:

The Peer-to-Peer (P2P) Session Initiation Protocol working group
(P2PSIP WG) is chartered to develop protocols and mechanisms for the
use of the Session Initiation Protocol (SIP) in settings where the
service of establishing and managing sessions is principally handled
by a collection of intelligent endpoints, or P2PSIP overlay peers,  
rather
than centralized servers as in client-server SIP as currently deployed.
A number of cases where such an architecture is desirable have been
documented in [1].

The terminology and concepts draft [2] explains the terms and concepts
used here. The work focuses on collections of nodes called "P2PSIP
overlay peers" and "P2PSIP overlay clients". P2PSIP overlay peers  
manifest
a distributed namespace in which overlay users are identified and  
provides
mechanisms for locating users or resources within the P2PSIP overlay.
P2PSIP overlay clients  and peers use the resolution services of the  
peers
as an alternative to the SIP correspondent discovery process of RFC  
3263.
Session management, messaging, and presence functions are performed
using traditional SIP.

This group's primary tasks are to produce:

1. An overview document explaining concepts, terminology, rationale,
and illustrative use cases for the remaining work.

2. A proposed standard defining a P2PSIP Overlay Peer Protocol. This
protocol is used between P2PSIP overlay peers, some of which may be
behind NATs. This protocol will define how the P2PSIP overlay peers
collectively provide for user and resource location in a SIP environment
with no or minimal centralized serves. This protocol may or may not be
syntactically based on SIP, a decision to be made by the WG. The
group will identify and require one base P2P algorithm (likely a  
particular
Distributed Hash Table (DHT) algorithm), while allowing for additional
optional algorithms in the future.

3. A proposed standard defining a P2PSIP Overlay Client Protocol for
use by P2PSIP overlay clients, some of which may be behind NATs. This
protocol will define how the P2PSIP overlay clients query and/or modify,
the resource location information of the overlay. While clearly a  
logical
subset of the P2PSIP Overlay Protocol, the WG will determine if the  
client
protocol is a syntactic subset of the peer protocol, and whether the  
client
protocol has SIP based syntax.

4. An architecture document. This document will address how the  
protocols
defined above, along with existing IETF protocols, can be used to  
produce
systems to locate a user, identify appropriate resources to facilitate
communications (for example media relays), and establish communications
between the users, without relying on centralized servers.

The work planned for the P2PSIP working group is distinct from, but
requires close participation with other IETF WGs, particularly SIP,
SIPPING, SIMPLE, BEHAVE and MMUSIC. The group cannot modify the
baseline SIP behavior, define a new version of SIP, or attempt to
produce a parallel protocol for session establishment. If
the group determines that any capabilities requiring an extension to
SIP are needed, the group will seek to define such extensions within
the SIP working group using the SIP change process (RFC 3427).
Similarly, existing tools developed in the BEHAVE and MMUSIC groups
will be used for NAT traversal, with extensions or changes desired to
support P2PSIP created in these groups.

The working group takes it as an unfortunate fact that NATs and
firewalls exist in the Internet, and will ensure that the protocols
produced work in their presence as much as possible. 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.

The following topics are excluded from the Working Group's scope:

1. Issues specific to applications other than locating users and
resources for SIP-based communications and presence.

2. Solving "research" type questions related to P2PSIP or P2P in
general. The WG will instead forward such work to the IRTF. Examples
include fully distributed schemes for assuring unique user identities
and the development of P2P-based replacements for DNS.

3. Locating resources based on something other than URIs.
In other words, arbitrary search of attributes is out of scope, but
locating resources based on their URIs is in scope.

4. Multicast and dynamic DNS based approaches for locating
users and resources.

Goals and Milestones

Sep 2007        Submit P2PSIP overview document to the IESG
(Informational)

Sep 2008        Submit P2PSIP overlay client protocol document to the
IESG (Standards track)

Sep 2008        Submit P2PSIP overlay peer protocol document to the
IESG (Standards track)

May 2009	Submit P2PSIP architecture document to the IESG
(Standards track)

References

  [1] D. Bryan, E. Shim, B. B. Lowekamp, "Use Cases for Peer-to-Peer
Session Initiation Protocol (P2PSIP)",
draft-bryan-sipping-p2p-usecases-00.txt, November 29, 2005

[2] D. Willis, D. Bryan, P. Matthews, E. Shim, "Concepts and
Terminology for Peer to Peer SIP," draft-willis-p2psip-concepts-01.txt
(work-in-progress), August 18, 2006

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Wed, 20 Sep 2006 15:34:38 -0500

Hi, Dean/Eunsoo/David/Bryan/Cullen,

This actually does look fairly good (Dean's words). I have a couple of 
questions.

- I have unanswered comments on the current concepts/terminology draft that 
are applicable to the charter (since it uses terminology from that draft). 
Does this mean that I have comments on the charter?

- I won't challenge the dates because they may very well be realistic, but 
they sure are a long way into the future.

- The current use cases draft has use cases that would benefit from 
multicast discovery. Does excluding multicast discovery sidestep 
prioritization of use cases?

- Forwarding research topics "to the IRTF" - does this mean "to the IRTF 
P2PRG research group"?

Thanks,

Spencer

> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Wed, 20 Sep 2006 13:47:54 -0700

This is an excellent charter.
Nothing is perfect so I suggest we leave 'as is'.

The only comment I have is that 3 years is a long time for this work on
definitions (mainly). 

How many users will Skype have by then? :-) 
Or even worse, how many incompatible P2P SIP implementations will there
be?

Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Dean Willis
Sent: Wednesday, September 20, 2006 4:01 PM
To: p2p-sip at cs.columbia.edu
Cc: David A. Bryan
Subject: [p2p-sip] Revised Draft Charter for P2PSIP

Chairs:
TBD

RAI Area Director(s):
Cullen Jennings
Jon Peterson

RAI Area Advisor:
Cullen Jennings

Mailing Lists:

Goals and Milestones

References

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 20 Sep 2006 15:58:22 -0500

> Does this mean that I have comments on the charter?

Only if the comments change the words in the concepts and terms draft  
that are used in the charter.

> they sure are a long way into the future.

My therapist says I'm becoming more of a realist. But my minister  
thinks I'm a hopeless optimist.

Of course, nobody complains if we get done sooner.

> prioritization of use cases?

I don't know. Do we have a use-case deliverable in greater detail  
than that required for the concepts or architectures deliverables?

> - Forwarding research topics "to the IRTF" - does this mean "to the  

Maybe. Depends on the topic ;-).

--
Dean

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 20 Sep 2006 22:43:27 -0700

> How many users will Skype have by then? :-)

[pp]: the cruel is, with competition from p2p-sip or not, skype in years
will gain a even larger number of users that very few folks here will like
to see, so the worry is needless for your health.

the good is, p2p-sip and skype can coexist, just like my son always opens
msn/aol and my colleagues open msn/gtalk/skype on their screens. such a
disloyalty is for your sleep.

> Or even worse, how many incompatible P2P SIP implementations will there
[pp]: "even worse"? if the history created by linux (against unix) or by
skype (against cs-sip) can carry you back to an eternity -- "the best takes
it.", there CAN'T be any INcompatible p2p-sip implementation eventually.

the best will take it, regardless of its (in)compatibility with the P2P SIP
*here* or elsewhere.

maybe yours this time for Adobe can be the one :-)

peter!

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Thu, 21 Sep 2006 14:36:11 +0200

Hi Dean,

thank you for a very good job!  I have just a few comments.

> between the users, without relying on centralized servers.

Some architectural assumptions -- mainly the client/peer distinction --
are at the very base of the work.  I understand (do I?) that here
"architecture" means something different or at least more complex, but
maybe it could be misinterpreted.  I think that if we don't change the
wording, we'll have to deal many and many times with the objection "Hey,
you are going to work on a protocol before deciding how to use it in
real life".

Just off the top of my head, instead of current #4, if I've actually
understood what it means, I'd prefer something like:
4'. A document defining some additional resources which can be
registered in overlays and used to facilitate communications (e.g. media
relays).
5'. A document addressing how communications can happen between users
registered in different overlays and/or canonical SIP networks.

> [..]

This does not preclude some solutions for problems that are actually in
scope (e.g. bootstrap, interworking) from using multicast and dynamic
DNS, does it?

> (work-in-progress), August 18, 2006

Just an editorial note: all the charters I've read have references to
drafts directly inline.  I don't know if it is better to have a
traditional "Reference" section, but, since the charter is likely to be
long-living and drafts will be certainly updated, maybe it is at least
worth stripping the version number from the name.

--
Ciao,
Enrico
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster at telecomitalia.it.

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

---

From: bryan at ethernot.org (David A. Bryan)
Date: Thu, 21 Sep 2006 09:08:05 -0400

> thank you for a very good job!  I have just a few comments.

Thanks. Nice to know folks appreciate our work!

More comments inline...

> registered in different overlays and/or canonical SIP networks.

Hmmm...what I was going for there was a "now that we defined the
tools, here is how you would put them together to do things" sort of a
concept. I think we all agreed that architecture might not have been
the best word, but not sure what else to call it.

The idea is to document how to do things (like what you mention above)
and actually build a workable system with the tools the earlier
charter items deliver. Other name suggestions?

> scope (e.g. bootstrap, interworking) from using multicast and dynamic

Nope. I don't think anyone is trying to preclude those from being
mechanisms for bootstrap or interworking, but rather as the underlying
resource location mechanism. I thought I captured that by saying
"locating users and resources", but I maybe not. Others think this is
too vauge?

David

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Thu, 21 Sep 2006 10:24:57 -0400

I have but one comment:

"The working group takes it as an unfortunate fact that NATs and
firewalls exist in the Internet, and will ensure that the protocols
produced work in their presence as much as possible. "

The word 'unfortunate' is editorializing, .  NATs have a purpose and people
use them. The IETF doesn't decide what is good.
Such pejorative comments have no place in a charter.

Apart from that I am happy and we should get on with it.

I agree with Henry that three years is a long time but that is a deadline
for the charter, not for the group itself.  Let's deliver ahead of
schedule.

Regards

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060921/dadb14e4/attachment.html

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 21 Sep 2006 11:48:56 -0400

> Such pejorative comments have no place in a charter.

I think we can remove the word 'unfortunate' from the charter without
hurting the charter.

> for the charter, not for the group itself.  Let's deliver ahead of

It's a good spirit! :-)

Thanks.

Eunsoo

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 21 Sep 2006 12:02:13 -0400

My comments are inline.

>> registered in overlays and used to facilitate communications (e.g. media
I think this is covered by the current text. The current text targets at
more than this as explained below by David.

>> registered in different overlays and/or canonical SIP networks.

I think it is covered by the current text. Otherwise it is case I don't
understand the meaning of the proposed text above.

>> worth stripping the version number from the name.

Hmm, it is a problem of referring to drafts in the charter.
Your suggestion sounds OK. Well, the draft names may change in the
future, too. :-(

Thanks.

Eunsoo

---

From: swb at employees.org (Scott W Brim)
Date: Thu, 21 Sep 2006 12:20:32 -0400

First, I'm hesitant about referring to drafts in the charter.
RFCs yes, but drafts are evanescent.  Second, even assuming it's okay
to do so, it makes the charter circular.

  > The terminology and concepts draft [2] explains the terms and
  > concepts used here.

and

  > 1. An overview document explaining concepts, terminology,
  > rationale, and illustrative use cases for the remaining work.

So the charter is based on the terminology and concepts draft as
fundamental in defining the scope of the work to be done, but the
first task is to finish defining them (and even possibly package them
differently).  Also the terminology and concepts do make assumptions
about architecture, and an architecture document is yet another
output.  Circular?

> The group will identify and require one base P2P algorithm (likely a
> particular Distributed Hash Table (DHT) algorithm), while allowing
> for additional optional algorithms in the future.

Is there a need for the () in the charter?

> resources for SIP-based communications and presence.

OK as long as "locate" is broadly defined.  Allow for "location" to be
determined "late" depending on the details of the desired
communication, etc.

> May 2009	Submit P2PSIP architecture document to the IESG

If an "architecture" is to be useful then it should be done before, or
at least at the same time as, the protocols.  We will certainly know
what the architecture is as we do the protocols.  So either it can be
bumped to Sep 2008 if not earlier, or you don't really mean an
architecture document -- perhaps the architecture will be in the
overview, and this will be an applicability document?

swb

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Thu, 21 Sep 2006 18:22:56 +0200

> understand the meaning of the proposed text above.

It just mean to be a rewording of the current text without the term
"architecture", so... I'm glad to see that you think it doesn't state
anything different :-)

> Your suggestion sounds OK. Well, the draft names may change in the

Ok, I understand the problem is bigger than what I noticed.

-- 
Ciao,
Enrico

Ahem.. Sorry, the notice below is not my fault :-(
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: bryan at ethernot.org (David A. Bryan)
Date: Thu, 21 Sep 2006 13:23:02 -0400

It definitely seems clear we need a new name for the latter
"architecture" document. The idea was that the "overview" deliverable
(the first one) was the background/basic framework document, and the
later architecture document (the last deliverable listed) was a "how
to use the tools produced by this group" sort of thing.

Applicability document is going down the right path name-wise. Any
other suggestions?

David

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 21 Sep 2006 13:27:55 -0400

I see the problem of 'being circular' in referring to the drafts.
Well, things are not happening strictly sequentially here for P2P SIP
standardization.
I believe it is because P2P SIP is one of major innovations rather than
a small extension of any existing IETF protocol. So even establishing
agreeable terminology is not a trivial task. Neither is establishing
agreeable architecture description. Then we have a problem in
identifying what protocols we are going to design.
One possible approach is chartering only for terminology, concepts, and
architecture, and so except the protocols.
Another possible approach is reaching a quite ROUGH agreement on the
terminology and concept, identifying the protocols to design and writing
the charter. In this approach, the terminology and so on need to be
reviewed and refined (or reworked) by the working group to be formed.

Well, we took the second approach and here we are. I think it was a good
and practical approach for the P2P SIP case.
The authors of the charter draft put references to the draft to avoid
confusion about the newly introduced terminology.

One solution is removing the reference section and somehow making sure
future readers of the charter know that there are such reference
documents. I don't know how to achieve the second part but I think it is
not a bad idea if it is important to avoid the 'circularity' problem.

Regarding the architecture document, first please take a look at David
Bryan's response to Enrico's comments about the architecture document.
Anyway usually major work and discussion are done much before than
submission to IESG. So later target does not mean we will have nothing
when we work on the protocol specifications. In any case I think we can
make the target date earlier as you suggested.

Thanks.

Eunsoo

---

From: swb at employees.org (Scott W Brim)
Date: Thu, 21 Sep 2006 13:30:32 -0400

> Applicability document is going down the right path name-wise. Any

See below for RFC 2026 on applicability statements.  It can be called
a framework, an AS, anything -- even an architecture :-).  In the
charter you can just refer to it generically as an AS.

swb

3.  INTERNET STANDARD SPECIFICATIONS

   Specifications subject to the Internet Standards Process fall into
   one of two categories:  Technical Specification (TS) and
   Applicability Statement (AS).

...

3.2  Applicability Statement (AS)

   An Applicability Statement specifies how, and under what
   circumstances, one or more TSs may be applied to support a
   particular Internet capability.  An AS may specify uses for TSs
   that are not Internet Standards, as discussed in Section 7.

   An AS identifies the relevant TSs and the specific way in which
   they are to be combined, and may also specify particular values or
   ranges of TS parameters or subfunctions of a TS protocol that must
   be implemented.  An AS also specifies the circumstances in which
   the use of a particular TS is required, recommended, or elective
   (see section
   3.3).

   An AS may describe particular methods of using a TS in a restricted
   "domain of applicability", such as Internet routers, terminal
   servers, Internet systems that interface to Ethernets, or datagram-
   based database servers.

   The broadest type of AS is a comprehensive conformance
   specification, commonly called a "requirements document", for a
   particular class of Internet systems, such as Internet routers or
   Internet hosts.

   An AS may not have a higher maturity level in the standards track
   than any standards-track TS on which the AS relies (see section
   4.1).  For example, a TS at Draft Standard level may be referenced
   by an AS at the Proposed Standard or Draft Standard level, but not
   by an AS at the Standard level.

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Thu, 21 Sep 2006 13:14:25 -0500

Hi, David,

> "locating users and resources", but I maybe not. Others think this is

I confess that I seem to have read this text the same way Enrico did. It 
SHOULD have been clearer than it was. If we all have the same understanding, 
the text could be OK.

Thanks,

Spencer

---

From: bryan at ethernot.org (David A. Bryan)
Date: Thu, 21 Sep 2006 14:49:51 -0400

Then we definitely need to reword.

What I am trying to avoid is questions about if we design the system
so that resource location in general is done with a broadcast (flood)
type protocol, which I believe is not the concensus of most folks. We
want to rule that out, while allowing broadcast for things like
locating a bootstrap.

Let me think about some alternate wording, or I am open to any suggestions.

David

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Thu, 21 Sep 2006 13:56:06 -0500

> want to rule that out, while allowing broadcast for things like

I agree.

> Let me think about some alternate wording, or I am open to any 

"Multicast and dynamic DNS based approaches for locating users and resources 
(although these approaches might be in-scope for overlay discovery, 
bootstrapping, etc.)"?

(And just to be clear - I agree with Henry's post yesterday that the charter 
would be acceptable as proposed, if charter chatter means that we lose focus 
on the problem at hand)

Thanks,

Spencer

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 21 Sep 2006 16:22:45 -0400

> (although these approaches might be in-scope for overlay discovery,

I had the same question when I read the original paragraph,
and I think that Spencer's proposed re-wording make things clearer.

- Philip

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 21 Sep 2006 16:37:14 -0400

I think Scott's proposal to use the term "Applicability Statement"
is a good one, even if most Applicability Statements that I have
seen are brief documents that do not have the depth that I feel
we want from our proposed document
(e.g., see RFC 3037 or RFC 3210).

I don't think that we are going to give a better description
of what we intend in just one or two sentences in the charter,
so I suggest we go with Scott's proposed term,
given that it is already well-established.

- Philip

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 21 Sep 2006 17:34:15 -0400

The draft charter says:

> behind NATs.

Earlier versions of the charter had the word "many" in place of  "some"
in a roughly corresponding place. I would prefer to see the word changed
to "most", or if there is strong disagreement on this, at least changed
back to "many".

- Philip

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Fri, 22 Sep 2006 09:26:03 +0200

> to "most", or if there is strong disagreement on this, at least changed

If it was a requirement someone else had to satisfy, "many" would work.
 However, since *we* will have to deal with it and since we all agree
that we have to support as many natted peers as we can, "some" is ok.  A
stricter requirement here would just have the side effect of increasing
the probability of a failure.

-- 
Ciao,
Enrico

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 22 Sep 2006 11:57:46 -0400

> the probability of a failure.

As long as everyone agrees that we will support as many natted peers  
as possible,
then I am happy. However, the wording in the charter does not make  
this clear
(at least to me), and this topic was a subject of some debate earlier  
this year.

- Philip