Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 22 May 2005 15:54:50 -0700 (PDT)

My comments inline below.

regards,
suresh

--- "Peterson, Jon" <jon.peterson@xxxxxxxxxxx> wrote:
> 
> In light of the recent Last Call discussions about behave-nat-udp, I wanted
> to make a few comments.
> 
> Regarding REQ-7, it seems pretty clear to me that there is no immediate
> consensus to endorse endpoint-dependent or endpoint-independent filtering.
> Consequently, in the interest of time I'd like to make the modest proposal
> that REQ-7 endorse neither, but instead state that both these modes (and
> address-specific filtering) should be supported. Is there some advantage to
> privileging one over the other?

[suresh] I have not read all the comments on the thread. However, I do agree, a
NAT that supports either the Address-restricted Cone NAT or the Full-Cone NAT
type behavior should be considered behave compliant. As for making Full Cone
NAT behavior as the only requirement - There is queasiness from the vendors as
this will be perceived as security threat. Address Restricted Cone NAT sould be
the minimal bar.  Per Refer RFC 1122, section 4.1.3.5 - UDP apps are required
to respond using the same Src/dest address pair, but no restrictions to make
the source port same as the destination port in the received request.

For example, in TFTP protocol (ref: RFC 1350), the initiating client sends a
TFTP request with UDP SrcPort set to XX and DestPort set to 69. The TFTP servr
responds back with SrcPort set to YY and DestPort set to XX. As you will note, 
the TFTP would not work with a Port Restricted Cone NAT, but will work with an
Address restricted Cone NAT. So, it makes sense to recommend that NATs support
Address Restricted Cone NAT type behavior rather than Port Restricted Cone NAT
behavior. 
  
> 
> I see no great need to specify the maximum datagram length that NATs must
> process.
> 
[suresh] I assume,  you are saying this is in the context of IP fragment
support. Say, you mandate that a NAT device must support IP fragment
processing, yet the fragments do not go through because the NAT device
restricts assembled IP packet size to be 1500 bytes. It is no help to the apps
to learn this by trial and error. So, I think, it would make sense to require
the NATs to suport a minimal threshold (say, 8710 bytes), so most common apps
using IP fragament (such as NFSv2/v3) woudl work through them.

> I find the conceptual model of behave-nat-udp, which focuses on functions
> NATs might perform rather than classifications of NATs as particular
> taxonomic entities (Basic, Full Cone, etc), to be very attractive. That much
> said, I do agree with several commentators that the resulting functional
> descriptions lead to some very wordy terminologies. There seems to be some
> emerging agreement on shorter terms, and I think that would be most welcome
> to readers.
> 
> Regarding the terms used in behave-nat-udp versus ford-behave-gen, I see no
> immediate problems with the terms used in behave-nat-udp. The distinction
> between a "map", a "binding" and a "NAT session" in ford-behave-gen makes me
> a little dizzy, to be honest. I do not find the definition of "mapping" in
> behave-nat-udp to be problematic. I don't find the use of the term "session"
> to refer to a transport-layer connection between two endpoints to be
> problematic. Terminology can be endlessly debated, but it is not clear to me
> that we will gain much leverage on our problem space by spending a few more
> cycles refining these terms.

[suresh] I am not suggesting redefining existign terms or coining new terms.
But, I am suggestng reuse of terms that are already defined in previous RFCs. I
am specifically refering to terms defined on NAT RFCs, not the Cone NAT
terminology in RFC 3489.

I believe, it is important to use the term "Binding" as was originally defined
in RFC 3022 & 4008 and not use it interchangeably with mapping. After all,
"Binding" is a key NAT concept. A big drive of the behave drafts is to require
NAT implementers to support "Address/Port Bindings". Symmetric NATs donot
support Bindings and hence Symmteric NAT type behavior ought to be deprecated. 
It makes no sense to dilute the meaning of this term or not use this well
defined term. 

RFC 4008 associates specific meaning to "mapping" and "NAT Session". Using the
previously defined terms consistently makes the text technically cohesive. 

> 
> In Section 4.1, I think it reasonable to define behaviors such as "External
> NAT mapping is endpoint address dependent" just in order to disallow them in
> the requirements section. I think it is worth being specific about things
> that we don't want implementers to do.
> 
[suresh] I am fine with this.

