Subject: Re: [nfsv4] Fw: New Version Notification for draft-naik-nfsv4-xattrs-00.txt

From: Manoj Naik <[email-masked]>
Date: Mon, 21 Jul 2014 12:15:24 -0700

Tom,

Responses inline based on the new draft we just submitted.

Manoj.

> From: "Haynes, Tom" <[email-masked]>
> To: Manoj Naik/Almaden/IBM@IBMUS, "[email-masked]" <[email-masked]>, 
> Date: 03/04/2014 03:58 PM
> Subject: Re: [nfsv4] Fw: New Version Notification for draft-naik-
> nfsv4-xattrs-00.txt
> Sent by: "nfsv4" <[email-masked]>
> 
> Hi Manoj,
> 
> Please find enclosed my review of your draft.

> 1) S1:
> 
> A lot of claims of wide spread use of xattrs with no citations.
> 
> 2) S1:
> 
> Use case seems to be that it exists, so lets put it on the wire.

I have added a few more use cases. While there are quite a few 
applications that use xattrs where the underlying file system supports 
them, I found it was near impossible to find public citations for them. If 
anybody has references that can be documented, I would be glad to include 
them. 

> 
> 3) S1:
> 
> What is the difference between xattrs and forks?

There is no explicit reference to the term "fork", which have varying 
implementations. Did you think we should bring out specific differences? 
The Solaris forks resemble the named attributes of NFSv4 closely, and the 
section on named attributes in the draft brings out the differences with 
xattrs. 

> 
> 4) S2:
> 
> Please call out in stronger terms why we do only want to allow
> user-managed metadata only to prevent the development of
> non-interoperable implementations. I would actually think that
> the reverse is true.
> 
> I.e., Labeled NFS object labels can be implemented as "security"
> xattrs. By having a well defined set of xattr names, it would
> promote interoperable implementations of seLinux.
> 
> I'd like to see called out that the non-interoperable implementations
> here means that the xattrs are only utilized by the client and not
> the server. I.e., I do not want the xattr implementation to become
> a backdoor to driving new functionality into someone's server.
> 
> And while that would appear to contradict my earlier statement
> about seLinux, the server would be enforcing the object label
> as it retrieved it from the sec_label attribute.
> 
> I'd also like to see how this can be enforced at the protocol level?

Paragraphs 2 and 3 of Section 3 expands on this a bit in the new draft. 
Neither the client nor the server can interpret xattrs - only the 
applications can manipulate them (and the backend file system store them). 
The draft leaves open the option of using specific names to represent 
well-defined xattrs (such as seLinux) in a future document. 

> 
> 5) S3
> 
>    Subsequently, xattrs presumably have size
>    limits ranging from a few bytes to several kilobytes, although this
>    is not universally defined.
> 
> Are you going to define a limit for NFSv4?
> 
> Are there limits on the size of the name?
> 
> Is the name going to ASCII or UTF-8?
> 
> Are there limits to the number of xattrs that can be associated with a 
fie system object?
> I.e., while a single xattr may be atomic, the collection of them may 
not.
> 
> I see you develop this a bit in S4, but the reasons for why there are
> limits should be discussed here.

Section 5.1.1 and 5.1.2 now covers this. There is no limit on the size or 
number of xattrs as long as the request to get/set them can fit in a 
single RPC. This is similar to what is implicitly accepted for other file 
attributes such as ACLs - NFS4ERR_REQ_TOO_BIG is used to indicate an 
error.

> 
> 6) S4
> 
>    A client may ask for any of these attributes to be returned by
>    setting a bit in the GETATTR request but MUST handle the case where
>    the server does not return them.  A client may ask for the set of
>    attributes the server supports and SHOULD NOT request attributes the
>    server does not support.
> 
> What is the server supposed to do if the client asks for xattrs and
> it does not support them?
> 
> Also, this is GETATTR, should it not be GETXATTR or whatever you are
> going to call it?

Fixed.

> 
> 7) S4
> 
> 4.2.1  Attribute 82: xattr_support
> 
>    TRUE, if the object's file system supports extended attributes.
> 
> 4.2.2  Attribute 83: maxxattrsize
> 
>    Maximum size in bytes of all the extended attributes per object that
>    the object's file system supports.
> 
> Do we need both? If maxxattrsize == 0, it indicates that there is no 
support
> for extended attributes.
> 
> If we need both, what is the defined reaction to these value(s) 
(including
> xattrsize) being 0?

Fixed - xattr_support removed. 

> 
> 8) S4.2.2
> 
> Are there any requirements that the xattr operations be atomic with any
> other operations inside the same compound?

No, in fact there is no requirement that setting multiple xattrs in the 
same SETXATTR is atomic either. See Section 5.2.4.3.

> 
> 9) S4.2.4
> 
>    Although the client can
>    get and set xattrs, the server is responsible for using the xattrs
>    for its own purposes.
> 
> Again, I'd argue that the server cannot use the xattrs.

Yes, fixed.

> 
> 10) S4.2.4
> 
>    For SETATTR operation, if the
>    associated xattrvalue4 has a length of zero, the corresponding xattr
>    is to be deleted, if it exists.
> 
> Where was xattrvalue4 defined?
> 
> Wait, I see it after this. You might want to define that data structure 
first.

Fixed.

> 
> 11) S4.2.4
> 
>    Specific names of attributes will not
>    be controlled by this document or other IETF Standards Track
>    documents.
> 
> Perhaps we can limit this to the "user" namespace and leave the
> decision of other name spaces to later documents.

Fixed.

> 
> 12) S4.2.4
> 
>         The NFS xattr structure is defined as follows:
> 
>         typedef utf8str_cis   xattrname4;
>         typedef opaque                xattrvalue4<>;
> 
>         struct xattr4 {
>                 xattrname4     xa_name;
>                 xattrvalue4    xa_value;
>         };
> 
> Do maxxattrsize and xattrsize apply to just the xa_value or to 
combination
> of xa_value and xa_name?

Combination, now mentioned in Section 5.2.1.

> 
> 13) S4.2.5
> 
> How is the name space encoded inside the xattrname4?

As stated earlier, this draft does not impose restrictions on the xattr 
name - encoding namespace or defining specific names is left for a future 
document.

> 
> 14) S4.2.5
> 
>    The xattrnames is similar to xattrs attribute, except that it only
>    returns the names of the xattrs for the file system object without
>    the values. Each xattr is a tuple of the form (name, value).
>    xattrname4 is a UTF-8 string denoting the xattr name, xattrvalue4 is
>    a variable length string that identifies the values of a specified
>    xattr. The NFS client or server must not interpret the value.
> 
> The last two sentences belong before this section. I.e., both
> xattrname4 and xattrvalue4 are also applicable to S4.2.4.

No longer required with the new operations.

> 
> 15) S4.3
> 
> xattrnames is basically a directory read. Do you need an ACE4 to control 
that?

The two ACE access mask attributes control permissions to 
GETXATTR/SETXATTR in the new draft.

> 
> 16) Normative references are [RFC5661] and informative ones are [1].
> 
> Please make consistent.
> 
> Also, [KEYWORDS] should be [RFC2119].

Fixed.

> 
> 17) Overall
> 
> If xattrs are allowed to be run on the server, how do they interact with 
pNFS?
> 
> Is the interpretation only to be on the MDS? Or do the DSes have an 
impact?

Added a section on pNFS considerations.

> 
> How do xattrs interact with seLinux? I.e., once we get this in NFSv4.x, 
can
> the object label specify what subject labels are authorized to 
read/write/list the xattrs?

This draft does not limit on specify the names (or namespace) for xattrs. 
Perhaps in a future document.

> 
> Finally, based on my experience with Labeled NFS, it might be better for 
you
> to split off the requirements and the implementation. There were much 
better
> use cases for Labeled NFS, but it still dragged on until we got the 
requirements
> gathered in a new document.

We see GETXATTR/SETXATTR as a fairly small extension to the protocol (in 
the same vein as READ_PLUS/WRITE_PLUS), that having requirements in a 
separate document may not have enough content and be warranted. The 
prevalence of xattr support in file systems is well-established, and 
despite the absence of a standard, their definition and operations are 
fairly consistent across platforms. Section 5.2 captures the requirements 
through the new operations. 

> 
> Tom
> 
> From: Manoj Naik <[email-masked]>
> Date: Friday, February 7, 2014 at 8:38 AM
> To: "[email-masked]" <[email-masked]>
> Subject: [nfsv4] Fw: New Version Notification for draft-naik-nfsv4-
> xattrs-00.txt
> 
> I have just submitted a draft proposal to support extended 
> attributes in NFS. We've tried to include most of the views 
> expressed on the mailing list in the past on this topic, and hoping 
> the discussion can continue here, at Connectathon and at London. 
> 
> This first draft extends the existing attribute bitmap to include 
> xattrs. This is easier to define and implement, but does not allow 
> some operations like reading or writing individual xattrs.
> 
> Other options mentioned (but not detailed) are:
> - define new operations - such as GETXATTR and SETXATTR - solely for
> xattrs. Cleaner, but has some consistency issues with GETATTR/SETATTR 
> with respect to attribute caching semantics.
> - define new operations - such as GETATTR_PLUS and SETATTR_PLUS 
> (similar to extensions to READ/WRITE proposed for 4.2) - that 
> support all the features of GETATTR/SETATTR, but include extensions 
> to fully support xattrs.
> 
> Please provide feedback.
> 
> Manoj Naik 
> IBM Almaden 
> 
> 
> [email-masked] wrote on 02/07/2014 12:16:01 AM:
> 
> > From: [email-masked] 
> > To: [email-masked], [email-masked] 
> > Date: 02/07/2014 12:16 AM 
> > Subject: New Version Notification for draft-naik-nfsv4-xattrs-00.txt
> > 
> > 
> > A new version of I-D, draft-naik-nfsv4-xattrs-00.txt
> > has been successfully submitted by Manoj Naik and posted to the
> > IETF repository.
> > 
> > Name:      draft-naik-nfsv4-xattrs
> > Revision:   00
> > Title:      Support for File System Extended Attributes in NFSv4
> > Document date:   2014-02-06
> > Group:      Individual Submission
> > Pages:      10
> > URL:            http://www.ietf.org/internet-drafts/draft-naik-
> > nfsv4-xattrs-00.txt
> > Status:         
https://datatracker.ietf.org/doc/draft-naik-nfsv4-xattrs/
> > Htmlized:       http://tools.ietf.org/html/draft-naik-nfsv4-xattrs-00
> > 
> > 
> > Abstract:
> >    This document proposes extensions to existing NFSv4 operations to
> >    allow file extended attributes (here forth also referred to as
> >    xattrs) to be manipulated in the protocol. An xattr is a file 
system
> >    feature that allows opaque metadata, not interpreted by the file
> >    system, to be associated with files and directories and are 
supported
> >    by many modern file systems. New file attributes are proposed to
> >    allow clients to query the server for xattr support, and get and 
set
> >    xattrs on file system objects.
> > 
> > 
> >  
> > 
> > 
> > Please note that it may take a couple of minutes from the time of 
submission
> > until the htmlized version and diff are available at tools.ietf.org.
> > 
> > The IETF Secretariat
> > [attachment "draft-naik-nfsv4-xattrs-00.txt" deleted by Marc 
> Eshel/Almaden/IBM] _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4