Subject: [p2p-sip] Draft charter for possible P2PSIP WG

From: royrr at us.saic.com (Roy, Radhika R.)
Date: Wed, 25 Jan 2006 10:12:58 -0500

Michael:

You are right. It has been misunderstood by many.

P2P-SIP WG will work within the framework IETF norms and principles. It
means this WG will coordinate its activities with all other IETF WGs. For
that matter, it will also look around the world what other folks are doing
so that we should NOT re-invent the wheel for P2P communications.

Our focus is P2P-SIP protocol development, and it includes all the things
that it takes to make SIP as P2P Protocol: FW/NAT crossing, Session
Establishments for real-time communications, Discovery, Routing, Resources
Management, QoS support for media (audio/video/data), Mobility Management,
etc.

In doing so, P2P-SIP protocol development will NOT violate any norms or
principles of the IETF focusing on P2P communications.

Best regards,

Radhika

  _____  

From: Michael Slavitch [mailto:slavitch at gmail.com] 
Sent: Tuesday, January 24, 2006 5:01 PM
To: Enrico Marocco
Cc: Roy, Radhika R.; P2P-SIP
Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG

You state that we MUST refer to BEHAVE and MMUSIC to provide a solution for
hindrance avoidance and multiparty media sessions.  
That is true.  I fully agree. The corollary of this statement is that it is
incumbent on BEHAVE and MMUSIC to provide a solution that is reasonable and
effective for P2PSIP and to do so in a timely manner. This places an onus on
these groups to deliver an answer, otherwise there is a disconnect that has
much larger implications.  Solutions must be finalized and finalized
promptly. 

If BEHAVE and MMUSIC has a solution in place that meets the needs of P2PSIP
by all means use it.  
As of today it does not. Proposed solutions exist in Internet-Draft form
only.  They are still in development.
Given that, what does P2PSIP working group do if there is no solution firmly
in place? Do we wait? How long?
More to the point, what does the P2PSIP community do?   Can it wait?  How
long?

The question that arises is "Can the P2PSIP WG go forward and meet its
stated goals when there is no NAT traversal solution firmly in place?"  My
answer to that would be a firm no, because the lack of a solution influences
the resulting activities of the working group. 

I argue that such solutions must be fully defined and in be place as a core
competency of P2PSIP communications.  If these solutions are not in place by
a certain date the goals and milestones of the P2PSIP working group cannot
be fully met, as a huge protocol hole exists, one that can't be waved away
as a  "not my department" issue.  This means that the success of P2PSIP
depends on the BEHAVE and MMUSIC working groups delivering a solution in
reasonably short order. 

The rate of progress to date does not inspire confidence or reflect any
sense of urgency. This is a risk that must be addressed.

Given that risk I propose that the the P2PSIP WG should adopt the following
recourse, just in case: 

If by a certain date  BEHAVE and MMUSIC  has not finalized a solution that
meets the early milestone needs of the P2PSIP charter then the P2PSIP
charter must include a provision that permits the WG to propose a solution
to BEHAVE and MMUSIC in the form of one or more Internet Drafts.  In the
absense of any other active or in place solutions the P2PSIP WG should then
request that these Internet Drafts be considered as a potential solution by
BEHAVE and MMUSIC for hindrance avoidance and multiparty media for P2PSIP
sessions.  In accordance with IETF guidelines these drafts, once fully
finalized and reviewed, would then be submitted for elevation to full RFC
status. 

The P2PSIP WG should always refer to appropriate prior solutions finalized
by BEHAVE and MMUSIC, whenever they exist.  The goal is not to replace the
work of these working groups but instead provide alternate proposals in
cases where a finalized solution is for whatever reason not forthcoming. 

On 24/01/06, Enrico Marocco <enrico.marocco at tilab.com
<mailto:enrico.marocco at tilab.com> > wrote:

If "something else" means "something we'll build", the latter doesn't
reconcile with the last phrase of the draft charter: "Respecting the
IETF specification change policy, the working group will refer any 
possible changes or extensions as suggestions to the appropriate WGs as
needed. A guiding principal of the WG will be to avoid extensions or
change wherever possible."

Since without such statement the charter wouldn't be accepted, we MUST 
look for solutions for hindrance avoidance and multiparty media session
control in behave and mmusic IETF working groups.

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

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Wed, 25 Jan 2006 12:56:56 -0500

I fully support Radhika's statement below.  I assert the following:

1. a finite statement similar to Radhika's should be part of the P2PSIP
charter. ("etc." may sound too open ended for the comfort of some.)

2. The WG must then develop milestones for deliverables that meet these
charter goals.

3. These deliverables must include precise definitions of the functional
requirements for core P2P components, including, for example, NAT traversal.

4. The deliverables must include references to specific definitions of the
solutions that have been accepted by the WG.

4. In the event of an absence of specific protocol definitions for solutions
that meet these requirements, these requirements should be then be used as
the basis for solution proposals that would then be presented to other
working groups, in accordance with IETF principles. The goal would be to
produce one or more specific protocol definition that would satisfy the
requirements of the P2PWG.

If P2PSIP is to be widely adopted and widely interoperable the WG must
deliver or reference protocols that give completely diverse and independent
groups operating under the same set of specifications all the means needed
to create fully interoperable implementations, without relying on
negotiation, permission, license or co-ordination of what is accepted as
best practice. To do this P2PSIP needs to produce or refer to formal
specifications.  The danger of relying on descriptions of best practices is
that they are open to interpretation, suasion and argument. It forces
implementers to be part of a club, and that club may well be exclusive.

Proprietary implementations could easily claim to be P2PSIP compliant when
in fact they are following private interpretations of best practices. This
is already a common practice for many actors even with well-established and
well-defined formal protocol standards such as HTTP.  Such efforts tend to
end up being limited to whatever wiggle room the standards definitions
allow.  The better the protocol the less room there is for wiggling.  One
frequently-used technique for turning so-called standards-compliant
implementations into proprietary solutions involves burying critical items
in protocol elements that are tagged with the dreaded OPTIONAL or SHOULD
clauses.  The word SHOULD isn't a specification, it's an opinion.

The defining characteristic of the IETF is that its protocol standards are
inclusive, open and interoperable.  This is a social contract.

A well defined formal protocol is a good and fair contract.  Such protocols
clearly describe steps for all known interactions and describe these steps
using unambiguous terms such as MUST, MUST NOT and SHALL wherever possible.
Terms like SHOULD, MAY and especially OPTIONAL are red flags and are used
only when there are truly compelling reasons to do so. A document full of
SHOULD, MAY and OPTIONAL statements isn't a contract, it's a recommendation.
Overuse of the three words SHOULD, MAY and OPTIONAL has been a
consistentsource of peril for
implementer of  IETF standards.

This is my plea that there be a commitment to avoiding such peril in
P2PSIP.  This commitment starts with an assertion that *all *the components
that as a whole will constitute what will be commonly called  *P2PSIP  *MUST
be fully described as a set of well-defined protocols that are in turn
defined as RFC standards track documents, and that in the event that such
documents do not exist, *they will be created*.

Core capabilities MUST NEVER be abstracted away.

Regards,

Michael

On 25/01/06, Roy, Radhika R. <royrr at us.saic.com> wrote:
>  ------------------------------
>
> *From:* Michael Slavitch [mailto:slavitch at gmail.com]
> *Sent:* Tuesday, January 24, 2006 5:01 PM
> *To:* Enrico Marocco
> *Cc:* Roy, Radhika R.; P2P-SIP
> *Subject:* Re: [p2p-sip] Draft charter for possible P2PSIP WG
>
>
>
> You state that we MUST refer to BEHAVE and MMUSIC to provide a solution
> for hindrance avoidance and multiparty media sessions.
> That is true.  I fully agree. The corollary of this statement is that it
> is incumbent on BEHAVE and MMUSIC to provide a solution that is reasonable
> and effective for P2PSIP *and to do so in a timely manne*r. This places an
> onus on these groups to deliver an answer, otherwise there is a disconnect
> that has much larger implications.  Solutions must be finalized and
> finalized promptly.
>
> If BEHAVE and MMUSIC has a solution in place that meets the needs of
> P2PSIP by all means use it.
> Given that, what does P2PSIP working group do if there is no solution
> firmly in place? Do we wait? How long?
> I argue that such solutions must be fully defined and in be place as a
> core competency of P2PSIP communications.  If these solutions are not in
> place by a certain date the goals and milestones of the P2PSIP working group
> cannot be fully met, as a huge protocol hole exists, one that can't be waved
> away as a  "not my department" issue.  This means that the success of P2PSIP
> Given that risk I propose that the the P2PSIP WG should adopt the
> following recourse, just in case:
>
>  On 24/01/06, *Enrico Marocco* <enrico.marocco at tilab.com> wrote:
>
>

--
Michael Slavitch
Ottawa, Ontario Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060125/18d3c345/attachment.html