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

Sanjay,

There is the possibility that an iSER initiator might prefer to operate in 
iSCSI mode and therefore not offer RDMAExtensions in its Login Request. 
But if the target can support and prefers iSER mode, it can offer 
RDMAExtensions in its Login Response.  It is then up to the initiator to 
determine if it wants to support iSER for this session.  The iSER draft is 
written to allow such possibilities.

Mike
Sent by:        ips-bounces@ietf.org
To:     <ips@ietf.org>
cc:      
Subject:        [Ips] iSER: draft-ietf-ips-iser-05.txt

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

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