Subject: [nfsv4] New draft for working group charter

From: David Noveck <[email-masked]>
Date: Sun, 14 May 2017 14:56:38 -0400

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.

In addition, some areas may need more concentrated work to correct the
specifications already published or to deal with unanticipated interactions
between features. 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;

   - Enable the performance attributes of advanced network fabrics
   - Adapt to new storage technologies,
   - Enable use of NFS in large-scale virtualization environments
   - Helping NFS adapt to increasing network 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)

---

From: Chuck Lever <[email-masked]>
Date: Sun, 14 May 2017 15:49:40 -0400

> On May 14, 2017, at 2:56 PM, David Noveck <[email-masked]> 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.
> 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"

> 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
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Mon, 15 May 2017 11:20:28 -0400

Thanks for the review.  Will incorporate your suggestions in the next
version of the draft in a few weeks.

> Nit: Suggest "existing RPC- and NFS-related IANA registries."

OK.

between features.

> 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.

> indicate the following list is not exhaustive.

I think the context already does that.  Maybe it would be clearer if we said

> Suggest "Maximize NFS performance on advanced network fabrics".

That's better.  Thanks.

> Suggest "Accommodate new storage protocols and technologies".

Will change.

> scale virtualization environments".

This isn't clear.    How about:

 Provide facilities useful in management of NFS-accessed storage in large-scale
virtualization environments.

> Nit: Use similar sentence form for all four bullets.

> Suggest

"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 <[email-masked]> wrote:

> >       • 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.
> >       • 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 milestones relating to the work discussed in
> between features.
> > 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
> >

---

From: Chuck Lever <[email-masked]>
Date: Fri, 19 May 2017 09:18:10 -0400

> On May 15, 2017, at 11:20 AM, David Noveck <[email-masked]> wrote:
> 
> Thanks for the review.  Will incorporate your suggestions in the next version of the draft in a few weeks.
> 
>  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.
> 
> 
> 
> 
> 
>  Provide facilities useful in management of NFS-accessed storage in large-scale virtualization environments.

I'm not 100% happy with this, but I don't have a better alternative.
Everything else works for me.

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Fri, 19 May 2017 15:08:39 -0400

> I'm not 100% happy with this, but I don't have a better alternative.

If you think of an alternative, let me know and I'll include it in the next
draft.

> Everything else works for me.

It looks like we are making progress.

On Fri, May 19, 2017 at 9:18 AM, Chuck Lever <[email-masked]> wrote:

> > >> The working group will discuss proposals for such extensions and
> assure they have adequate technical review including discussion of their
> > > Beyond the changes that result from additional working group comments
> I am anticipating the changes listed below.  Although these could happen as
> > > The NFSv4 protocol is designed to allow extension by the addition of
> new operations or new attributes, the creation of minor versions, and the
> > > The working group will discuss proposals for such extensions and
> assure they have adequate technical review including discussion of their
> > > 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