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

spencer shepler <spencer.shepler@gmail.com> Thu, 08 December 2016 22:25 UTC

Return-Path: <spencer.shepler@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 C02B2129B8C for <nfsv4@ietfa.amsl.com>; Thu, 8 Dec 2016 14:25:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGnadTSI_OnE for <nfsv4@ietfa.amsl.com>; Thu, 8 Dec 2016 14:25:21 -0800 (PST)
Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612BE129BBC for <nfsv4@ietf.org>; Thu, 8 Dec 2016 14:21:45 -0800 (PST)
Received: by mail-io0-x242.google.com with SMTP id f73so3033188ioe.2 for <nfsv4@ietf.org>; Thu, 08 Dec 2016 14:21:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QXCfUYbE8s5mGyQ/2QpN3ZYCo0jkUhKHqMFlYudxE5k=; b=lF7Lba3J0XXYp4kdHdUEALNMSVfJb64m3gttgkCbF7yADGLGDTEZY+NU4ExaSiEMi/ pURhDf6C/Pq5MRsQ0Ef8Cb2/y3EPlkLKpxj619Muvi+5RbvMiqrUdTc2z/DYCIIQ6HGI 6h06H5x8mh8YOiZyrQbLsb01KICNb31MWX7CfG8qvRoyTdMLFztBOvZFORDhUHysOgWE TZU8e3sgkfCA25S2T9Fzo4xo5LutQayCpjjNUzjmEsmRZocfw/JjkMz3eK3ex9Ylayb6 1SXSjq0mRaUbPx5fgwrms7vk8HxW6hTfhsywqnT2Skd9R3cEsgtb9LBkI68iqX54rYH6 yL8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QXCfUYbE8s5mGyQ/2QpN3ZYCo0jkUhKHqMFlYudxE5k=; b=hxfe3qIA7YQUysjCPxQaQX2NfQJ2cu/0wGAmWN8s8S/aAC7p+7kYntyQ2TyXiIh4iE 892MSc2SHvvLY6v2ZparNoPDwBli7XZbuuNTpV7MBBquZAL/xLWVt/emy6ZXmKtOfzPQ KJZjpI0QUI0aTZ6zBZEWJ/vLd9xNtz2X/wmvQmtsp4XKXWwoRKZWFECFS+mYEgdAf4xA PPhwbH4f57ewqVfTulTEHkAxRB8GTBU1+s8LKYQIRVeT1QBADqk4RQNgTme+PNGxXYPH L4AnalG7OrSMzKaAxboEoXEE6pZbVvZvEEBYzVuewG1I/IhwuM0zc8J5tLH2y/aCJCkF 5vhw==
X-Gm-Message-State: AKaTC008AL920v1VvHKGYiEOfsarLDr7CDYQh7SRReA92FytQTkdadVee84kc4S3Dc8bdbVkgScLL9r95Ou7OA==
X-Received: by 10.36.107.79 with SMTP id v76mr4029651itc.32.1481235704748; Thu, 08 Dec 2016 14:21:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.10.156 with HTTP; Thu, 8 Dec 2016 14:21:44 -0800 (PST)
In-Reply-To: <CADaq8je-pL0yGUvzL2r7wjSWXeWZBf3DgF5APMDKQpD2ejY16Q@mail.gmail.com>
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> <20161208202952.GB26583@fieldses.org> <CADaq8je-pL0yGUvzL2r7wjSWXeWZBf3DgF5APMDKQpD2ejY16Q@mail.gmail.com>
From: spencer shepler <spencer.shepler@gmail.com>
Date: Thu, 8 Dec 2016 14:21:44 -0800
Message-ID: <CAFt6Ba=yyVqyt3PJ6g_brUNt+Oy931kOuNw2sXtXWLe=CrqO8Q@mail.gmail.com>
To: David Noveck <davenoveck@gmail.com>
Content-Type: multipart/alternative; boundary=001a114a917c02ad8d05432d108f
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/6tW4xERSFpBeRsHFcMPVPow3bDQ>
Cc: "J. Bruce Fields" <bfields@fieldses.org>, "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 22:25:24 -0000

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

On Thu, Dec 8, 2016 at 1:51 PM, David Noveck <davenoveck@gmail.com> 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 <bfields@fieldses.org>
> 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.
>>
>
>