Subject: [Cbor] Should CDDL have an IANA registry for control operators? (#17)

From: Carsten Bormann <[email-masked]>
Date: Thu, 12 Jul 2018 09:06:35 +0200

To provide extensibility, CDDL provides one major extension point: control operators.

However, the current text does not define how to actually add a control operator.

One approach is that this extension point is there just for evolution of the language, so any new control operators would be defined  by a CDDL 1.1 or 2.0 document.  In this case, there is no need for additional text.

One other approach is to open up that extension point for third-party specifications.  If we do this, we should be providing an IANA registry, and need to define the registration policy (RFC 8126).  Theoretically, this could be done in a separate document, but the more usual way to do this is to create the registry in the document to which it applies.

If we create such a registry, what should be the registration policy?  How easy should it be to create a control operator (and claim a name for it)?  Section 4  of RFC 8126 proposes a number of potential policies.  Specification Required (which is supported by a designated expert who decides whether there *is* a specification) seems to be the minimum requirement we should impose.  On the other end of the spectrum, Standards Action means that that specification must be an approved IETF standards track (or BCP) RFC, which is not that much different from not having a registry at all.  If we go for RFC Required, the RFC could be Experimental or Informational, too.  Finally, Expert Review is the most flexible policy, but then we should include text that guides the designated expert to make a decision.

To properly decide which of these approaches is right, we need a crystal ball.  Creating too much latitude can fragment the language and create uncertainty whether a specification making use of a questionable extension actually can be used.  Creating too much rigidity may be bad for the evolution of the language and for its ability to address evolving requirements.

I’m currently leaning towards creating a registry and giving it Expert Review policy, guiding the Designated Expert to accept registrations where a specification is publicly available (Specification Required) and has received some community review, the result of which indicates that there is a good chance that independent implementations would achieve consistent semantics.

That places a pretty big onus on the Designated Expert, whom we’d need to find once the CDDL RFC is approved.  It is also more consensus oriented than a simple Specification Required but has less process than an IETF Review or Standards Action (both of which involve the IESG, which is a scarce resource).   It does give the Designated Expert a lot of leeway to evolve the details of the handling of requests, which may be a good or a bad thing (in the latter case, the IESG can always replace the designated expert, but this is a relatively heavyweight procedure).

What do you think?

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Thu, 12 Jul 2018 05:56:32 -0700

I would have a strong preference that this would be done via versioning of the language.  It makes it much easier to say that I have a CDDL version X item checker rather than trying to say I have a CDDL checker that support the following set of extensions.

Jim

> -----Original Message-----
> From: CBOR <[email-masked]> On Behalf Of Carsten Bormann
> Sent: Thursday, July 12, 2018 12:07 AM
> To: [email-masked]
> Subject: [Cbor] Should CDDL have an IANA registry for control operators?
> (#17)
> 
> One approach is that this extension point is there just for evolution of the
> language, so any new control operators would be defined  by a CDDL 1.1 or
> 2.0 document.  In this case, there is no need for additional text.
> 
> One other approach is to open up that extension point for third-party
> specifications.  If we do this, we should be providing an IANA registry, and
> need to define the registration policy (RFC 8126).  Theoretically, this could be
> done in a separate document, but the more usual way to do this is to create
> the registry in the document to which it applies.
> 
> If we create such a registry, what should be the registration policy?  How
> easy should it be to create a control operator (and claim a name for it)?
> Section 4  of RFC 8126 proposes a number of potential policies.  Specification
> Required (which is supported by a designated expert who decides whether
> there *is* a specification) seems to be the minimum requirement we should
> impose.  On the other end of the spectrum, Standards Action means that
> that specification must be an approved IETF standards track (or BCP) RFC,
> which is not that much different from not having a registry at all.  If we go for
> RFC Required, the RFC could be Experimental or Informational, too.  Finally,
> Expert Review is the most flexible policy, but then we should include text
> that guides the designated expert to make a decision.
> 
> To properly decide which of these approaches is right, we need a crystal ball.
> Creating too much latitude can fragment the language and create uncertainty
> whether a specification making use of a questionable extension actually can
> be used.  Creating too much rigidity may be bad for the evolution of the
> language and for its ability to address evolving requirements.
> 
> I’m currently leaning towards creating a registry and giving it Expert Review
> policy, guiding the Designated Expert to accept registrations where a
> specification is publicly available (Specification Required) and has received
> some community review, the result of which indicates that there is a good
> chance that independent implementations would achieve consistent
> semantics.
> 
> That places a pretty big onus on the Designated Expert, whom we’d need to
> find once the CDDL RFC is approved.  It is also more consensus oriented than
> a simple Specification Required but has less process than an IETF Review or
> Standards Action (both of which involve the IESG, which is a scarce resource).
> It does give the Designated Expert a lot of leeway to evolve the details of the
> handling of requests, which may be a good or a bad thing (in the latter case,
> the IESG can always replace the designated expert, but this is a relatively
> heavyweight procedure).
> 
> What do you think?
> 
> Grüße, Carsten
> 
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor

---

From: Michael Breuer <[email-masked]>
Date: Mon, 16 Jul 2018 20:47:49 +0200

+1

Having versioning of the language rather than fragmentation by the use
of extensions sounds much better to me. At least in this early stage of
the CDDL language.

Michael

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 16 Jul 2018 15:06:43 -0400

Hi Jim, Michael,

there are some assumptions in these answers that I’m not sure everybody shares.

First, the assumption seems to be that all control operations will be generally useful.
For the ones defined in the current WG draft, that has of course been the intention.  But we already have some requests from SDOs that have their own binary data formats and want to ship these around in CBOR — they’d need some very specific controls that can specify the shape of the contents of those byte strings.  These would not realistically become a part of the common version of CDDL.

More generally, the development model assumed here can be described as the Cathedral side in the “Cathedral vs. Bazaar” analogy: https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
So far CDDL indeed has been developed in Cathedral style — with good input from its users, but centrally managed.  But control operators provide a way to open this up in an, er, controlled way, so we don’t have to be stuck in a cathedral, but can have the best of both worlds: a reasonably controlled development model for the language itself, and a much more open model for the control operators.

We can always bundle up control operators we like in future versions of the language, so wanting “CDDL 2.0” as a shortcut for a number of control operators is not an argument against a more open handling of developing them.

If development of CDDL continues in the IETF, we can of course develop our own, generally applicable, well-honed control operators as well.  We are just sharing a registry with the general public (which would likely not be zero-threshold, anyway).  We can also import nice additions from outside into future versions of the CDDL language specification.  (This all stays theoretical until other organizations do some development, too, but as I said that is not unlikely.)

One approach to encourage bringing control operator extensions to the IETF would be to give external ones a separate namespace.  But this creates the “X-Dash” problem (RFC 6648) all over again: Once we pull some of them in, we would want to change their names; more likely, people would still  continue to use the old names to be compatible with the largest number of tools.  So we probably shouldn’t do that.

Grüße, Carsten

> On Jul 16, 2018, at 14:47, Michael Breuer <[email-masked]> wrote:
> 
> Signed PGP part
> +1
>

---

From: Michael Breuer <[email-masked]>
Date: Mon, 16 Jul 2018 23:00:55 +0200

Hej Carsten,

thanks for the detailed explanation. Not being that much into those other
SDOs was the missing information. Considering this, creating a new iana registry with expert review makes sense to me.

Grüße,
Michael

---

From: Jim Schaad <[email-masked]>
Date: Tue, 17 Jul 2018 11:30:11 -0400

> Sent: Monday, July 16, 2018 3:07 PM
> To: Michael Breuer <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Cbor] Should CDDL have an IANA registry for control operators?
> (#17)
> 
> Hi Jim, Michael,
> 

There is another assumption here that is not documented.  Is there going to be a push to do a CDDL 2.0 in a timely manner or is this the final version of the specification.  My answer would actually be different if there are no plans to ever do an update.

> For the ones defined in the current WG draft, that has of course been the
> intention.  But we already have some requests from SDOs that have their own
> binary data formats and want to ship these around in CBOR — they’d need
> some very specific controls that can specify the shape of the contents of those
> byte strings.  These would not realistically become a part of the common
> version of CDDL.

Either they are all going to be generally useful, or they are going to be so esoteric that not only do I not want them I don't even want to know about them.  This would be similar to all of the __foo type options that show up in C compilers that I don't use and therefore have never cared about.  I would expect that there would be some pressure to implement things in the registry even if they are esoteric.

> 
> More generally, the development model assumed here can be described as the
> Cathedral side in the “Cathedral vs. Bazaar” analogy:
> https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
> So far CDDL indeed has been developed in Cathedral style — with good input
> from its users, but centrally managed.  But control operators provide a way to
> open this up in an, er, controlled way, so we don’t have to be stuck in a
> cathedral, but can have the best of both worlds: a reasonably controlled
> development model for the language itself, and a much more open model for
> the control operators.
> 
> We can always bundle up control operators we like in future versions of the
> language, so wanting “CDDL 2.0” as a shortcut for a number of control
> operators is not an argument against a more open handling of developing
> them.

And of course we would probably change the semantics some when doing this so there are going to be multiple copies of these operators anyway.

> 
> If development of CDDL continues in the IETF, we can of course develop our
> own, generally applicable, well-honed control operators as well.  We are just
> sharing a registry with the general public (which would likely not be zero-
> threshold, anyway).  We can also import nice additions from outside into future
> versions of the CDDL language specification.  (This all stays theoretical until
> other organizations do some development, too, but as I said that is not
> unlikely.)
> 
> One approach to encourage bringing control operator extensions to the IETF
> would be to give external ones a separate namespace.  But this creates the “X-
> Dash” problem (RFC 6648) all over again: Once we pull some of them in, we
> would want to change their names; more likely, people would still  continue to
> use the old names to be compatible with the largest number of tools.  So we
> probably shouldn’t do that.

Being compatible with the largest number of tools implies that these are things which should be done in an updated version of the specification rather than being esoteric things that are one offs.

Jim

> > of extensions sounds much better to me. At least in this early stage
> > of the CDDL language.
> >
> > Michael
> >
> >> I would have a strong preference that this would be done via versioning of
> the language.  It makes it much easier to say that I have a CDDL version X item
> checker rather than trying to say I have a CDDL checker that support the
> following set of extensions.
> >>
> >> Jim
> >>
> >
> >
>

---

From: Sean Leonard <[email-masked]>
Date: Tue, 17 Jul 2018 13:54:53 -0400

+1 to Jim’s comment.

I remain skeptical about the actual utility of control operators in defining specifications. Accordingly, I am opposed to creating a registry.

If people use control operators in specs and later want to change or expand the range of acceptable values, they will regret putting the control operator in there in the first place. 

It is better to leave it as a free-for-all for now, which is to say, the text of cddl-02 (no registry) was better than cddl-03 (proposed IANA registry).

Sean

> On Jul 12, 2018, at 8:56 AM, Jim Schaad <[email-masked]> wrote:
>