[nfsv4] Re: New Version Notification for draft-rmacklem-nfsv4-posix-acls-00.txt

Rick Macklem <rick.macklem@gmail.com> Sat, 03 August 2024 01:42 UTC

Return-Path: <rick.macklem@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14678C169414 for <nfsv4@ietfa.amsl.com>; Fri, 2 Aug 2024 18:42:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBPfO_SRQBVN for <nfsv4@ietfa.amsl.com>; Fri, 2 Aug 2024 18:42:48 -0700 (PDT)
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16480C15199B for <nfsv4@ietf.org>; Fri, 2 Aug 2024 18:42:48 -0700 (PDT)
Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-1fc65329979so76513385ad.0 for <nfsv4@ietf.org>; Fri, 02 Aug 2024 18:42:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722649367; x=1723254167; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IbxyP+W+CkGiEnaJI3XQ7YBrj1rOk2Cwk0o3SlEgZmo=; b=aRo9B9DUZA9UjhhPWir98I0bLJMeuflFQy0gCsIhf5ixvrf4jMkkObljetgFk9EME7 M3okOeaO8QW2h3dn1RRH+rkLHZWeLRZINh4xZaFtO4STumaBF/Z3H2ihI8hPaVd4zknI 72BJfijTTlG8Sje7SJo+trjuuRKoCqIzcNLhumBy7b3gO9o00ChTbtUHVvNAjq2zUVQN Sn7TDOoSZKVKwp54zZxUVrQ4tSUaWTRegh/lNR1n1xhj1doc+2eaaIjKpdFYT0v5AYE9 /qwS0bLAfmM330recUSFEk1Y02kBz0DDxUh6JAYbFhEv+KmFsZv+rbgNqsnLZklHpBhX Qetw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722649367; x=1723254167; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IbxyP+W+CkGiEnaJI3XQ7YBrj1rOk2Cwk0o3SlEgZmo=; b=StVOf9vXMwQR69bBPXrf4EYxAt0FAaUwSDl2X+07qxaPNWRPpwfxO2v4+OSthjb+1Q BZ5uwp56V/Wq+WFJC+0sRjPqBEpA7ILxODtNRl+6ciQIHuQw5e5VG7MkZIcn7Sbbco29 QaPQayJKw4bmTOBVd4EI//5aw/DC2XxHJUHcfu0e+hbSs/dKwR4KEE3WJojyUUTlqvy8 +UOYKLndw5pDwh5GsHVdYJBTRklEei8DLItF+FMLztEkPE3bkJyvdkS6tLMTpqvk8pLq CmgYuEf/sWGLXSEKcrrj3zj2q3/3mxgTWzC6Aw7Oi/0X2DJ0/geI9rNHu5Dqa99GMi3B mYbQ==
X-Gm-Message-State: AOJu0Yzr/wFj9I8cKDBbPb046LWBOlTVPrLM0N8itEqgaN9E/CweHkkY /++fEzj3hNBEzszrJZPgpeamH4LKD9tMU1Hcoq2a0p6oxnnC5fkTM5veSCQaE0ad4jUj1HXhm8n ERwj4dH+E/wz+muYBY85GoYVNgA==
X-Google-Smtp-Source: AGHT+IFhKsS6dFucM9jJpYBJDj9TeHkWd8Qx7HytaF7IJOEBLmtMyEnd1TKKsiQvkl40Xh1lkunhQiiQ8bE1AIQTnCE=
X-Received: by 2002:a17:902:d48a:b0:1fb:b6ed:4979 with SMTP id d9443c01a7336-1ff57297051mr66468475ad.27.1722649367081; Fri, 02 Aug 2024 18:42:47 -0700 (PDT)
MIME-Version: 1.0
References: <172247136172.2230520.10372959849936316507@dt-datatracker-659f84ff76-9wqgv> <CAM5tNy7-1m2Xsz3hAAWwbehzqEWw_kzKZe_vc4YXcZrTsAx6ww@mail.gmail.com> <CADaq8jd=XXKWLZJHt_V75WQFSUvxE9xtG61GTJo_WVCafuDHrQ@mail.gmail.com> <CAM5tNy4BOLAkSg9neUes4oC5UYBnVeHf_ZQpsAgThWNnPs6YRg@mail.gmail.com> <CADaq8jfG=VmeYMrUVFr23BRdEnNr=nVP6FNEz-p606cXJ4Cdxg@mail.gmail.com>
In-Reply-To: <CADaq8jfG=VmeYMrUVFr23BRdEnNr=nVP6FNEz-p606cXJ4Cdxg@mail.gmail.com>
From: Rick Macklem <rick.macklem@gmail.com>
Date: Fri, 02 Aug 2024 18:42:36 -0700
Message-ID: <CAM5tNy7EMdw5psJDypw64DWnFJrb4WhY3rYb1g4=SvBp9EWhMg@mail.gmail.com>
To: David Noveck <davenoveck@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000098fb43061ebd8f6b"
Message-ID-Hash: 4EQJGXOW4Q3JJWZ3FFMUOZGWNC3AZUZM
X-Message-ID-Hash: 4EQJGXOW4Q3JJWZ3FFMUOZGWNC3AZUZM
X-MailFrom: rick.macklem@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-nfsv4.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: NFSv4 <nfsv4@ietf.org>, Rick Macklem <rmacklem@uoguelph.ca>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [nfsv4] Re: New Version Notification for draft-rmacklem-nfsv4-posix-acls-00.txt
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/J-MwBZV4_u0aqLWFMucpkAQdPyQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Owner: <mailto:nfsv4-owner@ietf.org>
List-Post: <mailto:nfsv4@ietf.org>
List-Subscribe: <mailto:nfsv4-join@ietf.org>
List-Unsubscribe: <mailto:nfsv4-leave@ietf.org>

On Fri, Aug 2, 2024 at 4:46 PM David Noveck <davenoveck@gmail.com> wrote:

>
>
> On Fri, Aug 2, 2024, 5:01 PM Rick Macklem <rick.macklem@gmail.com> wrote:
>
>>
>>
>> On Fri, Aug 2, 2024 at 9:07 AM David Noveck <davenoveck@gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, Jul 31, 2024 at 8:22 PM Rick Macklem <rick.macklem@gmail.com>
>>> wrote:
>>>
>>>> I've put a first draft of a POSIX ACLs document in the datatracker.
>>>> Please take a look when you have time.
>>>>
>>>> It currently specifies "per-file system" for the attribute that
>>>> reports what ACL model is being stored in the server.
>>>>
>>>
>>> That scope does not address cases that are important to me.
>>>
>>>
>>>> --> This could be changed to "per file".
>>>>
>>>
>>> Works for me,
>>>
>>>
>>>> or "per server".
>>>>
>>>
>>> That would make things much worse.
>>>
>>>
>>>>     Opinions?
>>>>
>>> I knew the scope of which ACL model is being used natively
>> by the server might be contentious.
>>
>
> I'm not sure how to define "is being used natively by the server" or if
> there is any point in defining it.  Your draft doesn't do so.
>
By "natively" I was just referring to the ACL stored for the file object
and used to determine access
to the object. (ie. What server_acl_model would return.)


> First, I will assume that only one model of ACL will be applied
>> to the file object for any given file object on the server.
>> (I think we agreed that to do otherwise would make permission
>> checking too confusing, even if we defined a way to do so.)
>>
>
> I haven't heard anyone disagree with that.
>
>
>> I'll admit my personal preference would have been "per server".
>> Why?
>> Because then a client could configure the mount point to handle
>> that model and that model only.
>>
>
> You can still do that by only configuring one of the two optional sets of
> attributes.
>
Yes, but it would be nice to do what the server supports and not bother
with a mount option many users will ignore.
--> For example, for the Linux knfsd, it sounds like the answer will be
    "the server always stores POSIX ACLs and uses them to determine access".
    I think it would be nice for the client to know that and configure the
    mount point appropriately.

Btw, when I first wrote this up, the server_acl_model attribute had a
second enum that looked like:
  enum aclscope4 {
      ACL_MODEL_FILE_OBJECT = 1,
      ACL_MODEL_ALL_THIS_FSID = 2,
      ACL_MODEL_ALL_SERVER = 3
  };
to define the actual scope of the answer, even though the attribute would
be defined as "per file".
I took that out, because it felt I was "cheating" w.r.t. scope, but I
could easily add it back in, if others think it is appropriate?


>
>> However, I can see why others would prefer a "per file" scope.
>> My first concern w.r.t. "per file" scope is inheritance.
>> - I suppose inheritance would be defined by which model is
>>   being used by the directory the new file object is being
>>   created in and any inheritance would be controlled by that.
>>
>
> I agree.
>
> - I do not know how automatic inheritance can happen in anything
>>   other than a pure NFSv4 ACL server/file system
>>
>
> As far as I know there is no automatic inheritance for POSIX ACLs so this
> seems to be a non-problem
>
>
> (I am not sure if
>>   automatic inheritance is expected to cross server file system
>>   boundaries?).
>>
>
> I don't see how it could.  Inheritance happens when creating a new object
> and there is  no way to create a new object within a directory that is also
> in another file system.
>
>   - Automatic inheritance is something that is not, as yet,
>>     discussed in the draft. It should be.
>>
>
> Only if it is required by POSIX ACL semantics.
>
It is not, as far I I know.


>
>
>
> I'm not sure I am
>>     knowledgible enough to say more that "sacl and dacl cannot
>>     be supported if the file server uses POSIX ACLs natively
>>     at all", or something like that.
>>
>
>  I expect that ontap will want to support sacl, dacl, and your POSIX
> attribute.  As fast as "natively"  I'm not sure what you mean
>
>
>> Then there is the fact that support for an attribute is "per file system"
>> and GETATTR is supposed to return supported attributes for all file
>> objects in the file system.
>> I see two approaches, if POSIX ACLs and NFSv4 ACLs are mixed within
>> the same server file system:
>> 1 - Require the server to do its "best effort" at mapping between the
>>     ACL models when the attribute(s) for the non-native ACL is done.
>>     (This leads to documenting the mapping, which I'll admit I was hoping
>>      to avoid. Bruce Fields has no problem with text being cribbed from
>>      the expired draft, but didn't bubble with enthusiasm when I asked
>>      about turning the expired draft into an RFC.)
>> or
>> 2 - Require the server to return a 0 length ACL for the attribute(s)
>>     for the non-native ACL.
>>
>
> I agree that returning a zero-length ACL is right. I don't see how
> nativity, citizenship or legal residence affects that  :-).
>
> Whether a server does #1 or #2 could be another new attribute and this
>> one would have to be "per server" or "per file system".
>>
>
> I prefer #2 being the only option.
>
I wonder if Chuck would like to comment on this?
I thought he was thinking of doing #1, but it would
be for a Linux file systems that does not normally mix them.
(This IBM GPFS is an interesting case. I wonder what the Linux
knfsd does with it?)


>
>
>
>
>> So, what's out there now?
>> - Linux always uses POSIX ACLs natively. Chuck seemed to indicate that
>>   supporting the acl attribute via mapping (#1 above) might be
>> appropriate.
>>   (That would be one style of "mixing the two ACL models".)
>> - FreeBSD sets one ACL model per server file system and does not do
>> mapping.
>>   (I do not envision any "mixing". A server file system would support the
>>    acl attribute or it would support the posix_default_acl and
>> posix_access_acl,
>>    but never all three for a given file system.)
>>   Yes, the server could be configured "per file system".
>> - Solaris (from a quick look at documentation only) seems similar to
>> FreeBSD,
>>   in that UFS file systems use POSIX ACLs natively and ZFS file systems
>> use
>>   NFSv4 ACLs natively. (It does not appear that there are "switches" to
>> change
>>   either file system type to a different ACL model.)
>>
>> What does Netapp Filers and other servers do?
>> - Do Netapp Filers support the NFSACL protocol for POSIX ACLs?
>>
>
> No.
>
>   - It does appear that Netapp Filers support native NFSv4 ACLs,
>>
>
> They do support them
>
>   I am not sure whether this is truly "natively" since we borrow/steal a
> lot of the cifs acl code.
>
> We would like to add support for you new acls attributes when the spec is
> farther along
>
> although
>>     it is just vague recollection from testing long ago.
>>
>> This exercise of mixing the two models, especially within one file system,
>> requires input from others.
>>
>>
>>> Lots of them.  See *Document Review *below.
>>>
>> Yes. Thanks for the comments. I will work on the typo ones.
>> I will hold off w.r.t. the interaction between ACLs of the two
>> models to give others a chance to comment on the above.
>>
>
> Interested in knowing what you decide.
>
Well, with this IBM GPFS case, it does sound like "per file" is what
the spec will need to support. (I do like the idea of "cheating" and
putting the scope in server_acl_model, since I think clients might
find it useful and server implementors should know the answer.)

We'll see what others say, while I plug away at it. (Unlike coding,
writing this junk goes slowly for me;-)

