Hi Pete,
At this point, a working week through the four week last call, I am wondering
whether the volume of comments and changes merit waiting for a revised version
before I do a last call review, or whether I should dive in with the current
version and risk raising a number of points already
On 10/11/13 2:04 PM, Adrian Farrel wrote:
At this point, a working week through the four week last call, I am wondering
whether the volume of comments and changes merit waiting for a revised version
before I do a last call review, or whether I should dive in with the current
version and risk
FWIW, on the issue of Informational RFCs seen as cast in stone:
I think I've seen that problem occasionally. I.e. people assigning a far too
high value to a document, just because it is an RFC. The world changes, our
understanding changes, and as Dave pointed out processes evolve… RFCs need to
Pete,
As usual, I really like your writing style, and I think you're
addressing a very important issue. There are two aspects that I would
suggest require further exploration, both having to do with the role of
the chair (the whole document has to do with the role of the chair, I
suppose):
1.
On Oct 9, 2013, at 1:30 AM, Melinda Shore melinda.sh...@gmail.com wrote:
Rough consensus - An agreement by almost everyone that the proposed
That's a lot like voting, I think.
It's worse than voting, because it encourages people to invite their friends to
sway the consensus. At least with
On 2013-10-09 20:35, Ted Lemon wrote:
On Oct 9, 2013, at 1:30 AM, Melinda Shore melinda.sh...@gmail.com wrote:
Rough consensus - An agreement by almost everyone that the proposed
That's a lot like voting, I think.
It's worse than voting, because it encourages people to invite their
On 10/9/13 4:35 AM, Ted Lemon wrote:
On Oct 9, 2013, at 1:30 AM, Melinda Shore melinda.sh...@gmail.com
wrote:
Rough consensus - An agreement by almost everyone that the
proposed
That's a lot like voting, I think.
It's worse than voting, because it encourages people to invite their
friends
On Mon, Oct 7, 2013 at 12:34 PM, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
On 08/10/2013 08:03, Ted Hardie wrote:
...
were. On the second point, the truth is that informational RFCs are
[not]
treated as actual requests for comments much any more, but are taken as
fixed;
On Mon, Oct 7, 2013 at 1:35 PM, Ted Lemon ted.le...@nominum.com wrote:
On Oct 7, 2013, at 3:34 PM, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
So I'd like to dispute Ted's point that by publishing a version of
resnick-on-consensus as an RFC, we will engrave its contents in stone.
On 10/8/2013 8:36 AM, Ted Hardie wrote:
And what are the RFC numbers for the comments? If none, as I suspect,
then the comments aren't the same status as the documents--that's fine
for RFC 791 and 2460, but it is not clear that Pete's document falls
into the same class. I would argue it does
On 10/7/13 10:48 AM, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'On Consensus and Humming in the IETF'
draft-resnick-on-consensus-05.txt as Informational RFC
I would like to perform a thorough review and provide more
On Oct 8, 2013, at 11:39 AM, Ted Hardie ted.i...@gmail.com wrote:
To be clear here, I did not think Pete's document was going for BCP.
Indeed, but you are speaking of it as if it were, which was my point.
Some comments in-line.
On Tue, Oct 8, 2013 at 8:47 AM, Dave Crocker d...@dcrocker.net wrote:
On 10/8/2013 8:36 AM, Ted Hardie wrote:
And what are the RFC numbers for the comments? If none, as I suspect,
then the comments aren't the same status as the documents--that's fine
for RFC 791 and
At 09:48 07-10-2013, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'On Consensus and Humming in the IETF'
draft-resnick-on-consensus-05.txt as Informational RFC
The IESG plans to make a decision in the next few weeks, and
On Oct 8, 2013, at 1:56 PM, S Moonesamy sm+i...@elandsys.com
wrote:
I am not sure whether hums are for a starting point or not. It can be argued
in different ways, for example, see Section 4. Humming helps to get a sense
of the room without people making a decision under duress.
On 10/8/13 3:21 PM, Fred Baker (fred) wrote:
To my small and somewhat naive mind, the difference between rough
consensus on a topic and a vote on the same topic is something about
winners and losers. In a purely political process, when a set of
parties vote on something and the preponderance
On Oct 8, 2013, at 8:23 PM, Melinda Shore melinda.sh...@gmail.com wrote:
I've done a lot of work on consensus over the years and I think
this is fundamentally correct, although I'd amend the last sentence
to something along the lines of While we may not all agree, those
who disagree can live
All,
FWIW - my personal way of thinking about consensus vd. rough consensus,
please note that it my personal view not a definition.
Consensus - An agreement by everyone in a group that a proposed
solution is the best of all of all possible solutions
Rough consensus - An agreement
On 10/8/13 9:20 PM, Loa Andersson wrote:
FWIW - my personal way of thinking about consensus vd. rough consensus,
please note that it my personal view not a definition.
Consensus - An agreement by everyone in a group that a proposed
solution is the best of all of all possible
On 2013-10-09 13:30, Melinda Shore wrote:
On 10/8/13 9:20 PM, Loa Andersson wrote:
FWIW - my personal way of thinking about consensus vs. rough consensus,
please note that it my personal view not a definition.
Consensus - An agreement by everyone in a group that a proposed
First, I am always happy when folks take the time to think deeply about the
IETF's processes and share those thoughts with the community. I think the
conversation this has already started has been useful, and I hope that the
last call conversation is the same.
That said, I do not think this
On 08/10/2013 08:03, Ted Hardie wrote:
...
were. On the second point, the truth is that informational RFCs are [not]
treated as actual requests for comments much any more, but are taken as
fixed;
I've inserted the not that Ted certainly intended. But I think he raises
an important point. If
On Oct 7, 2013, at 3:34 PM, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
So I'd like to dispute Ted's point that by publishing a version of
resnick-on-consensus as an RFC, we will engrave its contents in stone.
If that's the case, we have an even deeper problem than misunderstandings
Brian E Carpenter brian.e.carpen...@gmail.com wrote:
... If the phrase Request For Comments no longer means what it says,
we need another RFC, with a provisional title of
Request For Comments Means What It Says.
;^)
We still see comments on RFC 791 reasonably often, and I see comments
Ted Lemon ted.le...@nominum.com wrote:
On Oct 7, 2013, at 3:34 PM, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
So I'd like to dispute Ted's point that by publishing a version of
resnick-on-consensus as an RFC, we will engrave its contents in stone.
If that's the case, we have an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/7/13 5:23 PM, John Leslie wrote:
Ted Lemon ted.le...@nominum.com wrote:
On Oct 7, 2013, at 3:34 PM, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
So I'd like to dispute Ted's point that by publishing a version
of
On 10/7/13 6:23 PM, John Leslie wrote:
Oh my! I just saw the IESG agenda, and this_is_ proposed for BCP.
No, it's not. I'm just prolific this month. What you see on the agenda
is draft-resnick-retire-std1, not this document. That one *is* for BCP,
but draft-resnick-on-consensus
27 matches
Mail list logo
