The consensus seems to be that: - the errata should be rejected - Rob, do you agree? - YANG-next should fix it later - I created https://github.com/netmod-wg/yang-next/issues/104 - implementations should try to do the right thing now - Radek’s suggestion below LGTM!
Tallies: - for reject: Andy, Martin, Juergen, and Kent - for accept: Radek, and Balazs - unclear: Lada, Rob, and Jason Kent // as co-chair > On Apr 14, 2020, at 10:35 AM, Andy Bierman <a...@yumaworks.com> wrote: > > 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 <rkre...@cesnet.cz > <mailto:rkre...@cesnet.cz>> wrote: > Hi, > > Dne 09. 04. 20 v 17:26 Kent Watsen napsal(a): >> >> >>> On Apr 6, 2020, at 3:42 AM, Juergen Schoenwaelder >>> <j.schoenwael...@jacobs-university.de >>> <mailto:j.schoenwael...@jacobs-university.de>> 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 <mbj+i...@4668.se >>> <mailto:mbj+i...@4668.se>> 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 >> <http://www.yangvalidator.com/> and >> https://www.yangcatalog.org/yangvalidator >> <https://www.yangcatalog.org/yangvalidator> seem to be down. >> >> >> Kent // contributor >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org <mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod > <https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod