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

From: "Christopher Wood" <[email-masked]>
Date: Tue, 11 Dec 2018 06:16:33 -0800

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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 20 Dec 2018 10:14:45 -0600

Hi, Authors,

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

---

From: Chuck Lever <[email-masked]>
Date: Thu, 20 Dec 2018 11:18:27 -0500

> On Dec 20, 2018, at 11:14 AM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Authors,
> 
> On Tue, Dec 11, 2018 at 8:16 AM Christopher Wood <[email-masked]> wrote:
> Hello,
> 
> I believe these are the only Last Call comments I've seen on your draft, and the Last Call period has ended. 
> 

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.

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Thu, 27 Dec 2018 13:52:29 -0500

> the document. Please let me know if you’ve further questions, 

Hello Chris-

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

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

> guidance in case it does.

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

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

> sequentially, which seems unnecessarily prohibitive.

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

> 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