On 4/10/18 3:53 PM, Nico Williams wrote: > The earlier consensus is not just applicable, as if it were, we would > not be having this LC.
I have no idea what that even means, to be honest. We're through last call, and it's not that the earlier wg consensus isn't "applicable," it's that you've raised new issues. So let's be clear about that. I've been watching this discussion and trying to get a handle on what's been going on (and how this fits into several other IETF issues more generally), and I think this discussion would be over if the people arguing in favor of changing the use of the extension had plans to implement it. But so far nobody has said that they do. It's been suggested that if we intend to stick with the original, intended use we can just ignore the extra bytes, which strikes me as an exceedingly odd argument for including new protocol features. It's unfortunate that over in DNS-land they're discussing how to get rid of unused features that increase complexity, while over here we're having a discussion of how to add unused features that increase complexity. I think those of us who care about the institutional effectiveness of the IETF and the value of the standardization process care quite a bit about the amount of time it takes to push a document through to publication. Aside from negatively affecting the chances of the success of a given protocol, it's harmful to the standards process more broadly and discourages participation from people who want to get work done. There's an unfortunate number of IETF protocols that people worked on for years and that never saw implementation, and it seems to me that we ought to be trying to minimize the chances of that happening with the protocols we're working on. I haven't seen anything in this discussion that leads me to believe that the extension as specified is fundamentally broken or insecure for its intended use. I'm good with adding clarifying text or scoping it more clearly, but beating this thing to death for a use case that nobody intends to implement seems a bit misguided to me. Melinda -- Software longa, hardware brevis PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls