Can we clarify the Misconfiguration section?

[taddhar]

I am really struggling with this section and before I try again to make a proposal (I failed 3 times on my side) I will ask questions here and then see if and how I can make a proposal. Again consider WHO is the target audience of this section, not TLS developers or people who have been 30 years in it. Operational people will be either completely lost OR worse they will believe they understood which won't be the case.

I understand too we can't expand too much the text here but now it is reaaally too compact to read it from non-expert side.

So to guide the help I need, here are a few questions.

In the clause

"The retry mechanism repairs inconsistencies, provided the server is
authoritative for the public name. If server and advertised keys mismatch, the
server will reject ECH and respond with "retry_configs". If the server does
not understand
the "encrypted_client_hello" extension at all, it will ignore it as required by
{{Section 4.1.2 of RFC8446}}. Provided the server can present a certificate
valid for the public name, the client can safely retry with updated settings,
as described in {{rejected-ech}}."

Can somebody provide me with a precise definition of the term the server is authoritative for the public name

Can somebody clarify me If server and advertised keys mismatch and give me some example. Good example of where you have to build in your brain, which server, which keys, why can they mismatch, etc. remember not everybody is a TLS developer or 30 years in it. Especially for WHO is the audience of this section.

Can somebody clarify me can present a certificate valid for the public name.

Finally can someone give an example after

Unless ECH is disabled as a result of successfully establishing a connection to
the public name 

[ekr]

See #602.