on ICANN Evolution and Reform
Second Interim Implementation Report
2 September 2002
1. Mission and Core Values
2. ICANN Structure
A. The Board of Directors.
1. Voting Members.
2. Non-Voting Liaisons.
B. Nominating Committee.
1. Sources of Nominating Committee Members.
2. Criteria for Selecting NomCom Delegates.
3. Criteria for Selection by NomCom.
C. Supporting Organizations.
1. Generic Names Supporting Organization.
a. Composition of Council.
b. General Assembly.
c. Generic Names Policy Development Process.
2. Country-Code Names Supporting Organization (ccNSO).
3. Address Supporting Organization.
D. Advisory Committees.
1. Governmental Advisory Committee.
2. Technical Advisory Committee.
3. Security Advisory Committee.
4. Root Server System Advisory Committee.
5. At Large Advisory Committee.
3. Public Input and Accountability.
Appendix 1: Redrafted
statement of ICANN's Mission and Core Values
Appendix 2: Tentative
Timeline for the NomCom Process
On 28 June 2002, the ICANN
Board adopted and endorsed the Blueprint
for Reform that had been recommended by the Board's Evolution
and Reform Committee (ERC). It directed the ERC to "oversee further
detailed implementation and transition work based on the Blueprint for
The ERC has subsequently released two Status Reports on Implementation,
dated 15 July
and 24 July
2002, and issued its First
Interim Implementation Report on 1 August 2002. In this Second Interim
Implementation Report, we lay out our tentative views on the majority
of implementation details, and seek public comment on those views. We
anticipate that we will make our "final" recommendations to
the Board and the community on or about 1 October 2002. (We put "final"
in quotation marks simply to make it clear that we may continue to refine
those final recommendations in response to community feedback prior to
or at the Shanghai meeting on 27-31 October 2002.)
We are prepared to make one final recommendation now: evolution and reform
should be an ongoing process in ICANN. Each of the ICANN constituent entities,
including the Supporting Organizations and the Advisory Committees, should
be reviewed in some way at least every two years, with the objectives
to determine whether (1) it has a continuing purpose in the ICANN
structure, and (2) if so, whether any change in structure or operations
is desirable to maximize its effectiveness. ICANN should be a living,
breathing body, changing to meet evolving needs and circumstances. Thus,
we recommend that approximately half of ICANN's constituent entities be
subject to some form of independent scrutiny every year, and that the
community and the Board should carefully consider any recommendations
for changes arising from those reviews.
With this Report, we will have posted two Interim Implementation Reports,
two earlier status reports, and the recommendations of three Assistance
Groups. All have asked for community feedback, and we have received a
large number of comments, both to the forum
established for this purpose and in various other ways. This feedback
has been essential to our work, as will be obvious from reading this Report,
since many of the recommendations contained in it are the direct result
of comments and suggestions from the community. As was the case in developing
the Blueprint, the implementation work is an iterative process, and each
succeeding document reflects the care and attention that many throughout
the community have given to this subject.
As we reach the conclusion of our work, it is even more critical that
all members of the community make their views known, so that we can take
them into account in producing our "final" recommendations on
or about 1 October. What follows in this Report is a statement of our
current thinking and preliminary conclusions as to what to recommend on
the issues discussed, so to the extent that there are strong reactions,
pro or con, now is the time to present them. It would be unfortunate to
have serious objections or new ideas raised first at the Shanghai meeting,
when it will probably be too late to deal with them effectively. Now is
the time for comments, ideas, reactions, and objections.
1. Mission and Core Values
Attached as an appendix to this Report is a redrafted
statement of ICANN's Mission and Core Values, taking account of
both the suggestions from the GAC referenced
in our First Interim Implementation Report and other comments received.
We have incorporated most of the GAC
editorial suggestions, and have dealt with the extent to which ICANN's
mission includes policy development as outlined in our First Interim
Implementation Report. Having properly formulated statements of mission
(defining ICANN's scope) and core values (guiding how activities within
the mission should be exercised) is a very important element of ICANN
reform; we continue to seek comments and suggestions for improving this
2. ICANN Structure
describes a 15-member Board of Directors (with five non-voting liaisons),
three Supporting Organizations, and four Advisory Committees. The Board
instructed the ERC to examine the feasibility of creating an At
Large Advisory Committee as a possible fifth Advisory Committee. The
an Assistance Group to evaluate that possibility, made up of members
of the community who had been active in the various At Large initiatives
in the past. After considering various comments, and the recommendations
of the Assistance Group, we have decided to recommend the creation
of such an At Large Advisory Committee, thus increasing the number of
Advisory Committees to five.
In addition, the Blueprint calls for a Nominating Committee, charged
with selecting eight members of the ICANN Board and certain members
of other ICANN bodies. We set forth our tentative conclusions on the
implementation details of each of these elements below.
A. The Board of Directors.
1. Voting Members. We have considered various
comments and suggestions relating to the size and composition of the
Board, and concluded that the Blueprint recommendation for a Board
consisting of 15 voting members remains sound. The goal here was to
balance the various interests in the community, while creating conditions
that maximize the ability to attract high-quality persons to serve
on the ICANN Board and reducing the Board size to enhance effectiveness.
We believe that the selection of a majority of Board members by a
broadly representative Nominating Committee, with the remainder of
the Board (other than the President) selected by the ICANN policy
development bodies, best meets these goals. Issues of geographical
and functional diversity, critical to an effective ICANN Board, are
better dealt with through the Nominating Committee process, rather
than by expanding the number of Board seats selected by the Supporting
2. Non-Voting Liaisons. The Blueprint proposed
five non-voting liaisons to the Board one from each of
the four current or proposed Advisory Committees (the SAC, the GAC,
the RSSAC and the TAC) and one from the IETF/IAB. As indicated above,
we recommend that an At Large Advisory Committee be created; if that
recommendation is accepted, we believe that it, like the other ICANN
Advisory Committees, should also provide a non-voting liaison to the
Board. This would increase the number of non-voting liaisons on the
Board to six, and the total size of the Board, including non-voting
liaisons, to 21.
The Blueprint also calls for the non-voting liaisons, like voting
Board members, to serve three-year terms. On reflection, we believe
it would be more appropriate for those bodies selecting non-voting
liaisons to the Board to select them on an annual basis, subject to
reappointment. This will provide those bodies with added flexibility
in allocating the responsibilities of their various members.
B. Nominating Committee.
1. Sources of Nominating Committee Members.
The Blueprint called for a Nominating Committee (NomCom) of 19 delegates,
a non-voting Chair appointed by the Board, and two non-voting liaisons
one each from the RSSAC and the SAC. It sought to create a broadly
representative committee with a workable balance of delegates from
the provider, user, technical, and public interest communities.
The Blueprint set out the following recommended composition of the
- gTLD registries (1)
- gTLD registrars (1)
- ccTLD registries (1)
- Address registries (1)
- Internet service providers (1)
- Large business users (1)
- Small business users (1)
- IP organizations (1)
- Academic and other public entities (1)
- Consumer and civil society group[s (1)
- Individual domain name holders (1)
- IAB/IETF (1)
- TAC (1)
- GAC (1)
- Unaffiliated public interest persons (4)
After further consideration, we suggest certain modifications to
the Blueprint list, as described in the following text.
With some exceptions, delegates to the NomCom will be named by various
ICANN constituencies, as detailed in the Blueprint and amplified here.
There are three reasons for this: (1) to ensure that there are
NomCom members familiar with the concerns of particular constituencies;
(2) to ensure that the individual voices of the different ICANN
constituencies are heard in the NomCom; and (3) to ensure that
the widest possible net will be cast across and beyond the ICANN community
to identify the best possible candidates for the various positions
to be filled.
A number of the NomCom delegates identified in the Blueprint may
be logically drawn from existing entities. For example, the gTLD registries
and registrars are identifiable groups, with pre-existing representative
bodies (the respective Constituencies of the GNSO). Thus, these positions
on the NomCom can be filled from each of those respective Constituencies.
Other delegates can also be named by pre-existing entities; these
include the address registries (via the ASO Council), Internet service
providers (the ISP Constituency), intellectual property interests
(the IP Constituency), the IAB/IETF, and the GAC, as well as the non-voting
liaisons to the NomCom from the RSSAC and the SAC.
With respect to the two delegates named by large and small business
users, the Business
Constituency has proposed that, since it consists of both large
and small businesses and business organizations, it could reasonably
be the source of both the large and small business delegates. We note
that there are today no existing "Large" or "Small"
Business Constituencies, just a "Business" Constituency.
While we understand that some steps have been taken to begin organizing
a "Small” Business Constituency, we also note that many
of the business organizations that are members of the Business Constituency
do claim to represent large numbers of both large and small businesses
(both directly and through globally distributed association membership).
Thus, while we encourage all efforts to expand the representation
of businesses globally, we believe that an appropriate and practical
short-term solution is to allow the existing Business Constituency
to select two delegates to the Nominating Committee, one demonstrably
reflecting large business interests and perspectives and the other
those of small businesses. If and when any new constituencies are
recognized by the ICANN Board (which would of course require a showing
that they would adequately represent the interests globally of the
entities they purport to represent), this issue can be revisited.
Since the TAC is intended principally to provide a mechanism for
identifying resources from the various elements of the Internet technical
community (see the discussion below), each TAC member body should
select the TAC delegate to the NomCom in turn, so that the responsibility
for selecting the delegate rotates among the TAC member bodies in
the same way in which we propose that the selection of the TAC liaison
to the Board rotate among the TAC member bodies (see
Detailed discussion of how the ccNSO (see discussion below on this
name) delegate is selected should probably await the further efforts
of the Assistance Group we intend to create on the subject of structuring
the proposed Country-Code Names Supporting Organization. In general,
however, the ccNSO delegate to the NomCom should be drawn from the
community of ccTLD managers who participate in ICANN.
With respect to the two delegates from academic and other public entities
and consumer and civil society groups, there is an existing Non-Commercial
Domain Name Holders constituency that was originally established to
map approximately to these categories. Some organizations of both
groupings are at present affiliated with the existing Non-Commercial
Domain Name Holders Constituency of the DNSO, but we note that very
few academic entities are represented officially in the constituency.
Given the composition of NCDNHC's active membership, we feel comfortable
looking to that constituency for the consumer and civil society delegate
to the NomCom, but we are somewhat reluctant to turn to it as a permanent
(or even temporary) source of the academic and other public entities
delegate. On the other hand, we are aware of no new constituency organization
underway in this area. Thus, we solicit suggestions as to how to initially
fill the NomCom delegate position for academic and other public entities.
There is currently no obvious organized, globally recognized source
for the four "unaffiliated public interest persons" in the
Blueprint list. If our recommendation to establish an At Large Advisory
Committee is accepted by the Board, and that advisory committee matures
as expected, we believe that eventually it would be appropriate for
the ALAC to select five delegates to the NomCom (one from each ICANN
region, appointed by the regional councils envisaged in the ALAC proposal).
This would ensure the NomCom has the benefit of geographically diverse
perspectives drawn from the ALAC, and thereby promote the geographical
diversity that is an important objective of ICANN. Under these circumstances,
the five ALAC delegate positions could replace the four unaffiliated
public interest persons and the individual domain name holder delegate
positions included in the Blueprint list (since there is at present
no existing individual domain name holder constituency; if and when
such is recognized, this could be re-evaluated). We also recognize,
however, that there is a considerable distance between drafting on
paper and becoming truly functional, and it is unrealistic to expect
an ALAC, even if launched in Shanghai, to become immediately effective.
Thus, we invite the ALAC Assistance Group or other members of the
community to propose how some or all of these delegates could be selected
until such time as the ALAC is operational and has shown that it can
If these recommendations were accepted, the NomCom would be composed
of 18 voting delegates selected by the following groups:
- gTLD registries (1) (selected by the gTLD Constituency)
- gTLD registrars (1) (selected by the gTLD Registrar Constituency)
- ccTLD registries (1) (to be determined)
- Address registries (1) (selected by the ASO Council)
- Internet service providers (1) (selected by the ISP Constituency)
- Large business users (1) (selected by the Business Constituency)
- Small business users (1) (selected by the Business Constituency)
- IP organizations (1) (selected by the IP Constituency)
- At Large (5) (initial selection to be determined)
- Academic and other public organizations (1) (to be determined)
- Consumer and civil society groups (1) (to be determined)
- IAB/IETF (1) (selected by the IAB/IETF)
- TAC (1) (rotated among the TAC member entities)
- GAC (1) (selected by the GAC)
In addition, we believe that the previous year's NomCom Chair should
also serve as a non-voting member of the NomCom, as one way to provide
continuity to the function.
As described above, the NomCom would have five delegates selected
by groups who provide services of various kinds, 10 delegates (eventually)
selected by various user groups, two delegates selected by technical
bodies, and a delegate selected by governments. In addition, there
would be a non-voting Chair, last year's Chair, and two non-voting
liaisons, with the latter selected by technical bodies. So the final
mix of delegates, voting and non-voting, would be five from providers,
10 from users, four from the technical community, one from governments,
and the Chair and previous year's Chair (selected by the Board). We
are studying additional mechanisms to ensure and perfect the geographic
diversity that has already been a highly successful element of ICANN;
at a minimum, each delegate from a constituency or similar group should
be succeeded by a delegate from a different region.
We welcome comments on these modifications to the Blueprint.
2. Criteria for Selecting NomCom Delegates.
We believe that the Nominating Committee is one of the most important
parts of a reformed ICANN. It must function effectively, or ICANN
itself will not function effectively. Thus, while selections for NomCom
delegates should be left in the hands of appropriately representative
bodies, we feel strongly that all NomCom delegates should meet the
a. A NomCom delegate should be an accomplished person of integrity
and intelligence, with a reputation for sound judgment and an open
b. A NomCom delegate should be a person with wide contacts, broad
experience in the Internet community, and a commitment to the success
c. A NomCom delegate should be a person whom the selecting body
trusts to consult widely and accept input in doing his/her work
on the NomCom.
d. A NomCom delegate should be neutral and objective, without
any fixed personal commitments to particular individuals, organizations,
or commercial objectives.
e. A NomCom delegate should be a volunteer, and not be compensated
for service on the NomCom.
f. A NomCom delegate should have experience and be competent with
collegial large-group decision-making.
g. A NomCom delegate should be able to work and communicate in
written and spoken English. The ability to communicate in other
languages is highly desirable, and it is expected that all NomCom
delegates will tolerate and respect the fact that English will be
a second language for most delegates.
h. A NomCom delegate must have the ability and capacity to communicate
and network effectively and broadly (i.e., must have access to functioning
communication channels including telephone, e-mail, and web access,
particularly during the periods of intense NomCom activity).
We specifically did not list familiarity with ICANN, or with the
DNS, IP addressing, or Internet protocols. While many delegates may
have some or all of these attributes, we do not believe that they
are essential to carrying out NomCom responsibilities. Nor do we believe
that those with employment relationships with entities that could
be affected by ICANN should be disqualified from service on the NomCom.
This is not a policy-making body; to be broadly representative and
effective in locating the most suitable people to fill the positions
for which it is responsible, it must be able to access persons from
the entire community. Since particular employment (other than by governments)
is not disqualifying for a seat on the ICANN Board, it should also
not affect the selection of delegates for the NomCom.
3. Criteria for Selection by NomCom. As
set forth in the Blueprint, the NomCom will be responsible for
selecting some members of the ICANN Board, the GNSO Council, the ccNSO
Council, and the TAC. In addition, we recommend later in this Report
that the NomCom also select a portion of the ALAC. Thus, the criteria
for selection may vary to some extent, but there will be considerable
overlap. We set forth below our views on the criteria to be used in
NomCom selection of ICANN Board members, and we invite comments on
specific different or additional criteria that should be used for
other NomCom selections.
Criteria for Board Members. ICANN Board members
selected by the NomCom should be chosen to ensure that the Board
is composed of members that in the aggregate bring diversity in
skills, experience, and perspective to the Board. They should meet
all the relevant criteria set forth above for NomCom members, and
in addition the following standards:
a. Commitment to the success of ICANN in carrying out its
mission. Service on the ICANN Board is time-consuming, requires
the willingness to absorb large amounts of information which may
be technical, legal, or otherwise extremely specialized and marginal
to an individual Board member's field, and can involve making
difficult choices among competing positions, each of which may
have merit. Service inevitably invites attention, some of it critical,
and always carries with it the significant responsibility for
oversight of a small but essential element of the Internet. The
responsibilities of an ICANN Board member cannot be carried out
effectively without a personal commitment to the ICANN mission.
b. Broad functional diversity in the areas of expertise relevant
to ICANN's mission. This means that the NomCom should make
selections that ensure that the ICANN Board has some members with
personal familiarity with the operation of gTLD registries and
registrars; with ccTLD registries; with IP address registries;
with Internet technical standards and protocols, especially those
defining the Internet's naming and addressing systems; with policy-development
procedures, legal traditions, and the public interest; and with
the broad range of business, individual, academic and non-commercial
users of the Internet.
c. Global geographic and cultural diversity. The NomCom
should should seek the broadest cultural and geographic diversity
on the Board consistent with meeting other criteria. At a minimum,
the NomCom should make selections that ensure that the ICANN Board
has at least one member from each of ICANN's geographic regions,
and that no more than half of its voting members are from any
d. Understanding of ICANN's mission and its impact. The
NomCom should ensure that the ICANN Board members it selects appreciate
the limited but important scope of ICANN's mission, and are able
to understand the implications and impact of ICANN decisions on
the broad global Internet community.
e. Ability to contribute to the credibility of the ICANN
Board. The ICANN Board makes decisions that can have widely
varying impacts on various constituencies. These impacts may be
positive, or in some circumstances could impose additional burdens.
It is critical that ICANN Board members be perceived as persons
of integrity, objectivity, intelligence, and demonstrated capacity
for thoughtful group decision-making, which should ultimately
result in credibility in carrying out their volunteer responsibilities
on behalf of the Internet community.
We invite comments on these selection criteria, and how they should
be modified to apply to selections for other than the ICANN Board.
In addition, we invite comments as to whether and how these criteria
should be applied to Board selections by Supporting Organizations.
Our general view is that they should largely apply to those selections
4. Timeline. We include in an appendix
timeline for the NomCom process. We invite comments on this.
C. Supporting Organizations.
The Blueprint recommended three SOs Generic Names, Country
Names, and Address. We continue to believe this is the correct configuration.
Each of the Supporting Organizations should be supported by an ICANN
staff person whose primary responsibility is to support the SO's activities,
under the direction of the SO Council.
1. Generic Names Supporting Organization.
a. Composition of Council. The Blueprint
calls for a Council initially composed of six voting constituencies,
equally divided between provider constituencies and user constituencies.
Each was to select two voting members to the Council. We believed
that this balance was important to create the maximum incentives
for the creation of a consensus position. Without such balance,
the majority side of an issue has the perverse incentive to not
seek consensus; with such balance, and especially with the addition
of three voting members of the Council selected by the NomCom to
serve as the neutral tiebreakers, the incentives for compromise
and consensus are considerably improved.
On further reflection, and after carefully considering feedback
from the community, we believe that the proper balance to be sought
on the GNSO Council is not so much between providers and users,
but between those who are under contract to ICANN and those who
are not. The former are the entities that will be compelled to implement
the policies developed by ICANN, and who could be required to change,
possibly substantially, their business operations because of decisions
by ICANN. The GNSO is the policy-making body that originates policy
recommendations ultimately acted on by the ICANN Board. Thus, applying
the concept in the Blueprint calling for appropriate balance, we
believe that the representatives of entities under contract to ICANN
should have voting power on the GNSO Council equal to the representatives
of entities that are not under contract to ICANN.
As we noted in the Blueprint, it is a challenge to develop a scheme
for maintaining this balance, particularly one that allows for the
possible addition of new constituencies (all or most of which would
be likely to fall on the non-contract side of the balance). We believe
that the best way to accomplish this balance is for the aggregate
number of votes allocated to those constituencies representing entities
under contract with ICANN to be equal to the aggregate number of
votes allocated to constituencies associated with entities that
are not under contract, and to remain so regardless of future changes
in the number of constituencies. Today, this would mean that the
gTLD registrar and registry constituencies would be allocated the
same number of votes in aggregate as the four other constituencies
collectively (Business, IP, ISP, NCDNHC). Initially, this could
be accomplished by allocating 2 votes to each of the gTLD registry
and registrar representatives, and 1 vote to each of the representatives
of the other four constituencies, but these precise numbers could
change as constituencies are added in the future. NomCom selected
members would continue to have one vote, and thus be able to break
Moving now to the size of the Council, we have noted and carefully
considered the resolution
adopted by the current DNSO Names Council calling for reconsideration
of the Blueprint recommendation that the GNSO Council consist of
two members from each constituency and three members selected by
the Nominating Committee. The Names Council unanimously recommended
that there be three representatives from each constituency on the
Council, arguing that this is necessary to share workload and to
increase geographical diversity. The ERC has carefully considered
this issue, and while noting and giving weight to the arguments
in support of three members per constituency, continues to believe
that the desirability of a smaller and more effective Council outweighs
these arguments. Nevertheless, given the unanimous support on the
existing Names Council for this adjustment from what was proposed
by the ERC in the Blueprint, we are considering recommending to
the Board a change in the Blueprint from two representatives per
constituency to three representatives per constituency, at least
for the first year. This approach would allow for a more orderly
transition. (At the end of the first year, this and other aspects
of the GNSO should be reviewed; absent compelling evidence to the
contrary at that time, our view is that the number of representatives
should be reduced to two per constituency.) Each constituency representative
must come from a different region, regardless of whether there are
two or three.
If this transition recommendation is followed, the GNSO Council
would temporarily increase in size from 15 members (under the Blueprint)
to 21 members. We doubt that this increase in size will be conducive
to increased efficiency or effectiveness, and the possible addition
of new constituencies would create an even more unwieldy size, but
we understand and accept the desire for a workable transition model.
We invite comments from the community on the issues discussed above.
b. General Assembly. The Blueprint
states that the "GNSO General Assembly should be a cross-constituency
meeting place . . . ." It also notes that
the GNSO GA exists for the "exchange of information and ideas,
the discussion of particular issues, and as a resource for the creation
under the direction of the GNSO Council of working groups,
drafting committees and task forces." The Blueprint calls for
the GA to support only moderated electronic discussion lists and
forums in which all interested individuals and groups can participate,
and to be chaired by a member of the GNSO Council appointed by that
The ERC has given further consideration to this issue, taking into
account various comments and suggestions received and certain other
decisions subsequently made, such as the recommendation to create
an At Large Advisory Committee. We found particularly useful the
made by Thomas Roessler and Alexander Svensson, who productively
condense many of the discussions of the present General Assembly.
While we do not agree with all their suggestions, they were thoughtful
and offered with supporting explanations, which is a particularly
Our current thinking, on which we invite comments, is that the
existence of an effectively functioning ALAC might eventually eliminate
or significantly reduce the need for and utility of a General Assembly.
In our view, an effective ALAC would operate properly moderated
mailing lists and the like, thus allowing wide-ranging public discussion
of ICANN-related issues. Given this, there may be no need for a
separate General Assembly. We do take note of the long-standing
discussion on the overlap or competing functions of a General Assembly
concentrated on domain-name policy and an ALAC with a possibly wider
range of concerns, which has been reactivated in the reform process,
and we invite comments on this conclusion.
Since it will be some time, even if our recommendation to create
it is accepted by the Board in Shanghai, before it is clear that
the ALAC can in fact carry out this role, our current thinking is
that the GNSO Council should maintain the operation of the current
General Assembly discussion lists until such time as the ALAC has
shown it can take over that responsibility, and at that time the
responsibility for a general public discussion list on ICANN issues
should be transferred to the ALAC. If this approach were followed,
it would be unnecessary that there be such a thing as a General
Assembly Chair. Of course, under this approach, the GNSO Council
should have the power to designate the General Assembly list managers/moderators
for the time it remains responsible for that list, and after that
the ALAC would have this responsibility.
The disadvantage to this approach is that it would eliminate the
General Assembly as a potential vehicle for cross-constituency dialogue.
While we still believe this vehicle would be useful, that suggestion
does not appear to have been enthusiastically received by GNSO participants,
whose active participation is necessary to its success.
We agree with Roessler and Svensson that more participation by
GNSO constituency members on whatever discussion lists are provided
would be desirable, but we note that such participation is made
less likely to the extent that the list moderation rules permit
non-substantive or abusive postings. Therefore, we reiterate our
recommendation that the General Assembly list, as with any discussion
lists supported by the GNSO or ALAC, should be moderated to prevent
non-substantive, abusive and off-subject postings. We recognize
the potential burden that such moderation would impose, and suggest
that the GNSO Council, as a first order of business, adopt practical
moderation rules that adequately protect the usefulness of the GA
list so long as it is the responsibility of the GNSO. In this respect,
we find the suggestions of Roessler and Svensson particularly useful.
We invite comments on this discussion, especially from the GNSO
constituencies on which this suggestion would have the most impact.
c. Generic Names Policy Development Process.
We greatly appreciate the hard work of the Assistance Group on this
subject, chaired by Rita Rodin. We have reviewed their
recommendations, and we encourage further public comment on
them. In general, we find the recommendations cogent and persuasive,
and with some modifications are inclined to recommend their acceptance
by the Board as part of the implementation process. We offer the
following initial specific comments:
1. We accept the general timeline of 95 days from the initiation
of a policy development process (PDP) to a recommendation to the
Board. We recognize that this remains an aggressive schedule for
an organization that depends on volunteers for most of its work,
and appreciate that this schedule can only be met if those volunteers
have adequate staff support. We also recognize that this timing
may not be consistent in all cases with the desirability of seeking
advice from outside expert panels or bodies. Nevertheless, we
think there is great value in having a standard process and timeline,
even if occasional exceptions are required, and we believe that
the general process and timeline set forth by the Assistance Group
is appropriate and workable. The review of the GNSO and its processes
that is contemplated one year after it begins operations will
be a good opportunity to assess the effectiveness of both the
recommended process and the timelines.
2. We agree that there must be a clear understanding of which
issues are truly policy issues and which are not, and of whether
the Board is asking the GNSO or other SOs for policy recommendations
or simply for advice. The principles set forth in the Blueprint
were an initial effort to deal with the former, and we were pleased
to see their incorporation in the PDP. We believe the modification
suggested therein is appropriate, and we agree with the inclusion
in the process of an opportunity for receiving a formal opinion
from the General Counsel on this issue prior to the initiation
of a PDP.
3. Those portions of the Assistance Group recommendations relating
to the timing and constraints on the Board's action require further
consideration before we are prepared to state our views on them.
We appreciate that the Assistance Group provided cogent suggestions,
and while Committee members are persuaded by many of the Assistance
Group's arguments, some implications are still under discussion,
and require further community input as well. We do generally agree
that a consensus policy recommendation (described by the Assistance
Group as one that receives a "supermajority" vote of
the GNSO Council) should carry greater weight with the Board than
a recommendation that does not reflect as broad a consensus, but
how that should affect the ability of the Board to act is still
under consideration. We invite comments from the community on
4. We find the suggestion of a status web page detailing the
progress and current status of each PDP a good one, and we intend
to recommend such be created.
Again, we thank the Group for its very considerable efforts, and
we strongly encourage community feedback on the recommendations
and these comments. We would anticipate including in our "final"
recommendations specific suggestions on the policy development process,
drawn heavily from these recommendations, but we would certainly
be interested in additional community comment prior to that time.
2. Country-Code Names Supporting Organization
We are persuaded by community feedback that using the word "Country"
is inaccurate and misleading. While the term "country code"
is equally incorrect technically, community familiarity and its
well-established meaning make it an acceptable substitute. "Geographic"
would probably be preferable, but that would result in acronym confusion
with the Generic Names SO.
The ERC has engaged in several discussions with individual ccTLD
managers and with groups of ccTLD managers and others on the general
subject of a ccNSO. In those discussions, we have announced our
intention to create an Assistance Group in the very near future
to make recommendations relating to the ccNSO, including its membership,
scope, and internal organization. We encourage input from the community
on the appropriate implementation of the ccNSO to that Assistance
Group once established.
3. Address Supporting Organization.
The Blueprint calls for no changes to the current ASO structure
except for the addition of a GAC liaison to the Address Council,
consistent with the approach throughout the organization. We have
no additional comments to make at this time.
D. Advisory Committees.
The Blueprint called for four advisory committees. We presently intend
to recommend that there be a total of five the four identified
in the Blueprint and an At Large Advisory Committee. Each AC that
requests it should be supported by ICANN staff, working under the
direction of the AC Chair. In addition to the positions taken in the
Blueprint, we currently contemplate making the following recommendations
to the ICANN Board:
1. Governmental Advisory Committee.
The GAC should appoint a non-voting liaison to the ICANN Board.
In addition, the GAC should have the right to appoint a non-voting
liaison to SO Councils or Advisory Committees, to the extent that
it believes such is both appropriate and useful.
2. Technical Advisory Committee.
The Technical Advisory Committee is intended to channel technical
advice and guidance to the Board and to other organizations within
ICANN. It will serve ICANN in two different but equally important
roles: (1) as an entry point to a broad range of technical
communities with expertise relevant to ICANN's mission, so that
specific technical questions that arise in the course of ICANN's
work can be referred to the people and/or organizations best qualified
to answer them; and (2) as an active "watchdog" ensuring
that technical issues that might otherwise be overlooked are brought
to the attention of decision makers.
Reporting directly to the Board, the TAC should be chartered to
undertake the following tasks:
- To connect the Board with appropriate sources of technical advice
on specific matters of interest to the Board.
- To communicate on technical matters with a broad range of persons
and organizations, including (1) the operators and managers
of Internet naming and address allocation infrastructure services;
(2) companies and individuals who implement the Internet
naming and addressing standards; and (3) those bodies with
direct responsibility for Internet naming and address allocation
matters (including, in addition to the organizations represented
on the TAC itself, the RIRs, name registries, registrars, etc).
The TAC is expected to advise the Board of the relevance and progress
of technical activities in any of these quarters that could affect
Board decisions or other ICANN actions, and to draw attention
to global technical standards issues that affect policy development
within the scope of ICANN's mission.
- To report periodically to the Board on its activities.
The TAC is not chartered to provide policy advice to the Board,
although organizations participating in the TAC may individually
be asked by the Board to do so as the need arises in areas relevant
to their individual charters. Neither is it intended to debate or
otherwise coordinate technical issues across its participating organizations
or to establish unified positions and thus it does not impose on
them an additional, unnecessary layer of coordination for the development
of technical standards. The TAC has no involvement, advisory or
otherwise, with the IANA's work for the IAB/IETF/IRTF.
In order to fulfill this charter, the TAC should:
- consist of individuals with direct experience with technical
standards issues relating to ICANN's activities;
- consist initially of 10 members selected by the ICANN Board
based on nominations from ETSI, ITU-T, W3C, IETF, and IAB (two
nominations from each organization), and three other persons with
a strong technical background selected through the NomCom process,
resulting in a total initial membership of 13;
- select its own chair for a one-year non-renewable term;
- appoint one non-voting liaison member to the ICANN Board, selected
by each of the organizations represented on the TAC in turn on
a rotating basis, for a one-year term; and
- appoint one delegate to the Nominating Committee, selected by
each of the organizations represented on the TAC in turn on a
rotating basis, for a one-year term.
The mechanism whereby the responsibility for selecting a NomCom
delegate and a liaison to the Board rotates among the TAC member
organizations should ensure that in any given year the selections
are performed by different organizations.
Following the general procedure for all ICANN constituent entities,
the Board will review the charter, structure, and operation of the
TAC after one year of operation and every two years thereafter.
3. Security Advisory Committee.
The Security Advisory Committee should continued as a Board Advisory
Committee, with its current charter modified to allow for a GAC
liaison, and should appoint a non-voting liaison to both the ICANN
Board and the Nominating Committee.
4. Root Server System Advisory Committee.
The RSSAC should continue as a Board Committee, with its current
charter modified to allow for a GAC liaison, and should appoint
a non-voting liaison to both the ICANN Board and the Nominating
5. At Large Advisory Committee.
We appreciate the hard work of the Assistance Group on this subject,
led by Denise Michel and Esther Dyson. We welcome their
recommendations, and we encourage broad public comment on them.
The following are some initial specific comments on the Assistance
1. We agree with the Assistance Group that the "establishment
of an ALAC should be viewed as a critical first step towards structured
involvement of the individual user community in ICANN and, in
particular, towards a formalized role in ICANN's policy development
process that ensures [individual] users' views are taken into
account." This has always been a goal of the ICANN effort,
and it remains one of the unfinished pieces of organizational
business for ICANN. We recommend the creation of an ALAC as the
most effective way to begin this process.
2. We note that the ALAC proposed by the Assistance Group is
a somewhat complicated but we believe achievable
undertaking. While we appreciate that some of the
initial organizational work has already been done, there is a
very long way to go from the presently available narrative and
a diagram to a truly workable structure that can provide meaningful
and informed input to the ICANN process. Thus, we believe that
we should proceed with small steps rather than giant leaps, all
the while with the understanding that what we begin with today
will likely evolve into the finished product. Just as we have
seen with the Supporting Organizations, which in the reformed
ICANN will look (and perform) very differently from the original
versions, the ALAC we start with will likely mature into a different
structure. For that progress to be steady and positive, we should
begin with manageable steps.
3. For these reasons, we will likely recommend that the initial
ALAC be appointed by the Board, and that the members of the ALAC
Assistance Group be included in those initial appointments. We
are not as sanguine as the Assistance Group that this complicated
structure can be functional immediately, and yet we do agree that
there must be a focus for immediate and continued progress. Given
the significant efforts to date by the Assistance Group, their
appointment to an Interim ALAC seems suitable and appropriate.
It may also be appropriate for the Board to augment that group
with additional appointments, with an eye toward encouraging continued
progress toward a stable permanent structure. We are open to other
suggestions as to how to populate the initial ALAC without imposing
cumbersome and time-consuming processes.
4. We will likely recommend that the ALAC appoint a liaison
to the Board. Like other liaisons appointed by ICANN Advisory
Committees, the ALAC liaison should initially be non-voting. By
this, we do not mean to dismiss forever the possibility that the
ALAC (or some other appropriate At Large entity) could eventually
select voting members of the ICANN Board. As the ALAC matures,
or if and when at-large elections become practicable, the appropriate
vehicles for the expression of the views and interests of the
general individual user segment of the community can be reconsidered.
5. As explained earlier, we also accept the recommendation that
the ALAC, once properly organized and functioning, should select
five delegates (one by each ICANN regional council, as proposed
by the Assistance Group) to the Nominating Committee. Until these
regional councils are functional and operative, we invite the
ALAC Assistance Group or other members of the community to propose
how some or all of these delegates could be selected until such
time as the ALAC is operational and has shown that it can function
6. We are not persuaded that the ALAC should appoint liaisons
to the Supporting Organization Councils or other Advisory Committees,
at least at this time. We do not see the need or desirability
for this added complication to the ICANN structure, nor is it
consistent with the progressive build-up approach that we believe
the evolution of the ALAC should follow. This can be reconsidered
in the future.
7. We believe that the most critical step in creating a functioning
and effective ALAC is establishing the criteria to be applied
in admitting members to the ALAC, and in the processes for selecting
members of the ALAC itself. We endorse the notion of local, self-supporting
structures, and we remain interested in seeing how this notion
will be implemented. We would also welcome additional community
comments on this issue in particular.
8. While we believe we understand the rationale for the bottom-up
structure suggested by the Assistance Group, the Board will no
doubt be interested in seeing how this structure is implemented.
We generally agree with the notion of using a MOU approach to
the certification of the Regional At Large Organizations, and
look forward to suggestions as to what that MOU should contain
from both the members of the Assistance Group and the community
at large. We also agree with the proposal of the Assistance Group
that each Regional At Large Council should appoint two members
of the ALAC, and that the NomCom should name one additional member
from each region. This would result in an ALAC of 15 members,
10 selected by the Regional Councils, and five by the NomCom.
9. We agree that individual at large entities should meet some
"accreditation" standard, and we find the criteria and
standards recommended by the Assistance Group to be an attractive
list. We would be interested in community comments on how that
"accreditation" should be implemented. Our tentative
view is that, at least initially, a group appointed by the ICANN
Board should do any such “accreditation”, but we welcome
other suggestions as well.
10. We are not persuaded that ICANN should reimburse ALAC members'
travel costs to ICANN meetings. We appreciate that funding is
an issue for all individuals and organizations, but do not believe
that it would be appropriate to fund travel costs for one set
of Advisory Committee members and not for the participants in
other ACs and SOs. We do agree that the ALAC should have sufficient
ICANN staff support to effectively carry out its operations, and
will so recommend.
In this context, we intend to recommend that the reformed ICANN
generally set for itself the goal to depend less critically on face-to-face
interactions in physical meetings, and make it progressively easier
and more effective for individuals to participate at a distance
with no significant disadvantage.
We encourage community comment on this discussion, and on the entire
set of Assistance Group recommendations generally.
3. Public Input and Accountability.
One of the continuing issues for ICANN since its creation has been
the establishment of procedures and structures to ensure both broad
public input and appropriate methods of review of ICANN actions. The
At Large Advisory Committee described above will offer a significant
opportunity for informed public input into the ICANN decision-making
and policy development processes. The ERC asked Becky Burr, who was
present at the creation of ICANN in her former governmental capacity
and has continued to stay involved since returning to the private sector,
to provide recommendations about four other aspects of a reformed ICANN
recommended by the Blueprint: an Ombudsman; a staff position dedicated
to ensuring that information about ICANN's activities, and public reaction
to those activities, is fully adequate and available to the ICANN Board
and constituent entities in a timely manner; a reformed Reconsideration
Process; and an Independent Review process.
Ms. Burr has provided her
recommendations, and we thank her for the significant effort involved.
We find her recommendations helpful and generally persuasive. We strongly
encourage comment and reaction from the community, so we may take that
into account in producing our "final" recommendations. In
the meantime, we offer the following initial comments on Ms. Burr's
1. In general, we agree with the proposed charter for the Office
of Ombudsman. We believe that the Office should be funded through
the normal ICANN budget process, subject to community comment, and
the Office budget ultimately approved by the Board. In order to ensure
the neutrality of the Office, the Office should prepare its own budget
request separate from that of the ICANN CEO, but both should go through
the same community and Board scrutiny. We agree with an initial term
of two years, with the possibility of a longer tenure after some experience
with this concept; we agree that adequate job security is part of
the perception of neutrality that is required for this concept to
We solicit community comments on the Charter, the list of proposed
duties and other aspects of the Ombudsman concept.
2. In general, we also agree with the recommendations relating to
the Manager of Public Participation (this is just a working title).
This person should be responsible for working with the Board, other
staff, and the ICANN constituent bodies to help facilitate informed
public comment on ICANN activities, and to ensure that comment is
understood and available for consideration by the Board and other
ICANN bodies. Obviously, this position must coordinate carefully with
the staff assigned to support particular ICANN entities, such as the
SOs and the ACs, and particularly with the ALAC if created. (We note
the comment concerning the need for proper integration of the roles
of the Manager of Public Participation and the Staff Manager proposed
for the GNSO PDP, and will give attention to this issue.) To the extent
practical, information about the current status of ICANN activities
should be electronically available on as close to a real-time basis
3. The recommendations concerning the Reconsideration Policy seem
quite sound. At the present time, our intention would be to follow
these recommendations almost totally. The one exception might be the
notion that the Reconsideration Committee should report to the Board
on a quarterly basis; we agree that a periodic report of the kind
suggested would be useful, but our current view is that an annual
report would be sufficient.
4. The issues surrounding the Independent Review Process are difficult.
In general, we find the recommendations useful. Until we can have
more detailed discussions with possible providers of arbitration services,
we must withhold final judgments on certain of the procedural recommendations
5. With respect to the "Additional Recommendations and Observations,"
we welcome them and will give them serious consideration. We agree
it is likely that, as the reformed ICANN further matures, certain
additional mechanisms may be appropriate and useful in this area,
and we welcome community comment on these suggestions. We note that,
while a variety of concerns have been expressed over time about possible
"mission creep," and it is true that bylaws are not immutable
and thus do not perfectly prevent the possibility of such "mission
creep," we have yet to discover and no one has yet suggested
an approach that could create more certainty (without eliminating
necessary flexibility) than stating ICANN's mission (see Section
1 above) in the ICANN bylaws. We welcome any such suggestions.
We also welcome specific suggestions to deal with the other issues
raised in this section of Ms. Burr's report, although we believe
these issues are likely beyond the scope of the current reform process.
It is quite clear from a reading of the above that, if all these recommendations
are accepted, additional staff will be needed. There is a paradox here:
everyone wants a "lean and mean" ICANN, but everyone wants
the part of ICANN over which he or she is most concerned to function
effectively and smoothly. Just like the paradox that more and more process
can produce fewer and fewer results, effective functioning in an organization
made up of volunteers requires significant staff support. For policy
development processes to move rapidly and effectively, and with full
appreciation of the relevant considerations, there must be an appropriate
infrastructure able to support and implement both the processes and
the decisions made by the ICANN volunteer participants.
The approved 2002-2003
budget represents an important increase over 2001-2002, allowing
for a modest staff increase from an approved level of 21 (with 17 actually
now on board) to 27. Ramping up to these levels will take time, especially
with the actual process of recruitment competing for attention with
all the many other tasks that ICANN staff must do. This increase, however,
as noted in the Approved Budget document, provides for proper staffing
for today's ICANN "business as usual." It does not provide
for any of the additional positions that will result from the current
reform process, including the Ombudsman, the Manager of Public Participation,
and all the support staff envisioned for the SO Councils, the new Advisory
Committees (the current budget does provide for support staff for the
SAC, but not for the ALAC, the RSSAC, or the TAC), the Policy Development
Process, or the Nominating Committee all of which will
need staff support to be effective. Neither does it provide for any
permanent funding for a GAC Secretariat, although the GAC may provide
this itself. And of course, additional staff positions bring along increased
overhead, demands for administrative support, equipment and communications
support, and travel expenses, all of which would increase further to
the extent that ICANN's operations become ever more internationally
The ERC has not costed all of this out in detail at this point. However,
using conservative estimates of the likely salary, benefits, insurance,
administrative overhead, travel, etc. for the 7-10 additional persons
that seem likely to be required by the current reform efforts, an additional
budget increment over the current budget of between US$1 million and
US$1.3 million provides an approximate estimate of what will be required.
Some of this may be accomplished with external consultants rather than
full-time internal staff, so these estimates are necessarily imprecise.
The final actual numbers would be contingent on a detailed analysis,
and the extent to which various tasks can be combined and performed
by a single individual.
In the 2002-2003
budget, the revenues derived from variable registry/registrar fees
from gTLDs and ccTLDs under contract are budgeted at US$3.872 million.
A useful metric for comparison purposes is to divide this number by
the total number of domain names assumed by the budget; this produces
a figure of 12.69 cents per domain name for this portion of the budget.
An increase of the higher estimate of US$1.3 million would increase
this metric by about one-third, or by 4.23 cents, to a total of 16.92
cents per domain name. This calculation excludes the possible effects
of (a) any increase in voluntary funding from ccTLDs, (b) new
ccTLDs coming under contract, or (c) the addition of new gTLDs.
Neither does it consider the effect on per domain name costs of overall
growth in domain name registrations, which would have the effect of
lowering the per domain name cost.
These figures lie within the current scope of ICANN's existing agreements
with registries and registrars, but pursuant to those agreements, could
require budget approval each year by registrars that in the aggregate
represent two-thirds of total gTLD domain names. This estimate also
does not provide for any increase in reserves, the lack of which represents
a substantial exposure for ICANN under the circumstances. Steady building
of reserves could add funding requirements that could amount to as much
as another 3 to 4 cents per domain name, using this same metric.
This analysis, while still approximate, does provide a general perspective
on the budgetary implications of the current reform efforts. We invite
comments on this analysis.
To actually implement these various reforms will require what will
essentially be a rewriting of ICANN's bylaws. We intend to include in
our "final" recommendations a proposed new set of ICANN bylaws
reflecting our recommendations, and are now considering how to accomplish
that within the relevant timeframe and existing resources.
Assuming that the ICANN Board adopts a final reform plan at its meeting
in Shanghai, there will necessarily be a transition from the current
structure. We offer the following initial thoughts on that transition
process. We welcome comments and suggestions, especially on the practical
aspects of the transition.
1. The most critical element of the transition will be the effective
implementation of a mechanism that adequately funds staff support for
the various SOs and ACs. The following assumes that can be accomplished
shortly after the Shanghai meeting. Once that is done, the process of
hiring the necessary staff will begin; the goal should be to have as
many of the new staff hired as possible by the time of the March 2003
2. There will necessarily be a period of time before the newly constituted
ICANN Board can be seated. Assuming final action on reform by the Board
in Shanghai in late October, it seems entirely possible that selection
of the new ICANN Board could take a period of months. Some bodies (like
the ASO and the GNSO) will undoubtedly be able to function quickly and
select persons to the Board seats for which they are responsible, but
other selections (such as those from the Nominating Committee) are likely
to take longer to accomplish. The next public Board meeting following
Shanghai will likely be in March of 2003, or some four months after
Shanghai. It seems reasonable to assume that a newly constituted ICANN
Board could be ready to be seated by that time, and thus a transition
structure is (hopefully) necessary only until that time. Nonetheless,
any transition structure should be durable enough to last longer if
The current ICANN Board consists of 18 persons selected by various
constituencies, and the CEO ex officio. Of the 18, nine are designated
"At Large" directors, and the terms of those directors expire
at the end of the annual meeting in 2002. While the date of the official
annual meeting has not yet been set, the terms of those directors will
clearly expire prior to the March meeting in 2003. This leaves nine
directors three each selected by the DNSO, the ASO, and
the PSO. There is currently one vacancy from that group (the seat formerly
held by Phil Davidson, selected by the PSO). In addition, the ASO has
selected a new director for a term to begin at the end of this year's
annual meeting (Mouhamet Diop), and the DNSO is currently in the process
of selecting a person for the expiring seat of Alejandro Pisanty, also
for a term to begin at the end of this year's annual meeting. Thus,
as it currently stands, there will be eight (or nine, if the PSO should
hold elections to fill its vacant seat) ICANN directors whose terms
would, absent reform, run at least through 2003.
While there is any number of possible transition mechanisms, we believe
that the principal objective should be continuing stability during this
transition. To that end, we plan to recommend to the ICANN Board that
those members of the current Board whose terms would ordinarily continue
through next year should remain on the Board until the end of the March
meeting in 2003 (or longer, if that should prove necessary to select
the reformed Board). At that time, unless they have been selected to
the reformed ICANN Board by one of the selecting bodies, they would
retire from the ICANN Board. In addition, we plan to recommend that
the Board select six (or five, if the PSO has by then selected a third
director) of the directors whose terms are due to expire this year to
continue until a reformed ICANN Board is selected, at which time they
too, unless selected to the reformed ICANN Board, would retire. Since
a certain number of current Board members have indicated, publicly and
privately, that they do not intend to continue on the Board once their
term expires, it may be that this selection process could become simple
through the individual decisions of these Board members. Other adjustments
may also be necessary to accomplish a transition Board of the right
size commensurate with the intent of the final reform decisions.
3. Several of the non-voting liaisons to the ICANN Board (from the
GAC, RSSAC, SAC, IAB/IETF) are from existing entities; those entities
should select their liaison as soon as possible following the Shanghai
meeting, but in any event prior to the March 2003 ICANN meeting. The
liaisons from the TAC and the ALAC are discussed below, in connection
with the need to create these new organizations. In addition, those
organizations that provide a delegate to the NomCom should do so as
soon as possible following the Shanghai meeting.
4. The ASO requires no substantive changes. It should be able to function
immediately. Since the ASO will select two members of the ICANN Board
and one delegate to the NomCom, it should do so as promptly as possible
following Board action in Shanghai.
5. The GNSO will initially consist of six existing constituencies,
so it should be able to function promptly after the adoption of new
Bylaws. Since it will select two members of the ICANN Board, it should
do so as promptly as possible following Board action in Shanghai. Other
steps it must take are to designate a manager/moderator of the GA mailing
list for as long as the GNSO is responsible for its operation, and to
implement the PDP as mandated by the new Bylaws. The relevant GNSO constituencies
should select their delegates to the NomCom as soon as possible following
the Shanghai meeting.
6. ccNSO transition details must await further developments.
7. Assuming the Board creates an ALAC, we will recommend the creation
of an Interim ALAC consisting of the members of the ALAC Assistance
Group and such other persons as the Board deems appropriate to encourage
the prompt implementation of the ALAC structure recommended. The Interim
ALAC should designate the ALAC liaison to the ICANN Board until such
time as the final ALAC structure is implemented. The Interim ALAC should
also select the delegates to the NomCom for which it is responsible
as soon as possible following its appointment.
8. The entities that make up the TAC should be able to form the TAC
and select its initial Board liaison and NomCom delegate prior to the
March 2003 meeting of ICANN.
We reiterate again our call for comments and suggestions. The purpose
of these Interim Implementation Reports is to share our tentative conclusions
with the rest of the community, so that we can receive feedback and
take that reaction into effect in reaching our final conclusions. It
should be clear by now that comments and suggestions are carefully considered
and frequently adopted, and we encourage all members of the community
to offer their views. In this Report, we have tried to set forth both
our conclusions and the reasoning behind them, and we urge all members
of the community to offer your reactions, pro or con, and any alternative
Committee on ICANN Evolution and Reform
2 September 2002
Questions concerning the layout, construction and functionality
of this site
should be sent to firstname.lastname@example.org.
©2002 The Internet Corporation for Assigned
Names and Numbers. All rights reserved.