Subject: [Ietf-behave] New TCP requirements draft

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Jun 2005 14:42:01 -0700 (PDT)

Greetings again. Now that looks like the UDP requirements document is 
going to be organized more along the "general NAT requirements first, 
UDP-specific requirements second" model, I thought it would be good 
to take a stab at a draft that had *only* TCP-specific requirements. 
Please see 
<http://www.ietf.org/internet-drafts/draft-hoffman-behave-tcp-00.txt>, 
which gets its definitions from the UDP requirements document.

This document is purposely quite short. The goal of this WG is to 
create documents that are easily understood by all NAT developers, 
not just the most technical ones (and not just the ones who like 
reading standards documents). To reach that goal, we need to limit 
the rationale descriptions to just enough for a developer to believe 
we have some reason for our requirements.

If I missed any TCP-specific requirements, I'm happy to revise the document.

--Paul Hoffman, Director
--Cybersecurity Association
--www.cybersecurity.org

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 5 Jun 2005 08:43:18 -0700 (PDT)

Hi Paul,

First of all, I think the length of this document is refreshing.  

I think Requirements 2 through 5 are clear and the right level of
detail for your average NAT developer.

Requirement 1 was not immediately obvious to me.  I was thoroughly
confused after reading the motivation, but understood the requirement
as long as I didn't try to think about the motivation. I don't think
it is obvious to a new reader what the motivation is.  I think most
developers think of this behavior as an accidental side-effect of some
implementation decision and will need a bit more explanation to
understand that it is a Feature instead of a bug.  I think a packet
flow diagram would be very helpful here.  The statement beginning
"Normal TCP stacks..." Is downright confusing.

On a purely editorial note, I think it is confusing to have
requirements numbered from 1 that start in section 2.  I would make a
Section 2: Requirements, and put the existing requirements under that.

thanks,
-rohan

On 6/1/05, Paul Hoffman <paul.hoffman@xxxxxxxxxxxxxxxxx> wrote:
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>