From exim@www1.ietf.org Sun Feb 1 15:04:09 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09112 for ; Sun, 1 Feb 2004 15:04:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnNom-0000wI-6N for nfsv4-archive@odin.ietf.org; Sun, 01 Feb 2004 15:03:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i11K3ipI003600 for nfsv4-archive@odin.ietf.org; Sun, 1 Feb 2004 15:03:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnK6y-0007Xx-UL for nfsv4-web-archive@optimus.ietf.org; Sun, 01 Feb 2004 11:06:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01735 for ; Sun, 1 Feb 2004 10:54:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnJRK-0007gO-00 for nfsv4-web-archive@ietf.org; Sun, 01 Feb 2004 10:23:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnJ9J-0002VY-00 for nfsv4-web-archive@ietf.org; Sun, 01 Feb 2004 10:04:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnIeL-0002aG-06 for nfsv4-web-archive@ietf.org; Sun, 01 Feb 2004 09:32:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnIP3-0001Sv-1H for nfsv4-web-archive@ietf.org; Sun, 01 Feb 2004 09:16:49 -0500 Date: Sun, 01 Feb 2004 09:16:49 -0500 Message-ID: <20040201141649.1364.49666.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: nfsv4-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, nfsv4-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for nfsv4-web-archive@ietf.org: List Password // URL ---- -------- nfsv4@ietf.org maabit https://www1.ietf.org/mailman/options/nfsv4/nfsv4-web-archive%40ietf.org From exim@www1.ietf.org Mon Feb 2 08:29:49 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11160 for ; Mon, 2 Feb 2004 08:29:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ane8f-0007eQ-3n for nfsv4-archive@odin.ietf.org; Mon, 02 Feb 2004 08:29:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12DTLHt029404 for nfsv4-archive@odin.ietf.org; Mon, 2 Feb 2004 08:29:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ane8e-0007eB-LL for nfsv4-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 08:29:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11022 for ; Mon, 2 Feb 2004 08:29:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ane8d-0007Uu-00 for nfsv4-web-archive@ietf.org; Mon, 02 Feb 2004 08:29:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ane6k-00071u-00 for nfsv4-web-archive@ietf.org; Mon, 02 Feb 2004 08:27:26 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ane4e-0006ZG-00 for nfsv4-web-archive@ietf.org; Mon, 02 Feb 2004 08:25:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ane4Y-0006L5-3p; Mon, 02 Feb 2004 08:25:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AndwG-0005P7-SG for nfsv4@optimus.ietf.org; Mon, 02 Feb 2004 08:16:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09971 for ; Mon, 2 Feb 2004 08:16:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AndwF-0005ZO-00 for nfsv4@ietf.org; Mon, 02 Feb 2004 08:16:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AndvI-0005Uq-00 for nfsv4@ietf.org; Mon, 02 Feb 2004 08:15:33 -0500 Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx with esmtp (Exim 4.12) id 1AnduV-0005MR-00; Mon, 02 Feb 2004 08:14:43 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i12DE1Mf113384; Mon, 2 Feb 2004 13:14:01 GMT Received: from d10ml001.telaviv.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i12DDxh9121406; Mon, 2 Feb 2004 13:14:00 GMT In-Reply-To: <401A7352.2030803@mindspring.com> To: Ted Anderson Cc: nfsv4@ietf.org, nfsv4-admin@ietf.org, Nicolas Williams MIME-Version: 1.0 Subject: Re: [nfsv4] Namespace terminology X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 02/02/2004 15:13:54, Serialize complete at 02/02/2004 15:13:54 Content-Type: text/plain; charset="US-ASCII" Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Mon, 2 Feb 2004 15:13:53 +0200 Date: Mon, 2 Feb 2004 15:13:53 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 nfsv4-admin@ietf.org wrote on 30/01/2004 17:08:02: > Apologies for the delayed reply. > > On 1/16/2004 17:25, Nicolas Williams wrote: > > On Thu, Jan 15, 2004 at 08:44:25AM -0500, Ted Anderson wrote: > >>fragment -- A sub-tree which is exported as an indivisible unit by a > >> server. If the server is high in the namespace, this might be a > >> single directory containing nothing but referrals and hosted by an > >> LDAP database. Lower in the namespace it would likely be a file > >> server's filesystem. If the namespace supports file junctions then > >> a fragment might be as small as a single file. Fragments have names > >> (possibly structured like pathnames) unique within each domain. > > > > - I've been calling this a "sub-namespace" -- I'm just as happy to use > > "namespace fragment," but "fragment" by itself seems insufficiently > > descriptive. > > I agree. I'm also open to some better term as well. > > > - It seems to me that sub-namespaces, or namespace fragments, can have > > multiple [path]names. > > > > See examples given earlier in the other thread. > > Yes. > > > - Namespace fragments could also have multiple types of names, one type > > being pathnames (relative to other junctions or relative to a > > namespace root), another being more like automount map names. The > > latter are often easier to reference. > > I'm not clear exactly what automount map names are. However, I agree > that a fragment will have multiple types of names. I'd call them > "absolute pathnames", "relative (to another fragment) pathnames", and > "fragment names". The latter are arbitrary names (e.g. > users.ota.backup), whose scope is local to a namespace domain. This > namespace domain becomes a qualifier for fragment names in junction > targets. This qualifier might naturally default to the namespace domain > of the parent fragment, or could be specified explicitly. In AFS terms > a namespace domain is a cell and junctions with an explicitly specified > domain are called cellular mountpoints. > > >>junction -- a link between two fragments of the namespace that are > >> connected for the purposes of pathname traversal. The fragment that > >> is the target of the junction replaces the junction in its parent > >> directory for purposes of file system operations; thus it operates > >> somewhat like symbolic links. > > > > - I'd say junctions are, conceptually and from users' perspectives, > > more like mounts than they are like symbolic links, though on the > > wire they look more like symbolic links. > > Sure, but except for lstat() and unlink() symlinks are as invisible as > mounts to file system API users. > > >>LTE -- (location table entry) the conceptual mapping between a fragment > >> and one or more physical locations where it is located. Each > >> location is a URL(s) describing contact information for the server > >> exporting the fragment. > > > > - The word "entry" seems more appropriate to a concept directly linked > > to the directory. Thus we could have "locations," "location tables" > > and "location table entries." > > I don't get your point here. Are you arguing for the suitability of LTE > as a name for this concept? > > >>referral -- a combination of a junction and an LTE. Thus a referral > >> maps a pathname to a physical location(s). An NFSv4 client sees > >> referrals while the NFSv4 server sees junctions and LTEs. > > > > - This seems too simplified to me because: > > > > - A server may issue referrals as a result of namespace junctions, > > but it may also issue referrals as a result of FS migration. > > > > - A server need not issue a referral to clients crossing a namespace > > junction if the server is a location for both sides of the > > junction. > > Okay. This is a result of the complicated (and confusing) use of the > term "referral" on the mailing list. Interestingly the term does not > appear in RFC3530. Maybe it would be better to define the word > explicitly to be some clear subset of its current (de facto) meaning and > select other terms for other aspects of its meaning. This would seem > preferable to defining it as "that thing that NFSv4 servers do in this > list of situations". > I agree that two different names should be used for migration and "entering a different realm" > >>map -- the representation, perhaps stored in a database or configuration > >> file, of the connections between fragments. The global map is > >> composed of many individual maps that point to each other in a > >> directed graph. A map defines a domain of the namespace. (Because > >> these maps will be managed by many different entities, there is > >> little hope for guaranteeing acyclicity. Clients of the namespace > >> will just have to cope.) A domain's namespace map is supplemented > >> by a location table. > > > > - I think, in the end, that there wil be no such thing as a "global > > namespace" or "global map" anymore than sysadmins allow it, for which > > reason I'd rather speak as little of it as possible and instead focus > > on per-administrative domain namespaces and the mechanisms by which > > the locations of those are determined -- given which a global > > namespace can follow trivially. The point about cross-domain > > references and cycles is very important to make, however, the one > > being necessary to make a global namespace a better experience and > > the other being a result of the first. > > I agree with this. The concept of a global map may be useful in > explaining the namespace to users, but operationally it basically a fiction. > I am also in doubt of how useful it will be. But it would do no harm to align a default structure with the (reverse) DNS names so that the administrative domains could be named too. This may entice the administrators to use some regularity in the subtree (fragment) structuring too. Thus the ietf domain will have: org.ietf.rfc/ org.ietf.drafts/ > >>location table -- tracks the location(s) of each fragment in the domain. > >> The location table is a list of LTE(s) keyed by fragment name. > > > > - I see the sub-namespace name as the name of the table, not the name > > of the entries in the table. > > I think we agree the definitions of sub-namespace and fragment are the > same. Then I mean a location table to look like this, one LTE per line: > ... > users.nico => mercury.acm.org > users.ota => venus.acm.org > software.X11r6.x86 => mars.acm.org, jupiter.acm.org > ... > So there would be one table per server administrative domain (which > would often be one-to-one with namespace domains). > I think it is critical to have ONE table per administrative domain - and that is in contrast to the automount tables that are client data structure and uniformity is at best voluntary. This does go to say that a client can't have ways to override the "uniform global structure" - it only says that the global structure must exist. > >>filesystem -- a fragment that is stored in a file system and accessed by > >> a file server. > >> > >>virtual directory -- directories in fragments that contain only other > >> virtual directories and junctions. Generally, a namespace server > >> will render a map stored in a database (e.g. LDAP) as a tree of > >> virtual directories. The NFSv4 server's pseudo filesystem glues > >> together exported filesystems using virtual directories. > > > > - I'm not sure that this is necessary. This restriction is common to > > "indirect" automount maps, but it isn't obvious that it must remain > > in a referral-based namespace. > > I don't mean it as a restriction. I may have confused things with the > reference to NFSv4's pseudo-fs. Its directories are invisible to users > and used only by clients to navigate to exported filesystems. For > virtual directories, I meant to describe a directory, high in the > namespace, that contains no files but only other virtual directories and > junctions and may be hosted by an LDAP database not a file system. They > are virtual in that the underlying (database) representation might not > contain directories but only lists of junctions identified by fragment > names and relative pathnames. However, they would be directories in the > sense that a user could "cd" to them and "ls" in them. > > > I've been thinking of the schema modelling for namespace > > configuration lately and the automounter model keeps coming up as a > > reasonably straightforward one that can, with few changes, model most > > of what we've been discussing. > > > > I'm particularly interested in making sure that whatever model we > > choose is workable for both, smart-clients and > > dumb-clients/smart-servers. > > My concern about the automounter model is that it doesn't make any clear > distinction between namespace junctions and location tables. But I have > no operational experience with automounter and my academic experience is > quite limited. My reference for the automounter is Callaghan's "NFS > Illustrated". I can well imagine that this isn't the best source. > Could you recommend a guide for understanding this system, which I > realized is not just a single system. > > >>/net -- The Solaris automounter (and others) has an option to mount the > >> host namespace on some mountpoint (typically "/net") such that the > >> next path component down is a hostname and down from there there's > >> the exports or pseudo filesystem of the host in question. Thus we > >> have: "/net/somehost/someshare/somepath". This makes "net" (stored > >> in DNS) and "somehost" (stored in somehost's mtab) virtual > >> directories. > > > > - The Solaris terminology for this is "the -hosts special map." In the > > context of a global namespace composed of per-domain namespace I can > > also imagine a "-domains special map." > > Exactly. > I have to iterate that the issue I have with this model is that the map is a client map and a client has no reference to a global map. This creates a deployment conundrum. > >>DISCUSSION > >> > >>Should we try to find a better name for "fragments"? It is a pretty > >>generic term, but "namespace fragment" is clear enough though long. > > > > Yes. See above. > > You like sub-namespace better? > > >>Do we need a better name for "LTE"? > > > > Yes. See above. > > I didn't get your suggested alternative for LTE. > > >>We could redefine "referral" to mean "LTE" instead of the collective > >>"junction" + "LTE". But this might be confusing and lead to > >>misunderstandings, as it is already heavily used in this discussion > >>(though not in RFC3530). > > > > No. > > > >>The term "map" comes by extension from automounter maps. It is very > >>generic and should be used as "namespace map" to disambiguate. Should > > > > Fortunately the term maps nicely to the notion of namespace junctions. > > See above. > > > >>we dispose of this term and use something like namespace domain or > >>namespace database depending on circumstances? By analogy with the > >>automounter, perhaps "map" should be expanded to include "location > >>table", however, this didn't seem to be implied by the original usage > >>(by Julian on 21-Dec-2003). In other words, should we say that a "map" > >>is "namespace table" + "location table"? > > > > The term maps to a concept of a per-namespace junction sub-namespace > > configuration database. > > Ted > > > _______________________________________________ > 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 From exim@www1.ietf.org Tue Feb 3 13:04:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22002 for ; Tue, 3 Feb 2004 13:04:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao4u8-0000sO-4M for nfsv4-archive@odin.ietf.org; Tue, 03 Feb 2004 13:04:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13I48Hm003362 for nfsv4-archive@odin.ietf.org; Tue, 3 Feb 2004 13:04:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao4u7-0000s9-Uf for nfsv4-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 13:04:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21860 for ; Tue, 3 Feb 2004 13:04:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao4u6-0007nF-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 13:04:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao4rh-0007L7-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 13:01:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao4qH-000769-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 13:00:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao4qC-00007h-EJ; Tue, 03 Feb 2004 13:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao4pe-0008I7-OE for nfsv4@optimus.ietf.org; Tue, 03 Feb 2004 12:59:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21579 for ; Tue, 3 Feb 2004 12:59:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao4pc-000730-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 12:59:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao4od-0006xX-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 12:58:28 -0500 Received: from dsl093-002-214.det1.dsl.speakeasy.net ([66.93.2.214] helo=pumpkin.fieldses.org ident=Debian-exim) by ietf-mx with esmtp (Exim 4.12) id 1Ao4ne-0006oJ-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 12:57:26 -0500 Received: from bfields by pumpkin.fieldses.org with local (Exim 4.30) id 1Ao4nc-00047j-VZ for nfsv4@ietf.org; Tue, 03 Feb 2004 12:57:24 -0500 To: nfsv4@ietf.org Message-ID: <20040203175724.GC15097@fieldses.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i From: "J. Bruce Fields" Subject: [nfsv4] DELETE_CHILD and DELETE Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Tue, 3 Feb 2004 12:57:24 -0500 Date: Tue, 3 Feb 2004 12:57:24 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 If and acl allows DELETE_CHILD is set on a directory and denies DELETE on a file in the directory, is it documented anywhere whether the file should be removeable? (and what if it denies DELETE_CHILD and allows DELETE on the file?) I'm assuming that removal is allowed if *either* DELETE_CHILD or DELETE is set, in which case posix implementations should associate DELETE_CHILD with write permissions and should never set DELETE. --Bruce Fields _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Tue Feb 3 14:51:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26981 for ; Tue, 3 Feb 2004 14:51:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6ZE-0001xW-CF for nfsv4-archive@odin.ietf.org; Tue, 03 Feb 2004 14:50:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13Joe4D007524 for nfsv4-archive@odin.ietf.org; Tue, 3 Feb 2004 14:50:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6ZE-0001xH-6e for nfsv4-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 14:50:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26972 for ; Tue, 3 Feb 2004 14:50:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6ZB-0004EQ-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 14:50:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao6YS-00048a-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 14:49:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6Xb-00042U-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 14:48:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6Xc-0007sq-II; Tue, 03 Feb 2004 14:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6XF-0007rz-Ll for nfsv4@optimus.ietf.org; Tue, 03 Feb 2004 14:48:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26892 for ; Tue, 3 Feb 2004 14:48:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6XC-0003ze-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 14:48:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao6WI-0003tt-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 14:47:39 -0500 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6VU-0003id-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 14:46:48 -0500 Received: from frejya.corp.netapp.com (frejya [10.57.157.119]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i13JjlKw011778; Tue, 3 Feb 2004 11:45:47 -0800 (PST) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.10.22.171]) by frejya.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i13JjkDi012768; Tue, 3 Feb 2004 11:45:46 -0800 (PST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [nfsv4] DELETE_CHILD and DELETE Message-ID: Thread-Topic: [nfsv4] DELETE_CHILD and DELETE Thread-Index: AcPqf5oWIy7J+KnZQ/SCi6fSJKB9uAADdFKQ From: "Noveck, Dave" To: "J. Bruce Fields" , Content-Transfer-Encoding: quoted-printable Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Tue, 3 Feb 2004 11:45:40 -0800 Date: Tue, 3 Feb 2004 11:45:40 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > If and acl allows DELETE_CHILD is set on a directory and denies DELETE > on a file in the directory, is it documented anywhere whether the file > should be removeable? (and what if it denies DELETE_CHILD and allows > DELETE on the file?) Not that I could see. > I'm assuming that removal is allowed if *either* DELETE_CHILD or = DELETE > is set,=20 That doesn't seem right to me. If the owner of the directory let's me write in it, OK. But if the owner of the file doesn't let me do = anything with it (read, write, execute), why would I be allowed to delete the thing, especially since there is an explicit DELETE bit by which I may prohibit people from doing a delete? It would seem more natural to me if both were required, but I didn't see any text that addressed the issue. > in which case posix implementations should associate > DELETE_CHILD with write permissions and should never set DELETE. -----Original Message----- From: J. Bruce Fields [mailto:bfields@fieldses.org] Sent: Tuesday, February 03, 2004 12:57 PM To: nfsv4@ietf.org Subject: [nfsv4] DELETE_CHILD and DELETE If and acl allows DELETE_CHILD is set on a directory and denies DELETE on a file in the directory, is it documented anywhere whether the file should be removeable? (and what if it denies DELETE_CHILD and allows DELETE on the file?) I'm assuming that removal is allowed if *either* DELETE_CHILD or DELETE is set, in which case posix implementations should associate DELETE_CHILD with write permissions and should never set DELETE. --Bruce Fields _______________________________________________ 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 From exim@www1.ietf.org Tue Feb 3 15:12:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28226 for ; Tue, 3 Feb 2004 15:12:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6tX-0002ye-DV for nfsv4-archive@odin.ietf.org; Tue, 03 Feb 2004 15:11:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13KBd8N011438 for nfsv4-archive@odin.ietf.org; Tue, 3 Feb 2004 15:11:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6tX-0002yP-8G for nfsv4-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 15:11:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28178 for ; Tue, 3 Feb 2004 15:11:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6tU-00069Q-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 15:11:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao6sc-00064f-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 15:10:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6rw-0005zR-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 15:10:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6rx-0002Mp-N8; Tue, 03 Feb 2004 15:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6rY-0002G4-5D for nfsv4@optimus.ietf.org; Tue, 03 Feb 2004 15:09:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27978 for ; Tue, 3 Feb 2004 15:09:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6rV-0005xY-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 15:09:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao6qZ-0005sG-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 15:08:36 -0500 Received: from gw2.panasas.com ([65.194.124.178] helo=PIKES.panasas.com) by ietf-mx with esmtp (Exim 4.12) id 1Ao6pd-0005id-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 15:07:37 -0500 Received: by PIKES.panasas.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Feb 2004 15:07:05 -0500 Message-ID: <30489F1321F5C343ACF6872B2CF7942A05D38811@PIKES.panasas.com> From: "Halevy, Benny" To: "'Noveck, Dave'" , "J. Bruce Fields" Cc: nfsv4@ietf.org Subject: RE: [nfsv4] DELETE_CHILD and DELETE MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Tue, 3 Feb 2004 15:07:03 -0500 Date: Tue, 3 Feb 2004 15:07:03 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL autolearn=no version=2.60 What about REMOVE when link count is greater than one? In this case you are modifying the directory but you aren't deleting the object and I'd expect the file system to allow that if you have DELETE_CHILD (or WRITE if DELETE_CHILD is not specifically supported) access to the directory, regardless of whether you have DELETE access to the file. If the client is about to obliterate the file by removing its last link then it should need both DELETE_CHILD access to the directory and DELETE access to the file. For summary, my interpretation is that DELETE_CHILD refers to the directory contents and DELETE refers to the file's contents. Since REMOVE always modifies the directory, you should always need DELETE_CHILD access on the directory. When the file's link count is 1 you should also need DELETE access to the file. If you always require both it could lead to an unpleasant case where you can link a file to a directory but cannot unlink it. Still, I do not think the spec can or should mandate these semantics, but rather recommend them. Benny > -----Original Message----- > From: Noveck, Dave [mailto:Dave.Noveck@netapp.com] > Sent: Tuesday, February 03, 2004 2:46 PM > To: J. Bruce Fields; nfsv4@ietf.org > Subject: RE: [nfsv4] DELETE_CHILD and DELETE > > > > If and acl allows DELETE_CHILD is set on a directory and > denies DELETE > > on a file in the directory, is it documented anywhere > whether the file > > should be removeable? (and what if it denies DELETE_CHILD and allows > > DELETE on the file?) > > Not that I could see. > > > I'm assuming that removal is allowed if *either* > DELETE_CHILD or DELETE > > is set, > > That doesn't seem right to me. If the owner of the directory let's me > write in it, OK. But if the owner of the file doesn't let me > do anything > with it (read, write, execute), why would I be allowed to delete the > thing, especially since there is an explicit DELETE bit by which I may > prohibit people from doing a delete? > > It would seem more natural to me if both were required, but I didn't > see any text that addressed the issue. > > > in which case posix implementations should associate > > DELETE_CHILD with write permissions and should never set DELETE. > > -----Original Message----- > From: J. Bruce Fields [mailto:bfields@fieldses.org] > Sent: Tuesday, February 03, 2004 12:57 PM > To: nfsv4@ietf.org > Subject: [nfsv4] DELETE_CHILD and DELETE > > > If and acl allows DELETE_CHILD is set on a directory and denies DELETE > on a file in the directory, is it documented anywhere whether the file > should be removeable? (and what if it denies DELETE_CHILD and allows > DELETE on the file?) > > I'm assuming that removal is allowed if *either* DELETE_CHILD > or DELETE > is set, in which case posix implementations should associate > DELETE_CHILD with write permissions and should never set DELETE. > > --Bruce Fields > > _______________________________________________ > 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 > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Tue Feb 3 15:26:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29177 for ; Tue, 3 Feb 2004 15:26:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao773-0006eZ-8w for nfsv4-archive@odin.ietf.org; Tue, 03 Feb 2004 15:25:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13KPbJg025573 for nfsv4-archive@odin.ietf.org; Tue, 3 Feb 2004 15:25:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao773-0006eO-4D for nfsv4-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 15:25:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29171 for ; Tue, 3 Feb 2004 15:25:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao771-0007SW-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 15:25:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao769-0007Nu-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 15:24:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao75X-0007Ir-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 15:24:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao75V-0006Ye-76; Tue, 03 Feb 2004 15:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao758-0006YG-In for nfsv4@optimus.ietf.org; Tue, 03 Feb 2004 15:23:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29135 for ; Tue, 3 Feb 2004 15:23:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao757-0007Ht-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 15:23:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao74D-0007Cj-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 15:22:42 -0500 Received: from dsl093-002-214.det1.dsl.speakeasy.net ([66.93.2.214] helo=pumpkin.fieldses.org ident=Debian-exim) by ietf-mx with esmtp (Exim 4.12) id 1Ao73c-00077Z-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 15:22:04 -0500 Received: from bfields by pumpkin.fieldses.org with local (Exim 4.30) id 1Ao73Z-0004Nk-Jy; Tue, 03 Feb 2004 15:22:01 -0500 To: "Noveck, Dave" Cc: nfsv4@ietf.org Subject: Re: [nfsv4] DELETE_CHILD and DELETE Message-ID: <20040203202201.GJ15097@fieldses.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i From: "J. Bruce Fields" Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Tue, 3 Feb 2004 15:22:01 -0500 Date: Tue, 3 Feb 2004 15:22:01 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Tue, Feb 03, 2004 at 11:45:40AM -0800, Noveck, Dave wrote: > > I'm assuming that removal is allowed if *either* DELETE_CHILD or DELETE > > is set, > > That doesn't seem right to me. Ugh. Well, we need to agree on this. Can anyone point me to any authoritative documentation on NT ACL's (since they seem to be the inspiration for DELETE and DELETE_CHILD)? > If the owner of the directory let's me write in it, OK. But if the > owner of the file doesn't let me do anything with it (read, write, > execute), why would I be allowed to delete the thing, That's standard unix-like behavior: unlinking a file is a directory operation (it doesn't even necessarily destroy the file, which may be referenced elsewhere), so only directory permissions matter. > especially since there is an explicit DELETE bit by which I may > prohibit people from doing a delete? I'm operating in a total NT ACL vacuum here so one of the few tidbits I have to go on is some random linux-kernel email turned up by google, where someone refers to DELETE, "which lets you bypass directory write permission to delete a specified file." http://www.ussg.iu.edu/hypermail/linux/kernel/0007.3/0801.html Otherwise it would seem awfully easy to get into a situation where you could create a file you couldn't delete. --Bruce Fields _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Tue Feb 3 15:36:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29519 for ; Tue, 3 Feb 2004 15:36:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7Gp-0007Jo-AI for nfsv4-archive@odin.ietf.org; Tue, 03 Feb 2004 15:35:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13KZhmu028126 for nfsv4-archive@odin.ietf.org; Tue, 3 Feb 2004 15:35:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7Gp-0007JY-3Z for nfsv4-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 15:35:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29504 for ; Tue, 3 Feb 2004 15:35:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7Gn-0000Zr-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 15:35:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao7Fq-0000U3-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 15:34:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7FA-0000OP-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 15:34:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7FB-0007Cv-1P; Tue, 03 Feb 2004 15:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7Ek-0007BD-L5 for nfsv4@optimus.ietf.org; Tue, 03 Feb 2004 15:33:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29426 for ; Tue, 3 Feb 2004 15:33:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7Ej-0000ML-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 15:33:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao7Do-0000Ga-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 15:32:37 -0500 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7D5-00006G-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 15:31:51 -0500 Received: from hawk.corp.netapp.com (hawk [10.57.156.122]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i13KUoKw019508; Tue, 3 Feb 2004 12:30:50 -0800 (PST) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.10.22.171]) by hawk.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i13KUnRh015326; Tue, 3 Feb 2004 12:30:49 -0800 (PST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [nfsv4] DELETE_CHILD and DELETE Message-ID: Thread-Topic: [nfsv4] DELETE_CHILD and DELETE Thread-Index: AcPqkU608mUO/Vf0S32jWW6wO1pUbgAAKC0w From: "Noveck, Dave" To: "Halevy, Benny" , "J. Bruce Fields" Cc: Content-Transfer-Encoding: quoted-printable Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Tue, 3 Feb 2004 12:30:45 -0800 Date: Tue, 3 Feb 2004 12:30:45 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > For summary, my interpretation is that DELETE_CHILD refers to > the directory contents and DELETE refers to the file's contents. Make sense to me. > Since REMOVE always modifies the directory, you should always need > DELETE_CHILD access on the directory. When the file's link count > is 1 you should also need DELETE access to the file. I think you need WRITE_ATTRIBUTES on the file to decrement the link count, when the link count is greater than one. I suppose you need it if you are decrementing the link count from 1 to zero and keeping the file aroung (for example whie it is open). I agree that when the link count was 1, you need DELETE on the file. > If you always require both it could lead to an unpleasant case > where you can link a file to a directory but cannot unlink it. Since the spec distinguishes ADD_FILE and DELETE_CHILD, you have=20 that case anyway. I'm also assuming that if a directory allows one of those but not the other, you cannot rename a file within the directory. Fun, huh? > Still, I do not think the spec can or should mandate these semantics, > but rather recommend them. As long as it gives clear guidelines about what to do, I really don't care if they are offered as mandates or recommendations. -----Original Message----- From: Halevy, Benny [mailto:bhalevy@panasas.com] Sent: Tuesday, February 03, 2004 3:07 PM To: Noveck, Dave; J. Bruce Fields Cc: nfsv4@ietf.org Subject: RE: [nfsv4] DELETE_CHILD and DELETE What about REMOVE when link count is greater than one? In this case you are modifying the directory but you aren't=20 deleting the object and I'd expect the file system to allow that if you have DELETE_CHILD (or WRITE if DELETE_CHILD is not specifically supported) access to the directory, regardless of whether you have DELETE access to the file. If the client is about to obliterate the file by removing its last link then it should need both DELETE_CHILD access to the directory and DELETE access to the file. For summary, my interpretation is that DELETE_CHILD refers to the directory contents and DELETE refers to the file's contents. Since REMOVE always modifies the directory, you should always need DELETE_CHILD access on the directory. When the file's link count is 1 you should also need DELETE access to the file. If you always require both it could lead to an unpleasant case where you can link a file to a directory but cannot unlink it. Still, I do not think the spec can or should mandate these semantics, but rather recommend them. Benny > -----Original Message----- > From: Noveck, Dave [mailto:Dave.Noveck@netapp.com] > Sent: Tuesday, February 03, 2004 2:46 PM > To: J. Bruce Fields; nfsv4@ietf.org > Subject: RE: [nfsv4] DELETE_CHILD and DELETE >=20 >=20 > > If and acl allows DELETE_CHILD is set on a directory and=20 > denies DELETE > > on a file in the directory, is it documented anywhere=20 > whether the file > > should be removeable? (and what if it denies DELETE_CHILD and allows > > DELETE on the file?) >=20 > Not that I could see. >=20 > > I'm assuming that removal is allowed if *either*=20 > DELETE_CHILD or DELETE > > is set,=20 >=20 > That doesn't seem right to me. If the owner of the directory let's me > write in it, OK. But if the owner of the file doesn't let me=20 > do anything > with it (read, write, execute), why would I be allowed to delete the > thing, especially since there is an explicit DELETE bit by which I may > prohibit people from doing a delete? >=20 > It would seem more natural to me if both were required, but I didn't > see any text that addressed the issue. >=20 > > in which case posix implementations should associate > > DELETE_CHILD with write permissions and should never set DELETE. >=20 > -----Original Message----- > From: J. Bruce Fields [mailto:bfields@fieldses.org] > Sent: Tuesday, February 03, 2004 12:57 PM > To: nfsv4@ietf.org > Subject: [nfsv4] DELETE_CHILD and DELETE >=20 >=20 > If and acl allows DELETE_CHILD is set on a directory and denies DELETE > on a file in the directory, is it documented anywhere whether the file > should be removeable? (and what if it denies DELETE_CHILD and allows > DELETE on the file?) >=20 > I'm assuming that removal is allowed if *either* DELETE_CHILD=20 > or DELETE > is set, in which case posix implementations should associate > DELETE_CHILD with write permissions and should never set DELETE. >=20 > --Bruce Fields >=20 > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 >=20 > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 >=20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Tue Feb 3 15:36:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29531 for ; Tue, 3 Feb 2004 15:36:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7Gp-0007K6-Sw for nfsv4-archive@odin.ietf.org; Tue, 03 Feb 2004 15:35:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13KZhBB028144 for nfsv4-archive@odin.ietf.org; Tue, 3 Feb 2004 15:35:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7Gp-0007Jr-Ok for nfsv4-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 15:35:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29508 for ; Tue, 3 Feb 2004 15:35:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7Go-0000Zx-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 15:35:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao7Fr-0000UD-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 15:34:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7FA-0000OR-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 15:34:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7FB-0007DG-EN; Tue, 03 Feb 2004 15:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7Em-0007BV-Oz for nfsv4@optimus.ietf.org; Tue, 03 Feb 2004 15:33:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29437 for ; Tue, 3 Feb 2004 15:33:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7El-0000Mb-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 15:33:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao7Dq-0000Gs-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 15:32:39 -0500 Received: from dsl093-002-214.det1.dsl.speakeasy.net ([66.93.2.214] helo=pumpkin.fieldses.org ident=Debian-exim) by ietf-mx with esmtp (Exim 4.12) id 1Ao7DC-0000Bq-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 15:31:59 -0500 Received: from bfields by pumpkin.fieldses.org with local (Exim 4.30) id 1Ao7D9-0004P7-Tz; Tue, 03 Feb 2004 15:31:55 -0500 To: "Halevy, Benny" Cc: "'Noveck, Dave'" , nfsv4@ietf.org Subject: Re: [nfsv4] DELETE_CHILD and DELETE Message-ID: <20040203203155.GK15097@fieldses.org> References: <30489F1321F5C343ACF6872B2CF7942A05D38811@PIKES.panasas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30489F1321F5C343ACF6872B2CF7942A05D38811@PIKES.panasas.com> User-Agent: Mutt/1.5.5.1+cvs20040105i From: "J. Bruce Fields" Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Tue, 3 Feb 2004 15:31:55 -0500 Date: Tue, 3 Feb 2004 15:31:55 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Tue, Feb 03, 2004 at 03:07:03PM -0500, Halevy, Benny wrote: > What about REMOVE when link count is greater than one? > > In this case you are modifying the directory but you aren't > deleting the object and I'd expect the file system to allow > that if you have DELETE_CHILD (or WRITE if DELETE_CHILD is > not specifically supported) access to the directory, > regardless of whether you have DELETE access to the > file. > > If the client is about to obliterate the file by removing its > last link then it should need both DELETE_CHILD access to the > directory and DELETE access to the file. > > For summary, my interpretation is that DELETE_CHILD refers to > the directory contents and DELETE refers to the file's contents. > > Since REMOVE always modifies the directory, you should always need > DELETE_CHILD access on the directory. When the file's link count > is 1 you should also need DELETE access to the file. So a posix client could get the behavior it expects by always setting DELETE, and setting DELETE_CHILD only on directories wherever the write bit is set? I suppose that would work. Do you have a source for this interpretation? Are there server implementations that actually work this way? > If you always require both it could lead to an unpleasant case > where you can link a file to a directory but cannot unlink it. > Still, I do not think the spec can or should mandate these semantics, > but rather recommend them. If I sit down at a client to set certain mode bits or acls I don't want to have read all the client and server documentation to work out what those acls actually mean. That sounds like a security nightmare. --Bruce Fields _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Tue Feb 3 15:48:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00276 for ; Tue, 3 Feb 2004 15:48:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7SS-0008OZ-6d for nfsv4-archive@odin.ietf.org; Tue, 03 Feb 2004 15:47:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13KlitE032268 for nfsv4-archive@odin.ietf.org; Tue, 3 Feb 2004 15:47:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7SS-0008ON-03 for nfsv4-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 15:47:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00254 for ; Tue, 3 Feb 2004 15:47:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7SQ-0001cG-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 15:47:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao7RT-0001WE-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 15:46:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7Qn-0001Qe-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 15:46:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7Qo-000893-Mu; Tue, 03 Feb 2004 15:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7QS-000883-Ua for nfsv4@optimus.ietf.org; Tue, 03 Feb 2004 15:45:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00025 for ; Tue, 3 Feb 2004 15:45:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7QR-0001Ph-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 15:45:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao7PT-0001KW-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 15:44:39 -0500 Received: from dsl093-002-214.det1.dsl.speakeasy.net ([66.93.2.214] helo=pumpkin.fieldses.org ident=Debian-exim) by ietf-mx with esmtp (Exim 4.12) id 1Ao7P7-0001FY-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 15:44:17 -0500 Received: from bfields by pumpkin.fieldses.org with local (Exim 4.30) id 1Ao7P5-0004Qb-0a; Tue, 03 Feb 2004 15:44:15 -0500 To: "Noveck, Dave" Cc: "Halevy, Benny" , nfsv4@ietf.org Subject: Re: [nfsv4] DELETE_CHILD and DELETE Message-ID: <20040203204414.GL15097@fieldses.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i From: "J. Bruce Fields" Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Tue, 3 Feb 2004 15:44:14 -0500 Date: Tue, 3 Feb 2004 15:44:14 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Tue, Feb 03, 2004 at 12:30:45PM -0800, Noveck, Dave wrote: > I think you need WRITE_ATTRIBUTES on the file to decrement the link > count, when the link count is greater than one. I suppose you need > it if you are decrementing the link count from 1 to zero and keeping > the file aroung (for example whie it is open). You really don't want to require WRITE_ATTRIBUTES for any operation that might modify the attributes of a file. In fact, I was assuming that our linux client should set WRITE_ATTRIBUTES for the file's owner only. (Does WRITE_ATTRIBUTES also give the right to modify mode bits?) --b. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Tue Feb 3 16:27:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04383 for ; Tue, 3 Feb 2004 16:27:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao84M-0002pX-LI for nfsv4-archive@odin.ietf.org; Tue, 03 Feb 2004 16:26:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13LQsJp010876 for nfsv4-archive@odin.ietf.org; Tue, 3 Feb 2004 16:26:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao84M-0002pL-E9 for nfsv4-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 16:26:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04355 for ; Tue, 3 Feb 2004 16:26:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao84K-0007dF-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 16:26:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao83Q-0007Uc-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 16:25:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao82Y-0007Mt-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 16:25:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao82Y-0002hM-4j; Tue, 03 Feb 2004 16:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao82I-0002gh-Cb for nfsv4@optimus.ietf.org; Tue, 03 Feb 2004 16:24:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04165 for ; Tue, 3 Feb 2004 16:24:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao82G-0007KW-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 16:24:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao81M-0007E5-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 16:23:49 -0500 Received: from citi.umich.edu ([141.211.133.111]) by ietf-mx with esmtp (Exim 4.12) id 1Ao80s-00077t-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 16:23:18 -0500 Received: from citi.umich.edu (dumaguete.citi.umich.edu [141.211.133.51]) by citi.umich.edu (Postfix) with ESMTP id 492CA20807 for ; Tue, 3 Feb 2004 16:21:35 -0500 (EST) Subject: Re: [nfsv4] DELETE_CHILD and DELETE To: nfsv4@ietf.org From: Jim Rees In-Reply-To: "Noveck, Dave", Tue, 03 Feb 2004 12:30:45 PST Message-Id: <20040203212135.492CA20807@citi.umich.edu> Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Tue, 03 Feb 2004 16:21:35 -0500 Date: Tue, 03 Feb 2004 16:21:35 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I think you need WRITE_ATTRIBUTES on the file to decrement the link count, when the link count is greater than one. No, I don't think so. WRITE_ATTRIBUTES is for those attributes that are explicitly set by the client, the ones marked R/W in section 5.5 of the rfc. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Tue Feb 3 17:21:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08758 for ; Tue, 3 Feb 2004 17:21:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao8uS-0006hn-Ge for nfsv4-archive@odin.ietf.org; Tue, 03 Feb 2004 17:20:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13MKibJ025769 for nfsv4-archive@odin.ietf.org; Tue, 3 Feb 2004 17:20:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao8uS-0006hY-AO for nfsv4-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 17:20:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08744 for ; Tue, 3 Feb 2004 17:20:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao8uQ-0007VI-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 17:20:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao8tS-0007On-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 17:19:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao8so-0007Is-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 17:19:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao8sn-0006VT-BM; Tue, 03 Feb 2004 17:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao8rw-0006QI-QK for nfsv4@optimus.ietf.org; Tue, 03 Feb 2004 17:18:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08477 for ; Tue, 3 Feb 2004 17:18:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao8ru-00077m-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 17:18:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao8qc-0006ve-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 17:16:46 -0500 Received: from dsl093-002-214.det1.dsl.speakeasy.net ([66.93.2.214] helo=pumpkin.fieldses.org ident=Debian-exim) by ietf-mx with esmtp (Exim 4.12) id 1Ao8qC-0006ps-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 17:16:20 -0500 Received: from bfields by pumpkin.fieldses.org with local (Exim 4.30) id 1Ao8q8-0004aS-K2; Tue, 03 Feb 2004 17:16:16 -0500 To: Jim Rees Cc: nfsv4@ietf.org Subject: Re: [nfsv4] DELETE_CHILD and DELETE Message-ID: <20040203221616.GO15097@fieldses.org> References: <20040203212135.492CA20807@citi.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040203212135.492CA20807@citi.umich.edu> User-Agent: Mutt/1.5.5.1+cvs20040105i From: "J. Bruce Fields" Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Tue, 3 Feb 2004 17:16:16 -0500 Date: Tue, 3 Feb 2004 17:16:16 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Tue, Feb 03, 2004 at 04:21:35PM -0500, Jim Rees wrote: > I think you need WRITE_ATTRIBUTES on the file to decrement the link > count, when the link count is greater than one. > > No, I don't think so. WRITE_ATTRIBUTES is for those attributes that are > explicitly set by the client, the ones marked R/W in section 5.5 of the rfc. Except that there's a specific exception in the rfc, which says WRITE_ATTRIBUTES controls "The ability to write basic attributes (non-acls) of a file". "basic attributes" isn't a term that's defined anywhere; reading this text you might assume it just meant attributes other than acls, but I think it was intended to mean attributes other than named attributes. Of course if WRITE_ATTRIBUTES allows writing of mode bits, then in practice it *does* allow writing of acls. So perhaps mode bits should also be excepted. I'm also a little confused as to whether WRITE_ATTRIBUTES should control the ability to write the size attribute. --Bruce Fields _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Tue Feb 3 17:46:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10359 for ; Tue, 3 Feb 2004 17:46:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9IX-0000gl-Ot for nfsv4-archive@odin.ietf.org; Tue, 03 Feb 2004 17:45:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13Mjb2Q002641 for nfsv4-archive@odin.ietf.org; Tue, 3 Feb 2004 17:45:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9IX-0000gW-JF for nfsv4-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 17:45:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10299 for ; Tue, 3 Feb 2004 17:45:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao9IV-00036z-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 17:45:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao9Gk-0002iK-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 17:43:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao9F1-0002P9-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 17:41:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9F3-0000Rn-6f; Tue, 03 Feb 2004 17:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9Ev-0000R6-L8 for nfsv4@optimus.ietf.org; Tue, 03 Feb 2004 17:41:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09976 for ; Tue, 3 Feb 2004 17:41:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao9Et-0002NS-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 17:41:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao9Dm-0002Gj-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 17:40:43 -0500 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1Ao9DA-00027L-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 17:40:04 -0500 Received: from frejya.corp.netapp.com (frejya [10.57.157.119]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i13Md1Kw010700; Tue, 3 Feb 2004 14:39:01 -0800 (PST) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.10.22.171]) by frejya.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i13Md1Di007860; Tue, 3 Feb 2004 14:39:01 -0800 (PST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [nfsv4] DELETE_CHILD and DELETE Message-ID: Thread-Topic: [nfsv4] DELETE_CHILD and DELETE Thread-Index: AcPqo8XFvmqn//ChRhi9Kde9tR05GQAAkSvw From: "Noveck, Dave" To: "J. Bruce Fields" , "Jim Rees" Cc: Content-Transfer-Encoding: quoted-printable Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Tue, 3 Feb 2004 14:38:56 -0800 Date: Tue, 3 Feb 2004 14:38:56 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > I'm also a little confused as to whether WRITE_ATTRIBUTES should = control > the ability to write the size attribute. Why is that confusing? All you have to do is figure out whether the size is a "basic attribute". Maybe we can do a pH test :-) -----Original Message----- From: J. Bruce Fields [mailto:bfields@fieldses.org] Sent: Tuesday, February 03, 2004 5:16 PM To: Jim Rees Cc: nfsv4@ietf.org Subject: Re: [nfsv4] DELETE_CHILD and DELETE On Tue, Feb 03, 2004 at 04:21:35PM -0500, Jim Rees wrote: > I think you need WRITE_ATTRIBUTES on the file to decrement the link > count, when the link count is greater than one. >=20 > No, I don't think so. WRITE_ATTRIBUTES is for those attributes that = are > explicitly set by the client, the ones marked R/W in section 5.5 of = the rfc. Except that there's a specific exception in the rfc, which says WRITE_ATTRIBUTES controls "The ability to write basic attributes (non-acls) of a file". "basic attributes" isn't a term that's defined anywhere; reading this text you might assume it just meant attributes other than acls, but I think it was intended to mean attributes other than named attributes. Of course if WRITE_ATTRIBUTES allows writing of mode bits, then in practice it *does* allow writing of acls. So perhaps mode bits should also be excepted. I'm also a little confused as to whether WRITE_ATTRIBUTES should control the ability to write the size attribute. --Bruce Fields _______________________________________________ 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 From exim@www1.ietf.org Tue Feb 3 18:22:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12778 for ; Tue, 3 Feb 2004 18:22:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9rT-0000dZ-Mn for nfsv4-archive@odin.ietf.org; Tue, 03 Feb 2004 18:21:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13NLhVo002449 for nfsv4-archive@odin.ietf.org; Tue, 3 Feb 2004 18:21:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9rT-0000dQ-I7 for nfsv4-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 18:21:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12774 for ; Tue, 3 Feb 2004 18:21:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao9rQ-0006lZ-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 18:21:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao9qV-0006gu-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 18:20:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao9po-0006cA-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 18:20:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9pq-0000VI-Me; Tue, 03 Feb 2004 18:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9pb-0000PW-AM for nfsv4@optimus.ietf.org; Tue, 03 Feb 2004 18:19:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12729 for ; Tue, 3 Feb 2004 18:19:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao9pY-0006bs-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 18:19:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao9ok-0006Wg-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 18:18:54 -0500 Received: from gw2.panasas.com ([65.194.124.178] helo=PIKES.panasas.com) by ietf-mx with esmtp (Exim 4.12) id 1Ao9o4-0006LV-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 18:18:13 -0500 Received: by PIKES.panasas.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Feb 2004 18:17:37 -0500 Message-ID: <30489F1321F5C343ACF6872B2CF7942A05D38818@PIKES.panasas.com> From: "Halevy, Benny" To: "'J. Bruce Fields'" , "Halevy, Benny" Cc: "'Noveck, Dave'" , nfsv4@ietf.org Subject: RE: [nfsv4] DELETE_CHILD and DELETE MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Tue, 3 Feb 2004 18:17:36 -0500 Date: Tue, 3 Feb 2004 18:17:36 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 >So a posix client could get the behavior it expects by always setting >DELETE, and setting DELETE_CHILD only on directories wherever the write >bit is set? yes, posix requires only write permission on the directory see http://www.opengroup.org/onlinepubs/007904975/functions/unlink.html ... [EACCES] Search permission is denied for a component of the path prefix, or write permission is denied on the directory containing the directory entry to be removed. see also my reply to marius@umich.edu in ftp://ftp.ietf.org/ietf-mail-archive/nfsv4/2003-08.mail Message-ID: <3F43EF5C.6090809@panasas.com> I believe that a Posix compliant nfsv4 client should create an ACE for the file OWNER to allow it ACE4_WRITE_{ATTRIBUTES,ACL} | ACE4_WRITE_OWNER and an ACE for EVERYONE to allow ACE4_READ_{ATTRIBUTES,ACL} and ACE4_DELETE (when supported by the server). ... I believe that the correct mappings should be: Posix read: ACE4_READ_DATA | ACE4_LIST_DIRECTORY Posix write: ACE4_WRITE_DATA | ACE4_ADD_FILE | ACE4_APPEND_DATA | ACE4_ADD_SUBDIRECTORY | ACE4_DELETE_CHILD Posix execute: ACE4_READ_DATA | ACE4_LIST_DIRECTORY | ACE4_EXECUTE Benny >-----Original Message----- >From: J. Bruce Fields [mailto:bfields@fieldses.org] >Sent: Tuesday, February 03, 2004 3:32 PM >To: Halevy, Benny >Cc: 'Noveck, Dave'; nfsv4@ietf.org >Subject: Re: [nfsv4] DELETE_CHILD and DELETE > > >On Tue, Feb 03, 2004 at 03:07:03PM -0500, Halevy, Benny wrote: >> What about REMOVE when link count is greater than one? >> >> In this case you are modifying the directory but you aren't >> deleting the object and I'd expect the file system to allow >> that if you have DELETE_CHILD (or WRITE if DELETE_CHILD is >> not specifically supported) access to the directory, >> regardless of whether you have DELETE access to the >> file. >> >> If the client is about to obliterate the file by removing its >> last link then it should need both DELETE_CHILD access to the >> directory and DELETE access to the file. >> >> For summary, my interpretation is that DELETE_CHILD refers to >> the directory contents and DELETE refers to the file's contents. >> >> Since REMOVE always modifies the directory, you should always need >> DELETE_CHILD access on the directory. When the file's link count >> is 1 you should also need DELETE access to the file. > >So a posix client could get the behavior it expects by always setting >DELETE, and setting DELETE_CHILD only on directories wherever the write >bit is set? > >I suppose that would work. Do you have a source for this >interpretation? Are there server implementations that actually work >this way? > >> If you always require both it could lead to an unpleasant case >> where you can link a file to a directory but cannot unlink it. >> Still, I do not think the spec can or should mandate these semantics, >> but rather recommend them. > >If I sit down at a client to set certain mode bits or acls I don't want >to have read all the client and server documentation to work out what >those acls actually mean. That sounds like a security nightmare. > >--Bruce Fields > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Tue Feb 3 18:52:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13655 for ; Tue, 3 Feb 2004 18:52:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoAKV-0002uL-Ru for nfsv4-archive@odin.ietf.org; Tue, 03 Feb 2004 18:51:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13NphOb011171 for nfsv4-archive@odin.ietf.org; Tue, 3 Feb 2004 18:51:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoAKV-0002u6-KB for nfsv4-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 18:51:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13649 for ; Tue, 3 Feb 2004 18:51:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoAKS-0001pA-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 18:51:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoAJY-0001kt-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 18:50:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoAIr-0001gC-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 18:50:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoAIs-0002n7-Qy; Tue, 03 Feb 2004 18:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoAIc-0002mX-5F for nfsv4@optimus.ietf.org; Tue, 03 Feb 2004 18:49:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13620 for ; Tue, 3 Feb 2004 18:49:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoAIZ-0001fG-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 18:49:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoAHi-0001aa-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 18:48:50 -0500 Received: from dsl093-002-214.det1.dsl.speakeasy.net ([66.93.2.214] helo=pumpkin.fieldses.org ident=Debian-exim) by ietf-mx with esmtp (Exim 4.12) id 1AoAHP-0001V1-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 18:48:31 -0500 Received: from bfields by pumpkin.fieldses.org with local (Exim 4.30) id 1AoAHC-0004mY-8f; Tue, 03 Feb 2004 18:48:18 -0500 To: "Halevy, Benny" Cc: "'Noveck, Dave'" , nfsv4@ietf.org Subject: Re: [nfsv4] DELETE_CHILD and DELETE Message-ID: <20040203234817.GV15097@fieldses.org> References: <30489F1321F5C343ACF6872B2CF7942A05D38818@PIKES.panasas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30489F1321F5C343ACF6872B2CF7942A05D38818@PIKES.panasas.com> User-Agent: Mutt/1.5.5.1+cvs20040105i From: "J. Bruce Fields" Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Tue, 3 Feb 2004 18:48:18 -0500 Date: Tue, 3 Feb 2004 18:48:18 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,UPPERCASE_25_50 autolearn=no version=2.60 On Tue, Feb 03, 2004 at 06:17:36PM -0500, Halevy, Benny wrote: > I believe that a Posix compliant nfsv4 client should create an ACE for > the file OWNER to allow it ACE4_WRITE_{ATTRIBUTES,ACL} | ACE4_WRITE_OWNER > and an ACE for EVERYONE to allow ACE4_READ_{ATTRIBUTES,ACL} and ACE4_DELETE > (when supported by the server). > ... > I believe that the correct mappings should be: > Posix read: ACE4_READ_DATA | ACE4_LIST_DIRECTORY > Posix write: ACE4_WRITE_DATA | ACE4_ADD_FILE | ACE4_APPEND_DATA | > ACE4_ADD_SUBDIRECTORY | ACE4_DELETE_CHILD > Posix execute: ACE4_READ_DATA | ACE4_LIST_DIRECTORY | ACE4_EXECUTE I agree, except that I think we also need to add READ_NAMED_ATTRIBUTES and WRITE_NAMED_ATTRIBUTES to posix read and posix write, respectively. There's also a problem with WRITE_ATTRIBUTES: if you need it to modify the size, then WRITE_ATTRIBUTES should be set for whoever has write access; but if it also permits modification of mode bits then you give complete control of the file to anyone you give write access to. I think WRITE_ATTRIBUTES should not apply to the size, the mode bit, named attributes, acls, or to any attribute modifications that are a side-effect of some other operation (e.g. writing and reading change modification and (possibly) access times, and unlinking and linking change nlinks, but these operations shouldn't require WRITE_ATTRIBUTES.). Note that GENERIC_READ, GENERIC_WRITE, and GENERIC_EXECUTE are in any case completely wrong; is there any chance of just getting them deleted from the rfc, or is it too late for that? ---Bruce Fields _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Tue Feb 3 20:21:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16000 for ; Tue, 3 Feb 2004 20:21:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoBig-0007U1-H7 for nfsv4-archive@odin.ietf.org; Tue, 03 Feb 2004 20:20:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i141KkEk028759 for nfsv4-archive@odin.ietf.org; Tue, 3 Feb 2004 20:20:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoBig-0007Tm-6j for nfsv4-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 20:20:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15997 for ; Tue, 3 Feb 2004 20:20:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoBie-0002ZG-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 20:20:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoBhl-0002Uo-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 20:19:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoBgy-0002Pj-00 for nfsv4-web-archive@ietf.org; Tue, 03 Feb 2004 20:19:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoBgy-0007QE-Qp; Tue, 03 Feb 2004 20:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoBgn-0007Pq-0W for nfsv4@optimus.ietf.org; Tue, 03 Feb 2004 20:18:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15919 for ; Tue, 3 Feb 2004 20:18:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoBgk-0002Om-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 20:18:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoBfm-0002JC-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 20:17:47 -0500 Received: from gw2.panasas.com ([65.194.124.178] helo=PIKES.panasas.com) by ietf-mx with esmtp (Exim 4.12) id 1AoBes-00029H-00 for nfsv4@ietf.org; Tue, 03 Feb 2004 20:16:50 -0500 Received: by PIKES.panasas.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Feb 2004 20:16:20 -0500 Message-ID: <30489F1321F5C343ACF6872B2CF7942A05D3881A@PIKES.panasas.com> From: "Halevy, Benny" To: "'J. Bruce Fields '" , "Halevy, Benny" Cc: "''Noveck, Dave' '" , "'nfsv4@ietf.org '" Subject: RE: [nfsv4] DELETE_CHILD and DELETE MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Tue, 3 Feb 2004 20:16:19 -0500 Date: Tue, 3 Feb 2004 20:16:19 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,UPPERCASE_25_50 autolearn=no version=2.60 J. Bruce Fields wrote: > > On Tue, Feb 03, 2004 at 06:17:36PM -0500, Halevy, Benny wrote: > > I believe that a Posix compliant nfsv4 client should create an ACE for > > the file OWNER to allow it ACE4_WRITE_{ATTRIBUTES,ACL} | > ACE4_WRITE_OWNER > > and an ACE for EVERYONE to allow ACE4_READ_{ATTRIBUTES,ACL} and ACE4_DELETE > > (when supported by the server). > > ... > > I believe that the correct mappings should be: > > Posix read: ACE4_READ_DATA | ACE4_LIST_DIRECTORY > > Posix write: ACE4_WRITE_DATA | ACE4_ADD_FILE | ACE4_APPEND_DATA | > > ACE4_ADD_SUBDIRECTORY | ACE4_DELETE_CHILD > > Posix execute: ACE4_READ_DATA | ACE4_LIST_DIRECTORY | ACE4_EXECUTE > > I agree, except that I think we also need to add READ_NAMED_ATTRIBUTES and WRITE_NAMED_ATTRIBUTES to posix read and posix write, respectively. How would a POSIX client access named attribtues? I think that it would be acceptable if chmod() or creat() on a posix client leave {READ,WRITE}_NAMED_ATTRIBUTES unchanged and let named attributes capable clients to maintain them. > > There's also a problem with WRITE_ATTRIBUTES: if you need it to modify the size, then WRITE_ATTRIBUTES should be set for whoever has write access; but if it also permits modification of mode bits then you give complete control of the file to anyone you give write access to. I agree. Setting the size is considered a data modifying operation and it makes sense that it will be controlled by ACE4_WRITE_ACL. I'm not absolutely sure whether this should be in addition to ACE4_WRITE_ATTRIBUTES or not. > > I think WRITE_ATTRIBUTES should not apply to the size, the mode bit, named attributes, acls, or to any attribute modifications that are a > side-effect of some other operation (e.g. writing and reading change modification and (possibly) access times, and unlinking and linking change nlinks, but these operations shouldn't require WRITE_ATTRIBUTES.). > > Note that GENERIC_READ, GENERIC_WRITE, and GENERIC_EXECUTE are in any case completely wrong; is there any chance of just getting them deleted from the rfc, or is it too late for that? Good question... If anyone is using them for any other purpose we might want to add POSIX_READ, POSIX_WRITE, and POSIX_EXECUTE. > > ---Bruce Fields > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Wed Feb 4 09:54:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08199 for ; Wed, 4 Feb 2004 09:54:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoOQ7-0001Z4-Ri for nfsv4-archive@odin.ietf.org; Wed, 04 Feb 2004 09:54:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14EsR4O006012 for nfsv4-archive@odin.ietf.org; Wed, 4 Feb 2004 09:54:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoOQ7-0001Yt-My for nfsv4-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 09:54:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08193 for ; Wed, 4 Feb 2004 09:54:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoOQ5-0004hI-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 09:54:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoOP7-0004ad-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 09:53:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoOOl-0004UH-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 09:53:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoOOj-0001U0-1f; Wed, 04 Feb 2004 09:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoONz-0001TO-5Y for nfsv4@optimus.ietf.org; Wed, 04 Feb 2004 09:52:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07996 for ; Wed, 4 Feb 2004 09:52:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoONx-0004RV-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 09:52:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoON3-0004L3-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 09:51:18 -0500 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 1AoOMd-0004FG-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 09:50:52 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i14EoK5B428742 for ; Wed, 4 Feb 2004 09:50:20 -0500 Received: from d03nm124.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i14EoJcj080372 for ; Wed, 4 Feb 2004 07:50:19 -0700 Importance: Normal To: nfsv4@ietf.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Wu Zheng X-MIMETrack: Serialize by Router on D03NM124/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 02/04/2004 07:50:19 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBE4BCDFE0F1BC8f9e8a93df938690918c08BBE4BCDFE0F1BC" Content-Disposition: inline Subject: [nfsv4] anybody support ~HOMOGENEMOUS file system? Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Wed, 4 Feb 2004 08:50:16 -0600 Date: Wed, 4 Feb 2004 08:50:16 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 --0__=08BBE4BCDFE0F1BC8f9e8a93df938690918c08BBE4BCDFE0F1BC Content-type: text/plain; charset=US-ASCII Do any of your nfsv4 server implementations export file systems with the homogeneous attribute set to FALSE? Wu Zheng wzheng@us.ibm.com Phone: (512) 838-0558 T/L: 678-0558 11400 Burnet Road, Austin, TX 78758 --0__=08BBE4BCDFE0F1BC8f9e8a93df938690918c08BBE4BCDFE0F1BC Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Do any of your nfsv4 server implementations export file systems with the homogeneous attribute set to FALSE?

