David Harrington wrote: > Here are my reasons why I support the charter, which align with yours: There are multiple types of users for data models. The operators and reviewers care about the semantic model much more than the syntactic mapping. Ease of use and stability have proven to be the most important factors for NM data models. YANG provides enough semantic modeling to be useful for the NM problem at hand, and since it will be owned by the IETF, the complexity and stability will also be controllable by the IETF. By decoupling the syntactic mapping from the semantic model, the specific mapping rules can change over time as W3C standards continue to evolve, without impacting any installed base of data models. Last year XSD was the only thing. Now we seem to be dropping XSD and adopting DSDL instead. I am not convinced XSD is dead, or the DSDL will be the final answer either. But if the YANG language stays stable, I don't care. Andy > >> -----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 > > > _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf