Re: [nfsv4] New draft for working group charter

[David Noveck <[e-mail]>]

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 <[e-mail]> wrote:

>
> > On May 14, 2017, at 2:56 PM, David Noveck <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/nfsv4
>
> --
> Chuck Lever
>
>
>
>