Note: This ballot was opened for revision 05 and is now closed.
For the ADs - this draft is still in Last Call (ends 2017-05-16). I'm creating the ballot now, because it's easier to juggle the three NFSv4 drafts on the 2017-05-25 telechat agenda if you read -versioning first, and then read -xattrs and -umask together.
Jürgen Schönwälder, in his OPS DIR review flagged the same comment as Alexey: I was a bit surprised to see that numeric values for NFSv4 protocol extensions etc appear to be somewhat magically managed (section 8.6) instead of using IANA but this likely has its own history and reasons.
I share EKRs concerns.
Comment is Section 8.6 made me wonder: is there an IANA registry of all NFS extensions? Having a single place would avoid problems of conflicting allocations. Nit: "xattrs" is sometimes mistyped as "xatrrs"
I agree with the SecDir review about removing the nested references in the security considerations section. https://www.ietf.org/mail-archive/web/secdir/current/msg07386.html The security considerations section does exist and states that file attribute extensions adds no new concerns than that of file data and named attributes. It defers to the security considerations of application data in NFSv4.2 (RFC 7862), which refers to NFSv4.1 (RFC 5661). 5661 discusses possible MITM and down-grade attacks and how to mitigate them with RPCSEC_GSS (integrity or privacy services). I agree with this assertion, though I'd rather have the draft reference 5661 directly or RFC 7530. And support EKR's discuss.
My understanding of draft-ietf-nfsv4-versioning is that extensions are tightly bound to precisely one minor version of NFS, and become part of the mandatory-to-understand (but not necessarily implement) XDR for the next minor version. Based on this, I would expect any extension based on the new scheme defined by draft-ietf-nfsv4-versioning to be exceeding clear about which minor version they apply to (e.g., in the abstract, introduction, and/or title -- ideally all three). I can infer that this extension applies to 4.2 based on the timing of its publication request and a few sidelong mentions of 4.2 in the text, but I think this really needs to be more prominent. Editorial: - The code which is extracted from this document contains a copyright date of 2012. Is that intentional? - The "RFCTBD10" string in the code block in section 7.1 is highly likely to be overlooked by the RFC production center in its final production steps. I would recommend a note (either inline or as an RFC editor note to accompany the document) that explicitly calls out a need to replace this string. - Please expand the acronym "ACE" on first use.