April 2005 - council - lists.icann.org

GNSO minutes on web site
by philip.sheppard＠aim.be 05 Apr '05

05 Apr '05

Hello, webmaster, -a post MdP request. I cannot easily find approved GNSO Council meeting minutes on the website. Are these archived ? If so please add a link on the GNSO home page. The only way I can find them is to look at the mail list archive - this is less then efficient! Let me know plese when this change can be made. Philip Sheppard

1 0

ICANN and Everything Else
by Bret Fausett 05 Apr '05

05 Apr '05

I would appreciate having a discussion on ICANN and its relationship to the UN/ITU processes, WSIS, WGIG, etc. I know that we have members who are active in both. My own view has been (and still is) that the two activities are separate and should stay that way. The discussion today has lead me to believe that my view may not shared. Can we discuss this at some point? Bret

2 2

Vote summary for ICANN Board seat 14 from the email voting system
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG 04 Apr '05

04 Apr '05

[To:council[at]gnso.icann.org] Summary of votes for ICANN Board seat #14, from the email voting system. Please check your vote against your code. The results will be presented to the GNSO Council meeting on Wednesday 6 April 2005 for approval. Bfa2913b54D:20050316181917:[X] Yes Bfa2913b54D:20050316181917:[] No Bb975c1cc4D:20050317010745:[X] Yes Bb975c1cc4D:20050317010745:[] No B1d7cdf2e4D:20050317023638:[X] Yes B1d7cdf2e4D:20050317023638:[] No (ignored) Bb3b442f1eD:20050317041240:[*X*] Yes (ignored) Bb3b442f1eD:20050317041240:[] No Bb3b442f1eD:20050317041415:[X] Yes (duplicate; last one counts) Bb3b442f1eD:20050317041415:[] No B513ee1d7bD:20050317080125:[X] Yes B513ee1d7bD:20050317080125:[] No B22b1f72fbD:20050317115823:[X] Yes B22b1f72fbD:20050317115823:[] No (ignored) B06cece15cD:20050318094747:[X] Yes (email ballot; voter didn't edit correctly) B06cece15cD:20050318095210:[X] Yes (duplicate via web form) B06cece15cD:20050318095210:[] No B9200e55a3D:20050318095800:[X] Yes B9200e55a3D:20050318095800:[] No (ignored) B1abff3586D:20050321143031:[x] Yes (ignored) B1abff3586D:20050321143031:[] No B1abff3586D:20050321143152:[X] Yes (duplicate; last one counts) B1abff3586D:20050321143152:[] No B242018a28D:20050322060650:[X] Yes B242018a28D:20050322060650:[] No B0477f3cb2D:20050322165936:[X] Yes B0477f3cb2D:20050322165936:[] No B5d28ce8a9D:20050322215546:[X] Yes B5d28ce8a9D:20050322215546:[] No Bd02f9587cD:20050323065254:[x] Yes Bd02f9587cD:20050323065254:[] No B5dd86c2c4D:20050323181533:[X] Yes B5dd86c2c4D:20050323181533:[] No B79c832d6aD:20050324211429:[X] Yes B79c832d6aD:20050324211429:[] No B423d86090D:20050325060650:[X] Yes B423d86090D:20050325060650:[] No B6881bacb4D:20050326062341:[X] Yes B6881bacb4D:20050326062341:[] No B9b8562c81D:20050330112114:[] No (voter didn't edit vote correctly, but manual inspection indicates a "yes") Bc487af8beD:20050330115531:[X] Yes Bc487af8beD:20050330115531:[] No (ignored) Bcdcf400c1D:20050331035011:[X] Yes (ignored) Bcdcf400c1D:20050331035011:[] No (ignored) Bcdcf400c1D:20050331035507:[] Yes (duplicate) (ignored) Bcdcf400c1D:20050331035507:[] No Bcdcf400c1D:20050331035806:[X] Yes (duplicate) Bcdcf400c1D:20050331035806:[] No 20 "yes" votes, counting the one from B9b8562c81D The voter, for some reason, deleted the "[" and "]" characters that the software uses to identify the marks: Ballot: ELECTION: GNSO ICANN Board seat 14 SERIAL NUMBER: c682ddb674f BALLOT NUMBER: B9b8562c81D PASSWORD: PxxxxxxxxW ================================================================ I approve the selection of MICHAEL D. PALAGE as ICANN Board member :: x Yes :: [] No ================================================================ END__:c682ddb674f: -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

Public discussion on Domain Name Hijacking - Tuesday 5 April 2005 - 6:30pm to 7:30pm
by Bruce Tonkin 04 Apr '05

04 Apr '05

Hello All, Just a note to inform members of the GNSO Council that the Security and Stability Advisory Committee is running a public session on domain name hijacking issues on Tuesday 5 April 2005 from 6:30pm to 7:30pm. Some of the issues being discussed may have a bearing on refinement of the WHOIS and Transfers policies. Regards, Bruce Tonkin

1 0

ICANN Compliance Program for Registrars and Registries
by Bret Fausett 03 Apr '05

