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

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 3 Apr 2020 12:06:17 +0000

> -----Original Message-----
> From: netmod <[email-masked]> On Behalf Of Juergen Schoenwaelder
> Sent: 27 March 2020 16:13
> To: Martin Björklund <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; rfc-
> [email-masked]
> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> 
> On Fri, Mar 27, 2020 at 04:35:44PM +0100, Martin Björklund wrote:
> > [re-sent w/ correct address]
> >
> > Juergen Schoenwaelder <[email-masked]> wrote:
> > > Hi,
> > >
> > > two comments:
> > >
> > > - It is unclear to me whether this really qualifies as an errata.
> > >
> > > - If we add this, then there should probably text about which
> > >   combinations are allowed. For example, for pattern and ranges, there
> > >   is explicit text that says further restrictions of the value space
> > >   are possible, bot not expansions. If we follow that logic, then
> > >
> > >   typedef a {
> > >     type leaf-ref {
> > >       path "/some/thing";
> > >       require-instance true;
> > >     }
> > >   }
> > >
> > >   typedef b {
> > >     type a {
> > >       require-instance false;
> > >     }
> > >   }
> > >
> > >   might be illegal since b has a larger value space than a.
> >
> > The value space of b is the same as for a. "require-instance" doesn't
> > change the value space; it changes semantic validation of the given
> > values ((see my mail from 17 Mar, "Require-instance problem").
> >
> > /martin
> 
> OK. If we consider require-instance a constraint and not a restriction,
> then the motivation for this errata is at least
> confusing:
> 
>   Since no one argued against this understanding, this errata changes
>   the text to the same form as in other restrictions applicable to
>   derived types.
> 
> Simply put: Do you think it is OK to overwrite a require-instance true
> with a require-instance false in a derived type?
[RW] 
I'm not sure, but going in the other direction seems plausible.

E.g. you start with a typedef that is explicitly require-instance false that is then refined by a typedef to be require-instance true.

Regards,
Rob

> 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 3 Apr 2020 13:31:50 +0000

I don't think we should allow overwriting a require-instance true with a require-instance false in a derived type. It seems to go against the spirit of avoiding expansion of allowable values.

>From section 4.1 of RFC7950:

        Derived types can restrict their base type's set of valid values

And this text in section 7.3.4 implies that derived types only do further restriction:

    If the type's default value is not valid according to the new
   restrictions specified in a derived type or leaf definition, the
   derived type or leaf definition MUST specify a new default value
   compatible with the restrictions.

Going the other direction (overwriting with require-instance true) seems OK to me.

Jason

> From: netmod <[email-masked]> On Behalf Of Rob Wilton (rwilton)
> Sent: Friday, April 3, 2020 8:06 AM
> To: Juergen Schoenwaelder <[email-masked]>; Martin
> Björklund <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]
> E.g. you start with a typedef that is explicitly require-instance false that is then
> refined by a typedef to be require-instance true.
> 
> Regards,
> Rob
> 
> 
> >
> > /js
> >
> > --

---

From: Martin Björklund <[email-masked]>
Date: Fri, 03 Apr 2020 15:54:21 +0200 (CEST)

Hi,

"Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]> wrote:
> I don't think we should allow overwriting a require-instance true with
> a require-instance false in a derived type. It seems to go against the
> spirit of avoiding expansion of allowable values.

As I wrote earlier in this thread, the value space doesn't change with
require-instance.

/martin

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 3 Apr 2020 14:01:09 +0000

Hi Martin,

I believe you that the technical "value space" doesn't change, but that leaf would suddenly accept more values than it did before right?  I'm wondering if we want to follow the "spirit" here, or stick with the "value space" argument. 

I'm not really certain what the implications are (and maybe someone has an example of why it is better to allow it?) but overwriting require-instance with 'false' doesn't feel right.

Jason

