iSCSI Requirements -03 comments

[Black_David@emc.com]

One more set of comments from me.  I wrote these on
a plane yesterday -- with luck I didn't miss anything
crucial, but plead effects of altitude for oversights
and mistakes herein.

-- Conventions used in this document

Add a sentence indicating that use
of RFC 2119 terms in this informational document reflects requirements
for the protocol specification rather than the usual use of RFC 2119
terms to indicate requirements on implementations.

-- Section 1 - Summary

>From 2.2

"improve on the state of the art for SCSI interconnects" - not clear what
this
	means for the protocol, Gbit Ethernet has performance limits by
comparison
	to the forthcoming 2 Gbit Fibre Channel.

"cost competitive with alternative storage networking technologies" is also
	hard to do in a protocol specification alone.

--> For these two, and any other requirements over which we really don't
have
	complete control (in contrast to technical requirements), use lower
case
	"must", etc. to avoid invoking RFC-2119.

>From 2.4

Modify FIFO transport to allow error conditions to violate FIFO - if
violations
are possible, then MUST be able to configure enforcement of ordering in
presence
of error conditions.  Take text for this from previous discussion on list to
resolve Santosh Rao's comment on this issue.

>From 4.1

I agree with Bob Snively's comment to delete extensibility to other data
integrity
digest formats.  In practice, this is going to require a revision to the
basic protocol specification document and is not to be done lightly.  It'd
be ok
to require a protocol version number to help support this sort of future
change.

>From 5.2

Leave SAM2 completeness text as is.  Features that T10 wants deleted are
cases in
which the "SHOULD" in "SHOULD make such a feature either RECOMMENDED or
REQUIRED
in implementations" is overruled (i.e., we have carefully weighed the
implications
and done something different).

Delete "SHOULD track changes to SCSI and SAM"  Once the RFC is done, it's
done -
it can be subsequently revised.  Replace it with something about
specification
development - the IPS WG SHOULD track such changes to make sure that
the RFC is based on the most current state of SCSI and SAM.

>From 6.3

"SHOULD NOT preclude ..." is backwards.  The requirement to pass muster with
the IESG is "MUST specify and REQUIRE the implementation of ..."

>From 7.1

Make it clear that "(URL)" is an example.

"existing naming authorities" - "authorities" is the wrong word,
"approaches" is
	one alternate possibility.

"SHOULD deal with the complications of the new SCSI security architecture."
-
Rephrase/rewrite to avoid "deal with the complications".  I think this
is about access controls, and hence might be phrased in terms of ensuring
that support is provided for them.

-- Section 2.1

   In the 
   local area, TCP's adaptive retransmission timers provide for 
   automatic and rapid error detection and recovery.

Delete the words "adaptive" and "timers".

In step (6) of deployment, change "SAN" to "storage".

   might also support all host protocols that use TCP (NFS, CIFS, HTTP,
etc).

Replace "all" with "other".

(IPSWG) --> (IPS WG)

-- Section 2.2

See above comment on removing upper case from requirements not completely
within our
control.

    Conventional storage access is of a stop-and-wait 

Replace "of" with "often".

Direct data placement - pick up Bob Snively's rewrite.

-- Section 2.3

Framing discussion needs to indicate that framing MUST be OPTIONAL to
implement.
Add a sentence indicating "SHOULD specify a default framing mechanism"
(i.e.,
specify the first framing mechanism that MUST be implemented *if* any
mechanism
is implemented).  This should be responsive to some of Doug Otis's concerns
about framing mechanism consistency, but I absolutely, positively will not
allow
any document to REQUIRE a common framing mechanism between iSCSI and other
protocols for procedural reasons discussed previously on the list.

-- Section 2.4

Delete the paragraph starting with "In the presence of connection binding,
there are two ways to assign features to connections" and the paragraph
starting with "An alternate approach that was discussed extensively ..."
Recording of WG discussions and rationale for design decisions is better
placed in protocol specification documents rather than requirements
documents.

-- Section 4.1

Discussion of separate header and data digests is internally inconsistent.
Fix this by changing the "MAY" and "MUST" to two "SHOULD"s (i.e., SHOULD
specify separate header and data digests).

Delete "SHOULD" sentence on extensibility to other digest methods.

-- Section 4.2

Add a phrase or sentence to the end of the first paragraph indicating that
recovery is frequently infeasible for tape due to the absence of block
addresses in the SCSI command set used for tape devices.  This'll help
set up the non-idempotent recovery requirement.

Change ""storage servers"" to "network ports".

-- Section 5.2

See above comments on leaving "comply with SAM" text as is and
on tracking changes to SAM and SCSI.

In discussing the requirement to support all command sets and
device types, call out long CDB formats and bi-directional
commands as examples.

Delete the "There is considerable discussion on the mailing list
archives" sentence at the end of the ACA paragraph because
I believe AIX is known to use ACA.

