RE: iSCSI: statement on mandatory/optional

["Mallikarjun C." <cbm@rose.hp.com>]

David,

I admit that I could be off on what's the right IETF language.

In general, you suggest that the level of requirement specification
should be at least at the section level - than at the beginning 
of the document.  I am okay with that. 

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

I am not sure what exactly is meant here.  Negotiation is a process 
of announcing capabilities, and settling on what's acceptable to both....
Would the following wording express what I wanted better, say for 
digests?

  Receivers are REQUIRED to support digests and senders MAY use 
  digests. 

than the current 
  "and MUST be implemented by every iSCSI initiator and target." in rev06.

I agree with your suggestion to use REQUIRED for "not implemented"
and the negotiation itself where appropriate - this also implies to me 
that the "base" functionality support is not necessarily REQUIRED when 
an implementation supports a feature defined as OPTIONAL.  

If this is true, I suggest to Julian that language be added for synch 
and steering to make the no sync-and-steering mode REQUIRED, in addition 
to stating that synch and steering is OPTIONAL.
--
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.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
>> 
>