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

bfields@fieldses.org (J. Bruce Fields) Thu, 08 December 2016 20:29 UTC

Return-Path: <bfields@fieldses.org>
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 E2300129699 for <nfsv4@ietfa.amsl.com>; Thu, 8 Dec 2016 12:29:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.798
X-Spam-Level:
X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56MPTPOQuQUK for <nfsv4@ietfa.amsl.com>; Thu, 8 Dec 2016 12:29:53 -0800 (PST)
Received: from fieldses.org (fieldses.org [173.255.197.46]) by ietfa.amsl.com (Postfix) with ESMTP id 47F951295FC for <nfsv4@ietf.org>; Thu, 8 Dec 2016 12:29:53 -0800 (PST)
Received: by fieldses.org (Postfix, from userid 2815) id 9694B50F8; Thu, 8 Dec 2016 15:29:52 -0500 (EST)
Date: Thu, 08 Dec 2016 15:29:52 -0500
To: David Noveck <davenoveck@gmail.com>
Message-ID: <20161208202952.GB26583@fieldses.org>
References: <MWHPR03MB28935C4A8AF5FCDB34B37EA6C7B80@MWHPR03MB2893.namprd03.prod.outlook.com> <MWHPR03MB289323FB62D892F442482D9CC7830@MWHPR03MB2893.namprd03.prod.outlook.com> <CADaq8jewDSJZ7p3Kbjg43z0yhSWf20HcB+e+qgY35h0YavgryA@mail.gmail.com> <CAFt6BakDsGoo56KQPV-UGcCsPd=pUzrmy+j1DkGmy-6ryrDTbg@mail.gmail.com> <CADaq8jd42_UThHThuO-co5VSrU1go=QPiEXhu=rAdx6h2SSHYg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADaq8jd42_UThHThuO-co5VSrU1go=QPiEXhu=rAdx6h2SSHYg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
From: bfields@fieldses.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/V32OyKeHAwHsu9CUEH3Gz5BP2WQ>
Cc: "J. Bruce Fields" <bfields@redhat.com>, NFSv4 <nfsv4@ietf.org>
Subject: Re: [nfsv4] WG Last Call for Extension and Minor Versions, Extended Attributes, and ACLs / Umask - Ends Dec 2nd 2016
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Dec 2016 20:29:55 -0000

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.