Securing FTP with TLS
draft-murray-auth-ftp-ssl-16
Yes
(Ted Hardie)
No Objection
(Alex Zinin)
(Bill Fenner)
(David Kessens)
(Jon Peterson)
(Margaret Cullen)
Note: This ballot was opened for revision 16 and is now closed.
Ted Hardie Former IESG member
Yes
Yes
()
Unknown
Alex Zinin Former IESG member
No Objection
No Objection
()
Unknown
Allison Mankin Former IESG member
No Objection
No Objection
(2004-10-14)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Harald Alvestrand Former IESG member
No Objection
No Objection
(2004-10-14)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Margaret Cullen Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2004-10-13)
Unknown
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 IESG member
No Objection
No Objection
(2004-10-04)
Unknown
References need to be split and the page numbers in the Table of Contents are off by quite a bit.
Steven Bellovin Former IESG member
(was Discuss)
No Objection
No Objection
(2004-10-14)
Unknown
My comments have been folded in to Russ' DISCUSS.
Thomas Narten Former IESG member
No Objection
No Objection
(2004-10-14)
Unknown
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...