Subject: [Gen-art] Gen-ART LC review of draft-klensin-ftp-registry-02

From: Ben Campbell <[email-masked]>
Date: Fri, 20 Nov 2009 15:58:13 -0600

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-klensin-ftp-registry-02
Reviewer: Ben Campbell
Review Date: 2009-11-20
IETF LC End Date: 2009-11-23
IESG Telechat date: (if known)

Summary:

This draft is very close to ready to publish as a proposed standard. I have one minor clarification question, and a few nits.

Major issues:

None.

Minor issues:

-- section 2.4:

The section indicates that "base" FTP commands are not to be included in the registry. Is IANA expected to verify that any newly registered extensions do not conflict with base commands?

Nits/editorial comments:

-- Section 2.2, "Extension name" section. 

The text states that this column is called "FEAT Code". Should the paragraph be entitled "FEAT Code" rather than "Extension name" ?

-- Section 3, last paragraph prior to table:

s/marke/marked

-- IDNITS returns the following. In the case of the downref, I understand why it is there and do not object per se, but I wonder if it would not make more sense for that to be an informational reference. That is, it does not seem necessary to understand or implement the referenced document to understand or implement this one.

  == Unused Reference: 'RFC2119' is defined on line 355, but no explicit
     reference was found in the text

  ** Downref: Normative reference to an Experimental RFC: RFC 2773

  -- Obsolete informational reference (is this intentional?): RFC 1545
     (Obsoleted by RFC 1639)

---

From: Alfred Hönes <[email-masked]>
Date: Sun, 22 Nov 2009 22:55:22 +0100 (MEZ)

Ben,
thanks for your GenART review.
Please see my responses inline.

Ben Campbell wrote:

> This draft is very close to ready to publish as a proposed standard.
> I have one minor clarification question, and a few nits.
>
> Major issues:
>
> None.
>
> Minor issues:
>
> -- section 2.4:
>
> The section indicates that "base" FTP commands are not to be included
> in the registry. Is IANA expected to verify that any newly registered
> extensions do not conflict with base commands?

If that's indeed an issue, it might affect the legacy command names
in Section 2.5 as well.

However, the first paragraph of Section 2.3 already states:

| "This registry is primarily intended to avoid conflicting uses of the
|  same extension names and keywords for different purposes, not to
   demonstrate that an extension is somehow "approved".  [...]"

... restating that awareness of name conflicts was the primary
driving force for the document.  It would be entirely silly
(as far as we understand) for the author(s) of an FTP extension
to define 'new' command names conflicting with, and hence improperly
overlaying existing standard command names documented in RFCs.

In the case of item 1. in Section 2.3, the requested "peer review"
of the specification was assumed to guarantee that such sillyness
did not occur; in the case of item 2., actual implementation of the
new extension is required, which would be impossible in a manner
still conformant with STD 9, if a conflict were present.

We did not want to exclude the possibility to list already defined
command names in the registry again once a new extension adds new
functionality to an existing command, as already has happened for
the RFC 2228 commands AUTH, PBSZ, and PROT -- cf. Table 1.  Hence,
a simplistic formal uniqueness requirement for command opcodes does
not exist.

Thus, we reasonably expected that the applicants themselves take care
of conflict avoidance; this should not be a burden to IANA, which is
not expected to have the knowledge and resources to judge what is
"different purpose".

However, if it is deemed necessary, the text in Section 2.3 could be
slightly amended, e.g.:

  "This registry is primarily intended to avoid conflicting uses of the
   same extension names and keywords for different purposes, not to
   demonstrate that an extension is somehow "approved".  Applicants
   need to make sure that new command names do not conflict with the
   (current or legacy) standard opcodes listed in sections 2.4 and 2.5
   as well.  [...]"

> The text states that this column is called "FEAT Code". Should the
> paragraph be entitled "FEAT Code" rather than "Extension name" ?

No.  We have created the term "FEAT Code" to also accommodate the
corner cases described in the text, as an umbrella term for actual
(primary) FEAT keywords and 'placeholder' keywords for pre-RFC 2389
cases.  New 'placeholder' keywords are not expected or deemed useful
in the future, only actual, primary FEAT keywords.
Thus using "FEAT Code" as a *replacement* for "Extension name"
in the template could be misinterpreted as allowing/suggesting
the registration of further 'placeholder' keywords, which we do
not want to happen.

> -- Section 3, last paragraph prior to table:

Sure.  (Noticed by other parties as well.)

>
> -- IDNITS returns the following. In the case of the downref, I
> understand why it is there and do not object per se, but I wonder if
> it would not make more sense for that to be an informational reference.
> That is, it does not seem necessary to understand or implement the
> referenced document to understand or implement this one.
>
>   == Unused Reference: 'RFC2119' is defined on line 355, but no
>      explicit reference was found in the text

Mandatory-to-implement requirements have been demoted from normative
language to informal language (last paragraph above Table 1), and that
indeed now has made the reference to RFC 2119 unnecessary.  It will be
dropped, as already communicated in response to another review.

>   -- Obsolete informational reference (is this intentional?): RFC 1545

Yes, we wanted to document the history in Section 2.5.
RFC 1639, the successor of RFC 1545, is now Historical as well.
Similarly, RFC 775 was Experimental and arguably could also have
been declared as "Obsoleted by RFC 959" in the RFC index.

We leave it to IESG judgement whether RFC 2773, as a normative ref.
for the registry entry, should be listed as Normative of Informative
-- in IANA registries, there's no such distinction, hence it does not
matter actually.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Ben Campbell <[email-masked]>
Date: Sun, 22 Nov 2009 21:42:16 -0600

Thanks for the response. Comments inline:

Ben.

>   (current or legacy) standard opcodes listed in sections 2.4 and 2.5

I don't have strong feelings either way. I brought it up mostly to make sure it was thought about, and it's obvious from your response it has been.  I think the proposed update improves things a bit, but I will not complain if you choose to leave it as is.

> the registration of further 'placeholder' keywords, which we do

My point of confusion was that I was not sure what you intended the column name to be. The paragraph starts out "Extension Name--...", which I interpreted to mean the column being described was "Extension Name". But the text goes on to call the column "Feat Code", and the registration of known extensions later own shows the column as "Feat Code.".

> dropped, as already communicated in response to another review.

Yes, sorry, I saw that other response after I sent this review.

> -- in IANA registries, there's no such distinction, hence it does not

Okay, no problem

>  Alfred HÎnes.