Re: [sidr] wglc draft-ietf-sidr-policy-qualifiers-00

Andy Newton <andy@arin.net> Tue, 16 July 2013 13:50 UTC

Return-Path: <andy@arin.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 0440121E8087 for <sidr@ietfa.amsl.com>; Tue, 16 Jul 2013 06:50:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599]
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 eSv4GCb+Z2Ee for <sidr@ietfa.amsl.com>; Tue, 16 Jul 2013 06:49:55 -0700 (PDT)
Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 9A41321E8050 for <sidr@ietf.org>; Tue, 16 Jul 2013 06:49:55 -0700 (PDT)
Received: by smtp1.arin.net (Postfix, from userid 323) id 91EDE1651B1; Tue, 16 Jul 2013 09:49:54 -0400 (EDT)
Received: from ASHXCH01.corp.arin.net (ashxch01.corp.arin.net [199.43.0.17]) by smtp1.arin.net (Postfix) with ESMTP id 0796616519F; Tue, 16 Jul 2013 09:49:54 -0400 (EDT)
Received: from CHAXCH04.corp.arin.net (10.1.30.19) by ASHXCH01.corp.arin.net (199.43.0.17) with Microsoft SMTP Server (TLS) id 14.1.421.2; Tue, 16 Jul 2013 09:49:53 -0400
Received: from CHAXCH02.corp.arin.net ([169.254.2.236]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Tue, 16 Jul 2013 09:49:53 -0400
From: Andy Newton <andy@arin.net>
To: "Roque Gagliano (rogaglia)" <rogaglia@cisco.com>
Thread-Topic: [sidr] wglc draft-ietf-sidr-policy-qualifiers-00
Thread-Index: Ac5/P7KlsWW9gua6S/mEz+yRY2Jx6ACSJbqA///q8YCAAUv7gIAADzOA
Date: Tue, 16 Jul 2013 13:49:52 +0000
Message-ID: <CE0AC78A.26953%andy@arin.net>
In-Reply-To: <EF4348D391D0334996EE9681630C83F0221213C8@xmb-rcd-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.5.130515
x-originating-ip: [10.1.1.56]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3B34C080AE208F4BAA72C1DC035D2125@corp.arin.net>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Murphy, Sandra" <Sandra.Murphy@sparta.com>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] wglc draft-ietf-sidr-policy-qualifiers-00
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, 16 Jul 2013 13:50:01 -0000

This sounds fine to me, though it is really an interoperability
considerations section thingy. The IETF does those now, right? :)

-andy

On 7/16/13 4:55 AM, "Roque Gagliano (rogaglia)" <rogaglia@cisco.com> wrote:

>Thanks Andy.
>
>Do you think we need to add something in the security section about the
>transition?
>
>Something like:
>
>"A RP that performs a strick validation based on RFC6487 and fails to
>support the updates described in this document, would incorrectly
>invalidate RPKI signed objects that implements the changes in Section 2.
>At the time of this writing, all known RP software suites (you can
>mention them as in IDR) were tested and supported the updates on this
>document" 
>
>Roque
>
>On Jul 15, 2013, at 7:07 PM, Andy Newton <andy@arin.net> wrote:
>
>> On 7/15/13 10:22 AM, "Roque Gagliano (rogaglia)" <rogaglia@cisco.com>
>> wrote:
>> 
>>> Before sending my support to advance to the IESG, I wanted to ask the
>>> author if they have tested the effects of this change on existing RP
>>> tools. Do they really set the certificate as invalid?
>> 
>> Yes, we have tested against the three RP suites. One did not require a
>> change while the other two required simple one line changes. Current
>> releases of all three now accommodate it.
>> 
>> -andy
>> 
>
>