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?
> 
> 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.

Hello Chris-

Thanks for your review, and my apologies for the delayed response.


> - 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.

After discussion, Dave and I removed the text that mentions NFSv4.1-
specific features in this paragraph. They are an unnecessary
digression.


> - 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.

Dave and I agree that specifying client behavior here is a better
approach. Dave provided new text.


> - 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.

We assume you meant Section 5.1, sixth bullet. A reference to Section
7 "Security Considerations" was added at the end of this paragraph.


> - 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.

We introduced a couple of paragraphs of implementation guidance that
compares sequential and parallel connection approaches.


> - 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”?

We updated the text to clarify the ordering requirements.


Because you feel the document is "ready with nits" I've taken the
liberty of submitting draft-ietf-nfsv4-mv0-trunking-update-03
with these changes. rfcdiff will show the exact text that has
changed. Let us know if any further changes are necessary.


--
Chuck Lever