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

Chuck Lever <chuck.lever@oracle.com> Thu, 27 December 2018 18:52 UTC

Return-Path: <chuck.lever@oracle.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7675C130E7B; Thu, 27 Dec 2018 10:52:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.365
X-Spam-Level:
X-Spam-Status: No, score=-4.365 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6szalskcFkI; Thu, 27 Dec 2018 10:52:40 -0800 (PST)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D8B0126F72; Thu, 27 Dec 2018 10:52:40 -0800 (PST)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wBRIhhKi125446; Thu, 27 Dec 2018 18:52:38 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=Zr1vhy760I5wyT0XC6s7vHQNsiJB+vKyaCkWwY8TmK0=; b=4P1suOIzoz4cQcK9PATI0T6VVGDoJvyXH7cbAenVkiQYvK18gSY5Ayn1y6LN8VHCaztK DYlGlq8EEgR3U30VdJxR9x9VJf7Wr4UDojwdRoYdnLA1mNnSlEWHe6N58110QIABrY8D E9Wcpn4Fopeg1xgmGoYM+pxcxRfaCzqtziClbEn+fdNIavkkQnE6D9NfC9jpTYUEoDtg dBx4vWqImV6UemUs/U/gUw+uCxGerU2xpyguNSzU5OFzprueTDEZWGfn9Yel+0nRvd/6 huulEz6TfHxQc+jICOgJrTdQ5gJpcy+rJk0kaN+gVwCa50Ab9J1Ykg2DPwOTFKX1tFh+ og==
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2130.oracle.com with ESMTP id 2phcptxc9t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Dec 2018 18:52:38 +0000
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wBRIqW43029876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Dec 2018 18:52:32 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wBRIqVbp029392; Thu, 27 Dec 2018 18:52:32 GMT
Received: from anon-dhcp-121.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 Dec 2018 10:52:31 -0800
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <CAKKJt-dVn420A-eyOmHV2M5duORR0BvpNzrBrpN35jPvKDYhRw@mail.gmail.com>
Date: Thu, 27 Dec 2018 13:52:29 -0500
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-nfsv4-mv0-trunking-update@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <BEE9CA7E-2DDE-4D78-BC95-34EBA8DF160B@oracle.com>
References: <F11DB63C-7052-4813-B781-B3396E944E4F@gmail.com> <CAKKJt-dVn420A-eyOmHV2M5duORR0BvpNzrBrpN35jPvKDYhRw@mail.gmail.com>
To: Christopher Wood <christopherwood07@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9119 signatures=668680
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812270165
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/_3Psd3uDg2kh-UgJF65yejxpSCQ>
Subject: Re: [secdir] secdir review of draft-ietf-nfsv4-mv0-trunking-update-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Dec 2018 18:52:43 -0000


> On Dec 20, 2018, at 11:14 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>; wrote:
> 
> Hi, Authors,
> 
> On Tue, Dec 11, 2018 at 8:16 AM Christopher Wood <christopherwood07@gmail.com>; 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