SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI: Negotiating a parameter more than once



    Seems to me that the text in 4.4 should be deleted, since even reworded, its
    only confusing here.  Currently, there's no "negotiation" that's valid in
    FFP - SendTargets and MaxPDUDataLength are declarative. 
    
    > -----Original Message-----
    > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
    > Sent: Monday, June 17, 2002 5:27 PM
    > To: marjorie_krueger@hp.com; pat_thaler@agilent.com
    > Cc: ips@ece.cmu.edu
    > Subject: RE: iSCSI: Negotiating a parameter more than once
    > 
    > 
    > I referenced two sections - 4.3 and 4.4. I agree that 4.3 
    > isn't relevant to SendTargets, but the similar text in 4.4 is.
    > 
    > Pat
    > 
    > -----Original Message-----
    > From: KRUEGER,MARJORIE (HP-Roseville,ex1)
    > [mailto:marjorie_krueger@hp.com]
    > Sent: Monday, June 17, 2002 4:56 PM
    > To: 'THALER,PAT (A-Roseville,ex1)'
    > Cc: ips@ece.cmu.edu
    > Subject: RE: iSCSI: Negotiating a parameter more than once
    > 
    > 
    > 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
    > > 
    > 
    


Home

Last updated: Wed Jun 19 02:18:51 2002
10881 messages in chronological order