Draft #6 of the Summary of Routing Architectures discussed in the RRG is now available at:
http://bill.herrin.us/network/rrgarchitectures.html With this version, the draft is closed to additions. I now ask you to propose rejecting particular strategies or strategy variants on the grounds that they are in some way unacceptable. Changes from draft 5 to draft 6: * Strategy A now has method group A5: how we route RLOCs in the Internet core. * References to "layer 4" changed to "layer 4/5" in order to express that we're looking at both transport and session semantics, not just transport semantics. * A3b specifies that the analysis element is not necessarily under the control of a particular party. * A4, statements to the effect "IPv4 is abandoned" are changed to "Use a different A4 variant for IPv4" Although the draft is formally closed to additions, I'm still willing to add things where there is really no doubt they belong there. I may ask you to demonstrate a consensus on the mailing list that they belong first. I'll be as even-handed as I can. Please don't take me to task, either for adding something late or for asking you to demonstrate consensus. PHASE TWO: REJECTION Robin, now it's time to tell us why everything but Strategy A won't work. ;-) I'd like to ask everyone to nominate strategies, strategy variants or even phrases in a particular sentence for rejection. Maybe you think it can't work. Maybe you think it fails to address the problem. Whatever your reason, post it and call for a strong consensus. What is strong consensus? Strong consensus means that: A) Folks bother to express an opinion. If 3 people agree and nobody else expresses an opinion, that isn't a consensus. B) Almost nobody disagrees. If 20 people say yes and 10 people say no, that's a weak consensus. If 20 people say yes and 2 people say no, it's a strong consensus. I ask you to restrict nominations to the specific words that are in the document. I know that seems obvious, but I don't want anyone to get mad when I refuse to act on a proposal like, "We should reject anything that doesn't deal with XYZ problem." If you think XYZ problem is important, pick the strategies and strategy variants that you think fail to address it and nominate them for rejection instead. As we achieve consensus on the rejections, I will reorganize the document to reflect that we believe those approaches should be abandoned, along with a few words about why. I'll try to move to phase 3 in the second half of January. In phase 3 I'll seek consensus on which of the remaining strategies are promising enough to merit engineering work in the IETF. In another message, I'll call for the rejection of "Strategy F: Do nothing." You're welcome to copy the format of that message. You're also welcome to use a format of your own, as long as everybody clearly understands exactly what part of the document you propose to reject and opinions clearly express whether they intend that the document component be rejected or not. Regards, Bill Herrin -- William D. Herrin ................ [email protected] [email protected] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
