Short version: What objections are there to having two or more well written, generally non-overlapping, ~500 word critiques for a proposal if the authors can't figure out a way to express all their concerns in a single ~500 word piece?
Also, would there be any problem in attributing authorship of the one or more critiques? I understand the plan for Summary, Critique, "Rebuttal" and Reflection. What is the plan for debate and hopefully achieving rough consensus (or better than rough) support for a choice of a single proposal (or maybe two or more?) to recommend to the IETF? The options for altering the architecture to achieve scalable routing and addressing are tightly bounded by the installed base and by the need for widespread voluntary adoption. My page on some of these constraints: http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ has been fine-tuned as a result of considerable RRG discussion. As far as I know no-one objects to this attempt to express the real constraints we are operating within. Quite a few people expressed their support for this attempt - though of course we all wish there were no such constraints. I suggest that we work on a version of this to be included in the RRG Report, which the co-chairs will hopefully be able able to find rough consensus support for. Could the Report include a section near the front classifying the proposals into various groups? Hi Lixia and Tony, I support more than one critique being included in the RRG Report. After all the words which have flowed on this list - many of them of no lasting consequence regarding scalable routing - I can't see a problem with the RRG Report containing more than 500 words of critique, or more than one critique, for each proposal. Some proposals are still without a critique - though I hope to write one for each of these as soon as I can. Some proposals are so extensive and potentially important - in that they have a chance of being chosen as the future Internet architecture - that they really should have more than 500 words devoted to assessing them. This can easily be shown by the fact that two or more people are motivated to write their own critiques. RFCs are composed entirely of recycled electrons. They will take up space in IETF servers and search-engine databases for decades or centuries to come. But so does every message on this list. As long as each critique is reasonably well written and contains significant material which is not found in the other critiques - and and as long as those who wrote them would prefer their own critiques and those of others to appear alongside each other to the prospects of just one being chosen, or some attempt to jam all the ideas into a single body of 500 words - then what objections are there to the Report including multiple critiques? You decided on the 1000, 500, 500, 500 word format for Summary, Critique, "Rebuttal", and Reflection. No-one but Tony seems to have insisted on the 500 word limit, or the need for just one critique - so I am not suggesting a change to against anything which has been decided by consensus. My LISP critique is in the current draft of the Report: http://tools.ietf.org/html/draft-irtf-rrg-recommendation-04 and Noel Chiappa's: http://www.ietf.org/mail-archive/web/rrg/current/msg05747.html isn't, simply because I wrote mine before Noel wrote his. I don't want Noel's critique to displace mine, nor mine to displace his. I think they are both perfectly good critiques and there is only a small amount of overlap. I want Noel's critique included in the Report. Likewise any other similarly thoughtful critique of LISP or any other proposal. I also suggest that these critiques be attributed to the people who created them. The RRG Report needs to be adopted by consensus, and I won't fully support a final version which I think is missing a significant critique such as Noel's or my (not yet finalised) critique of Name Based Sockets. Similarly, Javier's critique of Name Based Sockets is in the current draft and mine is not, simply because Javier wrote his first. I do not want my critique to displace Javier's. As far as I know, he doesn't want to exclude mine from the Report either. I don't want to have to try to jam my concerns into a single piece of text which Javier would also be happy with. There is a diversity of opinion on what needs to be critiqued in each proposal - and there's no point in trying to force consensus or give the appearance of consensus when none exists. I might support collaboration on a single critique if there was no 500 word limit. I think it would be better to have a 500 word limit - if you must have one - and to allow multiple critiques. If you persist with the current plan, then the RRG Report will reflect arbitrary choices between multiple perfectly good critiques. Furthermore, the Report would not attribute the single critique to any author - which would imply that the text resulted from collaboration and reflected rough consensus. You and Tony have already changed your plan by accepting a proposal very late - RANGER. No-one seems to object to this. You have also accepted five proposals which are not actually proper scalable routing proposals: Evolution - Aggregation with Increasing Scopes This does not claim to solve the scaling problem - it is a number of suggestions for reconfiguring routers to achieve benefits which are very slight compared to the scaling benefits we need, but which may prove valuable while not getting in the way of a proper solution. Enhanced Efficiency of Mapping Distribution Protocols ... In the submission (msg05540) K. Sriram noted that this was intended for archival purposes: "I do not intend it to be a contribution for the mainstream set of proposals for a solution for scalability. . . . My main intent in submitting this proposal/document is for archival value." 2-phased mapping Layered Mapping System (LMS) Compact routing in locator identifier mapping system As with "Enhanced Efficiency ..." these three are for mapping systems only, not full proposals. I am not opposed to the inclusion of these five which were submitted despite Tony noting twice (msg05513, msg05496) that a mapping system alone is not a complete solution. I don't understand how you could be so relaxed about space concerns when including these five, and then be so concerned about space as to disallow the inclusion of multiple critiques for those complete proposals which people are most concerned about. Agreement and support is a rare commodity on this and many other discussion lists. I think my attempt to list a particular subset of the constraints we face: http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ achieved good support from a number of people. No-one argued that the list was not reflecting reality, though constraints 8, 9 and 10 are "sliding scale" constraints, where the partial failure to meet them only reduces the chance of success, rather than eliminates it. I suggest that the RRG Report contain a version of these for which the co-chairs can find consensus support for. I can work on rewriting it into a suitable form for a section in the Report - but would be happier if someone else did it, or at least helped me with it. It could be an appendix, but I think these constraints are important enough to be near the start of the Report. Also, I think the Report would be enhanced by some guidance near the start, which again would need to be supported by RRG consensus, on the nature of the proposals. I haven't yet read all the proposals, but my thoughts on this are: Core-Edge Separation (CES) architectures v4 v6 Ivip v4 v6 LISP v6 RANGER v4 v6 TIDR Core-Edge Elimination (CEE) architectures v6 GLI-Split v4 hIPv4 v6 ILNP v6 Name Based Sockets v4 v6 Name Overlay Service v6 RANGI Proposals concerning only mapping distribution systems 2-phased mapping Compact routing in locator identifier mapping system Enhanced Efficiency of Mapping Distribution Protocols ... Improving router utilization as a prelude to adopting a solution Evolution - Aggregation with Increasing Scopes Can you articulate your plans for how the RRG will discuss and hopefully achieve consensus support for a choice of which proposal to recommend to the IETF? Tony has written several times that the aim if for a single recommendation. There's only four or so weeks left. - Robin _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg