Subject: FYI -- First draft IETF/IANA contract (fwd)

From: Bob Allisat <[email-masked]>
Date: Thu, 17 Dec 1998 17:20:49 -0500 (EST)

Let me say that I concur with Mr. Auerbach's
 opinion though perhaps for differing reasons.
 IETF is no more and no less than one of many
 potential advisory bodies to the organization
 that will replace IANA (be that ICANN, ORSC or 
 yet another group). To have such an agreement
 as is advocated by Mr. Carpenter signed in
 advance of this turn-over will be to hand-cuff
 this body in advance and hard-wire IETF into
 what amounts to a veto position over Internet
 governance. This is unacceptable.

 Finally if it wasn't apparent before IETF is
 entirely engaged in a political struggle. In
 opposition to public  pronouncements this makes
 this forum and the IETF a political forum. And
 this and other messages discussing the issues
 outlined below absolutely appropriate. 

 Respectfully,

 Bob Allisat

 Free Community Network _ [email-masked] . http://fcn.net
 http://fcn.net/allisat _ http://fcn.net/draft

---------- Forwarded message ----------
Date: Tue, 15 Dec 1998 10:20:29 -0800 (PST)
From: Karl Auerbach <[email-masked]>
Reply-To: [email-masked]
To: IFWP Discussion List <[email-masked]>
Subject: [ifwp] FYI -- First draft IETF/IANA contract (fwd)

FYI...

I personally find the following attached proposed agreement to be
absolutely unacceptable.

It is merely a services contract under which the IETF gets ICANN
to perform clerical services, probably without compensation, and under
which ICANN can exert no policy role.

And this gets an SO and three board seats?

I personally find this proposal to be in total conflict with the purposes
espoused in the White Paper.

This raises with clarity the issue that the Protocol Parameters function
is merely a clerical job, free of policy ramifications.

As such, it should be removed entirely from ICANN, there should be no
Protocol Parameters Supporting Organization, and no board seats for such
an organization.

The IETF should, like other standards bodies, undertake to pay for its own
administrative clerical jobs.

ICANN should reject the following submission from the IETF/IAB as being
contrary to the policies of the White Paper.

		--karl--

---------- Forwarded message ----------
Date: Tue, 15 Dec 1998 17:33:31 +0000
From: Brian E Carpenter <[email-masked]>
To: [email-masked]
Cc: Esther Dyson <[email-masked]>,
    Mike Roberts <[email-masked]>,
    [email-masked],
    Zita <[email-masked]>
Subject: First draft IETF/IANA contract
Resent-Date: Tue, 15 Dec 1998 10:01:30 -0800 (PST)
Resent-From: Karl Auerbach <[email-masked]>
Resent-To: [email-masked]
Resent-Subject: First draft IETF/IANA contract

Poisson,     cc Esther Dyson, Mike Roberts, Joyce Reynolds, Zita Wenzel

To get moving as quickly as possible, here is a rough draft of the 
proposed contract between the IETF (probably represented by the ISOC) 
and the IANA (represented by whichever legal entity ends up being 
responsible, potentially ICANN).

This draft has been discussed in the IAB and IESG but IANA, ICANN 
and ISI have not commented on it. It is intended to represent 
"heads of agreement" or principal terms, rather than a full 
contract. We have not attempted to add the many contractual 
provisions that might otherwise be advisable in the definitive 
contract.

Therefore please discuss only the questions of principle,
within the narrow question of IETF/IANA relations,
and we will turn it into an Internet Draft after a first
round of discussion. 

   Brian Carpenter

DRAFT TERMS OF AGREEMENT BETWEEN THE IETF AND THE IANA

This agreement is between the Internet Engineering Task Force (IETF)
and the Internet Assigned Numbers Authority (IANA).

1. This agreement is valid for one year [3 years??], tacitly renewed 
on expiry unless cancelled with 6 months notice from either party.

2. The IANA will, [at no charge??], assign and register IETF protocol
parameters only as directed by the IETF. The criteria and 
procedures for this are specified by the IETF in RFCs, including
Proposed, Draft and full IETF Standards and Best Current
Practice documents, and any other RFC that calls for IANA assignment. 
If they are not so specified, or in case of ambiguity, IANA will 
continue to assign and register Internet 
protocol parameters that have traditionally been registered by IANA,
following past and current practice for such assignments, unless 
otherwise directed by the Internet Engineering Steering Group (IESG). 
If in doubt or in case of a technical dispute, IANA will seek and 
follow technical guidance exclusively from the IESG.

The IETF will develop any missing criteria and procedures over time,
which the IANA will adopt when so informed by the IESG.

3. In the event of dispute between the IANA and the IETF, both
will seek guidance from the IAB whose decision shall be final.

4. Two particular assigned spaces present policy issues, in addition
to the technical considerations specified by the IETF: the
assignment of top level domain names, and the assignment of IP address
blocks. These policy issues are outside the scope of the present 
agreement.

5. The IANA shall make available to the public, free of charge,
full details of all current assignments, using the second level
domain name "iana.org". 

6. In the event of termination of this agreement by either party,
the intellectual property in the database of all current assignments,
and the use of the domain name "iana.org", shall revert to the IETF.

