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

["John Hufferd" <hufferd@us.ibm.com>]

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).