|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI:new iSCSI draft 09.txt, some text omittedJohn, 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 14:17:47 2001 7855 messages in chronological order |