Subject: RE: [Ietf-behave] Standard Disclosure

From: "Francois Audet" <[email-masked]>
Date: Mon, 11 Jul 2005 18:12:52 -0700 (PDT)

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: Mon, 11 Jul 2005 18:23:19 -0700 (PDT)

Francois Audet wrote:
Or perhaps I could include a little table in section 12 with all your 
items, but including the REQ number they correspond to.
My original instinct was along these lines, too, but then I decided to 
keep it focused on exclusively the topic of disclosing NAT behavior in a 
regular way.  I didn't want to confuse the section by unnecessarily 
cross-referencing it against the requirements -- it's not intended to be 
an index or summary of requirements.

With that in mind, I stick to my original proposal of giving it its own 
section.

Anybody opposed? 

I think I've heard at least two voices supporting this.
Thanks.  I think it'd be useful, too.

-david

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 12 Jul 2005 04:30:17 -0700 (PDT)

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