[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf issue #1: language versioning
In the Pittsburgh meeting we agreed to #2 except that we wouldn't
bother registering the initial version of the language. If we make a
modification we would register that version. Nobody's going to put
capMatch(version1) at the beginning of every script particularly when
there's only 1 version (and we wouldn't want to lead people to believe
they should). When the second version comes out and you want to use
features from it, you can first test with capMatch(version2).
Wes Hardaker wrote:
> Options if we want to specify versioning:
> 1) don't. (ie, leave things as they are). I think everyone agrees
> that at least some form of versioning statement should be made.
> 2) Register the language version as a capabilities statement in the
> capabilities Table, and define a version OID elsewhere in the MIB
> dictating that this OID should be registered there if it supports
> this version of the document. If future modifications were made to
> the language in an incompatible way, a new version of the OID
> should probably created. Because of this, I'd recommend having the
> OID created be a root of an individual base such that we have
> something ending in ....pmVersionNumber.version1
> 3) Have a scalar (somewhere) indicate the language version number
> supported by the application.
> My opinion: #2 is the right way to go (plus it gives us a good example
> to use for the capabilities table).
> Wes Hardaker
> NAI Labs
> Network Associates