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 >
- Re: [storm] iSER - another try Tom Talpey
- [storm] iSER - another try david.black
- Re: [storm] iSER - another try Michael Ko
- [storm] Error behavior (RE: iSER - another try) david.black
- [storm] Invalidation (was RE: iSER - another try) david.black
- Re: [storm] Error behavior (RE: iSER - another tr… Tom Talpey
- Re: [storm] Invalidation (was RE: iSER - another … Tom Talpey
- Re: [storm] Error behavior (RE: iSER - another tr… david.black