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

[joel jaeggli <[e-mail]>]

It's been a long time in coming but we have an update to this draft
which I figured I would run by you, before we return it to the IESG.

draft-ietf-grow-irr-routing-policy-considerations-06

 is out

https://www.ietf.org/rfcdiff?url1=draft-ietf-grow-irr-routing-policy-considerations-05&url2=draft-ietf-grow-irr-routing-policy-considerations-06

On 11/24/14 3:44 PM, Terry Manderson wrote:
> 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.
> 
> 
> 
> _______________________________________________
> GROW mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/grow
>