[MIB2RDML] 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 BIWNoW.8N4GwRP3M1sUke.cADMTOSCDB9fnPQ_qjo52D_N2wKonOr
Message-ID: <46C07E65.8080503@andybierman.com>
Date: Mon, 13 Aug 2007 08:53:09 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: Ron Bonica <rbonica@juniper.net>
References: <019701c7db6f$674c3990$6702a8c0@china.huawei.com>
	<46BC9E07.3030502@andybierman.com> <46C06B7B.6080709@juniper.net>
In-Reply-To: <46C06B7B.6080709@juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 093efd19b5f651b2707595638f6c4003
X-Mailman-Approved-At: Mon, 13 Aug 2007 12:40:29 -0400
Cc: ngo@ietf.org, mib2rdml@ietf.org, opsawg@ietf.org, ops-nm@ietf.org
Subject: [MIB2RDML] Re: [OPSAWG] Re: [NGO] XSDMI work
X-BeenThere: mib2rdml@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: converting MIB modules into resource models <mib2rdml.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mib2rdml>,
	<mailto:mib2rdml-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mib2rdml>
List-Post: <mailto:mib2rdml@ietf.org>
List-Help: <mailto:mib2rdml-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mib2rdml>,
	<mailto:mib2rdml-request@ietf.org?subject=subscribe>
Errors-To: mib2rdml-bounces@ietf.org

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@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@comcast.net
>>> ietfdbh@comcast.net
>>>
>>>
>>
>> Andy
>>
>>
>> _______________________________________________
>> OPSAWG mailing list
>> OPSAWG@ietf.org
>> https://www1.ietf.org/mailman/listinfo/opsawg
>>
> 
> 

_______________________________________________
MIB2RDML mailing list
MIB2RDML@ietf.org
https://www1.ietf.org/mailman/listinfo/mib2rdml

OF 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@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@comcast.net
>>> ietfdbh@comcast.net
>>>
>>>
>>
>> Andy
>>
>>
>> _______________________________________________
>> OPSAWG mailing list
>> OPSAWG@ietf.org
>> https://www1.ietf.org/mailman/listinfo/opsawg
>>
> 
> 

_______________________________________________
MIB2RDML mailing list
MIB2RDML@ietf.org
https://www1.ietf.org/mailman/listinfo/mib2rdml