Subject: RE: [Ietf-behave] Standard Disclosure

From: "Francois Audet" <[email-masked]>
Date: Tue, 12 Jul 2005 08:16:10 -0700 (PDT)

Thanks. 

Agree.

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] 
> Sent: Tuesday, July 12, 2005 04:30
> To: Audet, Francois [SC100:9T51:EXCH]; David Barrett; Behave
> Subject: Re: [Ietf-behave] Standard Disclosure
> 
> 
> 
> Cullen with my individual hat on ....
> 
> Guys, I think this is in the wrong draft. Put all this stuff 
> in the test results draft including the table for all the 
> NATs we have tested. I can move the next version of 
> draft-jennings-behave-test-results to this style. I like the 
> basic way the terminology is set up. If we use these terms in 
> a test draft, it will help others that compare and publish 
> results about NAT behavior. If someone proposed a standard 
> XML format for this, I would make my test programs spit that 
> out as output. That might be very useful for the folks on 
> this list that run web sites that collect results from many 
> NAT. Basically, I like the idea of common terminology, but 
> think it should go in the test-results draft.
> 
> I would not hold my breath waiting to see this show up on the 
> back of a box that you might see at the local Best Buy. 
> Looking at what is on the boxes now, the amount of space on 
> them etc, I imagine the best we can hope for is is something 
> like it supports "RFC XXX - NAT UDP".
> 
> 
> And one comment with my chair hat on.
> 
> I can not think of another circumstance where IETF told 
> vendors what to put on a datasheet. I don't see anything 
> about that in the charter. There are standards group that do 
> this type of branded activity stuff (The "WiFi" brand being 
> one of the best known) but those group have contractual 
> relationships with vendors that allow them to cause things to 
> happen that would be impossible for IETF.
> 
> Cullen
> 
> 
> 
> On 7/11/05 9:12 PM, "Francois Audet" <audet@xxxxxxxxxx> wrote:
> 
> > Or perhaps I could include a little table in section 12 
> with all your 
> > items, but including the REQ number they correspond to.
> > 
> > I think it is a reasonable idea. I don't mind adding somthing like 
> > that.
> > 
> > Anybody opposed?
> > 
> > I think I've heard at least two voices supporting this.
> > 
> >> -----Original Message-----
> >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
> >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf 
> Of David 
> >> Barrett
> >> Sent: Monday, July 11, 2005 17:57
> >> To: 'Behave'
> >> Subject: [Ietf-behave] Standard Disclosure
> >> 
> >> 
> >> Francois Audet wrote:
> >>> Can you propose some text? Perhaps for section 1, or
> >> whatever section
> >>> you feel is appropriate.
> >> 
> >> I'd be happy to try.  Reviewing the UDP draft [1] I'd propose 
> >> including the following text:
> >> 
> >> [1]
> >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-02.txt
> >> 
> >> ----
> >> 
> >> 12. Standard Disclosure
> >> 
> >> To help consumers compare and choose between competing NAT 
> products, 
> >> for each NAT variation there SHOULD be made available a standard
> >> disclosure 
> >> of the NAT's behavior in the following form:
> >> 
> >>      Address and port mapping behavior:
> >>          "endpoint independent" |
> >>          "address dependent" |
> >>          "address and port dependent"
> >>      IP address pooling behavior:
> >>          "unsupported" |
> >>          "arbitrary" |
> >>          "paired"
> >>      Port preservation:
> >>          "yes" |
> >>          "no" |
> >>          "overloading"
> >>      Port-range preservation:
> >>          "none" |
> >>          "registered" |
> >>          "dynamic" |
> >>          "registered and dynamic"
> >>      Port-parity preservation:
> >>          "yes" |
> >>          "no"
> >>      Port-contiguity preservation:
> >>          "yes" |
> >>          "no"
> >>      Mapping refresh timer:
> >>          <seconds> |
> >>          "configurable"
> >>      Mapping outbound refresh:
> >>          "yes" |
> >>          "no"
> >>      Mapping inbound refresh:
> >>          "yes" |
> >>          "no"
> >>      Unsolicited packet filtering:
> >>          "endpoint independent" |
> >>          "address dependent" |
> >>          "address and port dependent"
> >>      Filter refresh timer:
> >>          <seconds> |
> >>          "configurable"
> >>      Filter outbound refresh:
> >>          "yes" |
> >>          "no"
> >>      Filter inbound refresh:
> >>          "yes" |
> >>          "no"
> >>      Hairpining behavior:
> >>          "none" |
> >>          "external source address and port" |
> >>          "internal source address and port"
> >>      Fixed application level gateways:
> >>          <DNS, FTP, etc.> |
> >>          "none"
> >>      Configurable application level gateways:
> >>          <DNS, FTP, etc.> |
> >>          "none"
> >>      Mapping and filtering determinism:
> >>          "deterministic" |
> >>          "non-deterministic"
> >>      Supports ICMP destination unreachable:
> >>          "yes" |
> >>          "no"
> >>      Supports fragmentation:
> >>          "yes" |
> >>          "no"
> >>      Fragment receive ordering:
> >>          "ordered" |
> >>          "out of order" |
> >>          "none"
> >>      Maximum transmission unit (MTU):
> >>          <bytes> |
> >>          "configurable"
> >> 
> >> For example, the product datasheet for a given NAT device might 
> >> include the following complete description of its NAT behavior:
> >> 
> >>      Address and port mapping behavior:       endpoint independent
> >>      IP address pooling behavior:             paired
> >>      Port preservation:                       yes
> >>      Port-range preservation:                 registered 
> and dynamic
> >>      Port-parity preservation:                yes
> >>      Port-contiguity preservation:            yes
> >>      Mapping refresh timer:                   configurable
> >>      Mapping outbound refresh:                yes
> >>      Mapping inbound refresh:                 yes
> >>      Unsolicited packet filtering:            endpoint independent
> >>      Filter refresh timer:                    configurable
> >>      Filter outbound refresh:                 yes
> >>      Filter inbound refresh:                  yes
> >>      Hairpining behavior:                     external 
> source address
> >> and port
> >>      Fixed application level gateways:        DNS, FTP
> >>      Configurable application level gateways: none
> >>      Mapping and filtering determinism:       deterministic
> >>      Supports ICMP destination unreachable:   yes
> >>      Supports fragmentation:                  yes
> >>      Fragment receive ordering:               out of order
> >>      Maximum transmission unit (MTU):         configurable
> >> 
> >> REQ-14: The product literature and documentation for a NAT SHOULD
> >>     include a standard description of its behavior in the form 
> >> detailed
> >>     by this document.
> >> 
> >> ----
> >> 
> >> Questions:
> >> 1) Are they called "external ports and addresses" or "public ports 
> >> and addresses"?  I'm using "external".
> >> 2) Should we use "yes/no" or "true/false"?  I'm using "yes/no".
> >> 3) Where should this be put?  I'm recommending a new section
> >> after all 
> >> the definitions, but before the requirements.
> >> 4) How strongly should it be required?  I'm proposing "SHOULD".
> >> 
> >> Naturally as the terminology in the draft changes, this 
> section would 
> >> need to be updated.  However, I believe it provides a 
> concise way to 
> >> completely define a NAT's behavior, and thus enable the 
> consumer to 
> >> make an informed choice between competing choices.
> >> 
> >> -david
> >> _______________________________________________
> >> Ietf-behave mailing list
> >> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> >> 
> >> 
> 
> 
>

