sou · GRB359d2 · 2004-01-01 00:00:00 — På internationell nivå har den mellanstatliga rådgivande kommittén (GAC) till on Assigned Names and Numbers (ICANN) utarbetat principer för delegering och admini- stration av nationella toppdomäner. I betänkande (SOU 2000:30) finns en beskrivning av domännamns- systemet. har föreslagit att inför en avtalsmodell motsvarande den som GAC har föreslagit för delegering av ansvaret för de nationella toppdomänerna. Sedan betänkande lämnades har kom- missionen i meddelandet KOM(2000)202 uppmanat medlemsstaterna att genomföra GAC:s principer på ett lämpligt sätt i den mån de avser regeringars förhållande till ICANN och till sina . Europeiska unionens råd upp- manade medlemsstaterna att med beaktande av nationella bestämmelser genomföra GAC:s principer för delegering och administration av nationella toppdomäner. Utredaren skall beskriva och utvärdera tillämpningen av GAC:s principer för den nationella toppdomänen punkt-se. Utredaren skall undersöka möjligheterna att genomföra principerna, särskilt artikel 5 som rör statens roll, genom en offentligrättslig reglering och lämna de författningsförslag som anses nödvändiga för att möjliggöra statlig tillsyn av principernas efterlevnad. Förslagens ekonomiska kon- sekvenser skall analyseras och redovisas. Utredaren skall ha stor frihet att ta upp de ytterligare frågor som denne anser behöver övervägas inom ramen för uppdraget. Det ingår dock inte i uppdraget att föreslå grundlagsändringar. Utredaren skall samråda med representanter för organisationer och företag inom området samt med berörda myndigheter. Om utredaren föreslår ändringar i radio- och TV-lagen skall förslagen utformas i samråd med utredningen om översyn av radio- och TV- lagen m.m. Utredaren skall även beakta konsekvenserna av föreslagen lag- stiftning för små företags villkor, i enlighet med 15 § kommitté- förordningen (1998:1474). Utredaren skall härvid samråda med för Regelgranskning. Utredaren skall beakta betänkande (SOU 2001:28) och den vidare beredningen av det. Utredaren skall beakta den vidare beredningen av departements- promemorian. Effektivare tvistlösning på teleområdet (Ds 2000:56) samt Post- och skrivelse Upp- lysning om teleadresser. Sårbarhets- och säkerhetsutredningen (Fö 1999:04) skall redo- visa sitt arbete . Utredaren skall inom ramen för sitt uppdrag beakta utredningens betänkande och den vidare bered- ningen av det. Regeringen uppdrog åt i dess reglerings- brev för att utreda vissa frågor för att säkerställa driften av Internet i . Uppdragen skall redovisas . Utredaren skall beakta myndighetens skrivelse med redo- visning av uppdragen. Utredaren skall också beakta betänkande (SOU 2000:111). Utredaren skall redovisa sitt uppdrag . Principles for the Delegation and Administration of Country Code Top Level Domains In the five years since the issuance of RFC 1591, the Internet has evolved from a tool reserved for computer and networking research, to a global medium for commerce, education, and communication. The new realities of the Internet, including its increased importance as a vehicle for national economic growth, and the expanding and more diverse nature of the Internet community necessitated evolution in the traditional means of managing and administering Internet technical functions. As a result, DNS functions, including the administration of the DNS root server system, the development of policies for the registration and allocation of domain names, the coordination of Internet Protocols, and the delegation of Internet Protocol numbers are becoming more clearly delineated and formalised through the ICANN process. Similarly, the procedures and framework of accountability for delegation and administration of ccTLDs need to evolve into a more robust, certain, and reliable system as well. While evolution is needed, the principle of RFC 1591 remains sound: the manager of a ccTLD performs a public service on behalf of the relevant local community and as such the designated manager has a duty to serve this community. The designated manager also has a responsibility to the global Internet community. By global Internet community' we do not mean any specific legal or international entity, but rather we interpret the term to refer to all of those who are affected by, now or in the future, the operation of the relevant TLD, because such operation may impinge on more than one jurisdiction and affect the interests of individuals and entities from both within the relevant country or territory and elsewhere. This is our interpretation of the meaning of global Internet community' as it is used in RFC 1591. 2.Objective of this Document The objective of this document is to suggest principles that will assist in the development of best practice for the delegation and administration of ccTLDs. These principles are intended to contribute to the development of models of: a communication between the relevant government or public authority and ICANN; a communication between ICANN and the delegee; and a communication between the relevant government or public authority and the delegee. For the purposes of this document, the following definitions apply: 3.1Alternative Dispute Resolution' (or ADR') means any system of resolving a dispute other than by court litigation, and includes arbitration, mediation, conciliation and processes of administrative dispute resolution. 3.2Communication' should include a law, regulation, agreement, document, contract, memorandum of understanding, or any other written instrument, as appropriate. 3.3Country code top level domain' or ccTLD' means a domain in the top level of the global domain name system assigned according to the two-letter codes in the ISO 3166-1 standard, Codes for the Representation of Names of Countries and Their Subdivisions.' 3.4Delegation' means delegation by ICANN/of responsibility for administration of a TLD in the DNS root. 3.5Delegee' means the organisation,enterprise or individual designated by the relevant government or public authority to exercise the public trust function of a ccTLD and consequently recognised through a communication between ICANN and the designated entity for that purpose. The delegee for a ccTLD may be the relevant government or public authority itself or an oversight body designated by the relevant government or public authority, inasmuch as the administrative and management functions for a ccTLD may be contracted out by the delegee to another party and hence not performed by the delegee itself. 3.6Designation' means designation by the relevant government or public authority of the delegee. 3.7DNS' means domain name system. 3.8ICANN' means the for Assigned Names and Numbers. 3.9Relevant government or public authority' means relevant national government or public authority of a distinct economy as recognised in international fora as those terms are used in the ICANN Bylaws and GAC Operating Principles. 3.10Relevant local community' means the local community in the context of the ISO 3166-1 code. This definition is specific to the purposes identified in this document and not broader. 3.11Top Level Domain' or TLD' means a domain in the top level of the global domain name system. 4.1The delegee of a ccTLD is a trustee for the delegated domain, and has a duty to serve the residents of the relevant country or territory in the context of ISO 3166-1, as well as the global Internet community (as that term is interpreted in the Preamble to this document). Its policy role should be distinguished from the management, administration and marketing of the ccTLD. These functions may be performed by the same or different entities. However the delegation itself cannot be sub-contracted, sub- licensed or otherwise traded without the agreement of the relevant government or public authority and ICANN. 4.2No private intellectual or other property rights should inhere in the ccTLD itself, nor accrue to the delegee as the result of delegation or to any entity as a result of the management, administration or marketing of the ccTLD. 4.3Tradable goods and services may arise in the performance of other management and administrative functions attached to the ccTLD. 4.4The delegee should recognise that ultimate public policy authority over the relevant ccTLD rests with the relevant government or public authority. 4.5The delegee should work cooperatively with the relevant government or public authority of the country or territory for which the ccTLD has been established, within the framework and public policy objectives of such relevant government or public authority. 4.6The delegee, and the delegee's administrative contact, should be resident or incorporated in the territory and/or jurisdiction of the relevant government or public authority. Where the delegee, administrative contact or technical contact are not resident or incorporated in the territory and/or jurisdiction of the relevant government or public authority, it should nevertheless operate in a way that is consistent with the laws and public policy of that relevant government or public authority. 5.Role of Government or Public Authority 5.1The relevant government or public authority ultimately represents the interests of the people of the country or territory for which the ccTLD has been delegated. Accordingly, the role of the relevant government or public authority is to ensure that the ccTLD is being administered in the public interest, whilst taking into consideration issues of public policy and relevant law and regulation. 5.2Governments or public authorities have responsibility for public policy objectives such as: transparency and non- discriminatory practices; greater choice, lower prices and better services for all categories of users; respect for personal privacy; and consumer protection issues. Considering their responsibility to protect these interests, governments or public authorities maintain ultimate policy authority over their respective ccTLDs and should ensure that they are operated in conformity with domestic public policy objectives, laws and regulations, and international law and applicable international conventions. 5.3It is recalled that () to ICANN has previously adopted the general principle that the Internet naming system is a public resource in the sense that its functions must be administered in the public or common interest. 5.4The relevant government or public authority should ensure that DNS registration in the ccTLD benefits from effective and fair condition of competition, at appropriate levels and scale of activity. 5.5To give effect to governments' or public authorities' public policy interests, governments or public authorities should ensure that the terms outlined in 9 are included in their communications with delegees. 5.6In making a designation for a delegee, the government or public authority should take into consideration the importance of long term stability in the administration and management of the ccTLD and in the DNS. In most cases, such stability may be best served through the designation of an organisation or an enterprise rather than a specific individual. 6.1 A primary function of ICANN is to establish, disseminate, and oversee implementation of the technical standards and practices that relate to the operation of the global DNS. In this capacity, ICANN administers a range of technical Internet management functions, including: of policy for IP number block allocation; administration of the authoritative root server system; creation of policy for determining the circumstances under which new TLDs would be added to the root system; coordination of the assignment of other Internet technical parameters as needed to maintain connectivity on the Internet; and other activities necessary to coordinate specified DNS administration functions. 6.2 Specifically in relation to the administration and operation of ccTLDs, ICANN's role is to develop and implement policies that fulfil the provisions of 10 below. 7.Principles relating to Delegations 7.1Where a communication between the relevant government or public authority and the delegee is in place, when ICANN is notified by the relevant government or public authority that the delegee has contravened the terms of the communication, or the term of the designation has expired, ICANN should act with the utmost promptness to reassign the delegation in coordination with the relevant government or public authority. 7.2Notwithstanding the urgent need for a communication-based regime for ccTLD designation, delegation and administration, in the absence of such communication between the relevant government or public authority and the administrator of the ccTLD, ICANN should, upon the tendering of evidence by such government or public authority that the administrator does not have the support of the relevant local community and of the relevant government or public authority, or has breached and failed to remedy other material provisions of RFC 1591, act with the utmost promptness to reassign the delegation in coordination with the relevant government or public authority. 7.3When ICANN notifies the relevant government or public authority that the ccTLD is being operated in a that threatens the stability of the DNS or of the Internet, or has otherwise breached and failed to remedy other material provisions of the communication between ICANN and the delegee, as outlined in 10, the relevant government or public authority should cooperate with ICANN to remedy this situation or effect the reassignment of the delegation for the ccTLD. 7.4With respect to future delegations or reassignment of delegations, ICANN should delegate the administration of a ccTLD only to an organisation, enterprise or individual that has been designated by the relevant government or public authority. 7.5Delegees should enjoy, in the execution of their responsibilities, the appropriate rights under applicable law, and should not be subject to discriminatory or arbitrary practices, policies or procedures from ICANN or the relevant government or public authority. In the event of a reassignment of delegation, registrants in the ccTLD should be afforded continued name resolution, or a reasonable period in which to transfer to another TLD. 8.Principles concerning the Communication between the relevant Government or Public Authority and ICAAN 8.1The communication between the relevant government or public authority and ICANN, as outlined in 2, should include a designated point of contact within the relevant government or public authority, as well as the name and contact details of the recognised delegee and duration of this recognition. Either as part of this communication, or through a subsequent communication, the relevant government or public authority should copy to ICANN any communication established between it and the delegee, setting forth the terms and conditions of the designation and/or concerning the execution of the delegee's role and the management of the delegation. 8.2The relevant government or public authority should communicate to ICANN how it will require the delegee to abide by the terms and conditions outlined in 9 below. 8.3Recognising ICANN's responsibilities to achieve consensus in the creation of any new generic TLDs, ICANN should avoid, in the creation of new generic TLDs, well known and famous country, territory or place names; well known and famous country, territory or regional language or people descriptions; or ISO 639 Codes for representation of languages unless in agreement with the relevant governments or public authorities. 9.Principles concerning the Communication between the relevant Government or Public Authority and the Delegee 9.1 The communication between the relevant government or public authority and the delegee should include the following provisions, a copy or summary of which should be forwarded to ICANN: 9.1.1Term, performance , opportunity for review and process for revocation. 9.1.2A commitment by the delegee to operate the ccTLD in the interest of the relevant local community and the global Internet community. 9.1.3A recognition by the delegee that the management and administration of the ccTLD are subject to the ultimate authority of the relevant government or public authority, and must conform with relevant domestic laws and regulations, and international law and international conventions. 9.1.4Confirmation that the ccTLD is operated in trust in the public interest and that the delegee does not acquire property rights to the ccTLD itself. 9.1.5Conditions to ensure the transfer of all relevant DNS data to a nominated replacement, if, for any reason, a reassignment to a new delegee is necessary. 9.1.6Conditions for the efficient and effective resolution of disputes arising from domain name registration. In so far as ccTLD registration policies allow or encourage registrations from entities or individuals resident outside the relevant territory, then the delegee concerned should implement dispute resolution policies that ensure that the interests of all registrants, and of third parties, including those outside their territory and in other jurisdictions, are taken into account. Dispute resolution policies should, to the greatest extent possible, follow common principles, including due regard for internationally recognised intellectual property, consumer protection and other relevant law, and be implemented by all delegees. The delegee should, so far as possible, implement alternative dispute resolution procedures conducted online, without precluding access to court litigation. 9.1.7The delegee's commitment to abide by ICANN developed policies as set forth in 10. 9.1.8Where ccTLD registration policies allow or encourage registrations from entities or individuals resident outside the relevant territory, the delegee commits to observe all ICANN policies applicable to such ccTLDs, not otherwise provided for in 10, except where the delegee is prohibited by law from, or instructed in writing by the relevant government or public authority to refrain from, implementing such other ICANN policies. 9.1.9The above terms and conditions shall apply to delegees, including delegees who are resident and/or incorporated outside the territory of the relevant local community. 9.2A delegee should not sub-contract part or all of the technical operations of the ccTLD registry without ensuring that the sub- contractor has the technical qualifications required by ICANN, and informing ICANN. 9.3In any sub-contracting of the technical operations of the ccTLD registry or administrative and management functions of the ccTLD, the sub-contract must state that the delegation itself is an exercise of a public right, not an item of property, and cannot be reassigned to a new delegee except in accordance with the provisions of 7. 10.Principles concerning the Communication between ICANN and the Delegee 10.1The communication between ICANN and the delegee should contain ICANN's commitment to: 10.1.1maintain, or cause to be maintained, a stable, secure, authoritative and publicly available database of relevant information for each ccTLD (see below); 10.1.2ensure that authoritative and accurate root zone information is generated from such database and ensure that the root servers are operated in stable and secure ; 10.1.3maintain, or cause to be maintained, authoritative records and an audit trail regarding ccTLD delegations and records related to these delegations; and 10.1.4inform the delegee in a timely of any changes to ICANN's contact information. 10.2The communication between ICANN and the delegee should contain the delegee's commitment to: 10.2.1cause to be operated and maintained in a stable and secure the authoritative primary and secondary nameservers for the ccTLD, adequate to resolve names within the ccTLD for users throughout the Internet, and any sub-domains over which they retain administrative authority, and ensure that the zone file and accurate and up-to-date registration data is continuously available to ICANN for purposes of verifying and ensuring the operational stability of the ccTLD only; 10.2.2inform ICANN in a timely of any changes to the ccTLD's contact information held by ICANN; 10.2.3ensure the safety and integrity of the registry database, including the of a data escrow or mirror site policy for the registry data managed by the delegate. The escrow agent or mirror site should be mutually approved by the relevant government or public authority and the delegee and should not be under the control of the delegee; 10.2.4ensure the transfer of all relevant DNS data to a nominated replacement, if, for any reason, a reassignment to a new delegee is necessary; 10.2.5abide by ICANN developed policies concerning: interoperability of the ccTLD with other parts of the DNS and Internet; operational capabilities and performance of the ccTLD operator; and the obtaining and maintenance of, and public access to, accurate and up-to-date contact information for domain name registrants; and 10.2.6ensure the payment of its contribution to ICANN's cost of operation in accordance with an equitable scale, based on ICANN's total funding requirements (including reserves), developed by ICANN on the basis of consensus. Bilagan har i sin helhet hämtats från betänkande .se?, SOU 2000:30. Domännamnssystemet – en snabbintroduktion Kungliga Tekniska 2.0, 1999–09–20 Uppslagsnyckel – värde ......................................................... Uppslagning – sökning .......................................................... Rotnamnservrar och hänvisningar ........................................ Uppslagning: ett exempel...................................................... Secure DNS i ............................................................. Det lättaste sättet att föreställa sig problemet är att tänka sig att man har beställt en telefon och just fått den installerad. Man sitter där med sin fina apparat och man kan i princip ringa till hela världen. Man kan namn och adress på en massa människor man vill prata med, problemet är att man inte kan några telefonnummer. Man behöver en telefonkatalog eller en nummerbyrå. På Internet fungerar det på samma sätt. Internet är helt världsomspännande, och lokala telefonkataloger anses utan värde. Det behövs en global telefonkatalog som täcker hela systemet. Av samma anledning som man inte har hela världens telefonkatalog i sin bokhylla – den blir alldeles för stor, och den blir alldeles för snabbt inaktuell – så har datorerna på Internet inte heller någon sammanhållen, central katalog; de har faktiskt ingen katalog alls. Man har satsat helt och hållet på en snabb och väl fungerande nummerbyrå: domännamnssystemet (DNS). Systemet är distri- buerat på ett hierarkiskt sätt, så att den som är ansvarig själv kan sköta sin del av databasen. Med hjälp av snabba hänvisningar kan den som letar snabbt hitta fram till rätt databasserver. Så länge datorer har funnits har människan givit dem namn. Redan de allra första datorerna döptes. och blev snabbt rikskändisar. När man kopplar ihop datorerna i nätverk blir det viktigt att veta vilken dator man kommunicerar med. En dators identitet på ett nätverk är i allmänhet ett tal (datorer arbetar ju bara med tal), och datorerna sinsemellan har inga problem att hålla isär varandra med hjälp av tal, men vi människor har det. Internet är inget undantag. Alla datorer på Internet identifieras med sitt eget tal – sitt telefonnummer om man vill. Denna Internetadress är svår för människor att komma ihåg (talen är stora, från 0 upp till 4294967295), och kan också ändras . skrivs adresserna som fyra grupper av mindre tal (t.ex. 192.168.11.1) för att de skall bli lättare att minnas och att hantera, men det är bara ett annat skrivsätt. Människor som arbetar med datorer vill kunna säga åt sina system Koppla dig till den där andra datorn!. På något sätt måste man identifiera den andra datorn.