Re: [OPS-AREA] RE: Comments on XSDMI BoF proposal
Jon Saperia <[email protected]> Wed, 06 Jun 2007 06:05:51 -0400
| Newsgroups | gmane.ietf.ops-nm |
|---|---|
| Message-ID | <[email protected]> |
--===============1714086940==
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
One comment/question in line below:<br>
<br>
Romascanu, Dan (Dan) wrote:
<blockquote
cite="midEDC652A26FB23C4EB6384A4584434A040D7E8D@307622ANEX5.global.avaya.com"
type="cite">
<pre wrap="">See in-line a few comments from a contributor perspective.
Dan
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: David Harrington [<a class="moz-txt-link-freetext" href="mailto:[email protected]">mailto:[email protected]</a>]
</pre>
<blockquote type="cite">
<pre wrap="">I strongly support the formation of this WG, and think it should be
the "only next step" in NETCONF Data Modeling standards development.
</pre>
</blockquote>
<blockquote type="cite">
<pre wrap="">Trying to standardize too much at once without enough
</pre>
</blockquote>
<pre wrap="">implementation
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
I do not believe that a standard CLI is achievable in the IETF. By now
we should assume this is not going to happen.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
<br>
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).<br>
<br>
The suggestion of using subtrees for functional (e.g., FCAPS)
separation has worked well in some cases (we use 0 for notifications
right). <br>
<br>
<blockquote
cite="midEDC652A26FB23C4EB6384A4584434A040D7E8D@307622ANEX5.global.avaya.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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?
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">access to MIB
</pre>
<blockquote type="cite">
<pre wrap="">data is definitely not covered by the title, and (D) is 'possibly'
NETCONF protocol-specific. (?? XSMI ?? SMIX ??
SMINET ??)
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">Milestones: Any idea how long you think it will take to do
</pre>
</blockquote>
<pre wrap="">all this
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">(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
</pre>
</blockquote>
<pre wrap="">something
</pre>
<blockquote type="cite">
<pre wrap="">to do with VACM, or something else undefined.
I think it is a smart idea to understand all the security issues
associated with (D).
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">(D)
I support a standard algorithmic translation between SMIv2
</pre>
</blockquote>
<pre wrap="">conceptual
</pre>
<blockquote type="cite">
<pre wrap="">data models and NETCONF configuration databases, which
</pre>
</blockquote>
<pre wrap="">includes data
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">write access is
</pre>
<blockquote type="cite">
<pre wrap="">not as strong, and the multi-protocol access and security
</pre>
</blockquote>
<pre wrap="">issues are
</pre>
<blockquote type="cite">
<pre wrap="">harder.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, see the above.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I do not support a generic XSD representation of SMIv2
</pre>
</blockquote>
<pre wrap="">macros, without
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">DESCRIPTION clauses,
</pre>
<blockquote type="cite">
<pre wrap="">RowPointer, RowStatus, StorageType, etc., all have to be explicitly
mapped to
</pre>
</blockquote>
<pre wrap="">the
</pre>
<blockquote type="cite">
<pre wrap="">specific NETCONF (or whatever) protocol operations and architecture
assumptions.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
Agree with David on this one.
</pre>
<blockquote type="cite">
<pre wrap="">David Harrington
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
_______________________________________________
OPS-AREA mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<a class="moz-txt-link-freetext" href="https://www1.ietf.org/mailman/listinfo/ops-area">https://www1.ietf.org/mailman/listinfo/ops-area</a>
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
OPS-NM mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<a class="moz-txt-link-freetext" href="https://www1.ietf.org/mailman/listinfo/ops-nm">https://www1.ietf.org/mailman/listinfo/ops-nm</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Jon Saperia
(cell) 617-201-2655
(Eve.) 978-461-0264</pre>
</body>
</html>
--===============1714086940==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
OPS-NM mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ops-nm
--===============1714086940==--