[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:12 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 5EC78124F57 for <sandbox-mailoutput@ietfa.amsl.com>; Thu, 5 Apr 2018 14:12:30 -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 5oWAlsGUFDDm for <sandbox-mailoutput@ietfa.amsl.com>; Thu, 5 Apr 2018 14:12:29 -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 2001312D7F2 for <sandbox-mailoutput@ietf.org>; Thu, 5 Apr 2018 14:12:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by sandbox.amsl.com (Postfix) with ESMTP id 1B6131C514D for <sandbox-mailoutput@ietf.org>; Thu, 5 Apr 2018 14:12:29 -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 teTjXINy59w6 for <sandbox-mailoutput@ietf.org>; Thu, 5 Apr 2018 14:12:27 -0700 (PDT)
Received: from sandbox.amsl.com (localhost [IPv6:::1]) by sandbox.amsl.com (Postfix) with ESMTP id 199EC1C514C for <sandbox-mailoutput@ietf.org>; Thu, 5 Apr 2018 14:12:27 -0700 (PDT)
Content-Type: multipart/mixed; boundary="===============4182318317633624396=="
MIME-Version: 1.0
From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
To: sandbox-mailoutput@ietf.org
Message-ID: <152296274709.31572.6855971117265006190.idtracker@sandbox.amsl.com>
Date: Thu, 05 Apr 2018 14:12:27 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sandbox-mailoutput/GwyVcq9YZ0UOL6xk7rxXfN0y4hw>
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:12:30 -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:12 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 ---