Subject: [Ietf-behave] on the behave charter

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 20 May 2005 16:35:41 -0700 (PDT)

In response to some of the discussion on this list related to introducing a new 
charter milestone for a general transport-independent framework and 
requirements draft which would be independent of the transport-specific 
milestones currently on the charter, I have a few comments.

As some comments to the list have pointed out, there are requirements in the 
UDP draft which are not specific to UDP. Those requirements should no doubt be 
identified as such (I believe the authors of the UDP draft have agreed to 
this), and preferably split into a subsection specifically designated for such 
requirements.

I think it is important for the UDP work to complete expeditiously. I 
furthermore believe that these general requirements are necessary to 
understanding how to engineer UDP NAT behavior. I foresee no great difficulty 
in having other drafts, like the TCP draft, reference this section of the UDP 
document, provided that its content is sound.

Are there any advocates of a separate transport-independent draft who believe 
that this approach is unworkable?

Jon Peterson
NeuStar, Inc.

---

From: Bryan Ford <[email-masked]>
Date: Sat, 21 May 2005 08:46:58 -0700 (PDT)

On Friday 20 May 2005 19:35, Peterson, Jon wrote:
> In response to some of the discussion on this list related to introducing a
> new charter milestone for a general transport-independent framework and
> As some comments to the list have pointed out, there are requirements in
> the UDP draft which are not specific to UDP. Those requirements should no
> doubt be identified as such (I believe the authors of the UDP draft have
> agreed to this), and preferably split into a subsection specifically
> designated for such requirements.

In the interest of getting the UDP document published quickly, I would be 
amenable to this compromise strategy, under the condition that the new 
transport-independent subsection you propose incorporates some of the 
important text from the behave-gen draft (draft-ford-behave-gen-01.txt) that 
provide important general information or address issues currently missing 
from the UDP draft.  Specifically:

* Section 2 of behave-gen, which provides the logical model of NAT operation 
essential to making the actual behavioral requirements clear and precise for 
NAT implementors.  I could live with compressing or eliminating section 2.4 
on the legacy RFC3489 terminology since I know there are strong objections to 
even mentioning those terms, but I think the rest of the section is 
essential.

* Section 3.3 in behave-gen provides a more complete discussion of receive 
fragmentation behavior than the current section 11 of the UDP draft, and 
should be included or merged.  Also, the specific requirements regarding 
fragmentation support needs to be updated as per the recent fragmentation 
discussion on the list: i.e., the NAT MUST support receiving fragmented 
packets.

* Section 3.4 in behave-gen, on outbound fragmentation issues.

* Section 3.6, on DHCP-configured NATs and conflicting private IP address 
spaces.

* Section 3.8, on ICMP error handling, provides a more complete and 
transport-independent discussion of this issue than the current section 9 of 
behave-udp, and thus should be incorporated.

* Section 3.10, on ALG support recommendations.

* Section 3.11, on denial-of-service protection.

* Section 4, "Hints to Implementors": I think it would be useful to include at 
least some of this section, although it is only for information and doesn't 
contain any normative requirements.

> understanding how to engineer UDP NAT behavior. I foresee no great
> difficulty in having other drafts, like the TCP draft, reference this
> section of the UDP document, provided that its content is sound.

I agree, again provided that its content is sound, and provided that the 
transport-independent portions of the UDP draft are clearly marked as such in 
a separate section or sections for that purpose, so that there will be no 
ambiguity on which parts also apply to other transports.

Cheers,
Bryan