Re: [nfsv4] Benjamin Kaduk's No Objection on draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: (with COMMENT)

Chuck Lever <chuck.lever@oracle.com> Wed, 26 February 2020 16:33 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 1A8563A0AEF; Wed, 26 Feb 2020 08:33:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-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 edjwQ2PWm2Pc; Wed, 26 Feb 2020 08:33:30 -0800 (PST)
Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 026963A0AF0; Wed, 26 Feb 2020 08:33:26 -0800 (PST)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 01QGNlVs060293; Wed, 26 Feb 2020 16:33:25 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-2020-01-29; bh=VsQh4Gg9mdG+GEIy3LERhmE4w/rT0p73RsYY+5TWl3M=; b=U3M8OxCVug+3yUK6ybxz+xpH4qkT+NYBpP6X48HKWBKhWInHEl2OEsVrWEsL5OZdI0mx Cqivrp8WFLGeVYRnlR5MC+z3Y+dGqweYuPgmI5P0XcTpjTbj98XR7f8BJrBcWqM9dt73 rbp3gjGXWQk7+cRfUn7i+sfw323/o3O4WVhgGuEcm7jO5NjkUzfhJ3o/Wwrszim7/i69 vtAFGQSkmkWOCsEcClkxhRJMNxqGw3u8NfrVOUrefsODNlGAUX1oQ/iLD++cgk9kIOGQ DyuvnW9KqthnnlcKGtxB2fxPw6hIFdG8oAyjvU4Tzm1UhGSjlAPvAEvrr3m/rBzDKATc SA==
Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 2ydcsrmuhg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 26 Feb 2020 16:33:25 +0000
Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 01QGM59n022304; Wed, 26 Feb 2020 16:33:24 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3020.oracle.com with ESMTP id 2ydj4hwkhs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 26 Feb 2020 16:33:24 +0000
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 01QGXMf2014037; Wed, 26 Feb 2020 16:33:22 GMT
Received: from [172.20.161.131] (/4.28.11.157) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 Feb 2020 08:33:22 -0800
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <20200220195155.GJ97652@kduck.mit.edu>
Date: Wed, 26 Feb 2020 08:33:21 -0800
Cc: nfsv4-chairs@ietf.org, nfsv4@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-nfsv4-rpcrdma-cm-pvt-data@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <0DB10D2E-CA76-49EA-8B7F-53F502114684@oracle.com>
References: <158216101788.17661.6926758160404035704.idtracker@ietfa.amsl.com> <E718C1B8-B96B-4A64-8B92-C4ABEC7B5E5F@oracle.com> <20200220195155.GJ97652@kduck.mit.edu>
To: Benjamin Kaduk <kaduk@MIT.EDU>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9543 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 suspectscore=0 spamscore=0 adultscore=0 malwarescore=0 mlxlogscore=999 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002260112
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9543 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 adultscore=0 suspectscore=0 bulkscore=0 malwarescore=0 spamscore=0 impostorscore=0 clxscore=1015 lowpriorityscore=0 mlxlogscore=999 phishscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002260112
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/JKkdfH5jPY2Hd3HkS3wH-58_zmU>
Subject: Re: [nfsv4] Benjamin Kaduk's No Objection on draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: (with 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: Wed, 26 Feb 2020 16:33:31 -0000

Hi Ben-

> On Feb 20, 2020, at 11:51 AM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
> 
> Hi Chuck,
> 
> On Thu, Feb 20, 2020 at 10:13:26AM -0500, Chuck Lever wrote:
>> 
>> 
>>> Section 4
>>> 
>>>  For RPC-over-RDMA version 1, the CM Private Data field is formatted
>>>  as described in the following subsection.  RPC clients and servers
>>>  use the same format.  If the capacity of the Private Data field is
>>>  too small to contain this message format, the underlying RDMA
>>>  transport is not managed by a Connection Manager, or the underlying
>>>  RDMA transport uses Private Data for its own purposes, the CM Private
>>>  Data field cannot be used on behalf of RPC-over-RDMA version 1.
>>> 
>>> How will an implementation know if "the underlying RDMA transport uses
>>> Private Data for its own purposes"?
>> 
>> That's what the Format Identifier is for. It indicates where the
>> RPC/RDMA-specific data sits in the CM Private Data buffer. A
>> compliant RPC/RDMA implementation does not assume it is the only
>> user of the CM Private Data.
> 
> Sure ... but now we have some text saying that other uses of CM Private
> Data can't coexist with RPC-over-RDMA v1 ("the underlying RDMA transport
> uses Private Data for its own purposes [...] cannot be used on behalf of
> RPC-over-RDMA version 1") that seems in conflict with the goal of using the
> Format Identifier "magic word" to identify the RPC-over-RDMA private data
> within a larger assembly.  So we should probably try to resolve the
> apparent inconsistency.

I want to make sure you are happy with how I addressed this comment.
The third paragraph of Section 4 in -08 now reads:

   For RPC-over-RDMA version 1, the CM Private Data field is formatted
   as described in the following subsection.  RPC clients and servers
   use the same format.  If the capacity of the Private Data field is
   too small to contain this message format or the underlying RDMA
   transport is not managed by a Connection Manager, the CM Private Data
   field cannot be used on behalf of RPC-over-RDMA version 1.

I've removed the conflicting item from the last sentence.

Please confirm this is a satisfactory solution.


--
Chuck Lever