Re: [nfsv4] WG Charter update - email discussion, close at IETF99

[David Noveck <[e-mail]>]

> IMO the maintenance and extension sections should also mention
> ONC RPC (and RPCSEC GSS) explicitly. A new version of RPCSEC
> was recently ratified, and RPC can be extended in the future
> to operate on new types of transport layers.

Good point.


> > Performance Challenges

> /layout/layout type

> Is work on respecifying RPC-over-RDMA Version One considered
> maintenance or performance?

I consider it both and I don't think it is a problem.  Performance is the
motivation while each of the performance items fits under one of the
mechanisms, either being maintenance or extension

> My impression from Dallas was
> this was maintenance of existing specifications.

Under the old charter, there was no performance category.

It fit under maintenance at Dallas since:

   - Very few people people had read the charter and so most did not
   understand how constrained the concept of maintenance there was.
   - At the time we embarked on this, we didn't realize that substantive
   technical changes were required., and thought of this (wrongly) as purely a
   matter of editorial correction. For example the bi-direction work, while
   clearly necessary, did not fit in the existing charter.


> Where does Andy's multi-path work fit?

> Does it need explicit mention in the WG charter?

I'll leave that question to Andy.  From a motivation point of view, this is
performance-related.

As far as mechanism, Andy has mentioned the possibility of an additional
attribute with connection bandwidth/capability information, which would be
a v4.2 extension.

Other work would probably fit in the maintenance category.  When
migration-issue-13 is out, we can talk about plans to follow up.   I'd like
20 minutes at IETF-99 for the working group to discuss this.

> Does the WG want to continue pursuing FedFS, if only in
> maintenance mode?

This is something the working group will have to decide, but if there is
nobody to do the work, it doesn't matter what the WG decides.

> Is Andy's multi-domain work able to continue if FedFS is removed from the
docket?

I think it can.  IIRC his document was not limited to FedFS but treated it
as one likely use.

As far as I am concerned, the man question is whether Andy wants to
continue this work.  I certainly think it is useful

On Tue, May 9, 2017 at 11:10 AM, Chuck Lever <[e-mail]> wrote:

>
> > On May 8, 2017, at 9:31 PM, David Noveck <[e-mail]> wrote:
> >
> > Spencer wrote:
> > > Hi.  It is time that we update our charter
> >
> > Yes we need to update the charter.
> >
> > > to determine what is next for the working group.
> >
> > I don't see us making a big decision like that in Prague.
> >
> > I expect us to continue the kind of work we have been doing, with
> > the charter updated to include it
> >
> > > Beepy said that he would take that on so I am nudging him in email.
> >
> > He nudged back.  It appears you guys have two different conceptions
> > of what "take that on" means and I'm not prepared to referee.
> >
> > > In the mean time, please comment here on suggested charter items.
> >
> > I'm sure we'll do that
> >
> > Beepy wrote:
> >
> > > Let's whack it on email
> >
> > I've tried to begin the whacking process below.  Comments and alternate
> proposed drafts are welcome.
> >
> > > and then put on agenda for fine tuning at Prague.
> >
> > We can  discuss this in Prague, if we have time., but we are not going
> to come up with a final text in a half-hour or even two hours.
> >
> > I think the goal for the Prague discussion has to be confirmation of an
> agreement on an outline previously agreed upon and a time line for
> submission of the new charter.   After that it is up to you and the
> Spencers to make it happen.
> >
> > Draft Charter for Working Group (Ready for further whacking)
> > 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, Federated Namespace, and
> related specifications. 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.  Finally, deployment guidance will be collected
> for deployments of the NFSv4 FedFS implementations and their interaction
> with integration with new user authentication models.
> >
> > 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 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.
> >
> > 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.
>
> IMO the maintenance and extension sections should also mention
> ONC RPC (and RPCSEC GSS) explicitly. A new version of RPCSEC
> was recently ratified, and RPC can be extended in the future
> to operate on new types of transport layers.
>
>
> > 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 likely 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.  The working group needs to discuss these
> alternatives, and possibly others, and develop the most promising ones.
>
> /layout/layout type
>
> Is work on respecifying RPC-over-RDMA Version One considered
> maintenance or performance? My impression from Dallas was
> this was maintenance of existing specifications.
>
> Where does Andy's multi-path work fit? Does it need explicit
> mention in the WG charter?
>
>
> > RFC5664bis
> >
> > Propose that this be terminated with extreme prejudice
> >
> > NFSv4.2
> >
> > This is already done so it might as well be whacked.
> >
> > NFSv4 Multi-Domain Access for FedFS
> >
> > A lot has happened in this area but there is probably work still to be
> done.  My suggestion is that Andy propose a replacement section, if
> necessary
>
> Last week I allowed two long-standing personal I-Ds related to
> FedFS to expire because there have been no deployments. There
> is a single known implementation (Linux), which is unfinished
> partly because the Linux filesystem community is not interested
> in making junctions a first-class filesystem object, and because
> the use of LDAP in FedFS makes it difficult to implement and
> awkward to deploy.
>
> We are considering removing FedFS support from new versions of
> Red Hat-based Linux (Fedora, CentOS, and RHEL).
>
> Does the WG want to continue pursuing FedFS, if only in
> maintenance mode? Is Andy's multi-domain work able to continue
> if FedFS is removed from the docket?
>
>
> > On Mon, May 8, 2017 at 7:11 PM, Brian Pawlowski <[e-mail]>
> wrote:
> > Nudge, nudge. Wink, wink.
> >
> > Here is the current charter:
> >
> > https://datatracker.ietf.org/wg/nfsv4/charter/
> >
> > Let's whack it on email and then put on agenda for fine tuning at Prague.
> >
> > Our AD will weigh in on what is appropriate. Last time we did this I
> believe we focused on things actively being worked on (staffed) with some
> agreement rather than creating new work items that had not been yet
> discussed.
> >
> > beepy
> >
> > On May 8, 2017, at 12:30 PM, spencer shepler <[e-mail]>
> wrote:
> >
> >
> > Hi.  It is time that we update our charter to determine what is next for
> the working group.
> >
> > Beepy said that he would take that on so I am nudging him in email.
> >
> > In the mean time, please comment here on suggested charter items.
> >
> > Spencer
> >
> > _______________________________________________
> > nfsv4 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/nfsv4
> >
> > _______________________________________________
> > nfsv4 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/nfsv4
> >
> >
> > _______________________________________________
> > nfsv4 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/nfsv4
>
> --
> Chuck Lever
>
>
>
>