Tommy it says you are \"Deleg Delegate\" - it should say \"Deleg Deleg\"
", "time": "2024-10-08T15:00:15Z"}, {"author": "Tommy Jensen", "text": "Deleg^2, clearly
", "time": "2024-10-08T15:01:27Z"}, {"author": "David Lawrence", "text": "To be clear, version 1 is option base 0, so actually the second version
", "time": "2024-10-08T15:02:20Z"}, {"author": "Florian Obser", "text": "btw. I'd like to see requirements numbering in the draft at some point. I'll send a mail sometime in the future when the important discussions quiet down.
", "time": "2024-10-08T15:03:40Z"}, {"author": "Tim Wicinski", "text": "Actually I like this numbering scheme and would prefer to mark them in the document for simpler way to discuss topics
", "time": "2024-10-08T15:03:45Z"}, {"author": "Tim Wicinski", "text": "I think we are in agreement Florian
", "time": "2024-10-08T15:04:15Z"}, {"author": "Ted Hardie", "text": "No need to take anything out now, in my opinion; leaving in the obvious will not hurt anything.
", "time": "2024-10-08T15:04:21Z"}, {"author": "Peter Thomassen", "text": "ack, Ted
", "time": "2024-10-08T15:04:42Z"}, {"author": "Tim Wicinski", "text": "agree Ted
", "time": "2024-10-08T15:05:46Z"}, {"author": "David Lawrence", "text": "Very much my thought in writing the \"obvious\" ones.
", "time": "2024-10-08T15:07:21Z"}, {"author": "Mike Bishop", "text": "So to be clear, it is not a requirement whether the solution places identical records at parent and child? Any solution here is acceptable?
", "time": "2024-10-08T15:08:41Z"}, {"author": "Tim Wicinski", "text": "Right now that is an implementation proposal decision
", "time": "2024-10-08T15:09:58Z"}, {"author": "Benjamin Schwartz", "text": "Mike Bishop said:
\n\n\nSo to be clear, it is not a requirement whether the solution places identical records at parent and child? Any solution here is acceptable?
\n
I think that line is meant to be an \"anti-requirement\", not a \"non-requirement\".
", "time": "2024-10-08T15:10:53Z"}, {"author": "Jim Reid", "text": "+1 Ben. I think we should keep our options open => no rule in or out having identical RRs in the parent and child. Let's see what transpires when the protocol work gets under way.
", "time": "2024-10-08T15:12:59Z"}, {"author": "Jim Reid", "text": "s/no/not/
", "time": "2024-10-08T15:13:22Z"}, {"author": "David Lawrence", "text": "Personally I think \"with DNSSEC\" should stay as is, since that it is the current means of securing DNS data. I am not really grokking what the objection to its presence is, even as I do acknowledge the point that the overall goal is the \"secure\" part and DNSSEC is just one specific means. But there hasn't been any other means suggested that indicates its a plausibly open issue about the mechanism.
", "time": "2024-10-08T15:17:45Z"}, {"author": "Jens Finkh\u00e4user", "text": "Could be solved by stating \"with DNSSEC or future means\" or some such.
", "time": "2024-10-08T15:18:36Z"}, {"author": "Jim Reid", "text": "Removing \"with... means\" does that too. With fewer words. :-)
", "time": "2024-10-08T15:19:28Z"}, {"author": "Benjamin Schwartz", "text": "David Lawrence said:
\n\n\nPersonally I think \"with DNSSEC\" should stay as is, since that it is the current means of securing DNS data. I am not really grokking what the objection to its presence is, even as I do acknowledge the point that the overall goal is the \"secure\" part and DNSSEC is just one specific means. But there hasn't been any other means suggested that indicates its a plausibly open issue about the mechanism.
\n
If DNSSEC is defined as being the DNS's security subsystem, is any DNS security mechanism DNSSEC? :thinking:
", "time": "2024-10-08T15:19:44Z"}, {"author": "Frederico Neves", "text": "DELEG MUST not use same NAME CLASS TYPE at parent and child zones.
", "time": "2024-10-08T15:19:45Z"}, {"author": "Ralf Weber", "text": "Agree
", "time": "2024-10-08T15:20:11Z"}, {"author": "Tim Wicinski", "text": "Frederick - agree with wording
", "time": "2024-10-08T15:20:30Z"}, {"author": "Jens Finkh\u00e4user", "text": "Jim Reid said:
\n\n\nRemoving \"with... means\" does that too. With fewer words. :-)
\n
Implicitly, yes. I am suggesting there is nothing lost by making it explicit.
", "time": "2024-10-08T15:22:19Z"}, {"author": "Jim Reid", "text": "I agree with Petr: \"don't make another ugly mess\" should be a req.
", "time": "2024-10-08T15:22:28Z"}, {"author": "David Lawrence", "text": "and registry operators
", "time": "2024-10-08T15:22:50Z"}, {"author": "Jim Reid", "text": "@Jens, making explicit lists of things leads to rat-holing IMO. Keep it simple. Less is more, etc, etc.
", "time": "2024-10-08T15:24:27Z"}, {"author": "Tim Wicinski", "text": "HARD AGREE on Operator term !
", "time": "2024-10-08T15:24:38Z"}, {"author": "Paul Hoffman", "text": "Good point; how could I forget registry operator? :-(
", "time": "2024-10-08T15:24:48Z"}, {"author": "Manu Bretelle", "text": "I am not sure how to capture the not making another mess into a requirement.
\nBut it seems:
\n\nDELEG MUST not use same NAME CLASS TYPE at parent and child zones.
\n
\ncapture part of it, implicitely.
On the operation side, I think the main problem is not knowing where the authoritative view is vs it being on parent or child.
", "time": "2024-10-08T15:25:45Z"}, {"author": "Roy Arends", "text": "I agree with Fred. NAME TYPE CLASS authoritative in one zone
", "time": "2024-10-08T15:25:49Z"}, {"author": "Jens Finkh\u00e4user", "text": "Jim Reid said:
\n\n\n@Jens, making explicit lists of things leads to rat-holing IMO. Keep it simple. Less is more, etc, etc.
\n
I think of it as a nudge towards acceptable means of compliance based on existing standards. I'm not too opinionated on this, however.
", "time": "2024-10-08T15:28:00Z"}, {"author": "David Lawrence", "text": "Hard agree with what Ed is saying, we're not disrupting the external semantics of the namespace
", "time": "2024-10-08T15:28:05Z"}, {"author": "Mike Bishop", "text": "The fundamental goal seems to me that legacy resolvers can still resolve names against DELEG-enabled authoritatives, and DELEG-enabled resolvers can still resolve names against legacy authoritatives. Everything else seems up for discussion.
", "time": "2024-10-08T15:30:33Z"}, {"author": "Paul Hoffman", "text": "+1, Mike
", "time": "2024-10-08T15:30:52Z"}, {"author": "Tim Wicinski", "text": "Opened an issue on Frederick's wording https://github.com/ietf-wg-deleg/draft-ietf-deleg-requirements/issues/9
", "time": "2024-10-08T15:31:34Z"}, {"author": "Tim Wicinski", "text": "(so I don't forget)
", "time": "2024-10-08T15:31:47Z"}, {"author": "Tim Wicinski", "text": "H1 is good to keep even if it seems obvious
", "time": "2024-10-08T15:32:44Z"}, {"author": "Frederico Neves", "text": "Most of those are goals of misses and no one will dispute.
", "time": "2024-10-08T15:32:48Z"}, {"author": "David Lawrence", "text": "We'd be DOA if we mess with the name industry
", "time": "2024-10-08T15:32:54Z"}, {"author": "Petr \u0160pa\u010dek", "text": "+1
", "time": "2024-10-08T15:33:11Z"}, {"author": "David Lawrence", "text": "I think disrupt is perfectly cromulent there.
", "time": "2024-10-08T15:33:52Z"}, {"author": "David Lawrence", "text": "+1 Petr
", "time": "2024-10-08T15:34:17Z"}, {"author": "Michael Richardson", "text": "It won't the the TLDs that are paying attention to DELEG that will have concerns ;-)
", "time": "2024-10-08T15:34:30Z"}, {"author": "Paul Hoffman", "text": "Maybe I misspoke, but I'm fine with both keeping or dropping H1.
", "time": "2024-10-08T15:36:26Z"}, {"author": "Tommy Jensen", "text": "Paul and Petr disagree, but I thought I hear you both say \"leave it alone\"?
", "time": "2024-10-08T15:36:36Z"}, {"author": "Tommy Jensen", "text": "ok cool, thanks Paul
", "time": "2024-10-08T15:36:43Z"}, {"author": "David Lawrence", "text": "Incremental is also about not havign a flag day where it has to be installed everywhere to work
", "time": "2024-10-08T15:37:00Z"}, {"author": "Manu Bretelle", "text": "It may not disrupt the financial model, but will eventually disrupt the technical aspect of it. e.g they probably will have to put some work to support DELEG
", "time": "2024-10-08T15:37:10Z"}, {"author": "Paul Hoffman", "text": "Manu: agree, but that's not in H1.
", "time": "2024-10-08T15:37:33Z"}, {"author": "Michael Richardson", "text": "+1 on what Paul said, hard to measure.
", "time": "2024-10-08T15:38:59Z"}, {"author": "Frederico Neves", "text": "Hard is MUST HAVE, Soft is good do have.
", "time": "2024-10-08T15:39:46Z"}, {"author": "Petr \u0160pa\u010dek", "text": "I think it's pretty easy to measure... Just look how many operations require involvement of registrant when operator wants to change something.
", "time": "2024-10-08T15:40:13Z"}, {"author": "Manu Bretelle", "text": "I guess I read H1 as broad, not just the financial
", "time": "2024-10-08T15:40:15Z"}, {"author": "Frederico Neves", "text": "It is a delegate from the delegated.
", "time": "2024-10-08T15:40:59Z"}, {"author": "Paul Hoffman", "text": "Agreeing with Peter's \"raising hands in confusion\"
", "time": "2024-10-08T15:41:52Z"}, {"author": "Tim Wicinski", "text": "S4 could add any extra wording and drop S7
", "time": "2024-10-08T15:42:19Z"}, {"author": "Tim Wicinski", "text": "S4: DELEG should enable a DNS operator to manage DNS service more completely on behalf of domain administrators. For example, DELEG could address long-standing issues of DNSSEC record maintenance that now often depend on registrant / registrar interaction. Similarly, DELEG could allow new transports to be deployed by an operator or nameserver names to be changed, without necessitating that delegation information be modified by the domain administrator.
", "time": "2024-10-08T15:42:26Z"}, {"author": "Manu Bretelle", "text": "+1 Jim. S7 is likely orthogonal while S7 makes it feel as DELEG will implement its own solution.
", "time": "2024-10-08T15:43:11Z"}, {"author": "Peter Thomassen", "text": "aha, S4 is the indirection delegation (~AliasMode)! thanks.
", "time": "2024-10-08T15:43:22Z"}, {"author": "Manu Bretelle", "text": "Peter, the mode that cannot be named :)
", "time": "2024-10-08T15:43:46Z"}, {"author": "Jim Reid", "text": "New S4 suggestion: DELEG should allow a third party DNS operator to manage and provision DNS services.
", "time": "2024-10-08T15:44:07Z"}, {"author": "Frederico Neves", "text": "Basically the aspiration is to crate a new indirection on DNS.
", "time": "2024-10-08T15:44:20Z"}, {"author": "Manu Bretelle", "text": "But yes, I think this is a direct mapping to what the Alias mode was for.
", "time": "2024-10-08T15:44:24Z"}, {"author": "Frederico Neves", "text": "I mean create
", "time": "2024-10-08T15:44:57Z"}, {"author": "Peter Thomassen", "text": "I think ways for the child to update the delegation is important, for a lot of reasons (e.g., changing providers, or changing keys for domains not using the indirect mechanism from S4, etc.)
", "time": "2024-10-08T15:45:46Z"}, {"author": "Peter Thomassen", "text": "In particular, S7 is important for automatic bootstrapping of delegation configuration
", "time": "2024-10-08T15:45:59Z"}, {"author": "Manu Bretelle", "text": "Jim Reid said:
\n\n\nNew S4 suggestion: DELEG should allow a third party DNS operator to manage and provision DNS services.
\n
if we want to avoid operator:
\nDELEG should allow a third party to manage DNS on behalf of the zone owner.\n\"provision\"?
", "time": "2024-10-08T15:46:46Z"}, {"author": "Peter Thomassen", "text": "If we don't have S7, then all registrants have to touch their delegation again to set up DELEG!
", "time": "2024-10-08T15:46:48Z"}, {"author": "Petr \u0160pa\u010dek", "text": "No, we are just saying that it's not a DELEG bussiness.
", "time": "2024-10-08T15:47:17Z"}, {"author": "Petr \u0160pa\u010dek", "text": "Or rather, DELEG requirement.
", "time": "2024-10-08T15:47:27Z"}, {"author": "Peter Thomassen", "text": "ah, fair.
", "time": "2024-10-08T15:47:36Z"}, {"author": "Edward Lewis", "text": "There's that 'provision' word
", "time": "2024-10-08T15:47:37Z"}, {"author": "Tim Wicinski", "text": "https://notes.ietf.org/notes-ietf-interim-2024-deleg-01-deleg?edit
", "time": "2024-10-08T15:47:37Z"}, {"author": "Tommy Jensen", "text": "Tim beat me to it
", "time": "2024-10-08T15:47:53Z"}, {"author": "Frederico Neves", "text": "A HARD one, DELEG should not be harder to debug than the current delegation mecanism.
", "time": "2024-10-08T15:48:15Z"}, {"author": "Jim Reid", "text": "Thanks to Tommy. And Tim.
", "time": "2024-10-08T15:48:18Z"}, {"author": "Jim Reid", "text": "Depends on what's meant by \"harder\" Fred.
", "time": "2024-10-08T15:49:17Z"}, {"author": "Tim Wicinski", "text": "Opened Issue: \"Drop S7, shorten S4 \" https://github.com/ietf-wg-deleg/draft-ietf-deleg-requirements/issues/10
", "time": "2024-10-08T15:49:18Z"}, {"author": "Jens Finkh\u00e4user", "text": "Not that it's ideal, but there is https://datatracker.ietf.org/doc/rfc5730/ for provisioning. If that is insufficient, should the work not be done there?
", "time": "2024-10-08T15:51:41Z"}, {"author": "Frederico Neves", "text": "I mean it should be clear if a delegation is funcional or not. The current model allow for some unpredictable cenarios.
", "time": "2024-10-08T15:52:07Z"}, {"author": "Andrew Newton", "text": "https://datatracker.ietf.org/doc/bofreq-wullink-restful-provisioning-protocol/
", "time": "2024-10-08T15:52:33Z"}, {"author": "Ted Hardie", "text": "I think the key point, though, is that you don't expect this delegation work to intersect with provision protocols.
", "time": "2024-10-08T15:53:06Z"}, {"author": "Andrew Newton", "text": "In the current DNS, there is a bit of an intersection with CDS.
", "time": "2024-10-08T15:53:41Z"}, {"author": "Jens Finkh\u00e4user", "text": "Andrew Newton said:
\n\n\nhttps://datatracker.ietf.org/doc/bofreq-wullink-restful-provisioning-protocol/
\n
Wasn't going to mention it, because we're active there, but yes.
", "time": "2024-10-08T15:53:43Z"}, {"author": "Paul Hoffman", "text": "Ted: We don't expect or not expect at this point.
", "time": "2024-10-08T15:56:01Z"}, {"author": "Ted Hardie", "text": "@Andrew Newton would any of that change with this work? Are you looking for a requirement that it not change?
", "time": "2024-10-08T15:56:04Z"}, {"author": "Andrew Newton", "text": "@Ted I think it would be undesirable to have the current ambiquity. How that becomes a requirement is beyond me.
", "time": "2024-10-08T15:56:55Z"}, {"author": "Tommy Jensen", "text": "Tim: thank you! All I ask is you bring a snarky flavor to notes headers.
", "time": "2024-10-08T15:57:20Z"}, {"author": "Petr \u0160pa\u010dek", "text": "Yes please!
", "time": "2024-10-08T15:57:35Z"}, {"author": "Ted Hardie", "text": "@Andrew Newton maybe you could open an issue on it and see if anyone has thoughts on making a requirement here?
", "time": "2024-10-08T15:58:28Z"}, {"author": "Paul Hoffman", "text": "Thanks, y'all!
", "time": "2024-10-08T16:00:24Z"}, {"author": "Jim Reid", "text": "bye
", "time": "2024-10-08T16:00:32Z"}, {"author": "Petr \u0160pa\u010dek", "text": "Thanks everyone!
", "time": "2024-10-08T16:00:34Z"}, {"author": "Manu Bretelle", "text": "bye all!
", "time": "2024-10-08T16:00:35Z"}, {"author": "Willem Toorop", "text": ":wave:
", "time": "2024-10-08T16:00:41Z"}, {"author": "Tim Wicinski", "text": "Thanks!
", "time": "2024-10-08T16:00:49Z"}, {"author": "Benno Overeinder", "text": ":wave:
", "time": "2024-10-08T16:01:01Z"}]