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

[Chuck Lever <[e-mail]>]

> On Sep 27, 2018, at 9:09 AM, Everhart, Craig <[e-mail]> wrote:
> 
> 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?

Good point. I can add language that fills that in. In fact
that will be a copy-and-paste from an earlier version of
this document.


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

Yes, that's what we want to do. This is exactly the same
as storing opaque file data. NFS is conveying and storing
data on behalf of an application which is responsible for
interpreting that data.


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

--
Chuck Lever