Re: [nfsv4] Remaining errata reports for rfc5661bis

Chuck Lever III <chuck.lever@oracle.com> Fri, 30 September 2022 17:39 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 070EEC1522D1 for <nfsv4@ietfa.amsl.com>; Fri, 30 Sep 2022 10:39:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com header.b=jBCCtscM; dkim=pass (1024-bit key) header.d=oracle.onmicrosoft.com header.b=cbDWuJVA
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFO5RM1lBLUD for <nfsv4@ietfa.amsl.com>; Fri, 30 Sep 2022 10:38:58 -0700 (PDT)
Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) (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 0EFACC14CE47 for <nfsv4@ietf.org>; Fri, 30 Sep 2022 10:38:57 -0700 (PDT)
Received: from pps.filterd (m0246629.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 28UGxCJV018670 for <nfsv4@ietf.org>; Fri, 30 Sep 2022 17:38:57 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=corp-2022-7-12; bh=uWlY69Qx9QNgSmPRgsIAeMKQk1kvQjtTSFtjgw5PhkI=; b=jBCCtscMx1p1sKWNs5lDoOpCjzESghgvcyR/ehQig0CNOiFJ3InzNqZAefyOENesJXBP UCM5wxlXfr3dRM6oZGmUh7O3GQdVcwYmG84RZ90u0kaxkaRbidtUE9hFmXZllhUs06zd Lh/ISSqPL+Lnrun6HnZYwj7S5hAovAtxOf4fE+asCPuCDjYzgi7FURjUW+x2jd/UCliL NsQ/welWRwDBxLPpBaxwRXJp6Jd1n2fIOeOE0+5ZFRXY1YoQo9OG7ZErfSbeLMKk24D5 u4YFygrRwCuKjRRFRrALDEMq/wkinu8ai1mXA2vSd5mO4/m3ALPG0LdSovnGVf0myX9y vw==
Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta02.appoci.oracle.com [147.154.114.232]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3jst0m0375-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <nfsv4@ietf.org>; Fri, 30 Sep 2022 17:38:55 +0000
Received: from pps.filterd (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (8.17.1.5/8.17.1.5) with ESMTP id 28UFvpjR034005 for <nfsv4@ietf.org>; Fri, 30 Sep 2022 17:38:54 GMT
Received: from nam02-dm3-obe.outbound.protection.outlook.com (mail-dm3nam02lp2042.outbound.protection.outlook.com [104.47.56.42]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 3jtpqbt2hj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <nfsv4@ietf.org>; Fri, 30 Sep 2022 17:38:54 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FYRnAqc3zxAV5m8YcBObMsKYbPtRsDiLwCc2vB+U8d0qs4JcF+h9JBqj3bIFNHs1KmB9vn+3aMCnTp4t0TEYbBbT/EUvAelT2USo9s90i9t8I01T+qTTTbJ7Wm1IHLgYSc6Oho+pcoltGRmWtg29xAx5nD230ZoYY4CnbpSN+gQ+8khtXKenlv8OQhdwTkZ7/YjmxSm4rnyBcb6RbINq6jffmiQSYurL7Zlu4GxgzjcXq9UiRYxZkkHE9sYII2LuA+NCI3zfbK97V7E1PND8oyc5MFNZeSaogyPJJ0wi7DJiF7kvDg8ibYxwHY6Y86MJMP+eyLdIRDN+vVIYxTvNww==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uWlY69Qx9QNgSmPRgsIAeMKQk1kvQjtTSFtjgw5PhkI=; b=R1YL9HBus/uUqRO1+qXzKvoLiEHf7UaO0i06AifrBs7yT4ZK0hzOAwHUGONYtVAkFPngNi4DeX90NySJkVpZ5vaRLVZLrASJ6D+HGPdRj4DzE08hzZBTB0Y4f5XDQg2K8F1Lfohk13SdiGoAhZ+KxV+jk+ZzA7X+/awoNRB1F+UF1v9NiNtVLrxuu3O67QqmrJSvq38rpZiCVBfSFB7QPOgk6EEXj5qwpQENOgzbnIy1vQdhUxOpjKifhZ/t3DddoVanKY6FAm9FkQh/6efdeHobSrmSvVPT3Wh7dU+9bVgiC8PWl60UPINyCFKJZ0008vawrTzL6zeHIT1laChe2Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uWlY69Qx9QNgSmPRgsIAeMKQk1kvQjtTSFtjgw5PhkI=; b=cbDWuJVAdoBcGNbakCKITA2HuXJrSIFVQUM9BSzp75nvBwY7lvWY7nmlFeYU+pi6JQhky2FQGZifboaZWJqbzecqVAxOE4hDH6sAWg11h+ABon4h+sNDNES3TcfPzuj/ibgGXFeWf25uEDRtpm/Z0viOzqxnUQuOKk2IP77oc+Q=
Received: from BN0PR10MB5128.namprd10.prod.outlook.com (2603:10b6:408:117::24) by CO6PR10MB5555.namprd10.prod.outlook.com (2603:10b6:303:142::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.23; Fri, 30 Sep 2022 17:38:52 +0000
Received: from BN0PR10MB5128.namprd10.prod.outlook.com ([fe80::5403:3164:f6c3:d48a]) by BN0PR10MB5128.namprd10.prod.outlook.com ([fe80::5403:3164:f6c3:d48a%3]) with mapi id 15.20.5676.020; Fri, 30 Sep 2022 17:38:52 +0000
From: Chuck Lever III <chuck.lever@oracle.com>
To: NFSv4 <nfsv4@ietf.org>
Thread-Topic: [nfsv4] Remaining errata reports for rfc5661bis
Thread-Index: AQHY1NCv8fv8EMTqMEiucBJjW7ANM634EPsAgAAU6wCAABd4AA==
Date: Fri, 30 Sep 2022 17:38:51 +0000
Message-ID: <2568D044-8900-4F14-AFC3-BCF4A4CADC18@oracle.com>
References: <CADaq8je+0rLEL3iG_yvB1rDCsScSb4P6bEX8usxC6kiGsLMZzA@mail.gmail.com> <675FA95B-0653-4504-A4E5-ED04A48FE090@oracle.com> <CADaq8jezkjk=SxGw0ah03cvF5SnyoFqGrtex589gXtn2CXeZ=g@mail.gmail.com>
In-Reply-To: <CADaq8jezkjk=SxGw0ah03cvF5SnyoFqGrtex589gXtn2CXeZ=g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3696.120.41.1.1)
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BN0PR10MB5128:EE_|CO6PR10MB5555:EE_
x-ms-office365-filtering-correlation-id: 4159ad5d-3edd-46f6-1aec-08daa30aa3d3
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Rury0PoHS/8k3LSL9ZRy9qpGOjqMf0JNsQQWzJ/6yNV6RS1WTzhNKOiNFbAjEU1dtyILTWdp5ErGjHM5N0m/8Iy0V+iU2i4AFp70qcn38JrF0mHt37uDRayJvcEXpl3tKngxPluYzsgC/HOV4QCBU2vv26gIvjzgo2YbtTpYYti+9l+8sBCk8ESjfqojagUG1zzNVhu+LUxybg9h7XKA6z4WUU5wKHlxo2yD9jDZk96QjFf4PZJA2oHwQU1ow62K7tAQy7uqd7mvhtvuU+AlnLaHhMTqS/P/+PpDstbCxPpl23MpzvOCFPmfUaHYRhpCE8ZIrLDe4c6YrMSP5RmFV5s/AoxxlXRVXLN0HJPsBFQnGSOwP8kAgxWoLHtCx/+RUdyv093AeN6plxoaaFWxomfe7kl9qMzDByK+Z5hC8Gyy3cXXyll+Ao3KiRLmQTHluSDZCZ3YXWigmJSp6w5yBtZPhNwUsktUN8rZeoakjdPQZT/3DnCgYSLij7xQvSRfoJLo7upGJi3MS8+5xTScyq9nVsSk/7fWGWgBlu6akbhwQ7Alz3Ki245aC7knInRUzpm4AOmnPTxXqDXnnTfd3+ocHrFfFUVZ4K1R/MM645jfu+xuuRJW9a7G6utiqWmxj5p7MWmGUIpU4ROreL5hbRh0/7+bOtqdwVAinRGG9cy8BHp9MouMjUHGAgUP6pFGh7bByuywXtWMej060yL0gLB6853FLadPYZGIXSe+Y3kEmhpAwZlwRFjj0gsbzAXGIOfbHjjBhfrM1z0zvQ4i5AA1AjywtNG/PFUkwH/1RMY=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN0PR10MB5128.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(346002)(136003)(396003)(366004)(39860400002)(376002)(451199015)(5660300002)(186003)(26005)(6512007)(122000001)(36756003)(38100700002)(8676002)(91956017)(76116006)(66446008)(2616005)(83380400001)(316002)(64756008)(6506007)(66556008)(41300700001)(33656002)(53546011)(66476007)(66946007)(6916009)(71200400001)(38070700005)(2906002)(6486002)(478600001)(86362001)(8936002)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: eF0HMMRvBbRp3LOr8z/R3MpGW3fc+KIRRHAm5YCMrl2czqd2GN8KGUBsiNSO97h06AhMDBEpTR6agooFNWysadt0X9wJ3+Wl+XWqCJE8V1IPIrRQzNaQwV4gB0XjOtX3/mzJVkdx0e8XLmoVPOIv9PHtrxByNRdcyljMHlKQcv6Pd8Fwi2Ik7HbSSTUaX9EzAcTNapB26ugFd9vnULweHg4wyfILQa6gtNfe1ScI4tpGsvmFV2Spibr134iwyDyAuxrFlkg2uiQjOolOxR7qQM1dS/UPTaE1QUW6FcBVJAnXZo1QF6EnWQCVHSZW37IuHJ0P8UQckYqc+TuUI34XQYitFAHHzNvpMymer4NZPjkrvCrDsOb46rbzJq7SBVdieF4417kuJ9BvuCbxMPagkZ8regVpnJvYvttM3T2b16qHo4J3JYNHuvY2cuHCocsSj7fVCLyYd4jWjevdY5VYyEKsvJbqkW1+I7Cd+v8Rr1wb1bEVuW+b7uuYJXbDRJ06XxpPaFKEmr7PXlqt6OR0eRpwBFHRCm6ScOPSm22J3x15sod4ZAtfSOiS8T53yl1WRR3D1HCWdHYMXPvl68uI91eTBvD7GOBxz+7FfFF7jft/uzQA1U6+b5/7j1LO8mer6ud1h07/b6TSWn3m8xmjuOxCPiMj8/pzD9Sbl7+h8BUTtGl9qzqQhCg4f4KyRV3yU2Tpqk1Yvlzg+xjvlLQVfKP4Q1yYsDzx00wCXLDYxWENk6tShDUhhebRg8Z4x98lBIufNIaV857musrgn6SFJMLlBdh7s+uQvBIpd+CHkaooQh33P2OeS+UD0/P6uVOKcump989uwZMYIf7JROx2d8sPKFnzPnCMApzGM+TFXTlY+JIg1z9juM/m6mlTj84EQS6J/NVPITR0v/+BBL6k/wPKxk5ck+3RI7m6ZKh1RrmYlSsPK4RZ9KyIAsBsbB30xbFhJY27oI2DJSIDDezgQrlTksPm5psQL1C4rymqbwe5IeWc3607CGy2kamAelxvWGeOaU7MUIA0k4QkLhohp/0MQ/XBG/i3TLLCo7WmekCq48BdpIT8MuuylHU/RTUbMvkIAHSY0DSkUp9EeDMx3Vb0bUOshER8Hb5pC9vD174cLhqqO49myR3xNrAlUhi4GAWbMdSji6ptCVSVjHC58Rio1Pi6xjV4kcZBYVbyFOtq9MHvkCVYRc8FYHOo/d18U7wytQX+SmTwhCdOZGGwtjGXswEOYpmPbKa1UtKlCGxk1fm7CuMCZNBD/TwvX9QWn82evIB6nw9rEoSZUOme8CqLBWU7mMpXeGCBOrzHsELiAY1ca3cc7y/8G9NNaKBImIhND3I3Bforuxny84HV1aTH23rctE4MfS/fONyztrh4Lvk6n03S1HSi7ndTpiBRVswqTn+PmulmiO6RDowB/s/7LcIAYDLr4F8tQhUDIQa/b+tXuhwI6CFciIcKoQ31uDVsR/gmURE/21EB/8rhR11vijdPxzyz3labdaGo0gD7tGS6VPXsFiKnn14QA2pHBYzfd8gS79sAD8GZ6FocsEUtCHfGBxl1jT+hfl4Ln2Bekbp5RNWNBiQ7SHiwzaIt8ulkRGYsJUtlDBAxUY6HpA==
Content-Type: multipart/alternative; boundary="_000_2568D04489004F14AFC3BCF4A4CADC18oraclecom_"
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0PR10MB5128.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4159ad5d-3edd-46f6-1aec-08daa30aa3d3
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2022 17:38:51.9399 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: LpkjFhbJbHw11CPVcW+LPx67WrqmTOW3OQ3tyLIoWp+lKaBg7aV1W1MNA9jKlFoKP/DUGjxeIvCGZcPGXMVfMQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR10MB5555
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1 definitions=2022-09-30_04,2022-09-29_03,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 bulkscore=0 mlxscore=0 suspectscore=0 malwarescore=0 adultscore=0 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2209300110
X-Proofpoint-GUID: weyVQI8Oh_J1HBmbwuuedFa5TPqhrcJ3
X-Proofpoint-ORIG-GUID: weyVQI8Oh_J1HBmbwuuedFa5TPqhrcJ3
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/hac3WsCuBKb1997G_ciz7_hmDSs>
Subject: Re: [nfsv4] Remaining errata reports for rfc5661bis
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 30 Sep 2022 17:39:01 -0000


On Sep 30, 2022, at 12:14 PM, David Noveck <davenoveck@gmail.com<mailto:davenoveck@gmail.com>> wrote:



On Fri, Sep 30, 2022 at 11:00 AM Chuck Lever III <chuck.lever@oracle.com<mailto:chuck.lever@oracle.com>> wrote:


On Sep 30, 2022, at 9:27 AM, David Noveck <davenoveck@gmail.com<mailto:davenoveck@gmail.com>> wrote:

The following are not, for various reasons, listed as addressed in draft-dnoveck-nfsv4-rfc5661bis-05.   I'd like to start wg discussion of these so that we can address as many as possible in draft-ietf-nfsv4-rfc5661bis-00.

  *   2722

This was actually addressed in rfc8881 😊.  See Err930 (attached) for an updated list

  *   2751

I'm kind of uncertain about the proposed new section 12.5.4.1.   Given its size, it needs some working group discussion before being put in an RFC.

I agree, further WG discussion is warranted.


  *   3067

I'm OK with the substance of this but:

     *   I'm unclear what "deprecated" means in a Proposed Standard.

I propose simply removing the sentence containing "deprecated".

I'd prefer simply saying these fields are no longer used.   I intend to also indicate this via comments in rfc5662bis.



     *   Regarding use of "SHOULD", unclear what might be valid rasons to ignore the recommendation.  Also, am dubious about the capacity of non-zero values to cause harm given thathe server is ignoring them.

I propose removing that sentence as well.

OK.



     *   Worried about the use of lower-case "should" in he last two sentences.

I propose replacing "should" with "MUST" in both sentences.

Although I'd prefer "is to",   I can live with "MUST".

The big problem with these two sentences is that the condition in the first is a subset of the condition an you can wind up with situations in which it would say you "MUST" return two different errors, which is self contradictory 😞

Propose the following but am open to replacing "is to" by "MUST":

For the case where the client does not hold any previously granted layout,
the server is to return the error NFS4ERR_BAD_LAYOUT. Otherwise, where no previously
granted layout has an iomode of LAYOUTIOMODE4_RW, the server is to return the error NFS4ERR_BAD_IOMODE.

That seems to eliminate the contradiction.

Re: "is to" v. "MUST": Using the phrase "is to" means clients cannot rely on servers to recognize and return these errors. I've always preferred the use of MUST in these cases -- I've known too many implementers who look at the current text and decide the guidance is inconvenient and therefore does not apply to them, and that makes the text pretty meaningless.



  *   4118

I'm OK with the substance of this but:

     *   Think the "SHOULD" in the third sentence is not appropriate.  Think "is to be ignored" is better.

I propose replacing "SHOULD" with "MUST".

I think it is better to say this field has no function.   As far as use of "MUST", how could the server depend on this being ignored.

We are making a protocol compliance statement. MUST is a legitimate and conventional way of identifying an unused protocol element. As an example, here is language from RFC 8797 about unused bit fields:


      Reserved:  This 7-bit field is unused.  Senders MUST set these bits
      to zero, and receivers MUST ignore their value.

That document's IESG reviewers requested this formulation specifically.


     *   For the fourth sentence suggest "The client can validly finish any outstanding I/Os that reference the previously   provided device-ID-to-device-address mapping and would have to use GETDEVICEINFO to obtain the updated mapping for the previously provided device-ID-to-device-address mapping before requesting new layouts" as a replacement.

I prefer the fourth sentence proposed in the errata. Can you say what your proposed replacement fixes?

First of all, it avoids use of lower-case "may" which is always confusing.

But it adds "would have to use" which is awkward. A subjunctive is not appropriate here, and makes this text worse than it is with "may". And "validly finish" is also not terribly meaningful. Instead, how about:

The client is permitted to finish outstanding I/O that references the previously provided device-ID-to-device-address mapping. Before requesting new layouts, the client needs to replace the previously provided device-ID-to-device-address mapping using a GETDEVINFO operation.


Is the phrase "before requesting new layouts" a protocol requirement,

Not really.   The client is not obligated to request new layouts even though most clients will.

and thus should it be stated using a compliance keyword?

I don't think so.   RFC2119 says these terms should be used "sparingly" which would be hard if every protocol requirement needed such a keyword.  I  think we can specify how the protocol works without sounding like control freaks.

My question simply is: is the current language specifying a point of interoperation? "before requesting new layouts" implies there might be an ordering requirement here that the implementation on one or the other side might choose to depend on -- or that could result in data corruption if it is not heeded.

This text still seems somehow weak to me -- it doesn't seem to describe the hazards well enough (to me) but maybe I'm missing some important context.


  *   5982

This is tentatively addressed in -04 in a eevised description of CLOSE but want to have working group dicussion of the new text before we consider this done.  In any case, what is in rfc8881 us self-contradictory and needs to be changed.

I got my errata confused here.   There may be no errata report associated with this change.   Nevertheless, I urge people to look at the changes in REMOVE in -04/-05 to address issues with preserve-unlinked.

Do you have a method to send us diffs?


Because the replier "is permitted (but not always obligated) to return NFS4ERR_FALSE_RETRY", I read the suggestions in the original text as implementation guidance, and not as Mandatory-To-Implement.

I agree but to me, that does not dispose of the matter.   The real issue is when false retries can happen.   If v4.1 truly had exactly-once semantics, which other parts of the spec suggest it does, the false retries would result only from a badly implemented peer.    As of now, we have a "MUST" which clients ignore due to the control-C problem.   We need to address that issue for the bis.

That wasn't clear from the errata, but OK: maybe you indicated the wrong errata number.


Thus I am not troubled by the original text -- implementers are free to choose not to use checksumming or other techniques when direct data placement is employed.

Yes, but if not doing so can result in data corruption, implementations might need to do so.   If it can't implementation guidance would have to make this clear.  This almost certainly will not be addressed in -00.

--
Chuck Lever