[storm] iSER - what to do

[<[e-mail]>]

<WG chair hat on>

The discussion about whether the buffer behavior of the Linux iSER
implementation complies with RFC 5046 is missing at least one
important point - to my knowledge, there are *no* iSER
implementations that comply with RFC 5046.

After RFC 5046 was issued, implementers looked at its requirements and
decided to do a number of things differently - the important difference
for this discussion is that the iSER Hello exchange is not implemented,
even though RFC 5046 requires that it be used.  There are a number of
other "running code" changes in the current iSER draft that reflect
implementations and that are incompatible with RFC 5046, see Appendix A
of the draft for details.

The iSER work item was added to the storm WG's charter in order to produce
an RFC specification of iSER that matches the "running code" and hence will
interoperate with existing implementations.  Here's the text from the
WG charter:

	(6) iSER: Experience with Infiniband implementations suggest
	a few minor updates to reflect what has been done in practice.

As WG chair, I'm going to insist on the following:
1) The iSER draft has to match the implementations in order to be
	published as an RFC.  Replacing RFC 5046 with another RFC that
	won't interoperate with the implementations is pointless.
2) The issue encountered by the Linux iSER implementation cannot be
	ignored by the WG.  The workaround (1 extra buffer, at most
	one unsolicited PDU until initiator has time to deploy
	resources) at least needs to be explained in the draft.
3) While requiring the iSER Hello exchange may be the proverbial
	"right thing to do" going forward, it is necessary to provide
	at least guidance on how to interoperate with current iSER
	implementations that don't support the Hello exchange.

In contrast, as WG chair, I'm not going to insist that we adopt the
workaround as part of the standard.  For example, it's possible to
recommend (SHOULD) use of the iSER Hello exchange (explicitly negotiated
using the new key) and explain the workaround as what should be
done in order to interoperate if that key results in a NotUnderstood
response.  For this approach to the workaround, I think a lower case
"should" may be acceptable (e.g., as opposed to a "SHOULD" or "MUST",
but that's subject to further discussion.

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