[GROW] RtgDir Review: draft-ietf-grow-irr-routing-policy-considerations-05

Terry Manderson <terry.manderson@icann.org> Mon, 24 November 2014 23:44 UTC

Return-Path: <terry.manderson@icann.org>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 355C51A871E; Mon, 24 Nov 2014 15:44:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.511
X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 04kvuoOzC6ba; Mon, 24 Nov 2014 15:44:12 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D161A6FE5; Mon, 24 Nov 2014 15:44:12 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org ( by PMBX112-W1-CA-2.pexch112.icann.org ( with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 24 Nov 2014 15:44:09 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.0847.030; Mon, 24 Nov 2014 15:44:09 -0800
From: Terry Manderson <terry.manderson@icann.org>
To: "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Thread-Topic: RtgDir Review: draft-ietf-grow-irr-routing-policy-considerations-05
Thread-Index: AQHQCECKbVUJjmxcAUWcjcppyPp5xQ==
Date: Mon, 24 Nov 2014 23:44:09 +0000
Message-ID: <D099DD40.4B060%terry.manderson@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3499753447_41281240"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/grow/3ZFS2mcS5XHJsCb1CHrw5fCA15w
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-grow-irr-routing-policy-considerations.all@tools.ietf.org" <draft-ietf-grow-irr-routing-policy-considerations.all@tools.ietf.org>, "grow@ietf.org" <grow@ietf.org>
Subject: [GROW] RtgDir Review: draft-ietf-grow-irr-routing-policy-considerations-05
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Nov 2014 23:44:15 -0000


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

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

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.

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

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.


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

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