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

["J. Bruce Fields" <[e-mail]>]

On Thu, Dec 08, 2016 at 02:21:44PM -0800, spencer shepler wrote:
> 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?

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.

> 
> Spencer
> 
> On Thu, Dec 8, 2016 at 1:51 PM, David Noveck <[e-mail]> wrote:
> 
> > > 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.
> >
> >
> >
> > On Thu, Dec 8, 2016 at 3:29 PM, J. Bruce Fields <[e-mail]>
> > wrote:
> >
> >> On Thu, Dec 08, 2016 at 06:49:38AM -0500, David Noveck wrote:
> >> > > Even though David responded, the question is for the document
> >> > > authors.
> >> >
> >> > 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
> >> > > document
> >> >
> >> > 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
> >> > > implementation.
> >> >
> >> > 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.
> >>
> >> 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.
> >>
> >
> >