Sneak preview of Sun response
Paul Mockapetris <pvm@isi.edu> Mon, 20 March 1995 16:25 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05643; 20 Mar 95 11:25 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05639; 20 Mar 95 11:25 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08548; 20 Mar 95 11:25 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05632; 20 Mar 95 11:25 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05628; 20 Mar 95 11:25 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa08543; 20 Mar 95 11:25 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17) id <AA07194>; Mon, 20 Mar 1995 08:25:57 -0800
Message-Id: <199503201625.AA07194@zephyr.isi.edu>
To: iesg@CNRI.Reston.VA.US
Subject: Sneak preview of Sun response
Reply-To: pvm@isi.edu
Date: Mon, 20 Mar 1995 08:25:57 -0800
X-Orig-Sender: iesg-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Paul Mockapetris <pvm@isi.edu>
There's no good way to organize the lessons of Sun. So I'll pollute the IETF list this week and send out three installments: 1) overview 2) details (maybe just a pointer to FTP file) 3) ISOC and statements from the BoT candidates. While I had offered to let the IESG decide if they wanted to support me, you are probably better off staying away unless you want in. Here's the overview I'll publish tomorrow PM (subject to editing): ------------------------------------------------------------------------ There are several views on the table about SUN/ONC et al, and I'd like to give you mine. I hope the SUN issue itself is moot by the time you read this, but the issues will continue. In the current scheme of things the IETF does the work, and the IESG has two roles: coordinating IETF activities, and managing the standards track. The IESG's population is primarily technical folk, little removed from the IETF population. Here's the problem: The IESG is asked to execute a standards process which has both a technical and a formal aspect. The technical part is what we understand, and modulo getting some better tracking in place, is probably not a problem. The formal part is there as well - The ISOC, which would like to own the RFC copyrights, number space, IETF, et al, believes we need formal standards and practices so that our standards can become "important", there are liasons, GATT, G7 and many other concerns. If we published proposed, draft, and full GoodIdeas instead of Standards, most IETF people might be happy, but this wouldn't do for entry into the club of the 300 or so SDOs (that's standards development organizations) in the US alone. So we have three choices: 1) Do Standards for real Really doing standards means either throwing up your hands about a lot of the patent issues or hiring lawyers. Real standards means that people who execute the standards policy have legal liability. In the current situation, we have the worst possible case: the 1602 procedures strive to guarantee that the technology can be used, not just standardized, meaning more legal responsibility. This is really noble, but the IESG is left holding the legal bag for the glory of the ISOC standards goals. The IESG could pass the bag to the IAB, or to individuals in working groups, but that doesn't solve the problem either, it just passes the buck. (For details of buck passing techniques see RFC 1602, section 5) The only possible solution is to have a neutral holding company, with legal resources adequate to the level of legal agreement required. This is what the ISOC is supposed to be, but is not. 2) Do GoodIdeas (or de facto standards) We could decide to forget about setting real standards and try and turn back the clock, but the companies that send people to the IETF and the ISOC might have to be convinced. Anyway, this approach allows you to break the rules creatively. We might create GoodIdeas and hand them over to the ISOC for blessing and standardization. 3) Do GoodIdeas and call them standards In this scenario we just do fast and loose procedures, but call them standards anyway. This doesn't fly for two reasons: you have the worst possible legal situation AND the SDOs don't give you proper credit anyway. A benign form of this is just to add an "initiative" process to RFC1602. We could just let the IETF override any rule by some sort our usual consensus procedures. This is just a fomalization of the social contract theory espoused by Marshall and Dave. Vox populi, vox dei. What do do: The IESG, not being lawyers, shouldn't even try to do amateur hour. We find the neutral holding company (or reform the ISOC) and we staff it with lawyers with bonuses for getting agreements done or we give up on doing the legal work. We reduce our legal needs to match our resources. Its real simple. Of course, with an ISOC budget cut of 100% for IETF, we probably should reconsider why we are spending time to do the ISOC process. I have no idea about where the POISED 95 BOF and WG to follow will come down on this, but I think they can use the SUN history as a good test case. Fortunately Sun is a tolerant and benign case - but we really need to prepare for malignant cases. tomorrow - the Sun agreement history the next day - the ISOC and BoT paul USC/Information Sciences Institute phone: 310-822-1511 x285 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 90292
- Sneak preview of Sun response Paul Mockapetris
- Re: Sneak preview of Sun response Erik Huizer (SURFnet BV)