[sidr] AD Review of draft-ietf-sidr-slurm-04

[Alvaro Retana <[e-mail]>]

Dear authors:

I just finished reading this document.

I have some comments (below) that should be easy to address — please take a
look.  I need you to address the References before I start the IETF Last
Call because of the DownRef to rfc6483.

Thanks!

Alvaro.



Major:

M1. Section 3.1:  I'm not sure what the Normative result is form this piece
of text: "JSON members that are not defined here MUST not be used in SLURM
Files, however Relying Parties SHOULD ignore such unrecognized JSON members
at the top level, while any deviations from the specification at lower
levels MUST be considered an error."  (s/MUST not/MUST NOT)  If the not
defined members MUST NOT be used, when would the RPs not ignore (or even
better, treat as errors) them?  IOW, why use SHOULD instead of MUST?


M2. Section 4.2: "Before an RP configures SLURM files from different source
it MUST make sure there is no internal conflict among the INR assertions in
these SLURM files.  To do so, the RP SHOULD check the entries of SLURM
file..."  I think there's a Normative mismatch: "MUST make
sure...no...conflict" vs "SHOULD check the entries"; the SHOULD leaves the
door open to not always checking -- are there cases when the entries
wouldn't be checked *and* the MUST can still be guaranteed?  It seems to me
like both keywords should be MUST.


M3. Section 6: "...but if the RP updates its SLURM file over the network,
it MUST verify the authenticity and integrity of the updated SLURM file."
 Please indicate that the mechanism to update files, and the
authentication/integrity verification are outside the scope of this
document.


M4. References:

M4.1. s/I-D.ietf-sidr-bgpsec-overview/rfc8205  ...and should be Normative.

M4.2. I believe the following references should also be Normative:
ietf-sidr-rpki-rtr-rfc6810-bis/rfc8210, rfc6483, rfc6810, rfc6811 and
rfc7159.

M4.3. [minor] Please update the references according to the Nits [1].

[1]
https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-sidr-slurm-04.txt





Minor:

P1. "Relying party software MAY modify other forms of output in comparable
ways, but that is outside the scope of this document."  If it's out of
scope, then there shouldn't be any Normative language. s/MAY/may

P2. "Locally Added Assertions" are sometimes called "Locally Adding
Assertions".


Nits:

N1. s/control make use of RPKI data/control use of RPKI data