Subject: Re: [nfsv4] rough consensus

From: <[email-masked]>
Date: Fri, 1 Oct 2010 12:46:57 -0400

I can work with "consensus" being a reserved word.  There are lots of
(near)-synonyms.

Note that Wikipedia had declared that B. L. Whorf's statements about a
large number of words for "snow" in Inuit (or is it Aleut?) has been
declared an urban legend (The language is agglutinative so what do you
expect? Duh.)  OTOH, I'm pretty sure the IETF will give them a run for
their money as we explore all the shades of possible levels of
agreement/support :-) 

-----Original Message-----
From: Black, David 
Sent: Thursday, September 30, 2010 6:11 PM
To: Noveck, David; [email-masked]
Subject: RE: [nfsv4] rough consensus

Dave Noveck,

> Let's move away from the procedural to the actual events.  I simply
noted it seemed that group
> consensus on the sparse file stuff was in favor but I didn't remember
it being formally put to the
> group.
>
> Now I can't prove it but I think that, in the past, Spencer would have
said he thought there was
> consensus and asked anyone who disagreed to speak.  Instead we got a
long recitation of Spencer's
> authority (a sort of "le groupe de travail c'est moi") which strongly
implied his total freedom to
> decide these matters and the changes in tone which I perceived (from
what someone has called the
> IETF "hippie principles"), I found quite disturbing and tried to
investigate where it came from.

I observe that it's usually a bad idea for anyone other than a WG chair
to attempt to determine, divine, state, etc. "consensus" of an IETF WG.
RFC 2418 is fairly direct on this point: "It is up to the Chair to
determine if rough consensus has been reached."  Independently trying to
determine rough consensus is rather inappropriate, and if that had
happened in a WG where I was a chair, I'd probably have been about as
blunt as Spencer was in discouraging it.  I also think Spencer was on
solid ground in declining to determine WG rough consensus for work based
on an expired draft.

It's quite possible that an unintended poor choice of wording
contributed to this situation - "consensus" is effectively a reserved
word wrt IETF process, and a word that's best avoided if there's any
doubt.  I suspect that if the original message had mentioned WG
"support" and absence of visible objection instead of "consensus", we
might not be having this discussion.

Skipping ahead ...

> I think the fundamental issue as I see it is between presentations
that treat the working group as a
> partner in the process with the co-chairs, even if not with same
powers, and those where the working
> group is simply not there, except as an object whose state is to be
judged based on the chairs
> feelings.  This was what we heard from Spencer.  He would decide
whether by a vote or Ouija board or
> whatever, and you could appeal which might possibly work in the case
if a Ouija board but probably
> not otherwise.

I concur on that fundamental issue - IETF is absolutely supposed to work
in the former fashion (WG as partner in the process).  I had read
Spencer's message as strongly discouraging consensus calls by those who
are not WG chairs, which (as a WG chair myself) I believe is
appropriate.

Thanks,
--David

> -----Original Message-----
> From: Noveck, David
> Sent: Thursday, September 30, 2010 4:07 PM
> To: Black, David; [email-masked]
> Subject: RE: [nfsv4] rough consensus
> 
> I certainly have an actual issue with the way that some of this has
happened, i.e. the tone and
> spirit in which the discussion has proceeded.
> 
> Let's move away from the procedural to the actual events.  I simply
noted it seemed that group
> consensus on the sparse file stuff was in favor but I didn't remember
it being formally put to the
> group.
> 
> Now I can't prove it but I think that, in the past, Spencer would have
said he thought there was
> consensus and asked anyone who disagreed to speak.  Instead we got a
long recitation of Spencer's
> authority (a sort of "le groupe de travail c'est moi") which strongly
implied his total freedom to
> decide these matters and the changes in tone which I perceived (from
what someone has called the
> IETF "hippie principles"), I found quite disturbing and tried to
investigate where it came from.
> 
> If his answer had been on the lines of yours, I would not have worried
very much.  The specific
> details of procedure do not bother me much so long the focus is on
responding to the group and
> getting the work done.  Maybe this was misperception on my part but I
felt something very different
> coming from Spencer.  We do have differences but I'll discuss them in
a small postscript.
> 
> It's not exactly that I worried about Spencer abusing his authority,
but that I was missing the
> Spencer I knew and wondered where he'd gone.  Also, I noted that if
someone were planning to abuse
> his authority, this would be exactly what he'd do.  Make great claims
of authority when there is no
> serious substantive issue and use those as a point of leverage when
there were such issues.
> 
> Spencer and I had an initial discussion and decided that it would be
best to hold any disagreement
> in abeyance until there was some issue of substance to disagree about.
At this point, we were in
> quasi-agreement, hadn't looked at RFC2418 and I had no need to do so.
> 
> At this point Mr. Harrington, despite Spencer's and my agreement and
his professed lack of desire to
> discuss such procedural matters added his voice, for what reason, I do
not know.
> 
> As to the difference between Mr. Harrington's remarks and RFC2418, my
perception is that there is a
> bit more that you do but that isn't the issue here.  We could discuss
that sensibly and with mutual
> respect and either come to a common conclusion or at least reduce our
differences to minimum.
> 
> The issue here is the difference in impression given by the selective
quotation that Mr. Harrington
> offered and a full reading of the corresponding section.  And when I
simply remarked on that, Mr.
> Harrington appeared to blow a fuse.  Rather than put forth his
contrary views, as you have done, he
> both refused to address my remarks and attacked for making them,
telling me where I'd be happier,
> etc.
> 
> People are different but if I (and I suspect you) had posted such a
selective quotation and somebody
> pointed that out, I would be mortified.  It would certainly apologize
to the group for giving them a
> false impression, even if it might later be argued that, in the more
complicated world in which that
> section was embedded, totality of the process was not changed in an
enormous way.  In addition I
> would very concerned to assure people that the fact that the limited
quotation omitted things
> discordant with my position was inadvertent.  Wouldn't you?
> 
> On the contrary, Mr. Harrington, far from offering apologies for
inadvertently misleading the group
> was offended that I read the document that he cited and that my that
view was different from his.
> This is not simply that our views were different and where he offered
arguments that his were
> correct. On the contrary, he absolutely refused to address my
arguments, and then offered his own
> somewhat disconnected set of arguments but it was pointless to address
them because it was clear
> that he treating anything I said with contempt.  He was not interested
in procedural debates he
> said, but he seemed to like one-sided procedural debates, since he
went on and on.  As to the IETF's
> "hippie principles", some of us have seen hippies who have discovered
coke and their principles
> rapidly evaporate.  The result here seemed analogous. (I am not
claiming anything about the cause.)
> 
> Don't know what else to say.  Part of our procedure is formal
decision-making and another part is
> civility of which serious and respectful attention to what others have
to say is the major part.  I
> thought that applied to co-chairs and AD's but the real question is
whether they do.  I'm not sure
> anymore.
> 
> P.S.
> 
> > > > Consensus can be determined by a show of hands, humming, or any
other
> > > > means on which the WG agrees (by rough consensus, of course).
> 
> > implies that the WG always actively "decides" the method:
> 
> If you add enough qualifiers, you can make anything false.
> 
> I don't think I said "actively".  If I did I withdraw it.
> 
> Also, we need to be clear that we are talking about what RFC2418 says,
at least that was what I was
> taking about.  That does speak of the working group deciding
something.  The part that Mr.
> Harrington posted did not and I felt that gave a false impression, not
only as to procedure but as
> the basic spirit of the approach.  Specifically, I don't feel that Mr.
Harrington's version in which
> only the chair is mentioned would ever have passed muster.  Do you?
> 
> > ... and he [WG chair] is required to use the method that the group
has decided upon ...
> 
> Again, if we are talking about what is in RFC2418, there is not a MUST
or REQUIRED but it does
> indicate that should be used.
> 
> I think the fundamental issue as I see it is between presentations
that treat the working group as a
> partner in the process with the co-chairs, even if not with same
powers, and those where the working
> group is simply not there, except as an object whose state is to be
judged based on the chairs
> feelings.  This was what we heard from Spencer.  He would decide
whether by a vote or Ouija board or
> whatever, and you could appeal which might possibly work in the case
if a Ouija board but probably
> not otherwise.
> 
> 
> I think the difference is between significant authority and unlimited
authority and the latter is
> almost never a good idea.
> 
> -----Original Message-----
> From: Black, David
> Sent: Thursday, September 30, 2010 12:39 PM
> To: Noveck, David; [email-masked]
> Subject: RE: [nfsv4] rough consensus
> 
> Dave Noveck,
> 
> As another WG chair, I have some experience and perspective on this.
I think you're splitting
> hairs, and in particular I don't think that RFC 2418's discussion of
WG agreement:
> 
> > > Consensus can be determined by a show of hands, humming, or any
other
> > > means on which the WG agrees (by rough consensus, of course).
> 
> implies that the WG always actively "decides" the method:
> 
> > ... and he [WG chair] is required to use the method that the group
has decided upon ...
> 
> I observe that while agreement with a proposed course of action is
part of making a decision, it is
> not the complete decision-making activity, as there first had to be a
proposal ;-).  Typically the
> WG chair has an initial proposal or preference for the method to use,
to which objections can be
> voiced (i.e., to the extent that a WG "decides" on a method of
determining rough consensus, it is
> often via absence of objection to the method that the WG chair
employs).  A WG chair who employs
> methods with which the bulk of the WG disagrees is liable to wind up
having a rather frank
> discussion with his responsible Area Director, at whose discretion
that WG chair serves (see RFC
> 2418).
> 
> Across the IETF, there are a variety of methods used to determine
rough consensus - at the end of
> the day, the important focus is whether the determined rough consensus
is accurate, as opposed to
> the process details of how it was determined.  If there is concern
that the determined rough
> consensus is incorrect, recourse is to the WG chair(s) and then the
Area Director, sometimes
> simultaneously ;-), beyond which there is a formal appeals procedure
for both process and technical
> issues, see RFC 2026.
> 
> All in all, I don't see a serious divergence between Dave Harrington's
remarks and RFC 2418 -
> between that RFC and RFC 2026, both WG Chairs and ADs have significant
authority, ability and
> flexibility to get things done, without detailed instructions on the
precise processes to be used.
> This is checked/balanced by AD oversight of the WG chairs and IESG
oversight of the ADs (including
> formal appeals if things really get out of hand).
> 
> Do you have an actual issue, or is this just a discussion of procedure
in principle?
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
> > Sent: Wednesday, September 29, 2010 10:34 PM
> > To: [email-masked]; [email-masked]; [email-masked]
> > Subject: Re: [nfsv4] rough consensus and the read sparse I-D RE:
nfsv4.x
> >
> > Your understanding doesn't match RFC 2418, which you cited.
> >
> > I get the impression, that you feel that your understanding, and not
> > RFC2418, is dispositive.  It isn't clear why, though.
> >
> > But since you don't want to debate the issue, there is no point in
> > proceeding.
> >
> > I guess the members of the working group need to confer privately
and
> > see how to proceed.
> >
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
Behalf
> > Of David Harrington
> > Sent: Wednesday, September 29, 2010 7:19 PM
> > To: Noveck, David; [email-masked]; [email-masked]
> > Subject: Re: [nfsv4] rough consensus and the read sparse I-D RE:
nfsv4.x
> >
> > 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 determining 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 intentionally 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 understanding 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
> > mull 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
> > [email-masked] (preferred for IETF)
> > [email-masked]
> > +1 603 828 1401 (cell)
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Wednesday, September 29, 2010 5:31 PM
> > > To: [email-masked]; [email-masked]; [email-masked]
> > > 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: [email-masked] [mailto:[email-masked]]
> > > On Behalf Of David Harrington
> > > Sent: Tuesday, September 21, 2010 11:26 PM
> > > To: 'Spencer Shepler'; [email-masked]
> > > 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
> > > [email-masked] (preferred for ietf)
> > > [email-masked]
> > > +1 603 828 1401 (cell)
> > >
> > > _______________________________________________
> > > nfsv4 mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/nfsv4
> > >
> >
> > _______________________________________________
> > nfsv4 mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/nfsv4
> >
> > _______________________________________________
> > nfsv4 mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/nfsv4
>