Chair slides here
See draft here:
https://datatracker.ietf.org/doc/draft-ietf-deleg-requirements/
There were several requirements without any discussion -- was this
because they are trivially accepted?
Requirements with no list discussion
Requirements with some list discussion
Bulk of list discussion
The TL;DR is:
Securing delegations
Parent v. child
Meaning of "disrupt"
S4 and S7
Provisioning
New issues filed during the meeting (thank you Tim!):
Jim: For H4, I think we are overthinking it. If we just say "DELEG needs
to secure delegations" we can stop there.
Ed: The naunce we should capture is that we want DELEG to not hinder
DNSSEC. Not depend on it, could use it if available.
Paul: We might be able to drop a few more requirements. Start with
"don't break existing DNS" and then eliminate requirements that are
strict subsets of this.
Duane: Note that today, delegations are not secure.
Tim: The way NS works today is a little odd -- let's dive into this
issue because I want to hear the arguments.
Ralf: We should define the source of authority and then not have
additional sources of information. That leads to the parent.
Tim: I agree with Ralf, but there's no reason the parent couldn't say
"go to the child for that information".
Jim: We need to wait and see what happens as protocol development
unfolds -- let's not make this call here in the requirements (keep our
options open).
Paul: I would remove this completely (because this is not a requirement
for the protocol) or a requirement that assigns to the protocol that it
needs to determine parent v. child.
Paul: We cannot use the terms "parent centric" and "child centric" -- we
need some different taxonomy.
Petr: +1 to not have this as a requirement right now. Something like
"The protocol must not create opportunities for misalignment" might be
useful.
Ed: The real requirement is that DELEG makes operations easier. Success
is not determined whether it is parent- or child-centric.
Paul: I agree with Ed. That said, we have two sets of operators:
resolver and authoritative. Whenever we do work on this, we need to pick
one of the two sets of operators to make operations easier for.
Duane: a word of caution: there are more than two types of operators.
Whatever we do may not make life easier for other operators.
Ed: Let's shelve all this NS and parent/child discussion and define the
goal of making operators lives easier (using "operators" generally).
Ed: DELEG only focuses on how the components talk to each other. We
should focus only on what is sent in messages, not how zones are
managed.
Jim: All I meant when working on this was to have "DELEG should not
disrupt the installed base". Saying "backward compatible" might be the
wrong way to say it. The point is an operator can still use NS records.
Peter: Let's refrain from transferring "who is authoritative for what"
onto DELEG.
Petr: +1 to Jim.
(from chat: Mike and Paul saying the point is that NS and DELEG
resolvers can still resolve names against one another)
Tim: opened an issue to track chat-suggested text by Frederick "DELEG
MUST not use same NAME CLASS TYPE at parent and child zones":
https://github.com/ietf-wg-deleg/draft-ietf-deleg-requirements/issues/9
Ed: + to DELEG being "only" a communication mechanism that should not
disrupt existing operations.
Jim: I do not think "disrupt" is the right word to balance our goals
against worrying operators.
Petr: I like the current wording.
Ed: Maybe the problem is "disrupt" means different things to different
people. We mean not to break things.
Paul: This doesn't matter until we get to the protocol development.
Let's just leave it as is, pass the requirements doc, then we can move
on. Keeping or dropping H1 is fine, let's just not work on wordsmithing
it now.
Petr: Let's keep H1.
Ed: We need to ensure the meaning comes across correctly (get the
wording right).
Paul: No because we cannot measure. It's just a requirement.
Tale: Hard requirements are the bare minimum needed for a working
protocol, and the rest were labeled soft requirements. They are still
active goals. I think this should be left as soft requirement.
Peter: S4 and S7 are both soft, look similar, but we're talking about
promoting S4 and dropping S7? I'm confused.
Duane: Think how Cloudflare can host your DNS for you, but they are not
a registrant/registry. S4 and S7 are talking about different parties.
Jim: We should delete S7 completely as it assumes a specific
implementation flavor.
Jim: S4 wording is clunky. More complete than what? Let's just say
"facilitate third parties to..."
Petr: +1 to Jim. S4 says "set up the record and you are done" which we
need, and S7 goes further to talk about implementation details. We
should drop S7.
Ed: The in-band part kills S7 for me. Let's not talk about "how" to do
anything at this point.
Paul: I like dropping S7, and I like shortening S4, but we should be
clear about which operators it refers to.
Petr: We should rephrase to explain that we want to minimize
communication needed between parties.
Ed: +1, we just want to facilitate direct communication.
Jim: Let's go further with this and generalize.
Tim: filed an issue for shortening S4 and dropping S7:
https://github.com/ietf-wg-deleg/draft-ietf-deleg-requirements/issues/10
Ed: We should think about pulling provisioning out and discussing it
separately. DNS is simple query/response, but provisioning has a
back-and-forth.
Paul: No (let's not add provisioning to requirements)
Petr: +1 to both (not adding provisioning). NS does not have this
anyway.
(chat shared links about existing provisioning work)
Jim: Sorry, this kind of provisioning was not my intention when using
this word.
Ed: This needs to be a detail to be mentioned in the solution, but open
to not being a requirement.
Paul: Yes, this is not a requirement. (+1 from Petr)
Duane: drafts are due by October 21
Tim: Opened issues based on discussion, will chat with Tommy to make
sure we caught everything.
(ended one hour early)