RE: Relational, hierarchical and flat

["Hunkins, Andrew" <ahunkins@unimax.com>]

We deal primarily with voice communications systems which contain a
large amount of user content which is highly relational in nature.
Certain well known manufacturers of voice equipment (names kept
anonymous to protect the innocent) have chosen to put LDAP front ends on
their systems as a scriptable adjunct to the CLI.  This has failed in
every case because LDAP is good at representing hierarchical information
but not relational.  And like SNMP, it does not support "methods", so
you really have access to the data only; it's difficult to perform
"functions".

XML can be used to encode an access protocol, or it can be used to
encode the content.  netconf does not expect or enforce any particular
content encoding, but still suggests XML is the "lingua franca" for
hierarchical content encoding.  I think using XML for the content
encoding will create similar problems created by attempts to cocoon
systems behind LDAP.  And I still think static configuration files will
fade as an acceptable approach; complexity is growing so quickly that we
must rely on scripting *rules and policies* for dynamic configuration,
not scripting a static configuration.  I don't think caching these files
for any significant time will remain useful.  But you mentioned this
before and I'm interested in your ideas on caching.

Another byproduct of relational content is that most of the properties
in each object (fields in each table, if you like) are keys to another
table.  This creates a problem for a human user at a CLI because all the
content they need to push into the configuration are just keys into
other tables.  The behavior of the same key value can be completely
different from one device to the next -- devices which have the
identical hardware and system software.  This is very difficult to do in
your head!  Yes, you can convert the relational data (if 3NF) into it's
hierarchical equivalent or flat equivalent, but this is extremely
expensive, especially for validation.  And yes, as script writers, tools
can be used to look up the values from the other tables, but then we're
back to my argument that we should not try to support human interaction
directly but allow CLIs or UIs to be built on top of netconf.

...so to answer your question, we've found that SQL/ODBC with SOAP works
really well.  All the transport, security and authentication stuff has
been developed de facto underneath.  The SQL/ODBC gives you great data
access and SOAP gives you access to functions and methods.  And it's
very easy to whip together some VB or Java or whatever to create a CLI,
web-based UI or whatever you want.

Is SQL/ODBC with SOAP too heavy for very small clients?  Yes, but it
sounds to me like a lot of what we're talking about here won't be cheap
either.  Multiple interfaces without a common conduit?!  SNMP uses
proxies for very small elements.  Have we discussed proxies?

I support the SOAP discussion.

-Andrew


> -----Original Message-----
> From: Eliot Lear [mailto:lear@cisco.com]
> Sent: Wednesday, June 18, 2003 5:02 PM
> To: Hunkins, Andrew
> Cc: Juergen Schoenwaelder; netconf@ops.ietf.org
> Subject: Re: Relational, hierarchical and flat
> 
> 
> Hunkins, Andrew wrote:
> > Do we want to be good at accessing relational, hierarchical and flat
> > content?  or only one or two of these?
> 
> I think that's a fair question.  What do you think?
> 
> Eliot
> 
> 
> 

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>