Re: [nfsv4] Mirja Kühlewind's No Objection on draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: (with COMMENT)

Chuck Lever <chuck.lever@oracle.com> Wed, 19 February 2020 20:46 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 B5A4C120810; Wed, 19 Feb 2020 12:46:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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, 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 bVNRutsQuxrC; Wed, 19 Feb 2020 12:46:19 -0800 (PST)
Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 A378312082D; Wed, 19 Feb 2020 12:46:19 -0800 (PST)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 01JKfP2w001486; Wed, 19 Feb 2020 20:46:18 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=3wXLmuMzO8U7s9bTZGpL6/qUGGG5NnhzNwqh7P8IEas=; b=Vz6ZTZkqSJsDUuMuLux5ZgtkqNX6YTrqVZXI/da18b7Dyi3gnZECaKd0ulMToImpuL54 8P9THkMh5vTUK4GRMuwq4tWmN4jYj1R8OcuCcrJE1Xp+YB4hETvDIqu4ujysP4ACTeUx j/fiun7/OHOLPGCZYcYd+x26KVRpTh3v2c44K6dK2VKoEglo5+0g7nLTwaKnppKerkcY gBJi3hwbsw5owynPXYyrWxS2qe+nmBQXI4vq8OdcuoXTh8bFHM1Y2NHknfKiX3J2w0F7 yriTzKbtC0t87aL6cClTtZpkkJ17CH0hdsV9ssj6EjlaJ0y3WLauocL2yMrt8utC7f4a ig==
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 2y8ud15qdn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 19 Feb 2020 20:46:17 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 01JKW0uV086844; Wed, 19 Feb 2020 20:46:17 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3020.oracle.com with ESMTP id 2y8ud7kmjg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 19 Feb 2020 20:46:17 +0000
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 01JKkEB8012045; Wed, 19 Feb 2020 20:46:15 GMT
Received: from anon-dhcp-153.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Feb 2020 12:46:14 -0800
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <158212228910.17604.1494714603838535207.idtracker@ietfa.amsl.com>
Date: Wed, 19 Feb 2020 15:46:13 -0500
Cc: The IESG <iesg@ietf.org>, nfsv4-chairs@ietf.org, nfsv4@ietf.org, draft-ietf-nfsv4-rpcrdma-cm-pvt-data@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <DB67100B-064B-4D5F-B69A-86D38D2CD52A@oracle.com>
References: <158212228910.17604.1494714603838535207.idtracker@ietfa.amsl.com>
To: =?utf-8?Q?Mirja_K=C3=BChlewind?= <ietf@kuehlewind.net>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9536 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=715 phishscore=0 suspectscore=0 mlxscore=0 malwarescore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002190154
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9536 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 malwarescore=0 suspectscore=0 bulkscore=0 spamscore=0 priorityscore=1501 phishscore=0 impostorscore=0 mlxlogscore=766 clxscore=1011 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002190154
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/mpFCQrydbVr_gGKssz4-qd0kgyY>
Subject: Re: [nfsv4] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-nfsv4-rpcrdma-cm-pvt-data-07=3A_=28with_COMMENT=29?=
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, 19 Feb 2020 20:46:22 -0000

Hello Mirja-

> On Feb 19, 2020, at 9:24 AM, Mirja Kühlewind via Datatracker <noreply@ietf.org> wrote:
> 
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcrdma-cm-pvt-data/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> One quick thought/comment: Another option for extensibility would be to use one
> of the reserved flags to e.g. extend the fields of the private data field.
> However, the draft states at all reserved flags need to be zero with version 1.
> This seems to be a bit of a waste of space but moreover it's a lost opportunity
> for an easy way to extend the private data field. Why was that decided?

The common way to extend this kind of data structures, I assumed,
was to use the version field. The set of defined flag fields cannot
change without a bump in the version number.

I would be interested to consider another way to handle extension,
though at this point there is already an implementation of this
protocol, which limits our ability to adjust the structure format
too much.

Thanks for your comment!


--
Chuck Lever