Securing FTP with TLS
RFC 4217

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

(Ted Hardie; former steering group member) Yes

Yes ( for -)
No email
send info

(Alex Zinin; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Allison Mankin; former steering group member) No Objection

No Objection (2004-10-14 for -)
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.

(Bill Fenner; former steering group member) No Objection

No Objection ( for -)
No email
send info

(David Kessens; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Harald Alvestrand; former steering group member) No Objection

No Objection (2004-10-14 for -)
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.

Comments:

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.

(Jon Peterson; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Margaret Cullen; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection (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/

(Scott Hollenbeck; former steering group member) No Objection

No Objection (2004-10-04 for -)
No email
send info
References need to be split and the page numbers in the Table of Contents are off by quite a bit.

(Steven Bellovin; former steering group member) (was Discuss) No Objection

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

(Thomas Narten; former steering group member) No Objection

No Objection (2004-10-14 for -)
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...