Date: Mon, 5 Jul 2010 10:30:48 +0100 From: "Robert N. M. Watson" <rwatson@freebsd.org> To: James Morris <jmorris@namei.org> Cc: freebsd-hackers@freebsd.org, David Quigley <dpquigl@tycho.nsa.gov>, Trond Myklebust <trond.myklebust@fys.uio.no>, "J. Bruce Fields" <bfields@fieldses.org>, Chuck Lever <chuck.lever@oracle.com>, Rick Macklem <rmacklem@freebsd.org> Subject: Re: Extended attributes for NFSv3 - possible Linux interop Message-ID: <DA80512E-4239-48DE-B512-BED88A168836@freebsd.org> In-Reply-To: <alpine.LRH.2.00.1007051907090.27098@tundra.namei.org> References: <alpine.LRH.2.00.1007021025580.2699@tundra.namei.org> <98BC47A1-7A14-48EF-8C4B-EFB7EF063853@freebsd.org> <alpine.LRH.2.00.1007051907090.27098@tundra.namei.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DA80512E-4239-48DE-B512-BED88A168836>