Thursday, 10 Nov 2022, 17:00 UK time
Administrative / status review (5 min)
Discussions (50 min)
a. DNS in CBOR, follow-up from 19 Oct interim discussion (ML)
b. Time-tag: do we sync with the SEDATE spec? (CB)
c. CDDL 2.0 -- the plan, and moving forward (CB)
d. Should we be having joint discussions with other working groups?
SUIT, RATS, ... (especially concerning CDDL 2.0)
e. Other?
AOB (5 min)
Minute takers: Marco Tiloca, Christian Amsüss
BL going through introductions and note-well.
BM: (proxying for Henk). Can we move Time-Tag and CDDL to the start?
BL: We'll go b-c-a-d then.
CB: Had the meeting on the proposed RG on formal methods. Sounds like
there will be a RG, which we can then talk to in the context of CDDL
2.0.
CB presenting.
Presented slides:
https://datatracker.ietf.org/meeting/115/materials/slides-115-cbor-carstens-slides-01.pdf
CB: This is from 2017, then tags registered in 2018 and have been used,
so we should avoid big changes. It got adopted in 2021, and now we're
synching with SEDATE.
CB (p3): An implementation survey suggests that RFC 3339 is used as
expected. There is an ongoing bugfix discussion. (around minus sign on
-00:00 time offsets forbidden in a newer ISO release). The bugfix needs
some chartering discussions. SEDATE has completed WGLC, so time-tag can
also move to WGLC. ECMA is also in sync with this. To-Do for us:
synchronize our draft, and do WGLC based on this.
CB (p4): UT1 would be on topic because CBOR is used in space. Originally
hoped to process WGLC at IETF 115, but postponed (surveying pending
points).
CB Presenting
Presented slides:
https://datatracker.ietf.org/meeting/115/materials/slides-115-cbor-carstens-slides-01.pdf
CB (p6): Some items from the freezer document can be brought up here. If
you have more that is not covered by these 4 items, please say so.
CB (p7): Backward compatible proposal to admit non-literal tag numbers
among '<' and '>'. How are we going to package this? Separate and very
short document? Some would like this to happen quickly.
BM: If we change what follows the '.' to a non-literal, you expose the
major type of the tag, maybe there's a cleaner way.
CB: That's the result of a mistake we can't probably fix. For any other
major type, what follows the major type is additional information. No
easy fix.
CB (p8): We've started already to extend the processing model.
Validation and features are currently available. CDDL can annotate the
rules used for matching. The model would benefit from annotating that
the use of a particular rule was important (eg. "that this just matched
a 'text' rule" could be unimportant, and would just be noise to the
user). The next step following validation is transformation, to remove
any "syntactical noise" thanks to the annotation.
BM (p9): Worked at the Hackathon on a CBOR parser definition directly
from CDDL. I have code + schema-ish data structure. Can't still parse
CBOR directly, but it iterates CBOR. Mostly SUIT in mind, but it can be
used more generally. Extracts guidance flags from CDDL (unwrapping CBOR
inside byte string, pass something to a handler function, handle
key-value pairs).
BM: I think entry points are missing in CDDL, which makes the process
difficult. If I had them, even though not proper of CDDL, I can tell my
generator what I want to pull out. Annotations would help my parser to
handle things in a particular way or not.
BM: Thinking of SUIT, one needs to extract a manifest Seq Num before any
validation. I'd like to have two variations.
BM: Ordered multi-maps are hard to handle for me. Same for imports, I
have to fetch copies of CDDL, and it's especially hard for COSE. I can't
strip out element I don't want and have to import everything.
BM (p10): Giving an example where, under a certain context and use case,
certain things are not expected to happen (e.g., certain types of
messages) and related information would be better filtered upfront if it
comes up.
CB (p11): On solutions. Proposed syntax for module superstructure,
backward compatible with CDDL 1.0. This use of 'export' may to some
extent be related to the "entry points" that BM mentioned. The other
types are still available (this does not encapsulate), but these are
expected to be used.
CB (p12): On referencing IANA registry and their entries. Had a
discussion with IANA about this. I'm using internal interfaces that I'm
not supposed to, so we need to work closely with IANA on this, which
will take time and IANA will have to implement an interface. That's why
a separate document would be better.
BM: It can help to use the CSV file available for each registry.
CB: Yes, though maybe not everything is there. Is there xpath for CSV?
CB: Could need time for IANA to work this out, so maybe push this out.
CB: At some point, something like this would be useful to do for ABNF.
CB (p13): On referencing RFCs.
CB (p14): Examples of exporting by using namespaces. It should work for
RFCs and Internet Drafts (though the version number is tricky to
handle). For old RFCs, everthing from those is implicitly imported.
BM (on chat): For explicit import, it should be xml, not txt, surely.
CB (p15): On operations, i.e., "export", "import", and "include/use".
The latter is problematic because the reference is out of the document.
CB (p16): Open point to discuss is how one finds the document exporting
a namespace. Also considering document splitting, updates, revisions,
from-version-X, etc.
CB (p17): If we do something for CDDL, it will likely work for ABNF too.
CA: The annotation might be missing an indication of whether something
is meant to be understood or not.
CB: For now, everything in a CDDL spec is mandatory to understand.
CA: If you think of extension points, it should be possible to ignore
particular branches for parts not necessary to understand.
CB: Somehow I'd like to pair this with .feature.
CA: Yes!
BM: Can't agree on mandatory-to-understand. If I have a parser that
understands COSE-Sign and not COSE-..., that's OK.
HB: My answer to Carsten is I don't know. Something related to BM's:
ID(?). We do annotation (??)
(miunte taker: ? Sorry didn't understand that point well enough to
capture)
CB: All this information in one CDDL spec does not work well. We agree
on some things in standard, but not others (eg. variable name for
something). We need to be able to add information to a CDDL file in a
way that survives the underlying CDDL evolving.
BM: That's what I would do, it's not only about CDDL. I agree.
BL: Time check…
CB: Please share ideas on the mailing list. Then we can bring the
discussion to the interim meetings.
Presented slides:
https://datatracker.ietf.org/meeting/115/materials/slides-115-cbor-cbor-for-dns-messages-01.pdf
ML presenting.
ML: (skillping into p3-5) Motivation: DNS-over-CoAP runs into
fragmentation quickly. Thus need to compress DNS messages. Decided to
use CBOR for this.
ML (p6): DNSOP feedback after CoRE discussion. Mitigation: Option to
have unstructured RRs; plus with content negotiation we can always fall
back to wire format.
ML (p7): The record entry is still encoded like I showed at the interim
meeting.
ML (p8): Also doesn't do stateful operations.
ML (p10): Fallback to unstrucutred RRs
ML (p11): Assumption that =transport can map request and response (if
not: set number)
ML: For querying ANY record, response can get quite large, hence we use
Packed CBOR, with a dedicated media-type. Not in v-01 yet. Shown example
with 163.9% compression through Packed CBOR.
ML: Back to designing for EDNS(0)/DSO or keep as is?
ML: Another next step is providing more details on using Packed CBOR
(e.g., constructing the compression table, now implying DNS-specific
tables).
CB: Worked on compression a lot ... there is urge to get that other 1%;
have to be careful to not fall victim to that and do the meaningful and
implementable things. If something falls out without much effort, let's
do it -- but not things that are complicated.
(no time, saved for first interim)
Interim schedule: Will keep cadence, in lockstep with CoRE (i.e., CBOR
on even weeks on Wednesdays). Start this year or wait for January?
No preferences in room, to mailing list.