Short version: List of messages in which I think rough consensus
has been declared.
draft-irtf-rrg-design-goals-01 is now 1 3/4 years
old and resulted from very little discussion.
I don't think consensus for this document was
formally established. I made a bunch of
suggestions after version 01 which were never
discussed.
Hi Tony,
In a recent message "Re: Point of order" you wrote that you couldn't
recall or find any record of a consensus judgement you made:
http://www.ietf.org/mail-archive/web/rrg/current/msg04836.html
I think it is best not to rely on memory. I suggest there be a list
of consensus tests / votes / judgements on the wiki - both those
which succeed and those which fail.
You also wrote, to Bill:
> Thank you for finding that. Your Google-fu is clearly stronger
> than mine. ;-) As is your memory. ;-) Please note that this is
> significantly different than "fix it for IPv6 first".
>
> As we did not, at the time, do an explicit consensus check on that
> at the time, you're well within your bounds to call for a formal
> check.
You didn't take a vote, but you did write:
> It's my judgement that we have rough consensus on this.
and since you are a co-chair, that's it: rough consensus has been
declared, with or without votes.
It is not unreasonable for Bill, others and me to assume "fix IPv6
first" as an implication of:
Our recommendation should be applicable to IPv6. It may or
may not also apply to IPv4, but at the very least must provide
a path forward for IPv6.
Below my signature are links to messages in which I believe you made
judgements about consensus. I don't remember any more. BTW, I am
searching my RRG archive in Thunderbird - not using Google.
I don't recall any consensus test resulting in no consensus - but you
have made statements identifying things which have not been tested
and which I agree we probably wouldn't or didn't have consensus on.
I haven't listed these in general, but one message linked to below
has a few such items.
One notable thing we haven't got formal consensus on is the RRG's
Design Goals (2007-07-08):
http://tools.ietf.org/html/draft-irtf-rrg-design-goals-01
Between the initial version 00 and the 01 version which you seem to
be happy with, not counting your messages (or Heiner Hummel's which
did not suggest improvements) I counted only 14 messages from 7 people.
A week after your version 01, I wrote a bunch of suggestions:
http://www.ietf.org/mail-archive/web/rrg/current/msg00203.html
but they were never discussed.
When Lars Eggert wrote in April 2008 questioning whether there was
consensus on rrg-design-goals-01, you wrote:
http://www.ietf.org/mail-archive/web/rrg/current/msg02117.html
> I must admit that I don't follow the RRG very closely very
> often (it requires a full-time commitment), but I don't
> remember the discussion around this document resulting in
> a consensus.
There was some discussion, but not a great deal of contention.
The comments did taper off, and that was taken as a sign of
rough consensus by yours truly.
...
We intentionally did not issue it as an RFC so that it could
be kept open for further changes. Suggestions are still
welcome.
Maybe a vote now would reveal rough consensus in support of your
version 01, but I think it resulted from very little discussion and
it would be a good thing to revise now - or perhaps to replace with
the new Recommendations document.
- Robin
2007-06-21 BGP convergence and messaging
-----------------------------------------
http://www.ietf.org/mail-archive/web/rrg/current/msg00166.html
Robin Whittle wrote:
> Then, maybe we wouldn't be so unhappy about BGP's
> convergence rate and the number of messages - which are
> two of the primary reasons we are having to invent a
> new routing and addressing architecture.
I don't believe that we have anything like consensus on that
view. In fact, rough consensus (as of Prague) was quite the
contrary: convergence and messaging _can_ be handled without
architectural changes.
http://www.ietf.org/mail-archive/web/rrg/current/msg00169.html
Yes, the consensus was that the dynamics do NOT require
architectural changes. This was based on the discussion during
the routing area meeting.
2008-05-23 Mapping granularity
------------------------------
The original text is here:
http://www.ietf.org/mail-archive/web/rrg/current/msg01870.html
I didn't follow the discussion or find where the final text was that
we supposedly achieved consensus on.
http://www.ietf.org/mail-archive/web/rrg/current/msg02241.html
There are a few things that we have consensus on and even then
there are contingencies on that consensus. Specifically, for
the mapping function, we have consensus that we should support
host specific identifiers, as well as blocks.
The next statement of consensus was retracted in a subsequent
message:
We also have consensus that mapping systems that there should be
active mechanisms for dealing with overload situations.
(See this message for various things for which there was no consensus.)
2008-06-14 Solution for IPv6 definitely, IPv4 maybe
----------------------------------------------------
http://www.ietf.org/mail-archive/web/rrg/current/msg04836.html
Last week we did a consensus check on the following:
|Our recommendation should be applicable to IPv6. It may or
|may not also apply to IPv4, but at the very least must provide
|a path forward for IPv6.
It's my judgement that we have rough consensus on this.
There is dissent, notably from Robin and Bill, but overall, it
seems that we have rough consensus.
http://www.ietf.org/mail-archive/web/rrg/current/msg02500.html
Hi Bill,
> I counted:
>
> 9 for
>
> 3 accept with the reservation that the IPv4 and IPv6
> solutions should be identical
>
> 4 offering other reservations
>
> 3 against
>
> That's a pretty weak consensus. Are you sure you want to
> roll forward without seeking a statement that more than
> a minority can agree to without reservations?
I admit that it's rough consensus, for varying definitions of
'rough'. ;-)
I wasn't trying to take a vote, just express my sense of where
we stand. If it becomes critical at some point and folks feel
that it's necessary, I'm more than happy to put things to a
formal vote.
2008-09-04 End-user networks not required to "renumber"
-------------------------------------------------------
http://www.ietf.org/mail-archive/web/rrg/current/msg03365.html
Our consensus check on renumbering has been running for
several weeks now and seems to have converged. The result is
a clear consensus for no renumbering.
Of 15 participants, 10 people voted exclusively for no
renumbering, 2 voted for no renumbering and another option,
and 3 voted for other options.
I find this to be a clear (if rough)
However, see below for confusion about what this meant.
This message (Consequences of no renumbering...):
http://www.ietf.org/mail-archive/web/rrg/current/msg03377.html
indicates you considered "renumbering" includes the once-off
renumbering to adopt the new namespace. I thought "renumbering"
meant having to renumber every time the end-user network chose
a new ISP:
http://www.ietf.org/mail-archive/web/rrg/current/msg03393.html
So I am not sure that this supposed consensus really means
anything.
This next message seems to indicate you understand
"renumbering" in terms of when changing ISPs, not in terms
of a one-off renumbering to adopt the scalable address space:
http://www.ietf.org/mail-archive/web/rrg/current/msg04185.html
> So can we just say that solutions above the network
> layer (including shim6, sctp and multipath transport)
> are simply out of scope: the RRG has decided not to
> work on them. Anything else is speculation.
Except that that's not exactly true. The RRG has not exactly
declared them out of scope. So far, solutions that are above
the networking layer require per-host renumbering, and we have
consensus that those solutions are not acceptable. If someone
figured out an architecture (possibly combining automated
renumbering technology) that fixed things above the network
layer in an acceptable fashion, we would definitely consider
it.
2008-11-08 Mobility not on the agenda?
--------------------------------------
http://www.ietf.org/mail-archive/web/rrg/current/msg03854.html
In previous discussions, I believe that we came to the
consensus that RRG is not trying to solve the full-blown
mobility problem. The rate of dynamism is higher than what
we'd really like to support in any mapping function.
(I vaguely recall rejection of mobility as a goal, but I don't
recall it being put to a consensus test. Your apparent
assumption that the mapping would change whenever the MN gets a
new CoA is not valid. No-one has suggested how a core-edge
separation scheme could work like that - which involves the
assumption that the ETR function is in the MN.
Please see: http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf
for how a core-edge separation scheme can support a global
approach to mobility, for IPv4 and IPv6, with mapping changes
only when the MN moves 1000km or so.)
2009-04-15 Terminology: locator, identifier & address
-----------------------------------------------------
http://www.ietf.org/mail-archive/web/rrg/current/msg04724.html
The definitions being voted on.
http://www.ietf.org/mail-archive/web/rrg/current/msg04781.html
The poll has now closed. The ayes have it, 10 to 4 (71%), which
is reasonably clear consensus. The definitions listed are
hereby adopted.
Also of interest:
2009-01-02 Notes on the consensus determination process
http://www.ietf.org/mail-archive/web/rrg/current/msg04185.html
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
