[{"author": "Warren Kumari", "text": "

This one hides Enter where I expect Space to be, so... \u00af\\_(\u30c4)_/\u00af

", "time": "2024-01-30T17:00:34Z"}, {"author": "Suzanne Woolf", "text": "

Warren I don't know anyone else who could make such an adventure out of a keyboard!

", "time": "2024-01-30T17:02:49Z"}, {"author": "Warren Kumari", "text": "

Yup, this was unusual, but there was clear interest in the work, so it seemed like a fine idea...

", "time": "2024-01-30T17:03:36Z"}, {"author": "Warren Kumari", "text": "

@Suz: Yah. It's not possible that I just suck at typing, so CLEARLY it must just be that I have not tried the right keyboard yet....

", "time": "2024-01-30T17:05:14Z"}, {"author": "Suzanne Woolf", "text": "

It's all part of the process Warren :-)

", "time": "2024-01-30T17:05:14Z"}, {"author": "Shumon Huque", "text": "

Roy will I think

", "time": "2024-01-30T17:05:16Z"}, {"author": "Shumon Huque", "text": "

On compliance testing results i.e.

", "time": "2024-01-30T17:05:41Z"}, {"author": "Tim Wicinski", "text": "

with the typo

", "time": "2024-01-30T17:07:12Z"}, {"author": "David Lawrence", "text": "

I am curious about the keyboard...

", "time": "2024-01-30T17:07:18Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

We can see the typo on the title slide :-)

", "time": "2024-01-30T17:07:24Z"}, {"author": "Samuel Weiler", "text": "

another typo: IETF118, not 108

", "time": "2024-01-30T17:11:41Z"}, {"author": "Benjamin Schwartz", "text": "

Typo: the last record should be \"IN SVCB 1 ...\"

", "time": "2024-01-30T17:13:58Z"}, {"author": "Paul Wouters", "text": "

note there is an additional query to follow the indirection

", "time": "2024-01-30T17:14:30Z"}, {"author": "Tim Wicinski", "text": "

We should make sure we note the followup query more explicitly

", "time": "2024-01-30T17:15:11Z"}, {"author": "David Lawrence", "text": "

Yes, in the cases where indirection is used. It need not be used.

", "time": "2024-01-30T17:15:20Z"}, {"author": "Vladim\u00edr \u010cun\u00e1t", "text": "

NS in a different zone is a similar indirection already.

", "time": "2024-01-30T17:15:39Z"}, {"author": "Paul Wouters", "text": "

yes but this adds a layer, lookup the target SVCB, read the config, pull the name, lookup the name

", "time": "2024-01-30T17:16:14Z"}, {"author": "Peter Thomassen", "text": "

not if you use the IP hints in the SVCB record

", "time": "2024-01-30T17:16:31Z"}, {"author": "Paul Wouters", "text": "

oh that's true. yes

", "time": "2024-01-30T17:16:56Z"}, {"author": "Peter Thomassen", "text": "

it's in fact quite neat the not extra queries are needed if done correctly (and you can save one when not using the indirection!)

", "time": "2024-01-30T17:17:20Z"}, {"author": "Peter Thomassen", "text": "

*neat that no extra.. (sry, Warren gave me the keyboard)

", "time": "2024-01-30T17:17:55Z"}, {"author": "Tim Wicinski", "text": "

and if done incorrectly ?

", "time": "2024-01-30T17:17:57Z"}, {"author": "Peter Thomassen", "text": "

incorrectly: you can still look up NS names even if you have IP hints available

", "time": "2024-01-30T17:18:21Z"}, {"author": "Tim Wicinski", "text": "

I was thinking of lookup steps if done wrong

", "time": "2024-01-30T17:18:56Z"}, {"author": "Peter Thomassen", "text": "

I meant: if you already have the DELEG with e.g., ipv4hint and you still do an A query for a nameserver hostname, that's a (legacy-style) lookup step that you can save.

", "time": "2024-01-30T17:19:41Z"}, {"author": "Benjamin Schwartz", "text": "

To be clear, the hints are only applicable to the iterative resolution process. They are never converted to AAAA records.

", "time": "2024-01-30T17:20:25Z"}, {"author": "Peter Thomassen", "text": "

yes.

", "time": "2024-01-30T17:20:39Z"}, {"author": "Tim Wicinski", "text": "

but if I have a DELEG record with a bunk ipv4hint, it falls back to NS

", "time": "2024-01-30T17:20:49Z"}, {"author": "Benjamin Schwartz", "text": "

@Tim Wicinski First it falls back to other DELEG records. Fall back to NS has some ... interesting security concerns.

", "time": "2024-01-30T17:21:29Z"}, {"author": "Tim Wicinski", "text": "

Just thinking of some worst case issues.

", "time": "2024-01-30T17:21:54Z"}, {"author": "Tim Wicinski", "text": "

I can easily see a test site to run variations against like Wes's broken-dnssec site

", "time": "2024-01-30T17:23:07Z"}, {"author": "Paul Wouters", "text": "

years ago I tested unknown DNSKEY flags when proposing DELEGATION_ONLY. all resolvers at the time worked fine (did not test systemd-resolved for obvious reaons :)

", "time": "2024-01-30T17:23:53Z"}, {"author": "Manu Bretelle", "text": "

I think this is more of a policy issue. During initial rollout, an admin may want to be more conservative and fallback to NS, but long term, you may not want to fallback.

\n

For one, DELEG may provided encrypted only resolver, falling back to NS would possibly downgrade your link to unencrypted.

", "time": "2024-01-30T17:23:56Z"}, {"author": "Tim Wicinski", "text": "

Almost like those fine regexp sites

", "time": "2024-01-30T17:23:59Z"}, {"author": "Samuel Weiler", "text": "

why use a DNSKEY flag as signal? That means the flag would come from the child zone (in the DNSKEY). When we presumably want that signal to come, signed, from the parent zone?

", "time": "2024-01-30T17:24:51Z"}, {"author": "Peter Thomassen", "text": "

Manu: that could be addressed by the presence of the signal (DNSKEY flag / DS record). As long as you don't put that, you can fall back to NS, but you also don't have downgrade resistance.

", "time": "2024-01-30T17:24:51Z"}, {"author": "Peter Thomassen", "text": "

Sam: the delegating zone.

", "time": "2024-01-30T17:25:02Z"}, {"author": "Paul Wouters", "text": "

sam: the sign ideally comes from the DNS hoster

", "time": "2024-01-30T17:25:19Z"}, {"author": "David Lawrence", "text": "

Right, NS fallback is a policy choice. The main technical thing to specify is not to mix information from DELEG and NS/DS/glue.

", "time": "2024-01-30T17:25:31Z"}, {"author": "Joe Abley", "text": "

sam: the dnskey flag informs a resolver about what kind of referral response to expect from that zone

", "time": "2024-01-30T17:25:32Z"}, {"author": "Peter Thomassen", "text": "

(the parent signals that it will send DELEG or DoE for all delegatoins)

", "time": "2024-01-30T17:25:42Z"}, {"author": "Samuel Weiler", "text": "

joe/peter: thank you.

", "time": "2024-01-30T17:25:52Z"}, {"author": "Joe Abley", "text": "

it's a defence against a mitm stripping the deleg

", "time": "2024-01-30T17:25:56Z"}, {"author": "Samuel Weiler", "text": "

so this is a signal from a (parent) zone about itself.

", "time": "2024-01-30T17:26:24Z"}, {"author": "Joe Abley", "text": "

yrd

", "time": "2024-01-30T17:26:29Z"}, {"author": "Joe Abley", "text": "

sorry, warren keyboard

", "time": "2024-01-30T17:26:34Z"}, {"author": "Joe Abley", "text": "

yes

", "time": "2024-01-30T17:26:35Z"}, {"author": "Paul Wouters", "text": "

not entirely? It is the child that commits to its hoster doing DELEG and putting that signal in the parent. but it is signed by the parent.

", "time": "2024-01-30T17:27:01Z"}, {"author": "Warren Kumari", "text": "

@Roy: Thank you for this testing; this looks like lots of work, and really helpful...

", "time": "2024-01-30T17:27:19Z"}, {"author": "Joe Abley", "text": "

paul: how?

", "time": "2024-01-30T17:27:50Z"}, {"author": "Paul Wouters", "text": "

joe: good question.

", "time": "2024-01-30T17:28:02Z"}, {"author": "Tim Wicinski", "text": "

but I like where paul is thinking about a child wanting to make a commit upstream

", "time": "2024-01-30T17:28:25Z"}, {"author": "Joe Abley", "text": "

these conversations get difficult when you introduce concepts like hoster and registrar, etc and stir them in to a pot of dns

", "time": "2024-01-30T17:28:40Z"}, {"author": "Joe Abley", "text": "

need a diagram

", "time": "2024-01-30T17:28:47Z"}, {"author": "Samuel Weiler", "text": "

+1 to diagram.

", "time": "2024-01-30T17:28:56Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

That's misunderstanding. DNSKEY flag tells resolver about what to expect in delegations from that single zone.

", "time": "2024-01-30T17:29:00Z"}, {"author": "Suzanne Woolf", "text": "

while registry op tries to stay out of the way...

", "time": "2024-01-30T17:29:11Z"}, {"author": "Samuel Weiler", "text": "

also, roy++ for this testing.

", "time": "2024-01-30T17:29:12Z"}, {"author": "Paul Wouters", "text": "

petr: ideally there are two. one from child and one from parent

", "time": "2024-01-30T17:29:31Z"}, {"author": "Vladim\u00edr \u010cun\u00e1t", "text": "

Basically it promises that the auth serving the zone implements DELEG (in referrals).

", "time": "2024-01-30T17:29:38Z"}, {"author": "Tim Wicinski", "text": "
", "time": "2024-01-30T17:29:39Z"}, {"author": "David Lawrence", "text": "

Reconfirming it works is good!

", "time": "2024-01-30T17:29:43Z"}, {"author": "Joe Abley", "text": "

by the way the correct order is 1.1.1.1 before 8.8.8.8 just saying

", "time": "2024-01-30T17:30:16Z"}, {"author": "Tim Wicinski", "text": "

Shumon if you need ripe credits let me know I have lots

", "time": "2024-01-30T17:30:23Z"}, {"author": "Shumon Huque", "text": "

Will let you know Tim. I think I only have a couple hundred million credits left! :)

", "time": "2024-01-30T17:31:00Z"}, {"author": "Tim Wicinski", "text": "

You know where to find me sir

", "time": "2024-01-30T17:31:45Z"}, {"author": "Warren Kumari", "text": "

@Joe: only because you will still be waiting for the answer ..

", "time": "2024-01-30T17:31:49Z"}, {"author": "Tim Wicinski", "text": "

+1 to Windows Server DNS Resolver

", "time": "2024-01-30T17:32:23Z"}, {"author": "Joe Abley", "text": "

warren: haha

", "time": "2024-01-30T17:32:51Z"}, {"author": "Shumon Huque", "text": "

Yes (to MS and other resolvers). AWS Route53 Resolver would be a good test case. I've done some preliminary tests without noticing any issues.

", "time": "2024-01-30T17:32:55Z"}, {"author": "Joe Abley", "text": "

I think it's clear that the draft is an early -00

", "time": "2024-01-30T17:33:05Z"}, {"author": "Warren Kumari", "text": "

:-)

", "time": "2024-01-30T17:33:15Z"}, {"author": "Joe Abley", "text": "

happy to help with editing!

", "time": "2024-01-30T17:33:27Z"}, {"author": "David Lawrence", "text": "

More specific feedback about what you found unclear or needed reorganization would be welcome.