> Given the conceptual model of behave-nat-udp, I think the distinction between
> "deterministic" and "non-deterministic" NATs in Section 8 is valuable. In
> fact, I think this non-determinism is one of the primary grounds to move away
> from a taxonomic model of NATs and into the functional model espoused by
> behave-nat-udp. I didn't find Section 8 to be particularly obscure when I
> read it, though no doubt the text could be made more focused.
> 
[suresh] While I have no problem with functional model, I find it problematic
to see the taxonomy being fully jettisioned or an entirely new jargon being
developed to go about describing the same stuff. As I said earlier, I am not
refering to the RFC 3489 terms.

I believe, ford-midcm-p2p is the draft that first proposed that attempting to
do port preservation should not be required. Bryan and I were co-authors of the
draft. I am certainly not opposed to mentioning this in the draft. I am fine
with that. But, the text in the document is far from clear to me. Some of the
text seems to be describing the buggy behavior of some NAT devices, not
necessarily the intended behavior. I donot see a need to describe bugs.
Products have bugs. But, we dont necessarily document bugs in RFCs.

> Jon Peterson
> NeuStar, Inc.

regards,
suresh

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 24 May 2005 01:50:27 -0700 (PDT)

<FONT face=Arial color=#0000ff 
size=2>Regarding just the REQ-7 text, I do think Bryan's suggestion has some 
merit. These requirements are intended to constrain NAT implementers, not the 
deployers of NATs. The implementers of NATs cannot anticipate what 
sort of filtering will be desired; that is something that deployers of NATs 
should be able to configure.
<FONT face=Arial color=#0000ff 
size=2> 
Jon 
Peterson
<FONT face=Arial color=#0000ff 
size=2>NeuStar, Inc.
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <FONT face=Tahoma 
  size=2>-----Original Message-----From: 
  ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
  [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Francois 
  AudetSent: Monday, May 23, 2005 11:00 AMTo: 
  'Behave'Subject: RE: [Ietf-behave] comments on 
  draft-ietf-behave-nat-udp-01
  Thanks to all, 
  This is a formal proposal on how to move forward, with 
  concrete text. 
  ------------------------ 
  How about this for REQ 7. 
  In the Requirements section: 
  REQ-7: In order to maximize application transparencyIt is 
  RECOMMENDED that        
  a NAT have an "Endpoint independent filtering" behavior. <FONT 
  size=2>       If a more stringent filtering 
  behavior is desired, it is RECOMMENDED <FONT 
  size=2>       that a NAT have an "Address 
  dependent" behavior. 
  In the REQ-7 justification section would be modified as 
  follows: 
  REQ-7: The recommendation to use endpoint independent 
  filtering is aimed at <FONT 
  size=2>       maximizing feature transparency, 
  in particular for applications that <FONT 
  size=2>       receive media simultaneously from 
  multiple locations (e.g., gaming), <FONT 
  size=2>       or applications that use 
  rendezvous techniques. However, it is also <FONT 
  size=2>       possible that in some 
  circumstances, it may be preferable to have <FONT 
  size=2>       a more stringent filtering 
  behavior. Filtering independently of the <FONT 
  size=2>       external endpoint is not as 
  secure: an unauthorized packet could get <FONT 
  size=2>       a specific port while the port was 
  kept open if ti was lucky enough <FONT 
  size=2>       to find the port open. In theory, 
  filtering based on both IP address <FONT 
  size=2>       and port is more secure than 
  filtering based only on the IP address <FONT 
  size=2>       (because the external endpoint 
  could in reality be two endpoints behind <FONT 
  size=2>       another NAT, where one of the two 
  endpoints is an attacker): however, such <FONT 
  size=2>       a policy could infere with 
  applications that use one than one port. 
  I'd like a Yay or Nay on the text above. 
  --------------------- 
  Wordy terminology:   As for the 
  wordy terminology for some of the names of behaviors, I also agree 
    (the reasons for wordy names are historical). I can go 
  through the text and simplify. 
  ------------------------ 
  REQs in-line:   Bryan feels 
  strongly about copying/pasting the REQs from section 12 in-line in the 
    text as they occur, to help the reader. I personally 
  think it is a reasonable   suggestion. Is there 
  any STRONG objection to this? (Cullen in particular, I'd like to 
    hear from you). 
  ------------------------- 
  Determinism:   I propose that to 
  address Bryan's concern, I put a note in section 4.1 and 5.1 <FONT 
  size=2>  refering to the Deterministic behavior section. I also propose 
  to change the first   sentence of section 8 to 
  the following:     The classification 
  of NATs is further complicated by the fact that under some <FONT 
  size=2>    conditions the same NAT often exhibits different 
  behaviors, especially for     mapping 
  and filtering. 
  ------------------------- 
  Again, I'd like a Yay or Nay from people on the points 
  above. 
  > -----Original Message----- > 
  From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [<A 
  href="mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx">mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] 
  On Behalf Of > Peterson, Jon <FONT 
  size=2>> Sent: Friday, May 20, 2005 16:48 > To: 
  Behave > Subject: [Ietf-behave] comments on 
  draft-ietf-behave-nat-udp-01 > <FONT 
  size=2>> > > In light 
  of the recent Last Call discussions about > 
  behave-nat-udp, I wanted to make a few comments. > 
  > Regarding REQ-7, it seems pretty clear to me that 
  there is no > immediate consensus to endorse 
  endpoint-dependent or > endpoint-independent 
  filtering. Consequently, in the interest > of time 
  I'd like to make the modest proposal that REQ-7 > 
  endorse neither, but instead state that both these modes (and <FONT 
  size=2>> address-specific filtering) should be supported. Is there 
  > some advantage to privileging one over the 
  other? > > I see no 
  great need to specify the maximum datagram length > 
  that NATs must process. > <FONT 
  size=2>> I find the conceptual model of behave-nat-udp, which 
  focuses > on functions NATs might perform rather 
  than classifications > of NATs as particular 
  taxonomic entities (Basic, Full Cone, > etc), to be 
  very attractive. That much said, I do agree with > 
  several commentators that the resulting functional <FONT 
  size=2>> descriptions lead to some very wordy terminologies. There 
  > seems to be some emerging agreement on shorter 
  terms, and I > think that would be most welcome to 
  readers. > > Regarding 
  the terms used in behave-nat-udp versus > 
  ford-behave-gen, I see no immediate problems with the terms <FONT 
  size=2>> used in behave-nat-udp. The distinction between a "map", a 
  > "binding" and a "NAT session" in ford-behave-gen 
  makes me a > little dizzy, to be honest. I do not 
  find the definition of > "mapping" in 
  behave-nat-udp to be problematic. I don't find > 
  the use of the term "session" to refer to a transport-layer <FONT 
  size=2>> connection between two endpoints to be problematic. 
  > Terminology can be endlessly debated, but it is 
  not clear to > me that we will gain much leverage 
  on our problem space by > spending a few more 
  cycles refining these terms. > <FONT 
  size=2>> In Section 4.1, I think it reasonable to define behaviors 
  > such as "External NAT mapping is endpoint address 
  dependent" > just in order to disallow them in the 
  requirements section. I > think it is worth being 
  specific about things that we don't > want 
  implementers to do. > > 
  Given the conceptual model of behave-nat-udp, I think the <FONT 
  size=2>> distinction between "deterministic" and "non-deterministic" 
  > NATs in Section 8 is valuable. In fact, I think 
  this > non-determinism is one of the primary 
  grounds to move away > from a taxonomic model of 
  NATs and into the functional model > espoused by 
  behave-nat-udp. I didn't find Section 8 to be > 
  particularly obscure when I read it, though no doubt the text <FONT 
  size=2>> could be made more focused. > 
  > Jon Peterson > 
  NeuStar, Inc. > > 
  _______________________________________________ > 
  Ietf-behave mailing list > 
  Ietf-behave@xxxxxxxxxxxxxxxxxxx > <A 
  href="https://list.sipfoundry.org/mailman/listinfo/ietf-behave" 
  target=_blank>https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 24 May 2005 14:16:45 -0700 (PDT)

Yeah, I tought it would be something like that. Very interesting.
The magic of ICE...

I am not sure we need to explain the whole thing in this document since
it seems more appropriate for the application document (or even for ICE or
NAT scenarios).  

I'll let Johnathan decide if it belongs there in ICE or not as one of its
benefits.

I could add something like this in the REQ-7 justification:

        Note - 
        Using Endpoint Independent Filtering or Address Dependent Filetering
      instead of Address and Port Dependent Filtering on a NAT (say NAT-A)
      also has benefits when the other enpoint is behind a non-BEHAVE compliant 
        NAT (say NAT-B) which doesn't support REQ-1. When the endpoints use ICE, 
        if NAT-A uses Address and Port Dependent Filtering, connectivity will
        require a Media Relay. However, if NAT-A uses Endpoint Indepent Filtering
        or Address Dependent Filtering, ICE will ultimately find connectivity   
        without requiring a Media Relay.

> -----Original Message-----
> From: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx 
> [mailto:yutaka_takeda@xxxxxxxxxxxxxxxxxxxx] 
> Sent: Monday, May 23, 2005 17:49
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: 'Behave'
> Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01
> 
> 
>  > Can you elaborate on this last point? I can't seem to make 
> sense  > out of it. Do you mean find connectivity without a 
> Media Relay?
> 
> Yes.
> 
>  > If so, can youd describe why, because it seems to me that 
> you will  > require a media relay if one end has a 
> address/port dependendent  > mapping.
> 
> Correct. That is what I meant.
> Let's say host A is behind a symmetric NAT (External IP 
> address=X)(address/port dependent) and host B is behind a port 
> restrected cone NAT (External IP address=Y) (address/port dependent). 
> Each hosts performs binding request with a STUN server and 
> obtain STUN 
> derived addresses, X:p and Y:q respectively, and then exchange the 
> addresses via a proxy server.
> 
> The, host A and B performs connectivity check against the transport 
> address obtained from the other host. However, packets sent 
> from host A 
> will have a different source port number 'p2' than 'p1', 
> consequently, 
> the packets will be discarded by the host B's NAT even host B 
> performs connectivity check against X:p1. (port must match to receive)
> 
> If the host B is behind an address dependent or independent NAT, the 
> packets from host A will be eventually received regardless of what 
> source port number it has, and then the host A will receive a 
> response 
> from host B. Host A, then detects a new MAPPED-ADDRESS (X:p2) in the 
> response, and performs an update (see section 9.3 in ICE document) to 
> modifiy the media transport address for host B. Finally, host B also 
> finds connectivity to the X:p2 and terminates the session initiation 
> process.
> 
> So, from what I understand, by avoiding address/port dependent to be 
> behave compliant NAT, the behave compliant NAT possibly removes the 
> requirement of a media relay (like TURN) in the case where the remote 
> host is behind a Symmetric NAT.
> 
> Hope this helps.
> 
> - Yutaka
> 
> 
> Francois Audet wrote:
> > 
> > 
> >  > -----Original Message-----
> >  > From: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx
> >  > [mailto:yutaka_takeda@xxxxxxxxxxxxxxxxxxxx]
> >  > Sent: Monday, May 23, 2005 15:37
> >  > To: Audet, Francois [SC100:9T51:EXCH]
> >  > Cc: 'Behave'
> >  > Subject: Re: [Ietf-behave] comments on 
> > >  >
> >  >
> >  > I had a discussion with our engineering team on
> >  > the new proposal by Francois on REQ-7 this morning.
> >  > We basically agree with his proposal.
> >  >
> >  > First off, some typos we found on the new REQ-7:
> >  > "transperencyIt" -> "transparency, it" "ti was lucky" -> "it
> >  > was lucky" "could infere" -> "could interfere" "one than one
> >  > port" -> "more than one port"
> > 
> > Thanks. Will fix.
> > 
> >  > I am not confident if I understand following statement
> >  > correctly. Could you please elaborate for me?
> >  >
> >  > "however, such a policy could interfere with 
> applications  > that 
> > use more  > than one port."
> > 
> > This is verbatim from the existing text. It is meant to the 
> case of an 
> > application behind a NAT, which would pierce a pinhole by 
> sending some 
> > packets from a source port, but where the remote 
> application may send 
> > packets to more than one local UDP port.
> > 
> > Perhaps the text should say "however, such a policy could interfere 
> > with applications that expect to receive UDP packets on 
> more than one 
> > UDP port."
> > 
> >  > Besides the security point of view, avoiding endpoint
> >  > address port dependent filtering has another significant
> >  > benefit. If the two hosts (A and B) are behind different NATs 
> > where:  >  > - Host A is behind Full-cone or Restricted-cone NAT.
> >  > - Host B is behind Symmetric NAT.
> >  > (sorry for the use of old terminology)
> >  >
> >  > ICE can find connectivity between the two in this case,
> >  > where if Host A is behind a Port-restricted cone NAT, ICE
> >  > will not be able to find a direct connectivity between them.
> >  > This could be mentioned in the REQ-7 justification section
> >  > for more specific clarification..?
> > 
> > Can you elaborate on this last point? I can't seem to make 
> sense out 
> > of it. Do you mean find connectivity without a Media Relay? 
> If so, can 
> > youd describe why, because it seems to me that you will require a 
> > media relay if one end has a address/port dependendent mapping.
> > 
> > Thanks.
> > 
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 24 May 2005 14:19:06 -0700 (PDT)

Agreed.

> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Bryan Ford
> Sent: Tuesday, May 24, 2005 14:04
> To: ietf-behave@xxxxxxxxxxxxxxxxxxx
> On Tuesday 24 May 2005 12:33, Francois Audet wrote (in 
> response to Jon 
> Peterson's message):
> > So you prefer this:
> >
> > REQ-7: NATs SHOULD support Endpoint-Independent Filtering, 
> > Address-Specific Filtering, and Endpoint-Specific Filtering, as 
> > options configurable by the user. Endpoint-Independent Filtering 
> > SHOULD be the default.
> >
> > I'm fine with this too.
> 
> Excellent - thanks.  One more minor note: although the text 
> above that I 
> suggested recommends that NATs support all three filtering 
> behaviors, I don't 
> have any strong attachment to the third, most restrictive behavior - 
> "Endpoint-Specific Filtering" - and as far as I can tell no 
> one else on this 
> list really appears to either.  So I would like to suggest 
> the following 
> minor alteration, which would weaken that part of the 
> recommendation (while 
> keeping it as an allowable implementation option):
> 
> REQ-7: NATs SHOULD support Endpoint-Independent Filtering and 
> Address-Specific Filtering, and MAY support Endpoint-Specific 
> Filtering, as options 
> configurable by the user. Endpoint-Independent Filtering 
> SHOULD be the 
> default.
> 
> But I don't have strong feelings either way on this point; 
> either of the above 
> two versions of REQ-7 are fine with me.
> 
> Thanks,
> Bryan
> 
> >
> > I'm assuming that you are OK with the rest?
> >
> > From: Peterson, Jon [mailto:jon.peterson@xxxxxxxxxxx]
> > Sent: Tuesday, May 24, 2005 01:50
> > To: Audet, Francois [SC100:9T51:EXCH]; Behave
> > Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01
> >
> >
> >
> > Regarding just the REQ-7 text, I do think Bryan's 
> suggestion has some 
> > merit. These requirements are intended to constrain NAT 
> implementers, 
> > not the deployers of NATs. The implementers of NATs cannot 
> anticipate 
> > what sort of filtering will be desired; that is something that 
> > deployers of NATs should be able to configure.
> >
> > Jon Peterson
> > NeuStar, Inc.
> >
> > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
> > Audet
> > Sent: Monday, May 23, 2005 11:00 AM
> > To: 'Behave'
> > Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01
> >
> >
> >
> > Thanks to all,
> >
> >        a NAT have an "Endpoint independent filtering" behavior.
> >        If a more stringent filtering behavior is desired, 
> it is RECOMMENDED
> >        that a NAT have an "Address dependent" behavior.
> >
> > In the REQ-7 justification section would be modified as follows:
> >
> filtering is aimed at
> >        maximizing feature transparency, in particular for 
> applications that
> >        receive media simultaneously from multiple locations 
> (e.g., gaming),
> >        or applications that use rendezvous techniques. 
> However, it is also
> >        possible that in some circumstances, it may be 
> preferable to have
> >        a more stringent filtering behavior. Filtering 
> independently of the
> >        external endpoint is not as secure: an unauthorized 
> packet could get
> >        a specific port while the port was kept open if ti 
> was lucky enough
> >        to find the port open. In theory, filtering based on 
> both IP address
> >        and port is more secure than filtering based only on 
> the IP address
> >        (because the external endpoint could in reality be two 
> > endpoints behind
> >        another NAT, where one of the two endpoints is an attacker): 
> > however, such
> >        a policy could infere with applications that use one 
> than one 
> > port.
> >
> > Wordy terminology:
> >   As for the wordy terminology for some of the names of 
> behaviors, I 
> > also agree
> > REQs in-line:
> >   Bryan feels strongly about copying/pasting the REQs from 
> section 12 
> > in-line in the
> think it is a 
> > reasonable
> >   suggestion. Is there any STRONG objection to this? (Cullen in 
> > particular, I'd like to
> >   hear from you).
> >
> > Determinism:
> >   I propose that to address Bryan's concern, I put a note 
> in section 
> > 4.1 and 5.1
> >   refering to the Deterministic behavior section. I also propose to 
> > change the first
> >   sentence of section 8 to the following:
> >     The classification of NATs is further complicated by 
> the fact that 
> > under some
> >     conditions the same NAT often exhibits different behaviors, 
> > especially for
> >     mapping and filtering.
> >
> > Again, I'd like a Yay or Nay from people on the points above.
> >
> > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
> > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
> >
> > <mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx> ] On Behalf Of
> >
> > > Peterson, Jon
> > > Sent: Friday, May 20, 2005 16:48
> > > To: Behave
> > > Subject: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01
> > >
> > >
> > >
> > > In light of the recent Last Call discussions about 
> behave-nat-udp, I 
> > > wanted to make a few comments.
> > >
> > > Regarding REQ-7, it seems pretty clear to me that there is no 
> > > immediate consensus to endorse endpoint-dependent or 
> > > endpoint-independent filtering. Consequently, in the interest of 
> > > time I'd like to make the modest proposal that REQ-7 endorse 
> > > neither, but instead state that both these modes (and 
> > > address-specific filtering) should be supported. Is there some 
> > > advantage to privileging one over the other?
> > >
> > > I see no great need to specify the maximum datagram 
> length that NATs 
> > > must process.
> > >
> > > I find the conceptual model of behave-nat-udp, which focuses on 
> > > functions NATs might perform rather than classifications 
> of NATs as 
> > > particular taxonomic entities (Basic, Full Cone, etc), to be very 
> > > attractive. That much said, I do agree with several commentators 
> > > that the resulting functional descriptions lead to some 
> very wordy 
> > > terminologies. There seems to be some emerging agreement 
> on shorter 
> > > terms, and I think that would be most welcome to readers.
> > >
> > > Regarding the terms used in behave-nat-udp versus 
> ford-behave-gen, I 
> > > see no immediate problems with the terms used in 
> behave-nat-udp. The 
> > > distinction between a "map", a "binding" and a "NAT session" in 
> > > ford-behave-gen makes me a little dizzy, to be honest. I 
> do not find 
> > > the definition of "mapping" in behave-nat-udp to be 
> problematic. I 
> > > don't find the use of the term "session" to refer to a 
> > > transport-layer connection between two endpoints to be 
> problematic.
> > > Terminology can be endlessly debated, but it is not clear to
> > > me that we will gain much leverage on our problem space by
> > > spending a few more cycles refining these terms.
> > >
> > > In Section 4.1, I think it reasonable to define behaviors such as 
> > > "External NAT mapping is endpoint address dependent" just 
> in order 
> > > to disallow them in the requirements section. I think it is worth 
> > > being specific about things that we don't want implementers to do.
> > >
> > > Given the conceptual model of behave-nat-udp, I think the 
> > > distinction between "deterministic" and 
> "non-deterministic" NATs in 
> > > Section 8 is valuable. In fact, I think this 
> non-determinism is one 
> > > of the primary grounds to move away from a taxonomic 
> model of NATs 
> > > and into the functional model espoused by behave-nat-udp. 
> I didn't 
> > > find Section 8 to be particularly obscure when I read it, 
> though no 
> > > doubt the text could be made more focused.
> > >
> > > Jon Peterson
> > > NeuStar, Inc.
> > >
> > > _______________________________________________
> > > Ietf-behave mailing list
> > > Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> >
> > <https://list.sipfoundry.org/mailman/listinfo/ietf-behave>
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>