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

From: royrr at us.saic.com (Roy, Radhika R.)
Date: Tue, 24 Jan 2006 08:34:57 -0500

Dean:

I think that the way you framed your reply seems to be that we are in
agreement from the broader context.

Couple of things are as follows:

1.      We are looking for p2p context of FW/NAT crossing by SIP. No other
IETF WGs are doing this work. The research p2p WG is doing p2p works, but
they are not focused for FW/NAT crossing by SIP per se, and, moreover,
p2p-SIP is looking for commercial solutions, NOT for any research works.

2.      People are proposing solutions for FW/NAT crossing using p2p-SIP
protocol. Some drafts are already there. So, let us work on those drafts
and/or proposals.

3.      P2P-SIP WG should be open to all proposals that help SIP to solve
all problems in p2p mode. So, the focus should be p2p, not any non-p2p
aspects of solutions because our charter is to make p2p-SIP protocol in the
context of the p2p public Internet.

So, let us be OPEN to all suggestions for p2p-SIP without limiting that some
items are here or some items are other groups. For example, even people may
say items like "discovery," "registrar," "proxy," or other services also do
NOT belong to p2p-SIP.

Hope this helps.

Best regards,

Radhika

-----Original Message-----
From: dean.willis at softarmor.com [mailto:dean.willis at softarmor.com
<mailto:dean.willis at softarmor.com> ]
Sent: Tuesday, January 24, 2006 12:19 AM
To: Roy, Radhika R.
Cc: Michael Slavitch; Pyda Srisuresh; P2P-SIP
Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG

On Jan 23, 2006, at 3:35 PM, Roy, Radhika R. wrote:

> Michael:

> I agree with you because this is one of the magic that p2p-SIP is  

> bringing on the table adding tremendous values. In fact, SIP  

> implementations are faltering because of FW/NAT crossing problems.

> If the power of p2p-SIP is so great that it can solve the most  

> complex problems of VoIP communications like FW/NAT crossing, why  

> should we object to it instead of welcoming?

Radhika,

Peer to peer techniques have no "magic" way of making NATs an easy-to- 

solve problem.  NATs are ugly, complex, nasty, and highly  

differentiated beasties, and there are myriad techniques for getting  

across different sorts of NATs.

P2P-SIP is about enabling P2P-SIP nodes to find and communicate with  

other P2P-SIP nodes. We know that some of these nodes will be behind  

NATs. We know that if ALL nodes are behind unique NATs (including the  

"rendezvous function or server"), then there is no known solution to  

be had using P2P techniques.

That said, we need to be able to answer a couple of questions in  

order to get things talking. We hope that P2P techniques will give us  

a better way to answer these questions than client-server techniques  

didm but they're pretty much the same question.

These include:

1) Where shall I send an offer in order to reach my correspondent,  

and how can the response to that offer reach me?

2) How can I inform my potential correspondents as to where they  

should send offers if they want to reach me?

3) If I or my correspondent is behind a particularly nasty relay  

element (firewall, NAT, etc.), what intermediate shall I use to  

attempt to reach (or be made reachable to) my correspondent, and how  

shall I communicate with that correspondent? Are there intermediate  

nodes that I can solicit for assistance with this task?

Notice that all of these questions fall roughly into the category of  

"resource discovery".

--

Dean

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060124/534fd5ef/attachment.html

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Tue, 24 Jan 2006 11:11:11 -0500

Dean, Roy, et al.

I agree. Let us beg, borrow and steal the methods that exist.  Does ICE yet
exist other than in continually changing draft development form?  It has
been in development for several years now and in my opinion there is some
lack of urgency in coming to a finalized solution, although Microsoft's
announced support may ultimately give ICE the kick in the pants that is
needed.  If that is the case P2P SIP should get on the ICE bandwagon, at
least for media sessions.  But what if ICE languishes?  What then? Do we
wait for an external dependency or do we pick up our socks and run with it
and perhaps use something else?

And good points on resource discovery. IMHO not only should resource
discovery exist, it should be largely automatic and the services should be
self-advertising, without requiring (but certainly not excluding)
centralized configuration, registrars, or rules.

On 24/01/06, Roy, Radhika R. <royrr at us.saic.com> wrote:
> So, let us be OPEN to all suggestions for p2p-SIP without limiting thatsome items are here or some items are other groups. For example, even people
> may say items like "discovery," "registrar," "proxy," or other services
> also do NOT belong to p2p-SIP.
>
> Hope this helps.
>
> Best regards,
>
> Radhika
>
> From: dean.willis at softarmor.com [mailto:dean.willis at softarmor.com<dean.willis at softarmor.com>
> ]

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

---

From: jose at netlab.hut.fi ([email-masked])
Date: Tue, 24 Jan 2006 18:41:50 +0200

Hello,

I tend to agree with the statement of taking existing mechanisms for NAT-FW, etc
but IMO as already stated the critical issue for the P2P SIP is the resource
discovery. We need to find where are the SIP entities, either Registrar, Proxy
or the UAs if any, we might also want to know where are the DNS server if we
want to use the URI of the SIP endpoint, etc.

For this we also have several options (e.g. Chord, SLP, UPnP, etc) but the
resource discovery has to be done automatically and in a scalable manner with
and without centralised support.

Therefore, the resource discovery would be one of the corner stones in the
proposed P2P SIP architecture.
Rgds
Jose

IMO the critical issue is on the resource discovery
> > So, let us be OPEN to all suggestions for p2p-SIP without limiting thatsome
> items are here or some items are other groups. For example, even people
> > From: dean.willis at softarmor.com
> [mailto:dean.willis at softarmor.com<dean.willis at softarmor.com>
> > ]

---

From: henry at pulver.com (Henry Sinnreich)
Date: Tue, 24 Jan 2006 11:12:17 -0600

Folks,

Just in case you may not have read previous emails:

Right now, please focus ONLY on making the BOF!

Unless we get an approved plan for the BOF, all technical discussions are in
vain. There will be plenty opportunity to discuss P2P technical topics AFTER
the WG has been approved.

Thanks, Henry

-----Original Message-----
From: jose at netlab.hut.fi [mailto:jose at netlab.hut.fi] 
Sent: Tuesday, January 24, 2006 10:42 AM
To: Michael Slavitch
Cc: Roy, Radhika R.; P2P-SIP
Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG

Hello,

I tend to agree with the statement of taking existing mechanisms for NAT-FW,
etc
but IMO as already stated the critical issue for the P2P SIP is the resource
discovery. We need to find where are the SIP entities, either Registrar,
Proxy
or the UAs if any, we might also want to know where are the DNS server if we
want to use the URI of the SIP endpoint, etc.

For this we also have several options (e.g. Chord, SLP, UPnP, etc) but the
resource discovery has to be done automatically and in a scalable manner
with
and without centralised support.

---

From: enrico.marocco at TILAB.COM (Enrico Marocco)
Date: Tue, 24 Jan 2006 18:17:48 +0100

