[BEHAVE] AD review: draft-ietf-behave-ftp64-09

["David Harrington" <[e-mail]>]

Hi,

I reviewed draft-ietf-behave-ftp64 and have a few questions.
Overall I think the document looks to be in good shape.
I spotted a few things that might cause IESG approval to be delayed,
and had a couple questions because I am not an expert in the content.
Some text modifications might make things clearer.

1) should security considerations discuss trust between client-alg and
alg-
server? I assume TLS cannot be used end-to-end for FTP, but must be
hop-to-hop
client-to-alg, and alg-to-server. Assuming different credentials
apply, the
secuirty association must be established between the client and the
alg, not
client-server, and the security association  must be established
between the alg
and server, not client-server. I would also assume that how this is
accomplished
depends on whether active or passive mode is being used to establish
connections.
The text as written might already already say that only passive
mode is used in the presence of TLS protection, but I'm not sure that
is what
the text says. This might be made clearer.

2) section 4 "As such, an ALG used with a stateful translator MUST
support EPSV
and MAY support EPRT. However, an ALG used with a stateless translator
SHOULD
also support EPRT. " Is there a requirement regarding stateless and
EPSV?

3) in section 9, "Implementations SHOULD NOT try to detect the
situation where
both PASV and PORT commands are issued prior to a command that
initiates a
transfer, but rather, apply the same translation they would have if
there had
not been a PASV command prior to a PORT command or a PORT command
prior to a
PASV command. " I find this a bit ambiguous. Is it expected that the
translation
they would have done be based on having received only the second
command (as if
the first had not been received), or based on not having received
either?

4) should the NOOP in section 12 be reflected in the ABNF algs-command
?

5) draft-liu-ftp64-extensions should be updated to
draft-ietf-ftpext2-ftp64
during subsequent processing.

6) The normative reference to ftpext2 work could cause this document
to be held
up in processing. is there a way to eliminate this reference? Can an
implementation "support EPSV successfully" without this ftpext2
extension? The
text isn't clear that "successfully" means requiring support for an
IPv4-IPv6
translation environment; that is only implied by the choice of
reference [2428]
vs [ftpext2]. 

Thanks,
David Harrington
Director, IETF Transport Area
[e-mail] (preferred for ietf)
[e-mail]
[phone] (cell)