Re: [sidr] AD Review of draft-ietf-sidr-rpki-oob-setup-04

Rob Austein <sra@hactrn.net> Wed, 21 December 2016 18:14 UTC

Return-Path: <sra@hactrn.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 D5E4B1294FE; Wed, 21 Dec 2016 10:14:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.001
X-Spam-Level:
X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_PASS=-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 vlw00egK449F; Wed, 21 Dec 2016 10:14:32 -0800 (PST)
Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF5D129501; Wed, 21 Dec 2016 10:14:32 -0800 (PST)
Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 0D98339917; Wed, 21 Dec 2016 18:14:32 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 5C8754470DE7; Wed, 21 Dec 2016 13:13:23 -0500 (EST)
Date: Wed, 21 Dec 2016 13:13:23 -0500
From: Rob Austein <sra@hactrn.net>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>
In-Reply-To: <CAA3F956-9CA9-4A3B-9AFF-C5D4D87A815D@cisco.com>
References: <C219759D-6DE4-4B23-95C3-E39156FEAFC2@cisco.com> <20161220173336.DD3B64469FFE@minas-ithil.hactrn.net> <51D959C0-064D-451F-8224-737613A60F86@cisco.com> <20161221011442.D34DF446EADB@minas-ithil.hactrn.net> <CAA3F956-9CA9-4A3B-9AFF-C5D4D87A815D@cisco.com>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-Id: <20161221181323.5C8754470DE7@minas-ithil.hactrn.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/YTXBqQ_r6QNYcMY7d0wsp25mnnA>
Cc: Chris Morrow <morrowc@ops-netman.net>, sidr-chairs@ietf.org, Rob Austein <sra@hactrn.net>, draft-ietf-sidr-rpki-oob-setup@ietf.org, sidr@ietf.org
Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-oob-setup-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: Wed, 21 Dec 2016 18:14:34 -0000

At Wed, 21 Dec 2016 12:20:54 +0000, Alvaro Retana (aretana) wrote:
...
> it still doesn?t tell me what the child should do.  I don?t think
> you want to specify taking up one or the other, but at least include
> some text that says that the child can choose.
> 
> In thinking about this I came up with another question.  A
> repository doesn?t have to honor every publisher_request it
> receives, right?   Specially ones that are the result of a referral?
> There is a ?refused? error reason defined, so that takes care of
> that?but I?m thinking that as a client I might want to take an
> <offer> instead of playing around with a <referral> because I know
> for sure my parent can do the job.  I?m sure there are other
> considerations that the child should take into account.  I?m ok if
> you just write that the selection criteria is out of scope.

I just added this to the end of "Protocol Walk-Through":

      <t>
        Any RPKI operator is free to run their own publication service
        should they feel a need to do so, and a child need not accept
        any particular &lt;offer/&gt; or &lt;referral/&gt;.  In
        general, having a smaller number of larger publication
        repositories is probably good for overall system performance,
        because it will tend to reduce the number of distinct
        repositories from which each relying party will need to fetch,
        but the decision on where to publish is up to individual RPKI
        CA operators and out of scope for this protocol.
      </t>

I hope this addresses the issue.  Same URLs for updated version:

> Proposed -05, reflecting comments from AD review:
> 
>   https://subvert-ietf.hactrn.net/rpki-oob-setup/draft-ietf-sidr-rpki-oob-setup-05.txt
>   https://subvert-ietf.hactrn.net/rpki-oob-setup/draft-ietf-sidr-rpki-oob-setup-05-from-04.diff.html
> 
> Absent objections, I will post to I-D repository, probably tomorrow.

I think we are close enough at this point that I will push this
version this afternoon.  Can always do another rev if we must, but I
want to get these changes into the version that directorates are being
asked to review.