"Sterne, Jason (Nokia - CA/Ottawa)" <jason.ste...@nokia.com> wrote: > That seems like a reasonable approach to me.
I agree. /martin > Jason > > From: netmod <netmod-boun...@ietf.org> On Behalf Of Rob Wilton (rwilton) > Sent: Friday, April 24, 2020 3:34 PM > To: Kent Watsen <kent+i...@watsen.net>; netmod@ietf.org > Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031) > > Hi Kent, > > Thanks for creating the issue. > > I think that errata falls under section 7 of > https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/, and > could be classified as “Hold for Document Update”. I.e. “Changes that modify > the working of a protocol to something that might be different from the > intended consensus when the document was approved should be either Hold for > Document Update or Rejected. Deciding between these two depends on judgment. > Changes that are clearly modifications to the intended consensus, or involve > large textual changes, should be Rejected. In unclear situations, small > changes can be Hold for Document Update.” > > I think that the consensus of the long term fix (e.g. in YANG 1.2) is that > “require-instance” should be allowed under typedefs that refined types that > allow it. > > Pragmatically, I think that we can mark this errata is a “Hold for Document > Update”, with the accompanying errata notes (derived from Radek’s comments) > changed to: > > “The document does not specify whether the “require-instance” keyword is > allowed in typedef refinements derived from the “leafref” or > “instance-identifier” base types, but it is anticipated that a future > revision of YANG would allow this. It is suggested that modules using YANG > language versions 1 [RFC 6020] and 1.1 [RFC 7950] avoid using this construct, > YANG module validation tools flag a warning if this construct is used, but > implementations allow this if possible.” > > Does anyone object to this course of action (or wishes to refine my errata > notes)? > > Regards, > Rob > > > From: Kent Watsen <kent+i...@watsen.net<mailto:kent+i...@watsen.net>> > Sent: 23 April 2020 17:59 > To: Andy Bierman <a...@yumaworks.com<mailto:a...@yumaworks.com>> > Cc: Radek Krejci <rkre...@cesnet.cz<mailto:rkre...@cesnet.cz>>; Juergen > Schoenwaelder > <j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>>; > Martin Björklund <mbj+i...@4668.se<mailto:mbj+i...@4668.se>>; > netmod@ietf.org<mailto:netmod@ietf.org>; Rob Wilton (rwilton) > <rwil...@cisco.com<mailto:rwil...@cisco.com>> > Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031) > > 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<mailto: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 seem to be down. > > > Kent // contributor > > > _______________________________________________ > netmod mailing list > netmod@ietf.org<mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
