RE: sming meeting minutes draft...

-----Original Message-----
From: Durham, David [mailto:[email protected]]
Sent: Monday, December 16, 2002 4:13 AM
To: [email protected]
Subject: sming meeting minutes draft...

Wes Hardaker presented SMIng enhancements that would be useful to his =
OOPS proposal:

[...]
There was a lot of discussion whether or not this is useful. [...] Andy =
made it clear we should only have one version of the SMI and not create =
the need to continually support two versions. There was no consensus in =
the room that this was a necessary or appropriate language mechanism. =
[...]=20

[dbh]
There's ambiguity in the text. "There was no consensus in the room that =
this ..." What is the "this" referring to? Wes's proposal, or Andy's =
response? A close reading of the text can resolve the ambiguity (I =
think), but the text would be clearer to simply change "this" to "Wes's =
proposal".
[end dbh]

Next, Wes suggests that smiv3 notifications should be able to contain =
structs and possibly even arrays. Currently only support for single =
objects. Example: would like to be able to send all addresses associated =
with linkup. It would be nice to support new notifications with more =
complex/complete data (like syslog). The limited data that snmpv3 =
notifications support is a reason why operators use prefer to use syslog =
instead of snmp. Wes is trying to define new PDUs to make access to new =
more complete structures easier. This affects smiv3 because =
notifications would now be able to support aggregate types instead of =
just base types, but this would not be backwards with snmpv3. There was =
more support in the room for this proposal over the rest, however, =
enabling backward compatibility w/ snmpv3 requires more thought.=20

[dbh]
We would likely run into the same problems trying to permit syslog type =
messages to be sent via snmp notifications as we hit with configuration. =
Syslog is tied to the complete management package (CLI, web-server, =
snmp, etc.), and syslog messages can be defined by the initial =
implementers of a device's functionality. Snmp is limited to passing =
defined snmp managed objects, and mibs are typically defined as a =
follow-on feature. If all we want to do is be able to send messages that =
are as useful as syslog messages, then all we neeed to do is define a =
notification that contains a syslog message, and NOT try to standardize =
what the semantics or format of the message content should be (i.e. use =
an OCTET STRING, compatible with syslog standards). When syslog =
standardizes the semantics and format of syslog messages, then the =
content of the SNMP notification would end up being standardized.=20

I think this can be done now and doesn't require a new PDU.
[end dbh]

Andy Bierman presents the SMIv3 Open issues:

* Oid naming for aggresgates and sub-aggregates:

How to tell you want to access row three down in the second nested =
array. DH suggested having a zero to apply on the left to distinguish =
the constant part from the instance identifier part. Other organizations =
my have oids with 0's in [their mib OIDs].

[dbh]
For example, the IEEE sometimes defines their own mibs, such as for the =
802.1X protocol. The OID of the IEEE 802.1 branch for mibs is { iso(1) =
std(0) iso8802(8802) ieee802dot1(1) ieee802dot1mibs(1)}, so every mib =
put out by the IEEE 802.1 group will have a zero in the OID.
[end dbh]

DD: Why not having a separate branch for all new SMIv3 structure. Having =
naming that is helpful to us instead of being in the way. If you have =
only one layer of nesting then it falls out that the indicies are on the =
right, because they are in the right place anyway. Bring this to the =
list, too complex to deal with now. Juergen previously had objections to =
putting the new definitions under a new branch, he thought it would =
break things.

[dbh]
Hi DD,=20

One of the objectives if the WG is to make the SMI more user-friendly. =
Think of navigating web sites. Is it easier for a human to navigate the =
web site if the information is organized hierarchically by content, or =
if it is organized based on some artifact of revision x.y of the HTML =
protocol standard? How many users would even know about the differences =
between revisions to the HTML protocol standard?=20

If we created a new branch under 1.3.6.1.2 for SMIv3 mibs, then do we =
require that vendors who are defining proprietary mibs using SMIv3 =
features craete a new branch under their enterprise-specific branch =
(1.3.6.1.4.1.<enterprise>.SMIv3? What if they had their branch nicely =
organized by product line? or organized by other content, such mib =
objects versus notifications versus A-C statements, etc.?=20

If we force them use a recognized (standardized) value for the SMIv3 =
sub-oid, what happens if it conflicts with a number they've already used =
under <enterprise>? If we don't force them to use a standardized =
sub-oid, how will SMIv3-capable engines know when they have entered an =
SMIv3-specific branch of the <enterprise> subtree?
[end dbh]



Existing MODULE-SOMPLIANCE macro won't work for SMIv3 objects.=20

[dbh] spelling error. [end dbh]