Last Call Review of draft-ietf-nfsv4-mv0-trunking-update-02
review-ietf-nfsv4-mv0-trunking-update-02-secdir-lc-wood-2018-12-13-00

Hello,

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
  These comments were written primarily for the benefit of the security 
area directors.  Document editors and WG chairs should treat these 
comments just like any other last call comments.

   The summary of my review is: Ready with nits.

This document is in great shape and very well written. Most of my 
comments are editorial in nature aimed at helping improve readability of 
the document. Please let me know if you’ve further questions, 
comments, or concerns.

- Section 3, fourth bullet: Regarding “[NFSv4.1] distinguishes two 
(see [RFC5661]),” would it be possible to provide the two types of 
trunking relationships inline? Although this document is meant to 
supplement existing work, I do think it would help improve readability 
and minimize cross-referencing.
- Section 5.1, fifth bullet: Rather than specify that addresses “MUST 
provide a way of connecting to a single server,” could we specify 
desired client behavior if this does not happen? I do not know how often 
such misconfigurations occur, though it seems prudent to provide 
guidance in case it does.
- Section 5.2, sixth bullet: It might be worth pointing to the amended 
Security Considerations section, which contains relevant text regarding 
DNSSEC validation for host name entries. I left a note here while 
reading only to discover it was addressed later on.
- Section 5.2.3: Are clients allowed to race connection attempts across 
all types available? The text implies that this must be done 
sequentially, which seems unnecessarily prohibitive.
- Section 5.2.5, third paragraph, first sentence: Perhaps a simpler way 
to write this is something akin to “fs_locations cannot point to 
alternate locations until data propagation occurs”?

Best,
Chris