> From: Martin Björklund <[email-masked]>
> Sent: Friday, April 3, 2020 9:54 AM
> To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
> Cc: rwilton=[email-masked]; j.schoenwaelder@jacobs-
> university.de; [email-masked]; [email-masked]; [email-masked]; rfc-
> [email-masked]

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 03 Apr 2020 16:52:09 +0200

On Fri, 2020-04-03 at 14:01 +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote:
> Hi Martin,
> 
> I believe you that the technical "value space" doesn't change, but that leaf
> would suddenly accept more values than it did before right?  I'm wondering if
> we want to follow the "spirit" here, or stick with the "value space" argument.

I agree with Martin here. Moreover, if such a derived type is added, it doesn't
change anything related to existing data, because they use the base type as
before. New data nodes may use the new type but no confusion can arise - their
type has "require-instance false", which is correct.

Lada  

> 
> I'm not really certain what the implications are (and maybe someone has an
> example of why it is better to allow it?) but overwriting require-instance
> with 'false' doesn't feel right.
> 
> Jason
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 3 Apr 2020 16:24:35 +0000

For the errata, it looks like there are two choices:

1) We reject this errata, on the grounds that it is unclear on what the behaviour was expected to be.  It is left unspecified as to whether require-instance is allowed in a typedef.  We add an issue on the YANG.Next issue tracker to sort this out in a future revision of YANG.

2) We agree on what the expected behaviour should be, in which case it may be possible that this can be "Hold for document update", although it still seems questionable whether this really fits as an errata.

Regards,
Rob

> From: netmod <[email-masked]> On Behalf Of Ladislav Lhotka
> Sent: 03 April 2020 15:52
> To: [email-masked]
> > I believe you that the technical "value space" doesn't change, but
> > that leaf would suddenly accept more values than it did before right?
> > I'm wondering if we want to follow the "spirit" here, or stick with the
> "value space" argument.
> 
> I agree with Martin here. Moreover, if such a derived type is added, it
> doesn't change anything related to existing data, because they use the
> base type as before. New data nodes may use the new type but no confusion
> can arise - their type has "require-instance false", which is correct.
> 
> Lada
> 
> >
> > I'm not really certain what the implications are (and maybe someone
> > has an example of why it is better to allow it?) but overwriting
> > require-instance with 'false' doesn't feel right.
> >
> > Jason
> >
> > > university.de; [email-masked]; [email-masked]; [email-masked];
> > > rfc- [email-masked]
> > > > I don't think we should allow overwriting a require-instance true
> > > > with a require-instance false in a derived type. It seems to go
> > > > against the spirit of avoiding expansion of allowable values.
> > >
> > > As I wrote earlier in this thread, the value space doesn't change
> > > with require-instance.
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > > > > To: Juergen Schoenwaelder
> > > > > <[email-masked]>;
> > > > > Martin
> > > > > > Cc: [email-masked]; [email-masked]; [email-masked];
> > > > > > rfc- [email-masked]
> > > > > > > >   combinations are allowed. For example, for pattern and
> > > > > > > > ranges,
> > > there
> > > > > > > change the value space; it changes semantic validation of
> > > > > > > the given values ((see my mail from 17 Mar, "Require-instance
> problem").
> > > > > > >
> > > > > > > /martin
> > > > > >
> > > > > > OK. If we consider require-instance a constraint and not a
> > > > > > restriction, then the motivation for this errata is at least
> > > > > > confusing:
> > > > > >
> > > > > > Simply put: Do you think it is OK to overwrite a
> > > > > > require-instance true with a require-instance false in a derived
> type?
> > > > > [RW]
> > > > > E.g. you start with a typedef that is explicitly
> > > > > require-instance false that is then refined by a typedef to be
> > > > > require-instance true.
> > > > >
> > > > > Regards,
> > > > > Rob
> > > > >
> > > > >
> > > > > > /js
> > > > > >
> > > > > > --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 Apr 2020 18:55:38 +0200

I propose option 1) and add an issue on yang-next (if not already
there yet).

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 3 Apr 2020 13:36:04 -0700

> I propose option 1) and add an issue on yang-next (if not already
+1  (Noting that neither pyang or yangdump-pro handles this correctly right
now)

> /js
Andy

> > 1) We reject this errata, on the grounds that it is unclear on what the
> behaviour was expected to be.  It is left unspecified as to whether
> require-instance is allowed in a typedef.  We add an issue on the YANG.Next
> issue tracker to sort this out in a future revision of YANG.
> >
> > 2) We agree on what the expected behaviour should be, in which case it
> may be possible that this can be "Hold for document update", although it
> still seems questionable whether this really fits as an errata.
> >
> > Regards,
> > Rob
> >
> >
> > > > > > Going the other direction (overwriting with require-instance
> true)
> > > > > > seems OK to me.
> > > > > >
> > > > > > Jason
> > > > > >
> > > > > >
> > > > > > > > > Juergen Schoenwaelder <
> [email-masked]>
> > > > > wrote:
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > two comments:
> > > > > > > > > >
> > > > > > > > > The value space of b is the same as for a.
> "require-instance"
> > > > > > > > > doesn't
> > > > > > > >   the text to the same form as in other restrictions
> applicable
> > > to
> > > > > > > >   derived types.
> > > > > > > >
> > > > > > > > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen
> |
> > > Germany

---

From: Radek Krejci <[email-masked]>
Date: Mon, 6 Apr 2020 08:51:46 +0200

Hi,
I just want to emphasis, what are the consequences of the option 1. This
way, the tools are allowed to not accept require-instance in derived
types, so actually schema authors SHOULD NOT use require-instance this
way. Since there is at least 1 YANG model in RFC (8639 and I would
expect more), which has require-instance in the derive type, errata will
be needed in this case(s).

Regards,
Radek

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Apr 2020 09:42:35 +0200

> be needed in this case(s).

RFC 7950 says in 9.9.3:

  If this statement is not present, it defaults to "true".

This means that require-instance is 'on by default'. Hence, it is
necessary to use what RFC 7950 calls a 'restriction' (9.9.1) to
effectively _remove_ what seems like a restriction (or constraint).
(This text apparently has already been in RFC 6020.)

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.";
        }

What bothers me here is that I find the design of the default
behaviour backwards. If the default would have been

  If this statement is not present, it defaults to "false".

then require-instance could be used to add a constraint in derived
types but not to remove it (like the other type restrictions).

If people were to agree that the default here is wrong, can the
problem be fixed?  Likely not since changing the default (even in say
YANG 2.0) could have drastic consequences and would essentially
require to be always explicit about the require-instance property to
be on the safe side.

/js

---

From: Martin Björklund <[email-masked]>
Date: Mon, 06 Apr 2020 13:38:05 +0200 (CEST)

> (This text apparently has already been in RFC 6020.)

I think the correct fix is to change the text so that
"require-instance" is not classified as a restriction and keep the
default.  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.

/martin

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 8 Apr 2020 08:27:53 +0000

I would like to allow require-instance in derived types (done in errata or
any other way) because we allow other constraints to be changed. Regularity
of YANG is very important for me. Learning YANG is difficult enough without
adding new exception cases.

Also as I consider this undefined, it is better to document whether this is
allowed or not. This is a binary decision, either/or. If setting it as a
YANG language rule is to strict, we still need a guideline at least for RFC
authors, shall we consider it a problem or not? 
Balazs

-----Original Message-----
From: netmod <[email-masked]> On Behalf Of Martin Björklund
Sent: 2020. április 6., hétfő 13:38
To: [email-masked]
Cc: [email-masked]; rwilton=[email-masked]
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

Juergen Schoenwaelder <[email-masked]> wrote:
> > I just want to emphasis, what are the consequences of the option 1. 
> > This way, the tools are allowed to not accept require-instance in 
> > derived types, so actually schema authors SHOULD NOT use 
> > require-instance this way. Since there is at least 1 YANG model in 
> > RFC (8639 and I would expect more), which has require-instance in 
> > the derive type, errata will be needed in this case(s).
> >
> 
> RFC 7950 says in 9.9.3:
> 

