Early Review of draft-ietf-grow-irr-routing-policy-considerations-05
review-ietf-grow-irr-routing-policy-considerations-05-rtgdir-early-manderson-2014-11-25-00

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