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

Tim Bruijnzeels <tim@ripe.net> Wed, 08 August 2012 14:52 UTC

Return-Path: <tim@ripe.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 613F021F867A for <sidr@ietfa.amsl.com>; Wed, 8 Aug 2012 07:52:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.468
X-Spam-Level:
X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 uIaQ2SRSURtE for <sidr@ietfa.amsl.com>; Wed, 8 Aug 2012 07:52:26 -0700 (PDT)
Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 41B9221F8679 for <sidr@ietf.org>; Wed, 8 Aug 2012 07:52:26 -0700 (PDT)
Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1Sz7cV-0005Dr-TG; Wed, 08 Aug 2012 16:52:25 +0200
Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-232.ripe.net) by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1Sz7cT-0007Je-Cz; Wed, 08 Aug 2012 16:52:23 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-1-1058118762"
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <53D504DF-C0A3-4CFC-AD93-689630336F7D@apnic.net>
Date: Wed, 08 Aug 2012 07:52:18 -0700
Message-Id: <097D025D-1879-455C-BB14-F9C8BFAC88AA@ripe.net>
References: <FE3A7AFD-0064-477A-B8F0-55735610CC9A@isode.com> <53D504DF-C0A3-4CFC-AD93-689630336F7D@apnic.net>
To: George Michaelson <ggm+ietf@apnic.net>
X-Mailer: Apple Mail (2.1084)
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120808 clean
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071932054669c02cca3a6f587e8121637674
Cc: sidr@ietf.org
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: Wed, 08 Aug 2012 14:52:27 -0000

Hi,

Thank you George for phrasing this so accurately. I fully agree that in case of the RIRs there already exists a frame work (address policy) that provides all the process needed for this. I am not sure how many big ISPs / LIRs follow this discussion, but I expect that there commercial contractual concerns exist regarding this and I highly doubt that such companies will follow this document's advice, just because it's a standard..

Tim 


On 6 Aug 2012, at 18:38, George Michaelson wrote:

> 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
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr