Re: [GROW] I-D Action: draft-mcpherson-irr-routing-policy-considerations-01.txt

Hey Nick,

First, I'm very sorry for the absurd delay in addressing these comments, but thank you very much for them.  I've incorporated most of them and will be pushing a new version soon.

Eric

On Sep 4, 2012, at 6:12 PM, Nick Hilliard <nick@inex.ie> wrote:

> On 04/09/2012 20:17, Danny McPherson wrote:
>> FYI, may be able to find a home here in grow if folks are interested.
>> Encourage feedback from all...
> 
> Danny,
> 
> regarding section #4, "Accuracy and Integrity of Data", you've missed the
> most important part of all - the tie between the resource and the end user.
> If this cannot be verified, then certification of any form is basically
> pointless because you're only certifying the assertions that the creator /
> maintainer of the resource object.
> 
> The RIPE community dealt with this by putting in a foundation policy
> (policy 2007-01, written by yours truly), which requires a contractual link
> between the RIPE NCC and the end user in direct assignment + asn assignment
> cases which weren't previously covered by LIR contracts for address
> allocations.  There were a couple of intentions with this policy:
> 
> 1. there was an encumbrance placed in the policy for the LIR to charge the
> end-user for provider independent resources.  This action creates a natural
> garbage collection mechanism for PI address resources (v4 / v6 space, asns).
> 
> 2. it guaranteed that all RIPE NCC allocated/assigned space would be
> subject to a contractual link, and that this contractual chain might end up
> actually meaning something when it came to the issue of who made what claim
> about what number resource.
> 
> 3. it would tie into the RIPE NCC's object grandfathering policy which ties
> the registration details of the end-user to the object registered in the
> irr database.
> 
> So unless you have similar chain-of-ownership functionality in other
> IRRDBs, the whole discussion about certification and pretty much everything
> else related is moot.
> 
> In section 7.3, I would view it as useful to note that SIDR does not
> currently include bgp as-path validation, and that this is a Difficult Problem.
> 
> I think your draft has merit (no pun intended).  I'd like to see it
> developed further because it provides a lot of important background
> information on where we stand at the moment, and it's difficult to move
> forward unless we have a clear idea we are.
> 
> nit: "ISP's" should be "ISPs" in the case where you are talking about
> multiple ISPs.
> 
> Nick
> 
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow