Re: [ftpext] I-D Action: draft-ietf-ftpext2-typeu-02.txt

John C Klensin <john-ietf@jck.com> Mon, 11 July 2011 10:59 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ftpext@ietfa.amsl.com
Delivered-To: ftpext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C54C21F8B1C for <ftpext@ietfa.amsl.com>; Mon, 11 Jul 2011 03:59:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.799
X-Spam-Level:
X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpxlkaBhj0m9 for <ftpext@ietfa.amsl.com>; Mon, 11 Jul 2011 03:59:39 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 05A4821F8B1A for <ftpext@ietf.org>; Mon, 11 Jul 2011 03:59:39 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QgEDC-000PDm-7X; Mon, 11 Jul 2011 06:59:38 -0400
Date: Mon, 11 Jul 2011 06:59:37 -0400
From: John C Klensin <john-ietf@jck.com>
To: Mykyta Yevstifeyev <evnikita2@gmail.com>, ftpext@ietf.org
Message-ID: <DEC899D42D147F6752E8D553@PST.JCK.COM>
In-Reply-To: <4E1AB7BE.7020307@gmail.com>
References: <20110711050127.13929.50068.idtracker@ietfa.amsl.com> <4E1AB7BE.7020307@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: Re: [ftpext] I-D Action: draft-ietf-ftpext2-typeu-02.txt
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ftpext>, <mailto:ftpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ftpext>
List-Post: <mailto:ftpext@ietf.org>
List-Help: <mailto:ftpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jul 2011 10:59:40 -0000

--On Monday, July 11, 2011 11:43 +0300 Mykyta Yevstifeyev
<evnikita2@gmail.com> wrote:

> As I mentioned in my previous message, I have several comments
> on new IANA considerations, which follow.  The current Section
> 5 is:
> 
>> 5.  IANA Considerations
>> 
>>     When this specification is approved, IANA is requested to
>>     add an additional table to the FTP Extensions Registry
>>     established by RFC 5797 [RFC5797].  That table should be
>>     titled "TYPE command arguments" and should include "A (m)
>>     RFC 959", "E (o) RFC 959", "I (o) RFC 959", "L (o) RFC
>>     959", and "U (o) RFCNNNN".
> 
> First, this sections doesn't mention clearly what is the new
> "table".  I suppose you wanted a new sub-registry.  In this
> case it really lacks a number of information required by RFC
> 5226.  This includes: (1) what is the format of the
> sub-registry (I guess this should be "TYPE parameter",
> "conformance" and "reference").  Probably we can also create
> the separate column entitled "2nd parameter" and corresponding
> possible values "allowed/not-allowed"; (2) what is the
> addition policy for the new entries (I suppose this should be
> "IETF Consensus" or "RFC Required"; I think the 1st is
> better). (3) see also bullet 2 of Section 4.2 of RFC 5226.

Given the time, other commitments, and closeness to the
deadline, I put something there that would clearly indicate a
direction without taking the time to check 5226 or laying out a
table that would have made the intent more clear.  That
represented a tradeoff between having an updated document the WG
could discuss in Quebec if it were so inclined and missing the
posting deadline.   I probably should have inserted a note in
the draft indicating awareness of those issues but didn't think
to do so.  Sorry.  Addressed in the next draft.

> Moreover, I think creating the registry should be done by the
> separate document, whereas your one should only register the
> corresponding value in it.  This will be clearer a bit, IMO.
> Yet, I don't insist much on this particular issue.

While I understand your concern, we create registries in
protocol specs fairly frequently.   In retrospect, we should
have make explicit provision in RFC 5797 for registry tables
("subregistries" if you will) for argument values to base FTP
commands as they are extended.   It seems to me that creating a
separate document either to create this particular registry or
to establish the general principle would be mostly a waste of
time.  YMMD, but that is how I intend to proceed until / unless
the WG tells me otherwise.

Again, thanks for the close reading. 

    john