Subject: [OAUTH-WG] [oauth] #14: Restoring Client Assertion Credentials to the framework specification

From: "oauth issue tracker" <[email-masked]>
Date: Fri, 15 Apr 2011 15:37:23 -0000

#14: Restoring Client Assertion Credentials to the framework specification

 There was no clear consensus on the list to remove this.

-- 
--------------------------------+-------------------------------------------
 Reporter:  Tony Nadalin        |       Owner:                        
     Type:  defect              |      Status:  new                   
 Priority:  major               |   Milestone:  Deliver OAuth 2.0 spec
Component:  v2                  |     Version:                        
 Severity:  Active WG Document  |    Keywords:                        
--------------------------------+-------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/oauth/trac/ticket/14>
oauth <http://tools.ietf.org/oauth/>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 15 Apr 2011 09:31:17 -0700

Chairs,

I want to thank you for the re-introduction of the issues tracker. This will greatly assist in tracking issues and building consensus. Below is an example of a case where I thought consensus had been achieved, but arguably where the Tony and Mike continued to disagree. We always hope to have everyone agree, but in some cases, unanimous consensus may not be possible. In other cases, we may not have explored the problem far enough. It's clear to me, that the consensus process is important.

I hope that the issue tracker will help a lot in this area--but it may not be sufficient.

In the past, we have had email votes, but the feedback was these email votes are guidance only. This leaves me confused as to how consensus is being achieved.  Can the chairs clarify on what you believe the process is for the OAuth WG?

There is also an issue that at times consensus is asked for far too early when the proposals to be voted on are often unacceptable to a significant community (case in point, the scenario below). As everyone knows, I've been in the same position several times myself. I often have the view that the problem isn't being addressed. Before moving to a vote, there may need to be agreement on the problem definition first, any necessary constraints, and the requirements for a solution.  

I want to acknowledge everyone's efforts here. This has been a big specification with lots of issues to solve. We're at the end-game and it can be frustrating ironing out the final issues. I have greater confidence that items will be properly tracked and handled but would like to see the consensus process improved/communicated as well.

Best Regards,

Phil

Begin forwarded message:

> From: "oauth issue tracker" <[email-masked]>
> Date: April 15, 2011 8:37:23 AM PDT
> Cc: [email-masked]
> Subject: [OAUTH-WG] [oauth] #14: Restoring Client Assertion Credentials to the framework specification
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Barry Leiba <[email-masked]>
Date: Fri, 15 Apr 2011 17:45:17 -0400

Hi, Phil.  I'm glad you brought up this question, because it gives me
a good opportunity to clear up some points of IETF process.

> I want to thank you for the re-introduction of the issues tracker. This will
> greatly assist in tracking issues and building consensus.

We hope it will.  But, as you say, it's just a tool, and it's really
the participants who develop consensus, and the chairs who manage the
process.  Sometimes, again, as you say, we can come to agreement after
some discussion... but sometimes we get to a point where there's still
disagreement, and we have to see where the rough consensus is.  Not
everyone will always be happy, but we hope we can get a result that
most of us think will work and is technically sound.

> In the past, we have had email votes, but the feedback was these email votes
> are guidance only. This leaves me confused as to how consensus is being
> achieved.  Can the chairs clarify on what you believe the process is for the
> OAuth WG?
> There is also an issue that at times consensus is asked for far too early
> when the proposals to be voted on are often unacceptable to a significant
> community

Let me start by saying that people sometimes use the word "vote" as a
sort of shorthand term, but we need to be clear here: we do not "vote"
in the usual sense.  It's not just a semantic point, but something
that's central to how the IETF works.

We work on "rough consensus", and judging that is one of the jobs the
chairs have.  It doesn't go on a "one participant, one vote" line --
and remember, too, that participants here participate as individuals,
so let's not make the mistake of thinking about one or another
company's view (or, heavens, "vote").

Here's an example of what I mean by that: suppose we get to a point
where, say, 15 people have expressed opinions, and 8 of them fall on
one side of an issue, with 7 on the other.  If we were "voting", we
might say that the 8 votes win.  But in most cases we'd say "We don't
have rough consensus on this point."  In fact, depending upon the
issue and the arguments, 9 to 6, or even 10 to 5 might not be enough
for "rough consensus".  On the other hand, it doesn't have to be 15 to
0.  Where rough consensus falls is a judgment the chairs have to make,
on an issue-by-issue basis.  We might make that differently for a
cosmetic issue (the name of a protocol element, say) than for a
technical point that has a significant effect on the interoperability,
extensibility, or security of the protocol.

It's also up to the chairs to decide how long to let the discussion go
on, and when to make a consensus decision.  Participants are, of
course, free to offer their opinions on the matter, and I'm sure you
won't be shy about that.  But please, everyone: when someone does make
such a suggestion, take that as a message to the chairs, and don't act
on it unless it's the chairs who say it.  We will be the ones issuing
"last calls" for comments on issues, requesting straw polls when we
think we need to, and so on.

And, indeed, we might decide we need a straw poll to tease out the
support for particular points.  Remember that if we do that, it's not
a formal vote, and a slim majority won't necessarily "win".  See
above.

We also need your cooperation on reaching consensus.  If you see an
opportunity to accede to someone else's view in order to help reach
consensus on an issue, please do so.  There may be the occasional
issue you really feel it's important to dig your heels in on, but most
issues aren't like that, and some give and take will help get things
finished while keeping the result technically sound -- even if it's
not exactly as you'd like it to be.

Finally, the chairs don't always get it right, and if you think we're
cutting off discussion too soon -- or letting it run too long, beyond
the point where it's useful and productive -- please let us know.
Most of the time, it'll be best to tell us that *off* the mailing
list, to avoid adding to the already busy list traffic with
meta-discussion.  We'd rather keep the discussion on the list to that
which addresses the issues directly.  We'll make sure things are
recorded on the list for openness and archival purposes.

The most convenient way to contact all the chairs together is with the
tool alias: <[email-masked]>
Mostly, you needn't copy us on anything that's posted to the mailing
list, because we're all subscribed to it.

Barry, as chair