Re: [nfsv4] New draft for working group charter

David Noveck <davenoveck@gmail.com> Fri, 02 June 2017 18:39 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 79B6E129584; Fri, 2 Jun 2017 11:39:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_FONT_SIZE_LARGE=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 8HGSlDf3EdCn; Fri, 2 Jun 2017 11:39:14 -0700 (PDT)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 E1E5F12940D; Fri, 2 Jun 2017 11:39:13 -0700 (PDT)
Received: by mail-it0-x22c.google.com with SMTP id m62so14614797itc.0; Fri, 02 Jun 2017 11:39:13 -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=4HEahj4p9hah6iOpMQZ6HKSj7ZjJQi4LYVIVJ1TsoWc=; b=m9AvMTGGPrQELTROnKlUwW9XTkZxxojzvzFv/+kjqcyecqDSIwEyxxe5Vx6+ujL0Pu zDTffeDZBMEvJ/dO3m3eh5hsSAGCXja0ljH51edI0yCofjqJMcdD6Qp7HJM4X9QPDOzP Y/4/tjrfeuRJgSwTK4DT117qNBwiQC8L3xkY/hSHgOiqXopLaW8+rQIUgVN/bMNJ01fr e+IQRvtq+lnHgdNZgz0wbszysHYnTRtMmsNS4nrdC0gfLjyDhYMznL7shjznYo0J94hP jUCPhpCNS9bzjtSaPhtrogx+T89OCMFKRCUQsNRWVqQ996LWn8fxLrqkU7sdsetj+A8R +w5w==
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=4HEahj4p9hah6iOpMQZ6HKSj7ZjJQi4LYVIVJ1TsoWc=; b=UayvND/NjN3pra0FrWltC2uiX9yveP0UV/pZbCmH13YKJ83eg/1M2Vq+6lhUjMC/68 Kr87dn86Xy6zzLmXVr68nKBVRRXtrQ9+GqJNXw+Uk6Don8lVVbOOZz17wcMsTcYaaUb5 nR14O1kbZ6xjEPmer6UN3QbA5ZpTFEOGtui7ek7NgM6rw0gDFz+53J5qXzogl7Nz4XVM X74W9lvu0abgBuEYRmPNQM5X/UnKjOEgaXNddSVcqJUn49jGiqx3atxnXUuhXM/kOS1F m2JN9HhdZGPnkz3OTYsvs0bF1vPmbOBdgHMYEGVBhnm45sTv5ioy5ZBPHOk6sOmwcyEr OxlA==
X-Gm-Message-State: AODbwcAhQ5EveSdMDeC6qeeKDkjdfHgPWON6oy+rUP08SvDsH7yAD9XZ 44Zt/KgXW+Mihhfsmr/ChSidqBNUMQ==
X-Received: by 10.107.143.148 with SMTP id r142mr9239686iod.137.1496428753111; Fri, 02 Jun 2017 11:39:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.4.148 with HTTP; Fri, 2 Jun 2017 11:39:11 -0700 (PDT)
In-Reply-To: <CADaq8jdi2N1ePeRRFqJprgFssJreEVJZGJ=_mF69cOWJkYGK9A@mail.gmail.com>
References: <CADaq8jcyxGnLh3K94JEqTkOycqzSJXS4Bcckcg63AQdksN0LJA@mail.gmail.com> <C4801D03-0607-4AEE-B7F9-FE60B3620B5F@oracle.com> <CADaq8jdi2N1ePeRRFqJprgFssJreEVJZGJ=_mF69cOWJkYGK9A@mail.gmail.com>
From: David Noveck <davenoveck@gmail.com>
Date: Fri, 2 Jun 2017 14:39:11 -0400
Message-ID: <CADaq8jfb0qswY2LLJPSZe67BRsfpzvOHvNDqMzH5nr1L2+vkZA@mail.gmail.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>, "nfsv4-chairs@ietf.org" <nfsv4-chairs@ietf.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c05a28e42d1d50550fe78fe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/fwA6N7d5p4rEwYEUq3pcOH7jXFg>
Subject: Re: [nfsv4] New draft for working group charter
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: Fri, 02 Jun 2017 18:39:17 -0000

