[{"author": "Brian Haberman", "text": "

@Joe Did you find all your emergency exits?

", "time": "2024-11-04T09:30:06Z"}, {"author": "Joe Abley", "text": "

yep, out onto the balcony, plummet four floors into the canal

", "time": "2024-11-04T09:31:19Z"}, {"author": "Joe Abley", "text": "

the full meetecho client for remote is working for me

", "time": "2024-11-04T09:32:39Z"}, {"author": "Daniel Gillmor", "text": "

onsite meetecho is working for me

", "time": "2024-11-04T09:33:12Z"}, {"author": "Daniel Gillmor", "text": "

from the datatracker, clicking \"meeting materials\" for deleg, then trying to switch to the slides tab fails.

", "time": "2024-11-04T09:34:47Z"}, {"author": "Barry Leiba", "text": "

Notice that Joe does not so much fly, as plummet.

", "time": "2024-11-04T09:35:01Z"}, {"author": "Greg Choules", "text": "

In meetecho web. I can chat, but nothing appearing in the main window.

", "time": "2024-11-04T09:35:21Z"}, {"author": "Tim Wicinski", "text": "

https://github.com/ietf-wg-deleg/draft-ietf-deleg-requirements

", "time": "2024-11-04T09:35:22Z"}, {"author": "Joe Abley", "text": "

Barry, plummet is just a special case of fly

", "time": "2024-11-04T09:35:38Z"}, {"author": "Tim Wicinski", "text": "

I'd like to thank Dave for Volunterring to speak

", "time": "2024-11-04T09:35:47Z"}, {"author": "Joe Abley", "text": "

Note to chairs on the podium, when you type aggressively into your laptop, the keystrokes are quite audible remotely

", "time": "2024-11-04T09:36:27Z"}, {"author": "Joe Abley", "text": "

(assume that's where the typing is happening)

", "time": "2024-11-04T09:36:37Z"}, {"author": "Brian Haberman", "text": "

Other than this message, no typing on the stage

", "time": "2024-11-04T09:36:59Z"}, {"author": "Joe Abley", "text": "

must be someone else then

", "time": "2024-11-04T09:37:07Z"}, {"author": "Manu Bretelle", "text": "

Joe Abley said:

\n
\n

Note to chairs on the podium, when you type aggressively into your laptop, the keystrokes are quite audible remotely

\n
\n

we hear it here to. I wonder if this was coming from @Tim Wicinski though. I didn't see hand moving from the chairs.

", "time": "2024-11-04T09:37:14Z"}, {"author": "Lorenzo Miniero", "text": "

Maybe it's coming from Tim?

", "time": "2024-11-04T09:37:18Z"}, {"author": "Daniel Gillmor", "text": "

https://github.com/ietf-wg-deleg/draft-ietf-deleg-requirements (tim's link was weirdly formatted)

", "time": "2024-11-04T09:37:22Z"}, {"author": "Mark Andrews", "text": "

It Wass Tim's keyboard

", "time": "2024-11-04T09:37:23Z"}, {"author": "Joe Abley", "text": "

let's blame Tim

", "time": "2024-11-04T09:37:25Z"}, {"author": "Joe Abley", "text": "

it has mysteriously stopped now that Tim is speaking

", "time": "2024-11-04T09:37:33Z"}, {"author": "Tim Wicinski", "text": "

Apologies I'm having a hair issue

", "time": "2024-11-04T09:38:21Z"}, {"author": "Tim Wicinski", "text": "

@Manu Bretelle That has to be me. thanks for reminding me

", "time": "2024-11-04T09:39:18Z"}, {"author": "Michael Richardson", "text": "

Double Thumbs Up to what Paul said.

", "time": "2024-11-04T09:40:58Z"}, {"author": "Peter van Dijk", "text": "

Not sure the mixing should be up to configuration

", "time": "2024-11-04T09:44:46Z"}, {"author": "Daniel Gillmor", "text": "

agreed with Peter van Dijk, mixing based on configuration seems like a recipe for indeterminate responses.

", "time": "2024-11-04T09:46:39Z"}, {"author": "Ond\u0159ej Sur\u00fd", "text": "

FTR One of the QR codes outside has \u201cthauditorium\u201d instead of \u201ctheauditorium\u201d embedded.

", "time": "2024-11-04T09:47:14Z"}, {"author": "George Michaelson", "text": "

I don't like a decision being forced absent a conversation. Surely the goal is a choice to be made in the future but we should be less proscriptive WHICH choice is to be made at this stage in the life of the WG?

", "time": "2024-11-04T09:47:16Z"}, {"author": "Andrew Campling", "text": "

Mixed looks complicated, a recipe for confusion?

", "time": "2024-11-04T09:47:44Z"}, {"author": "George Michaelson", "text": "

here we have a model and an assert they are unmixable, and complete. I think we can challenge both statements in hypothesis, before we settle on one?

", "time": "2024-11-04T09:47:49Z"}, {"author": "Ond\u0159ej Sur\u00fd", "text": "

Oh dog, not the mixed model. Haven\u2019t we learnt anything from the NS parent-child mixed model?

", "time": "2024-11-04T09:49:00Z"}, {"author": "Brian Haberman", "text": "

We are not choosing now. Paul is raising awareness of things we need to consider during solution development

", "time": "2024-11-04T09:49:01Z"}, {"author": "Greg Choules", "text": "

I have to say that I have seen operationally with the current model that some child domain owners get it wrong and manage to cut themselves off, if resolver chooses to believe the child rather than the parent.

", "time": "2024-11-04T09:49:04Z"}, {"author": "George Michaelson", "text": "

Sorry Brian, paul implied a choice should be made \"soon\" in the lifetime of the WG. or at least thats how I heard him

", "time": "2024-11-04T09:49:36Z"}, {"author": "Stephen Farrell", "text": "

hang on, where's warren's hat?

", "time": "2024-11-04T09:49:46Z"}, {"author": "Benjamin Schwartz", "text": "

I think this parent vs. child conversation may just go away with the improved flexibility of DELEG. Some DELEG designs allow the parent to say \"go look over here\", and for the target to say \"actually no thank you, go look over here\".

", "time": "2024-11-04T09:49:48Z"}, {"author": "George Michaelson", "text": "

I'm maybe overdoing a devils advocate \"is that wise\" and if the sense of the room is yes, ok, so be it

", "time": "2024-11-04T09:50:05Z"}, {"author": "David Lawrence", "text": "

It should be clarified which aspect is mixed. One potential model has been that an aliasing record points to another record that is not in the parent.

", "time": "2024-11-04T09:50:29Z"}, {"author": "David Lawrence", "text": "

(didn't see Ben's message as I was sending mine)

", "time": "2024-11-04T09:51:44Z"}, {"author": "Michael Richardson", "text": "

I don't understand the second model with the HINT. How do I know how to talk to the child until I've seen the DELEG?

", "time": "2024-11-04T09:53:11Z"}, {"author": "Michael Richardson", "text": "

The biggest block for new RRtypes is the various web interfaces to the DNS hosting platforms that are slow to learn about new RRtypes.

", "time": "2024-11-04T09:54:32Z"}, {"author": "George Michaelson", "text": "

fetching multiple discrete unknown-n things to assemble a blob and intuit its state feels like an opportunity to not complete. fetching one big blog which has sematic and syntactic cost is at least one fetch, and then compute.

", "time": "2024-11-04T09:57:22Z"}, {"author": "George Michaelson", "text": "

s/blog/blob/

", "time": "2024-11-04T09:57:35Z"}, {"author": "Peter van Dijk", "text": "

Came here to type the same, George!

", "time": "2024-11-04T09:57:50Z"}, {"author": "Erik Nygren", "text": "

The single blob also solves a range of change roll-out and synchronization issues that are highly relevant here. For the class of things we're looking to do we want to have a service-binding style model.

", "time": "2024-11-04T09:58:53Z"}, {"author": "Erik Nygren", "text": "

(ie, what dkg just said at the mic)

", "time": "2024-11-04T09:59:33Z"}, {"author": "Benjamin Schwartz", "text": "

I think the implication here is that the whole collection of \"DELEGish records\" would be returned in response to a single message of some kind. It seems to me that this design requires a lot of deep changes to the DNS message flow, without corresponding benefit.

", "time": "2024-11-04T10:01:13Z"}, {"author": "Ask Hansen", "text": "

The omnibus format could presumably be treated more like individual records if there are use cases for that by having multiple records each with their information. (Also agreed with what Daniel said, if you want to DELEG to DoT and DoQ each with various features specified that'd be two _sets_ of data; that seems unmanageable with individual records).

", "time": "2024-11-04T10:02:39Z"}, {"author": "Wes Hardaker", "text": "

multiple answers in additional section certainly can work -- but it requires multiple signatures and the packet will get really big

", "time": "2024-11-04T10:03:00Z"}, {"author": "Tim Wicinski", "text": "

\"Not solve this in the mic line\" What Universe did I wake up in this morning? (and thanks!)

", "time": "2024-11-04T10:03:36Z"}, {"author": "Wes Hardaker", "text": "

but that's how we solve things -- with many round trips at the mic line.

", "time": "2024-11-04T10:04:08Z"}, {"author": "Daniel Gillmor", "text": "

Petr's proposal of splitting into distinct records each with IDs that can be matched sounds like a nightmare, especially as you can imagine people updating records and then some resolver retrieving distinct records from before and after the change, you could have matching IDs cross-referencing each other accidentally. yikes

", "time": "2024-11-04T10:04:54Z"}, {"author": "Jens Finkh\u00e4user", "text": "

Wouldn't multiple RRTypes also duplicate information? Purely from an operational side, let's keep zones smaller IMHO

", "time": "2024-11-04T10:06:17Z"}, {"author": "Suzanne Woolf", "text": "

If any parameter can't be parsed, none can be parsed, or at least the logic gets complicated really fast. So no advantage to multiple RRs anyway? -> a single RR

", "time": "2024-11-04T10:06:50Z"}, {"author": "Wes Hardaker", "text": "

that was one of the [valid IMHO] points about translatting records -- multiple RRTYPEs traslated into a single can be a problem

", "time": "2024-11-04T10:07:09Z"}, {"author": "Suzanne Woolf", "text": "

(+1 to RayB)

", "time": "2024-11-04T10:07:11Z"}, {"author": "Christian Elmerot", "text": "

The multiple RRSIGs needed for distinct record types would be a major downside

", "time": "2024-11-04T10:07:27Z"}, {"author": "Shane Kerr", "text": "

Plus using 2 bytes for CLASS on each RR. :wink:

", "time": "2024-11-04T10:08:08Z"}, {"author": "Jens Finkh\u00e4user", "text": "

That as well, yes.

", "time": "2024-11-04T10:08:09Z"}, {"author": "Roy Arends", "text": "

Paul Wouters proposed a third solution. Shoehorn SVCB params into a new DS digest type.

", "time": "2024-11-04T10:13:02Z"}, {"author": "Erik Nygren", "text": "

Is there a link to the slides with Datatracker not working?

", "time": "2024-11-04T10:13:28Z"}, {"author": "Paul Hoffman", "text": "

Is there a draft for that?

", "time": "2024-11-04T10:13:29Z"}, {"author": "Daniel Gillmor", "text": "

why do we need to upgrade authoritatives? because they need to parse the zonefile with the DELEG indicator instead of reading it as a numeric class? or are we talking about needing to upgrade the gui interface or something?

", "time": "2024-11-04T10:13:34Z"}, {"author": "Roy Arends", "text": "

lemme check

", "time": "2024-11-04T10:13:45Z"}, {"author": "Daniel Gillmor", "text": "

Erik: https://datatracker.ietf.org/meeting/121/materials/slides-121-deleg-updates-slides-for-my-presentaton-how-deleg-and--deleg-00 worked for me

", "time": "2024-11-04T10:13:47Z"}, {"author": "Michael Richardson", "text": "

H7 vs S2. I think that when he says DNS operator, I don't think he means DNSSEC operator? Without a replacement for DS, I don't think we can have two operators signing with different keys?

", "time": "2024-11-04T10:14:57Z"}, {"author": "David Lawrence", "text": "

An authority with deleg at the zone cut would need to be updated to recognize it as parent side authoritative. Strictly speaking though you don't need to update all authorities for the zone in the absence of dnssec

", "time": "2024-11-04T10:15:16Z"}, {"author": "Willem Toorop", "text": "

@daniel, they need to return the DELEG in referral responses

", "time": "2024-11-04T10:15:46Z"}, {"author": "David Lawrence", "text": "

Michael, multivendor dnssec has recently been worked through dnsop

", "time": "2024-11-04T10:15:56Z"}, {"author": "Daniel Gillmor", "text": "

@Willem why is that not also true for _deleg?

", "time": "2024-11-04T10:16:15Z"}, {"author": "Andrew Campling", "text": "

@Erik Datatracker seems to be okay now

", "time": "2024-11-04T10:16:26Z"}, {"author": "Michael Richardson", "text": "

DELEG would be signed, while NS was not, so that's why it's stronger. Okay.

", "time": "2024-11-04T10:16:28Z"}, {"author": "Willem Toorop", "text": "

With _deleg, the SVCB can bee queried for. But DELEG cannot be queried for, because it is at the zonecut so a referral will be returned

", "time": "2024-11-04T10:16:45Z"}, {"author": "Tim Wicinski", "text": "

I do prefer having DELEG records not at the parent as the _deleg draft discusses.

", "time": "2024-11-04T10:16:51Z"}, {"author": "David Lawrence", "text": "

Because a receiver can query for _deleg explicitly

", "time": "2024-11-04T10:16:58Z"}, {"author": "Michael Richardson", "text": "

David Lawrence said:

\n
\n

Michael, multivendor dnssec has recently been worked through dnsop

\n
\n

Oh. I'll go look. I assume it requires validators to do something different?

", "time": "2024-11-04T10:17:09Z"}, {"author": "Joe Abley", "text": "

It doesn't, it requires signers to be coordinated

", "time": "2024-11-04T10:17:26Z"}, {"author": "Tim Wicinski", "text": "

Michael, David and Shumon have operational experience with multi-signer DNSSEC

", "time": "2024-11-04T10:18:01Z"}, {"author": "Tim Wicinski", "text": "

(among others)

", "time": "2024-11-04T10:18:09Z"}, {"author": "Tim Wicinski", "text": "

Phillip did a most excellent job walking through all those requiementsa

", "time": "2024-11-04T10:18:38Z"}, {"author": "Michael Richardson", "text": "

Tim Wicinski said:

\n
\n

Michael, David and Shumon have operational experience with multi-signer DNSSEC

\n
\n

draft-ietf-dnsop-dnssec-automation I think. Reading.

", "time": "2024-11-04T10:18:41Z"}, {"author": "Joe Abley", "text": "

When the .GOV zone moved from Verisign to Cloudflare a year or so ago we used multi-provider DNSSEC to allow the zone to move between providers without going unsigned and without transmitting private keys between providers

", "time": "2024-11-04T10:18:46Z"}, {"author": "Joe Abley", "text": "

so this is not just experimental, it has been used in anger, no truck role for validators required

", "time": "2024-11-04T10:19:10Z"}, {"author": "David Lawrence", "text": "

https://www.rfc-editor.org/rfc/rfc8901.html

", "time": "2024-11-04T10:19:11Z"}, {"author": "David Lawrence", "text": "

That RFC is \"Multi-Signer DNSSEC Models\"

", "time": "2024-11-04T10:19:49Z"}, {"author": "Shumon Huque", "text": "

Yup, RFC 8901 - Multi-Signer DNSSEC - Michael - happy to chat if you want to dig into that and operational experiences with it.

", "time": "2024-11-04T10:20:00Z"}, {"author": "Christian Elmerot", "text": "

TLDR< All providers need to carry each others ZSKs

", "time": "2024-11-04T10:20:06Z"}, {"author": "Joe Abley", "text": "

Christian did a nice DNS-OARC presentation that included some of the .GOV details, IIRC

", "time": "2024-11-04T10:20:33Z"}, {"author": "Daniel Gillmor", "text": "

we really should have a draft of Paul Wouter's DS pseudo-digest algorithm approach

", "time": "2024-11-04T10:21:39Z"}, {"author": "Benjamin Schwartz", "text": "

It would also be good to compare against the \"designated parent-side RR type number range\" proposal, which seemed popular.

", "time": "2024-11-04T10:22:27Z"}, {"author": "Roy Arends", "text": "

Paul has a draft, just not submitted to the datatracker I think

", "time": "2024-11-04T10:24:21Z"}, {"author": "Daniel Gillmor", "text": "

as long as we only choose one approach -- i don't want us to land in the classic IETF failure mode of \"we could let people do both\"

", "time": "2024-11-04T10:24:26Z"}, {"author": "Roy Arends", "text": "

I will ask him to submit

", "time": "2024-11-04T10:24:37Z"}, {"author": "Ralf Weber", "text": "

I think we discussed various drafts that wanted to put stuff into DS in dns-privacy and IMHO it is good that none of them became RFCs. We should not open that discussion again. DNS(SEC) already is hard enough to debug

", "time": "2024-11-04T10:24:56Z"}, {"author": "Peter van Dijk", "text": "

lol, Paul W hated it when I tried to stuff verbatim data in DSes ;)

", "time": "2024-11-04T10:25:21Z"}, {"author": "Peter van Dijk", "text": "

there are upsides to stuffing things in DS (no auth upgrades necessary) but I agree with Ralf - if we take a bit of pain now, we'll get a much cleaner result

", "time": "2024-11-04T10:25:53Z"}, {"author": "Roy Arends", "text": "

@ralf wouldn't placing alias DS functionality into DELEG records also make it more complex?

", "time": "2024-11-04T10:26:24Z"}, {"author": "Roy Arends", "text": "

fwiw, I really think it is a smart idea (from Peter van Dijk) to leave DNSSEC related info (such as DS Aliasing) in the DS record, via his verbatim-type proposal

", "time": "2024-11-04T10:28:16Z"}, {"author": "Ralf Weber", "text": "

Maybe, we haven't defined this yet. But that is optional

", "time": "2024-11-04T10:28:17Z"}, {"author": "Peter van Dijk", "text": "

please use https://datatracker.ietf.org/doc/draft-vandijk-dnsop-ds-digest-verbatim/ wisely or not at all ;)

", "time": "2024-11-04T10:30:21Z"}, {"author": "Tim Wicinski", "text": "

Big Fan of Petr's Table

", "time": "2024-11-04T10:31:54Z"}, {"author": "Erik Nygren", "text": "

That table makes me wonder how much harder _deleg is going to be to test and debug in the long-run if there are lots of corner-cases and flows there.

", "time": "2024-11-04T10:33:11Z"}, {"author": "Daniel Gillmor", "text": "

Erik++

", "time": "2024-11-04T10:33:22Z"}, {"author": "Michael Richardson", "text": "

David Lawrence said:

\n
\n

That RFC is \"Multi-Signer DNSSEC Models\"

\n
\n

Thanks. I thought this was still an unsolved problem, and one of the arguments for DELEG.

", "time": "2024-11-04T10:33:56Z"}, {"author": "Joe Abley", "text": "

The type option looks a lot cleaner, but I think the name option is a lot more deployable

", "time": "2024-11-04T10:34:19Z"}, {"author": "Roy Arends", "text": "

is _deleg signed? with a potential alias again?

", "time": "2024-11-04T10:34:28Z"}, {"author": "Shane Kerr", "text": "

After looking at this detailed analysis, I am now completely unsure what to do. :-D

", "time": "2024-11-04T10:34:30Z"}, {"author": "Joe Abley", "text": "

and if you look hard, it's not actually clear which is more clean

", "time": "2024-11-04T10:34:38Z"}, {"author": "Daniel Gillmor", "text": "

Shane: the goal is to be confused at a higher level than we were before

", "time": "2024-11-04T10:34:52Z"}, {"author": "Michael Richardson", "text": "

Joe Abley said:

\n
\n

and if you look hard, it's not actually clear which is more clean

\n
\n

Do we think that authoritative servers or resolvers are easier to upgrade. I think resolvers are a much longer tail for upgrades, while I think (due to excessive centralization), the number of authoritative resolvers is now fewer. <cynical smile>

", "time": "2024-11-04T10:36:49Z"}, {"author": "Willem Toorop", "text": "

@roy, Yes _deleg is signed (because it is conventional authoritative data)

", "time": "2024-11-04T10:37:06Z"}, {"author": "Andrew Campling", "text": "

Picking up on Michael\u2019s comment above, if multi-signer DNSSEC has a separate solution, is there still a high level of support for Deleg as well?

", "time": "2024-11-04T10:37:09Z"}, {"author": "Christian Elmerot", "text": "

Soft deploy mode, \"On failure fallback to legacy/NS\" ?

", "time": "2024-11-04T10:37:21Z"}, {"author": "Ralf Weber", "text": "

Resolvers are also fairly centralise between public and large ISP resolvers

", "time": "2024-11-04T10:37:23Z"}, {"author": "Willem Toorop", "text": "

@michael resolvers need to be upgraden for both proposals

", "time": "2024-11-04T10:37:26Z"}, {"author": "David Lawrence", "text": "

I don't understand your question, Andrew

", "time": "2024-11-04T10:38:09Z"}, {"author": "Michael Richardson", "text": "

Willem Toorop said:

\n
\n

@michael resolvers need to be upgraden for both proposals

\n
\n

It's true, but with type, we all have to wait for all the authoritative servers for a zone to upgrade before we can get ROI from updating our resolvers.

", "time": "2024-11-04T10:38:26Z"}, {"author": "Joe Abley", "text": "

we expect a long tail with any deployment. One question to ask is: if we imagine having to support the old and new system for the next twenty years, which of name/type is better?

", "time": "2024-11-04T10:38:34Z"}, {"author": "David Lawrence", "text": "
\n

It's true, but with type, we all have to wait for all the authoritative servers for a zone to upgrade before we can get ROI from updating our resolvers.

\n
\n

I don't think this is accurate, especially with the large number of unsigned zones out there.

", "time": "2024-11-04T10:39:09Z"}, {"author": "Daniel Gillmor", "text": "

Many zones only have one coordinated set of authoritatives. Those zones just need that set to be upgraded.

", "time": "2024-11-04T10:39:09Z"}, {"author": "Michael Richardson", "text": "

Daniel Gillmor said:

\n
\n

Many zones only have one coordinated set of authoritatives. Those zones just need that set to be upgraded.

\n
\n

Is that by design, or because of limitations in management abilities, and lack of multi-signer DNSSEC?

", "time": "2024-11-04T10:40:16Z"}, {"author": "Andrew Campling", "text": "

@Tale IIRC from the discussion in Charlotte, one of the major drivers for Deleg was multi-signer DNSSEC. My memory may of course be overstating this versus other benefits.

", "time": "2024-11-04T10:40:33Z"}, {"author": "Daniel Gillmor", "text": "

it is by design for a lot of zones, i think.

", "time": "2024-11-04T10:40:39Z"}, {"author": "Greg Choules", "text": "

How do either of these deal with ENTs?

", "time": "2024-11-04T10:40:52Z"}, {"author": "Jens Finkh\u00e4user", "text": "

@Michael: can be regulatory requirements, even :)

", "time": "2024-11-04T10:41:02Z"}, {"author": "Benjamin Schwartz", "text": "

Greg Choules said:

\n
\n

How do either of these deal with ENTs?

\n
\n

_deleg substantially relies on correct ENT handling

", "time": "2024-11-04T10:41:30Z"}, {"author": "Peter van Dijk", "text": "

a DNAME! no! lol!

", "time": "2024-11-04T10:41:46Z"}, {"author": "Joe Abley", "text": "

@michael: I think it's just commerical/operational reality. Most zones don't have multiple providers, regardless of whether DNSSEC is being used

", "time": "2024-11-04T10:41:51Z"}, {"author": "Manu Bretelle", "text": "

Christian Elmerot said:

\n
\n

Soft deploy mode, \"On failure fallback to legacy/NS\" ?

\n
\n

I am not sure if @Benjamin Schwartz meant deployment risk purely in sense of operational deployment, vs possible software bug. I suppose both are a potential issue, but even with the assumption that there is no bug in the recursor/authoritative server, there is still an operation risk.

", "time": "2024-11-04T10:41:59Z"}, {"author": "Shumon Huque", "text": "

@Andrew Campling - Multi-Signer DNSSEC works today. The discussions related to DELEG was how to make it easier to manage the deployment of multi-signer configurations and to be able to offload DS management to the multi providers with new protocol machinery.

", "time": "2024-11-04T10:42:24Z"}, {"author": "Daniel Gillmor", "text": "

the transcript thinks that this is the wrong Lars

", "time": "2024-11-04T10:42:28Z"}, {"author": "Kazunori Fujiwara", "text": "

How about implementing both the DELEG RR and _deleg and perform experiment?

", "time": "2024-11-04T10:43:01Z"}, {"author": "Brian Haberman", "text": "

@Daniel Maybe because I said \"Lars\" instead of \"Lars-Johan\"?

", "time": "2024-11-04T10:43:16Z"}, {"author": "Daniel Gillmor", "text": "

the transport said that it was Lars Eggert, but it was LArs-Johan Liman

", "time": "2024-11-04T10:43:23Z"}, {"author": "Manu Bretelle", "text": "

Christian Elmerot said:

\n
\n

Soft deploy mode, \"On failure fallback to legacy/NS\" ?

\n
\n

At DNS OARC in Charlotte, we had discussed the idea covered in https://www.ietf.org/archive/id/draft-manuben-svcb-testing-flag-00.html

", "time": "2024-11-04T10:43:53Z"}, {"author": "Michael Richardson", "text": "

Joe Abley said:

\n
\n

@michael: I think it's just commerical/operational reality. Most zones don't have multiple providers, regardless of whether DNSSEC is being used

\n
\n

Well, the historical small operational situation is that we swap being secondary for each other in a settlement-free way. (And these people, mostly, we, are likely early adopters...) But, you are right the majority of zones are hosted by servers operated by a registrar/hosting service.

", "time": "2024-11-04T10:43:54Z"}, {"author": "Joe Abley", "text": "

I agree that people exist who swap secondaries. But I disagree that that is the \"historical situation\". Is it an extremely rare corner case, I think, if you are counting by zone or traffic. I am not suggesting it's a bad idea, just that it's not common.

", "time": "2024-11-04T10:44:52Z"}, {"author": "Michael Richardson", "text": "

\"All your _deleg are belong to us\" :-)

", "time": "2024-11-04T10:45:54Z"}, {"author": "Tommy Jensen", "text": "

_ohhh_, the \"service accidentally lets customers register the _deleg label\" story hits hard

", "time": "2024-11-04T10:46:14Z"}, {"author": "Daniel Gillmor", "text": "

/me goes off to register _deleg in as many public suffixes as possible

", "time": "2024-11-04T10:46:51Z"}, {"author": "Joe Abley", "text": "

I don't know of a TLD registry that allows underscore names to be registered, but it's very true that we are talking about all zone cuts, not just zone cuts under TLD zones

", "time": "2024-11-04T10:46:54Z"}, {"author": "David Lawrence", "text": "
\n

@Tale IIRC from the discussion in Charlotte, one of the major drivers for Deleg was multi-signer DNSSEC. My memory may of course be overstating this versus other benefits.

\n
\n

The DNSSEc benefit was more about having operators being able to manage chain of trust on behalf of customers. But even that was one of only two immediate use cases that drove the desire for an updated delegation method.

", "time": "2024-11-04T10:47:15Z"}, {"author": "Benjamin Schwartz", "text": "

Re: activation danger, _deleg has the advantage of keeping the activation signal in the parent zone (\"_deleg exists\"), instead of the super-parent zone (DNSKEY flag -> requires a DS update). That means if it breaks something I can roll it back in minutes instead of hours to days.

", "time": "2024-11-04T10:47:40Z"}, {"author": "Joe Abley", "text": "

I am not sure I agree with Warren. I think the name approach might actually be superior in a couple of important ways, and not just an advantage for quick deployment.

", "time": "2024-11-04T10:48:22Z"}, {"author": "Shane Kerr", "text": "

I think Warren has it exactly backwards.

", "time": "2024-11-04T10:48:26Z"}, {"author": "Shane Kerr", "text": "

Yes, what Joe says. :-D

", "time": "2024-11-04T10:48:32Z"}, {"author": "Daniel Gillmor", "text": "

Shane, Joe, please explain why. Warren's perspective seems accurate to me.

", "time": "2024-11-04T10:48:50Z"}, {"author": "Peter van Dijk", "text": "

I am also curious :)

", "time": "2024-11-04T10:48:58Z"}, {"author": "Michael Richardson", "text": "

Joe Abley said:

\n
\n

I am not sure I agree with Warren. I think the name approach might actually be superior in a couple of important ways, and not just an advantage for quick deployment.

\n
\n

Please say more.

", "time": "2024-11-04T10:48:59Z"}, {"author": "Willem Toorop", "text": "

It's not just optimizing for quick deployment, it also maintaining DNS semantics w.r.t. who is authoritative for what data

", "time": "2024-11-04T10:49:07Z"}, {"author": "Shane Kerr", "text": "

I think it was a mistake to conflate child & parent namespaces by putting NS in the parent. Having a separate place to do delegation seems reasonable to me.

", "time": "2024-11-04T10:49:20Z"}, {"author": "Willem Toorop", "text": "

So in that sense more clean

", "time": "2024-11-04T10:49:26Z"}, {"author": "David Lawrence", "text": "

Like Warren at the mic right now, I agree that yes, name is nice for initial deployability, but that steady-state the RR @ cut is better on multiple levels. I also don't fully agree with Philip that if Paul had thought about it when he developed DNS that he would have used an approach like this.

", "time": "2024-11-04T10:49:27Z"}, {"author": "Peter van Dijk", "text": "

Shane, definitely agreed on the first half. I may have to unlearn some icks for the second half ;)

", "time": "2024-11-04T10:49:52Z"}, {"author": "David Lawrence", "text": "

I accept that name works but still strongly prefer type.

", "time": "2024-11-04T10:49:59Z"}, {"author": "Joe Abley", "text": "

We are too accustomed to the horrors of the same (QNAME, QTYPE, QCLASS) being answerable from both the parent and child zones, with attendant complexity when (e.g.) parent and child zones are hosted on the same server. Separating the information in the namespace avoids that complexity. This is an example.

", "time": "2024-11-04T10:50:02Z"}, {"author": "Michael Richardson", "text": "

Joe Abley said:

\n
\n

We are too accustomed to the horrors of the same (QNAME, QTYPE, QCLASS) being answerable from both the parent and child zones, with attendant complexity when (e.g.) parent and child zones are hosted on the same server. Separating the information in the namespace avoids that complexity. This is an example.

\n
\n

I think this is a really good argument.

", "time": "2024-11-04T10:50:35Z"}, {"author": "Shane Kerr", "text": "

Yeah I was actually opposed to _deleg until Petr's presentation. Now I have no idea!

", "time": "2024-11-04T10:50:40Z"}, {"author": "David Lawrence", "text": "

I also don't think we can casually toss aside what we're accustomed to. I'm not wed to it, but it isn't inconsequential.

", "time": "2024-11-04T10:51:42Z"}, {"author": "Michael Richardson", "text": "

While _deleg can't be a zone cut, can it be a separate file loaded into the authoritative server?

", "time": "2024-11-04T10:52:09Z"}, {"author": "Jim Reid", "text": "

\"Separating the information in the namespace avoids that complexity.\" and adds new complexity.

", "time": "2024-11-04T10:52:37Z"}, {"author": "Willem Toorop", "text": "

@michael Yes, I don't see why not

", "time": "2024-11-04T10:52:51Z"}, {"author": "Benjamin Schwartz", "text": "

Clearly we should solve this by moving DELEG into a new CLASS.

", "time": "2024-11-04T10:52:53Z"}, {"author": "Richard Wilhelm", "text": "

fwiw: a minor point that extra queries do matter (a bit) to authoritatives b/c they typically have SLAs on the DNS

", "time": "2024-11-04T10:53:08Z"}, {"author": "Joe Abley", "text": "

@michael, it has been a long time since I have worried about the implementation detail of \"zones\" being \"files\". I'm not sure that's relevant to the protocol.

", "time": "2024-11-04T10:53:16Z"}, {"author": "Shane Kerr", "text": "

I thought we had moved past DS-hacking. :smiling_face_with_tear:

", "time": "2024-11-04T10:53:29Z"}, {"author": "Joe Abley", "text": "

@jim agreed that all change comes with complexity

", "time": "2024-11-04T10:53:37Z"}, {"author": "David Lawrence", "text": "
\n

While _deleg can't be a zone cut, can it be a separate file loaded into the authoritative server?

\n
\n

Implementation detail; surewhynot. (Some of my objection to _deleg I've since softened on because I can dream up implementation ways to amelioerate them... but I still prefer DELEG RR.)

", "time": "2024-11-04T10:54:03Z"}, {"author": "Michael Richardson", "text": "

Joe Abley said:

\n
\n

@michael, it has been a long time since I have worried about the implementation detail of \"zones\" being \"files\". I'm not sure that's relevant to the protocol.

\n
\n

I'm thinking about locks on data structures, and multi-threading, so \"files\" was really just a metaphor for that.

", "time": "2024-11-04T10:54:16Z"}, {"author": "Peter van Dijk", "text": "

We will never move past DS-hacking (this is a prediction, not a threat)

", "time": "2024-11-04T10:54:17Z"}, {"author": "Jim Reid", "text": "

We're agreeing Joe? Surely not? :-)

", "time": "2024-11-04T10:54:25Z"}, {"author": "Joe Abley", "text": "

again, Jim!

", "time": "2024-11-04T10:54:36Z"}, {"author": "Joe Abley", "text": "

the last time was at a mic in a deleg room too, unless I am mistaken!

", "time": "2024-11-04T10:54:46Z"}, {"author": "Joe Abley", "text": "

maybe it was dnsop

", "time": "2024-11-04T10:55:01Z"}, {"author": "George Michaelson", "text": "

Wes makes a very good point because intermediaries are a fact of life

", "time": "2024-11-04T10:56:05Z"}, {"author": "George Michaelson", "text": "

operationally it helps to permit them

", "time": "2024-11-04T10:56:16Z"}, {"author": "Erik Nygren", "text": "

@Benjamin Schwartz : I also was wondering that \"put DELEG in its own Class\" question, but was afraid to mention it as it seemed like it might cause more trouble. But using Class to differentiate Parent-only records is vaguely intriguing.

", "time": "2024-11-04T10:56:31Z"}, {"author": "David Lawrence", "text": "

You can dump _deleg data right into the blob that you get when you internally look up the (regular) name by whatever means. Then just put it out with the _deleg label. There's a little inefficient around for having to be able to look up the _deleg and regular names explicitly, but I don't have much better than handwaving around the impact.

", "time": "2024-11-04T10:56:41Z"}, {"author": "Roy Arends", "text": "

Philip did say that _deleg as a delegation introduces new cyclical dependencies

", "time": "2024-11-04T10:56:45Z"}, {"author": "Roy Arends", "text": "

(infinite recursion was the quote I think)

", "time": "2024-11-04T10:57:07Z"}, {"author": "David Lawrence", "text": "

The DELEG CLASS suggestion was a running joke at the Prague Hackathon, one which I gleefully participated in but it never had any serious traction

", "time": "2024-11-04T10:57:16Z"}, {"author": "Willem Toorop", "text": "

@roy, but he suggested a _deleg DNAME instead, which could point to another zone

", "time": "2024-11-04T10:57:55Z"}, {"author": "Roy Arends", "text": "

non \"IN\" classes have no root defined.

", "time": "2024-11-04T10:58:02Z"}, {"author": "Roy Arends", "text": "

not the same tree

", "time": "2024-11-04T10:58:20Z"}, {"author": "Willem Toorop", "text": "

FYI we did have a student that implemented a PoC for _deleg, see: https://nlnetlabs.nl/downloads/publications/extensible-deleg-in-resolvers_2024-07-08.pdf

", "time": "2024-11-04T10:59:16Z"}, {"author": "Benjamin Schwartz", "text": "

Roy Arends said:

\n
\n

not the same tree

\n
\n

That's up to us when we define a new CLASS. But anyway, CLASS would require significantly larger changes than either of these proposals.

", "time": "2024-11-04T10:59:21Z"}, {"author": "Willem Toorop", "text": "

Costed him two weeks actually

", "time": "2024-11-04T10:59:36Z"}, {"author": "Roy Arends", "text": "

I agree with Petr: prioritize doing it right over doing it fast

", "time": "2024-11-04T10:59:41Z"}, {"author": "Greg Choules", "text": "

Right and fast are not necessarily mutually exclusive.

", "time": "2024-11-04T11:01:04Z"}, {"author": "Roy Arends", "text": "

@benjamin, nope. \"example.com\" in the IN class is not the same tree as \"example.com\" in the \"SOMETHING\" class.

", "time": "2024-11-04T11:01:06Z"}, {"author": "Michael Richardson", "text": "

so actually a Consensus Call.

", "time": "2024-11-04T11:01:40Z"}, {"author": "Roy Arends", "text": "

@greg, if right comes with fast, great.

", "time": "2024-11-04T11:01:44Z"}, {"author": "Paul Hoffman", "text": "

No need to think of _deleg as \"fast\": to me, it's \"easier to test\".

", "time": "2024-11-04T11:02:12Z"}, {"author": "Michael Richardson", "text": "

Good session. Thank you.

", "time": "2024-11-04T11:02:12Z"}, {"author": "Andrew Campling", "text": "

Worth a show of hands using Meetecho?

", "time": "2024-11-04T11:02:40Z"}, {"author": "Benjamin Schwartz", "text": "

Roy Arends said:

\n
\n

@benjamin, nope. \"example.com\" in the IN class is not the same tree as \"example.com\" in the \"SOMETHING\" class.

\n
\n

We are empowered to define the semantics of any hypothetical new CLASS. I'm not aware of any significant constraints on us. If we say \"this CLASS is an overlay for the IN class tree\", then that's what it means.

", "time": "2024-11-04T11:02:44Z"}, {"author": "Erik Nygren", "text": "

Do we want a non-binding hum on which directions people are leaning?

", "time": "2024-11-04T11:02:44Z"}, {"author": "\u00c9ric Vyncke", "text": "

I am really impressed by the DELEG progress... The BoF was IETF-119, and the state at IETF-121 is really good !

", "time": "2024-11-04T11:03:04Z"}, {"author": "Manu Bretelle", "text": "

Yeah, I think it would be great to get a feel more than a perception from ad-hoc discussions

", "time": "2024-11-04T11:03:20Z"}, {"author": "Roy Arends", "text": "

show of hands in meetecho would work

", "time": "2024-11-04T11:03:45Z"}, {"author": "Manu Bretelle", "text": "

show of hand to know if we want a show of hand....

", "time": "2024-11-04T11:03:59Z"}, {"author": "Warren Kumari", "text": "

Is Petr asking for a hum / show of hands?

", "time": "2024-11-04T11:04:03Z"}, {"author": "Shane Kerr", "text": "

I don't think anyone could accuse DELEG of moving too fast to discussing protocols!

", "time": "2024-11-04T11:04:26Z"}, {"author": "David Lawrence", "text": "

I think he was asking for more feedback about how individuals feel

", "time": "2024-11-04T11:04:36Z"}, {"author": "David Lawrence", "text": "

DELEG slowed way down from where we were a year ago :)

", "time": "2024-11-04T11:04:58Z"}, {"author": "Brian Haberman", "text": "

My understanding is that there is another proposal that hasn't been submitted.

", "time": "2024-11-04T11:05:22Z"}, {"author": "Michael Richardson", "text": "

I think Paul is going to write this document :-)

