Subject: [Sandbox-mailoutput] [Django development] Personal ID list of [email-masked] notification: Changes to draft-ietf-sidr-slurm

From: IETF Secretariat <[email-masked]>
Date: Thu, 05 Apr 2018 14:18:47 -0700

The attached message would have been sent, but the tracker is in development mode.
It was not sent to anybody.

Subject: Personal ID list of [email-masked] notification: Changes to draft-ietf-sidr-slurm
From: IETF Secretariat <[email-masked]>
To: <[email-masked]>
Date: Thu, 05 Apr 2018 14:18:47 -0700

Hello,

This is a notification from the Personal ID list of [email-masked].

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)