Subject: LDAP and XML

From: [email-masked]
Date: Thu, 12 Apr 2001 03:43:20 -0400

Doug,

With my WG co-chair hat on ... this thread needs to
stop, because Marjorie's offer to include LDAP in
addition to XML as an example is reasonable, and is
all that needs to be done for the iSCSI requirements
draft.  Among the examples of the use of XML for
management software is the XML dialect of CIM used
by both DMTF and SNIA, and CIM can clearly be extended
to include iSCSI.  Hence the suggestion that XML be
removed as an inappropriate example is hereby
rejected.  The inclusion of XML as an example
does not obligate the WG to develop an XML schema
any more than inclusion of LDAP would obligate
the WG to develop an LDAP schema.  FWIW, use of
XML does not require a "database" - e.g., some
of the data retrieved by SNMP from the MIB could
also be encoded in XML for retrieval via HTTP.

Comments from others who feel this topic is important
are welcome, but Doug's well-known opinion on LDAP is
noted and should not be repeated on the list in
discussion of the iSCSI requirements draft prior to
the interim meeting.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From:	Douglas Otis [SMTP:[email-masked]]
> Sent:	Wednesday, April 11, 2001 9:33 PM
> To:	KRUEGER,MARJORIE (HP-Roseville,ex1); [email-masked]
> Subject:	RE: iSCSI Naming: WWUIs, URNs, and namespaces
> 
> Marjorie,
> 
> Although there is nothing within requirements documentation regarding how
> an
> XML database scheme is used within an iSCSI architecture, there must be
> some
> relationship either directly or indirectly or it does not belong.  The
> aspect of using this database is unclear, so your views in this area are
> welcome in relating the function you understand this database fulfilling.
> I
> simply said there must be some way to find this service with a substratum
> of
> XML in whatever form it takes.  This service should be comprehensive and
> provide SCSI related items to allow a client, directly or indirectly, the
> means for successful communication using iSCSI.  I did not indicate this
> would be used as a discovery tool, but rather there would need to be such
> a
> means in place to allow its use.  Centralized data removes the abstraction
> server concept that has been found objectionable.  I was attempting to
> view
> such data in that light.
> 
> Doug
> 
> > > There is a need to obtain iSCSI configuration information in
> > > a generalized
> > > way.  This information should allow the client to find the
> > > server using
> > > existing IP namespace information.
> > ..snip..
> >
> > >
> > > Marjorie had mentioned that some are considering XML to support this
> > > function.  You will need some way to find this service.
> >
> > You misread that paragraph in the iSCSI Requirements document.  There
> has
> > been no assertion that storage devices will use XML to discover
> > each other!
> > To quote the requirements document:
> >
> > "... Development of specifications for iSCSI device management as
> > MIBs, XML
> > schemas, etc"
> >
> > Device management is much different (and entirely separate) from service
> > discovery and authentication.  Naming is an a construct for
> > identity, which
> > is necessary for authentication.
> >
> > Marj
> >

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 12 Apr 2001 13:11:57 -0700

David,

In my defense, whatever the database and whatever the function, it must be
related to the iSCSI architecture for it to belong within the IPS efforts.
This was a premise and not a request.  The comment was addressing a larger
concern of use of this information and not the underlying mechanism.  The
point you seem to have missed although you will likely not agree is that
having information abstracted through multiple servers is likely the area
causing greater concern with respect to namespace.  That was the issue
within this thread I was addressing.  I am not sure what you're reacting to
except perhaps a misunderstanding of a general premise that I suspect you
agree with however.

On a prior occasion I indicated a concern I had regarding inclusion of a
schema within the requirements document as a related function was not
discernable and was seeking insight.  Even DMTF CIM standard security
requires the now unmentionable.  Am I wrong about the over-shadowing concern
of a naming server?  The comment made by Marjorie concerning IESG/IAB as it
relates to this was:

- Description: How the syntax is documented and the resulting
suggestions/implications for its use.

- Syntax: How those identifiers are represented in messages and related
issues of control over use and extension of that representation.

- Semantics: Unique identifiers, global scope, not tied to communication
endpoints.

Could you provide your understanding of how this relates to the current
architecture.  My take on these comments is to remove any new abstraction
server akin to DNS in a communication protocol.  The furtherance of that
would then imply a comprehensive means of obtaining information without this
additional abstraction layer.  In addition to providing an out-of-band
signal, what other function is disrupted with this type of change?

Doug