Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

[Radek Krejci <[e-mail]>]

Hi,

Dne 09. 04. 20 v 17:26 Kent Watsen napsal(a):
>
>
>> On Apr 6, 2020, at 3:42 AM, Juergen Schoenwaelder
>> <[e-mail]
>> <mailto:[e-mail]>> 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 <[e-mail]
>> <mailto:[e-mail]>> 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
>