Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-nsec-ttl-04: (with COMMENT)

Hi Peter, > -Original Message- > From: Peter van Dijk > Sent: 18 May 2021 18:26 > To: Rob Wilton (rwilton) ; The IESG > Cc: draft-ietf-dnsop-nsec-...@ietf.org; dnsop-cha...@ietf.org; > dnsop@ietf.org; tjw.i...@gmail.com > Subject: Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-d

Re: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-nsec-ttl-04: (with COMMENT)

Hello Benjamin, On Tue, 2021-05-18 at 20:36 -0700, Benjamin Kaduk via Datatracker wrote: > -- > COMMENT: > -- > > I put a (small) handful of editorial suggestion

Re: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-nsec-ttl-04: (with COMMENT)

On Wed, May 19, 2021 at 12:28:16PM +0200, Peter van Dijk wrote: > > Section 3.1, etc. > > > > | The TTL of the NSEC RR that is returned MUST be the lesser of the > > | MINIMUM field of the SOA record and the TTL of the SOA itself. > > | This matches the definition of the TTL for negative respon

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

I wanted to chime in on this discussion as a client-side implementor who has already widely deployed support for SVCB/HTTPS. The current format, where the parameters are structured as a list within a single RR, is certainly simpler and less error prone for processing. Much of the information co

Re: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-nsec-ttl-04: (with COMMENT)

Thanks, Job -- that looks better than anything I would have come up with! -Ben On Wed, May 19, 2021 at 01:10:27PM +0200, Job Snijders wrote: > On Wed, May 19, 2021 at 12:28:16PM +0200, Peter van Dijk wrote: > > > Section 3.1, etc. > > > > > > | The TTL of the NSEC RR that is returned MUST be th

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 19, 2021 at 7:49 AM Tommy Pauly wrote: > I wanted to chime in on this discussion as a client-side implementor who > has already widely deployed support for SVCB/HTTPS. > > The current format, where the parameters are structured as a list within a > single RR, is certainly simpler and

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

> On May 19, 2021, at 1:34 PM, Brian Dickson > wrote: > > > > On Wed, May 19, 2021 at 7:49 AM Tommy Pauly > wrote: > I wanted to chime in on this discussion as a client-side implementor who has > already widely deployed support for SVCB/HTTPS. > > The current form

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Given the request below to preserve the current wire format for both HTTPS and SVCB, I think this raises some interesting options and questions: - My understanding of SVCB is that it is intended to be the "parent" type for both HTTPS and other future "mappings" over SVCB. - HTTPS is the f

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 19, 2021 at 5:12 PM Tommy Pauly wrote: > > > On May 19, 2021, at 1:34 PM, Brian Dickson > wrote: > > > > On Wed, May 19, 2021 at 7:49 AM Tommy Pauly wrote: > >> I wanted to chime in on this discussion as a client-side implementor who >> has already widely deployed support for SVCB/H

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

Are these still just idle ideas you are tossing out (as you indicated earlier), or meant to be serious proposals? If the latter, what is the significant improvement over the current draft? I ask because it feels like you are suggesting moving the inherent complexity of the semantics of SCVB arou

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

> On May 19, 2021, at 2:37 PM, Erik Nygren wrote: > >  > > >> On Wed, May 19, 2021 at 5:12 PM Tommy Pauly wrote: >> >> >>> On May 19, 2021, at 1:34 PM, Brian Dickson >>> wrote: >>> >>> >>> >>> On Wed, May 19, 2021 at 7:49 AM Tommy Pauly wrote: I wanted to chime in on this discu

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 19, 2021 at 2:50 PM Paul Hoffman wrote: > Are these still just idle ideas you are tossing out (as you indicated > earlier), or meant to be serious proposals? If the latter, what is the > significant improvement over the current draft? I ask because it feels like > you are suggesting m

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

If you split presentation format records into one record per SvcParam, that necessitates either changing the wire format to match or structuring the presentation and wire formats fundamentally differently with a translation to merge those records into a single record for the wire format. What the

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 19, 2021 at 3:00 PM Brian Dickson wrote: > > > On Wed, May 19, 2021 at 2:50 PM Paul Hoffman > wrote: > >> Are these still just idle ideas you are tossing out (as you indicated >> earlier), or meant to be serious proposals? If the latter, what is the >> significant improvement over th

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 19, 2021 at 7:01 PM Brian Dickson wrote: > > > On Wed, May 19, 2021 at 3:00 PM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > >> >> >> On Wed, May 19, 2021 at 2:50 PM Paul Hoffman >> wrote: >> >>> Are these still just idle ideas you are tossing out (as you indicated >>> ea

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 19, 2021 at 5:15 PM Erik Nygren wrote: > > > On Wed, May 19, 2021 at 7:01 PM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > >> >> >> On Wed, May 19, 2021 at 3:00 PM Brian Dickson < >> brian.peter.dick...@gmail.com> wrote: >> >>> >>> >>> On Wed, May 19, 2021 at 2:50 PM Paul

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Thu, May 20, 2021, at 10:35, Brian Dickson wrote: > I was under the impression that the extensibility is for the SVCB type, > and not strictly needed for HTTPS. It is absolutely needed for HTTPS. I also want to add to what Tommy (P) said about deployment. We've deployed the current wire for

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Thu, 20 May 2021, Martin Thomson wrote: I also want to add to what Tommy (P) said about deployment. We've deployed the current wire format (that's what you get when you assign a codepoint people!) Changes would have serious implications. It looks like the early code point was assigned a

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Thu, May 20, 2021, at 11:08, Paul Wouters wrote: > This discussion should be around reasonable and secure wire and > presentation formats, not about "but we already deployed this". > It should surely be taken into account if changing at this point > gives enough benefits, but the idea of changin

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 19, 2021 at 6:15 PM Martin Thomson wrote: > On Thu, May 20, 2021, at 11:08, Paul Wouters wrote: > > This discussion should be around reasonable and secure wire and > > presentation formats, not about "but we already deployed this". > > It should surely be taken into account if changin

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 19, 2021 at 5:52 PM Martin Thomson wrote: > On Thu, May 20, 2021, at 10:35, Brian Dickson wrote: > > I was under the impression that the extensibility is for the SVCB type, > > and not strictly needed for HTTPS. > > It is absolutely needed for HTTPS. > I'm not saying I doubt you, but

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Thu, May 20, 2021, at 11:32, Brian Dickson wrote: > Is it one of those things that are "Well, we think we might need > something", or is it "We already know something we need"? The former is definitely a factor. Though you might reasonably say that defining another HTTPSv2 codepoint is feasi

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

All I'd like to circle around as chair and call this discussion illuminating. I do feel that there is rough consensus to keep with the current format. The discussion here has gone down the path of wholesale redesign. We call the WGLC closed for now. The authors have an updated document to publish

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, 19 May 2021, Ben Schwartz wrote: So long as there are no registered protocol identifiers containing "," or "\\", zone file implementations MAY disallow these characters instead of implementing the `value-list` escaping procedure. Sorry, an implementor cannot predict the future of the

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

> On 20 May 2021, at 11:52, Paul Wouters wrote: > > On Wed, 19 May 2021, Ben Schwartz wrote: > >> So long as there are no registered protocol identifiers containing "," or >> "\\", zone file implementations MAY >> disallow these characters instead of implementing the `value-list` escaping >>

[DNSOP] SVCB/HTTPS, ECH, and AltSvc

Hey, I've just opened https://github.com/MikeBishop/dns-alt-svc/issues/326 It's a bit long and I won't repeat it here, but I don't think that the current state of the document is good with respect to its handling of ECH and alternative services. ___

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

On Wed, May 19, 2021 at 7:15 PM Mark Andrews wrote: > > > > On 20 May 2021, at 11:52, Paul Wouters wrote: > > > > On Wed, 19 May 2021, Ben Schwartz wrote: > > > >> So long as there are no registered protocol identifiers containing "," > or "\\", zone file implementations MAY > >> disallow these

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

> On 20 May 2021, at 12:31, Brian Dickson wrote: > > > > On Wed, May 19, 2021 at 7:15 PM Mark Andrews wrote: > > > > On 20 May 2021, at 11:52, Paul Wouters wrote: > > > > On Wed, 19 May 2021, Ben Schwartz wrote: > > > >> So long as there are no registered protocol identifiers containing