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
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
