Yes, and that's is why I have double feelings.
I concur with you about the usability to 'overcome' LEA actions but
also I agree with others about some of the negative sides. I think the draft
has good intentions but IMHO it needs more thinking. Otherwise it could create
more problems than solving them.
I will keep trying to digest it, and f I have something more
constructive to say I will.
Regards,
as
On 9 Aug 2012, at 15:25, 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
