RE: iSCSI: statement on mandatory/optional

[Black_David@emc.com]

While I agree with the intent of the proposed explanatory
text, I don't thing the wording is a good idea.  To start
with, the appropriate words to express levels of requirements
are MUST, SHOULD, MAY, MUST NOT, SHOULD NOT, and their
synonyms as defined in RFC 2119.  The usual practice is
to have the RFC-2119 words that express the level of
requirement be located near the description of the
feature and/or behavior that is required - this simplifies
things for the reader.   A summary at the end of a
section or subsection may be a useful way to structure
things to ensure that nothing's been missed.

As a result, the following text is not needed: 

>   - All the features that are specified in this draft are
>     mandatory to implement and mandatory to use, unless otherwise
>     stated.

The rest of the proposed text appears to be about
negotiation (implicit or explicit).

>   - Features that are identified as "mandatory to implement
>     but optional to use" (like the digests) MUST be implemented
>     and MUST be honored by one side when the other side uses
>     them (as in a PDU type), or wants to use them (as in negotiation).

The right thing to do here is for each such feature,
spell out exactly what the REQUIRED (MUST) or RECOMMENDED
(SHOULD) behavior is.  The PDU type is easy - one side
just sends it and since support for it is REQUIRED, the
other side has to do what the specification REQUIRES.
For negotiation, the behavior would need to be spelled
out in the appropriate place (probably with the feature
description, and possibly also with the text tag description).
What Mallikarjun proposes above uses negotiation as an
announcement mechanism (one side uses negotiation only
to tell the other side "I'm doing <X>").  That's definitely
an acceptable possibility, but may not be appropriate in
all cases.

>   - Features that are identified as "optional to implement" 
>     (like the synch and steering layer) imply that implementations
>     that support the features MUST interoperate with other 
>     implementations that do not support these features (i.e.
>     implementations are guaranteed to be interoperable regardless
>     of the feature support).

Again this principle is generally implicit in the IETF dictum
of "be conservative in what you send, liberal in what you
accept".  For features where this matters (there's risk of
a receiver being confused by a sender making a different
implementation choice), one possibility is to make support
OPTIONAL for the sender and REQUIRED by the receiver (which is
the previous case), another is to make it negotiable and
REQUIRE support for "not implemented" as well as the behavior
behavior to negotiate it.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


> -----Original Message-----
> From: 	Mallikarjun C. [mailto:cbm@rose.hp.com] 
> Sent:	Thursday, June 07, 2001 1:44 PM
> To:	ips@ece.cmu.edu
> Subject:	iSCSI: statement on mandatory/optional
> 
> Julian,
> 
> I suggest the following explanatory text to be added to
> the iSCSI main draft (possibly as section 1.2.1).  I really
> think this (in an abstract sense) helps readers to understand 
> the optionality or otherwise of iSCSI features.
> 
> Mandatory and optional features
> 
>   - All the features that are specified in this draft are
>     mandatory to implement and mandatory to use, unless otherwise
>     stated.
>   - Features that are identified as "mandatory to implement
>     but optional to use" (like the digests) MUST be implemented
>     and MUST be honored by one side when the other side uses
>     them (as in a PDU type), or wants to use them (as in negotiation).
>   - Features that are identified as "optional to implement" 
>     (like the synch and steering layer) imply that implementations
>     that support the features MUST interoperate with other 
>     implementations that do not support these features (i.e.
>     implementations are guaranteed to be interoperable regardless
>     of the feature support).
> 
> Regards.
> --
> Mallikarjun 
> 
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668	Hewlett-Packard, Roseville.
> cbm@rose.hp.com
>