Re: [NGO] external module properties

[Wes Hardaker <wjhns1 at hardakers.net>]

>>>>> On Mon, 28 Apr 2008 08:16:46 -0700, Andy Bierman <ietf at 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).

>> 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).
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
NGO mailing list
NGO at ietf.org
https://www.ietf.org/mailman/listinfo/ngo