", "time": "2024-11-04T11:05:49Z"}, {"author": "David Lawrence", "text": "

Just try and stop him!

", "time": "2024-11-04T11:05:58Z"}, {"author": "Joe Abley", "text": "

I think getting a sense from the room is perfectly fine, based on the information people have right now and the people who are in the room right now

", "time": "2024-11-04T11:06:03Z"}, {"author": "Benjamin Schwartz", "text": "

The DELEG vs. _deleg slides are very clear and a sufficient basis for a mailing list discussion.

", "time": "2024-11-04T11:06:10Z"}, {"author": "Daniel Gillmor", "text": "

Show of hands for DELEG v _deleg would be good.

", "time": "2024-11-04T11:06:34Z"}, {"author": "Joe Abley", "text": "

of course I don't actually know how to do a show of hands in meetecho

", "time": "2024-11-04T11:06:54Z"}, {"author": "Michael Richardson", "text": "

Why not ask, \"Based upon the presentation, do you now feel you can decide?\"

", "time": "2024-11-04T11:07:07Z"}, {"author": "Manu Bretelle", "text": "

:hand: for a show of hands

", "time": "2024-11-04T11:07:08Z"}, {"author": "Michael Richardson", "text": "

Michael Richardson said:

\n
\n

Why not ask, \"Based upon the presentation, do you now feel you can decide?\"

