Re: [nfsv4] Genart last call review of draft-ietf-nfsv4-versioning-09

David Noveck <davenoveck@gmail.com> Tue, 02 May 2017 23:50 UTC

Return-Path: <davenoveck@gmail.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 C9FE212922E; Tue, 2 May 2017 16:50:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 TdINOFsHzeqv; Tue, 2 May 2017 16:50:43 -0700 (PDT)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE6D6129BC8; Tue, 2 May 2017 16:48:57 -0700 (PDT)
Received: by mail-it0-x22a.google.com with SMTP id e65so28222225ita.1; Tue, 02 May 2017 16:48:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=f1WYamJ6MhRIrh8VhyDg6ZTGF89M6xNA5fWwZ2pTCng=; b=Hv9j8fSo8Ol9AT1qjIwCwcK+OZDsiG51TuBEuK/X0yEPpwgTeuEyrHZLWnJ3mOpQ7l FUGVTRaiErnTckhewpQFrwI3gGgmY6HWYmh6aU+fzcn0zRn1eqULvrVlGceJfx9oHypX LVTBDSY+GoIHpyLB2OxNXF42BTXn50vkw/i/3I9NmmwwEc/0iKqko8xkxCnhLW+fMNhV VNCMvcSZswHhy9y7hYA/Ru1jA4oRmkFX0PfmgIh/fbXyEm4YIWeB1fxCI1K65+5sCHlp juvW/Hs8Y3nuaDVSqb7Y1Nj/0WvXb19Qb0aMF9KgXJQNSl0Y/JW0RCZxbUiHlE+v7lXb Wr9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=f1WYamJ6MhRIrh8VhyDg6ZTGF89M6xNA5fWwZ2pTCng=; b=TX/ix36AJCBNwAca32FlEnHCd7HEp+MecjaZ1KXB3AETEMyMBqlUUcXwm7LIyhYLFd DTIUAnmS3um2CkvWqXNqm78yTbtgNdMS9CyqggvMnQ4pVsEA/xBUIJOobC5uMNq8FSdL 9X0/G5kkJ1uXFVW2+MVze9gkHViL11/ju3Sl7cVBkLLEzrYNTZDGiX9Oi7LiiezbAQFs uIWRYsZrZuDM+WAyjbPo1Vg5EurN+8w+DskFUBl4v6a1Jt8YCs9SAQy27cflvNy+BiZO 0jfIaTszogfnnHt8zF4ft+fg767yLnKiMhWpO2l7UJ4WozO1tEvpeqWbGoLkrTtWyv5l wFwQ==
X-Gm-Message-State: AN3rC/6TzAeUSmijWFZv6pzf5B+jq3gREPOC4KA4Q6KLk/8TcqN7Uany o9+5tP6SQNwFY4skShLwtTUQPrHoeXCM
X-Received: by 10.36.137.212 with SMTP id s203mr5379805itd.57.1493768937205; Tue, 02 May 2017 16:48:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.175.14 with HTTP; Tue, 2 May 2017 16:48:56 -0700 (PDT)
In-Reply-To: <149375188938.21443.7482767478129358123@ietfa.amsl.com>
References: <149375188938.21443.7482767478129358123@ietfa.amsl.com>
From: David Noveck <davenoveck@gmail.com>
Date: Tue, 02 May 2017 19:48:56 -0400
Message-ID: <CADaq8jfqDuaLdsmWuvJpyyKc+krqHBYdif1BEBrGvRBSTnKrzg@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Cc: "gen-art >> General area reviewing team" <gen-art@ietf.org>, ietf@ietf.org, draft-ietf-nfsv4-versioning.all@ietf.org, "nfsv4@ietf.org" <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c05f6a0e0fb78054e932ea3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/bbz33OahG1pqVm9VvPOIOnUrYm4>
Subject: Re: [nfsv4] Genart last call review of draft-ietf-nfsv4-versioning-09
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 02 May 2017 23:50:46 -0000

Thanks for the review.

