Hi, I agree with Juergen that this errata should be rejected and the issue resolved in yang-next. No IETF module should use this construct. It is easy to convert to an equivalent form that is not under dispute.
Andy On Tue, Apr 14, 2020 at 6:40 AM Radek Krejci <[email protected]> wrote: > Hi, > > Dne 09. 04. 20 v 17:26 Kent Watsen napsal(a): > > > > On Apr 6, 2020, at 3:42 AM, Juergen Schoenwaelder < > [email protected]> wrote: > > The definition I found in RFC 8639 is this: > > leaf stream { > type stream-ref { > require-instance false; > } > mandatory true; > description > "Indicates the event stream to be considered for > this subscription."; > } > > This could be changed to: > > leaf stream { > type leafref { > path "/sn:streams/sn:stream/sn:name"; > require-instance false; > } > mandatory true; > description > "Indicates the event stream to be considered for > this subscription."; > } > > > I can confirm that `yanglint` validates the module cleanly after this > change. > > > > On Apr 6, 2020, at 7:38 AM, Martin Björklund <[email protected]> wrote: > > I think the correct fix is to change the text so that > "require-instance" is not classified as a restriction and keep the > default. > > > Agreed. > > > Also, I think that it would be easiest (for backwards > compatibility w/ existing models) to allow "require-inetance" to be > changed in derived types. > > However, this cannot imo be done in an errata. > > > While I appreciate Radek and Michal’s perspective, I also think that is > would be best for the community for `yanglint` to support this, as they are > published modules doing it. > > > I don't feel as an expert for IETF processes, so I don't know if this > issue can be solved in errata or not (and I'm not sure there is a consensus > on this in mailing list). For the implementation, I would appreciate at > least a consensus on a solution. So far I saw opinions to allow it, to > disallow and also to make it implementation-specific (which means in fact > to disallow from the authors perspective, since there can be a tool > disallowing it and we are saying that such a tool is ok). So, there is no > clear way for implementors, which means problems for interoperability - > there will be always someone unhappy and so far I don't know what is the > major opinion to go. > > So far, I tend to allow it (accept by libyang), but print warning to warn > authors about possible problems (some tool can refuse such a module). Is it > ok? > > Radek > > > As an aside, I feel that all modules should be tested against all > available validation tools during the publication process, but to find > issues in the modules and well as possibly improve the tools. > > Sadly, I only have `yanglint` and `yangson` available to me. I just > checked for the “yang validator” project, but both www.yangvalidator.com > and https://www.yangcatalog.org/yangvalidator seem to be down. > > > Kent // contributor > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
