headers
denis bider | 2 Oct 2001 16:45

availability of specifications

Folks,

this SSH2 gig looks a bit like a private party.

Why has the transport draft not been updated on the IETF website? Rather,
one has to dig through the mailing list archives to retrieve the latest
version. Is it impossible to have the folks at IETF make an exception and
accept a belated update?

Why has the whitespace formatting of the various drafts changed between
versions, making diff tools useless? To make the documents prettier, or to
confuse outsiders? I can accept that everyone has the best of intentions,
but the side effect of such decisions is confusion. Is that what a standards
body is supposed to be for?

Worst of all, why has the SFTP specification become unavailable? I try to
download
http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-01.txt, and I
get "Unrevised documents placed in the Internet-Drafts directories have a
maximum life of six months. After that time, they are deleted." There are
working SFTP implementations out there. It's supposed to be an open
standard. How can the specification just disappear? The message such
carelessness conveys is: "If you weren't with us when the SFTP specification
was still available, don't bother. We don't care for newbies." Is that what
everyone here is trying to say?

I think that, at minimum, someone should put the SFTP specification back
online.

Regards,
(Continue reading)

Permalink | Reply | 7 comments |
headers
Markus Friedl | 2 Oct 2001 16:52
Picon
Favicon

Re: availability of specifications

On Tue, Oct 02, 2001 at 04:45:33PM +0200, denis bider wrote:
> Why has the whitespace formatting of the various drafts changed between
> versions, making diff tools useless?

wdiff works fine.
Permalink | Reply | 6 comments |
headers
Markus Friedl | 2 Oct 2001 17:50
Picon
Favicon

Re: availability of specifications

On Tue, Oct 02, 2001 at 05:19:22PM +0200, denis bider wrote:
> > > Why has the whitespace formatting of the various drafts
> > > changed between versions, making diff tools useless?
> >
> > wdiff works fine.
> 
> Thanks, actually I noticed that in the archives, but I thought it was a
> reasonable argument nevertheless.

editors changed, so formatting changed. i don't buy this point.

sftp is gone because there is no editor.

> Now that I'm speaking, I think there's one other major problem with SSH2.
> With so many implementations out there, the specification should now be
> done. Over. Completed.

yes, but this is what the group is be talking about (if there would
be any traffic on the list).

> Right now, we should be working on SSH 2.1, not SSH
> 2.0. That would be the right approach, and it would solve many problems that
> we are now encountering. The way it is right now, we have a deployed
> standard and yet we're trying to hack it with improvements and new request
> types.  We're trying to have it both ways.

i don't think anyone want's to _change_ the current specification.
all we try to do is find ambiguities and fix them.

> Such behavior seems irresponsible to me.
(Continue reading)

Permalink | Reply | 1 comment |
headers
denis bider | 2 Oct 2001 18:36

RE: availability of specifications

> editors changed, so formatting changed. i don't buy this point.

I don't mind, it's not a critical point. I'm just saying it isn't nice.

> sftp is gone because there is no editor.

Is that a matter of volunteering? Well, if no one else volunteers, then I
will. Someone has to do the job. Should I apply? If yes, how do I do it?

> i don't think anyone want's to _change_ the current specification.
> all we try to do is find ambiguities and fix them.

That's alright then. While browsing the archives, I gathered the impression
that there were several proposals for changes to the existing protocol. My
impression must have been mistaken.

But how about the transport draft? Is there really no way to get the latest
version published?
Permalink | Reply | 0 comments |
headers
denis bider | 2 Oct 2001 17:19

RE: availability of specifications

> > Why has the whitespace formatting of the various drafts
> > changed between versions, making diff tools useless?
>
> wdiff works fine.

Thanks, actually I noticed that in the archives, but I thought it was a
reasonable argument nevertheless.

Now that I'm speaking, I think there's one other major problem with SSH2.
With so many implementations out there, the specification should now be
done. Over. Completed. Right now, we should be working on SSH 2.1, not SSH
2.0. That would be the right approach, and it would solve many problems that
we are now encountering. The way it is right now, we have a deployed
standard and yet we're trying to hack it with improvements and new request
types.  We're trying to have it both ways.

Such behavior seems irresponsible to me.

I don't know about you, but if it were up to me, I would be pushing to make
SSH2 official as it stands in current implementations, ASAP. The very fact
that widely deployed implementations already exist is a violation of the
standardization process. I think we need to fix that situation, not make it
worse by continuing to tinker with the 2.0 version of the protocol.