> This document, once approved, will update RFC 5661 and RFC 7862.

Yes, because it invalidates statements regarding versioning made in
those documents.

> It seems to me that it should also update RFC 7530.

I don't see why.  What is in RFC7530 regarding versioning still
remains valid once this document is approved.

> It fulfills a promise made in Section 11 of RFC 7530.

Section 11 says that a document such as this would be desirable
but it doesn't make any sort of promise.

I think the question is what is the proper stanard for one RFC to
update another.  I followed my own understanding.  If that is wrong, I
will change it.



> In Section 4.2, the last bullet in the section is unusual.  That
> bullet add a new context for the entire list of bullets.
> It would be better
> for the introduction to the list to provide the full context at the
> beginning.

Actually, the last bullet in saying "these items" is not referring to
the items in all the bullets, but only those in the last bullet.

Still, this is confusing.  The last bullet shoud be merged into the third.


> Throughout the document, some bullet items end with periods and
> others do not.
> Use of the period is more common.  Please pick one style and
> use it throughout the document.

Will do.

> The last sentence of the Introduction is not clear.  After reading it
> several times, I think you are trying to say:

>   ... enabling interoperation to proceed just as if both
>   implementations supported only the parts of the protocol
>   that are being used.

I'm having trouble understanding that.  I think the problem we
re both having is that, except for callbacks, the client doesn't
support features it uses them.  I think we have a fundamentally
asymmetric situation and we keep tripping over ourselves as we
try to present it symmetrically.

How about:

As described in Section 4.4, two implementations can each choose  a
subset of available extensions, with the client able to use the subset
of the extensions that it is prepared to use that the server supports
as well.  Support for this common subset is not affected by the fact
that extensions outside this common subset may be supported by the
server or potentially used by the client.


> In Section 2.3:
> s/(not necessarily proper)/(not necessarily a proper subset)/

Will change.

> In Section 4.4.2, in the last set of bullets, the first bullet begins
> with "The minor version consists", but it should begin with "When the
> minor version consists".  The "so" following the comma should also be
> removed.

Will fix.  Your version is better.

> In Section 6, 2nd paragraph, I found the text confusing because
> "following" is used with two very different meanings in the same
> sentence.  I suggest: S/to following/to obeying/

I think I prefer S/the following rules/the rules listed below/.

On Tue, May 2, 2017 at 3:04 PM, Russ Housley <housley@vigilsec.com> wrote:

> Reviewer: Russ Housley
> Review result: Almost Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>
> For more information, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Document: draft-ietf-nfsv4-versioning-09
> Reviewer: Russ Housley
> Review Date: 2017-05-02
> IETF LC End Date: 2017-03-08
> IESG Telechat date: Unknown
>
> Summary: Almost Ready
>
> Major Concerns:
>
> This document, once approved, will update RFC 5661 and RFC 7862.  It
> seems to me that it should also update RFC 7530.  It fulfills a
> promise
> made in Section 11 of RFC 7530.
>
> Minor Concerns:
>
> In Section 4.2, the last bullet in the section is unusual.  That
> bullet
> add a new context for the entire list of bullets.  It would be better
> for the introduction to the list to provide the full context at the
> beginning.
>
> Nits:
>
> Throughout the document, some bullet items end with periods and
> others
> do not.  Use of the period is more common.  Please pick one style and
> use it throughout the document.
>
> The last sentence of the Introduction is not clear.  After reading it
> several times, I think you are trying to say:
>
>    ... enabling interoperation to proceed just as if both
>    implementations supported only the parts of the protocol
>    that are being used.
>
> In Section 2.3:
> s/(not necessarily proper)/(not necessarily a proper subset)/
>
> In Section 4.4.2, in the last set of bullets, the first bullet begins
> with "The minor version consists", but it should begin with "When the
> minor version consists".  The "so" following the comma should also be
> removed.
>
> In Section 6, 2nd paragraph, I found the text confusing because
> "following" is used with two very different meanings in the same
> sentence.  I suggest: S/to following/to obeying/
>
>
>