Terry, On Jun 7, 2012, at 7:54 AM, Terry Manderson wrote:
Hi Randy, I'm presuming that there are cases that prompt you to write this draft as BCP. Are you able to elaborate on why (using the nomenclature from your example) "A" wouldn't re-issue the rpki certificate to "C" to be "10.42.0.0/23,10.42.4.0/22,10.42.8.0/21,10.42.16.0/20,10.42.32.0/19,10.42.64 .0/18,10.42.128.0/17" (ie the 10.42.0.0/16 resources minus "C's" /23) and a certificate to G of "10.42.2.0/23" since both "A" and "C" are in agreement that "G" retains that prefix? Or is this what you are trying to describe? So far the wording seems (to me) that some certificate state will eventuate that "A" issues a certificate for the 10.42.0.0/16 to "C" _AND_ creates a 10.42.2.0/23 resulting object (ROA etc) on "G's" behalf as a subordinate object of "A's" 10/8? I'm not sure that was the intent of the RPKI? Was it? I had the same reaction as you. I looked at the CP document and the Cert. Profile. The best reference to this use-case is the second paragraph of the Security Section on RFC 6487: " A resource certificate PKI cannot in and of itself resolve any forms of ambiguity relating to uniqueness of assertions of rights of use in the event that two or more valid certificates encompass the same resource. If the issuance of resource certificates is aligned to the status of resource allocations and assignments, then the information conveyed in a certificate is no better than the information in the allocation and assignment databases." My understanding of Randy's proposal is that both C and G will have for a period of time the "right of use" for the 10.42.2.0/23 address space. Your proposal on the first paragraph is an alternative but I would say that it will be much harder to "make before break". Roque Cheers Terry On 7/06/12 12:00 AM, "Randy Bush" <[email protected]<mailto:[email protected]>> wrote: this draft is relevant to the sidr wg work and i, as author, request it be made a work item. randy From: [email protected]<mailto:[email protected]> To: [email protected]<mailto:[email protected]> Subject: New Version Notification for draft-ymbk-rpki-grandparenting-00.txt Message-ID: <[email protected]<mailto:[email protected]>> Date: Wed, 06 Jun 2012 06:59:03 -0700 A new version of I-D, draft-ymbk-rpki-grandparenting-00.txt has been succes= sfully submitted by Randy Bush and posted to the IETF repository. Filename: draft-ymbk-rpki-grandparenting Revision: 00 Title: Responsible Grandparenting in the RPKI Creation date: 2012-06-06 WG ID: Individual Submission Number of pages: 5 Abstract: There are circumstances in RPKI operations where a resource holder's parent may not be able to, or may not choose to, facilitate full and proper registration of the holder's data. As in real life, the holder may form a relationship to their grandparent who is willing to aid the grandchild. This document describes simple procedures for doing so. The IETF Secretariat _______________________________________________ sidr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
