[Sandbox-mailoutput] [Django development] Personal ID list of jhaas@pfrc.org notification: Changes to draft-ietf-sidr-slurm
IETF Secretariat <ietf-secretariat-reply@ietf.org> Thu, 05 April 2018 21:18 UTC
Return-Path: <ietf-secretariat-reply@ietf.org>
X-Original-To: sandbox-mailoutput@ietfa.amsl.com
Delivered-To: sandbox-mailoutput@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B70412D80E for <sandbox-mailoutput@ietfa.amsl.com>; Thu, 5 Apr 2018 14:18:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 i1FcY4UDqyFt for <sandbox-mailoutput@ietfa.amsl.com>; Thu, 5 Apr 2018 14:18:48 -0700 (PDT)
Received: from mailtest.ietf.org (unknown [4.31.198.57]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE60512D7F8 for <sandbox-mailoutput@ietf.org>; Thu, 5 Apr 2018 14:18:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by sandbox.amsl.com (Postfix) with ESMTP id AB3C31C514D for <sandbox-mailoutput@ietf.org>; Thu, 5 Apr 2018 14:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at mailtest.ietf.org
Received: from mailtest.ietf.org ([4.31.198.57]) by localhost (mailtest.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCarQA-sZ2sf for <sandbox-mailoutput@ietf.org>; Thu, 5 Apr 2018 14:18:47 -0700 (PDT)
Received: from sandbox.amsl.com (localhost [IPv6:::1]) by sandbox.amsl.com (Postfix) with ESMTP id AD4121C514C for <sandbox-mailoutput@ietf.org>; Thu, 5 Apr 2018 14:18:47 -0700 (PDT)
Content-Type: multipart/mixed; boundary="===============7013587325920423326=="
MIME-Version: 1.0
From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
To: sandbox-mailoutput@ietf.org
Message-ID: <152296312770.595.15585728753198530790.idtracker@sandbox.amsl.com>
Date: Thu, 05 Apr 2018 14:18:47 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sandbox-mailoutput/6uRuQP93h03gl7hOXRYD8EoQ-UQ>
Subject: [Sandbox-mailoutput] [Django development] Personal ID list of jhaas@pfrc.org notification: Changes to draft-ietf-sidr-slurm
X-BeenThere: sandbox-mailoutput@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <sandbox-mailoutput.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sandbox-mailoutput>, <mailto:sandbox-mailoutput-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sandbox-mailoutput/>
List-Post: <mailto:sandbox-mailoutput@ietf.org>
List-Help: <mailto:sandbox-mailoutput-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sandbox-mailoutput>, <mailto:sandbox-mailoutput-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2018 21:18:51 -0000
The attached message would have been sent, but the tracker is in development mode. It was not sent to anybody.
--- Begin Message ---Hello, This is a notification from the Personal ID list of jhaas@pfrc.org. Document: draft-ietf-sidr-slurm, https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ Change by Eric Rescorla on 2018-04-05 14:18 PDT: [Ballot comment] > 1. There may be conflicting changes to Origin Validation > assertions if there exists an IP address X and distinct SLURM > files Y, Z such that X is contained by any prefix in any > or in file Y and X is > contained by any prefix in any or > in file Z. OK, so you are going to error out even if there are assertions which are identical? > Each ROA Prefix Assertion MUST contain an IPv4 or IPv6 prefix, an AS > number, optionally a MaxLength and optionally a comment that can be > shown to users of the RP software. > > 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. > means "applies to all". The meaning of the "slurmTarget" element, if > present, is determined by the user. If a "slurmTarget" element is > present, an RP SHOULD verify that the target is an acceptable value, > and reject this SLURM file if the "slurmTarget" element is not > acceptable. Each "slurmTarget" element contains merely one "asn" or > one "hostname". An explanatory "comment" MAY be included in each Is this exclusive or? > slurmTarget example 1 > > Also, for instance, an organization may share one trusted third-party > SLURM file source. For the local control, or in the case of > Emergency Response Team Coordination, the SLURM file source may > generate a SLURM file that is to be applied to only one specific RP. I am having trouble reading this sentence. Can you please rephrase. > > 3.1. Use of JSON > > This document describes responses in the JSON [RFC8259] format. JSON > members that are not defined here MUST NOT be used in SLURM Files. > An RP MUST consider any deviations from the specification an error. Nit: errors. > consideration for routing decisions) any assertions in the RPKI that > are overridden by local Origin Validation assertions and BGPsec > assertions. > > 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 citation for rpki-rtr plese. > discretion. Additionally, a network operator might wish to make use > of a local override capability to protect routes from adverse actions > [RFC8211], until the results of such actions have been addressed. > The mechanisms developed to provide this capability to network > operators are hereby called Simplified Local internet nUmber Resource > Management with the RPKI (SLURM). It would help here to say that this includes filtering. > described in [RFC6811], and validation of the path of a route is > described in [RFC8205].) > > However, an "RPKI relying party" (RP) may want to override some of > the information expressed via putative Trust Anchor(TA) and the > certificates downloaded from the RPKI repository system. For I don't really understand this sentence. Why "putatve" > Number Resources (INRs) to make verifiable statements about those > resources. Network operators, e.g., Internet Service Providers > (ISPs), can use the RPKI to validate BGP route origination > assertions. ISPs can also be able to use the RPKI to validate the > 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 Nit: their network Best regards, The Datatracker draft tracking service (for the IETF Secretariat)--- End Message ---
- [Sandbox-mailoutput] [Django development] Persona… IETF Secretariat