I think the correct fix is to change the text so that "require-instance" is
not classified as a restriction and keep the default.  Also, I think that it
would be easiest (for backwards compatibility w/ existing models) to allow
"require-inetance" to be changed in derived types.

/martin

> > >> 1) We reject this errata, on the grounds that it is unclear on what
the behaviour was expected to be.  It is left unspecified as to whether
require-instance is allowed in a typedef.  We add an issue on the YANG.Next
issue tracker to sort this out in a future revision of YANG.
> > >>
> > >> 2) We agree on what the expected behaviour should be, in which case
it may be possible that this can be "Hold for document update", although it
still seems questionable whether this really fits as an errata.
> > >>> On Fri, 2020-04-03 at 14:01 +0000, Sterne, Jason (Nokia - 
> > >>> CA/Ottawa)
> > >>> wrote:
> > >>>> Hi Martin,
> > >>>>
> > >>>> I believe you that the technical "value space" doesn't change, 
> > >>>> but that leaf would suddenly accept more values than it did before
right?
> > >>> I agree with Martin here. Moreover, if such a derived type is 
> > >>> added, it doesn't change anything related to existing data, 
> > >>> because they use the base type as before. New data nodes may use 
> > >>> the new type but no confusion can arise - their type has
"require-instance false", which is correct.
> > >>>
> > >>> Lada
> > >>>
> > >>>> I'm not really certain what the implications are (and maybe 
> > >>>> someone has an example of why it is better to allow it?) but 
> > >>>> overwriting require-instance with 'false' doesn't feel right.
> > >>>>
> > >>>> Jason
> > >>>>
> > >>>>> Cc: rwilton=[email-masked]; 
> > >>>>> j.schoenwaelder@jacobs- university.de; [email-masked]; 
> > >>>>> [email-masked]; [email-masked];
> > >>>>>> I don't think we should allow overwriting a require-instance 
> > >>>>>> true with a require-instance false in a derived type. It 
> > >>>>>> seems to go against the spirit of avoiding expansion of allowable
values.
> > >>>>> As I wrote earlier in this thread, the value space doesn't 
> > >>>>> change with require-instance.
> > >>>>>
> > >>>>>
> > >>>>> /martin
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> true) seems OK to me.
> > >>>>>>> From: netmod <[email-masked]> On Behalf Of Rob 
> > >>>>>>> Wilton
> > >>>>>>> (rwilton)
> > >>>>>>>>> Juergen Schoenwaelder 
> > >>>>>>>>> <[email-masked]>
> > >>>>> wrote:
> > >>>>>>>>>> Hi,
> > >>>>>>>>>>
> > >>>>>>>>>> two comments:
> > >>>>>>>>>>
> > >>>>>>>>   Since no one argued against this understanding, this 
> > >>>>>>>> errata
> > >>> changes
> > >>>>>>> require-instance false that is then refined by a typedef to 
> > >>>>>>> be require-instance true.
> > >>>>>>>
> > >>>>>>> Regards,
> > >>>>>>> Rob
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>> /js
> > >>>>>>>>
> > >>>>>>>> --
> Fax:   +49 421 200 3103
<https://protect2.fireeye.com/v1/url?k=58bd6cd1-04696b7d-58bd2c4a-8667c4afe1
3e-71a13094f514c718&q=1&e=191787dd-7c26-48db-93a5-c2bba7224ee6&u=https%3A%2F
%2Fwww.jacobs-university.de%2F>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 9 Apr 2020 15:26:02 +0000

> On Apr 6, 2020, at 3:42 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

I can confirm that `yanglint` validates the module cleanly after this change.

> On Apr 6, 2020, at 7:38 AM, Martin Björklund <[email-masked]> wrote:
> 
> default.  

Agreed.

> Also, I think that it would be easiest (for backwards

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.

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

---

From: Radek Krejci <[email-masked]>
Date: Tue, 14 Apr 2020 15:40:20 +0200

Hi,

Dne 09. 04. 20 v 17:26 Kent Watsen napsal(a):
>
>
>> On Apr 6, 2020, at 3:42 AM, Juergen Schoenwaelder
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> On Apr 6, 2020, at 7:38 AM, Martin Björklund <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
> 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
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 14 Apr 2020 07:35:19 -0700

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-masked]> wrote:

> On Apr 6, 2020, at 3:42 AM, Juergen Schoenwaelder <
> 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.
>
>
> 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
>
>
> checked for the “yang validator” project, but both www.yangvalidator.com
>  and https://www.yangcatalog.org/yangvalidator seem to be down.
>
>
> Kent // contributor
>
>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 23 Apr 2020 16:59:06 +0000

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-masked]> 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-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
>>> On Apr 6, 2020, at 3:42 AM, Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> On Apr 6, 2020, at 7:38 AM, Martin Björklund <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
> 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
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 24 Apr 2020 00:41:07 +0000

I finally caught up to this thread. I agree with concerns raised by Radek and Balazs, but as others have mentioned an errata doesn’t seem to be the right medium for this. OTOH, yang-next might be too far away…. Could we do an update to RF7950 just for this? I realize it’s lots of work/overhead for “just” this issue.

Regards,
Reshad.

From: netmod <[email-masked]> on behalf of Kent Watsen <[email-masked]>
Date: Thursday, April 23, 2020 at 12:59 PM
To: 'Andy Bierman' <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Rob Wilton (rwilton)" <rwilton=[email-masked]>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

Tallies:

Kent // as co-chair

On Apr 14, 2020, at 10:35 AM, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Andy

On Tue, Apr 14, 2020 at 6:40 AM Radek Krejci <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
Dne 09. 04. 20 v 17:26 Kent Watsen napsal(a):

