Re: [sidr] Reboot: questions regarding WG acceptance of draft-ymbk-rpki-grandparenting-02

[Christopher Morrow <[e-mail]>]

clarifying question in your example...

On Fri, Dec 7, 2012 at 12:32 PM, Brian Dickson
<[e-mail]> wrote:
> P.S. Here is a worked example to illustrate this concept:
>
> Suppose the initial state of affairs is as follows:
> 10.0.0.0/8 is delegated by IANA to RIR "A". RIR "A" does not route any
> portion of this block, but only doles out portions of it.
> 10.1.0.0/16 is delegated by RIR "A" to LIR "A1". Again, not routed.
> 10.1.0.0/20 is delegated by LIR "A1" to ISP "B". ISP B routes this prefix.
> 10.1.15.0/24 is delegated by ISP "B" to customer "C". C routes this prefix,
> which is more-specific and preferred over 10.1.0.0/20.
>
> Now add to the above, that ISP "B" goes out of business.
>
> The proposed way of directly assigning the 10.1.15.0/24 to "C" would be to
> have the delegation done directly to "C" by RIR "A", or by LIR "A1".
> (Or by IANA, only included for completeness, i.e. this would likely never
> happen.)
>
> And, in order to continue to assure the uniqueness of the assignment, the
> corresponding delegations would need to explicitly call out the
> NON-delegation of 10.1.15.0/24, attached to the delegation chain starting
> wherever the fork occurred.

you mean a CRL would be updated with the previous certificate for 10.1.15.0/24 ?
So, you are essentially saying:
"Grandparenting == re-delegation + break-old-delegation-cert" ? (seems
ok to me...)

> So, if the direct delegation is done by LIR "A1", the new delegations by A1
> would be:
> 10.1.0.0/20 minus 10.1.15.0/24 (from LIR "A1" to ISP "B" (which is defunct,
> presumably, but whose assets might be sold to another party))
> 10.1.15.0/24 (to "C" directly)
>
> Or if the direct delegation is done by RIR "A", the delegations would be:
> 10.1.0.0/16 minus 10.1.15.0/24 (from RIR "A" to LIR "A1")
> 10.1.15.0/24 (from RIR "A" to end-user "C")
> 10.1.0.0/20 minus 10.1.15.0/24 (from LIR "A1" to ISP "B")
>
> The "minus foo" would need to be attached to any delegation covering "foo",
> throughout the delegation hierarchy, once such a "fork" occurs.
> ROA validation would need to check this, but the logic is quite simple.

or just adhere to the crl, right?

> On Fri, Dec 7, 2012 at 11:54 AM, Alexey Melnikov <[e-mail]>
> wrote:
>>
>> Hi,
>> Sorry for procrastinating on this for so long.
>>
>> Here are questions I would like to ask WG participants. At this point I
>> would like to ask people to review the questions and let me know if you
>> think they are contradictory. If they are clear, I will poll the WG early
>> next week. Comments on the mailing list or sent directly to WG chairs
>> <[e-mail]> are welcome.
>>
>> ----------------
>>
>> 1) Is the problem described/solved by draft-ymbk-rpki-grandparenting-02
>> actually a problem that the WG needs to address? (Answer: yes or no.
>> Additional information is welcomed, but I don't want people to repeat the
>> whole discussion.)
>>
>> 2) If you answered "yes" to the question #1, please also answer the
>> following question:
>>
>> Is draft-ymbk-rpki-grandparenting-02 a reasonable starting point to become
>> a WG document? Please choose one of the following:
>>
>>
>> a) Ready for Adoption (whether or not you have some specific issues with
>> it. Also, this answer is unrelated to whether this should be a separate
>> draft or a part of an existing draft).
>>
>> b) Needs more work BEFORE Adoption
>>
>> c) Should not be adopted. In particular this mean that you don't believe
>> any amount of work on the proposed draft will address your issues. So any
>> solution to this problem should be a new draft written from scratch.
>>
>> d) Abstain/don't care
>>
>>
>> 3) If you answered "a" or "b" above, please also answer the following
>> question:
>>
>> Does this need to be in a standalone draft, or can it be incorporated into
>> another existing WG draft? When answering this question please only base
>> your answer on technical reasons, in particular please leave the decision on
>> who is going to edit the document (if it is standalone) to WG chairs.
>>
>>
>> _______________________________________________
>> sidr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidr
>
>
>
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr
>