Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-mv0-trunking-update-03: (with DISCUSS and COMMENT)

Chuck Lever <chuck.lever@oracle.com> Mon, 28 January 2019 15:52 UTC

Return-Path: <chuck.lever@oracle.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8152C130E72; Mon, 28 Jan 2019 07:52:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.853
X-Spam-Level:
X-Spam-Status: No, score=-8.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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 I4cka0lbbKQv; Mon, 28 Jan 2019 07:52:09 -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 83116130E65; Mon, 28 Jan 2019 07:52:09 -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 x0SFdGpS050965; Mon, 28 Jan 2019 15:52:04 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=Uhw2CQvvjDVAO12r9edK/w9JZMdGYSfKZb2RP0Ca1FY=; b=0nUhRlyloV9e5YxpHdF5HsKpBXRICc2Cit7PMAu7zMKMeVPAv1tYmh8EcN5yhcpCB3JI VVDeIK+etdOv/nkd3dtqj/cQghz0qL7NFs0m7dRd3+rHocVCE9Tu2sWhMjs73HdrK66Y DsvZs5WMdQUrHlxjevr/M9zzXJO+ymQGdDrZqME95forEHyi/9z2MgDfnFwGFZ4bxT52 7cMJG/rw6DQ3H2KhbOxIqAB0AGU8h6OuHPfBX7qWlsLzi0YKwUkNy7XbieByJGL+I91Z F9n4UD5mAFziris66hOOo3KZownmsHVkxg56I9/kKD/+c5WafleHRhl/U7B8ERtT9bFx DQ==
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2130.oracle.com with ESMTP id 2q8eyu6xt5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 28 Jan 2019 15:52:03 +0000
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x0SFpwp6015279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 28 Jan 2019 15:51:58 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x0SFpvQ0008589; Mon, 28 Jan 2019 15:51:57 GMT
Received: from anon-dhcp-171.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Jan 2019 07:51:57 -0800
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <20190126205820.GH49072@kduck.mit.edu>
Date: Mon, 28 Jan 2019 10:51:55 -0500
Cc: draft-ietf-nfsv4-mv0-trunking-update@ietf.org, nfsv4-chairs@ietf.org, The IESG <iesg@ietf.org>, NFSv4 <nfsv4@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <873D6460-1454-4CD0-9B10-6B0233E608BE@oracle.com>
References: <154706146206.5038.389871557428840458.idtracker@ietfa.amsl.com> <CADaq8je-npyZmw3HcU=its5BcpOD-fhBqyZUmDETmFWhV_PxPw@mail.gmail.com> <CADaq8jdo7BQuupv_ytX3LTpBST3VJxJb4SuBW1sxnFdHHc308Q@mail.gmail.com> <20190126205820.GH49072@kduck.mit.edu>
To: Benjamin Kaduk <kaduk@mit.edu>, David Noveck <davenoveck@gmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9150 signatures=668682
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-1901280120
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/dzuoADJ3aYUBzKpnKflPRys57NM>
Subject: Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-mv0-trunking-update-03: (with DISCUSS and COMMENT)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Jan 2019 15:52:11 -0000


> On Jan 26, 2019, at 3:58 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> On Thu, Jan 24, 2019 at 04:22:28PM -0500, David Noveck wrote:
>> Following are the responses to your non-DISCUSS comments.
>> 
>>> Section 1
>>> 
>>>  As part of addressing this need, [RFC7931] introduces trunking into
>>>  NFS version 4.0 along with a trunking detection mechanism.  This
>>>  enables a client to determine whether two distinct network addresses
>>>  are connected to the same NFS version 4.0 server instance.
>>>  Nevertheless, the use of the concept of server-trunkability is the
>>>  same in both protocol versions.
>> 
>>> Er, what are the two protocol versions in question?  (I assume 4.0 and
>> 4.1,
>>> but you don't say 4.1 anywhere.)
>> 
>> 
>> 
>> This was addressed by the introductory paragraphs about locking prompted by
>> your DISCUSS.
>> 
>> The paragraphs were:
>> 
>> 
>> 
>> As part of addressing this need, [RFC7931] introduces trunking into NFS
>> version 4.0 along with a trunking detection mechanism.  A trunking
>> detection mechanism enables a client to determine whether two distinct
>> network addresses are connected to the same NFS version 4.0 server
>> instance.  This knowledge is necessary since, without it, a client unaware
>> of a trunking relationship between paths it is using simultaneous is likely
>> to become confused in ways described in [RF7530].
>> 
>> 
>> 
>> NFSv4.1 was defined with an integral means of trunking detection described
>> in [RFC5661], while NFSv4.0 initially did not have one, with it being added
>> by [RFC7931].  Nevertheless, the use of the concept of server-trunkability
>> is the same in both protocol versions
>> 
>>>  o  To provide NFS version 4.0 with a means of trunking discovery,
>>>     compatible with the means of trunking detection introduced by
>>>     [RFC7931].
>>> 
>>> We haven't yet mentioned that the distinction between "detection" and
>>> "discovery" is important, so it's probably worth a forward reference to the
>>> text below.
>> 
>> 
>> 
>> I think we can revise this bullet to read as follows in -04:
>> 
>> 
>> 
>>   - To provide NFS version 4.0 with a means of finding addresses trunkable
>>   with a given address. i.e., trunking discovery, compatible with the means
>>   of trunking detection introduced by [RFC7931].  For an explanation of
>>   trunking detection and trunking discovery see Section 3.
> 
> Thanks.

[ ... remaining comments snipped ... ]

If there are no more comments to resolve, I will assemble and submit -04 this
week based on these e-mail threads.


--
Chuck Lever