Yes, better, thanks! K.
> On Apr 24, 2020, at 3:33 PM, Rob Wilton (rwilton) <rwil...@cisco.com> wrote: > > 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/ > <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> > Sent: 23 April 2020 17:59 > To: Andy Bierman <a...@yumaworks.com> > Cc: Radek Krejci <rkre...@cesnet.cz>; Juergen Schoenwaelder > <j.schoenwael...@jacobs-university.de>; Martin Björklund <mbj+i...@4668.se>; > netmod@ietf.org; Rob Wilton (rwilton) <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 > <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 > <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
