Subject: iSCSI: statement on mandatory/optional

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 07 Jun 2001 11:44:10 PDT

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.
[email-masked]

---

From: "Robert Griswold" <[email-masked]>
Date: Thu, 7 Jun 2001 14:46:15 -0500

Mallikarjun:

I agree with your suggestion in concept, leaving it to those with the
IETF experience to draw up the words, if yours don't work.  Given the
cross-over technology that this represents for engineers used to one
style of standards wording, this kind of a paragraph would help with the
interpretation issues.  Good suggestion.

Bob

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

 -----Original Message-----
From: 	Mallikarjun C. [mailto:[email-masked]] 
Sent:	Thursday, June 07, 2001 1:44 PM
To:	[email-masked]
Subject:	iSCSI: statement on mandatory/optional

Julian,

Regards.
--
Mallikarjun 

Mallikarjun Chadalapaka

---

From: [email-masked]
Date: Mon, 11 Jun 2001 18:58:43 -0400

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.

>     mandatory to implement and mandatory to use, unless otherwise

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

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

>     implementations are guaranteed to be interoperable regardless

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
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 12 Jun 2001 21:21:46 PDT

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. 

>an acceptable possibility, but may not be appropriate in

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

---

From: [email-masked]
Date: Wed, 13 Jun 2001 15:09:56 -0400

Mallikarjun,

I think we're in basic agreement.

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

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

> 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