[{"author": "\u00c9ric Vyncke", "text": "

;-)

", "time": "2022-07-28T17:31:26Z"}, {"author": "Anthony Somerset", "text": "

warren has magiced it back into existence

", "time": "2022-07-28T17:31:54Z"}, {"author": "Brett Carr", "text": "

Hello Everyone :)

", "time": "2022-07-28T17:32:09Z"}, {"author": "Eric Rescorla", "text": "

Can someone transcribe when presentations are starting in this channel? I have a conflict so I have to jump in at the end for my presentation

", "time": "2022-07-28T17:32:47Z"}, {"author": "Shivan Sahib", "text": "

Hi all!

", "time": "2022-07-28T17:33:31Z"}, {"author": "Barry Leiba", "text": "

Chair slides starting

", "time": "2022-07-28T17:33:36Z"}, {"author": "Andrew Campling", "text": "

Hi Brett

", "time": "2022-07-28T17:33:54Z"}, {"author": "Eric Rescorla", "text": "

@Barry Leiba thanks!

", "time": "2022-07-28T17:34:17Z"}, {"author": "Andrew Campling", "text": "

The agenda is pretty content rich! :-)

", "time": "2022-07-28T17:36:12Z"}, {"author": "Barry Leiba", "text": "

Warren talks about DNS directorate

", "time": "2022-07-28T17:37:10Z"}, {"author": "Barry Leiba", "text": "

Tim W talks about doc status

", "time": "2022-07-28T17:41:47Z"}, {"author": "Warren Kumari", "text": "

Erm. Should I turn down the in-room speakers? I think that the other mics are not quite as hot, so don't want to futz with it unless needed...

", "time": "2022-07-28T17:47:15Z"}, {"author": "Warren Kumari", "text": "

Actually, I will ask the technical ppl instead of me twiddling the knobs...

", "time": "2022-07-28T17:47:41Z"}, {"author": "\u00c9ric Vyncke", "text": "

Possible safer ;-)

", "time": "2022-07-28T17:48:04Z"}, {"author": "Anthony Somerset", "text": "

i think we should be fine now

", "time": "2022-07-28T17:49:03Z"}, {"author": "Barry Leiba", "text": "

Nils talks about the hackathon

", "time": "2022-07-28T17:49:26Z"}, {"author": "Barry Leiba", "text": "

Yorgos, more hackathon

", "time": "2022-07-28T17:51:29Z"}, {"author": "Barry Leiba", "text": "

Paul H, DNSSEC as a BCP

", "time": "2022-07-28T17:53:11Z"}, {"author": "Barry Leiba", "text": "

Moving to WGLC now\u2026

", "time": "2022-07-28T17:55:21Z"}, {"author": "Benno Overeinder", "text": "

We will keep you informed ekr.

", "time": "2022-07-28T17:55:52Z"}, {"author": "Barry Leiba", "text": "

Daniel M, Recommendations for DNSSEC Resolvers

", "time": "2022-07-28T17:56:19Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

It sounds there might be an overlap between the Paul's document and this document...

", "time": "2022-07-28T17:57:42Z"}, {"author": "Anthony Somerset", "text": "

i agree - i was going to ask the same question

", "time": "2022-07-28T17:58:06Z"}, {"author": "Eric Rescorla", "text": "

@Benno Overeinder thank you!

", "time": "2022-07-28T17:58:50Z"}, {"author": "Barry Leiba", "text": "

Shivan, Domain Verification Techniques

", "time": "2022-07-28T18:00:25Z"}, {"author": "Tim Wicinski", "text": "

@Andrew Campling DNSOP is always a good time - don't like one document, there will be another one coming round the bend !

", "time": "2022-07-28T18:01:26Z"}, {"author": "Tim Wicinski", "text": "

I did an editorial dive on Daniel's doc and will shepherd Paul's DNSSEC BCP, so I'll make a note to review both and compare.

", "time": "2022-07-28T18:02:35Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Excellent, thank you!

", "time": "2022-07-28T18:08:35Z"}, {"author": "Tim Wicinski", "text": "

of course, The chairs are to serve.

", "time": "2022-07-28T18:09:02Z"}, {"author": "Tim Wicinski", "text": "