This is  based on iteration three (sent 5/14) with two sets of changes:

   - Updates responding to Chuck's comments of 5/15.
   - Some changes to *Maintenance* and *Extensions* to prepare us to
   respond in some way to the SECDIR comments about RFC7530's Security
   Considerations section.

While I will continue to respond to comments and update the draft as
necessary, it seems that something very like this will one of the draft
charters we will be discussing in Prague.  There has been no on-list
discussion about how we would use the thirty minutes allocated for
charter-related matters but I would appreciate around ten minutes to
present some slides (six?) giving  my view of the appropriate way forward.

Two changes that I anticipate making before or at IETF99 are:

   - Some wording changes regarding the virtualization management bullet
   that Chuck feels would be an improvement.
   - Wording of an appropriate bullet to capture the flex-files work and
   similar future initiatives that the working group might undertake.

Also, I continue to look for possible new milestones but think it is not
likely we will see any before IETF99.  I hope we will be able to agree on a
few soon after IETF99.




Draft Charter for NFSv4 WG (Iteration Four)

NFS Version 4 is the IETF standard  for file sharing. To maintain NFS
Version 4's utility and currency, the working group is chartered to
maintain the existing NFSv4.0, NFSv4.1, and NFSv4.2 protocols and
specifications of related ONC components such as those defining RPC, XDR,
and RPCSECGSS. In addition, extensions will be developed, as necessary, to
correct problems with the protocols as currently specified, to accommodate
needed file system semantics, and to respond to technological developments
in the areas of networking and persistent storage/memory.

*Maintenance*

The working group has found that as NFSv4 implementations mature and
deployments continue, clarifications and corrections to existing RFCs are
needed. These specification updates help vendors in delivering quality
and interoperable implementations.

The working group is chartered with the vetting of the issues and
determining correctness of submitted errata. The working group is also
responsible for approving changes to RPC- and NFS-related IANA registries.

In addition, some areas may need more concentrated work to correct the
specifications already published, to deal with unanticipated interactions
between features, or to respond to changed IESG expectations with regard to
areas such as security.  Since necessary changes in such cases are
generally not appropriate for the errata system, the working group will
assist in publication of best practices RFCs and of RFCs that provide
editorial modification or technical updates to original RFCs.  Since the
new NFSv4 versioning framework has been approved, such technical updates to
NFSv4 minor versions could include limited XDR changes.

*Extension*

The NFSv4 protocol is designed to allow extension by the addition of new
operations or new attributes, the creation of minor versions, and the
definition of new pNFS layout types.  Similarly, associated ONC protocol
components that have a versioning/extension  framework can be incrementally
extended, when necessary.

The working group will discuss proposals for such extensions and assure
they have adequate technical review, including discussion of their
interaction with existing features, before adopting them as working group
items and helping to draft specification documents. Some likely motivations
for such extensions would be to:


   - Maximize NFS performance on advanced network fabrics.
   - Accommodate new storage technologies.
   - Provide facilities useful in management of NFS-accessed storage in
   large-scale virtualization environments.
   - Provide more effective NFS response to security challenges.





Milestones (Third draft -- unchanged from second)

Because the previous charter was at variance with the work the group was
actually doing, the list of pending milestones that can determined now is
quite limited.  To accommodate this situation and in light of the fact that
maintenance activities are inherently unpredictable, new milestones that
fall within the scope specified within the charter can be added after
working group consensus on acceptance and approval by the responsible Area
Director.

*Date               Milestone*

March 2018    WGLC for draft-ietf-nfsv4-migration-issues (Informational)

On May 15, 2017 11:20 AM, "David Noveck" <davenoveck@gmail.com> wrote:

> Thanks for the review.  Will incorporate your suggestions in the next
> version of the draft in a few weeks.
>
> > > The working group has found that as NFSv4 implementations mature and
> deployments continue, clarifications to existing RFCs are needed. These
> clarifications assist vendors in delivering quality and interoperable
> implementations. The working group is chartered with the vetting of the
> issues and determining correctness of submitted errata. In addition,the
> working group is responsible for approving changes to NFS-related IANA
> registries.
>
> > Nit: Suggest "existing RPC- and NFS-related IANA registries."
>
> OK.
>
> > In addition, some areas may need more concentrated work to correct the
> specifications already published or to deal with unanticipated interactions
> between features.
>
> > Nit: Two adjacent sentences begin with the clause "In addition,".
>
> > Suggest removing that clause in one or both places.
>
> Will change:
>
>  In addition,the working group is responsible for approving changes to
> NFS-related IANA registries.
>
> To:
>
>  The working group is also responsible for approving changes to existing
> RPC- and NFS-related IANA registries.
>
>
>
>
>
>
> >> The working group will discuss proposals for such extensions and assure
> they have adequate technical review including discussion of their
> interaction with existing features before adopting them as working group
> items and helping to draft specification documents. It is likely that such
> extensions will be needed in order to;
>
> > As you suggested earlier, the introductory text should somehow
> > indicate the following list is not exhaustive.
>
> I think the context already does that.  Maybe it would be clearer if we
> said
>
> Some likely motivations for such extensions would be to:
>
>
>
> > >       • Enable the performance attributes of advanced network fabrics
>
> > Suggest "Maximize NFS performance on advanced network fabrics".
>
> That's better.  Thanks.
>
>
> > >       • Adapt to new storage technologies,
>
> > Nit: Other bullet points do not end with a comma.
>
> > Suggest "Accommodate new storage protocols and technologies".
>
> Will change.
>
> > >       • Enable use of NFS in large-scale virtualization environments
>
> > NFS can already be used in these environments. Suggest
> > "Simplify administration of NFS-accessed storage in large-
> > scale virtualization environments".
>
> This isn't clear.    How about:
>
>  Provide facilities useful in management of NFS-accessed storage in large-scale
> virtualization environments.
>
>
> > >       • Helping NFS adapt to increasing network security challenges
>
> > Nit: Use similar sentence form for all four bullets.
>
> > Suggest
> > "Prepare NFS to meet increasing security challenges"
>
> "Prepare'" seems too passive.
>
> How about:
>
>
> Provide effective NFS response to increasing security challenges.
>
>
>
> On Sun, May 14, 2017 at 3:49 PM, Chuck Lever <chuck.lever@oracle.com>
> wrote:
>
>>
>> > On May 14, 2017, at 2:56 PM, David Noveck <davenoveck@gmail.com> wrote:
>> >
>> > The following is the third iteration of my attempt to provide a draft
>> charter to be "whacked" on (as Beepy put it) by the working group so all
>> comments are appreciated.  However, if someone would like to present an
>> alternate draft, that would be fine as well.  We do need some sort of draft
>> to work from for a discussion in Prague.  Without it, a discussion in
>> Prague is not going to arrive at a useful charter candidate.
>> >
>> > The new draft has the following changes from the second draft.  If you
>> object to any of these changes, let me know right away:
>> >       • Revised the lead paragraph to avoid explicitly referencing
>> performance.
>> >       • Included Chuck's suggestion regarding NFS-related registries in
>> the  Maintenance  section.
>> >       • Reorganized the  Maintenance  section into two paragraphs
>> >       • Deleted the  Performance Challenges section and moved the
>> material into the Extension section, dealing with performance-related items
>> in line with Chuck's suggested typology.
>> >       • Reorganized the Extensions section to include a list of likely
>> motivations for extensions.
>> >       • Changed "mapping types" to "layout types".
>> >       • At Spencer S's request, Milestones  has been cut back to a
>> single milestone. When -13 is published, the way forward in this area
>> should become clearer and the list could be updated to include some
>> expected documents to address the issues described in the Informational
>> document.  BTW, I'm assuming there will be a need for WGLC for that
>> document as a means of establishing consensus on a way forward for those
>> issues even though I believe there is no point in publishing that document
>> as an RFC.
>> > Beyond the changes that result from additional working group comments I
>> am anticipating the changes listed below.  Although these could happen as
>> late as IETF99, it is better if we get to a base draft for discussion
>> before that.
>> >       • Addition of one or more milestones for flex-files.
>> >       • A statement concerning flex-files work for the bullet list in
>> the Extension section.
>> >       • Addition of milestones relating to the work discussed in
>> migration-issues-13, relating to trunking discovery, migration, and the
>> relationship between those two features.
>> > Draft Charter for NFSv4 Working Group (Iteration Three)
>> > NFS Version 4 is the IETF standard for file sharing. To maintain NFS
>> Version 4's utility and currency, the working group is chartered to
>> maintain the existing NFSv4.0, NFSv4.1, NFSv4.2, protocols and related
>> specifications of ONC components such as those defining RPC, XDR, and
>> RPCSECGSS. In addition, extensions will be developed, as necessary, to
>> correct problems with the protocols as currently specified, to accommodate
>> needed file system semantics, and to respond to technological developments
>> in the areas of networking and persistent storage.
>> >
>> > Maintenance
>> >
>> > The working group has found that as NFSv4 implementations mature and
>> deployments continue, clarifications to existing RFCs are needed. These
>> clarifications assist vendors in delivering quality and interoperable
>> implementations. The working group is chartered with the vetting of the
>> issues and determining correctness of submitted errata. In addition,the
>> working group is responsible for approving changes to NFS-related IANA
>> registries.
>>
>> Nit: Suggest "existing RPC- and NFS-related IANA registries."
>>
>>
>> > In addition, some areas may need more concentrated work to correct the
>> specifications already published or to deal with unanticipated interactions
>> between features.
>>
>> Nit: Two adjacent sentences begin with the clause "In addition,".
>> Suggest removing that clause in one or both places.
>>
>>
>> > In the cases in which the required changes are inappropriate for the
>> errata system, the working group will assist in publication of best
>> practices RFCs or of RFCs that provide editorial modification or technical
>> updates to original RFCs.  Once, the new NFSv4 versioning framework is
>> approved, such technical updates to NFSv4 versions could include limited
>> XDR changes.
>> >
>> > Extension
>> >
>> > The NFSv4 protocol is designed to allow extension by the addition of
>> new operations or new attributes, the creation of minor versions, and the
>> definition of new pNFS layout types.  Similarly, associated ONC protocol
>> components that have a versioning/extension  framework can be incrementally
>> extended, when necessary.
>> >
>> > The working group will discuss proposals for such extensions and assure
>> they have adequate technical review including discussion of their
>> interaction with existing features before adopting them as working group
>> items and helping to draft specification documents. It is likely that such
>> extensions will be needed in order to;
>>
>> As you suggested earlier, the introductory text should somehow
>> indicate the following list is not exhaustive.
>>
>>
>> >       • Enable the performance attributes of advanced network fabrics
>>
>> Suggest "Maximize NFS performance on advanced network fabrics".
>>
>>
>> >       • Adapt to new storage technologies,
>>
>> Nit: Other bullet points do not end with a comma.
>>
>> Suggest "Accommodate new storage protocols and technologies".
>>
>>
>> >       • Enable use of NFS in large-scale virtualization environments
>>
>> NFS can already be used in these environments. Suggest
>> "Simplify administration of NFS-accessed storage in large-
>> scale virtualization environments".
>>
>>
>> >       • Helping NFS adapt to increasing network security challenges
>>
>> Nit: Use similar sentence form for all four bullets. Suggest
>> "Prepare NFS to meet increasing security challenges"
>>
>>
>> > Milestones (Second draft)
>> >
>> > Because the previous charter was at variance with the work the group
>> was actually doing, the list of pending milestones that can determined now
>> is quite limited.  To accommodate this situation and in light of the fact
>> that maintenance activities are inherently unpredictable, new milestones
>> that fall within the scope specified within the charter can be added after
>> working group consensus on acceptance and approval by the responsible Area
>> Director.
>> >
>> > Date               Milestone
>> >
>> > March 2018    WGLC for draft-ietf-nfsv4-migration-issues
>> (Informational)
>> >
>> >
>> > _______________________________________________
>> > nfsv4 mailing list
>> > nfsv4@ietf.org
>> > https://www.ietf.org/mailman/listinfo/nfsv4
>>
>> --
>> Chuck Lever
>>
>>
>>
>>
>