Michael Slavitch wrote:
> I agree. Let us beg, borrow and steal the methods that exist.  Does ICE
> yet exist other than in continually changing draft development form?  It
> has been in development for several years now and in my opinion there is
> some lack of urgency in coming to a finalized solution, although
> Microsoft's announced support may ultimately give ICE the kick in the
> pants that is needed.  If that is the case P2P SIP should get on the ICE
> bandwagon, at least for media sessions.  But what if ICE languishes? 
> What then? Do we wait for an external dependency or do we pick up our
> socks and run with it and perhaps use something else? 

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.

Enrico

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
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 send an e_mail to
MailAdmin at tilab.com. Thank you
====================================================================

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Tue, 24 Jan 2006 12:44:18 -0500

Henry made an important point.
What we need to talk about urgently is whether the proposed charter is 
fine and, if not, what should be improved and how.
Thanks.

Eunsoo

Henry Sinnreich wrote:

>yet
>>>1.      We are looking for p2p context of FW/NAT crossing by SIP. No
>>>      
>>>
>other
>  
>
>>>IETF WGs are doing this work. The research p2p WG is doing p2p works,
>>>      
>>>
>but
>  
>
>>>3.      P2P-SIP WG should be open to all proposals that help SIP to
>>>      
>>>
>solve
>  
>
>>>aspects of solutions because our charter is to make p2p-SIP protocol in
>>>      
>>>
>the
>  
>
>>>So, let us be OPEN to all suggestions for p2p-SIP without limiting
>>>      
>>>
>thatsome
>  
>
>_______________________________________________
>p2p-sip mailing list
>p2p-sip at cs.columbia.edu
>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>  
>

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Tue, 24 Jan 2006 17:01:21 -0500

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.

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

---

From: sathya at research.panasonic.com (Sathya Narayanan)
Date: Tue, 24 Jan 2006 18:04:39 -0500

Michael Slavitch wrote:

> <snip>
> 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.  

I don't understand what you mean by "the WG to propose a solution to
...". AFAIK, there is no need for any provision in the charter for
*participants* of P2PSIP WG to submit IDs to the BEHAVE or MMUSIC WG. 
As Dean mentioned earlier, if we don't believe the existing solutions
are satisfactory, we (as individual IETF participants) should drive new
requirements into the appropriate working group along with any proposed
solutions. I don't see any reason to add a new provision to the proposed
P2PSIP charter.

- Sathya

> 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:
>
>
>------------------------------------------------------------------------
>

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Wed, 25 Jan 2006 00:23:27 -0500

"We (as individual IETF participants) should drive new requirements into the
appropriate working group along with any proposed solutions."

Absolutely, we should indeed.  The formal legalese earlier may have been a
little over the top but I have been a veteran of far too many standards
battles over the years (not just IETF, although the IETF is catching up in
this department) where the real value of an initiative is scuttled,
intentionally or not,  through inertia and delay by someone successfully
arguing that critical components are "not a part of the core mandate" and
hence letting them sit as unattended unsolved orphans.  This is why  key
components of P2PSIP must be articulated well enough in advance to ensure
that  a common consensus and possibly a formal agreement exists on how to
deal with these issues as they arise.

It is my opinion that the WG must have milestones in place for implementing
public NAT traversal protocols including a real fixed date for having such
protocols fully described. The P2PSIP WG  will first define the specific
requirements that will be met by these protocols and deliver these
requirements in an early milestone.

Given that the WG charter must then reflect that these are issues under the
mandate of the WG.

To date there is no formal RFC protocol that deals with NAT traversal for
SIP signalling or RTP multimedia.  What exists today is an Internet-draft
that describes a set of methodologies that details related connection
techniques while offering example call flows.  It is still  a tutorial that
describes techniques.   It has not to date been coalesced into a specific
signalling protocol. This must change, and the sooner it is formalized the
better.

Changing this may require some effort on the part of the P2PSIP community.
Unless a  formalized broad protocol appears in the near term it appears that
members of the  P2PSIP community will have no choice but to begin the task
of formalizing existing best practises into protocol descriptions that best
meet specific P2PSIP requirements.  This may result in a patchwork of
standards that differ between classic SIP and P2P SIP.  In any case a
patchwork of formal standards is still better than no standards at all.

Regards

Michael

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

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 25 Jan 2006 00:51:38 -0600

On Jan 24, 2006, at 11:23 PM, Michael Slavitch wrote:

> To date there is no formal RFC protocol that deals with NAT  
> traversal for SIP signalling or RTP multimedia.  What exists today  
> is an Internet-draft that describes a set of methodologies that  
> details related connection techniques while offering example call  
> flows.  It is still  a tutorial that describes techniques.   It has  
> not to date been coalesced into a specific signalling protocol.  
> This must change, and the sooner it is formalized the better.

Ok, I may not know all your history here.

But I do know a little bit about the history of NAT traversal and SIP.

There are actually several key drafts, colloquially referred to as  
STUN, TURN, ICE, and "outbound". STUN is actually a reasonably widely  
implemented discrete protocol. TURN is not far behind. Outbound is a  
signaling extension to SIP for providing persistent through-NAT  
reflexive signaling. ICE is, as you describe it, a methodology for  
combining the other techniques. There's a high level of urgency -- I  
sat through the almost overnight ICE ad-hoc in Vancouver as the key  
players worked through issue after issue. Sure, there's more work to  
be done. But issuing an ultimatum from another working group isn't  
going to make it go faster.

And even if there were total agreement on every detail of these  
specifications, and the drafts were completely final and blessed by  
the working groups, IESG, and greater IETF, we'd still be over a year  
from having a referable RFC. That's just the nature of IETF work  
right now.

The other problem is that there is no specific, formalized behavior  
of NATs to write a "signalling protcocol" against. There are many  
different sorts of NATs with a broad range of characteristics.  We  
have an entire group (BEHAVE) dedicated to sorting these  
characteristics out. We have seen no evidence of any single traversal  
protocol that works on all of them all the time. Sometimes you need a  
relay element, sometimes you don't. Sometimes, about all you can do  
is squeeze a tunnel through to a correspondent node that fronts all  
the protocols for you.

STUN helps us discover what we look like to the outside world. TURN  
gives us a media relay. Outbound gives us a back-channel for  
signaling, so that we can receive requests. ICE gives us a  
methodology for bringing this all together in a way that, if not  
perfect, is at least probably going to work.

How does this relate to P2P-SIP?

In a world without dedicated servers, how do we find something to run  
STUN against so we can find out if we're NATed? How do we find and  
make use of a peer that offers TURN relay services? How do we build  
persistent signaling relationships with peers outside our NATs so  
that they can get messages back to us, and how do our other peers  
discover and re-use those relationships? These are the correspondent  
and service discovery questions that have to be addressed so that SIP  
can be made to do something useful in the P2P environments we seem to  
agree are our targets.

--
Dean

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Tue, 24 Jan 2006 23:26:24 -0800

Like all WG in the IETF there is nothing stopping you from going and helping
in any WG. If you feel the BEHAVE work is moving too slowly, go to that WG
and help accelerate it. If you think the approach they are using is wrong,
go to that WG and get it changed. However, if you think the charter of a
P2P-SIP WG should say that this WG is charted to do work that another WG
such as BEHAVE or MMUSIC is already charted to do ... well that I would
heavily objectless to that proposal. I suspect most people would object to
that and I view the odds of it happening to be so low that is barely worth
discussing. 

I do think that most people (myself included) think that a P2P-SIP system
would need to work with many nodes behind NATs. I suspect I can prove that
if all the nodes participating in the system are behind a symmetric NAT,
then it is impossible for any of them to every communicate with any other
node. Because of this I think there will have to be some relaxed
requirements about some of them at least being behind full cone NATs.

If the the P2P protocol was defined over UDP, then everything you need from
any other group for NAT traversal may already be done. I'm not suggesting
that it is a good idea to use UDP.  TCP might have much better firewall
traversal properties and the odds are good you would want to look at
something such as the STUNT work in BEHAVE.

Cullen

On 1/24/06 2:01 PM, "Michael Slavitch" <slavitch at gmail.com> wrote:

> 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.
> 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.
> 
> 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.
> 
> 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.
> 
> 

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

---

From: jose at netlab.hut.fi ([email-masked])
Date: Wed, 25 Jan 2006 09:47:37 +0200

Hi,

Fully agree!
So far it seems the consensus is around two items:
- P2P Resource discovery.
- Distributed NAT/FW traversal.

The former, as far as I know there is no WG dealing with that issue but on the
latter I guess we have a lengthy discussion whether we should tackle that issue
or rely on the work from other WGs.
IMO we should not forget the problem since NAT/FW is an important factor but we
should limit the scope of this WG to the issues within P2P architecture that no
other WG is handling like the resource discovery.

We should limit the scope to something achievable within certain timeframe.
Thus, the charter should reflect the two issues but the focus should be on the
P2P resource discovery.
Rgds
Jose

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Wed, 25 Jan 2006 10:13:43 -0500

>Thus, the charter should reflect the two issues but the focus should be on the
The draft charter includes the following statement.

"While ensuring:

1. Security is addressed in these systems.

2. Interoperability with existing client-server (CS) SIP and the PSTN.

3. The solutions proposed will function even with some or many nodes
    located behind NATs or firewalls.

4. Existing protocols are reused whenever possible."

Doesn't this statement satisfy what you wrote above? What do you think?

Regards,

Eunsoo

---

From: jose at netlab.hut.fi ([email-masked])
Date: Wed, 25 Jan 2006 17:56:10 +0200

Hi Eunsoo,

Yep, the NAT/FW traversal is included there.
Is the resource discovery mentioned also in the charter?
Rgds
Jose

---

From: sathya at research.panasonic.com (Sathya Narayanan)
Date: Wed, 25 Jan 2006 11:29:19 -0500

Michael Slavitch wrote:

> "We (as individual IETF participants) should drive new requirements
> into the appropriate working group along with any proposed solutions."
>
> Absolutely, we should indeed.  The formal legalese earlier may have
> been a little over the top but I have been a veteran of far too many
> standards battles over the years (not just IETF, although the IETF is
> catching up in this department) where the real value of an initiative
> is scuttled, intentionally or not,  through inertia and delay by
> someone successfully arguing that critical components are "not a part
> of the core mandate" and hence letting them sit as unattended unsolved
> orphans.  This is why  key components of P2PSIP must be articulated
> well enough in advance to ensure that  a common consensus and possibly
> a formal agreement exists on how to deal with these issues as they arise.

Ofcourse, I agree that the key components of P2PSIP must be articulated
- but I think it should be done in a ID.

> It is my opinion that the WG must have milestones in place for
> implementing public NAT traversal protocols including a real fixed
> date for having such protocols fully described. The P2PSIP WG  will
> first define the specific requirements that will be met by these
> protocols and deliver these requirements in an early milestone.

This sounds to me like again trying to mandate things from another
working group. As was mentioned many times earlier, this is not possible
in IETF.

>
> Given that the WG charter must then reflect that these are issues
> under the mandate of the WG.

Please suggest the changes you think is needed. I don't think it is
possible to word your suggestions in a formal charter for a WG.

regards,
Sathya

>
> To date there is no formal RFC protocol that deals with NAT traversal
> for SIP signalling or RTP multimedia.  What exists today is an
> Internet-draft that describes a set of methodologies that details
> related connection techniques while offering example call flows.  It
> is still  a tutorial that describes techniques.   It has not to date
> been coalesced into a specific signalling protocol. This must change,
> and the sooner it is formalized the better.
>
> Changing this may require some effort on the part of the P2PSIP
> community. Unless a  formalized broad protocol appears in the near
> term it appears that members of the  P2PSIP community will have no
> choice but to begin the task of formalizing existing best practises
> into protocol descriptions that best meet specific P2PSIP
> requirements.  This may result in a patchwork of standards that differ
> between classic SIP and P2P SIP.  In any case a patchwork of formal
> standards is still better than no standards at all.
>
>
> Regards
>
> Michael
>
>
> On 24/01/06, *Sathya Narayanan* <sathya at research.panasonic.com
> <mailto:sathya at research.panasonic.com> > wrote:
>
>     Michael Slavitch wrote:
>
>     > <snip>
>     > On 24/01/06, *Enrico Marocco* < enrico.marocco at tilab.com
>     <mailto:enrico.marocco at tilab.com>
>     > <mailto:enrico.marocco at tilab.com
>     <mailto:enrico.marocco at tilab.com>>> wrote:
>     >
>     >
>     >     possible changes or extensions as suggestions to the
>     appropriate
>     >     WGs as
>     >     Since without such statement the charter wouldn't be
>     accepted, we
>     >     MUST
>     >p2p-sip at cs.columbia.edu <mailto:p2p-sip at cs.columbia.edu>

---

From: bryan at ethernot.org (David A. Bryan)
Date: Wed, 25 Jan 2006 11:36:58 -0500

I think we have that covered in the sense that we mention some of the
future work might include locating resources rather than users as
needed for particular SIP communications based purposes. We mention
lookup schemes for user location as a current working item, and VM and
services such as distributed media relay as possible future items
(which would of course require locating a resource), and in the list
of what we exclude, we say:

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

So as sort of a corollary -- "it isn't out so if needed for P2P SIP
items it is in" -- we include locating resources as needed for
SIP-based communication, if that is required for services we do after
recharters (things like locating vm message, relays, storing a UA
config file, or other SIP communications service specific things).

On the other hand, a *general* resource location mechanism outside of
real time SIP based communication (so for example, general file
sharing/location stuff that isn't intended for use in SIP based
communications) is obviously out of scope for this group, since the
item above rules them out explicitly.

David

---

From: henry at pulver.com (Henry Sinnreich)
Date: Wed, 25 Jan 2006 11:32:59 -0600

I suggest to add to the charter text something like this:

The P2P SIP WG will use, where applicable, the insights and the results from
the work of the P2P IRTF Group for such topics as generic requirements for
P2P and P2P resource and service discovery protocols, see
http://www.irtf.org/charter.php 

Thanks, Henry

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Wed, 25 Jan 2006 13:46:31 -0500

On 25/01/06, Sathya Narayanan <sathya at research.panasonic.com> wrote:

> working group. As was mentioned many times earlier, this is not possible

So what happens when the results of other WG's are either absent,
incomplete, or do not meet the requirements of the WG?

Does the WG sit on its hands?

> >     >     look for solutions for hindrance avoidance and multiparty
> media
> >     >     session

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

---

From: salman at cs.columbia.edu (Salman Abdul Baset)
Date: Wed, 25 Jan 2006 15:28:14 -0500 (EST)

For a global SIP p2p/overlay network, STUN solves all the NAT problems
until symmetric or UDP blocking NATs come in the picture. In those cases,
relays are required and TURN can be used to get a public IP address from a
well known TURN server. The P2P-SIP helps to discover those relays. The
P2P-SIP relay discovery mechanism, IMO, must be explicitly described in the
P2P-SIP draft. Relay discovery comes under the general problem of resource
discovery; however it is important enough to be explicitly stated. The
implementation requirement for relay discovery will perhaps be a MAY or
SHOULD rather than MUST to cater for corporate fully natted scenarios.

A UDP blocking NAT (which is very rare) requires media to travel over TCP. In
corporates, only HTTP is typically allowed. I do not think that folks in
IETF want to have NAT or firewall traversal over HTTP.

There is a draft on 'Best Current Practices for NAT Traversal for SIP'
available at:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-03.txt

Regards,
Salman

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Wed, 25 Jan 2006 17:34:30 -0500

On 25/01/06, Dean Willis <dean.willis at softarmor.com> wrote:

(snip)

 There's a high level of urgency -- I
> going to make it go faster.

I agree. Ultimatums are never useful. But real milestones are.

Delivery targets and milestones do matter and are very useful. Working
towards an actual deadline and a real targeted date for delivery has
implications that will influence the decisions and the milestones of several
working groups. It doesn't matter if the actual deadline is missed.  What
matters is that exists a reasonable expectation that some solution will be
at hand in a reasonable timeframes.

> from having a referable RFC. That's just the nature of IETF work

Ok, that's the anticipated wg acceptance milestone date plus one year.
Good.  Now we're getting somewhere.  Given that, what agreed-n date can
anyone offer as a reasonable date for reaching a consensus?  Is it in 2006?
Is it in 2007? Is there any deadline or milestone at all, or can this
discussion go on forever? I argue that a real deadline will force the issue
enough such that consensus can be reached, and that this is for the general
good.

> is squeeze a tunnel through to a correspondent node that fronts all

The perfect is often the enemy of the good,  and this appears to be one of
those cases.

Why can't there be individual responses to specific characteristics?  Why
can't these responses be defined as individual algorithms implemented as
small, tractable RFC's? Why must we wait for one grand unification protocol
that solves every case when solutions that work within specific boundries
are well known and at hand, and are already implemented in a variety of
proprietary solutions that are in wide use?

How can it be that Skype is so smart and the IETF is so stuck?  How can the
IETF consider this to be intractable and ignore the obvious?
Any more delay and the IETF effort won't matter at all, as the world will
line up pretty please and pay happily for proprietary solutions from a
variety of vendors, be they Skype or Damaka or Google or Microsoft.  These
solutions aren't perfect, but they exist and they are now setting the agenda
from the perspective that matters, which is users and subsequently vendors.
Inaction cannot be ignored away, and a real failure scenario, one where open
standards get replaced by closed proprietary impementations, is a real and
present danger.  This will happen if the current pace continues.  The world
isn't waiting for the IETF to come up with a perfect solution.  It may be
fully satisfied by a Google API.

How does the IETF respond to this?  One way would be to start providing
solutions that reduce the problem, and offer a plan for the future.
With a timeline.

For example the STUN discovery protocol is relatively simple.
It spits back one of a fixed set of responses (if it can respond at all).
The set of responses is thus finite, a simple state machine.

This allows solutions to be catagorized. If solutions can be catagorized
they can be externalized and the problem reduced.

Why can't NAT traversal reference different solutions for different
circumnstances, like here?:

Case A: Local NAT type A, Remote NAT type B see RFC XXXA (negotiation)
Case B: Local NAT type B, Remote NAT type A see RFC XXXB (negotiation)
Case C: Local NAT type C, Remote NAT type D,see RFC XXXC (negotiation)
Case D: Local NAT type D, Remote NAT type D,see RFC XXXD (relay)
Case E: Local NAT type E, Remote NAT type Y; solution not there yet but on
the way. fail.
Case X: Local NAT type BAD. Remote NAT type don't care.  Exception. No can
do. Fail.
Case Z: No answer to STUN request. Fail. Sorry.

Assume that this is implemented in a product called 'foo'

Implementation 'foo" supports NAT types A,B,C,D as described in RFC XXXX,
XXXA, XXXB, XXXC, XXXD..

This summary is what would go on a data sheet.  It sets reasonable
expectations. Customers and vendors are happy enough that they avoid doing
something else, something like a closed solution from a single vendor.

Why can't a NAT traversal solution based on a relatively simple well formed
NAT discovery technique (using STUN, either in line or not)  reference one
or more outside algorithm as the appropriate response?  Such output may not
offer a perfect answer, but it is a partial solution that can be delivered
in short order, and as additional solutions come along they can be added to
the list.   It solves most of the problems that we face today, it describes
failure modes accurately, users will live with it until improvements come
along.   It also stands a much better chance of being implemented by
engineers.  They need  a basic specification to work from. Remember that ICE
may be implemented in simple commodity hardware that has restricted
capabilities. Parsing XML may not be one of them.

Even if it takes a year just to get to consensus it still offers a
deliverable that will forestall a purely proprietary world for which the
IETF currently has no answer.

I agree that the BEHAVE group has no solution for all cases.  But it has
solutions for MOST cases. Why aren't these being put forward in the meantime
as a set of NAT traversal standards for which there are solutions and leave
the art of the perfect for later?

> perfect, is at least probably going to work.

See above.  I agree.  What I propose is that this be made as deterministic
as is possible using protocols that are as simple as is possible,
continually reducing the problem domain.

> can be made to do something useful in the P2P environments we seem to

