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

["Romascanu, Dan (Dan)" <dromasca at avaya.com>]

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

Dan


_______________________________________________
OPS-NM mailing list
OPS-NM at ietf.org
https://www1.ietf.org/mailman/listinfo/ops-nm