clarifying question in your example... On Fri, Dec 7, 2012 at 12:32 PM, Brian Dickson <brian.peter.dick...@gmail.com> 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 <alexey.melni...@isode.com> > 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 >> <sidr-cha...@tools.ietf.org> 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 >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > > > _______________________________________________ > 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
