Re: Comments on XSDMI BoF proposal
Andy Bierman <ietf <at> andybierman.com>
2007-06-06 15:55:03 GMT
David Harrington wrote:
> 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.)
>> -----Original Message-----
>> From: Andy Bierman [mailto:ietf <at> andybierman.com]
>> Sent: Monday, June 04, 2007 1:15 PM
>> To: Ops-Nm
>> Subject: [OPS-NM] Comments on XSDMI BoF proposal
>> 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
> to take advantage of the existing NM data definitions in the MIB.
This is fine, but it should be based on use cases, as you say later on.
IMO, there is a use case to read MIB data via a NETCONF session.
The goal can be abstract, but the solutions has to be specific,
in order to have an inter-operable standard.
> 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.
I am not interested in an SNMP-like interface to SMI data, encoded in XML.
IMO, via NETCONF <get>, the access should be per-row-instance, via subtree
and Xpath filters, not per-column-instance, via lexi-next (getnext).
Other protocols will have completely different requirements and
retrieval operations, and the solution might not be the same.
> 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.
I do not think this limited and generalized translation (D) is very useful,
or realistically possible to do well in the IETF, in finite time.
I prefer to view the Network Management problem in specific terms, e.g.,
understanding how conceptual data defined in SMIv2 can be mapped
into a NETCONF Configuration Database, and accessed with NETCONF
Abstracting the NM problem as if there was nothing going on beyond
editing the XML instance document itself does not really help.
>> Milestones: Any idea how long you think it will take to do
>> all this work?
>> Work items:
>> The XSD for SMIv2 data types and TCs draft has been reviewed
>> and refined
>> a couple years, and it is very much needed, and ready, for
> 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.
>> 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
Previous discussions wrt/ NETCONF access control have indicated
that a simple solution allowed just 2 access levels (read and write)
is favored. Perhaps as a backlash to VACM.
>> I support a standard algorithmic translation between SMIv2
>> 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,
>> RowStatus, StorageType, etc., all have to be explicitly mapped to
>> 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
> 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.
I was pointing these complexities out as a reason not to deal
with write access. If there are products used by operators someday,
that have some sort of XML-based "set" operation for MIB data,
then maybe it would be interesting to standardize it.
> David Harrington
OPS-NM mailing list
OPS-NM <at> ietf.org