Allowing Inheritable NFSv4 Access Control Entries to Override the Umask
RFC 8275
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
Warren Kumari No Objection
I agree with Alexey - an example would be helpful. As someone who has run into this issue (and differences in behavior!), this is a useful document. Nits: Abstract: "In many important environments, inheritable NFSv4 ACLs can be rendered ineffective by the application of the per-process umask." s/important// 1: (personal peeve) - every environment is important to someone... 2: this makes it sound like inheritable ACLs would NOT be ineffective if the environment is not important :-) Sec 2. Problem Statement "As a result, inherited ACEs describing".... First use of ACE, please expand / reference.
(Spencer Dawkins; former steering group member) Yes
(Adam Roach; former steering group member) No Objection
Please expand "ACL" and "ACE" on first use and in the title. Section 5 uses an all-caps "RECOMMENDATION," which is confusable with (but not) an RFC2119 term. If this is intended to be invoke RFC2119 terminology, please rephrase with "RECOMMENDED" or "SHOULD." If not, please remove the capitalization or change to a synonym that is less confusable with "RECOMMENDED."
(Alexey Melnikov; former steering group member) No Objection
Without being "fluent" in NFSv4, it would be nice to have an example how this fit into larger picture. E.g. by showing a file create request.
(Alia Atlas; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Ben Campbell; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
Editorial:
Page 2: As a result, inherited ACEs describing
Suggest expanding the “ACE” or adding a reference since the term first appeared.
(Deborah Brungard; former steering group member) No Objection
(Eric Rescorla; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
Not sure I understand the reason in section 3 why this document does not update RFC7862. But I guess both (updating or not updating) is fine.
(Suresh Krishnan; former steering group member) No Objection