Re: [nfsv4] rough consensus
<david.noveck@emc.com> Fri, 01 October 2010 16:46 UTC
Return-Path: <david.noveck@emc.com>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E960C3A6BEB for <nfsv4@core3.amsl.com>; Fri, 1 Oct 2010 09:46:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.671
X-Spam-Level:
X-Spam-Status: No, score=-6.671 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjX6gQzYKByl for <nfsv4@core3.amsl.com>; Fri, 1 Oct 2010 09:46:51 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 7C7713A6AED for <nfsv4@ietf.org>; Fri, 1 Oct 2010 09:46:51 -0700 (PDT)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o91Glar5021956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <nfsv4@ietf.org>; Fri, 1 Oct 2010 12:47:37 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for <nfsv4@ietf.org>; Fri, 1 Oct 2010 12:47:25 -0400
Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.169.197]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o91GkwK8012088 for <nfsv4@ietf.org>; Fri, 1 Oct 2010 12:46:58 -0400
Received: from CORPUSMX50A.corp.emc.com ([128.221.62.39]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Oct 2010 12:46:58 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 01 Oct 2010 12:46:57 -0400
Message-ID: <BF3BB6D12298F54B89C8DCC1E4073D80027654D7@CORPUSMX50A.corp.emc.com>
In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E03D1B61614@MX14A.corp.emc.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [nfsv4] rough consensus
Thread-Index: ActRHg8QsQFN2KpTR1qRqMMkWrj5HgI5ygLwAYSFqJAABDX10AAHnYEgABwza7AABQO7QAAGUXKQACirDkA=
References: <E043D9D8EE3B5743B8B174A814FD584F09C3F21A@TK5EX14MBXC126.redmond.corp.microsoft.com><12DF0AF06D38492FB34731B462348640@23FX1C1><BF3BB6D12298F54B89C8DCC1E4073D80027650EE@CORPUSMX50A.corp.emc.com> <89B1192DD67049C284456E5A1D9C3EF4@23FX1C1> <BF3BB6D12298F54B89C8DCC1E4073D8002765140@CORPUSMX50A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E03D1B61426@MX14A.corp.emc.com> <BF3BB6D12298F54B89C8DCC1E4073D8002765321@CORPUSMX50A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E03D1B61614@MX14A.corp.emc.com>
From: david.noveck@emc.com
To: david.black@emc.com, nfsv4@ietf.org
X-OriginalArrivalTime: 01 Oct 2010 16:46:58.0156 (UTC) FILETIME=[433ABAC0:01CB6188]
X-EMM-MHVC: 1
Subject: Re: [nfsv4] rough consensus
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Oct 2010 16:46:54 -0000
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; nfsv4@ietf.org 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; nfsv4@ietf.org > 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; nfsv4@ietf.org > 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 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > -----Original Message----- > > From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] On Behalf Of david.noveck@emc.com > > Sent: Wednesday, September 29, 2010 10:34 PM > > To: ietfdbh@comcast.net; sshepler@microsoft.com; nfsv4@ietf.org > > 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: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] On Behalf > > Of David Harrington > > Sent: Wednesday, September 29, 2010 7:19 PM > > To: Noveck, David; sshepler@microsoft.com; nfsv4@ietf.org > > 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 > > ietfdbh@comcast.net (preferred for IETF) > > dbharrington@huaweisymantec.com > > +1 603 828 1401 (cell) > > > > > -----Original Message----- > > > From: david.noveck@emc.com [mailto:david.noveck@emc.com] > > > Sent: Wednesday, September 29, 2010 5:31 PM > > > To: ietfdbh@comcast.net; sshepler@microsoft.com; nfsv4@ietf.org > > > 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: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] > > > On Behalf Of David Harrington > > > Sent: Tuesday, September 21, 2010 11:26 PM > > > To: 'Spencer Shepler'; nfsv4@ietf.org > > > 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 > > > ietfdbh@comcast.net (preferred for ietf) > > > dbharrington@huaweisymantec.com > > > +1 603 828 1401 (cell) > > > > > > _______________________________________________ > > > nfsv4 mailing list > > > nfsv4@ietf.org > > > https://www.ietf.org/mailman/listinfo/nfsv4 > > > > > > > _______________________________________________ > > nfsv4 mailing list > > nfsv4@ietf.org > > https://www.ietf.org/mailman/listinfo/nfsv4 > > > > _______________________________________________ > > nfsv4 mailing list > > nfsv4@ietf.org > > https://www.ietf.org/mailman/listinfo/nfsv4 >
- [nfsv4] rough consensus and the read sparse I-D R… Spencer Shepler
- Re: [nfsv4] rough consensus and the read sparse I… Dean Hildebrand
- Re: [nfsv4] rough consensus and the read sparse I… Spencer Shepler
- Re: [nfsv4] rough consensus and the read sparse I… david.noveck
- Re: [nfsv4] rough consensus and the read sparse I… david.noveck
- Re: [nfsv4] rough consensus and the read sparse I… Spencer Shepler
- Re: [nfsv4] rough consensus and the read sparse I… david.noveck
- Re: [nfsv4] rough consensus and the read sparse I… Haynes, Tom
- Re: [nfsv4] rough consensus and the read sparse I… David Harrington
- Re: [nfsv4] rough consensus and the read sparse I… david.noveck
- Re: [nfsv4] rough consensus and the read sparse I… David Harrington
- Re: [nfsv4] rough consensus and the read sparse I… david.noveck
- Re: [nfsv4] rough consensus david.black
- Re: [nfsv4] rough consensus david.noveck
- Re: [nfsv4] rough consensus david.black
- Re: [nfsv4] rough consensus Nicolas Williams
- Re: [nfsv4] rough consensus Brian Pawlowski
- Re: [nfsv4] rough consensus david.noveck