[nfsv4] Re: Our different approaches to draft POSIX ACL support in NFSv4

Rick Macklem <rick.macklem@gmail.com> Thu, 25 July 2024 00:55 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 7D47CC1D8752 for <nfsv4@ietfa.amsl.com>; Wed, 24 Jul 2024 17:55:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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_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 LYgK099RC5Jb for <nfsv4@ietfa.amsl.com>; Wed, 24 Jul 2024 17:55:10 -0700 (PDT)
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FADC14F600 for <nfsv4@ietf.org>; Wed, 24 Jul 2024 17:55:10 -0700 (PDT)
Received: by mail-pg1-x534.google.com with SMTP id 41be03b00d2f7-7a130ae7126so302496a12.0 for <nfsv4@ietf.org>; Wed, 24 Jul 2024 17:55:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721868910; x=1722473710; 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=XyJ//YfmbhAeI/UMvzv5o7/AE3pmjGyNiYfVl3mpBs4=; b=MfsIJqxKmGXVBqnob5UcqG2fxB6mVj8L50YvCsOxTzN2PZPRd4eP2ULBk0ojWQ5vKh x9AUobCyIR/tj/Vrqj8JS72NPE5PbzGNozk6RSgQZ55hllhy1LNFYFhPTXPxIptrHbF0 5B33gxUIJ+ir4fo0UGWXbjwxpM6/nWx7sKQ6WsXM1I4Y1F9PfgyXuFoVcIPjEOhpfvnl gtxdTHgZD//KqM2YHv0Q34hhfw8jrgoSoTg+6dfFZskXYBlmQFFtCYw1/lbWAXCYCaTw 3AgrQGRS1A/YU1zSRjjTspnUJuY6AOk2s0xLiGgxgl7axSZYIVJtOSEKSAdr0yNqhLIn oAIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721868910; x=1722473710; 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=XyJ//YfmbhAeI/UMvzv5o7/AE3pmjGyNiYfVl3mpBs4=; b=uwsvtYmzoDrptS26XeuiRKg6aPmfWUUX4OVEokBpVZDk50UZGpqlgvBmSl4KltuiH5 Jwgp97m8nC701/l+FOVMghPTQm7RQghQboiuPqJUk2UREA+E3nSeti2yuAv2OiGa4CJP cii/Vfknnqgn0lQ6n1G+qUaxDCSqMK0pUIQh6xziCuLtQFgRNbWdRPAprVzn7DmW5ktZ plg79meBOBOvKXIYgm+xGvMp4mKZFxRBL+qux0HrwVObmQmFIHKeLivU17CMqb72AFbg JpLQoYPipFmN1qZkGtxeTfQKQVdT5ihCR5ZuIFUbGFgU8xGXEC176GO09w2fBSIx89MT hwjQ==
X-Forwarded-Encrypted: i=1; AJvYcCUQsaHm+joWwerco69JjIEgNrlDChYEazW5DgmdhVj75wr2RWapEDDy3la6xNVWUt2asU+7/Sw0miUU5ORG/g==
X-Gm-Message-State: AOJu0YxCh30Gv6j/U/w9bQpu4KpqSSq+RMYXFZkJ2QCIRaGbEXH8uDrD W/wzGpxuNKsuZ9oOPcta19tEazWC5uppRhRrIrQOCVS+0xwp2yk+gvKXeO8ZYSQ4LbGLmC/Tra/ i4pQGdykwjPgv0RFsq3m/PTtzdQ==
X-Google-Smtp-Source: AGHT+IGbzoRr7NQNjy/NPP4ou6vm2IjPENpf3Sv6cJqRhyEc2Lb+nQk1IrzA98p/9bUptJfvxHzG7w9ZtEFeNa8b4+c=
X-Received: by 2002:a17:90b:274c:b0:2ca:7636:2214 with SMTP id 98e67ed59e1d1-2cf2e9cfe3fmr280088a91.4.1721868910031; Wed, 24 Jul 2024 17:55:10 -0700 (PDT)
MIME-Version: 1.0
References: <CADaq8jdvZ5pcFNN5zjuVHLTO30v9=2kYKzFdRxxbkTmHYZdTdA@mail.gmail.com> <CAM5tNy7Fw954gCzYHCTjRg7th_njSHhxznni48Zz4xsSXT631A@mail.gmail.com> <53DAEF45-2A4D-4066-97C2-7B09018DE99B@oracle.com> <CAM5tNy6a4ZG90i2ugXzuPqQ1zrsK9m8jLRKmv9VpnFG6m_Pqew@mail.gmail.com> <DD250FBD-A434-4294-818A-5728757CE032@oracle.com> <d1c538065728c17df66a6f9e79e55d90849fc866.camel@gmail.com> <D352FEB9-A487-4B3E-9BC8-DB2C1896F941@oracle.com> <8efc39289ecef97624622cfc431f890736b579a0.camel@hammerspace.com> <33FA1D6E-73B3-43A1-B65C-D806156E39A5@oracle.com> <9720A0DE-D475-4A1B-AF8E-2119D27F2B1E@cert.org> <8EDC3491-4D38-4210-8630-0FFB597A8789@oracle.com>
In-Reply-To: <8EDC3491-4D38-4210-8630-0FFB597A8789@oracle.com>
From: Rick Macklem <rick.macklem@gmail.com>
Date: Wed, 24 Jul 2024 17:54:55 -0700
Message-ID: <CAM5tNy6BbzZYc304+VRXqDX=uH3BAeBu1dBazQQDaiCeChuCjw@mail.gmail.com>
To: Chuck Lever III <chuck.lever=40oracle.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bb7946061e07d8e7"
Message-ID-Hash: AR3B5L23DF6IR36DPPWNLTZOIBQBXI6T
X-Message-ID-Hash: AR3B5L23DF6IR36DPPWNLTZOIBQBXI6T
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: Trond Myklebust <trondmy@hammerspace.com>, Bruce Fields <bfields@fieldses.org>, "nfsv4@ietf.org" <nfsv4@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [nfsv4] Re: Our different approaches to draft POSIX ACL support in NFSv4
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/mGgssJCcS0FCECwBkFfHK1LO1pU>
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 Tue, Jul 23, 2024 at 2:39 PM Chuck Lever III <chuck.lever=
40oracle.com@dmarc.ietf.org> wrote:

