Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf-nfsv4-flex-files-15: (with DISCUSS and COMMENT)

> On Jan 24, 2018, at 1:48 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> Eric Rescorla has entered the following ballot position for
> draft-ietf-nfsv4-flex-files-15: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-flex-files/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I concur with Kathleen's discuss. To put a finer point on it, I think the
> security considerations section here needs to really clearly state what the
> security properties of this design are and how they differ from existing NFS.
> That's not true yes.

Could you please clarify the last sentence?

That’s not true yet.

Or:

That’s not true, yes?

If yet, then hopefully pushing the next version will suffice.

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> - I'm a bit confused on whether the client can tell which model the server is using. I see:
> 
>   An implementation can always be deployed as a loosely coupled model.
>   There is however no way for a storage device to indicate over a NFS
>   protocol that it can definitively participate in a tightly coupled
>   model:
> 
> But then there is a flag that you use to indicate you are tightly coupled. So I'm confused.
> 

Ah, the flag ffdv_tightly_coupled is used between the metadata server
and the client. Not between the storage device and the metadata server.

> 
> - I note that some of your PDUs have /// in front and some do not. E.g., Section 5. Is that a bug.
> 

No, the ones with a /// are to be extracted and the other ones refer to existing fragments
from other IDs. So for example, the one in Section 5 is referring to RFC5662.

> - S 2.2.
> " Note: it is recommended to implement common access control methods at"
> 
> Do you want RECOMMENDED.

Yes, this was pointed out by Brian Weis in the SecDir review.

> 
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4