Re: Notification Issue List -- DRAFT

[Martin Bjorklund <mbj@tail-f.com>]

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 ;)

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

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.


> 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


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