Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
Since xattrs are application data, security issues are exactly the same as those relating to the storing of file data and named attributes. These are all various sorts of application data and the fact that the means of reference is slightly different in each case should not be considered security-relevant. As such, the additions to the NFS protocol for supporting extended attributes do not alter the security considerations of the NFSv4.2 protocol [RFC7862]. This seems inadequate. The issue is that if machine A writes some extended attribute which is security relevant (i.e., this file is only readable under certain conditions) and then machine B doesn't know about the attribute, then you have a security problem on B because it will not enforce it. It seems like FreeBSD uses extended attributes for this purpose, so this isn't just theoretical.
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.