From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 6 14:18:33 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 B0349106566C; Tue, 6 Jul 2010 14:18:33 +0000 (UTC) (envelope-from dpquigl@tycho.nsa.gov) Received: from msux-gh1-uea01.nsa.gov (msux-gh1-uea01.nsa.gov [63.239.65.39]) by mx1.freebsd.org (Postfix) with ESMTP id 542D08FC0A; Tue, 6 Jul 2010 14:18:33 +0000 (UTC) Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id o66E5dv4022430; Tue, 6 Jul 2010 14:05:39 GMT Received: from [144.51.25.2] (moss-terrapins [144.51.25.2]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id o66E6UQL021700; Tue, 6 Jul 2010 10:06:30 -0400 From: "David P. Quigley" To: "Robert N. M. Watson" In-Reply-To: References: <98BC47A1-7A14-48EF-8C4B-EFB7EF063853@freebsd.org> Content-Type: text/plain Organization: National Security Agency Date: Tue, 06 Jul 2010 09:59:03 -0400 Message-Id: <1278424743.2494.28.camel@moss-terrapins.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 07 Jul 2010 00:26:22 +0000 Cc: freebsd-hackers@freebsd.org, James Morris , 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: Tue, 06 Jul 2010 14:18:33 -0000 On Mon, 2010-07-05 at 10:30 +0100, Robert N. M. Watson wrote: > 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 > >> RFC -- the lack of NFS support for EAs (and the EA vs. file fork > >> confusion) have long caused me frustration, and with systems like > >> SELinux, our various MAC policies, and all sorts of other things > >> floating around, there's a strong motivation to fix this ... in a > >> portable way! I'm just sorry I haven't gotten to this sooner... > > > > The IETF process is closed for NFSv3, so in this case, it would be not an > > ID or RFC. > > >From 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 It is possible to do this work not as a working group document which would be ideal since there is no NFSv3 WG. What you need to do is draft up the specification and submit it as an personal internet draft. Then since there is no working group you would probably need to contact the Transport Area Director (Still Lars I believe) to have him sponsor your document. Of course this may take a few iterations of the document before Lars is happy with it. You should also get people on the NFSv4 working group to look it over as well since some of them were probably involved with v3. Once Lars decides to sponsor the document it needs IESG approval (I think its IESG and not IAB). They will put out a request for experts to review your document and once again several iterations of review and rewrites will happen. Once that is all done the IESG sends it along to the RFC editor and eventually you will get an informational rfc numbers. Most times leaving it at this is sufficient for most people. Make sure that everyone knows its informational though and you don't intend it for the standards track. CALIPSO which was the IPv6 mls security option (not really an option since IPv6 doesn't have options) was done as an informational RFC. Dave