Good question.  What is above is a my 2c example of an answer. The outside
state machine could be modified for a P2P SIP world (perhaps using some kind
of base certificate-obtained "seed", but that's not for now) where discovery
processes replace value parameters.

In most cases it would invoke the same RFCs as for regular SIP, but (as an
example) relay cases the algorithm could then point to a peer discovery
algorithm, possibly defined as another RFC, that returns a resulting value,
instead of immediately using a relay based on some present known value.  It
would then get the ball rolling with that relay in the same way that regular
SIP does.

The big difference between classic SIP and P2PSIP could then be largely one
of using known fixed values vs using the results of discovery processes that
meet some rule criteria.

SIP has "use relay x" where X is a scalar value.

P2PSIP could have "discover relays and use the one that meets certain
rules",
where the rules are such things as:

"Only use peers, never dedicated hosts"
"never from canonically Evil Vendor M, maybe from usually Good Vendor G but
not if it is in France" and finally
"please use first good result unless congested otherwise choose randomly
from first ten results".

I wonder if someone from Google is watching this discussion. They could
offer good input.

The SIP of today sees parameters such as hosts as values while P2PSIP may
see these as references to one or more discovery processes. The underlying
NAT traversal solutions for individual NAT cases would then be unchanged and
reused,  as they reflect the connection not the connecting entities.  Most
of SIP could then be reused, replacing value parameters with discovery
processes and rule definitions.

Given this scenario P2PSIP would ultimately behave just like regular ol' SIP
given the right circumstances, in cases where discovery algorithms return
known values.  No reinventing the wheel. Now that would be interesting.

Regards

Michael

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

---

From: sathya at research.panasonic.com (Sathya Narayanan)
Date: Thu, 26 Jan 2006 10:29:08 -0500

Michael Slavitch wrote:

>
>
> On 25/01/06, *Sathya Narayanan* <sathya at research.panasonic.com
> <mailto:sathya at research.panasonic.com>> wrote:
>
>  
>

No. As was mentioned many times before, individual participants from the
P2PSIP WG should participate and drive the requirements through the
other WG.

>     traversal
>     > On 24/01/06, *Sathya Narayanan* < sathya at research.panasonic.com
>     <mailto:sathya at research.panasonic.com>
>     > <mailto:sathya at research.panasonic.com
>     <mailto:sathya at research.panasonic.com>> > wrote:
>     >
>     >     Michael Slavitch wrote:
>     >
>     >     > <snip>
>     >     <mailto: enrico.marocco at tilab.com
>     <mailto:enrico.marocco at tilab.com>>
>     >     <mailto: enrico.marocco at tilab.com
>     <mailto:enrico.marocco at tilab.com>>>> wrote:
>     >     >
>     >     >
>     >     >     look for solutions for hindrance avoidance and
>     multiparty media
>     >     >     session
>     <mailto:p2p-sip at cs.columbia.edu <mailto:p2p-sip at cs.columbia.edu>>

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 26 Jan 2006 14:23:30 -0500

Henry:

The current charter draft (as posted by David) has the text

"The working group will operate in close cooperation with the SIP,
SIPPING, SIMPLE, MMUSIC and BEHAVE working groups, as well as the
IRTF."

Is this sufficient?

I am thinking that, since the P2P SIP WG will also need to use the  
insights and results of
other working groups (such as the insights and results of the BEHAVE  
group on NAT traversal),
singling out the P2PRG more explicitly with a longer statement might  
be out-of-place.

What do you think?

- Philip

---

From: henry at pulver.com (Henry Sinnreich)
Date: Thu, 26 Jan 2006 13:37:59 -0600

"The working group will operate in close cooperation with the SIP, SIPPING,
SIMPLE, MMUSIC and BEHAVE working groups, as well as the IRTF."

Yes, this is sufficient.

Thanks, Henry

-----Original Message-----
From: Philip Matthews [mailto:philip_matthews at magma.ca] 
Sent: Thursday, January 26, 2006 1:23 PM
To: henry at pulver.com
Cc: David A. Bryan; P2P-SIP
Subject: Re: [p2p-sip] Using results from the IRTF P2P Research Group

Henry:

Is this sufficient?

What do you think?

- Philip

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Thu, 26 Jan 2006 14:39:05 -0500

Michael:

It is not clear to me what you are proposing.

In the draft charter that David Bryan posted, there are some concrete  
deliverables
listed, and the milestones section proposes some concrete dates.
I had a hand in suggesting these deliverables and dates, and I feel  
they are reasonable and achievable.

Do you have some proposals for text modifications that would reflect  
your concerns?

- Philip

On 25-Jan-06, at 17:34 , Michael Slavitch wrote:

> Delivery targets and milestones do matter and are very useful.  
> Working towards an actual deadline and a real targeted date for  
> delivery has implications that will influence the decisions and the  
> milestones of several working groups. It doesn't matter if the  
> actual deadline is missed.  What matters is that exists a  
> reasonable expectation that some solution will be at hand in a  
> reasonable timeframes.
>
>
> Ok, that's the anticipated wg acceptance milestone date plus one  
> year.  Good.  Now we're getting somewhere.  Given that, what agreed- 
> n date can anyone offer as a reasonable date for reaching a  
> consensus?  Is it in 2006?  Is it in 2007? Is there any deadline or  
> milestone at all, or can this discussion go on forever? I argue  
> that a real deadline will force the issue enough such that  
> consensus can be reached, and that this is for the general good.
>
>
> The perfect is often the enemy of the good,  and this appears to be  
> one of those cases.
>
> Why can't there be individual responses to specific  
> characteristics?  Why can't these responses be defined as  
> individual algorithms implemented as small, tractable RFC's? Why  
> must we wait for one grand unification protocol that solves every  
> case when solutions that work within specific boundries are well  
> known and at hand, and are already implemented in a variety of  
> How can it be that Skype is so smart and the IETF is so stuck?  How  
> can the IETF consider this to be intractable and ignore the obvious?
> Any more delay and the IETF effort won't matter at all, as the  
> world will line up pretty please and pay happily for proprietary  
> solutions from a variety of vendors, be they Skype or Damaka or  
> Google or Microsoft.  These solutions aren't perfect, but they  
> exist and they are now setting the agenda from the perspective that  
> matters, which is users and subsequently vendors.  Inaction cannot  
> be ignored away, and a real failure scenario, one where open  
> standards get replaced by closed proprietary impementations, is a  
> real and present danger.  This will happen if the current pace  
> continues.  The world isn't waiting for the IETF to come up with a  
> perfect solution.  It may be fully satisfied by a Google API.
>
> How does the IETF respond to this?  One way would be to start  
> providing solutions that reduce the problem, and offer a plan for  
> the future.
> With a timeline.
>
> This allows solutions to be catagorized. If solutions can be  
> catagorized they can be externalized and the problem reduced.
>
> Case E: Local NAT type E, Remote NAT type Y; solution not there yet  
> but on the way. fail.
> Case X: Local NAT type BAD. Remote NAT type don't care.  Exception.  
> No can do. Fail.
> Implementation 'foo" supports NAT types A,B,C,D as described in RFC  
> XXXX, XXXA, XXXB, XXXC, XXXD..
>
> expectations. Customers and vendors are happy enough that they  
> avoid doing something else, something like a closed solution from a  
> single vendor.
>
> Why can't a NAT traversal solution based on a relatively simple  
> well formed NAT discovery technique (using STUN, either in line or  
> not)  reference one or more outside algorithm as the appropriate  
> response?  Such output may not offer a perfect answer, but it is a  
> partial solution that can be delivered in short order, and as  
> additional solutions come along they can be added to the list.   It  
> solves most of the problems that we face today, it describes  
> failure modes accurately, users will live with it until  
> improvements come along.   It also stands a much better chance of  
> being implemented by engineers.  They need  a basic specification  
> to work from. Remember that ICE may be implemented in simple  
> commodity hardware that has restricted capabilities. Parsing XML  
> may not be one of them.
>
> deliverable that will forestall a purely proprietary world for  
> which the IETF currently has no answer.
>
> I agree that the BEHAVE group has no solution for all cases.  But  
> it has solutions for MOST cases. Why aren't these being put forward  
> in the meantime as a set of NAT traversal standards for which there  
> are solutions and leave the art of the perfect for later?
>
> See above.  I agree.  What I propose is that this be made as  
> deterministic as is possible using protocols that are as simple as  
> is possible,
> Good question.  What is above is a my 2c example of an answer. The  
> outside state machine could be modified for a P2P SIP world  
> (perhaps using some kind of base certificate-obtained "seed", but  
> that's not for now) where discovery processes replace value  
> parameters.
>
> In most cases it would invoke the same RFCs as for regular SIP, but  
> (as an example) relay cases the algorithm could then point to a  
> peer discovery algorithm, possibly defined as another RFC, that  
> returns a resulting value, instead of immediately using a relay  
> based on some present known value.  It would then get the ball  
> rolling with that relay in the same way that regular SIP does.
>
> The big difference between classic SIP and P2PSIP could then be  
> largely one of using known fixed values vs using the results of  
> discovery processes that meet some rule criteria.
>
> P2PSIP could have "discover relays and use the one that meets  
> certain rules",
> "never from canonically Evil Vendor M, maybe from usually Good  
> Vendor G but not if it is in France" and finally
> "please use first good result unless congested otherwise choose  
> randomly from first ten results".
>
> I wonder if someone from Google is watching this discussion. They  
> could offer good input.
>
> The SIP of today sees parameters such as hosts as values while  
> P2PSIP may see these as references to one or more discovery  
> processes. The underlying NAT traversal solutions for individual  
> NAT cases would then be unchanged and reused,  as they reflect the  
> connection not the connecting entities.  Most of SIP could then be  
> reused, replacing value parameters with discovery processes and  
> rule definitions.
>
> Given this scenario P2PSIP would ultimately behave just like  
> regular ol' SIP given the right circumstances, in cases where  
> discovery algorithms return known values.  No reinventing the  
> wheel. Now that would be interesting.
>
> Regards
>
> Michael
>
> -- 
> Michael Slavitch
> Ottawa, Ontario Canada

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

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Thu, 26 Jan 2006 23:32:09 -0500

The existing statement, as written, works very well for the protocols
defined by the SIP, SIPPING, and SIMPLE working groups. In those cases the
P2PSIP WG will exploit methods that either already exist in broad use as
public protocols, are enhancements that exploit or extend existing
protocols, or are in such an early stage that their absence will  not impact
core P2PSIP WG charter goals. Any remaining open questions are either part
of the basic P2PSIP WG scope or can be deferred without jeopardy

P2PSIP has a dependency on SIP standards, but a broad enough SIP ecosystem
already exists such that P2PSIP can meet its goals using methods already
defined by that ecosystem with minimal enhancements and changes.  P2PSIP
likely can't exist without SIP, but SIP already exists so this is not an
issue.

This is not true in the case of NAT traversal.  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.  This not about extensions or changes.  You cannot
extend or change something that does yet not exist. What the WG can do is
investigate how NAT traversal is used by P2PSIP, when, and describe its
implementation requirements.

The requirements for NAT traversal that the MMUSIC WG has set for itself may
be very different than the requirements needed to meet the basic charter
goals for P2PSIP.  The MMUSIC and BEHAVE working groups are working on
developing a general solution for NAT traversal that ideally works in all
cases.  The problem itself may well be intractable, there may be no general
solution. This is not known yet.  A general solution is still an open
research topic, something that is normally out of the scope of the IETF.
Like someone said earlier, the IETF is not about research, it is about
developing solutions and practises that can be defined as implementable and
interoperable standard protocols.
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.
MMUSIC has done excellent work in describing methodologies that perform NAT
traversal. The P2PSIP WG should investigate how best to exploit them and
define the acceptable practical limits of any proposed solution.  Any
enhancements or changes that result from this would be offered to the
affected working groups for their consideration.

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. This investigation
should produce a deliverable with a milestone of August 2006 that specifies
the basic functional NAT traversal requirements for P2PSIP that are in
keeping with the concurrent use-case document.  These requirements would
then be passed on to the MMUSIC WG for their consideration, as well as any
other affected groups.
At that time individuals may choose to contribute proposed implementations
that meet these requirements to the affected groups.

Given the above, I would add this line to the statement of activities (after
item 4, an equivalent item regarding  SIP Extensions)

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.

And add the following milestone, concurrent with the use-case document.

Aug 2006    Submit Preliminary Functional Requirements For Meeting Proposed
Use Cases to affected IETF working groups for their consideration.

These changes would give the underlying NAT problem the attention it
deserves.

Regards,

Michael

On 26/01/06, Philip Matthews <philip_matthews at magma.ca> wrote:
> I had a hand in suggesting these deliverables and dates, and I feel they
> are reasonable and achievable.
>
> Do you have some proposals for text modifications that would reflect your
> concerns?
>
> - Philip
>
>
>
>
> How can it be that Skype is so smart and the IETF is so stuck?  How can
> the IETF consider this to be intractable and ignore the obvious?
> Why can't a NAT traversal solution based on a relatively simple well
> formed NAT discovery technique (using STUN, either in line or not)
> reference one or more outside algorithm as the appropriate response?  Such
> output may not offer a perfect answer, but it is a partial solution that can
> be delivered in short order, and as additional solutions come along they can
> be added to the list.   It solves most of the problems that we face today,
> it describes failure modes accurately, users will live with it until
> improvements come along.   It also stands a much better chance of being
> implemented by engineers.  They need  a basic specification to work from.
> Remember that ICE may be implemented in simple commodity hardware that has
> restricted capabilities. Parsing XML may not be one of them.
>
> The big difference between classic SIP and P2PSIP could then be largely
> one of using known fixed values vs using the results of discovery processes
> that meet some rule criteria.
>
> "never from canonically Evil Vendor M, maybe from usually Good Vendor G
> but not if it is in France" and finally
> Given this scenario P2PSIP would ultimately behave just like regular ol'
> SIP given the right circumstances, in cases where discovery algorithms
> return known values.  No reinventing the wheel. Now that would be
> interesting.
>
> Regards
>
> Michael
>
> --
> Michael Slavitch
> Ottawa, Ontario Canada

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

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Fri, 27 Jan 2006 09:55:54 -0500

> (snip)

I appreciate your stressing the importance of NAT traversal problem for 
P2P SIP and I believe at least most of the group are aware of its 
importance and have been paying attention to it.
The draft charter says

"The solutions proposed will function even with some or many nodes
    located behind NATs or firewalls."

It seems to me this is sufficient but it seems also OK to add the proposed text (with some modifications) below.

> Given the above, I would add this line to the statement of activities 
> (after item 4, an equivalent item regarding  SIP Extensions)
>
> 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.

I'd like to propose a slight rewording.
"Investigate how existing firewall/NAT traversal techniques are to be 
incorporated for P2P SIP.
If necessary, define requirements for enhancements of existing 
techniques to be acted on by the MMUSIC, the BEHAVE, and any other 
affected IETF working group."

> Aug 2006    Submit Preliminary Functional Requirements For Meeting 
> Proposed Use Cases to affected IETF working groups for their 
> consideration.
>
As you see in the draft charter, there is no milestone for defining 
requirements of SIP extensions because it is not clear yet whether any 
SIP extensions are necessary.
I think it is the same for NAT traversal. So we can leave the milestones 
for defining those requirements open like the draft charter.

What do you think?

Regards,

Eunsoo

>
>
> On 26/01/06, *Philip Matthews * <philip_matthews at magma.ca 
> <mailto:philip_matthews at magma.ca>> wrote:
>
>     Michael:
>
>     In the draft charter that David Bryan posted, there are some
>     concrete deliverables
>     I had a hand in suggesting these deliverables and dates, and I
>     feel they are reasonable and achievable.
>
>     Do you have some proposals for text modifications that would
>     reflect your concerns?
>
>     - Philip
>
>
>
>
>>     On 25/01/06, *Dean Willis* < dean.willis at softarmor.com
>>     <mailto:dean.willis at softarmor.com>> wrote:
>>
>>     (snip)
>>
>>
>>     delivery has implications that will influence the decisions and
>>     the milestones of several working groups. It doesn't matter if
>>     the actual deadline is missed.  What matters is that exists a
>>     year.  Good.  Now we're getting somewhere.  Given that, what
>>     agreed-n date can anyone offer as a reasonable date for reaching
>>     a consensus?  Is it in 2006?  Is it in 2007? Is there any
>>     deadline or milestone at all, or can this discussion go on
>>     forever? I argue that a real deadline will force the issue enough
>>     such that consensus can be reached, and that this is for the
>>     general good.
>>
>>
>>     The perfect is often the enemy of the good,  and this appears to
>>     be one of those cases.
>>
>>     How can it be that Skype is so smart and the IETF is so stuck? 
>>     How can the IETF consider this to be intractable and ignore the
>>     obvious?
>>     exist and they are now setting the agenda from the perspective
>>     that matters, which is users and subsequently vendors.  Inaction
>>     cannot be ignored away, and a real failure scenario, one where
>>     open standards get replaced by closed proprietary impementations,
>>     is a real and present danger.  This will happen if the current
>>     pace continues.  The world isn't waiting for the IETF to come up
>>     with a perfect solution.  It may be fully satisfied by a Google API.
>>
>>     Why can't NAT traversal reference different solutions for
>>     different circumnstances, like here?:
>>
>>     Case E: Local NAT type E, Remote NAT type Y; solution not there
>>     yet but on the way. fail.
>>     Case X: Local NAT type BAD. Remote NAT type don't care. 
>>     Exception. No can do. Fail.
>>     Implementation 'foo" supports NAT types A,B,C,D as described in
>>     RFC XXXX, XXXA, XXXB, XXXC, XXXD..
>>
>>     This summary is what would go on a data sheet.  It sets
>>     reasonable expectations. Customers and vendors are happy enough
>>     that they avoid doing something else, something like a closed
>>     solution from a single vendor.
>>
>>     well formed NAT discovery technique (using STUN, either in line
>>     or not)  reference one or more outside algorithm as the
>>     appropriate response?  Such output may not offer a perfect
>>     answer, but it is a partial solution that can be delivered in
>>     short order, and as additional solutions come along they can be
>>     added to the list.   It solves most of the problems that we face
>>     today, it describes failure modes accurately, users will live
>>     with it until improvements come along.   It also stands a much
>>     better chance of being implemented by engineers.  They need  a
>>     basic specification to work from. Remember that ICE may be
>>     implemented in simple commodity hardware that has restricted
>>     Even if it takes a year just to get to consensus it still offers
>>     a deliverable that will forestall a purely proprietary world for
>>     it has solutions for MOST cases. Why aren't these being put
>>     forward in the meantime as a set of NAT traversal standards for
>>     which there are solutions and leave the art of the perfect for
>>     later?
>>      
>>
>>     deterministic as is possible using protocols that are as simple
>>     as is possible,
>>     Good question.  What is above is a my 2c example of an answer.
>>     The outside state machine could be modified for a P2P SIP world
>>     In most cases it would invoke the same RFCs as for regular SIP,
>>     but (as an example) relay cases the algorithm could then point to
>>     a peer discovery algorithm, possibly defined as another RFC, that
>>     NAT cases would then be unchanged and reused,  as they reflect
>>     the connection not the connecting entities.  Most of SIP could
>>     then be reused, replacing value parameters with discovery

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Fri, 27 Jan 2006 10:34:12 -0500

In keeping with Henry's request, I ask that  Eunsoo Shim <
eunsoo at research.panasonic.com>'s wording:*
*
"5.  Investigate how existing firewall/NAT traversal techniques are to be
incorporated for P2P SIP. If necessary, define requirements for enhancements
of existing techniques to be acted on by the MMUSIC, the BEHAVE, and any
other affected IETF working group."

be added to the charter following similar wording for SIP.  Apart from that
the charter seems fine by me.

Regards

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

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 27 Jan 2006 12:25:32 -0500

On 27-Jan-06, at 10:34 , Michael Slavitch wrote:

> In keeping with Henry's request, I ask that  Eunsoo Shim  
> <eunsoo at research.panasonic.com>'s wording:
>
> "5.  Investigate how existing firewall/NAT traversal techniques are  
> to be incorporated for P2P SIP. If necessary, define requirements  
> for enhancements of existing techniques to be acted on by the  
> MMUSIC, the BEHAVE, and any other affected IETF working group."
>
> be added to the charter following similar wording for SIP.  Apart  
> from that the charter seems fine by me.
>
> Regards
>
> Michael

[Adding Radhika to the CC, since he has expressed interest in this  
topic.]

I have a few concerns about this proposed change.

First of all, the existing charter draft says:
	3. The solutions proposed will function even with many nodes located  
behind NATs or firewalls.
and
	The working group will operate in close cooperation with the SIP,
	SIPPING, SIMPLE, MMUSIC and BEHAVE working groups, as well as the
	IRTF. Respecting the IETF specification change policy, the working
	group will refer any possible changes or extensions as suggestions to
	the appropriate WGs as needed.
In my opinion, it would be a mistake to remove the existing text, and
the proposed additional text doesn't add anything new that the  
existing sentences don't already say.
The proposed new text does emphasis these a bit more, but as long as  
the words are in the charter
somewhere, then the real emphasis in a WG comes from the actions of  
its participants and not from the words
in the charter.
In other words, I don't really see what we gain by the additional text.

Second, assuming that other feel strongly that new words should be  
added, I would suggest the following
rewording of Eunsoo's proposal:
	5. Investigate firewall/NAT traversal techniques for P2P SIP.
	    If appropriate, submit requirements in this area to other  
working groups, such as MMUSIC and BEHAVE.
Here I have generalized the first sentence, because existing  
techniques might not be sufficient. (In fact, I think
there WILL be cases where existing techniques are not sufficient).
And I have reworded the second sentence to make it clear that we are  
simply making suggestions to
other working groups for what we would like to see.

Comments?

- Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060127/51b54e5d/attachment.html

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Fri, 27 Jan 2006 12:46:39 -0500

My opinion is that 5, regarding NAT traversal, is as needed as is 4.
regarding SIP.

NAT is as important an enabler to the P2P part of P2PSIP as much as URI and
TCP/UDP/RTP are to the SIP part of P2PSIP.

It has to be a core issue.

On 27/01/06, Philip Matthews <philip_matthews at magma.ca> wrote:
> eunsoo at research.panasonic.com>'s wording: *
> *
> be added to the charter following similar wording for SIP.  Apart from
> that the charter seems fine by me.
>
> Regards
>
> Michael
>
>
> [Adding Radhika to the CC, since he has expressed interest in this topic.]
>
> 3. The solutions proposed will function even with many nodes
> the proposed additional text doesn't add anything new that the existing
> sentences don't already say.
> The proposed new text does emphasis these a bit more, but as long as the
> words are in the charter
> somewhere, then the real emphasis in a WG comes from the actions of its
> participants and not from the words
> in the charter.
> Second, assuming that other feel strongly that new words should be added,
> I would suggest the following
>     If appropriate, submit requirements in this area to other working
> groups, such as MMUSIC and BEHAVE.
> Here I have generalized the first sentence, because existing techniques
> might not be sufficient. (In fact, I think

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

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Sun, 29 Jan 2006 21:38:55 -0600

> Does the WG sit on its hands?

This is the IETF. You're not restricted to participated in only one  
working group.

If another working group is supposed to be doing something that we  
need and they aren't doing it,  we either go to the other working  
group and get the job done, or we get the IESG to scrap the working  
group that isn't getting the job done and recharter the work elsewhere.

What we do NOT do is independently try to standardize Yet Another  
Solution to the same problem.

--
Dean

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Sun, 29 Jan 2006 21:41:51 -0600

> from that the charter seems fine by me.

I think this works OK for me too.

--
Dean

---

From: srisuresh at yahoo.com (Pyda Srisuresh)
Date: Sun, 29 Jan 2006 21:49:42 -0800 (PST)

I fully agree with Michael.

cheers,
suresh

---

From: quittek at netlab.nec.de (Juergen Quittek)
Date: Mon, 30 Jan 2006 14:47:38 +0100

Dear all,

I also see firewall and NAT traversal as one of the key components
of a P2P SIP solution.  So far, we have three suggestions for phrasing
of a charter work item:

Michael:  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.

Comments
  - This version put focus on "how NAT traversal techniques ... to be
    implemented...".  This is too weak.  It is not just implementation
    but also a _selection_ of methods and a well designed _integration_
    with P2P SIP required.  How to implement should not be a major
    problem for the P2PSIP WG.

Eunsoo: 5.  Investigate how existing firewall/NAT traversal techniques
        are to be incorporated for P2P SIP.  If necessary, define
        requirements for enhancements of existing techniques to be acted
        on by the MMUSIC, the BEHAVE, and any other affected IETF working group.

Comments
  - What means "incorporated" in the first sentence different than implemented?
    Again, selection and integration of existing techniques are the problems to
    be solved.
  - There are more WGs working on related techniques, such as NSIS and MIDCOM.
    I would suggest not to mention particular WGs for this work item.  To which
    WG a request needs to be directed should either be obvious anyway, or the
    target WG should be discussed when details of the request are clear.

Philip:  5. Investigate firewall/NAT traversal techniques for P2P SIP.
         If appropriate, submit requirements in this area to other working
         groups, such as MMUSIC and BEHAVE.

Comments
  - Also this alternative is a little bit weak.  We should not investigating
    techniques is the challenge (they are well known and we already have practical
    experiences with many of them), but how to use which ones is the point.

In summary: neither the _investigation_ in FW/NAT traversal techniques, nor their
_implementation_ is the core work for us, but the steps in between: selecting the right
one(s) and integrating them with the P2P SIP solution that we will be working on.
Consequently, here is suggestion #4:

5.  Select firewall/NAT traversal technique(s) for P2P SIP and integrate them
    into the P2P SIP architecture or framework.  If necessary, define requirements
    for enhancements of existing techniques to be acted on by other working groups.

Juergen
-- 
Juergen Quittek        quittek at netlab.nec.de       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Mon, 30 Jan 2006 15:21:17 -0600

>     for enhancements of existing techniques to be acted on by other  

This is also acceptable to me, and I think it might draw less fire  
from the IAB than the previous formulation.

--
Dean

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Mon, 30 Jan 2006 16:37:48 -0500

The wording by Juergen is OK with me, too.
So far, no one objected to adding such a statement into the charter draft.
Philip expressed a concern about it (saying it does not add anything 
new) but I see from his email that he is willing to accept the change. 
Philip, please correct me if I am wrong here.
I believe we agree on what the statement should say and there are only 
subtle differences in wording.
These subtle differences of wording should not prevent us from moving 
forward.

Dean and David, if appropriate, would you mind integrating the proposed 
statement into the charter draft and posting the new revised draft?
Thanks.

Eunsoo

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Tue, 31 Jan 2006 06:32:00 -0500

I am OK with this wording.

Why don't we wait a day to see if anyone has any objections,
and, if not, declare consensus on this resolution to the issue?

- Philip

On 30-Jan-06, at 16:37 , Eunsoo Shim wrote:

> Philip expressed a concern about it (saying it does not add  
> anything new) but I see from his email that he is willing to accept  
> the change. Philip, please correct me if I am wrong here.
> I believe we agree on what the statement should say and there are  
> only subtle differences in wording.
> These subtle differences of wording should not prevent us from  
> moving forward.
>
> Dean and David, if appropriate, would you mind integrating the  
> proposed statement into the charter draft and posting the new  
> revised draft?
> Thanks.
>
> Eunsoo
>
> Dean Willis wrote:
>
>>
>> This is also acceptable to me, and I think it might draw less  
>> fire  from the IAB than the previous formulation.
>>
>> -- 
>> Dean
>>
>