Re: [nfsv4] Verified editorial Errata on 5561 and sesqui-msns

Tom Talpey <tom@talpey.com> Thu, 30 July 2020 14:36 UTC

Return-Path: <tom@talpey.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 4F18C3A1195 for <nfsv4@ietfa.amsl.com>; Thu, 30 Jul 2020 07:36:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 ClzHGlwtxwZZ for <nfsv4@ietfa.amsl.com>; Thu, 30 Jul 2020 07:36:52 -0700 (PDT)
Received: from p3plsmtpa07-06.prod.phx3.secureserver.net (p3plsmtpa07-06.prod.phx3.secureserver.net [173.201.192.235]) (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 A42A43A1192 for <nfsv4@ietf.org>; Thu, 30 Jul 2020 07:36:52 -0700 (PDT)
Received: from [192.168.0.79] ([24.218.182.144]) by :SMTPAUTH: with ESMTPSA id 19fvkWSNdYIxd19fwkP2Ji; Thu, 30 Jul 2020 07:36:52 -0700
X-CMAE-Analysis: v=2.3 cv=WfxylHpX c=1 sm=1 tr=0 a=ugQcCzLIhEHbLaAUV45L0A==:117 a=ugQcCzLIhEHbLaAUV45L0A==:17 a=IkcTkHD0fZMA:10 a=yPCof4ZbAAAA:8 a=0FD05c-RAAAA:8 a=48vgC7mUAAAA:8 a=BqEg4_3jAAAA:8 a=2JLUh5-gAAAA:8 a=syBfA4MV1_6qD10fjHMA:9 a=QEXdDO2ut3YA:10 a=l1rpMCqCXRGZwUSuRcM3:22 a=w1C3t2QeGrPiZgrLijVG:22 a=0mFWnFbQd5xWBqmg7tTt:22 a=hnrGVjIjb-X0WoHtSFqa:22
X-SECURESERVER-ACCT: tom@talpey.com
To: nfsv4@ietf.org
References: <HE1PR0702MB3772011E83C71FC05A28983F95700@HE1PR0702MB3772.eurprd07.prod.outlook.com> <65F221A3-3405-4F2C-99B6-278E8C2C0AD8@oracle.com> <HE1PR0702MB377297EAEE9040F8BDD7046D95710@HE1PR0702MB3772.eurprd07.prod.outlook.com>
From: Tom Talpey <tom@talpey.com>
Message-ID: <8c6e035a-9b50-f485-794a-54f02619643c@talpey.com>
Date: Thu, 30 Jul 2020 10:36:52 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <HE1PR0702MB377297EAEE9040F8BDD7046D95710@HE1PR0702MB3772.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfCjieAOfkWN3vhtqOjqG9ia0xmcKZ7RGanrBEC3zwMDKpJkNzJqkZqQJQcbH3/0P01szJ9dDi3oSA0uVpbA6nVavfwh+giCq6eD1mr47CqKiAoFNsCsT 2mIa5I4NjezdEZphiprBEyr/HBAhmoyncqs2CqG++LuIQQ8pDYJYlyWl
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/V_P2sFAopcdHSR4tJCb6037FfJo>
Subject: Re: [nfsv4] Verified editorial Errata on 5561 and sesqui-msns
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: Thu, 30 Jul 2020 14:36:54 -0000

On 7/30/2020 10:25 AM, Magnus Westerlund wrote:
> Hi Chuck,
> 
> If Errata 2249 despite its status as a verified editorial errata is not 
> editorial then lets leave it out of these changes. I really only want to 
> propose things that are truly editorial and have the potential for cause 
> issues for an implementor using this specification.

Totally agree with the goal, but this erratum is 10 years old (!) and
was filed by someone who well-understands the situation. At a minimum
it seems prudent to update the text to clarify this, perhaps while
making a statement of fact that implementations to an earlier version
might have differing behavior.

JMHO.

> 
> Cheers
> 
> Magnus
> 
> *From:*Chuck Lever <chuck.lever@oracle.com>
> *Sent:* den 30 juli 2020 14:18
> *To:* Magnus Westerlund <magnus.westerlund@ericsson.com>
> *Cc:* nfsv4@ietf.org; draft-ietf-nfsv4-rfc5661sesqui-msns@ietf.org
> *Subject:* Re: Verified editorial Errata on 5561 and sesqui-msns
> 
> Hi Magnus -
> 
> 
> 
>     On Jul 29, 2020, at 5:01 AM, Magnus Westerlund
>     <magnus.westerlund@ericsson..com
>     <mailto:magnus.westerlund@ericsson.com>> wrote:
> 
>     Hi Authors and WG
> 
>     This relates to the ongoing AUTH48 for
>     draft-ietf-nfsv4-rfc5661sesqui-msnsI
> 
>     I got a question from the RFC-editor about some of the errata filed
>     on RFC 5561. These where two errata that are editorial and verified.
>     They are basically typos or other very basic issues but of potential
>     importance to understanding. And maybe we should include these
>     change into this document instead of continue to confuse the reader.
>     However looking in the Errata list there are more that of this basic
>     type but wasn’t obvious in the copy editing.
> 
>     The Errata that I think falls into this category are:
> 
>     https://www.rfc-editor.org/errata/eid3558
>     <https://protect2.fireeye.com/v1/url?k=2187309c-7f279e51-21877007-86073b36ea28-7eccff51ed56e2f2&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid3558>
> 
>     https://www.rfc-editor.org/errata/eid2062
>     <https://protect2.fireeye.com/v1/url?k=72c62308-2c668dc5-72c66393-86073b36ea28-54630add5fc8660d&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2062>
> 
>     https://www.rfc-editor.org/errata/eid2249
>     <https://protect2.fireeye.com/v1/url?k=94ba5266-ca1afcab-94ba12fd-86073b36ea28-60b60d9c5490c0b6&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2249>
> 
>     https://www.rfc-editor.org/errata/eid2280
>     <https://protect2.fireeye.com/v1/url?k=8da5c41c-d3056ad1-8da58487-86073b36ea28-21dd69a0e0e97c0d&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2280>
> 
>     https://www.rfc-editor.org/errata/eid2324
>     <https://protect2.fireeye.com/v1/url?k=f75faa3f-a9ff04f2-f75feaa4-86073b36ea28-ded42b3464c0a2bb&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2324>
> 
>     https://www.rfc-editor.org/errata/eid2330
>     <https://protect2.fireeye.com/v1/url?k=e48cd74b-ba2c7986-e48c97d0-86073b36ea28-1ba367ea7b2d71fc&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2330>
> 
>     https://www.rfc-editor.org/errata/eid2548
>     <https://protect2.fireeye.com/v1/url?k=e2145460-bcb4faad-e21414fb-86073b36ea28-3e737b266ad059ce&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2548>
> 
>     So the above ones is the ones I wonder if we simply should have the
>     RFC-editor apply before publication? I think this is simply
>     correcting things that the WG knows are wrong in RFC5661 and it
>     could help the reader. I am aware of this is not following what was
>     previous said about Errata, but I think this category should have
>     been included as they appear very straight forward and have been
>     previously classified as relevant for understanding and have risk of
>     causing implementation errors. If the WG participants think we
>     should stick with previous path and not include them I will listen.
>     However, take a look at them before you make that assessment.
> 
> All of these appear to be errors that might be typically caught and 
> corrected during AUTH48, with one exception:
> 
> https://www.rfc-editor.org/errata/eid2249 
> <https://protect2.fireeye.com/v1/url?k=8fa96a97-d109c45a-8fa92a0c-86073b36ea28-bf9a924cced2a88a&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2249>
> 
> appears to be technical, and therefore requires review by WG members 
> familiar with implementations of CB_LAYOUTRECALL to avoid protocol 
> changes that would impact interoperability among existing implementations.
> 
> With the exception of 2249, I am in favor of addressing these minor 
> issues before publication. I do not believe addressing them would result 
> in undue delay.
> 
>     There are two Errata that are listed as editorial and verified that
>     are not straight forward nor necessary only editorial
> 
>     https://www.rfc-editor.org/errata/eid2328
>     <https://protect2.fireeye.com/v1/url?k=7f12ac8c-21b20241-7f12ec17-86073b36ea28-ef8e722add5a545a&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2328>
> 
>     This appears to an Error code that is missing in RFC5661 and should
>     be listed in Section 15.1.16. This doesn’t have text that can just
>     be applied.
> 
>     https://www.rfc-editor.org/errata/eid4215
>     <https://protect2.fireeye.com/v1/url?k=e27bb61d-bcdb18d0-e27bf686-86073b36ea28-9e3f3185e9f7c66a&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid4215>
> 
>     This Errata appears to fix a unclear statement in fourth paragraph
>     of Section 22.2. However, I don’t see this as Editorial as it
>     changes the IANA procedure even if what is currently written is
>     confusing.
> 
>     So these I would leave for the proper bis to take care of.
> 
>     Cheers
> 
>     Magnus Westerlund
> 
> --
> 
> Chuck Lever
> 
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>