Re: [secdir] secdir review of draft-ietf-nfsv4-mv0-trunking-update-02

[Chuck Lever <[e-mail]>]

> On Dec 20, 2018, at 11:14 AM, Spencer Dawkins at IETF <[e-mail]> wrote:
> 
> Hi, Authors,
> 
> On Tue, Dec 11, 2018 at 8:16 AM Christopher Wood <[e-mail]> wrote:
> 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.
> 
> I believe these are the only Last Call comments I've seen on your draft, and the Last Call period has ended. 
> 
> Could you respond to Christopher, and (if necessary) submit a revised draft?

I actually hadn't seen any comments until now! Thanks for
forwarding this. I will huddle with Dave and submit a
revised draft within the next week.


> Thanks!
> 
> Spencer (D)
>  
> 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
> 

--
Chuck Lever