(y'all can stop laughing now)

", "time": "2022-07-28T18:09:47Z"}, {"author": "Hazel Smith", "text": "

Do people use DNAME for domain verification? (I haven't seen it used like that personally, but I haven't been surveying the matter either.)

", "time": "2022-07-28T18:11:33Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

FWIW BCP makes more sense to me as well.

", "time": "2022-07-28T18:11:41Z"}, {"author": "Brett Carr", "text": "

Happy to help as a reviewer when this moves towards being a BCP

", "time": "2022-07-28T18:11:57Z"}, {"author": "Barry Leiba", "text": "

Yorgos, Dry-Run DNSSEC

", "time": "2022-07-28T18:12:00Z"}, {"author": "Shumon Huque", "text": "

re: BCP for domain verification techniques, I agree also. We initially set a low bar for ourselves to feel out the working group, so it was a primarily a survey. But we would like to have provide solid recommendations about good ways to do this.

", "time": "2022-07-28T18:13:28Z"}, {"author": "Brian Dickson", "text": "

I'm not aware of usage of DNAME, but an anti-caveat is that DNAME can exist at zone apex, with no impact/pollution on the apex itself, it's actually an elegant method.
\nfoo.domain.example hits domain.example DNAME bar.example, rewrite to foo.bar.example, QED

", "time": "2022-07-28T18:14:46Z"}, {"author": "Brian Dickson", "text": "

(But must not be a persistent record since only one DNAME can exist.)

", "time": "2022-07-28T18:16:10Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

I would be more worried about unintended interaction of DNAME vs. other techniques - when provides requires you to verify using _subdomain but you have DNAME in place, what does it mean? IMHO that's what should be described in the BCP.

", "time": "2022-07-28T18:17:27Z"}, {"author": "Brian Dickson", "text": "

Note to meeting folks, not seeing presentation on meetecho feed?

", "time": "2022-07-28T18:17:38Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

I do see it on MeetEcho.

", "time": "2022-07-28T18:17:52Z"}, {"author": "Shumon Huque", "text": "

I agree that we should clarify what happens when a DNAME is present at the domain name where a verification record exists. We should probably clarify that the domain name being verified is the owner of the record, rather than the DNAME target.

", "time": "2022-07-28T18:17:53Z"}, {"author": "Brett Carr", "text": "

I can see it here brian

", "time": "2022-07-28T18:18:03Z"}, {"author": "Brian Dickson", "text": "

Thanks, Brett

", "time": "2022-07-28T18:18:28Z"}, {"author": "\u00c9ric Vyncke", "text": "

@Brian be sure to click on the right most icon on the top right

", "time": "2022-07-28T18:19:29Z"}, {"author": "John O'Brien", "text": "

re: DDS RR type -- An idle thought: Shouldn't it be PDS?

", "time": "2022-07-28T18:19:46Z"}, {"author": "Shumon Huque", "text": "

Yeah, that's a good point Petr - the subdomains of the DNAME owner will essentially be occluded so no domain verif record can exist there.

", "time": "2022-07-28T18:20:07Z"}, {"author": "John Levine", "text": "

also that dname at foo and _tag.foo won't work

", "time": "2022-07-28T18:20:19Z"}, {"author": "Yoshitaka Aharen", "text": "

maybe I misunderstand something, but looking at the example in slide 9, can it be used to validate ca.us with \"[ldh-challenge-label].ca.us DNAME [challenge-domain-name]\"?

", "time": "2022-07-28T18:20:44Z"}, {"author": "Suzanne Woolf", "text": "

<no hats> I like this draft

", "time": "2022-07-28T18:22:01Z"}, {"author": "Tim Wicinski", "text": "

i like this draft, and I wear the hat of an operator to state this.

", "time": "2022-07-28T18:22:43Z"}, {"author": "Brett Carr", "text": "

+1 for a seperate record

", "time": "2022-07-28T18:22:49Z"}, {"author": "Shumon Huque", "text": "

Part of the work on the domain verification draft should also involve us reaching out to app folks (including outside IETF). If they do not buy into and adopt our recommendations, we might be wasting our time.

", "time": "2022-07-28T18:23:27Z"}, {"author": "Hazel Smith", "text": "

Presumably the alternative is to not \"go secure\" either in the first place? i.e. never set the AD bit when validating dry-run DS?

", "time": "2022-07-28T18:23:59Z"}, {"author": "Antoin Verschuren", "text": "

If we can't convince people to implement DNSSEC, then how can we convince people to try dry-run DNSSEC?

", "time": "2022-07-28T18:25:51Z"}, {"author": "David Lawrence", "text": "

Am I the only one not digging it? I'm not really sure why this is superior to pre-delegation testing that we can already do, and I'm not even one that normally complains about the Camel. We can achieve what is needed without protocol modifications, so why pursue this?

", "time": "2022-07-28T18:26:49Z"}, {"author": "Samuel Weiler", "text": "

We have a proposed standard RFC on DNSSEC Experiments, 4955, that suggests using algorithm numbers to signal experiments, not the DS alg identifiers. I'm thinking we should follow its guidance....

", "time": "2022-07-28T18:26:52Z"}, {"author": "David Lawrence", "text": "

I'm currently against adoption, for whatever that's worth.

", "time": "2022-07-28T18:27:24Z"}, {"author": "Jim Reid", "text": "

Good point Antoin.

", "time": "2022-07-28T18:27:32Z"}, {"author": "Antoin Verschuren", "text": "

+1 David. THis is a DNS Camel proposal, because we can and it's fancy to do something DNS

", "time": "2022-07-28T18:27:57Z"}, {"author": "Peter Koch", "text": "

Maybe the IETF could use the re-instantiated DNS Directorate to discuss a moratorium on methods that \"ease\" DNSSEC deployment, so the poor folk out there have something remotely stable to understand and roll out?

", "time": "2022-07-28T18:28:06Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Antoin, Jim. I think it's the opposite. Why would people risk breaking their domain... slack.com could tell stories.

", "time": "2022-07-28T18:28:15Z"}, {"author": "David Lawrence", "text": "

The Slack story would not have improved with this.

", "time": "2022-07-28T18:29:08Z"}, {"author": "\u00c9ric Vyncke", "text": "

For what it is worth, the DNS directorate is not a gating point, but will have a very useful role in reviewing and pointing issues.

", "time": "2022-07-28T18:29:16Z"}, {"author": "\u00c9ric Vyncke", "text": "

(for @Peter)

", "time": "2022-07-28T18:29:23Z"}, {"author": "Hazel Smith", "text": "

Yeah, there are no \"success reports\"

", "time": "2022-07-28T18:29:55Z"}, {"author": "Antoin Verschuren", "text": "

Adoption is not about breakage. Adoption is about cost and initiative. Look at the .nl adoption.

", "time": "2022-07-28T18:30:02Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

@Dave It could. The error was detectable because the NSEC was rubbish, and it might have been reported to operator instead of breaking stuff.

", "time": "2022-07-28T18:30:03Z"}, {"author": "Hazel Smith", "text": "

I wonder if you could have a sample rate?

", "time": "2022-07-28T18:30:04Z"}, {"author": "John Klensin", "text": "

Antoin, David: As a would-be camel herder, I would certainly agree that the bar to this should be rather high.

", "time": "2022-07-28T18:30:15Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Yes, error reporting does allow sampling.

", "time": "2022-07-28T18:30:22Z"}, {"author": "Jim Reid", "text": "

This ID adds a lot of complexity for marginal benefit IMO. I'm not sure it's a good idea to tweak a protocol to enable configuration testing.

", "time": "2022-07-28T18:30:57Z"}, {"author": "Randy Bush", "text": "

@jim: we're gonna stop now?

", "time": "2022-07-28T18:31:27Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

I agree with the complexity objection, certainly. Having said that, I still think it is a useful feature.

", "time": "2022-07-28T18:31:33Z"}, {"author": "Jim Reid", "text": "

Sure Randy. We have to stop somwhere. :-)

