Subject: [saag] errata in draft-ietf-secsh-filexfer-02.txt

From: Logan <[email-masked]>
Date: Sat, 5 Jan 2013 00:30:05 +0400

Dear All,

I'm currently working on resume support for sftp. 

My patch is available here:

https://bugzilla.mindrot.org/show_bug.cgi?id=2021

Damien Miller raised an issue with section 6.1.

Quote:
  The protocol and implementations MUST process requests relating to
   the same file in the order in which they are received.  In other
   words, if an application submits multiple requests to the server, the
   results in the responses will be the same as if it had sent the
   requests one at a time and waited for the response in each case.  For
   example, the server may process non-overlapping read/write requests
   to the same file in parallel, but overlapping reads and writes cannot
   be reordered or parallelized.  However, there are no ordering
   restrictions on the server for processing requests from two different
   file transfer connections.  The server may interleave and parallelize
   them at will.

   There are no restrictions on the order in which responses to
   outstanding requests are delivered to the client, except that the
   server must ensure fairness in the sense that processing of no
   request will be indefinitely delayed even if the client is sending
   other requests so that there are multiple outstanding requests all
   the time.

The first paragraph suggests banning re-ordering whereas the second paragraph
suggests that no restrictions should be made on the order.

This can lead to implementation issues as damien outlined:
We've considered doing this in the past but was worried about the wording in section 6.1 of http://www.openssh.com/txt/draft-ietf-secsh-filexfer-02.txt allowing the server to reorder the responses from the block transfers in such a way that the client got a wrong idea of the high water mark.
Also, secsh-filexter-02 is the most widely implemented sftp spec, despite not being an rfc.

Openssh, dropbear and filezilla base their implementation in version 02.

However, the secsh wg is marked as concluded, and attempts made at contacting the authors have not
been successful.

Please advise.

Kind regards,
//Logan
C-x-C-c
-
----------------------------------------------------------------------------------------------------
Please join us at the Africa Internet Summit, Lusaka, Zambia, 9 ? 21
June 2013
-
----------------------------------------------------------------------------------------------------

---

From: Mouse <[email-masked]>
Date: Fri, 4 Jan 2013 21:47:59 -0500 (EST)

> I'm currently working on resume support for sftp.

For what it's worth, I'd suggest the ssh list ([email-masked]) for
such discussions.

>    the same file in the order in which they are received.  [...]

>    server must ensure [no over-busy starvation]

> The first paragraph suggests banning re-ordering whereas the second
> paragraph suggests that no restrictions should be made on the order.

Read them carefully.  The first paragraph says that _processing_ must
be done in order.  The second says that _reply delivery_ may occur out
of order.  (Requests bear IDs which allow clients to match up replies
with requests.  This is not sufficient for arbitrary backlogs, but it
is capable of handling outstanding request counts up to a bit over 4
billion.)

If you want to change anything here, I would suggest just emphasizing
that difference, to prevent other people from being confused the way
you were.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B