Reserved field definitions

["Robert Griswold" <rgriswold@Crossroads.com>]

Julian:

In review the use of Reserved fields in the iSCSI draft, there seem to
be some inconsistencies through the document, and the assumptions of
their use appear to be in conflict with SAM-2.  First, two quotes from
07 and SAM-2:

"2. iSCSI PDU Formats 
...  Any bits not defined MUST be set to zero. Any reserved fields and
values MUST be 0 unless specified otherwise. "

"3.3.8 reserved: A keyword referring to bits, bytes, words, fields and
code values that are set aside for future standardization. Their use and
interpretation may be specified by future extensions to this or other
standards. A reserved bit, byte, word or field shall be set to zero, or
in accordance with a future extension to this standard. Recipients are
not required to check reserved bits, bytes, words or fields for zero
values.  Receipt of reserved code values in defined fields shall be
reported as an error."

It appears that there are some conflicts with the usage of the
definition of reserved in the iSCSI document and the definitions coming
from T10, specifically how to handle garbage in reserved fields.  I
would suggest that a PDU format error in iSCSI is actually a PDU
received that has errors in any defined fields, but does not require a
reject if inconsistencies are found in reserved fields.  Also, the fact
that some reserved fields require zeros, while others require ones seems
odd, and will probably lead to more incompatibilities than the value of
having dissimilar reserved field use provides.  If there is previous art
that forces this difference than let's call that use of the field for
what it is, versus calling it reserved.  My understanding of TCP network
protocols is very weak, though, and there could be a really good reason
why this mapping is happening, so please whack me with the stupid stick
if necessary.

The following are cases where 07 has lapses in the use of reserved
fields:

Page 44, under AHSType, bits 0 and 3-59 are declared Reserved, but not
"must be 0".  But also strangely here, it seems that AHSType is an
eight-bit field, that has 64-bits worth of explanation.  Am I reading
something wrong here?

Page 45, byte 2 of word 0 of op-code 0x01 is declared Reserved, but no
requirement for zeros (aside from the directive in Section 2).

Page 49, bits 5 and 6 of Flags are declared as Reserved, but no
requirement for zeros.  Also, bit 7 is not even declared even though the
table above (pg 48) shows bit 7 as a 1.  Does this mean bit 7 falls into
the odd category of a reserved field that must be 1?

Page 49, bits 80-ff of Response are declared as "Reserved" for
Vendor-unique responses.  Now most developers would interpret this
correctly, but the use of the word reserved here could lead some into
thinking only 0's are allowed, or must be checked for 0's.

Page 51, both 2.4.7 and 2.4.8 declare that if the S field is 0, then the
two mentioned fields are reserved, but no requirement for zeros (aside
from the directive in Section 2).

Page 53, the definition of Reference Task Tag or Reserved shows that a
reserved (even though specified) field need not be 0 (aside from the
directive in Section 2).

Page 80, bytes 0 and 1 of word 8 show CID or Reserved, but no
requirement for zeros (aside from the directive in Section 2).

Page 84, definition of Bit S, says 'otherwise, it is reserved,' but no
requirement for zeros (aside from the directive in Section 2).

Thanks,
Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272