Wu Zheng
wzheng@us.ibm.com
Phone: (512) 838-0558 T/L: 678-0558
11400 Burnet Road, Austin, TX 78758 --0__=08BBE4BCDFE0F1BC8f9e8a93df938690918c08BBE4BCDFE0F1BC-- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Wed Feb 4 10:00:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08399 for ; Wed, 4 Feb 2004 10:00:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoOVq-0001zs-Hx for nfsv4-archive@odin.ietf.org; Wed, 04 Feb 2004 10:00:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14F0Mka007664 for nfsv4-archive@odin.ietf.org; Wed, 4 Feb 2004 10:00:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoOVq-0001zN-BD for nfsv4-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 10:00:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08393 for ; Wed, 4 Feb 2004 10:00:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoOVo-0005FP-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 10:00:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoOUs-00059Y-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 09:59:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoOUW-00053m-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 09:59:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoOUW-0001kJ-Qa; Wed, 04 Feb 2004 09:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoOTm-0001jW-OG for nfsv4@optimus.ietf.org; Wed, 04 Feb 2004 09:58:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08312 for ; Wed, 4 Feb 2004 09:58:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoOTk-00052t-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 09:58:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoOSp-0004yI-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 09:57:16 -0500 Received: from gw2.panasas.com ([65.194.124.178] helo=PIKES.panasas.com) by ietf-mx with esmtp (Exim 4.12) id 1AoOSX-0004tS-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 09:56:57 -0500 Received: by PIKES.panasas.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Feb 2004 09:56:24 -0500 Message-ID: <30489F1321F5C343ACF6872B2CF7942A05D3881B@PIKES.panasas.com> From: "Halevy, Benny" To: "'nfsv4@ietf.org'" Subject: RE: [nfsv4] DELETE_CHILD and DELETE MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Wed, 4 Feb 2004 09:56:23 -0500 Date: Wed, 4 Feb 2004 09:56:23 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,UPPERCASE_25_50 autolearn=no version=2.60 (resending to the alias) -----Original Message----- From: Halevy, Benny Sent: Tuesday, February 03, 2004 8:16 PM To: 'J. Bruce Fields '; Halevy, Benny Cc: ''Noveck, Dave' '; 'nfsv4@ietf.org ' Subject: RE: [nfsv4] DELETE_CHILD and DELETE J. Bruce Fields wrote: > > On Tue, Feb 03, 2004 at 06:17:36PM -0500, Halevy, Benny wrote: > > I believe that a Posix compliant nfsv4 client should create an ACE for > > the file OWNER to allow it ACE4_WRITE_{ATTRIBUTES,ACL} | > ACE4_WRITE_OWNER > > and an ACE for EVERYONE to allow ACE4_READ_{ATTRIBUTES,ACL} and ACE4_DELETE > > (when supported by the server). > > ... > > I believe that the correct mappings should be: > > Posix read: ACE4_READ_DATA | ACE4_LIST_DIRECTORY > > Posix write: ACE4_WRITE_DATA | ACE4_ADD_FILE | ACE4_APPEND_DATA | > > ACE4_ADD_SUBDIRECTORY | ACE4_DELETE_CHILD > > Posix execute: ACE4_READ_DATA | ACE4_LIST_DIRECTORY | ACE4_EXECUTE > > I agree, except that I think we also need to add READ_NAMED_ATTRIBUTES and WRITE_NAMED_ATTRIBUTES to posix read and posix write, respectively. How would a POSIX client access named attribtues? I think that it would be acceptable if chmod() or creat() on a posix client leave {READ,WRITE}_NAMED_ATTRIBUTES unchanged and let named attributes capable clients to maintain them. > > There's also a problem with WRITE_ATTRIBUTES: if you need it to modify the size, then WRITE_ATTRIBUTES should be set for whoever has write access; but if it also permits modification of mode bits then you give complete control of the file to anyone you give write access to. I agree. Setting the size is considered a data modifying operation and it makes sense that it will be controlled by ACE4_WRITE_ACL. I'm not absolutely sure whether this should be in addition to ACE4_WRITE_ATTRIBUTES or not. > > I think WRITE_ATTRIBUTES should not apply to the size, the mode bit, named attributes, acls, or to any attribute modifications that are a > side-effect of some other operation (e.g. writing and reading change modification and (possibly) access times, and unlinking and linking change nlinks, but these operations shouldn't require WRITE_ATTRIBUTES.). > > Note that GENERIC_READ, GENERIC_WRITE, and GENERIC_EXECUTE are in any case completely wrong; is there any chance of just getting them deleted from the rfc, or is it too late for that? Good question... If anyone is using them for any other purpose we might want to add POSIX_READ, POSIX_WRITE, and POSIX_EXECUTE. > > ---Bruce Fields > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Wed Feb 4 10:58:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12239 for ; Wed, 4 Feb 2004 10:58:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPPx-0004i4-MD for nfsv4-archive@odin.ietf.org; Wed, 04 Feb 2004 10:58:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14FwL4d018104 for nfsv4-archive@odin.ietf.org; Wed, 4 Feb 2004 10:58:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPPx-0004hv-HC for nfsv4-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 10:58:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12235 for ; Wed, 4 Feb 2004 10:58:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoPPv-0003kc-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 10:58:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoPP0-0003fF-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 10:57:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoPOe-0003Zi-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 10:57:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPOf-0004aL-Cm; Wed, 04 Feb 2004 10:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoPO3-0004ZI-I0 for nfsv4@optimus.ietf.org; Wed, 04 Feb 2004 10:56:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12152 for ; Wed, 4 Feb 2004 10:56:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoPO0-0003Yc-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 10:56:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoPNA-0003T9-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 10:55:28 -0500 Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx with esmtp (Exim 4.12) id 1AoPMh-0003MD-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 10:54:59 -0500 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i14FsSpZ810542 for ; Wed, 4 Feb 2004 10:54:28 -0500 Received: from d03nm130.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i14FsQOA083324 for ; Wed, 4 Feb 2004 08:54:27 -0700 To: nfsv4@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Carl Burnett X-MIMETrack: Serialize by Router on D03NM130/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 02/04/2004 08:54:26, Serialize complete at 02/04/2004 08:54:26 Content-Type: text/plain; charset="US-ASCII" Subject: [nfsv4] RENAME and NFS4ERR_ISDIR Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Wed, 4 Feb 2004 09:54:25 -0600 Date: Wed, 4 Feb 2004 09:54:25 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 The RENAME operation does not list NFS4ERR_ISDIR as a valid error. POSIX states that if you try to rename a file to a directory (oldpath is file, newpath is a dir), EISDIR should be returned. Without allowing NFS4ERR_ISDIR as a valid return, the POSIX behavior cannot be achieved with NFSv4. Currently, the spec seems to suggest that NFS4ERR_EXIST should be returned. - "If they are not compatible or if the target is a directory but not empty, the server will return the error, NFS4ERR_EXIST." We noticed in testing with the Solaris beta download, that the server looks to be returning NFS4ERR_ISDIR in this case, which per the spec would be non-compliant. But of course, it allows POSIX behavior. What's the correct thing to do. I think NFS4ERR_ISDIR should be allowed for RENAME. Thanks, Carl Carl Burnett AIX Kernel Architecture - Network File System (512) 838-8498, TL 678-8498 (please reply to cburnett@us.ibm.com) _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Wed Feb 4 12:03:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14732 for ; Wed, 4 Feb 2004 12:03:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQQt-0002Hm-Ss for nfsv4-archive@odin.ietf.org; Wed, 04 Feb 2004 12:03:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14H3Nqa008785 for nfsv4-archive@odin.ietf.org; Wed, 4 Feb 2004 12:03:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQQt-0002Hc-Kw for nfsv4-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 12:03:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14709 for ; Wed, 4 Feb 2004 12:03:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoQQs-0002j8-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 12:03:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoQPu-0002dL-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 12:02:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoQPN-0002Xv-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 12:01:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQOp-0001tV-5f; Wed, 04 Feb 2004 12:01:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQNs-0001f8-4x for nfsv4@optimus.ietf.org; Wed, 04 Feb 2004 12:00:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14627 for ; Wed, 4 Feb 2004 12:00:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoQNq-0002QB-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 12:00:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoQMs-0002KV-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 11:59:15 -0500 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1AoQLx-0002B0-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 11:58:17 -0500 Received: from hawk.corp.netapp.com (hawk [10.57.156.122]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i14GvkKw011011; Wed, 4 Feb 2004 08:57:46 -0800 (PST) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.10.22.171]) by hawk.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i14GvkRh001408; Wed, 4 Feb 2004 08:57:46 -0800 (PST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [nfsv4] RENAME and NFS4ERR_ISDIR Message-ID: Thread-Topic: [nfsv4] RENAME and NFS4ERR_ISDIR Thread-Index: AcPrN4/ggGzgqeLNRm6acLrnp83QrgAANFTQ From: "Noveck, Dave" To: "Carl Burnett" , Content-Transfer-Encoding: quoted-printable Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Wed, 4 Feb 2004 08:57:40 -0800 Date: Wed, 4 Feb 2004 08:57:40 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > What's the correct thing to do. I think NFS4ERR_ISDIR should be = allowed=20 > for RENAME. I agree but how (procedurally) do we make that happen? RFC 3530 is set in stone but is it sandstone, granite, or what? I assume we can address stuff like that in v4.1 (in addition to the bigger stuff like sessions and directory delegation) but how can we change v4.0, in the meantime? Making this change doesn't really cause an incompatibility. Nobody, except a hypothetical test suite would be depending on NFS4ERR_ISDIR=20 not being returned by RENAME. Supposing that this clears the first hurdle, of the working group thinking this is a good thing to do, what other hurdles are there? =20 -----Original Message----- From: Carl Burnett [mailto:cburnett@us.ibm.com] Sent: Wednesday, February 04, 2004 10:54 AM To: nfsv4@ietf.org Subject: [nfsv4] RENAME and NFS4ERR_ISDIR The RENAME operation does not list NFS4ERR_ISDIR as a valid error.=20 POSIX states that if you try to rename a file to a directory (oldpath is = file, newpath is a dir), EISDIR should be returned. Without allowing=20 NFS4ERR_ISDIR as a valid return, the POSIX behavior cannot be achieved=20 with NFSv4. Currently, the spec seems to suggest that NFS4ERR_EXIST should be=20 returned. - "If they are not compatible or if the target is a directory but = not empty, the server will return the error, NFS4ERR_EXIST." We noticed in testing with the Solaris beta download, that the server=20 looks to be returning NFS4ERR_ISDIR in this case, which per the spec = would=20 be non-compliant. But of course, it allows POSIX behavior. What's the correct thing to do. I think NFS4ERR_ISDIR should be allowed=20 for RENAME. Thanks, Carl Carl Burnett AIX Kernel Architecture - Network File System (512) 838-8498, TL 678-8498 (please reply to cburnett@us.ibm.com) _______________________________________________ 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 From exim@www1.ietf.org Wed Feb 4 12:35:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16548 for ; Wed, 4 Feb 2004 12:35:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQv3-0005RC-Fp for nfsv4-archive@odin.ietf.org; Wed, 04 Feb 2004 12:34:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14HYXVJ020901 for nfsv4-archive@odin.ietf.org; Wed, 4 Feb 2004 12:34:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQv3-0005R2-7h for nfsv4-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 12:34:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16507 for ; Wed, 4 Feb 2004 12:34:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoQv1-0006HD-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 12:34:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoQuD-0006A0-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 12:33:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoQtY-000620-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 12:33:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQtY-0005NB-IE; Wed, 04 Feb 2004 12:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQt8-0005MK-2L for nfsv4@optimus.ietf.org; Wed, 04 Feb 2004 12:32:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16318 for ; Wed, 4 Feb 2004 12:32:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoQt6-0005zE-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 12:32:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoQsJ-0005r3-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 12:31:44 -0500 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 1AoQrX-0005d4-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 12:30:55 -0500 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i14HUO5B316068; Wed, 4 Feb 2004 12:30:24 -0500 Received: from d03nm124.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i14HUMOA090212; Wed, 4 Feb 2004 10:30:22 -0700 Importance: Normal Subject: RE: [nfsv4] DELETE_CHILD and DELETE To: "Halevy, Benny" Cc: "'nfsv4@ietf.org'" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Wu Zheng X-MIMETrack: Serialize by Router on D03NM124/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 02/04/2004 10:30:22 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBE4A3DFCD6F728f9e8a93df938690918c08BBE4A3DFCD6F72" Content-Disposition: inline Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Wed, 4 Feb 2004 11:30:18 -0600 Date: Wed, 4 Feb 2004 11:30:18 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_MESSAGE, UPPERCASE_25_50 autolearn=no version=2.60 --0__=08BBE4A3DFCD6F728f9e8a93df938690918c08BBE4A3DFCD6F72 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I agree with what you have. I want to add the following. A user can alter a file's mode or ACL only when he/she has the ACE4_WRITE_ACL permission. A file's mode can be read when the user has ACE4_READ_ATTRIBUTES or ACE4_READ_ACL permission. A file's ACL can be read when the user has ACE4_READ_ACL permission. Wu Zheng wzheng@us.ibm.com Phone: (512) 838-0558 T/L: 678-0558 11400 Burnet Road, Austin, TX 78758 "Halevy, Benny" @ietf.org on 02/04/2004 08:56:23 A= M Sent by: nfsv4-admin@ietf.org To: "'nfsv4@ietf.org'" cc: Subject: RE: [nfsv4] DELETE_CHILD and DELETE (resending to the alias) -----Original Message----- From: Halevy, Benny Sent: Tuesday, February 03, 2004 8:16 PM To: 'J. Bruce Fields '; Halevy, Benny Cc: ''Noveck, Dave' '; 'nfsv4@ietf.org ' Subject: RE: [nfsv4] DELETE_CHILD and DELETE J. Bruce Fields wrote: > > On Tue, Feb 03, 2004 at 06:17:36PM -0500, Halevy, Benny wrote: > > I believe that a Posix compliant nfsv4 client should create an ACE = for > > the file OWNER to allow it ACE4_WRITE_{ATTRIBUTES,ACL} | > ACE4_WRITE_OWNER > > and an ACE for EVERYONE to allow ACE4_READ_{ATTRIBUTES,ACL} and ACE4_DELETE > > (when supported by the server). > > ... > > I believe that the correct mappings should be: > > Posix read: ACE4_READ_DATA | ACE4_LIST_DIRECTORY > > Posix write: ACE4_WRITE_DATA | ACE4_ADD_FILE | ACE4_APPEND_DATA = | > > ACE4_ADD_SUBDIRECTORY | ACE4_DELETE_CHILD > > Posix execute: ACE4_READ_DATA | ACE4_LIST_DIRECTORY | ACE4_EXECUTE= > > I agree, except that I think we also need to add READ_NAMED_ATTRIBUTE= S and WRITE_NAMED_ATTRIBUTES to posix read and posix write, respectively.= How would a POSIX client access named attribtues? I think that it would be acceptable if chmod() or creat() on a posix cl= ient leave {READ,WRITE}_NAMED_ATTRIBUTES unchanged and let named attributes capable clients to maintain them. > > There's also a problem with WRITE_ATTRIBUTES: if you need it to modif= y the size, then WRITE_ATTRIBUTES should be set for whoever has write acc= ess; but if it also permits modification of mode bits then you give complete= control of the file to anyone you give write access to. I agree. Setting the size is considered a data modifying operation and it makes sense that it will be controlled by ACE4_WRITE_ACL. I'm not absolutely sure whether this should be in addition to ACE4_WRITE_ATTRIBUTES or not. > > I think WRITE_ATTRIBUTES should not apply to the size, the mode bit, named attributes, acls, or to any attribute modifications that are a > side-effect of some other operation (e.g. writing and reading change modification and (possibly) access times, and unlinking and linking cha= nge nlinks, but these operations shouldn't require WRITE_ATTRIBUTES.). > > Note that GENERIC_READ, GENERIC_WRITE, and GENERIC_EXECUTE are in any= case completely wrong; is there any chance of just getting them deleted= from the rfc, or is it too late for that? Good question... If anyone is using them for any other purpose we migh= t want to add POSIX_READ, POSIX_WRITE, and POSIX_EXECUTE. > > ---Bruce Fields > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 = --0__=08BBE4A3DFCD6F728f9e8a93df938690918c08BBE4A3DFCD6F72 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

I agree with what you have. I want to add the following.

A user can alter a file's mode or ACL only when he/she has the ACE4_WRI= TE_ACL permission.
A file's mode can be read when the user has ACE4_READ_ATTRIBUTES or ACE= 4_READ_ACL permission.
A file's ACL can be read when the user has ACE4_READ_ACL permission.

Wu Zheng
wzheng@us.ibm.com
Phone: (512) 838-0558 T/L: 678-0558
11400 Burnet Road, Austin, TX 78758

Sent by: nfsv4-admin@ietf.org

To: "= ;'nfsv4@ietf.org'" <nfsv4@ietf.org>
cc:
Subject: RE:= [nfsv4] DELETE_CHILD and DELETE


(resending to the alias)

-----Original Message-----
From: Halevy, Benny
Sent: Tuesday, February 03, 2004 8:16 PM
To: 'J. Bruce Fields '; Halevy, Benny
Cc: ''Noveck, Dave' '; 'nfsv4@ietf.org '
Subject: RE: [nfsv4] DELETE_CHILD and DELETE


J. Bruce Fields wrote:
>
> On Tue, Feb 03, 2004 at 06:17:36PM -0500, Halevy, Benny wrote:
= > > I believe that a Posix compliant nfsv4 client should create a= n ACE for
> > the file OWNER to allow it ACE4_WRITE_{ATTRIBUTES,ACL} |
> ACE4_WRITE_OWNER
> > and an ACE for EVERYONE to allow ACE4_READ_{ATTRIBUTES,ACL} a= nd ACE4_DELETE
> > (when supported by the server).
> > ...
> > I believe that the correct mappings should be:
> > Posix read: ACE4_READ_DATA | ACE4_LIST_DIRECTORY
> > Posix write: ACE4_WRITE_DATA | ACE4_ADD_FILE | ACE4_APPEND= _DATA |
> > ACE4_ADD_SUBDIRECTORY | ACE4_DELETE_CHILD
= > > Posix execute: ACE4_READ_DATA | ACE4_LIST_DIRECTORY | ACE4_E= XECUTE
>
> I agree, except that I think we also need to add READ_NAMED_ATTRIB= UTES and WRITE_NAMED_ATTRIBUTES to posix read and posix write, respecti= vely.

How would a POSIX client access named attribtues?
I think that it would be acceptable if chmod() or creat() on a posix cl= ient leave {READ,WRITE}_NAMED_ATTRIBUTES unchanged and let named attrib= utes capable clients to maintain them.

>
> There's also a problem with WRITE_ATTRIBUTES: if you need it to mo= dify the size, then WRITE_ATTRIBUTES should be set for whoever has writ= e access; but if it also permits modification of mode bits then you giv= e complete control of the file to anyone you give write access to.

I agree. Setting the size is considered a data modifying operation
= and it makes sense that it will be controlled by ACE4_WRITE_ACL.
I'm not absolutely sure whether this should be in addition to ACE4_WRIT= E_ATTRIBUTES or not.

>
> I think WRITE_ATTRIBUTES should not apply to the size, the mode bi= t, named attributes, acls, or to any attribute modifications that are a=
> side-effect of some other operation (e.g. writing and reading chan= ge modification and (possibly) access times, and unlinking and linking = change nlinks, but these operations shouldn't require
WRITE_ATTRIBUTES.).
>
> Note that GENERIC_READ, GENERIC_WRITE, and GENERIC_EXECUTE are in = any case completely wrong; is there any chance of just getting them del= eted from the rfc, or is it too late for that?

Good question... If anyone is using them for any other purpose we migh= t want to add POSIX_READ, POSIX_WRITE, and POSIX_EXECUTE.

>
> ---Bruce Fields
>

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


= --0__=08BBE4A3DFCD6F728f9e8a93df938690918c08BBE4A3DFCD6F72-- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Wed Feb 4 12:36:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16641 for ; Wed, 4 Feb 2004 12:36:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQwq-0005dL-8o for nfsv4-archive@odin.ietf.org; Wed, 04 Feb 2004 12:36:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14HaOB0021649 for nfsv4-archive@odin.ietf.org; Wed, 4 Feb 2004 12:36:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQwq-0005d6-0m for nfsv4-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 12:36:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16634 for ; Wed, 4 Feb 2004 12:36:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoQwo-0006Ub-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 12:36:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoQw7-0006PK-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 12:35:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoQvV-0006In-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 12:35:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQvV-0005SP-VD; Wed, 04 Feb 2004 12:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoQuq-0005Qr-5j for nfsv4@optimus.ietf.org; Wed, 04 Feb 2004 12:34:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16459 for ; Wed, 4 Feb 2004 12:34:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoQuo-0006FM-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 12:34:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoQtq-00066k-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 12:33:19 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AoQst-0005xI-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 12:32:19 -0500 Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i14HWIi5003754; Wed, 4 Feb 2004 10:32:18 -0700 (MST) Received: from [192.168.0.4] (vpn-129-150-16-208.SFBay.Sun.COM [129.150.16.208]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i14HWHCl007468; Wed, 4 Feb 2004 09:32:17 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <48FBB9BE-5738-11D8-B479-000A95DBCB70@sun.com> Content-Transfer-Encoding: 7bit Cc: , "Carl Burnett" From: Spencer Shepler Subject: Re: [nfsv4] RENAME and NFS4ERR_ISDIR To: "Noveck, Dave" X-Mailer: Apple Mail (2.609) Content-Transfer-Encoding: 7bit Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Wed, 4 Feb 2004 11:33:46 -0600 Date: Wed, 4 Feb 2004 11:33:46 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Note, we are able to submit RFC errata for this type of change. We have one or two other error code changes that have been mentioned in the past that should be included in the errata as well. Spencer On Feb 4, 2004, at 10:57 AM, Noveck, Dave wrote: >> What's the correct thing to do. I think NFS4ERR_ISDIR should be >> allowed >> for RENAME. > > I agree but how (procedurally) do we make that happen? > > RFC 3530 is set in stone but is it sandstone, granite, or what? > > I assume we can address stuff like that in v4.1 (in addition to > the bigger stuff like sessions and directory delegation) but how > can we change v4.0, in the meantime? > > Making this change doesn't really cause an incompatibility. Nobody, > except a hypothetical test suite would be depending on NFS4ERR_ISDIR > not being returned by RENAME. Supposing that this clears the first > hurdle, of the working group thinking this is a good thing to do, > what other hurdles are there? > > > > -----Original Message----- > From: Carl Burnett [mailto:cburnett@us.ibm.com] > Sent: Wednesday, February 04, 2004 10:54 AM > To: nfsv4@ietf.org > Subject: [nfsv4] RENAME and NFS4ERR_ISDIR > > > The RENAME operation does not list NFS4ERR_ISDIR as a valid error. > > POSIX states that if you try to rename a file to a directory (oldpath > is > file, newpath is a dir), EISDIR should be returned. Without allowing > NFS4ERR_ISDIR as a valid return, the POSIX behavior cannot be achieved > with NFSv4. > > Currently, the spec seems to suggest that NFS4ERR_EXIST should be > returned. - > > "If they are not compatible or if the target is a directory > but > not empty, the server will return the error, NFS4ERR_EXIST." > > We noticed in testing with the Solaris beta download, that the server > looks to be returning NFS4ERR_ISDIR in this case, which per the spec > would > be non-compliant. But of course, it allows POSIX behavior. > > What's the correct thing to do. I think NFS4ERR_ISDIR should be allowed > for RENAME. > > Thanks, > Carl > > > Carl Burnett > AIX Kernel Architecture - Network File System > (512) 838-8498, TL 678-8498 > (please reply to cburnett@us.ibm.com) > > > _______________________________________________ > 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 > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Wed Feb 4 13:10:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18575 for ; Wed, 4 Feb 2004 13:10:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoRTp-0000Yp-EI for nfsv4-archive@odin.ietf.org; Wed, 04 Feb 2004 13:10:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14IATEY002152 for nfsv4-archive@odin.ietf.org; Wed, 4 Feb 2004 13:10:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoRTp-0000Yd-2X for nfsv4-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 13:10:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18564 for ; Wed, 4 Feb 2004 13:10:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoRTn-0002no-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 13:10:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoRTA-0002hl-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 13:09:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoRSP-0002am-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 13:09:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoRSO-0000QV-Rt; Wed, 04 Feb 2004 13:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoRRr-0000Oy-Ty for nfsv4@optimus.ietf.org; Wed, 04 Feb 2004 13:08:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18440 for ; Wed, 4 Feb 2004 13:08:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoRRp-0002Xa-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 13:08:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoRQw-0002OZ-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 13:07:31 -0500 Received: from dsl093-002-214.det1.dsl.speakeasy.net ([66.93.2.214] helo=pumpkin.fieldses.org ident=Debian-exim) by ietf-mx with esmtp (Exim 4.12) id 1AoRPx-0002DS-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 13:06:29 -0500 Received: from bfields by pumpkin.fieldses.org with local (Exim 4.30) id 1AoRPt-00068R-EG; Wed, 04 Feb 2004 13:06:25 -0500 To: "Halevy, Benny" Cc: "''Noveck, Dave' '" , "'nfsv4@ietf.org '" Subject: Re: [nfsv4] DELETE_CHILD and DELETE Message-ID: <20040204180624.GC22875@fieldses.org> References: <30489F1321F5C343ACF6872B2CF7942A05D3881A@PIKES.panasas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30489F1321F5C343ACF6872B2CF7942A05D3881A@PIKES.panasas.com> User-Agent: Mutt/1.5.5.1+cvs20040105i From: "J. Bruce Fields" Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Wed, 4 Feb 2004 13:06:25 -0500 Date: Wed, 4 Feb 2004 13:06:25 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, Feb 03, 2004 at 08:16:19PM -0500, Halevy, Benny wrote: > J. Bruce Fields wrote: > > > > On Tue, Feb 03, 2004 at 06:17:36PM -0500, Halevy, Benny wrote: > > > I believe that the correct mappings should be: > > > Posix read: ACE4_READ_DATA | ACE4_LIST_DIRECTORY > > > Posix write: ACE4_WRITE_DATA | ACE4_ADD_FILE | ACE4_APPEND_DATA | > > > ACE4_ADD_SUBDIRECTORY | ACE4_DELETE_CHILD > > > Posix execute: ACE4_READ_DATA | ACE4_LIST_DIRECTORY | ACE4_EXECUTE > > > > I agree, except that I think we also need to add READ_NAMED_ATTRIBUTES > > and WRITE_NAMED_ATTRIBUTES to posix read and posix write, respectively. > > How would a POSIX client access named attribtues? That's not standardized as far as I know, but I'm assuming that POSIX clients that implement named attributes expect them to be treated like file/directory data for permissions purposes. I believe this is true at least on Linux and FreeBSD. > I think that it would be acceptable if chmod() or creat() on a posix > client leave {READ,WRITE}_NAMED_ATTRIBUTES unchanged and let named > attributes capable clients to maintain them. The problem is that a server using POSIX ACL's on the exported filesystem to implement a subset of NFSv4 ACL's can't leave it to clients to maintain the NAMED_ATTRIBUTES bits because the server doesn't have any way of storing the NAMED_ATTRIBUTES bits; it's stuck mapping an incoming NFSv4 ACL to a POSIX ACL and then mapping back when it retrieves the ACL. So it's going to have to return an ACL that consistently either includes the NAMED_ATTRIBUTES bits or doesn't. I believe the latter default makes more sense. > > Note that GENERIC_READ, GENERIC_WRITE, and GENERIC_EXECUTE are in > > any case completely wrong; is there any chance of just getting them > > deleted from the rfc, or is it too late for that? > > Good question... If anyone is using them for any other purpose we > might want to add POSIX_READ, POSIX_WRITE, and POSIX_EXECUTE. I don't know of any purpose that anyone could be using them for that would be correct. They aren't referred to anywhere in the rfc outside their definition, so deleting them should be trivial. It would be easy for a reader of the rfc to get the impression that they provide a sensible way of synchronizing ACL's with mode bits, but they don't, so they seem like a trap for unwary implementors. --Bruce Fields _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Wed Feb 4 13:12:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18736 for ; Wed, 4 Feb 2004 13:12:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoRVl-0000ls-Tt for nfsv4-archive@odin.ietf.org; Wed, 04 Feb 2004 13:12:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14ICTnX002958 for nfsv4-archive@odin.ietf.org; Wed, 4 Feb 2004 13:12:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoRVl-0000ld-PI for nfsv4-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 13:12:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18709 for ; Wed, 4 Feb 2004 13:12:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoRVj-00031b-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 13:12:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoRUt-0002ve-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 13:11:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoRUK-0002ot-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 13:11:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoRUL-0000bA-Pw; Wed, 04 Feb 2004 13:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoRTi-0000YI-0X for nfsv4@optimus.ietf.org; Wed, 04 Feb 2004 13:10:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18545 for ; Wed, 4 Feb 2004 13:10:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoRTg-0002mf-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 13:10:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoRSy-0002fs-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 13:09:36 -0500 Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx with esmtp (Exim 4.12) id 1AoRRv-0002S1-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 13:08:31 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i14I80pZ653534; Wed, 4 Feb 2004 13:08:01 -0500 Received: from d03nm130.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i14I80cj120156; Wed, 4 Feb 2004 11:08:00 -0700 In-Reply-To: <48FBB9BE-5738-11D8-B479-000A95DBCB70@sun.com> To: Spencer Shepler Cc: nfsv4@ietf.org MIME-Version: 1.0 Subject: Re: [nfsv4] RENAME and NFS4ERR_ISDIR X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Carl Burnett X-MIMETrack: Serialize by Router on D03NM130/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 02/04/2004 11:08:00, Serialize complete at 02/04/2004 11:08:00 Content-Type: text/plain; charset="US-ASCII" Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Wed, 4 Feb 2004 12:07:58 -0600 Date: Wed, 4 Feb 2004 12:07:58 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Can this get done ASAP. I would like to change our server with the comfort that its in spec. I would also like to know what the other errors you refer to below are. Thanks, Carl Carl Burnett AIX Kernel Architecture - Network File System (512) 838-8498, TL 678-8498 (please reply to cburnett@us.ibm.com) Spencer Shepler Sent by: nfsv4-admin@ietf.org 02/04/2004 11:33 AM To: "Noveck, Dave" cc: , Carl Burnett/Austin/IBM@IBMUS Subject: Re: [nfsv4] RENAME and NFS4ERR_ISDIR Note, we are able to submit RFC errata for this type of change. We have one or two other error code changes that have been mentioned in the past that should be included in the errata as well. Spencer On Feb 4, 2004, at 10:57 AM, Noveck, Dave wrote: >> What's the correct thing to do. I think NFS4ERR_ISDIR should be >> allowed >> for RENAME. > > I agree but how (procedurally) do we make that happen? > > RFC 3530 is set in stone but is it sandstone, granite, or what? > > I assume we can address stuff like that in v4.1 (in addition to > the bigger stuff like sessions and directory delegation) but how > can we change v4.0, in the meantime? > > Making this change doesn't really cause an incompatibility. Nobody, > except a hypothetical test suite would be depending on NFS4ERR_ISDIR > not being returned by RENAME. Supposing that this clears the first > hurdle, of the working group thinking this is a good thing to do, > what other hurdles are there? > > > > -----Original Message----- > From: Carl Burnett [mailto:cburnett@us.ibm.com] > Sent: Wednesday, February 04, 2004 10:54 AM > To: nfsv4@ietf.org > Subject: [nfsv4] RENAME and NFS4ERR_ISDIR > > > The RENAME operation does not list NFS4ERR_ISDIR as a valid error. > > POSIX states that if you try to rename a file to a directory (oldpath > is > file, newpath is a dir), EISDIR should be returned. Without allowing > NFS4ERR_ISDIR as a valid return, the POSIX behavior cannot be achieved > with NFSv4. > > Currently, the spec seems to suggest that NFS4ERR_EXIST should be > returned. - > > "If they are not compatible or if the target is a directory > but > not empty, the server will return the error, NFS4ERR_EXIST." > > We noticed in testing with the Solaris beta download, that the server > looks to be returning NFS4ERR_ISDIR in this case, which per the spec > would > be non-compliant. But of course, it allows POSIX behavior. > > What's the correct thing to do. I think NFS4ERR_ISDIR should be allowed > for RENAME. > > Thanks, > Carl > > > Carl Burnett > AIX Kernel Architecture - Network File System > (512) 838-8498, TL 678-8498 > (please reply to cburnett@us.ibm.com) > > > _______________________________________________ > 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 > _______________________________________________ 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 From exim@www1.ietf.org Wed Feb 4 14:08:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20534 for ; Wed, 4 Feb 2004 14:08:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoSNu-0003iL-Ex for nfsv4-archive@odin.ietf.org; Wed, 04 Feb 2004 14:08:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14J8Qdb014271 for nfsv4-archive@odin.ietf.org; Wed, 4 Feb 2004 14:08:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoSNu-0003i6-8w for nfsv4-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 14:08:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20531 for ; Wed, 4 Feb 2004 14:08:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoSNr-0000Ro-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 14:08:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoSN3-0000Mr-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 14:07:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoSMW-0000H2-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 14:07:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoSMX-0003ME-3y; Wed, 04 Feb 2004 14:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoSLs-0003KW-04 for nfsv4@optimus.ietf.org; Wed, 04 Feb 2004 14:06:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20501 for ; Wed, 4 Feb 2004 14:06:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoSLp-0000Fu-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 14:06:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoSKs-0000Ag-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 14:05:19 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AoSK1-00000G-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 14:04:25 -0500 Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i14J3t0J016093; Wed, 4 Feb 2004 11:03:55 -0800 (PST) Received: from [129.153.128.227] (dhcp-uaus08-128-227.Central.Sun.COM [129.153.128.227]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i14J3sCl028866; Wed, 4 Feb 2004 11:03:55 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <159D2E02-5745-11D8-B4EE-000A95DBCB70@sun.com> Content-Transfer-Encoding: 7bit Cc: nfsv4@ietf.org From: Spencer Shepler Subject: Re: [nfsv4] RENAME and NFS4ERR_ISDIR To: Carl Burnett X-Mailer: Apple Mail (2.609) Content-Transfer-Encoding: 7bit Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Wed, 4 Feb 2004 13:05:23 -0600 Date: Wed, 4 Feb 2004 13:05:23 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit First we need to ensure we have WG consensus on this and other proposed errata and this will include approval of the authors. :-) We can then submit the errata to the RFC editor. Not sure how long it takes for them to post the errata. In general, once we have consensus on the WG and it is is in the archives, then it is a matter of process and that shouldn't hold anyone's implementation plans, IMO. Spencer On Feb 4, 2004, at 12:07 PM, Carl Burnett wrote: > Can this get done ASAP. I would like to change our server with the > comfort > that its in spec. I would also like to know what the other errors you > refer to below are. > > Thanks, > Carl > > Carl Burnett > AIX Kernel Architecture - Network File System > (512) 838-8498, TL 678-8498 > (please reply to cburnett@us.ibm.com) > > > > > > Spencer Shepler > Sent by: nfsv4-admin@ietf.org > 02/04/2004 11:33 AM > > To: "Noveck, Dave" > cc: , Carl Burnett/Austin/IBM@IBMUS > Subject: Re: [nfsv4] RENAME and NFS4ERR_ISDIR > > > > Note, we are able to submit RFC errata for this type of change. We > have one > or two other error code changes that have been mentioned in the past > that should be included in the errata as well. > > Spencer > > On Feb 4, 2004, at 10:57 AM, Noveck, Dave wrote: > >>> What's the correct thing to do. I think NFS4ERR_ISDIR should be >>> allowed >>> for RENAME. >> >> I agree but how (procedurally) do we make that happen? >> >> RFC 3530 is set in stone but is it sandstone, granite, or what? >> >> I assume we can address stuff like that in v4.1 (in addition to >> the bigger stuff like sessions and directory delegation) but how >> can we change v4.0, in the meantime? >> >> Making this change doesn't really cause an incompatibility. Nobody, >> except a hypothetical test suite would be depending on NFS4ERR_ISDIR >> not being returned by RENAME. Supposing that this clears the first >> hurdle, of the working group thinking this is a good thing to do, >> what other hurdles are there? >> >> >> >> -----Original Message----- >> From: Carl Burnett [mailto:cburnett@us.ibm.com] >> Sent: Wednesday, February 04, 2004 10:54 AM >> To: nfsv4@ietf.org >> Subject: [nfsv4] RENAME and NFS4ERR_ISDIR >> >> >> The RENAME operation does not list NFS4ERR_ISDIR as a valid error. >> >> POSIX states that if you try to rename a file to a directory (oldpath >> is >> file, newpath is a dir), EISDIR should be returned. Without allowing >> NFS4ERR_ISDIR as a valid return, the POSIX behavior cannot be achieved >> with NFSv4. >> >> Currently, the spec seems to suggest that NFS4ERR_EXIST should be >> returned. - >> >> "If they are not compatible or if the target is a directory >> but >> not empty, the server will return the error, NFS4ERR_EXIST." >> >> We noticed in testing with the Solaris beta download, that the server >> looks to be returning NFS4ERR_ISDIR in this case, which per the spec >> would >> be non-compliant. But of course, it allows POSIX behavior. >> >> What's the correct thing to do. I think NFS4ERR_ISDIR should be >> allowed >> for RENAME. >> >> Thanks, >> Carl >> >> >> Carl Burnett >> AIX Kernel Architecture - Network File System >> (512) 838-8498, TL 678-8498 >> (please reply to cburnett@us.ibm.com) >> >> >> _______________________________________________ >> 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 >> > > > _______________________________________________ > 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 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Wed Feb 4 16:47:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02104 for ; Wed, 4 Feb 2004 16:47:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoUr3-0001mG-7o for nfsv4-archive@odin.ietf.org; Wed, 04 Feb 2004 16:46:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14Lkf2h006828 for nfsv4-archive@odin.ietf.org; Wed, 4 Feb 2004 16:46:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoUr3-0001m3-1U for nfsv4-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 16:46:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02022 for ; Wed, 4 Feb 2004 16:46:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoUr1-0003zD-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 16:46:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoUpm-0003hS-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 16:45:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoUoT-0003RP-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 16:44:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoUoT-0001b3-1h; Wed, 04 Feb 2004 16:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoUnt-0001aI-5G for nfsv4@optimus.ietf.org; Wed, 04 Feb 2004 16:43:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01691 for ; Wed, 4 Feb 2004 16:43:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoUnr-0003Kz-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 16:43:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoUmy-0003EW-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 16:42:28 -0500 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1AoUmH-00039X-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 16:41:46 -0500 Received: from user-38lc198.dialup.mindspring.com ([209.86.5.40] helo=earthlink.net) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AoUmF-0004fc-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 13:41:44 -0800 Message-ID: <40214931.CA79E9FE@earthlink.net> From: Erblichs X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: nfsv4@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nfsv4] Regular files and holes (non-contiguous) Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Wed, 04 Feb 2004 11:34:09 -0800 Date: Wed, 04 Feb 2004 11:34:09 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi group, I must be going blind, but I don't see the NFSv4 spec covering how to do the opposite functionalities when it comes to holes. FYI, holes are caused when a regular file has multiple operations where a byte has been written at a specific offset and then the offset has been increased and additional writes are done. The creation of a hole is done to allow a regular file object to be created that is larger than the FS itself and/or to minimize the allotment of file system pages for non contigous pages. These holes also should decrease the amount of time for the writes to occur. However, if this hole is written with NULLs or whatever, then a reservation mechanism is encountered as a secondary effect. So, with the spec, am I missing something that allows me to specify commit of previous writes to the regular file with and without holes. Thanks, Mitchell Erblich Sr. Software Engineer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Wed Feb 4 22:21:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16176 for ; Wed, 4 Feb 2004 22:21:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoa4F-0006Cy-66 for nfsv4-archive@odin.ietf.org; Wed, 04 Feb 2004 22:20:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i153Kd7J023861 for nfsv4-archive@odin.ietf.org; Wed, 4 Feb 2004 22:20:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoa4E-0006Cm-Vq for nfsv4-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 22:20:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16172 for ; Wed, 4 Feb 2004 22:20:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoa4B-0006jM-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 22:20:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoa3F-0006el-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 22:19:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aoa2f-0006a5-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 22:19:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoa2f-000671-EK; Wed, 04 Feb 2004 22:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoa2I-00066c-Vs for nfsv4@optimus.ietf.org; Wed, 04 Feb 2004 22:18:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16125 for ; Wed, 4 Feb 2004 22:18:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoa2F-0006Zg-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 22:18:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoa1J-0006VD-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 22:17:38 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1Aoa0u-0006QN-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 22:17:12 -0500 Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i153GgdO008337; Wed, 4 Feb 2004 19:16:42 -0800 (PST) Received: from [129.153.128.227] (dhcp-uaus08-128-227.Central.Sun.COM [129.153.128.227]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i153G3OS021694; Wed, 4 Feb 2004 19:16:04 -0800 (PST) In-Reply-To: <40214931.CA79E9FE@earthlink.net> References: <40214931.CA79E9FE@earthlink.net> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: nfsv4@ietf.org From: Spencer Shepler Subject: Re: [nfsv4] Regular files and holes (non-contiguous) To: Erblichs X-Mailer: Apple Mail (2.609) Content-Transfer-Encoding: 7bit Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Wed, 4 Feb 2004 21:18:10 -0600 Date: Wed, 4 Feb 2004 21:18:10 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The protocol allows for writes to any offset within the server's support maximum file size. Write do not have to be done contiguously; the same has been true of NFSv2/v3. There is no protocol mechanism for determining if a hole exists in a particular file. If the client reads a range of the file that is actually a hole, the client will be returned nulls for that data range. Again, this has been the case for NFSv2/v3. You will also note that there is no way delete a range of a file or effectively punching a hole in the file. On Feb 4, 2004, at 1:34 PM, Erblichs wrote: > Hi group, > > I must be going blind, but I don't see the NFSv4 spec > covering how to do the opposite functionalities when > it comes to holes. > > FYI, holes are caused when a regular file has multiple > operations where a byte has been written at a specific > offset and then the offset has been increased and > additional writes are done. > > The creation of a hole is done to allow a regular file > object to be created that is larger than the FS itself > and/or to minimize the allotment of file system pages > for non contigous pages. These holes also should decrease > the amount of time for the writes to occur. > > However, if this hole is written with NULLs or whatever, > then a reservation mechanism is encountered as a secondary > effect. > > So, with the spec, am I missing something that allows me > to specify commit of previous writes to the regular file with > and without holes. > > Thanks, > Mitchell Erblich > Sr. Software Engineer > > _______________________________________________ > 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 From exim@www1.ietf.org Wed Feb 4 22:24:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16402 for ; Wed, 4 Feb 2004 22:24:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoa7C-0006jg-Fu for nfsv4-archive@odin.ietf.org; Wed, 04 Feb 2004 22:23:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i153NgDs025886 for nfsv4-archive@odin.ietf.org; Wed, 4 Feb 2004 22:23:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoa7C-0006jR-8w for nfsv4-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 22:23:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16383 for ; Wed, 4 Feb 2004 22:23:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoa79-00078c-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 22:23:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoa6D-00072Z-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 22:22:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aoa5X-0006wZ-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 22:21:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoa5Z-0006K2-Mt; Wed, 04 Feb 2004 22:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoa5A-0006Fj-PS for nfsv4@optimus.ietf.org; Wed, 04 Feb 2004 22:21:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16197 for ; Wed, 4 Feb 2004 22:21:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoa57-0006t7-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 22:21:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoa4C-0006jZ-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 22:20:37 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1Aoa3O-0006a8-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 22:19:46 -0500 Received: from engmail1mpk.Eng.Sun.COM ([129.146.11.21]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i153JG0J014457 for ; Wed, 4 Feb 2004 19:19:16 -0800 (PST) Received: from [129.153.128.227] (dhcp-uaus08-128-227.Central.Sun.COM [129.153.128.227]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i153IcOS022034 for ; Wed, 4 Feb 2004 19:18:38 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v609) To: nfsv4@ietf.org Message-Id: <4927794E-578A-11D8-B4EE-000A95DBCB70@sun.com> Content-Type: multipart/alternative; boundary=Apple-Mail-6-1007281071 From: Spencer Shepler X-Mailer: Apple Mail (2.609) Subject: [nfsv4] Fwd: I-D ACTION:draft-khan-nfsv4-directory-delegation-00.txt Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Wed, 4 Feb 2004 21:20:45 -0600 Date: Wed, 4 Feb 2004 21:20:45 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 --Apple-Mail-6-1007281071 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit In case you didn't see the notification.... Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: February 4, 2004 2:41:38 PM CST > To: IETF-Announce:; > Subject: I-D ACTION:draft-khan-nfsv4-directory-delegation-00.txt > Reply-To: Internet-Drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : NFSv4.1: Directory Delegations and Notifications > Author(s) : S. Khan > Filename : draft-khan-nfsv4-directory-delegation-00.txt > Pages : 24 > Date : 2004-2-4 > > This document proposes adding directory delegations and notifications > to NFS Version 4 [RFC3530]. It is hoped that these changes will be > part of a new minor version of NFS, such as NFSv4.1. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-khan-nfsv4-directory- > delegation-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-khan-nfsv4-directory-delegation-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-khan-nfsv4-directory-delegation-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2004-2-4155943.I-D@ietf.org> --Apple-Mail-6-1007281071 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit In case you didn't see the notification.... Begin forwarded message: 0000,0000,0000From: Internet-Drafts@ietf.org 0000,0000,0000Date: February 4, 2004 2:41:38 PM CST 0000,0000,0000To: IETF-Announce:; 0000,0000,0000Subject: I-D ACTION:draft-khan-nfsv4-directory-delegation-00.txt 0000,0000,0000Reply-To: Internet-Drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NFSv4.1: Directory Delegations and Notifications Author(s) : S. Khan Filename : draft-khan-nfsv4-directory-delegation-00.txt Pages : 24 Date : 2004-2-4 This document proposes adding directory delegations and notifications to NFS Version 4 [RFC3530]. It is hoped that these changes will be part of a new minor version of NFS, such as NFSv4.1. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-khan-nfsv4-directory-delegation-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-khan-nfsv4-directory-delegation-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-khan-nfsv4-directory-delegation-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <<2004-2-4155943.I-D@ietf.org> --Apple-Mail-6-1007281071-- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Wed Feb 4 22:33:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16681 for ; Wed, 4 Feb 2004 22:33:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoaFu-0007Uc-O9 for nfsv4-archive@odin.ietf.org; Wed, 04 Feb 2004 22:32:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i153WgSj028788 for nfsv4-archive@odin.ietf.org; Wed, 4 Feb 2004 22:32:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoaFu-0007Tw-Hl for nfsv4-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 22:32:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16678 for ; Wed, 4 Feb 2004 22:32:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoaFr-0000Ad-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 22:32:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoaEt-00005m-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 22:31:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoaEF-00000b-00 for nfsv4-web-archive@ietf.org; Wed, 04 Feb 2004 22:30:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoaEI-0007Md-1r; Wed, 04 Feb 2004 22:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoaDw-0007Kl-3f for nfsv4@optimus.ietf.org; Wed, 04 Feb 2004 22:30:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16654 for ; Wed, 4 Feb 2004 22:30:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoaDs-000004-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 22:30:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoaD0-0007jQ-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 22:29:43 -0500 Received: from gw2.panasas.com ([65.194.124.178] helo=PIKES.panasas.com) by ietf-mx with esmtp (Exim 4.12) id 1AoaCR-0007cH-00 for nfsv4@ietf.org; Wed, 04 Feb 2004 22:29:08 -0500 Received: from yang ([172.17.19.35]) by PIKES.panasas.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SVSYN2B3; Wed, 4 Feb 2004 22:28:37 -0500 From: "Benny Halevy" To: "Spencer Shepler" , "Erblichs" Cc: Subject: RE: [nfsv4] Regular files and holes (non-contiguous) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Wed, 4 Feb 2004 22:28:17 -0500 Date: Wed, 4 Feb 2004 22:28:17 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Note also that when the file size is extended by SETATTR the protocol is saying that the server is free to either allocate storage for the extended byte range or leave it as a hole as long as the range between the current end of file to the new end of file after SETATTR is implicitly filled with zeroes as in: ... a size greater than the current size of the file causes logically zeroed data bytes to be added to the end of the file. Servers are free to implement this using holes or actual zero data bytes. Clients should not make any assumptions regarding a server's implementation of this feature, beyond that the bytes returned will be zeroed. Servers must support extending the file size via SETATTR. > -----Original Message----- > From: nfsv4-admin@ietf.org [mailto:nfsv4-admin@ietf.org]On Behalf Of > Spencer Shepler > Sent: Wednesday, February 04, 2004 22:18 > To: Erblichs > Cc: nfsv4@ietf.org > Subject: Re: [nfsv4] Regular files and holes (non-contiguous) > > > > The protocol allows for writes to any offset within the server's > support maximum file size. Write do not have to be done > contiguously; the same has been true of NFSv2/v3. > > There is no protocol mechanism for determining if a hole exists > in a particular file. If the client reads a range of the file that is > actually a hole, the client will be returned nulls for that data range. > Again, this has been the case for NFSv2/v3. > > You will also note that there is no way delete a range of a file > or effectively punching a hole in the file. > > On Feb 4, 2004, at 1:34 PM, Erblichs wrote: > > > Hi group, > > > > I must be going blind, but I don't see the NFSv4 spec > > covering how to do the opposite functionalities when > > it comes to holes. > > > > FYI, holes are caused when a regular file has multiple > > operations where a byte has been written at a specific > > offset and then the offset has been increased and > > additional writes are done. > > > > The creation of a hole is done to allow a regular file > > object to be created that is larger than the FS itself > > and/or to minimize the allotment of file system pages > > for non contigous pages. These holes also should decrease > > the amount of time for the writes to occur. > > > > However, if this hole is written with NULLs or whatever, > > then a reservation mechanism is encountered as a secondary > > effect. > > > > So, with the spec, am I missing something that allows me > > to specify commit of previous writes to the regular file with > > and without holes. > > > > Thanks, > > Mitchell Erblich > > Sr. Software Engineer > > > > _______________________________________________ > > 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 > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Fri Feb 6 16:57:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23915 for ; Fri, 6 Feb 2004 16:57:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApDyW-0002ro-Ov for nfsv4-archive@odin.ietf.org; Fri, 06 Feb 2004 16:57:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16LvO79011014 for nfsv4-archive@odin.ietf.org; Fri, 6 Feb 2004 16:57:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApDyW-0002rZ-JM for nfsv4-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 16:57:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23725 for ; Fri, 6 Feb 2004 16:57:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApDyU-00057m-00 for nfsv4-web-archive@ietf.org; Fri, 06 Feb 2004 16:57:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApDwB-0004dL-00 for nfsv4-web-archive@ietf.org; Fri, 06 Feb 2004 16:55:00 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1ApDuj-0004JM-00 for nfsv4-web-archive@ietf.org; Fri, 06 Feb 2004 16:53:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1ApDpU-0008DW-SO for nfsv4-web-archive@ietf.org; Fri, 06 Feb 2004 16:48:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApDpR-0001zu-Li; Fri, 06 Feb 2004 16:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApDoz-0001yH-5C for nfsv4@optimus.ietf.org; Fri, 06 Feb 2004 16:47:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22636 for ; Fri, 6 Feb 2004 16:47:29 -0500 (EST) From: rick@snowhite.cis.uoguelph.ca Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApDow-0003SC-00 for nfsv4@ietf.org; Fri, 06 Feb 2004 16:47:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApDnk-0003Bj-00 for nfsv4@ietf.org; Fri, 06 Feb 2004 16:46:16 -0500 Received: from snowhite.cis.uoguelph.ca ([131.104.48.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApDlT-0002ft-00 for nfsv4@ietf.org; Fri, 06 Feb 2004 16:43:55 -0500 Received: (from rick@localhost) by snowhite.cis.uoguelph.ca (8.9.3/8.9.3) id QAA66172 for nfsv4@ietf.org; Fri, 6 Feb 2004 16:43:40 -0500 (EST) Message-Id: <200402062143.QAA66172@snowhite.cis.uoguelph.ca> To: nfsv4@ietf.org Subject: [nfsv4] NFS4ERR_EXIST vs NFS4ERR_ISDIR Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Fri, 6 Feb 2004 16:43:40 -0500 (EST) Date: Fri, 6 Feb 2004 16:43:40 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Just an historical note... The section on returning NFS4ERR_EXIST for Rename for that case seems to be taken directly from RFC1813 for V3. Does this imply that "real V3" servers return ISDIR and not EEXIST? rick ps: I don't have a problem with returning EISDIR, just would like to know if there was a reason V3 didn't allow it? _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Fri Feb 6 17:14:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25456 for ; Fri, 6 Feb 2004 17:14:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApEEq-0004Jv-5q for nfsv4-archive@odin.ietf.org; Fri, 06 Feb 2004 17:14:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16MEGBG016601 for nfsv4-archive@odin.ietf.org; Fri, 6 Feb 2004 17:14:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApEEq-0004Jg-1q for nfsv4-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 17:14:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25338 for ; Fri, 6 Feb 2004 17:14:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApEEn-0006od-00 for nfsv4-web-archive@ietf.org; Fri, 06 Feb 2004 17:14:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApEDb-0006bK-00 for nfsv4-web-archive@ietf.org; Fri, 06 Feb 2004 17:13:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApECc-0006WJ-00 for nfsv4-web-archive@ietf.org; Fri, 06 Feb 2004 17:11:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApECe-0004AT-EW; Fri, 06 Feb 2004 17:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApEBq-00049R-Sv for nfsv4@optimus.ietf.org; Fri, 06 Feb 2004 17:11:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25167 for ; Fri, 6 Feb 2004 17:11:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApEBo-0006RS-00 for nfsv4@ietf.org; Fri, 06 Feb 2004 17:11:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApEAo-0006N5-00 for nfsv4@ietf.org; Fri, 06 Feb 2004 17:10:06 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1ApEA5-0006GS-00 for nfsv4@ietf.org; Fri, 06 Feb 2004 17:09:21 -0500 Received: from phys-giza-2 ([129.147.4.101]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i16M8pdO019391 for ; Fri, 6 Feb 2004 14:08:51 -0800 (PST) Received: from Sun.COM (nyday.Central.Sun.COM [172.20.25.90]) by giza-mail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HSO00G10O6ROH@giza-mail1.Central.Sun.COM> for nfsv4@ietf.org; Fri, 06 Feb 2004 15:08:51 -0700 (MST) From: Peter Staubach Subject: Re: [nfsv4] NFS4ERR_EXIST vs NFS4ERR_ISDIR To: rick@snowhite.cis.uoguelph.ca Cc: nfsv4@ietf.org Reply-to: Peter.Staubach@Sun.COM Message-id: <40241014.3040105@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: <200402062143.QAA66172@snowhite.cis.uoguelph.ca> Content-Transfer-Encoding: 7bit Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Fri, 06 Feb 2004 15:07:16 -0700 Date: Fri, 06 Feb 2004 15:07:16 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit rick@snowhite.cis.uoguelph.ca wrote: > Just an historical note... The section on returning NFS4ERR_EXIST for > Rename for that case seems to be taken directly from RFC1813 for V3. > > Does this imply that "real V3" servers return ISDIR and not EEXIST? > > rick > ps: I don't have a problem with returning EISDIR, just would like to > know if there was a reason V3 didn't allow it? > Actually, the NFSv3 protocol does not restrict which errors could be returned from which operation. There were lists associated with each operation, but they were intended to be the more common errors. There is no reason that any specific error can not be returned, as long as it is one of the valid errors for the protocol. ps _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Fri Feb 6 17:27:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26154 for ; Fri, 6 Feb 2004 17:27:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApERB-0005CU-K9 for nfsv4-archive@odin.ietf.org; Fri, 06 Feb 2004 17:27:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16MR15i019979 for nfsv4-archive@odin.ietf.org; Fri, 6 Feb 2004 17:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApERA-0005C0-VD for nfsv4-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 17:27:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26123 for ; Fri, 6 Feb 2004 17:26:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApER8-0007hg-00 for nfsv4-web-archive@ietf.org; Fri, 06 Feb 2004 17:26:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApEQB-0007eQ-00 for nfsv4-web-archive@ietf.org; Fri, 06 Feb 2004 17:26:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApEPE-0007bG-00 for nfsv4-web-archive@ietf.org; Fri, 06 Feb 2004 17:25:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApEPF-00051X-5P; Fri, 06 Feb 2004 17:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApEOJ-0004xX-Ub for nfsv4@optimus.ietf.org; Fri, 06 Feb 2004 17:24:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26048 for ; Fri, 6 Feb 2004 17:23:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApEOH-0007Y0-00 for nfsv4@ietf.org; Fri, 06 Feb 2004 17:24:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApENM-0007V4-00 for nfsv4@ietf.org; Fri, 06 Feb 2004 17:23:05 -0500 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1ApEN7-0007Rv-00 for nfsv4@ietf.org; Fri, 06 Feb 2004 17:22:49 -0500 Received: from frejya.corp.netapp.com (frejya [10.57.157.119]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i16MMJKw013449; Fri, 6 Feb 2004 14:22:19 -0800 (PST) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.10.22.171]) by frejya.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i16MMIDi027415; Fri, 6 Feb 2004 14:22:18 -0800 (PST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [nfsv4] NFS4ERR_EXIST vs NFS4ERR_ISDIR Message-ID: Thread-Topic: [nfsv4] NFS4ERR_EXIST vs NFS4ERR_ISDIR Thread-Index: AcPs/kKitv6uFtXDRWyU8grE4IxwsgAAJM9Q From: "Noveck, Dave" To: , Cc: Content-Transfer-Encoding: quoted-printable Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Fri, 6 Feb 2004 14:22:12 -0800 Date: Fri, 6 Feb 2004 14:22:12 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Peter Staubach wrote: > Actually, the NFSv3 protocol does not restrict which errors could be > returned from which operation. There were lists associated with each > operation, but they were intended to be the more common errors. There > is no reason that any specific error can not be returned, as long as = it > is one of the valid errors for the protocol. That may be true of the error lists, but the following text from RFC1813 does specifically say that in the case we are talking about, you should return EXIST and not ISDIR. The fact that RFC1813 is, in general, not inclined to limit you on the errors you return, makes the fact that it=20 is so specific, sort of noteworthy. Just like Rick, I wonder why = (although I may never find out). If the directory, to.dir, already contains an entry with the name, to.name, the source object must be compatible with the target: either both are non-directories or both are directories and the target must be empty. If compatible, the existing target is removed before the rename occurs. If they are not compatible or if the target is a directory but not empty, the server should return the error, NFS3ERR_EXIST. -----Original Message----- From: Peter Staubach [mailto:Peter.Staubach@Sun.COM] Sent: Friday, February 06, 2004 5:07 PM To: rick@snowhite.cis.uoguelph.ca Cc: nfsv4@ietf.org Subject: Re: [nfsv4] NFS4ERR_EXIST vs NFS4ERR_ISDIR rick@snowhite.cis.uoguelph.ca wrote: > Just an historical note... The section on returning NFS4ERR_EXIST for > Rename for that case seems to be taken directly from RFC1813 for V3. >=20 > Does this imply that "real V3" servers return ISDIR and not EEXIST? >=20 > rick > ps: I don't have a problem with returning EISDIR, just would like to > know if there was a reason V3 didn't allow it? >=20 Actually, the NFSv3 protocol does not restrict which errors could be returned from which operation. There were lists associated with each operation, but they were intended to be the more common errors. There is no reason that any specific error can not be returned, as long as it is one of the valid errors for the protocol. ps _______________________________________________ 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 From exim@www1.ietf.org Fri Feb 6 18:20:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29306 for ; Fri, 6 Feb 2004 18:20:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApFGX-0006pj-AG for nfsv4-archive@odin.ietf.org; Fri, 06 Feb 2004 18:20:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16NK5UV026261 for nfsv4-archive@odin.ietf.org; Fri, 6 Feb 2004 18:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApFGV-0006pO-Tp for nfsv4-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 18:20:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29279 for ; Fri, 6 Feb 2004 18:19:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApFGT-0003ak-00 for nfsv4-web-archive@ietf.org; Fri, 06 Feb 2004 18:20:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApFFT-0003WL-00 for nfsv4-web-archive@ietf.org; Fri, 06 Feb 2004 18:19:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApFEV-0003Rx-00 for nfsv4-web-archive@ietf.org; Fri, 06 Feb 2004 18:17:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApFEX-0005zb-CV; Fri, 06 Feb 2004 18:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApFDc-0005kQ-FF for nfsv4@optimus.ietf.org; Fri, 06 Feb 2004 18:17:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29029 for ; Fri, 6 Feb 2004 18:16:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApFDZ-0003NS-00 for nfsv4@ietf.org; Fri, 06 Feb 2004 18:17:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApFCc-0003Jc-00 for nfsv4@ietf.org; Fri, 06 Feb 2004 18:16:03 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1ApFBo-0003Fo-00 for nfsv4@ietf.org; Fri, 06 Feb 2004 18:15:12 -0500 Received: from phys-giza-2 ([129.147.4.101]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i16NEpiv008042 for ; Fri, 6 Feb 2004 16:15:06 -0700 (MST) Received: from Sun.COM (nyday.Central.Sun.COM [172.20.25.90]) by giza-mail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HSO00J2RPIBEJ@giza-mail1.Central.Sun.COM> for nfsv4@ietf.org; Fri, 06 Feb 2004 15:37:23 -0700 (MST) From: Peter Staubach Subject: Re: [nfsv4] NFS4ERR_EXIST vs NFS4ERR_ISDIR To: "Noveck, Dave" Cc: rick@snowhite.cis.uoguelph.ca, nfsv4@ietf.org Reply-to: Peter.Staubach@Sun.COM Message-id: <402416C4.9060103@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: Content-Transfer-Encoding: 7bit Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Fri, 06 Feb 2004 15:35:48 -0700 Date: Fri, 06 Feb 2004 15:35:48 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Noveck, Dave wrote: > Peter Staubach wrote: > >>Actually, the NFSv3 protocol does not restrict which errors could be >>returned from which operation. There were lists associated with each >>operation, but they were intended to be the more common errors. There >>is no reason that any specific error can not be returned, as long as it >>is one of the valid errors for the protocol. > > > That may be true of the error lists, but the following text from RFC1813 > does specifically say that in the case we are talking about, you should > return EXIST and not ISDIR. The fact that RFC1813 is, in general, not > inclined to limit you on the errors you return, makes the fact that it > is so specific, sort of noteworthy. Just like Rick, I wonder why (although > I may never find out). > > If the directory, to.dir, already contains an entry with > the name, to.name, the source object must be compatible > with the target: either both are non-directories or both > are directories and the target must be empty. If > compatible, the existing target is removed before the > rename occurs. If they are not compatible or if the target > is a directory but not empty, the server should return the > error, NFS3ERR_EXIST. > Yes, so that would have been text that I would have written, so perhaps I should remember... :-) That text was added because the Solaris UFS implementation returns EEXIST. It has been long enough that I don't recall why though, perhaps POSIX or the SVID... ps _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Fri Feb 6 18:22:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29371 for ; Fri, 6 Feb 2004 18:22:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApFIQ-0006u9-Av for nfsv4-archive@odin.ietf.org; Fri, 06 Feb 2004 18:22:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16NM25p026535 for nfsv4-archive@odin.ietf.org; Fri, 6 Feb 2004 18:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApFIQ-0006tu-5s for nfsv4-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 18:22:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29359 for ; Fri, 6 Feb 2004 18:21:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApFIN-0003hz-00 for nfsv4-web-archive@ietf.org; Fri, 06 Feb 2004 18:21:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApFHO-0003eg-00 for nfsv4-web-archive@ietf.org; Fri, 06 Feb 2004 18:20:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApFGR-0003aY-00 for nfsv4-web-archive@ietf.org; Fri, 06 Feb 2004 18:19:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApFGT-0006nL-7U; Fri, 06 Feb 2004 18:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApFFX-0006bs-Vr for nfsv4@optimus.ietf.org; Fri, 06 Feb 2004 18:19:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29240 for ; Fri, 6 Feb 2004 18:18:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApFFV-0003WU-00 for nfsv4@ietf.org; Fri, 06 Feb 2004 18:19:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApFEX-0003SD-00 for nfsv4@ietf.org; Fri, 06 Feb 2004 18:18:01 -0500 Received: from gw2.panasas.com ([65.194.124.178] helo=PIKES.panasas.com) by ietf-mx with esmtp (Exim 4.12) id 1ApFDb-0003L0-00 for nfsv4@ietf.org; Fri, 06 Feb 2004 18:17:03 -0500 Received: by PIKES.panasas.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Feb 2004 18:16:28 -0500 Message-ID: <30489F1321F5C343ACF6872B2CF7942A05D38840@PIKES.panasas.com> From: "Halevy, Benny" To: "'rick@snowhite.cis.uoguelph.ca'" , nfsv4@ietf.org Subject: RE: [nfsv4] NFS4ERR_EXIST vs NFS4ERR_ISDIR MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Fri, 6 Feb 2004 18:16:21 -0500 Date: Fri, 6 Feb 2004 18:16:21 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 FreeBSD returns EISDIR when renaming a file onto an existing directory. I see that with 4.6.2 - Benny >-----Original Message----- >From: rick@snowhite.cis.uoguelph.ca >[mailto:rick@snowhite.cis.uoguelph.ca] >Sent: Friday, February 06, 2004 4:44 PM >To: nfsv4@ietf.org >Subject: [nfsv4] NFS4ERR_EXIST vs NFS4ERR_ISDIR > > >Just an historical note... The section on returning NFS4ERR_EXIST for >Rename for that case seems to be taken directly from RFC1813 for V3. > >Does this imply that "real V3" servers return ISDIR and not EEXIST? > >rick >ps: I don't have a problem with returning EISDIR, just would like to > know if there was a reason V3 didn't allow it? > >_______________________________________________ >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 From exim@www1.ietf.org Fri Feb 6 19:55:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02035 for ; Fri, 6 Feb 2004 19:55:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApGkY-00041x-Ey for nfsv4-archive@odin.ietf.org; Fri, 06 Feb 2004 19:55:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i170tAUm015487 for nfsv4-archive@odin.ietf.org; Fri, 6 Feb 2004 19:55:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApGkY-00041i-9N for nfsv4-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 19:55:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02028 for ; Fri, 6 Feb 2004 19:55:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApGkW-0001C8-00 for nfsv4-web-archive@ietf.org; Fri, 06 Feb 2004 19:55:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApGjX-00018v-00 for nfsv4-web-archive@ietf.org; Fri, 06 Feb 2004 19:54:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApGjQ-00015t-00 for nfsv4-web-archive@ietf.org; Fri, 06 Feb 2004 19:54:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApGjQ-0003x9-NR; Fri, 06 Feb 2004 19:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApGiW-0003vy-Eg for nfsv4@optimus.ietf.org; Fri, 06 Feb 2004 19:53:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01985 for ; Fri, 6 Feb 2004 19:53:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApGiU-000153-00 for nfsv4@ietf.org; Fri, 06 Feb 2004 19:53:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApGhX-000120-00 for nfsv4@ietf.org; Fri, 06 Feb 2004 19:52:04 -0500 Received: from gw2.panasas.com ([65.194.124.178] helo=PIKES.panasas.com) by ietf-mx with esmtp (Exim 4.12) id 1ApGge-0000wg-00 for nfsv4@ietf.org; Fri, 06 Feb 2004 19:51:08 -0500 Received: by PIKES.panasas.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Feb 2004 19:50:39 -0500 Message-ID: <30489F1321F5C343ACF6872B2CF7942A05D38843@PIKES.panasas.com> From: "Halevy, Benny" To: "'Peter.Staubach@Sun.COM'" , "Halevy, Benny" Cc: "'nfsv4@ietf.org'" Subject: RE: [nfsv4] NFS4ERR_EXIST vs NFS4ERR_ISDIR MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Fri, 6 Feb 2004 19:50:36 -0500 Date: Fri, 6 Feb 2004 19:50:36 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Peter Staubach wrote: > >Halevy, Benny wrote: >> FreeBSD returns EISDIR when renaming a file onto an existing >> directory. I see that with 4.6.2 >> > >What does it return when an attempt is made to rename one directory >to another existing directory where the existing directory is not >empty? That's the situation under discussion... > > ps > > In case of a rename of a directory onto an existing directory which is not empty FreeBSD 4.6.2 returns ENOTEMPTY. I looked at the server code and it looks like it just passes whatever error code the underlying filesystem returns. By the way, my application running on Solaris sees EEXIST as the errno so I guess the Solaris client is translating it under the covers. Benny _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Fri Feb 6 21:16:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04601 for ; Fri, 6 Feb 2004 21:16:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApI0u-0001EF-KQ for nfsv4-archive@odin.ietf.org; Fri, 06 Feb 2004 21:16:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i172G8qO004717 for nfsv4-archive@odin.ietf.org; Fri, 6 Feb 2004 21:16:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApI0u-0001E0-FJ for nfsv4-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 21:16:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04597 for ; Fri, 6 Feb 2004 21:16:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApI0r-0006Ns-00 for nfsv4-web-archive@ietf.org; Fri, 06 Feb 2004 21:16:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApHzw-0006LW-00 for nfsv4-web-archive@ietf.org; Fri, 06 Feb 2004 21:15:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApHzp-0006Iq-00 for nfsv4-web-archive@ietf.org; Fri, 06 Feb 2004 21:15:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHzq-00017k-H4; Fri, 06 Feb 2004 21:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHyz-00014t-1l for nfsv4@optimus.ietf.org; Fri, 06 Feb 2004 21:14:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04565 for ; Fri, 6 Feb 2004 21:14:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApHyw-0006Hz-00 for nfsv4@ietf.org; Fri, 06 Feb 2004 21:14:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApHxz-0006F8-00 for nfsv4@ietf.org; Fri, 06 Feb 2004 21:13:08 -0500 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1ApHxW-0006A3-00 for nfsv4@ietf.org; Fri, 06 Feb 2004 21:12:38 -0500 Received: from hawk.corp.netapp.com (hawk [10.57.156.122]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i172C3Kw012621; Fri, 6 Feb 2004 18:12:03 -0800 (PST) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.10.22.171]) by hawk.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i172C2Rh011887; Fri, 6 Feb 2004 18:12:02 -0800 (PST) Received: from tmt.netapp.com ([10.97.6.38]) by silver.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 6 Feb 2004 21:12:00 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3ED1F.C4EAD800" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [nfsv4] NFS4ERR_EXIST vs NFS4ERR_ISDIR Message-ID: <5.2.1.1.2.20040206210728.00bbcf18@silver.nane.netapp.com> Thread-Topic: [nfsv4] NFS4ERR_EXIST vs NFS4ERR_ISDIR Thread-Index: AcPtH8UY8+Ar/9aYQ2aUfeHCWSBqwQ== From: "Talpey, Thomas" To: "Noveck, Dave" Cc: , , Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Fri, 6 Feb 2004 18:11:44 -0800 Date: Fri, 6 Feb 2004 18:11:44 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3ED1F.C4EAD800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 05:22 PM 2/6/2004, Noveck, Dave wrote: >return EXIST and not ISDIR. The fact that RFC1813 is, in general, not >inclined to limit you on the errors you return, makes the fact that it=20 >is so specific, sort of noteworthy. Just like Rick, I wonder why = (although >I may never find out). > > If the directory, to.dir, already contains an entry with > the name, to.name, the source object must be compatible > with the target: either both are non-directories or both > are directories and the target must be empty. If > compatible, the existing target is removed before the > rename occurs. If they are not compatible or if the target > is a directory but not empty, the server should return the > error, NFS3ERR_EXIST. Especially because it's not Posix: e.g. = [EEXIST] = or [ENOTEMPTY] =20 The link named by new is a directory that is not an empty directory.=20 [EISDIR] =20 The new argument points to a directory and the old argument points to a = file that is not a directory.=20 Okay, who wrote that into RFC1813? :-) Tom.=20 ------_=_NextPart_001_01C3ED1F.C4EAD800 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [nfsv4] NFS4ERR_EXIST vs NFS4ERR_ISDIR

At 05:22 PM 2/6/2004, Noveck, Dave wrote:
>return EXIST and not ISDIR.  The fact that = RFC1813 is, in general, not
>inclined to limit you on the errors you return, = makes the fact that it
>is so specific, sort of noteworthy.  Just = like Rick, I wonder why (although
>I may never find out).
>
>      If the directory, = to.dir, already contains an entry with
>      the name, to.name, = the source object must be compatible
>      with the target: = either both are non-directories or both
>      are directories = and the target must be empty. If
>      compatible, the = existing target is removed before the
>      rename occurs. If = they are not compatible or if the target
>      is a directory but = not empty, the server should return the
>      error, = NFS3ERR_EXIST.

Especially because it's not Posix:

e.g. <ht= tp://www.opengroup.org/onlinepubs/007908799/xsh/rename.html>[EEXIS= T] or [ENOTEMPTY] 
The link named by new is a directory that is not an = empty directory.
[EISDIR] 
The new argument points to a directory and the old = argument points to a file that is not a directory.
Okay, who wrote that into RFC1813? :-)

Tom.

------_=_NextPart_001_01C3ED1F.C4EAD800-- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Wed Feb 11 17:26:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04070 for ; Wed, 11 Feb 2004 17:26:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2ne-0007ev-NI for nfsv4-archive@odin.ietf.org; Wed, 11 Feb 2004 17:25:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BMPgK5029440 for nfsv4-archive@odin.ietf.org; Wed, 11 Feb 2004 17:25:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2ne-0007el-Iy for nfsv4-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 17:25:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04060 for ; Wed, 11 Feb 2004 17:25:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2nc-0003bS-00 for nfsv4-web-archive@ietf.org; Wed, 11 Feb 2004 17:25:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2mo-0003U1-00 for nfsv4-web-archive@ietf.org; Wed, 11 Feb 2004 17:24:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2m0-0003LL-00 for nfsv4-web-archive@ietf.org; Wed, 11 Feb 2004 17:24:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2m1-0007Sh-0y; Wed, 11 Feb 2004 17:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Kf-000481-PA for nfsv4@optimus.ietf.org; Wed, 11 Feb 2004 15:51:41 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22618; Wed, 11 Feb 2004 15:51:39 -0500 (EST) Message-Id: <200402112051.PAA22618@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nfsv4@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [nfsv4] I-D ACTION:draft-ietf-nfsv4-acl-mapping-01.txt Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Wed, 11 Feb 2004 15:51:39 -0500 Date: Wed, 11 Feb 2004 15:51:39 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network File System Version 4 Working Group of the IETF. Title : Mapping Between NFSv4 and Posix Draft ACLs Author(s) : M. Eriksen Filename : draft-ietf-nfsv4-acl-mapping-01.txt Pages : 10 Date : 2004-2-11 The NFS (Network File System) version 4[rfc3530] (NFSv4) specifies a flavor of Access Control Lists (ACLs) that apply to file system objects. ACLs specify an access level for a number of entities. The NFSv4 ACLs model resembles that of Windows NT. A POSIX draft[posixacl] proposes another, more restrictive ACL model. Many systems implement this proposed standard. Differing in syntax, semantics and extensiveness, it is only feasible to create a correct representation for POSIX ACLs with NFSv4 ACLs. This does not hold for an attempt to represent arbitrary NFSv4 ACLs with POSIX ACLs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-acl-mapping-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nfsv4-acl-mapping-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nfsv4-acl-mapping-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-11160545.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nfsv4-acl-mapping-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nfsv4-acl-mapping-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-11160545.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Wed Feb 11 17:59:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06713 for ; Wed, 11 Feb 2004 17:59:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3Jo-0001oN-7A for nfsv4-archive@odin.ietf.org; Wed, 11 Feb 2004 17:58:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BMwu1f006957 for nfsv4-archive@odin.ietf.org; Wed, 11 Feb 2004 17:58:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3Jn-0001o5-TO for nfsv4-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 17:58:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06663 for ; Wed, 11 Feb 2004 17:58:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar3Jl-0000W4-00 for nfsv4-web-archive@ietf.org; Wed, 11 Feb 2004 17:58:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar3Iq-0000Nj-00 for nfsv4-web-archive@ietf.org; Wed, 11 Feb 2004 17:57:57 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar3Hx-0000GN-00 for nfsv4-web-archive@ietf.org; Wed, 11 Feb 2004 17:57:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar3Hy-0007zM-4h for nfsv4-web-archive@ietf.org; Wed, 11 Feb 2004 17:57:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3Hy-0001hG-0K; Wed, 11 Feb 2004 17:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3Hl-0001cO-EH for nfsv4@optimus.ietf.org; Wed, 11 Feb 2004 17:56:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06604 for ; Wed, 11 Feb 2004 17:56:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar3Hi-0000F7-00 for nfsv4@ietf.org; Wed, 11 Feb 2004 17:56:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar3Gp-00008u-00 for nfsv4@ietf.org; Wed, 11 Feb 2004 17:55:52 -0500 Received: from dsl093-002-214.det1.dsl.speakeasy.net ([66.93.2.214] helo=pumpkin.fieldses.org ident=Debian-exim) by ietf-mx with esmtp (Exim 4.12) id 1Ar3G8-000021-00 for nfsv4@ietf.org; Wed, 11 Feb 2004 17:55:08 -0500 Received: from bfields by pumpkin.fieldses.org with local (Exim 4.30) id 1Ar3G6-0004zD-Lo for nfsv4@ietf.org; Wed, 11 Feb 2004 17:55:06 -0500 To: nfsv4@ietf.org Subject: Re: [nfsv4] I-D ACTION:draft-ietf-nfsv4-acl-mapping-01.txt Message-ID: <20040211225506.GC17779@fieldses.org> References: <200402112051.PAA22618@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402112051.PAA22618@ietf.org> User-Agent: Mutt/1.5.5.1+cvs20040105i From: "J. Bruce Fields" Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Wed, 11 Feb 2004 17:55:06 -0500 Date: Wed, 11 Feb 2004 17:55:06 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, Feb 11, 2004 at 03:51:39PM -0500, Internet-Drafts@ietf.org wrote: > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-acl-mapping-01.txt Note that anyone that cares about how to keep mode bits and acl's in sync also needs to pay some attention to this. I think what we're now proposing is consistent with what's been discussed on this list, but speak up if anything looks wrong: posix read bit = ACE4_READ_DATA | ACE4_READ_NAMED_ATTRS posix write bit = ACE4_WRITE_DATA | ACE4_WRITE_NAMED_ATTRS | ACE4_APPEND_DATA | ACE4_DELETE_CHILD (though ACE4_DELETE_CHILD actually only has meaning on directories) posix execute bit = ACE4_EXECUTE_BIT | ACE4_READ_DATA Also, everyone gets ACE4_READ_ATTRIBUTES | ACE4_READ_ACL, and the owner (and only the owner) gets ACE4_WRITE_ATTRIBUTES | ACE4_WRITE_ACL. Also (I just realized this got left out of the above draft), everyone should get DELETE (at least on files). We're making some assumptions here: 1. ACE4_WRITE_DATA (and ACE4_APPEND_DATA?) are sufficient to allow someone to modify the length of a file; ACE4_WRITE_ATTRIBUTES is not required. 2. ACE4_WRITE_ATTRIBUTES does not give the right to modify mode bits, ACLs, or named attributes 3. ACE4_DELETE_CHILD on the directory is always required for unlink to succeed; ACE4_DELETE doesn't allow this to be bypassed. (Mitch Halevy's interpretation that ACE4_DELETE would only be checked when removing the last link made sense to me.) Arguments welcomed.--b. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Wed Feb 11 20:18:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16859 for ; Wed, 11 Feb 2004 20:18:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5UL-0003Pd-H5 for nfsv4-archive@odin.ietf.org; Wed, 11 Feb 2004 20:17:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C1HvdT013110 for nfsv4-archive@odin.ietf.org; Wed, 11 Feb 2004 20:17:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5UL-0003PN-CE for nfsv4-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 20:17:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16825 for ; Wed, 11 Feb 2004 20:17:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5UJ-0002su-00 for nfsv4-web-archive@ietf.org; Wed, 11 Feb 2004 20:17:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar5TI-0002mk-00 for nfsv4-web-archive@ietf.org; Wed, 11 Feb 2004 20:16:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5SW-0002gm-00 for nfsv4-web-archive@ietf.org; Wed, 11 Feb 2004 20:16:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5SV-0003Ie-Cb; Wed, 11 Feb 2004 20:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5SL-0003H7-U2 for nfsv4@optimus.ietf.org; Wed, 11 Feb 2004 20:15:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16709 for ; Wed, 11 Feb 2004 20:15:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5SJ-0002fx-00 for nfsv4@ietf.org; Wed, 11 Feb 2004 20:15:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar5RU-0002aA-00 for nfsv4@ietf.org; Wed, 11 Feb 2004 20:15:01 -0500 Received: from gw2.panasas.com ([65.194.124.178] helo=PIKES.panasas.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar5Ql-0002QW-00 for nfsv4@ietf.org; Wed, 11 Feb 2004 20:14:15 -0500 Received: from yang ([172.17.19.39]) by PIKES.panasas.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SVSY3L9Z; Wed, 11 Feb 2004 20:13:45 -0500 From: "Benny Halevy" To: "J. Bruce Fields" , Cc: Subject: RE: [nfsv4] I-D ACTION:draft-ietf-nfsv4-acl-mapping-01.txt Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-reply-to: <20040211225506.GC17779@fieldses.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Wed, 11 Feb 2004 20:14:10 -0500 Date: Wed, 11 Feb 2004 20:14:10 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, first, the draft looks much more sensible than its previous version. 1) IMO NFSv4 "OWNER", "GROUP", and "EVERYONE" better be referred as "OWNER@", "GROUP@", and "EVERYONE@" respectively. See rfc3530 section 5.11.6. Mode and ACL Attribute 2) A couple of technical comments: - NFSv4 is now rfc3530 not rfc3010. - there are a lot of control characters in the text (backspaces?) 3) The draft could use an example. 4) It'd be great if as the next step we define how a POSIX compliant server should support NFSv4 ACLs. What NFSv4 ACE types and flags can be supported and how they should be translated into the posix model. Regards, Benny (who's Mitch?) Halevy > -----Original Message----- > From: nfsv4-admin@ietf.org [mailto:nfsv4-admin@ietf.org]On Behalf Of J. > Bruce Fields > Sent: Wednesday, February 11, 2004 17:55 > To: nfsv4@ietf.org > Subject: Re: [nfsv4] I-D ACTION:draft-ietf-nfsv4-acl-mapping-01.txt > > > On Wed, Feb 11, 2004 at 03:51:39PM -0500, Internet-Drafts@ietf.org wrote: > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-acl-mapping-01.txt > > Note that anyone that cares about how to keep mode bits and acl's in > sync also needs to pay some attention to this. > > I think what we're now proposing is consistent with what's been > discussed on this list, but speak up if anything looks wrong: > > posix read bit = ACE4_READ_DATA | ACE4_READ_NAMED_ATTRS > posix write bit = ACE4_WRITE_DATA | ACE4_WRITE_NAMED_ATTRS > | ACE4_APPEND_DATA | ACE4_DELETE_CHILD > (though ACE4_DELETE_CHILD actually only has meaning on > directories) > posix execute bit = ACE4_EXECUTE_BIT | ACE4_READ_DATA > > Also, everyone gets ACE4_READ_ATTRIBUTES | ACE4_READ_ACL, and the > owner (and only the owner) gets ACE4_WRITE_ATTRIBUTES | ACE4_WRITE_ACL. > Also (I just realized this got left out of the above draft), everyone > should get DELETE (at least on files). > > We're making some assumptions here: > 1. ACE4_WRITE_DATA (and ACE4_APPEND_DATA?) are sufficient to > allow someone to modify the length of a file; > ACE4_WRITE_ATTRIBUTES is not required. > 2. ACE4_WRITE_ATTRIBUTES does not give the right to modify mode > bits, ACLs, or named attributes > 3. ACE4_DELETE_CHILD on the directory is always required for > unlink to succeed; ACE4_DELETE doesn't allow this to be > bypassed. (Mitch Halevy's interpretation that ACE4_DELETE > would only be checked when removing the last link made sense > to me.) > > Arguments welcomed.--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 From exim@www1.ietf.org Wed Feb 11 20:42:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17518 for ; Wed, 11 Feb 2004 20:42:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5rU-0005KQ-3a for nfsv4-archive@odin.ietf.org; Wed, 11 Feb 2004 20:41:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C1fq1x020479 for nfsv4-archive@odin.ietf.org; Wed, 11 Feb 2004 20:41:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5rT-0005KE-TQ for nfsv4-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 20:41:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17506 for ; Wed, 11 Feb 2004 20:41:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5rR-00056p-00 for nfsv4-web-archive@ietf.org; Wed, 11 Feb 2004 20:41:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar5qX-00051C-00 for nfsv4-web-archive@ietf.org; Wed, 11 Feb 2004 20:40:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5pj-0004vP-00 for nfsv4-web-archive@ietf.org; Wed, 11 Feb 2004 20:40:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5pj-0005Fm-Cu; Wed, 11 Feb 2004 20:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5pY-0005Es-QU for nfsv4@optimus.ietf.org; Wed, 11 Feb 2004 20:39:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17436 for ; Wed, 11 Feb 2004 20:39:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5pW-0004ug-00 for nfsv4@ietf.org; Wed, 11 Feb 2004 20:39:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar5oa-0004ow-00 for nfsv4@ietf.org; Wed, 11 Feb 2004 20:38:52 -0500 Received: from dsl093-002-214.det1.dsl.speakeasy.net ([66.93.2.214] helo=pumpkin.fieldses.org ident=Debian-exim) by ietf-mx with esmtp (Exim 4.12) id 1Ar5oO-0004jP-00 for nfsv4@ietf.org; Wed, 11 Feb 2004 20:38:40 -0500 Received: from bfields by pumpkin.fieldses.org with local (Exim 4.30) id 1Ar5oM-0005Cq-Eu; Wed, 11 Feb 2004 20:38:38 -0500 To: Benny Halevy Cc: marius@umich.edu, nfsv4@ietf.org Subject: Re: [nfsv4] I-D ACTION:draft-ietf-nfsv4-acl-mapping-01.txt Message-ID: <20040212013838.GA19942@fieldses.org> References: <20040211225506.GC17779@fieldses.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i From: "J. Bruce Fields" Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Wed, 11 Feb 2004 20:38:38 -0500 Date: Wed, 11 Feb 2004 20:38:38 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Thanks for the comments. On Wed, Feb 11, 2004 at 08:14:10PM -0500, Benny Halevy wrote: > Folks, first, the draft looks much more sensible than its previous > version. > > 1) IMO NFSv4 "OWNER", "GROUP", and "EVERYONE" better be referred as > "OWNER@", "GROUP@", and "EVERYONE@" respectively. See rfc3530 > section 5.11.6. Mode and ACL Attribute > > 2) A couple of technical comments: > - NFSv4 is now rfc3530 not rfc3010. > - there are a lot of control characters in the text (backspaces?) > > 3) The draft could use an example. > > 4) It'd be great if as the next step we define how a POSIX compliant server > should support NFSv4 ACLs. What NFSv4 ACE types and flags can be supported > and how they should be translated into the posix model. By a "POSIX-compliant" server, do you mean a server that's using posix acl's on the exported filesystem to store ACL's? We're doing that right now in Linux by rejecting any acl handed to us by a client that isn't *exactly* the ACL that would be produced by the mapping described in the draft. This has the advantage that ACL's that are accepted can be returned unmodified. Some more flexibility might be possible. > Benny (who's Mitch?) Halevy Crap, I apologize, my mind's playing tricks on me.--Bruce Fields _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Thu Feb 12 00:26:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25113 for ; Thu, 12 Feb 2004 00:26:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9MQ-0004SJ-QU for nfsv4-archive@odin.ietf.org; Thu, 12 Feb 2004 00:26:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C5Q2Hk017111 for nfsv4-archive@odin.ietf.org; Thu, 12 Feb 2004 00:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9MP-0004Rb-PW for nfsv4-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 00:26:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24994 for ; Thu, 12 Feb 2004 00:25:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar9MN-0004EQ-00 for nfsv4-web-archive@ietf.org; Thu, 12 Feb 2004 00:25:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar9LO-00043X-00 for nfsv4-web-archive@ietf.org; Thu, 12 Feb 2004 00:24:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar9KU-0003wd-00 for nfsv4-web-archive@ietf.org; Thu, 12 Feb 2004 00:24:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9KT-0003Hn-RD; Thu, 12 Feb 2004 00:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar8Cn-0008Ev-1e for nfsv4@optimus.ietf.org; Wed, 11 Feb 2004 23:12:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23022 for ; Wed, 11 Feb 2004 23:11:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar8Cj-0005Be-00 for nfsv4@ietf.org; Wed, 11 Feb 2004 23:11:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar8Bt-000566-00 for nfsv4@ietf.org; Wed, 11 Feb 2004 23:11:06 -0500 Received: from gw2.panasas.com ([65.194.124.178] helo=PIKES.panasas.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar8BZ-0004zX-00 for nfsv4@ietf.org; Wed, 11 Feb 2004 23:10:45 -0500 Received: from yang ([172.17.19.39]) by PIKES.panasas.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SVSY3ML5; Wed, 11 Feb 2004 23:10:15 -0500 From: "Benny Halevy" To: "J. Bruce Fields" , Cc: Subject: {READ,WRITE}_NAMED_ATTRS (was RE: [nfsv4] I-D ACTION:draft-ietf-nfsv4-acl-mapping-01.txt) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-reply-to: <20040211225506.GC17779@fieldses.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Wed, 11 Feb 2004 23:10:39 -0500 Date: Wed, 11 Feb 2004 23:10:39 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I've been thinking more about the READ and WRITE NAMED_ATTRS ACE access masks and I think I have more questions than answers at this point. In draft-ietf-nfsv4-acl-mapping-01.txt you tie these access masks with READ and WRITE DATA respectively. Is this the right thing to do? How do clients use named attributes? I guess these would be typically used to store additional information about filesystem objects like "Description", "Title", "Author", "Version", "Checksum", etc. For example, I look at Microsoft's custom file properties. These are organized hierarchically in named groups, each having a list of named properties having a type and a value. These fit pretty well into the named attributes model but the question here is whether access control for these attributes is tied with access to the file data? Or should it be tied to the access control for the file's attributes? (in posix that means readable to everybody and writable to owner and privileged users) Say you want to present some of the named attributes such as "Description" or "Artist" or "Icon" when listing a directory. You would want to be able to read their contents even when you are not allowed to read the file's data. Benny > -----Original Message----- > From: nfsv4-admin@ietf.org [mailto:nfsv4-admin@ietf.org]On Behalf Of J. > Bruce Fields > Sent: Wednesday, February 11, 2004 17:55 > To: nfsv4@ietf.org > Subject: Re: [nfsv4] I-D ACTION:draft-ietf-nfsv4-acl-mapping-01.txt > > > On Wed, Feb 11, 2004 at 03:51:39PM -0500, Internet-Drafts@ietf.org wrote: > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-acl-mapping-01.txt > > Note that anyone that cares about how to keep mode bits and acl's in > sync also needs to pay some attention to this. > > I think what we're now proposing is consistent with what's been > discussed on this list, but speak up if anything looks wrong: > > posix read bit = ACE4_READ_DATA | ACE4_READ_NAMED_ATTRS > posix write bit = ACE4_WRITE_DATA | ACE4_WRITE_NAMED_ATTRS > | ACE4_APPEND_DATA | ACE4_DELETE_CHILD > (though ACE4_DELETE_CHILD actually only has meaning on > directories) > posix execute bit = ACE4_EXECUTE_BIT | ACE4_READ_DATA > > Also, everyone gets ACE4_READ_ATTRIBUTES | ACE4_READ_ACL, and the > owner (and only the owner) gets ACE4_WRITE_ATTRIBUTES | ACE4_WRITE_ACL. > Also (I just realized this got left out of the above draft), everyone > should get DELETE (at least on files). > > We're making some assumptions here: > 1. ACE4_WRITE_DATA (and ACE4_APPEND_DATA?) are sufficient to > allow someone to modify the length of a file; > ACE4_WRITE_ATTRIBUTES is not required. > 2. ACE4_WRITE_ATTRIBUTES does not give the right to modify mode > bits, ACLs, or named attributes > 3. ACE4_DELETE_CHILD on the directory is always required for > unlink to succeed; ACE4_DELETE doesn't allow this to be > bypassed. (Mitch Halevy's interpretation that ACE4_DELETE > would only be checked when removing the last link made sense > to me.) > > Arguments welcomed.--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 From exim@www1.ietf.org Thu Feb 12 00:27:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25149 for ; Thu, 12 Feb 2004 00:27:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9Mw-0004a5-42 for nfsv4-archive@odin.ietf.org; Thu, 12 Feb 2004 00:26:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C5QYtq017603 for nfsv4-archive@odin.ietf.org; Thu, 12 Feb 2004 00:26:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9Mv-0004Zq-W4 for nfsv4-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 00:26:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25092 for ; Thu, 12 Feb 2004 00:26:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar9Mt-0004Io-00 for nfsv4-web-archive@ietf.org; Thu, 12 Feb 2004 00:26:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar9Lj-000488-00 for nfsv4-web-archive@ietf.org; Thu, 12 Feb 2004 00:25:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar9L0-0003xC-00 for nfsv4-web-archive@ietf.org; Thu, 12 Feb 2004 00:24:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9Ke-0003Nj-IT; Thu, 12 Feb 2004 00:24:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar8ei-0001Hd-OY for nfsv4@optimus.ietf.org; Wed, 11 Feb 2004 23:40:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23611 for ; Wed, 11 Feb 2004 23:40:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar8eg-0007lx-00 for nfsv4@ietf.org; Wed, 11 Feb 2004 23:40:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar8dj-0007hR-00 for nfsv4@ietf.org; Wed, 11 Feb 2004 23:39:52 -0500 Received: from smtp.engin.umich.edu ([141.213.75.24] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1Ar8cy-0007cy-00 for nfsv4@ietf.org; Wed, 11 Feb 2004 23:39:04 -0500 Received: from [192.168.0.61] (eecs497b.eecs.umich.edu [141.213.10.149]) (authenticated bits=0) by smtp.engin.umich.edu (8.12.9/8.12.9) with ESMTP id i1C4d1r9026164 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 11 Feb 2004 23:39:02 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6376D676-5D15-11D8-BB16-000A95CEA038@umich.edu> Content-Transfer-Encoding: 7bit Cc: "J. Bruce Fields" , From: Marius Aamodt Eriksen Subject: Re: {READ,WRITE}_NAMED_ATTRS (was RE: [nfsv4] I-D ACTION:draft-ietf-nfsv4-acl-mapping-01.txt) To: "Benny Halevy" X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Wed, 11 Feb 2004 23:39:05 -0500 Date: Wed, 11 Feb 2004 23:39:05 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Feb 11, 2004, at 23:10, Benny Halevy wrote: > I've been thinking more about the READ and WRITE NAMED_ATTRS > ACE access masks and I think I have more questions than > answers at this point. > > In draft-ietf-nfsv4-acl-mapping-01.txt you tie these access masks > with READ and WRITE DATA respectively. Is this the right thing to do? while there does not seem to be any defined behavior in posix for this; the extended attributes implementation in linux implements this scheme (and is why we adapted it). > Say you want to present some of the named attributes such > as "Description" or "Artist" or "Icon" when listing a directory. > You would want to be able to read their contents even when you are > not allowed to read the file's data. the problem is that there is no way to express this with posix acls. however the scheme we have adapted is consistent with what is being used together with posix acls in real systems today. but i do agree -- some users may wish for finer granularity, but we will not be able to express that in terms of posix ACLs. marius. -- marius a eriksen | http://www.citi.umich.edu/u/marius/ _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Thu Feb 12 11:51:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02139 for ; Thu, 12 Feb 2004 11:51:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArK3f-0001zP-Ie for nfsv4-archive@odin.ietf.org; Thu, 12 Feb 2004 11:51:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CGpNTr007646 for nfsv4-archive@odin.ietf.org; Thu, 12 Feb 2004 11:51:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArK3f-0001zF-Dl for nfsv4-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 11:51:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02120 for ; Thu, 12 Feb 2004 11:51:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArK3c-0000uV-00 for nfsv4-web-archive@ietf.org; Thu, 12 Feb 2004 11:51:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArK2h-0000pP-00 for nfsv4-web-archive@ietf.org; Thu, 12 Feb 2004 11:50:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArK2L-0000k5-00 for nfsv4-web-archive@ietf.org; Thu, 12 Feb 2004 11:50:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArK2M-0001pv-K8; Thu, 12 Feb 2004 11:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArK1h-0001ke-8s for nfsv4@optimus.ietf.org; Thu, 12 Feb 2004 11:49:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01968 for ; Thu, 12 Feb 2004 11:49:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArK1e-0000iP-00 for nfsv4@ietf.org; Thu, 12 Feb 2004 11:49:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArK0i-0000d6-00 for nfsv4@ietf.org; Thu, 12 Feb 2004 11:48:22 -0500 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1ArK09-0000WH-00 for nfsv4@ietf.org; Thu, 12 Feb 2004 11:47:45 -0500 Received: from hawk.corp.netapp.com (hawk [10.57.156.122]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i1CGlHJC009090 for ; Thu, 12 Feb 2004 08:47:17 -0800 (PST) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.10.22.171]) by hawk.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i1CGlGBp002160 for ; Thu, 12 Feb 2004 08:47:16 -0800 (PST) Received: from tmt.netapp.com ([10.97.6.38]) by silver.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 12 Feb 2004 11:47:03 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F187.D7359D80" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Message-ID: <5.2.1.1.2.20040212113506.01b0e020@silver.nane.netapp.com> Thread-Topic: I-D ACTION:draft-gibson-pnfs-problem-statement-00.txt Thread-Index: AcPxh9fLfOQf/8mTRA6q0anYuBFZIw== From: "Talpey, Thomas" To: Subject: [nfsv4] Fwd: I-D ACTION:draft-gibson-pnfs-problem-statement-00.txt Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Thu, 12 Feb 2004 08:46:48 -0800 Date: Thu, 12 Feb 2004 08:46:48 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F187.D7359D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In case folks haven't seen this. There's been an effort recently to explore using NFSv4 as a vehicle for parallel filesystem work. We hope to discuss this at the upcoming Connectathon and IETF meetings. More information below and at Tom. > ---------- Forwarded Message ---------- >Subject: I-D ACTION:draft-gibson-pnfs-problem-statement-00.txt >Date: Mon, 9 Feb 2004 16:15:13 -0500 >From: >Reply-To: > >A New Internet-Draft is available from the on-line Internet-Drafts = directories. > > > Title : pNFS Problem Statement > Author(s) : G. Gibson > Filename : draft-gibson-pnfs-problem-statement-00.txt > Pages : 12 > Date : 2004-2-9 >=09 >This draft considers the problem of limited bandwidth to NFS servers. =20 > The bandwidth limitation exists because an NFS server has limited=20 > network, CPU, memory and disk I/O resources. Yet, access to any one = > file system through the NFSv4 protocol requires that a single server = > be accessed. While NFSv4 allows file system migration, it does not=20 > provide a mechanism that supports multiple servers simultaneously=20 > exporting a single writable file system.=20 > =20 > This problem has become aggravated in recent years with the advent = of=20 > very cheap and easily expanded clusters of application servers that=20 > are also NFS clients. The aggregate bandwidth demands of such=20 > clustered clients, typically working on a shared data set=20 > preferentially stored in a single file system, can increase much = more=20 > quickly than the bandwidth of any server. The proposed solution is=20 > to provide for the parallelization of file services, by enhancing=20 > NFSv4 in a minor version. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-gibson-pnfs-problem-statement-= 00.txt > >To remove yourself from the IETF Announcement list, send a message to=20 >ietf-announce-request with the word unsubscribe in the body of the = message. > >Internet-Drafts are also available by anonymous FTP. Login with the = username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-gibson-pnfs-problem-statement-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html=20 >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-gibson-pnfs-problem-statement-00.txt". >=09 >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > ---------- End of Forwarded Message ----------=20 ------_=_NextPart_001_01C3F187.D7359D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fwd: I-D = ACTION:draft-gibson-pnfs-problem-statement-00.txt

In case folks haven't seen this.

There's been an effort recently to explore using NFSv4 = as a vehicle
for parallel filesystem work. We hope to discuss this = at the upcoming
Connectathon and IETF meetings.

More information below and at <http://www.citi.umich.edu/NEPS>

Tom.

> ---------- Forwarded Message ----------
>Subject: I-D = ACTION:draft-gibson-pnfs-problem-statement-00.txt
>Date: Mon, 9 Feb 2004 16:15:13 -0500
>From: <Internet-Drafts@ietf.org>
>Reply-To: <Internet-Drafts@ietf.org>
>
>A New Internet-Draft is available from the = on-line Internet-Drafts directories.
>
>
>       = Title           : pNFS = Problem Statement
>       = Author(s)       : G. Gibson
>       = Filename        : = draft-gibson-pnfs-problem-statement-00.txt
>       = Pages           : 12
>       = Date            : = 2004-2-9
>      
>This draft considers the problem of limited = bandwidth to NFS servers. 
>   The bandwidth limitation exists = because an NFS server has limited
>   network, CPU, memory and disk I/O = resources.  Yet, access to any one
>   file system through the NFSv4 = protocol requires that a single server
>   be accessed.  While NFSv4 = allows file system migration, it does not
>   provide a mechanism that supports = multiple servers simultaneously
>   exporting a single writable file = system.
>   
>   This problem has become aggravated = in recent years with the advent of
>   very cheap and easily expanded = clusters of application servers that
>   are also NFS clients.  The = aggregate bandwidth demands of such
>   clustered clients, typically working = on a shared data set
>   preferentially stored in a single = file system, can increase much more
>   quickly than the bandwidth of any = server.  The proposed solution is
>   to provide for the parallelization = of file services, by enhancing
>   NFSv4 in a minor version.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-gibson-pnfs-prob= lem-statement-00.txt
>
>To remove yourself from the IETF Announcement = list, send a message to
>ietf-announce-request with the word unsubscribe = in the body of the message.
>
>Internet-Drafts are also available by anonymous = FTP. Login with the username
>"anonymous" and a password of your = e-mail address. After logging in,
>type "cd internet-drafts" and = then
>       "get = draft-gibson-pnfs-problem-statement-00.txt".
>
>A list of Internet-Drafts directories can be = found in
>http://www.ietf.org/shadow.html<= /A>
>or ftp://ftp.ietf.org/iet= f/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by = e-mail.
>
>Send a message to:
>       = mailserv@ietf.org.
>In the body type:
>       "FILE = /internet-drafts/draft-gibson-pnfs-problem-statement-00.txt".=
>      
>NOTE:  The mail server at ietf.org can = return the document in
>       MIME-encoded = form by using the "mpack" utility.  To use this
>       feature, = insert the command "ENCODING mime" before the = "FILE"
>       = command.  To decode the response(s), you will need = "munpack" or
>       a = MIME-compliant mail reader.  Different MIME-compliant mail = readers
>       exhibit = different behavior, especially when dealing with
>       = "multipart" MIME messages (i.e. documents which have been = split
>       up into = multiple messages), so check your local documentation on
>       how to = manipulate these messages.
>       =        
>       =        
>Below is the data which will enable a MIME = compliant mail reader
>implementation to automatically retrieve the = ASCII version of the
>Internet-Draft.
>
>
> ---------- End of Forwarded Message ---------- =

------_=_NextPart_001_01C3F187.D7359D80-- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Fri Feb 13 16:28:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06182 for ; Fri, 13 Feb 2004 16:28:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arkqx-0006FV-Tc for nfsv4-archive@odin.ietf.org; Fri, 13 Feb 2004 16:28:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DLS3bZ024015 for nfsv4-archive@odin.ietf.org; Fri, 13 Feb 2004 16:28:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arkqx-0006FG-O2 for nfsv4-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 16:28:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06076 for ; Fri, 13 Feb 2004 16:28:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arkqv-0004dP-00 for nfsv4-web-archive@ietf.org; Fri, 13 Feb 2004 16:28:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arkpu-0004Vf-00 for nfsv4-web-archive@ietf.org; Fri, 13 Feb 2004 16:26:59 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Arkp4-0004LR-00 for nfsv4-web-archive@ietf.org; Fri, 13 Feb 2004 16:26:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Arkp4-0006uC-N6 for nfsv4-web-archive@ietf.org; Fri, 13 Feb 2004 16:26:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arkp0-00069y-GR; Fri, 13 Feb 2004 16:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkaK-0003wX-HH for nfsv4@optimus.ietf.org; Fri, 13 Feb 2004 16:10:52 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03848; Fri, 13 Feb 2004 16:10:49 -0500 (EST) Message-Id: <200402132110.QAA03848@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nfsv4@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [nfsv4] I-D ACTION:draft-ietf-nfsv4-nfs-rdma-problem-statement-00.txt Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Fri, 13 Feb 2004 16:10:49 -0500 Date: Fri, 13 Feb 2004 16:10:49 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network File System Version 4 Working Group of the IETF. Title : NFS RDMA Problem Statement Author(s) : T. Talpey Filename : draft-ietf-nfsv4-nfs-rdma-problem-statement-00.txt Pages : 15 Date : 2004-2-12 This draft addresses applying Remote Direct Memory Access to the NFS protocols. NFS implementations historically incur significant overhead due to data copies on end-host systems, as well as other sources. The potential benefits of RDMA to these implementations are explored, and the reasons why RDMA is especially well-suited to NFS and network file protocols in general are evaluated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-nfs-rdma-problem-statement-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nfsv4-nfs-rdma-problem-statement-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nfsv4-nfs-rdma-problem-statement-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-13163304.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nfsv4-nfs-rdma-problem-statement-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nfsv4-nfs-rdma-problem-statement-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-13163304.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Fri Feb 13 16:39:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07802 for ; Fri, 13 Feb 2004 16:39:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arl23-0007Jo-C4 for nfsv4-archive@odin.ietf.org; Fri, 13 Feb 2004 16:39:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DLdVV1028126 for nfsv4-archive@odin.ietf.org; Fri, 13 Feb 2004 16:39:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arl23-0007JZ-83 for nfsv4-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 16:39:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07727 for ; Fri, 13 Feb 2004 16:39:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arl21-0006vN-00 for nfsv4-web-archive@ietf.org; Fri, 13 Feb 2004 16:39:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arl10-0006jQ-00 for nfsv4-web-archive@ietf.org; Fri, 13 Feb 2004 16:38:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arkzb-0006Qa-00 for nfsv4-web-archive@ietf.org; Fri, 13 Feb 2004 16:36:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arkzc-0006r1-PC; Fri, 13 Feb 2004 16:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arkyi-0006cV-Nk for nfsv4@optimus.ietf.org; Fri, 13 Feb 2004 16:36:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06954 for ; Fri, 13 Feb 2004 16:36:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arkyg-0006DH-00 for nfsv4@ietf.org; Fri, 13 Feb 2004 16:36:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArkwU-0005jH-00 for nfsv4@ietf.org; Fri, 13 Feb 2004 16:33:49 -0500 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1ArkuD-000571-00 for nfsv4@ietf.org; Fri, 13 Feb 2004 16:31:25 -0500 Received: from frejya.corp.netapp.com (frejya [10.57.157.119]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i1DLUsJC025506 for ; Fri, 13 Feb 2004 13:30:54 -0800 (PST) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.10.22.171]) by frejya.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i1DLUkiV013259 for ; Fri, 13 Feb 2004 13:30:54 -0800 (PST) Received: from tmt.netapp.com ([10.97.1.34]) by silver.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Feb 2004 16:29:29 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F278.7639C280" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Message-ID: <5.2.1.1.2.20040213162734.00c50f40@silver.nane.netapp.com> Thread-Topic: I-D ACTION:draft-talpey-nfs-rdma-problem-statement-01.txt Thread-Index: AcPyeHbfn3WJbs/mRK6Lt8ClnZ46FQ== From: "Talpey, Thomas" To: Subject: [nfsv4] Fwd: I-D ACTION:draft-talpey-nfs-rdma-problem-statement-01.txt Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Fri, 13 Feb 2004 13:28:54 -0800 Date: Fri, 13 Feb 2004 13:28:54 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F278.7639C280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI the NFS/RDMA Problem statement has been updated. The changes are minor, largely updating the references. Comments are welcome. Tom Talpey and Chet Juszczak. > ---------- Forwarded Message ---------- >Subject: I-D ACTION:draft-talpey-nfs-rdma-problem-statement-01.txt >Date: Fri, 13 Feb 2004 16:10:05 -0500 >From: >Reply-To: > >A New Internet-Draft is available from the on-line Internet-Drafts = directories. > > > Title : NFS RDMA Problem Statement > Author(s) : T. Talpey > Filename : draft-talpey-nfs-rdma-problem-statement-01.txt > Pages : 15 > Date : 2004-2-12 >=09 >This draft addresses applying Remote Direct Memory Access to the >NFS protocols. NFS implementations historically incur significant >overhead due to data copies on end-host systems, as well as other >sources. The potential benefits of RDMA to these implementations >are explored, and the reasons why RDMA is especially well-suited to >NFS and network file protocols in general are evaluated. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-talpey-nfs-rdma-problem-statem= ent- >01.txt > >To remove yourself from the IETF Announcement list, send a message to=20 >ietf-announce-request with the word unsubscribe in the body of the = message. > >Internet-Drafts are also available by anonymous FTP. Login with the = username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-talpey-nfs-rdma-problem-statement-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html=20 >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE = /internet-drafts/draft-talpey-nfs-rdma-problem-statement-01.txt". >=09 >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > ---------- End of Forwarded Message ----------=20 ------_=_NextPart_001_01C3F278.7639C280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fwd: I-D = ACTION:draft-talpey-nfs-rdma-problem-statement-01.txt

