Re: [NGO] external module properties

[Andy Bierman <ietf at andybierman.com>]

Ladislav Lhotka wrote:
> Andy Bierman píše v Út 29. 04. 2008 v 12:16 -0700:
> 
>> Excellent point.
>> I am envisioning a system which includes a mandatory standard
>> 'schema-discovery' mechanism.  The <hello> exchange is a bad
>> place for all this versioned module to namespace mapping info
>> (even though that's exactly what I have implemented now ;-)
> 
> Why is it so bad? The big advantage I see is that it works with the
> existing NETCONF framework.
> 
>> The namespace URI should be stable.  It is assigned in
>> the first version of the module.  It can never change.
>> If the module is obsolete, the namespace is still 'used up',
>> and can never be reused in another module.
>>
>> In XSD, the <schema> 'version' attribute should be used in addition
>> to the targetNamespace, to determine the exact schema content.
>> In YANG, each new version of a module (std:MUST/vendor:SHOULD)
>> include a new revision-stmt, which has a date string which becomes
>> the new version identifier.
> 
> RELAX NG has no such attribute and nobody seems to be complaining.
> Version numbers are indeed encoded in namespace URIs. In my view, the
> revision statement could be interpreted as an auxiliary version marker
> intended for human readers - the only authoritative identifier of a YANG
> module content would be the URI.
> 

The problem with this approach is that is it very API-unfriendly
for NM devices.  Consider dozens of NETCONF applications
that are all using FOO-MIB with namespace "foo-mib-1".
If an agent implementing a new version changes the namespace
to "foo-mib-2", all the applications that are currently
using "foo-mib-1" will break, when talking to that agent.

Since NM modules are only allowed to change in backward-compatible
ways, and since breaking existing applications to deploy new ones
is not acceptable, it is actually harmful to change the namespace URI.

If the FOO-MIB needs to be changed such that it breaks existing APIs,
then a new module must be defined instead, with a new name and
a new namespace.


> Lada
> 

Andy


_______________________________________________
NGO mailing list
NGO at ietf.org
https://www.ietf.org/mailman/listinfo/ngo