File System Extended Attributes in NFSv4

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

Spencer Dawkins Yes

Comment (2017-05-12 for -05)
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

(Benoit Claise) No Objection

Comment (2017-05-24 for -05)
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)
I share EKRs concerns.

Mirja Kühlewind No Objection

Terry Manderson No Objection

Alexey Melnikov No Objection

Comment (2017-05-23 for -05)
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)
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)
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.