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 _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg