전길남 박사님께서 보내주신 쟁점, 아젠다, 회의 일정입니다.
ICANN Service - Draft Report> >
1. Background>
> In the beginning, the Internet consisted of a small number of linked
> university computers, funded via the US Government, and located in
> different cities, evolving in the US and subsequently spread out
throughout
> the world.. These computers were connected together by means of full time
> long distance telephone lines, also paid for by the US Government. The
> telephone lines carried data, or electronic messages between computers.
> While the original intent was to share expensive computing resources, an
> interesting side effect occurred. Individual users with accounts and
> permissions to use those computers in one location could communicate with
> users in another location, and they could do so without incurring
individual
> long distance communication charges. For example, someone with access in
San
> Francisco could send an electronic mail message to someone in Boston.
Since
> the computers, which were acting as electronic post offices, were already
> linked, or "networked", and those links were paid for, there was zero
> incremental cost to send those messages.>
> Other universities requested access to these new resources, especially the
> ability to send messages to locations outside their servoice area. The new
> universities coming on to the network paid the long distance line charges
> from their physical location to the nearest "Internet connected" computer
> site.>
> Similar activities in other countries resulted in the creation of many
> "in-country networks". One such example is Australia National University.
> The users of these systems manifested a strong desire to extend their free
> or low cost communication to beyond their National borders. Interlinking
the
> various National systems into a coherent International network compelled
> the formation of various technical working groups to deal with the issues.
> Somehow, the focus of the work of these groups managed to remain technical
> and not political.>
> Major issues and problems to solve included interoperability between
> organizations' computers, messaging formats, country codes and computer
> naming conventions, addressing methodology, and the ability to route
> messages over diverse paths.>
> Internet pioneers employed new paradigm of governance to solve these
> problems. Proposed specifications and Requests for Comment(RFCs)
> circulated between persons interested in participating in Internet
> development. Through consensus formation guidelines, specifications, and,
> one might say "laws" came into existance that governed the operation of
> the Internet.>
> Consensus formation is the foundation of Internet Law. Technical changes
and
> improvements across a system that spans, potentially, all countries of the
> world must be driven and adopted by consensus, rather than decree.
> Application of engineering specifications and technical policy needs to be
> uniform and consistent across the entire Internet system to insure
> availability to all users.> > > > 2. The Naming System>
> This document concerns itself with the Naming system.>
> The current Internet naming system is based on a heirarchry of
> "Name Servers".>
> The root server is placed in the top of the hierarchical tree of the
Domain
> Name System (DNS) and contains the information about where to find the
> addresses of the name servers of all the top-level domains (TLDs). This
> includes generic (gTLDs), such as .COM and .NET as well as national
(ccTLDs)
> such as .SE and .VI.>
> Any new TLD that is created in the future must be put into the root before
> it becomes visible on the Internet. Conversely, if any TLD is removed from
> the root server, that TLD and the domain names attached to that TLD would
> become unreachable. There is the very real potential of thousands or even
> millions of organizations "disappearing" from the Internet a failure
> should occur.>
> At the time of this writing, there are 13 so called root severs. Ten (10)
of
> these are situated in different places in the US and the 3 remaining are
in
> countries outside the US.> > 3. Developments in the Last 5 Years:>
> Rapid growth and consumer acceptance of the Internet, combined with
revenue
> driven business opportunities in advertising and e-commerce compels
> formalization of the methods of Internet governance. Increased
> multi-national participation requires that this governance become less
> US-centric. Control of the sub Domain Namespace seemed to be moving out of
> the universities into the hands of diverse individuals, organizations, and
> governments. Nevertheless, control at the top level remained in the hands
of
> the US Department of Commerce (DOC).>
> The US Government, in an attempt to assist in the globalisation of the
> governance of the Internet, directed the US Department of Commerce to
> privatise the system. The relevant document is called The White Paper.
> This led to the creation of the Internet Corporation for Assigned Names
and
> Numbers (ICANN) in 1998. ICANN is the non-profit corporation that was
formed
> to take over responsibility for the IP address space allocation, protocol
> parameter assignment, domain name system management, and root server
system
> management functions now performed under U.S. Government contract by
> Internet Assigned Numbers Authority (IANA) and other entities. A
Memorandum
> Of Understanding Between The U.S. Department Of Commerce And Internet
> Corporation For Assigned Names And Numbers outlines the proposed
transition
> process. The MoU expires on 30 September, 2000.>
> Moving in the same direction, new regional organizations such as Council
of
> European National Top-Level Domain Registries(CENTR) and Asia-Pacific
> Top Level Domain Forum(APTLD) were established to provide coordination
> functions for substantial blocks of countries.>
> During 1998 The Root Server System Advisory Committee (RSSAC) was formed
and
> members are the individuals and organizations running the root servers.
The
> Root Name server Year 2000 Status Document provides a table of root
> server locations.>
> An agreement was signed between the US Department of Commerce (DOC) and
> Network Solutions (NSI) during 1998 about the conditions of the running of
> the gTLDs .COM, .NET and .ORG.>
> One of the conditions was to separate the A-root zone from the gTLD-zones,
> which so far has been performed on the same servers. This work has started
> but is yet not finalised.>
> This concludes the historical perspective and background.> > > >
> 4. Statement of Current Work (April 2000)>
> Specifically, we are now defining the components and issues involved in
the
> transition from an informal (de facto) system operated by trusted
> individuals working on a voluntary, usually unpaid basis, to a formal (de
> jure) system operated by and for corporate organizations, defined by
> contract, with specific deliverables and financial considerations.>
> 4.1 Identification of the parties to the contract.>
> The draft committee takes the position that, until such time as a formal
> mechanism for interposing a third party is in place, there are only two
> parties to this contract. The designated ccTLD administrator, whether an
> individual or an organization, and ICANN are the two parties.>
> The act of developing and signing a contract between the ccTLD
administrator
> and ICANN, in itself, will provide ICANN with the evidence it needs to
show
> legitimacy of "bottom-up", "consensus based" international support, and
> will go a long way towards giving ICANN the independence from the US
> Government that ICANN desires.>
> The ccTLD administrator, in turn, receives the recognition that it is the
> designated manager of the ccTLD at the time of signing of the contract. No
> changes may be made without compliance with procedures that are a part of
> the ccTLD Best Practices Document That document is in the hands of
> another ccTLD working group.>
> There is a non-voting Governmental Advisory Committee (GAC) to ICANN,
which
> has provided a paper in which they state their position on delegation of
> ccTLDs. (See URL or Attachment). The GAC paper talks about a three-party
> agreement between ICANN ? Government ? ccTLD delegee. This paper is of
great
> interest to some countries and those countries may wish to implement it.>
> Whether there can be two types of contracts; that is, a two party contract
> for some ccTLDs and a three party contract for other ccTLDs remains to be
> determined.> >
> 4.2 Specification of Quality of Service (QoS) level and performance
guarantees
> > The concerns over security and stability are growing amongst the
individual
> domain name holders. Revenues from E-commerce are escalating the
importance
> of the uninterruptible operation of the domains. Loss of connectivity for
an
> income-generating domain would be more than unpopular. Lawsuits over
> liability issues, revenue losses, business interruption, damage to
> reputation, and other factors could lead to actual and punitive damages
> assessed against an Internet Service Provider, and/or a ccTLD manager.>
> Loss of connections can be caused by many factors, but the ccTLDs managers
> need to ensure that loss of connection does not result from their actions,
> or on the actions or inactions of the upstream root services providers.>
> The domain name holders will (or maybe are) today negotiating QoS service
> level agreements with the Internet Service Providers (ISPs). The ISPs
can't
> sign a contact without knowing what QoS service level service they will
> obtain from the ccTLDs.
> And to follow the chain the TLDs can't agree on a level without knowing
the
> QoS service level of the root. For those TLDs making agreements direct
with
> the domain name holder the problem is the same except for the part of the
> ISP.> > 4.3 Scenario>
> A ccTLD looses root service and goes down for a period of time. The
> different domain name holders lose income because the customers can't
reach
> them. They expect to get reimbursed and sue the ccTLD. The ccTLD then on
its
> side finds out that the problem was because of a mistake in the root-zone
> and doesn't want to bear the liability cost on something that was not his
> fault. The ccTLDs then sue the root.> > >
> 5. The Agreement between ccTLD and ICANN>
> The agreement between ccTLD and ICANN must contain a section about the
> security and stability of the root.>
> The root is crucial to the Internet Community as without them the system
> will break down and the customers domains will go down. There fore the
TLDs
> need to have insurance about the stability and an agreement on the service
> level. The service level agreement to a domain name holder can’t be
> stronger than its weakest link. Today there is no insurance from the
> root-servers about the service today.>
> The Root Server Consortium has to be formalised is the same way as the
TLDs
> and they must operate in an open process.> > 5.1 Root Server Availability>
> The Root server will be available 100% of the time. Assessment of
> availability should be based on a procedure such as ITU - CCITT document
> M.1016.> > 5.2 Latency>
> The services will be deployed (mirrored) in such as way that latency
(speed)
> of access from any major Internet carrier backbone will not fall below 85
> milliseconds for an in-region round trip, and 125 milliseconds for an
> trans-regional round trip.> > 5.3 Notification>
> If a fault known to the root server manager causes the service to be
> unavailable for a period of time exceeding five (5) minutes, the root
> server administrator will notify the ccTLD managers in accordance with the
> manner agreed between the root server manager and the ccTLD manager
(e-mail,
> phone, fax, beeper), 24 hours a day and 7 days a wekk(24*7).>
> If a fault becomes known to the ccTLD manager, the ccTLD shall notify the
> root server manager in accaordnace with the manner agreed between the root
> server manager and the ccTLD manager(e-mail, phone, fax, beeper), 24 hours
> a day and 7 days a weeek(24*7).> > 5.4 Escalation Procedure>
> Once the root server manager is aware of a fault, the time shall be logged
> (hard copy, wet signature).>
> An incident escalation system (possibly submitted by the root server
> manager) must be in place that causes an increased level of human
resources
> to be applied to fault resolution over a period of time.> > 5.5 Costs>
> The root server manager must disclosed the true, unbundled costs of
operating
> the service to the ccTLD mangers, or to a designated ccTLD constituency
> representative. > > > > > --> ccTLD Constituency of the DNSO
> Discussion Mailing List> (Formerly wwtld@ripe.net)
