RE: iSCSI: statement on mandatory/optional

[Black_David@emc.com]

Mallikarjun,

I think we're in basic agreement.

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

Yes -- a general piece of advice is to use the
terms defined in RFC 2119, and use them in places
close enough to the specification of the features
that someone looking for the feature is unlikely to
miss the corresponding requirement statement(s).
Summaries by section are fine if they improve
clarity/readability/accessibility of the document.

> 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 don't think so, because the shift from "initiator/target"
to "sender/receiver" terminology implies that the digests
are separately negotiated in each direction which is not
the current state of things.  Going back to the former
terminology is better:

	Targets are REQUIRED to support digests and
	initiators MAY use digests.

although it needs some additional text describing the
negotiation - if the Initiator sends a Digest key
indicating that presence of the digest is the only
acceptable alternative (i.e., "none" is not offered),
the Target MUST accept this, and then in full-feature
phase, both the Initiator and Target MUST generate and
check the negotiated digest in both directions.

Note that this is weaker than one of the possible
intentions of the -06 text, namely that either side can
require through negotiation that digests be used,
in which case different language is needed.

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

In general, I think that if feature <X> is OPTIONAL,
correct (inter-)operation in the absence of <X> is REQUIRED,
but spelling that out for clarity doesn't hurt.

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