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

[David Noveck <[e-mail]>]

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

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

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:

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

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.

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

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

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

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

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

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

>
> 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 <[e-mail]> wrote:
>
>> > For the extension and performance items, I believe they are too broad
>> for 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.
>>
>> > Performance especially difficult because the range of work items can be
>> very broad and there may not be consensus with respect to approach, etc. --
>>
>> 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.
>>
>> > the pre-discussion of proposed extensions or changes can capture that
>> performance is the use case and then build towards specific proposals.
>>
>>
>> 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 <
>> [e-mail]> wrote:
>>
>>>
>>> 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 <[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.
>>>>
>>>> *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
>>>>
>>>> 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
>>>>>
>>>>>
>>>>
>>>
>>
>