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