---

From: David Barrett <[email-masked]>
Date: Tue, 12 Jul 2005 14:12:28 -0700 (PDT)

I can see this perspective.  I think it depends on whether or not there 
is an explicit requirement that vendors disclose their NAT behavior in 
this form.  If it is required, it'd need to be kept in the BEHAVE draft 
with the other requirements.  If it's not required, I agree it can (and 
probably should) be moved to a separate document.

And to clarify, I agree it won't likely go onto the box.  But I don't 
think it's onerous to require that it go *somewhere*, such as in the 
product documentation.  The impetus for all this was because I was doing 
research on a specific NAT model and could find *no* description of its 
behavior, anywhere, in any detailed form.

I proposed the following requirement text:

REQ-14: The product literature and documentation for a NAT SHOULD
    include a standard description of its behavior in the form detailed
    by this document.
This is intentionally ambiguous in its reference to "product literature 
and documentation" (though perhaps an 'or' would be better there) to 
give the vendor flexibility in where to put it, so long as it's put 
*somewhere*.

So I pose this question: should BEHAVE make *any* requirement (of any 
strength) that vendors disclose NAT behavior in a standard way, or not?

I vote yes, else I fear vendors will stick with "business as usual" 
which means non-disclosure.

-david

Francois Audet wrote:
Thanks. 

Agree.

-----Original Message-----
From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] 
Sent: Tuesday, July 12, 2005 04:30
To: Audet, Francois [SC100:9T51:EXCH]; David Barrett; Behave
Subject: Re: [Ietf-behave] Standard Disclosure

Cullen

Anybody opposed?

-----Original Message-----

Barrett

you feel is appropriate.

[1]

12. Standard Disclosure

and port

----

Questions:

-david