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 > seem > to be down. > > > Kent // contributor >
smime.p7s
Description: Elektronicky podpis S/MIME
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
