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

From: spencer shepler <[email-masked]>
Date: Mon, 8 May 2017 15:30:02 -0700

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

---

From: Brian Pawlowski <[email-masked]>
Date: Mon, 8 May 2017 13:11:04 -1000

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 <[email-masked]>
wrote:

Spencer

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: David Noveck <[email-masked]>
Date: Mon, 8 May 2017 21:31:13 -0400

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.

*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.

*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

---

From: Chuck Lever <[email-masked]>
Date: Tue, 9 May 2017 11:10:23 -0400

> On May 8, 2017, at 9:31 PM, David Noveck <[email-masked]> wrote:
> 
> Spencer wrote:
> I've tried to begin the whacking process below.  Comments and alternate proposed drafts are welcome.
> 
> 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.
> 
> 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
> NFSv4.2
> 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 <[email-masked]> wrote:
> 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 <[email-masked]> wrote:
> 
> 
> Hi.  It is time that we update our charter to determine what is next for the working group.
> 

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Tue, 9 May 2017 12:49:47 -0400

> to operate on new types of transport layers.

Good point.

> 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

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.

> 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 <[email-masked]> wrote:

> > 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.
> >
> 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
> >

---

From: Chuck Lever <[email-masked]>
Date: Tue, 9 May 2017 14:51:54 -0400

> On May 9, 2017, at 12:49 PM, David Noveck <[email-masked]> wrote:
> 
> 	• 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.  
> 
> 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.  
> 
> 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

---

From: David Noveck <[email-masked]>
Date: Tue, 9 May 2017 16:06:32 -0400

> IMO FedFS is truly

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.

> 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 <[email-masked]> wrote:

> >       • Very few people people had read the charter and so most did not
> >       • 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.
> >

---

From: spencer shepler <[email-masked]>
Date: Tue, 9 May 2017 13:18:09 -0700

For the extension and performance items, I believe they are too broad for
the WG charter.

For the charter, outside of maintenance items (bis and other related work),
it would be best to have work items that are better defined.  If that
definition doesn't exist, then the WG can be a place that the ideas can be
refined through personal drafts and when ready the WG can work with the AD
for a charter update, etc.

Performance especially difficult because the range of work items can be
very broad and there may not be consensus with respect to approach, etc. --
the pre-discussion of proposed extensions or changes can capture that
performance is the use case and then build towards specific proposals.

Spencer

On Mon, May 8, 2017 at 6:31 PM, David Noveck <[email-masked]> wrote:

> practices RFCs or of RFCs that provide editorial modification or
> technical updates to original RFCs.
>
> *Extension*
>

---

From: David Noveck <[email-masked]>
Date: Tue, 9 May 2017 17:11:12 -0400

the WG charter.

Obviously I disagree.   Note that my charter draft was intended to
encompass the work that the working group has been doing over the last few
years even if it is out of scope according to the existing charter.

> For the charter, outside of maintenance items (bis and other related
work), it would be best to have work items that are better defined.

True, but we are where we are.   There were some things that were quite
well-defined but did not work out so well (e.g. fedFS), and some important
needs that we have to address even though the specific means by which they
will be met is not yet certain.  That is what the process of discussion is
for.

> If that definition doesn't exist, then the WG can be a place that the
ideas can be refined through personal drafts

That has been happening.  versioning, umask and xattrs were defined in
personal drafts and then were adopted as working group items, the fact that
they were outside our charter notwithstanding.  I think it would be better
to have a charter that includes the things we have been doing and expect to
do.

> and when ready the WG can work with the AD for a charter update, etc.

It sounds like you are proposing a further delay in updating the charter.
This is already over a year overdue.  I think it is well accepted that we
need a new charter and I will continue, with others' help, to work on
that.  If you have a counter-proposal, we can discuss it in Prague and try
to come to some agreement.

It can be and there might not be consensus, but, as my charter draft
suggests, deciding the most promising avenues to develop is something that
needs to be done.  We may fail in doing that but if we put this work
outside of the working group's charter we guarantee failure, and he
consequence will be irrelevance for NFSv4.

