Re: [nfsv4] Possibility of adding additional REQUIRED attributes

[Jeff Layton <[e-mail]>]

On Tue, 2024-03-26 at 16:02 +0000, Thomas Haynes wrote:
> 
> 
> 
> > On Mar 25, 2024, at 10:00 AM, David Noveck <[e-mail]> wrote:
> > 
> > 
> > IIRC, at an earlier interim(?) meeting you raised the issue of the possible addition of other attributes to the set ofREQUIRED attributes.   As I am now updating rfc5661bis to reflect the attribute categorization changes made in other documents including toe regarding mode, owner and owner_group, I'd like to follow up on this issue soon,  if that is possible. 
> > Since I am looking to finalize a full reworking of attribute categorization to appear in -03, I'd like to close out this discussion with regard to the rfc5661bis effort, if it still has relevance to that effort.  To make progress on this, I would need a list of attributes that you believe need to be made REQUIRED as part of rfc5661bis. Right now, I don't anticipating any, although in rewriting the general description ofOPTIONAL (formerly "RECOMMENDED") attributes, I am trying to provide a more balanced discussion, getting rid of the text which stressed the difficulty (for servers) of implementing attributes and underplayed the issues for the client in doing without attributes typically expected.  I'm also explicitly mentioning the need for OPTIONAL attributes in connection with OPTIONAL features.
> > 
> > Although I don't know of any attributes that need to be made REQUIRED in the context of fc5661bis, I feel that there are a number of attributes that need to be considered for promotion in  NFSv4.3, now that it is in the process of graduating from the snide remark stage to the initial discussion stage.  These would include the ones you alluded to, the attributes brought over from NFSv3, but I would also like us to include a substantial subset  of the per-fsOPTIONAL attributes.  Some examples:
> > 
> >  * fs_charset is very easy for the server to implement and making it REQUIRED avoid the added complexity for the client of dealing with the case of this attribute not being supported.
> >  * aclsupport raises similar issues even if it is associated with an OPTIONALfeature.  This is similar to other attributes which provide gateways to OPTIONALfeatures, with very simple implementations possible when the OPTIONAL feature is not supported..
> >  * fs_layout_type could be made REQUIRED with servers not supporting pNFS simply returning a zero-length array.
> > Please update me regarding any issues you have regarding attributes in rfc5661bis as soon as you can.  Also, I'd like us to schedule some discussion of NFSv4.3 at a forthcoming interim meeting so we can really kick off this effort.
> 
> 
> Pretty sure it was FATTR4_TYPE, which I see is already required.
> 
> This came out of a discussion with Jeff Layton, who wanted to make sure servers could always return it in READDIR results.
> 
> Jeff is my recollection correct?
> 

Yes. Allowing NFS to fill out the d_type field in a readdir response
without having to do an extra GETATTR is a nice benefit.
-- 
Jeff Layton <[e-mail]>