RE: sming meeting minutes draft...

Hi,

Structured string formats seem to be fairly popular with operators, if =
the current use of CLI and syslog, and the expectation that XML will be =
useful, are any indication.

dbh

> -----Original Message-----
> From: Durham, David [mailto:[email protected]]
> Sent: Monday, December 16, 2002 4:27 PM
> To: Harrington, David; [email protected]
> Subject: RE: sming meeting minutes draft...
>=20
>=20
> Thanks David,
>=20
> I've incorporated your feedback.=20
>=20
> I find it interesting that to address complex notifications=20
> you are talking
> about structured string formats. It always seems to come back=20
> to structured
> string formats in PDUs, doesn't it?=20
>=20
> Thanks for your reaction to DD's suggestion to use=20
> alternative branches for
> smiv3 oids. We didn't have time in the meeting to discuss, I=20
> agree with you
> that these new roots introduce too much complexity.
>=20
> -Dave
>=20
> > -----Original Message-----
> > From: Harrington, David [mailto:[email protected]]
> > Sent: Monday, December 16, 2002 7:15 AM
> > To: Durham, David; [email protected]
> > Subject: RE: sming meeting minutes draft...
> >=20
> >=20
> > -----Original Message-----
> > From: Durham, David [mailto:[email protected]]
> > Sent: Monday, December 16, 2002 4:13 AM
> > To: [email protected]
> > Subject: sming meeting minutes draft...
> >=20
> > Wes Hardaker presented SMIng enhancements that would be=20
> useful to his
> > OOPS proposal:
> >=20
> > [...]
> > There was a lot of discussion whether or not this is=20
> useful. [...] Andy
> > made it clear we should only have one version of the SMI=20
> and not create
> > the need to continually support two versions. There was no=20
> consensus in
> > the room that this was a necessary or appropriate language=20
> mechanism.
> > [...]
> >=20
> > [dbh]
> > There's ambiguity in the text. "There was no consensus in=20
> 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=20
> "this" to "Wes's
> > proposal".
> > [end dbh]
> >=20
> > Next, Wes suggests that smiv3 notifications should be able=20
> to contain
> > structs and possibly even arrays. Currently only support for single
> > objects. Example: would like to be able to send all=20
> 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=20
> to use syslog
> > instead of snmp. Wes is trying to define new PDUs to make=20
> access to new
> > more complete structures easier. This affects smiv3 because
> > notifications would now be able to support aggregate types=20
> instead of
> > just base types, but this would not be backwards with=20
> 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=20
> syslog type
> > messages to be sent via snmp notifications as we hit with=20
> 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=20
> messages that
> > are as useful as syslog messages, then all we neeed to do=20
> is define a
> > notification that contains a syslog message, and NOT try to=20
> standardize
> > what the semantics or format of the message content should=20
> 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]
> >=20
> > Andy Bierman presents the SMIv3 Open issues:
> >=20
> > * Oid naming for aggresgates and sub-aggregates:
> >=20
> > 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=20
> distinguish
> > the constant part from the instance identifier part. Other=20
> organizations
> > my have oids with 0's in [their mib OIDs].
> >=20
> > [dbh]
> > For example, the IEEE sometimes defines their own mibs,=20
> such as for the
> > 802.1X protocol. The OID of the IEEE 802.1 branch for mibs=20
> is { iso(1)
> > std(0) iso8802(8802) ieee802dot1(1) ieee802dot1mibs(1)}, so=20
> every mib
> > put out by the IEEE 802.1 group will have a zero in the OID.
> > [end dbh]
> >=20
> > DD: Why not having a separate branch for all new SMIv3=20
> structure. Having
> > naming that is helpful to us instead of being in the way.=20
> If you have
> > only one layer of nesting then it falls out that the=20
> 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=20
> objections to
> > putting the new definitions under a new branch, he thought it would
> > break things.
> >=20
> > [dbh]
> > Hi DD,
> >=20
> > One of the objectives if the WG is to make the SMI more=20
> user-friendly.
> > Think of navigating web sites. Is it easier for a human to=20
> navigate the
> > web site if the information is organized hierarchically by=20
> content, or
> > if it is organized based on some artifact of revision x.y=20
> of the HTML
> > protocol standard? How many users would even know about the=20
> differences
> > between revisions to the HTML protocol standard?
> >=20
> > If we created a new branch under 1.3.6.1.2 for SMIv3 mibs,=20
> 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=20
> 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=20
> 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=20
> entered an
> > SMIv3-specific branch of the <enterprise> subtree?
> > [end dbh]
> >=20
> >=20
> >=20
> > Existing MODULE-SOMPLIANCE macro won't work for SMIv3 objects.
> >=20
> > [dbh] spelling error. [end dbh]
>=20
>=20