Greetings. I have reviewed draft-irtf-rrg-recommendation-10.txt as part of the IRSG review process, described at <http://trac.tools.ietf.org/group/irtf/trac/wiki/IRTF-RFCs>. That page says "The purpose of the IRSG review is to ensure consistent editorial and technical quality for IRTF publications."

This document definitely meets a high standard for editorial and technical quality. There are a few issue that I (as a definite outsider to routing in general, much less next-generation routing in specific) think could be usefully addressed before publication. Please take these suggestions as proposals for improvements, not requirements.

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.

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.

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.

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.

Please let me know if you have any questions.

--Paul Hoffman, Director
--VPN Consortium