[nfsv4] [Technical Errata Reported] RFC7931 (4822)
RFC Errata System <rfc-editor@rfc-editor.org> Thu, 06 October 2016 18: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 6DB16129759 for <nfsv4@ietfa.amsl.com>; Thu, 6 Oct 2016 11:34:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.598
X-Spam-Level:
X-Spam-Status: No, score=-105.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 li6ht6IqdAhK for <nfsv4@ietfa.amsl.com>; Thu, 6 Oct 2016 11:34:56 -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 5156112943D for <nfsv4@ietf.org>; Thu, 6 Oct 2016 11:34:56 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 474D4B80ADD; Thu, 6 Oct 2016 11:34:56 -0700 (PDT)
To: davenoveck@gmail.com, piyush.shivam@oracle.com, chuck.lever@oracle.com, bill.baker@oracle.com, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, spencer.shepler@gmail.com, beepee@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20161006183456.474D4B80ADD@rfc-editor.org>
Date: Thu, 06 Oct 2016 11:34:56 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/hZY6xAzize3XPvZOLwsEdyluhAA>
X-Mailman-Approved-At: Thu, 06 Oct 2016 11:44:12 -0700
Cc: rfc-editor@rfc-editor.org, nfsv4@ietf.org
Subject: [nfsv4] [Technical Errata Reported] RFC7931 (4822)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 06 Oct 2016 18:34:57 -0000
The following errata report has been submitted for RFC7931, "NFSv4.0 Migration: Specification Update". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7931&eid=4822 -------------------------------------- Type: Technical Reported by: David Noveck <davenoveck@gmail.com> Section: 5.8 Original Text ------------- Note that the NFSv4.0 specification requires the server to make sure that such verifiers are very unlikely to be regenerated. Given that it is already highly unlikely that the clientid4 XC is duplicated by distinct servers, the probability that SCn is duplicated as well has to be considered vanishingly small. Note also that the callback update procedure can be repeated multiple times to reduce the probability of further spurious matches. Corrected Text -------------- Although the NFSv4.0 specification requires the server to make sure that such verifiers are very unlikely to be regenerated, different servers may use the same approach to the construction of such verifiers, raising the probability that two distinct servers might inadvertently assign the same verifier value. The fact that the servers in question have assigned the same clientid4 may raise this probability. In order to guard against the possibility that such assignments might cause two distinct servers to be incorrectly considered the same, the SETCLIENTID procedure mentioned above needs to be repeated. Repeating the procedure once is sufficient to ensure that the successive confirm values SCn, SCn' generated by these repeated SETCLIENTID operations cannot all collide with a verifier previously received by the client when communicating with IPn. Notes ----- It appears that the original text underestimated the probability inadvertant of duplication of clientid4's and verifiers. Existing servers while conforming to to RFC7530, may generate the same sequence of clientid4's when they all happen to be rebooted at the same time. The new text deals with this possibility and ensures that two different servers cannot be considered the same. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7931 (draft-ietf-nfsv4-rfc3530-migration-update-08) -------------------------------------- Title : NFSv4.0 Migration: Specification Update Publication Date : July 2016 Author(s) : D. Noveck, Ed., P. Shivam, C. Lever, B. Baker Category : PROPOSED STANDARD Source : Network File System Version 4 Area : Transport Stream : IETF Verifying Party : IESG
- [nfsv4] [Technical Errata Reported] RFC7931 (4822) RFC Errata System