Hi Paul, Thanks much for the review.
> There is no description of who wrote the rebuttals and counterpoints. I don't > think that names need to be used, but a description in the introduction of > the process used to collect rebuttals and counterpoints would give useful > context to the reader. Makes sense. Consider it done. > Two of the proposals, NOL (Section 6) and 2-phased mapping (Section 9), have > no references, which means that the entire technical description of the > proposal is contained in this document. However, neither of those were > particularly clear and concise, as compared to most of the rest of the > proposals. Having an explanation of why they discussed here without further > reference would be useful to understand where they stand in the pantheon of > routing proposals. Sure, we can add some notes here. > Many of the Internet Drafts in the references are long-expired, including one > of the two normative references. This will make for an interesting > conversation with the RFC Editor. The expired normative reference is the design goals document. We'll be updating that and passing that up for IRSG review as well. Note that many of the other proposals are not opting to publish as RFC status, so many of the informational references will time out. I'm not particularly happy about this, but I don't see a good solution either. We can't exactly force people to publish. > This last recommendation is obviously the trickiest one, and it may be a > touchy subject. From reading this document without reading the mailing list, > I have absolutely zero idea why Section 17, the recommendations, exists. > Section 1.1 says: > The group did not reach consensus on this > recommendation, thus the recommendation reflects the decision of the > co-chairs. The group did reach consensus that the overall document > should be published. > This can be (mis)interpreted many ways: > - The RG could not come to consensus on recommendations, so the co-chairs > are reporting the strongest agreement they could find. > - The RG could not come to consensus on recommendations, so the co-chairs > are taking advantage of this and saying what the two of them like. > - The RG only wanted the overall document without recommendations published, > but the co-chairs thought that didn't go far enough to be useful, so they > added some recommendations almost as a placeholder. > - The IETF demands recommendations, and we couldn't come to consensus, so we > put some in, but you can ignore them because they aren't really RG consensus. > - One of the three recommendations listed is co-authored by one of the > co-chairs, so she must have insisted that it be listed and consensus be > damned. > - It's all dumb IETF politics! Run away! > Many of those interpretations are unhelpful and do a disservice to the > obviously large amount of work in the RG that went into this document. There > hopefully would be a clear explanation of why the co-chairs get to give their > recommendations when there was no RG consensus, and hopefully also why there > was not consensus in the RG. Short of being able to add that, please strongly > consider replacing the section with a few paragraphs about the lack of > consensus on recommendations and an apology for not being able to give > recommendations. > > As I said, I recognize that this last bit is tricky, and there are probably > good reasons for the document being the way it is now. However, that doesn't > help the reader who is not part of the RG, much less the reader 20 years from > now who wants to know why the IETF chose the new routing architectures that > it did. If the document is published without context about the > recommendations, the document will lose a fair amount of its long-term > usefulness. You're right, this is tricky. We've been over the wording quite a bit, but apparently it's still not sufficiently clear. Our directive from Aaron was very simple: whatever process we chose, it had to be open. We could have flipped a coin, rolled dice, or thrown darts. Instead, we tried for consensus. When that didn't materialize we added our own two cents. We've been trying to be as clear as possible about this and it took several passes to get to the current wording. Any suggestions on how we could wordsmith this? Regards, Tony _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
