[storm] iSER - another try

[<[e-mail]>]

We don't seem to be making progress on definitive requirements that
vary by RCaP, so here's another suggestion (would be [4] if I were
numbering it ...)

It's clear that at least one implementation has diverged from the
requirements in RFC 5046 for use of SendSE, SendInv and SendInvSE.
I suggest documenting this and applying the IETF approach of "be
conservative in what you send, be liberal in what you accept",
roughly as follows:

i) Some iSER implementations have not followed RFC 5046's strict requirements
	for use of SendSE, SendInv and SendInvSE; they use Send instead.
ii) For interoperability, iSER implementations SHOULD accept and correctly
	process SendSE, SendInv and SendInvSE messages.
iii) SendSE, SendInv and SendInvSE should be regarded as optimizations or
	enhancements to the basic Send message, and their support varies by
	RCaP.  If these messages are used, the implementation SHOULD be
	capable of reverting to use of Send in order to work with a receiver
	that does not support these messages (lack of receiver support MUST
	result in an error send back to the sender).  These messages
	SHOULD NOT be used with the InfiniBand RCaP because InfiniBand does
	not require support for their functionality.
iv) New iSER implementations SHOULD use Send (and not these three additional
	messages) unless there are compelling reasons for doing otherwise
	(latter is implicit in use of "SHOULD", but worth saying explicitly,
	IMHO).
v) Some new text will be needed (including Security Considerations) to
	make it clear that STag invalidation is necessary for security
	reasons, and has to be performed independent of whether an
	Invalidate version of Send was used or not.

Is this workable?

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------