[nfsv4] [Errata Held for Document Update] RFC5661 (4119)
RFC Errata System <rfc-editor@rfc-editor.org> Fri, 25 October 2019 08:34 UTC
Return-Path: <wwwrun@rfc-editor.org>
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 7B83612012D; Fri, 25 Oct 2019 01:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 NmATeCad4P90; Fri, 25 Oct 2019 01:34:40 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E81E12001E; Fri, 25 Oct 2019 01:34:40 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 217E6F4071F; Fri, 25 Oct 2019 01:34:40 -0700 (PDT)
To: hch@lst.de, shepler@storspeed.com, mike@eisler.com, dnoveck@netapp.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: magnus.westerlund@ericsson.com, iesg@ietf.org, nfsv4@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20191025083440.217E6F4071F@rfc-editor.org>
Date: Fri, 25 Oct 2019 01:34:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/G8n6GkOpCRHf9OGNUg6w0nAY3xM>
Subject: [nfsv4] [Errata Held for Document Update] RFC5661 (4119)
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: Fri, 25 Oct 2019 08:34:41 -0000
The following errata report has been held for document update for RFC5661, "Network File System (NFS) Version 4 Minor Version 1 Protocol". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid4119 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Christoph Hellwig <hch@lst.de> Date Reported: 2014-09-17 Held by: Magnus Westerlund (IESG) Section: 12.2.10 Original Text ------------- A device ID lives as long as there is a layout referring to the device ID. If there are no layouts referring to the device ID, the server is free to delete the device ID any time. Corrected Text -------------- A device ID is established by referencing it in the result of a GETDEVICELIST or LAYOUTGET operation and can be deleted by the server as soon as there are no layouts referring to the device ID. If the client requested notifications for device ID mappings, the server SHOULD send CB_NOTIFY_DEVICEID notifications for device ID deletions or changes to the device-ID-to-device-address mappings to any client which has used the device-ID in question at least once, irrespective of whether the client has any layouts currently referring to it. If the server does not support or the client does not request notifications for device ID mappings, the client SHOULD periodically retired unused device IDs. Given that GETDEVICELIST does not support requesting notifications a server that implements GETDEVICELIST MUST not not advertise support for NOTIFY_DEVICEID4_CHANGE notification in GETDEVICEINFO, and client using GETDEVICELIST must not rely on NOTIFY_DEVICEID4_CHANGE or NOTIFY_DEVICEID4_DELETE notifications to work reliably. Notes ----- The lifetime rules in RFC5661 are contradictory - both GETDEVICELIST and CB_NOTIFY_DEVICEID (NOTIFY4_DEVICEID_DELETE) operations imply that device IDs are valid even without layouts referring to them. Implementations rely on this fact by caching not referenced device IDs to avoid the huge setup costs, and thus require notifications to be sent for that case. -------------------------------------- RFC5661 (draft-ietf-nfsv4-minorversion1-29) -------------------------------------- Title : Network File System (NFS) Version 4 Minor Version 1 Protocol Publication Date : January 2010 Author(s) : S. Shepler, Ed., M. Eisler, Ed., D. Noveck, Ed. Category : PROPOSED STANDARD Source : Network File System Version 4 Area : Transport Stream : IETF Verifying Party : IESG
- [nfsv4] [Errata Held for Document Update] RFC5661… RFC Errata System