Subject: [Ietf-behave] Re: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00

From: Lars Eggert <[email-masked]>
Date: Tue, 16 May 2006 09:10:30 -0700 (PDT)

Forwarding to the behave list, where this discussion should take place.

Tom - thanks for the review!

On May 16, 2006, at 15:32, Tom Petch wrote:

I looked, took a few Paracetamol, looked some more and still think  
this is not
fit to advance; it is or is likely to be incomprehensible to many  
intended
readers.

Not surprisingly, then, I find it hard to give specific, tcp- 
technical reasons
why -  eg REQ-3 is wrong because it does not take cognizance of  
para x in
RFCyyyy; rather, it is the 'first impressions count', the look and  
feel that
convinces me that this I-D is not fit.

First page and there are too many editors for the RFC Editor's  
liking.  Move on
to  'Applicability' and it is very clear: 'Application and OS  
aspects of  TCP
NAT traversal are out-of-scope'; but wait for section 6,
"6.  Application Level Gateways
   FIXME OPEN ISSUE: Is this out-of-scope?  Do we need to specify all
   TCP ALGs should be off by default?  What about FTP?"
(good questions).

The document is written in an unfamiliar (to me) language of NAT- 
specific
technical terms, for which the reader is referred to FIXME-BEHAVE- 
UDP (sic)
which is in fact draft-ietf-behave-nat-udp-06 (the subject of  
recent criticism
on the main IETF list).  This has a poorly laid out section on  
Terminology which
urges the reader
"to refer to RFC 2263 [8] for information on NAT taxonomy and  
terminology"
(in passing, RFC2263 is SNMP Applications from one of the abortive  
starts on
SNMPv3) and ends with comments that the terminology from RFC3489  
{STUN}
"has been the source of much confusion as it has proven inadequate..."
(yes, feels about right).  In between, this section makes no  
mention of several
of the terms in use (eg Address and Port Dependent Mapping) so the  
reader of
behave-tcp must read and digest behave-udp (and RFC2263) before  
starting.

A simple example on terminology; these I-D take terms like internal  
and external
for granted; well yes, I can deduce what they mean but what is  
internal to an
ISP is not internal to an ISP's customer and vice versa; it would  
be so easy to
make the meaning clear (like, a diagram).

This I-D has normative references to NUTSS and NATBLASTER in the  
shape of
SIGCOMM  Proceedings which suggests to me that the intended  
audience is rather
esoteric.

As I said, none of this is hard, tcp-related reasons why I regard  
this I-D as
unfit to advance but I think it does give the flavour.

I note that the only reference to TCP is to RFC793, which, great as  
it is, is
not the TCP used in most sessions today (are the editors aware of  
this?).  The
I-D should at least reference the recent Roadmap and say whether or  
not the many
later additions to TCP are relevant to NATs or not.

Overall, I think that behave is on the wrong track; this I-D reads  
like an
afterthought tacked onto UDP-related work by someone keen on  
gaming.  Rather,
they should first produce an update to RFC2263 on NAT in general,  
with clear
concepts and related terminology, and then produce separate I-D for  
UDP and TCP
(and DCCP and STCP and etc etc) which refer back to this common  
work.  The idea
that someone concerned with TCP should first become a master of UDP  
and NUTSS
is, well nuts:-)

Tom Petch

----- Original Message -----
From: "Mark Allman" <mallman@xxxxxxxx>
To: <tcpm@xxxxxxxx>
Sent: Tuesday, April 18, 2006 3:54 PM
Subject: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00

Folks-

Lars sent the attached request a few weeks back and we haven't heard
anything.  Could a couple of folks volunteer to take a look at this
document in the next week or two (it's pretty short)?
(And, send along a note to me indicating that you intend to do so,  
else
I'll have to try to poll people specifically.)

Thanks!

allman

---------------------------------------------------------------------- 
----------

_______________________________________________
tcpm mailing list
tcpm@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/tcpm
Lars
--
Lars Eggert                                     NEC Network Laboratories

Attachment:
smime.p7s

---

From: Saikat Guha <[email-masked]>
Date: Thu, 18 May 2006 09:28:26 -0700 (PDT)

Thanks for the review Tom. 

On Tue, 2006-05-16 at 18:10 +0200, Lars Eggert wrote:
> > 'Applicability' and it is very clear: 'Application and OS  
> > aspects of  TCP

Agreed. ALGs were deemed in scope at the last meeting. The applicability
statement will reflect this.

> > technical terms, for which the reader is referred to FIXME-BEHAVE- 

Agreed. The draft now summarizes the important terminology from UDP
where appropriate.

> > SIGCOMM  Proceedings 

References to the above and like have been moved to the informational
references section. 

> > The

OK.

> The idea
> > [...] is, well nuts:-)

While I agree to some extent, I believe the main audience of the
documents (both UDP and TCP) are NAT vendors (and to some extent
application developers). The argument for moving some
protocol-independent stuff into UDP was that a vendors will need to read
and understand the full set of 3-4 RFC/BCPs  (UDP, TCP, ICMP, ...) for
their product anyway and each therefore need not be stand-alone. That
said, I agree that TCP draft should reduce its dependence on the UDP
terminology by summarizing the important bits when necessary.

cheers,
-- 
Saikat
Attachment:
signature.asc