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

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

Hi Chuck, I guess I don't understand this.

On 10/8/18, 3:50 PM, "nfsv4 on behalf of Chuck Lever" <[e-mail] on behalf of [e-mail]> wrote:

    >You're declaring that kind of interaction to be not well-defined.  Why?
    
    This is precisely because the file system plays no part in provenance
    assessment.
    
    If you want the server to do the assessment for all clients that access
    it, there's no need to expose FPI via NFS. A trust relationship must
    exist between the clients and server, of course,

And, because of the opaque nature of the specification, I have no reason to understand why this "of course" would have to be the case--or, for that matter, why the first sentence is true.  Intuitively, it's not obvious.  If there's a defect in my intuition, I believe that the document has done little to correct my defects.

    and there would need
    to be a strong guarantee that the network between the server and clients
    is of very high integrity. Perhaps the use of a GSS integrity service
    would be required in such a use case.

Why does this impose additional requirements on this OPTIONAL, but otherwise completely opaque, service?  What additional requirements does it levy?  Why wouldn't, for example, it be totally adequate to apply other techniques for recovering incompatibility?  For example, if the provenance information were to include, effectively, a checksum of the content, what is the range of meaningful actions available to the provenance assessor if the file object's checksum were not to match that in the provenance's checksum?

-----

My point in most of this is that one gives up a huge amount of understanding when the content semantics is completely opaque, as in this case.  Fine--it can be optional--but if it is present, what does it mean?  How should an implementation treat it?  What kind of implementation can someone write if they look only at the specification?

		Craig