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

[Spencer Dawkins at IETF <[e-mail]>]

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