Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
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 > > > > > > > > > > > > > > > > > > > -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 < > j.schoenwael...@jacobs-university.de> > > > >
[netmod] Murray Kucherawy's No Objection on draft-ietf-netmod-factory-default-14: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-netmod-factory-default-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-factory-default/ -- COMMENT: -- Section 2: * "All security sensitive data (i.e., private keys, passwords, etc.) SHOULD be overwritten ..." presents a choice. Why would an implementer not do this? * "Implementors SHOULD reboot the device or otherwise restart processes needed to bootstrap it." leads me to the same question. Nits: * "Upon receiving the RPC" is followed by a list, so please add a colon * "datastores(e.g.," -- add a space after "datastores" Section 3: Nits: * "The contents of is defined ..." -- s/is/are/ Section 5: * "This document registers one URI in the IETF XML Registry [RFC3688]. ..." should say explicitly that it's the "ns" sub-registry receiving a new entry. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
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) > > > > > > > > > > > > > > > > > > > > > > > > > -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
Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
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)
> > > > > >
> > > > > > 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
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)
> > > > >
> > > > > 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
Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
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 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
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 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
Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
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
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
Re: [netmod] versioning procedures (RFC vs. I-D)
[As an individual contributor]
> -Original Message-
> From: netmod On Behalf Of Martin Björklund
> Sent: 02 April 2020 17:52
> To: a...@yumaworks.com
> Cc: netmod@ietf.org; italo.b...@huawei.com
> Subject: Re: [netmod] versioning procedures (RFC vs. I-D)
>
> Andy Bierman wrote:
> > Hi,
> >
>
> I think it quite clear that such a label should not be used in I-Ds.
[RW]
Currently, it takes IETF a long time to publish YANG modules. If IETF decides
to use Semver labels for YANG modules then I think that giving a pre-release
version label to work in progress is helpful for folks who choose to implement
pre-release versions of those modules while they wait for the formal versions
to be standardized.
Regards,
Rob
>
>
> /martin
>
>
> >
> > bis-draft-02: 1.0.0+3
> >
> > [repeat NBC step bis-draft-02 10 times] 1.0.0+4 .. 1.0.0+13
> >
> > RFC-2: 2.0.0 (in general: 1.0.1 or 1.1.0 or 2.0.0)
> >
> > The BC vs. NBC distinction is not relevant for a work-in-progress.
> > We have seen many times in this WG where a NBC change was made and
> > then later undone. There is no value in tracking the module during
> > development.
> >
> >
> > Andy
> >
> >
> > On Thu, Apr 2, 2020 at 7:46 AM Reshad Rahman (rrahman)
> >
> > wrote:
> >
> > >
> > >
> > >
> > >
> > > *From: *'Andy Bierman'
> > > *Date: *Thursday, April 2, 2020 at 10:26 AM
> > > *To: *"Reshad Rahman (rrahman)"
> > > *Cc: *Italo Busi , "Joe Clarke (jclarke)" <
> > > jcla...@cisco.com>, NetMod WG
> > > *Subject: *Re: [netmod] versioning procedures (RFC vs. I-D)
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Apr 2, 2020 at 4:11 AM Reshad Rahman (rrahman)
> > >
> > > wrote:
> > >
> > > Hi,
> > >
> > >
> > >
> > > *From: *Italo Busi
> > > *Date: *Thursday, April 2, 2020 at 5:06 AM
> > > *To: *"Reshad Rahman (rrahman)" , 'Andy Bierman'
> > > < a...@yumaworks.com>, "Joe Clarke (jclarke)"
> > > *Cc: *NetMod WG
> > > *Subject: *RE: [netmod] versioning procedures (RFC vs. I-D)
> > >
> > >
> > >
> > > Reshad,
> > >
> > >
> > >
> > > My doubt and, if I understand well also Andy’s question, is about
> > > the fact that before publishing an RFC-bis with e.g., 1.1.0, we will
> > > have a set of Internet-Drafts updating the RFC with 1.0.0
> > >
> > >
> > >
> > > What versions should be used in the YANG modules published in these
> > > Internet-Drafts?
> > >
> > >
> > >
> > > Think about the following scenario: -00 version provide BC changes
> > > to the RFC module but the -01 version provide NBC changes to what
> > > has been added in the -00 module (thus the -01 version is BC with
> > > the RFC 1.0.0 module but NBC with the -00 version module)
> > >
> > > So bis 00 would be 1.1.0 (BC with RFC module).
> > >
> > > Bis 01 should be updated according to its relationship to the RFC
> > > module (bis 00 doesn’t matter anymore), when RFC bis is published it
> > > won’t have the full history.
> > >
> > >
> > >
> > > Hope I correctly understood your question.
> > >
> > >
> > >
> > >
> > >
> > > This semver plan is not very intuitive and not sure it works.
> > >
> > >
> > >
> > > draft-00
> > >
> > >
> > >
> > >container the-container; version 0.1.0 OK
> > >
> > >
> > >
> > > draft-01:
> > >
> > >container my-container; version 0.2.0; rules
> violated;
> > > NBC should force 1.0.0
> > >
> > >
> > >
> > > draft-02:
> > >
> > >
> > >
> > > container my-container { version 0.3.0; should be 1.1.0
> > >
> > > leaf my-leaf { type int32; }
> > >
> > > }
> > >
> > >
> > >
> > > RFC-1:
> > >
> > >
> > >
> > > container my-container { version 1.0.0; should be 2.0.0
> > > according to NBC rules
> > >
> > > leaf my-leaf { type uint32; }
> > >
> > > }
> > >
> > >
> > >
> > > bis-draft-00:
> > >
> > >
> > >
> > >container my-container { version 1.1.0; OK
> > >
> > > leaf my-leaf { type uint32; }
> > >
> > > leaf another-leaf { type int32; }
> > >
> > > }
> > >
> > >
> > >
> > > bis-draft-01:
> > >
> > >
> > >
> > > container my-container { diff against RFC-1:
> version
> > > 1.1.0 but already used; use 1.2.0?
> > >
> > > leaf my-leaf { type uint32; }
> > >
> > > leaf another-leaf { type uint32; }
> > >
> > > }
> > >
> > >
> > >
> > > bis-draft-02:
> > >
> > >
> > >
> > > container example-my-container { diff against RFC-
> 1:
> > > version 2.0.0 but use 1.3.0 instead?
> > >
> > > leaf my-leaf { type uint32; }
> > >
> > > leaf another-leaf { type uint32; }
> > >
> > > }
> > >
> > >
> > >
> > > [repeat NBC step bis-draft-02 10 times now up to version 12.0.0
> > > or is it 1.13.0? something else?
> > >
> > >
> > >
> > > RFC-2: publish draft-12 as RFC-2: now change the label from 1.13.0
> to
> > > 2.0.0? or leave it 12.0.0?
> > >
> > >
> > >
> > > IMO it is very confusing that the stated rules are so inconsistent
> > > and are violated so many ways.
> >
Re: [netmod] versioning procedures (RFC vs. I-D)
[As a contributor]
Although, I can see how increasing the number from the starting version makes
more logical sense, I think that it is better to conform to the semver rules.
Hence, I would suggest that the process to update the version string could look
something like this:
Starting with RFC 6991 version 1.0.0.
Bis version with backwards compatible change: “1.1.0-6991bis-01”
If the next bis version has NBC changes, then it would be : “2.0.0-6991bis-02”
Then the WG decide that an NBC change isn’t required, so the next draft version
is: : “1.1.0-6991bis-03”
Once it gets to new RFC, then the version becomes “1.1.0”.
I think that this conforms to the Semver 2.0.0 rules, specifically paragraph 9
at https://semver.org/
Regards,
Rob
From: netmod On Behalf Of Andy Bierman
Sent: 02 April 2020 19:22
To: Martin Björklund
Cc: NetMod WG ; Italo Busi
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)
On Thu, Apr 2, 2020 at 9:51 AM Martin Björklund
mailto:mbj%2bi...@4668.se>> wrote:
Andy Bierman mailto:a...@yumaworks.com>> wrote:
> Hi,
>
> I agree that a revision-label could be useful in an I-D but not to indicate
> NBC changes (because it doesn't).
> The rules need to be clear and simple with no exceptions.
>
> 1) Special version 0.x.y contains NO NBC information
> Major version = 0 means the module has no published version
>
> 2) First published version is 1.0.0
>
> 3) The revision-label in an unpublished module has a special form which
> simply identifies
> the source of the development and the iteration of the
> work-in-progress.
> You can't really pick the next published label until the module is
> ready.
>
> >From my example:
>
> draft-00: 0.1.0
>
> draft-01: 0.2.0
>
> draft-02: 0.3.0
>
> RFC-1:1.0.0
>
> bis-draft-00: 1.0.0+1
If this was normal semver, it would be:
bis-draft-00: 2.0.0-1
bis-draft-01: 2.0.0-2
etc. ("+" and "-" have special meaning in semver)..
One problem though is that when the -bis work starts, it might not be
clear if the end result (published RFC) will be NBC or BC. And this
might change back and forth during development of the I-D.
What happens if there are multiple release trains in progress?
Seems more useful to base the label on the known starting point
instead of the possible ending point.
I think it quite clear that such a label should not be used in I-Ds.
Agreed
/martin
Andy
>
> bis-draft-02: 1.0.0+3
>
> [repeat NBC step bis-draft-02 10 times] 1.0.0+4 .. 1.0.0+13
>
> RFC-2: 2.0.0 (in general: 1.0.1 or 1.1.0 or 2.0.0)
>
> The BC vs. NBC distinction is not relevant for a work-in-progress.
> We have seen many times in this WG where a NBC change was made
> and then later undone. There is no value in tracking the module during
> development.
>
>
> Andy
>
>
> On Thu, Apr 2, 2020 at 7:46 AM Reshad Rahman (rrahman)
> mailto:rrah...@cisco.com>>
> wrote:
>
> >
> >
> >
> >
> > *From: *'Andy Bierman' mailto:a...@yumaworks.com>>
> > *Date: *Thursday, April 2, 2020 at 10:26 AM
> > *To: *"Reshad Rahman (rrahman)"
> > mailto:rrah...@cisco.com>>
> > *Cc: *Italo Busi mailto:italo.b...@huawei.com>>,
> > "Joe Clarke (jclarke)" <
> > jcla...@cisco.com>, NetMod WG
> > mailto:netmod@ietf.org>>
> > *Subject: *Re: [netmod] versioning procedures (RFC vs. I-D)
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Apr 2, 2020 at 4:11 AM Reshad Rahman (rrahman)
> > mailto:rrah...@cisco.com>>
> > wrote:
> >
> > Hi,
> >
> >
> >
> > *From: *Italo Busi mailto:italo.b...@huawei.com>>
> > *Date: *Thursday, April 2, 2020 at 5:06 AM
> > *To: *"Reshad Rahman (rrahman)"
> > mailto:rrah...@cisco.com>>, 'Andy Bierman' <
> > a...@yumaworks.com>, "Joe Clarke (jclarke)"
> > mailto:jcla...@cisco.com>>
> > *Cc: *NetMod WG mailto:netmod@ietf.org>>
> > *Subject: *RE: [netmod] versioning procedures (RFC vs. I-D)
> >
> >
> >
> > Reshad,
> >
> >
> >
> > My doubt and, if I understand well also Andy’s question, is about the fact
> > that before publishing an RFC-bis with e.g., 1.1.0, we will have a set of
> > Internet-Drafts updating the RFC with 1.0.0
> >
> >
> >
> > What versions should be used in the YANG modules published in these
> > Internet-Drafts?
> >
> >
> >
> > Think about the following scenario: -00 version provide BC changes to the
> > RFC module but the -01 version provide NBC changes to what has been added
> > in the -00 module (thus the -01 version is BC with the RFC 1.0.0 module but
> > NBC with the -00 version module)
> >
> > So bis 00 would be 1.1.0 (BC with RFC module).
> >
> > Bis 01 should be updated according to its relationship to the RFC module
> > (bis 00 doesn’t matter anymore), when RFC bis is published it won’t have
> > the full history.
> >
> >
> >
> > Hope I correctly understood your question.
> >
> >
> >
> >
> >
> > This semver plan is not very intuitive and not sure it works.
> >
> >
> >
> > draft-00
> >
> >
> >
> >container the-container; version 0.1.0
[netmod] [Errata Verified] RFC7950 (6078)
The following errata report has been verified for RFC7950,
"The YANG 1.1 Data Modeling Language".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6078
--
Status: Verified
Type: Technical
Reported by: Michal Vasko
Date Reported: 2020-04-03
Verified by: Rob Wilton (IESG)
Section: 6.4.
Original Text
-
For example, consider the following definition:
leaf lxiv {
type decimal64 {
fraction-digits 18;
}
must ". <= 10";
}
An instance of the "lxiv" leaf having the value of
10.0001 will then successfully pass validation.
Corrected Text
--
For example, consider the following definition:
leaf lxiv {
type decimal64 {
fraction-digits 18;
}
must ". <= 9";
}
An instance of the "lxiv" leaf having the value of
9.0001 will then successfully pass validation.
Notes
-
Value 10.0001 is not a valid decimal64 value with 18 fraction
digits as per Section 9.3.4.
--
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
Re: [netmod] [Technical Errata Reported] RFC7950 (6078)
Martin,
Thanks for confirming.
Regards,
Rob
> -Original Message-
> From: Martin Björklund
> Sent: 03 April 2020 11:42
> To: rfc-edi...@rfc-editor.org
> Cc: war...@kumari.net; Rob Wilton (rwilton) ;
> joe...@bogus.com; kent+i...@watsen.net; lber...@labn.net; netmod@ietf.org
> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6078)
>
> Hi,
>
> This errata is correct and should be accepted.
>
>
> /martin
>
>
> 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/eid6078
> >
> > --
> > Type: Technical
> > Reported by: Michal Vasko
> >
> > Section: 6.4.
> >
> > Original Text
> > -
> >For example, consider the following definition:
> >
> > leaf lxiv {
> >type decimal64 {
> > fraction-digits 18;
> >}
> >must ". <= 10";
> > }
> >
> >An instance of the "lxiv" leaf having the value of
> >10.0001 will then successfully pass validation.
> >
> > Corrected Text
> > --
> >For example, consider the following definition:
> >
> > leaf lxiv {
> >type decimal64 {
> > fraction-digits 18;
> >}
> >must ". <= 9";
> > }
> >
> >An instance of the "lxiv" leaf having the value of
> >9.0001 will then successfully pass validation.
> >
> > Notes
> > -
> > Value 10.0001 is not a valid decimal64 value with 18
> fraction digits as per Section 9.3.4.
> >
> > 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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [Technical Errata Reported] RFC7950 (6078)
Hi,
This errata is correct and should be accepted.
/martin
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/eid6078
>
> --
> Type: Technical
> Reported by: Michal Vasko
>
> Section: 6.4.
>
> Original Text
> -
>For example, consider the following definition:
>
> leaf lxiv {
>type decimal64 {
> fraction-digits 18;
>}
>must ". <= 10";
> }
>
>An instance of the "lxiv" leaf having the value of
>10.0001 will then successfully pass validation.
>
> Corrected Text
> --
>For example, consider the following definition:
>
> leaf lxiv {
>type decimal64 {
> fraction-digits 18;
>}
>must ". <= 9";
> }
>
>An instance of the "lxiv" leaf having the value of
>9.0001 will then successfully pass validation.
>
> Notes
> -
> Value 10.0001 is not a valid decimal64 value with 18 fraction
> digits as per Section 9.3.4.
>
> 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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
[netmod] [Technical Errata Reported] RFC7950 (6078)
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/eid6078
--
Type: Technical
Reported by: Michal Vasko
Section: 6.4.
Original Text
-
For example, consider the following definition:
leaf lxiv {
type decimal64 {
fraction-digits 18;
}
must ". <= 10";
}
An instance of the "lxiv" leaf having the value of
10.0001 will then successfully pass validation.
Corrected Text
--
For example, consider the following definition:
leaf lxiv {
type decimal64 {
fraction-digits 18;
}
must ". <= 9";
}
An instance of the "lxiv" leaf having the value of
9.0001 will then successfully pass validation.
Notes
-
Value 10.0001 is not a valid decimal64 value with 18 fraction
digits as per Section 9.3.4.
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
