Recommendation for a Routing Architecture
draft-irtf-rrg-recommendation-16

[Ballot comment]
This is a useful document but one which could be significantly improved if the editors has more time to work on it. My understanding is that they do not have the time. That being the case it is better that this is published to capture this body of work, than that the work be lost.

It is important however, that when it is published, it contains clear warning notes that this does not represent a consensus position for recommended action to the IETF.

The quality of the summaries is very variable, and is dependent on the quality of the reference material. Some of the reference material is of poor quality and could perhaps be relegated to an appendix with appropriate warnings to indicate that it is of lower value.

Some of the summaries (most to some extent) make impossible-to-evaluate claims since they lack context. An example: "End-user networks will typically pay the cost of Open ITR in the DFZ  (OITRD) forwarding to their networks." Without knowing what an OITRD is this isn't very useful.

The security section is a best token, and it would have been useful if the authors had used security as one metric in evaluating the various options. Further the security of the existing Internet is a rather low bar.

Some Minor Issues:

1. The definition of PMTUD in S 1.2 says "PMTUD Path Maximum Transmission Unit Discovery: The process or mechanism that determines the largest packet that can be sent between a given source and destination with being either i) fragmented (IPv4 only), or ii) discarded (if not fragmentable) because it is too large to be sent down one link in the path from the source to the destination."  Shouldn't that say "withOUT"?

2. A citation seems to be missing for "LISP-TREE".

3. S 14, "Evolution" should either include "Aggregation In Increasing Scopes", or it should just be referenced as "Evolution" in S 17, "Recommendation".

4. A citation seems to be missing for RFC 4861.

5. The review makes the general statement that the Internet architecture should be scalable, but that is not a very useful observation without quantifying what dimensions need to be scalable and to what extent. Insofar as specifics are given, it mostly sticks to the formula that multihoming is the primary scaling pressure.  However, a more nuanced analysis might turn into an exercise that never terminates, so I don't necessarily suggest that improving this be a block to progress.

6. It seems almost inconceivable that all the summaries, even with their point, rebuttal, coutnerpoint structure, represent the fullness of the debate. Of course some cutoff is needed, and I don't propose any further expansion. But a disclaimer might be in order that the document represents a snapshot of opinion and doesn't purport to be a consensus.  (This is done to some extent but could be made clearer.)

7. It would have been useful in following up on this to list the authors of each section.

8. Given there are no counterpoints in the document, I recommend deleting those subsections. If desired this can be addressed by mentioning in the intro that an opportunity existed for authors to supply a counterpoint, but none did.


Nits:

1. S 17.3, s/packets/packet's/

Thanks to the RTG Directorate reviewer for drawing my attention to a number of these issues.

[Ballot comment]
Thanks for a clearly-written and helpful document. While it is regrettable that no consensus could be reached, the chairs' opinions are valuable.

I would welcome it if the authors worked with the RFC Editor to address my points below.

I found "ALT" was used without expansion.                                 

Should [I-D.irtf-rrg-design-goals] have progressed first or at the same time? I feel it is important to the evaluation of the potential solutions.

I should have liked to hear a little bit more about the WG (lack of) consensus process. I presume that at least some of
the proposed solutions achived consensus for non-adoption, and this information would be helpful to the IESG and the wider IETF in determining how to act.

This is a request for the IESG to perform a RFC5742 review of draft-irtf-rrg-recommendation-14.txt [1] to be published an an Informational IRTF RFC. The document has been approved for publication by the IRSG. See [2] for details on prior reviews. Please copy all correspondence to the document shepherd, Joel Halpern .

--aaron
IRTF Chair

[1] http://tools.ietf.org/html/draft-irtf-rrg-recommendation-14
[2] http://trac.tools.ietf.org/group/irtf/trac/ticket/39

-------- Original Message --------
Subject: RRG Recommendation
Date: Fri, 01 Oct 2010 10:23:14 -0400
From: Joel M. Halpern
To: Aaron Falk
CC: irsg@ISI.EDU, Routing Research Group list

The current I-D addresses all comments that were reeived during the
review period. (Thee actually were a few comments beyond the one reviewer.)
Therefore, this document is ready for IESG review preparatory to RFC
Publication.

Thank you.

Document:
http://www.ietf.org/id/draft-irtf-rrg-recommendation-14.txt
http://tools.ietf.org/html/draft-irtf-rrg-recommendation-14

Tracker Entry:
http://trac.tools.ietf.org/group/irtf/trac/ticket/39

Paul Hoffman's review can be found here:
http://www.ietf.org/mail-archive/web/rrg/current/msg07291.html

The draft addresses these issues, and a few editorial items there were
found during the review period.

Yours,
Joel M. Halpern