", "time": "2022-07-28T18:32:00Z"}, {"author": "Shumon Huque", "text": "

@David Lawrence - I agree. More complete pre-delegation testing would have caught the issue that took Slack down.

", "time": "2022-07-28T18:32:20Z"}, {"author": "John Klensin", "text": "

@Randy, if not now, when ? (translated from the camel)

", "time": "2022-07-28T18:32:49Z"}, {"author": "Antoin Verschuren", "text": "

In my opinion, implementing real DNSSEC is just as hard, or even simpler than doing dry-run DNSSEC.

", "time": "2022-07-28T18:34:06Z"}, {"author": "Hazel Smith", "text": "

I wonder if it would be useful to have an (Informational?) document on suggested approaches for testing DNSSEC with a parallel domain? (e.g. slack.com -> fynpx.com or whatever test domain you want to buy)

\n

(E.g. suggestions of tooling to use to compare the zones or something?)

", "time": "2022-07-28T18:34:07Z"}, {"author": "Hazel Smith", "text": "

i.e. curate a collection of \"What we tried, what went well, what went poorly, what we learned\" type observations from large DNS domains that did a migration to DNSSEC

", "time": "2022-07-28T18:35:21Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Hazel, I like that idea - that might be an excellent BCP.

", "time": "2022-07-28T18:35:57Z"}, {"author": "Tim Wicinski", "text": "

The Slack writeup was really well done

", "time": "2022-07-28T18:36:04Z"}, {"author": "Tim Wicinski", "text": "

(Agreeing with Hazel)

", "time": "2022-07-28T18:36:15Z"}, {"author": "Jim Reid", "text": "

Using dry-run DNSSEC with a pretendy key before using the actual key seems clumsy: more moving parts, more ways to complicate or break things. What does this ID do that can't be done already?

", "time": "2022-07-28T18:36:20Z"}, {"author": "Brian Dickson", "text": "

Antoin, when you say \"DNSSEC implementation\", do you actually mean \"DNSSEC deployment\" instead? E.g. enabling/configuring DNSSEC, rather than actual code development? Are there any significant DNS implementations (auth, resolver, client) that haven't done DNSSEC yet? I'm not convinced those are blockers, e.g. that there are enough implementations that operators can switch to, on auth/resolver at least.

", "time": "2022-07-28T18:36:31Z"}, {"author": "Hazel Smith", "text": "

@Jim Reid Yeah, that would be my concern, that there's plenty of scope to still shoot yourself in the foot when mangling the dry-run DS record to make it a real one... (tooling would likely help here ofc)

", "time": "2022-07-28T18:37:05Z"}, {"author": "David Lawrence", "text": "

I'm not so much a stubborn old goat, but I'm not yet seeing anything that convinces me that a protocol changing approach is superior to the perennial request for better tooling. Even the protocol change would still need tooling anyway, so it's not like that somehow saves that part of the problem.

", "time": "2022-07-28T18:39:15Z"}, {"author": "Jim Reid", "text": "

Yes Hazel. More tooling would help of course. IMO that effort should focus on the real DS records and keys - not diversions.

", "time": "2022-07-28T18:39:21Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Well, testing from one spot is not an issue. The hard part is validating it all over the world where you don't have control over clients.

", "time": "2022-07-28T18:39:24Z"}, {"author": "David Lawrence", "text": "

I do my dry runs with dnsviz command line. A spiffy web front end with dancing bananas could make it more accessible.

", "time": "2022-07-28T18:40:02Z"}, {"author": "Antoin Verschuren", "text": "

@Brian Dickson, yes, I meant deployment. Experience in DNSSEC deployment tell me that the protocol is not the issue, but the operational process and maintainence is where it can go wrong. People that don't think about maintainability..

", "time": "2022-07-28T18:41:49Z"}, {"author": "Hazel Smith", "text": "

@Petr \u0160pa\u010dek Quite.

\n

Some of the sort of things I was thinking of for how to test this where you care (e.g. in the browser for web operators, but other scenarios should be covered too!) was experiments with client-side javascript (or embedded 1x1 pixel jpgs, or...) on webpages to test if \"non-dnssec-test-1-slack.com\" and \"dnssec-test-1-slack.com\" both succeed or both fail or only one succeeds etc?

", "time": "2022-07-28T18:41:59Z"}, {"author": "Barry Leiba", "text": "

Paul H, Initializing a DNS Resolver with Priming Queries

", "time": "2022-07-28T18:43:14Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Generally what Geoff Huston does, in many variations possible. If you control the page it's even easier.

", "time": "2022-07-28T18:43:15Z"}, {"author": "Benno Overeinder", "text": "

@ekr, heads up in about 15 minutes.

", "time": "2022-07-28T18:46:22Z"}, {"author": "Eric Rescorla", "text": "

@Benno Overeinder thank you. I am outside the room

