Subject: [rrg] List of RRG rough consensus checks

From: Robin Whittle <[email-masked]>
Date: Fri, 17 Apr 2009 16:44:57 +1000

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

---

From: Scott Brim <[email-masked]>
Date: Fri, 17 Apr 2009 09:00:13 -0400

> which succeed and those which fail.

+1.  I already asked Tony to put the definitions results on the wiki.
Some history would be good too.