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

"David Harrington" <ietfdbh@comcast.net> Wed, 06 June 2007 13:07 UTC

Return-path: <ops-nm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvvEw-0005an-Hl; Wed, 06 Jun 2007 09:07:54 -0400
Received: from ops-nm by megatron.ietf.org with local (Exim 4.43) id 1HvvEv-0005ai-D0 for ops-nm-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 09:07:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvvEv-0005aZ-3T for ops-nm@ietf.org; Wed, 06 Jun 2007 09:07:53 -0400
Received: from sccrmhc15.comcast.net ([63.240.77.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvvEu-0006Ws-S7 for ops-nm@ietf.org; Wed, 06 Jun 2007 09:07:53 -0400
Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc15) with SMTP id <2007060613075201500cedh1e>; Wed, 6 Jun 2007 13:07:52 +0000
From: David Harrington <ietfdbh@comcast.net>
To: 'Ops-Nm' <ops-nm@ietf.org>
References: <4664489B.1000406@andybierman.com> <02c901c7a7aa$ab924fc0$0600a8c0@china.huawei.com> <EDC652A26FB23C4EB6384A4584434A040D7E8D@307622ANEX5.global.avaya.com> <466686FF.3090906@jdscons.com> <EDC652A26FB23C4EB6384A4584434A040D8023@307622ANEX5.global.avaya.com> <4666ADF5.8010008@jdscons.com>
Subject: RE: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF proposal
Date: Wed, 06 Jun 2007 09:07:43 -0400
Message-ID: <038e01c7a83b$ab683aa0$0600a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <4666ADF5.8010008@jdscons.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: AceoOYTrUjnoPSF1R1yw7fJXgAZ0twAAMuhQ
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7
X-BeenThere: ops-nm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: OPS Area NM e-mail list <ops-nm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ops-nm>, <mailto:ops-nm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ops-nm>
List-Post: <mailto:ops-nm@ietf.org>
List-Help: <mailto:ops-nm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ops-nm>, <mailto:ops-nm-request@ietf.org?subject=subscribe>
Errors-To: ops-nm-bounces@ietf.org

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:saperia@jdscons.com] 
> 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:saperia@jdscons.com] 
> > 	
> >
> > 			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
OPS-NM@ietf.org
https://www1.ietf.org/mailman/listinfo/ops-nm