RE: iSCSI Discovery and SendTargets

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

Mark and NDT team,

Nice write-up of your discussions.  In summary I would like to strongly
support the position of option 1 in your memo, which is keeping SendTargets
as-is with the few minor modifications to support aggregation tags, but not
much else.  We do need to contain the scope of SendTargets, but removing it
from the spec would be a tremendous loss of a very simply yet powerful
feature.  My supporting comments are as follows:

1. Keeping SendTargets basically as-is, but with the addition of aggregation
tags is a very small increment over what must already be implemented for
general iSCSI login, authentication and text processing.  It is basically
just another text command that has very wide spread utility.  

2. The fact that a discovery session, where SendTargets can be performed,
uses the exact same authentication and login mechanisms is a fundamental
benefit of the scheme.  Alternatives will require their own (albeit similar)
implementations for authentication.  Deploying, configuring and maintaining
AAA infrastructure has always been a stumbling block for customers and
complicating this with additional protocols and clients will not help
matters.

3. The complication of an iterator can be avoided if we restrict the usage
of SendTargets to a session on a well-known target or clearly document the
potential issues of blocking a connection in an implementation.  However, I
would support the definition of an iterator if there is consensus.  This is
not a show-stopper.

4. Splitting SendTargets into multiple commands (ReportTargets and
ReportPortalGroups) seems unnecessary and not relevant.  I have not heard
the entire discussion surrounding ReportPortalGroups, but it would seem that
this information would be better reported via the MIB or at least should be
made available via the MIB.  Even if there is a need for such a command then
it appears to be an entirely separate issue.

5. Enhancing SendTarget responses to include additional information
regarding certificates or boot related information appears to be in the
category of 'creeping elegance' and does not to need to be considered at
this time.  Facilities will be in place to establish the session needed to
perform SendTargets anyway, and returning additional information that allows
one to avoid using these facilities is purely an optimization.

6. An example of SendTarget's power and simplicity (as-is) is the ability to
use it to create a SendTargets tree as you've described.  There is really
nothing that "needs" to be changed from the current scheme to support this
behavior.  This is a perfect example of how the very same mechanism can be
used to 'scale' in environments from very small plug-and-play workgroups to
a large centrally administered, highly secured, enterprises.

So, from an expediency and philosophical perspective I believe we should
implement SendTargets now and contain the number of proposed changes to keep
it as simply as possible.  We should NOT move this to another document,
since it is really just another text command, but a very powerful one at
that.

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     +
+--------------------------+----------------------------+