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

[David Noveck <[e-mail]>]

On Fri, Oct 21, 2022, 11:24 AM Chuck Lever III <[e-mail]>
wrote:

>
>
> On Oct 13, 2022, at 4:57 PM,⁰ David Noveck <[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).
>

OK.  I can do that.


> 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.
>
>
I don't  agree.  After all, rfc9289, uses "encryption" and not
"confidentiality".  I presume this is because encryption is clearer and is
in fact how  confidentiality is provided.


>    - RPCSEC GSS already provides client peer authentication.
>
> Does it?  As I understood things, it provided client *principal* authentication.
If it did, there would be no need for the special ops defined in v4.1 to
provide state protection.

>
>    - The use of TLS peer authentication is not novel.
>
>
It is now.


>    - 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.
>
>
Do you have any specifics on what you'd like to see?  I agree with being
compatible with future development but we cannot be so generic that
implementors are not clear what to do.



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

We have to trade off document hugeness and decided, with good reason, to
divide things this way.  I  don't think it makes sense to shift things now


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

Will look at addressing.

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

Will look at addressing.


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

The general principles/requirements are the same.  However, the
implementation considerations and potential threats are definitely
different.

Likewise, Section 17.12 "Security Considerations for the File Layout Type".
>

Will look at that.


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

Will fix that up.

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

OK


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

I'm not sure about that.  The last I heard from you I'd that the response
was "tepid".  Am prepared to respond to working group consensus on this, as
judged by Brian.


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

So are those of getting it right.  Am prepared to move this issue to a
separate document if the wg wants.

I strongly urge that this change be postponed to a future document so that
> prototypes can be created and adequately tested.
>

Noted.


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

Nevertheless, they have to be addressed individually since it makes sense
to address them collectively.

Regardless of any worries about "tumult", you and other members of the
working group need to discuss these issues, if we are to make progress

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
>

*Not true.  *-00 was submitted 12/2020 and there has been ample opportunity
for review and discussion.

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

Your opinion is clearly misguided.  Please review the facts.


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

I don't agree that we need all this new mechanism.  What is needed is
discussion of the consensus issues listed in Appendix B.  If people are
unwilling to do that without major process work than rfc5661bis is going to
be delayed for a number of years.

Technical details aside, when this work is finally adopted, there needs to
> be much greater transparency.
>

It would be desirable  but it is not necessary and so should not delay the
work.


> I am philosophically in favor of updating NFSv4 specifications and
> systematically addressing their known flaws.
>

Perhaps so but this philosophically commitment needs to be complemented but
concrete help to move the document forward.

> However, because of the short time frame during which this document has
been actually available for review.

Not so.  See above.

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

That's putting it mildly


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

The only impediments are ones you propose.  I hope the working group will
help improve this document without extensive, potentially unrealizable,
process modifications.

>
>
> --
> Chuck Lever
>
>
>
>