-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Thursday, April 15, 2010 9:07 AM To: Tony Li; IRTF Routing RG Subject: Re: [rrg] Proposal for recommendation language
Dear Tony, all, More elaboration and justification for selecting the proposed solutions would be welcome. At least including some text to motivate why one single solution is not convenient, what part(s) of the problem is covered by each of the proposed three solutions, why other candidate solutions do not fulfil the initial design requirements, etc. Cheers, Med [[WEG]] Agree. If you ignore the whining about IVIP not being chosen/refuted to his satisfaction (and his rehashing of his issues with you as a chair) from Robin's message, he has a point. Your recommendation does not currently have sufficient information to stand on its own as anything other than a pseudo-random choice on the chairs' part driven by the absence of a consensus from the group. While I have a lot of respect for you and your opinion, your credibility as chairs and IxTF participants is not strong enough to ensure that the recommendation is taken seriously by the community on face value alone. I assume that some thought went into the recommendation, so as they told me in math class - show your work. Take the reader through the thought process that led to this recommendation for you. The recommendation certainly doesn't have to re-hash each discussion in the previous section, but it does need to hit a couple of the high points. I'd like to see something that expounds on the contributed critiques and defenses of ILNP when compared to the other proposals which are not being recommended - in other words, "the recommended proposal addresses the following problems present in X, Y, Z proposals (or categories of proposals) in the following ways...." It may also be helpful to at least identify why the outlined problems are fundamental enough to sink the other proposals. Also, you need a section - "the following issues are still known to exist with the recommendations..." which leads to an explanation of why multiple proposals are needed, as well as outlining the problem-space that IETF needs to solve to actually implement these ideas. As to why multiple proposals are required to solve the problem, you have some feedback in the form of the comments from myself and several other operators in Anaheim- We see AIS as a short-term solution to buy us time to build a better one, which in this case is ILNP. Consensus not being an option, I'd think that Operator feedback might be a good way to lend credibility. Lastly, you also need to draw a better logical link to why renumbering is specifically mentioned here - if the problem is either unique to ILNP's implementation, or fundamental to make any of these proposals work better, say that. Otherwise, I'm not sure it's clear why that's referenced. We know renumbering needs work, we have a good draft telling us why, but unless you make it clearer why it's something that has to be fixed in the context of RRG- what not fixing it would exacerbate in the RRG recommended solution, it shows as an afterthought. Thanks, Wes -----Message d'origine----- De : [email protected] [mailto:[email protected]] De la part de Tony Li Envoyé : mercredi 14 avril 2010 00:36 À : IRTF Routing RG Objet : [rrg] Proposal for recommendation language Hi all, I hope everyone's had a chance to get caught up with their day jobs after IETF. ;-) I would like to start work on the language to go in section 17 (Recommendation) of our document. As a strawman, I would like to propose the language below. This would appear (modulo editorial changes) as the complete text of that section. Comments? Regards, Tony P.s. The draft is also open for folks that would like to make editorial changes to their contributions. ---------------- As can be seen from the extensive list above, the group explored a number of possible solutions. Unfortunately, the group did not reach rough consensus on a single best approach. Accordingly, the decision of the co-chairs is to recommend that the IETF pursue work in the following areas: - Aggregation in Increasing Scopes [I-D.zhang-evolution] - Identifier/Locator Network Protocol (ILNP) [ILNP Site] - Renumbering [I-D.carpenter-renum-needs-work] 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
