[sidr] Warren Kumari's Discuss on draft-ietf-sidr-slurm-07: (with DISCUSS and COMMENT)

Warren Kumari <warren@kumari.net> Sun, 01 April 2018 21:02 UTC

Return-Path: <warren@kumari.net>
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 DDF131200A0; Sun, 1 Apr 2018 14:02:51 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari <warren@kumari.net>
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.76.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152261657190.23824.4759371193986790926.idtracker@ietfa.amsl.com>
Date: Sun, 01 Apr 2018 14:02:51 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/eqEj_-_M09I7mYaV5Uv-LcycbZY>
Subject: [sidr] Warren Kumari's Discuss on draft-ietf-sidr-slurm-07: (with DISCUSS and 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: Sun, 01 Apr 2018 21:02:52 -0000

Warren Kumari has entered the following ballot position for
draft-ietf-sidr-slurm-07: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I don't understand the targeting as it related to domain/host names (and
suspect that others will have the same issue).

>From section 3.3:
"  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.... Accordingly, the SLURM file
   source needs to indicate which RP(s) should make use of the file by
   adding the domain name(s) of the RP(s) to the SLURM file target...
  Such a target value is a server name expressed in FQDN.

   "slurmTarget": [
     {
       "hostname": "rpki.example.com",
       "comment": "This file is intended for RP server rpki.example.com"
     }
]

So, if I want to target multiple RPs (rpki1.example.com, rpki2.example.com) can
I do:

   "slurmTarget": [
     {
       "hostname": "example.com",
       "comment": "This file is intended for RP server rpki.example.com"
     }
]

?
The "domain names(s)" versus "hostname" vs "server name expressed in FQDN" text
is handwavey. I'm assuming that I'd need to do:

   "slurmTarget": [
     {
       "hostname": "rpki1.example.com",
       "comment": "This file is intended for RP server rpki1.example.com"
     },
{
       "hostname": "rpki2.example.com",
       "comment": "This file is intended for the RP server, rpki2.example.com"
     },
]"
Can you please make this clearer, and hopefully add more targets to the
examples? This seems like an easy fix / clarification, happy to clear once it
is, er, clear.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have a few questions and editorial comments:

1: Section Abstract:
ISPs can also be able to use the RPKI to validate the path of a BGP route.
I think you meant "ISPs can also use the RPKI..."

2: Section 1.  Introduction
"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." I think this should be either "a
putative Trust Anchor (TA)" or "putative Trust Anchors (TA)" (single vs
plurals). I agree with others that "putative TA" is not a well known term -
perhaps you can find a better one?

Section 3.4.1.  Validated ROA Prefix Filters
In the "prefixFilters examples", I think it would be helpful to update the
comments to be more explicit about what is being matched (e.g"All VRPs covered
by 198.51.100.0/24 and matching AS 64497")