Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting

George Michaelson <ggm+ietf@apnic.net> Tue, 07 August 2012 01:38 UTC

Return-Path: <ggm+ietf@apnic.net>
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 254BD21F8674 for <sidr@ietfa.amsl.com>; Mon, 6 Aug 2012 18:38:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 ZE2QvQINyg7t for <sidr@ietfa.amsl.com>; Mon, 6 Aug 2012 18:38:30 -0700 (PDT)
Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id A958021F8658 for <sidr@ietf.org>; Mon, 6 Aug 2012 18:38:28 -0700 (PDT)
Received: from [IPv6:2001:dc0:a000:4:2d45:468f:7923:2712] (unknown [IPv6:2001:dc0:a000:4:2d45:468f:7923:2712]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 4851FB684B for <sidr@ietf.org>; Tue, 7 Aug 2012 11:38:27 +1000 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\))
From: George Michaelson <ggm+ietf@apnic.net>
In-Reply-To: <FE3A7AFD-0064-477A-B8F0-55735610CC9A@isode.com>
Date: Tue, 07 Aug 2012 11:38:29 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <53D504DF-C0A3-4CFC-AD93-689630336F7D@apnic.net>
References: <FE3A7AFD-0064-477A-B8F0-55735610CC9A@isode.com>
To: sidr@ietf.org
X-Mailer: Apple Mail (2.1485)
Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting
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: Tue, 07 Aug 2012 01:38:31 -0000

I am very concerned the impact this kind of activity has on the integrity of public allocation registries.

How are external parties meant to understand what should exist, if the RPKI signing leaps over intermediate parties that are explicitly listed as having substantive authority over the disposition of resources?

I am struggling to imagine how this activity happens in the context of lawsuit, and the risk of lawsuit by the skipped-over party, and other unrelated parties.

The Grandparent has no contractual relationship with the Grandchild. What is the basis for entering into an agreement to certify these resources, rather than performing a publicly recognized transfer of control? Whats the long-term relationship between the new child, and the Grandparent? on what basis does RPKI certification continue, or cease? Does the parent retain any control? What if the parent does wake up an RPKI engine, and issues conflicting signing state? 

I don't think these are subjects which vest well inside the IETF process, or an RFC. I think they go to address policy questions  currently handled inside the RIR policy framework, by address holders. Since the affected parties include address holders I cannot see how this should be documented or defined outside of that process.

-George

On 05/08/2012, at 4:12 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:

> Hi,
> On behalf of SIDR WG chairs I would like to initiate 2 weeks acceptance call for draft-ymbk-rpki-grandparenting starting from today, August 4th. Please send your positive or negative feedback to the mailing list or directly to chairs.
> 
> Thank you,
> Alexey
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr