File System Extended Attributes in NFSv4
RFC 8276

Note: This ballot was opened for revision 05 and is now closed.

(Spencer Dawkins) Yes

Comment (2017-05-12 for -05)
No email
send info
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.

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

(Benoît Claise) No Objection

Comment (2017-05-24 for -05)
No email
send info
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

Alissa Cooper No Objection

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2017-05-24 for -05)
No email
send info
I share EKRs concerns.

(Mirja Kühlewind) No Objection

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

Comment (2017-05-23 for -05)
No email
send info
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"

(Kathleen Moriarty) No Objection

Comment (2017-05-24 for -05)
No email
send info
I agree with the SecDir review about removing the nested references in the security considerations section.

    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.

(Eric Rescorla) (was Discuss, No Objection) No Objection

(Adam Roach) No Objection

Comment (2017-05-24 for -05)
No email
send info
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.


- 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.