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

[Bruce Fields <[e-mail]>]

On Thu, Sep 27, 2018 at 04:59:05PM +0000, Everhart, Craig wrote:
> Just to say: when there was the "8-bit-transparent" scheme around, it LOST to the UTF encoding.  Without knowing what the local character scheme was, it made no sense to claim interoperability with some other unspecified character encoding scheme.

Huh, I thought we'd gone the other way--RFC 3530 tried to mandate UTF-8
but that didn't really take.

But I don't know if there's any lesson there.

--b.

> 
> The analogy here is that you're either trying to reserve an "8-bit-clean" repository of opaque data, where a server doesn't know what it's storing and a separate client has no idea what it's seeing, or you're trying to reserve a particular slot for the sole use of some format that you don't describe.  In that second case, the analogy with file name data isn't so clear: NFS is built around having exactly one (component) file name, without a label explaining how to interpret that file name label.
> 
> But you're effectively asking for private use of the "file provenance" name space.  I hope there's never another community that also comes up with a "file provenance" description scheme.
> 
> 		Craig
> 
> 
> 
> On 9/27/18, 12:24 PM, "Chuck Lever" <[e-mail]> wrote:
>     
>     > 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
>     
>     
>     
>     
>