FYI the NFS/RDMA Problem statement has been = updated.
The changes are minor, largely updating the = references.
Comments are welcome.

Tom Talpey and Chet Juszczak.

> ---------- Forwarded Message ----------
>Subject: I-D = ACTION:draft-talpey-nfs-rdma-problem-statement-01.txt
>Date: Fri, 13 Feb 2004 16:10:05 -0500
>From: <Internet-Drafts@ietf.org>
>Reply-To: <Internet-Drafts@ietf.org>
>
>A New Internet-Draft is available from the = on-line Internet-Drafts directories.
>
>
>       = Title           : NFS RDMA = Problem Statement
>       = Author(s)       : T. Talpey
>       = Filename        : = draft-talpey-nfs-rdma-problem-statement-01.txt
>       = Pages           : 15
>       = Date            : = 2004-2-12
>      
>This draft addresses applying Remote Direct = Memory Access to the
>NFS protocols.  NFS implementations = historically incur significant
>overhead due to data copies on end-host systems, = as well as other
>sources.  The potential benefits of RDMA to = these implementations
>are explored, and the reasons why RDMA is = especially well-suited to
>NFS and network file protocols in general are = evaluated.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-talpey-nfs-rdma-pr= oblem-statement-
>01.txt
>
>To remove yourself from the IETF Announcement = list, send a message to
>ietf-announce-request with the word unsubscribe = in the body of the message.
>
>Internet-Drafts are also available by anonymous = FTP. Login with the username
>"anonymous" and a password of your = e-mail address. After logging in,
>type "cd internet-drafts" and = then
>       "get = draft-talpey-nfs-rdma-problem-statement-01.txt".
>
>A list of Internet-Drafts directories can be = found in
>http://www.ietf.org/shadow.html<= /A>
>or ftp://ftp.ietf.org/iet= f/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by = e-mail.
>
>Send a message to:
>       = mailserv@ietf.org.
>In the body type:
>       "FILE = /internet-drafts/draft-talpey-nfs-rdma-problem-statement-01.txt".
>      
>NOTE:  The mail server at ietf.org can = return the document in
>       MIME-encoded = form by using the "mpack" utility.  To use this
>       feature, = insert the command "ENCODING mime" before the = "FILE"
>       = command.  To decode the response(s), you will need = "munpack" or
>       a = MIME-compliant mail reader.  Different MIME-compliant mail = readers
>       exhibit = different behavior, especially when dealing with
>       = "multipart" MIME messages (i.e. documents which have been = split
>       up into = multiple messages), so check your local documentation on
>       how to = manipulate these messages.
>       =        
>       =        
>Below is the data which will enable a MIME = compliant mail reader
>implementation to automatically retrieve the = ASCII version of the
>Internet-Draft.
>
>
> ---------- End of Forwarded Message ---------- =

