SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI:new iSCSI draft 09.txt, some text omitted



    
    The Network Enity is called out in the figure in section 2.5
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Home Office (408) 997-6136, Cell: (408) 499-9702
    Internet address: hufferd@us.ibm.com
    
    
    Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 11/19/2001 02:01:30 AM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  Re: iSCSI:new iSCSI draft 09.txt, some text omitted
    
    
    
    John,
    
    I'll add it to the to-do list provided that we have a think called "iSCSI
    Target Network Entity"...
    
    Regards,
    Julo
    
    
    
    
    John Hufferd@IBMUS
    19-11-01 11:02
    
    
            To:     Julian Satran/Haifa/IBM@IBMIL
            cc:     ips@ece.cmu.edu
            From:   John Hufferd/San Jose/IBM@IBMUS
            Subject:        Re: iSCSI:new iSCSI draft 09.txt, some text omitted
    
    
    
    
    
    
    Julian,
    With regard to point 2.2.7, I now see the wordage is probably OK, I think
    I was thrown off by the lack of change bars, at that point, in your PDF
    version.
    
    However, the 3.12.8 Item (which is now at 3.12.7) we thought needed to
    have the last sentence changed from:
    
    "...this uniquely identifies the session with that initiator."
    
    to:
    
    "...this uniquely identifies a session from that specific target to that
    specific initiator. That is, the TSID is a unique value within the scope
    of a specific target (not necessarily unique within the iSCSI Target
    Network Entity)."
    
    We spent a lot of time discussing this, and found there was a lot of
    confusion.  So we wanted to unambiguously state the value of TSID did not
    have scope beyond the Specific Target, which might exist amoung others, in
    the same Network Entity.
    
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Home Office (408) 997-6136, Cell: (408) 499-9702
    Internet address: hufferd@us.ibm.com
    
    Sent by:        owner-ips@ece.cmu.edu
    To:     ips@ece.cmu.edu
    cc:
    Subject:        Re: iSCSI:new iSCSI draft 09.txt, some text omitted
    
    
    
    John,
    
    The change was already made when Andre asked for it.
    I've checked it and it did not disappear. The wording may be different but
    the names are required at each login.
    I've checked it now and it appears everywhere.
    If I omitted to specify it somewhere please let me know.
    
    Regards,
    Julo
    
    
    
    
    
    
    John Hufferd/San Jose/IBM@IBMUS
    Sent by: owner-ips@ece.cmu.edu
    19-11-01 01:20
    Please respond to John Hufferd
    
    
            To:     Julian Satran/Haifa/IBM@IBMIL
            cc:     ips@ece.cmu.edu
            Subject:        iSCSI:new iSCSI draft 09.txt, some text omitted
    
    
    
    
    Julian,
    I think you perhaps overlooked, for the new draft, the wordage presented
    by
    Andre Asselin in the area of 2.2.7 and  3.12.8 shown below.
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Home Office (408) 997-6136, Cell: (408) 499-9702
    Internet address: hufferd@us.ibm.com
    
    
    Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 11/05/2001 10:21:55 PM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  Re: spec revs to make TargetName reqd on every connection
    
    
    
    thanks - julo
    
    
    
    
    Andre Asselin@IBMUS
    05-11-01 22:55
    
    
            To:     Julian Satran/Haifa/IBM@IBMIL
            cc:     John Hufferd/San Jose/IBM@IBMUS, Jim
    Hafner/Almaden/IBM@IBMUS,
    ips@ece.cmu.edu
            From:   Andre Asselin/Raleigh/IBM@IBMUS
            Subject:        spec revs to make TargetName reqd on every
    connection
    
    
    
    Julian,
            Attached is an attempt to pull together all the required spec
    updates to make InitiatorName required on every login, TargetName required
    on every normal login, and clarify related text.
    
    Does this look good to everyone?  Any places I missed?
    
    Andre Asselin
    IBM ServeRAID Software Development
    Research Triangle Park, NC
    
    
    Appendix D, TargetName option:
    
    Remove "LO" from Use.
    
    Change
    
    This key MUST be provided by the initiator of the TCP connection to the
    remote endpoint before the end of the login phase. The iSCSI Target Name
    specifies the worldwide unique name of the target.  The TargetName key may
    also be returned by the "SendTargets" text request (and that is its only
    use when issued by a target).
    
    To
    
    This key must be provided by the initiator of the TCP connection to the
    remote endpoint in the first login request if the initiator is  not
    establishing a discovery session. The iSCSI Target Name specifies the
    worldwide unique name of the target.  The TargetName key may also be
    returned by the "SendTargets" text request (and that is its only use when
    issued by a target).
    
    Appendix D, InitiatorName option:
    
    Remove "LO" from Use.
    
    Change
    
    This key MUST be provided by the initiator of the TCP connection to the
    remote endpoint at the first Login of login phase for every connection.
    The Initiator key enables the initiator to identify itself to the remote
    endpoint.
    
    To
    
    This key must be provided by the initiator of the TCP connection to the
    remote endpoint at the first Login of login phase for every connection.
    The InitiatorName key enables the initiator to identify itself to the
    remote endpoint.
    
    
    The current version of the 6th paragraph in chapter 5 reads:
    
    The initial Login request of the first connection of a session (leading
    login) MUST include the InitiatorName key=value pair. The leading Login
    request MAY also include the SessionType key=value pair in which case if
    the SessionType is not "discovery" then the leading Login Request MUST
    also include the key=value pair TargetName.
    
    A suggested rewrite would be (building on the text suggested by Bob
    Russell):
    
    All initial Login requests MUST include the InitiatorName key=value pair.
    
    If the initial Login request is also a leading Login (TSID=0) and the new
    session is to be a discovery session, then the initial Login request MUST
    also include the SessionType=discovery key=value pair.
    
    If the initial Login request is a leading Login and the new session is to
    be a normal session,  then the initial Login request MUST also include the
    TargetName key=value pair and MAY also include the SessionType=normal
    key=value pair.
    
    All initial Login requests that are not also a leading Login (TSID != 0)
    MUST include the TargetName key=value pair.
    
    Also, this text appears in 2.2.7:
    
    The initiator MUST present both its iSCSI Initiator Name and the iSCSI
    Target Name to which it wishes to connect in the first login request of a
    new session.  The only exception is if a discovery session (see 2.4) is to
    be established; the iSCSI Initiator Name is still required, but the iSCSI
    Target Name may be ignored.  The key "SessionType=discovery" is sent by
    the initiator at login to indicate a discovery session.
    
    A suggested rewrite would be:
    
    The initiator must present its iSCSI Initiator Name in the first login
    request.  If the initiator is not establishing a discovery session (see
    2.4), it also must present the iSCSI Target Name to which it wishes to
    connect in the first login request.  The key "SessionType=discovery" is
    sent by the initiator on the Initial Login request to indicate a discovery
    session. See chapter 5 for a more detailed description of the Login
    process.
    
    Section 3.12.8 currently reads:
    
    The TSID is the target assigned component of the session identifier
    (SSID).  Together with the ISID provided by the initiator, this uniquely
    identifies the session with that initiator.
    
    Suggested rewrite (melding current text w/John's rewrite):
    
    The TSID is the target assigned component of the session identifier
    (SSID).  Together with the ISID provided by the initiator, this uniquely
    identifies a session from that specific target to that specific initiator.
     That is, the TSID is a unique value within the scope of a specific target
    (not necessarily unique within the iSCSI Target Network Entity).
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    


Home

Last updated: Mon Nov 19 17:17:35 2001
7856 messages in chronological order