Hi Linda, Thanks for the review. > On Jan 4, 2018, at 10:49 AM, Linda Dunbar <ldunbar@xxxxxxxxxx> 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/nfsv4 >