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

Hi,

I was referring to the separation of config and state data, as
described in RFC4741.
I do think the distinction made in rfc4741 is not very clear, so work
would need to be done.

Would this result in duplication of information? Without a draft
making a specific proposal for this, I cannot say. It might.

dbh

> -----Original Message-----
> From: Jon Saperia [mailto:[email protected]] 
> Sent: Wednesday, June 06, 2007 8:52 AM
> To: Romascanu, Dan (Dan)
> Cc: David Harrington; Andy Bierman; Ops-Nm
> Subject: Re: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF proposal
> 
> Thanks for the clarification, lets see what Dave says.  If it 
> is as you 
> say, then I would say what is the justification for introducing 
> duplication of information?
> /jon
> 
> Romascanu, Dan (Dan) wrote:
> >  
> >  
> >  
> >  
> >
> >
> > ________________________________
> >
> > 	From: Jon Saperia [mailto:[email protected]] 
> > 	
> >
> > 			XML-based management leverages lessons learned
> > from the WWW. 
> > 			While document-based rather than
command-based,
> > tasks can 
> > 			often be grouped into a document-type
interface,
> > such as a 
> > 			web page. With automated translation from XML
> > into HTML (and 
> > 			related technologies), we can work on
developing
> >
> > 			task-based-document NM interfaces. 
> > 			
> > 			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. 
> > 		  
> >
> >
> > 	I have seen a couple of references in the discussion to State
> > and netconf.  Can we be more specific about what we mean by 
> state here.
> > Configuration state?  When I think of other types of state such as
> > operational state or quality state I think of either read 
> MIB objects or
> > notifications (traps/informs).
> > 	[DR]  
> > 	[DR] My interpretation was state as in state of the system
which
> > is the super-set of configuration state, but not limited to
> > configuration state. It is David however who introduced the 
> term in the
> > thread, so I would rather have him answer. 
> > 	 
> > 	Dan
> > 	 
> > 	
> > 	
> >
> >
> >   
> 
> -- 
> Jon Saperia
> (cell) 617-201-2655
> (Eve.) 978-461-0264
> 
> 




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