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

From: Spencer Shepler <[email-masked]>
Date: Fri, 10 Sep 2010 19:27:35 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Friday, September 10, 2010 11:51 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [nfsv4] nfsv4.x
> 
> I believe that going ahead with this has rough working group consensus,
> although the matter has not been formally put to the group in just that form
> (probably because it seemed as if there was no v4.2).  I think it should be put
> to the group and those objecting should have an opportunity to raise their
> objects.
> 
> There have been a number of messages in which v4.x requirements were
> specified in terms of rough WG consensus plus some set of other things.
> This raises confusion as the sets mentioned are not always the same and it
> isn't clear who would doing the judging as to whether those were met.
> I think it would make things a lot simpler if we said the requirement was
> rough WG consensus, period.  Statements that sufficient interest and activity
> are important, or working code is important could then be understood as not
> in addition to WG consensus but simply part of the discussion explaining
> what considerations were most important to the specific individuals raising
> these as important issues for everybody to consider.

Note that determination of rough consensus is the purview of the
working group (co-)chair.  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; however, it is up to the co-chairs
to determine the best method of rough consensus for the group, etc.

As for read sparse, it is clear that there is support for the ideas but there
is still work to be done as to the details -- taking the opportunity to
point out that the referenced draft has expired.

Spencer

---

From: Dean Hildebrand <[email-masked]>
Date: Fri, 10 Sep 2010 13:21:24 -0700

important issues for everybody to consider.
> point out that the referenced draft has expired.
Sounds good.

Regarding its expiry, officially the draft says it expires in September 
2010, with no specific date.  Can someone let me know how to determine 
what exact day it expired?

I have the following issues queued up to address before I submit a new 
version:
1) Text describing use with pNFS layouts and striping
2) Possible use of READ EOF return value

Please let me know if anyone has any other issues regarding this draft.

Some issues I would like to hold off until it is part of the NFSv4.2 
RFC. For example, at the last WG meeting some people voiced support for 
also adding information regarding an offset and length for the previous 
allocated block.  It is unclear to me that it is common whether many 
applications could take advantage of this information (they would have 
to sequentially read the file, block by block, from end to beginning.  
So I'm all for adding it, but maybe these are discussions that need to 
happen with an actual NFSv4.2 draft.

I would also like to voice support for an incremental improvement from 
Mike's req's draft:

"Hints for the type of file access, such as sequential read.  While
       traditionally NFS servers have been able to detect read-a-head
       patterns, with the introduction of pNFS, this will be harder.
       Since NFS clients can detect patterns of access, they can advise
       servers.  In addition, the UNIX/Linux madvise() API is an example
       of where applications can provide direct advice to the NFS server."

I think would be a perfect fit for the server DIRECT I/O support I 
discussed in Maastricht
http://www.ietf.org/proceedings/78/slides/nfsv4-1.pdf

Dean

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 10 Sep 2010 20:30:10 +0000

> Of Dean Hildebrand
> Sent: Friday, September 10, 2010 1:21 PM
> To: [email-masked]
> Subject: Re: [nfsv4] rough consensus and the read sparse I-D RE: nfsv4.x
> 
> > asked by the AD for a positive show of support via the WG alias as a
> > method of ensuring there was support; however, it is up to the
> > co-chairs to determine the best method of rough consensus for the group,
> etc.
> >
> > As for read sparse, it is clear that there is support for the ideas
> > but there is still work to be done as to the details -- taking the
> > opportunity to point out that the referenced draft has expired.
> Sounds good.
> 
> Regarding its expiry, officially the draft says it expires in September 2010,
> with no specific date.  Can someone let me know how to determine what
> exact day it expired?

Bottom of each page of the I-D:  "Expires September 1, 2010"
:-)

> Some issues I would like to hold off until it is part of the NFSv4.2 RFC. For
> example, at the last WG meeting some people voiced support for also adding
> information regarding an offset and length for the previous allocated block.
> It is unclear to me that it is common whether many applications could take
> advantage of this information (they would have to sequentially read the file,
> block by block, from end to beginning.
> So I'm all for adding it, but maybe these are discussions that need to happen
> with an actual NFSv4.2 draft.

Please address the issues in of themselves.  Assume that the work is
to be included in the next minor version and move forward -- this is to
encourage complete, stand-alone I-Ds such that we avoid delaying
progress for something that is not "technical".

> I think would be a perfect fit for the server DIRECT I/O support I discussed in
> Maastricht http://www.ietf.org/proceedings/78/slides/nfsv4-1.pdf

Further discussion on the WG alias is a good next step and/or an I-D
that captures the details would also be a good next step.

Spencer

---

From: <[email-masked]>
Date: Fri, 10 Sep 2010 18:19:14 -0400

> however, it is up to the co-chairs

And other things?  What other things might be included in that?  Maybe
you think I'm paranoid,  but I'd argue that a sole-discretion-phobia is
not necessarily dysfunctional.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Spencer Shepler
Sent: Friday, September 10, 2010 3:28 PM
To: [email-masked]
Subject: [nfsv4] rough consensus and the read sparse I-D RE: nfsv4.x

a method of ensuring there was support; however, it is up to the
co-chairs

As for read sparse, it is clear that there is support for the ideas but
there
is still work to be done as to the details -- taking the opportunity to
point out that the referenced draft has expired.

Spencer

---

From: <[email-masked]>
Date: Fri, 10 Sep 2010 18:34:05 -0400

I don't see what about getting to the v4.x stage would make this any
easier to resolve.

> For example, at the last WG meeting some people voiced 
> support for also adding information regarding an offset 
> and length for the previous allocated block. 

They did.

> It is unclear to me that it is common whether many 
> applications could take advantage of this information 
> (they would have to sequentially read the file, block 
> by block, from end to beginning. 

I don't think anybody said that it was all that common but they felt
there were some important applications where it would be a big a help.
It might help if these people would send mail detailing the uses they
anticipate.
 
> So I'm all for adding it, 
> but maybe these are discussions that need to 

If people have objections they should be able to express them now.  I
assume that they would still have the opportunity to express objections
as part of v4.2 group-last-call if they thought about it and found some
issues, but it would be best if anybody who knows of any objections
would express them now, and if there aren't, then let's add it now.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dean Hildebrand
Sent: Friday, September 10, 2010 4:21 PM
To: [email-masked]
Subject: Re: [nfsv4] rough consensus and the read sparse I-D RE: nfsv4.x

co-chairs
> As for read sparse, it is clear that there is support for the ideas
but there
Sounds good.

       of where applications can provide direct advice to the NFS
server."

Dean

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 10 Sep 2010 22:54:28 +0000

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, September 10, 2010 3:19 PM
> To: Spencer Shepler; [email-masked]
> Subject: RE: [nfsv4] rough consensus and the read sparse I-D RE: nfsv4.x
> 
> And other things?  What other things might be included in that?  Maybe you
> think I'm paranoid,  but I'd argue that a sole-discretion-phobia is not
> necessarily dysfunctional.

My impression is that you are pre-optimizing.  My suggestion is to
raise a question if a future rough consensus decisions seems inappropriate.

My attempt in providing earlier comments about NFSv4.x was to
provide for a wider range of activity than what had been occurring. 

Spencer

---

From: <[email-masked]>
Date: Sat, 11 Sep 2010 08:53:55 -0400

> My impression is that you are pre-optimizing.  My suggestion 
> is to raise a question if a future rough consensus decisions 
> seems inappropriate.

OK.  I'll do that.

> My attempt in providing earlier comments about NFSv4.x was 
> to provide for a wider range of activity than what had been 
> occurring.

I think that's an excellent goal.  Since the term "consensus" gets us
into disputed waters, let me just say that I believe the overwhelming
majority of the working group agrees.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Spencer Shepler
Sent: Friday, September 10, 2010 6:54 PM
To: Noveck, David; [email-masked]
Subject: Re: [nfsv4] rough consensus and the read sparse I-D RE: nfsv4.x

> And other things?  What other things might be included in that?  Maybe
you

My impression is that you are pre-optimizing.  My suggestion is to
raise a question if a future rough consensus decisions seems
inappropriate.

Spencer

---

From: "Haynes, Tom" <[email-masked]>
Date: Sat, 11 Sep 2010 21:17:02 -0500

> majority of the working group agrees.  

Hummmmmmmm

---

From: "David Harrington" <[email-masked]>
Date: Tue, 21 Sep 2010 23:26:20 -0400

> 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)

---

From: <[email-masked]>
Date: Wed, 29 Sep 2010 17:31:28 -0400

> 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

+1

+1

David Harrington

---

From: "David Harrington" <[email-masked]>
Date: Wed, 29 Sep 2010 19:18:50 -0400

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

> Sent: Wednesday, September 29, 2010 5:31 PM
> To: [email-masked]; [email-masked]; [email-masked]
> > 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.
>   
> 
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of David Harrington
> > 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
> support via 
> > the WG alias as a method of ensuring there was support;
> 
> +1
> 
>    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

---

From: <[email-masked]>
Date: Wed, 29 Sep 2010 22:33:55 -0400

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,

David Harrington

---

From: <[email-masked]>
Date: Thu, 30 Sep 2010 12:39:21 -0400

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

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
----------------------------------------------------

> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, September 29, 2010 10:34 PM
> Spencer was determining consensus, he would speak up. And I am obviously
> authority, or deliberately or intentionally misuses the authority they
> have been delegated.
> 
> be a lawyer. If you believe my understanding is wrong, then feel free
> mull this over yourself; you don't need to include me in your
> [email-masked] (preferred for IETF)

---

From: <[email-masked]>
Date: Thu, 30 Sep 2010 16:06:49 -0400

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. 

> 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

> ... 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

Of [email-masked]

---

From: <[email-masked]>
Date: Thu, 30 Sep 2010 18:11:26 -0400

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

> From: Noveck, David
> Sent: Thursday, September 30, 2010 4:07 PM
> To: Black, David; [email-masked]
> 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.
>
> 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?
>
> 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.
>
> 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:
>
> 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).
>

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 30 Sep 2010 17:33:01 -0500

On Thu, Sep 30, 2010 at 06:11:26PM -0400, [email-masked] wrote:
> [...]
> 
> 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.

+1 David Black's comments.

I believe it is appropriate for a participant to request a consensus
call.  I believe it's also appropriate for a participant to voice their
opinion as to what the consensus is.  Statements such as "<WG chair
name>, I believe you'll agree with me that there is consensus on this
question" are fair enough, though of course such statements are not
authoritative, and the chair may well disagree with them.

Even statements such as "there is rough consensus for X" from non-chairs
are allowable -- they just aren't authoritative, and therefore not
useful.  It's much better to qualify such statements accordingly, and
it's even better to request a formal determination of consensus.

The relevant I-D's authors would do well to submit a new version, then
request whatever procedure is appropriate.  E.g., if it's not a work
item and the authors wish it were, then ask for a consensus call
regarding that, or, if the authors think the I-D is ready, they could
ask for a WG Last Call, and so on.

As far as I can see, there's nothing to see here.

Cheers,

Nico
--

---

From: Brian Pawlowski <[email-masked]>
Date: Thu, 30 Sep 2010 18:09:43 -0700 (PDT)

I don't see any action in this e-mail chain to take. An interesting 
discussion though.

David did speak for me correctly. Spencer and I talk about directions
and such in the working group. And what amount to decisions.

I recall early on (very early on - 6+ years ago) that we could not
agree on one or two points - I don't believe we ever took them
to the mat in an argument about consensus. The faint recollection
I have was I think a practical request from the V4 chairs for the
disagreeing parties to go off and strike a compromise in one instance.
(I would really have to dig up very old e-mails on specifics).
So we avoided the "51%" issue.

I also recall that we deferred some item because never mind consensus,
we couldn't get agreement on approach or a proposal that anyone
felt had legs.

I'll tell you more of what has practically been a problem - not the
issue of consensus, but of interest. This I think is more what
we have wrestled with - no objection to a technical proposal (feature,
tweak etc.) - but lack of interest of others to take up the proposed
feature and consider implementing it. Spencer and I have spent a fair 
bit of time in discussion with Lars (mostly recently) about taking
on WG items. This I think has been our more pressing issue.

Dave, if you're going to Beijing we can find time to curl up. I must
owe you any number of lunches/dinners if you would like to go off
and discuss.

>From my perspective, the NFS V4 WG has mostly worked, and has been
very collaborative, and I am most proud that all the participants
are committed to prototyping proposals and doing frequent testing
to shake out protocol changes and enhancements from an implementation
perspective. Perhaps it is this very active prototyping and testing
that has tended to drive the protocol towards "consensus" because
the developers are overlapping dev and specification and removing
so many uncertainties from the process.

See everyone in Beijing!
beepy