Re: [NGO] external module properties

Wes Hardaker wrote:
>>>>>> On Mon, 28 Apr 2008 08:16:46 -0700, Andy Bierman <ietf@andybierman.com> said:
> 
> AB> I believe 2 independent YANG implementations are deriving the version
> AB> from the most recent revision date.  In my code, the current date
> AB> will be used (for the internal version) if no revision clauses are
> AB> provided.
> 
> A numerical date meets my needs too...
> 
> I'd be tempted not to even define the required formatting of the version
> number.  Simply say it must be sortable using a standard comparison
> function (strcmp or >).
> 
> DNS does this with the SOA serial number.  The format is up to the
> network operator.  Some use date/time based serial numbers.  Some
> (especially those with > 256 pushes a day) use an incrementing number
> approach.  In the end, all the software that needs to look at the serial
> number is never confused: it just does a comparison to decide if their
> local copy is newer or older than the currently published zone file.
> 
> AB> The first order problem I want to solve is a standard mechanism
> AB> for distinguishing between multiple versions of the same module.
> 
> Do you mean multiple vendors publishing a single yang module?  How is
> that even possible (namespace definitions alone should take care of
> those conflicts think).
> 

No, I just mean mandatory revision clauses in YANG.
There must be some data within the module itself that
can be used to distinguish 2 different versions of
the same module.

We already have a single naming scope for module names.
There is no concept at all in YANG of the Acme FOO-MIB
and some other FOO-MIB.  There is just one FOO-MIB,
and any import (or include) which identifies FOO-MIB
in the target is referring to the one and only possible
module (within that implementation) called FOO-MIB.

The YANG spec is silent on finding the module associated
with an import or include.  That doesn't mean a robust,
interoperable, standards-based CM system can be silent on the issue.

>>> 2) How about we do the inverse of normal SMIv2 modules and optimize for
>>> the reader...  Most of this type of meta information, which I do
>>> agree is critical, isn't of huge interest to the average technical
>>> reader (which 99% of the time are trying to get to the technical
>>> cruft).  How about we put it at the bottom (or anywhere after the
>>> real data definitions)?
>>>
> 
> AB> I suppose a long list of revision statements gets in the way,
> AB> but not 1 or 2.  I would like to reserve the 'bottom' for the granular
> AB> conformance specification that is missing from YANG.
> 
> I don't really care how the bottom stuff is organized.  We likely have
> multiple sets of information that need to go into a YANG module.  Lets
> say that boils down to: technical stuff, an ever growing list of
> meta-data, conformance statements.  I don't care about the order beyond
> the fact I want the technical stuff to go first.  Because that's what
> 99% of the population cares the most about getting to.  Anything else
> gets in their way.
> 
> Now...  don't read into this that I'm proposing a CLR sorting rule.  I'm
> not.  I actually think the file should be more flexible in it's required
> ordering.  But IETF documents and the resulting YANGnits tool should
> suggest that non-technical sort of stuff needs to be lower in the
> document.  Which makes it a CLS (suggestion).

Andy

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