", "time": "2024-01-30T17:33:57Z"}, {"author": "John Dickinson", "text": "

What is the relation between DELEG and RFC9461

", "time": "2024-01-30T17:35:56Z"}, {"author": "Tim Wicinski", "text": "

I agree with working on the motivations and ideas etc but I feel confident the authors will work on that

", "time": "2024-01-30T17:36:02Z"}, {"author": "Benjamin Schwartz", "text": "

John Dickinson said:

\n
\n

What is the relation between DELEG and RFC9461

\n
\n

TBD, but they're clearly closely connected. Personally, my goal is to align them to the greatest extent we can.

", "time": "2024-01-30T17:36:33Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

To that I will add: If possible. But SVCB should not limit what DELEG can do just because SVCB already exists.

", "time": "2024-01-30T17:37:23Z"}, {"author": "Suzanne Woolf", "text": "

General discussion after Paul speaks, thanks

", "time": "2024-01-30T17:37:34Z"}, {"author": "Shumon Huque", "text": "

\"enthousiast\" is the canadian/dutch spelling ..

", "time": "2024-01-30T17:37:37Z"}, {"author": "Andrew Campling", "text": "

.. via Warren's keyboard presumably? :grinning:

", "time": "2024-01-30T17:38:26Z"}, {"author": "Tim Wicinski", "text": "

Agree with Ben and Petr. But it's good to explain the differences., I can send an issue

", "time": "2024-01-30T17:38:28Z"}, {"author": "Joe Abley", "text": "

it's possible to imagine exactly the current metadata being used to publish DELEG records in the parent, if the TLD operator's contracts, etc allowed it

", "time": "2024-01-30T17:39:22Z"}, {"author": "Warren Kumari", "text": "

If it was from Warren's keyboard is would be \"enttthusiaesrstswst\"

", "time": "2024-01-30T17:39:44Z"}, {"author": "Tim Wicinski", "text": "

I had some suggestions on the dns records in the draft, and of course I would push to not use 86400 as a TTL

", "time": "2024-01-30T17:39:52Z"}, {"author": "Joe Abley", "text": "

it seems possible that DELEG is incrementally deployable without provisioning changes

", "time": "2024-01-30T17:39:56Z"}, {"author": "Tim Wicinski", "text": "

Joe - yes, I was thinking of how to deploy as subdomains and SLDs without touching those messy TLDs and Registrars

", "time": "2024-01-30T17:40:37Z"}, {"author": "Benjamin Schwartz", "text": "

It's not clear to me that DELEG is even visible to stub resolvers at all, so there may not be any ossification risk there.

", "time": "2024-01-30T17:40:38Z"}, {"author": "Joe Abley", "text": "

right, referral responses are only normally received by and useful for resolvers

", "time": "2024-01-30T17:41:07Z"}, {"author": "Benjamin Schwartz", "text": "

Failover on NXDOMAIN seems expressible to me.

", "time": "2024-01-30T17:42:10Z"}, {"author": "Benjamin Schwartz", "text": "

Protecting nameserver names is not a top priority. In DELEG's current model, I expect it would normally be revealed in the TLS SNI. (ECH might be possible but has not been investigated in detail...)

", "time": "2024-01-30T17:44:31Z"}, {"author": "Stephen Farrell", "text": "

if you can do DoH/DoT you can do ECH with that

", "time": "2024-01-30T17:45:08Z"}, {"author": "Benjamin Schwartz", "text": "

@Stephen Farrell I expect so. Operationally, it may be tricky to publish ECHConfigs in the parent, for example.

", "time": "2024-01-30T17:45:49Z"}, {"author": "Stephen Farrell", "text": "

sure, figuring out such should be solveable, but is not yet solved

", "time": "2024-01-30T17:46:18Z"}, {"author": "Vladim\u00edr \u010cun\u00e1t", "text": "

That's what the alias-form DELEG is for. (reacting to presentation)