\n
\n

(without actually asking which one you prefer)

", "time": "2024-11-04T11:07:28Z"}, {"author": "Christian Elmerot", "text": "

A show of hands would be an indication how we feel/think based on todays presentations, not a defniitive decision

", "time": "2024-11-04T11:07:38Z"}, {"author": "Joe Abley", "text": "

I don't think we are asking for a decision, @michael, I think we are asking for a sense of current preference understanding that decisions come later

", "time": "2024-11-04T11:07:41Z"}, {"author": "Vicky Risk", "text": "

it would be helpful to publish the slides - the tables are very useful.

", "time": "2024-11-04T11:07:57Z"}, {"author": "Pete Resnick", "text": "

@Joe Abley If you're in Meetecho, you'll see a prompt for the survey. It's got a little \"bar graph\" looking icon.

", "time": "2024-11-04T11:08:00Z"}, {"author": "Greg Choules", "text": "

How do we see the slide decks? I'm not getting them in meetecho.

", "time": "2024-11-04T11:08:07Z"}, {"author": "Joe Abley", "text": "

thanks pete

", "time": "2024-11-04T11:08:09Z"}, {"author": "Andrew Campling", "text": "

Show of hands is definitely non-binding

", "time": "2024-11-04T11:08:17Z"}, {"author": "Michael Richardson", "text": "

