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

[Radek Krejci]

+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)
>> mailto:jason.ste...@nokia.com>> wrote:
>>
>> That seems like a reasonable approach to me.
>> Jason
>>  
>> *From:* netmod > <mailto:netmod-boun...@ietf.org>> *On Behalf Of *Rob Wilton (rwilton)
>> *Sent:* Friday, April 24, 2020 3:34 PM
>> *To:* Kent Watsen > <mailto:kent+i...@watsen.net>>; netmod@ietf.org <mailto:netmod@ietf.org>
>> *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 mailto:kent+i...@watsen.net>> 
>> *Sent:* 23 April 2020 17:59
>> *To:* Andy Bierman mailto:a...@yumaworks.com>>
>> *Cc:* Radek Krejci mailto:rkre...@cesnet.cz>>;
>> Juergen Schoenwaelder > <mailto:j.schoenwael...@jacobs-university.de>>; Martin Björklund
>> mailto:mbj+i...@4668.se>>; netmod@ietf.org
>> <mailto:netmod@ietf.org>; Rob Wilton (rwilton) > <mailto: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
>>   - 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 > <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 > <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
>> > <mailto:j.schoenwael...@jacobs-university.de>> wrote:
>>  
>>
>> The definition I found in RFC 86

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

[Mahesh Jethanandani]

+1.

> On Apr 24, 2020, at 12:39 PM, Sterne, Jason (Nokia - CA/Ottawa) 
>  wrote:
> 
> That seems like a reasonable approach to me.
> Jason
>  
> From: netmod  On Behalf Of Rob Wilton (rwilton)
> Sent: Friday, April 24, 2020 3:34 PM
> To: Kent Watsen ; netmod@ietf.org
> 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/ 
> <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 mailto:kent+i...@watsen.net>> 
> Sent: 23 April 2020 17:59
> To: Andy Bierman mailto:a...@yumaworks.com>>
> Cc: Radek Krejci mailto:rkre...@cesnet.cz>>; Juergen 
> Schoenwaelder  <mailto:j.schoenwael...@jacobs-university.de>>; Martin Björklund 
> mailto:mbj+i...@4668.se>>; netmod@ietf.org 
> <mailto:netmod@ietf.org>; Rob Wilton (rwilton)  <mailto: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  <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  <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 
>  <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

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

[Rob Wilton (rwilton)]

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

Thanks,
Rob


From: Kent Watsen 
Sent: 24 April 2020 22:09
To: Rob Wilton (rwilton) 
Cc: netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

Yes, better, thanks!

K.



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

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

[Kent Watsen]

Yes, better, thanks!

K.


> On Apr 24, 2020, at 3:33 PM, Rob Wilton (rwilton)  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  
> Sent: 23 April 2020 17:59
> To: Andy Bierman 
> Cc: Radek Krejci ; Juergen Schoenwaelder 
> ; Martin Björklund ; 
> netmod@ietf.org; Rob Wilton (rwilton) 
> 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  <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  <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 
>  <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  <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 perspec

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

[Reshad Rahman (rrahman)]

Makes sense, it’s good with me.

Regards,
Reshad.

From: netmod  on behalf of "Rob Wilton (rwilton)" 

Date: Friday, April 24, 2020 at 3:34 PM
To: Kent Watsen , "netmod@ietf.org" 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

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 
Sent: 23 April 2020 17:59
To: Andy Bierman 
Cc: Radek Krejci ; Juergen Schoenwaelder 
; Martin Björklund ; 
netmod@ietf.org; Rob Wilton (rwilton) 
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 
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 
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 
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 
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 interoperabi

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

[Martin Björklund]

"Sterne, Jason (Nokia - CA/Ottawa)"  wrote:
> That seems like a reasonable approach to me.

I agree.


/martin


> Jason
> 
> From: netmod  On Behalf Of Rob Wilton (rwilton)
> Sent: Friday, April 24, 2020 3:34 PM
> To: Kent Watsen ; netmod@ietf.org
> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> 
> 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 mailto:kent+i...@watsen.net>>
> Sent: 23 April 2020 17:59
> To: Andy Bierman mailto:a...@yumaworks.com>>
> Cc: Radek Krejci mailto:rkre...@cesnet.cz>>; Juergen 
> Schoenwaelder 
> mailto:j.schoenwael...@jacobs-university.de>>;
>  Martin Björklund mailto:mbj+i...@4668.se>>; 
> netmod@ietf.org<mailto:netmod@ietf.org>; Rob Wilton (rwilton) 
> mailto: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
>   - 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 
> 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 
> 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 
> 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 
> 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.
> 
&

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

[Sterne, Jason (Nokia - CA/Ottawa)]

That seems like a reasonable approach to me.
Jason

From: netmod  On Behalf Of Rob Wilton (rwilton)
Sent: Friday, April 24, 2020 3:34 PM
To: Kent Watsen ; netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

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 mailto:kent+i...@watsen.net>>
Sent: 23 April 2020 17:59
To: Andy Bierman mailto:a...@yumaworks.com>>
Cc: Radek Krejci mailto:rkre...@cesnet.cz>>; Juergen 
Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>;
 Martin Björklund mailto:mbj+i...@4668.se>>; 
netmod@ietf.org<mailto:netmod@ietf.org>; Rob Wilton (rwilton) 
mailto: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
  - 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 
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 
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 
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 
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

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

[Rob Wilton (rwilton)]

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 
Sent: 23 April 2020 17:59
To: Andy Bierman 
Cc: Radek Krejci ; Juergen Schoenwaelder 
; Martin Björklund ; 
netmod@ietf.org; Rob Wilton (rwilton) 
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 
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 
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 
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 
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?

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

[Reshad Rahman (rrahman)]

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  on behalf of Kent Watsen 

Date: Thursday, April 23, 2020 at 12:59 PM
To: 'Andy Bierman' 
Cc: "netmod@ietf.org" , "Rob Wilton (rwilton)" 

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 
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 
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 
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 
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 seem to be down.


Kent // contributor


___
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

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  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  > wrote:
> Hi,
> 
> Dne 09. 04. 20 v 17:26 Kent Watsen napsal(a):
>> 
>> 
>>> On Apr 6, 2020, at 3:42 AM, Juergen Schoenwaelder 
>>> >> > 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 >> > 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 
>>  and 
>> https://www.yangcatalog.org/yangvalidator 
>>  seem to be down.
>> 
>> 
>> Kent // contributor
>> 
> 
> ___
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

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  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> 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  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
>  and https://www.yangcatalog.org/yangvalidator seem to be down.
>
>
> Kent // contributor
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Radek Krejci]

Hi,

Dne 09. 04. 20 v 17:26 Kent Watsen napsal(a):
>
>
>> On Apr 6, 2020, at 3:42 AM, Juergen Schoenwaelder
>> > > 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 > > 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
>  and https://www.yangcatalog.org/yangvalidator 
> seem
> to be down.
>
>
> Kent // contributor
>



smime.p7s
Description: Elektronicky podpis S/MIME
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

> On Apr 6, 2020, at 3:42 AM, Juergen Schoenwaelder 
>  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  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.

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 
 and https://www.yangcatalog.org/yangvalidator 
 seem to be down.


Kent // contributor

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Balázs Lengyel]

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  On Behalf Of Martin Björklund
Sent: 2020. április 6., hétfő 13:38
To: j.schoenwael...@jacobs-university.de
Cc: netmod@ietf.org; rwilton=40cisco@dmarc.ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

Juergen Schoenwaelder  wrote:
> On Mon, Apr 06, 2020 at 08:51:46AM +0200, Radek Krejci wrote:
> > 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).
> >
> 
> 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.)

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

> 
> 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
> 
> > Regards,
> > Radek
> > 
> > 
> > Dne 03. 04. 20 v 18:55 Juergen Schoenwaelder napsal(a):
> > > I propose option 1) and add an issue on yang-next (if not already 
> > > there yet).
> > >
> > > /js
> > >
> > > On Fri, Apr 03, 2020 at 04:24:35PM +, Rob Wilton (rwilton) wrote:
> > >> 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
> > >>  
> > >>
> > >>> -Original Message-
> > >>> From: netmod  On Behalf Of Ladislav 
> > >>> Lhotka
> > >>> Sent: 03 April 2020 15:52
> > >>> To: netmod@ietf.org
> > >>> Subject: Re: [n

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

[Martin Björklund]

Juergen Schoenwaelder  wrote:
> On Mon, Apr 06, 2020 at 08:51:46AM +0200, Radek Krejci wrote:
> > 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).
> >
> 
> 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.)

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

> 
> 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
> 
> > Regards,
> > Radek
> > 
> > 
> > Dne 03. 04. 20 v 18:55 Juergen Schoenwaelder napsal(a):
> > > I propose option 1) and add an issue on yang-next (if not already
> > > there yet).
> > >
> > > /js
> > >
> > > On Fri, Apr 03, 2020 at 04:24:35PM +, Rob Wilton (rwilton) wrote:
> > >> 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
> > >>  
> > >>
> > >>> -Original Message-
> > >>> From: netmod  On Behalf Of Ladislav Lhotka
> > >>> Sent: 03 April 2020 15:52
> > >>> To: netmod@ietf.org
> > >>> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> > >>>
> > >>> On Fri, 2020-04-03 at 14:01 +, 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,

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

[Juergen Schoenwaelder]

On Mon, Apr 06, 2020 at 08:51:46AM +0200, Radek Krejci wrote:
> 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).
>

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

> Regards,
> Radek
> 
> 
> Dne 03. 04. 20 v 18:55 Juergen Schoenwaelder napsal(a):
> > I propose option 1) and add an issue on yang-next (if not already
> > there yet).
> >
> > /js
> >
> > On Fri, Apr 03, 2020 at 04:24:35PM +, Rob Wilton (rwilton) wrote:
> >> 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
> >>  
> >>
> >>> -Original Message-
> >>> From: netmod  On Behalf Of Ladislav Lhotka
> >>> Sent: 03 April 2020 15:52
> >>> To: netmod@ietf.org
> >>> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> >>>
> >>> On Fri, 2020-04-03 at 14:01 +, 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
> >>>>
> >>>>> -Original Message-
> >>>>> From: Martin Björklund 
> >>>>> Sent: Friday, April 3, 2020 9:54 AM
> >>>>> To: Sterne, Jason (Nokia - CA/Ottawa) 
&g

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

[Radek Krejci]

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


Dne 03. 04. 20 v 18:55 Juergen Schoenwaelder napsal(a):
> I propose option 1) and add an issue on yang-next (if not already
> there yet).
>
> /js
>
> On Fri, Apr 03, 2020 at 04:24:35PM +, Rob Wilton (rwilton) wrote:
>> 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
>>  
>>
>>> -Original Message-
>>> From: netmod  On Behalf Of Ladislav Lhotka
>>> Sent: 03 April 2020 15:52
>>> To: netmod@ietf.org
>>> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
>>>
>>> On Fri, 2020-04-03 at 14:01 +, 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
>>>>
>>>>> -Original Message-
>>>>> From: Martin Björklund 
>>>>> Sent: Friday, April 3, 2020 9:54 AM
>>>>> To: Sterne, Jason (Nokia - CA/Ottawa) 
>>>>> Cc: rwilton=40cisco@dmarc.ietf.org; j.schoenwaelder@jacobs-
>>>>> university.de; mbj+i...@4668.se; war...@kumari.net; netmod@ietf.org;
>>>>> rfc- edi...@rfc-editor.org
>>>>> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
>>>>>
>>>>> Hi,
>>>>>
>>>>> "Sterne, Jason (Nokia - CA/Ottawa)"  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 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
>>>>>>
>>>>>>
>>>>>>> -O

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

[Andy Bierman]

On Fri, Apr 3, 2020 at 9:56 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

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


> /js
>
>
Andy