7. The IANA shall provide on-line facilities for the public to request
Internet protocol parameter assignments and shall either execute
such assignments, or deny them for non-conformance with applicable
technical requirements, in a timely manner. There shall be no charge
for assignments without the consent of the IETF and requests shall
only be denied on technical grounds.

For protocols within the IETF scope (i.e., registries created 
by IETF (IAB or IESG) action), appeals against such denials may be
made to the IESG and subsequently to the IAB as provided in 3 above.

8. The IANA shall have one non-voting liaison seat in  each of the 
IAB and IESG, and may participate in IAB and IESG discussions 
concerning technical requirements for protocol parameter assignment 
through such liaisons. 

9. The IANA shall review all documents in IETF Last Call to identify
any issues of concern to the IANA, and shall raise these issues
with the IESG.

---

__________________________________________________
To receive the digest version instead, send a
blank email to [email-masked]

To SUBSCRIBE forward this message to:
[email-masked]

To UNSUBSCRIBE, forward this message to:
[email-masked]

Problems/suggestions regarding this list? Email [email-masked].
___END____________________________________________

---

From: [email-masked]
Date: Mon, 21 Dec 1998 10:08:46 -0800

*> 
  *> The Internet technical community has always been
  *> much larger than IETF/IESG/IAB.

Mr. Banan,

If you look more carefully, you will find that a noticeable part of the
"non-IETF Internet technical community" consists of people who have,
until recently, entirely failed to appreciate the strengths of the
Internet architecture, and in some cases have worked against its
success by promoting competing but narrow technologies -- X.25, OSI,
and ATM-supreme come to mind.
 
So, perhaps we should distinguish the *core* Internet technical
community, the hundreds of very smart people have labored very, very
hard in the IETF since its beginning in 1986, from the more recent
converts to the Internet.  Unfortunately, there is quite a lot of
evidence that at least the noisier of the new converts have not really
"gotten it" yet.  They want to reintroduce X.25 or OSI, or they want to
introduce their own pet protocols that are tightly engineered as point
solutions that do not have the breadth of vision that the Internet
requires.

The IETF/IESG/IAB does not represent the entire community of computer
communication, and it certainly not the telecommunications industry,
but it does represent the core Internet technical community.  These
days, too much of its energy goes into blocking the entropy being
introduced by the newcomers, who don't yet "get it".  Even worse are
the newcomers who insist on standing outside the IETF process and
haranguing us.

  *> 
  *> Central technical support services such as protocol
  *> number assignment (IANA services) and protocol
  *> publication services (RFC publication) are services
  *> to which all of the Internet technical community
  *> should have fair and equal access.
  *> 

The RFC series has been, and continues to be, a series of documents by
and for the core Internet technical community, and in support, direct
or indirect, of the IAB/IESG/IETF.  There is no such thing as "fair and
equal access" to RFC publication.  Documents are judged on the degree
to which their publication will help (or hurt) the Internet.

Since the IETF is a group process, and democracy is messy, the results
are sometimes inconsistent and/or slow.  "Traditional" standards
processes are driven by companies who can afford to pay people to be
standards jockies.  By and large, the core of the IETF is made up of
people who in varying degrees moon-light from their regular jobs to do
what needs to be done.

  *> IETF/IESG are just one of the many protocol
  *> producing entities that have been moving the
  *> Internet forward. If the IETF/IESG (a protocol

Perhaps you and I differ on what we mean by the "Internet".  Perhaps
I would understand your point better if you would name a few other
protocol producing entities that are "moving the Internet forward".

  *> producing entity) is allowed to take on on any role
  *> that could possibly interfere with the progress of
  *> the work of other non-IETF protocol producing entities
  *> then the progress of the Internet technical
  *> community will slow down.

I believe you have this exactly backwards.  It is vital that other
"non-IETF protocol producing entities" not hinder the work of the
core Internet technical community, i.e., the work of the IETF.

I would suggest that if people really want to contribute to Internet
technology, they should stop posturing and join constructively into
IETF standards activities.

  *> 
  *> For example, from first hand experience I know that
  *> the IESG has interfered (and can interfere again)
  *> with publication of non-IETF non-standards-track
  *> documents as Informational RFCs. The case of
  *> publication of RFC-2188 is one such reference
  *> point.
  *> 

The word "intererence" is self-serving and inappropriate here.

  *> 
  *> The Internet's central technical support services
  *> such as protocol number assignment (IANA services)
  *> and protocol publication services (RFC publication)
  *> should be managed and run by completely INDEPENDENT
  *> entities not involved in producing protocols.
  *> 
  *> 
  *> The IETF/IESG have a clear and obvious case of
  *> conflict of interest when (in theory or in
  *> practice) they assume oversight, supervisory or
  *> controlling roles in the Internet's central
  *> technical support services.
  *> 

For reasons I have stated above, I would submit that this
paragraph reflects a deep confusion about reality.

Bob Braden

---

From: [email-masked]
Date: Mon, 21 Dec 1998 10:08:46 -0800

*> 

Mr. Banan,

  *> 

  *> 

  *> 

Bob Braden