Subject: Re: [NGO] external module properties

From: Andy Bierman <[email-masked]>
Date: Thu, 01 May 2008 15:30:50 -0700

Martin Bjorklund wrote:
> "Randy Presuhn" <[email-masked]> wrote:
>>> From: "Martin Bjorklund" <[email-masked]>
>>> How about adding an optional counter after the date?  So you can do
>>>
>>>   2008-04-29
>>>   2008-04-29:1
>>>   2008-04-29:2
>>>
>>> and so on.
>>>
>>> It removes the arbitrary timing constraint that worries Wes, and it's
>>> still simple enough for the common use case.
>> ...
>>
>> Even simpler - just use RFC 3339 date-time with the option of
>> abbreviating it to full-date.  That should be enough for even the
>> busiest believers in rapid prototyping.
> 
> That was my first thought as well, with the additional CLR to only use
> UTC, in order for simple string comparison to work.  But I thought a
> single integer would be simpler and do the job just fine.
> 
> If we do a single integer, we should use a dot instead of colon, as
> Andy suggested.
> 

I prefer the simple integer approach, but I can see how
others find the dateTime more 'standards-y'.

> /martin

Andy

_______________________________________________
NGO mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ngo

---

From: Andy Bierman <[email-masked]>
Date: Thu, 01 May 2008 15:44:42 -0700

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