On 12/06/2019 13:01, Ladislav Lhotka wrote: >>> What I meant was rather something like >>> >>> pattern-language "POSIX"; >>>
Yeah, that is what I proposed here: https://github.com/openconfig/public/issues/44#issuecomment-416320334 >> But depending on how many pattern languages are supported, wouldn’t that make >> implementing YANG a lot harder, since implementations would need to support >> all the allowed pattern languages? > Not necessarily, implementors should be able decide which flavours to support. > So OpenConfig would be a niche that uses POSIX, and they have to use tools > that > support it. Well, some of the languages need to be mandatory-to-implement otherwise things like unions stop working consistently. > The real problem here is that they use an extension for changing the semantics > of a built-in YANG statement, which is IMO not permitted by RFC 7950 and > causes > implementations to break without warning, or even opens security holes. If it > was a critical extension, and I didn't want to implement the POSIX flavour, my > implementation should be able to notice it and say "Sorry, I can't work with > this module". I could argue that tailf:action introduced such an extension, as users expected augment to work with it -- except a parser cannot assume an extension it knows nothing about actually defines a thing in the schema tree. In my mind that constitutes prior art of getting things work in the field before standardizing. It makes little difference to me as an implementer whether the users scream at me for the patterns not working as expected (we've had equivalents of the issue you referenced pop up for years now) or they scream because the tooling rejects to work with the models. In either case the source is whoever wrote the models and it is the expectation that tools work Just Work (tm). Regards, Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
