Re: [rrg] Recommendation and what happens next

[Robin Whittle <[e-mail]>]

Hi Tony,

You wrote:

>> 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.

OK - but where have you encouraged debate, or contributed to it by
arguing for your own preferred position?  I understand you support
ILNP (CEE, Locator / Identity Separation) - which are only practical
for IPv6.  I am not sure what you want for IPv4.

Consensus doesn't involve just compromise - at least in the sense of
people giving up on what they really want, and going along with less
enthusiasm for something they think would be inferior, but not as bad
as other alternatives.  It also involves people changing their minds
about what is practical and desirable - including recognising their
own proposal is not suitable for IETF development or for the
long-term future of the Net.

Quite a few people who contributed proposals to the RRG have
indicated they recognise their proposal is not sufficiently developed
to be considered for IETF development - I think this is true of the
mapping-only proposals and the CES proposal TIDR.  So they may well
be happy to support some other proposal.


Some previously active proposals were not submitted for this phase of
RRG consideration:

    Eliot Lear (msg05274) retired NERD from active development.

    APT was retired because the designers couldn't see how ISPs would
    be motivated to make the initial investment.

    Bill Herrin didn't develop TRRP any more or submit it for RRG
    consideration.

    Christian Vogt dropped Six/One Router and developed Name Based
    Sockets.  I don't know whether he still wants Name Based Sockets
    considered for IETF development, because he hasn't written to the
    RRG since 13 January.


>>> 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?

Since you are one of the co-chairs and you are urging us - indeed
expecting us - by so-far unspecified methods, to develop and in some
way be happy with a single-architecture Recommendation in the next 19
days, I was hoping you would be able to give us more guidance about
how to debate this, including leading by example: by arguing in
detail for your own preferred outcomes.  Lixia has done this for her
AIS (Evolution) proposal.


>>> 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.

You haven't yet stated when you and Lixia intend to finalise the text
of the RRG Report, at which point you will choose what, if anything,
goes in the Recommendation section.  Nor have you explained how you
will choose the text, or guide the mailing list or meeting discussions.

Do you intend to finalise the Recommendation during the meeting, or
afterwards?  If the former, than I am concerned that those not at the
meeting will be at a disadvantage through not being able to be
express our arguments as directly as those who can attend.  If the
latter, do you have any plans for how long after the meeting you will
finalise the text?


>>> 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.

This is a statement about the past.  If this continues for the next
few weeks, then there will be no large enough subset of active RRG
participants with a compatible opinion to form anything like
consensus.  But I doubt that everyone would hold to their own
proposals in the context of a detailed, constructive, debate - a
debate we are yet to have.

We already know that some of the proposals are not real proposals
which could be considered for IETF development - those which just
concern mapping systems:

   Compact routing in locator identifier mapping system
   Layered mapping system (LMS)
   2-phased mapping
   Enhanced Efficiency of Mapping Distribution Protocols in
   Map-and-Encap Schemes

There are three other proposals which are neither CEE or CES:

   hIPv4
   Name overlay (NOL)
   Evolution - Aggregation with Increasing Scopes (AIS)

hIPv4 involve changes to hosts and DFZ routers.  (I don't recall
whether it requires changes to applications).  NOL involves changes
to some routers and to applications.  There's no way these can
compete with CES proposals which involve no host stack or application
changes.

I am yet to read the response to my critique of AIS, but I can't see
how it could cope with the reasonable goals of portability,
multihoming and inbound TE for 10^7 non-mobile networks, much less
mobility for 10^9 to 10^10 MNs.

There are four CEE proposals:

   GLI-Split
   ILNP - Identifier-Locator Network Protocol
   Name-Based Sockets
   RANGI

These are only for IPv6 and are all subject to the critique that they
burden all hosts with extra delays and packets.  Also, they require
all hosts to be changed before there are substantial benefits to
adopters or to scalable routing.

None of the proponents of these architectures have argued why their
proposal should be accepted for development and deployment ahead of
any or all of the CES architectures.  CES works for both IPv4 and
IPv6, involves no host stack or application changes, and (at least
with Ivip and LISP) provides full benefits to adopters irrespective
of the level of adoption, and scalable routing benefits in proportion
to their level of adoption.

That leaves four CES architectures:

   IRON-RANGER
   Ivip
   LISP
   TIDR

TIDR can't solve the routing scaling problem because its "mapping" is
almost identical to advertising individual end-user network prefixes
in the DFZ.  I have argued that IRON-RANGER is not yet sufficiently
developed to understand its security and scaling challenges - and
there's no apparent method of supporting packets sent from
non-upgraded networks.  As far as I know, there have been no
substantial counter-arguments to these critiques.

There is a coherent argument in my msg06162 why only LISP and Ivip
could be considered for IETF development, why the distinguishing
architectural elements of Ivip are superior to those of LISP and why
Ivip or similar should be preferred over all other proposals for IETF
development.

No-one, including the LISP folks or any CEE proponent, has responded
to this yet.  Any constructive debate will involve people reading
opposing views and responding to them in detail.


Your statement:

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

may be true of the recent past.  But surely it is your task - a
difficult and perhaps thankless one - to improve on this pattern of
people turning their back on real debate, ignoring other people's
proposals and simply restating their positions, without properly
engaging in debate about why their proposal is better than all the
others.


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

Sure - but I am talking about the future, between now and whenever
you finalise the RRG's Recommendation.


>> 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.

OK - but if you and Lixia include text as a "Recommendation" without
a process which tests support for it - or if there is such a test and
it only gets minority support - then the "Recommendation" won't have
much value or be taken particularly seriously by the IESG or anyone else.


>> 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 don't recall you or Lixia write anything about what various groups
of people have in common and where they differ.

Classifying the proposals into groups is a way of starting this
process.  I did this in msg06162 and neither of you have commented on
this.


>> 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.

Your statement is about the past and you seem to have no hope or plan
for improving on this currently bleak situation.  In a recent message:

  Why won't supporters of Loc/ID Separation (CEE) argue their case?
  http://www.ietf.org/mail-archive/web/rrg/current/msg06187.html

I suggested how you, as co-chair, could lead by example in arguing in
detail for the position you support - including arguing in detail
against the arguments (such as msg06162) for opposing positions.


>> 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.

Sure - but if that is the best we can do, then surely it would be
better to produce a coherent report on the various positions which
people have adopted, with the arguments each group advances in
support of their position, and the arguments they provide against the
positions of others.

To pretend that the situation involved more agreement than it really
does would be a worse failure.

Also, I think it would be a failure if this situation of isolated,
disengaged, groups of people or individuals persisted due to lack of
hope or guidance from the co-chairs about how to constructively
debate the issues so that people might change their mind, or at least
articulate the reasons for their positions better than they have so far.


>> 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.

You seem to think the only useful thing the RRG can do is present the
IESG with a single chosen architecture to develop.

You seem to believe that it it will be impossible to get consensus
agreement to any such single architecture recommendation.

Yet you intend to produce such as single architecture recommendation
- and expect RRG members to be happy with this.

You have no apparent plan - and do not lead by example - for debating
the issues, trying to identify commonalities and differences etc.

You have even stated that you don't plan to test for consensus.

I think that is an extraordinary statement to make.  It hardly
encourages people to engage in the RRG process if you are planning to
choose some text as the RRG Recommendation which doesn't result from
consensus and which you don't even plan to test for consensus support.

  - Robin