RE: [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

"Noveck, Dave" <Dave.Noveck@netapp.com> Fri, 14 July 2006 18:30 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1SR2-0001Bg-0l; Fri, 14 Jul 2006 14:30:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1SR0-0001AH-Vq for nfsv4@ietf.org; Fri, 14 Jul 2006 14:30:42 -0400
Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1SQy-00035q-MC for nfsv4@ietf.org; Fri, 14 Jul 2006 14:30:42 -0400
Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2.netapp.com with ESMTP; 14 Jul 2006 11:30:40 -0700
X-IronPort-AV: i="4.06,244,1149490800"; d="scan'208"; a="393025704:sNHT21178120"
Received: from svlexc03.hq.netapp.com (svlexc03.corp.netapp.com [10.57.156.149]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k6EIUPhY026905; Fri, 14 Jul 2006 11:30:39 -0700 (PDT)
Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexc03.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 14 Jul 2006 11:29:45 -0700
Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 11:29:44 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready
Date: Fri, 14 Jul 2006 14:29:42 -0400
Message-ID: <C98692FD98048C41885E0B0FACD9DFB8023DF690@exnane01.hq.netapp.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready
Thread-Index: Acancog9AnYzh2nTTMqp92Pcpo8vggAAFANg
From: "Noveck, Dave" <Dave.Noveck@netapp.com>
To: "J. Bruce Fields" <bfields@fieldses.org>, nfsv4@ietf.org
X-OriginalArrivalTime: 14 Jul 2006 18:29:44.0812 (UTC) FILETIME=[7AB0C2C0:01C6A773]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: Sam Falkner <Sam.Falkner@sun.com>, nfs@lists.sourceforge.net, Spencer Shepler <spencer.shepler@sun.com>, "Pawlowski, Brian" <beepy@netapp.com>
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
Errors-To: nfsv4-bounces@ietf.org

I think in all the cases you mentioned, we a have situation in 
which the set of attributes you ask for can effect whether you 
get an error or not.  I'm not aware of any case in which you 
will get different values for a single attribute (no error in 
either case) based on whether you are asking for a different 
attribute.  Other than things like asking for an attribute
that doesn't exist will cause an error to be set in rdattr_error,
but that is part of the function of rdattr_error.

-----Original Message-----
From: J. Bruce Fields [mailto:bfields@fieldses.org] 
Sent: Friday, July 14, 2006 2:23 PM
To: nfsv4@ietf.org
Cc: Sam Falkner; Pawlowski, Brian; Spencer Shepler;
nfs@lists.sourceforge.net
Subject: Re: [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interaction /
mask,draft-ietf-nfsv4-acls-00 not ready


On Fri, Jul 14, 2006 at 01:59:30PM -0400, J. Bruce Fields wrote:
> For a client that doesn't support the new attributes, a server can
apply
> the mask attributes to the ACL before returning it.  I suppose a
> multi-protocol server would do the same for CIFS clients.

By the way, the proposed protocol behavior here is odd:  the server
returns a different ACL depending on whether the client requested any of
the new mask attributes in the same GETATTR.

But I suppose there are other cases (rdattr_error, maybe some migration
cases??) where what we return can depend in strange ways on which
attributes were requested, so maybe it's not totally without precedent?

--b.

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4