RE: iSCSI: Negotiating a parameter more than once

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

The section you reference is titled "Login Phase" - SendTarget's isn't valid
during the login phase, and it's not a negotiation.  It's a
request/declaration, and its only valid during FFP.  Sorry, I don't see a
problem with the text you quoted.

Marjorie

> -----Original Message-----
> From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com]
> Sent: Monday, June 17, 2002 4:05 PM
> To: Julian_Satran@il.ibm.com
> Cc: ips@ece.cmu.edu
> Subject: RE: iSCSI: Negotiating a parameter more than once
> 
> 
> Julian,
> 
> It also isn't clear whether SendTargets can be sent more than 
> once during a negotiation sequence.
> 
> It would be reasonable for the Initiator to set the F bit 
> when it sends SendTargets and then when the Target sets the F 
> bit the initiator will know that the response is complete. 
> However if SendTargets isn't covered by the limitation on 
> negotiating a parameter only once per negotiation sequence, 
> an initiator could also leave the F bit at zero, assume the 
> response is done when it gets a response with an empty text 
> field, and send SendTargets again later in the same 
> negotiation sequence. An initiatior could even send a single 
> PDU with something like: SendTargets=<iSCSI-target-name-A>; 
> SendTargets=<iSCSI-target-name-B>; SendTargets=<iSCSI-target-name-C>. 
> 
> There doesn't seem to be anything in Appendix D to say which 
> of these is intended. The first possibility - allowing 
> SendTargets to be sent only once during a negotiation 
> sequence - seems adequate and simpler.
> 
> Pat
> 
> -----Original Message-----
> From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
> Sent: Monday, June 17, 2002 3:19 PM
> To: Julian_Satran@il.ibm.com
> Cc: ips@ece.cmu.edu
> Subject: iSCSI: Negotiating a parameter more than once
> 
> 
> Julian,
> 
> The following text appears in 4.3 (page 78 just before 4.3.1):
> 
> Neither the initiator nor the target should attempt to negotiate a
> parameter more than once during login. If detected by the target this
> MUST result in a Login reject (initiator error). The initiator MUST
> drop the connection.
> 
> and nearly the same text in 4.4 (page 85 near the end):
> 
> Neither the initiator nor the target should attempt to negotiate a
> parameter more than once during any negotiation sequence without an
> intervening reset. If detected by the target this MUST result in a
> Reject with a reason of "protocol error". The initiator MUST reset
> the negotiation as outlined above.
> 
> This is confusing partly because "negotiate" seems to be 
> generally used covering both negotiations and declarations 
> and in some cases covering only negotiations. It isn't clear 
> in which sense it is used. If the text above applies only to 
> negotiated values, then it would be allowable to send 
> parameters such as Initiator Name, SessionType, and 
> MaxRecvDataSegmentLength over which doesn't seem to be a good 
> idea. However, there are other declarative parameters which 
> are sent multiple times - SendTargets where there are 
> multiple targets or multiple addresses for a target requires 
> sending the same parameter multiple times. 
> 
> Perhaps the text should be changed to:
> 
> Neither the initiator nor the target should attempt to 
> declare or negotiate a
> parameter other than TargetName, TargetAlias or TargetAddress 
> more than once....
> 
> Regards,
> Pat
>