Subject: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 3 Jun 2005 12:35:58 -0700 (PDT)

> One more reason, why I believe, we need to treat behave-gen and behave-udp as
> two different drafts with different scopes and NOT combine them into one 
> within
> the UDP draft. Any comments?
 
I do have one further comment on this. It has become increasingly clear to me 
that treating these as separate drafts, with separate authors and terminology 
and ideas, is unlikely to be a path towards consensus. At best, I think it 
would sweep certain differences under the rug. I think it is preferable, and 
possible, to come to WG consensus about those differences. That should be done 
in the context of a single document.

Jon Peterson
NeuStar, Inc.

> cheers,
> suresh

---

From: Marc Manthey <[email-masked]>
Date: Fri, 3 Jun 2005 12:43:35 -0700 (PDT)

hello experts, sorry for  my  offtopic  post
due  to the massive  influence from tycoon firms,
apple for  example during  the miss use of vlanhacks
and the ongoing  software patents disscussion
in europe and the pressure from the
http://www.mpaa.org/ on bittorrent users
i think there is a strong need for  Opencuseeme
a free peer2peer multiconferencing tool.
please  join
regards
www.cuseeme.de
Attachment:
smime.p7s

---

From: Pyda Srisuresh <[email-masked]>
Date: Sat, 4 Jun 2005 10:33:48 -0700 (PDT)

--- "Peterson, Jon" <jon.peterson@xxxxxxxxxxx> wrote:

> possible, to come to WG consensus about those differences. That should be
> done in the context of a single document.
> 
[suresh] It is interesting that you come to a different conclusion than I did.
I agree there shoudl be consensus on the terminology used across the drafts.
But, I dont see why there cannot be seperate drafts with seperate authors,
using the same terminology. What are the differences you think will be swept
under the carpet? 

FWIW, Bi-directional NATs effect the TCP apps just as they do the UDP apps. The
Bindings (Address and/or Port Bindings) are bi-directional in a Bi-Directional
NAT. As a result, Bi-Directional NAT is P2P friendly for both TCP and UDP apps.
So, going by your argument, why continue with a seperate draft for TCP? Why not
combine all three drafts (behave-gen, behave-udp & behave-tcp) into one? 

While on the subject, let me also point out that a NAT device may not be a pure
Cone NAT or a pure Bi-Directional NAT. The address maps configured on a NAT
device may be such that certain Bindings  are uni-directional and some  are
Bi-directional so that the NAT device provides security in some cases and added
application friendliness in other cases. The key here is configurability and
directionality of the Bindings on the NAT device. Not mentioning the term
Binding in a Behave draft would be "brushing under the rug".

There are several items in the behave-gen draft that effects TCP apps. ICMP
Error packet handling, rejection of IP packets not permitted by NAT, honoring
the DF bit, Port Block reservaton, Hairpin support in a Multi-level NAT,
fragment processing, and DHCP configured NAT processing - to name a few.
Depending upon your point of view one could argue for them all being combined
into a single draft along with the TCP and UDP requirements or into 3 different
drafts.

We agreed on this list that there is a need for transport-independent general
NAT requirements, UDP-specific NAT requirements and TCP-specific NAT
requirements. The WG milestones calls for producing BCP drafts for a) unicast
UDP requirements, b) TCP requirements, and c) ICMP  requirements. 

Given these, I would think, the natural conclusion would be one of 
(i) generate three behave drafts - one each for transport-independent general
NAT requirements, UDP-specific NAT requirements and TCP-specific NAT
requiremens.
(or) 
(ii) Combine all three requirements into a single draft.

I donot understand how one could draw the conclusion to have two drafts - One
to cover transport-independent general requirements and UDP-specific
requirements; and another to cover TCP-specific requirements. 

Please explain. Thanks.

cheers,
suresh