Ben, Thanks very much for your comments.
Please see authors' responses in lines. > 在 2018年4月4日，03:43，Ben Campbell <b...@nostrum.com> 写道： > > Ben Campbell 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: > ---------------------------------------------------------------------- > > Major Comments: > > §6: I also agree with Benjamin's sadness about the security considerations. > The > section really should at least discuss the potential consequences of an > adversary inserting a false slurm file, modifying one on the fly, or > eavesdropping on one. We authors intend to work on a proposed standard mechanism for updating SLURM files through a secure API in the near future. The very proposal is intended to be in a separate draft for SIDROPS. > > Minor Comments: > > §1.1: The document contains at least a few lower case instances of "must". > Please consider using the boilerplate from RFC 8174. > ACK. > §3.3, 1st paragraph: "RP SHOULD verify that the target is an acceptable value" > What is the criteria for acceptability? As we authors have decided to drop slurmTarget element, this is no longer an issue :-) > > §8.2, " [RFC4648]": The document requires Base64 encoding. Doesn't that make > this a normative reference? But it has been listed as a normative reference. > > Editorial Comments and Nits: > > [significant] Abstract (and throughout the document): > > I don't find the term "local view of the RPKI" to be descriptive. IIUC, we are > talking about overriding assertions that come from the RPKI based on local (or > possibly 3rd party) knowledge. This seems to me to be a different thing than > providing a "local view of the RPKI", and I certainly would not have gotten a > sense of that difference from the Abstract alone, and possibly not the > introduction. We will make the change as follows: OLD: However, ISPs may want to establish a local view of the RPKI to control its own network while making use of RPKI data. NEW: However, ISPs may want to establish a local view of exceptions to the RPKI data in the form of local filters and additions. Hopefully this will give context to the term ‘local view’ throughout the document. > > §1, last paragraph: Please expand or define rpki-rtr on first mention. ACK. > > §3.4.1: Please expand SKI on first mention. (You do so in the second mention > :-) ) > > ACK. Di _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
