[GROW] Stephen Farrell's No Objection on draft-ietf-grow-irr-routing-policy-considerations-05: (with COMMENT)

"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Sun, 04 January 2015 04:40 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: The IESG <iesg@ietf.org>
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150104044026.12585.96310.idtracker@ietfa.amsl.com>
Date: Sat, 03 Jan 2015 20:40:26 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/grow/CvQlTRI3pZmxkQJDkH55Sq5MkP0
Cc: grow-chairs@tools.ietf.org, grow@ietf.org, draft-ietf-grow-irr-routing-policy-considerations.all@tools.ietf.org
Subject: [GROW] Stephen Farrell's No Objection on draft-ietf-grow-irr-routing-policy-considerations-05: (with COMMENT)

Stephen Farrell has entered the following ballot position for
draft-ietf-grow-irr-routing-policy-considerations-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-grow-irr-routing-policy-considerations/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------



Thanks for this. I learned from reading it and following
some links etc. I think other readers will be similarly
educated.

- I agree with Adrian's request that the routing review
be discussed. In particular, wrt the relationship
between this work and the RPKI - it'd be good that that
be (checked as having been) documented correctly. No
disrespect to the authors here, but the RPKI vs. IRR
stuff here is not that crisply described - most likely
(I'm guessing) because that relationship is just in
reality vague. But if I'm recalling correctly some of
the very capable authors here aren't the biggest fans of
the RPKI so it'd be good for them and this document that
their description of RPKI be challenged now a little bit
rather than that be done later (if that has not already
happened, which may well be the case).

- 5.1, I'd be interested in why RFC2725 is now seen as
then having been a barrier to deployment and whether or
not that is still considered to be the case. Put another
way - was the problem the security requirements or the
design provided in 2725? (Note, I'm not asking for any
change, just wondering.)

- section 6 has a "[REF?]" that's presumably an undone
TBD

[GROW] Stephen Farrell's No Objection on draft-ie… Stephen Farrell