Hi Martin!
> I think you meant https://github.com/netmod-wg/yang-next/issues/49. Yes but, in spirit of the idea, I suppose both would be in play, if at all. >> IMO the parsing of YANG files to produce a conceptual data model >> is a critical component of the language itself. Any statements that >> affect this conversion step MUST be regular statements. >> An extension is (by definition) an external statement that is not part of >> the YANG language. >> Critical extensions are not a good design choice. > > I strongly agree. Allowing the language to drastically change (like > in this example) by just defining a critical extension is not a good > idea. Basically, anyone can define their own extension that changes > YANG to whatever, and still claim conformance. I also agree, for this issue (versioning), but there may be other places where a "critical" flag would help (wit the conversation that issue generated). That said, for a limited-scope rfc7950-bis, it would be fine to not pick up either of these issues. >> Just add real statements >> instead. >> >> IMO most of the yang-next issues are not interesting or valuable, >> so a long WG process to go through this entire list is a non-starter. >> > > The problem is that everyone will have their own pet-issues that they > think are critical... > > >> There are 3 critical changes that need to be made. >> - change "status" so deprecated and obsolete definitions are >> correct > > ... for example I don't think this is critical ... > >> - introduce new instance-identifier data type based on RFC 7951 definition >> - introduce new identityref data type based on RFC 7951 definition > > ... but I do agree with these! > > > /martin Whilst the chairs haven't closed this WGLC yet, I propose a YANG-next design team, asked to produce a limited-scope I-D they think best. WG-objections of the form "my pet-issue isn't picked-up" should not be used to fail adoption (or, later, the WGLC). Of course, objections to how the specific-issues picked-up were resolved are valid. The goal being to most expediently (<1yr) forward the versioning work in a correct (contract-compliant) manner. Support? Kent _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
