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 +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 <[email protected]> On Behalf Of Ladislav Lhotka >>> Sent: 03 April 2020 15:52 >>> To: [email protected] >>> 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 <[email protected]> >>>>> Sent: Friday, April 3, 2020 9:54 AM >>>>> To: Sterne, Jason (Nokia - CA/Ottawa) <[email protected]> >>>>> Cc: [email protected]; j.schoenwaelder@jacobs- >>>>> university.de; [email protected]; [email protected]; [email protected]; >>>>> rfc- [email protected] >>>>> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031) >>>>> >>>>> Hi, >>>>> >>>>> "Sterne, Jason (Nokia - CA/Ottawa)" <[email protected]> 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 <[email protected]> On Behalf Of Rob Wilton >>>>>>> (rwilton) >>>>>>> Sent: Friday, April 3, 2020 8:06 AM >>>>>>> To: Juergen Schoenwaelder >>>>>>> <[email protected]>; >>>>>>> Martin >>>>>>> Björklund <[email protected]> >>>>>>> Cc: [email protected]; [email protected]; >>>>>>> [email protected] >>>>>>> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031) >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: netmod <[email protected]> On Behalf Of Juergen >>>>>>> Schoenwaelder >>>>>>>> Sent: 27 March 2020 16:13 >>>>>>>> To: Martin Björklund <[email protected]> >>>>>>>> Cc: [email protected]; [email protected]; [email protected]; >>>>>>>> rfc- [email protected] >>>>>>>> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 >>>>>>>> (6031) >>>>>>>> >>>>>>>> On Fri, Mar 27, 2020 at 04:35:44PM +0100, Martin Björklund >>> wrote: >>>>>>>>> [re-sent w/ correct address] >>>>>>>>> >>>>>>>>> Juergen Schoenwaelder <[email protected]> >>>>> wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> two comments: >>>>>>>>>> >>>>>>>>>> - It is unclear to me whether this really qualifies as an >>> errata. >>>>>>>>>> - If we add this, then there should probably text about >>> which >>>>>>>>>> combinations are allowed. For example, for pattern and >>>>>>>>>> ranges, >>>>> there >>>>>>>>>> is explicit text that says further restrictions of the >>>>>>>>>> value space >>>>>>>>>> are possible, bot not expansions. If we follow that >>>>>>>>>> logic, then >>>>>>>>>> >>>>>>>>>> typedef a { >>>>>>>>>> type leaf-ref { >>>>>>>>>> path "/some/thing"; >>>>>>>>>> require-instance true; >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> typedef b { >>>>>>>>>> type a { >>>>>>>>>> require-instance false; >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> might be illegal since b has a larger value space than a. >>>>>>>>> The value space of b is the same as for a. "require-instance" >>>>>>>>> doesn't >>>>>>>>> change the value space; it changes semantic validation of >>>>>>>>> the given values ((see my mail from 17 Mar, "Require-instance >>> problem"). >>>>>>>>> /martin >>>>>>>> OK. If we consider require-instance a constraint and not a >>>>>>>> restriction, then the motivation for this errata is at least >>>>>>>> confusing: >>>>>>>> >>>>>>>> Since no one argued against this understanding, this errata >>> changes >>>>>>>> the text to the same form as in other restrictions applicable >>> to >>>>>>>> derived types. >>>>>>>> >>>>>>>> Simply put: Do you think it is OK to overwrite a >>>>>>>> require-instance true with a require-instance false in a derived >>> type? >>>>>>> [RW] >>>>>>> I'm not sure, but going in the other direction seems plausible. >>>>>>> >>>>>>> E.g. you start with a typedef that is explicitly >>>>>>> require-instance false that is then refined by a typedef to be >>>>>>> require-instance true. >>>>>>> >>>>>>> Regards, >>>>>>> Rob >>>>>>> >>>>>>> >>>>>>>> /js >>>>>>>> >>>>>>>> -- >>>>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >>> Germany >>>>>>>> Fax: +49 421 200 3103 <https://www.jacobs- >>> university.de/> >>>>>>>> _______________________________________________ >>>>>>>> netmod mailing list >>>>>>>> [email protected] >>>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>>> _______________________________________________ >>>>>>> netmod mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> _______________________________________________ >>>> netmod mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/netmod >>> -- >>> Ladislav Lhotka >>> Head, CZ.NIC Labs >>> PGP Key ID: 0xB8F92B08A9F76C67 >>> >>> _______________________________________________ >>> netmod mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod
smime.p7s
Description: Elektronicky podpis S/MIME
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
