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 > [email protected] > https://www.ietf.org/mailman/listinfo/grow >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