Joe Abley said:

\n
\n

I don't think we are asking for a decision, @michael, I think we are asking for a sense of current preference understanding that decisions come later

\n
\n

I didn't suggest we decide, but rather, do you feel that you understand the solution space.

", "time": "2024-11-04T11:08:18Z"}, {"author": "Daniel Gillmor", "text": "

Vicky, the slides are at https://datatracker.ietf.org/meeting/121/materials/slides-121-deleg-comparison-draft-wesplaap-deleg-01-vs-draft-homburg-deleg-incremental-deleg-00-00

", "time": "2024-11-04T11:08:30Z"}, {"author": "Vicky Risk", "text": "

@dkg TY

", "time": "2024-11-04T11:08:58Z"}, {"author": "Erik Nygren", "text": "

Full list should also be here: https://datatracker.ietf.org/meeting/121/session/deleg/

", "time": "2024-11-04T11:09:04Z"}, {"author": "Peter van Dijk", "text": "

I still like the range idea - we can revive https://www.ietf.org/archive/id/draft-peetterr-dnsop-parent-side-auth-types-00.html

", "time": "2024-11-04T11:10:01Z"}, {"author": "Daniel Gillmor", "text": "

i don't know the difference between \"no opinion\" and \"no\" here :P

", "time": "2024-11-04T11:10:45Z"}, {"author": "David Lawrence", "text": "

