Re: [nfsv4] New draft for working group charter

[David Noveck <[e-mail]>]

> Please remove the milestone entries for everything except the migration
issues work.  We have progressed far

> enough that our responsibility is to nudge the work through the rest of
the process and by the time the charter is

> updated, we should be even further along.


OK, but that leaves us with only one milestone :-(


OTOH, I think there could be additional milestones coming out of the
migration issues work that could be added at or before IETF99.  Stay tuned
for the publication of of migration-issues-13.



> I believe the charter should have two sections.


As a result of my discussions with Chuck, I will move toward a two-section
approach.


> One for maintenance


OK.


> and one for potential areas of extended interest.


I think there has to be some place for extensions in general, i.e. the kind
of thing we have been doing.


So I"m thinking about a larger extensions section that includes the
material you are talking about, but a more generic statement about
extensions (the stuff currently in the extensions section) as well.


> In that second section we can then include some of the examples of areas
that have been an interest for those

> engaged with the group and appear to have growing energy.


Yes, but we have to get WG agreement about what those are.



> From this we will then work with our AD on charter updates


I'm worried about "updates".  SInce we have had such trouble/delay doing a
single charter update, I'm worried about a program that foresees multiple
updates.


> for the larger work items that deserve a notification to the IESG such
that there is the potential for cross

> area/working-group touch points.


I'm not sure there are any of those.  What areas are you thinking of?


> I will work with Spencer D. on this approach to see if it is workable
from his point of view.


Since Spencer D is copied, it might be best if you filled in the details on
your proposal.  I expect Spencer would let us know if he thinks we are
barking up the wrong tree (or at the moon :-).

On Fri, May 12, 2017 at 12:48 PM, Spencer Shepler <[e-mail]>
wrote:

>
>
> David,
>
>
>
> Please remove the milestone entries for everything except the migration
> issues work.  We have progressed far enough that our responsibility is to
> nudge the work through the rest of the process and by the time the charter
> is updated, we should be even further along.
>
>
>
> I believe the charter should have two sections.  One for maintenance and
> one for potential areas of extended interest.  In that second section we
> can then include some of the examples of areas that have been an interest
> for those engaged with the group and appear to have growing energy.
>
>
>
> From this we will then work with our AD on charter updates for the larger
> work items that deserve a notification to the IESG such that there is the
> potential for cross area/working-group touch points.  I will work with
> Spencer D. on this approach to see if it is workable from his point of view.
>
>
> Spencer S.
>
>
>
> *From:* nfsv4 [mailto:[e-mail]] *On Behalf Of *David Noveck
> *Sent:* Thursday, May 11, 2017 4:57 AM
> *To:* [e-mail]; [e-mail]
> *Cc:* Spencer Dawkins at IETF <[e-mail]>
> *Subject:* [nfsv4] New draft for working group charter
>
>
> The following is the second iteration of my attempt to provide a draft
> charter to be "whacked" (as Beepy put it) on the working group list so all
> comments are appreciated.  However, if someone would like to present an
> alternate draft, that's OK too.  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.
>
> This has the following changes from the initial draft.  If you object to
> any of these changes, let me know right away:
>
>    - Deletion of References to FedFS, per Chuck's comments.
>    - Inclusion of other ONC components in the *Maintenance *section, per
>    Chuck's comments.
>    - Deletion of the out-of-date sections* RFC5664bis* and *NFSv4.2.*
>    - Deletion (for now) of the section *NFSv4 Multi-Domain Access for
>    FedFS.*  Unlike the previously mentioned sections, this could come
>    back, probably in the form *NFSv4 Multi-Domain Access* if someone
>    (e.g. Andy) provides a draft charter section.
>    - Added a reference within the *Maintenance *section, to the ability
>    of technical updates to NFSv4 versions to include limited XDR changes.
>    - A start at a draft* Milestones* section (see below).  This is very
>    limited since most WG documents are past WGLC right now.  I've made some
>    reasonable assumptions regarding migration-issues.  When -13 is published,
>    the way forward in this area will 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.
>    - In order to help deal with our  limited set of current milestones,
>    I've followed Spencer's suggestion and adapted the material he cited from
>    the TCPM charter.
>
> Draft Charter for Working Group (Iteration Two)
>
> 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 make significant performance
> improvements.
>
> *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, 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 mapping types.  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. Siniilarly, associated ONC protocol components
> that have a versioning/extension  framework can be suitably extended to
> accommodate new security requirements, and to make significant performance
> improvements.
>
> *Performance Challenges*
>
> The increase of network bandwidths and the reduction of latencies
> associated with network traffic and access to persistent storage have
> created challenges for remote file access protocols which need to meet
> increasingly demanding performance expectations.  Some work already done in
> this area includes the respecification of RPC-over-RDMA Version One and the
> pNFS SCSI layout.  It is lexpected that further work in this area will be
> required.  This might take the form of further RPC-over-RDMA versions,
> adaptation of the SCSI layout to NVMe, or the development of an
> RDMA-oriented pNFS layout type.  The working group needs to discuss these
> alternatives, and possibly others, and develop the most promising ones.
>
> Milestones (Preliminary 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*
>
> Nov. 2017      Publication of RFC5666bis as a Proposed Standard
>
> Nov. 2017      Publication of a Proposed Standard describing bidirectional
> operation for RPC-over-RDMA
>
> Jan. 2018       Publication of RFC5667bis as a Proposed Standard.
>
> Feb. 2018       Publication of a Proposed Standard describing NFSv4
> versioning/extension framework.
>
> Feb. 2018       Publication of a Proposed Standard describing the umask
> extension to NFSv4.2.
>
> Feb. 2018       Publication of a Proposed Standard describing the xattr
> extension to NFSv4.2.
>
> March 2018    WGLC for draft-ietf-nfsv4-migration-issues (Informational)
>
>
>