ietf
[Top] [All Lists]

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

2009-11-22 22:44:30
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: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah(_at_)TR-Sys(_dot_)de                  
   |
+------------------------+--------------------------------------------+


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>