[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[OPS-NM] Re: [OPSAWG] Re: [NGO] XSDMI work

Ron Bonica wrote: 
Andy, David,

Permit me to ask a few dumb questions so that I can understand a) what
David is proposing and b) why Andy is objecting.

AFAIKS, David is proposing the following:

- a mapping from SMIv2 TCs to XSD types
- a mechanism to translate SNMP MIBS to XSD.

The XSD is an XML schema that is independent of the protocol that is
used to shuffle the data back and forth. In one respect, it is a bit
like Esperanto. It strength is that it omits the details that make it
inappropriate for one protocol or the other. But at the same time, it's
weakness is that it lacks the detail that would be required by any protocol.


That's the pretty picture from 10000 feet

David, Andy, do I have this right? If so, could you guys point out what
some of those omitted/lacking details are?



The XSD is going to contain <key> clauses that specify how
data naming works for the multiple conceptual instances
of the 'table row' (i.e., some ancestor node of all index nodes).
In order to be useful for a particular protocol, this naming scheme
must be compatible with that protocol.
The conceptual data structures are going to use data types that must
be supported in that protocol, which impacts DM design.

In order to be useful for any protocol, another document
would be needed that maps every detail in the SMI-to-XSD algorithm
to every detail of the operations (verbs) for that protocol.
This is 90% of the work.

This generic SMI-to-XSD mapping is the other 10%.
IMO, this just complicates things.  I would rather
the 90% document be 100%, and map SMIv2 directly
to the protocol, rather than mapping from SMIv2 to an XSD info model,
and then to the protocol.

The current proposal contains lots of SNMP-specific details,
like engine-IDs, contexts, and max-repetitions.  This suggests
that the mapping is for SNMP, not SMIv2.  IMO, seamless integration
of MIB-based data into the NETCONF protocol is an interesting
problem to solve.  Using a NETCONF session to send SNMP PDUs in XML
to the NETCONF agent, who will forward it to the SNMP agent,
is not an interesting problem to solve.


Andy


                                 /speaking as individual contributor
                                 /and by no means a data modeling expert
                                  Ron


Andy Bierman wrote: 
David Harrington wrote:

Hi,

The XSDMI BOF proposed the creation of a WG to develop 1) the XSD
equivalents of datatypes and textual conventions from SMIv2, and 2)
algorithms to translate MIB module specifications into XSD
equivalents. The BOF demonstrated community support for these two work
items.
People in the BOF volunteered to commit to being editors (3) and
reviewers (14) for these work items. Starting documents and
implementations already exist. The work is expected to take less than
12 months.

At Dan's suggestion, rather than starting a new WG for this work, we
have proposed that the SMI-to-XSD translation work be done in the
OPSAWG.

I have an objection to this "translation" work.
You will make all kinds of assumptions about data organization
and data naming, and I'm not sure what people are supposed
to do with the XSDs.

The term "XSD translation" is misleading.
The XML on the wire is what is at stake here.
The smidump translation of a MIB has SNMP operations
built into it.  Is this work supposed to produce
a standard way to send an SNMP PDU over any protocol
designed to encode SNMP PDUs in XML?  Why do we need this?

Is the charter going to state that the XSD translation will
be suitable for use for any particular protocol?
NETCONF needs to standardize XML data organization,
namespace usage, and Xpath-based data naming.
Is this translation going to be compatible with that standard
when it eventually comes out?

I would like the charter to be clear on the purpose of this work item,
and what 'protocols' are signed up to use it.


The OPSAWG chairs need to determine whether the OPSAWG WG should
accept this work. Please send email to opsawg at ietf.org with comments
about your support/lack of support for having the OPSAWG do this work.
(If you do not subscribe to opsawg, you might want to do so, in order
to follow the discussions.)

David Harrington
dbharrington at comcast.net
ietfdbh at comcast.net



Andy


_______________________________________________
OPSAWG mailing list
OPSAWG at ietf.org
https://www1.ietf.org/mailman/listinfo/opsawg






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