Re: Reserved field definitions

["Julian Satran" <Julian_Satran@il.ibm.com>]

Robert,

I iSCSI the reserved fiels are generally said to be 0 except in the very
few cases in which we use a "reserved value" to indicate that the field has
an invalid value and the value 0 is a (convenient) valid value. The tags
fall in this category - Initiators may use for tags
some simple derivative of a control-block-address and so do targets and
reserving 0 was felt to be prohibitive.

As for checking the reserved fields for the reserved value the draft
refrains from asking this.

As for some specifics - coments are inserted in text.

Julo

"Robert Griswold" <rgriswold@Crossroads.com>@ece.cmu.edu on 08-08-2001
21:34:55

Please respond to "Robert Griswold" <rgriswold@Crossroads.com>

Sent by:  owner-ips@ece.cmu.edu


To:   Julian Satran/Haifa/IBM@IBMIL
cc:   <ips@ece.cmu.edu>
Subject:  Reserved field definitions



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?

+++You must have been confused by the B - it means bit. The first 2 bits
have special meaning while the rest are a coded field with 64 value+++

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).

+++There is a general requirement sated in the last statement before 2.1
that reads:
Any bits not defined MUST be set to zero. Any reserved fields and values
MUST be 0 unless specified otherwise.
++++
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.

+++ I doubt that somebody would really think so but if you mean to suggest
another wording please do so +++
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).
+++ all requirements for 0 are covered y the general statement +++
Thanks,
Bob

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