------_=_NextPart_001_01C3F278.7639C280-- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Fri Feb 13 16:58:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09395 for ; Fri, 13 Feb 2004 16:58:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlKF-0008OP-DJ for nfsv4-archive@odin.ietf.org; Fri, 13 Feb 2004 16:58:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DLwJ06032255 for nfsv4-archive@odin.ietf.org; Fri, 13 Feb 2004 16:58:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlKE-0008OA-TS for nfsv4-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 16:58:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09384 for ; Fri, 13 Feb 2004 16:58:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArlKC-0001Qu-00 for nfsv4-web-archive@ietf.org; Fri, 13 Feb 2004 16:58:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArlJI-0001Mx-00 for nfsv4-web-archive@ietf.org; Fri, 13 Feb 2004 16:57:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArlIy-0001Ik-00 for nfsv4-web-archive@ietf.org; Fri, 13 Feb 2004 16:57:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlIz-0008Hw-P2; Fri, 13 Feb 2004 16:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArlIK-0008Fv-8Z for nfsv4@optimus.ietf.org; Fri, 13 Feb 2004 16:56:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09282 for ; Fri, 13 Feb 2004 16:56:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArlII-0001Hj-00 for nfsv4@ietf.org; Fri, 13 Feb 2004 16:56:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArlHR-0001Dt-00 for nfsv4@ietf.org; Fri, 13 Feb 2004 16:55:27 -0500 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1ArlH3-00018w-00 for nfsv4@ietf.org; Fri, 13 Feb 2004 16:55:02 -0500 Received: from hawk.corp.netapp.com (hawk [10.57.156.122]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i1DLsWJC029009 for ; Fri, 13 Feb 2004 13:54:32 -0800 (PST) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.10.22.171]) by hawk.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i1DLsMmG014122 for ; Fri, 13 Feb 2004 13:54:31 -0800 (PST) Received: from tmt.netapp.com ([10.97.1.34]) by silver.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 13 Feb 2004 16:54:11 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F27B.E9910380" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: Re: [nfsv4] I-D ACTION:draft-ietf-nfsv4-nfs-rdma-problem-statement-00.txt Message-ID: <5.2.1.1.2.20040213165017.023f7008@silver.nane.netapp.com> Thread-Topic: [nfsv4] I-D ACTION:draft-ietf-nfsv4-nfs-rdma-problem-statement-00.txt Thread-Index: AcPye+nZ/T1LkMn3T/aDXt9QAbFNfQ== From: "Talpey, Thomas" To: Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Fri, 13 Feb 2004 13:53:40 -0800 Date: Fri, 13 Feb 2004 13:53:40 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F27B.E9910380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OBTW. This is the same document as the earlier one, draft-talpey-nfs-rdma-problem-statement-01.txt=20 This one is the official work group item, per the charter and earlier discussion. Due to a glitch in the document approval process, two documents were queued! Sorry for the confusion, please read this one, comments welcome. Tom Talpey and Chet Juszczak. At 04:10 PM 2/13/2004, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts = directories. >This draft is a work item of the Network File System Version 4 Working = Group=20 >of the IETF. > > Title : NFS RDMA Problem Statement > Author(s) : T. Talpey > Filename : draft-ietf-nfsv4-nfs-rdma-problem-statement-00.txt > Pages : 15 > Date : 2004-2-12 >=09 >This draft addresses applying Remote Direct Memory Access to the > NFS protocols. NFS implementations historically incur significant > overhead due to data copies on end-host systems, as well as other > sources. The potential benefits of RDMA to these implementations > are explored, and the reasons why RDMA is especially well-suited = to > NFS and network file protocols in general are evaluated. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-nfs-rdma-problem-st= atem >ent-00.txt > >To remove yourself from the IETF Announcement list, send a message to=20 >ietf-announce-request with the word unsubscribe in the body of the = message. > >Internet-Drafts are also available by anonymous FTP. Login with the = username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-nfsv4-nfs-rdma-problem-statement-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html=20 >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE = /internet-drafts/draft-ietf-nfsv4-nfs-rdma-problem-statement-00.txt". >=09 >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > ------_=_NextPart_001_01C3F27B.E9910380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [nfsv4] I-D = ACTION:draft-ietf-nfsv4-nfs-rdma-problem-statement-00.txt

OBTW. This is the same document as the earlier = one,
        draft-talpey-nfs-rdma-problem-statement-01.txt

This one is the official work group item, per the = charter and
earlier discussion. Due to a glitch in the document = approval
process, two documents were queued! Sorry for the = confusion,
please read this one, comments welcome.

Tom Talpey and Chet Juszczak.

At 04:10 PM 2/13/2004, Internet-Drafts@ietf.org = wrote:
>A New Internet-Draft is available from the = on-line Internet-Drafts directories.
>This draft is a work item of the Network File = System Version 4 Working Group
>of the IETF.
>
>       = Title           : NFS RDMA = Problem Statement
>       = Author(s)       : T. Talpey
>       = Filename        : = draft-ietf-nfsv4-nfs-rdma-problem-statement-00.txt
>       = Pages           : 15
>       = Date            : = 2004-2-12
>      
>This draft addresses applying Remote Direct = Memory Access to the
>     NFS protocols.  NFS = implementations historically incur significant
>     overhead due to data = copies on end-host systems, as well as other
>     sources.  The = potential benefits of RDMA to these implementations
>     are explored, and the = reasons why RDMA is especially well-suited to
>     NFS and network file = protocols in general are evaluated.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-nfs-rdm= a-problem-statem
>ent-00.txt
>
>To remove yourself from the IETF Announcement = list, send a message to
>ietf-announce-request with the word unsubscribe = in the body of the message.
>
>Internet-Drafts are also available by anonymous = FTP. Login with the username
>"anonymous" and a password of your = e-mail address. After logging in,
>type "cd internet-drafts" and = then
>       "get = draft-ietf-nfsv4-nfs-rdma-problem-statement-00.txt".
>
>A list of Internet-Drafts directories can be = found in
>http://www.ietf.org/shadow.html<= /A>
>or ftp://ftp.ietf.org/iet= f/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by = e-mail.
>
>Send a message to:
>       = mailserv@ietf.org.
>In the body type:
>       "FILE = /internet-drafts/draft-ietf-nfsv4-nfs-rdma-problem-statement-00.txt"= .
>      
>NOTE:  The mail server at ietf.org can = return the document in
>       MIME-encoded = form by using the "mpack" utility.  To use this
>       feature, = insert the command "ENCODING mime" before the = "FILE"
>       = command.  To decode the response(s), you will need = "munpack" or
>       a = MIME-compliant mail reader.  Different MIME-compliant mail = readers
>       exhibit = different behavior, especially when dealing with
>       = "multipart" MIME messages (i.e. documents which have been = split
>       up into = multiple messages), so check your local documentation on
>       how to = manipulate these messages.
>       =        
>       =        
>Below is the data which will enable a MIME = compliant mail reader
>implementation to automatically retrieve the = ASCII version of the
>Internet-Draft.
>
>