And, thanks David, for the grammatical comments. I need them;-)

rick


>
>> rick
>>
>>
>>>
>>>>
>>>> Thanks, rick
>>>>
>>>>
>>>> On Wed, Jul 31, 2024 at 5:16 PM <internet-drafts@ietf.org> wrote:
>>>>
>>>>> CAUTION: This email originated from outside of the University of
>>>>> Guelph. Do not click links or open attachments unless you recognize the
>>>>> sender and know the content is safe. If in doubt, forward suspicious emails
>>>>> to IThelp@uoguelph.ca.
>>>>>
>>>>>
>>>>> A new version of Internet-Draft draft-rmacklem-nfsv4-posix-acls-00.txt
>>>>> has
>>>>> been successfully submitted by Rick Macklem and posted to the
>>>>> IETF repository.
>>>>>
>>>>> Name:     draft-rmacklem-nfsv4-posix-acls
>>>>> Revision: 00
>>>>> Title:    POSIX Draft ACL support for Network File System Version 4,
>>>>> Minor Version 2 (NFSv4.2)
>>>>> Date:     2024-07-31
>>>>> Group:    Individual Submission
>>>>> Pages:    9
>>>>> URL:
>>>>> https://www.ietf.org/archive/id/draft-rmacklem-nfsv4-posix-acls-00.txt
>>>>> Status:
>>>>> https://datatracker.ietf.org/doc/draft-rmacklem-nfsv4-posix-acls/
>>>>> HTML:
>>>>> https://www.ietf.org/archive/id/draft-rmacklem-nfsv4-posix-acls-00.html
>>>>> HTMLized:
>>>>> https://datatracker.ietf.org/doc/html/draft-rmacklem-nfsv4-posix-acls
>>>>>
>>>>>
>>>>> Abstract:
>>>>>
>>>>>    This document describes the addition of three new attributes that
>>>>> are
>>>>>    used by servers to support POSIX ACLs.  The term POSIX ACLs refers
>>>>> to
>>>>>    the ACL component of the Portable Operating System Interface (POSIX)
>>>>>    1003.1e draft 17 [IEEE] document for which sponsorship was withdrawn
>>>>>    in January 1998.  Although the draft POSIX standard that describes
>>>>>    these ACLs was never ratified, several POSIX based operating
>>>>> systems,
>>>>>    such as Linux, Solaris and FreeBSD include support for them.  The
>>>>> NFS
>>>>>    Version 4 ACLs described in [RFC8881] henseforth referred to as
>>>>> NFSv4
>>>>>    ACLs, use a different model and attempts to map between the ACLs of
>>>>>    these two models has not been completely successful.  As such, this
>>>>>    document proposes three new attributes that may optionally be used
>>>>> by
>>>>>    an NFSv4.2 server to support ACLs that conform the afor mentioned
>>>>>    POSIX 1003.1e draft 17.
>>>>>
>>>>>
>>>>>
>>>>> The IETF Secretariat
>>>>>
>>>>>
>>>>> _______________________________________________
>>>> nfsv4 mailing list -- nfsv4@ietf.org
>>>> To unsubscribe send an email to nfsv4-leave@ietf.org
>>>
>>>
>>> *Document Review *
>>>
>>> *Overall Evaluation*
>>> This is a good start on addressing an important security issue.  I feel
>>> the use of the new attribute currently called "server_acl_model" is an
>>> excellent choice.
>>>
>>> There are a number of major issues that need to be addressed before
>>> document adoption.  Most of these are discussed in *General Comments*.
>>>  For the few within *Per-section Comments*, that status is specially
>>> noted below if necessary.
>>>
>>> *General Comments *
>>>
>>> *Needed Changes in Direction*
>>>
>>> The changes I am referring to all derive, in some  way, from the need to
>>> provide better support for the case in which support for both NFSv4 ACLs
>>> and POSIX ACLs are available.
>>>
>>> While this is partially addressed by shifting server_acl_model to be a
>>> per-fs-object attribute as discussed in *7.1 Attribute NN:
>>> server_acl_model*,  this makes necessary other  changes specifying how
>>> other actions affect the value of this attribute.  Some of those are
>>> discussed in *Per-section Comments* while others are mentioned in *Things
>>> That are Missing.*
>>>
>>> I'd appreciate your response to comments in this section as soon as
>>> possible and in advance of a next draft.   Right now, I am fairly far along
>>> in draftng acl-05 and beliee that if we can come to agreement on these
>>> matters, I can shift and produce a different acl-05 that fits together with
>>> your v4.2 extensons.
>>>
>>> *Things That are Missing.*
>>>
>>> I think the following thing needs to be done:
>>>
>>>    - I think you have to look at the issues related to XDR extraction
>>>    and how the updated v4.2 XDR is to be arrived a .  I think you should look
>>>    at how this is addressed in other v4.2 extensions.
>>>    - I think you need a section describing the differences between the
>>>    two ACL models.   This is to address the part of the audience who will be
>>>    adding your extensions to an implementation supporting the NFSv4 ACL
>>>    model.  The current document is oriented to those that do not have an such
>>>    an existing.   While this is a large part of the audience, it is not all of
>>>    it.
>>>
>>>
>>> *Per-section Comments*
>>> *Abstract*
>>> Suggest replacing "POSIX based" by "POSIX-based".
>>>
>>> Suggest replacing "henseforth" by "henceforth".
>>>
>>> Suggest replacing "has not been completely successful" by "have not
>>> been completely successful"
>>>
>>> Suggest replacing "as such" by "In order to adequately  support these
>>> ACLs,"
>>>
>>> Suggest replacing "the afor mentioned" by "to the aforementioned".
>>>
>>> *1, Introduction*
>>>
>>> The current first sentence assumes that there needs to be mapping
>>> without giving the reader any basis for that feeling, which seems to come
>>> from out of nowhere.  Suggest the following replacement for the
>>> existing first sentence:
>>>
>>> Because of the semantic differences between the two ACL models involved,
>>> attempts have been made to map between these two sorts of ACLs.  However, implementation
>>> experience with mapping between NFSv4 and POSIX ACLs has not been
>>> completely successful.
>>>
>>> The last sentence of the paragraph, as currently written may provoke
>>> unhelpful may-vs-MAY discusssion.  Suggest starting "A server has the
>>> option of choosing".
>>>
>>> In the second paragraph suggest replacing "as such" by "In order to
>>> provide better support for POSIX ACLs.".  In the second sentence of the
>>> paragraph, suggest replacing "these attributes" by "any of
>>> these attributes".
>>>
>>> The current third paragraph leaves me mystified.   Is the following more
>>> like what you want?
>>>
>>> The semantics relevant  to the implementation of  POSIX ACLs by the server, are  described in [Grünbacher].  In addition, issues related to the over-the-wire format of POSIX ACLs and the interactions among the various new attributes are dealt with in this document.
>>>
>>>  *  4.  XDR definitions for new attributes*
>>>
>>> If the attribute returning aclmodel4 is, as I believe it should be, of
>>> per-fIle scope, you are missing an enum value to cover the case in which a
>>> file has a neither an NFSv4 ACL nor a POSIX ACL.   ACL_MODEL_NEITHER?
>>>
>>> *5.  POSIX ACL Considerations*
>>>
>>> As far as I can see from Andreas' paper, the first clause of the first
>>> sentence of the third paragraph is not true.
>>>
>>> Regarding the second sentence of that paragraph:
>>>
>>>    - I can't see how "Therefore" is justfied.
>>>    - I don't think it is possible to use set_mode_masked in this case.
>>>
>>> Regarding the third sentence of that paragraph, I think it is relevant
>>> that RFC8811 does address both these being set for the NFSv4 ACL model,
>>> casting doubt on the implication that the choices you made were somehow
>>> forced on you.  I don't think your choices are bad ones,  but you cannot
>>> claim here that you had no other choice.
>>>
>>> In the fourth paragraph, the reference to "POSIX system call" is
>>> inapproprIate.  I think you need to refer to the NFSv4 operation.
>>>
>>> *7.1.  Attribute NN: server_acl_model*
>>>
>>> I'd like to suggest a change in this name to something like "acl_model".
>>>
>>> In my view, this is not particularly server-specific although it is determined on the server based on server attributes supported and client action.
>>>
>>> In any case, we don't do this for other attributes.  For example, fh is chosen by the server but is not called "server_fh.
>>>
>>> While I have previous said that this should be per-object, you need to make additional changes with that for the whole thing to make sense,  Suggest the following:
>>>
>>> This attribute is a read-only attribute that indicates the ACL model of the ACL used to regulate access authorization for the current file object .  Distinct values indicate whether:
>>>
>>>
>>>    - This is controlled by a draft POSIX ACL.
>>>    - This is controlled by ALLOW and DENY ACEs as part of an ACL set by the acl or dacl attributes or by ACL inheritance within NFSv4 ACLs.  Note that this is not affected by the presence of a sacl attribute value or of AUDIT and ALARM ACEs within an acl atribute value.
>>>    - This is not controlled by an acl but only by the mode attribute.
>>>
>>> It is a per-file system object attribute.
>>>
>>> *7.1.1 Rationale*
>>>
>>> The current first sentence ignores the problem that doing this as
>>> suggested cost one extra client-sever round ttrip.
>>>
>>> The current second sentence is kind of misleading in that the real reason your proposal does no mapping is that it specifes you do no mapping
>>>
>>> It appears that you have decided that mapping is  impossible to do correctly.
>>>
>>> In any case, I would suggest deleting this section and adding the following to 7.1:
>>>
>>> This attribute provides a convenient low-overhead means of determining the acl model in use without the effort of obtaining the acl itself.
>>>
>>> Often, clients are not prepared to interpret acls (of eiter model) that are fetched and rely on ACCESS to determine authorization decisions.
>>>
>>> *7.2.1.  Rationale*
>>>
>>> I suggest replacing this by something like the following either in this section or the preceding section:
>>>
>>> Without this attribute the client would have  no way to set or interrogate the default acl, as provided for by the structure of the POSIX ACL model.  While it is theoretically possible to somehow map NFSv4 ACLs to POSIX ACLs, important semantic differences make this a poor choice,  In addition, the fundamentally different approaches taken to ACL inheritance compounds the associated difficulties, and no provision to do such mapping has been provided in this specification.
>>>
>>> *7.3.  Attribute NN: posix_access_acl*
>>>
>>> I suggest adding a paragraph like the following:
>>>
>>> When this attribute is set to to a contain an ACL of length greater than zero, it has the effect of changing the value of server_acl_model to ACL_MODEL_POSIX.
>>>
>>> *7.3.1.  Rationale*
>>>
>>> I suggest replacing this by something like the following either in this section or the preceding section:
>>>
>>> Without this attribute the client would have  no way to set or interrogate the access ACL, as provided for by the structure of the POSIX ACL model.  While it is theoretically possible to somehow map NFSv4 ACLs to POSIX ACLs, important semantic differences make this a poor choice,
>>>
>>> *9.  References*
>>>
>>> We have an unfortunate difference of opinion between David B. and Chris.  So far, the only conclusion I can draw is that at least one of them is wrong.
>>>
>>> It is true that there is a lot of material that characterizes the distinction between normative and informative references between as David says they are to be distinguished.
>>>
>>> Nevertheless the terms "Normative" and "Informative" are used and it is hard to ignore  Chris's point that these also should have the role.
>>>
>>> I have considered the possibility of three reference subdivisions for
>>>
>>>
>>>    - "normative references"
>>>    - "essential non-prescriptive references"
>>>    - "other informative references"
>>>
>>> but  could see how you might not want to do that.
>>>
>>> Nevertheless, regardless of the IETF's possible attachment to this Procrustean bucket, it needs to be made clear that the knowledge in thisdocument
>>>
>>> cannot be dispensed with.  While you can kinda sorta understand this document without it, if an implementer did not get this knowledge somehow, the
>>>
>>> resulting implementation is not of any value.
>>>
>>> In any case, although you might not want to say this explcitly, reading this document is more important than reading most of the current normative references.
>>>
>>> I know this is heretical, but, so far I know, the IETF has never burned anyone at the stake.
>>>
>>>
>>>
>>>
>>>