Securing FTP with TLS
RFC 4217

Note: This ballot was opened for revision 16 and is now closed.

(Ted Hardie) Yes

(Harald Alvestrand) No Objection

Comment (2004-10-14 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Reviewed by John Loughney, Gen-ART

His review:

Technically, the document is ready, but it needs an additional editorial pass.
File a No Objection, but request an additional editorial pass.


1) References need splitting.
2) Draft is using  RFC2026 boilerplate, needs update
3) ToC is off.
4) Footers need to be fixed, they currently say: 
	Ford-Hutchinson                                         FORMFEED[Page 1]
5) Abstract reads more like an introduction, it should be shortened.
6) Need blank line between paragraphs in many places.
7) Page 4:
    "The File Transfer Protocol (FTP) currently defined in [RFC-959] and
   in place on the Internet is an excellent mechanism for exchanging
   files. "
	Suplufeous text, delete.  Most file exchangers are using non-IETF protocols
 	these days ....  
8) Sub-section titles shouldn't be indented.
9) 1st page header should be corrected.
10) Section 11 has formatting problems.
11) IPR & Copyright text need updating.

(Steven Bellovin) (was Discuss) No Objection

Comment (2004-10-14)
No email
send info
My comments have been folded in to Russ' DISCUSS.

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Scott Hollenbeck) No Objection

Comment (2004-10-04 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
References need to be split and the page numbers in the Table of Contents are off by quite a bit.

(Russ Housley) (was Discuss) No Objection

Comment (2004-10-13)
No email
send info
  The Abstract is way too long.  It is a full page.  Much of the information
  belongs in the Introduction.  Once moved to the Introduction, the list of
  bullets should also include one about authentication of the FTP server,
  which is not normally provided.

  I propose a rewording of the last paragraph of the Introduction:

    There are many ways in which these three protocols might be combined.
    This document selects one method by which FTP can operate securely,
    while providing both flexibility and interoperation.  This necessitates
    a brief description of the actual negotiation mechanism, a detailed
    description of the required policies and practices, and a discussion
    of the expected behaviours of clients and servers to allow either
    party to impose their security requirements on the FTP session.

  In the Overview: s/PBSZ:PROT/PBSZ and PROT/

  The paragraph indentation is inconsistent in sections 5 and 11.

  In section 5.2: s/USER command must still/USER command MUST still/

  In section 9: s/PBSZ:PROT command sequence/PBSZ command followed by the PROT command/

  In section 16.2.1: s/COULD/could/

(David Kessens) No Objection

(Allison Mankin) No Objection

Comment (2004-10-14 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
In the course of fixes for other purposes, the discussion in Section 15
of dropping FTP's use of the TCP URG should be cleaned up.  This is
not clear:

                                                                                    The TLS
      session will be corrupted if any data is sent on a socket while
      TLS is active.

(Thomas Narten) No Objection

Comment (2004-10-14 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
There is no IANA considerations asking to register the commands/names used. But it seems FTP never created an IANA registry. Should probably be fixed at some point...

(Jon Peterson) No Objection

(Alex Zinin) No Objection