------_=_NextPart_001_01C3F27B.E9910380-- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Tue Feb 17 12:53:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21694 for ; Tue, 17 Feb 2004 12:53:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9PH-0001G2-Hl for nfsv4-archive@odin.ietf.org; Tue, 17 Feb 2004 12:53:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HHrFe5004828 for nfsv4-archive@odin.ietf.org; Tue, 17 Feb 2004 12:53:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9PH-0001Fn-Bm for nfsv4-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 12:53:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21691 for ; Tue, 17 Feb 2004 12:53:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At9PF-00042G-00 for nfsv4-web-archive@ietf.org; Tue, 17 Feb 2004 12:53:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At9OI-0003zz-00 for nfsv4-web-archive@ietf.org; Tue, 17 Feb 2004 12:52:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At9O6-0003xc-00 for nfsv4-web-archive@ietf.org; Tue, 17 Feb 2004 12:52:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9O4-0001Bv-Su; Tue, 17 Feb 2004 12:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At9NJ-0001BG-7s for nfsv4@optimus.ietf.org; Tue, 17 Feb 2004 12:51:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21637 for ; Tue, 17 Feb 2004 12:51:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At9NH-0003wm-00 for nfsv4@ietf.org; Tue, 17 Feb 2004 12:51:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At9MM-0003uc-00 for nfsv4@ietf.org; Tue, 17 Feb 2004 12:50:15 -0500 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1At9Lc-0003pG-00 for nfsv4@ietf.org; Tue, 17 Feb 2004 12:49:28 -0500 Received: from hawk.corp.netapp.com (hawk [10.57.156.122]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i1HHmvJC005743 for ; Tue, 17 Feb 2004 09:48:57 -0800 (PST) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.10.22.171]) by hawk.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i1HHmum4022690 for ; Tue, 17 Feb 2004 09:48:56 -0800 (PST) Received: from tmt.netapp.com ([10.97.1.35]) by silver.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Feb 2004 12:48:50 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F57E.4CD1AD00" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Message-ID: <5.2.1.1.2.20040217104921.026f9548@silver.nane.netapp.com> Thread-Topic: I-D ACTION:draft-talpey-nfsv4-rdma-sess-01.txt Thread-Index: AcP1fk2TD/JZ4c94R9+mqbjBN2q+Pg== From: "Talpey, Thomas" To: Subject: [nfsv4] Fwd: I-D ACTION:draft-talpey-nfsv4-rdma-sess-01.txt Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Tue, 17 Feb 2004 09:47:59 -0800 Date: Tue, 17 Feb 2004 09:47:59 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F57E.4CD1AD00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable One more draft to mention... The v4/sessions document has been updated and is available from the I-D repository. This update pulls in comments we received in the working group discussions over the past months. The protocol in the proposal is largely unchanged, except to raise the scope of the "streamid" to the session, from the connection. One session operation was slightly renamed and one argument was removed from another. The more visible change to the document was to rearrange and separate the sessions discussion, relative to RDMA. Since the sessions piece is transport-independent, this organizes the document more cleanly and clearly. Tom Talpey and Spencer Shepler. > ---------- Forwarded Message ---------- >Subject: I-D ACTION:draft-talpey-nfsv4-rdma-sess-01.txt >Date: Mon, 16 Feb 2004 15:36:51 -0500 >From: >Reply-To: > >A New Internet-Draft is available from the on-line Internet-Drafts = directories. > > > Title : NFSv4 RDMA and Session Extensions > Author(s) : T. Talpey, S. Shepler > Filename : draft-talpey-nfsv4-rdma-sess-01.txt > Pages : 47 > Date : 2004-2-16 >=09 >Extensions are proposed to NFS version 4 which enable it to support >sessions, connection management, and operation atop RDMA-capable >RPC. These extensions enable universal support for Exactly-once >Semantics by NFSv4 servers, enhanced security, and multipathing and >trunking of transport connections. These extensions provide >identical benefit over both TCP and RDMA connection types. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-talpey-nfsv4-rdma-sess-01.txt > >To remove yourself from the IETF Announcement list, send a message to=20 >ietf-announce-request with the word unsubscribe in the body of the = message. > >Internet-Drafts are also available by anonymous FTP. Login with the = username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-talpey-nfsv4-rdma-sess-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html=20 >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-talpey-nfsv4-rdma-sess-01.txt". >=09 >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > ---------- End of Forwarded Message ----------=20 ------_=_NextPart_001_01C3F57E.4CD1AD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fwd: I-D ACTION:draft-talpey-nfsv4-rdma-sess-01.txt

