Re: iSCSI reserved bits and fields

["John Hufferd" <hufferd@us.ibm.com>]

I am sending a response to my note, to Paul Koning, onto the list, since I
failed to send my note there to begin with.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com
---------------------- Forwarded by John Hufferd/San Jose/IBM on 11/13/2001
08:39 AM ---------------------------

Paul Koning <ni1d@arrl.net> on 11/13/2001 06:56:47 AM

To:   John Hufferd/San Jose/IBM@IBMUS
cc:
Subject:  Re: iSCSI reserved bits and fields



Excerpt of message (sent 12 November 2001) by John Hufferd:
>
> Paul,
> The reason for the wording was to permit unique vendor versions to be
> produced before things are made standard or for vendors to add key value
> (at their own risk until they get standardized.

Good point, but such implementations are operating outside the
standard, so the rules of the standard don't apply then.

> I understood what you meant however, the must on the sender would
normally
> require the target to check.

Not at all, and that's exactly what I did NOT intend.  Sender behavior
and receiver behavior are a separate matter.  As a principle of
design, receivers should check *only* what is necessary for correct
results (i.e., for interoperability -- or sometimes other
considerations, for example security protocols tend to check more
because of a need to detect attacks).

> Perhaps a compromise is a "MUST leave zero" on the sending side and "MUST
> not check" on the target side. This would overtly tell implementers that
> they are NOT a valid iSCSI implementation, but not cause things to break
in
> early implementations of features not yet standardized.

That is exactly what I meant to propose; apparently I did not make it
clear enough.

> However, I really think the "SHOULD leave zero" on the Initiator side and
> "MUST not check" on the target side, is sufficient.  This is how folks
have
> generally built (at their own risk) new features.  It is not clear we
would
> have the Jumbo Frames Features, on any products if this type of wordage
was
> not operative.

I'm not sure about the jumbo frame example.  In any case, I'll accept
"should" though I'd prefer the "compromise" wording you gave.

By the way, did you mean to send your note to the list?  It seems that
you did not.

    paul