RE: sming meeting minutes draft...

["Durham, David" <david.durham@intel.com>]

Thanks David,

I've incorporated your feedback. 

I find it interesting that to address complex notifications you are talking
about structured string formats. It always seems to come back to structured
string formats in PDUs, doesn't it? 

Thanks for your reaction to DD's suggestion to use alternative branches for
smiv3 oids. We didn't have time in the meeting to discuss, I agree with you
that these new roots introduce too much complexity.

-Dave

> -----Original Message-----
> From: Harrington, David [mailto:dbh@enterasys.com]
> Sent: Monday, December 16, 2002 7:15 AM
> To: Durham, David; sming@ops.ietf.org
> Subject: RE: sming meeting minutes draft...
> 
> 
> -----Original Message-----
> From: Durham, David [mailto:david.durham@intel.com]
> Sent: Monday, December 16, 2002 4:13 AM
> To: sming@ops.ietf.org
> 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.
> [...]
> 
> [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.
> 
> [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.
> 
> 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,
> 
> 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?
> 
> 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.?
> 
> 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.
> 
> [dbh] spelling error. [end dbh]