", "time": "2024-01-30T17:46:37Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Yeah, I have a feeling that this is already addressed.

", "time": "2024-01-30T17:47:18Z"}, {"author": "Peter Thomassen", "text": "

also, on the previous slide, there was an implication that DoT attempts + fails might cause similar extra overhead as during DELEG introduction. But I think DELEG introduciton does not cause extra queries.

", "time": "2024-01-30T17:48:04Z"}, {"author": "Philip Homburg", "text": "

given the state of unilateral probing, i wonder if just DoT would actually be faster

", "time": "2024-01-30T17:48:56Z"}, {"author": "Benjamin Schwartz", "text": "

Technically, DELEG-0 records point to SVCB records, not more DELEG, but that's a detail.

", "time": "2024-01-30T17:48:58Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Random Joe Registrant will just use alias mode. It's even simpler to enter than full NS RRs today.

", "time": "2024-01-30T17:50:28Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

(As in, 1 name for alias mode instead of full set of NS names.)

", "time": "2024-01-30T17:50:46Z"}, {"author": "Joe Abley", "text": "

random joe registrant uses nameservers and dns config provided by his registrar and doesn't know what any of these things are

", "time": "2024-01-30T17:50:57Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Or that, yeah :-)

", "time": "2024-01-30T17:51:20Z"}, {"author": "Stephen Farrell", "text": "

goto paul's proposal#4 :-)

", "time": "2024-01-30T17:52:08Z"}, {"author": "Tim Wicinski", "text": "

and meetecho doesn't allow much running over

", "time": "2024-01-30T17:52:30Z"}, {"author": "Warren Kumari", "text": "

+1 to this...

", "time": "2024-01-30T17:52:49Z"}, {"author": "Benjamin Schwartz", "text": "

I don't understand this idea. \"Resolve at parent\" only matters if you're trying to pass the DELEG record back to a stub resolver, but that's not what DELEG is for.

", "time": "2024-01-30T17:53:19Z"}, {"author": "Stephen Farrell", "text": "

overall deleg seems worth exploring, most cringy thing for me is duplication of addresses in hints and a/aaaa

", "time": "2024-01-30T17:53:23Z"}, {"author": "Warren Kumari", "text": "

I like the IANA range ides...

", "time": "2024-01-30T17:53:28Z"}, {"author": "Joe Abley", "text": "

stephen, I have also been cringing at the data duplication since it seems filled with inevitable fail

", "time": "2024-01-30T17:53:54Z"}, {"author": "Manu Bretelle", "text": "

+1 that may be useful in the future vs hardcoding what RRTYPE needs to be resolved at parent

", "time": "2024-01-30T17:53:57Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

It was also proposed at IETF 118. The reason why we did not put it in draft was fear that it will derail the discussion.

", "time": "2024-01-30T17:54:11Z"}, {"author": "Warren Kumari", "text": "

I have some process ideas for at%he end

", "time": "2024-01-30T17:54:23Z"}, {"author": "Benjamin Schwartz", "text": "

Stephen Farrell said:

\n
\n

overall deleg seems worth exploring, most cringy thing for me is duplication of addresses in hints and a/aaaa

\n
\n

Currently, we have duplication of addresses in the child and parent glue. The duplication is intrinsic and unavoidable, but IMHO DELEG makes the distinction dramatically clearer by avoiding the colliding RRSets of the current system.

", "time": "2024-01-30T17:54:32Z"}, {"author": "Joe Abley", "text": "

the cringy thing for me is taking existing duplication of data between parent and child and providing another opportunity for duplication in deleg

", "time": "2024-01-30T17:55:01Z"}, {"author": "Stephen Farrell", "text": "

@ben if clear guidance as to which addrs to use when were possible that'd be good, not sure it is though

", "time": "2024-01-30T17:55:18Z"}, {"author": "Jim Reid", "text": "

When is the BoF in Brisbane? It would be good to know this before booking my plane ticket.

