Comments on XSDMI BoF proposal

Hi,

Here is the BoF proposal for reference:

XSD for accessing SMIv2 data models (xsdmi) BOF
Status: request submitted including proposed WG charter
Discussions: NETCONF WG list [email protected]
Responsible AD: Dan Romascanu
BOF Chair: David Harrington ([email protected])
Internet-Drafts:
draft-romascanu-netconf-datatypes-02 (XSD for SMIv2 Data Types and
Textual Conventions)
draft-li-ngo-access-mib-01 (SMIv2 Data Access for NETCONF)
Summary and Scope: Future WG Formation - The XSDMI WG will undertake the
following work items:
(A) Development of a standard XML Schema Definition [XSD] to specify the
XML encoding of the core SMIv2 data types defined in RFC2578.
(B) Development of a standard XML Schema Definition [XSD] to specify the
XML encoding of some generic and common SMIv2 textual conventions, as
identified at http://www.ops.ietf.org/mib-common-tcs.html.
(C) Definition of a standard set of security requirements for accessing
MIB management data by potentially multiple protocols.
(D) Development of a standard set of algorithms for accessing SMIv2
management information, possibly using the NETCONF <get> operation
and/or <notification> data delivery mechanism.

---------------------------------------

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.

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 ??)

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.

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

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


Andy




_______________________________________________
OPS-NM mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ops-nm