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

From: "Francois Audet" <[email-masked]>
Date: Wed, 9 Mar 2005 14:21:36 -0800 (PST)

Thank you Jonathan, you must have read my mind ;^)

I fully support your recommendation. 

Unless I hear any compelling reason on the mailing list on
why it shouldn't be done, I will remove completely from
draft-ietf-behave-nat-udp section 6 and all material 
concerning the legacy terminology Cone/Symmetric.

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Jonathan Rosenberg
> Sent: Wednesday, March 09, 2005 14:11
> To: Behave
> Subject: [Ietf-behave] remove nat type definitions from rfc3489bis
> 
> 
> 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 _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 9 Mar 2005 15:22:11 -0800 (PST)

Yes, it is already in there:

Good NAT == External NAT mapping is Endpoint Independent
Bad NAT  == External NAT mapping is Endpoint Dependent

> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Dan Wing
> Sent: Wednesday, March 09, 2005 14:50
> To: Jonathan Rosenberg
> Cc: Behave
> Subject: Re: [Ietf-behave] remove nat type definitions from rfc3489bis
> 
> 
> 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:
> 
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > -- 
> _______________________________________________
> Ietf-behave mailing list

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 10 Mar 2005 06:59:52 -0800 (PST)

Exactly.

The fact that we spent 90% of the presentation's time arguing
about what symmetric NAT meant proves that the terminoly
is indeed problematic. 

> Sent: Wednesday, March 09, 2005 18:07
> To: Pyda Srisuresh
> Cc: Behave
> I don't think it is our objective to obliterate the 
> definition from the 
> world's vocabulary. It is our objective to define sufficient 
> terminology 
> to convey the requirements we need to convey in the documents we are 
> trying to produce. I believe the terminology defined in the 
> udp-behave 
> draft, which uses terms for each individual component 
> behavior, is the 
> ideal way to do that. The fact that we cannot agree on what a 
> symmetric 
> NAT is, merely elucidates that point.
> 
> -Jonathan R.
> 
> 
> Pyda Srisuresh wrote:
> 
> > First off, Much thanks to Jonathan for clearing this up about the 
> > terminology on Symmetric NAT & Cone NATs.
> > 
> > As Dan points out, these terms are already out there in use by NAT 
> > endors and NAT users. We need clarification of these terms, not 
> > abandon them completely. Joanthan is dropping these terms from 
> > 3489bis. If we abandon the terms entirely, we will need to coin new 
> > terms. Given the wide use of these terms, I suggest we 
> redefine these 
> > terms accurately in the behave-gen draft. All behave drafts 
> will refer 
> > the definition provided in the gen draft for these terms.
> > 
> > Any comments? Thanks.
> > 
> > regards,
> > suresh
> > 
> > --- Dan Wing <dwing@xxxxxxxxx> wrote:
> > 
> it needs 
> >>>to
> >>>http://www.cisco.com 
> http://www.cisco.com