Subject: [p2p-sip] Issues in Draft Charter of 17 Jan 2006

From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 27 Jan 2006 11:19:15 -0500

Folks:

To try to bring some focus into our draft charter discussions,
I have stolen an idea I saw used very effectively in the BGP WG and  
created a document
that tracks the issues in the draft charter. Hopefully this will  
allow us
to identify the issues and bring them to a resolution.

I have reproduced this document below (it is just a text file).

For issue #1, raised by Henry, I have marked it tentatively resolved
because Henry has said he is happy with the existing text. Speak up
on the mailing list if you disagree.

The other issues are still open.

I have tried to list all the issues that people have raised. If I  
have missed something,
just sent me an e-mail with a pointer to the message and I will add  
it to the document.
Going forward, I plan to add issues as I see them appear on the  
mailing list
(again, if I miss something, just let me know)

I will try to include an abbreviated version of the discussion in the  
document.
By necessity, this abbreviation will be subjective, and people will  
need to look at the mailing list
for the full discussion. However, if you feel your points have been  
misrepresented,
then let me know.

- Philip

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

Issues in proposed P2P-SIP charter draft
(in the version posted by David Bryan on 17 Jan 2006)

Summary:
	- 6 issues in total
	- 1 tentatively closed (pending confirmation by group)
	- 5 still open

Issue 1: Reference to P2PRG
Existing Text:
	The working group will operate in close cooperation with the SIP,
	SIPPING, SIMPLE, MMUSIC and BEHAVE working groups, as well as the
	IRTF.
Proposed Text:
	(Unclear)
Proposed by: Henry Sinnreich
Discussion: Henry is now happy with the existing text. No one else  
has indicated
that he/she would like to see a change.
Resolution: CLOSED?

Issue 2: Description of conventional SIP.
Existing Text:
	This is an alternative to the conventional SIP approach of
	using a hierarchy of proxies where the mapping of users to proxies is
	determined by a combination of out-of-band and geographic mechanisms.
Proposed Text:
	This is an alternative to the conventional SIP approach of
	relying on service provider hosted proxies to which users get  
assigned by
	out-of-band means, usually based on geography, association or  
business reasons.
Proposed by: Aki Niemi
Discussion:
[Aki Niemi]
	The [original] sentence is a bit too sophisticated to efficiently  
communicate
	the message. How about simply saying that the conventional SIP approach
	relies on service provider hosted proxies to which users get  
assigned by
	out-of-band means, usually based on geography, association or business
	reasons.
Resolution: OPEN

Issue 3: Namespace
Existing Text:
	1. Peer associations groups, which may be called "P2P networks". 'P2P
	   overlays", or "P2P federations" will provide namespaces within
	   which P2P-SIP resources are identified. These namespaces are
	   bounded by the identifier(s) of the peer association group, which
	   generally map to domain-level identifiers in the DNS.
Proposed Text:
	(Nothing proposed yet)
Proposed by Aki Niemi
Related issues: #4
Discussion:
[Aki Niemi]
	I find this a little hard to understand. I guess the meaning is to  
still
	use a username at domain construct for user ids, and that each domain's
	name is rooted in the DNS? If so, why not just say that?
Resolution: OPEN

Issue 4: Namespace again
Existing Text:
	3. Some elements of each peer association group MAY be rooted in the
	   DNS such that they can be used for bootstrapping operations.
	   However, a peer association group that is operating entirely in an
	   isolated (or disconnected, or autonomous) mode will rely on
	   alternate means of bootstrapping the peer association group based
	   on the "zeroconf" work.
Proposed Text:
	(Nothing proposed yet)
Proposed by: Aki Niemi
Related issues: #3
Discussion:
[Aki Niemi]
	This isn't either or; perhaps it could also be mentioned that peers can
	very well sometimes be in disconnected mode, while other times in
	connected mode. In such cases, the names should have global scope in
	both modes.
	Maybe say that names should always have global scope?

