[sidr] Benjamin Kaduk's No Objection on draft-ietf-sidr-slurm-07: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-sidr-slurm-07: No Objection

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/



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

The directorate reviews have some good comments, especially about expanding
acronyms/defining terms.

I think Section 3.3 would benefit from greater clarity about individual
components of the JSON array that is the value of the "slurmTarget" element,
versus that element itself.  (Also, slurmTarget appears to be mandatory, so
talking about cases where it is present seems strange, and presumably a
nonempty value being present is the desired criterion.)

I'm also not entirely sure I understand the intended semantics --
when first introduced in Section 3.2, we say that "all targets MUST
be acceptable to the RP".  (Presumably that includes both ASN and
FQDN entries.) Does this mean that if the same SLURM file is
provided to multiple RPs, those RPs both need to be "responsible
for" all the ASNs and FQDNS contained therein?  Would this present a
limit on the ability to reuse SLURM files for multiple recipients
within a single administrative domain (that may span multiple ASNs
and FQDNs)?

Some editorial suggestions follow.

Abstract:

OLD:

   [...] ISPs can also be able to use the RPKI to validate the
   path of a BGP route.

NEW:

   [...] ISPs can also use the RPKI to validate the
   path of a BGP route.

Section 3.2

OLD:
   o  A SLURM Version indication that MUST be 1

NEW:
   o  A SLURM Version indication.  This document specifies version 1.

Also, in

      *  Zero or more target elements.  In this version of SLURM, there
         are two types of values for the target: ASN or Fully Qualified
         Domain Name(FQDN).  If more than one target line is present,
         all targets MUST be acceptable to the RP.

What's the difference between a target element and a target line?

Section 3.5 (both subsections):

"is locally configured with" does not mention SLURM at all as being
involved in that configuration; perhaps it should.

Section 4.2

   [...] To do so, the RP MUST
   check the entries of SLURM file with regard to overlaps of the INR
   assertions and report errors to the sources that created these SLURM
   files in question.

The "report errors to the sources" part seems ineligible for
MUST-level requirement.

Also, in case of conflict, does the "MUST NOT use them" apply to all
SLURM files, only the ones with directly conflicting inputs, or only
enough files to remove the conflict?

Section 6

I'm always a little sad to see security-relevant functionality (such
as the transport with authenticity and integrity protection of SLRUM
files over the network) left as out of scope with no examples of
reasonable usage given.

I also wonder if we would benefit from a little discussion of the
potential routing issues that could arise from using a "broken" (or
deliberately adversarial) SLURM file, though I expect that the
target audience is probably pretty familiar with these already.