Re: [NGO] external module properties

Hi,

So there are two questions to answer that might require different
solutions.
1) are these two versions the same or different?
2) which is newer?

The first is simply a "do the verson identifier match?" 
The second requires a standard progression mechanism, such as rev1.2
vs. rev2.1 or a standardized format for the revision date. And if you
are going to compare strings, then we need to pay attention to
character sets, etc.

Which use cases are we trying to address?

dbh

> -----Original Message-----
> From: ngo-bounces@ietf.org [mailto:ngo-bounces@ietf.org] On 
> Behalf Of Wes Hardaker
> Sent: Tuesday, April 29, 2008 11:05 AM
> To: Andy Bierman
> Cc: NETCONF Goes On
> Subject: Re: [NGO] external module properties
> 
> >>>>> 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).
> 
> >> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/ngo
> 

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