Subject: Re: [ifwp] FYI -- First draft IETF/IANA contract (fwd)

From: jeff Williams <[email-masked]>
Date: Tue, 15 Dec 1998 17:52:30 +0000

Karl and all,

  We are in complete agreement with Karl on this as well.  In addition the
IETF proposal seems to be an attempt to "Map-In" the IETF as the
"ONLY" protocol standards organization.  This has been a problem and
point of contention for several years now and one of the reasons why a
need to "Privatize" the Internet.

To wit from Brian Carpenters "Contract proposal":

"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. "

  The above language emphizes the point that "ONLY" the IETF should
set Protocol standards, which we find not only to be in direct conflict
with the White Paper, but also counterproductive to the Stakeholders/users
as well.

Karl Auerbach wrote:

> 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____________________________________________

Regards,

--
Jeffrey A. Williams
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [email-masked]
Contact Number:  972-447-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208

---

From: jeff Williams <[email-masked]>
Date: Tue, 15 Dec 1998 17:52:30 +0000

Karl and all,

Regards,

---

From: "John Border" <[email-masked]>
Date: Tue, 15 Dec 1998 18:19:11 -0500

I think this discussion has quickly moved to the wrong mailing list but I
don't have the right context to push it back...

    Actually, the quoted statement only says that the IETF wants the right to
assign and register protocol parameters for protocols that the IETF develops.
 It doesn't say that only the IETF should set protocol standards.

    I hesitate to speak for anyone but myself.  But, I think the problem here
is that Brian's mail did not properly set the context of the discussion.
 Anyone at last Thursday's IETF poisson meeting [probably] got the context but
anyone who was not there probably did not...

John Border
Hughes Network Systems

On Dec 15,  5:52pm, jeff Williams wrote:
> Subject: Re: [ifwp] FYI -- First draft IETF/IANA contract (fwd)
>
> Karl and all,
>
> [ Attachment (application/x-pkcs7-signature): "smime.p7s" 3362 bytes
>   S/MIME Cryptographic Signature
>   Encoded with "base64" ]
>-- End of excerpt from jeff Williams

---

From: "John Border" <[email-masked]>
Date: Tue, 15 Dec 1998 18:19:11 -0500

John Border
Hughes Network Systems

---

From: jeff Williams <[email-masked]>
Date: Tue, 15 Dec 1998 20:10:16 +0000

John and all,

  It appears from you comments here that you did not read the proposes
Karl forwarded kindly, regarding part 2, which I had quoted part of
in my previous post in response on this thread.  In so many words
it indicates that the IETF and IESG will dictate what protocol standards
will be in effect and that those standards will be based on "Traditional"
RFC documentation.  As such, this seems like a round about way
of "Mapping-in" the IETF and the IESG as default  or only Protocol
standards setting group for the ICANN.  This is unexceptable.

Regards,

---

From: jeff Williams <[email-masked]>
Date: Tue, 15 Dec 1998 20:10:16 +0000

John and all,

Regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Dec 1998 14:10:03 +0000

Let me say this once, and then I will set a filter such that
any further IFWP mail will be deleted automatically on arrival.
I apologise for cc'ing the IETF list, but this needs to be clear
to everybody. 

The IETF uses a high-tech clerical service called the IANA. The
creation of ICANN and its supporting organisations, to deal with
policy matters, is largely orthogonal to this. The IETF will
need a contract with the IANA, regardless of who executes the
IANA function. This is a private matter between the IETF and the
IANA. That is what we are now working on, as an IETF WG discussion.

  Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Dec 1998 14:10:03 +0000

Brian Carpenter

---

From: jeff Williams <[email-masked]>
Date: Fri, 18 Dec 1998 11:31:50 +0000

Brian and all,

> I apologise for cc'ing the IETF list, but this needs to be clear

  Well your reaction to my post in this manner is a strong indication
that SOME members of the IETF are NOT interested in an open
discussion process in these matters.  This is indeed a shame,
and as an IETF member I fine it reprehensible and disenfranchising
to the INternet community as a whole and most of the IETF
community.

> IANA. That is what we are now working on, as an IETF WG discussion.

  No Brian it is NOT any longer nor should it have ever been a private
matter and in fact was never a private matter between the IANA and
the IETF.

Regards,

---

From: jeff Williams <[email-masked]>
Date: Fri, 18 Dec 1998 11:31:50 +0000

Brian and all,

Regards,

---

From: Jay Fenello <[email-masked]>
Date: Fri, 18 Dec 1998 12:34:51 -0500

Hi Brian,

Now that the relationship between the IETF and ICANN 
is under review, sometimes it is helpful to take a step 
back and view the situation from a higher level.

Conceptually, a stable governance structure for the Internet 
would balance the interests of the Internet infrastructure 
providers, with the interests of Internet users, subject to 
the recommendations of the Internet technical community.

Somewhere along the line, another model of governance was 
introduced, one designed to build support from the existing 
Internet establishment.  This model splits representation on
the ICANN board between the Internet establishment (the nine
board appointee's from the three SO's), and the newly forming 
Internet stakeholders (the nine board appointee's from the 
at-large membership).

While the second structure was successful at buying early
support (especially when Jon was here to keep it all together), 
it is a structure that is inherently unstable, and not as easy
to justify as the conceptual model outlined above.

IMHO, the IETF should not be contorting itself to fit into 
a poorly designed SO structure.  The IETF *should*, however,
be the vehicle that provides recommendations on behalf of 
the Internet technical community.  

Given the failure of ICANN to gain approval as it is now
constituted, given the uncertainty surrounding the ICANN
membership structure, and given the uncertainty surrounding
the SO structures, NOW is the time to address this issue.  

IMHO & FWIW.

Jay.

P.S.  To ensure delivery, "[IFWP]" was removed from the header, 
      and the the IFWP list was bcc:'d on this email.

>> > > ___END____________________________________________

Respectfully,

Jay Fenello
President, Iperdome, Inc.  
404-943-0524  http://www.iperdome.com

---

From: Jay Fenello <[email-masked]>
Date: Fri, 18 Dec 1998 12:34:51 -0500

Hi Brian,

IMHO & FWIW.

Jay.

Respectfully,

Jay Fenello

---

From: jeff Williams <[email-masked]>
Date: Fri, 18 Dec 1998 17:49:32 +0000

Kent and all,

 "A PSO" should indeed exist for in part the reasons that Kent has stated
below.  The one currently should be denied legitimacy as it was not
formulated in a public forum and without the proper requirements of
the White Paper, namely Transparency and Openness.

Kent Crispin wrote:

> On Fri, Dec 18, 1998 at 10:25:43AM -0800, Karl Auerbach wrote:
> > Consequently there is no need to burden ICANN with a Protocol parmeters
> > Supporting Organization to oversee what is nothing more than a clerical
> > operation with no public policy content.
>
> That is not why the PSO exists.  The PSO exists to give ICANN a
> strong technical representation, independent of anything to do with
> protocol parameters.
>
> --
> Kent Crispin, PAB Chair                         "Do good, and you'll be
> [email-masked]                               lonesome." -- Mark Twain
>

Regards,

---

From: jeff Williams <[email-masked]>
Date: Fri, 18 Dec 1998 17:49:32 +0000

Kent and all,

Regards,