Roman Danyliw's No Objection on draft-ietf-nfsv4-rfc5661sesqui-msns-03: (with COMMENT)
Roman Danyliw via Datatracker <[email protected]> Tue, 17 Dec 2019 18:05:42 -0800
| Newsgroups | gmane.ietf.nfsv4 |
|---|---|
| Message-ID | <[email protected]> |
Roman Danyliw has entered the following ballot position for draft-ietf-nfsv4-rfc5661sesqui-msns-03: 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-nfsv4-rfc5661sesqui-msns/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I conducted this review in the spirit of draft-roach-bis-documents-00 and the significant security caveats enumerated in Appendix C. A big thanks to Sean Turner for his SECDIR reviews and the authors for incorporating this feedback where appropriate. ** Section 1.1. The motivation for the editorial approach taken in this document is cited as being in [I.D-roach-bis-documents] but there is not such reference in the document. ** The SECDIR review asked about retaining id-sha1 in Section 14.3. The WG was going to be consulted. What was the resolution? In the spirit of this focused review, keeping it REQUIRED doesn’t present an issue, IMO. However, would there be a reduced set of algorithms that could be RECOMMENDED in the Security Considerations? ** Section 21, Per “When DNS is used to convert server names to addresses and DNSSEC [29] is not available, the validity of the network addresses returned cannot be relied upon.”, this concern about the fidelity of the DNS information is a helpful consideration. It would be worth mentioning/recommending the use of other DNS technologies such as DNS over TLS [RFC7858] and DNS over HTTPS [RFC8484] that could provide additional/alternatives confidence mechanisms in the DNS data. _______________________________________________ nfsv4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nfsv4