Subject: Re: WG Review: NETCONF Data Modeling Language (netmod)

From: Bernard Aboba <[email-masked]>
Date: Thu, 24 Apr 2008 17:40:36 -0700

I echo Tom Petch's concern.

Given the level of deployment success of IETF management efforts
for the last 5-10 years, I'd suggest that we need both customer
"pull" as well as technical community "push" for such an effort
to succeed.  While there have been arguments made for the latter,
I don't see enough evidence of customer (in particular, operator)
involvement to feel confident that the former has been addressed.

David Harrington said:

"The people who believe that YANG is more expressive and better suited
for this poarticular purpose include contributors to the design of
SMIv2, MIB Doctors, members of the NMRG who helped develop the SMING
information and data modeling language,  contributors to the SMIng WG
which worked on developing a proposed SMIv3 to converge the SMIv2
standard and the SPPI data modeling language standard and the NMRG
SMING approach, and engineers who have multiple independent
implementations of running code for Netconf data modeling."

Tom Petch said:

"Sounds magnificent but who are these people and where are they?

I do track the YANG and NGO mailing lists and what I see there worries me.  I
see a significant number of questions along the lines; of what does this mean,
how can this ever work, how can I do ... and the questions are all very
reasonable and need answers - which they mostly get, even if they are somewhat
too often along the lines of 'oh dear', or 'more work needed'.

But they are the sort of questions I, for all I have done with SMI, ASN.1 and
other languages, would not have thought to ask; they come from someone at the
sharp end writing code for today's boxes.  Yet these questions are almost all
coming from just one person with a specific market place, and if he can find so
many doubts and queries, how many more are there waiting to be discovered?

That one person - hi, Andy! - is doing a magnificent job but for a new language
to live up to its billing, we need half a dozen such people, from different
parts of O&M to find the holes; and I just do not see them, at least not on the
YANG and NGO mailing lists.

The answers, likewise, mostly come from the same three or so people; again, I am
concerned that there are not more, given the claims of yang.

This causes me to doubt that we, the IETF, really has the community of interest
to undertake such a challenging assignment.

Tom Petch"
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 25 Apr 2008 14:21:09 -0600

Hi -

> From: "Bernard Aboba" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, April 24, 2008 6:40 PM
> Subject: Re: WG Review: NETCONF Data Modeling Language (netmod)
>
...

Whether we like it or not, the last five years have been devoted largely to
NETCONF.  RFC 4741 is already published on the standards track.
During that time, the community has been forbidden to work on data models
in the IETF.  Without data models, NETCONF's utility is rather limited, to
say the least.  Consequently, a lack of perceived "pull" should hardly be
surprising.

The choice before us is pretty simple:

   - allow work to continue on standardized data models, so there will be
     some hope of interoperability

   - ignore the need, rely on the continued proliferation of proprietary
     approaches, and hope someone else figures out how to interoperate
     (though some may consider the lack of interoperability to be a sales-
     enhancing feature rather than a problem to be overcome)

   - hope some other organization will give the work a home if the people
     willing to do the work are not allowed to do it on IETF turf.

The question now is whether the IETF wants NETCONF protocol to succeed.
Yes, more operator input is desirable.  But in the case of NETCONF,
the protocol itself is far removed from what the operators asked for
at the IAB workshop. These leaves me wondering whether more input
would really change anything.

Based on my understanding of the operator input at the IAB workshop,
the Yang proposal, of all the ones mentioned at the CANMOD BOF,
is by far the best-aligned with the concerns the operators voiced,
which were, in a word, "readability".  (For the data itself, terms like
"screen scraping" came up a lot.)

I'm certain something better is possible, but no one has bothered
to write an i-d.  At some time we have to stop waiting for something
better to magically appear and go with something that will be good
enough that has the support of implementors.

This work should have been undertaken five years ago.  How much
longer?

Randy