> On Jun 19, 2018, at 9:20 AM, Carsten Bormann <[email protected]> wrote: > > Hi Michael, > > 2.2.2 says: > > It is not an error if a name is first used with a "/=" or "//=" > (there is no need to “create it" with "=“).
We must have absorbed this sentence w/o noticing it. > > The intention is indeed to say that no initial rule with a “=“ is needed. > Any ideas how we can clarify this some more? I would help if the use of /= or //= is clarified to be a message to implementors that future values should be expected and handled appropriately. As it reads, in concert with the first sentence of the next section (“Instead of naming all the values that make up a choice”), I find myself unsure as to the need for a sentence such as we’ve provided. Do we need to inform implementors that future values MAY be seen? What if we intended that future values MUST NOT be included? Its reasonable for CDDL to declare that out-of-scope; in which case the current language looks sufficient but it would mean use of CDDL in this area will often have an additional sentence to clarify for implementors. - max > > You could also make use of the convention (not currently checked by any tool, > but that could be done) to mark an extension point with a dollar sign: > > $transport-proto /= IPPROTO_TCP > > (See section 3.9 for more about that convention.) > > Grüße, Carsten > > >> On Jun 19, 2018, at 17:08, Michael Richardson <[email protected]> wrote: >> >> Signed PGP part >> >> In draft-ietf-anima-bootstrapping-keyinfra-15, we specify a protocol value >> for GRASP. In this normative part of the document, there is only one choice, >> but it is our intention to allow additional choices, as per section 2.2.2 >> of cddl-02. >> >> We think that we should specify our single "choice", using /=, rather than =, >> as this should clue the reader in to expect multiple values here. >> >> From our document: >> >> transport-proto /= IPPROTO_TCP ; note this is an extensible CDDL choice >> ; and can be added to in subsequent >> ; specifications using the /= and //= >> >> It is unclear in section 2.2.2 if we can say foo /= without having said >> foo = 1 / 2 / 3 >> previously, but it seems like it should be reasonable to do in order to >> indicate that implementations should expect future values. >> >> -- >> Michael Richardson <[email protected]>, Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> >> > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
