Re: [nfsv4] Proposed Working Group Charter

["Black, David" <[e-mail]>]

Picking up on the mention of security here:

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

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:[e-mail]] On Behalf Of Spencer Dawkins at IETF
Sent: Tuesday, August 29, 2017 2:12 PM
To: spencer shepler <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [nfsv4] Proposed Working Group Charter

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.

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

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.

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.

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

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