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

[Christopher Wood <[e-mail]>]

On Thu, Dec 27, 2018 at 10:52 AM Chuck Lever <[e-mail]> wrote:
>
>
>
> > 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.

No further changes needed. Thanks for the updates!

Best,
Chris