", "time": "2022-07-28T18:46:33Z"}, {"author": "John Klensin", "text": "

Please ask Paul to try to stop moving back and forth... in some positions, he becomes nearly inaudible.

", "time": "2022-07-28T18:46:51Z"}, {"author": "Tim Wicinski", "text": "

Done John

", "time": "2022-07-28T18:47:32Z"}, {"author": "John Klensin", "text": "

Thanks. Immediate improvement noted.

", "time": "2022-07-28T18:47:49Z"}, {"author": "Tim Wicinski", "text": "

Also, Shout Out to @Barry Leiba for the chat transcribing.

", "time": "2022-07-28T18:48:12Z"}, {"author": "Tim Wicinski", "text": "

Chairs have interest in this work.

", "time": "2022-07-28T18:49:09Z"}, {"author": "Warren Kumari", "text": "

As do I (with no hats)

", "time": "2022-07-28T18:49:30Z"}, {"author": "Brian Dickson", "text": "

ObHumor/Pun: Optimus Priming

", "time": "2022-07-28T18:49:32Z"}, {"author": "Barry Leiba", "text": "

Dan Wing, Structured Data for Filtered DNS

", "time": "2022-07-28T18:49:32Z"}, {"author": "Eric Rescorla", "text": "

Thank you. I am in the back of the room now and ready to go whenever

", "time": "2022-07-28T18:50:28Z"}, {"author": "Brett Carr", "text": "

I support the adoption of this document, we would welcome this in our RPZ based DNS Resolver.

", "time": "2022-07-28T18:53:17Z"}, {"author": "Tim Wicinski", "text": "

Chairs are interested in hearing about folks willing to implement

", "time": "2022-07-28T18:53:58Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Excellent, thank you for feedback!

", "time": "2022-07-28T18:54:12Z"}, {"author": "Andrew Campling", "text": "

Providing greater transparancy on why content is filtered is a really positive step

", "time": "2022-07-28T18:54:47Z"}, {"author": "John O'Brien", "text": "

Re: structured DNS error with RPZ -- I'm specifically thinking about whether it is possible and advisable to include EDE with NOERROR responses; those in which a known-naughty response has been rewritten to a captive portal address, for instance.

", "time": "2022-07-28T18:55:33Z"}, {"author": "Hazel Smith", "text": "

Re: \"should we\" (shove this into the DNS)... surely some non-trivial proportion of operators have already shoved this functionality into their DNS recursive services, and I guess the question is whether we want to support/obstruct/encourage/discourage/have no opinion on that

", "time": "2022-07-28T18:57:20Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

@Ben I think the question is not if DNS is the right place. This things is happening in the wild. The question is if want to allow better UX for what is happening right now.

", "time": "2022-07-28T18:58:02Z"}, {"author": "Hazel Smith", "text": "

\"this functionality\" as in \"malware filtering etc being done by DNS operators at query time\"

", "time": "2022-07-28T18:58:04Z"}, {"author": "Tim Wicinski", "text": "

agree Hazel - as an operator I see so many variations on this that maybe some consistency would be useful?

", "time": "2022-07-28T18:58:21Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Ah, I forgot to scroll down to see that other people already said.

", "time": "2022-07-28T18:58:37Z"}, {"author": "Andrew Campling", "text": "

+1 to Petr

", "time": "2022-07-28T18:58:52Z"}, {"author": "Warren Kumari", "text": "

Philosophically, people shouldn't futz with answers... but, if they are going to, it should would be nice if they could tell you that they did, and why..

", "time": "2022-07-28T18:59:55Z"}, {"author": "Andrew Campling", "text": "

A great point about non-browser client s/w

", "time": "2022-07-28T19:00:03Z"}, {"author": "Barry Leiba", "text": "

EKR, Recent results on measuring the end-to-end success rate of DNSSEC and new record types

", "time": "2022-07-28T19:00:06Z"}, {"author": "Brian Dickson", "text": "

E.g. REST APIs, so +1 and echoing Viktor

", "time": "2022-07-28T19:00:07Z"}, {"author": "John O'Brien", "text": "

Did somebody set the session on 2x speed?

", "time": "2022-07-28T19:06:09Z"}, {"author": "Antoin Verschuren", "text": "

;-) It's Eric. It's very hard for him to talk even slower :-)

", "time": "2022-07-28T19:07:11Z"}, {"author": "Hazel Smith", "text": "

(Speed is fine for me, but I see your point - I thought you meant the whole WG)

", "time": "2022-07-28T19:07:36Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

We cannot hear the room.

", "time": "2022-07-28T19:12:37Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Or is it just me?

", "time": "2022-07-28T19:12:44Z"}, {"author": "Antoin Verschuren", "text": "

I hear the room...

", "time": "2022-07-28T19:12:58Z"}, {"author": "Yoshitaka Aharen", "text": "

I can hear EKR speaking

", "time": "2022-07-28T19:13:01Z"}, {"author": "Randy Bush", "text": "

audio ok for me except when ekr turns away from mic

", "time": "2022-07-28T19:13:08Z"}, {"author": "Tim Wicinski", "text": "

not the remote speaker?

", "time": "2022-07-28T19:13:11Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Okay, local problem. Sorry for the noise.

", "time": "2022-07-28T19:13:21Z"}, {"author": "Antoin Verschuren", "text": "

I can hear everybody

", "time": "2022-07-28T19:13:25Z"}, {"author": "Warren Kumari", "text": "

I'll just type instead: EKR, you've made me sad....

", "time": "2022-07-28T19:13:58Z"}, {"author": "Randy Bush", "text": "

@warren: as ekr said, ImperialViolet told us this a decade ago. but these are finer grained measurements, which is cool

", "time": "2022-07-28T19:15:55Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

Well, next time ISPs start to weep about DoH and DoT I know the slides to show them.

", "time": "2022-07-28T19:16:32Z"}, {"author": "Warren Kumari", "text": "

Yup. Also, I was hoping that things had gotten much better over time...

", "time": "2022-07-28T19:16:35Z"}, {"author": "Brian Dickson", "text": "

@ekr or whoever else, could you make anonymized raw data available for other slicing/dicing/aggregation of it, to provide back to you for your benefit too?

", "time": "2022-07-28T19:16:59Z"}, {"author": "Randy Bush", "text": "

i wish i lived in that universe

", "time": "2022-07-28T19:17:04Z"}, {"author": "Warren Kumari", "text": "

@Randy: You mean the one where things get better over time? Yeah, me too...

", "time": "2022-07-28T19:17:34Z"}, {"author": "Warren Kumari", "text": "

But hope springs eternal...

", "time": "2022-07-28T19:18:00Z"}, {"author": "Hazel Smith", "text": "

One person's comment in the room that it's \"interesting and depressing\" is a fair summary I think

", "time": "2022-07-28T19:19:19Z"}, {"author": "Hazel Smith", "text": "

Thanks, ekr for doing this and sharing the results!

", "time": "2022-07-28T19:19:28Z"}, {"author": "Barry Leiba", "text": "

Peter T, consistency is mandatory

", "time": "2022-07-28T19:19:47Z"}, {"author": "Petr \u0160pa\u010dek", "text": "

@ekr Excellent data, thank you very much. By any chance, is a preprint version of the paper available somewhere?

", "time": "2022-07-28T19:19:54Z"}, {"author": "Hugo Salgado", "text": "

I support the demand for consistency between NS, it's the mechanism that we have implemented in our TLD for scanning, and I understand that zonemaster also performs checks in all NS. It is the right and necessary thing to do.

", "time": "2022-07-28T19:25:53Z"}, {"author": "Hugo Salgado", "text": "

Bootstraping from unsigned to signed has more demanding requirements than a simple rollover.

", "time": "2022-07-28T19:26:43Z"}, {"author": "Jabber", "text": "

dkg: Ben: the draft doesn't say anything about querying cadence at all -- why add querying cadence for this part?

", "time": "2022-07-28T19:28:49Z"}, {"author": "Benjamin Schwartz", "text": "

dkg: I think the correct cadence is not obvious, so some guidance would be useful

", "time": "2022-07-28T19:29:29Z"}, {"author": "Jabber", "text": "

dkg: it seems to me that the most relevant missing time constant has to do with whether the responses are consistent, given that the responses don't all come in perfectly simultaneously

", "time": "2022-07-28T19:29:31Z"}, {"author": "Hazel Smith", "text": "

Thanks everyone!

", "time": "2022-07-28T19:29:32Z"}]