More edits.

[richsalz]

Required the endpoitn array to be all of the same type: alias or service entries. Do we want that??? Wording in the text is still contradictory, so we have to make up our minds :)

[bemasc]

At MUST level (syntactically), SVCB allows a mix of AliasMode and ServiceMode records. At SHOULD level (i.e. within present semantics), it allows either ServiceMode records or one AliasMode record. I think we should probably pick one or the other of those. Allowing multiple AliasMode records but not a mix seems like an odd middle ground.

I think there's a reasonable argument to be made that if we relax the semantic rules in the future, it would be good to be able to use the existing formats for WKECH, and maybe even the existing translators. That argues in favor of flexibility.

[richsalz]

I prefer a mix of Alias/Service records and agree about the flexibility and will post a fixup commit tomorrow.

If CDN-A has one ECH key for all its customers and CDN-B has one ECH key for all its customers and the origin is a customer of both CDN's, then you could use multiple Alias records, no?

[bemasc]

If CDN-A has one ECH key for all its customers and CDN-B has one ECH key for all its customers and the origin is a customer of both CDN's, then you could use multiple Alias records, no?

As specified, SVCB/HTTPS doesn't allow that. Instead, you need something like WKECH, so you can combine A and B's ServiceMode RRSets, and deliver the combination to your ZF with continuous updates.

[richsalz]

Right, oops, forgot about only one AliasMode. So I think the example of two alias entries should be fixed and you can then have

• Zero length array
• Array of length one (either alias or service entry)
• Array of length >1 (all service entries)

thoughts?

[bemasc]

It sounds like you're saying that we should let the format be flexible, but stick to examples that comply with all the SVCB SHOULDs. That seems like a good plan to me.

[richsalz]

Fixup commit pushed, please take a look.

[richsalz]

Do we want to insist on one regen interval for all ServiceMode entries? Different CDNs, for example, might regen keys differently. I'm fine with moving regeninterval to top-level as long as we're making an informed decision.

[bemasc]

regeninterval serves two purposes:

• It tells the ZF how frequently to poll for updates.
• It hints to the ZF how long a DNS TTL it should use.

Polling is necessarily requesting the whole JSON file, and the DNS TTL applies to the whole HTTPS RRset (all RRs must have the same TTL). If there were multiple regenintervals, the ZF would have to combine them somehow into a single number anyway. I think the origin is better placed to do that, since it knows where the contents are coming from.

[richsalz]

I made reginterval a top-level field, and pulled it out of the individual items in the endpoints array. The other part of that change is updating the IANA section, which will be in #29 shortly. But I believe I have addressed all your concerns (so far:) here.

[richsalz]

Merged by hand on my machine; too many merge conflicts. Closing this PR