On Fri, Aug 4, 2017 at 8:37 PM, Christian Huitema <huit...@huitema.net>

> Clearly, Section 2 could be turned into some kind of 'problem statement"
> draft. I personally don't like splitting problem statement and proposed
> solution in separate documents, but if that's the group consensus, why not.
I don't think it need be split into a separate document. Indeed, I think
explaining the design space and the reasons for that a specific design was
selected should be welcomed in an RFC.

What makes this document distinct are the sentences like "SNI encryption
designs MUST mitigate this attack." This appears to be constraining /other/
documents by saying that such designs are not merely unattractive (in the
views of the author), but forbidden to be considered.

The IETF does do such policy documents from time-to-time, but not mixed
with a technical document like this in my experience.

> If it wants to be a technical document, then the draft includes two very
> different designs with a note saying that one will be chosen at some point.
> So which are we talking about adopting? While drafts evolve during the WG
> process, there's a big gap between the two ideas and I'd support one but
> not the other.
> My goal was to list the current state of solutions. The document could be
> split with different drafts presenting different solutions, but I believe
> there is value in an attempt at unification.

Eventually we have to pick one, right? I feel that drafts are generally
more opinionated before a call for adoption, although the chairs might well
feel that the design-space span is this document is focused enough already.



Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
TLS mailing list

Reply via email to