Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-01.txt

["Everhart, Craig" <[e-mail]>]

This exact issue needs to be discussed in the draft--whether it makes sense for clients/servers that don't a-priori recognize the "file provenance" information to reject the communication, and how.  Should non-recognizing servers store the information blind?  Or should they reject such files?

Essentially, the draft seems to imply that there's a well-understood way that some community of file handlers has of describing file provenance.  Instead of explaining what that is, the author(s) of the draft simply want to standardize a way of describing data that is otherwise opaque.  The draft gives no information on how to construct an appropriate file-provenance blob of bits, to my reading, or to explain what a formatted blob of bits would mean.

Let's say that there are multiple communities that all are composed of people that understand some formatting scheme.  How should they interact?  How would I (a file server) take a blob from community A and present it in a way that community B would understand?  Or is this formatting scheme to remain opaque forever?

We had an analogous tussle many years ago with the "8-bit-transparent" file name stuff.  One community wanted NFS to simply save file names in their full 8-bit form, without interpretation.  That's fine as long as everybody who sees a given name knows how to interpret it.  (This was in the days before UTF-8 or its analogues; we had a lot of localized character sets that people wanted to use verbatim.)  Thank heavens that we no longer have that particular fight.  But this draft feels analogous: it apparently wants NFS to store and retrieve "provenance" blobs without altering them, saying that they have meaningful semantics, but without explaining what those semantics are.

		Craig Everhart



On 9/27/18, 11:32 AM, "nfsv4 on behalf of Chuck Lever" <[e-mail] on behalf of [e-mail]> wrote:

    The consequences of not recognizing the file provenance information
    are not dire. In those cases, clients simply don't allow access to
    the file's content, and the implementations are free to report to
    the administrator that the FPI format is not recognized.
    
    Would it help to state that in the draft?