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

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Wed, 06 June 2007 05:57 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 1HvoW5-0000wv-Eh; Wed, 06 Jun 2007 01:57:09 -0400
Received: from ops-nm by megatron.ietf.org with local (Exim 4.43) id 1HvoW4-0000wn-8F for ops-nm-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 01:57:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvoW3-0000wf-S1 for ops-nm@ietf.org; Wed, 06 Jun 2007 01:57:07 -0400
Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvoW1-0007Ng-3w for ops-nm@ietf.org; Wed, 06 Jun 2007 01:57:07 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-outbound.avaya.com with ESMTP; 06 Jun 2007 01:57:04 -0400
X-IronPort-AV: i="4.16,388,1175486400"; d="scan'208"; a="25615866:sNHT12262854"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF proposal
Date: Wed, 06 Jun 2007 07:56:29 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A040D7E8D@307622ANEX5.global.avaya.com>
In-Reply-To: <02c901c7a7aa$ab924fc0$0600a8c0@china.huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF proposal
Thread-Index: AcemzA59oB5ulVZRR7W5+F6lyv4NKQAzMFkAABh/jXA=
References: <4664489B.1000406@andybierman.com> <02c901c7a7aa$ab924fc0$0600a8c0@china.huawei.com>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: David Harrington <ietfdbh@comcast.net>, Andy Bierman <ietf@andybierman.com>, Ops-Nm <ops-nm@ietf.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437
Cc:
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

See in-line a few comments from a contributor perspective. 

Dan

 
 

> -----Original Message-----
> From: David Harrington [mailto:ietfdbh@comcast.net] 
> > 
> > I strongly support the formation of this WG, and think it should be 
> > the "only next step" in NETCONF Data Modeling standards development.
> 
> > Trying to standardize too much at once without enough 
> implementation 
> > experience is not going to help.  The most critical DM need is to 
> > figure out how to use the standard NM data definitions we already 
> > have.
> 
> My intention is to develop a way to access MIB data via 
> XML-based NM protocols, to take advantage of the existing NM 
> data definitions in the MIB. 
> 
> This is a migration strategy to move from a 
> mainly-SNMP-and-MIB management framework to a 
> multi-protocol-and-multi-data-model
> management framework. 
> 
> I do not think MIB access is enough. A binary data-based 
> approach like the MIB is fine for automated management, but 
> it is not good for operator-interactive management, and it 
> fails to take advantage of advances in computer networking 
> technology like WWW technologies.
> 
> For operator-interactice NM, I think we need task-based NM interfaces.
> The CLI is one approach, and standardizing it would probably 
> be helpful, but the engineering departments of vendors are 
> not very cooperative on doing that; it is easier for 
> engineers to use freeform text when developing CLIs and 
> syslog-style reporting than to use standardized content. 

I do not believe that a standard CLI is achievable in the IETF. By now
we should assume this is not going to happen. 

> 
> 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. 

> 
> While I would like to see the reuse of existing standards, 
> such as XSD, we need to support programmatic interfaces to 
> allow (incremental) automation of repetitive tasks. That 
> means we need to provide machine-readable "clues" about the 
> meta-nature of management information. Maybe that can be done 
> in XML using attributes, or namespaces, or hierarchical 
> organization. Maybe it will require a new SMI with all the 
> special fields found in SMIv2 - and more. 
> 
> I think one of the big questions we need to address is 
> whether a new SMI should be developed that is an 
> extension/superset of SMIv2, or is distinct from SMIv2. I 
> think that work involves getting operator feedback of how 
> they work, so we can understand whether we should be trying 
> to merge the existing NM protocols, or should keep them (and 
> their data) distinct. I think we should be considering how to 
> componentize existing standards work, so we can reuse some 
> parts, such as secure transport, while keeping other parts distinct. 

I somehow like the paradigm - SNMP for performance monitoring and
alerts, Netconf for configuration and status retrieval. Could we
consider that the current standard MIB modules based would be used for
read configuration operations, like declare it as the status branch in
each MIB, ignoring the configuration objects and build atop of it what
is needed for configuration, even if this means duplication of some
objects. Simple or too simplistic? 

> 
> That work can advance while we work on developing support for 
> one or more XML-based interfaces to SMIv2 data models, as a 
> migratory step toward multi-protocol management.
> 
> > 
> > Nit: The WG acronym is kind of cryptic and I'm not sure what it 
> > supposed to mean.  Also, the WG name only describes work items
> > (A) and (B).  Security requirements for multi-protocol 
> access to MIB 
> > data is definitely not covered by the title, and (D) is 'possibly' 
> > NETCONF protocol-specific. (?? XSMI ?? SMIX ??
> > SMINET ??)
> 
> I deliberately avoided the use of SMI. As somebody pointed 
> out (you?), this work (A and B) is not developing a new SMI, 
> it is merely translating elements of SMIv2 from one language 
> to another.
> 
> > 
> > Milestones:  Any idea how long you think it will take to do 
> all this 
> > work?
> > 
> > Work items:
> > 
> > (A)(B)
> > The XSD for SMIv2 data types and TCs draft has been reviewed and 
> > refined over a couple years, and it is very much needed, and ready, 
> > for standardization.
> 
> Yan will be publishing a base datatype translation document, 
> based on libsmi translations. Since this has been defined and 
> used(?) fo ryears, I expect this should be fast - in IETF 
> terms, we can probably finish in seven or eight years ;-). 
> Seriously, I hope this can be done in six months or so, if 
> there is enough interest to work on it.
> 
> That will be supplemented by the (romascanu) TC translations document.
> We need to decide whether XSD can express the restrictions 
> adequately to support machine-validation, and whether the 
> amount of machine-validation supported justifies having an 
> XSD for the TC.
> Having TC translations might be helpful for netconf to go 
> read existng MIB data, without having to also parse SMIv2 MIB 
> documents to understand what the values mean. I think the 
> bigger benefit is defining TCs that can be used by multiple 
> protocols to support consistent semantics across protocols, 
> and XML is the preferred language for most new protocols.
> 
> This will require case-by-case analysis, and might take time 
> to reach consensus. Of course, not every contentious TC must 
> be included in this document, so if we cut out the 
> contentious ones, this should be able to be wrapped up within 
> a year, I hope.

I would try to push for a more aggressive schedule, even if it's a
smaller set of TCs. It's not that all needs to be standardized in RFC
form, but it is better to have this in a stable format for other work to
re-use it including proprietary implementations to deploy this. 

> 
> > 
> > (C)
> > This work item is a bit vague.  I'm not sure if it means a mapping 
> > between an SNMP EngineID to a NETCONF session identity, or 
> something 
> > to do with VACM, or something else undefined.
> > I think it is a smart idea to understand all the security issues 
> > associated with (D).
> 
> I'm looking at the bigger picture of multi-protocol 
> management. There are lots of protocols being developed, both 
> inside and outside IETF, to perform management functionality. 
> As Bob Natale pointed out, the MIB is the "crown jewel" of 
> IETF Management (I think SNMP is as well, when used for what 
> it is good at). I think lots of WGs and lots of other SDOs 
> are going to look at the MIB and say "gee, we should leverage that!"
> 
> I think we need to set some guidelines about how protocols 
> should deal with the MIB, so that it is not ruined by 
> unconstrained access by multiple protocols, especially write access.
> 
> But even read-access can be problematic. Security is a 
> process, not a product. The IETF needs to decide how to 
> "balance" security in an environment of multi-protocol 
> management. It makes no sense to protect your house with a 
> front door that has multiple deadbolt locks, if your back 
> door has no locks. 
> 
> It makes no sense to expect operators to go to the trouble of 
> configuring VACM to protect the data in the MIB when using 
> SNMP, if the operator's VACM configuration will just be 
> ignored by netconf and other protocols accessing the MIB. I 
> think we need some guidelines that provide for a more 
> consistent approach to multi-protocol MIB access, than 
> VACM-for-SNMP and nothing-for-others. 
> 
> Personally, I would like to see VACM not be 
> mandatory-to-implement for SNMP, if there is no corresponding 
> mandatory-to-implement access control for other protocols. I 
> don't think the operator community is actually ready for 
> standardized cross-protocol access control, and if it isn't 
> balanced across protocols, then we shouldn't require any NM 
> protocol standards to have a mandatory-to-implement access 
> control model.

I confess that this is confuse for me too. I am not sure that I
understand what is the deliverable here, or whether the problem can be
solved within the context of this working group. 

> 
> > 
> > (D)
> > I support a standard algorithmic translation between SMIv2
> conceptual
> > data models and NETCONF configuration databases, which 
> includes data 
> > organization and standard protocol operation mappings.
> > I think read-only access instead of full access will be easier to 
> > achieve, so it should be done first.  The use case for 
> write access is 
> > not as strong, and the multi-protocol access and security 
> issues are 
> > harder.
> 
> I agree that read-only access would probably be sufficient 
> for netconf to gather state information, statistical 
> information, and notifications. I do not see a lot of reason 
> to support write access to the MIB via netconf.

Yes, see the above.

> 
> > 
> > I do not support a generic XSD representation of SMIv2 
> macros, without 
> > consideration of the specific XML-based protocol being used.
> > The 'embedded' SNMP protocol operations in SMIv2, as well as the 
> > explicit SNMP operations discussed in MIB object 
> DESCRIPTION clauses, 
> > RowPointer, RowStatus, StorageType, etc., all have to be explicitly 
> > mapped to
> the
> > specific NETCONF (or whatever) protocol operations and architecture 
> > assumptions.
> 
> I think these need to be supported to understand the values 
> of certain fields that might be read from the MIB. 
> 
> RowStatus reflects the operational state of the row, and if 
> netconf is accessing the MIB to determine operational state 
> of the thing represented by that row, it is an important 
> piece of information. But if netconf has no write capability 
> to the MIB, it does not need to know how to manipulate the values.
> 
> StorageType is also state information about a row that might 
> be important for a netconf client to understand; it might be 
> helpful to know that the MIB representation (or the 
> underlying instrumentation) is in ROM. But if it has no write 
> capability, it does not need to know how to manipulate the 
> row within the constraints of StorageType. 
> 
> The MIB is more or less a relational database, where the 
> relations between rows is important information. If netconf 
> reads a row that has a relationship to another row via a 
> RowPointer, netconf better know how to interpret a RowPointer.
> 
> (It is important to understand that I make no assumptions 
> that a netconf-client will have a direct connection to an 
> SNMP manager that knows how to parse this information from an 
> SMIv2  MIB module
> document.)
> 
> I think we need to walk through these TCs on a case-by-case 
> basis to decide whether we need each one for use with 
> netconf, and what XSD restrictions apply.

Agree with David on this one. 

> 
> David Harrington
> dharrington@huawei.com
> dbharrington@comcast.net
> ietfdbh@comcast.net
> 
> 
> 
> 
> _______________________________________________
> OPS-AREA mailing list
> OPS-AREA@ietf.org
> https://www1.ietf.org/mailman/listinfo/ops-area
> 


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