Subject: Re: [OPSAWG] XSDMI BoF

From: Ron Bonica <[email-masked]>
Date: Tue, 04 Sep 2007 10:15:47 -0400

Folks,

I am not a data modeling expert, and I don't even play one on
television. So, I am a little confused about the urgency to start one
data modeling effort when there is a good possibility that we will start
another in a few weeks.

Wouldn't running two parallel data modeling efforts confuse the
market-place? Isn't there a good possibility that one effort will suck
resources away from the other?

Maybe somebody could change my mind by convincing me that we need *both*
 the output of *both* efforts. To do this, you would have to convince me
that the output of each effort is a) different from the output of the
other and b) useful in ways that the other is not.

                                    Ron

Romascanu, Dan (Dan) wrote:
> As I already said, speaking as a contributor, I support doing this work.
> I believe it is high priority and that the OPSAWG could be the
> appropriate home. I do not see a problem in running parallel data
> modeling efforts, provided that they are distinct in scope and in time
> span. That is why I believe that we want to continue the work on the
> XSDMI Internet-Drafts using OPSAWG list for discussions and decide by
> Vancouver about adoption as a chartered item and where.  
> 
> Dan
> 
> 
> 
> 
>  
>  
> 
> 
>>-----Original Message-----
>>From: Ron Bonica [mailto:[email-masked]] 
>>Sent: Wednesday, August 29, 2007 10:30 PM
>>To: David Harrington
>>Cc: [email-masked]
>>Subject: Re: [OPSAWG] XSDMI BoF
>>
>>David,
>>
>>Please note that we have not rejected the XSDMI proposal. We 
>>are merely deferring a decision until we see the YANG BoF.
>>
>>                                    Ron
>>
>>David Harrington wrote:
>>
>>>Hi,
>>>
>>>I don't now if all the feedback you have received has been 
>>
>>public or 
>>
>>>not.
>>>Obviously I have been watching the public response to XSDMI.
>>>
>>>XSDMI is explicitly a protocol-independent translstion of SMIv2 to 
>>>XSD. SMIv2 is supposed to be protocol-independent, so it 
>>
>>can be used 
>>
>>>with multiple protocols. (The SNMP community unfortunately 
>>
>>gets mixed 
>>
>>>reviews for keeping MIBs protocol-neutral.)
>>>
>>>During the BOF, the response was 13 for and 0 against doing work on 
>>>the datatypes.
>>>During the BOF, the response was 9 for and 0 against doing 
>>
>>mib module 
>>
>>>translation.
>>>
>>>At the request of the ADs, we asked the OPSAWG whether we 
>>
>>could work 
>>
>>>on these twp items in this WG to save the difficulty of finding new 
>>>chairs and so on.
>>>
>>>One person, and only one person, Juergen Schoenwaelder, has raised 
>>>objections to this work going forward:
>>>'the existence of the translated XSD output will cause future data 
>>>modeling languages to be "consistent" with the XSD output 
>>
>>coming out 
>>
>>>of the translation.'
>>>
>>>Obviouly, this person who is part of a design team 
>>
>>developing a data 
>>
>>>modeling approach for Netconf believes the XSDMI work is being done 
>>>specifically for Netconf. I disagree with his assessment.
>>>
>>>One person, Andy Bierman, raised questions about the intent of this 
>>>work. I believe I answered his questions.
>>>
>>>It has been oft repeated in the Netconf WG that any valid XML 
>>>qualifies as content for Netconf. There has been no 
>>
>>agreement that XSD 
>>
>>>must be developed to specify a mechanism to validate the 
>>
>>XML content.
>>
>>>The YANG proposal (draft-yang-pre-00.txt yet to be made public) 
>>>actually does not use XSD as its SMI; it uses a 
>>
>>newly-developed C-like 
>>
>>>modeling language. The NCX proposal 
>>
>>(draft-bierman-ncx-smi-00) accepts 
>>
>>>any base data types defined in XSD and in SMIv2, and holds 
>>
>>that higher 
>>
>>>level "data type definitions are considered to be abstract 
>>
>>constructs 
>>
>>>that cannot be accessed by any protocol mechanism." So there is no 
>>>conflict with these two emerging Netconf proposals.
>>>
>>>The XSDMI effort is designed to produce **one** XSD 
>>
>>specification to 
>>
>>>guide translating MIB data into **a** valid XML format useable with 
>>>any protocol. The XSDMI XSD could also be used to perform 
>>
>>validation 
>>
>>>of the data.  The XSDMI XSD should not in any way constrain other 
>>>approaches to developing valid XML for use with Netconf, 
>>
>>whether those 
>>
>>>approaches utilize XSD or other protocols for specification and 
>>>validation purposes.
>>>
>>>I agree the XSDMI effort should not constrain the Netconf 
>>
>>efforts, but 
>>
>>>I also believe the Netconf efforts should not constrain the XSDMI 
>>>effort.
>>>
>>>We have waited years for the Netconf protocol developers to reach 
>>>consensus to even start developing a data modeling language 
>>
>>that can 
>>
>>>be used to specify valid XML useable with Netconf. The Netconf 
>>>community includes vendors and operators and not just protocol 
>>>designers. The Netconf **community** is obviously one potential 
>>>customer for the XSDMI XSD. There has been significant demand from 
>>>vendors for standardized data models to go with the Netconf 
>>
>>protocol; 
>>
>>>so far they are constrained to providing proprietary data 
>>
>>models for 
>>
>>>use with the Netconf protocol.
>>>
>>>The XSDMI XSD would allow vendors who are implementing the Netconf 
>>>protocol and their customers who are deploying the Netconf 
>>
>>protocol to 
>>
>>>use the XSDMI XSD to at least monitor their existing 
>>
>>standardized MIB 
>>
>>>instrumentation. Vendors can provide their customers with a 
>>>partially-useful and partially-interoperable Netconf protocol 
>>>implementation, while waiting for the Netconf protocol designers to 
>>>reach consensus on a complete configuration-oriented data modeling 
>>>language and to start developing Netconf-specific data models for 
>>>interoperable configuration.
>>>
>>>It seems unreasonable for the Netconf protocol developers to 
>>>deliberately deny the rest of the Netconf community the 
>>
>>option of an 
>>
>>>intermediate solution.
>>>
>>>David Harrington
>>>[email-masked]
>>>[email-masked]
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Ron Bonica [mailto:[email-masked]]
>>>>Sent: Wednesday, August 29, 2007 11:48 AM
>>>>To: [email-masked]
>>>>Subject: [OPSAWG] XSDMI BoF
>>>>
>>>>Folks,
>>>>
>>>>Dan and I have received light but mixed reaction to the 
>>
>>XSDMI BoF. A 
>>
>>>>few participants have supported XSDMI becoming a working 
>>
>>group while a 
>>
>>>>smaller number have objected. The people objecting have stated that 
>>>>XSDMI might interfere with other work aimed at creating an SMI 
>>>>designed specifically for NETCONF.
>>>>
>>>>So, Dan and I are deferring our decision wrt to XSDMI for at least
>>>
>>>one
>>>
>>>
>>>>IETF. We would like to give the folks proposing an NETCONF specific 
>>>>SMI some time to arrange a BoF session. After having seen that BoF, 
>>>>the community will decide whether one, the other or both 
>>
>>groups should 
>>
>>>>become working groups.
>>>>
>>>>                                       Ron
>>>>
>>>>
>>>>
>>>>_______________________________________________
>>>>OPSAWG mailing list
>>>>[email-masked]
>>>>https://www1.ietf.org/mailman/listinfo/opsawg
>>>>
>>>
>>>
>>>
>>
>>_______________________________________________
>>OPSAWG mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/opsawg
>>
> 
> 

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/opsawg

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 4 Sep 2007 16:36:45 +0200

For short, the XSDMI proposals seem to provide the following specific
value:
- XSD access to MIB and re-use (partial at least) of the many years of
modeling work invested in SMI MIBs
- usage of XML/XSD which is today sort of the de-facto default format
used by vendors for access to data carried by NETCONF
- possible usage with multiple protocols

For NETCONF, relative to other data modeling efforts this proposal can
provide a shorter term which is IMO critical at this phase of the
evolution of NETCONF. The other efforts as I understand them aim towards
the creation of a new SMI, are NETCONF specific, and do not use MIB
translations - which for me means that these will be a longer term
effort to create a solid SMI and then remodel some of the key data to be
carried. 

There is no architectural conflict to prevent running the two proposals
in parallel, although I believe that the XSDMI will end up earlier if
not much earlier. The resources at least in what concerns editing are
different. 

Dan
(speaking as contributor)

> Sent: Tuesday, September 04, 2007 5:16 PM
> To: Romascanu, Dan (Dan)
> Cc: David Harrington; [email-masked]
> television. So, I am a little confused about the urgency to 
> start one data modeling effort when there is a good 
> possibility that we will start another in a few weeks.
> 
> Wouldn't running two parallel data modeling efforts confuse 
> the market-place? Isn't there a good possibility that one 
> effort will suck resources away from the other?
> 
> Maybe somebody could change my mind by convincing me that we 
> need *both*  the output of *both* efforts. To do this, you 
> would have to convince me that the output of each effort is 
> a) different from the output of the other and b) useful in 
> ways that the other is not.
> 
>                                     Ron
> 
> >>Please note that we have not rejected the XSDMI proposal. We are 
> >>merely deferring a decision until we see the YANG BoF.
> >>
> >>                                    Ron
> >>
> >>David Harrington wrote:
> >>
> >>>Hi,
> >>>

---

From: "David Harrington" <[email-masked]>
Date: Wed, 5 Sep 2007 23:55:14 -0400

Hi Ron,

The XSDMI is not really a data modeling effort. It is a simple
translation effort - translating SMIv2 into an equivalent XSD format.
The purpose is just to make the MIB more accessible to XML-based
protocols and XML-based tools.

The MIB is strong on providing access to operational state and
statistics, which has been found especially useful for fault and
performance management. The operational state and statistics can
easily be represented in a least common denominator of vendor
information. If you want to know which VLANs exist on a device, you
need much less vendor-specific information than you do to actually
create and configure those VLANs.

The MIB is notably weak on support for configuration. SMIv2 modeling
is database-oriented, whereas configuration tends to be task-oriented.
There is a serious mismatch between the type of modeling available via
the MIB and what is needed for configuration. The IETF has done a poor
job of modeling configuration information in the MIB; most IETF MIB
modules do not contain read-write configuration information, only
read-only monitoring information, and most implementations of SNMP do
not support the SET operation, which is the only operation that can be
used to perform configuration using SNMP. That's why there is a demand
for a new (task-oriented) configuration protocol and an XML-based data
modeling approach (XML is much more extensible and flexible than
SMIv2). See RFC3535 for more detailed information about the mismatch
between the MIB and SNMP and operator requirements for configuration.

The Netconf WG(s) have developed a  protocol that supports extensible
(task-oriented) remote procedure calls, and are trying to develop a
configuration-oriented structure of management information using the
XML family of protocols. While there is an intersection between the
sets of configuration and operational management information, it is
extremely difficult to reach consensus on a least common denominator
for configuration information. Every vendor designs their own
configuration parameters, and those parameters are essential to
competitive differentiation. So the configuration standardization
problem is extremely difficult to resolve, because it flies in the
face of business economics. Standardization of monitoring information
does not fly in the face of business economics.

Once the Netconf WG(s) reach consensus on a (task-oriented) data
modeling language for configuration information, then they need to
develop the actual data models for configuration information. These
data models will be different than what is modeled by the MIB, and are
expected to be significantly more complex than the simplistic SMIv2
language allows. For example, SMIv2 only supports two-dimensional
arrays, and it is difficult to use SMIv2 to model real-world devices
that employ hash tables, multi-dimensional arrays, and other complex
data structures, or to perform standardized operations on those
complex data structures.

The problem being addressed by the XSDMI effort is substantially
different than that being addressed by the Netconf WG(s). The goal of
XSDMI is simply to make it easier to leverage MIB datatypes and use
XML-based tools and protocols with the existing MIB data models to do
monitoring and fault/performance analysis. The goal of Netconf is to
define a whole new approach to data modeling that better fits the
requirements of operators performing configuration work.

David Harrington
[email-masked]
[email-masked]

> Sent: Tuesday, September 04, 2007 10:16 AM
> To: Romascanu, Dan (Dan)
> need *both*