Voting - no specification without representation

[Hallam-Baker, Phillip]

Brian writes:

>It would be a problem if a design team or directorate (which are
>explicitly not open, as Phill says) proposed a solution that did
>not meet rough consensus in the WG or at IETF Last Call and then
>the IESG put that solution on standards track. That would in fact
>be a major violation of RFC 2026.

My problem is with the transparency of the process, not specifically
the issue of whether it did or did not violate RFC 2026. In my view
and according to a litteral reading of RFC 2026 the process was 
violated, but it is the violation of the spirit of openness that 
led to calls for the WG chair to resign (and not just from me).

I agree that the above would be a violation, but when a protocol
has yet to be deployed the use of the same tactics to defend the
status quo is an exactly equivalent abuse. According to RFC 2026
the directorate is appointed by the AD and reports to the ADs
alone. There was a technical violation of 2026 in that the WG chair
had no business referring anything to the directorate, even though
he is AD in another area.

The problem is that the referal was done without any notice to
the working group and was used to supress the consensus that the WG
had then reached to forward OPTIN to the IESG for approval.

So while everyone in the group is waiting for the draft to go to
the IESG it is actually stalled in a private queue of the chair's
invention.

In a commercial environment a delay can have exactly the same 
effect as a veto.


I do not believe that this behavior would survive judicial review.
If it is as you claim consistent with RFC 2026 then RFC 2026 needs
urgent modification to correct it. 

A process that allows the chair to pocket WG decisions that he has
a partisan position against and then recycle the question until he
can pretend that the result was the one he wanted is not open by
any definition I consider credible.


Or forget the process issue for a moment, look at the outcome of
of the process. For me the main point in a standards process is 
to obtain the buy in of all the parties necessary to deploy an
interoperable spec. In this case the IETF has by its refusal to
insist on an open and fair process ended up with a spec that is
not going to be supported by the operators of the largest zones
in its current form.

That is not a successful result in my view. To get XKMS adopted as
an industry standard I had to spend a considerable amount of time
working out how my direct and indirect competitors would benefit
from supporting it - as well of course as my partners.

The result of this 'consensus' process is an undeployable spec 
that is not supported by the principal industry stakeholders.


This outcome is every bit as bad as any that is alledged for OSI
process. Only instead of having a vote and moving on the issue
has simmered for three years already and is far from over.

My experience of voting in OASIS is that it is rarely divisive.
I have not seen the type of vote packing that has occurred in WAP
this is probably because you have to attend the con-calls to 
vote.

		Phill

PS: If you think that the appeals process is not equally broken 
then why not prove me wrong by making the appeal yourself?