Pollsters would be envious of our response rate

", "time": "2024-11-04T11:11:05Z"}, {"author": "David Lawrence", "text": "

70%!

", "time": "2024-11-04T11:11:13Z"}, {"author": "Pete Resnick", "text": "

Still a significant number of people who need more info.

", "time": "2024-11-04T11:11:17Z"}, {"author": "Michael Richardson", "text": "

Daniel Gillmor said:

\n
\n

i don't know the difference between \"no opinion\" and \"no\" here :P

\n
\n

No opinion means that no amount of additional discussion would let you decide.

", "time": "2024-11-04T11:11:22Z"}, {"author": "Andrew Campling", "text": "

Useful to ask a second question, DELEG, _deleg or no opinion / preference?

", "time": "2024-11-04T11:11:41Z"}, {"author": "David Lawrence", "text": "

102 people could respond. 72 responded.

", "time": "2024-11-04T11:11:57Z"}, {"author": "Peter van Dijk", "text": "

Andrew, that feels too early to me

", "time": "2024-11-04T11:12:01Z"}, {"author": "Daniel Gillmor", "text": "

I agree with Andrew Campling

", "time": "2024-11-04T11:12:03Z"}, {"author": "Peter Thomassen", "text": "

I can see poll results but could not vote -- why? (me being stupid?)

", "time": "2024-11-04T11:12:06Z"}, {"author": "Samuel Weiler", "text": "

math is hard

", "time": "2024-11-04T11:12:15Z"}, {"author": "David Lawrence", "text": "

Warren just said how well nice we work together, Peter. We're certainly not about to call you stupid!

", "time": "2024-11-04T11:12:32Z"}, {"author": "Shane Kerr", "text": "

Only 44 of 102 think they have an opinion, I'm not sure it makes sense to ask what it is. :-D

", "time": "2024-11-04T11:12:37Z"}, {"author": "Tommy Jensen", "text": "

so is UI design

", "time": "2024-11-04T11:12:40Z"}, {"author": "Manu Bretelle", "text": "

Andrew Campling said:

\n
\n

Useful to ask a second question, DELEG, _deleg or no opinion / preference?

\n
\n

yeah, agreed. This is non-binding, but it would help getting a sense of what people think. Now we are wondering what people think.

", "time": "2024-11-04T11:12:41Z"}, {"author": "Andrew Campling", "text": "

+1 to dkg

", "time": "2024-11-04T11:12:52Z"}, {"author": "Erik Nygren", "text": "

+1 to dkg

", "time": "2024-11-04T11:13:16Z"}, {"author": "Samuel Weiler", "text": "

we better not see more than 44 votes on this next question...

", "time": "2024-11-04T11:14:05Z"}, {"author": "\u00c9ric Vyncke", "text": "

IETF engineering at its best: discussion about the question

", "time": "2024-11-04T11:14:21Z"}, {"author": "Peter van Dijk", "text": "

Samuel Weiler said:

\n
\n

we better not see more than 44 votes on this next question...

\n
\n

I think some people missed the window on the other one :)

", "time": "2024-11-04T11:14:27Z"}, {"author": "David Lawrence", "text": "

I want two of three outcomes, either my preferred one or split. I pre-reject the outcome of everyone being for the one I don't favor. /s

", "time": "2024-11-04T11:14:53Z"}, {"author": "Daniel Gillmor", "text": "

it's more than 44, Sam!

", "time": "2024-11-04T11:14:59Z"}, {"author": "Andrew Campling", "text": "

Could we also do US presidential vote \u2026 :smile:

", "time": "2024-11-04T11:15:50Z"}, {"author": "David Lawrence", "text": "

We're up to 105 possible respondents. How very interesting.

", "time": "2024-11-04T11:15:56Z"}, {"author": "Shane Kerr", "text": "

Is this why we're not supposed to have voting in the IETF? :stuck_out_tongue_wink:

", "time": "2024-11-04T11:15:56Z"}, {"author": "David Lawrence", "text": "

