Subject: [OPSAWG] XSDMI BoF

From: Ron Bonica <[email-masked]>
Date: Wed, 29 Aug 2007 11:48:11 -0400

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

---

From: "David Harrington" <[email-masked]>
Date: Wed, 29 Aug 2007 14:38:53 -0400

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,
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 29 Aug 2007 12:21:22 -0700

Hi -

> From: "David Harrington" <[email-masked]>
> To: "'Ron Bonica'" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, August 29, 2007 11:38 AM
> Subject: RE: [OPSAWG] XSDMI BoF
...
> deliberately deny the rest of the Netconf community the option of an
...

As a no longer terribly interested observer...

While I'm loathe to ascribe intent to the netconf protocol developers,
it's been clear from the beginning that one of the consequences of
making the protocol largely payload agnostic, and of deferring
any work on anything resembling a data model or architecture, would
be that by the time any standardization work began on such a model
or architecture, it would be too late for it to displace the proprietary
ones that provided the motivation for the netconf work in the first place.

What's been delivered is exactly what the operators at the IAB
workshop told us they did not want, and the direction the remaining
work is taking does little to address their concerns.  But that's also
no surprise, and was evident from the early days of netconf.

It should not be surprising that those who already have significant investment
in particular approaches to the representation of data models might harbor
some opposition to any kind of standardization effort.  Even with all kinds
of assurances that it's just another approach, there's always the possibilty,
even the likelihood, that a WG would produce something superior to
somebody's proprietary hack.  At the same time, there may also be a 
"once-burned, twice-shy" feeling among those involved in the SMIng effort.

But take heart.  Good ideas appear to engender particularly fierce
opposition in the IETF.  The trouble is that the existence of opposition
doesn't guarantee that the idea is good.  :-)

Randy

---

From: Ron Bonica <[email-masked]>
Date: Wed, 29 Aug 2007 15:29:56 -0400

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:
>>So, Dan and I are deferring our decision wrt to XSDMI for at least
> 
> one
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 30 Aug 2007 07:21:38 +0200

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

> 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,
> > 
> >>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 
> >>XSDMI might interfere with other work aimed at creating an SMI 
> >>designed specifically for NETCONF.
> >>
> >>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
> >>
> >>
> >>