Subject: [Cbor] CDDL-02 section 2.2.2 choices

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Jun 2018 11:08:21 -0400

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-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 19 Jun 2018 17:20:34 +0200

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 "=").

The intention is indeed to say that no initial rule with a “=“ is needed.
Any ideas how we can clarify this some more?

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-masked]> wrote:
> 
> Signed PGP part
>

---

From: Jim Schaad <[email-masked]>
Date: Tue, 19 Jun 2018 08:21:08 -0700

Look at the last paragraph in section 2.2.2

It is not an error if a name is first used with a "/=" or "//=" (there is no
need to "create it" with "=").

Jim

> -----Original Message-----
> From: CBOR <[email-masked]> On Behalf Of Michael Richardson
> Sent: Tuesday, June 19, 2018 8:08 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Cbor] CDDL-02 section 2.2.2 choices
> 
> 
of cddl-
> 02.
indicate
> that implementations should expect future values.
> 
> --

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 19 Jun 2018 17:15:34 +0000

> On Jun 19, 2018, at 9:20 AM, Carsten Bormann <[email-masked]> wrote:
> 
> Hi Michael,
> 
> 2.2.2 says:
> 
>   (there is no need to “create it" with "=“).

We must have absorbed this sentence w/o noticing it. 

> 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

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Jun 2018 13:53:45 -0400

> Any ideas how we can clarify this some more?

Neither Max nor I saw this while we were perusing this part.
May I suggest that it be moved to be the second paragraph?

    > 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:

    > (See section 3.9 for more about that convention.)

Ah, interesting. thank you.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Jun 2018 08:45:56 +1200

> Ah, interesting. thank you.

However: I suggest not using that in the BRSKI draft. Our emergency plan
if CDDL is not yet close to being an RFC is to add a normative appendix
to GRASP specifying the subset of CDDL that we use, and I'd like to
keep that subset as small as possible.

Even better, CBOR could wrap up the CDDL spec in Montreal.

Regards
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Jun 2018 19:48:26 -0400

> Even better, CBOR could wrap up the CDDL spec in Montreal.

I don't believe that BRSKI will enter the RFC-EDITOR queue before CDDL.
If it does, we could fix stuff as you suggest.