Re: [sidr] draft-ymbk-rpki-grandparenting-00.txt

Terry Manderson <terry.manderson@icann.org> Thu, 07 June 2012 05:54 UTC

Return-Path: <terry.manderson@icann.org>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263BE11E80E9 for <sidr@ietfa.amsl.com>; Wed, 6 Jun 2012 22:54:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XC6FXSzrduWf for <sidr@ietfa.amsl.com>; Wed, 6 Jun 2012 22:54:24 -0700 (PDT)
Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC8F11E80E8 for <sidr@ietf.org>; Wed, 6 Jun 2012 22:54:24 -0700 (PDT)
Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 6 Jun 2012 22:54:21 -0700
From: Terry Manderson <terry.manderson@icann.org>
To: Randy Bush <randy@psg.com>, sidr wg list <sidr@ietf.org>
Date: Wed, 6 Jun 2012 22:54:19 -0700
Thread-Topic: [sidr] draft-ymbk-rpki-grandparenting-00.txt
Thread-Index: Ac1D7MjRF53PrJ9KSjKhYSccACT4iAAhTHKP
Message-ID: <CBF67F2B.2677C%terry.manderson@icann.org>
In-Reply-To: <m28vg0lev7.wl%randy@psg.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3421929259_34031755"
MIME-Version: 1.0
Subject: Re: [sidr] draft-ymbk-rpki-grandparenting-00.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jun 2012 05:54:25 -0000

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" <randy@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-drafts@ietf.org
> To: randy@psg.com
> Subject: New Version Notification for draft-ymbk-rpki-grandparenting-00.txt
> Message-ID: <20120606135903.5473.73476.idtracker@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