On Apr 6, 2020, at 3:42 AM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

       leaf stream {
         type stream-ref {
           require-instance false;
         }
         mandatory true;
         description

       leaf stream {
         type leafref {

On Apr 6, 2020, at 7:38 AM, Martin Björklund <[email-masked]<mailto:[email-masked]>> wrote:

Agreed.

Radek

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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 24 Apr 2020 19:33:41 +0000

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 <[email-masked]>
Sent: 23 April 2020 17:59
To: Andy Bierman <[email-masked]>
Cc: Radek Krejci <[email-masked]>; Juergen Schoenwaelder <[email-masked]>; Martin Björklund <[email-masked]>; [email-masked]; Rob Wilton (rwilton) <[email-masked]>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

Tallies:

Kent // as co-chair

Hi,

Andy

       leaf stream {
         type stream-ref {
           require-instance false;
         }
         mandatory true;
         description

       leaf stream {
         type leafref {

Agreed.

Radek

Kent // contributor

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 24 Apr 2020 19:39:07 +0000

That seems like a reasonable approach to me.
Jason

From: netmod <[email-masked]> On Behalf Of Rob Wilton (rwilton)
Sent: Friday, April 24, 2020 3:34 PM
To: Kent Watsen <[email-masked]>; [email-masked]
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

Hi Kent,

Regards,
Rob

From: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Sent: 23 April 2020 17:59
To: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Cc: Radek Krejci <[email-masked]<mailto:[email-masked]>>; Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>>; Martin Björklund <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

Tallies:

Kent // as co-chair

Hi,

Andy

       leaf stream {
         type stream-ref {
           require-instance false;
         }
         mandatory true;
         description

       leaf stream {
         type leafref {

Agreed.

Radek

Kent // contributor

---

From: Martin Björklund <[email-masked]>
Date: Fri, 24 Apr 2020 21:54:24 +0200 (CEST)

> That seems like a reasonable approach to me.

I agree.

/martin

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 24 Apr 2020 19:57:13 +0000

Makes sense, it’s good with me.

Regards,
Reshad.

From: netmod <[email-masked]> on behalf of "Rob Wilton (rwilton)" <rwilton=[email-masked]>
Date: Friday, April 24, 2020 at 3:34 PM
To: Kent Watsen <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

Hi Kent,

Regards,
Rob

Tallies:

Kent // as co-chair

Hi,

Andy

       leaf stream {
         type stream-ref {
           require-instance false;
         }
         mandatory true;
         description

       leaf stream {
         type leafref {

Agreed.

Radek

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Fri, 24 Apr 2020 21:08:53 +0000

Yes, better, thanks!

K.

> On Apr 24, 2020, at 3:33 PM, Rob Wilton (rwilton) <[email-masked]> wrote:
> 
> Hi Kent,
>  
> 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 created https://github.com/netmod-wg/yang-next/issues/104 <https://github.com/netmod-wg/yang-next/issues/104>
> On Apr 14, 2020, at 10:35 AM, Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi,
>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 27 Apr 2020 11:20:20 +0000

Thanks.  I’ll wait until Friday for any further comments.

Thanks,
Rob

From: Kent Watsen <[email-masked]>
Sent: 24 April 2020 22:09
To: Rob Wilton (rwilton) <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

Yes, better, thanks!

K.

On Apr 24, 2020, at 3:33 PM, Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kent,

Regards,
Rob

Tallies:

Kent // as co-chair

Hi,

Andy

       leaf stream {
         type stream-ref {
           require-instance false;
         }
         mandatory true;
         description

       leaf stream {
         type leafref {

Agreed.

Radek

Kent // contributor

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 27 Apr 2020 10:30:18 -0700

+1.

> On Apr 24, 2020, at 12:39 PM, Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]> wrote:
> 
> I think that errata falls under section 7 ofhttps://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.”
>  
> From: Kent Watsen <[email-masked] <mailto:[email-masked]>> 
> To: Andy Bierman <[email-masked] <mailto:[email-masked]>>
> Cc: Radek Krejci <[email-masked] <mailto:[email-masked]>>; Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]>>; Martin Björklund <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Rob Wilton (rwilton) <[email-masked] <mailto:[email-masked]>>

---

From: Radek Krejci <[email-masked]>
Date: Tue, 28 Apr 2020 10:34:25 +0200

+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-masked] <mailto:[email-masked]>> wrote:
>>
>> *From:* netmod <[email-masked]
>> <mailto:[email-masked]>> *On Behalf Of *Rob Wilton (rwilton)
>> *Sent:* Friday, April 24, 2020 3:34 PM
>> *To:* Kent Watsen <[email-masked]
>> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> *Subject:* Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
>>  
>> Hi Kent,
>>  
>> 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.”
>>  
>> *From:* Kent Watsen <[email-masked] <mailto:[email-masked]>> 
>> *Sent:* 23 April 2020 17:59
>> *To:* Andy Bierman <[email-masked] <mailto:[email-masked]>>
>> *Cc:* Radek Krejci <[email-masked] <mailto:[email-masked]>>;
>> Juergen Schoenwaelder <[email-masked]
>> <mailto:[email-masked]>>; Martin Björklund
>> <[email-masked] <mailto:[email-masked]>>; [email-masked]
>> <mailto:[email-masked]>; Rob Wilton (rwilton) <[email-masked]
>> <mailto:[email-masked]>>
>> *Subject:* Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
>>  
>>     No IETF module should use this construct. It is easy to convert
>>     to an equivalent form that is not under dispute.
>>      
>>      
>>     Andy
>>      
>>      
>>                 On Apr 6, 2020, at 7:38 AM, Martin Björklund
>>                 <[email-masked] <mailto:[email-masked]>> wrote:
>>                  
>>             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
>>             <http://www.yangvalidator.com/> and https://www.yangcatalog.org/yangvalidator seem
>>             to be down.
>>              
>>              
>>             Kent // contributor
>>              
>>
>>