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

"George, Wes" <> Tue, 12 June 2012 13:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B22B21F8557 for <>; Tue, 12 Jun 2012 06:23:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.813
X-Spam-Status: No, score=-0.813 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nh7-sayMsQ5P for <>; Tue, 12 Jun 2012 06:23:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5BF6B21F8516 for <>; Tue, 12 Jun 2012 06:23:56 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,758,1330923600"; d="scan'208";a="394277440"
Received: from unknown (HELO ([]) by with ESMTP/TLS/RC4-MD5; 12 Jun 2012 09:23:27 -0400
Received: from ([]) by ([]) with mapi; Tue, 12 Jun 2012 09:23:55 -0400
From: "George, Wes" <>
To: Randy Bush <>, sidr wg list <>
Date: Tue, 12 Jun 2012 09:23:53 -0400
Thread-Topic: [sidr] draft-ymbk-rpki-grandparenting-00.txt
Thread-Index: Ac1D7L5Bw3TC05JiRRudUhZWRrVTlgEsIkKA
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [sidr] draft-ymbk-rpki-grandparenting-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Jun 2012 13:23:57 -0000

Randy -

I'm thinking that there's a simpler use case for this -

In the situation where A delegated space to C, who delegated it further to G, and G would like help managing data, but C is not willing or able to do so, and so G works with A to make this happen. The concept of changing providers may not be necessary to illustrate the point.

Regarding adoption, I'm not certain I understand from the current text why this can't be incorporated into existing drafts as a brief note. If I'm interpreting this draft correctly, you're saying that there's nothing technically hard about doing this, but that there are some business and contractual issues to deal with, mainly on account of the potentially fractured business relationship between the parties involved, and proper validation of the information you're certifying. But that's true of any relationship where one party certifies on anothers' behalf. What's different about this case that requires it to be treated separately from other operational considerations? I love the "responsible grandparenting" title, but I'm just thinking it's easier for reader and implementer alike if this is consolidated.


Wes George

> -----Original Message-----
> From: [] On Behalf Of
> Randy Bush
> Sent: Wednesday, June 06, 2012 10:00 AM
> To: sidr wg list
> Subject: [sidr] draft-ymbk-rpki-grandparenting-00.txt
> this draft is relevant to the sidr wg work and i, as author, request it
> be made a work item.
> randy
> From:
> To:
> Subject: New Version Notification for draft-ymbk-rpki-grandparenting-
> 00.txt
> Message-ID: <>
> 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

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.