RE: [OPS-AREA] RE: Comments on XSDMI BoF proposal

=20
=20

> -----Original Message-----
> From: David Harrington [mailto:[email protected]]=20
> Sent: Wednesday, June 06, 2007 6:48 PM
> To: 'Ops-Nm'
> Subject: RE: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF proposal
>=20
>=20
>  Hi,
>=20
> Dan, Thanks for changing the list.
>=20
> > See in-line a few comments from a contributor perspective.=20
> >=20
> > Dan
> =20
> > > I think we need to spend more time thinking about operator=20
> > > use-cases, not just technical designs of SMIs. I think it=20
> would help=20
> > > to start thinking in terms of modular data models similar to MIB=20
> > > modules, not just a <running> config,  but we need to=20
> develop an SMI=20
> > > that helps to differentiate config and state info, which SMIv2=20
> > > doesn't do, Maybe all we need to do is recommend that MIB modules=20
> > > have separate subtrees for config and for state, much as we now=20
> > > recommend separate subtrees for objects and notifications.
> >=20
> > Maybe, but at this point in time all the base of standard=20
> MIB modules=20
> > is not designed this way. What are we going to do, re-write=20
> these MIB=20
> > modules, or part of them? This does not seem an achievable task.
>=20
> SMIv1 MIB modules did not organize notifications in a=20
> separate subtree, and it wasn't even done in the earlier=20
> SMIv2 MIB modules.
> Over time (about twelve years), we have migrated MIB design=20
> in that direction.=20
>=20
> There has been strong demand from operators for a distinction=20
> between config and state data.
> >From operator requirements documented in RFC3535:=20
>=20
>    3.  It is required to be able to fetch separately=20
> configuration data,
>        operational state data, and statistics from devices, and to be
>        able to compare these between devices.
> =20
> Now would seem a good time to establish new guidelines about=20
> how to differentiate these, so over time, existing MIB=20
> modules can be migrated in that direction. Or we could just=20
> provide guidelines for XML-based representations, and migrate=20
> away from SMIv2 to the XML-based schemas for SNMP as well.=20
> Now is the time when we have a "destructive technology shift"=20
> under way from ASN.1 to XML, that could provide a good=20
> opportunity for starting the gradual re-definition of=20
> existing MIB modules, based on the lessons learned over the=20
> past twenty years.
>=20
> So I think the separation is an achievable task, just not a=20
> short-term task. We could try to define some guidelines as a=20
> short-term task, but that is not part of this BOF.


Sure, if we are talking about a mid-long term task we are in agreement.=20

Dan


_______________________________________________
OPS-NM mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ops-nm