On 2016-04-29 17:07, Ladislav Lhotka wrote: > >> On 29 Apr 2016, at 16:32, Per Hedeland <[email protected]> wrote: >> >> On 2016-04-29 16:15, Ladislav Lhotka wrote: >>> >>>> On 29 Apr 2016, at 15:51, Per Hedeland <[email protected]> wrote: >>>> >>>> On 2016-04-29 15:28, Ladislav Lhotka wrote: >>>>> >>>>>> On 29 Apr 2016, at 15:07, Juergen Schoenwaelder >>>>>> <[email protected]> wrote: >>>>>> >>>>>> On Fri, Apr 29, 2016 at 02:57:36PM +0200, Ladislav Lhotka wrote: >>>>>>> >>>>>>> Or are you saying that "type foo {}" is not the same as "type foo;"? >>>>>>> >>>>>> >>>>>> Yes, "type foo {}" has a restriction while "type foo;" does not have a >>>>>> restriction. OK, I think I see your point now that we have a case >>>>>> where there is a subtle difference between "{}" and ";" and so you >>>>>> suggest to interpret "type foo {}" as all values of foo? >>>>> >>>>> Now it becomes really interesting! :-) I wonder if there is any YANG >>>>> parser out there that is able to distinguish those two syntactic forms. I >>>>> think they must be considered identical by all means. >>>> >>>> +1. Though if I read the ABNF right, "type foo {}" is actually illegal >>>> if foo is an enum type.:-) >>> >>> I don't think so: >>> >>> type-stmt = type-keyword sep identifier-ref-arg-str optsep >>> (";" / >>> "{" stmtsep >>> [type-body-stmts] >>> "}") stmtsep >>> >>> Everything inside the braces is optional. >> >> Yes, fixed in 1.1 - but 6020 (which I "happened" to look at as I was >> flipping between the two) has: >> >> type-stmt = type-keyword sep identifier-ref-arg-str optsep >> (";" / >> "{" stmtsep >> type-body-stmts >> "}") >> >>>>> My point was that the text about restrictions of the "enumeration" type >>>>> is unclear, and IMO the more logical answer to my original question is >>>>> that the "bar" set is empty. This is most likely not the 1.0 semantics >>>>> though. >>>> >>>> No, it isn't - and I think the answer to your *original* question is >>>> quite clearly "bar is the same set as foo" in both 1 and 1.1, since 1.1 >>>> says: >>>> >>>> An enumeration can be restricted with the "enum" (Section 9.6.4) >>>> statement. >>>> >>>> If there is no "enum" statement, there is no restriction, and thus foo >>>> and bar are identical. The "if-feature removes all the enum >>>> restrictions" case is perhaps ambiguous with an "extremely literal" >>>> interpretation of "if-feature", but to me (just having implemented >>>> if-feature for enums/bits in our compiler) it is obvious that this case >>>> too is a restriction and not an identity - the if-feature only modifies >>>> the specifics of the restriction. >>> >>> Yes, this makes sense, too, but needs to be explained. >> >> I think some text would be appreciated if you think it is needed. > > OLD > When an existing enumeration type is restricted, the set of assigned > names in the new type MUST be a subset of the base type's set of > assigned names. The value of such an assigned name MUST NOT be > changed. > > NEW > When an existing enumeration type is restricted by means of one or more > "enum" statements (even if any or all of them are disabled through an > "if-feature" statement), the set of assigned names in the new type MUST > be a subset of the base type's set of assigned names. The value of such > an assigned name MUST NOT be changed. > > If a new type is derived from an existing enumeration type and no "enum" > restrictions are specified, then the sets of permitted values are the same > for both types. > > And the same for bits type, mutatis mutandis.
Agree with the first paragraph, but I do think the second is superfluous - it just says "if there is no restriction statement, the type isn't restricted". This is true for all types. --Per > Lada > >> >>> In a way, solution Y10-02 would have been more straightforward. >> >> Please don't do that. >> >> --Per >> >>> Lada >>> >>>> >>>> But adding some text that clarifies this can't hurt I guess (just like >>>> the text that points out that the outcome of if-feature evaluation does >>>> not affect the value assignment). >>>> >>>> --Per >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
