[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Notification Issue List -- DRAFT

Martin Bjorklund wrote:

Andy Bierman <ietf@andybierman.com> wrote:

Martin Bjorklund wrote:

Andy Bierman <ietf@andybierman.com> wrote:
...


I91)

- pg 14-15, XSD comments
  - should define the new verbs to be in the NETCONF base namespace and use
    the capability to determine whether to use it (like all other NC
operations)

But that means that rfc4741 has to be updated, right?  IMO it's
cleaner with separate namespace.



<xsd-rant>
For some definition of the word 'cleaner'.

I know from the protocol draft experience that we must modify our XML
to meet the capabilities of XSD, if ever the 2 are in conflict.
Unfortunately, XSD isn't very good at all at some things
that SNMP/SMI got right, like DM lifecycle, extensions, conformance...


I agree.  Don't use XSD for data modelling ;)


Yeah right. Tell the IESG that ;-)




What makes it worse is that there is no DM discovery mechanism
(like SNMP getnext), except for a <get> or <get-config> of the entire tree.
If the filter (subtree or Xpath) has any nodes at all in it,
then they must be in a particular namespace.  Therefore, all other
namespaces (mixed in the child nodes) will be skipped by the filter
because they don't match the namespace ID test.

At least in SMI, if you add an AUGMENTS or new table (in a new module)
later on, an NMS can find it with a getnext starting somewhere 'close by'
in the OID tree, (if the MIB is properly designed) like the module root.
NETCONF has a capabilities exchange, but these are technically just
capability URIs (like registration OIDs) and not namespace URIs.


These could be the same.  In fact, that's what we do all the time -
each loaded datamodel namespace URI is by default sent by the agent as
a capability.  So this is DM discovery.  This has nothing to do with
XSD though.



I am using the unofficial 'module URI'

 urn:ietf:params:netconf:capability:module:<owner-name>:<mod-name>:<mod-version>

 The namespace URI is auto-generated with the (owner, application, [version]) tuple,
 module.  A module is just a container of definitions.  It does not directly
 impact the data organization structure.  (Gee, another thing SMI got right.;-)

 What about adding 'module', 'namespace', and 'version' attributes to
 the <capability> element, to keep with the "do not parse URIs" CLR?

 What about a <get-version> operation to help figure out up-rev and down-rev
 incompatibilities at runtime?




Also, we're currently experimenting with something similar to
AUGMENTS, but in the XML you get back you will see the augmented data
where the base data is defined.  A small example:  DS0 augments the
ifEntry:

    <ifEntry>
      <ifIndex>1</ifIndex>
      ...
      <ifAlias>ds0 if</ifAlias>
      <ds0:ds0ChannelNumber>1</ds0:ds0ChannelNumber>



So every time we change or add a new bit of data to NETCONF,
it will have to be in a new XSD <schema> and with a new targetNamespace?
So by the time we have one tenth as many 'MIB objects' as SNMP,
we will have about 5000 different namespace URIs to deal with?


This problem isn't unique for NETCONF, and I think it has been solved
(it must be) for XSD in general.  A DM effort for NETCONF has to
consider this problem of course.



I don't think it has been solved in XSD.
(Anyone know, then send a pointer!).

I know people are working on alternatives to XSD ;-)
We would only have one programming language if every software project
had the same problem to solve.

If I was trying to solve an XML document editing problem,
I would use WEBDAV.  If I was trying to provide the most
comprehensive language to model XML instance documents,
I would use XSD.  But I'm working on a network management problem,
not an XML document problem.





Eventually, vendors will add their own hacks to undo the uselessness
of various XSD CLRs, like saving configs without defaults or ignoring
namespace processing rules.  What a mess...
</xsd-rant>

Andy




/martin



Andy

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