Subject: Re: [nfsv4] WG Last Call for Extension and Minor Versions, Extended Attributes, and ACLs / Umask - Ends Dec 2nd 2016

From: Spencer Shepler <[email-masked]>
Date: Mon, 5 Dec 2016 17:30:41 +0000

Bruce,

For the umask I-D, there is a normative reference for "POSIX 1003.1e Withdrawn Draft 17".

Unfortunately, without a stable reference, we will need to remove that from the document.  Do you have an alternative document that provides the needed background or is this needed in the I-D?

Spencer

From: nfsv4 [mailto:[email-masked]] On Behalf Of Spencer Shepler
Sent: Thursday, November 10, 2016 2:00 PM
To: NFSv4 <[email-masked]>
Subject: [nfsv4] WG Last Call for Extension and Minor Versions, Extended Attributes, and ACLs / Umask - Ends Dec 2nd 2016

This is the announcement of the working group last call for the 3 working group drafts listed below.

Accounting for the review of 3 documents and the upcoming US holiday, the last call will end on Dec 2nd 2016.

If more time is needed for review, let me know.

Please provide comments and review feedback to the authors of these documents.  Substantive comments or feedback should include the working group alias.

Thanks,
Spencer

Rules for NFSv4 Extensions and Minor Versions (https://www.ietf.org/id/draft-ietf-nfsv4-versioning-07.txt<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-ietf-nfsv4-versioning-07.txt&data=01%7C01%7Csshepler%40microsoft.com%7Cc1092553ded943ce3bd708d409b4e049%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=n6i4%2BiJnf8qUycmjSRQQkrR3zd0%2BCNb2XK292W6dMok%3D&reserved=0>)
File System Extended Attributes in NFSv4 (https://www.ietf.org/id/draft-ietf-nfsv4-xattrs-03.txt<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-ietf-nfsv4-xattrs-03.txt&data=01%7C01%7Csshepler%40microsoft.com%7Cc1092553ded943ce3bd708d409b4e049%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=sRUZotSPwf89NbIaX72aS4e9wCJT%2B2CcBse9GT0iNBE%3D&reserved=0>)
Allowing inheritable NFSv4 ACLs to override the umask (https://www.ietf.org/id/draft-ietf-nfsv4-umask-02.txt)

---

From: David Noveck <[email-masked]>
Date: Wed, 7 Dec 2016 08:43:45 -0500

I'm not sure about the mechanics of providing a "stable" reference.
Certainly that specific draft is not subject to change.

An interesting alternative would be a reference based on
https://linux.die.net/man/5/acl.   I'm not sure about copyright issues
that might arise in creating a stable reference based on this material, but
note that Andreas is listed as the author of that man
page :-)

There's a lot of work for lawyers involved in issues like this.  That
doesn't bother me as much as it used to now that my
daughter is in law school.

On Mon, Dec 5, 2016 at 12:30 PM, Spencer Shepler <[email-masked]>
wrote:

> Unfortunately, without a stable reference, we will need to remove that
> from the document.  Do you have an alternative document that provides the
> needed background or is this needed in the I-D?
>
>
>
> Spencer
>
>
>
>
>
> *From:* nfsv4 [mailto:[email-masked]] *On Behalf Of *Spencer
> Shepler
> *Sent:* Thursday, November 10, 2016 2:00 PM
> *To:* NFSv4 <[email-masked]>
> *Subject:* [nfsv4] WG Last Call for Extension and Minor Versions,
> Extended Attributes, and ACLs / Umask - Ends Dec 2nd 2016
>
>
>
>
>
> Please provide comments and review feedback to the authors of these
> documents.  Substantive comments or feedback should include the working
> group alias.
>
>
>
> Thanks,
>
> Spencer
>
>
>
> Rules for NFSv4 Extensions and Minor Versions (https://www.ietf.org/id/
> draft-ietf-nfsv4-versioning-07.txt
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-ietf-nfsv4-versioning-07.txt&data=01%7C01%7Csshepler%40microsoft.com%7Cc1092553ded943ce3bd708d409b4e049%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=n6i4%2BiJnf8qUycmjSRQQkrR3zd0%2BCNb2XK292W6dMok%3D&reserved=0>
> )
>
> File System Extended Attributes in NFSv4 (https://www.ietf.org/id/
> draft-ietf-nfsv4-xattrs-03.txt
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-ietf-nfsv4-xattrs-03.txt&data=01%7C01%7Csshepler%40microsoft.com%7Cc1092553ded943ce3bd708d409b4e049%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=sRUZotSPwf89NbIaX72aS4e9wCJT%2B2CcBse9GT0iNBE%3D&reserved=0>
> )
>
> Allowing inheritable NFSv4 ACLs to override the umask (
> https://www.ietf.org/id/draft-ietf-nfsv4-umask-02.txt)
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>
>

---

From: spencer shepler <[email-masked]>
Date: Wed, 7 Dec 2016 10:58:36 -0800

Even though David responded, the question is for the document authors.

My apologies for being opaque about "stable reference".

The  POSIX-1003.1e normative reference makes it appear that it is a Posix
standards document while in the content of the reference it does state
"withdrawn" - confusing.

The other problem is that I cannot quickly locate a copy of that document
and if it is going to be a normative reference then it needs to
be reasonably available.

I understand that it is a defacto standard at this point given the
implementation.

My main point is that if it is going to be a reference a target needs to
exist and the naming should likely be changed to remove the implication
that it is a Posix standard.

As mentioned, if the reference is not needed based on the contents of the
I-D, then the I-D can be reworded and references removed or changed.

Spencer

On Wed, Dec 7, 2016 at 5:43 AM, David Noveck <[email-masked]> wrote:

> that might arise in creating a stable reference based on this material,
> but note that Andreas is listed as the author of that man
> page :-)
>
>> Rules for NFSv4 Extensions and Minor Versions (
>> https://www.ietf.org/id/draft-ietf-nfsv4-versioning-07.txt
>> File System Extended Attributes in NFSv4 (https://www.ietf.org/id/draft
>> -ietf-nfsv4-xattrs-03.txt

---

From: David Noveck <[email-masked]>
Date: Thu, 8 Dec 2016 06:49:38 -0500

> Even though David responded, the question is for the document

Right but I thought it might be helpful to discuss the possible choices
before they decide to pick one.

> My apologies for being opaque about "stable reference".

I don't think you were "opaque".  The problem is that there is a level of
uncertainty about exactly how stable the reference needs to be, and no
matter what we choose, the answer might be different when the IESG (and
various assorted reviewers) consider the matter.

> The  POSIX-1003.1e normative reference makes it appear that it
> is a Posix standards document while in the content of the
> reference it does state "withdrawn" - confusing.

I referenced this issue in my review but I wasn't clear about why this was
a problem.  I just asked how it could be normative, which may not have been
helpful in correcting the problem.  Your formulation is clearer.

> The other problem is that I cannot quickly locate a copy of that

I could quickly locate a copy.  Unfortunately I can also quickly find a
bunch of advertised links to that document, which are broken :-(

> and if it is going to be a normative reference then it needs
> to be reasonably available.

That implies it wouldn't have to if it is an informative reference.  I
suspect that there will be some concern about this issue during the review
process, even for an informative reference.

> I understand that it is a defacto standard at this point given the

I don't think the IESG would be very receptive to the idea of "De facto
Standard References" section :-(

> My main point is that if it is going to be a reference a target needs
> to exist and the naming should likely be changed to remove the
> implication that it is a Posix standard.

I agree.

> As mentioned, if the reference is not needed based on the
> contents of the I-D, then the I-D can be reworded and references >
removed or changed.

I still think the acl man page would be a good target for an informative
reference but the authors need to decide what they want to do about this
issue.

---

From: [email-masked] (J. Bruce Fields)
Date: Thu, 8 Dec 2016 15:29:52 -0500

> reference but the authors need to decide what they want to do about this

I don't care much, I think either could work.  Are there other examples
of RFC's referencing man pages?

I guess for now I'll keep the existing reference and move it to an
"informative references" section.

--b.

---

From: David Noveck <[email-masked]>
Date: Thu, 8 Dec 2016 16:51:41 -0500

> Are there other examples of RFC's referencing man pages?

I don't think so but I don't think there are RFC's referencing withdrawn
POSIX drafts either. Sigh!

> I guess for now I'll keep the existing reference and move it to
> an "informative references" section.

I think you need a place to find this document such as a URL.  That's what
a reference is for, after all.  I know this sort of stuff can be
aggravating but I think you are better off getting this out of the way now,
rather during IESG review.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 8 Dec 2016 17:19:01 -0500

> rather during IESG review.

I haven't found a URL that looks like it would work better than just the
name of the document.

Maybe Andreas knows of one.

If not, then, I don't know, possible choices:

	1. find a good place to archive POSIX-1003.1e ourselves and refer
	   to that.
	2. figure out how to refer to the linux acl man page.
	3. just assert that this is how Linux (and possibly others) have
	   done it without citation.

#3 isn't too helpful, #1 sounds most helpful to everyone involved but
I'm not sure who to ask, so maybe #2 is the most practical.

--b.

---

From: spencer shepler <[email-masked]>
Date: Thu, 8 Dec 2016 14:21:44 -0800

Given how the reference is used, I would be more direct about the
implementation.  As stated in the draft, this mechanism is needed for
unix-like (e.g. Linux) to appropriately apply the umask logic in the face
of an ACL implementation.  As Dave suggests, if there is a Linux man page
with this logic captured, then quote it in the RFC and make the reference
(quoted text could be in an appendix).  If there is concern about copyright
(and rightfully so), then just make the general reference and it would be
good to have more elaboration of the requirements if the I-D is not fully
self-contained.  Would also be good to know the Solaris behavior but
realistically this is being done for Linux, right?

Spencer

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 12 Dec 2016 16:32:09 -0500

> realistically this is being done for Linux, right?

Right, so I think it would be enough to say "here's how we know it works
on Linux, other systems using mode bits and acls are likely to run into
the same problem".

OK, I'll think about how to do that.

--b.