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