Recommendation for a Routing Architecture
RFC 6115

Note: This ballot was opened for revision 16 and is now closed.

(Jari Arkko) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2010-11-17 for -)
No email
send info
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.

(Gonzalo Camarillo) No Objection

Comment (2010-11-18 for -)
No email
send info
Was there any counterpoint submitted to any particular proposal?

(Adrian Farrel) No Objection

Comment (2010-11-13 for -)
No email
send info
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.

(Russ Housley) No Objection

(Tim Polk) No Objection