Re: Comments on v12 of iSCSI Specification

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Fri, 3 May 2002, BARRY,BOB (HP-Roseville,ex1) wrote:

> The following comments are submitted against the April 17, 2002,
> draft-ietf-ips-iSCSI-12.txt.

Wow. That's a lot of input. :-)

Commenting on the ones I have input on.

> Bob Barry
> ====================================================
>
> General Comments
>    1)	An acronym section would make it easier to read
> 	this document.  Acronyms such as SW for session
> 	wide, IO for initialize-only, and others are not
> 	immediately obvious.

Agreed.

>    2)	A copyright notice be part of this document.

There is one, on page 260.

>    3)	In chapter 9, each PDU should have a complete
> 	description provided.  Yes, this means a duplication
> 	of the field descriptions, but having to search back
> 	in the document to find field meanings does not
> 	make sense.

Also, I think some PDUs (R2T for example) list DataSegmentLengths when the
PDU won't have a data segment. Other PDUs that lack data segments list
bytes 5 through 7 as reserved.

Additionally, some PDU examples helpfully show the data coming after the
PDU. Others show the digests (if any), then the data. Both of these usages
are not consistent with the usage shown on page 119 at the top of the page
(tail end of section 9.2); they don't show the AHS, nor the data digests.

I realize that AHSs don't always make sense, but if we're going to have an
AHSlength in a PDU, and we show more than just the PDU, shouldn't we show
the optional AHS?

>    5)	Either "data is" or "data are" are considered correct
> 	for technical documentation, however, only one should
> 	be used in a document for consistency.  Examples:
> 	  p 35: last paragraph, first line          "data is"
> 	  p 36: third paragraph, first line         "data are"
> 	  p 36: third paragraph, third line        "data are"
> 	  p 36: seventh paragraph, fourth line  "data is"

Agreed. I also vote for using "data are" since data originated as the
plural of datum. :-)

>    6)	The word "null" is used throughout this document to
> 	mean "zero", or "zero valued".  This needs to be
> 	clearly stated.

Also, when we are talking about the zero-character at the end of
login/text messages, could we please refer to it as NUL, which is the
correct ASCII name for it. Yes, I realize they are UTF-8, not ASCII, but
"null" is sloppy in this regard.

> Comments regarding draft contents

>   11)	p 63: third paragraph of 4.1, last line: "(comma or
> 	null)" should be "(comma or zero byte)"

zero byte would work too.

Take care,

Bill