> -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On > Behalf Of Eric Rescorla > > I propose that you list (again) your (technical) objections > > to the the current proposal. > > Sure. Based on my knowledge of modelling/protocol description > languages, the techniques that Rohan described based on RNG and > Schematron seemed to me quite adequate to get the job done and the > relatively large baggage introduced by defining another language > (YANG) which is then translated into them seems wholly unnecessary. > > I appreciate that some people believe that YANG is more expressive and > better suited for this particular purpose, but I didn't see any really > convincing arguments of that (I certainly don't find the arguments in > F.2 of draft-bjorklund-netconf-yang dispositive). Given what I know of > the complexity of designing such languages, and of their ultimate > limitations and pitfalls, this seems like a bad technical tradeoff. 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. I respect their experience and combined knowledge of the complexity of designing such languages. I also respect operators' knowledge of the complexity of using such languages to actually manage networks. The NM community has been working to resolve the problem of the unsuitability of the IETF's SNMP-only approach to configuration for many years, and the NM comunity has deliberately sought out operators for feedback about what does and what doesn't work well for them in configuration data modeling. One of the major problems of designing a language for data modeling is that there are many different constituencies with very different requirements for a configuration language, which change over time, as can be seen in RFC3139 and RFC3216 and RFC3535. There are a tremendous number of potential tradeoffs to make a general-purpose language meet "everybody's" needs. In RFC4101 "Writing Protocol Models", you argue that "reviewers have only limited amounts of time" and "most documents fail to present an architectural model for how the protocol operates, opting instead to simply describe the protocol and let the reviewer figure it out. This is acceptable when documenting a protocol for implementors, because they need to understand the protocol in any case; but it dramatically increases the strain on reviewers. Reviewers need to get the big picture of the system and then focus on particular points. They simply do not have time to give the entire document the attention an implementor would." The NM comunity sought out multiple operator communities, and came to a similar conclusion. Operators need to "review" data model specifications, and quickly understand the model, often while in the middle of fire-fighting. To help address the need to quickly understand the model, the MIB Doctors have developed guidelines and templates for desecribing the data model in surrounding text. In practice, however, MIB modules are frequently distributed without the surrounding document text, and operators responding to network problems don't have time to find the right document and read it to understand the model. As a result, the NM community concluded that data models themselves need to be human readable. MIB modules, for example, are read by agent implementers, application implementers, operators, and applicatuon users (e.g., when MIB module descriptions are presented as help files). NM data models are frequently developed by enterprises to model their proprietary implementations, so it is also important that the language be easy to write correctly. XSD can be very hard to read (and even harder to write accurately). RelaxNG, possibly with Schematron, is better, but it can still be difficult to understand. YANG was written with human-readability as the highest priority. In addition, there are some specific constructs important to managing a network (and already available in MIB modules) that are not natively supported in XSD or RNG, so existing XML-based tools are incapable of writing and fully validating data models with these constructs. The NM community thinks it would be a step backwards for the IETF to ignore twenty years of consensus on the importance of these NM-related constructs, and throw these away in order to use an existing standard language that was designed for different purposes. Some major lessons we learned from SMIv1 and SMIv2 was the difficulty of building atop existing standards from other organizations with different goals, like building SMI atop ASN.1, when the standards are likely to grow in different directions than what we need for IETF NM data model standardization purposes. Unfortunately, you did not attend the many sessions over the past few years as the NM community did comparisons of the suitability of SMIv2, SPPI, SMING, XSD, RNG, YANG and others for purposes of configurastion data modeling. But the community that has attended such discussions of the suitability of different languages for the task at hand has reached rough consensus and developed multiple implementations of running code for this proposed direction forward. David Harrington dbharrington@xxxxxxxxxxx ietfdbh@xxxxxxxxxxx dharrington@xxxxxxxxxx _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf