Re: [storm] iSER - another try

Michael Ko <mkosjc@gmail.com> Mon, 23 April 2012 15:55 UTC

Return-Path: <mkosjc@gmail.com>
X-Original-To: storm@ietfa.amsl.com
Delivered-To: storm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4896E21F8758 for <storm@ietfa.amsl.com>; Mon, 23 Apr 2012 08:55:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPaQCzwB1707 for <storm@ietfa.amsl.com>; Mon, 23 Apr 2012 08:55:24 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id CED1021F8751 for <storm@ietf.org>; Mon, 23 Apr 2012 08:55:23 -0700 (PDT)
Received: by qaea16 with SMTP id a16so1583459qae.10 for <storm@ietf.org>; Mon, 23 Apr 2012 08:55:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y7iyHMJ+qMxt+9B5F0lOtJFY09mq4b51/Nq1Te6OlMU=; b=n0vhz0MZiGh6SYrMbwbWhNCPRXr8zv+rDFbgTzzvJ5uPFnZakwBXALpeiFLzNA8DgP 30w9FNnrhU4qIf4Bj8NpnEOQKRUfe1Bih4brlgGtsplYOmoWTwITums4fUfAq01vUAI9 JTrBnMNUHLIxnMHQ13L0eaeiDfUUAxoiV92nPCBsZNYVnSHq9tnfOP2DsA4clHUeixFF 30kdWijlJGGjJKCh76eNPY+mu+5Qlfb8VK3Eh3n5TfXVM0tSLEEVeGjEDURvkvNdh+LD DpHiyKExA1dSVlDn/FXsr6pnAIQFp9ND7InKHHvPTA6rUwMk5sK40HHx52mQy0YaY3au qpZg==
MIME-Version: 1.0
Received: by 10.229.69.92 with SMTP id y28mr4438376qci.33.1335196523377; Mon, 23 Apr 2012 08:55:23 -0700 (PDT)
Received: by 10.229.133.194 with HTTP; Mon, 23 Apr 2012 08:55:23 -0700 (PDT)
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7120925D1@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE7120925D1@MX15A.corp.emc.com>
Date: Mon, 23 Apr 2012 08:55:23 -0700
Message-ID: <CAP_=6dJT62LRDQSOTdOk1LvSxATcSDC4NjnDsXLE1fpOD21Gig@mail.gmail.com>
From: Michael Ko <mkosjc@gmail.com>
To: david.black@emc.com
Content-Type: multipart/alternative; boundary="485b3918ac207b35a304be5aaa38"
Cc: storm@ietf.org
Subject: Re: [storm] iSER - another try
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Apr 2012 15:55:27 -0000

David,

I agree with this position.

Mike

On Mon, Apr 23, 2012 at 6:02 AM, <david.black@emc.com> wrote:

> 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
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> david.black@emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
> _______________________________________________
> storm mailing list
> storm@ietf.org
> https://www.ietf.org/mailman/listinfo/storm
>