Re: [rrg] Recommendation and what happens next

Tony Li <tony.li@tony.li> Sun, 07 March 2010 19:26 UTC

Return-Path: <tony.li@tony.li>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4D5C28C1BE for <rrg@core3.amsl.com>; Sun, 7 Mar 2010 11:26:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijideVeMChRp for <rrg@core3.amsl.com>; Sun, 7 Mar 2010 11:26:44 -0800 (PST)
Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id DC22128C1A0 for <rrg@irtf.org>; Sun, 7 Mar 2010 11:26:44 -0800 (PST)
Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta03.emeryville.ca.mail.comcast.net with comcast id qKNa1d00A0cQ2SLA3KSpeX; Sun, 07 Mar 2010 19:26:49 +0000
Received: from [192.168.0.113] ([24.6.155.154]) by omta10.emeryville.ca.mail.comcast.net with comcast id qKSl1d00B3L8a8Q8WKSn2x; Sun, 07 Mar 2010 19:26:49 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Sun, 07 Mar 2010 11:26:43 -0800
From: Tony Li <tony.li@tony.li>
To: Robin Whittle <rw@firstpr.com.au>, RRG <rrg@irtf.org>
Message-ID: <C7B93DF3.4F45%tony.li@tony.li>
Thread-Topic: [rrg] Recommendation and what happens next
Thread-Index: Acq+LB5R2gAzH5Guo0Sttuk4GaTKkg==
In-Reply-To: <4B937C5C.5040501@firstpr.com.au>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: Lixia Zhang <lixia@CS.UCLA.EDU>
Subject: Re: [rrg] Recommendation and what happens next
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Mar 2010 19:26:45 -0000

Hi Robin,

> Short version:   Surely we should aim to do better than assume there can
>                  be no consensus.


That would be nice, but consensus building is a process, not an
instantaneous event.  It begins with debate, to be sure, but generally
involves people compromising to come together to back fewer and fewer
proposals over time.  We've seen none of that.


>> What I expect will happen will look like:
>> 
>>     - Some initial discussion
>>     - Presentation of the recommendation
>>     - Feedback afterwards
> 
> OK - I understand from this you have no clear idea of what will happen.


That's as clear as I can make it.  What were you hoping for?


>> Yes, it will undoubtedly be discussed after the meeting, probably for
>> several years.  ;-)
> 
> OK - but do you have a plan for when you will finalise the RRG Report?
> Discussions after that are a different thing from those before you and
> Lixia finalising it.


Hopefully, it's all editorial afterwards.


>> Given the lack of consensus that we have seen so far, there's not going to
>> even be a call for consensus.
> 
> Then how could you be sure that no consensus existed?


The discussions that we've had (both publically and privately) have made it
quite clear that everyone is simply going to back their own proposals.

Have you seen folks volunteer to withdraw their proposals and back another?
I can think of only one case.


>> I would expect that the RRG would continue on and address other routing
>> research issues.  The RRG has been a standing group for some time and has
>> looked at numerous issues.  This is only the latest work item.  Other
>> obvious things that may be taken up: prevention of micro-loops, multi-party
>> routing in mobile networks, etc.  I would expect that the next work item
>> would be under new leadership, more appropriate to the subject matter.
> 
> OK.
> 
> 
> It seems a curious plan to me - to assume there is no consensus, to
> assume the meeting will somehow produce a "Recommendation" and then that
> the meeting will debate it, but that there will be no test of consensus
> on the list or in the meeting.

As I've said before: we would like their to be consensus, but from an IRTF
perspective, it is not a strict requirement.
 
> Surely there's a role for the co-chairs in trying to establish what
> things people agree on and disagree on, and how the opinions of the
> various individuals can reasonably be grouped, or at least described.

Indeed.  This is, in part, the function of the document.

> I think there would be little point in developing a Recommendation
> which simply reflected the views of a subset of people, when there were
> multiple subsets with different, reasonably coherent views - since
> there's no way of choosing which subset's views to use for the
> Recommendation except by quite arbitrary means.

This is the choice we're left with.  Folks are unwilling to compromise yet
we need to make a choice.
 
> Even if we are highly divided, I imagine we could reach consensus on a
> Recommendation that the IESG consider, for instance, the three major
> bodies of opinion, which are irreconcilable.

That's a failure to make any decision, which is, itself, a failure.

> Then we could probably reach consensus that this statement was a
> reasonable summary of the major bodies of opinion amongst participating
> RRG members.  The Recommendation would not be to adopt a single
> architecture, but that the IESG consider the three or whatever types of
> approach which are most prominent.  I think this would be a useful
> thing to work on and to present to the IESG.

We disagree.  Our job is to present the IESG with a path.

Tony