Re: [storm] iSER approach - update

[Michael Ko <[e-mail]>]

David,

I agree with your summary.

Mike

On Thu, May 3, 2012 at 3:29 PM, <[e-mail]> wrote:

> Attempting to summarize where we are ... the changes from my earlier
> attempt
> are:
> - Dropped the MUST for error reporting by the receiver.
> - Added a more general "SHOULD NOT use" to iii).
> - Added caching discussion and need for yet more security considerations
>        text to v).
> - Added a warning about relying on SendSE and SendInvSE at receiver - new
> item
>        vi).
>
> Are we getting closer?  Here's the new version:
>
> 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 are to be regarded as optimizations or
>        enhancements to the basic Send message, and their support may vary
> by
>        RCaP protocol and specific implementation.  In general, these
> messages
>        SHOULD NOT be used, unless the RCaP requires support for them in all
>        implementations.  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 message (and we need to note that
> attempted
>        use of these messages with a peer that doesn't support them may
> result
>        in a fatal error that closes the RCaP connection).  A specific
> instance
>        that needs to be noted is that these messages SHOULD NOT be used
> with
>        the InfiniBand RCaP because InfiniBand does not require support for
> them
>        in all cases.
> 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 (especially Security Considerations) to
>        make it clear that STag invalidation is the initiator's
> responsibility
>        for security reasons, and the initiator cannot rely on the target
>        using an Invalidate version of Send - the initiator MUST check and
>        do its own invalidation as required.  The initiator MAY choose to
> cache
>        mappings (i.e., reuse STags) across I/Os for efficiency, but that
> has
>        security consequences (exposes initiator memory to remote access for
>        longer) that have to be discussed in the new Security
> Considerations text.
> vi) Similarly, iSER implementations SHOULD NOT rely on events triggered by
>        SendSE and SendInvSE, as these messages may not be used.  In
> contrast
>        to invalidation, there are no security consequences in this aspect.
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
>
>
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm
>