> On Fri, Apr 03, 2020 at 04:24:35PM +, Rob Wilton (rwilton) wrote:
> > 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
> >
> >
> > > -Original Message-
> > > From: netmod  On Behalf Of Ladislav Lhotka
> > > Sent: 03 April 2020 15:52
> > > To: netmod@ietf.org
> > > Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> > >
> > > On Fri, 2020-04-03 at 14:01 +, 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
> > > >
> > > > > -Original Message-
> > > > > From: Martin Björklund 
> > > > > Sent: Friday, April 3, 2020 9:54 AM
> > > > > To: Sterne, Jason (Nokia - CA/Ottawa) 
> > > > > Cc: rwilton=40cisco@dmarc.ietf.org; j.schoenwaelder@jacobs-
> > > > > university.de; mbj+i...@4668.se; war...@kumari.net;
> netmod@ietf.org;
> > > > > rfc- edi...@rfc-editor.org
> > > > > Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> > > > >
> > > > > Hi,
> > > > >
> > > > > "Sterne, Jason (Nokia - CA/Ottawa)" 
> 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 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
> > > >

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

[Juergen Schoenwaelder]

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

/js

On Fri, Apr 03, 2020 at 04:24:35PM +, Rob Wilton (rwilton) wrote:
> 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
>  
> 
> > -Original Message-
> > From: netmod  On Behalf Of Ladislav Lhotka
> > Sent: 03 April 2020 15:52
> > To: netmod@ietf.org
> > Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> > 
> > On Fri, 2020-04-03 at 14:01 +, 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
> > >
> > > > -Original Message-
> > > > From: Martin Björklund 
> > > > Sent: Friday, April 3, 2020 9:54 AM
> > > > To: Sterne, Jason (Nokia - CA/Ottawa) 
> > > > Cc: rwilton=40cisco@dmarc.ietf.org; j.schoenwaelder@jacobs-
> > > > university.de; mbj+i...@4668.se; war...@kumari.net; netmod@ietf.org;
> > > > rfc- edi...@rfc-editor.org
> > > > Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> > > >
> > > > Hi,
> > > >
> > > > "Sterne, Jason (Nokia - CA/Ottawa)"  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 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
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: netmod  On Behalf Of Rob Wilton
> > > > > > (rwilton)
> > > > > > Sent: Friday, April 3, 2020 8:06 AM
> > > > > > To: Juergen Schoenwaelder
> > > > > > ;
> > > > > > Martin
> > > > > > Björklund 
> > > > > > Cc: war...@kumari.net; netmod@ietf.org;
> > > > > > rfc-edi...@rfc-editor.org
> > > > > > Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> > > &

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

[Rob Wilton (rwilton)]

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
 

> -Original Message-
> From: netmod  On Behalf Of Ladislav Lhotka
> Sent: 03 April 2020 15:52
> To: netmod@ietf.org
> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> 
> On Fri, 2020-04-03 at 14:01 +, 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
> >
> > > -Original Message-
> > > From: Martin Björklund 
> > > Sent: Friday, April 3, 2020 9:54 AM
> > > To: Sterne, Jason (Nokia - CA/Ottawa) 
> > > Cc: rwilton=40cisco@dmarc.ietf.org; j.schoenwaelder@jacobs-
> > > university.de; mbj+i...@4668.se; war...@kumari.net; netmod@ietf.org;
> > > rfc- edi...@rfc-editor.org
> > > Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> > >
> > > Hi,
> > >
> > > "Sterne, Jason (Nokia - CA/Ottawa)"  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 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
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: netmod  On Behalf Of Rob Wilton
> > > > > (rwilton)
> > > > > Sent: Friday, April 3, 2020 8:06 AM
> > > > > To: Juergen Schoenwaelder
> > > > > ;
> > > > > Martin
> > > > > Björklund 
> > > > > Cc: war...@kumari.net; netmod@ietf.org;
> > > > > rfc-edi...@rfc-editor.org
> > > > > Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: netmod  On Behalf Of Juergen
> > > > > Schoenwaelder
> > > > > > Sent: 27 March 2020 16:13
> > > > > > To: Martin Björklund 
> > > > > > Cc: ibagd...@gmail.com; war...@kumari.net; netmod@ietf.org;
> > > > > > rfc- edi...@rfc-editor.org
> > > > > > Subject: Re: [netmod] [Technical Errata Reported] RFC7950
> > > > > > (6031)
> > > > > >
> > > 

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

[Ladislav Lhotka]

On Fri, 2020-04-03 at 14:01 +, 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
> 
> > -Original Message-
> > From: Martin Björklund 
> > Sent: Friday, April 3, 2020 9:54 AM
> > To: Sterne, Jason (Nokia - CA/Ottawa) 
> > Cc: rwilton=40cisco@dmarc.ietf.org; j.schoenwaelder@jacobs-
> > university.de; mbj+i...@4668.se; war...@kumari.net; netmod@ietf.org; rfc-
> > edi...@rfc-editor.org
> > Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> > 
> > Hi,
> > 
> > "Sterne, Jason (Nokia - CA/Ottawa)"  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 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
> > > 
> > > 
> > > > -Original Message-
> > > > From: netmod  On Behalf Of Rob Wilton
> > > > (rwilton)
> > > > Sent: Friday, April 3, 2020 8:06 AM
> > > > To: Juergen Schoenwaelder ;
> > > > Martin
> > > > Björklund 
> > > > Cc: war...@kumari.net; netmod@ietf.org; rfc-edi...@rfc-editor.org
> > > > Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> > > > 
> > > > 
> > > > 
> > > > > -Original Message-
> > > > > From: netmod  On Behalf Of Juergen
> > > > Schoenwaelder
> > > > > Sent: 27 March 2020 16:13
> > > > > To: Martin Björklund 
> > > > > Cc: ibagd...@gmail.com; war...@kumari.net; netmod@ietf.org; rfc-
> > > > > edi...@rfc-editor.org
> > > > > 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 
> > 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;
> > > > &g

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

[Sterne, Jason (Nokia - CA/Ottawa)]

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

> -Original Message-
> From: Martin Björklund 
> Sent: Friday, April 3, 2020 9:54 AM
> To: Sterne, Jason (Nokia - CA/Ottawa) 
> Cc: rwilton=40cisco@dmarc.ietf.org; j.schoenwaelder@jacobs-
> university.de; mbj+i...@4668.se; war...@kumari.net; netmod@ietf.org; rfc-
> edi...@rfc-editor.org
> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> 
> Hi,
> 
> "Sterne, Jason (Nokia - CA/Ottawa)"  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 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
> >
> >
> > > -Original Message-
> > > From: netmod  On Behalf Of Rob Wilton
> > > (rwilton)
> > > Sent: Friday, April 3, 2020 8:06 AM
> > > To: Juergen Schoenwaelder ;
> > > Martin
> > > Björklund 
> > > Cc: war...@kumari.net; netmod@ietf.org; rfc-edi...@rfc-editor.org
> > > Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: netmod  On Behalf Of Juergen
> > > Schoenwaelder
> > > > Sent: 27 March 2020 16:13
> > > > To: Martin Björklund 
> > > > Cc: ibagd...@gmail.com; war...@kumari.net; netmod@ietf.org; rfc-
> > > > edi...@rfc-editor.org
> > > > 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 
> 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 

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

[Martin Björklund]

Hi,

"Sterne, Jason (Nokia - CA/Ottawa)"  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 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
> 
> 
> > -Original Message-
> > From: netmod  On Behalf Of Rob Wilton
> > (rwilton)
> > Sent: Friday, April 3, 2020 8:06 AM
> > To: Juergen Schoenwaelder ;
> > Martin
> > Björklund 
> > Cc: war...@kumari.net; netmod@ietf.org; rfc-edi...@rfc-editor.org
> > Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> > 
> > 
> > 
> > > -Original Message-
> > > From: netmod  On Behalf Of Juergen
> > Schoenwaelder
> > > Sent: 27 March 2020 16:13
> > > To: Martin Björklund 
> > > Cc: ibagd...@gmail.com; war...@kumari.net; netmod@ietf.org; rfc-
> > > edi...@rfc-editor.org
> > > 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  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
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Sterne, Jason (Nokia - CA/Ottawa)]

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


> -Original Message-
> From: netmod  On Behalf Of Rob Wilton (rwilton)
> Sent: Friday, April 3, 2020 8:06 AM
> To: Juergen Schoenwaelder ; Martin
> Björklund 
> Cc: war...@kumari.net; netmod@ietf.org; rfc-edi...@rfc-editor.org
> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> 
> 
> 
> > -Original Message-
> > From: netmod  On Behalf Of Juergen
> Schoenwaelder
> > Sent: 27 March 2020 16:13
> > To: Martin Björklund 
> > Cc: ibagd...@gmail.com; war...@kumari.net; netmod@ietf.org; rfc-
> > edi...@rfc-editor.org
> > 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  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
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Rob Wilton (rwilton)]

> -Original Message-
> From: netmod  On Behalf Of Juergen Schoenwaelder
> Sent: 27 March 2020 16:13
> To: Martin Björklund 
> Cc: ibagd...@gmail.com; war...@kumari.net; netmod@ietf.org; rfc-
> edi...@rfc-editor.org
> 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  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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

On Fri, Mar 27, 2020 at 04:35:44PM +0100, Martin Björklund wrote:
> [re-sent w/ correct address]
> 
> Juergen Schoenwaelder  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?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Björklund]

[re-sent w/ correct address]

Juergen Schoenwaelder  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


> 
> /js
> 
> On Fri, Mar 27, 2020 at 03:18:12AM -0700, RFC Errata System wrote:
> > The following errata report has been submitted for RFC7950,
> > "The YANG 1.1 Data Modeling Language".
> > 
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid6031
> > 
> > --
> > Type: Technical
> > Reported by: Radek Krejci 
> > 
> > Section: 9.9.3
> > 
> > Original Text
> > -
> > The "require-instance" statement, which is a substatement to the 
> > "type" statement, MAY be present if the type is "instance-identifier"
> > or "leafref".  It takes as an argument the string "true" or "false".
> > If this statement is not present, it defaults to "true".
> > 
> > Corrected Text
> > --
> > The "require-instance" statement, which is a substatement to the
> > "type" statement, MAY be present if the type is "instance-identifier",
> > "leafref" or a type derived from them. It takes as an argument the
> > string "true" or "false". If this statement is not present, it defaults
> > to "true".
> > 
> > Notes
> > -
> > As discussed in 
> > https://mailarchive.ietf.org/arch/browse/netconf/?gbt=1=p_zRKwQ6TBxTuCDPc5wJbdZgWTc,
> >  authors expect that the require-instance statement is available not only 
> > for leafref and instance-identifier types, but also for all the types 
> > derived from them using typedef statement. Since no one argued against this 
> > understanding, this errata changes the text to the same form as in other 
> > restrictions applicable to derived types.
> > 
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party  
> > can log in to change the status and edit the report, if necessary. 
> > 
> > --
> > RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> > --
> > Title   : The YANG 1.1 Data Modeling Language
> > Publication Date: August 2016
> > Author(s)   : M. Bjorklund, Ed.
> > Category: PROPOSED STANDARD
> > Source  : Network Modeling
> > Area: Operations and Management
> > Stream  : IETF
> > Verifying Party : IESG
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

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.

/js

On Fri, Mar 27, 2020 at 03:18:12AM -0700, RFC Errata System wrote:
> The following errata report has been submitted for RFC7950,
> "The YANG 1.1 Data Modeling Language".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6031
> 
> --
> Type: Technical
> Reported by: Radek Krejci 
> 
> Section: 9.9.3
> 
> Original Text
> -
> The "require-instance" statement, which is a substatement to the 
> "type" statement, MAY be present if the type is "instance-identifier"
> or "leafref".  It takes as an argument the string "true" or "false".
> If this statement is not present, it defaults to "true".
> 
> Corrected Text
> --
> The "require-instance" statement, which is a substatement to the
> "type" statement, MAY be present if the type is "instance-identifier",
> "leafref" or a type derived from them. It takes as an argument the
> string "true" or "false". If this statement is not present, it defaults
> to "true".
> 
> Notes
> -
> As discussed in 
> https://mailarchive.ietf.org/arch/browse/netconf/?gbt=1=p_zRKwQ6TBxTuCDPc5wJbdZgWTc,
>  authors expect that the require-instance statement is available not only for 
> leafref and instance-identifier types, but also for all the types derived 
> from them using typedef statement. Since no one argued against this 
> understanding, this errata changes the text to the same form as in other 
> restrictions applicable to derived types.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> --
> Title   : The YANG 1.1 Data Modeling Language
> Publication Date: August 2016
> Author(s)   : M. Bjorklund, Ed.
> Category: PROPOSED STANDARD
> Source  : Network Modeling
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Balázs Lengyel]

