<speaking only for myself> I support the concept of grandpareting. However, as others here, believe the document needs more work.
I share Andy's concerns, and personally believe that if grandparenting is going to be an 'approved' practice (a RFC or even a WG draft tends to give people such feelings) then this document or other document needs to clearly state requirements for grandparents so relying parties can keep trusting the system. I'd love to see a flag somewhere that marks that a given cert/roa represents a grandchild and not a direct child. regards Carlos On 8/9/12 3:25 PM, Christopher Morrow wrote: > an interesting outgrowth of the grandparenting could be the ability to > 'avoid' LEA actions at middle tiers of the address allocation > heirarchy... that's something to consider, i'd say. > > On Thu, Aug 9, 2012 at 10:50 AM, Randy Bush <[email protected]> wrote: >> tim, >> >> i see where some confusion might come from >> >>> I am not sure how many big ISPs / LIRs follow this discussion, but I >>> expect that there commercial contractual concerns exist regarding this >>> and I highly doubt that such companies will follow this document's >>> advice, just because it's a standard. >> >> i know rirs like to speak for their members, but this document was >> written by one of them :) >> >> as a large isp, we serve a fair number of smaller isps. i specifically >> had in mind the circumstance where one of our customers failed and their >> child needed support. we're engineers, and our primary concern is that >> the packets get delivered. >> >> indeed, the contractual concerns you raise are specifically why one may >> not want to disturb the child's cert while seeing that the grandchild's >> packets are delivered. >> >> i also have concern that rirs are not seeing the needs of the community, >> which includes the grandchildren (even though you do not rent integers >> to them directly). >> >> the issue here is operational packet delivery, not rir policy. >> >> randy >> _______________________________________________ >> sidr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
