Re: [nfsv4] Opsdir last call review of draft-ietf-nfsv4-flex-files-15

Thomas, 

Thank you very much for the suggested changes, which helps me to understand the description. 

Linda

-----Original Message-----
From: Thomas Haynes [mailto:loghyr@primarydata.com] 
Sent: Thursday, January 04, 2018 3:48 PM
To: Linda Dunbar <linda.dunbar@huawei.com>
Cc: ops-dir@ietf.org; draft-ietf-nfsv4-flex-files.all@ietf.org; ietf@ietf.org; nfsv4@ietf.org
Subject: Re: [nfsv4] Opsdir last call review of draft-ietf-nfsv4-flex-files-15

Hi Linda,

Thanks for the review.

> On Jan 4, 2018, at 10:49 AM, Linda Dunbar <ldunbar@huawei.com> wrote:
> 
> Reviewer: Linda Dunbar
> Review result: Has Nits
> 
> I think the document is written very clear. Ready to move forward, 
> except some minor Nits. The document used "uids" and "gids" 
> extensively.  I assume that "uids" = "User IDs". How about "gids"? 
> does it mean "Group IDs"? it will be helpful to expand it at the first occurance in the document.

I can do that.

> In Section 2.2.2
> (Examples of using uids & gids) (Page 9), why saying "owner and group 
> are modified.."? what does the value "1066" or "1067" represent (as 
> the value "1697" represents the UID of the user "loghyr”)?

1697 is the file size.

However, I agree that the transition from:

   On the storage device, it may be assigned some random synthetic uid/
   gid to deny access:

   -rw-r-----    1 19452   28418    1697 Dec  4 11:31 data_ompha.c

to

   When the file is opened on a client, since the layout knows nothing
   about the user (and does not care), whether loghyr or garbo opens the
   file does not matter.  The owner and group are modified and those
   values are returned.

   -rw-r-----    1 1066    1067     1697 Dec  4 11:31 data_ompha.c

Does not make sense.

I’ve analyzed it and understand the point I was trying to make, but we’ve gone away from that intent.

I’m going to suggest replacing it with:

   On the storage device, it may be assigned some random synthetic uid/
   gid to deny access:

   -rw-r-----    1 19452   28418    1697 Dec  4 11:31 data_ompha.c

   When the file is opened on a client and accessed, it will try to get a
   layout for the data file. Since the layout knows nothing
   about the user (and does not care), whether the user loghyr or
   garbo opens the file does not matter.  The client has to present
   an uid of 19452 to get write permission. If it presents any other
   value for the uid, then it must give a gid of 28418 to get read
   access.

   Further, if the metadata server decides to fence the file, it may
   change the uid and gid as such:

   -rw-r-----    1 19453   28419    1697 Dec  4 11:31 data_ompha.c

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