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

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Wed, 06 June 2007 12:48 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 1Hvuvs-0001wv-TL; Wed, 06 Jun 2007 08:48:12 -0400
Received: from ops-nm by megatron.ietf.org with local (Exim 4.43) id 1Hvuvr-0001wn-Vh for ops-nm-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 08:48:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvuvr-0001wf-M8 for ops-nm@ietf.org; Wed, 06 Jun 2007 08:48:11 -0400
Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvuvq-0001wG-5v for ops-nm@ietf.org; Wed, 06 Jun 2007 08:48:11 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by de307622-de-outbound.net.avaya.com with ESMTP; 06 Jun 2007 08:48:09 -0400
X-IronPort-AV: i="4.16,389,1175486400"; d="scan'208,217"; a="23848553:sNHT16041300"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF proposal
Date: Wed, 06 Jun 2007 14:47:28 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A040D8023@307622ANEX5.global.avaya.com>
In-Reply-To: <466686FF.3090906@jdscons.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF proposal
Thread-Index: AceoIlt8+hi60PIOQrK6rKB1RKK9nwAFivkg
References: <4664489B.1000406@andybierman.com> <02c901c7a7aa$ab924fc0$0600a8c0@china.huawei.com> <EDC652A26FB23C4EB6384A4584434A040D7E8D@307622ANEX5.global.avaya.com> <466686FF.3090906@jdscons.com>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Jon Saperia <saperia@jdscons.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407
Cc: Ops-Nm <ops-nm@ietf.org>
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>
Content-Type: multipart/mixed; boundary="===============1130395102=="
Errors-To: ops-nm-bounces@ietf.org

 
 
 
 


________________________________

	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
	 
	
	

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