File Transfer Protocol HOST Command for Virtual Hosts
draft-hethmon-mcmurray-ftpext-ftp-hosts-05

I have no objection to the publication of this document, but I do have a non-blocking comment that I think would be useful to consider.  The examples supplied in section 3.1 (top of pg. 8) are educational, but I am concerned about the use of link-local IPv6 addresses.  The examples do not seem like they need to use link-local IPv6 addresses, so using global addresses out of the documentation space (RFC 3849) would be a good choice.  My concern about using link-local IPv6 addresses is that their use requires more information than just the address.  In order to handle the non-uniqueness of these addresses, users have to specify which interface to use for the communication (e.g., "ftp FE80::1:2:3:4%en0").  RFC 4007 (section 11) discusses the reason for needing this additional information.  Given that, I would suggest changing the example to use the defined documentation (i.e., global) address range.

I'm clearing and making my discuss a comment; you now know the issue and I do not have a strong opinion about how to fix it. Here were my two significant comments:

Bbefore recommending the approval I wanted to ask for clarification on two points to make sure that implementors can read this spec accurately.

I had trouble understanding what the "chooses not conform" on page 17 means. Did you mean "chooses not to use"? 

Similarly, on page 18, I did not understand this: "a server implementation MUST treat an additional HOST command that was sent before a user has been authenticated as though a previous HOST command was not sent." Can you clarify?

See also Meral's Gen-ART review.

Section 3, para 1: "legal" is weird here. Don't you mean "authorized"?

Section 3.1: Why are these copied in here as opposed to being included by reference? Especially given that you've got a change to hostname and not to the literals, you're bound to cause confusion by mixing them. But we've seen this before and I leave it to the authors and AD to make the right choice.

Section 3.2.2, para 5: "An exception to the above statement..." Which above statement are you talking about?

After discussing with the Apps AD, I'd prefer that there's some kind of recommendation for the support of TLS for protecting communications between the UA and the host.

I have a few comments that you might wish to consider, along with any other comments you receive during IESG evaluation.

In section 3.1.  Syntax of the HOST command

   The "hostname" (given as a parameter) specifies the virtual host to
   which access is desired.  This SHOULD be the same host name that was
   used to obtain the IP address to which the FTP control connection was
   made, after any client conversions have been completed that convert
   an abbreviated or local alias to a complete (fully qualified) domain
   name, but before resolving a DNS alias (owner of a CNAME resource
   record) to its canonical name.

I'm not understanding why this is a SHOULD. Does something break in the protocol if you don't do this? Can the server-FTP process even tell that the user-FTP process has specified a host name that wasn't used to obtain the IP address?

In section 3.2.  HOST command semantics

   Upon receiving the HOST command, before authenticating the user-PI, a
   server-FTP process SHOULD validate that the hostname given represents
   a valid virtual host for that server, and, if it is valid, establish
   the appropriate environment for that virtual host.

I'm not understanding why this is a SHOULD. Is this just so a server-FTP process that treats all of its virtual hosts as identical doesn't have to reject a HOST command from a user-FTP process that uses the HOST command to be robust in the presence of virtual hosts that aren't identical?

In section 3.2.1.  REIN command semantics

   As specified in [RFC0959], the REIN command returns the state of the
   connection to what it was immediately after the transport connection
   was opened.  This specification makes no changes to that behavior.
   The effect of a HOST command MUST be reset if a REIN command is
   performed, and a new HOST command MUST be issued afterwards in order
   to connect to a virtual host.

I think I was able to figure out what this is saying, but the (I think) similar text at the beginning of Section 4 was much easier for me to understand. You might consider stealing some of that phrasing, perhaps something like 

   As specified in [RFC0959], the REIN command returns the state of the
   connection to what it was immediately after the transport connection
   was opened.  This specification makes no changes to that behavior.
   In this situation, the server implementation MUST reset the
   authentication environment as though a previous HOST command was not
   sent, and a new HOST command MUST be issued afterwards in order
   to connect to a virtual host.

Thank you for including Appendix A. It was helpful to me as a reviewer.

- I support Sean's DISCUSS points

section 1 - "Such an arrangement presents some problems
for FTP servers, as an FTP server distinguishes incoming
FTP connections by their IP addresses rather than their
DNS names." is a bit confusing, I think s/IP
address/inbound destination IP address/ would clarify.
I was temporarily confused by that fwiw.

section 3 - with a host, auth, host sequence the 2nd
host command gets a 503 response. But what else happens,
if anything? You probably should say if its not implied
by the 503.

3.1 - say if a server is behind a NAT/CGN. Then it might
be genuinely presented with an IP address literal that's
not the one by which it knows itself.  Very much a
corner case, but do you really want that MUST for
sending a 504 in that case?  Actually now that I think
about that, it might be a real issue for WebRTC handling
of ftp: URLs maybe.  I guess there might also be a
corner case wrt MPTCP there too, can't recall.

3.2.1 - corner case - with an OTP REIN isn't quite what
its supposed to be, but that's independent of HOST I
guess

Appendix A - I'm not sure all of the paths-not-taken are
required to be "unworkable" so the appendix title seems
odd.

Section 3.1 copies ABNF from RFC 3986 rather than incorporating it by reference.   The reader most likely knows what an IPv4 address and an IPv6 address looks like, and if they don't they can refer to RFC 3986.   So I would really encourage you to incorporate these by reference rather than copying the text.   Copying the text invites errors, and I don't think it adds value.

Dropping the following DISCUSS based on Barry's agreement to address it.   There is still some discussion ongoing with the authors about other concerns that came up during the discussion of the DISCUSS, but I don't think they are DISCUSS-worthy.

Section 3, paragraph 1:
   This command MUST be
   issued before the user is authenticated, as this will allow the
   authentication scheme and set of legal users to be dependent upon the
   virtual host that is chosen.

Does this mean "if the user agent is going to send a HOST command, it MUST send it before it authenticates?"   Or does it mean "User agents implementing this specification MUST send a HOST command before authenticating?"    I think it means the latter, but it could be read as meaning the former.