Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​ http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-grow-irr-routing-policy-considerations-05 Reviewer: Terry Manderson Review Date: 2014-11-24 IETF LC End Date: 2014-12-01 Intended Status: Informational Summary: I have a handful of minor concerns about this document which should be resolved prior to publication, and a few comments centered around general draft direction. Comments: I think the handling of the historical issues of IRRs is fair. There is often a reach to 'beat up' on the perceived faults of a system - this draft doesn't do this. Indeed I thought the first half of the draft was very well constructed and provides an appropriate discussion. When discussing the data integrity (or lack thereof) of an IRR I feel insufficient attention is given to overall integrity of the IRR source, esp. wrt mirroring (sec 5.1). That is, are all the objects completely mirrored, is there a way to tell? why not? etc? As it is RIPE withhold certain objects for PII reasons, what else could be missing that is operationally important? The lack of C.I.A. on the NRTM stream is touched on, but not given due attention. Additionally the lack of C.I.A on the current query side (WHOIS/TCP/43) should be iterated as a part of the attack surface, both for the IRR operator and the IRR user. A number of times within the draft the similarities, differences, and 'nice to have' aspects between the IRR and the RPKI are highlighted. I'm left wondering if this topic actually needs its own section. For example: the RPKI has RPKI-RTR, yet that in itself will not carry policy based information. Without turning such a section into "what the RPKI doesn't do", some time spent highlighting what the IRR provides and what RPKI may provide could help the reader. The underpinning statement from the draft appears to be that RPKI origin validation is or could be good, but it (RPKI) currently is not scoped to replace RPSL and the nuanced policy applications which providers employ now. If this is a pragmatism holds true, then for completeness of the discussion the Authors and ADs might wish to include it. Major Issues: No major issues found. Minor Issues: Section 5, Para 4: I feel it is glib to state that "it can be observed that the most common circuit size used by ISPs is now 10 Gbps". Qualifying this with the economic development or network development of the region is prudent, or perhaps provide a reference to a survey if one exists. Section 5.2, Para 5. I found the last sentence in para 5 difficult to parse. Please consider rewording. Section 7.2, Para 2. Please consider re-writing the second sentence of this para. The (over) use of commas makes it hard to read. Section 7.3, Para 1. I don't think you actually mean '"offline" server'.. Perhaps "disparate"? or "configuration"??? Please clarify, or perhaps define the term in the context here. "offline" is an overloaded term. Nits: Section 5.1, para 3: s/(Edge)/(edge)/ Section 5.2, para 4: "turn-up", word suggestion: "commission" Section 5.2, para 4: s/call up/call/ (the "up" is superfluous) Section 6, para 4: s/take affect/take effect/ x2 Section 7.2, para 4: s/so have the some of the scaling/so have some of the scaling/ Section 8: 1st sentence. I read this and thought: "the green leaf is green".. This might just be a style difference around over-stating the obvious. Attachment: smime.p7s Description: S/MIME cryptographic signature