On Sat, Jan 9, 2016 at 1:40 PM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: > > On 10/01/2016 03:54, John C Klensin wrote: > ... >> Probably an excellent idea, especially since I can only see four >> possible outcomes from any given attempt: >> >> (1) "We know enough now, form the WG". In that case, we save >> calendar and meeting time and are able to get on with the work >> sooner. >> >> (2) "This is conclusively a bad idea or not ready for IETF work" >> or "it is now clear that no one other than the author cares". >> As with the above, saves time and allows us to get on with our >> lives. >> >> (3) "Don't know enough, need either another virtual meeting or >> an in-person BOF". In that case, we haven't really lost >> anything and probably have more information than we would have >> had from mailing list discussion alone. >> >> (4) "Couldn't make a determination, due eitherto lack of >> attendance by key people or some technical issue.". As with >> (3), little has been lost and we can always hold a physical BOF >> under traditional rules if needed. > > Speaking from the time-zone-challenged corner, I see a high risk > of hitting (4) rather frequently. Of course you can argue that > there is also a high risk of hitting (4) with face2face BOFs at > unpopular destinations. > > That said, it does seem worth a try. The objective of having a BOF should not be to decide on the proposition, it should be to decide what the proposition should be. Rather too often we end up with a process in which a small group of people decide they want to handle a particular problem in a particular way, they hold a BOF to decide on their approach which is generally run in a way that excludes other approaches or ensures that they have no chance of adoption and a working group is formed. At this point the group asserts that they have exclusive ownership of that particular problem and nobody else is to be allowed to work on it - period. I have a real problem with this approach. But when I complain I am told that this is 'unhelpful' and 'disruptive'. My problem with the situation is purely the exclusivity part. For example, there is in my view a very obvious and simple way to approach the problem of 'secure on first contact' TLS connections. This is to take the current mechanisms described in RFC 6797 and RFC 7469 and allow the exact same header data to be published as a DNS record. But no, this isn't allowed because the DANE group called 'dibs' on using the DNSSEC six years ago and nobody else is to be allowed to try a different approach. This despite the fact that none of the relevant software providers has expressed interest in the DANE approach while all the major browsers support HSTS and Chrome and Mozilla have already deployed HSKP. I did point out at the time that the group was formed that it would conflict with the security policy work being done on HTTP Strict Security. But I was assured that DANE would not be doing security policy. Then as soon as they were chartered they began doing security policy and loudly asserted nobody else could. This particular way of carrying on does not seem to be very helpful to me. Either we should allow a hundred flowers to bloom and for competing approaches to be pursued side by side or we should have a formal mechanism for resolving the conflicts that doesn't depend on being considered a 'team player'.