Subject: [BEHAVE] WGLC for behave-p2pstate-02 starts now

From: "Dan Wing" <[email-masked]>
Date: Tue, 20 Feb 2007 13:57:00 -0800

The working group last call for behave-p2p-state-02 starts now.  URL for
this document is 
http://www.ietf.org/internet-drafts/draft-ietf-behave-p2p-state-02.txt

Abstract:
   This memo documents the various methods known to be in use by
   peer-to-peer (P2P) applications for communication in the presence
   of Network Address Translators (NATs) at the current time. This
   memo covers NAT traversal approaches used by both TCP and UDP
   based applications. This memo is not an endorsement of the methods 
   described, but merely an attempt to capture them in a document.   

WGLC ends in two weeks on Tuesday, March 6.

Please send comments to [email-masked].

-d

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: "David Barrett" <[email-masked]>
Date: Tue, 20 Feb 2007 14:12:23 -0800

Great doc!  I like how you include the latest statistics and success rates
throughout.  I think it's ready for the presses.

-david

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]]
> Sent: Tuesday, February 20, 2007 1:57 PM
> To: [email-masked]
> Cc: 'Dan Kegel'
> Subject: [BEHAVE] WGLC for behave-p2pstate-02 starts now
>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 20 Feb 2007 18:28:42 -0600

Document is in very good shape. Very readable. 

I have the following comments:

- Section 2.4 introduces the term "Endpoint-Dependent Mapping" to cover
  two terms defined in RFC 4787 "Address-Dependent Mapping" and "Address
  and Port-Dependent Mapping". I'm not convinced that we gain anything
  by defining this new term. Personally, I'd rather we not introduce
this
  new term. If we do decide to keep it (because it makes the text later
in 
  the document less cumbersome for example), then we need to address the
  problem of  consistency with section 2.6 (see below).

- Section 2.6 introduces the term "Endpoint-Dependent Filtering".
However,
  unlike 2.4 which has Endpoint-Dependent = Address-Dependent | Address
and
  Port-Dependent, in this section it means Endpoint-Dependent = Address
and 
  Port-Dependent (only). Address-Dependent Filtering is not even
