+1 Thanks Kent and Rob for moving this forward, we should release libyang/yanglint with this change within 2 weeks.
Regards, Radek Dne 27. 04. 20 v 19:30 Mahesh Jethanandani napsal(a): > +1. > >> On Apr 24, 2020, at 12:39 PM, Sterne, Jason (Nokia - CA/Ottawa) >> <[email protected] <mailto:[email protected]>> wrote: >> >> That seems like a reasonable approach to me. >> Jason >> >> *From:* netmod <[email protected] >> <mailto:[email protected]>> *On Behalf Of *Rob Wilton (rwilton) >> *Sent:* Friday, April 24, 2020 3:34 PM >> *To:* Kent Watsen <[email protected] >> <mailto:[email protected]>>; [email protected] <mailto:[email protected]> >> *Subject:* Re: [netmod] [Technical Errata Reported] RFC7950 (6031) >> >> Hi Kent, >> >> Thanks for creating the issue. >> >> I think that errata falls under section 7 >> ofhttps://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 <[email protected] <mailto:[email protected]>> >> *Sent:* 23 April 2020 17:59 >> *To:* Andy Bierman <[email protected] <mailto:[email protected]>> >> *Cc:* Radek Krejci <[email protected] <mailto:[email protected]>>; >> Juergen Schoenwaelder <[email protected] >> <mailto:[email protected]>>; Martin Björklund >> <[email protected] <mailto:[email protected]>>; [email protected] >> <mailto:[email protected]>; Rob Wilton (rwilton) <[email protected] >> <mailto:[email protected]>> >> *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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[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] >> <mailto:[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] <mailto:[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 >> <http://www.yangvalidator.com/> and >> https://www.yangcatalog.org/yangvalidator seem >> to be down. >> >> >> Kent // contributor >> >> >> >> _______________________________________________ >> netmod mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> _______________________________________________ >> netmod mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod
smime.p7s
Description: Elektronicky podpis S/MIME
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
