[nfsv4] Roman Danyliw's No Objection on draft-ietf-nfsv4-rfc5661sesqui-msns-03: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

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.