Comments on draft-ietf-nfsv4-integrity-measurement-07

Feedback and comments on the draft “Integrity Measurement for Network File
System version 4” - draft-ietf-nfsv4-integrity-measurement-07.



Note that these comments are personal contribution and do not reflect my
position as working group co-chair.

In short, I am opposed to moving this draft to last call in its current
state.  Generally, the draft describes the Linux implementation of a
feature that is to be extended via NFS.  However, the description provided
is insufficient for interoperable implementations to be achieved.

There are two options, in my opinion, to moving this document forward:

1)  Limit the description to the addition of the new, opaque attribute and
corresponding errors that can be returned as a result of the interpretation
of that attribute.

2)  Fully define the contents of the new attribute such that independent
implementations can be achieved. This would include, but is not limited to,
the open definition of the content of the new attribute and the procedures
associated with defining new content and interpretation thereof.

If option 1) were chosen, I would still be of the opinion that the draft
should not move forward since it would present another barrier to open,
interoperable implementations.

Note that I am also doubtful of the use case being presented. Using NFS to
directly store and supply application executables seems to be in rapid
decline or has already fallen out of use.  Given the rise of virtualization
and the hosting of virtual disks on NFS along with the rise of containers
and distribution thereof, application distribution seems to be a thing of
the past with respect to their store/retrieval from NFS mounts.

If the effort was more focused on more traditional data integrity from
source to consumption, that would be a more interesting use case.  With the
rise of large scale data center usage of NFS (e.g. cloud computing) where
customers expect data integrity or the identification of failure, the scale
of cloud computing presents many opportunities for the loss of data
integrity and NFS (and the client and server implementations thereof) do
nothing to ensure data integrity.  The draft does mention spot fixes of
data-at-rest methods, and in-transit methods, but there are many points
that present areas of potential failure, and these are ignored in today’s
implementations (at least to this commenter's knowledge).


Spencer

_______________________________________________
nfsv4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nfsv4