[Philip Matthews]
	I would personally be reluctant to say in the charter that names  
must always have global
	scope until I better understood the implications of that statement.  
Currently,
	I suspect that having user and resource names which are unique only  
within
	a specific P2P-SIP network are much more realistic.

[Aki Niemi]
	My point is that nodes can move around and be part of both  
disconnected and connected overlays.
	It probably makes sense for that node to use the same name in each  
scenario, and that name to
	not collide with other names.
Resolution: OPEN

Issue 5: Should Distributed Media Relays be part of the first set of  
deliverables?
Existing Text:
[In the section with the heading "The following topics are initially  
out of the Working Group's scope,
but may be considered in possible future charters:"]
	1. Using P2P mechanisms to manage groups of distributed media relays.
Proposed Text:
	(Nothing proposed yet)
Discussion:
[Aki Niemi]
	Hmm.. I understand this in terms of the charter being scoped to SIP  
only
	(initially), but this seems like cutting out a major part of where
	distributing or sharing resources actually is a big benefit.

	After all, running a SIP proxy is quite cheap; disk and cpu are cheap
	and SIP doesn't consume that much bandwidth. Running a TURN server then
	again is another thing entirely. I can't see a system that has
	distributed rendezvous having to resort to centralized media relays.

	Shouldn't this rather be included in the first iteration already?

[Philip Matthews]
	I believe that we really need to have a small set of deliverables  
for the initial charter,
	otherwise the charter won't get past the IESG. In my opinion, only  
really essential stuff
	should be part of the first set of deliverables. So, for example, I  
am personally very interested
	in item 3 below (voicemail), but I am not objecting to leaving it  
for after a re-charter
	because I don't consider it "essential".
	In my opinion, item 1 (distributed media relays) are also not  
essential and
	should wait until after a re-charter.
	Does this make sense? Do you agree?

[Aki Niemi]
	Voicemail is hardly an essential feature. But media relays are  
needed to get around the most difficult
	middleboxes. What fraction of nodes are we expecting to live behind  
such boxes, and by not counting those
	in does it represent a complete enough solution?

	Because I just can't see a P2PSIP that requires centralized media  
relays to work properly getting
	off the ground (any better than traditional SIP).
Resolution: OPEN

Issue 6: NAT Traversal milestone
Existing Text:
	(None)
Proposed Text:
[In the section with the heading "Specifically, the working group  
will:"]
	5.  Investigate how NAT traversal techniques as described by MMUSIC  
are to be implemented by P2PSIP.
	    Define requirements for enhancements, protocols, or partial  
interim solutions for submission to
	    all affected IETF working groups.
[In the Milestones section]
	Aug 2006    Submit Preliminary Functional Requirements For Meeting  
Proposed Use Cases to affected
		    IETF working groups for their consideration.
Proposed by: Michael Slavitch
Discussion:
[Michael Slavitch] (brief excerpts -- see e-mails for complete text)
	... The ability to do NAT traversal is a core requirement for P2PSIP  
entities. Its absence jeopardizes
	the ability of the WG to meet one of its key pressing goals. Nothing  
else matters if peers can't
	communicate through NAT firewalls. The success of P2PSIP largely  
depends on an item that is largely
	not within its own mandate for which there is no current public  
standards based solution, no matter
	how partial or interim. ...
	...The absence of a a general solution for a problem should not  
prevent partial solutions from being
	developed and defined in the meantime,  especially if the partial  
solution does not preclude the
	inclusion of a general solution  if and when such a solution becomes  
available. ...
	... I believe that this issue is so important that an investigation  
into how NAT traversal techniques
	are to be implemented by P2PSIP entities should become part of the  
basic scope of the WG charter and
	one of the initial activities of the group.  Naturally in keeping  
with the principles of the IETF
	this investigation will be based on existing MMUSIC work. ...
Resolution: OPEN