Subject: RE: iSCSI: Send Targets and Report Portal Groups

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Thu, 7 Jun 2001 15:25:57 -0700

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

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 7 Jun 2001 17:12:48 -0700

Marjorie,

This leads to feature creep where eventually all management is placed upon
the transport.  Any such management at this point will still need to come
from some other management scheme or this does not allow for promulgation or
coherency and will lead to vendor unique solutions.  I would be in favor of
removing as much away from the transport and instead converge on an existing
management server.  I would hope the signaling desired could be done by
those entities that either identify or instrument a change and then those
entities signal effected servers of these changes.

Doug

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> KRUEGER,MARJORIE (HP-Roseville,ex1)
> Sent: Thursday, June 07, 2001 3:26 PM
> To: [email-masked]
> Subject: RE: iSCSI: Send Targets and Report Portal Groups
>
>