mentioned. This
  makes 2.4 and 2.6 inconsistent, and is related to a long discussion
  we had on this previously (and for which the conclusion was, "yes,
there
  are NATs with Address-Dependent Filtering behavior out there"). My
preference
  would be NOT to introduce the term "Endpoint-Dependent Filtering" and
stick
  to the RFC 4787-defined ones only (as mentioned above). Alternatively,
if
  we can not avoid defining a new term because we think it improves the 
  readability of the document, it should also cover both "Address and
  Port-Dependent Filtering" and "Address-Dependent Filtering".

- Section 2.10: Instead of using the term "hairping", we should use the 
  term "hairpinning" for consistency with RFC 4787.

> Sent: Tuesday, February 20, 2007 13:57
> To: [email-masked]
> Cc: 'Dan Kegel'
> The working group last call for behave-p2p-state-02 starts 
> now.  URL for this document is

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 21 Feb 2007 04:47:10 -0800 (PST)

Thanks, David. Glad you like it.

regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 21 Feb 2007 04:50:09 -0800 (PST)

Francois,

Please see my responses below inline.

regards,
suresh

> Document is in very good shape. Very readable. 

[suresh] Thanks.

>   Port-Dependent Filtering" and "Address-Dependent Filtering".

[suresh] As you said, the terms "Endpoint-Dependent Mapping" and
"Endpoint-Dependent Filtering" were introduced to make the document easy to
read. Unlike RFC4787, this document does not require fine granular definitions.
As for section 2.6 missing reference to "Address Dependent Filtering", I will
add that. Not a problem. Thanks for pointing out.

>   term "hairpinning" for consistency with RFC 4787.

[suresh] Sure, I will fix that.

regards,
suresh

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 21 Feb 2007 09:51:20 -0600

Thanks. That will address my comments. 

> From: Pyda Srisuresh [mailto:[email-masked]] 
> Sent: Wednesday, February 21, 2007 04:50
> To: Audet, Francois (SC100:3055); [email-masked]
> Cc: Dan Wing; Dan Kegel
> Subject: RE: [BEHAVE] WGLC for behave-p2pstate-02 starts now
> 
> Francois,
> 
> >   new term. If we do decide to keep it (because it makes the text 
> > later in
> >   unlike 2.4 which has Endpoint-Dependent = Address-Dependent | 
> > Address and
> >   Port-Dependent, in this section it means Endpoint-Dependent = 
> > Address and
> >   would be NOT to introduce the term "Endpoint-Dependent Filtering" 
> > and stick
> >   to the RFC 4787-defined ones only (as mentioned above). 
> > Alternatively, if
> [suresh] As you said, the terms "Endpoint-Dependent Mapping" 
> and "Endpoint-Dependent Filtering" were introduced to make 
> the document easy to read. Unlike RFC4787, this document does 
> not require fine granular definitions.
> As for section 2.6 missing reference to "Address Dependent 
> Filtering", I will add that. Not a problem. Thanks for pointing out.
> 
> > > The working group last call for behave-p2p-state-02 
> starts now.  URL 
> > > for this document is 
> > >

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 25 Feb 2007 08:50:29 -0800

There is lots of really good stuff in here but this draft looks like  
it needs more work before it is ready for WGLC.

A few things that I am afraid other reviewers might not bring up ....

It has lots of confusing terminology - I suggest it stop using all  
the terminology that the document does not need -  for example  
"symmetric"

I don't think it should be duplicating explaining terms that are  
defined elsewhere.

I think the term "P2P Friendly" is a major marketing mistake and  
highly likely to ensure vendors don't want to do this. I would use  
"Behave Compliant" and define that as a nat compliant with the UDP  
and TCP documents. I would move away from P2P - it has meaning to  
most people beyond what you mean hear and perhaps talk more about end  
to end which is what you are actually trying to achieve here.

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 25 Feb 2007 16:55:31 -0800 (PST)

My responses inline.

> A few things that I am afraid other reviewers might not bring up ....
[suresh] I dont understand what you mean here. Why are you afraid that others
wont bring up, but you alone can? Is this something you alone would know or
should I and others have known as well? I certainly do not know and am at a
loss with your comment. Please explain.

> the terminology that the document does not need -  for example  
[suresh] The document uses the terms defined in section 2. There is exactly one
mention of "Symmetric NAT" in section 2.4 under "Endpoint-Dependent Mapping" as
follows.

   Symmetric NAT devices ([STUN]) are a good example of NAT devices
   performing Endpoint-Dependent Mapping.

This is a perfectly valid usage and is hardly confusing. I am wondering if you
read the draft that was called for WGLC or some older rev.

I did notice, the TOC lists section 5.2 as "Symmteric NATs are not P2P
friedly". This is a typo. I will fix this. The actual section 5.2 is titled,
"NATs Employing Endpoint-Dependent Mapping are not P2P friendly". 

> I don't think it should be duplicating explaining terms that are  

[suresh] For the purposes of this document, we did not need all the granular
definitions in the UDP document. SO, we explain the terms used and state how
they relate to the UDP terms. The explantions do not hurt the understanding.

Why is this a problem?

> highly likely to ensure vendors don't want to do this. 

[suresh] I cannot parse your sentence. I certainly donot understand what you
are trying to say. Why is the term "P2P friendly" a marketing mistake? Even if
so, Why should I care in this draft?  And, What does "highly likely to ensure
vendors don't want to do this" mean? Please explain.

>                                                        I would use  
> and TCP documents.
 
[suresh] The title of this draft is "State of Peer-to-Peer(P2P) Communication
Across Network Address Translators(NATs)". This is independent of the BEHAVE
compliance.  The document is not about making recommendations.  I dont see any
point in using "BEHAVE compliant" term. 

Oh, by the way, you missed mentioning ICMP BEHAVE document for "behave
compliant" definition. Was that a mistake (or) you do not think the ICMP
document needs mention?
 
>                    I would move away from P2P - it has meaning to  

[suresh] I dont know what you have in mind for this document. But, AFAIK, the
focus of the document, from its very inception has been cocerning P2P. In case
you are attributing different meanings, please note, the document defines a P2P
application in section 2.7 as follows.

   A P2P application is an application that uses the same endpoint to
   initiate outgoing sessions to peering hosts as well as accept
   incoming sessions from peering hosts.

regards,
suresh

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 25 Feb 2007 18:26:59 -0800

> read the draft that was called for WGLC or some older rev.

We agreed not to use this terminology and moved to new terminology  
because this term was under-specified and the way [STUN] used the  
work symmetric was in direct conflict with how all firewall vendors  
used the word and how most NAT vendors use the word.

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 26 Feb 2007 10:31:16 -0800 (PST)

> used the word and how most NAT vendors use the word.
[suresh] Cullen - You responded back to just this one comment. Am I to
understand this is your only remaining comment on the draft for WGLC? What
other comments do you have outstanding for WGLC on the draft? 

regards,
suresh

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 26 Feb 2007 10:38:48 -0800

On Feb 26, 2007, at 10:31 AM, Pyda Srisuresh wrote:

> understand this is your only remaining comment on the draft for WGLC?

that would be an incorrect understanding.

> What

I don't think this document is ready or WGLC - I sent some examples  
of why in my previous email.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 26 Feb 2007 11:19:13 -0800

> [suresh] I cannot parse your sentence. I certainly donot 
> understand what you are trying to say. Why is the term "P2P 
> friendly" a marketing mistake? Even if so, Why should I care 
> in this draft?  And, What does "highly likely to ensure

Almost immediately after the advent of the first popular peer-
to-peer file sharing networks (Kazza and Gnutella), the term 
"peer-to-peer" has implied illicit sharing of copyrighted
content.  Thus, "peer-to-peer friendly" implies friendliness
towards the same.

Unfortunately, the fact that other protocols operate in a 
peer-to-peer fashion is lost on most people (for example, 
networked games, SIP, Microsoft's NetMeeting, etc.).

I believe Cullen's concern is that using the unqualified 
term "peer-to-peer" brings to mind illicit file sharing,
and nobody wants their company to be associated with illicit
activities.  Such an association is always a business risk 
and typically an unnecessary business risk.

Our milestone for this item is:

Mar 2007  Submit informational that discusses current
          NAT traversal techniques used by applications

So, perhaps downplaying the use of the term "peer to peer"
is what Cullen was referring to.  Or perhaps eliminating
it entirely.  I'm not entirely sure.

-d

---

From: EKR <[email-masked]>
Date: Mon, 26 Feb 2007 11:27:31 -0800

> and typically an unnecessary business risk.

If this is Cullen's concern, I share it. Whatever we would like P2P to
mean, as a practical matter it mostly means filesharing applications, so
I think it would be appropriate to rewrite the draft to use a different
term. Cullen had suggested Behave Compliant, which seems to me to
be fairly appropriate. Suresh, can you elaborate on what you don't
like about this term.

-Ekr

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 28 Feb 2007 07:46:30 -0800 (PST)

> and typically an unnecessary business risk.
[suresh] Dan - Thank you for the clarification. Now, I understand the context
better.

The term "Peer-to-peer" has been used widely throughout in BEHAVE drafts. There
were 7 references to the term in the recently publiched RFC 4787 alone.
"Peer-to-peer" applications have been the focus on this mailing list when
discussing BEHAVE compliance from day one. Besides, The p2p-state draft
qualifies the term "peer-to-peer" (or P2P, for short) with the following
defintion, so there is no confusion on what the term means.

So, given that the draft is making a qualified use of the term and the term is
also used in other BEHAVE RFCs and drafts, I believe, is is appropriate to use
the term in the draft.

>           NAT traversal techniques used by applications

[suresh] Dan - The milestone was created to permit adapting the p2p-state draft
as WG item. So, I did not pay attention to the exact wording of the milestone.
The draft has throuhgout been about the traversal of peer-to-peer applications.

> it entirely.  I'm not entirely sure.
[suresh] Perhaps, Cullen's concern is not much to do with the term
"Peer-to-peer" per se. But, more to do with the term "P2P-friendly NAT".

I have two terms defined in the document -  "P2P friendly NAT" and "NAT
friendly P2P Application". This document is about the state of P2P application
traversal through NATs. I cannot say that all P2P friendly NAT devices out
there are BEHAVE compliant. There are many that are not. I needed a generic
term that describes the state of NATs out there without tieing it down to
BEHAVE documents. I could rename this as "End-to-end friendly NAT", if that
would work. Note, this is different from "Behave Compliant NAT". If you like, I
could add a line that BEHAVE complaint NAT devices are good examples of "P2P
friendly NAT" devices. I already state that NAT devices employing
Address-Independent Mapping are examples of P2P-friendly NAT devices in the
document.

As for the term "NAT friendly P2P application", Once again, there are several
types of P2P applications out there that are NAT friendly. I picked a term that
would not tie it down to BEHAVE complaince.

Would the above work for you? Thanks.

regards,
suresh

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 28 Feb 2007 08:44:19 -0800

On Feb 28, 2007, at 7:46 AM, Pyda Srisuresh wrote:

> Note, this is different from "Behave Compliant NAT". If you like, I
> friendly NAT" devices.

Help me understand the difference between the two? If this is an  
effort to define P2P Friendly NATs to be the things that the WG  
disagreed with you about when doing the existing drafts, I doubt that  
represents WG consensus.