Subject: [BEHAVE] review of draft-ietf-behave-ftp64-05

From: "Dan Wing" <[email-masked]>
Date: Mon, 27 Sep 2010 14:28:11 -0700

Iljitsch,

My review:

Abstract:

   FTP has an active and a passive mode, both as original commands that
   are IPv4-specific, and as extended, IP version agnostic commands.
   The only FTP mode that works without changes through an IPv6-to-IPv4
   translator is extended passive.  However, many existing FTP servers
   do not support this mode, and some clients do not ask for it.  This
   document describes specifies a middlebox that may solve this
............^^^^^^^^^^^^^^^^^^^
           remove duplicate wording

-----

Section 1, Introduction:

   Although these issues can and should be addressed by modifying, where
   necessary, clients and servers support EPSV successfully, such
.................................^ 
                                "to"
   modifications may not appear widely in a timely fashion.  Also,
   network operators who may want to deploy IPv6-to-IPv4 translation
   generally don't have control over client or server implementations.
   As such, this document standardizes an FTP Application Layer Gateway
   that will allow unmodified IPv6 FTP clients to interact with
   unmodified IPv4 FTP servers successfully when using FTP for simple
   file transfers between a single client and a single server.

It seems useful to provide an Informational reference to the FTPEXT2 
document at the end of the first sentence.

-----

also in the Introduction:

   Clients that want to engage in more complex behavior, such as server-
   to-server transfers, may make an FTP application layer gateway (ALG)
   go into transparent mode by issuing an AUTH or ALGS commands as
.......................................^^
                                 remove "an"

-----

Section 2, Notational Conventions:

      Where these words appear in lower case, they SHOULD NOT be	
	interpreted within the context of [RFC2119], but rather, in	
	accordance with regular English usage.

I don't think that escape clause is useful.

-----

Informational references:

   [Bernstein]
              Bernstein, D., "PASV security and PORT security", 2000,
              <http://cr.yp.to/ftp/security.html>.

is listed, but isn't referenced.  idnits complained about that.  IESG
loves to run idnits, so we can't submit to IESG until that is fixed.

-----

Section 7.1, notwithstanding the escape clause in Notational 
Conventions, section 7.1 has a lowercase must:

   If the address specified in the EPRT command is the IPv6 address used
   by the client for the control channel session, then the FTP ALG
   reformats the EPRT command into a PORT command with the IPv4 address
   that maps to the client's IPv6 address.  The port number must be
............................................................^^^^
   preserved for compatibility with stateless translators.  For
   instance, if the client with IPv6 address 2001:db8:2::31 issues the
   following EPRT command:

This should be an uppercase MUST; non-compliance with that sentence
will break interoperability, right?

-----

Notwithstanding the escape clause in Notational Conventions,
I see Section 12 (Timeouts and translating to NOOP) uses RFC2119
language twice where it should really be uppercased:

   Wherever possible, control channels should not time out while there
.......................................^^^^^^^^^^
   is an active data channel.  A timeout of at least 30 seconds is
   recommended for data channel mappings created by the FTP ALG that are
...^^^^^^^^^^^
   waiting for initial packets.

I poked around a little bit but I couldn't find a citation for those
recommendations.  They both seem reasonable, but if there is a citation
that would strengthen them.

I would also suggest clarifying it to be more clear that the
text applies to the ALG itself, with wording like "the ALG should not 
time out its control channel ..." and "The ALG SHOULD NOT timeout the
data channel mapping until 30 seconds ...".

-d