Subject: [Ietf-behave] remove nat type definitions from rfc3489bis

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 9 Mar 2005 14:11:33 -0800 (PST)

During the behave meeting at this IETF, we had a lengthy and not too 
productive debate about the precise meaning of symmetric NAT. The 
current draft-ietf-behave-rfc3489bis-01, as well as rfc3489, defines the 
terms for the various NAT types. The new udp-behave draft spends some 
time, in section 6, trying to map the new definitions in udp-behave with 
the definitions in rfc3489.

I think that this serves no purpose.

The behave drafts are clear, I think, that the terminology in RFC3489 
was problematic, and that it was better to define a set of orthogonal 
behaviors that could be named. Thus, I think that it is a futile 
exercise to try and go back and clarify what we mean by "symmetric nat" 
by mapping the new behaviors in udp-behave to the concepts in 3489.

I would instead propose that:

1. we remove the definitions of symmetric/full-cone/port-restricted/etc. 
from rfc3489bis. These definitions are not used anymore except for the 
IAB considerations section, where they are not really needed.

2. We remove all the stuff in behave-udp that tries to give new meaning 
to those terms

3. behave-udp update its references to rfc3489bis whenever it needs to 
mention stun

Comments?

-Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Dan Wing <[email-masked]>
Date: Wed, 9 Mar 2005 14:49:40 -0800 (PST)

I believe you still need a definition of symmetric (or whatever term 
you'd like to use) to explain the type of NAT that doesn't work with 
STUN.  Perhaps the term non-STUN-friendly is sufficient, though?

-d

On Mar 9, 2005, at 2:11 PM, Jonathan Rosenberg wrote:

During the behave meeting at this IETF, we had a lengthy and not too 
productive debate about the precise meaning of symmetric NAT. The 
current draft-ietf-behave-rfc3489bis-01, as well as rfc3489, defines 
the terms for the various NAT types. The new udp-behave draft spends 
some time, in section 6, trying to map the new definitions in 
udp-behave with the definitions in rfc3489.

The behave drafts are clear, I think, that the terminology in RFC3489 
was problematic, and that it was better to define a set of orthogonal 
behaviors that could be named. Thus, I think that it is a futile 
exercise to try and go back and clarify what we mean by "symmetric 
nat" by mapping the new behaviors in udp-behave to the concepts in 
3489.

1. we remove the definitions of 
symmetric/full-cone/port-restricted/etc. from rfc3489bis. These 
definitions are not used anymore except for the IAB considerations 
section, where they are not really needed.

2. We remove all the stuff in behave-udp that tries to give new 
meaning to those terms

Comments?

-Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 
07054-2711
Cisco Systems
jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 15 Mar 2005 11:02:17 -0800 (PST)

Not as chair ...

Yes - I think that sounds like a really good idea. W