[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?