+1
Balazs

-Original Message-
From: netmod  On Behalf Of RFC Errata System
Sent: 2020. március 27., péntek 11:18
To: m...@tail-f.com; ibagd...@gmail.com; war...@kumari.net; joe...@bogus.com;
kent+i...@watsen.net; lber...@labn.net
Cc: netmod@ietf.org; rfc-edi...@rfc-editor.org
Subject: [netmod] [Technical Errata Reported] RFC7950 (6031)

The following errata report has been submitted for RFC7950, "The YANG 1.1
Data Modeling Language".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6031

--
Type: Technical
Reported by: Radek Krejci 

Section: 9.9.3

Original Text
-
The "require-instance" statement, which is a substatement to the "type"
statement, MAY be present if the type is "instance-identifier"
or "leafref".  It takes as an argument the string "true" or "false".
If this statement is not present, it defaults to "true".

Corrected Text
--
The "require-instance" statement, which is a substatement to the "type"
statement, MAY be present if the type is "instance-identifier", "leafref" or
a type derived from them. It takes as an argument the string "true" or
"false". If this statement is not present, it defaults to "true".

Notes
-
As discussed in
https://mailarchive.ietf.org/arch/browse/netconf/?gbt=1=p_zRKwQ6TBxTuC
DPc5wJbdZgWTc, authors expect that the require-instance statement is
available not only for leafref and instance-identifier types, but also for
all the types derived from them using typedef statement. Since no one argued
against this understanding, this errata changes the text to the same form as
in other restrictions applicable to derived types.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please use
"Reply All" to discuss whether it should be verified or rejected. When a
decision is reached, the verifying party can log in to change the status and
edit the report, if necessary. 

--
RFC7950 (draft-ietf-netmod-rfc6020bis-14)
--
Title   : The YANG 1.1 Data Modeling Language
Publication Date: August 2016
Author(s)   : M. Bjorklund, Ed.
Category: PROPOSED STANDARD
Source  : Network Modeling
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[RFC Errata System]

The following errata report has been submitted for RFC7950,
"The YANG 1.1 Data Modeling Language".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6031

--
Type: Technical
Reported by: Radek Krejci 

Section: 9.9.3

Original Text
-
The "require-instance" statement, which is a substatement to the 
"type" statement, MAY be present if the type is "instance-identifier"
or "leafref".  It takes as an argument the string "true" or "false".
If this statement is not present, it defaults to "true".

Corrected Text
--
The "require-instance" statement, which is a substatement to the
"type" statement, MAY be present if the type is "instance-identifier",
"leafref" or a type derived from them. It takes as an argument the
string "true" or "false". If this statement is not present, it defaults
to "true".

Notes
-
As discussed in 
https://mailarchive.ietf.org/arch/browse/netconf/?gbt=1=p_zRKwQ6TBxTuCDPc5wJbdZgWTc,
 authors expect that the require-instance statement is available not only for 
leafref and instance-identifier types, but also for all the types derived from 
them using typedef statement. Since no one argued against this understanding, 
this errata changes the text to the same form as in other restrictions 
applicable to derived types.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC7950 (draft-ietf-netmod-rfc6020bis-14)
--
Title   : The YANG 1.1 Data Modeling Language
Publication Date: August 2016
Author(s)   : M. Bjorklund, Ed.
Category: PROPOSED STANDARD
Source  : Network Modeling
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod