Subject: [nfsv4] Review of stefanha-nfav4-rpc-over-vsock-00 (part one of three)

From: David Noveck <[email-masked]>
Date: Fri, 15 Dec 2017 15:30:50 -0500

*Review Structure*

This is the first part of a three-part review, split up into multiple
messages to avoid running into message size limits for the working group
mailing list.

The three parts are as follows:

   1. Contains *Review Structure*, *Introduction*, and *General Comments.*
   2. Contains *Comments by Section (Abstract through Section 3)*
   3. Contains *Comments by Section (Section 4 through end)*

*Introduction*

This series of messages was written to review Stefan's draft,
*draft-stefanha-nfsv4-rpc-over-vsock*, which consisted mainly of material
needed to register new VSOCK-related Network Identifiers and the associated
Universal Address Format.  The comments related to how the document
addressed that function are all located in the *Comments by Section* sections
in parts two and three of this three-part review.  That function will need
to be addressed in some document presumably, although not necessarily, an
RFC (See *Need for Clarity Regarding Rules for Netid/uaddr Assignments*).
I'm assuming that document will be based on Stefan's document and these
comments will be useful to him in that connection, once decisions are made
on the future path for this feature.

As work proceded on this review, I came to the conclusion that addressing
the registration of these items is only a small part of the necessary work,
because issues related to using this new transport type in the context  of
NFSv4 are not as simple as they would be in the case of NFSv3, for
example.  A significant portion of the NFSv4 protocol is based in the
assumption that the client has access to a hostname which it might use as
the basis for an RPCSEC_GSS service name and for translation to a network
address by use of DNS or other means.  As a result, there will have to be a
decision about whether to address these issues in a separate document or in
an expansion of the existing document.  See *Uncertainty Regarding Role of
this Document* for a discussion of these issues and a list of decisions to
be made.  This section is basically directed to the working group as a
whole although I expect Stefan to be concerned with this issue,
particularly if he chooses to expand the current document or have a role in
writing an NFSv4-specfic document.

Given the imprtance of this fuction (hypervisor-guest communication) and
the range of possible solutions, it might make sense for the working group
to approach this issue as a problem to be anlyzed and solved, rather than
basing its consideration on the assumption that VSOCK solves this problem
and the need is solely for documentation and ratification of an existing
solution.  Note that possible soluions include those that use NFSv4 over
VSOCK, those that use VSOCK as a configuraition mechanism to enable IP-bsed
commnication to be used by NFSV4, and those that do not VSOCK at all,  One
possible approach might be to analyze the issues and possible solutions in
an Informtional document along the lines that were done for transparent
state migration and trunking in *draft-ietf-nfsv4-migration-issues.*

*General Comments*

*Uncertainty Regarding Role of this Document*

One difficuly in reviewing this document is that it is quite unclear what
the role of this draft  is.  Many internet-drafts are intended to be steps
along the way to an eventual RFC, either Standards-track or Informational.
Often the Proposed Status in the xml governs this choice although this has
been known to change as documents develop.  Often the text of the document
makes clear the eventual goal.

Here we have a special set of circumstances to deal with which make it hard
to determine the intent:

   - Any choice one makes is inconsistent with some part of the existing
   draft.  For example, the specfication of standards-action assigment
(see *10.1.
   Netids for AF_VSOCK* and *10.2. Uaddr Format for AF_VSOCK*) is
   inconsistent with anything except an eventual standards-track RFC. On the
   other hand, there are other sections where the current treatment seems
   to indicate to me that an Informational status is intended. For example,
   .*2. Status of AF_VSOCK* seems to describe an existing implementation
   and des not deal with matters that the IETF might standardize, while *9.
   Security Considerations* describes a current limited implementtion which
   is at variance with the REQUIREMENTS in RFC5661.
   - Intentions regarding the treatment of NFSv4.1 are not clear.  A
   decision needs to be made whether this document is to deal with the RFC
   layer alone or with the consequences of this addition for NFSv4 as well.
   If the former is chosen, the treatment would have to be extended to
deal with
   the consequences of this addition for the many aspects of the NFSv4
   specfication and implementations that are built around the idea that host
   names and/or IP addresses are always present.  (e.g. fs_locations,
   RPCSEC_GSS).  In any case, those issue need to be adressed somewhere.
   - It is possible that, if FCFS assigments were to be made, an RFC would
   not be necessary in otder to effect the assigment of id's. In that case,
   this document would serve as a draft for the document defining the
   requested netids and uaddr formats and never become an RFC. However, it is
   not clear if that is possible in this case. See *Need for Clarity
   Regarding Rules for Netid/uaddr Assignments* for further discussion.
   However, in any case, there would be a need for a separate document dealing
   with NFSv4-related issues if this approch is taken.

It appears that some decisions need to be made.  I expect that the first
few of these need to be made fairly soon.

   - Whether to use a single document to address both levels or to switch
   to a two-document model, with separate documents dealing with RPC-level and
   NFSv4-related issues.
   - If the two-document model is chosen, it might be possible to do the
   RPC-level doument without an RFC, and put the majorty of work into the
   NFSv4-related document.
   - If the two-document model is chosen  and there will be two RFCs, a
   decision needs to be made to pursue these with only a one-way depenency of
   the NFSv4 document on the RPC-level or essentially as a cluster.  Choosing
   the former approach would allow early non-prototype use of NFSv3, for
   example.  Another possibility would be to use VSOCK-based RPC between guest
   and hypervisor to provide initial configuration services, allowing early
   use of essentially unmodified NFSv4 for this use case.
   - In either case, decisions would have to be made about whether each of
   the RFCs to be done would be standards-track or Informational.  It is
   generally best if each of these decisions is made before the corresponing
   RFC-candidate document becomes a working group item.

*Need for Clarity Regarding Rules for Netid/uaddr Assignments*

It appears that netids and uaddr formats may be registered on either an
FCFS or a standards action basis.  Unfortunately, there is no information
as to why one might choose one or the other.  Clearly the former is less
work, so there should be some reason to choose the latter.  Unfortunately,
it is unclear what the consequences of choosing the FCFS approach are,
particularly as they affect existng standards-track protocols.

The working group needs to understand this issue better.  I'll try to drive
a discussion to enable us to have better information about this issue.
I've reached out to Mike Eisler, the author of RFC5665, to see if he can
provide any relevant background.

*Lack of a Clear Motivation for this Work*

As discussed below in *4.  Intended Use* and *Potential New Section Dealing
with Motivation*, more infornation is needed regarding the motivation for
this work, particularly as it affects NFSv4. Apart from the need to include
this information in specific documents, it would help the working group to
have this information as it consider the appropiate path forward to address
the general problem of the provision of NFSv4 services to guests by
hypervisors.