Subject: snmpconf issue #1: language versioning

From: Wes Hardaker <[email-masked]>
Date: 02 Apr 2001 12:23:24 -0700

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

---

From: Steve Waldbusser <[email-masked]>
Date: Tue, 03 Apr 2001 01:35:35 -0700

Wes,

  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).

Steve

---

From: Wes Hardaker <[email-masked]>
Date: 03 Apr 2001 17:30:29 -0700

>>>>> On Tue, 03 Apr 2001 01:35:35 -0700, Steve Waldbusser <[email-masked]> said:

Steve> In the Pittsburgh meeting we agreed to #2 except that we
Steve> wouldn't bother registering the initial version of the
Steve> language. If we make a modification we would register that
Steve> version. Nobody's going to put capMatch(version1) at the
Steve> beginning of every script particularly when there's only 1
Steve> version (and we wouldn't want to lead people to believe they
Steve> should). When the second version comes out and you want to use
Steve> features from it, you can first test with capMatch(version2).

Ahh.  No one mentioned that at the last meeting when I brought it up.

Anyway, thats fine by me.  I can't think of any reason to force a v1
registration.  The only vague answer I can come up with is that if a
manager was querying a cap table to see what version of a script to
upload, it wouldn't have to match against every known version type to
determine if it was a v1 script engine.  Minor minor point though.

-- 
Wes Hardaker
NAI Labs
Network Associates