I've been hard avoiding external references :)

", "time": "2024-11-04T11:16:11Z"}, {"author": "Manu Bretelle", "text": "

in case someone is waiting for verbal signal that the new question is up.... the new question is up.

", "time": "2024-11-04T11:16:46Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Well we could hum the old way, but then remote participants would be in rough spot.

", "time": "2024-11-04T11:16:51Z"}, {"author": "Daniel Gillmor", "text": "

This is non-binding, but it does show that there is a lean to the group of participants at the moment. If i was responsible for implementing something, i'd start with the thing we're leaning toward to see if it made sense.

", "time": "2024-11-04T11:17:10Z"}, {"author": "Andrew Campling", "text": "

Humming in this size room would be challenging

", "time": "2024-11-04T11:17:25Z"}, {"author": "Manu Bretelle", "text": "

the good news is that the results of each individual polls are not in contradiction.

", "time": "2024-11-04T11:18:14Z"}, {"author": "Tommy Jensen", "text": "

@Manu agreed, I'm glad my concern was unwarranted.

", "time": "2024-11-04T11:18:51Z"}, {"author": "Ask Hansen", "text": "

Screenshot-2024-11-04-at-11.19.05.png

\n
", "time": "2024-11-04T11:19:14Z"}, {"author": "Tim Wicinski", "text": "

Write up the results in the minutes

", "time": "2024-11-04T11:19:14Z"}, {"author": "Mark Andrews", "text": "

Based on the presentations today, do you feel you could choose between DELEG (type) and _deleg (name) approaches?
\nTOTAL PARTICIPANTS
\n: 102
\nyes
\n44
\nno
\n17
\nno opinion
\n11
\nDo have a preference for the _deleg (name) approach?
\nTOTAL PARTICIPANTS
\n: 105
\nyes
\n15
\nno
\n44
\nno opinion
\n14
\nDo you have a preference for the DELEG (type) approach?
\nTOTAL PARTICIPANTS
\n: 105
\nyes
\n42
\nno
\n13
\nno opinion
\n13

", "time": "2024-11-04T11:19:26Z"}, {"author": "Joe Abley", "text": "

we have enough scary voting happening this week, I'm fine with not calling this a vote

", "time": "2024-11-04T11:19:30Z"}, {"author": "Michael Richardson", "text": "

I preferred type, but Paul convinced me that testing name would be easier.

", "time": "2024-11-04T11:19:38Z"}, {"author": "Tommy Jensen", "text": "

@Tim: way ahead of you :)

", "time": "2024-11-04T11:19:43Z"}, {"author": "Daniel Gillmor", "text": "

the transcript just called Brian Haberman \"Brian Trammell\"

", "time": "2024-11-04T11:20:01Z"}, {"author": "David Lawrence", "text": "

I'm grateful for the work that Philip (and WIllem et al) have done. I think it was valuable and still worthy of ongoing discussion. It's clearly a workable solution and has improved the deliberations of the WG.

", "time": "2024-11-04T11:20:15Z"}, {"author": "Michael Richardson", "text": "

Thou Art Brian.

", "time": "2024-11-04T11:20:19Z"}, {"author": "Benjamin Schwartz", "text": "

Michael Richardson said:

\n
\n

I preferred type, but Paul convinced me that testing name would be easier.

\n
\n

My intuition is that the compatibility matrix testing is not very different between them. DELEG has fewer modes, but _deleg doesn't involve the super-parent.

", "time": "2024-11-04T11:21:05Z"}, {"author": "Jim Reid", "text": "

What's with all this voting? Have we become the ITU?

", "time": "2024-11-04T11:21:10Z"}, {"author": "Tim Wicinski", "text": "

I agreee with Dave - Phillip/.Petr/Willem have done great stuff

", "time": "2024-11-04T11:21:18Z"}, {"author": "Joe Abley", "text": "

it's not voting, Jim!

", "time": "2024-11-04T11:21:31Z"}, {"author": "Daniel Gillmor", "text": "

it's not a vote, geez

", "time": "2024-11-04T11:21:33Z"}, {"author": "David Lawrence", "text": "

The transcript also called Paul Hoffman as Tim Wicinski for his first presentation. Which I thought was just that it lost a participation tracking token somewhere but now I wonder how Brian Trammel showed up at all

", "time": "2024-11-04T11:21:55Z"}, {"author": "Roy Arends", "text": "

it is a hand excersize

", "time": "2024-11-04T11:22:01Z"}, {"author": "Joe Abley", "text": "

there, back to disagreeing with Jim, I have an enhanced sense of personal calm

", "time": "2024-11-04T11:22:05Z"}, {"author": "Tommy Jensen", "text": "

This is said GitHub location: https://github.com/ietf-wg-deleg

", "time": "2024-11-04T11:22:14Z"}, {"author": "Joe Abley", "text": "

:wave:

", "time": "2024-11-04T11:22:41Z"}, {"author": "Lorenzo Miniero", "text": "

Transcription is not automated in this session, there's a human transcriber

", "time": "2024-11-04T11:22:48Z"}, {"author": "Willem Toorop", "text": "

:wave:

", "time": "2024-11-04T11:22:59Z"}, {"author": "Brian Haberman", "text": "

@Lorenzo A human transcriber confused me with Brian T.?

", "time": "2024-11-04T11:23:17Z"}, {"author": "Tommy Jensen", "text": "

https://notes.ietf.org/s/notes-ietf-121-deleg

", "time": "2024-11-04T11:23:38Z"}]