Re: [ftpext] Followup on FTPEXT2 BOF in Maastricht

[Anthony Bryan <[e-mail]>]

On Thu, Sep 9, 2010 at 5:13 AM, Alexey Melnikov
<[e-mail]> wrote:
> Hi Anthony,
>
> Anthony Bryan wrote:
>
>> On Wed, Sep 8, 2010 at 4:05 AM, Alexey Melnikov
>> <[e-mail]> wrote:
>>
>>>
>>> 2). Propose and agree on WG charter on the mailing list.
>>
>> thanks, Alexey. I agree we need more participants, and I will continue
>> to invite relevant people.
>>
>> I've never worked on an IETF charter, but here's what I had, borrowing
>> from other charters and the BOF proposal.
>>
> Thanks for proposing an initial version. Some quick feedback with my Area
> Director hat on.

thanks! is there more info on charters/WGs/rechartering somewhere?

>> because of the maturity of HOST, I would say it deserves an
>> accelerated schedule.
>>
>> FTP Extensions, 2nd edition (ftpext2) Charter
>>
>> Description of Working Group:
>>
>> The Standard File Transfer Protocol specification in RFC 959
>> has been updated several times with command extensions of one
>> sort or another, including those based on the extension
>> mechanism of RFCs 2389 (a complete list appears in RFC 5797 and
>> the corresponding IANA registry at
>>
>> http://www.iana.org/assignments/ftp-commands-extensions/ftp-commands-extensions.xhtml
>> ).
>>
>> The following are active FTP related drafts:
>>
>>   draft-bryan-ftp-hash
>>   draft-hethmon-mcmurray-ftp-hosts (completed IETF Last Call in May)
>>   draft-ietf-behave-ftp64
>>   draft-preston-ftpext-deflate
>>
>> The Working Group will:
>> * Review and finalize already mature drafts that are close to
>>  completion.
>> * Continue work on other drafts that are already in progress.
>> * Identify additional areas of FTP that need extending, such as
>>  unofficial FTP commands that need documentation or new commands.
>>
>
> In general IESG doesn't like openended charters ("we will work on anything
> that has FTP in its name"). It is much better to have a specific set of
> deliverables (especially for a new WG, with no prior history of successful
> completion of any work), and recharter later to take on additional
> documents. Rechartering is a much easier process, especially if a WG has
> some proof that it is making progress.

makes sense.

>> * Review and confirm or reject errata of current FTP RFCs.
>>
>
> This one is fine. I actually like that.

thanks. I think it's important. as you've seen I've filed about 5 and
had 1 verified so far. and there are others unverified.

>> * Discuss the differences between FTP in theory (current RFCs)
>>  and practice.
>>
> This sounds a bit openended as well. Is this item trying to motivate future
> work? So maybe "Investigate the differences between FTP in theory (current
> RFCs) and practice, and recommend future work to align them"?

that sounds great.

>> The Working Group's specification deliverables are:
>> * A document that specifies the HOST command (Proposed Standard).
>> * A document that specifies the HASH command (Proposed Standard).
>>
>> The Working Group must not introduce a new version of FTP, e.g.
>> an incompatible FTP 2.0.
>>
>> The following issues are specifically omitted from the working group's
>> charter, but may be added by the Area Directors if time permits,
>> once the above goals have been acheived.
>>
> Area Directors typically don't do that. I can provide more feedback (for
> example if you list too many documents), but it is ultimately up to the
> group to decide what to work on and in which order.

Ok, that was taken from the original ftpext charter.

how else can I list something like that as a possibility, from
discussions so far, but not as a definite deliverable? is
"...recommend future work to align them." enough? or just wait &
recharter?

Mark noticed that I accidentally forgot to list his draft. please
speak up if I'm missing anything else.

you'll also see that I only list HOST/HASH as deliverables/goals. this
is only because I'm most familiar w/ these, and they seem to have the
most consensus, from my biased POV as author of one :) again, speak up
if you think someone else is not included that should be.

here is my 2nd stab at the charter:


FTP Extensions, 2nd edition (ftpext2) Charter

Description of Working Group:

The Standard File Transfer Protocol specification in RFC 959
has been updated several times with command extensions of one
sort or another, including those based on the extension
mechanism of RFCs 2389 (a complete list appears in RFC 5797 and
the corresponding IANA registry at
http://www.iana.org/assignments/ftp-commands-extensions/ftp-commands-extensions.xhtml
).

The following are active FTP related drafts:

    draft-bryan-ftp-hash
    draft-hethmon-mcmurray-ftp-hosts (completed IETF Last Call in May)
    draft-ietf-behave-ftp64 (behave WG)
    draft-peterson-streamlined-ftp-command-extensions
    draft-preston-ftpext-deflate

The Working Group will:
* Review and finalize already mature drafts that are close to
  completion.
* Continue work on other drafts that are already in progress.
* Review and confirm or reject errata of current FTP RFCs.
* Investigate the differences between FTP in theory
  (current RFCs) and practice, and recommend future work to align them.

The Working Group's specification deliverables are:
* A document that specifies the HOST command (Proposed Standard).
* A document that specifies the HASH command (Proposed Standard).

The Working Group must not introduce a new version of FTP, e.g.
an incompatible FTP 2.0.

Goals and Milestones
Sep 2010    Submit 'File Transfer Protocol HOST Command for Virtual
Hosts' as working group item (draft-hethmon-mcmurray-ftp-hosts will be
used as a starting point)
Sep 2010    Submit 'File Transfer Protocol HASH Command for
Cryptographic Hashes' as working group item (draft-bryan-ftp-hash will
be used as a starting point)
XXX 2010    Working group Last Call of HOST document
XXX 2010    Submit 'File Transfer Protocol HOST Command for Virtual
Hosts' to the IESG for consideration as a Proposed Standard
XXX 2010    Working group Last Call of HASH document
XXX 2010    Submit 'File Transfer Protocol HASH Command for
Cryptographic Hashes' to the IESG for consideration as a Proposed
Standard
XXX 2011    Close or recharter


-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads