On Mon, Aug 29, 2022 at 12:33 PM, Erik Nygren <erik+i...@nygren.org> 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 been a fascinating discussion, but I agree that there are no fundamental technical changes needed — there is nothing here that falling into the "OMG! That clearly doesn't work, 1+1 doesn't equal 17…" camp. With that said, the fact that we have had this robust of a discussion shows that there is ambiguity / different interpretations possible. No matter what we do, odd faults and misconfigurations will happen and > Postel's law applies. > Client implementers will try and be liberal with what they accept (as long > as doing so doesn't introduce > security issues, such as if you know you have bad data), and even then > some client implementers > may ignore this and still try to be robust. > > On the "how to sell this behavior", beyond giving client implementers the > ability > to be robust, there will be clients not implementing SVCB/HTTPS RRs > behavior for > a long time to come, so fallbacks will be needed for a long time. HTTPS > RR in particular > is specified as SVCB-optional. > > I think some confusion keeps coming from a desire to think of AliasMode > SVCB RRs > as "CNAMEs that can live at the apex" which they are not, even if they can > help solve > that problem. > Yes, that desire / area does seem to be a significant part of the confusion - but we did already discuss this topic in the WG before WGLC, and nothing seems to have changed. Brian, if I understand it right your 301 redirect approach seems like a > reasonable > way to address the fallback and legacy client case (and as clients pick > this up the need > for those redirects should decrease). > > 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 more clear to readers? For example, would having some examples > of the failure cases (without changing the semantics) help? > Note that since the fallback behavior is a SHOULD not a MUST for > clients, > it can't necessarily be relied upon. > … and that's what I'm trying to figure out — can we craft a sentence (or possibly two) which only clarify what is already written? Like "When we said 'Call me a taxi' we mean "Please summon a taxi", not "Ok, you are a taxi!" "... > * This might be too much of a technical change at this point, > but would it make sense to change the SHOULD to a MAY on client > fallback behavior? Clients implementations may choose to ignore the > SHOULD > so this doesn't change the contract. > Yes, I think that that would be too large of a change. If there was very strong and clear consensus from the WG that that is *obviously* the right thing to do we *could* do another WGLC and IETF LC *only* on that point, but I really really don't see anything approaching that level of consensus (nor do I think it is needed — SHOULD is very close to MAY in this case). > * 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 to the client on how to reach an instance > > of service. > Everywhere else in the normative sections such as 1.2 and 2.1 we > say that the TargetName is a "domain name" (aligned with the > clarification in rfc8499 > on the difference between host and domain names). > I think that the current is clear enough. I agree that it would probably have been better as 'domain name' if we had caught that at WGLC / IETF LC, but I think it would be gratuitous / not rise to the level of 'futzing after approval'... > On the rfc1123s2 front. a corner-case that might be encountered is that > Proxies might be confused by "When connecting using a SVCB record, > clients MUST provide the final TargetName and port to the proxy" > in the case where proxies don't expect a domain name (eg, with an > underscore prefix). > I don't know if there is any warning we should provide about this > corner-case, > or cover that in the future if it turns out to be a problem? > > > For the future, there are subsequent drafts that could be introduced: > > * We could add an optional "nofallback" SvcParam to AliasMode as Brian > suggests, > but in a future draft. (This would be the first SvcParam on AliasMode, > but they are allowed > and introducing them might help prevent ossification of this extension > point.) > Yup, this seems like a fine thing to consider putting in a -bis / Updates: document. * Introducing an optional "Alt-Used" equivalent (eg, "Service-Used") > that provides information about the SVCB/HTTPS RR path followed would > be very useful to service operators. We got stuck on not finding the > right > content vs privacy balance here, and experience with Alt-Used is that > not all clients will implement it regardless. But if we had this and got > enough clients to implement then it could help address some of Brian's > concerns > about getting better visibility in the fallback case. > (eg, "Service-Used: type=fallback" as an HTTP header) > Ditto. We may want to consider this in a new / update, but not in this doc. So, in summary: I don't see issues large enough to change any existing technical decisions, but I do think that the fact that we had this much discussion about interpretations (and that it wasn't just one person objecting to previous consensus) means that adding a simple clarification is justified. If someone proposes acceptable text in the next few days (and there is general consensus that it is just a clarification of existing behavior), I will ask the IESG to approve the addition. As a final note: While it is clearly doable to claw a document back from the RFC Editor (and we have to do it every now and then), it is uncomfortable, icky and can lead to drama. Let's try and make sure that we don't have to do this again.... W P.S: Thank you everyone for having kept this conversation / thread civil and constructive; I've been worried about the erosion of the IETF culture over time, and it's reassuring / refreshing to see it work well… > Erik > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
