ICANN 04

From ICANNWiki
(Redirected from ICANN 4)
Jump to navigation Jump to search
ICANNLogo.png
Dates: November 1-4, 1999
Location: Los Angeles, California
Venue: Sheraton Gateway Hotel
Website: ICANN 4


ICANN 4 was held in Los Angeles in November 1999.[1] Once again, the Berkman Center for Internet & Society provided remote participation and scribing services during the course of the event.[2]

Ad Hoc Group on Future Numbering Policies

Following up on actions taken at ICANN 3, the board approved the charter for an ad hoc group on future numbering policies.[3] The charter was succinct and grounded in an expectation that the group would not solve all of the issues that it identified:

The ad hoc group should identify the key technology, commercial and economic drivers that will affect addressing and numbering in the Internet. Recognising the risks of specifying modifications to core Internet technologies in a small group that inevitably understands some elements of the picture better than others, the group will identify issues, problems, risks, and opportunities, but is not expected to propose, much less adopt, technical solutions to them. The assessment must include current trends in services and network convergence and globalisation, particularly those emerging from the telecommunications sector, as well as changes in the demands on traditional IP address space. Examples of technology forces to be considered include IMT 2000, 3GPP, and Bluetooth. The group will examine and identify any characteristics of these applications that they believe are so unusual as to challenge the Internet's technical tradition of an application-independent basic architecture for addressing and routing structures. The ad hoc group shall focus on the future demands and impacts these new technologies will have on the administration of IP address space. Particular attention must be given towards global policy formation and the identification of any requirements to Internet addressing in the future. If the ad hoc group identifies areas in which they believe changes to addressing architectures or other technologies should be considered, they should clearly identify the problems that require resolution rather than suggesting technical solutions so that appropriate responses to those requirements can be considered in a broader more open and technically responsive forum.[3]

References