Subject: Re: [Ietf-behave] on the behave charter

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 22 May 2005 12:47:36 -0700 (PDT)

--- "Peterson, Jon" <jon.peterson@xxxxxxxxxxx> 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
> requirements draft which would be independent of the transport-specific
> milestones currently on the charter, I have a few comments.
> 
[suresh] First off, thank you, Jon, for taking notice and responding with
comments. I appreciate that.

> 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

[suresh] UDP document does not get used in isolation by NAT implementers. TCP
work is equally or arguably more important (More apps use TCP than UDP). I
donot see the particular need for rushing the UDP draft (other than the
artificial one, by virtue of it being lised first in the WG milestones). NAT
implementers do not care for UDP RFC to be the first. More basic stuff such as
the logical mode of NAT operation, Distinction between Bindings and NAT
Sessions, DHCP Configured NATs, Hairpinning, fragmentation handling, ICMP
handling and generic hints to implementers are much more important from a basic
requirements understanding perspective. UDP specific aditional requirements are
relatively minor. 

As an FYI, more than 50% of the requirements in the current UDP draft are not
UDP specific. 

> furthermore believe that these general requirements are necessary to
> understanding how to engineer UDP NAT behavior. 

[suresh] Yes. I agree.

>                                                 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.
> 
[suresh] UDP draft curently has 13 requirements listed. More than 50% of the
requiements are not UDP specific. Behave-gen draft is focussed on generic
requirements, including common terminology and hints to implementers and has 11
generic  requirements.

Given a choice between the TCP draft refering the UDP draft vs a generic draft
for refering generic sections, which do you believe is cleaner? My choice would
be to have a seperate draft for generic requirements. That sounds more straight
forward, I believe, from a end-user (i.e., NAT implementer) perspective.

> Are there any advocates of a separate transport-independent draft who believe
> that this approach is unworkable?
>
[suresh] The approach you suggest is doable. But, that is more work because
large portions of the behave-gen draft are to be merged into the UDP draft to
have a solid generic section. 

Instead, why not simply excise generic stuff from the UDP draft and review the
UDP and generic drafts independently, but at the same time.  

> Jon Peterson
> NeuStar, Inc.

Thanks.

regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 22 May 2005 12:56:10 -0700 (PDT)

If there MUST be just one draft. I agree with what Bryan says below. Large
portions of behave-gen should be merged with the behave-udp draft.

cheers,
suresh

--- Bryan Ford <baford@xxxxxxx> wrote:
> On Friday 20 May 2005 19:35, Peterson, Jon wrote:
> > 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
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>

---

From: "Kaushik Biswas (kbiswas)" <[email-masked]>
Date: Tue, 24 May 2005 18:48:31 -0700 (PDT)

-----Original Message-----
From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Pyda
Srisuresh
Sent: Sunday, May 22, 2005 12:56 PM
To: Bryan Ford; ietf-behave@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Ietf-behave] on the behave charter

If there MUST be just one draft. I agree with what Bryan says below.
Large portions of behave-gen should be merged with the behave-udp draft.

[Kaushik] Agreed. Cleaner approach would be to have the
protocol-independent discussions in a separate draft or to atleast have
a separate section in the udp-draft merging the protocol-independent
stuff from behave-gen. 

Thanks,
Kaushik

cheers,
suresh

--- Bryan Ford <baford@xxxxxxx> 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 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.
> 
> 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
> 
> * 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.6, on DHCP-configured NATs and conflicting private IP 
> address spaces.
> 
> transport-independent discussion of this issue than the current 
> section 9 of behave-udp, and thus should be incorporated.
> 
> * 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.
> 
> > 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.
> 
> 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

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Wed, 25 May 2005 06:20:37 -0700 (PDT)

I strongly think the right approach would be a separate draft for the
transport independent requirements. Having the general requirements
split across TCP and UDP drafts would be a distraction to the NAT
implementers and people who deploy NAT. 

Senthil

-----Original Message-----
From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Peterson,
Jon
Sent: Friday, May 20, 2005 4:36 PM
To: ietf-behave@xxxxxxxxxxxxxxxxxxx
Subject: [Ietf-behave] on the behave charter

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.

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

Jon Peterson
NeuStar, Inc.