[sidr] Eric Rescorla's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT)

Eric Rescorla <ekr@rtfm.com> Mon, 02 April 2018 16:56 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: sidr@ietf.org
Delivered-To: sidr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 243CE12D778; Mon, 2 Apr 2018 09:56:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-sidr-slurm@ietf.org, Chris Morrow <morrowc@ops-netman.net>, aretana.ietf@gmail.com, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.77.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152268817614.31085.6790269677708093564.idtracker@ietfa.amsl.com>
Date: Mon, 02 Apr 2018 09:56:16 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/q8YmOXzBUuyM0qI0wzwEs6yRy_w>
Subject: [sidr] Eric Rescorla's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.22
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, 02 Apr 2018 16:56:16 -0000

Eric Rescorla has entered the following ballot position for
draft-ietf-sidr-slurm-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

   path of a BGP route.  However, ISPs may want to establish a local
   view of the RPKI to control its own network while making use of RPKI
   data.  The mechanisms described in this document provide a simple way

Nit: their network

   the information expressed via putative Trust Anchor(TA) and the
   certificates downloaded from the RPKI repository system.  For
   instances, [RFC6491] recommends the creation of ROAs that would

I don't really understand this sentence. Why "putatve"

   operators are hereby called Simplified Local internet nUmber Resource
   Management with the RPKI (SLURM).

It would help here to say that this includes filtering.

   In general, the primary output of an RP is the data it sends to
   routers over the rpki-rtr protocol.  The rpki-rtr protocol enables
   routers to query an RP for all assertions it knows about (Reset

citation for rpki-rtr plese.

   members that are not defined here MUST NOT be used in SLURM Files.
   An RP MUST consider any deviations from the specification an error.
   Future additions to the specifications in this document MUST use an

Nit: errors.

   acceptable.  Each "slurmTarget" element contains merely one "asn" or
   one "hostname".  An explanatory "comment" MAY be included in each
   "slurmTarget" element so that it can be shown to users of the RP

Is this exclusive or?

   Emergency Response Team Coordination, the SLURM file source may
   generate a SLURM file that is to be applied to only one specific RP.
   This file can take advantage of the "target" element to restrict the

I am having trouble reading this sentence. Can you please rephrase.

   [RFC6487].  This is the value of the ASN.1 OCTET STRING without the
   ASN.1 tag or length fields.
IMPORTANT: There is an opportunity for ambiguity here in case the SPKI was not
DER-encoded. I assume you mean this must be taken directly from the cert?

   The following JSON structure represents an array of
   "prefixAssertions" with an element for each use case listed above:

I guess that the semantics here are obvious, but perhaps you could state them
explicitly, given that this is actually not exactly the same as an ROA.

3.5.2.  BGPsec Assertions
IMPORTANT: It seems even less obvious what the semantics are here for injecting
BGPSec assertions. How do you reconstruct the BGPSec data.

          contained by any prefix in any <prefixAssertions> or
          <prefixFilters> in file Z.

OK, so you are going to error out even if there are assertions which are
identical?