Subject: Re: is TargetName always mandatory or not?

From: "Andre Asselin" <[email-masked]>
Date: Thu, 1 Nov 2001 15:15:13 -0500

Jim,
     I agree with what you say, except for the part that mapping
TSID=target portal group tag will work.

Let's assume the following architecture:  I have a network entity with one
network portal (and thus one portal group).  Inside this entity lives two
iSCSI targets.

Scenerio: An iSCSI initiator opens a connection to the network portal in
order to add a connection to an already existing session (the network
entity's networking code knows this because TSID in the initial login
request is 0).  The networking code needs to determine what session the
initiator wants to add to, so it compares some items from the initial login
request to each of the established sessions until it finds a match.  The
question is what items should it compare to identify a match?

Section 3.12.9 of the spec reads:

        The TSID is the target assigned tag for a session with a specific
        named initiator that, together with the ISID uniquely identifies a
        session with that initiator.

As you say, this is clearly target centric (because, for example, an
initiator could have 2 different sessions open to two different targets
that have the same TSID).  But from a target point of view, what that text
means to me that the network entity's networking code should compare ISID +
InitiatorName + TSID to determine a match.  That implies that TSID must be
unique per TargetName and per portal group ID.  If TSID is just the target
portal group tag, then the comparison wouldn't work.  For example, using
the architecture above where there is just one portal group, the target
could have two sessions open: session A (InitiatorName=foo, ISID=1,
TargetName=bar, TSID=0) and session B (InitiatorName=foo, ISID=1,
TargetName=foobar, TSID=0).  If it receives a login request with
(InitiatorName=foo, ISID=1, TSID=0), which session is it for?

Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC

                    Jim Hafner                                                                                                        
                                         To:     Andre Asselin/Raleigh/IBM@IBMUS                                                      
                    10/31/2001           cc:     [email-masked]                                                                      
                    06:33 PM             From:   Jim Hafner/Almaden/IBM@IBMUS                                                         
                                         Subject:     Re: is TargetName always mandatory or not?(Document link: Andre Asselin)        

                                                                                                                                      

Andre,

First, your comment "SSID + InitiatorName must be enough to uniquely
identify a session" is target-centric.  It would be different from the
initiator's viewpoint.  However, from the target's viewpoint, the target
name is implicit and from the initiator viewpoint, the initiator name is
implicit, so globally, the triple of the two names + SSID (made up of the
ISID and TSID) form the identifier of the session.  Locally (between two
specific guys), the names are implicit so only the SSID is required.  It's
all a matter of point of view!

As for the difference in identifiers, as I mentioned in the private note,
the session is an iSCSI construct and is identified by iSCSI things.  The
nexus is a SCSI thing and is identified by SCSI constructs (based on how
we've mapped the iSCSI things to SCSI things).

However, you've brought to the fore again a related question:  "what value
does the TSID provide to the protocol?"

I'm not going to answer that, but I will note that one target
implementation that (I think) works is that the TSID = target portal group
tag.

The other thing to ask is "what value is there in  the nexus identifier?"
This is never really used in SCSI at all, so it's not a critical issue what
composes it.  However, it is important (IMO) that the SCSI ports have names
and the logical derivative of that statement is that the nexus is
identified by the concatenation of the SCSI port names (hence the
definition we have).

Jim Hafner

Andre Asselin/Raleigh/IBM@[email-masked] on 10/31/2001 03:00:53 pm

Sent by:  [email-masked]

To:   John Hufferd/San Jose/IBM@IBMUS
cc:   [email-masked]
Subject:  Re: is TargetName always mandatory or not?

John,
     WHOOPS!  I was wrong; you are absolutely right that the spec says
"TargetName" and not "TSID".  When I was reading through it, I saw
"TargetName", but read to myself "TSID".  Apologies...
     In my defense (confusion?), however, 3.12.9 says TSID rather than
TargetName is used to uniquely identify a session.  Going by that, SSID +
InitiatorName must be enough to uniquely identify a session.

     Jim Hafner pointed out to me that the I_T nexus is identified by one
thing and the session is identified by another.  If the two must have a 1-1
mapping in iSCSI, why are there two different identifiers?  Why not just
use the current definition of the I_T nexus to uniquely identify both the
nexus and session (i.e. get rid of TSID)?

Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC

                    John Hufferd
                                         To:     Andre
Asselin/Raleigh/IBM@IBMUS
                    10/31/2001           cc:     [email-masked]
                    04:42 PM             From:   John Hufferd/San
Jose/IBM@IBMUS
                                         Subject:     Re: is TargetName
always mandatory or not?(Document link: Andre Asselin)

Andre,
I looked again through the document and No where could I find a statement
that you claimed as "a nexus, and therefore an iSCSI session, is uniquely
identified by the InitiatorName, ISID, TSID, and portal group tag".  It is
the InitiatorName, ISID, TSID, with the TargetName and PortalGroup.

Please point out to me in the Spec (8 or above), where  I can find your
statement on I_T Nexus.

I did find the following (please ignore for this conversation the "i" and
't" stuff):

"- Session: The group of TCP connections that link an initiator with a
target, form a session (loosely equivalent to a SCSI I-T nexus). TCP
connections can be added and removed from a session. Across all connections
within a session, an initiator sees one "target image".  "

" - I_T nexus: According to [SAM2], the I_T nexus is a relationship between
a SCSI Initiator Port and a SCSI Target Port. For iSCSI, this relationship
is a session, defined as a relationship between an iSCSI Initiator's end of
the session (SCSI Initiator Port) and the iSCSI Target's Portal Group. The
I_T nexus can be identified by the conjunction of the SCSI port names; that
is, the I_T nexus identifier is the tuple (iSCSI Initiator Name + 'i'+
ISID, iSCSI Target Name + 't'+ Portal Group Tag). NOTE: The I_T nexus
identifier is not equal to the session identifier (SSID).  "

I have not found a place where Session ID is tied to the TSID.

Hence my comment that we also need to have the TargetName in the Initial
Login on all Connections.

.
.
.
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
Internet address: [email-masked]

Andre Asselin/Raleigh/IBM@[email-masked] on 10/31/2001 10:40:55 AM

Sent by:  [email-masked]

To:   [email-masked]
cc:   John Hufferd/San Jose/IBM@IBMUS
Subject:  Re: is TargetName always mandatory or not?

John & Julian,
     How about this for the section 5 text:

The initial Login request of the first connection of a session (leading
login) MUST include the InitiatorName key=value pair. The initial login
request
of the leading Login MAY also include the SessionType key=value pair, in
which case if the SessionType is not "discovery", then the initial login
request
MUST also include the key=value pair TargetName.

John,
     I disagree with your second statement: I don't see any way you could
have 2 different sessions established within the same portal group with the
same InitiatorName, ISID, and TSID.  The spec. says that a nexus, and
therefore an iSCSI session, is uniquely identified by the InitiatorName,
ISID, TSID, and portal group tag.  There is no mention of TargetName
contributing to the identificaiton of a session.  In my opinion, a
non-leading connection should NOT have the TargetName, since it doesn't
contribute anything.

Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC

                    John
                    Hufferd/San          To:     Julian
Satran/Haifa/IBM@IBMIL
                    Jose/IBM@IBMUS       cc:     [email-masked]
                    Sent by:             Subject:     Re: is TargetName
always mandatory or not?
                    owner-ips@ece.
                    cmu.edu

                    10/31/2001
                    04:20 AM

Julian,
I think the TargetName should be included on the Initial Login Request on
the Leading Login.  It seem strange to permit the Authentication functions
to proceed if perhaps the intended Target is different then the one doing
the Authentication.  The way it currently is written, you could pass all
the Security test and then find out just before going into Full Function
Phase, that it was intended for some other Target.  Seems like a waste.

My I think that TargetName should also be on all connections on the Initial
Login Request.  Here is my thinking:

The SSID (ISID+TSID) is unique only with regards to a Specific Initiator
and Target Node Pair.  It is therefore not clear that just knowing the SSID
and InitiatorName is enough to understand what session the subsequent
connections are being attached to.  And it is possible that the CID could
be also overlapped with another session.

Therefore, I think it make since to determine all this on the initial Login
on every Connection, so you know at the beginning what values can be
negotiated, or that are being set to the right Session.

.
.
.
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
Internet address: [email-masked]

Julian Satran/Haifa/IBM@[email-masked] on 10/30/2001 11:33:50 PM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  Re: is TargetName always mandatory or not?

It is the leading login:

The section 5 paragraph will read:

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.

Julo

Andre Asselin/Raleigh/IBM@IBMUS
Sent by: [email-masked]
31-10-01 02:08
Please respond to Andre Asselin

        To:     "IPS Reflector (E-mail)" <[email-masked]>
        cc:
        Subject:        is TargetName always mandatory or not?

     In section 5 of the spec, it says "If the SessionType is not
"discovery" then the initial Login Request MUST also include the key=value
pair TargetName.".  However, in Appendix D, the description for TargetName
says it is Leading Only.
     Should TargetName not be Leading Only, or should the text in section
5
say that TargetName must be in the initial Login Request of a leading
connection?

Andre Asselin
IBM ServeRAID Software Development
Research Triangle Park, NC

---

From: "Robert D. Russell" <[email-masked]>
Date: Thu, 1 Nov 2001 15:43:18 -0500

Julian:

Please see comments below:

Bob Russell
InterOperability Lab
University of New Hampshire
[email-masked]
603-862-3774

> From [email-masked] Wed Oct 31 08:15:10 2001
> Date: Wed, 31 Oct 2001 09:33:50 +0200
> From: Julian Satran <[email-masked]>
> To: [email-masked]

I believe the phrase "in which case" should be taken out, because in the
case when SessionType key is omited, the default session type is normal
and the initial Login request MUST include the TargetName key.
Furthermore, if the session is to be a discovery session, then the
SessionType=discover pair MUST also be present in the initial login
request.  The new wording would then be:

  The initial Login request of the first connection of a session (leading 
  login) MUST include the InitiatorName key=value pair. If the session
  is to be a discovery session, then the leading Login request MUST also
  include the SessionType=discovery pair.  If the session is to be a
  normal session, then the leading Login request MUST also include the
  key=value pair TargetName.

I also have some related changes that need to be made in order
to maintain consistency with the above wording in section 5.

1. The following sentence must be removed from the end of section 5.1
(because the LO designation means that the InititatorName, TargetName,
and SessionType keys cannot be sent at all during the login phase of
new connections within existing sessions).

  remove
    If sent on new connections within an existing session the iSCSI
    Target Name and the iSCSI Initiator Name MUST be the same as the
    one used for the leading connection.

2. The wording in Appendix D for the InitiatorName and TargetName
entries should be changed as follows:

 for InitiatorName:

    change
      "This key MUST be provided by the initiator of the TCP connection to
      the remote endpoint before the end of the login phase."
    to
      "This key MUST be provided by the initiator on the initial Login
      request of the first connection of any type of session."

 for TargetName:

    change
      "This key MUST be provided by the initiator of the TCP connection to
      the remote endpoint before the end of the login phase."
    to
      "This key MUST be provided by the initiator on the initial Login
      request of the first connection of a normal session."

3. The following phrase should be added to the wording in Appendix D
for the SessionType entry:

  "This key can only be used on the initial Login request of the first
  connection of a session."

4. Finally, the wording in section 2.2.7 should be changed:

  change
    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.
  to
    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 omitted.  The key "SessionType=discovery"
    MUST be sent by the initiator on the initial Login request of the
    first connection to indicate a discovery session.

---

From: "Andre Asselin" <[email-masked]>
Date: Thu, 1 Nov 2001 15:33:28 -0500

John,

     So according to that, TSID + ISID + InitiatorName must be enough
information for a target to uniquely idenfity a session, so mapping TSID to
target portal group ID won't always work (see my other note addressed to
Jim for an example of where it won't).
     After thinking about this for a while, I've come to the same
conclusion as you (that a target should compare ISID + InitiatorName +
TargetName + target portal group to uniquely identify a session), but from
a different angle.
     My reasoning:  Since there is a 1-1 correspondence between an I_T
nexus and a session, if you can identify the nexus, you've identified the
session, and vice versa.  Since 3.12.9 says that TSID + ISID +
InitiatorName must uniquely identify a session, then TSID must be an alias
for TargetName + target portal group ID, since (ISID + InitiatorName +
TargetName + portal group ID) uniquely identifies a nexus.  In my opinion,
that aliasing only complicates (and confuses!) the protocol and should be
done away with.  If TargetName were required on every initial login
request, then the target could compare (ISID + InitiatorName + TargetName +
portal group) to determine a session match, and forget about TSID entirely.
In that case, there is no need for TSID, except to flag whether the login
request is to create a new session or to add a new connection to an
existing session (i.e. indicate leading login), in which case it could be
dropped and replaced with a single bit.

To eliminate TSID, I believe the following changes would be needed:
- Eliminate TSID from login request and login response
- Use one of the bits in byte 1 of login request to indicate a leading
login, and update any text that refers to TSID=0 to refer to this bit
- Define session to be equivalent to I_T nexus (not "loosely equivalent
to")
- Define SSID/session ID to be the same as the I_T nexus identifier
- Remove the "LO" from TargetName
- If it hasn't already been done, remove the "LO" from InitiatorName

Comments?

Andre Asselin

                    John Hufferd                                                                                                      
                                         To:     Andre Asselin/Raleigh/IBM                                                            
                    10/31/2001           cc:     [email-masked]                                                                      
                    06:32 PM             From:   John Hufferd/San Jose/IBM@IBMUS                                                      
                                         Subject:     Re: is TargetName always mandatory or not?(Document link: Andre Asselin)        

                                                                                                                                      

Andre,
TSID, and therefore SSID is a handle that can be use to queue stuff within
the scope of the Initiator Node and Target Node.  The target can use what
ever it wants in this field.  Some Folks might want to use the TSID to be
the Portal Group Tag and I think then it might be unique.   But even then
only within the InitiatorName+ISID Space.  Anyway, you need to think of it
only as a handle.  Also since most folks will not have 64k Sessions into
their box, some (most?) implementations  might find it unique.  But it is
not unique in the Architecture.

Now the important thing is that, as things stand now, the Login needs the
InitiatorName, and the TargetName on the Initial Login of ALL Connections
in order to uniquely identify secondary Connections to the Original
Connection of the Session.

Does that seem correct to you and others on the Reflector?

.
.
.
John L. Hufferd

                Andre Asselin                          
                10/31/2001 03:00 PM                    

To:   John Hufferd/San Jose/IBM@IBMUS
cc:   [email-masked]
From: Andre Asselin/Raleigh/IBM@IBMUS
Subject:  Re: is TargetName always mandatory or not?  (Document link: John
      Hufferd)

John,

Andre Asselin

                    John Hufferd                                                                                                      
                                         To:     Andre Asselin/Raleigh/IBM@IBMUS                                                      
                    10/31/2001           cc:     [email-masked]                                                                      
                    04:42 PM             From:   John Hufferd/San Jose/IBM@IBMUS                                                      
                                         Subject:     Re: is TargetName always mandatory or not?(Document link: Andre Asselin)        

                                                                                                                                      

Andre,

.
.
.
John L. Hufferd

To:   [email-masked]

John & Julian,

John,

Andre Asselin

                    John
                    Hufferd/San          To:     Julian
Satran/Haifa/IBM@IBMIL

                    10/31/2001
                    04:20 AM

Julian,

.
.
.
John L. Hufferd

To:   [email-masked]
cc:

It is the leading login:

Julo

Andre Asselin

---

From: "Jim Hafner" <[email-masked]>
Date: Thu, 1 Nov 2001 12:39:51 -0800

Andre,

Your picture isn't quite right.  The portal group tag is relative to the
iSCSI target and that target is *uniquely* identified by it's name.  So, in
your picture, there are two targets (not one).  Each can label its target
portal group any way it wants (independent of the other).  Each has
independent control over the TSIDs it uses.  Each may *share* use of a
network portal, but that's a different issue.  The model implies two
independent targets (even if they live in the same network entity and share
resources) in your scenario.
In other words, the portal groups are wrt targets not the network entity.

In your scenario, whatever layer (you put it in the network code) has to
decide what session to add the connection to has the initiator name, the
ISID, the TSID *and* the target name (you left this out) in the login
request.  That fully qualifies both the target and the session as well.

Jim Hafner

                Andre Asselin                          
                11/01/2001 12:15 pm                    

To:   Jim Hafner/Almaden/IBM@IBMUS
cc:   [email-masked]
From: Andre Asselin/Raleigh/IBM@IBMUS
Subject:  Re: is TargetName always mandatory or not?  (Document link:
      Database 'Jim Hafner', View '($Inbox)')

Jim,

Andre Asselin

                    Jim Hafner                                                                                                        
                                         To:                                                                                          
                    10/31/2001           cc:                                                                                          
                    06:33 PM             From:                                                                                        
                                         Subject:     (Document link: Andre Asselin)                                                  

                                                                                                                                      

Andre,

Jim Hafner

John,

Andre Asselin

                    John Hufferd
                                         To:     Andre

Andre,

.
.
.
John L. Hufferd

To:   [email-masked]

John & Julian,

John,

Andre Asselin

                    John
                    Hufferd/San          To:     Julian
Satran/Haifa/IBM@IBMIL

                    10/31/2001
                    04:20 AM

Julian,

.
.
.
John L. Hufferd

To:   [email-masked]
cc:

It is the leading login:

Julo

Andre Asselin

---

From: "John Hufferd" <[email-masked]>
Date: Thu, 1 Nov 2001 13:38:16 -0800

Andre,
I think Jim has just answered your question on the use of portal groups.

In any event the wordage you point out in 3.12.9 is a bit loose.  When it
says: "The TSID is the target assigned tag ...." it is only implied that
the TSID is chosen in the context of the Target (iSCSI Target Node) and not
a iSCSI Network Entity.  Therefore, the implication that the code would
only need the TSID + ISID + InitiatorName to bind a connection to a
Session, is only valid in the context of a Specific iSCSI Target Node.  The
Fact that more then one iSCSI Target Node could be located in a iSCSI
Network Entity, means that the implementation needs more complete
information to direct the connection binding with the approprate Session
(and hence the approprate Target Node).

Depending on the implementation, it is probably possible to use the 64K
different possibilities to make the TSID unique across the entire iSCSI
Network Entity, but that is not a hard requirement of the protocol.

I do not mind having the TSID being left in, it can be most useful in many
(most) installations is sufficient as a unique qualifier with the ISID +
InitiatorName, but that is SIZE and implementation determined.

I think we need to update the wordage in 3.12.9 and other places to make
sure that everyone understands that TSID is only specified as being unique
in the setting of a specific iSCSI Node.  And we need to update the Draft
to ensure that Both the InitiatorName and TargetName are always used on all
non Discovery Connection Logins, and always on the Initial Login request of
each connection.

.
.
.
John L. Hufferd

                Andre Asselin                          
                11/01/2001 12:33 PM                    

John,

Comments?

Andre Asselin

                    John Hufferd                                                                   
                                         (Document link: Andre Asselin)                            

                                                                                                   

Andre,

.
.
.
John L. Hufferd

                Andre Asselin                          
                10/31/2001 03:00 PM                    

John,

Andre Asselin

                    John Hufferd                                                                   
                                         (Document link: Andre Asselin)                            

                                                                                                   

Andre,

.
.
.
John L. Hufferd

To:   [email-masked]

John & Julian,

John,

Andre Asselin

                    John
                    Hufferd/San          To:     Julian
Satran/Haifa/IBM@IBMIL

                    10/31/2001
                    04:20 AM

Julian,

.
.
.
John L. Hufferd

To:   [email-masked]
cc:

It is the leading login:

Julo

Andre Asselin

---

From: "Cunningham, Howard" <[email-masked]>
Date: Fri, 2 Nov 2001 04:45:43 -0800

Andre:

I apologize if I have missed something in this thread, but...

A non-zero TSID means either a connection re-start (X) bit or add a new
connection to an existing session. It seems to me ISID-TSID uniquely
determines the session, while a new CID (unique within the session only)
indicates a new connection.

In draft 8 section 3.12.9, it says:

	3.12.9 TSID 

        On a Login request a TSID value of 0 indicates a request to open a 
        new session. 
         
        A non zero TSID indicates a request to add a connection to an 
        existing session.

Regards...

-----Original Message-----
From: Jim Hafner [mailto:[email-masked]]
Sent: Thursday, November 01, 2001 3:40 PM
To: Andre Asselin
Cc: [email-masked]
Subject: Re: is TargetName always mandatory or not?

Andre,

Jim Hafner

                Andre Asselin                          
                11/01/2001 12:15 pm                    

Jim,

Andre Asselin

                    Jim Hafner

                                         To:

                    10/31/2001           cc:

                    06:33 PM             From:

                                         Subject:     (Document link: Andre
Asselin)                                                  

 

Andre,

Jim Hafner

John,

Andre Asselin

                    John Hufferd
                                         To:     Andre

Andre,

.
.
.
John L. Hufferd

To:   [email-masked]

John & Julian,

John,

Andre Asselin

                    John
                    Hufferd/San          To:     Julian
Satran/Haifa/IBM@IBMIL

                    10/31/2001
                    04:20 AM

Julian,

.
.
.
John L. Hufferd

To:   [email-masked]
cc:

It is the leading login:

Julo

Andre Asselin

---

From: "Jim Hafner" <[email-masked]>
Date: Fri, 2 Nov 2001 08:04:03 -0800

Folks,

I think this thread may be exposing either an ambiguity in the draft or
perhaps a gap.

I think it's possible to interpret the requirement that TargetName be
supplied (for normal sessions) only on the *first login message on the
first connection of a new session* and is not required on the *first login
message of subsequent connections intended for the same session". My
personal interpretation is that the TargetName is required on the *first
login message on every connection (in all cases, new session or adding
connections to existing sessions)*.  I also think Andre's example of a
network entity containing many iSCSI targets with shared network portals
(and the scoping of portal group tags and TSIDs by iSCSI target) points out
the need for the more restrictive requirement (and the rest of my response
to Andre assumed this).

But I've heard other comments that can be interpreted as the less
restrictive requirement is what is intended.

So, I suggest (and I don't think this is asking much) that the requirement
be that TargetName be supplied on the first Login message of every
connection (not just the leading one).

Jim Hafner

---

From: "John Hufferd" <[email-masked]>
Date: Fri, 2 Nov 2001 11:40:50 -0800

Julian,
I agree with Jim Hafner on this issue.  The Draft should say:

"The TargetName is required on the first login message on every connection
(in all cases, new session or adding connections to existing sessions)."

Also I think we need to change section 3.12.9, which currently says:

"The TSID is the target assigned tag for a session with a specific named
initiator that, together with the ISID uniquely identifies a session with
that initiator".

Should be changed to:

"The TSID is the target assigned tag for a session with a specific named
initiator that, together with the ISID 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)."

.
.
.
John L. Hufferd

Jim Hafner/Almaden/IBM@[email-masked] on 11/02/2001 08:04:03 AM

To:   [email-masked]
cc:
Subject:  RE: is TargetName always mandatory or not?

Folks,

Jim Hafner

---

From: "Andre Asselin" <[email-masked]>
Date: Fri, 2 Nov 2001 16:54:04 -0500

John,
     The wording you have below, I assume that is for the description of
TargetName in Appendix D, right?  If so, since TargetName isn't required
for a discovery session, could I suggest this wording instead?

        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.

Also, there are a few other places in the spec that need to be updated to
be consistent with TargetName being required in the leading login of all
normal sessions.

The current version of the 6th paragraph in chapter 5 reads:

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 at login
to indicate
        a discovery session. See chapter 5 for a more detailed description
of the login process.

Rationale for making the MUST lowercase: I think specs should state the
MUSTs, MAYs, and SHOULDs in only one place so that a requirement isn't
stated multiple times in slightly different language.  If the powers that
be disagree, then feel free to ignore my opinion...

Andre Asselin

                    John                                                                                                              
                    Hufferd/San          To:     Julian Satran/Haifa/IBM@IBMIL                                                        
                    Jose/IBM@IBMUS       cc:     Jim Hafner/Almaden/IBM@IBMUS, [email-masked]                                        
                    Sent by:             Subject:     RE: is TargetName always mandatory or not?                                      
                    owner-ips@ece.                                                                                                    
                    cmu.edu                                                                                                           

                    11/02/2001                                                                                                        
                    02:40 PM                                                                                                          

Julian,

Should be changed to:

.
.
.
John L. Hufferd

To:   [email-masked]
cc:

Folks,

Jim Hafner