Re: Gen-ART LC review of draft-klensin-ftp-registry-02

[Ben Campbell <[e-mail]>]

Thanks for the response. Comments inline:

Ben.


On Nov 22, 2009, at 3:55 PM, Alfred HÎnes wrote:

> Ben,
> thanks for your GenART review.
> Please see my responses inline.
> 
> 
> Ben Campbell wrote:
> 
>> 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?
> 
> 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.  [...]"

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.

> 
> 
>> 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" ?
> 
> 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.

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.".



> 
> 
>> -- Section 3, last paragraph prior to table:
>> 
>> s/marke/marked
> 
> 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.

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

> 
>> 
>>  ** Downref: Normative reference to an Experimental RFC: RFC 2773
>> 
>>  -- Obsolete informational reference (is this intentional?): RFC 1545
>>     (Obsoleted by RFC 1639)
> 
> 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.

Okay, no problem

> 
> 
> Kind regards,
>  Alfred HÎnes.
> 
> -- 
> 
> +------------------------+--------------------------------------------+
> | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
> | Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
> | D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
> +------------------------+--------------------------------------------+
>