> On 29 Apr 2016, at 14:41, Juergen Schoenwaelder > <j.schoenwael...@jacobs-university.de> wrote: > > On Fri, Apr 29, 2016 at 02:36:55PM +0200, Ladislav Lhotka wrote: >> >>> On 29 Apr 2016, at 14:30, Juergen Schoenwaelder >>> <j.schoenwael...@jacobs-university.de> wrote: >>> >>> On Fri, Apr 29, 2016 at 02:19:08PM +0200, Ladislav Lhotka wrote: >>>> >>>> The problem here is that enum statements aren't really restrictions but >>>> rather specify the new set of values. It would be kind of discontinuos: >>>> with >>>> >>>> typedef bar { >>>> type foo { >>>> enum one; >>>> enum two; >>>> } >>>> } >>>> >>>> the "bar" set would be {one, two}. If I remove the "enum two;" statement, >>>> the set would be just {one}, but then if I remove the "enum one;" >>>> statement, the set would again become {one, two}. >>>> >>> >>> So what? Apparently, being able to use foo without having to repeat >>> all values of foo is the main reason to define foo in the first place. >> >> So what about this: >> >> typedef bar { >> type foo { >> enum one { >> if-feature fancy; >> } >> } >> } >> >> If "fancy" feature is supported then the "bar" set is {one}. But if it isn't >> supported, then what? >> > > If the "fancy" feature is not set, the value set of "bar" is {} (since > there is a restriction reducing the value set to an empty set).
I think you have no support for this conclusion in 6020bis text, it depends on what "conditional" means. One defensible interpretation is that type foo { enum one { if-feature fancy; } } is equivalent to type foo { } if feature "fancy" isn't supported. Or are you saying that "type foo {}" is not the same as "type foo;"? Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod