Subject: Re: [nfsv4] upcoming draft of RFC3530 errata

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 10 Mar 2005 11:05:47 -0500

On Mon, Feb 28, 2005 at 12:56:38AM -0800, Spencer Shepler wrote:
> 
> Over the next two weeks or so, I will be putting together errata
> for RFC3530.  I will be using the items that have either been
> sent to me directly or mentioned on the WG alias.  Please send
> me any items you know of and want to ensure make it into the errata.

Any guidelines on what is and isn't appropriate for the errata?
Examples of other RFC errata that we could look at?

--b.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Mike Eisler <[email-masked]>
Date: Thu, 10 Mar 2005 08:20:56 -0800

> -----Original Message-----
 > From: J. Bruce Fields [mailto:[email-masked]]
 > Sent: Thursday, March 10, 2005 8:06 AM
 > To: Spencer Shepler; [email-masked]
 > Subject: Re: [nfsv4] upcoming draft of RFC3530 errata
 >
 >

http://www.rfc-editor.org/cgi-bin/errata.pl

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 10 Mar 2005 11:45:20 -0500

Some things I've noted.  I'll leave it to Spencer to 
determine whether they fit the criteria:

The fact that the spec contradicts itself about ops that can
and can't return MOVED.  One place it says all except PUTFH and
GETATTR but the individual ops list MOVED for those and don't
list six others.  [This does modify the sense in that we would
like to change from a situation in which the spec contradicts
itself to one where it does not and you can't do that without 
changing the sense.]

The fact that the spec says you must return all atributes
requested or else an error occurs, but clearly expects that when
locations is requested you will not do that (not return all
atributes and not return an error).  [Same as above.]

The lack-of-clarity/confustion about the stateid for SETATTR,
in particular that you need it so that you can determine if 
another client is doing a SETATTR when you have a delegation.
[Seems more than a typo.  Whether it changes the sense of the
spec depends on what you think the sense of the spec is and 
the problem is that that isn't clear.]

The issue of whether for READDIR clients may return subsets of
the attributes requested without returning an error.  [Same as
above].

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 10 Mar 2005 11:55:51 -0500

I've noticed some errata in my errata (meta-errata) so 
I've just put the corrected version below.

The fact that the spec contradicts itself about ops that can
and can't return MOVED.  One place it says all except PUTFH and
GETATTR can but the individual ops list MOVED for those two and 
don't list six others.  [This does modify the sense in that we 
would like to change from a situation in which the spec contradicts
itself to one where it does not and you can't do that without 
changing the sense or lack thereof.]

The fact that the spec says you must return all atributes
requested for GETATTR or else an error occurs, but clearly 
expects that when locations is requested you will not do that 
(you will not return all attributes and not return an error).  
[Same as above.]

The lack-of-clarity/confustion about the stateid for SETATTR,
in particular that the client needs to sends it so that you 
can determine if another client is doing a SETATTR when you 
have a delegation. [Seems more than a typo.  Whether it changes 
the sense of the spec depends on what you think the sense of 
the spec is and the problem is that that isn't clear.]

The issue of whether for READDIR servers may return subsets of
the attributes requested without returning an error.  [Same as
above].

---

From: "Khan, Saadia" <[email-masked]>
Date: Thu, 10 Mar 2005 14:38:40 -0800

Does the errata include clarification on various features. In that case
some clarification on acls would be nice. For that to be done some
guidelines on what should be added to the errata as opposed to what
should be left upto implementations would also be nice.

Some issues that I think should be clarified:
1. What does it mean to set an acl with ace count of zero? Should it
even be allowed?
2. What do read and write named attribute permissions control?
3. Clarification on ACE4_NO_PROPAGATE_INHERIT_ACE. Currently it states
that:

      Can be placed on a directory.  Normally when a new directory is
      created and an ACE exists on the parent directory which is marked
      ACL4_DIRECTORY_INHERIT_ACE, two ACEs are placed on the new
      directory.  One for the directory itself and one which is an
      inheritable ACE for newly created directories.  This flag tells
      the server to not place an ACE on the newly created directory
      which is inheritable by subdirectories of the created directory.

In NT, if a dir has an inheritable ace for the
creator_owner/creator_group sid, only then when a subdir is created
within that dir, two aces are placed on that dir. One for the user who
created the subdir and the other one for the creator_owner. In case of
NFSv4, we don't have the concept of creator_owner/creator_group so I
don't think the above statement applies but it will be good to clarify
that.
4. If a file/dir is created in a dir that contains an inheritable acl,
and the create request comes in with a mode, how should the interaction
of mode and acl be? Is this something that is implementation dependent?
In any case, this should be clarified as well.
5. What does it mean to have delete_child and sticky bit set on a dir?
Which one takes precedence?
6. the delete/delete_child debate. Carl is already working on that
though.

I'm sure there are other issues which will come up but for now these
were the ones I could think of.

Saadia

> Sent: Thursday, March 10, 2005 8:56 AM
> To: [email-masked]
> and can't return MOVED.  One place it says all except PUTFH 
> and GETATTR can but the individual ops list MOVED for those two and 
> would like to change from a situation in which the spec 
> contradicts itself to one where it does not and you can't do 
> that without 
> The issue of whether for READDIR servers may return subsets 
> of the attributes requested without returning an error.  
> [Same as above].
> 
> and can't return MOVED.  One place it says all except PUTFH 
> and GETATTR but the individual ops list MOVED for those and 
> don't list six others.  [This does modify the sense in that 
> we would like to change from a situation in which the spec 
> contradicts itself to one where it does not and you can't do 
> that without 
> changing the sense.]
> 
> requested or else an error occurs, but clearly expects that 
> when locations is requested you will not do that (not return 
> all atributes and not return an error).  [Same as above.]
> 
> The issue of whether for READDIR clients may return subsets 
> of the attributes requested without returning an error.  
> [Same as above].
> 
> 
>  > On Mon, Feb 28, 2005 at 12:56:38AM -0800, Spencer Shepler 
> wrote:  > >  > > Over the next two weeks or so, I will be 
> putting together errata  > > for RFC3530.  I will be using 
> the items that have either been  > > sent to me directly or 
> mentioned on the WG alias.  Please send  > > me any items you 
> know of and want to ensure make it into the errata.  >  > Any 
> guidelines on what is and isn't appropriate for the errata?