Hi Ben, thanks for the feedback, comments below... > On 16 Sep 2026, at 15:23, Ben Schwartz <[email protected]> wrote: > > > Thanks for bringing this draft to IETF for review. > > As a matter of process, I think this proposal is primarily relevant to > the HTTPBIS working group, and should be reviewed there, not here.
We’ve emailed the HTTPBIS chairs for advice, we can post there too in due course. > > On the content: It seems like the main potential benefit of this > proposal is to fail faster in certain cases, by skipping HTTP requests > that would return a 404 response. For this to work, the SvcParam > needs to be specified as an exhaustive list of all .well-known/ > endpoints on the host. (Otherwise, absence from the list does not > allow the client to skip the HTTP request.) However, many HTTP > origins have a large number* of resources available in .well-known, > which would result in bloated HTTPS records. Having a fixed list seems impractical as DNS server implementors would need to keep up with changes to registered well-known suffixes. One of the benefits we wanted to highlight is effectively saying these well-known suffixes are present, rather than a client trying one or more speculatively. So the thinking is a positive shortcut (“look this/these is/are available”) rather than a fail fast. Maybe that is a glass half-full vs. empty perspective though :-) > > There are also operational friction concerns: adding and removing > .well-known resources now requires updating two different systems, and > errors may occur when they disagree. That could also be said of ipv4hints, services might change IPs due to availability. So an operator of a service has the choice to use ipv4hints or not, probably dependent on how often they think change might happen. I don’t expect a service that is advertising capability by something like a URI ending agent-card.json would change too often, so the operator of that service would have a choice about using well-known dependent on the expected operational profile of that resource/service. > > Given these issues, and the obvious security concerns, Can you be specific with these concerns? We have some thoughts in the Security Considerations section of the draft, were you referring to these or something else? Once again thanks for the feedback. Cheers, Jim _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
