Pasi Eronen said: "On the other hand, I also think that just refusing to publish this document would be a highly unproductive approach. If the document solves a reasonable problem, the solution works, and it looks likely it will be widely deployed, I don't think preventing publication on minor process details would exactly "make the Internet work better"." I agree that not publishing this document would be unproductive, but I'm not sure I agree about the "minor process details" part. The IETF has processes in order to ensure fairness and due process. These details are not minor -- one might argue they are at the heart of what it means to be an open standards body. You do make a good argument that the TLS IANA considerations are producing results that are not very logical. If that's true, then we should fix this so that the results make sense to the community. Throughout the IETF we seem to be overwhelmed with the proliferation of rules which while originally created with good intentions, now contribute little to the fundamental business of the organization, and are contributing to the perception that the process is illogical and unfair. Adding a layer of exceptions on top in order to get enable smoother passage through the thicket will only make things even more complex; it might be preferrable to consider a defoliant. I'd also note that there is another TLS extension going for Proposed Standard that is in much the same situation: http://www.watersprings.org/pub/id/draft-salowey-tls-ticket-07.txt That document is also likely to be widely deployed, is largely backed by a single vendor, and has some issues that would require changes that may be difficult to make given the advanced state of development. Does it make sense to refuse to publish this document because of these issues? No. Is it important that the IETF treat such documents in a manner that is uniform as well as logical? Very much so. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf