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

[Spencer Dawkins at IETF <[e-mail]>]

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

> > 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.o
> rg/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.o
>> rg/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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>