Pick up resolution of list discussion of command ordering in the face of
errors.

-- Section 6.1

Add a MUST for dynamic security mechanism being secure against
man-in-the-middle
attacks that would cause weak or no security to be negotiated when that was
not
the outcome intended by the negotiating parties.

-- Section 6.2 and 6.3

See earlier comment on "MUST NOT preclude" - turns up in both sections.  Add
connection hijacking as a specific case of source spoofing because it
imposes
additional requirements on the mechanism used for this.

-- Section 6.4

I'd prefer to call this "confidentiality" to avoid the fact that "privacy"
has more than one meaning.

-- Section 7.1

Make it clear that URL (RFC 1783) format is RECOMMENDED, not REQUIRED.

"path on which it is found" --> "path by which it is accessed".

LU WWN - iSCSI MAY REQUIRE this to be implemented.

Discussion of SCSI security is fine here, BUT delete the T10 document
reference - we can't make a normative reference to that sort of thing.
Provide a general description of what T10 is up to.  the first sentence
of this paragraph should be used in Section 1 instead of the "deal with
the complications" language that's currently there.

-- Section 7.2

Qualify the "provide some means of determining whether an iSCSI
service is available through an IP address" requirement to either
apply to an <IP address, TCP port> pair or apply to the <IP address>
and the default iSCSI TCP port.  The underlying issue is that the
straightforward thing to do is contact one TCP port and see if
iSCSI responds - if it doesn't, one shouldn't be REQUIRED to
do a port scan to find the
unauthorized iSCSI server running at port 12835, and doing that
scan will actually cause discovery and zoning problems in some
configurations.

    SCSI protocol-dependent techniques SHOULD be used for further 
    discovery beyond the iSCSI layer.

Change this to:

    Standard SCSI discovery techniques (e.g., REPORT_LUNS), as specified
    in the appropriate SCSI standards. MUST be used ...

On target discovery:
	given an IP end point on its well-known port
Generalize this to an IP endpoint and arbitrary TCP port (e.g., the default
TCP port for iSCSI as allocated by IANA)

-- References

We need Ralph Weber's advice about how to write stable references to T10
work in progress.  References 3-5 and 9 (SAM, SPC, CAM, FCP-2) have this
issue.  I think Reference 6 to the Hafner draft has to be deleted because
I don't see how to readily make that an archival/durable reference.
Reference 7 is incomplete, and reference 8 is fine.

------ DLB's comments on Bob Snively's comments --------

(1) Ok, add this requirement that one LU can't block another.
(2) Ok to rewrite ordered command delivery requirement to apply
	to I_T_L nexii, but make sure not to preclude a design
	(e.g., the one iSCSI is currently using) that satisfies
	this by doing command sequencing on I_T nexii.
(3) Change the phrase "passive attack" to "eavesdropping" or
	"traffic monitoring" and rephrase appropriately.
(4) Ok to delete the marketing-oriented text, as I don't think
	it's crucial to the document.  Ask Bob to supply a
	complete list of what he wants deleted.
(5) I like Bob's rewrite of the direct data placement text.
(6) I agree - delete all mention of the alternate connection binding
	model.  This sort of design decision rationale belongs in
	the protocol specification, not the requirements document.
(7) Bob's clarification of negotiation requirements for optional
	features looks reasonable to me.
(8) I agree - there should be one iSCSI CRC, and that should be it, period.
	It can be revised in a subsequent RFC which'll get a new document
number.
(9) Actually, the text is almost correct as written.  Here's how I
	think it should read:

   "In order to be considered a SCSI transport, the iSCSI standard MUST 
   comply with the requirements of the SCSI Architecture Model [SAM2] 
   for a SCSI transport.  Any feature SAM2 requires in a valid 
   transport mapping MUST be specified by iSCSI.  The iSCSI document 
   SHOULD specify that each such feature is RECOMMENDED, 
   or REQUIRED to implement, although they may be OPTIONAL to use."

	When T10 says iSCSI should not specify something that's in SAM,
	that winds up being an exception to the "SHOULD" - the WG must
	carefully consider all of the consequences and implications
	(cf. RFC 2119 definition of SHOULD) before doing something
	different.  Bob and I are in violent agreement about the goal
	and intent and disagreeing only on wording to achieve it,
	perhaps this explanation ought to be added?

(10) Bob's proposed new text for gateway requirements looks good.
(11) We can't delete the congestion control requirement, but adding
	a sentence indicating that TCP satisfies this requirement is
	appropriate.

FWIW, my taste in RFC-2119 terms is to use MUST instead of SHALL
to avoid any possible SHALL vs. SHOULD confusion, but this is my personal
taste and not something that I will enforce as a WG co-chair.

From a procedural standpoint, I think we're going to need a -04 version
of the document for those who have submitted comments to check to make
sure that the changes are satisfactory.  Many thanks to Marjorie for her
patience with this.

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