", "time": "2024-01-30T17:55:58Z"}, {"author": "Warren Kumari", "text": "

I think that the end of that agneda says:

\n", "time": "2024-01-30T17:56:10Z"}, {"author": "Benjamin Schwartz", "text": "

Stephen Farrell said:

\n
\n

@ben if clear guidance as to which addrs to use when were possible that'd be good, not sure it is though

\n
\n

Actually I think DELEG makes that much better. \"Use DELEG hints during resolution\". The end. Whereas in the current world, you need strange hacks like \"the exact same record can exist in two different versions in cache depending on how it was sourced\".

", "time": "2024-01-30T17:56:11Z"}, {"author": "Stephen Farrell", "text": "

@jim, we can have the bof on the plane - there'll be enough time anyway:-)

", "time": "2024-01-30T17:56:25Z"}, {"author": "Warren Kumari", "text": "

Hah, schedules are not fixed for quite a while yet.

", "time": "2024-01-30T17:56:39Z"}, {"author": "Warren Kumari", "text": "

and the BoF isn't actually approved yet, which is why I want there to be some time to discuss this here...

", "time": "2024-01-30T17:57:02Z"}, {"author": "Manu Bretelle", "text": "

BoF was confirmed?

", "time": "2024-01-30T17:57:04Z"}, {"author": "Warren Kumari", "text": "

Nope.

", "time": "2024-01-30T17:57:09Z"}, {"author": "Manu Bretelle", "text": "

ha, Warren answered :p

", "time": "2024-01-30T17:57:11Z"}, {"author": "Stephen Farrell", "text": "

this bof will be approved I bet

", "time": "2024-01-30T17:57:17Z"}, {"author": "Suzanne Woolf", "text": "

@Warren-- yes. Arguably DNSOP could take it on, \"protocol maintenance\" is on charter, but this is a big chunk of work and goes deep into protocol

", "time": "2024-01-30T17:57:32Z"}, {"author": "Peter Thomassen", "text": "

who decides BoF approval?

", "time": "2024-01-30T17:57:35Z"}, {"author": "Warren Kumari", "text": "

@Stephen: Unless we get to discuss it, quite likely no...

", "time": "2024-01-30T17:57:43Z"}, {"author": "Warren Kumari", "text": "

The IEAG and IAB...

", "time": "2024-01-30T17:57:50Z"}, {"author": "Andrew Campling", "text": "

On a European Commission call last week, Lars suggested more detail was needed before confirming the DELEG BoF, is this still the case?

", "time": "2024-01-30T17:57:58Z"}, {"author": "Stephen Farrell", "text": "

if this isn't the topic of a BoF at 119 then that'd be a fail

", "time": "2024-01-30T17:58:37Z"}, {"author": "Peter Thomassen", "text": "

good idea

", "time": "2024-01-30T17:58:57Z"}, {"author": "Stephen Farrell", "text": "

+1 to what warren just said

", "time": "2024-01-30T17:59:03Z"}, {"author": "Tim Wicinski", "text": "

nice suggestions warren !!!

", "time": "2024-01-30T17:59:44Z"}, {"author": "Andrew Campling", "text": "

A DELEG BoF then wg makes good sense

", "time": "2024-01-30T17:59:47Z"}, {"author": "Suzanne Woolf", "text": "

+1 Stephen

", "time": "2024-01-30T17:59:49Z"}, {"author": "Benjamin Schwartz", "text": "

@Warren Kumari Recharter DPRIVE :-)

", "time": "2024-01-30T17:59:56Z"}, {"author": "Mark McFadden", "text": "

I support Warren's idea here.

", "time": "2024-01-30T18:00:20Z"}, {"author": "Jim Reid", "text": "

Nah Ben. Recharter the DoH WG. :-)

", "time": "2024-01-30T18:00:29Z"}, {"author": "Suzanne Woolf", "text": "

Warren discused what he just said with DNSOP-chairs and we agreed. A new WG is the decision of the IESG.

