Re: [netmod] yang-data-ext issues
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
[netmod] YANG Model Versioning Design Team
Hi, As discussed at the NETMOD WG session in IETF 101, London, we would like to set up a design team for YANG versioning. The proposed charter for the design team is as follows: The YANG Model Versioning Design Team is chartered to propose a revised approach to supporting YANG module updates. The existing approach is described in [1], and related issues have been discussed at IETF 100 [2], IETF 101 [3] and in [4]. The Design Team will document the current problem, related requirements and objections, and lead the WG related discussion to ensure consensus. The result of this effort is expected to be an individual draft which may be adopted by the WG per normal process. The goal of the design team is to have this draft published prior to IETF 102. The Design Team is also expected to explore the possible solution space and propose a single solution to the WG in the form of an individual document. The goal of the design team is to have an initial version of this draft available prior to IETF 103, and to help with the effort of achieving WG adoption of the draft. The Design Team is expected to close once there is WG draft providing a revised solution to supporting YANG module updates. We have asked Rob Wilton to lead the DT and would like to ask that those who are interested in joining the design team please contact the chairs and Rob Wilton. Note if you have already sent mail to the chairs regarding volunteering, there is no need to send an additional e-mail. If you volunteer and are not asked to join, please know that you will have ample opportunity to provide input as any documents produced by the DT will follow normal WG process, starting with a normal WG adoption call. Thank you, NETMOD WG Chairs [1] https://tools.ietf.org/html/rfc7950#section-11 [2] https://datatracker.ietf.org/meeting/100/session/netmod [3] https://datatracker.ietf.org/meeting/101/session/netmod [4] https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
