|
Julian,
We don't need to
mandate the F bit, but it currently isn't clear whether it can be sent only once
or more than once per negotiaiton. I would be happy with an explicit
clarification of that - which could be covered by the change for the other
string on negotiating a parameter more than once.
Pat
Pat,
I don't see why we have to say something specific
about SendTargets.
It should be sent only once during a
negotiiation.
Why should we mandate the F bit?
Julo
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
Home
Last updated: Mon Jun 17 20:18:42 2002
10865 messages in
chronological order
|
