Minutes IETF102: cbor
minutes-102-cbor-00

CBOR WG Meeting
IETF 102 - Montreal
Tuesday, July 17, 2018, 13:30 - 15:30
Chairs: Barry Leiba, Francesca Palombini

Minute takers: David Waltermire

* Introduction [10'] : Chairs - slides
https://datatracker.ietf.org/meeting/102/materials/slides-102-cbor-chairs-00
----------------------------------

  Agenda bashing and status update
Chairs provided a short status update based on content in the slides.

WG documents: - slides
https://datatracker.ietf.org/meeting/102/materials/slides-102-cbor-consolidated-01
* CDDL [60'] : Carsten
  https://tools.ietf.org/html/draft-ietf-cbor-cddl
--------------------------------------------------

slide7:

Jeffrey Yasskin: Q - There is not standard definition for path expression
grammars. Carsten: We need to find a good reference for this. Jeffrey: We also
need to define the mapping between parse expression syntax and CDDL syntax.

Slide8:

Alexey: To use specification required, we need clear guidelines around what is
expected. Jim Schaad: Does the specification need to be public? Barry: Yes. If
you don't need that, then expert review can be used. Sean Leonard: Not sure we
need a control operator registry. Chairs: If we are going to have a registry,
we need to define what will be required. Do we need to establish a registry
now. Paul Hoffman: It would be bad to delay creating a registry. I prefer
expert review over specification required. Barry: You are suggesting we do not
need a specification for including an item in the registry? Paul: Yes. Expert
review provides a good level flexibility to support adequate human review. Jim:
If we do a CDDL 2, we should hold off on the registry until we have a better
handle on language details. Paul: It is fine to create a registry and to decide
later how a CDDL 2 would use the registry or do something else. Carsten: There
are things that can't be fixed in CDDL that need a CDDL 2 (e.g., cuts). This is
a reason to do a CDDL 2. The point of the registry is to communicate to users
that they can use CDDL even if their needed operator is not available. The
registry allows the user to define operators on their own schedule, based on
their ongoing needs. Barry: Expert review requires review by a group of people
based on defined criteria. Specification required add to "Expert Review" the
need to reference a specification. Chris Lemonios: We need a registry to
provide an orderly way to extend the language. Not having one will be a mess.
Alexey: Who would be upset if CDDL provided this registry? Sean Leonard: I
don't think a registry helps at this point in time. I don't think its useful,
and it will inhibit innovation. Dave Waltermire: A registry provides a way to
have agreement on an approach. Alexey: Expert review provides for some safety
through review around how a given item is approached. Chris Lemonios: Agree.
Designated experts will encourage good specifications. Mike Jones: With
specifiation required, the registration template contains a reference to the
specification. Jim Schaad: What if I want to write a control operator that
supports a closed use? Brian Carpenter: The IETF doesn't like a lack of
transparency around specifications. Alexey: I advise against "secret"
specifications. Need expert review. Recommend specifications.

Chairs: Add the registry. Make the requirement specification required.

POLL: Any concerns? no. Strong consensus in the room to move forward with
adding the registry and making the entries specification required.

Slide 9:

There was a discussion on how to handle equality of different types. Concerns
were raised about being clear. It was proposed to use different operators for
strings and numbers. (side 10) It was asked if there is a need to have numeric
variants of these operators.

Jeffrey Yasskin: It might be safe to restrict .ne/.eq to only numeric types. We
can extend use of these operators to other types in CDDL 2.

Slide 11:

Carsten: Symmetry in provided operators is consistent with other historic
languages. For this reason, CDDL should provide for the same symmetry.

Slide 13:

Dave Waltermire: We need to avoid fragmentation in tooling that may be caused
by different serialization options. Henk: Extensions can also create a
situation where serialization choices get broken. Lawrance Lumblade: We should
focus on the core specification and use case, and let specialized use cases do
something different. This keeps interoperability to a maximum within the core
uses, while allowing for special case handling in small communities.

Slide 16:

Jim: (Issue 9) My concerns was with promoting an appendix subsection to a
top-level appendix only. I don't think this will create a reference problem.

Chairs: Asked for participants to speak up in the meeting or on the list if
they are unhappy with where CDDL is at this point. No concerns were raised in
the room.

Chairs: Aiming for shipping the draft to Alexey in late August for AD review.

* CBOR specification status [30'] : Carsten
  https://tools.ietf.org/html/draft-ietf-cbor-7049bis
--------------------------------------------------

* Flextime [10']

* CBOR Tag Definitions
----------------------

Dave Waltermire: Maybe use a wiki instead of a document.
Alexey: Not a bad place to start
Paul Hoffman: Not sure of the value of this. People often reinvent the same
extension. The problem is around how new participants can find what extensions
already exist.

Some discussion around what format to use: I/D, RFC, wiki. More discussion
needed.

* Wrap-up [10'] : Chairs
------------------------

CDDL revision out by July 30
CBOR updated by October - August 31 for a next draft
 - Have bi-weekly conference calls starting the week of August 6th.
 - Chairs will setup the WG webex for this purpose.