RE: iSCSI: Send Targets and Report Portal Groups

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

> Reasons for not having it (others can add to this list):
> 1) Do not want discovery mechanism as part of the protocol.
> 2) It will continue to evolve and is not as simple as it seems.
> 3) IETF standards approving body will have a problem with it, 
> and this will
> delay the approval of the whole standard.
> 4) Can use SLP or iSNS to get the same functionality, and we 
> can piggyback
> on the future enhancements to these discovery protocols.

5)There is also the viewpoint that a transport protocol should contain only
what's necessary for establishing a transport link and keeping that link
functioning.  (eg, TCP connection establishment, SYN exchange) Any other
configuration data exchange is a management function that should use a
generic data exchange/mgmt protocol (SLP? DHCP? SNMP? XML?).  Or iSNS.
Given this purist viewpoint, there is a clear difference between the other
text commands in iSCSI and the SendTargets or ReportPortalGroups text
commands.

IMO, it's a judgement call where you draw the line between architectural
purity and practical functional encapsulation.  My current feeling is that a
limited SendTargets function adds a small amount of implementation burden
and a large amount of functional value to product solutions.  Given the
nature and deployment of storage devices, the reporting of minimal 'iSCSI
connectivity information' in the iSCSI protocol enables a powerful
capability for 'plug-n-play' at a minimal cost.  The fact that SLP and iSCSI
have different authentication models and points of control is a large factor
in support of SendTargets - authentication management is a huge burden for
customers.  (Of course that fact could start a whole nother thread cause
this is a common problem between various IP-based protocols).

ReportPortalGroups feels like feature-creep to me given that it's a subset
of SendTargets.

I agree with Mallikarjun, moving SendTargets to an 'annex' doesn't seem
appropriate when viewed thru his logic, and we should strip out fluff like
"TargetAlias", which is clearly 'value-add' more appropriate to a MIB or
some other management interface.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com