I think we have specific proposals motivated by performance issues.  For
example, draft-cel-nfsv4-rpcrdma-version-two is a specific proposal which
the working group might reasonably adopt at some point.  But that
discussion needs to happen but we should not foreclose the result by
placing this document outside the working group charter.

The work on NVMe and RDMA-based layouts is not as far along but I expect
Christoph will have proposals to make to the working group at IETF-99.
Even if we just have slideware in July, there will be a basis for an
initial discussion about the best way forward.   That discussion is an
important part of the working group's work and the charter should make
provision for it.

On Tue, May 9, 2017 at 4:18 PM, spencer shepler <[email-masked]>
wrote:

> For the charter, outside of maintenance items (bis and other related
> work), it would be best to have work items that are better defined.  If
> that definition doesn't exist, then the WG can be a place that the ideas
> can be refined through personal drafts and when ready the WG can work with
> the AD for a charter update, etc.
>

---

From: spencer shepler <[email-masked]>
Date: Tue, 9 May 2017 14:29:15 -0700

David,

I would suggest we look to the TCPM WG charter as a model for what is done
with the NFSV4 WG charter update.  See
https://datatracker.ietf.org/wg/tcpm/about/

We also need direction from Spencer D. as our area director for general
guidance on what he and the broader IESG would like to see for a group that
has existed for 20 years.

While you believe otherwise, my suggestions are not meant to impede
progress of desired work items.  What I am suggesting is that we be clear
to ourselves that the protocols and working group are generally in
maintenance mode.  Yes, there are new features and additions that are
desired and that work can fall into the charter.  For example, the TCPM
charter uses this language:

"* The WG mostly focuses on maintenance issues (e.g., bug fixes) and
modest changes to the protocol, algorithms, and interfaces that
maintain TCP's utility.

* The WG is a venue for moving current TCP specifications along the
standards track (as community energy is available for such efforts)."

I believe this captures the behavior that the NFSv4 WG has had for some
time (albeit some of the work items have been slightly larger but with the
versioning I-Ds this should be less the case as intended).

Finally in the TCPM charter is the following:

"New TCPM milestones that fall within the scope specified within the
charter can be added after consensus on acceptance in the working
group and approval by the responsible Area Director."

This seems reasonable.  This way we don't have to recharter completely to
add milestones but we are communicating timeline and work with the
involvement of the AD.  We don't surprise our AD and if they have questions
about charter scope there is an opportunity to express it earlier than
later.

Spencer

On Tue, May 9, 2017 at 2:11 PM, David Noveck <[email-masked]> wrote:

> > For the extension and performance items, I believe they are too broad
> for the WG charter.
>
> On Tue, May 9, 2017 at 4:18 PM, spencer shepler <[email-masked]
> > wrote:
>
>>

---

From: David Noveck <[email-masked]>
Date: Tue, 9 May 2017 21:10:53 -0400

> I would suggest we look to the TCPM WG charter as a model for what is
done with the NFSV4 WG charter update. > See https://datatracker.ietf.
org/wg/tcpm/about/

Each working group is different and I would prefer a charter based on what
we have been doing and what we expect to do in the near future.  That's
what I tried to do in my draft.

I would like to hear Spencer D's views on the charter.  I think the best
way to do that is to give him a draft to comment on, or two if you prefer.

> While you believe otherwise, my suggestions are not meant to impede
progress
> of desired work items.

I don't understand the motivations for your suggestions, or why you think
that you
know what I believe.

Although I have heard suggestions that you are deliberately impeding
progress, I've
never believed them.  If you wanted to impede progress you would have a
very constraining
charter and you would enforce it strictly.  Yet we have published RFCs 7931
and 8K
and still there is no Evil Spencer saying "outside the charter" :-).

> What I am suggesting is that we be clear to ourselves that the protocols
and
> working group are generally in maintenance mode.

I agree with that, but the issue is the type and scope of that maintenance.

> Yes, there are new features and additions that are desired and that work
can fall
> into the charter.

Exactly so.  That is what I tried to describe in the extension section  of
my draft.  IIRC,
you objected to that and  did not offer a replacement.  If you have a
suggested replacement,
we can consider it.

> For example, the TCPM charter uses this language:

> modest changes to the protocol, algorithms, and interfaces that

