FTP Command and Extension Registry
RFC 5797

[Ballot discuss]
First some background ….

The INAA registration procedures are under specified. and will just add to confusion without adding much to existing commonly used IANA terms.

  1.  The extension is described in an RFC or other generally-available
      publication for which the fact of publication indicates some
      level of peer review of document quality.

The term peer review will generate debate any time it is applied. Large portion s of the academic community does not consider stander track RFC to be peer reviewed. I on the other hand consider something that I ran by 3 other epode and posted on my blog to peer reviewed. The "National Enquirer", which considers itself a journal, has considerable proof all this articles are peer reviewed by experts. I will argue that for all practical purposes, the above will be about the same as FCFS.

  2.  The extension is actually implemented in FTP client and server
      systems that are generally available (not necessarily either free
      or unencumbered, but available) and those systems are identified
      as part of the documentation requirement above.

This seems to highlight that the documentations requirements don't include any requirement of other people being able to implement the and purely a description would be sufficient for registration. For example "My secrete compression extensions that will compress any file by a factor or 2". Generally available is also a very vague term. I regally have people incest that something meant for over a billion cell phones is not for "general use" and I also hear people claiming something is generally available when a few grad students and two differ universities causes a message or two to interoperate.

Creating new registration process just causes extra work and head aches for the people that have to deal with them for years to come. For that reasons I would have preference to choose one of the existing commonly used registration practices unless there was some really good reason they were not adequate. Inventing news ones is not easy.

From my point of view, I do not understand the motivation for this draft to need smoother than FCFS, or it could choose Spec Required. Or it could choose a combination of requiring either of
1) Spec Required, or
2) Combination of FCFS along with Running Code

It's not like we have a zillion people developing FTP extensions and the code space does not look at any risk of running out.
Now to the heart of my actual Discuss. Why can't we use one of the existing common registration procedures? If there is a special reasons something new is needed, I'm willing to be convinced but I'd rather not create new things if not needed as they are not easy to nail down.

[Note]: 'Barry Leiba <barryleiba@computer.org> is the document shepherd.
Note that as per latest revision, references to documents defining FTP extensions are now Informational.' added by Alexey Melnikov

[Ballot discuss]
Given the changes to the strength of implementation requirements on some of the extensions, should this document Update 2389 and 2428 (should 3659 also be in this list)?

[Ballot comment]
In this test from section 2.2:

  Command Name -  The FTP command, either new or modified, used in the
      extension or with which the extension is used.

what does "either new or modified" mean?


In section 3, s/marke/marked/

[Ballot comment]
I think it would be useful if the IANA registry contained all
commands (including those in Sections 2.4 and 2.5) -- this would make
it easier to figure out, e.g., which command names are "available" and
which are not.

[Ballot discuss]
I'll be happy to clear this Discuss if either the document is updated
or if I can be convinced that my concern is not a real issue.

Sections 2.4 and 2.5 list commands names that have been used, but that
are not to be included in the registry.

Section 2.3 describes the *only* criteria to be checked during expert
review. We can assume that one other criteria is checked by IANA -  that
the extension does not use a command name that is already in the
registry.

Naifly, it seems that no-one checks that the extension does not use a
command name that either:
- is already in use in the base protocol
or
- was used but has now been deprecated.

Wouldn't it make sense to also include the base commands and the
obsoleted commands in the registry to properly protect the protocol from
future confusion?

[Ballot comment]
There has been discussion of the comments in the Gen-ART Review by
  Ben Campbell.  I expected some changes to the document based on the
  discussion.

PROTO writeup for draft-klensin-ftp-registry-02, intended for Proposed Standard.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Barry Leiba is the document shepherd.  I have reviewed this version, and am satisfied that it's ready.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

The document has adequate review, and I have no concerns.  It received no negative comments during discussion on the apps-discuss list, nor during a presentation at the apps area general meeting in Hiroshima.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

I have no concerns.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

I have no concerns.  There is no IPR involved.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

There is, as best we can tell, agreement among the apps community that the registry that this creates is useful.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

There are a few unresolved nits according to idnits 2.11.15:
1. There is no pre-5378 disclaimer; this is not a problem for this document, which is entirely the work of the authors.
2. There is an unused reference for RFC 2119.  The authors have an -03 version of the document ready, which removes that and fixes a couple of minor editorial points.  They will submit that when the AD advises them to do so.
3. There are, by the nature of this document, references to experimental and obsoleted RFCs.  This is correct here, because we should be including the commands defined in those documents in the registry.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

All references are properly separated and labelled.  See 1.g for comment about downward references.  It's arguable that those do not need to be normative references, but they are currently defined as such, and the authors believe that is correct.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA Considerations section is correct and adequate.  The whole point of this document is to create an IANA registry.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

There is no formal language in this document.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

  Every version of the FTP specification has added a few new commands,
  with the early ones summarized in RFC 959.  RFC 2389
  established a mechanism for specifying and negotiating
  extensions to the FTP protocol specified in RFC 959, by
  means of "FEAT Strings" identifying extensions supported by the FTP
  server, and sent in response to a "FEAT" command.  As the number of
  those extensions increases, it appears useful to establish an IANA
  registry to reduce the likelihood of conflict of names and the
  consequent ambiguity.  This specification establishes that registry.

    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

This is not a WG document.
Nothing to note.  There have been no negative comments or objections.

    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?
       
FTP vendors appear to support the formation of this registry.  There's every reason to believe that they will use it.