RE: iSCSI: Canonical Targets

["CONGDON,PAUL (HP-Roseville,ex1)" <paul_congdon@hp.com>]

This seems like a reasonable proposal to me, with the following comments.

> 
> 4. A device containing a single target MUST provide both the
>    canonical target and the real target.  (This is implied by the
>    above requirements).
> 
>    An initiator connecting to such a device using only its IP address
>    would first connect to the canonical target, and use SendTargets
>    to obtain the iSCSI name of the real target.  It would then create
>    a separate session to the real target.  Essentially, this means
>    there's nothing special about a single-target device. 

There needs to be an explicit SHOULD for the initiator.  While I see
value in having the initiator always follow a specific set of steps
to establish a full feature session, it seems a bit harsh to require
the a two step process when the initiator may very well know who it
should connect to.

> 
> 6. We can further specify the order in which the SendTargets response
>    fields are returned, to simplify things further, e.g. each target
>    in the SendTargets response MUST return these fields in this order:
> 
>    - A TargetName= field
>    - A TargetAlias= field (value left blank if there's no alias)
>    - One or more TargetAddress= fields
>    - Any vendor-specific fields (ignored by standard initiators)
>

The above fields should be considered a 'record' and should not be 
split across multiple PDUs if we decide upon an iterator.  Personally,
I think the idea of only allowing SendTargets on this session eliminates
the need for an iterator and is a good direction to take.  A complete
'record' should always be return for each target in the list.  This
'record' must include the name, address and alias, but the alias
value can be left blank as described above.

The concept of this 'record' should also be used in Login-response
PDUs in the case of Target Moves or Redirects.  Again, the complete
record should be returned.  Note that this allows the ability to
redirect the login to a completely different target.  Not something
that is currently possible, but would be valuable.  In the current
Login-response only a TargetAddress field needs to be returned, but 
instead it should specify an entire target record.

> Additional questions to send input on:
> 
> 1. Should a non-canonical target respond to a SendTargets command?
> 
> 2. If so, should it respond only with addresses for its own target,
>    or should it respond with other targets, as a canonical target
>    might do?

It should be allowed to respond with the complete target 'records' for
other targets that this initiator has access to if it so desires.  There
is no reason to restrict this.

Paul

+--------------------------+----------------------------+
+ Paul Congdon             + Email: paul_congdon@hp.com +
+ Hewlett Packard Company  + Mail Stop:  5662           +
+ HP ProCurve Networking   + Phone:  (916) 785-5753     +
+ 8000 Foothills Blvd      + Fax:    (916) 785-5949     +
+ Roseville, CA   95747    + Mobile: (916) 765-4056     +
+--------------------------+----------------------------+