Re: Virtual BOFs

[Phillip Hallam-Baker <[e-mail]>]

On Sat, Jan 9, 2016 at 1:40 PM, Brian E Carpenter
<[e-mail]> 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'.