Re: [sidr] I-D Action: draft-ietf-sidr-rfc6490-bis-03.txt

David Mandelberg <david@mandelberg.org> Wed, 01 April 2015 02:06 UTC

Return-Path: <david@mandelberg.org>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C241A0095 for <sidr@ietfa.amsl.com>; Tue, 31 Mar 2015 19:06:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 u-atDe0u_fzf for <sidr@ietfa.amsl.com>; Tue, 31 Mar 2015 19:06:18 -0700 (PDT)
Received: from nm16-vm4.access.bullet.mail.gq1.yahoo.com (nm16-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.104]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689521A005D for <sidr@ietf.org>; Tue, 31 Mar 2015 19:06:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427853978; bh=l90IYnNRkwvwpAjzQkSbe+Gh5dgpddxDj9tN9Mj69vM=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject; b=fhlOGRbgzkZvxYxNMjT9cO+NijbSvOeIgRHN2UHDVs56BXKdNBus3ASeiZmXmbeOcKEaDEIjOwtgzkLB8vu6H4ALXwxqPCSLQ/cbmVhzsqP+fDBWJTmFz3v0HWWtpmYp57o1yG3j4MgX+LzpfUk+TTjZZu8og9wOxFoR5PUSQy4pujkJWMhLIZJ9cM+kftbHO8sznQBW1jJk+0PEknq3W8OK9R3m5D6kfNvpyKqdcmVd+8EIJOAAZC6ud70t1LACZTcQ3HtCnQnswnXh6ztMtfQVC+KQmxTjFIR01fjGWLBuC+4fK2Krei9UruRGDx2i9t3lDXlqFZgxB75GUv2Zgg==
Received: from [216.39.60.171] by nm16.access.bullet.mail.gq1.yahoo.com with NNFMP; 01 Apr 2015 02:06:18 -0000
Received: from [98.138.104.98] by tm7.access.bullet.mail.gq1.yahoo.com with NNFMP; 01 Apr 2015 02:06:18 -0000
Received: from [127.0.0.1] by smtp118.sbc.mail.ne1.yahoo.com with NNFMP; 01 Apr 2015 02:06:17 -0000
X-Yahoo-Newman-Id: 878316.67253.bm@smtp118.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 5RA2MWEVM1mhKDokCxNR9ZIACDgyqqIpXUKqVQAnredHsuW s8O3AmMPBS0npDEd.zo7cIp7K_VDifAUppLdtOP1EZ7A6KbkKJhzMAtJUa.2 Dsru1mazKnCaC5DiOkEET2T6wSB7DDrRf0fE5UPFOMwwIK5CvKMlu1HkZFeV Wi893OEi2C80kfW7b9yJiJb_YBl6K7cOwy6vWMMTPudsYs6qIoAGjNM8MShG dVn6wVVNIkzR4GmppxWDK6eKrYM.UOYNxEWgSQN5ARTohVhz8kG9MHoUAiI_ nTro6lDeg5FwcZNNLQaBxh02zxfNNhq4muyr5FVmsrBHh1quvURBmaRS5iK2 xRWBH8C2GxYI7U.qOlddKYn.mW9x.xL28ZDnbCtbv4oIZ_la.5mqt1hn6kAq .t3rFlXI7zFW6n8Dc42.TnbQUx5zbHTDZhhk5RHytxhJEdNqDxUGjFzT1BFp jf.vTnN2ryALllcihSiioTEs9_i7w6SNZxiC7xYaJH8wZSvFYA228B5V3Opj PrajyaqyoPzpcRGWuPyuwvwG1.78DSMwzhyo2QtXVHpXfpN49RV_VJUYpNy. 2TXO1ZiUIYZI1OlONErN1Xu9_rqmxoSdTdwm1QnB1v0N3n.cNmQ--
X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708-
Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id C7D9D1C6095 for <sidr@ietf.org>; Tue, 31 Mar 2015 22:06:16 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Tue, 31 Mar 2015 21:06:16 -0500
From: David Mandelberg <david@mandelberg.org>
To: sidr@ietf.org
In-Reply-To: <20150328232012.8464.95328.idtracker@ietfa.amsl.com>
References: <20150328232012.8464.95328.idtracker@ietfa.amsl.com>
Message-ID: <bc62010f92fd5e6e49d013c2013df692@mail.mandelberg.org>
X-Sender: david@mandelberg.org
User-Agent: Roundcube Webmail/0.7.2
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/VRUuq4EyRvSnL8U1tmFrQn52cUw>
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rfc6490-bis-03.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
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, 01 Apr 2015 02:06:21 -0000

Hi,

While thinking about RRDP (draft-ietf-sidr-delta-protocol-00), I 
realized that there's a minor conflict between RRDP's push to transition 
from rsync to http(s), and the TAL format's requirement to use only 
rsync URIs. I propose the below changes to 
draft-ietf-sidr-rfc6490-bis-03 to make RRDP's work easier in the future 
without causing any harm now. Sorry to bring this up so late in the 
process for draft-ietf-sidr-rfc6490-bis.


In the abstract, change:

    This document obsoletes RFC 6490 by adding support for multiple URIs 
in a TAL.

to:

    This document obsoletes RFC 6490 by adding support for multiple URIs 
in a TAL, and allowing URI schemes other than rsync.


In section 2.1, change:

    where the URI section is comprised of one of more of the ordered
    sequence of:


       1.1)  an rsync URI [RFC5781],

       1.2)  a <CRLF> or <LF> line break.

to:

    where the URI section is comprised of one of more of the ordered
    sequence of:


       1.1)  a URI [RFC3986],

       1.2)  a <CRLF> or <LF> line break.

    The URI section MUST include one or more rsync URIs [RFC5781]. 
Non-rsync URIs MAY be present.

I assume that an rfc3986 URI cannot include either <CRLF> or <LF>, but 
if I'm wrong then I'd like to add a MUST NOT somewhere in this text.


In section 2.2, change:

    Each rsync URI in the TAL MUST reference a single object.

to:

    Each URI in the TAL MUST reference a single object.

and:

    Where the TAL contains two or more rsync URIs, then the same self-
    signed CA certificate MUST be found at each referenced location.  In
    order to operational increase resilience, it is RECOMMENDED that the
    domain name parts of each of these URIs resolve to distinct IP
    addresses that are used by a diverse set of repository publication
    points, and these IP addresses be included in distinct Route
    Origination Authorizations (ROAs) objects signed by different CAs.

to:


    Where the TAL contains two or more URIs, then the same self-
    signed CA certificate MUST be found at each referenced object.  In
    order to increase operational resilience, it is RECOMMENDED that
    no two URLs which share a scheme have domain name parts that can
    resolve to the same IP address. Additionally, it is RECOMMENDED that
    these IP addresses be included in distinct Route
    Origination Authorizations (ROAs) objects signed by different CAs.


In section 3, add this paragraph at the beginning:

    An RP MUST support the rsync URI scheme and MAY support additional
    URI schemes. An RP SHOULD ignore all URIs with unsupported schemes.

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/