Re: [nfsv4] Adoption call for draft-dnoveck-rfc5661bis

[Chuck Lever III <[e-mail]>]

On Oct 13, 2022, at 4:57 PM, David Noveck <[e-mail]<mailto:[e-mail]>> wrote:

This is an adoption call for draft-dnoveck-nfsv4 which is intended to be a standards-track describing nfsv4.1, obsoleting rfc8881.

As it says in the abstract,

-----

This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC7530) and protocol extensions made subsequently.  The later minor version has no dependencies on NFS version 4 minor version 0, and was , until recently, documented as a completely separate protocol.

This document is part of a set of documents which collectively obsolete RFC 8881.  In addition to many corrections and clarification, it will rely on NFSv4-wide documents to substantially revise the treatment of protocol extension, internationalization, and security, superseding the description of those aspects of the protocol appearing in RFCs 5661 and 8881.

-----

The chairs would like to determine whether there is interest in adopting this document by the nfsv4 working group. The adoption call will run for two weeks and end on 10/26/2022 (UTC time). Please send any objections or expressions of support for adoption to the wg mailing list.

As stated previously, since I am editor of this document, I will not be involved in making a judgment as to the existence of consensus.  It is expected that Brian will be doing this with Zahed available as a backup if circumstances do not allow Brian to do this job.

I've examined rfc5661bis in order to address the question of whether it is ready for WG adoption.

Both the document and the diff are huge (for any reasonable definitions of "huge").

Sections 1.2 and 1.3 should be relocated to the Appendix to keep such material together and to help reduce churn in the document's chapter and section numbering (resulting in cleaner diffs now as work progresses, and once these sections are removed before publication).

Throughout:

  *   The terms "TLS-based encryption" and "transport-level encryption" need to be replaced with "transport-layer confidentiality". Let's adopt the terminology used by the rest of the community.
  *   RPCSEC GSS already provides client peer authentication. The use of TLS peer authentication is not novel. The principles introduced and used in this discussion need to be generic, because surely RPC-with-TLS will not be the final word in transport-layer security.

Security will also be described in a separate document applying to
all minor versions.  The handling is different because there is a
wider range of security-relevant features within v4.1, despite the
fact that the fundamental approach is the same for all minor
versions.  As a result, for some features, the security document
will have the lead role while, for others, the v4.1 specification
will be the main source of information about the feature, although
the basic security functionality will be as defined by the
NFSv4-wide security document.

I question whether separation of the security discussion in this way is truly beneficial to readers. Scattering the discussion like this will make it easy to miss important information.

The section defining the GSS service principal (common to all minor versions of NFSv4) should be moved to the security document.

Section 6 is problematic. I suspect the intention was Section 6 through 6.3 are meant to be part of Section 5, and Section 6.3.1 "Put Filehandle Operations" is supposed to start a new chapter. Sections 6 through 6.3 belong in the security document, IMO, not in RFC 5661bis.

Section 16.9 "Security Considerations for pNFS" belongs in the nfsv4-wide security document. The only minor version this section does not apply to is NFSv4.0. The caveat about the discussion covering non-RPC storage protocols is not pertinent, IMO; general security considerations should be the same for all layout types. Likewise, Section 17.12 "Security Considerations for the File Layout Type".

Section 19.1.11.3.  "NFS4ERR_BAD_HIGH_SLOT (Error Code 10077)" First sentence was changed to a sentence fragment that does not match the form/style of other error descriptions.
Section 19.1.16.4.  "NFS4ERR_RESOURCE (Error Code 10018)" What is the need for re-adding the RESOURCE status code?

Section 22.29.  "Operation 33: SECINFO - Obtain Available Security" I don't agree with moving the mechanical description of this operation along with its arguments and results to the nfsv4-security document. This appears to be the only operation that has been changed in this way even though there are other security-related operations in common amongst all NFSv4 minor versions.

Section 1.2.2 says:

This shift is necessary because the description of SECINFO needs
to be revised to allow negotiation of security-related transport
characteristics in addition to auth-flavors, associated mechanisms
and RPCSEC_GSS services.

No one has yet agreed to address negotiation this way; in fact, there have been active objections to it.

Further, it says:

Significant work has been done to provide rpc-tls-based state
protection which can be taken advantage even by clients who have
not implemented SP4_MACH_CRED or SP4_SSV or who are using
AUTH_SYS.



The Section 5.5.3 has been revised to allow, when SP4_NONE is
used, to allow client host authentication to be used for state
protection.

Although this work might not introduce new protocol elements, the implications of getting this feature wrong are significant. I strongly urge that this change be postponed to a future document so that prototypes can be created and adequately tested.

The document editor has attempted to address every known problem in this update. However there are so many issues to be dealt with that the resulting tumult of document changes are difficult to assess individually. This has led to a seemingly limitless increase in the scope of changes in the bis with no opportunities for WG oversight until now. The first revision of rfc5661bis was submitted only a week or two ago, and a request for adoption followed after just a few days without any time for WG contributors to review and absorb this update. This in my opinion is an abuse of process.

In particular, we need mechanisms to attribute provenance to each text change (eg, who requested the change and why, who wrote the replacement), a way to set off text changes (change bars or a commit log), and a less unwieldy way to compare the bis document to its base document; rfcdiff by itself is easily confused by changes in sections generated automatically, and is wholly unable to deal with document splits. Technical details aside, when this work is finally adopted, there needs to be much greater transparency.

I am philosophically in favor of updating NFSv4 specifications and systematically addressing their known flaws. However, because of the short time frame during which this document has been actually available for review, the lack of tools to accurately assess the documents in question, and the amount of work remaining (both in terms of adding unfinished material and editing out unnecessary, controversial, or deferrable changes), I am not enthusiastic about WG adoption at this time.

I would prefer to see more progress on this document as a personal draft while the WG attempts to address process transparency issues. I do not believe there is any impediment to progress in the absence of WG adoption.


--
Chuck Lever