Subject: [nfsv4] Proposed Working Group Charter

From: David Noveck <[email-masked]>
Date: Mon, 28 Aug 2017 10:04:08 -0400

The attached file is based on what was presented at IETF99.  It includes
some
minor tweaks that were suggested at the meeting or soon therafter.

Added to that was material on proposed milestones which was presented to the
working group for its review on 8/17.  It now appears that the consolidated
proposal
is ready for presentation to the IESG.

Because there have been some difficulties with the archiving of
powerpoints, I want to
make sure that any further such difficulties will not prevent access to the
substance of this
proposal.  In order to provide another path of access, an ascii-ized
representation is to be
found below.

========================================================================

NFSv4wg Charter

Final Proposal

Including Proposed Milestones

David Noveck

August 28, 2017

1. Proposed Charter Text

1.1.  General Section

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, and NFSv4.2 protocols
and specifications of related ONC components, such as those defining RPC,
XDR, and RPCSECGSS.

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 respond to technological developments in the areas of
networking and persistent storage/memory.

1.2 Maintenance Section

The working group has found that, as NFSv4 implementations mature and
deployments continue, clarifications and corrections to existing RFCs
are needed.

These specification updates help vendors in delivering high-quality and
interoperable implementations.

The working group is chartered with the vetting of reported issues and
determining correctness of submitted errata.

The working group is also responsible for approving changes to RPC- and
NFS-related IANA registries

In addition, some areas may need more concentrated work to correct the
specifications already published, to deal with unanticipated interactions
between features, or to respond to evolving IESG expectations with regard
to areas such as security.

Since necessary changes in such cases are generally not appropriate for
the errata system, the working group will assist in publication of RFCs
that provide implementation guidance and of RFCs that provide editorial
modification or technical updates to original RFCs.

Since the new NFSv4 versioning framework is in effect, such technical
updates to NFSv4 minor versions could include limited XDR changes.

1.3 Extension Section

The NFSv4 protocol is designed to allow extension by the definition of
new operations, new attributes, and new pNFS layout types, as well as
the creation of minor versions.

Similarly, associated ONC protocol components that have a versioning/
extension framework can be incrementally extended, when necessary.

The working group will discuss proposals for such extensions and assure
that 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.

Some likely motivations for such extensions would be to:

Maximize NFS performance on advanced network fabrics.

Accommodate new storage technologies.

Provide facilities useful in management of NFS-accessed storage in

large-scale virtualization environments.

Provide more effective NFS response to security challenges.

2. Proposed Milestones

Because the previous charter was at variance with the work the group
was actually doing, the list of pending milestones that can determined
now is somewhat limited.

To accommodate this situation and in light of the fact that maintenance
activities are inherently unpredictable, new milestones that fall within
the scope specified within the charter can be added to the list of
milestones below after working group consensus upon acceptance and
approval by the responsible Area Director

========================================================================
|   Date  |                Milestone                                   |
|---------+------------------------------------------------------------|
| 3/2018  | WGLC for description of use of NVMe in accessing a pNFS    |
|         | SCSI Layout                                                |
| 6/2018  | WGLC for draft-ietf-nfsv4-migration-issues (Informational) |
| 8/2018  | WGLC for document describing NFSv4.0 trunking discovery    |
| 10/2018 | WGLC for document describing NFSv4.1 trunking discovery    |
| 10/2018 | WGLC for document describing Transparent State Migration   |
|         | in NFSv4.1                                                 |
|---------+------------------------------------------------------------|
| 1Q2019  | WGLC for description of CM private data convention         |
|         | (Informational)                                            |
| 1Q2019  | WGLC for pNFS RDMA Layout                                  |
| 3Q2019  | WGLC for RPC-over-RDMA Version 2                           |
========================================================================

---

From: spencer shepler <[email-masked]>
Date: Mon, 28 Aug 2017 08:34:17 -0700

Thanks, Dave.  The charter update does look ready to go.  Will leave it to
Spencer D. on next steps and his feedback.

Spencer S.

On Mon, Aug 28, 2017 at 7:04 AM, David Noveck <[email-masked]> wrote:

> working group for its review on 8/17.  It now appears that the
> consolidated proposal
> make sure that any further such difficulties will not prevent access to
> the substance of this

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 28 Aug 2017 17:32:23 -0500

Hi, Spencer (S),

On Mon, Aug 28, 2017 at 10:34 AM, spencer shepler <[email-masked]
> wrote:

> Spencer D. on next steps and his feedback.

This looks mostly ready to go, to me. I have two questions.

