Re: [sidr] AD Review of draft-ietf-sidr-delta-protocol-04

"Alvaro Retana (aretana)" <aretana@cisco.com> Mon, 09 January 2017 13:15 UTC

Return-Path: <aretana@cisco.com>
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 8381D129CA2; Mon, 9 Jan 2017 05:15:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.72
X-Spam-Level:
X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98bBV6VGPCqU; Mon, 9 Jan 2017 05:15:01 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4AF5129B3A; Mon, 9 Jan 2017 05:15:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15322; q=dns/txt; s=iport; t=1483967700; x=1485177300; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qY9yVaSOhuW4WzCRXB0c2mzSuF2z140N2CRMA7lGCuk=; b=NjtLmuhQ+0G2J+uvtSkanl1q3oQj0XfSG9ImMiv6XnrWujyc/apmItkN /bHzAlWp0lldP76mfhOC6FtD5m1NpptUVLtrEEzZNhlU3XEFdh467mDfz spfFq2Klhwlz85C6dNUOmJP2JtOU0IhhF5LkQMRAnbngVFOQqN7uU1akr w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BtAQA7jHNY/5JdJa1dGQEBAQEBAQEBAQEBBwEBAQEBgnFJAQEBAQEfX4EMB4NIigiiHYUrggqGIgIagUc/FAECAQEBAQEBAWMohGkGI1YQAgEIEi0DAgICMBQDDgIEDgUUiFyvSoIlK4lhAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYZFggIIgleED4M/LYIxBZUchgABkUyBd45liAuKSQEfOIFAFUcBhhpzh1mBDQEBAQ
X-IronPort-AV: E=Sophos;i="5.33,339,1477958400"; d="scan'208,217";a="368850347"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2017 13:14:59 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v09DExa7010918 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Jan 2017 13:14:59 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 9 Jan 2017 07:14:58 -0600
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Mon, 9 Jan 2017 07:14:58 -0600
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: Tim Bruijnzeels <tim@ripe.net>
Thread-Topic: [sidr] AD Review of draft-ietf-sidr-delta-protocol-04
Thread-Index: AQHSWsMmv8FEfthKGUScz+TLnYEy7KEeAgSAgA47ooCABE/kAP//wnMA
Date: Mon, 09 Jan 2017 13:14:58 +0000
Message-ID: <A78AA861-BA51-4698-957D-F565DFD05A79@cisco.com>
References: <7DE58D01-AC82-4099-9A46-99E625315637@cisco.com> <99DD12D4-6E13-40A4-95C7-17B12CB61F1C@ripe.net> <EE84C61E-7730-4559-852A-4CFBF8543756@cisco.com> <EEDD968F-D454-4B10-AC0D-8C1B3CD89709@ripe.net>
In-Reply-To: <EEDD968F-D454-4B10-AC0D-8C1B3CD89709@ripe.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1d.0.161209
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.5]
Content-Type: multipart/alternative; boundary="_000_A78AA861BA514698957DF565DFD05A79ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/a6kQUe7y456oLmTDrvrBqwR5oRI>
Cc: "draft-ietf-sidr-delta-protocol@ietf.org" <draft-ietf-sidr-delta-protocol@ietf.org>, Chris Morrow <morrowc@ops-netman.net>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] AD Review of draft-ietf-sidr-delta-protocol-04
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 09 Jan 2017 13:15:02 -0000

Tim:

Congratulations!  ☺


I think we’re in sync with everything else, just this last piece is outstanding.

Thanks!

Alvaro.

On 1/9/17, 6:55 AM, "Tim Bruijnzeels" <tim@ripe.net<mailto:tim@ripe.net>> wrote:



Let me try to make the point again – I didn’t do a good job above.  In fact, reading this over I want to change it…

In this document you’re saying: here’s a new protocol that SHOULD be used instead of rsync (3.4.1).

And, as you mentioned above, the intent is to eventually phase out rsync in favor of RRDP.  Time lines to phase it out are really out of the scope of this (or I think any other RFC) document because it is something the RPKI community agrees on and migrates to, just like any other new protocol.

All that is good.

However, both RFC6480 and RFC6481 mandate the use of rsync: “all publication points MUST be accessible via rsync” and “publication repository MUST be available using rsync”.  Which means that to comply with the RPKI architecture rsync MUST be supported forever, regardless of whether RRDP is used, or a different protocol that may come along in the future…or even if it is not needed at all anymore (not even for eventual backup). ☹

The question about updating RFC6480 above should have been a statement: this document should update RFC6480/RFC6481 so that rsync is not required anymore.

Changing the text in RFC6480/RFC6481 to say “MUST use RRDP” would just result in another update later if another protocol ever comes along, so I think this document should be explicit in the change (to allow the move away from rsync), but still generic…for example, the text in RFC6480/RFC6481 can be replaced with something like: “The publication point MUST be accessible using a retrieval mechanism consistent with the accessMethod element value(s).  Multiple retrieval mechanisms can be supported at the repository operator’s discretion”.

A change like that would require that this document be tagged to Update RFC6480/RFC6481 (and would of course return RFC6481 to be Normative).

Ok, I understand. But I will need a bit of time for the text. (baby number two has his due date this Thursday so bear with me).