While this is closer to what have been doing than the current charter in
that it is not limited to editorial changes, it is not a good fit because
of the differences in what the groups do. TCP specifies detailed
implementation algorithms including those for congestion control discussed
in a part of the charter you don't quote.  We don't do that, for good
reason and we have to deal with changing file system semantics such as we
did with the xattrs work.  Whether it is "modest" or not is a matter of
opinion, but there is nothing in TCP  with which it is analogous.

> standards track (as community energy is available for such efforts)."

I don't see how this relates to our group.

> versioning I-Ds this should be less the case as intended).

I think my draft did it better, which is no surprise since I was describing
our group rather than the TCPM group.

Again, if you think I'm wrong, propose an update to my draft or your own
draft for our WG. Let the working group and Spencer D comment.

Perhaps I'm immodest, but while RFC7931 and versioning work were
maintenance, I don't consider either of them 'modest" changes.  Creating a
new extension model was a significant change even though the goal was a
more suitable approach to maintenance.  RFC 7931 moved v4.0 from a protocol
to which trunking was an alien concept to one in which it was an integral
part of the protocol.  The motivation was to fix a problem but it marked a
major advnce for NFSv4.0.  It was a good thing the Evil Spencer was not
paying attention :-).

> group and approval by the responsible Area Director."

I wouldn't have a problem adding something like this to the next iteration,
although personally I'd prefer to just ignore the whole milestone thing as
we have been doing these last few years.

> This seems reasonable.

It is reasonable if the AD is reasonable.  That's the case now but it has
not always been so.

> This way we don't have to recharter completely to add milestones but we
are communicating timeline and work with > the involvement of the AD.  We
don't surprise our AD and if they have questions  about charter scope there
is an     > opportunity to express it earlier than later.

I can live with it.

On Tue, May 9, 2017 at 5:29 PM, spencer shepler <[email-masked]>
wrote:

> with the NFSV4 WG charter update.  See https://datatracker.ietf.
> org/wg/tcpm/about/
>
>> It sounds like you are proposing a further delay in updating the
>> charter.  This is already over a year overdue.  I think it is well accepted
>> that we need a new charter and I will continue, with others' help, to work
>> on that.  If you have a counter-proposal, we can discuss it in Prague and
>> try to come to some agreement.
>>
>> example, draft-cel-nfsv4-rpcrdma-version-two is a specific proposal
>> which the working group might reasonably adopt at some point.  But that
>> On Tue, May 9, 2017 at 4:18 PM, spencer shepler <
>> [email-masked]> wrote:
>>
>>>
>>>> The NFSv4 protocol is designed to allow extension by the addition of
>>>> new operations or new attributes, the creation of minor versions, and the

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 25 May 2017 10:05:22 -0400

So, three things ...

Giving me a draft charter that you folks can live with (or even two draft
charters that you can live with) is a good plan.

For the record, I consider you folks one of my better working groups - you
produce clear and clean drafts that tend to solve real problems and get
deployed.

Please remember that "Evil Spencer" is now an anycast address :p

Thanks,

Spencer (D)

On Tue, May 9, 2017 at 9:10 PM, David Noveck <[email-masked]> wrote:

> done with the NFSV4 WG charter update. > See https://datatracker.ietf.o
> rg/wg/tcpm/about/
>
> charter and you would enforce it strictly.  Yet we have published RFCs
> 7931 and 8K
> I think my draft did it better, which is no surprise since I was
> describing our group rather than the TCPM group.
>
> I wouldn't have a problem adding something like this to the next
> iteration, although personally I'd prefer to just ignore the whole
> milestone thing as we have been doing these last few years.
>
> > This seems reasonable.
>
> On Tue, May 9, 2017 at 5:29 PM, spencer shepler <[email-masked]
> > wrote:
>
>>
>> David,
>>
>> done with the NFSV4 WG charter update.  See https://datatracker.ietf.o
>> rg/wg/tcpm/about/
>>
>>> > Performance especially difficult because the range of work items can
>>> be very broad and there may not be consensus with respect to approach, etc.
>>> --
>>>
>>>>> 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
>>>>> On Mon, May 8, 2017 at 7:11 PM, Brian Pawlowski <[email-masked]
>>>>> > wrote:
>>>>>