The ticketrequests I-D is likely to be the second time Viktor (and others including me) have been told "do your own extension, we won't oppose it, make it an individual submission, whatever, have fun and leave us alone!".
There are several ways in which this attitude by the WG, by the relevant I-D authors, and by the chairs, are harmful. Let's focus on just one harm: feature matrix fragmentation. One could stop right there. No doubt we all understand exactly what "feature matrix fragmentation" means. Just in case though, let's flesh it out. Suppose we get enough of these "bleep off and do your own"[*] cases, and so after a few years we have some number N of specialty extensions, where N > M, where M is the number of extensions we would have had if the WG's attitude had been more constructive. What would that mean for application developers, and for TLS stack developers / maintainers? Well, an app developer might say "hey, I need these three extensions", look, and find that no TLS stacks implement all three. Sadness ensues. Now the app developer might need to implement support for one or more extensions in some open source TLS stack and wait a few months/years for that to be integrated and ship. Or worse! the app developer might have to wait for a vendor to implement and ship. And TLS stack devs/maints will have a nasty time of it too. Besides having a hard time approaching 100% feature matrix support, they might find that some extensions don't fit their stacks' APIs very well and require significant rototilling or worse, not even attempting to support those extensions. The latter is what happens when substantive feedback is ignored by the WG. And yet that is a major reason we should want WG and IETF review: so that such impedance mismatches can be avoided where possible. Undoubtedly there is a cost to accepting substantive feedback. E.g., delay and extra labor costs. But that cost is limited by the process that we have (only timely and substantive feedback needs to be considered). This cost mostly affects us, WG participants, and implementors, while the feature matrix fragmentation problem's costs affect primarily users and implementors. On balance, I believe feature matrix fragmentation is easily the costlier problem. Maybe we want to consciously and explicitly accept this feature matrix fragmentation issue, in which case here is a humble proposal: that all TLS IANA registries be made Expert Review only, and that the TLS WG stop accepting work items that don't involve substantial changes to the protocol. If the only objections or improvements we'll allow are security or privacy concerns, but implementors' and users' concerns are to be excluded, then we're impliedly headed towards feature matrix fragmentation. Besides, allowing authors to dictate what is and is not in-scope for their documents is practically the same as rubber- stamping, which is... not what we are supposed to be doing. In any case, it's NOT OK for authors to refuse to consider substantive feedback. WGs should police reticent WG work item editors and authors. I know, because I've been an editor/author who disliked where the WG was headed with an I-D of mine and I had to accept it. Indeed, I was threatened by a WG chair with removal as editor. I don't see why other authors should not be subject to the same treatment. That's not spite but right. Oh, and a word about the social harms caused by your attitude: there goes good will. Appeals, end-less and bitter [email protected] threads, more rather than less WG work item review specifically to find wrenches to throw into the gears at the worst possible times -- these are things that the aggrieved might resort to. That's not a threat: I'm not a maintainer or developer of a TLS stack, so I'm more likely to leave this WG alone if it insists on its current approach than to spend my precious time on fighting it. Nor can I or do I speak for anyone else. But I can imagine someone taking a scorched earth, spiteful approach, and if they do, you best bet I'll be eating popcorn and cheering them along. Nico [*] No has one said "bleep off", but that's clearly the message being sent, and it's certainly the message that's been received. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
