[Add] Followup from ADD session today

["Arnaud.Taddei.IETF" <[e-mail]>]

As a matter of fact today I was cut on the mic and yet after me, Barry had the chance to speak and then another person had the chance to speak so it gives me the continued appearance that it is difficult to work in the IETF.

So if I would have had the chance to speak, I would have asked the question regarding David's presentation that the approach taken here seems to particularly increase the centralisation effect and I would have asked clarification questions on the UX implications on how the user would chose the right DoH server from the vetted hard coded one vs the proposed new one, etc. which UX was expected, wondering how could it be done with a good UX in a situation of a expansion of modalities (this app is using this DoH server, this browser another one, my OS another one and now I am asked to make a choice !?! are we ‘customer centric’ ?). Not saying at all it is impossible, nor whether I like it or not but what was considered.

The other aspects are, as Vasily Dolmatov said, the fact that we are implicitly accepting a default of configuration at application level for 1.1.1.1, etc. is going to have a number of consequences that we probably do not measure yet completely in particular, I backup Vasily, that it will create interesting semantic issues between domains (application level vs infrastructure level) and I share his concern about the potential implications.

Another person made the good remark that it is a change on the architecture for applications and services overall and we should pause and discuss it and Jari pointed the problem of centralization which is a real problem to me too

So my question on another alternative to what David is proposing, is why don't we try to recognise that here we have general application configuration issue and this situation reminded me the infancy 25 years ago when mail and DNS where basically the 2 only services that could be offered to customers, citizens etc. and when we were missing so many pieces and it had many side effects on what we were trying to do like how to get clients to understand their own configuration. In this vein an application access protocol was created called ACAP which is still https://tools.ietf.org/html/rfc2244. it didn't meet any big success perhaps for the similar centralisation issues as we have today but in a different context at that time

I am surely very naive here but if what we are facing here are applications that need to find their DoH server and perhaps other resources, why are we not more ambitious and why don't we reconsider a protocol that is for application configuration and thus it could be managed by service providers, would keep the alignment to infrastructure semantics, would help to distribute the deployment, could avoid centralisation and could help the architecture?

My 0.02 CHF

Sent with [ProtonMail](https://protonmail.com) Secure Email.