Hello,

	Overall, I am very impressed by the GridFTPv2 document, and look
forward to its adoption and implementation. It describes a well-thought out set
of extensions. I do find the language of the document at times unclear, which
is the basis for most of my comments.

Thanks,
Rob Kennedy
dCache/SRM Project Leader
Fermi National Accelerator Laboratory
03 April 2005

------------------

Page 2 - Language. *--* marks words I would add to fix the grammar, and make
minimal change to the text meaning as far as I can tell.

	*The* GridFTP protocol has become *a* popular data movement tool used
	to build distributed grid-oriented applications. *The* GridFTP protocol
	extends *the* FTP protocol defined by RFC959 [rfc959] and other IETF
	documents by adding certain features designed to improve *the*
	performance of data movement over *a* wide area network, to allow the
	application to take advantage of "long fat" communication channels,
	*and* to help build distributed data handling applications.

	Several groups have developed independent implementations of *the*
	GridFTP v1 [gftp] protocol for different applications. The experience
	gained by these groups uncovered several drawbacks of *the* GridFTP v1
	protocol. They are summarized in *a* GGF draft [gftp-impr]. This
	document proposes modifications of the protocol which are supposed to
	address *the* majority of *the* issues found.

The text needs proofreading for language usage. Skipping further language
issues...

Page 4 - "Data Block Format"

	"Transaction ID is used to hold" -what-? Used as a place holder? Used
	to hold some state value?

	"The only difference..." but you are listing two new fields. Perhaps it
	would be clearer here if you stated: something like
	
	+ Transaction id  - A place holder for future use (?)
	+ Checksum value  - If data integrity checking is turned on...

page 5 - "Sender will close data channel instead of re-using it (?)"

The (?) is in the document. This should be resolved one way or the other.

page 7 - I understand how the data channel can be used for bi-directional
communications for orderly transition messages like READY, EOD, and BYE, as
well as signaled events like a connection closing unexpectedly. Is the sender
expected to check for messages from the receiver in between the sending of each
data BLOCK? Is this assumed because it is obvious from past practice or should
it be stated that the sender is expected to do so, at least as a best practice?
The same can be said for RESEND.

page 8 - Figure 4: is a EOD message missing from the figure?

page 9 - Figure 4 label is repeated. Should be Figure 5?

	I do not see how Figure 5 adds to the document as it is. Perhaps a
3-step time series of the same kind of diagram showing "before", "network
resource changes" (may-be a new pathway becomes available or one goes down),
"after reaction" to demonstrate how dynamic management can be utilized to
maximize throughput.

page 10 - It seems a BYE has to be sent by the receiver, but is optionally
received by the sender. Suppose I have a very "anti-social" sender who never
waits for a BYE, and a receiver who is slow but polite and sends it eventually.
In this case, the receiver could get a SIGWRITE at the end of each transfer,
which seems a bit unwieldy. One expects a SIGWRITE to indicate a real problem,
a dropped connection, and (since its just the receiver) a protocol error. But
it is not. So, my receiver would have to catch SIGWRITE with a "real-error"
signal handler for READY, but switch to an "do-nothing" signal handler for BYE.
Is this common practice?

page 11 - Here is says that the sender must not close the data channel until it
receives a "BYE" command, which makes more sense to me. So, what did it mean on
page 10 that the "active sender can close any data channel ... and optionally
receiving "BYE" as the acknowledgement"?

page 14 - "file upload"? I presume this means client sends file to server?

page 15 - SCKS: it may be cleaner to keep the text...