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?

Cheers
Terry

On 7/06/12 12:00 AM, "Randy Bush" <ra...@psg.com> wrote:

> this draft is relevant to the sidr wg work and i, as author, request it
> be made a work item.
> 
> randy
> 
> 
> From: internet-dra...@ietf.org
> To: ra...@psg.com
> Subject: New Version Notification for draft-ymbk-rpki-grandparenting-00.txt
> Message-ID: <20120606135903.5473.73476.idtrac...@ietfa.amsl.com>
> 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&#39;s
>    parent may not be able to, or may not choose to, facilitate full and
>    proper registration of the holder&#39;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
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to