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
- [OPS-NM] Comments on XSDMI BoF proposal Andy Bierman
- RE: [OPS-NM] Comments on XSDMI BoF proposal David Harrington
- RE: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF… Romascanu, Dan (Dan)
- Re: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF… Jon Saperia
- RE: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF… Romascanu, Dan (Dan)
- Re: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF… Jon Saperia
- RE: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF… David Harrington
- RE: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF… David Harrington
- Re: [OPS-NM] Comments on XSDMI BoF proposal Andy Bierman
- Re: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF… Andy Bierman
- Re: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF… Jon Saperia
- Re: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF… Andy Bierman
- Re: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF… Jon Saperia
- RE: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF… Romascanu, Dan (Dan)