I think we need to seal version 2.0 as it is and then proceed with 2.1.
Permalink | Reply | 5 comments |
headers
RJ Atkinson | 2 Oct 2001 19:36

RE: availability of specifications

At 11:19 02/10/01, denis bider wrote:
>The very fact that widely deployed implementations already exist 
>is a violation of the standardization process. 

Denis,

        No, that is NOT a violation of the IETF standardisation process.  
If you think otherwise, please cite page, section, and paragraph 
from RFC-2026 to support your contention.

        Clearly, we need to FIX the ssh2 specs before those
specs can/should go out as any sort of RFCs.  The lack of 
co-operation from SSH Comm Sec (the company) hasn't helped
things much, so don't jump on the IETF about the delays.
Take your gripes about delays either to Finland or (better) /dev/null.

Ran
Permalink | Reply | 2 comments |
headers
Darren Moffat | 2 Oct 2001 18:46
Picon

Re: availability of specifications

>Why has the transport draft not been updated on the IETF website? Rather,

Because it missed the cut off by 5 minutes before the last IETF meeting
and I as the editor haven't yet had time to resubmit it with the changes
requested on the list.

>one has to dig through the mailing list archives to retrieve the latest
>version. Is it impossible to have the folks at IETF make an exception and
>accept a belated update?

yes it is impossible to get the IETF people to accept a submission that
hit 5 minutes after the cut off time.

People do this in their "spare" time don't complain unless you are willing
to standup be counted and do a better job.

>Why has the whitespace formatting of the various drafts changed between
>versions, making diff tools useless? To make the documents prettier, or to
>confuse outsiders? I can accept that everyone has the best of intentions,
>but the side effect of such decisions is confusion. Is that what a standards
>body is supposed to be for?

It changed because the document editor changed and I don't have the tools
available that the previous editor did so I had to spend about 10 hrs
converting them to a tool I did have, it was very very painful.

>Worst of all, why has the SFTP specification become unavailable? I try to
>download
>http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-01.txt, and I
(Continue reading)

Permalink | Reply | 6 comments |
headers
denis bider | 2 Oct 2001 21:33

RE: availability of specifications

> People do this in their "spare" time don't complain unless
> you are willing to standup be counted and do a better job.

Well, if there's anything I can do, I'm all for it. Just let me know how I
can help.

> Because it has expired and nobody cared to update it.
> IMO that is fine because I don't personally like the
> protocol anyway, this issue has been raised by my self
> and others on the list if you read the archives.

The way I see it, it is a protocol that is being used. I personally don't
have a problem with SFTP. It's certainly safer than FTP, it's more elegant
than FTP, it's implemented by a non-trivial number of products, and it
works. So, I would like to see a normative, publicly available SFTP
specification. (As opposed to a deleted one.)

> No, you seem to have a miss understanding of how the IETF works
> I suggest you go and read all the RFCs and docs on the IETF site
> about how working groups and drafts work before complaining.

> > I think that, at minimum, someone should put the SFTP
> > specification back online.

> Someone needs to take ownership of it and update the draft and
> resubmit it so it is valid for another 6months.

So, in order to get the SFTP specification back online, do I need to read
all those RFCs and docs, or is there a faster way?
(Continue reading)

Permalink | Reply | 0 comments |
headers
denis bider | 2 Oct 2001 21:48

RE: availability of specifications

> The lack of co-operation from SSH Comm Sec (the company)
> hasn't helped things much, so don't jump on the IETF about
> the delays.

Actually, big commercial vendors are who I was alluding to when I commented
that this looks like a private party. I don't know the reality of the
situation, I'm just saying what it looks like.

If the big commercial vendors care about keeping SSH2 an open protocol, I
find it strange that they let drafts such as SFTP simply disappear. It's as
if IETF doesn't really matter to them.
Permalink | Reply | 1 comment |
headers
Markus Friedl | 2 Oct 2001 21:58
Picon
Favicon

Re: availability of specifications

On Tue, Oct 02, 2001 at 09:46:00AM -0700, Darren Moffat wrote:
> >I think that, at minimum, someone should put the SFTP specification back
> >online.
> 
> Someone needs to take ownership of it and update the draft and resubmit it
> so it is valid for another 6months.

At the IETF serveral people expressed interest in SFTP but it seemed
that everyone was confused about the status of the drafts or did
not know why or that they disappeared.

who want's to work on the drafts? is there any interest?

-m
Permalink | Reply | 4 comments |

Gmane