Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

Bringing (hopeful) closure to this thread, we've published -11: Diff of the changes: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-11.txt The only things included are the two changes agreed on in this thread. (We did not include the "hostname" => "domain name" clarification

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

One item discussed above that the authors would like to clarify is to be consistent about whether the alternative endpoint name (TargetName) is a hostname or a domain name. In all but one place in the doc we refer to it as a "domain name" but there is one reference that calls it a "hostname". In

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

Hi all, Firstly, and most importantly, thank y'all for keeping this civil, friendly and productive; I really appreciate it. I've (informally) checked with the IESG on the proposed change in the PR and also including Erik's proposed operational note ("Some implementations may not allow A or

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

There seem to be two topics: 1) Victor's clarification makes sense, although the wording is a little awkward and perhaps we can improve that sentence. The section was already implying that meaning (ie, that the fallback addition of the QNAME was for the AliasMode case) but clarifying this

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Sep 8, 2022, at 8:35 AM, Viktor Dukhovni wrote: > This is a bug fix, the proposed behaviour makes no sense when $QNAME > is the unaltered (attrleaf prefixed) starting point. The current > meaning was not intended. If the edit can be made without any > major process, just a note to the RFC

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Thu, Sep 08, 2022 at 03:06:45PM +, Paul Hoffman wrote: > > If no AliasMode record was processed, then $QNAME would be the > > origin name PLUS the prefix(es) of type attrleaf ( underscore > > thingies). Those won't be legitimate A/ owner names (and > > shouldn't exist), and if a client

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Sep 7, 2022, at 8:29 PM, Brian Dickson wrote: > > Once SVCB resolution has concluded, whether successful or not, > > +if at least one AliasMode record was processed, > > SVCB-optional clients SHALL append to the priority list an > > endpoint consisting of the final value of $QNAME, the

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Thu, Sep 08, 2022 at 02:08:27PM +1000, Martin Thomson wrote: > On Thu, Sep 8, 2022, at 13:29, Brian Dickson wrote: > > If no AliasMode record was processed, then $QNAME would be the origin > > name PLUS the prefix(es) of type attrleaf ( underscore thingies). Those > > won't be legitimate

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Wed, Sep 7, 2022 at 9:09 PM Martin Thomson wrote: > > > On Thu, Sep 8, 2022, at 13:29, Brian Dickson wrote: > > If no AliasMode record was processed, then $QNAME would be the origin > > name PLUS the prefix(es) of type attrleaf ( underscore thingies). Those > > won't be legitimate A/

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Thu, Sep 8, 2022, at 13:29, Brian Dickson wrote: > If no AliasMode record was processed, then $QNAME would be the origin > name PLUS the prefix(es) of type attrleaf ( underscore thingies). Those > won't be legitimate A/ owner names (and shouldn't exist), and if a > client did that it

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Wed, Sep 7, 2022 at 7:41 PM Paul Hoffman wrote: > On Sep 7, 2022, at 5:48 PM, Viktor Dukhovni > wrote: > > Once SVCB resolution has concluded, whether successful or not, > > +if at least one AliasMode record was processed, > > SVCB-optional clients SHALL append to the priority list an > >

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Sep 7, 2022, at 5:48 PM, Viktor Dukhovni wrote: > Once SVCB resolution has concluded, whether successful or not, > +if at least one AliasMode record was processed, > SVCB-optional clients SHALL append to the priority list an > endpoint consisting of the final value of $QNAME, the authority >

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

> Yes, and catching COVID on Friday didn't help. Will attempt to send a > pull request for just the $QNAME fix shortly. Making a pull request does not preclude also Cc'ing the list. Which is what I'm doing now and was planning to do in any case:

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Wed, Sep 07, 2022 at 03:36:16PM -0700, Warren Kumari wrote: > I chatted with Viktor Dukhovni late last week, and he promised us a > sentence to solve all that ails us… or, at least, a simple, clear, concise > sentence which only clarifies what appears to have been intended. > > I suspect that

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

I chatted with Viktor Dukhovni late last week, and he promised us a sentence to solve all that ails us… or, at least, a simple, clear, concise sentence which only clarifies what appears to have been intended. I suspect that US Labor day vacation got in the way, but I hope to have it soon. If not,

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

I don’t personally find this proposal to be an improvement for clarity. The fact that a client is SVCB-optional means, somewhat by definition, that they allow not using the SVCB results. Saying that the client “MAY” doesn’t really help; it’s the very definition of what SVCB-optional is. If the

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

So, here is my suggestion, for "a sentence (or possibly two) which only clarify what is already written?": In section 3: If the client is SVCB-optional, and connecting using this list of endpoints has failed, the client now attempts to use non-SVCB connection modes. becomes: If the

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

Off-list: > Can we "rescue" just the clarifications/corrections? Yes, with an Internet Draft that would become an RFC later. Brian pretty much refuses to do this kind of thing, so you should consider doing it yourself. --Paul smime.p7s Description: S/MIME cryptographic signature

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Wed, Aug 31, 2022 at 4:39 AM, Brian Dickson < brian.peter.dick...@gmail.com> wrote: > Here are some proposed text changes, per Warren's invitation to send text: > Um, no. Warren said: "can we craft a sentence (or possibly two) which only clarify what is already written?". This is a

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

Here are some proposed text changes, per Warren's invitation to send text: In section 1.2, change: 2. TargetName: The domain name of either the alias target (for AliasMode) or the alternative endpoint (for ServiceMode). to: 2. TargetName: Either the domain name of the alias target

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Sat, Aug 27, 2022 at 3:00 PM Ben Schwartz wrote: > > > On Fri, Aug 26, 2022 at 10:49 PM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > >> >> Fail fast may not be appealing, but in some (probably the majority of) >> cases, it may be the most correct option. >> >> It may also be the

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Mon, Aug 29, 2022 at 09:32:24PM +, Warren Kumari wrote: > > * For the rfc1123 section 2 topic, it may make sense to clarify the text > > to say "domain name" rather than "hostname": > >> An "alternative endpoint" is a hostname, port number, and other > >> associated instructions

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Mon, Aug 29, 2022 at 12:33 PM, Erik Nygren wrote: > Catching up on this thread, I agree with Ben Schwartz, Tommy Pauly, and > Eric Orth > that the current behavior makes sense and that no fundamental technical > change is needed. > I've been watching this thread and following along - it has

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Mon, Aug 29, 2022 at 12:33:55PM -0400, Erik Nygren wrote: > On paths forward on the draft as it stands to clarify without making > significant technical changes (which I don't think are necessary): > > * Are there particular clarifications we can/should add to help make > the current behavior

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

Catching up on this thread, I agree with Ben Schwartz, Tommy Pauly, and Eric Orth that the current behavior makes sense and that no fundamental technical change is needed. No matter what we do, odd faults and misconfigurations will happen and Postel's law applies. Client implementers will try and

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Fri, Aug 26, 2022 at 11:54 AM Tommy Pauly wrote: > > > On Aug 26, 2022, at 4:29 AM, Ben Schwartz 40google@dmarc.ietf.org> wrote: > >  > > > On Thu, Aug 25, 2022 at 7:19 PM Viktor Dukhovni > wrote: > >> On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote: >> >> > Relatedly, the

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Thu, Aug 25, 2022 at 1:35 PM Ben Schwartz wrote: > For now, I think it's better to keep the current guidance, in order to > minimize the risk of disruptions as these new RR types begin to be deployed. > I have a small favor to ask. Could you try to "sell" the guidance from the hypothetical

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Thu, Aug 25, 2022 at 1:35 PM Ben Schwartz wrote: > > Brian proposes a use case of serving only a warning message on the origin > endpoint, in order to minimize the load on IP addresses that are likely > hardcoded into a customer's zone. > So, the major update to add to this is: - We

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Fri, Aug 26, 2022 at 4:29 AM Ben Schwartz wrote: > > > On Thu, Aug 25, 2022 at 7:19 PM Viktor Dukhovni > wrote: > >> On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote: >> > Indeed it is a possible position to say that the Internet is not yet >> ready for semantically distinct

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Thu, Aug 25, 2022 at 1:35 PM Ben Schwartz wrote: > (Also, Brian's analysis indicates that the origin hostname's address > record TTL would bias the endpoint selection, but this is not correct.) > This statement intrigues me, and I think is highly relevant to the discussion. Could you

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Thu, Aug 25, 2022 at 1:35 PM Ben Schwartz wrote: > Thanks to Brian, Viktor, and others for the very close review, as always. > While I disagree with many of the claims made here, it's clear that some of > the text has proven confusing. I'm not familiar with the process rules > given the

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Aug 26, 2022, at 4:29 AM, Ben Schwartz wrote:On Thu, Aug 25, 2022 at 7:19 PM Viktor Dukhovni wrote:On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote: > Relatedly, the results presented by EKR [1] at the most recent DNSOP > meeting measure that 6.5% of

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Fri, Aug 26, 2022 at 07:29:06AM -0400, Ben Schwartz wrote: > > I also noted an issue around the initial $QNAME having prefix labels (in > > the case of SVCB rather than HTTPS), and so this is likely not the name > > you want appended as a fallback to the target list. > > > > Indeed, I think

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Thu, Aug 25, 2022 at 7:19 PM Viktor Dukhovni wrote: > On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote: > > > Relatedly, the results presented by EKR [1] at the most recent DNSOP > > meeting measure that 6.5% of Firefox users are unable to retrieve HTTPS > > records through their

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote: > Relatedly, the results presented by EKR [1] at the most recent DNSOP > meeting measure that 6.5% of Firefox users are unable to retrieve HTTPS > records through their local resolver. To me, this implies that functional > origin

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

Thanks to Brian, Viktor, and others for the very close review, as always. While I disagree with many of the claims made here, it's clear that some of the text has proven confusing. I'm not familiar with the process rules given the draft's current state, but perhaps we can improve clarity with

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Thu, Aug 25, 2022 at 7:58 AM Paul Hoffman wrote: > On Aug 24, 2022, at 7:14 PM, Brian Dickson > wrote: > > >> Are you saying that it was explicit after WG Last Call but changed? Or > during IETF Last Call and was changed? > >> > > No, I'm saying that, as far as I can tell, the flow was never

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Aug 24, 2022, at 7:14 PM, Brian Dickson wrote: >> Are you saying that it was explicit after WG Last Call but changed? Or >> during IETF Last Call and was changed? >> > No, I'm saying that, as far as I can tell, the flow was never explicit, and > that's a big part of the problem. > > And

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

I still disagree with the arguments for such a change being the ideal behavior. But rather than debating that further here, I will instead just argue that I do not believe any of this rises to the level of necessity for making technical changes at this late stage. This is not a case of "OMG!

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Wed, Aug 24, 2022 at 6:19 PM Paul Hoffman wrote: > On Aug 24, 2022, at 5:14 PM, Brian Dickson > wrote: > > "at this stage" is only the case due to the draft not being explicit in > the flow. > > Are you saying that it was explicit after WG Last Call but changed? Or > during IETF Last Call

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Aug 24, 2022, at 5:14 PM, Brian Dickson wrote: > "at this stage" is only the case due to the draft not being explicit in the > flow. Are you saying that it was explicit after WG Last Call but changed? Or during IETF Last Call and was changed? > Yes, this is a non-editorial change. Also

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Sat, Aug 20, 2022 at 1:29 PM, Paul Hoffman wrote: > On Aug 20, 2022, at 10:07 AM, Warren Kumari wrote: > > Pausing publication is an unusual, but definitely not unprecedented, step. > Although we are able to make changes until a document is published as an > RFC, once it is approved and sent

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

On Aug 20, 2022, at 10:07 AM, Warren Kumari wrote: > Pausing publication is an unusual, but definitely not unprecedented, step. > Although we are able to make changes until a document is published as an RFC, > once it is approved and sent to the RFC Editor, we should only make >