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