Re: [nfsv4] rough consensus and the read sparse I-D RE: nfsv4.x

["David Harrington" <[e-mail]>]

Hi,

It is my understanding that the chairs are authorized to oversee the
process, including how consensus will be determined. They are overseen
by me and the rest of the IESG to make sure their approach is
reasonable. The IETF way is to invest significant authority in the WG
chair position, because the rough consensus of the IETF is that this
is the best way to ensure progress on our technical standards, without
being hamstrung by lots of procedural debates (as many other SDOs can
be). 

Spencer is not the only chair. Brian is also a chair, and they confer
with one another. I am quite sure that if Brian objected to how
Spencer was determing consensus, he would speak up. And I am obviously
watching the list to see what is happening as well, and I am
conferring with Lars on a weekly basis about any concerns I have, and
Lars and I confer with the IESG about any concerns we have. So there
are people watching to make sure no one person gets too much
authority, or deliberately or intentially misuses the authority they
have been delegated.

I don't feel like getting into a fully documented legal argument with
you about the process rules right now. I have never had any desire to
be a lawyer. If you believe my understandoing is wrong, then feel free
to appeal the chair's decision about how to determine consensus.
Personally I think that would be a tremendous waste of everybody's
time, and would greatly delay the progress of the NFS standards, but
it's your right to appeal if you want.

If you want to worry about such things, feel free. Here's a problem
for you mull over ... if the WG were charged with deciding how
consensus should be decided, and the WG could not achieve consensus on
how to determine consensus, how would the WG make progress? Please
mullt this over yourself; you don't need to include me in your
mulling, because I'm not worried about this. And you are free to
appeal that advice from me if you want. 

If you really LIKE procedural debates, come see me at ietf79. I'll
recommend some SDOs where you'll fit right in!

I don't mean to seem flippant, or to seem as if I don't care about
your concerns. I do. A great deal. Which is why I watch to make sure
the chairs are doing their jobs correctly. But, based on my
understanding, they have not in any way misused their authority, and I
have no cause for worry. I think there are higher priority things -
things that are important right now - that I should spend my time on
than this procedural debate.

David Harrington
Director, IETF Transport Area
[e-mail] (preferred for ietf)
[e-mail]
[phone] (cell)

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: Wednesday, September 29, 2010 5:31 PM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [nfsv4] rough consensus and the read sparse I-D 
> RE: nfsv4.x
> 
> From RFC2418:
> 
> > Consensus can be determined by a show of hands, humming, or 
> any other 
> > means on which the WG agrees (by rough consensus, of course).
> 
> So the method of determination is up to the working group, by 
> rough consensus.
> 
> > It is up to the Chair to determine if rough consensus has been 
> > reached.
> 
> You see the problem here.  If the working group decides that 
> a show of hands is to be used, and it is up to the Chair to 
> determine if rough consensus has been achieved, we have a 
> potential contradiction.  Either the working group choice is 
> a nullity, or we have a situation in which the working 
> group's choice must be respected and the role of the chair is 
> one of judgment, and he is required to use the method that 
> the group has decided upon, and the data provided by that 
> method.  He is given latitude in where he draws that line but 
> RFC 2418 does give him the following guidance. 
> 
> > Note that 51% of the working group does not qualify as "rough 
> > consensus" and 99% is better than rough.
> 
> Thus the chair is not free to decide that 51% of the working 
> group qualifies as a rough consensus, or simply decide based 
> on his own wishes.
> 
> I am not saying that that has ever happened, but the 
> assertions that I am hearing about the Chair's authority do 
> not seem to make it clear that he must work within that 
> framework of rules, and respect the working group's decisions.  
> 
> This is not a personal issue.  Spencer has indeed respected 
> the working group's decisions but Spencer may not be the last 
> chair the working group will have and it is best not to rely 
> on personalities when dealing with governance issues.  I 
> recall Boss Tweed saying that he didn't care how the people 
> voted, as long as he got to do the counting.  I am a worrier 
> about such issues.
>   
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of David Harrington
> Sent: Tuesday, September 21, 2010 11:26 PM
> To: 'Spencer Shepler'; [e-mail]
> Subject: Re: [nfsv4] rough consensus and the read sparse I-D 
> RE: nfsv4.x
> 
> 
>  
> > Note that determination of rough consensus is the purview of the 
> > working group (co-)chair.
> 
> +1
> 
> From RFC2418:
>    A number of procedural questions and issues will arise 
> over time, and
>    it is the function of the Working Group Chair(s) to manage 
> the group
>    process, keeping in mind that the overall purpose of the 
> group is to
>    make progress towards reaching rough consensus in realizing the
>    working group's goals and objectives.
> 
> > There have been occasions
> > where I have been asked by the AD for a positive show of 
> support via 
> > the WG alias as a method of ensuring there was support;
> 
> +1
> 
> and appeals are possible:
>    Formal procedures for requesting a review of WG, Chair, 
> Area Director
>    or IESG actions and conducting appeals are documented in 
> The Internet
>    Standards Process [1].
> 
> David Harrington
> Director, IETF Transport Area
> [e-mail] (preferred for ietf) 
> [e-mail]
> [phone] (cell)
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>