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

[David Noveck <[e-mail]>]

> IMO FedFS is truly
> moribund (and I'd bet there are others on the WG who knew
> this years ago), thus looking forward, perhaps the charter
> should not mention FedFS.

You've convinced me.  The next draft version I send out will drop FedFS.

When I did the initial draft I left things out only if I was certain they
should be gone, but
now, with your feedback,  I will try to remove things based on my best
understanding
of the situation.

People are still free to object but I hope that people who have an issue
with this will
not wait until Prague to raise objections.


> I wasn't sure, but I thought this work was complete with the
> publication of RFC 8000. I'm thinking part of our review should
> determine what else might be needed.

I'm not sure about this since the existing charter mentions a number of
possible
documents. I'm still waiting to hear from Andy about this section but
if he tells us there is no there there, we don't need a review although
anyone
would still be free to propose something in this area.


On Tue, May 9, 2017 at 2:51 PM, Chuck Lever <[e-mail]> wrote:

>
> > On May 9, 2017, at 12:49 PM, David Noveck <[e-mail]> wrote:
> >
> > > 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.
>
> Fair enough. I'm not volunteering.
>
> The question is whether it is worth a mention in the charter
> as part of the WG's maintenance mission. IMO FedFS is truly
> moribund (and I'd bet there are others on the WG who knew
> this years ago), thus looking forward, perhaps the charter
> should not mention FedFS.
>
>
> > > 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
>
> I wasn't sure, but I thought this work was complete with the
> publication of RFC 8000. I'm thinking part of our review should
> determine what else might be needed.
>
>
> --
> Chuck Lever
>
>
>
>