Re: [ftpext] WG Status (was: Re: Fwd: Re: ftpext2 review of FTP HOST command?)

[Anthony Bryan <[e-mail]>]

On Tue, Mar 13, 2012 at 10:10 AM, John C Klensin <[e-mail]> wrote:
>
>
> --On Tuesday, March 13, 2012 08:32 +0100 Daniel Stenberg
> <[e-mail]> wrote:
>
>>> If the answer to some or all of the above is "no", should
>>> people really  spend time reviewing this document or should
>>> we be thinking about concluding  that FTP's detractors are
>>> correct about level of interest and hence give up  on this
>>> effort?
>>
>> I'm sorry to agree: this is not a very functional WG. To me,
>> it looks like there's not enough interest from implementors to
>> update FTP.
>
> Let me say something slightly more optimistic than the above,
> even though I don't think it helps the WG very much.  I think we
> have several implementers out there, each with a client/customer
> base.  While those clusters of customers probably overlap enough
> in their properties and needs to be different from a
> niche-per-implementer/ vendor, they are different.  The result
> is that vendor X wants extensions A, B, and C (which they may
> have developed, implemented, and deployed in some form).  Vendor
> Y wants extensions D, E, and C', where C' is functionally more
> or less like C but not identical.  Maybe we could get them
> together to work on a common C-approximation (although there
> hasn't been evidence of that so far).  But X sees no commercial
> value in working on, or even reviewing D or E and Y sees no
> commercial value in working on A or B.

perhaps I'm misunderstanding, but what are C & C'?

HASH vs the many hash like commands (XCRC, XMD5, XSHA, etc)?

> Worse from our point of view, X's main interest, as a server
> vendor, in bringing A and B to the IETF is to get them
> standardized so they can beat up client vendors who haven't
> implemented what would otherwise be a perfectly good proprietary
> feature.  That not only gives them no incentive to invest energy
> on D or E, it gives them significant incentive to push back on
> any changes to their already-implemented versions of A and B
> (using "running code" as an excuse).

I (& my co-authors) are the only ones who have proposed more than one
command (HASH, RANG, LOCK) to be standardized.

we are all independent AFAIK but work on our own implementations
(curl, aria2, FileZilla).

if you're talking about HOST, it was created by Bero in the open
source realm quite some time ago.
it appears to first be specified in 1998, in the ID that became RFC
3659: http://tools.ietf.org/html/draft-ietf-ftpext-mlst-05

if you mean, as far as a person from Microsoft investing time to
standardize/finalize it, isn't that a good thing to be done at the
IETF out in the open than "beat[ing] up client vendors" with something
proprietary that is only known internally & documented in a .doc file?
:) [no offense I have no idea how things work there.]

> I think (Anthony can correct me if needed) we can understand the
> target audience for HOST in that context.  While it is one that
> might occasionally require strong user authentication (including
> the usual cryptographic isolation of the relevant information
> and/or handshaking), and might require integrity protection of
> the data stream (and that is where draft-ietf-ftpext2-hash comes
> in) it would rarely require privacy protection.  I say
> "occasionally" because there would be many cases where the
> approach would be used anonymously or with a minimum of
> identification (just like "normal" FTP).   In that sense, the
> model is very similar to web pages that are accessed to retrieve
> information rather that, e.g., to carry out transactions that
> might require authentication and/or transmission of sensitive
> information.
>
> If that is the model, then the proposal in this spec is
> reasonable and most of the concern about TLS, especially TLS
> with strong certificate-based protection, is largely irrelevant.
> However, that view raises the obvious and usual questions:
>
>        (1) Will (and should) the IETF accept a proposal with
>        known security weaknesses if the author says "just don't
>        use it in contexts requiring strong data privacy
>        protection".
>
>        (ii) Are the WG and the IETF willing to accept an FTP
>        Extension spec that doesn't play well with extant
>        extensions?  The charter is remarkably silent on that
>        matter.
>
>        (iii) What value can/does the IETF add in this type of
>        limited scenario case?
>
>        (iv) Why doesn't the specification describe the usage
>        scenarios clearly enough that it can clearly exclude
>        those cases that require strong security?
>
> Pragmatically, what this all amounts to, IMO, is "draft needs
> work".  And the evidence remains that the WG doesn't have
> whatever it takes to get that work done.

I agree the draft needs work, but do you think it needs more than
these last reviews (& hopefully a later AppsDir & SecDir review) can
provide.

granted obviously the WG has been at death's door, but we should still
have the mailing list if it gets closed.

> p.s. On looking at the charter, I discovered that one of the
> things the WG committed to do was
>
>        "* Review and confirm or reject errata of current FTP
>        RFCs"
>
> Circa 18 months after we got serious about chartering the group
> (longer than that if one uses other criteria), that task hasn't
> been started.  Another entry in the "not a good sign" list, IMO.

I see that an errata discussion started in July 2010.

some were filed in 2010 against RFC 959 & 3659 by a quick look, & we
should follow up that thread. most were marked "held for document
update"

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