Matt Caswell

> @mattcaswell I think adding a version prefix to the key would be the less confusing way to go, then each installation would just use their respective key. Ostensibly if...

Still no plans. I understand it is still in draft. Not sure what the timeline is for RFC publication. Perhaps @kaduk knows.

In principle yes, but my expectation is that this will be difficult to do in practice and would be a *significant* amount of work. On the on the one hand...

Responses from OTC: > Q for OTC: Do you have some advice on testing that I need to know? OTC: There are several different types of testing for DTLSv1.2 that...

> Sure. Good point. Please do create the branch. We're still figuring out ourselves how feature branches are going to work. As I said above: > So, we are expecting...

> But at this stage I see no API changes (other than the ability to select DTLS 1.3). Ok, good. > There might be some DTLS 1.3 configuration of the...

Pushed. Thanks. Autosquashing failed so I had to manually squash.

I think the concept of the ECHStore, broadly in line with what you are proposing, is the right way to go. I would call it `OSSL_ECHSTORE` instead though to avoid...

We don't need to expose any internal structure or fields of an ECHConfig or ECHConfigList. They can be entirely opaque with constructors for various sources (e.g. mem buffer or BIO)...

By passing the raw bytes around you have to parse it every time. Using an object you can parse it once, and just pass that object around from then on....