>
>
> > On Jul 23, 2024, at 5:28 PM, Chris Inacio <inacio@cert.org> wrote:
> >
> >>>
> >>>
> >>> Bruce and Marius' draft should suffice to document the legacy non-
> >>> standard. It is still available from the data tracker:
> >>> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-acl-mapping/
> >>
> >> So again, it sounds like there does need to be standards
> >> action if the WG feels that this expired draft cannot
> >> be legitimately cited by a new document. My recollection
> >> of the citation rules suggests that it cannot, but I
> >> might be wrong.
> >>
> >> But even if it can be cited, I don't see how that
> >> addresses the IP concerns at all.
> >>
> >>
> >
> > [ci] I’m not commenting on the rest of the discussion.  But I will
> comment, with Chair hat on, about referencing this “closed” or
> “proprietary” material.  Generally, that is allowed - *as long as it was
> available enough for all WG participants to consult it during the
> development of a draft that references it*.  In this case, since it’s
> openly available, that wouldn’t be a problem.
>
> The concern I have is that the CDDL is not a fully
> open license. Yes, the nfs_acl.x file is available on
> the open Internet. The license makes it a potential
> problem for some.
>
I'm certainly no IP guy, but...
- It doesn't look like patents are a problem.
- The above (and other opensolaris sources related to NFSACL)
  that are accessible without signing any contract
  --> No trade secret.
- This leaves Copyright. So long as we do not copy the
  text verbatim, I do not believe there would be any copyright
  infringement.

If we were to do as Christoph suggested and use new attributes,
then there would be no copying, since there would not be the
new RPCs defined by NFSACL.  Any similarity would simply be
naming as used in the POSIX draft.  Using the terminology in
the POSIX draft should be sufficient, I think?

rick


>
> > [ci] That does NOT clear the IP hurdle if we reuse the techniques, etc.
> In that case, yes, an informational with a grant from Oracle for use would
> be extremely helpful.
>
> No promises, but I can begin to explore that approach. I
> feel like that approach would be the most above-board,
> and the resulting Informational document would not have
> to be large.
>
>
> > [ci] this has been my experience chairing and shepherding documents
> through the IETF process.  But I can follow up with the AD/secretariat/etc.
> to confirm.
>
> That echoes my experiences, and I would feel better if
> folks who are more expert in the black art of IP could
> weigh in.
>
>
> --
> Chuck Lever
>
>
> _______________________________________________
> nfsv4 mailing list -- nfsv4@ietf.org
> To unsubscribe send an email to nfsv4-leave@ietf.org
>