", "time": "2024-01-30T18:00:29Z"}, {"author": "Andrew Campling", "text": "

DELEG wg as DNSOPs Extension :-)

", "time": "2024-01-30T18:00:39Z"}, {"author": "Benjamin Schwartz", "text": "

deleg.dnsop.ops.ietf.

", "time": "2024-01-30T18:01:05Z"}, {"author": "Suzanne Woolf", "text": "

@Andrew it's in our charter to help spin off new work, we did that with DPRIVE and ADD

", "time": "2024-01-30T18:01:06Z"}, {"author": "Tim Wicinski", "text": "

send suggestions Viktor !!

", "time": "2024-01-30T18:01:36Z"}, {"author": "Warren Kumari", "text": "

New we jsut need funnier name....

", "time": "2024-01-30T18:01:40Z"}, {"author": "Manu Bretelle", "text": "

DOPE, DNS OPerational Extension

", "time": "2024-01-30T18:02:12Z"}, {"author": "Andrew Campling", "text": "

:-)

", "time": "2024-01-30T18:02:21Z"}, {"author": "Jim Reid", "text": "

Where do we send suggestions Tim, dnsop mailing list?

", "time": "2024-01-30T18:02:21Z"}, {"author": "Warren Kumari", "text": "

There are 2 hard problems in computer science, and only one in the IETF?

", "time": "2024-01-30T18:02:30Z"}, {"author": "Stephen Farrell", "text": "

DOZEY

", "time": "2024-01-30T18:02:32Z"}, {"author": "Warren Kumari", "text": "

Oh! I like DOPE...

", "time": "2024-01-30T18:02:37Z"}, {"author": "Warren Kumari", "text": "

Or DOZY.

", "time": "2024-01-30T18:02:42Z"}, {"author": "Tim Wicinski", "text": "

DNSOP for now

", "time": "2024-01-30T18:02:47Z"}, {"author": "Warren Kumari", "text": "

+1

", "time": "2024-01-30T18:02:58Z"}, {"author": "Edward Lewis", "text": "

There's a draft now...

", "time": "2024-01-30T18:03:02Z"}, {"author": "Peter Thomassen", "text": "

good. Just clarifying

", "time": "2024-01-30T18:03:08Z"}, {"author": "Warren Kumari", "text": "

I think that it is important for tranparency, etc that IETF works happens in IETF lsits, etc...

", "time": "2024-01-30T18:03:23Z"}, {"author": "Warren Kumari", "text": "

Yup. Well said.

", "time": "2024-01-30T18:03:57Z"}, {"author": "Jim Reid", "text": "

+1 Benno.

", "time": "2024-01-30T18:04:00Z"}, {"author": "Peter Thomassen", "text": "

thank you for setting this up so quickly

", "time": "2024-01-30T18:04:02Z"}, {"author": "Tim Wicinski", "text": "

We (chairs) also see whether in DNSOP or new WG will some interims over 2024

", "time": "2024-01-30T18:04:02Z"}, {"author": "Joe Abley", "text": "

until this adopted by a wg this is an individual draft and discussion can surely happen wherever the authors prefer :-)

", "time": "2024-01-30T18:04:03Z"}, {"author": "Warren Kumari", "text": "

Cool.

", "time": "2024-01-30T18:04:36Z"}, {"author": "Andrew Campling", "text": "

I'll be in Charlotte Tuesday evening Ralf

", "time": "2024-01-30T18:04:36Z"}, {"author": "Manu Bretelle", "text": "

@ralf, I will post in oarc member list

", "time": "2024-01-30T18:04:40Z"}, {"author": "Jim Reid", "text": "

Who's Charlotte Tuesday?

", "time": "2024-01-30T18:04:56Z"}, {"author": "Warren Kumari", "text": "

Yah, nicely done.

", "time": "2024-01-30T18:05:12Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

:stop:

", "time": "2024-01-30T18:05:12Z"}]