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

[Bruce Fields <[e-mail]>]

Just to be clear, I don't claim to know what's best, I'm just want to
make sure I understand the decisions here:

On Thu, Sep 27, 2018 at 08:31:58AM -0700, Chuck Lever wrote:
> On Sep 26, 2018, at 6:12 PM, Bruce Fields <[e-mail]> wrote:
> > OK, but you do have to know how all the other clients are formatting the
> > information.  I don't quite understand what's meant by ensuring
> > interoperability, then.
> > 
> > I guess I expected to see something like say a 32-bit "type" field with
> > implementations able to register different "type" values so you could at
> > least tell whether it should bother trying to parse a given file
> > provenance field.
> 
> I don't think it's helpful to insert the WG and IANA in the
> process of deciding the type of information in the FPI payload,
> especially when the structure of that payload is out of the WG's
> hands.

What would be the problem with, for example, documenting what IMA
currently does?

> Either the clients look at a 32-bit enum value, or they look at
> the payload and figure out what it is. I can't see how it makes
> any operational difference.

If the client tries to parse it without knowing which implementation
created it, and it turns out it was created by someone else, I guess the
verification will normally fail and maybe that's what you want.

It's not impossible that it could get misparse it and succeed, though.
Maybe there's no realistic situation where that has practical
consequences, I don't know.

> > Maybe it's not necessary.  I wonder what would would happen in practice.
> > I geuss if people deployed two different clients that both claimed
> > support for file provenance, they might be surprised when they started
> > randomly throwing errors when one client tries to read files written by
> > another.
> 
> Typically, an NFS server serves a fleet of clients that have a
> common administrator who provisions and configures these clients
> to recognize the same FPI payload.
> 
> 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?

Maybe so.

--b.