Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> 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 +0000, 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 <netmod-boun...@ietf.org> 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 +0000, Sterne, Jason (Nokia - CA/Ottawa)
> > >>> wrote:
> > >>>> Hi Martin,
> > >>>>
> > >>>> I believe you that the technical "value space" doesn't change, but
> > >>>> that leaf would suddenly accept more values than it did before right?
> > >>>> I'm wondering if we want to follow the "spirit" here, or stick with the
> > >>> "value space" argument.
> > >>>
> > >>> I agree with Martin here. Moreover, if such a derived type is added, it
> > >>> doesn't change anything related to existing data, because they use the
> > >>> base type as before. New data nodes may use the new type but no
> > >>> confusion
> > >>> can arise - their type has "require-instance false", which is correct.
> > >>>
> > >>> Lada
> > >>>
> > >>>> I'm not really certain what the implications are (and maybe someone
> > >>>> has an example of why it is better to allow it?) but overwriting
> > >>>> require-instance with 'false' doesn't feel right.
> > >>>>
> > >>>> Jason
> > >>>>
> > >>>>> -----Original Message-----
> > >>>>> From: Martin Björklund <mbj+i...@4668.se>
> > >>>>> Sent: Friday, April 3, 2020 9:54 AM
> > >>>>> To: Sterne, Jason (Nokia - CA/Ottawa) <jason.ste...@nokia.com>
> > >>>>> 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)" <jason.ste...@nokia.com> 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 <netmod-boun...@ietf.org> On Behalf Of Rob Wilton
> > >>>>>>> (rwilton)
> > >>>>>>> Sent: Friday, April 3, 2020 8:06 AM
> > >>>>>>> To: Juergen Schoenwaelder
> > >>>>>>> <j.schoenwael...@jacobs-university.de>;
> > >>>>>>> Martin
> > >>>>>>> Björklund <mbj+i...@4668.se>
> > >>>>>>> Cc: war...@kumari.net; netmod@ietf.org;
> > >>>>>>> rfc-edi...@rfc-editor.org
> > >>>>>>> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>> -----Original Message-----
> > >>>>>>>> From: netmod <netmod-boun...@ietf.org> On Behalf Of Juergen
> > >>>>>>> Schoenwaelder
> > >>>>>>>> Sent: 27 March 2020 16:13
> > >>>>>>>> To: Martin Björklund <mbj+i...@4668.se>
> > >>>>>>>> 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>
> > >>>>> 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
> > >>> --
> > >>> Ladislav Lhotka
> > >>> Head, CZ.NIC Labs
> > >>> PGP Key ID: 0xB8F92B08A9F76C67
> > >>>
> > >>> _______________________________________________
> > >>> 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
>
>
> --
> 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
