Thinking through this some more, I'm skeptical that this is going to be that useful as a debugging-only feature.
In my experience, there are four major scenarios for diagnosing this kind of failure. Under the assumption that you control one end, the other end can be:
1. A live endpoint.
2. A testing endpoint someone has put up.
3. An endpoint that someone is actively working on with you.
4. An endpoint you control (e.g., you're running it on your own machine).
If this is a debug-only feature, then it won't be available in case #1, and it's not that helpful in case 4, because you can read the logs, errors, etc. yourself. For the same reason, it's not really that helpful in case #3, because you can just ask the person you're working with to read the logs, so this leaves case #2, which I agree can be annoying. However, what we've started doing with QUIC is just to have the endpoints dump their logs so that they're available on a co-located Web site. That gives you a lot more information than you'd probably want to fit in an alert message (e.g., you can print out the keying material, etc.)
I guess there might be some intermediate category 1.5 that's kind of in production so you don't want to print out complete logs, but you'd like more detail than you would probably want to expose in general, but my experience is that that's not super-common.
-Ekr
On Fri, Mar 30, 2018 at 7:16 PM, Peter Gutmann <pgut001@xxxxxxxxxxxxxxxxx> wrote:
Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com > writes:
>I agree with Eric’s assessment, this could be in a new draft as an extension.
Anyone want to work on this? I can contribute a bit by recycling the EtM
text, which sets out how to communicate a boolean flag (for "I speak extended
alerts") as an extension, apart from that you just need to define the alert
format, which I assume just means adding a free-form text field to the
existing alerts.
Peter.
