IETF 124 DELEG

Chairs opening

There was off-list discussion on the requirements, today we will be
mainly going through the main draft

Main draft overview

Changes from -01 to -05 didn't change a lot of the core functionality,
but there were a lot of other changes, including:

added "deleg" key to RESINFO
expanded examples
RR type changes that will make it easier to expand into new keys
included
Avoided rewriting requirements from RFC 103x or RFC 403x (DNS and
DNSSEC), fixing examples

Implementation experience

Akamai has done auth and recursive
BIND did dig and auth zone load
CoreDNS for RR format
dnspythong for RR format

Implementation feedback

Found that nested, multi-level include-delegi= was awkward
However, we have to have two levels
TTL makes this challenging
Possible to use tricks with one layer of indirection so that values
can be dynamically generated elsewhere

Discussions with registries was productive, no knee jerk reactions
against it.

Need more examples (but they are going to be test vectors now that we
have implementations)

WG discussion on test vectors

What happens if the test vectors are wrong because the implementors
get the spec wrong?
This should all work out well
If that happens, we can end up chaging the spec to match how we
think it ought to be working
(general support for test vectors)

(Definitions of requested examples omitted for brevity, they are listed
on slides 14-22)

WG discussion on the examples needed

Slide 17 Yes please. As implementors, we had to dig deep to
figure this out (auth having parent and child zone at the same time
and DE=0 and QTYPE=DELEG query)
Slide 18 There are no test vectors in SVCB, so we may even help
fix issues in SVCB implementations (clarification from chat:
actually, there are at least for formatting issues)
Slide 18 This should work also for registry protocols

GitHub issues

Issue 5: see draft-arends-dnsop-delext in the dnsop WG, we will discuss
this issue in the dnsop session instead

Issue 27: should we split priming into a separate document as this is
really only for roots?

Issue 35: when using server name, MUST NOT or SHOULD NOT for keeping
server-name and include-delegi keys in the delegation domain's zone

Issue 92: SVCB mandatory key, should we use this key to ensure SVCB
recor dis ignored if there's a specified encrypted DNS transport that
isn't supported? (see discussion on list)

Issue 93: should we have global rules for processing each key to make it
easier for implementors reading IANA registry? Authors leaning toward
per-key basis (see discussion on list)

Issue 95: SVCB RFC says MUST ignore unknown keys, suggesting we mimic
this (see Issue 92 above)

WG discussion on GitHub issues

Should we define some keys as always MUST be defined as mandatory
keys?
Aren't there edge cases with this mandatory behavior where we will
end up with no unignored delegation records?
(room disagreement on how we handle mandatory key definitions)
For issue 35, use SHOULD NOT and specify ignore
Please don't use SHOULD unless you can defined when an implementor
MAY ignore it

Implementation status

Are there other implementations that were not listed in the previous
discussion? Please bring them forward so they can be included in the
experimentations.

Shumon does (worked at hackathon, mostly in line with -05)
This should not be included in the draft. When there is lag between
versions of the draft, people are unaware of newer implementations.
Let's track implementations list in GitHub

The chairs would like to see working implementations to gate
publilcation, could use the test vectors discussed

We need to be careful, as resolvers have a lot of lateral freedom to
behave differently

Requirements doc: should we publish it?

We have refreshed the requirements doc, and our charter says we will
publish it as Informational. Is the WG comfortable with its current
state, and should we go ahead with publication?

We should just ignore the charter and not publish this
Éric Vyncke (Responsible AD): you cannot go outside your charter,
but you don't have to do everything in the charter if you do not
want to. Please publish requirements together with base protocol if
you're going to
It's useful for historic reasons to publish requirements (in 15
years, people will understand why we made given decisions)
We need to commit to not retroactively changing the requirements to
match the base protocol we wrote (ack which requirements we actually
met instead)

AOB

DNS Directorate review: should we?

Jim Reid (co-chair of DNS Directorate): we will assign someone who
hasn't been active in DELEG to do the review, if such a person
exists
Éric Vyncke (Responsible AD): should get Ops review as well

Can we / should we recharter to support proposed extensions that are
currently not in scope?

Seems reasonable within six months, these drafts have been waiting
on the base protocol anyway
(Support for rechartering sooner rather than six months, for
transports + at least two other extensions)

What are our plans/timeline for nailing down TLD registry requirements
versus existing guidance for auths?

There is some coordination going on, yes (but how heavy do we expect
requirements on TLS registries to be?)
The base protocol editors have done reach out to RIRs. Please reach
out to us if there needs to be more

Chairs will raise on the list also, but is there interested in an
interim (late Jan / early Feb)?

DNS Directorate review by then would be worth having a meeting to
review
Cool, chairs will get DNS and OPS Directorates to review promptly
Geoff Huston, co-chair of DNS Directorate: it seems you're
overinterpreting a single person's review. We can farm this review
out to a few different people if you want that, if you formally
indicate that to us (Jim and Geoff).

New GitHub issues filed: