From Jay at Iperdome.com Mon Oct 4 23:50:48 1999 From: Jay at Iperdome.com (Jay Fenello) Date: Mon, 04 Oct 1999 17:50:48 -0400 Subject: ICANN renames RFC1591 as ICANN IPC1 Message-ID: <4.2.0.58.19991004175030.009d3bc0@mail.mindspring.com> FYI: Date: Mon, 4 Oct 1999 11:33:48 -0400 To: poised at lists.tislabs.com From: Gordon Cook Subject: ICANN renames RFC1591 as ICANN IPC1 - implicatons??? Dear Poised list members.... please take a look at http://www.noie.gov.au/docs/gac3min.htm There you will find that: "Mr. Roberts reported that there were no further developments related to the review process for the delegation of management of ccTLDs since the May meeting of the GAC. He said that this reflects the limited resources and funding available to ICANN to address the matter and confirmed that ICANN views the matter as important. He said that the document previously known as "RFC 1591" is now titled "ICANN Policy Document 1" or "ICP 1" and is posted on the ICANN website for reference. He confirmed that ICP 1 does not contain any policy changes from RFC 1591 and is a simple restatement in the new format. " I have some questions for Mr. Roberts and list members. It is well known that the GAC would like to hand countrol of country code TLDs to the national governments of each country. If GAC/ICANN were not prepar ing to asset its own control over RFCs why would GAC/ICANN now be grabbing and renaming RFCs? I would imagine that Roberts and company might not be so foolish as to try to say that IPC1 could take precedence over RFC 1591. But I can see ICANN as part of its on going process of taking more and more authoity on to itsel f as saying: THIS is how we are interpreting the management of county code domains. If the IE TF doesn't agree that is the IETF's problem. After all the IETF is subbordinate to ICANN as one of three protocol supporting oganizations. ICANN will let the IETF keep its RFCs. It will just over ride them at will. Given the ICANN's behavior is this something that the IETF wishes to condone? ---------- Forwarded message ---------- Date: Mon, 4 Oct 1999 09:39:03 -0700 (PDT) From: Mike Roberts To: poised at lists.tislabs.com Subject: Re: RFC1591 and ICANN ICP-1 As was the case with Gordon's last post to POISED, his alleged facts don't match reality very well. If anyone on the list wishes to explore this item beyond the scope of my points below, I'd be happy to discuss it with you offline - see contact info below. - the white paper and the DOC MOU with ICANN explicitly identify TLD delegations as an area of ICANN policy responsibility. We are currently in transition under those various agreements and moving from the era of Jon Postel stewardship of the TLD delegations to one of ICANN responsibility is a task we are now engaged in. The ICANN DNSO has a working group [see dnso.org] focusing on part of the complex issues involved and their recommendations will come to the ICANN Board in due course for further public comment, etc. - as a first step, it was necessary to update and restate the guidance contained in 1591 WITHOUT making any policy changes. This was done last April and May, and the resulting document was discussed by me and others in several meetings in Berlin at the end of May, including the public forum held on the Wednesday. Neither in the meetings in May, nor in the discussions in Santiago in August was there any feedback that ICP-1 was not consistent with previous IANA practice during Jon's management. - RFC-1591 was an informational, not a standards setting RFC. The IETF publishes numerous informational RFC's that meet various needs of the technical community. It was well known that 1591 was a document that Jon used in connection with his personal diplomacy in finding public spirited individuals and organizations around the world that were willing to help spread the Internet by putting up and maintaining a TLD server. ICANN aspires to do as well as Jon did with this task and it won't be easy. - The relationship between ICANN and IAB/IETF is set out in the PSO MOU, and in the exchange of correspondence between Esther Dyson and Brian Carpenter from last winter, which will shortly be the subject of an IAB/IANA MOU. These are public documents, they are not ambiguous, and they do not give any policy role to ICANN in the technical standards setting activity of the IETF. - Mike Roberts ----------- Michael M. Roberts Interim President and Chief Executive Officer Internet Corporation for Assigned Names and Numbers 4676 Admiralty Way, Suite 330, Marina del Rey, CA 90292-6601 +1 310.823.9358 voice +1 310.823.8649 fax http://www.icann.org Office of the Interim President & CEO 339 La Cuesta Drive, Portola Valley, CA 94028 USA +1.650.854.2108 voice / +1.650.854.8134 fax roberts at icann.org -------- Logged at Thu Oct 21 11:10:10 CEST 1999 --------- From rob_bron at nl.ibm.com Thu Oct 21 11:09:42 1999 From: rob_bron at nl.ibm.com (rob_bron at nl.ibm.com) Date: Thu, 21 Oct 1999 11:09:42 +0200 Subject: X-NCC-RegID EU.IBM Reversed address delegation for PI block Message-ID: <80256811.0032563C.00@d06mta01.portsmouth.uk.ibm.com> (Embedded image moved to file: pic15241.pcx) Rob J Bron @ IBMNL 21/10/99 10:09 To: inaddr at ripe.net@internet, tld-wg at ripe.net cc: Franz_Fasching at at.ibm.nl@internet From: Rob J Bron/Netherlands/IBM at IBMNL Hello, Can you please help me with underneath request. Connect Austria obtained 194.24.128 /19 half a year ago. Because RIPE is the authorative point for this IP block, you should be able to arrange: Austria Conect run their own nameservers, and have everything in place, except the delegation of the de reversed arpa delegatipon to the RIPE nameservers ONE would need the reverse delegation for their address range delegated to their nameservers ns1.connect-austria.at 194.232.99.254 and ns2.connect-austria.at 194.232.98.254 their range is (as you know) 128.24.194.in-addr.arpa up to 149.24.194.in-addr.arpa. Can you advise / help us with the above. Thanks in advance Best regards, vriendelijke groeten, Rob Bron Team leader of the EMEA Order Management team http://w3.nl.ibm.com/services/emeaom AT&T Global Network Services Nederland B.V. International Customer Care Processes Boerhaavelaan 11, 2713 HA Zoetermeer, The Netherlands Tel: +31 79 322 2966 - Fax: +31 79 322 4411 E-mail: Rob_Bron at nl.ibm.com - Notes: Rob J Bron/Netherlands/IBM at IBMNL -------------- next part -------------- A non-text attachment was scrubbed... Name: pic15241.pcx Type: application/octet-stream Size: 1522 bytes Desc: not available URL: