On 17/04/18 07:35, Ladislav Lhotka wrote: > Hi, > > this is a slippery slope. If we want to turn YANG into a general-purpose > schema language, it should IMO be done the other way around: design a > general-purpose schema language with a sound architecture, and then use > it for defining schemas of datastores, protocol messages or whatever. > > YANG extensions make changes to the original YANG architecture way too > easy, but the result may be a bastard with no architecture at all.
+1 in general, although I am not convinced we need to start from scratch. The problem is that the metamodel behind YANG is not formally defined, which means every implementer has to reverse-engineer it from RFC6020/7960 (and 6241, and others). Since there is no metamodel spec, it is very hard to reason about how an extension affects it, especially in edge cases -- which can (and most probably will) lead to bastardization. One example: YANG 1.1 was supposed to be a backwards-compatible, yet it introduced multiple-inheritence to a language which was previously strictly single-inheritence. That sort of change is a major revision of the metamodel and certainly does not qualify as backwards-compatible at that level of abstraction. It may not be important for run-of-the-mill NETCONF operations, but becomes pivotal when you are mapping YANG to other languages. Regards, Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
