-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Vince Fuller Sent: Thursday, April 22, 2010 5:17 PM
[[WEG]] <snip> Incidentally, I would be also interested in seeing the opinions of RRG members on how to move forward with this. Given four options: 1. publish the document as-is as an RRG recommendation to the IETF 2. remove RRG references and publish as an individual contribution 3. split the document as described above 4. none of the above (please describe an alternative) [[WEG]] I say option #1, or option 4, with option 4 defined below. Sorry in advance for the longish email, but there's a lot to discuss. My reasoning for #1 - RRG did not reach consensus. Failing the chairs making a recommendation, this would have been a filibuster - endless debate blocking progress, and it would have gone on indefinitely. It's time to move on. RRG is not helpful to the community if it waits so long to make a recommendation that the problems which brought us here in the first place start becoming reality before IETF has a chance to implement anything to fix it, nor is it helpful to simply have one proposal outlast the others by wearing them out in debate. I'm a relative outsider on this list. I dropped off the list for nearly a year because I couldn't keep up with the volume, and then rejoined prior to the Anaheim meeting in the lead-up to the recommendation. Whether that gives me any sort of unique perspective or not I leave to you to decide. However, I can say that I have *still* seen some of the same arguments go around in circles since I rejoined, and I don't see any compromise in sight. I'm by no means trying to minimize the contributions that anyone made to RRG, nor make a statement on the quality of each proposal, but... My sense of what happened here is that those who came up with proposals were so convinced that their idea was the right one that they either DOS attack us with email in support of it in the belief that someone is only against the idea because they don't understand it well enough, or were simply unwilling to compromise in such a way as to come up with a uniform recommendation that takes the best parts of several ideas and combines them. It may be that they believe (right or wrong) that their solution is incompatible with the others, but I find it hard to believe that two proposals in the same class [referencing Anaheim presentation for classification] could not find any common ground in implementation. Thus, we end up with 15(!) separate proposals, and deadlock. So to phrase that another way, a chair recommendation is the tiebreaker so that we can start moving forward. If your proposal wasn't chosen, are you open to working to make the chosen proposals better as they transition to IETF? Or would you rather this be about making sure IETF knows that you disagree with the chairs' recommendation, or that you were the one with the "big idea" that fixed the internet? If it's the latter two, feel free to write an individual contribution refuting the RRG recommendation, as I think Tony has done a good job modifying the text to reflect the fact that this isn't a consensus recommendation, and why that's still ok within the context of an IRTF group. Further, as Tony stated a few weeks ago, those who are unhappy with the choice that the chairs made are free (and encouraged) to pursue individual contribution drafts, perhaps taking the direction that the LISP folks took and either getting their own WG started, or at least shopping their ideas to existing WGs to get them to take on the effort of refining the idea with an eye to eventual implementation. Option 2/3 is a no-op, because not only would there be a Tony/Lixia doc, there would be an IVIP doc, and there would be a [LISP] doc, and an IRON-RANGER doc, etc, etc. It would only prolong the current state of non-consensus. Regarding #4 - As I see it, there are two alternatives: 1) Compromise, and actually distill the 15 proposals down to a few proposed implementations based on the way that they solve the problem. 2) Admit defeat and punt to IAB with no recommendation, with the assumption that IAB will be able to look at this objectively and provide the compromise that has failed to happen in RRG, and recommend a path forward within IETF. This would likely take the form Vince described of perhaps further classifying the proposals in the existing document and leaving a big [to be completed by IAB] in section 17. Unless there is a sudden groundswell of support for taking the multiple proposals and merging them down to perhaps one recommendation in each class of solution (and yes, I realize that there isn't even agreement on how to classify some of these), or a recommendation of a certain *type* of solution instead of a specific proposal, I think it's time to call the horse dead, and already beaten to sub-molecular bits. For example - Both of the recommendations made in Anaheim fit into Class 1. I assume that the chairs believe that this is the best type of solution of the 3 classes. There are obviously others who disagree, and think that either a Class 2 or Class 3 solution might be best, but it doesn't work as a recommendation to say that all 7 or 5 or 12 of those proposals are recommended. My personal opinion is that since LISP already is well into the "running code" phase, and is therefore much further along in actual refinement by the community at large, it would be the recommended map-and-encap solution, and that at some point those with alternatives in this space need to help the LISP WG resolve the problems that they perceive to still be extant in that implementation, perhaps using ideas from your own proposals. The correct solution is NOT to continue trying to convince people in RRG that your idea is better. Also, if RRG recommends multiple types of solutions (one from each class, for example) there would need to be more written on the pros and cons of each type of solution, so that the recommendation can further be refined down to an actual course of action to solve the problem within the auspices of IETF WGs. I don't believe that the IETF has the resources to solve the problem multiple times by recommending multiple solutions and starting a race within IETF, so I think that making a general architectural recommendation based on a type of solution agnostic to the solution proposals themselves, and then leaving the debate about which implementation is best to the WGs that end up taking up the work is probably a no-op and would still require direction from the IAB. I don't know if the recommendation as written today will ultimately result in IETF taking the recommended action. If the recommendation is truly just the chairs' and the majority of IETF believes they're wrong, chances are it won't. But I do know that the solution to the lack of consensus problem isn't to write MORE reams of text in support of individual proposals as in option 2/3 above, and I don't see much value in splitting the draft up. Thanks, Wes George This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
