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]> 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
>> <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
> <https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
