Re: [storm] I-D Action: draft-ietf-storm-iser-04.txt

<> Mon, 26 September 2011 22:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E08D811E8119 for <>; Mon, 26 Sep 2011 15:54:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.552
X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iGBgN7Q3ZNEw for <>; Mon, 26 Sep 2011 15:54:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 632A711E80D4 for <>; Mon, 26 Sep 2011 15:54:45 -0700 (PDT)
Received: from ( []) by (Switch-3.4.3/Switch-3.4.3) with ESMTP id p8QMvMXP009470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2011 18:57:22 -0400
Received: from ( []) by (RSA Interceptor); Mon, 26 Sep 2011 18:57:11 -0400
Received: from ( []) by (Switch-3.4.3/Switch-3.4.3) with ESMTP id p8QMvABc024819; Mon, 26 Sep 2011 18:57:11 -0400
Received: from ([]) by ([]) with mapi; Mon, 26 Sep 2011 18:57:09 -0400
From: <>
To: <>, <>
Date: Mon, 26 Sep 2011 18:57:08 -0400
Thread-Topic: [storm] I-D Action: draft-ietf-storm-iser-04.txt
Thread-Index: Acx8m4uWzfQ9eYdkSDKbpqCOlzQifAAAjahg
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7C4DFCE962635144B8FAE8CA11D0BF1E058CE4B25DMX14Acorpemcc_"
MIME-Version: 1.0
Subject: Re: [storm] I-D Action: draft-ietf-storm-iser-04.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Sep 2011 22:54:49 -0000


Thanks for updating this draft.

Looking at the details.  I think some changes are needed:

6.7  MaxOutstandingUnexpectedPDUs

The problem here is that the change in the default value of the key from
0 to 4 is not backwards compatible if the key is not negotiated.  I had
thought that the default was going to be changed to 0.

I think there are three choices:
a) No default, key MUST be negotiated, 4 is a suggested value, unless a
      larger value is needed.
b) Default remains at 0, keep existing text that says the key SHOULD be
negotiated because that default value is problematic.
c) Change the default to 4 and state that all implementations do this,
      keep existing text that says the key SHOULD be negotiated because
the default value of 0 in RFC 5046 is problematic is fine.
It looks like you're headed for option c), and hence need to add text
to say that all implementations already use this default if that's the
case.  If not, a) may be the best way out of this.

This will affect item 4 in Section 14.

I'd like to edit the text in 6.8 MaxAHSLength to use a SHOULD and make

it clear when the SHOULD applies:

      For interoperability with implementations based on [RFC5046], an
      initiator or target MAY terminate the connection if it anticipates
      MaxAHSLength to be greater than 256 and the key is not understood by
      its peer.
      For interoperability with implementations based on [RFC5046], an
      initiator or target that needs a MaxAHSLength larger than
256 and receives a NotUnderstood response to this key from its peer
SHOULD terminate the connection.


From: [] On Behalf Of Michael Ko
Sent: Monday, September 26, 2011 6:25 PM
Subject: Re: [storm] I-D Action: draft-ietf-storm-iser-04.txt

This version of the iSER draft incorporated the comments from David Black on backward compatibility.  Changes from the -03 version are in sections 6.7, 6.8, and Appendix A.

----- Original Message -----
Sent: Monday, September 26, 2011 3:17 PM
Subject: [storm] I-D Action: draft-ietf-storm-iser-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the STORage Maintenance Working Group of the IETF.

Title           : iSCSI Extensions for RDMA Specification
Author(s)       : Michael Ko
                          Alexander Nezhinsky
Filename        : draft-ietf-storm-iser-04.txt
Pages           : 91
Date            : 2011-09-26

   iSCSI Extensions for RDMA provides the RDMA data transfer capability
   to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol.  An
   RDMA-Capable Protocol provides RDMA Read and Write services, which
   enable data to be transferred directly into SCSI I/O Buffers without
   intermediate data copies.  This document describes the extensions to
   the iSCSI protocol to support RDMA services as provided by an RDMA-
   Capable Protocol.

   This document obsoletes RFC 5046.

A URL for this Internet-Draft is:

Internet-Drafts are also available by anonymous FTP at:

This Internet-Draft can be retrieved at:
storm mailing list<>