One more draft to mention...

The v4/sessions document has been updated and is = available
from the I-D repository. This update pulls in = comments we
received in the working group discussions over the = past months.

The protocol in the proposal is largely unchanged, = except to
raise the scope of the "streamid" to the = session, from the
connection. One session operation was slightly = renamed and
one argument was removed from another.

The more visible change to the document was to = rearrange
and separate the sessions discussion, relative to = RDMA. Since
the sessions piece is transport-independent, this = organizes
the document more cleanly and clearly.

Tom Talpey and Spencer Shepler.

> ---------- Forwarded Message ----------
>Subject: I-D = ACTION:draft-talpey-nfsv4-rdma-sess-01.txt
>Date: Mon, 16 Feb 2004 15:36:51 -0500
>From: <Internet-Drafts@ietf.org>
>Reply-To: <Internet-Drafts@ietf.org>
>
>A New Internet-Draft is available from the = on-line Internet-Drafts directories.
>
>
>       = Title           : NFSv4 = RDMA and Session Extensions
>       = Author(s)       : T. Talpey, S. = Shepler
>       = Filename        : = draft-talpey-nfsv4-rdma-sess-01.txt
>       = Pages           : 47
>       = Date            : = 2004-2-16
>      
>Extensions are proposed to NFS version 4 which = enable it to support
>sessions, connection management, and operation = atop RDMA-capable
>RPC.  These extensions enable universal = support for Exactly-once
>Semantics by NFSv4 servers, enhanced security, = and multipathing and
>trunking of transport connections.  These = extensions provide
>identical benefit over both TCP and RDMA = connection types.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-talpey-nfsv4-rdma-sess-= 01.txt
>
>To remove yourself from the IETF Announcement = list, send a message to
>ietf-announce-request with the word unsubscribe = in the body of the message.
>
>Internet-Drafts are also available by anonymous = FTP. Login with the username
>"anonymous" and a password of your = e-mail address. After logging in,
>type "cd internet-drafts" and = then
>       "get = draft-talpey-nfsv4-rdma-sess-01.txt".
>
>A list of Internet-Drafts directories can be = found in
>http://www.ietf.org/shadow.html<= /A>
>or ftp://ftp.ietf.org/iet= f/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by = e-mail.
>
>Send a message to:
>       = mailserv@ietf.org.
>In the body type:
>       "FILE = /internet-drafts/draft-talpey-nfsv4-rdma-sess-01.txt".
>      
>NOTE:  The mail server at ietf.org can = return the document in
>       MIME-encoded = form by using the "mpack" utility.  To use this
>       feature, = insert the command "ENCODING mime" before the = "FILE"
>       = command.  To decode the response(s), you will need = "munpack" or
>       a = MIME-compliant mail reader.  Different MIME-compliant mail = readers
>       exhibit = different behavior, especially when dealing with
>       = "multipart" MIME messages (i.e. documents which have been = split
>       up into = multiple messages), so check your local documentation on
>       how to = manipulate these messages.
>       =        
>       =        
>Below is the data which will enable a MIME = compliant mail reader
>implementation to automatically retrieve the = ASCII version of the
>Internet-Draft.
>
>
> ---------- End of Forwarded Message ---------- =

