Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT)

Oleg Muravskiy <oleg@ripe.net> Mon, 27 February 2017 09:25 UTC

Return-Path: <oleg@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 72B3712950F; Mon, 27 Feb 2017 01:25:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 MjGdejhj5AGC; Mon, 27 Feb 2017 01:25:09 -0800 (PST)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0EC01294CA; Mon, 27 Feb 2017 01:25:06 -0800 (PST)
Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from <oleg@ripe.net>) id 1ciHYB-000BMh-CZ; Mon, 27 Feb 2017 10:25:00 +0100
Received: from dog.ripe.net ([193.0.1.217] helo=[IPv6:::1]) by titi.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from <oleg@ripe.net>) id 1ciHYA-0004TO-41; Mon, 27 Feb 2017 10:24:58 +0100
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset="utf-8"
From: Oleg Muravskiy <oleg@ripe.net>
In-Reply-To: <A3DDD124-EBE6-42AC-B66F-532AF0A5E175@cisco.com>
Date: Mon, 27 Feb 2017 09:24:57 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <9DC16A6F-84C6-4E59-9086-3C4EB1A0C05E@ripe.net>
References: <148721059915.31454.12790381111112907537.idtracker@ietfa.amsl.com> <47B3699A-B344-4BA5-A131-309A6DF04FBD@ripe.net> <3A008C78-B846-4F8F-A813-C54C276FAEFD@cisco.com> <A3DDD124-EBE6-42AC-B66F-532AF0A5E175@cisco.com>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>
X-Mailer: Apple Mail (2.3124)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: --------
X-RIPE-Spam-Report: Spam Total Points: -8.0 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.5 BAYES_05 BODY: Bayes spam probability is 1 to 5% [score: 0.0395]
X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b74c20a437c05f51bdb513b29587aba6745
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/URUmNpzoVptb1gYcdgLLVBbC2Xs>
Cc: "sidr@ietf.org" <sidr@ietf.org>, "morrowc@ops-netman.net" <morrowc@ops-netman.net>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, The IESG <iesg@ietf.org>, "sandy@tislabs.com" <sandy@tislabs.com>, "draft-ietf-sidr-delta-protocol@ietf.org" <draft-ietf-sidr-delta-protocol@ietf.org>
Subject: Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT)
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, 27 Feb 2017 09:25:10 -0000

Hi everybody,

> On 23 Feb 2017, at 20:25, Alvaro Retana (aretana) <aretana@cisco.com> wrote:
> 
> Tim:
>  
> Hi!
>  
> Given the feedback so far on the list, I think we should roll back the updates in preparation for next week’s IESG Telechat.

Currently RFC7730 (TAL format) only allows rsync URIs in there.

In order to allow RRDP in TAL, I think we have to keep the update to RFC7730 in draft-ietf-sidr-delta-protocol, namely this part of the draft:

============================================================================
4.3.  Updates to RFC7730

4.3.1.  Update in Section 2.1, Trust Anchor Locator Format

   OLD:

      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.

   NEW:

      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.

4.3.2.  Update in Section 2.2, TAL and Trust Anchor Certificate
        Considerations

   OLD:

      Each rsync URI in the TAL MUST reference a single object.  It MUST
      NOT reference a directory or any other form of collection of
      objects.

      ...

      Where the TAL contains two or more rsync URIs, then the same self-
      signed CA certificate MUST be found at each referenced location.

   NEW:

      Each URI in the TAL MUST reference a single object.  It MUST NOT
      reference a directory or any other form of collection of objects.

      ...

      Where the TAL contains two or more URIs, then the same self-signed
      CA certificate MUST be found at each referenced location.

4.3.3.  Update in Section 5.1, Normative References

   Remove the reference to RFC5781, "The rsync URI Scheme".

   Add a reference to RFC3986, "Uniform Resource Identifier (URI):
   Generic Syntax".


============================================================================

What do you think?

Oleg


>  
> Thanks!
>  
> Alvaro.
>  
> On 2/17/17, 9:56 AM, "sidr on behalf of Alvaro Retana (aretana)" <sidr-bounces@ietf.org on behalf of aretana@cisco.com> wrote:
>  
> > **Chairs**:  Given that this is a significant change, and that the WG may have not been
> > focused on the discussion, and that we now have a little more time given the fact that the
> > IESG review of this document was deferred until Mar/2…  Please explicitly ask the WG to
> > review the Updates to RFC6480, RFC6481 and RFC7730.  I think that a week of discussion
> > on the list should be enough.
> 
>