Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting

<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 <randy@psg.com> 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
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
> 