[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ga] Older Registrations
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 29-Mar-2000 Simon Higgs wrote:
> At 11:16 PM 3/28/00 -0800, William X. Walsh wrote:
>
> "The IANA has the discretionary authority to delegate portions of this
> responsibility"
>
> Everyone please note the words "discretionary" and "authority" are used by
> the NSF as acting agency for the USG.
>
> Any questions?
Yes, let's address them below. (BTW, you picked a really bad document to lay
as the foundation of your claims, really, this one is so easily picked apart).
>>On 29-Mar-2000 Simon Higgs wrote:
>> > At 02:01 PM 3/27/00 -0800, William X. Walsh wrote:
>> >
>> >>On 27-Mar-2000 Christopher Ambler wrote:
>> >> > There is every reason to recognize those. If for no other reason, then
>> >> > Jon Postel caused a number of individuals and companies to spend
>> >> > good resources in time and money based on his request to show working
>> >> > code previous to process.
>> >>
>> >>All I have to say to this is that you should have made sure that he indeed
>> >>had the authority he was claiming to have.
>> >
>> > Jon Postel did have the authority to add new TLDs to the root. The
>> evidence
>> > is sitting in the root zone right now. His actions were, specifically, as
>> > head of IANA & contracted to the NSF/USG, to establish the process and
>>
>>His authority existed solely with regard to ccTLDs. NSF's actions make this
>>clear. Provide documentary evidence to back up your claims, or just admit
>>you
>>are wrong.
>
> Since I'm not wrong, let's start with an NSF InterNIC document:
>
> ftp://ftp.internic.net/nsf/nren-solicitation.txt
> ***Start Quote***
> This project solicitation is issued pursuant to the National
> Science Foundation Act of 1950, as amended (42 U.S.C. 1861 et
> seq) and the Federal Cooperative Agreement Act (31 U.S.C. 6305)
> and is not subject to the Federal Acquisition Regulations.
> [SNIP]
> 1. (P) Registration Services
> The provider of registration services will function in accordance
> with the provisions of RFC 1174. As stated in RFC 1174, "[T]he
> Internet system has employed a central Internet Assigned Numbers
> Authority (IANA) for the allocation and assignment of various
> numeric identifiers needed for the operation of the Internet.
> The IANA function is performed by the University of Southern
> California's Information Sciences Institute. The IANA has the
> discretionary authority to delegate portions of this
> responsibility and, with respect to numeric network and
> autonomous system identifiers, has lodged this responsibility
> with an Internet Registry (IR)." Moreover, in cooperation with
> the IANA, the IR may create delegate registries to carry out
> registration services for specified domains.
> ***End Quote***
Everything I see in this section deals with IP Addresses and Numbers until the
last part. And if you put it back into the original context, it is pretty
clear to me they are discussing the .arpa domain as it related to IP delegation.
This entire section is irrelevent to your claims.
> No mention of any limitations to ccTLDs here.
No mention of gTLDs or Top level domains either. More attempts to twist things
to your benefit?
> ? Now let's see what RFC1174
> says:
>
> http://www.faqs.org/rfcs/rfc1174.html
Which was written by the IAB, and is not binding on the USG/NSF in any fashion
whatsoever, so it serves as NO authority at all. But let's look at it anyway.
> ***Start Quote***
> 1.2. Introduction
> Throughout its entire history, the Internet system has employed a
> central Internet Assigned Numbers Authority (IANA) for the allocation
> and assignment of various numeric identifiers needed for the
> operation of the Internet. The IANA function is performed by USC
> Information Sciences Institute. The IANA has the discretionary
> authority to delegate portions of this responsibility and, with
> respect to numeric network and autonomous system identifiers, has
> lodged this responsibility with an Internet Registry (IR). This
> function is performed by SRI International at its Network Information
> Center (DDN-NIC).
Again, "numeric network and autonomous system identifiers." More IP Address
stuff. IANA's authority over IP address delegation is not in dispute, and
irrelevent to your claims.
> [SNIP]
> 1.3. Proposed Method of Operation
> It is proposed to retain the centralized IANA and IR functions.
> The IR would continue to be the principal registry for all network
> and autonomous system numbers. It would also continue to maintain
> the list of root Domain Name System servers and a database of
> registered nets and autonomous systems.
> ***End Quote***
Again, no mention that IANA had authority to create, delegate or accept
applications for new top level domains.
> Again, no mention of ccTLDs. Just lots of authority for lots of system &
> network identifiers, including domain names.
Where do you see that????? I see tha tthey maintain a list of root dns
servers, but nothing that gives them authority over domain names. Please,
specify what portions of the above give authority to IANA over domain names
(again, presuming the RFC even carries any binding authority in the first
place).
> http://www.isoc.org/isoc/media/releases/iana.shtml
> ***Start Quote***
> The IANA has managed the root of the DNS to promote stability and
> robustness. This role is primarily one of making minor technical decisions
> about the location of root nameservers, the qualifications of applicants to
> manage country code top level domains, and evaluating any additions to the
> established generic top level domains which are proposed by the
> community.
> [SNIP]
> The IANA is the name for the function for the allocation and
> assignment of various identifiers needed for the operation of the
> Internet, which function was assigned by DARPA to the
> Information Sciences Institute (ISI) of the University of
> Southern California pursuant to contracts between DARPA
> and ISI. Under the DARPA contracts, ISI (through the IANA
> function) has the discretionary authority to delegate portions of
> this function, and has delegated that portion of the
> responsibility concerning some aspects of numeric network and
> autonomous system identifiers to an Internet Numbers Registry
> (IR), previously performed by SRI International and currently
> performed by NSI. See RFC 1174 and Section H.1., NSF
> Solicitation for Network Information Services Manager for
> NSFnet and the NREN ("ISI (as the IANA) ha[s] delegated
> to the DISA NIC (currently NSI) the registration of users for
> the Internet").
> ***End Quote***
>
> The Internet Society disagrees with you. Specifically, there is authority
> to evaluate new gTLDs.
"Numeric Network and Autonomous System Identifiers" Still nothing about top
level domains, and nothing about gTLDS.....
More taking things out of context and twisting them to try and make them say
something they do not say, Simon. NONE OF THIS BACKS UP YOUR CLAIMS, even on
a quick cursory review.
> http://www.networksolutions.com/legal/internic/cooperative-agreement/agreement
> .html
> ***Start Quote***
> D. Moreover, in cooperation with the IANA, the IR may create
> delegate registries to carry out registration services for
> specified domains.
> [SNIP]
> F. The Non-military internet registration services to be
> provided under this agreement will initially include, but not be
> limited to, the following:
> 1. Domain name registration
> 2. Domain name server registration
> 3. Network number assignment
> 4. Autonomous system number assignment
> ***End Quote***
Again, nothing there that gives IANA authority to create top level domains,
accept applications for new top level domains, or to create a process for new
top level domains.
> This explains the function of the RFC1591 application process for new TLDs,
> and is one more confirmation of RFC1174.
>
> I dunno William. The evidence is overwhelmingly against you.
>
No, Simon, it really isn't. I ask again, do you have references to specific
documentation that gives IANA the authority to create new gTLDs or not?
I notice you ignore the reference to Sexton's messages on the same thread. He
provides some really compelling arguments to this as well, and you have just
ignored all of that and taken a lot of unrelated documents and tried to twist
them into something that they don't say.
I for one think it looks like you are grasping at straws here. But then you
have a real issue at stake here, don't you? You stand to not be able to keep
something you took upon yourself to create, and have someone else do it
instead. I understand your motivation very well. But that doesn't make these
arguments any more valid.
- --
William X. Walsh <william@userfriendly.com>
http://userfriendly.com/
GPG/PGP Key at http://userfriendly.com/wwalsh.gpg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1c (Mandrake Linux)
Comment: Userfriendly Networks http://www.userfriendly.com/
iD8DBQE44b8b8zLmV94Pz+IRAg5ZAKDUZi4c2UXrtq/TJAyfnjIp7N6ZWgCg3BHW
Uq7QDpMg7ZyEKvUMcBsaw18=
=ppz7
-----END PGP SIGNATURE-----
--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html