Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-mv1-msns-update-04: (with DISCUSS and COMMENT)

David Noveck <davenoveck@gmail.com> Wed, 08 May 2019 15:56 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 61060120136; Wed, 8 May 2019 08:56:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 TQoaTDfZcPgo; Wed, 8 May 2019 08:56:13 -0700 (PDT)
Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 3493D1200DF; Wed, 8 May 2019 08:56:13 -0700 (PDT)
Received: by mail-ot1-x32e.google.com with SMTP id c3so4064636otr.3; Wed, 08 May 2019 08:56:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3f5/KI9wWk6NulHSuzTOU4L1u2Q91EdfxkUryD2eh7g=; b=Mz1JqJ1+Uxg0WktdwiTU0G9JqeR2bQdp83UPBXMarVIKKiTe4bo73Zms+lFZGTZWRW jXkKkZN/Xo+I6MLGZO7KkIhCDzReghD5Vji6UPkVxserX0c7hixWvKcnMJAluiLMhhGu 3azr3Jr9Ag6EtOn7wwfXJ3EmkURqrYMf/pS2iZa7otJPdRiPr2av9GkJgKVO2ESFgRMR Shyzw5Oqo6rd8EoX+N6yVUcEoj9PYDTMAisEVHmAk2VumpyrHzLvR9chGkZZ8BoqA+cp DhKzIJ/LvfF0Mvjc/1UW1S6pIPgRJyjhMyaLS14dRelRZyOAIC39C5r2Ai1qwfbw0h62 yncQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3f5/KI9wWk6NulHSuzTOU4L1u2Q91EdfxkUryD2eh7g=; b=T5Ezsfs7U7KlQ/rHx57Ew1B+FlTsXj71J/o2VBFepgQ6yGjmaUNL3eJ2mCwNv7oB4F zs9d3r5xSZfs5KdlsEZ8yG64LLQtkOnBYS2xuPhQTlRByymKiriISTq9VUmQXJbVj72y fDQYyER5bBicYAyeUTm96LnqWxt4Hph360MbrsS9RD8DEhEQbuFs6/QJ69PPPaBf2BV+ VDcsKTCf5YnnPz9YISB7Y7Cm58ElGKdVYGqlU0WF5z/RVoQ6WCjTe97/VE9C6glqasp7 1L/dyjYjD3Mr+/rfdzIZNvVjeXQIVuIbWkz+/1ODrmWN3sMrUW84cU4zWe2P8uFq5LBI h/7w==
X-Gm-Message-State: APjAAAU4KAVxwb7kLefBHZXSWjaGaRTOB9o+z7da8sTcWFbiaW0i2R9/ bp/E+q8ggQ4Yz1obXH7mBciSV74Y667ykKU3AyY=
X-Google-Smtp-Source: APXvYqyL4GEkFAoMzyvmddxMcfHAj53IPDLKwNxyes2NhnUMTm1+Ls8P0v/rERXO7itMU7DGbdpU5CB6FiujpagcIQ4=
X-Received: by 2002:a9d:634b:: with SMTP id y11mr22055149otk.78.1557330972436; Wed, 08 May 2019 08:56:12 -0700 (PDT)
MIME-Version: 1.0
References: <155184411184.27685.16459405842977852294.idtracker@ietfa.amsl.com> <CADaq8jcbtAy+RnCsxLBHpGfX7YOUCXbVU21DKKF5yOuXtwM4GQ@mail.gmail.com> <CAKKJt-c++YwyEONK=He55uX0GR+23bc1jrjjU5hxHB3ipJYwmg@mail.gmail.com> <CADaq8jcA_TP5xrCy8VXBPRASA_o8rmxOpn+7PBnhH_1=2tHGEA@mail.gmail.com> <CADaq8jdNOWEKqGxBCZ6+He6iNyUfQw7HmnU5VU=dFhFMGv=mTQ@mail.gmail.com> <HE1PR0701MB25228E47DAA1B605342637B095320@HE1PR0701MB2522.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR0701MB25228E47DAA1B605342637B095320@HE1PR0701MB2522.eurprd07.prod.outlook.com>
From: David Noveck <davenoveck@gmail.com>
Date: Wed, 8 May 2019 11:56:00 -0400
Message-ID: <CADaq8jdMbD59OHixRrw9q_odLWzXMxKQ_mzFaxfYNEJwT-7kBg@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, NFSv4 <nfsv4@ietf.org>, "draft-ietf-nfsv4-mv1-msns-update@ietf.org" <draft-ietf-nfsv4-mv1-msns-update@ietf.org>, "nfsv4-chairs@ietf.org" <nfsv4-chairs@ietf.org>, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000068ee5c0588625f0c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/_FcQOC4zGSowVzdQWQG40iYSFFQ>
Subject: Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-mv1-msns-update-04: (with DISCUSS and COMMENT)
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: Wed, 08 May 2019 15:56:17 -0000

> IESG, so the new document is this :
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc5661-msns-update/

> I have looked at this now a bit more in detail and have some comments. I
> am also looking at this document in the context of a proposal for a
> process update that could be applied in this type of case. NFSv4 WG you
> are very welcome to comment on what is proposed in this document
> https://datatracker.ietf.org/doc/draft-roach-bis-documents/ from your
> perspective.

>From my point of view, it should eliminate what had been the prime obtacle
to
presenting this document in the form of an rfc5661bis, the need to evalluate
a Security Considerations secton for that document in a way that would be
appropriate to a new Proposed Standard.

By providing the non-major updates previously poposed in the form of a bis
document, as the IESG has been requesting, I think we could avoid this
difficulty.

> I do note that with your update document the RFC diff is possible to use
> to find the changes, but gets quite cluttered up by the introduction and
> many pages of excluded chapters. See for yourself here:
>
https://tools.ietf.org/rfcdiff?url1=https://www.rfc-editor.org/rfc/rfc5661.txt&url2=https://www.ietf.org/id/draft-ietf-nfsv4-rfc5661-msns-update-00.txt
.
> I think an update according to this proposal with the full document
> would have a cleaner DIFF.

Agree that it woud.

There would no longer be pointless diffs reporting the deletion of the
excluded (unchanged) chapter.

With regard to the introductory/explanatory text, that would still be there
but it would no longer be perceived as clutter.  Instead it would be marked
in the diff as additions,

> To my understanding your document in a full form would meet the Basic
> Qualifications in 3.1 of the process proposal. Do the WG agree?

I agree. I think the best way to find out if the working group agrees is
for me
to produce a -01 along the lines suggested, adding back the deleted
sections,
have any necessary working group discussion, and then see if we can move
toward WGLC on the document.

> IESG, I do want to you to consider if you think this form of an update
> would be sufficient in this case. As you note it is still a long
> document of 130+ pages. We should arrive as soon as possible to an
> direction for this document.

I think I need to give the IESG fair warning that the document we are
talking about
would be much  longer than 13O oages, and in fact longer than rfc5661,
because of
the new explanatory sections and the material on transparent state
migration.

> Still some more detailed comments on the document.

> 1. The section headers. I do propose that all the "Update section" or
"New Section" text are removed.

I'm OK with doing that in -01 but I realize there might be pushback down
the line.

> 2. If it is desired to have inline reference to the corresponding
> section in RFC 5661 then I think one can add that as bracketed comment
> in the beginning of the body of the section.

OK.


On Wed, May 8, 2019 at 10:20 AM Magnus Westerlund <
magnus.westerlund@ericsson.com> wrote:

> Editors, WG and IESG,
>
> IESG, so the new document is this :
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc5661-msns-update/
>
> I have looked at this now a bit more in detail and have some comments. I
> am also looking at this document in the context of a proposal for a
> process update that could be applied in this type of case. NFSv4 WG you
> are very welcome to comment on what is proposed in this document
> https://datatracker.ietf.org/doc/draft-roach-bis-documents/ from your
> perspective.
>
> I do note that with your update document the RFC diff is possible to use
> to find the changes, but gets quite cluttered up by the introduction and
> many pages of excluded chapters. See for yourself here:
>
> https://tools.ietf.org/rfcdiff?url1=https://www.rfc-editor.org/rfc/rfc5661.txt&url2=https://www.ietf.org/id/draft-ietf-nfsv4-rfc5661-msns-update-00.txt
> .
> I think an update according to this proposal with the full document
> would have a cleaner DIFF.
>
> To my understanding your document in a full form would meet the Basic
> Qualifications in 3.1 of the process proposal. Do the WG agree?
>
> IESG, I do want to you to consider if you think this form of an update
> would be sufficient in this case. As you note it is still a long
> document of 130+ pages. We should arrive as soon as possible to an
> direction for this document.
>
> Still some more detailed comments on the document.
>
> 1. The section headers. I do propose that all the "Update section" or
> "New Section" text are removed.
>
> 2. If it is desired to have inline reference to the corresponding
> section in RFC 5661 then I think one can add that as bracketed comment
> in the beginning of the body of the section.
>
> I only read in detail until the end of Section 3.
>
> Cheers
>
> Magnus Westerlund
>
>
>
>
>
>
>