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

Mike,

I understand that, the point I was trying to make was if Initiator
prefers  
iSCSI mode, why would it change its mind after it gets  RDMAExtensions
key from Target.

-Sanjay

>Original>-----Original Message-----
>Original>From: Mike Ko [mailto:mako@almaden.ibm.com] 
>Original>Sent: Tuesday, November 29, 2005 1:52 PM
>Original>To: Sanjay Goyal
>Original>Cc: ips@ietf.org
>Original>Subject: Re: [Ips] iSER: draft-ietf-ips-iser-05.txt
>Original>
>Original>Sanjay,
>Original>
>Original>There is the possibility that an iSER initiator might 
>Original>prefer to operate in iSCSI mode and therefore not 
>Original>offer RDMAExtensions in its Login Request. 
>Original>But if the target can support and prefers iSER mode, 
>Original>it can offer RDMAExtensions in its Login Response.  
>Original>It is then up to the initiator to determine if it 
>Original>wants to support iSER for this session.  The iSER 
>Original>draft is written to allow such possibilities.
>Original>
>Original>Mike
>Original>Sent by:        ips-bounces@ietf.org
>Original>To:     <ips@ietf.org>
>Original>cc:      
>Original>Subject:        [Ips] iSER: draft-ietf-ips-iser-05.txt
>Original>
>Original>
>Original>Hi
>Original>below is the description as per 
>Original>draft-ietf-ips-iser-05.txt section 6.3
>Original> 
>Original>--------------
>Original>An iSER-enabled node is not required to initiate the 
>Original>RDMAExtensions 
>Original>   key exchange if it prefers to operate in the 
>Original>Traditional iSCSI mode. 
>Original>   However, if the RDMAExtensions key is to be 
>Original>negotiated, an initiator 
>Original>   MUST offer the key in the first Login Request PDU in the 
>Original>   LoginOperationalNegotiation stage of the leading 
>Original>connection, and a 
>Original>   target MUST offer the key in the first Login 
>Original>Response PDU with which 
>Original>   it is allowed to do so (i.e., the first Login 
>Original>Response PDU issued 
>Original>   after the first Login Request PDU with the C bit 
>Original>set to 0) in the 
>Original>   LoginOperationalNegotiation stage of the leading 
>Original>connection.  In 
>Original>   response to the offered key=value pair of 
>Original>RDMAExtensions=yes, an 
>Original>   initiator MUST respond in the next Login Request 
>Original>PDU with which it 
>Original>   is allowed to do so, and a target MUST respond in 
>Original>the next Login 
>Original>   Response PDU with which it is allowed to do so. 
>Original>----------
>Original> 
>Original>What is confusing to me is
>Original>"if the RDMAExtensions key is to be negotiated, an initiator 
>Original>   MUST offer the key in the first Login Request PDU in the 
>Original>   LoginOperationalNegotiation stage of the leading 
>Original>connection" 
>Original>               which is later followed by "In 
>Original>response to the offered key=value pair of 
>Original>RDMAExtensions=yes, an 
>Original>   initiator MUST respond in the next Login Request 
>Original>PDU with which it 
>Original>   is allowed to do so"
>Original> 
>Original>If the Initiator did not exchange the key in first 
>Original>Login Request, means that it doesnot want to 
>Original>negotiate, why would it get the key in the first 
>Original>Login Response as Target should not send it to begin with.
>Original> 
>Original>Please clarify,
>Original> 
>Original>Regards,
>Original> 
>Original>Sanjay Goyal
>Original>678-990-1550 x204
>Original>iVivity Inc.
>Original>Norcross, GA 30093
>Original> _______________________________________________
>Original>Ips mailing list
>Original>Ips@ietf.org
>Original>https://www1.ietf.org/mailman/listinfo/ips
>Original>
>Original>
>Original>

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