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


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

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.

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?

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>




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