Re: [nfsv4] New draft for working group charter

[David Noveck <[e-mail]>]

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

>
> > On May 15, 2017, at 11:20 AM, David Noveck <[e-mail]> 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.
>
> I'm not 100% happy with this, but I don't have a better alternative.
> Everything else works for me.
>
>
> > > >       • 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
> >
> >
> >
> >
>
> --
> Chuck Lever
>
>
>
>