------_=_NextPart_001_01C3F57E.4CD1AD00-- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Wed Feb 18 12:16:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29747 for ; Wed, 18 Feb 2004 12:16:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtVIq-0006d6-KX for nfsv4-archive@odin.ietf.org; Wed, 18 Feb 2004 12:16:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IHG4bL025478 for nfsv4-archive@odin.ietf.org; Wed, 18 Feb 2004 12:16:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtVIq-0006ca-E5 for nfsv4-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 12:16:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29653 for ; Wed, 18 Feb 2004 12:16:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtVIp-0004yG-00 for nfsv4-web-archive@ietf.org; Wed, 18 Feb 2004 12:16:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtVHo-0004qv-00 for nfsv4-web-archive@ietf.org; Wed, 18 Feb 2004 12:15:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtVGu-0004nr-00 for nfsv4-web-archive@ietf.org; Wed, 18 Feb 2004 12:14:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtVGr-0006Pu-T7; Wed, 18 Feb 2004 12:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtVFx-0006Ok-On for nfsv4@optimus.ietf.org; Wed, 18 Feb 2004 12:13:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29533 for ; Wed, 18 Feb 2004 12:13:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtVFw-0004jh-00 for nfsv4@ietf.org; Wed, 18 Feb 2004 12:13:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtVF1-0004ga-00 for nfsv4@ietf.org; Wed, 18 Feb 2004 12:12:07 -0500 Received: from web60202.mail.yahoo.com ([216.109.118.97]) by ietf-mx with smtp (Exim 4.12) id 1AtVEa-0004cy-00 for nfsv4@ietf.org; Wed, 18 Feb 2004 12:11:40 -0500 Message-ID: <20040218171106.78335.qmail@web60202.mail.yahoo.com> Received: from [148.87.1.171] by web60202.mail.yahoo.com via HTTP; Wed, 18 Feb 2004 09:11:06 PST From: namit jain To: nfsv4@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [nfsv4] WRITE_LT locks Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Wed, 18 Feb 2004 09:11:05 -0800 (PST) Date: Wed, 18 Feb 2004 09:11:05 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi, Are WRITE_LT locks commonly used by NFS clients ? What I am trying to find out is whether it is a common operation, or a relatively very rare operation as opposed to reads. Thanks, -namit __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Tue Feb 24 12:23:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00215 for ; Tue, 24 Feb 2004 12:23:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvgGv-0008Nt-4D for nfsv4-archive@odin.ietf.org; Tue, 24 Feb 2004 12:23:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OHN5Qx032223 for nfsv4-archive@odin.ietf.org; Tue, 24 Feb 2004 12:23:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvgGu-0008Ne-Vy for nfsv4-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 12:23:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00208 for ; Tue, 24 Feb 2004 12:23:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvgGt-0004bB-00 for nfsv4-web-archive@ietf.org; Tue, 24 Feb 2004 12:23:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvgFv-0004QV-00 for nfsv4-web-archive@ietf.org; Tue, 24 Feb 2004 12:22:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvgEx-0004IL-00 for nfsv4-web-archive@ietf.org; Tue, 24 Feb 2004 12:21:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvgEv-0008Cs-DY; Tue, 24 Feb 2004 12:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvgEf-0008C8-R0 for nfsv4@optimus.ietf.org; Tue, 24 Feb 2004 12:20:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00143 for ; Tue, 24 Feb 2004 12:20:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvgEe-0004Ea-00 for nfsv4@ietf.org; Tue, 24 Feb 2004 12:20:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvgDC-00044l-00 for nfsv4@ietf.org; Tue, 24 Feb 2004 12:19:14 -0500 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1AvgCi-0003yZ-00 for nfsv4@ietf.org; Tue, 24 Feb 2004 12:18:44 -0500 Received: from hawk.corp.netapp.com (hawk [10.57.156.122]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i1OHI8JC027129 for ; Tue, 24 Feb 2004 09:18:08 -0800 (PST) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.10.22.171]) by hawk.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i1OHI4Dq015694 for ; Tue, 24 Feb 2004 09:18:08 -0800 (PST) Received: from tmt.netapp.com ([10.97.6.35]) by silver.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Feb 2004 12:17:13 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FAFA.0B02B280" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Message-ID: <6.0.3.0.2.20040224120132.01b7fec0@silver.nane.netapp.com> Thread-Topic: NFS RDMA Linux client talk is online Thread-Index: AcP6+gt19uwzwXabTB+Rjrvx5XEL3A== From: "Talpey, Thomas" To: Subject: [nfsv4] NFS RDMA Linux client talk is online Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Tue, 24 Feb 2004 09:17:04 -0800 Date: Tue, 24 Feb 2004 09:17:04 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FAFA.0B02B280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI, a talk I gave at Connectathon yesterday on our NFS/RDMA client in Linux is online at: = This talk has an overview of the various protocol drafts and how they fit together, as well as details of the implementation of the RPC/RDMA transport in Linux. This transport is being tested with NFSv3 on Infiniband here at Connectathon. There is also backup material in the presentation on the recent update to the NFSv4/RDMA/Sessions proposal, which is part of the possible v4.1 work. Many URLs in the presentation. Comments or questions are welcome! Tom. ------_=_NextPart_001_01C3FAFA.0B02B280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable NFS RDMA Linux client talk is online

FYI, a talk I gave at Connectathon yesterday on = our
NFS/RDMA client in Linux is online at:

        <http://www.citi.umich.edu/projects/rdma/refs/NFS-RDMA_Linux_CT= hon_2004.pdf>

This talk has an overview of the various = protocol
drafts and how they fit together, as well as = details
of the implementation of the RPC/RDMA = transport
in Linux. This transport is being tested with = NFSv3
on Infiniband here at Connectathon.

There is also backup material in the = presentation
on the recent update to the = NFSv4/RDMA/Sessions
proposal, which is part of the possible v4.1 = work.

Many URLs in the presentation. Comments or
questions are welcome!

Tom.

------_=_NextPart_001_01C3FAFA.0B02B280-- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Fri Feb 27 17:19:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28504 for ; Fri, 27 Feb 2004 17:19:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwqJi-0002yR-SP for nfsv4-archive@odin.ietf.org; Fri, 27 Feb 2004 17:18:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RMIk42011427 for nfsv4-archive@odin.ietf.org; Fri, 27 Feb 2004 17:18:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwqJi-0002yE-O1 for nfsv4-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 17:18:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28471 for ; Fri, 27 Feb 2004 17:18:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwqJg-00076A-00 for nfsv4-web-archive@ietf.org; Fri, 27 Feb 2004 17:18:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwqIk-0006yj-00 for nfsv4-web-archive@ietf.org; Fri, 27 Feb 2004 17:17:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwqI1-0006ot-00 for nfsv4-web-archive@ietf.org; Fri, 27 Feb 2004 17:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwqI1-0002kb-Bs; Fri, 27 Feb 2004 17:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwqHo-0002it-3R for nfsv4@optimus.ietf.org; Fri, 27 Feb 2004 17:16:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28208 for ; Fri, 27 Feb 2004 17:16:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwqHl-0006mU-00 for nfsv4@ietf.org; Fri, 27 Feb 2004 17:16:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwqGj-0006Yt-00 for nfsv4@ietf.org; Fri, 27 Feb 2004 17:15:42 -0500 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1AwqFz-0006Mz-00 for nfsv4@ietf.org; Fri, 27 Feb 2004 17:14:55 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i1RMEOF4607014 for ; Fri, 27 Feb 2004 17:14:24 -0500 Received: from d03nm113.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1RMEOHj136164 for ; Fri, 27 Feb 2004 15:14:24 -0700 To: nfsv4@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Stevan Steve Allen X-MIMETrack: Serialize by Router on D03NM113/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 02/27/2004 15:14:23, Serialize complete at 02/27/2004 15:14:23 Content-Type: multipart/alternative; boundary="=_alternative 007A295988256E47_=" Subject: [nfsv4] (no subject) Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Fri, 27 Feb 2004 14:14:21 -0800 Date: Fri, 27 Feb 2004 14:14:21 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 007A295988256E47_= Content-Type: text/plain; charset="US-ASCII" Question.. If Owner & Group name strings are not supported by the server for SETATTR. Can the server return it's internal string representation for owner and group without a domain name (which is unknown) in GETATTR/READDIR? Thanks, Stevan C. Allen NFS Development --=_alternative 007A295988256E47_= Content-Type: text/html; charset="US-ASCII"
Question..

If Owner & Group name strings are not supported by the server for SETATTR.  Can the server return it's internal string representation for owner and group without a domain name (which is unknown) in GETATTR/READDIR?

Thanks,
Stevan C. Allen
NFS Development
 --=_alternative 007A295988256E47_=-- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Fri Feb 27 17:46:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29700 for ; Fri, 27 Feb 2004 17:46:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awqk0-0004Iz-Gm for nfsv4-archive@odin.ietf.org; Fri, 27 Feb 2004 17:45:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RMjuR6016545 for nfsv4-archive@odin.ietf.org; Fri, 27 Feb 2004 17:45:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awqk0-0004Im-BU for nfsv4-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 17:45:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29693 for ; Fri, 27 Feb 2004 17:45:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awqjx-0002L8-00 for nfsv4-web-archive@ietf.org; Fri, 27 Feb 2004 17:45:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awqj1-0002CZ-00 for nfsv4-web-archive@ietf.org; Fri, 27 Feb 2004 17:44:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Awqi7-000250-00 for nfsv4-web-archive@ietf.org; Fri, 27 Feb 2004 17:43:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awqi8-00045e-Sj; Fri, 27 Feb 2004 17:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awqi0-00044V-Te for nfsv4@optimus.ietf.org; Fri, 27 Feb 2004 17:43:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29593 for ; Fri, 27 Feb 2004 17:43:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awqhy-00023C-00 for nfsv4@ietf.org; Fri, 27 Feb 2004 17:43:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awqh3-0001va-00 for nfsv4@ietf.org; Fri, 27 Feb 2004 17:42:54 -0500 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1AwqgJ-0001kq-00 for nfsv4@ietf.org; Fri, 27 Feb 2004 17:42:07 -0500 Received: from hawk.corp.netapp.com (hawk [10.57.156.122]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i1RMfXJC029587; Fri, 27 Feb 2004 14:41:37 -0800 (PST) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.10.22.171]) by hawk.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i1RMfUDe013654; Fri, 27 Feb 2004 14:41:33 -0800 (PST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FD82.CEE92D2E" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [nfsv4] (no subject) Message-ID: <482A3FA0050D21419C269D13989C611302D22720@lavender-fe.eng.netapp.com> Thread-Topic: [nfsv4] (no subject) Thread-Index: AcP9f3frZBgYLVbTTZWulppgH4Uc2wAAt2NA From: "Khan, Saadia" To: "Stevan Steve Allen" , Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Fri, 27 Feb 2004 14:41:15 -0800 Date: Fri, 27 Feb 2004 14:41:15 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=HTML_30_40,HTML_FONTCOLOR_BLUE, HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FD82.CEE92D2E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe you should return NFSERR_BADOWNER on the setattr and if this happens on a getattr/readdir because the mapping no longer exists then maybe the best way to handle this would be to return the internally stored id as a string. However that may not mean anything to the client and the client would then have to decide how to handle it. =20 Saadia -----Original Message----- From: Stevan Steve Allen [mailto:scallen@us.ibm.com]=20 Sent: Friday, February 27, 2004 2:14 PM To: nfsv4@ietf.org Subject: [nfsv4] (no subject) Question..=20 If Owner & Group name strings are not supported by the server for SETATTR. Can the server return it's internal string representation for owner and group without a domain name (which is unknown) in GETATTR/READDIR?=20 Thanks, Stevan C. Allen NFS Development ------_=_NextPart_001_01C3FD82.CEE92D2E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I=20 believe you should return NFSERR_BADOWNER on the setattr and if this = happens on=20 a getattr/readdir because the mapping no longer exists then maybe = the best=20 way to handle this would be to return the internally stored id as a = string.=20 However that may not mean anything to the client and the client would = then have=20 to decide how to handle it.
 
Saadia
-----Original Message-----
From: = Stevan Steve=20 Allen [mailto:scallen@us.ibm.com]
Sent: Friday, February = 27, 2004=20 2:14 PM
To: nfsv4@ietf.org
Subject: [nfsv4] (no=20 subject)


Question..

If = Owner &=20 Group name strings are not supported by the server for SETATTR. =  Can the=20 server return it's internal string representation for owner and group = without=20 a domain name (which is unknown) in GETATTR/READDIR? =

Thanks,
Stevan C. Allen
NFS=20 Development
 ------_=_NextPart_001_01C3FD82.CEE92D2E-- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Fri Feb 27 18:06:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01439 for ; Fri, 27 Feb 2004 18:06:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awr3P-0000kv-3p for nfsv4-archive@odin.ietf.org; Fri, 27 Feb 2004 18:05:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RN5xhH002899 for nfsv4-archive@odin.ietf.org; Fri, 27 Feb 2004 18:05:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awr3O-0000kg-WB for nfsv4-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 18:05:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01391 for ; Fri, 27 Feb 2004 18:05:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awr3M-00055I-00 for nfsv4-web-archive@ietf.org; Fri, 27 Feb 2004 18:05:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awr2N-0004vl-00 for nfsv4-web-archive@ietf.org; Fri, 27 Feb 2004 18:04:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Awr1U-0004mZ-00 for nfsv4-web-archive@ietf.org; Fri, 27 Feb 2004 18:04:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awr1V-0000DZ-H3; Fri, 27 Feb 2004 18:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awr1E-00008a-Jq for nfsv4@optimus.ietf.org; Fri, 27 Feb 2004 18:03:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01123 for ; Fri, 27 Feb 2004 18:03:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awr1B-0004kI-00 for nfsv4@ietf.org; Fri, 27 Feb 2004 18:03:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awr0F-0004dn-00 for nfsv4@ietf.org; Fri, 27 Feb 2004 18:02:44 -0500 Received: from mhoutside.hcl.com ([199.71.120.71] helo=MHOUTSIDE.HUMMINGBIRD.COM) by ietf-mx with esmtp (Exim 4.12) id 1AwqzW-0004RF-00 for nfsv4@ietf.org; Fri, 27 Feb 2004 18:01:58 -0500 Received: from sergeylt (sergeylt.hcl.com [10.1.38.148]) by MHOUTSIDE.HUMMINGBIRD.COM (8.12.10/8.12.10) with ESMTP id i1RN1USb025847 for ; Fri, 27 Feb 2004 18:01:30 -0500 From: "Sergey Klyushin" To: Subject: RE: [nfsv4] (no subject) Message-ID: <009701c3fd9e$bf5c8e80$9426010a@hcl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0098_01C3FD5B.B1394E80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Fri, 27 Feb 2004 18:01:14 -0800 Date: Fri, 27 Feb 2004 18:01:14 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=HTML_60_70, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0098_01C3FD5B.B1394E80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Do you mean "OWNER@" and "GROUP@" are not supported by server or = something else? Why would domain name be unknown? =20 Sergey =20 -----Original Message----- From: nfsv4-admin@ietf.org [mailto:nfsv4-admin@ietf.org] On Behalf Of = Stevan Steve Allen Sent: Friday, February 27, 2004 2:14 PM To: nfsv4@ietf.org Subject: [nfsv4] (no subject) =20 Question..=20 If Owner & Group name strings are not supported by the server for = SETATTR. Can the server return it's internal string representation for owner and group without a domain name (which is unknown) in GETATTR/READDIR?=20 Thanks, Stevan C. Allen NFS Development ------=_NextPart_000_0098_01C3FD5B.B1394E80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Do you mean “OWNER@” = and “GROUP@” are not supported by server or something else?

Why would domain name be = unknown?

 

Sergey

 

-----Original Message-----
From: = nfsv4-admin@ietf.org [mailto:nfsv4-admin@ietf.org] On = Behalf Of Stevan Steve Allen
Sent: Friday, February = 27, 2004 2:14 PM
To: nfsv4@ietf.org
Subject: [nfsv4] (no = subject)

 


Question..

If Owner & Group name strings are not supported by the server for = SETATTR.  Can the server return it's internal string representation for owner and = group without a domain name (which is unknown) in = GETATTR/READDIR?

Thanks,
Stevan C. Allen
NFS Development

------=_NextPart_000_0098_01C3FD5B.B1394E80-- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From exim@www1.ietf.org Fri Feb 27 19:16:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05692 for ; Fri, 27 Feb 2004 19:16:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aws93-0007sS-2j for nfsv4-archive@odin.ietf.org; Fri, 27 Feb 2004 19:15:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1S0FrHI030274 for nfsv4-archive@odin.ietf.org; Fri, 27 Feb 2004 19:15:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aws92-0007sD-TM for nfsv4-web-archive@optimus.ietf.org; Fri, 27 Feb 2004 19:15:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05688 for ; Fri, 27 Feb 2004 19:15:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aws91-0005Jt-00 for nfsv4-web-archive@ietf.org; Fri, 27 Feb 2004 19:15:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aws81-0005DH-00 for nfsv4-web-archive@ietf.org; Fri, 27 Feb 2004 19:14:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aws7F-000575-00 for nfsv4-web-archive@ietf.org; Fri, 27 Feb 2004 19:14:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aws7E-0007mn-Re; Fri, 27 Feb 2004 19:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aws6y-0007mI-VB for nfsv4@optimus.ietf.org; Fri, 27 Feb 2004 19:13:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05638 for ; Fri, 27 Feb 2004 19:13:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aws6x-00055o-00 for nfsv4@ietf.org; Fri, 27 Feb 2004 19:13:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aws61-00050w-00 for nfsv4@ietf.org; Fri, 27 Feb 2004 19:12:46 -0500 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1Aws5E-0004qf-00 for nfsv4@ietf.org; Fri, 27 Feb 2004 19:11:56 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i1S0BKF4504346 for ; Fri, 27 Feb 2004 19:11:20 -0500 Received: from d03nm113.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1S0BJHj200144 for ; Fri, 27 Feb 2004 17:11:20 -0700 To: nfsv4@ietf.org MIME-Version: 1.0 Subject: RE: [nfsv4] (no subject) - Owner Group attr strings. X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Stevan Steve Allen X-MIMETrack: Serialize by Router on D03NM113/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 02/27/2004 17:11:19, Serialize complete at 02/27/2004 17:11:19 Content-Type: multipart/alternative; boundary="=_alternative 000107D588256E48_=" Sender: nfsv4-admin@ietf.org Errors-To: nfsv4-admin@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NFSv4 Working Group List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Fri, 27 Feb 2004 16:11:17 -0800 Date: Fri, 27 Feb 2004 16:11:17 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 000107D588256E48_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Pj5EbyB5b3UgbWVhbiDigJxPV05FUkDigJ0gYW5kIOKAnEdST1VQQOKAnSBhcmUgbm90IHN1cHBv cnRlZCBieSBzZXJ2ZXIgb3IgDQpzb21ldGhpbmcgZWxzZT8NCj4+V2h5IHdvdWxkIGRvbWFpbiBu YW1lIGJlIHVua25vd24/DQo+Pi0gU2VyZ2V5DQoNCkkgYW0gc3BlYWtpbmcgb2Ygb3duZXIgYW5k IG93bmVyX2dyb3VwIGF0dHJpYnV0ZXMgMzYgJiAzNyBub3QgYmVpbmcgDQpzdXBwb3J0ZWQgYnkg dGhlIHNlcnZlciBmb3IgU0VUQVRUUi4gIFRoZSBwcm90b2NvbCBzdGF0ZXMgaWYgdGhlIHNlcnZl ciANCnN1cHBvcnRzIG93bmVyICYgb3duZXJfZ3JvdXAgb24gU0VUQVRUUiwgdGhlIHNlcnZlciBw cm9taXNlcyB0byByZXR1cm4gdGhlIA0KZXhhY3Qgc2FtZSBzdHJpbmcgb24gYSBzdWJzZXF1ZW50 IEdFVEFUVFIuDQoNCklmIGEgc2VydmVyIGNhbiBub3Qgc3VwcG9ydCB0aGUgcmVxdWlyZW1lbnQg Zm9yIHNldHRpbmcgYW5kIHJldHVybmluZyB0aGUgDQpzYW1lIG93bmVyICYgb3duZXJfZ3JvdXAg YXR0cmlidXRlcywgIGl0IHNlZW1zIGl0IG11c3QgdHVybiBvZmYgc3VwcG9ydCBpbiANCnRoZSBz ZXJ2ZXIgc3VwcF9hdHRyIG1hc2ssIHdoaWNoIHdvdWxkIGFsc28gYWZmZWN0IGdldGF0dHIgYW5k IHJlYWRkaXIgbm90IA0KcmV0dXJuaW5nIHRoZSBzdHJpbmdzLiAgVGhlIHNlcnZlciB0dXJuaW5n IG93bmVyICYgb3duZXJfZ3JvdXAgIm9uIiB3b3VsZCANCnN1Z2dlc3QgdGhlIHNlcnZlciBzdXBw b3J0cyBhIFNFVEFUVFIgb2Ygb3duZXIgYW5kIG93bmVyX2dyb3VwLg0KDQpEb2VzIGFueW9uZSBl eHBlY3Qgb3RoZXJ3aXNlPyAgLi4uc3VjaCBhcy4uLiBhIHNlcnZlciB3aGljaCBzYXlzIGl0IA0K c3VwcG9ydHMgb3duZXIvZ3JvdXAgKGF0dHIgbWFzaykgYW5kIHJldHVybnMgaW50ZXJuYWwgc3Ry aW5ncyBhcyANCm93bmVyL2dyb3VwIGFuZCBkb2VzIG5vdCBhbGxvdyBzZXR0aW5nIHRoZXNlIHZh bHVlcyAodXNpbmcgYW4gZXJyb3IgY29kZSANCmZvciBzZXRhdHRyKS4gPyAgIGUuZy4gSXMgdGhl cmUgYSBiZW5lZml0IG9yIG5lZWQgdG8gb2J0YWluIHRoZSBzZXJ2ZXJzIA0KaW50ZXJuYWwgc3Ry aW5ncyB2cy4gbm90aGluZz8gDQoNCm5vdGU6ICBvdGhlciBSL1cgYXR0cmlidXRlcyBoYXZlIHNl cGFyYXRlZCB0aGUgcmVhZCBhbmQgd3JpdGUgc3VwcG9ydCBieSANCmFkZGluZyBhIHNlY29uZCBh dHRyLCBzdWNoIGFzIGNhbnNldHRpbWUuDQo= --=_alternative 000107D588256E48_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPiZndDsmZ3Q7RG8g eW91IG1lYW4g4oCcT1dORVJA4oCdDQphbmQg4oCcR1JPVVBA4oCdIGFyZSBub3Qgc3VwcG9ydGVk IGJ5IHNlcnZlciBvciBzb21ldGhpbmcgZWxzZT88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNv bG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPiZndDsmZ3Q7V2h5IHdvdWxkIGRvbWFpbiBuYW1lDQpi ZSB1bmtub3duPzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJB cmlhbCI+Jmd0OyZndDstIFNlcmdleTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+SSBhbSBzcGVha2luZyBvZiBvd25lciBhbmQgb3duZXJfZ3JvdXANCmF0 dHJpYnV0ZXMgMzYgJmFtcDsgMzcgbm90IGJlaW5nIHN1cHBvcnRlZCBieSB0aGUgc2VydmVyIGZv ciBTRVRBVFRSLiAmbmJzcDtUaGUNCnByb3RvY29sIHN0YXRlcyBpZiB0aGUgc2VydmVyIHN1cHBv cnRzIG93bmVyICZhbXA7IG93bmVyX2dyb3VwIG9uIFNFVEFUVFIsDQp0aGUgc2VydmVyIHByb21p c2VzIHRvIHJldHVybiB0aGUgZXhhY3Qgc2FtZSBzdHJpbmcgb24gYSBzdWJzZXF1ZW50IEdFVEFU VFIuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JZiBh IHNlcnZlciBjYW4gbm90IHN1cHBvcnQgdGhlIHJlcXVpcmVtZW50DQpmb3Igc2V0dGluZyBhbmQg cmV0dXJuaW5nIHRoZSBzYW1lIG93bmVyICZhbXA7IG93bmVyX2dyb3VwIGF0dHJpYnV0ZXMsDQom bmJzcDtpdCBzZWVtcyBpdCBtdXN0IHR1cm4gb2ZmIHN1cHBvcnQgaW4gdGhlIHNlcnZlciBzdXBw X2F0dHIgbWFzaywgd2hpY2gNCndvdWxkIGFsc28gYWZmZWN0IGdldGF0dHIgYW5kIHJlYWRkaXIg bm90IHJldHVybmluZyB0aGUgc3RyaW5ncy4gJm5ic3A7VGhlDQpzZXJ2ZXIgdHVybmluZyBvd25l ciAmYW1wOyBvd25lcl9ncm91cCAmcXVvdDtvbiZxdW90OyB3b3VsZCBzdWdnZXN0IHRoZQ0Kc2Vy dmVyIHN1cHBvcnRzIGEgU0VUQVRUUiBvZiBvd25lciBhbmQgb3duZXJfZ3JvdXAuPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Eb2VzIGFueW9uZSBleHBl Y3Qgb3RoZXJ3aXNlPyAmbmJzcDsuLi5zdWNoDQphcy4uLiBhIHNlcnZlciB3aGljaCBzYXlzIGl0 IHN1cHBvcnRzIG93bmVyL2dyb3VwIChhdHRyIG1hc2spIGFuZCByZXR1cm5zDQppbnRlcm5hbCBz dHJpbmdzIGFzIG93bmVyL2dyb3VwIGFuZCBkb2VzIG5vdCBhbGxvdyBzZXR0aW5nIHRoZXNlIHZh bHVlcw0KKHVzaW5nIGFuIGVycm9yIGNvZGUgZm9yIHNldGF0dHIpLiA/ICZuYnNwOyBlLmcuIElz IHRoZXJlIGEgYmVuZWZpdCBvcg0KbmVlZCB0byBvYnRhaW4gdGhlIHNlcnZlcnMgaW50ZXJuYWwg c3RyaW5ncyB2cy4gbm90aGluZz8gJm5ic3A7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5ub3RlOiAmbmJzcDtvdGhlciBSL1cgYXR0cmlidXRlcyBoYXZl DQpzZXBhcmF0ZWQgdGhlIHJlYWQgYW5kIHdyaXRlIHN1cHBvcnQgYnkgYWRkaW5nIGEgc2Vjb25k IGF0dHIsIHN1Y2ggYXMgY2Fuc2V0dGltZS48L2ZvbnQ+DQo= --=_alternative 000107D588256E48_=-- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4