Any objection if I significantly reduce the paragraphs at the beginning of
the Milestones section? I'd be happier if we didn't remind the IESG that
NFSv4 has been working outside the charter and is now rechartering to
reflect the current situation.

So, my understanding is that NFSv4 wants a revised charter to match the
current work efforts already underway, but doesn't need to add additional
milestones now, is that right?

Spencer (D)

---

From: David Noveck <[email-masked]>
Date: Mon, 28 Aug 2017 19:18:04 -0400

> Any objection if I significantly reduce the paragraphs at the beginning
of the Milestones section? I'd be happier if we didn't remind the IESG that
NFSv4 has been working outside the charter and is now rechartering to
reflect the current situation.

No objection.

Yes, but we do need the option to add small milestones without another
rechartering.  In other other words, while there is no problem withr
reducing those paragraphs, there would  be a problem if they were reduced
into non-existence.

On Mon, Aug 28, 2017 at 6:32 PM, Spencer Dawkins at IETF <
[email-masked]> wrote:

> Hi, Spencer (S),
>
> On Mon, Aug 28, 2017 at 10:34 AM, spencer shepler <
> [email-masked]> wrote:
>
>>
>> Thanks, Dave.  The charter update does look ready to go.  Will leave it
>> to Spencer D. on next steps and his feedback.
>>
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 29 Aug 2017 07:55:15 -0500

Hi, David,

> reducing those paragraphs, there would  be a problem if they were reduced

Right. I'm thinking what's needed is just the very end:

"new milestones that fall within
the scope specified within the charter can be added to the list of
milestones below after working group consensus upon acceptance and
approval by the responsible Area Director"

I don't KNOW that this is necessary, because I think that's the way
charters work (you had consensus from the IETF for the *charter*, so adding
milestones for work that falls within the charter is up to the working
group and the AD who are actually doing the work), but you folks have way
more experience at discussions within NFSv4 about adding milestones than I
do, so I defer to your experience, and don't have any objection to the
charter making that explicit if you folks think it's helpful.

Spencer (D)

---

From: David Noveck <[email-masked]>
Date: Tue, 29 Aug 2017 10:34:16 -0400

I don't recalll any discussion about adding milestones outside the context
of a new charter, but it might be that I was simply not involved in those
discussions (or it could be that I simply don't remember).   The chairs
might have some yseful observations..

In recent times, we have added a bunch of new work tems without adding
milestones corresponding to them.  I'm not sure exactly why milestones were
not added but it could have been any of the following:

   - There was no need to do so, since the IESG was not bothering us about
   a lack of milestones.
   - Given that a lot of our new work items were outside the current
   charter, there was an understandable reluctance draw attention to that fact.
   - The chairs or AD's were not clear about a procedure to add milestones
   outside of a charter revision.

I was always under the impression that new milestones did generally require
a charter revision.  Because of that, I was quite pleased when Spencer S.
found language similar to what we proposed in the TCPM charter.  Given our
needs (which were greater at the time since we only had one prospctive
milestone), it seemed just the thing we needed.  Over time, I added a bunch
of elaboration which you decided to remove.  At the time this text was
added, I assumed that Spencer S. also felt that without that text we would
have not been able to easily add milestones, but you should verify with him.

In any case, I accept that it might not be necessary.  However, given that
there is no indication that it is harmful, we might as well leave it in.

---

From: spencer shepler <[email-masked]>
Date: Tue, 29 Aug 2017 09:32:17 -0700

I think with the affirmation from Spencer D. that if the charter covers the
work that milestone updates are not considered a recharter but more of a
clerical update to make timeline/work clear to align with the WG I-Ds that
are taken on.

In the end, I don't have a strong opinion either way.

Spencer

On Tue, Aug 29, 2017 at 7:34 AM, David Noveck <[email-masked]> wrote:

>    - There was no need to do so, since the IESG was not bothering us
>    about a lack of milestones.
>    - The chairs or AD's were not clear about a procedure to add
>    milestones outside of a charter revision.
>
> I was always under the impression that new milestones did generally
> require a charter revision.  Because of that, I was quite pleased when
> Spencer S. found language similar to what we proposed in the TCPM charter.
> Given our needs (which were greater at the time since we only had one
> prospctive milestone), it seemed just the thing we needed.  Over time, I
> added a bunch of elaboration which you decided to remove.  At the time this
> text was added, I assumed that Spencer S. also felt that without that text
> we would have not been able to easily add milestones, but you should verify
> with him.
>
>>> > Any objection if I significantly reduce the paragraphs at the
>>> beginning of the Milestones section? I'd be happier if we didn't remind the
>>> IESG that NFSv4 has been working outside the charter and is now
>>> rechartering to reflect the current situation.
>>>
>>> No objection.
>>>
>>> > So, my understanding is that NFSv4 wants a revised charter to match
>>> the current work efforts already underway, but doesn't need to add
>>> additional milestones now, is that right?
>>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 29 Aug 2017 13:12:24 -0500

Dear NFSv4 Chairs and working group participants,

This is what I've got in the datatracker as version 05-00 of the charter.

It is intended to be what David proposed in this thread, with some
abbreviation expansions and paraphrasing. I did leave the part about adding
milestones for deliverables within charter, and we'll see if other ADs
think that should change.

Please let me know how this looks, and I'll start Internal Review.

Thanks,

Spencer

Network File System version 4 (NFSv4) is the IETF standard for file
sharing.

To maintain NFS Version 4's utility and currency, the NFSv4 working group is
chartered to maintain the existing NFSv4.0, NFSv4.1, and NFSv4.2 protocols
and specifications of related ONC components, such as those defining RPC,
XDR, and RPCSECGSS.

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 respond to technological developments in the areas of
networking and persistent storage/memory.

Maintenance

The working group's experience has been that, as NFSv4 implementations
mature
and deployments continue, clarifications and corrections to existing RFCs
are needed.

The NFSv4 working group is chartered with vetting reported issues and
determining correctness of submitted errata.

The working group is also responsible for approving changes to RPC- and
NFS-related IANA registries.

In addition, some areas may need more concentrated work to correct the
specifications already published, to deal with unanticipated interactions
between features, or to respond to evolving IESG expectations with regard
to areas such as security. Since necessary changes in such cases are
generally not appropriate for the errata system, the working group will
assist in publication of new RFCs that provide implementation guidance,
editorial modification or technical updates to existing RFCs.

Since the new NFSv4 versioning framework has been approved, these technical
updates to NFSv4 minor versions could include limited XDR changes.

Extensions

The NFSv4 protocol is designed to allow extension by the definition of
new operations, new attributes, and new Parallel NFS layout types, as well
as
the creation of minor versions.

New milestones that fall within the scope specified in this charter can
be added to the list below after working group consensus and upon
approval by the responsible Area Director.

Proposed Milestones

---

From: spencer shepler <[email-masked]>
Date: Tue, 29 Aug 2017 11:37:32 -0700

Reviewed and this looks good to me, Spencer D.

Spencer S.

---

From: David Noveck <[email-masked]>
Date: Tue, 29 Aug 2017 15:50:22 -0400

Lokks fine to me as well.

On Tue, Aug 29, 2017 at 2:37 PM, spencer shepler <[email-masked]>
wrote:

>> new operations, new attributes, and new Parallel NFS layout types, as
>> well as

---

From: "Black, David" <[email-masked]>
Date: Tue, 29 Aug 2017 22:00:43 +0000

> editorial modification or technical updates to existing RFCs.

After what I said at the mic in Prague about security work, I checked with the Security ADs, with Spencer D. being part of that discussion.

The upshot is roughly that the Security ADs would:

a)      welcome and encourage work on an RFC that updates the general NFSv4 security considerations; and

b)      be open to an approach of specifying different security requirements for controlled/managed environments, e.g., data centers, vs. usage on the public Internet.

Of course the ADs will want to see the detailed security requirements and differences between controlled/managed environments vs. public Internet usage before signing off on anything.   See as GRE/UDP(RFC 8086) for an example of this approach (two sets of requirements) in a different domain.

I don’t have the time to write this draft by myself, but could help if others are interested.

Thanks, --David

From: nfsv4 [mailto:[email-masked]] On Behalf Of Spencer Dawkins at IETF
Sent: Tuesday, August 29, 2017 2:12 PM
To: spencer shepler <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [nfsv4] Proposed Working Group Charter

It is intended to be what David proposed in this thread, with some abbreviation expansions and paraphrasing. I did leave the part about adding milestones for deliverables within charter, and we'll see if other ADs think that should change.

Thanks,

Spencer

Maintenance

The working group's experience has been that, as NFSv4 implementations mature
and deployments continue, clarifications and corrections to existing RFCs
are needed.

Extensions

The NFSv4 protocol is designed to allow extension by the definition of
new operations, new attributes, and new Parallel NFS layout types, as well as
the creation of minor versions.

Proposed Milestones