From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 5 09:30:52 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8B2F106566B; Mon, 5 Jul 2010 09:30:52 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7E1208FC0C; Mon, 5 Jul 2010 09:30:52 +0000 (UTC) Received: from [192.168.2.110] (host86-162-156-210.range86-162.btcentralplus.com [86.162.156.210]) by cyrus.watson.org (Postfix) with ESMTPSA id 8644946B23; Mon, 5 Jul 2010 05:30:50 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: Date: Mon, 5 Jul 2010 10:30:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <98BC47A1-7A14-48EF-8C4B-EFB7EF063853@freebsd.org> To: James Morris X-Mailer: Apple Mail (2.1081) Cc: freebsd-hackers@freebsd.org, David Quigley , Trond Myklebust , "J. Bruce Fields" , Chuck Lever , Rick Macklem Subject: Re: Extended attributes for NFSv3 - possible Linux interop X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 09:30:52 -0000 On 5 Jul 2010, at 10:25, James Morris wrote: >> I'm happy to help contribute to the writing on an Internet Draft = and/or=20 >> RFC -- the lack of NFS support for EAs (and the EA vs. file fork=20 >> confusion) have long caused me frustration, and with systems like=20 >> SELinux, our various MAC policies, and all sorts of other things=20 >> floating around, there's a strong motivation to fix this ... in a=20 >> portable way! I'm just sorry I haven't gotten to this sooner... >=20 > The IETF process is closed for NFSv3, so in this case, it would be not = an=20 > ID or RFC. =46rom a working group, yes, but a third-party informational RFC might = fit the process? It's been about a decade since I've done anything in = IETF-land so I'm not familiar with how the process has evolved. However, = there used to be a way to feed "this is a best practice originating = outside the IETF with protocol implications" ID through the RFC system, = which leaves it "not a standard" but at least a useful reference in an = authoritative form. Robert=