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



    Sorry Pat, I read your response too quickly and misinterpreted the definition of "negotiation sequence".  I agree with you, the text you suggest is appropriate.
     
    In addition, it would be nice if section 11 had an explicit "Use" indication distinguishing keys that can be repeated w/in a declaration sequence (targetAddress, targetAlias, targetName) and keys that cannot be repeated.
     
    You mentioned that you couldn' t find text that says the SendTargets command can be repeated w/in a declaration sequence - in fact, Appendix D paragraph 6 says:
        
         "A SendTargets command consists of a single Text request PDU.
         This PDU contains exactly one text key and value.  The text key MUST
         be SendTargets.  The expected response depends upon the value, as
         well as whether the session is a discovery or operational session."
     
    This seems OK to me, if an initiator wants information about another target, it can just initiate another SendTargets "negotiation sequence"??
     
    Marj

     
     -----Original Message-----
    From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com]
    Sent: Wednesday, June 19, 2002 11:32 AM
    To: 'THALER,PAT (A-Roseville,ex1)'; Julo-Actcom; ips@ece.cmu.edu
    Subject: RE: iSCSI: Negotiating a parameter more than once

    In the context of the two keys that are valid during FFP, neither of these suggested edits to that paragraph make sense.  Currently, there is no "negotiation" key that's valid in FFP, and the "declarative" keys that are valid, - SendTargets and MaxPDUDataLength *can* validly be repeated.  If an initiator opens a discovery session, it may keep it open, and it may repeat SendTargets requests as it deems necessary to keep it's target information up to date.  In the course of a SendTargets response, the target validly repeats certain keys.  The MaxPDUDataLength key can be sent by the initiator as often as the PMTU changes.
     
    Why not just delete this paragraph?  In the future if there are keys added that are valid during FFP, the RFC that specifies those keys can specify whether or not they can be "renegotiated".
     
    Marjorie Krueger
    Networked Storage Architecture
    Networked Storage Solutions Org.
    Hewlett-Packard
     
    -----Original Message-----
    From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com]
    Sent: Wednesday, June 19, 2002 10:19 AM
    To: Julo-Actcom; ips@ece.cmu.edu
    Subject: RE: iSCSI: Negotiating a parameter more than once

    Julian,
     
    If declarations should not be repeated (except for those where it is explicitly allowed), then it should be "negotiate or declare" because "negotiate" doesn't cover declarations. Alternatively, one could add an explicit definition that "Negotiate" includes both declarations and negotiations. Secondly, SendTargets is not a valid example for login as it is FFPO. I think the only parameter explicitly allowed to be duplicated during Login is TargetAddress (when returned as a result of a redirect). Furthermore, I can not find any explicit statement that SendTargets may be repeated during a FFP negotiation sequence. Only TargetName and TargetAddress have explicit text allowing them to be repeated (in Appendix B for both and in the description of redirection for LoginResponse for TargetAddress).
     
    Therefore, I suggest:
    For 4.3:
    Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection
     
    For 4.4:
    Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations (e.g. TargetAddress). 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.
     
    Pat
    -----Original Message-----
    From: Julo-Actcom [mailto:Julian_Satran@actcom.net.il]
    Sent: Tuesday, June 18, 2002 10:12 PM
    To: ips@ece.cmu.edu
    Subject: RE: iSCSI: Negotiating a parameter more than once

    Pat,
     
    4.3 and 4.4 cover two diferent phases.
    Parameters should not be negotiated or declared twice.
     
    I think that you refer to the responses to SendTargets - those contain more than an instance of the declarations and have to outlined.
     
    How about the following text in 4.4:
     

    Neither the initiator nor the target should attempt to negotiate a parameter more than once during login except for responses to specific keys that explicitly allow repeated key declarations (e.g. SendTargets). If detected by the target this MUST result in a Login reject (initiator error). The initiator MUST drop the connection.

     

    and in 4.4:

     

    Neither the initiator nor the target should attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset except for responses to specific keys that explicitly allow repeated key declarations. 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.

    Julo


Home

Last updated: Thu Jun 20 03:18:50 2002
10904 messages in chronological order