03 Apr '05

Apropos to our discussion today on compliance and enforcement, ICANN posted the following last night: http://icann.org/compliance/ -- Bret

1 0

List of major tasks for GNSO
by Bruce Tonkin 03 Apr '05

03 Apr '05

Hello All, Here is the list of tasks that are seen as important during the GNSO Council meeting today. MAJOR TASKS WHOIS New gtlds Strat Plan SIGNIFICANT TASKS Registry services Compliance Deletes Transfers GNSO review outcomes

1 0

[Fwd: [stratplan] FW: Strat Plan Consultation Process]
by Glen De Saint Géry 03 Apr '05

03 Apr '05

FYI Dear all At the Amsterdam Consultation on the ICANN Strategic Plan, many in attendance agreed that the stakeholders could make a useful contribution to the development of the Strategic Plan planning/consultation process. Attached is a “straw proposal” drawn from Grant Forsyth’s presentation on Day Two of the Amsterdam Consultation and expanded through the contributions of a few willing volunteers: Grant Forsyth, Maureen Stubberly, Chuck Gomes, and Marilyn Cade. It is intended as a working document and all comments and suggestions are welcomed. The idea is that on Wednesday, it can be one contribution to the discussion. Undoubtedly, others in the community may have contributions or suggestions. I’ll be traveling as of Thursday, but will have some access to hotmail over the week end. Please feel free to post any comments to the StratPlan list. Do also feel free to widely circulate this document to others in the community who you think are interested. The meeting on Wednesday at ICANN will be an opportunity for real time input from those who participate in the meeting. I hope all who are in MdP will come along to all three of the consultation meetings and contribute their suggestions to the ICANN staff who are hosting the meetings. Denise, Axel, and Chris, can we ask that you distribute to your groups? Best regards, Marilyn -- Glen de Saint Géry ICANN glen[at]icann.org http://www.icann.org

1 0

GNSO Council GAC notes 3 April 2005
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG 03 Apr '05

03 Apr '05

[To: council[at]gnso.icann.org] Dear Councillors, Please find the notes from the GNSO Council meeting with the GAC representatives this morning, Sunday 3 April 2005. Thanks to Maria Farrell, the notes are very complete. If you would like anything changed, please let me know. Thank you. Kind regards, Glen -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

3 4

Possible operational tasks for the GNSO Council and staff
by Bruce Tonkin 03 Apr '05

03 Apr '05

ÐÏà¡±á>þÿ 35þÿÿÿ4ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿì¥Á` ð¿f bjbjææ .íífÿÿÿÿÿÿ€€€€€€€€ž žº2, , , , , , , , 9;;;;;;$ìhT_€, , , , , _€€, , tÌ Ì Ì , .€, €, 9Ì , 9Ì Ì © €€õ , Bu8Å Z Á 90ºÉ ,Öp RÖõ Ö€õ D, , Ì , , , , , __Â , , , º, , , , žžž€\ €žžž\ žžž€€€€€€ÿÿÿÿAgenda will include: (1) GNSO operational plan for next 12 months (ie what policy work do we envision for next 12 months) (2) GNSO strategic planning for next 3 years (what are the major policy activities for the next 3 years) (3) ICANN operational plan (discuss input into ICANN operational planning process and meeting on Monday evening) (4) ICANN strategic planning (discuss input into ICANN strategic plan and meeting on Tuesday evening) (5) ICANN planning process going forward (how should ICANN manage operational and strategic planning going forward) (6) breakfast with ICANN Board on Monday morning (discuss approach and topics for discussion) (7) GNSO public forum on Wednesday morning (discuss topics) Transfers review 3, 6, 12 months WHOIS problem report input to the task force WHOIS TF Registry Services PDP Revision of the registrar accreditation agreement (registrars are primary interface with end users), and issue of graduated sanctions Issues report on deleted names Issues report new gtlds Enforcement and graduated sanctions Possible WIPO-II Recommendations from GNSO Council Review E.g establish liaisons to other supporting organisations and advisory committees Exploring technologies for Council teleconferences (combination of text and audio) Improve website design last changes, simple summary documents GNSO structure review Ï Ð Ñ Ò ô õ FÍºí M d f íåÝÕÃ±ÃÃ{Ãi#h§' hY5CJHOJQJ^JaJH#h§' h§' 5CJ(OJQJ^JaJ(#h§' h9 5CJ(OJQJ^JaJ(#h§' h 25CJ(OJQJ^JaJ(#h§' hY5CJ(OJQJ^JaJ(#h§' h€5CJ(OJQJ^JaJ(h 2CJHaJHh€CJHaJHhiCJHaJH#hÞÄhÞÄ5CJ$OJQJ^JaJ${|åæW X Ÿ ¿ 3 4 Ï Ð Ñ Ò õ ö %&/0FGöööööööööööööööôôôìçìçìçìâgd 2gd€ &Fgd€ 7$8$H$gdÞÄf ýGÍÎíî+,>?hiº M N d e f ÷ò÷ò÷ò÷ò÷ò÷òêêêò÷èè &Fgd€gd€ &Fgd€,1h°. °ÆA!°"°# $ %°°Ä°ÄÄ@@ñÿ@NormalCJ_HaJmH sH tH DA@òÿ¡DDefault Paragraph FontRi@óÿ³RTable Normalö4Ö l4Öaö(k@ôÿÁ(No Listfÿÿÿÿ{|åæWXŸ¿34ÏÐÑÒõö%&/0FGÍÎíî+,>?hiº MNdeh000000000000000000 00 00 00 00 00 00 00 00 00 0 0 0? 0? 0?0 0004Ïh{0T9y0y0ÿ0{00Šf Gf f DFilh8Ah3Òö&EÎ=?gNehhïxiMJÎôüÿÿÿÿÿÿÿÿÿ\þÆ^`\þOJPJQJ^Jo(- þÆ ^ `þOJQJ^Jo(hHopþÆp^p`þOJQJo(hH§ð@þÆ@^@`þOJQJo(hH·ðþÆ^`þOJQJ^Jo(hHoàþÆà^à`þOJQJo(hH§ð°þÆ°^°`þOJQJo(hH·ðþÆ^`þOJQJ^Jo(hHoPþÆP^P`þOJQJo(hH§ðïxiMÿÿÿÿÿÿÿÿšåä× å 9 §' iYüc* 2y|SÕl_€'ÞÄÿ@ýf0@ÿÿUnknownÿÿÿÿÿÿÿÿÿÿÿÿGz ÿTimes New Roman5Symbol3&z ÿArial?5 z ÿCourier New;Wingdings"qðÐh&àÎ Î Yð ŽŽ24dd2QðHX)ðÿ?äÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿY2ÿÿAgenda will include:Bruce TonkinBruce TonkinþÿàòùOh«+'³Ù0žÄÜèô , LX dpxäAgenda will include:Bruce TonkinNormal.dotBruce Tonkin2Microsoft Office Word@@ÝJ@ü¡c8Å@<h8ÅÎþÿÕÍÕ.+,ù®0hp š°žÀ ÈéäMelbourne IT dØAgenda will include:Title þÿÿÿ þÿÿÿþÿÿÿ !"#$%þÿÿÿ'()*+,-þÿÿÿýÿÿÿ0þÿÿÿþÿÿÿþÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿRoot Entryÿÿÿÿÿÿÿÿ ÀF`@8Å2Data ÿÿÿÿÿÿÿÿÿÿÿÿ1TableÿÿÿÿæWordDocumentÿÿÿÿ.SummaryInformation(ÿÿÿÿÿÿÿÿÿÿÿÿDocumentSummaryInformation8ÿÿÿÿÿÿÿÿ&CompObjÿÿÿÿÿÿÿÿÿÿÿÿqÿÿÿÿÿÿÿÿÿÿÿÿþÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿþÿ ÿÿÿÿ ÀFMicrosoft Office Word Document MSWordDocWord.Document.8ô9²qRoot Entryÿÿÿÿÿÿÿÿ ÀFÁ§i8Å7Data ÿÿÿÿÿÿÿÿÿÿÿÿ1TableÿÿÿÿæWordDocumentÿÿÿÿ. þÿÿÿ þÿÿÿþÿÿÿ !"#$%þÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ6ýÿÿÿþÿÿÿþÿÿÿþÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿþÿÿÿþÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿSummaryInformation(ÿÿÿÿÿÿÿÿÿÿÿÿDocumentSummaryInformation8ÿÿÿÿÿÿÿÿCompObjÿÿÿÿÿÿÿÿÿÿÿÿqÿÿÿÿÿÿÿÿÿÿÿÿþÿ ÿÿÿÿ ÀFMicrosoft Office Word Document MSWordDocWord.Document.8ô9²qþÿÕÍÕ.+,ù®DÕÍÕ.+,ù®Lhp š°žÀ ÈéäMelbourne IT dØAgenda will include:Title4 $,°

1 0

Re: [gnso-dow123] [Fwd: RFC 920]definition of admin and technical contacts
by Ross Rader 03 Apr '05

03 Apr '05

I would add to this that this "definition" was specific to the function of DNS registrations within the ARPA/DARPA networks. While this document has historical significance, it is long since obsolete. For the most part, the Registry and Registrar agreements now set the requirements for estabishing domain names, not RFC 920. To understand the true historical context of this document, one should also review RFC 1032 which describes the responsibilities of Domain Administrators - http://www.faqs.org/rfcs/rfc1032.html The most recent set of definitions, outside of the agreements, can be found here: http://www.icann.org/gnso/transfers-tf/report-exhc-12feb03.htm Glen De Saint Géry wrote: > Kiyoshi requested that this be forwarded. > Glen > > -------- Original Message -------- > Subject: RFC 920 > Date: Sun, 3 Apr 2005 11:26:29 -0400 > From: Kiyoshi I. Tsuru <ktsuru(a)bgmt.com.mx> > To: 'Glen De Saint Géry' <glen(a)icann.org> > > > > Dear Glen, > > This is the RFC that defines admin and technical contacts > > Could you possibly distribute it among the Council? > > Thank you so much, > > Kiyoshi > > > > RFC 920 (RFC920) > > Internet RFC/STD/FYI/BCP Archives > > [ RFC Index <http://www.faqs.org/rfcs/> | RFC Search > <http://www.faqs.org/rfcs/rfcsearch.html> | Usenet FAQs > <http://www.faqs.org/faqs/> | Web FAQs <http://www.faqs.org/contrib/> | > Documents <http://www.faqs.org/docs/> | Cities > <http://www.city-data.com/> ] > > *Alternate Formats:* rfc920.txt <http://www.faqs.org/ftp/rfc/rfc920.txt> > | rfc920.txt.pdf <http://www.faqs.org/ftp/rfc/pdf/rfc920.txt.pdf> > > Comment on RFC 920 <http://www.faqs.org/rfccomment.php?rfcnum=920> > > > RFC 920 - Domain requirements > > ------------------------------------------------------------------------ > > Network Working Group J. Postel > Request for Comments: 920 J. Reynolds > ISI > October 1984 > > Domain Requirements > > Status of this Memo > > This memo is a policy statement on the requirements of establishing a > new domain in the ARPA-Internet and the DARPA research community. > This is an official policy statement of the IAB and the DARPA. > Distribution of this memo is unlimited. > > Introduction > > This memo restates and refines the requirements on establishing a > Domain first described in RFC-881 > <http://www.faqs.org/rfcs/rfc881.html> [1]. It adds considerable detail > to that discussion, and introduces the limited set of top level > domains. > > The Purpose of Domains > > Domains are administrative entities. The purpose and expected use of > domains is to divide the name management required of a central > administration and assign it to sub-administrations. There are no > geographical, topological, or technological constraints on a domain. > The hosts in a domain need not have common hardware or software, nor > even common protocols. Most of the requirements and limitations on > domains are designed to ensure responsible administration. > > The domain system is a tree-structured global name space that has a > few top level domains. The top level domains are subdivided into > second level domains. The second level domains may be subdivided > into third level domains, and so on. > > The administration of a domain requires controlling the assignment of > names within that domain and providing access to the names and name > related information (such as addresses) to users both inside and > outside the domain. > > RFC 920 <http://www.faqs.org/rfcs/rfc920.html> > October 1984 > Domain Requirements > > General Purpose Domains > > While the initial domain name "ARPA" arises from the history of the > development of this system and environment, in the future most of the > top level names will be very general categories like "government", > "education", or "commercial". The motivation is to provide an > organization name that is free of undesirable semantics. > > After a short period of initial experimentation, all current > ARPA-Internet hosts will select some domain other than ARPA for their > future use. The use of ARPA as a top level domain will eventually > cease. > > Initial Set of Top Level Domains > > The initial top level domain names are: > > Temporary > > ARPA = The current ARPA-Internet hosts. > > Categories > > GOV = Government, any government related domains meeting the > second level requirements. > > EDU = Education, any education related domains meeting the > second level requirements. > > COM = Commercial, any commercial related domains meeting the > second level requirements. > > MIL = Military, any military related domains meeting the > second level requirements. > > ORG = Organization, any other domains meeting the second > level requirements. > > Countries > > The English two letter code (alpha-2) identifying a country > according the the ISO Standard for "Codes for the > Representation of Names of Countries" [5]. > > RFC 920 <http://www.faqs.org/rfcs/rfc920.html> > October 1984 > Domain Requirements > > Multiorganizations > > A multiorganization may be a top level domain if it is large, > and is composed of other organizations; particularly if the > multiorganization can not be easily classified into one of the > categories and is international in scope. > > Possible Examples of Domains > > The following examples are fictions of the authors' creation, any > similarity to the real world is coincidental. > > The UC Domain > > It might be that a large state wide university with, say, nine > campuses and several laboratories may want to form a domain. Each > campus or major off-campus laboratory might then be a subdomain, > and within each subdomain, each department could be further > distinguished. This university might be a second level domain in > the education category. > > One might see domain style names for hosts in this domain like > these: > > LOCUS.CS.LA.UC.EDU > CCN.OAC.LA.UC.EDU > ERNIE.CS.CAL.UC.EDU > A.S1.LLNL.UC.EDU > A.LAND.LANL.UC.EDU > NMM.LBL.CAL.UC.EDU > > The MIT Domain > > Another large university may have many hosts using a variety of > machine types, some even using several families of protocols. > However, the administrators at this university may see no need for > the outside world to be aware of these internal differences. This > university might be a second level domain in the education > category. > > One might see domain style names for hosts in this domain like > these: > > APIARY-1.MIT.EDU > BABY-BLUE.MIT.EDU > CEZANNE.MIT.EDU > DASH.MIT.EDU > > RFC 920 <http://www.faqs.org/rfcs/rfc920.html> > October 1984 > Domain Requirements > > MULTICS.MIT.EDU > TAC.MIT.EDU > XX.MIT.EDU > > The CSNET Domain > > There may be a consortium of universities and industry research > laboratories called, say, "CSNET". This CSNET is not a network > per se, but rather a computer mail exchange using a variety of > protocols and network systems. Therefore, CSNET is not a network > in the sense of the ARPANET, or an Ethernet, or even the > ARPA-Internet, but rather a community. Yet it does, in fact, have > the key property needed to form a domain; it has a responsible > administration. This consortium might be large enough and might > have membership that cuts across the categories in such a way that > it qualifies under the "multiorganization rule" to be a top level > domain. > > One might see domain style names for hosts in this domain like > these: > > CIC.CSNET > EMORY.CSNET > GATECH.CSNET > HP-LABS.CSNET > SJ.IBM.CSNET > UDEL.CSNET > UWISC.CSNET > > General Requirements on a Domain > > There are several requirements that must be met to establish a > domain. In general, it must be responsibly managed. There must be a > responsible person to serve as an authoritative coordinator for > domain related questions. There must be a robust domain name lookup > service, it must be of at least a minimum size, and the domain must > be registered with the central domain administrator (the Network > Information Center (NIC) Domain Registrar). > > Responsible Person: > > An individual must be identified who has authority for the > administration of the names within the domain, and who seriously > takes on the responsibility for the behavior of the hosts in the > domain, plus their interactions with hosts outside the domain. > This person must have some technical expertise and the authority > within the domain to see that problems are fixed. > > RFC 920 <http://www.faqs.org/rfcs/rfc920.html> > October 1984 > Domain Requirements > > If a host in a given domain somehow misbehaves in its interactions > with hosts outside the domain (e.g., consistently violates > protocols), the responsible person for the domain must be > competent and available to receive reports of problems, take > action on the reported problems, and follow through to eliminate > the problems. > > Domain Servers: > > A robust and reliable domain server must be provided. One way of > meeting this requirement is to provide at least two independent > domain servers for the domain. The database can, of course, be > the same. The database can be prepared and copied to each domain > server. But, the servers should be in separate machines on > independent power supplies, et cetera; basically as physically > independent as can be. They should have no common point of > failure. > > Some domains may find that providing a robust domain service can > most easily be done by cooperating with another domain where each > domain provides an additional server for the other. > > In other situations, it may be desirable for a domain to arrange > for domain service to be provided by a third party, perhaps on > hosts located outside the domain. > > One of the difficult problems in operating a domain server is the > acquisition and maintenance of the data. In this case, the data > are the host names and addresses. In some environments this > information changes fairly rapidly and keeping up-to-date data may > be difficult. This is one motivation for sub-domains. One may > wish to create sub-domains until the rate of change of the data in > a sub-domain domain server database is easily managed. > > In the technical language of the domain server implementation the > data is divided into zones. Domains and zones are not necessarily > one-to-one. It may be reasonable for two or more domains to > combine their data in a single zone. > > The responsible person or an identified technical assistant must > understand in detail the procedures for operating a domain server, > including the management of master files and zones. > > The operation of a domain server should not be taken on lightly. > There are some difficult problems in providing an adequate > service, primarily the problems in keeping the database up to > date, and keeping the service operating. > > RFC 920 <http://www.faqs.org/rfcs/rfc920.html> > October 1984 > Domain Requirements > > The concepts and implementation details of the domain server are > given in RFC-882 <http://www.faqs.org/rfcs/rfc882.html> [2] and > RFC-883 <http://www.faqs.org/rfcs/rfc883.html> [3]. > > Minimum Size: > > The domain must be of at least a minimum size. There is no > requirement to form a domain because some set of hosts is above > the minimum size. > > Top level domains must be specially authorized. In general, they > will only be authorized for domains expected to have over 500 > hosts. > > The general guideline for a second level domain is that it have > over 50 hosts. This is a very soft "requirement". It makes sense > that any major organization, such as a university or corporation, > be allowed as a second level domain -- even if it has just a few > hosts. > > Registration: > > Top level domains must be specially authorized and registered with > the NIC domain registrar. > > The administrator of a level N domain must register with the > registrar (or responsible person) of the level N-1 domain. This > upper level authority must be satisfied that the requirements are > met before authorization for the domain is granted. > > The registration procedure involves answering specific questions > about the prospective domain. A prototype of what the NIC Domain > Registrar may ask for the registration of a second level domain is > shown below. These questions may change from time to time. It is > the responsibility of domain administrators to keep this > information current. > > The administrator of a domain is required to make sure that host > and sub-domain names within that jurisdiction conform to the > standard name conventions and are unique within that domain. > > If sub-domains are set up, the administrator may wish to pass > along some of his authority and responsibility to a sub-domain > administrator. Even if sub-domains are established, the > responsible person for the top-level domain is ultimately > responsible for the whole tree of sub-domains and hosts. > > This does not mean that a domain administrator has to know the > > RFC 920 <http://www.faqs.org/rfcs/rfc920.html> > October 1984 > Domain Requirements > > details of all the sub-domains and hosts to the Nth degree, but > simply that if a problem occurs he can get it fixed by calling on > the administrator of the sub-domain containing the problem. > > Top Level Domain Requirements > > There are very few top level domains, each of these may have many > second level domains. > > An initial set of top level names has been identified. Each of these > has an administrator and an agent. > > The top level domains: > > ARPA = The ARPA-Internet *** TEMPORARY *** > > Administrator: DARPA > Agent: The Network Information Center > Mailbox: HOSTMASTER(a)SRI-NIC.ARPA > <mailto:HOSTMASTER@SRI-NIC.ARPA> > > GOV = Government > > Administrator: DARPA > Agent: The Network Information Center > Mailbox: HOSTMASTER(a)SRI-NIC.ARPA > <mailto:HOSTMASTER@SRI-NIC.ARPA> > > EDU = Education > > Administrator: DARPA > Agent: The Network Information Center > Mailbox: HOSTMASTER(a)SRI-NIC.ARPA > <mailto:HOSTMASTER@SRI-NIC.ARPA> > > COM = Commercial > > Administrator: DARPA > Agent: The Network Information Center > Mailbox: HOSTMASTER(a)SRI-NIC.ARPA > <mailto:HOSTMASTER@SRI-NIC.ARPA> > > MIL = Military > > Administrator: DDN-PMO > Agent: The Network Information Center > Mailbox: HOSTMASTER(a)SRI-NIC.ARPA > <mailto:HOSTMASTER@SRI-NIC.ARPA> > > RFC 920 <http://www.faqs.org/rfcs/rfc920.html> > October 1984 > Domain Requirements > > ORG = Organization > > Administrator: DARPA > Agent: The Network Information Center > Mailbox: HOSTMASTER(a)SRI-NIC.ARPA > <mailto:HOSTMASTER@SRI-NIC.ARPA> > > Countries > > The English two letter code (alpha-2) identifying a country > according the the ISO Standard for "Codes for the > Representation of Names of Countries" [5]. > > As yet no country domains have been established. As they are > established information about the administrators and agents > will be made public, and will be listed in subsequent editions > of this memo. > > Multiorganizations > > A multiorganization may be a top level domain if it is large, > and is composed of other organizations; particularly if the > multiorganization can not be easily classified into one of the > categories and is international in scope. > > As yet no multiorganization domains have been established. As > they are established information about the administrators and > agents will be made public, and will be listed in subsequent > editions of this memo. > > Note: The NIC is listed as the agent and registrar for all the > currently allowed top level domains. If there are other entities > that would be more appropriate agents and registrars for some or > all of these domains then it would be desirable to reassign the > responsibility. > > Second Level Domain Requirements > > Each top level domain may have many second level domains. Every > second level domain must meet the general requirements on a domain > specified above, and be registered with a top level domain > administrator. > > RFC 920 <http://www.faqs.org/rfcs/rfc920.html> > October 1984 > Domain Requirements > > Third through Nth Level Domain Requirements > > Each second level domain may have many third level domains, etc. > Every third level domain (through Nth level domain) must meet the > requirements set by the administrator of the immediately higher level > domain. Note that these may be more or less strict than the general > requirements. One would expect the minimum size requirements to > decrease at each level. > > The ARPA Domain > > At the time the implementation of the domain concept was begun it was > thought that the set of hosts under the administrative authority of > DARPA would make up a domain. Thus the initial domain selected was > called ARPA. Now it is seen that there is no strong motivation for > there to be a top level ARPA domain. The plan is for the current > ARPA domain to go out of business as soon as possible. Hosts that > are currently members of the ARPA domain should make arrangements to > join another domain. It is likely that for experimental purposes > there will be a second level domain called ARPA in the ORG domain > (i.e., there will probably be an ARPA.ORG domain). > > The DDN Hosts > > DDN hosts that do not desire to participate in this domain naming > system will continue to use the HOSTS.TXT data file maintained by the > NIC for name to address translations. This file will be kept up to > date for the DDN hosts. However, all DDN hosts will change their > names from "host.ARPA" to (for example) "host.DDN.MIL" some time in > the future. The schedule for changes required in DDN hosts will be > established by the DDN-PMO. > > Impact on Hosts > > What is a host administrator to do about all this? > > For existing hosts already operating in the ARPA-Internet, the > best advice is to sit tight for now. Take a few months to > consider the options, then select a domain to join. Plan > carefully for the impact that changing your host name will have on > both your local users and on their remote correspondents. > > For a new host, careful thought should be given (as discussed > below). Some guidance can be obtained by comparing notes on what > other hosts with similar administrative properties have done. > > The owner of a host may decide which domain to join, and the > > RFC 920 <http://www.faqs.org/rfcs/rfc920.html> > October 1984 > Domain Requirements > > administrator of a domain may decide which hosts to accept into his > domain. Thus the owner of a host and a domain administrator must > come to an understanding about the host being in the domain. This is > the foundation of responsible administration. > > For example, a host "XYZ" at MIT might possible be considered as a > candidate for becoming any of XYZ.ARPA.ORG, XYZ.CSNET, or > XYZ.MIT.EDU. > > The owner of host XYZ may choose which domain to join, > depending on which domain administrators are willing to have > him. > > The domain is part of the host name. Thus if USC-ISIA.ARPA changes > its domain affiliation to DDN.MIL to become USC-ISIA.DDN.MIL, it has > changed its name. This means that any previous references to > USC-ISIA.ARPA are now out of date. Such old references may include > private host name to address tables, and any recorded information > about mailboxes such as mailing lists, the headers of old messages, > printed directories, and peoples' memories. > > The experience of the DARPA community suggests that changing the name > of a host is somewhat painful. It is recommended that careful > thought be given to choosing a new name for a host - which includes > selecting its place in the domain hierarchy. > > The Roles of the Network Information Center > > The NIC plays two types of roles in the administration of domains. > First, the NIC is the registrar of all top level domains. Second > the NIC is the administrator of several top level domains (and the > registrar for second level domains in these). > > Top Level Domain Registrar > > As the registrar for top level domains, the NIC is the contact > point for investigating the possibility of establishing a new top > level domain. > > Top Level Domain Administrator > > For the top level domains designated so far, the NIC is the > administrator of each of these domains. This means the NIC is > responsible for the management of these domains and the > registration of the second level domains or hosts (if at the > second level) in these domains. > > RFC 920 <http://www.faqs.org/rfcs/rfc920.html> > October 1984 > Domain Requirements > > It may be reasonable for the administration of some of these > domains to be taken on by other authorities in the future. It is > certainly not desired that the NIC be the administrator of all top > level domains forever. > > Prototypical Questions > > To establish a domain, the following information must be provided to > the NIC Domain Registrar (HOSTMASTER(a)SRI-NIC.ARPA > <mailto:HOSTMASTER@SRI-NIC.ARPA>): > > Note: The key people must have computer mail mailboxes and > NIC-Idents. If they do not at present, please remedy the > situation at once. A NIC-Ident may be established by contacting > NIC(a)SRI-NIC.ARPA <mailto:NIC@SRI-NIC.ARPA>. > > 1) The name of the top level domain to join. > > For example: EDU > > 2) The name, title, mailing address, phone number, and organization > of the administrative head of the organization. This is the contact > point for administrative and policy questions about the domain. In > the case of a research project, this should be the Principal > Investigator. The online mailbox and NIC-Ident of this person should > also be included. > > For example: > > Administrator > > Organization USC/Information Sciences Institute > Name Keith Uncapher > Title Executive Director > Mail Address USC/ISI > 4676 Admiralty Way, Suite 1001 > Marina del Rey, CA. 90292-6695 > Phone Number 213-822-1511 > Net Mailbox Uncapher(a)USC-ISIB.ARPA > <mailto:Uncapher@USC-ISIB.ARPA> > NIC-Ident KU > > 3) The name, title, mailing address, phone number, and organization > of the domain technical contact. The online mailbox and NIC-Ident of > the domain technical contact should also be included. This is the > contact point for problems with the domain and for updating > information about the domain. Also, the domain technical contact may > be responsible for hosts in this domain. > > RFC 920 <http://www.faqs.org/rfcs/rfc920.html> > October 1984 > Domain Requirements > > For example: > > Technical Contact > > Organization USC/Information Sciences Institute > Name Craig Milo Rogers > Title Researcher > Mail Address USC/ISI > 4676 Admiralty Way, Suite 1001 > Marina del Rey, CA. 90292-6695 > Phone Number 213-822-1511 > Net Mailbox Rogers(a)USC-ISIB.ARPA > <mailto:Rogers@USC-ISIB.ARPA> > NIC-Ident CMR > > 4) The name, title, mailing address, phone number, and organization > of the zone technical contact. The online mailbox and NIC-Ident of > the zone technical contact should also be included. This is the > contact point for problems with the zone and for updating information > about the zone. In many cases the zone technical contact and the > domain technical contact will be the same person. > > For example: > > Technical Contact > > Organization USC/Information Sciences Institute > Name Craig Milo Rogers > Title Researcher > Mail Address USC/ISI > 4676 Admiralty Way, Suite 1001 > Marina del Rey, CA. 90292-6695 > Phone Number 213-822-1511 > Net Mailbox Rogers(a)USC-ISIB.ARPA > <mailto:Rogers@USC-ISIB.ARPA> > NIC-Ident CMR > > 5) The name of the domain (up to 12 characters). This is the name > that will be used in tables and lists associating the domain and the > domain server addresses. [While technically domain names can be > quite long (programmers beware), shorter names are easier for people > to cope with.] > > For example: ALPHA-BETA > > 6) A description of the servers that provides the domain service for > translating name to address for hosts in this domain, and the date > they will be operational. > > RFC 920 <http://www.faqs.org/rfcs/rfc920.html> > October 1984 > Domain Requirements > > A good way to answer this question is to say "Our server is > supplied by person or company X and does whatever their standard > issue server does". > > For example: Our server is a copy of the server operated by > the NIC, and will be installed and made operational on > 1-November-84. > > 7) A description of the server machines, including: > > (a) hardware and software (using keywords from the Assigned > Numbers) > > (b) addresses (what host on what net for each connected net) > > For example: > > (a) hardware and software > > VAX-11/750 and UNIX, or > IBM-PC and MS-DOS, or > DEC-1090 and TOPS-20 > > (b) address > > 10.9.0.193 on ARPANET > > 8) An estimate of the number of hosts that will be in the domain. > > (a) initially, > (b) within one year, > (c) two years, and > (d) five years. > > For example: > > (a) initially = 50 > (b) one year = 100 > (c) two years = 200 > (d) five years = 500 > > RFC 920 <http://www.faqs.org/rfcs/rfc920.html> > October 1984 > Domain Requirements > > Acknowledgment > > We would like to thank the many people who contributed to this memo, > including the participants in the Namedroppers Group, the ICCB, the > PCCB, and especially the staff of the Network Information Center, > particularly J. Feinler and K. Harrenstien. > > References > > [1] Postel, J., "The Domain Names Plan and Schedule", RFC-881 > <http://www.faqs.org/rfcs/rfc881.html>, USC > Information Sciences Institute, November 1983. > > [2] Mockapetris, P., "Domain Names - Concepts and Facilities", > RFC-882 <http://www.faqs.org/rfcs/rfc882.html>, USC Information > Sciences Institute, November 1983. > > [3] Mockapetris, P., "Domain Names - Implementation and > Specification", RFC-883 <http://www.faqs.org/rfcs/rfc883.html>, > USC Information Sciences Institute, > November 1983. > > [4] Postel, J., "Domain Name System Implementation Schedule", > RFC-897 <http://www.faqs.org/rfcs/rfc897.html>, USC Information > Sciences Institute, February 1984. > > [5] ISO, "Codes for the Representation of Names of Countries", > ISO-3166, International Standards Organization, May 1981. > > [6] Postel, J., "Domain Name System Implementation Schedule - > Revised", RFC-921 <http://www.faqs.org/rfcs/rfc921.html>, USC > Information Sciences Institute, October > 1984. > > [7] Mockapetris, P., "The Domain Name System", Proceedings of the > IFIP 6.5 Working Conference on Computer Message Services, > Nottingham, England, May 1984. Also as ISI/RS-84-133, > June 1984. > > [8] Mockapetris, P., J. Postel, and P. Kirton, "Name Server Design > for Distributed Systems", Proceedings of the Seventh > International Conference on Computer Communication, October 30 > to November 3 1984, Sidney, Australia. Also as ISI/RS-84-132, > June 1984. > > > Comment on RFC 920 <http://www.faqs.org/rfccomment.php?rfcnum=920> > > > > Previous: RFC 0919 - Broadcasting Internet Datagrams > <http://www.faqs.org/rfcs/rfc919.html> > > > > Next: RFC 0921 - Domain name system implementation schedule - revised > <http://www.faqs.org/rfcs/rfc921.html> > > > > ------------------------------------------------------------------------ > [ RFC Index <http://www.faqs.org/rfcs/> | RFC Search > <http://www.faqs.org/rfcs/rfcsearch.html> | Usenet FAQs > <http://www.faqs.org/faqs/> | Web FAQs <http://www.faqs.org/contrib/> | > Documents <http://www.faqs.org/docs/> | Cities > <http://www.city-data.com/> ] > > > > > > *Kiyoshi I. Tsuru > Bello, Guzmán, Morales y Tsuru, S.C. > *Agustín Manuel Chávez 1 - 104 > Centro de Ciudad Santa Fe > 01210, México, D.F. > Tel. +52 (55) 5292-5232 > Fax +52 (55) 5292-5233 > www.bgmt.com.mx <http://www.bgmt.com.mx/> > > La información contenida en este mensaje de datos es confidencial, > constituye un secreto industrial en términos de la legislación vigente y > se encuentra dirigida exclusivamente al destinatario indicado en dicho > mensaje. Si usted recibe esta información por error o si usted no es el > destinatario del mensaje, favor de destruirlo inmediatamente, > absteniéndose de leerlo, reproducirlo, transmitirlo, almacenarlo, > divulgarlo, revelarlo o usarlo de manera directa o indirecta en > cualquier forma y por cualquier medio. Muchas gracias. > The information contained in this electronic message is confidential, > privileged and intended for its recipient only. If you receive this mail > by mistake and/or if you are not the recipient thereof, please destroy > it immediately, abstaining yourself from reading, reproducing, > transmitting, storing, disclosing, revealing or using it, either > directly or indirectly, in any manner and by any means. Thank you very > much. > > > -- -rwr Contact info: http://www.blogware.com/profiles/ross Skydasher: A great way to start your day My weblog: http://www.byte.org

1 0