[Ips] iSER: draft-ietf-ips-iser-05.txt

"Sanjay Goyal" <sanjayg@ivivity.com> Tue, 29 November 2005 18:36 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhAL3-0007hw-6n; Tue, 29 Nov 2005 13:36:25 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhAKz-0007gF-Q8 for ips@megatron.ietf.org; Tue, 29 Nov 2005 13:36:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17092 for <ips@ietf.org>; Tue, 29 Nov 2005 13:35:35 -0500 (EST)
Received: from [64.238.111.98] (helo=thoth.ivivity.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhAf5-0006uF-U8 for ips@ietf.org; Tue, 29 Nov 2005 13:57:09 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 29 Nov 2005 13:36:01 -0500
Message-ID: <0F31272A2BCBBE4FA01344C6E69DBF50295FF8@thoth.ivivity.com>
Thread-Topic: iSER: draft-ietf-ips-iser-05.txt
Thread-Index: AcX1E78kFXht5clXR8uy37Jv/lzRuQ==
From: Sanjay Goyal <sanjayg@ivivity.com>
To: ips@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf
Subject: [Ips] iSER: draft-ietf-ips-iser-05.txt
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1704369948=="
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org

Hi

below is the description as per draft-ietf-ips-iser-05.txt section 6.3

 

--------------

An iSER-enabled node is not required to initiate the RDMAExtensions 

   key exchange if it prefers to operate in the Traditional iSCSI mode.


   However, if the RDMAExtensions key is to be negotiated, an initiator 

   MUST offer the key in the first Login Request PDU in the 

   LoginOperationalNegotiation stage of the leading connection, and a 

   target MUST offer the key in the first Login Response PDU with which 

   it is allowed to do so (i.e., the first Login Response PDU issued 

   after the first Login Request PDU with the C bit set to 0) in the 

   LoginOperationalNegotiation stage of the leading connection.  In 

   response to the offered key=value pair of RDMAExtensions=yes, an 

   initiator MUST respond in the next Login Request PDU with which it 

   is allowed to do so, and a target MUST respond in the next Login 

   Response PDU with which it is allowed to do so. 

----------

 

What is confusing to me is 

"if the RDMAExtensions key is to be negotiated, an initiator 

   MUST offer the key in the first Login Request PDU in the 

   LoginOperationalNegotiation stage of the leading connection" 

               which is later followed by

"In response to the offered key=value pair of RDMAExtensions=yes, an 

   initiator MUST respond in the next Login Request PDU with which it 

   is allowed to do so"

 

If the Initiator did not exchange the key in first Login Request, means
that it doesnot want to negotiate, why would it get the key in the first
Login Response as Target should not send it to begin with.

 

Please clarify,

 

Regards,
 
Sanjay Goyal
678-990-1550 x204
iVivity Inc.
Norcross, GA 30093

 

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips