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

"David Harrington" <ietfdbh@comcast.net> Tue, 05 June 2007 19:49 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 1Hvf2T-0006wf-CV; Tue, 05 Jun 2007 15:49:57 -0400
Received: from ops-nm by megatron.ietf.org with local (Exim 4.43) id 1Hvf2S-0006wQ-9z for ops-nm-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 15:49:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvf2R-0006wH-VI; Tue, 05 Jun 2007 15:49:55 -0400
Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvf2R-0002WC-Hc; Tue, 05 Jun 2007 15:49:55 -0400
Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <2007060519495501400deje2e>; Tue, 5 Jun 2007 19:49:55 +0000
From: David Harrington <ietfdbh@comcast.net>
To: 'Andy Bierman' <ietf@andybierman.com>, 'Ops-Nm' <ops-nm@ietf.org>
References: <4664489B.1000406@andybierman.com>
Subject: RE: [OPS-NM] Comments on XSDMI BoF proposal
Date: Tue, 05 Jun 2007 15:49:46 -0400
Message-ID: <02c901c7a7aa$ab924fc0$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: <4664489B.1000406@andybierman.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: AcemzA59oB5ulVZRR7W5+F6lyv4NKQAzMFkA
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1
Cc: ops-area@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>
Errors-To: ops-nm-bounces@ietf.org

Hi,

comments inline 

(I am cross-posting to the ops-area mailing list because no official
decision was made to relocate discussion for XSDMI to the ops-nm list.
I will ask Dan to change the BOF page to direct discussion to the
ops-nm list. Interested parties please find XSDMI discussion on the
ops-nm list.)

dbh

> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com] 
> Sent: Monday, June 04, 2007 1:15 PM
> To: Ops-Nm
> Subject: [OPS-NM] Comments on XSDMI BoF proposal
> 
> General:
> 
> 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. 

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. 

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. 

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.

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

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

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

David Harrington
dharrington@huawei.com 
dbharrington@comcast.net
ietfdbh@comcast.net




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