From owner-aso-policy@aso.icann.org Fri Feb 4 23:40:16 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id XAA112181; Fri, 4 Feb 2000 23:40:16 +1000 (EST) Received: from sattel1.sat-tel.com (mail.sat-tel.com [206.154.140.2]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id XAA112173 for ; Fri, 4 Feb 2000 23:40:13 +1000 (EST) Received: from sat-tel.com ([208.208.122.149] (may be forged)) by sattel1.sat-tel.com (2.5 Build 2626 (Berkeley 8.8.6)/8.8.4) with ESMTP id IAA01941 for ; Fri, 04 Feb 2000 08:16:09 -0500 Message-ID: <389AD789.41439E64@sat-tel.com> Date: Fri, 04 Feb 2000 08:43:37 -0500 From: Linda Werner X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "aso-policy@aso.icann.org" Subject: [aso-policy] [Fwd: Proposed global policies] Content-Type: multipart/alternative; boundary="------------A1BB621F0547C1917C5C35F3" Sender: owner-aso-policy@aso.icann.org Precedence: bulk --------------A1BB621F0547C1917C5C35F3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Good Morning, > > I agree with the three global policies (listed below) that have been > proposed for adoption. ICANN should only distribute address space to > a > recognized RIR. It is imperative that the RIR approve all address > space > within their region to ensure proper utilization. Any organization > should submit a request for address space to their RIR. The RIR's > will > be unable to ensure proper utilization if organizations are able to > obtain address space by bypassing their RIR > > Best regards, > > Linda Werner > Satellite Communication Systems, Inc. > > Proposed Global Policy > > There are three global policies presented herein that are proposed for > > adoption, as identified below. > > (1) The ICANN distributes address space only to a recognized RIR and > does not > make allocations or assignments directly to any other organization. > > (2) If ICANN, or its affiliates or subordinate entities, is in need > of > address space for its own use, a request will be made to the RIR > responsible for the region wherein the ICANN (or the requesting > entity) > resides. Appropriate criteria, according to established guidelines, > must > be > met in order to receive an allocation. > > (3) If ICANN receives a request directly from another organization, > the > > requesting entity will be referred to the appropriate RIR. > > > > --------------A1BB621F0547C1917C5C35F3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Good Morning,

I agree with the three global policies (listed below) that have been
proposed for adoption.  ICANN should only distribute address space to a
recognized RIR.  It is imperative that the RIR approve all address space
within their region to ensure proper utilization.  Any organization
should submit a request for address space to their RIR.  The RIR's will
be unable to ensure proper utilization if organizations are able to
obtain address space by bypassing their RIR

Best regards,

Linda Werner
Satellite Communication Systems, Inc.

Proposed Global Policy

There are three global policies presented herein that are proposed for
adoption, as identified below.

(1)  The ICANN distributes address space only to a recognized RIR and
does not
 make allocations or assignments directly to any other organization.

(2)  If ICANN, or its affiliates or subordinate entities, is in need of
address space for its own use, a request will be made to the RIR
responsible for the region wherein the ICANN (or the requesting entity)
resides. Appropriate criteria, according to established guidelines, must
be
met in order to receive an allocation.

(3)  If ICANN receives a request directly from another organization, the

requesting entity will be referred to the appropriate RIR.
 
 
 
 

--------------A1BB621F0547C1917C5C35F3-- * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * From owner-aso-policy@aso.icann.org Sun Feb 6 11:29:59 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id LAA116099; Sun, 6 Feb 2000 11:29:59 +1000 (EST) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id LAA116095 for ; Sun, 6 Feb 2000 11:29:56 +1000 (EST) Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id RAA02660; Sat, 5 Feb 2000 17:29:53 -0800 (PST) From: Bill Manning Message-Id: <200002060129.RAA02660@zephyr.isi.edu> Subject: [aso-policy] RIR proposal To: aso-policy@aso.icann.org Date: Sat, 5 Feb 2000 17:29:52 -0800 (PST) Cc: bmanning@ISI.EDU X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aso-policy@aso.icann.org Precedence: bulk I can not support this proposal in its current form. It lacks the perspective needed for long term vison and quick action that is needed by the IANA task to meet fundamental shifts in Internet technology. The bottom-up, membership driven nature of all the RIRs will act as an hindrence to Internet growth if they are the only authorized delegates of IANA delegated address space. The IANA has always had the ability to delegate when reasonable requests were made. This restricts the ability of the IANA to only act as a registar to the RIRs. I believe that this proposal is very shortsighted and do plead with the ASO to consider the ramifications to the Internet if this you endorse this proposal. -- --bill * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * From owner-aso-policy@aso.icann.org Sun Feb 6 21:39:03 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id VAA81984; Sun, 6 Feb 2000 21:39:03 +1000 (EST) Received: from nico.telstra.net (nico.telstra.net [139.130.204.16]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id VAA81971 for ; Sun, 6 Feb 2000 21:39:01 +1000 (EST) Received: from sao (grip.telstra.net [203.10.60.5]) by nico.telstra.net (8.8.8/8.6.10) with ESMTP id WAA06482 for ; Sun, 6 Feb 2000 22:38:58 +1100 (EST) Message-Id: <4.2.0.58.20000206220650.00963bf0@mako1.telstra.net> X-Sender: gih@mako1.telstra.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 06 Feb 2000 22:39:25 +1100 To: aso-policy@aso.icann.org From: Geoff Huston Subject: Re: [aso-policy] RIR proposal In-Reply-To: <200002060129.RAA02660@zephyr.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aso-policy@aso.icann.org Precedence: bulk At 05:29 PM 2/5/00 -0800, Bill Manning wrote: >I can not support this proposal in its current form. It lacks the >perspective needed for long term vison and quick action that is >needed by the IANA task to meet fundamental shifts in Internet >technology. The bottom-up, membership driven nature of all the RIRs >will act as an hindrence to Internet growth if they are the only >authorized delegates of IANA delegated address space. The IANA >has always had the ability to delegate when reasonable requests >were made. This restricts the ability of the IANA to only act as >a registar to the RIRs. I believe that this proposal is very shortsighted >and do plead with the ASO to consider the ramifications to the >Internet if this you endorse this proposal. I would like to respond in support of the proposal in its current form. While some may believe that a bottom up process may have some form of failing in recognizing longer term vision due to the more pressing quality of immeidate needs, there are very grave and serious risks in a single body taking executive action using justification of some form of superior knowledge and foresight without the implicit balances and open debate that are a feature of a open bottom-up process. Historically such measures and assertions of unilateral power have lead us down very dangerous paths, and I believe that it could take IANA and ICANN down a path leading to conflict of interest with the RIRs and the RIR membership. I see that as being most unhelpful. There are of course examples in the past where IANA allocations have been made in a framework where consequent through would suggest an alternative action. Bill note advocates IANA as a place where 'reasonable requests' can be made, predicated that in order for a request to reach IANA the entire RIR structure would've had to have been subverted in some way in order to get to IANA in any case. What is NOT at issue here is the ability of ICANN to set global policy for the RIRs - what IS at issue is that it is then most unseemly for IANA to have some independet ability of allocation OUTSIDE OF THESE VERY POLICIES THAT ICANN WANTS TO IMPOSE ON THE RIRs my emphasis). Of course if the response were to be that the allocations would conform to these policies, then there would be no problem in making the allocation through the RIR structure in the first place, right? I would like also to note that much thought has gone into this proposal, and that thought is based on the RIR policies and processes to date, and based on the acceptance of the ICANN structure into the future. These policies reflect what we have learned about address resource administration in the Internet, and how we manage to strike a balance between the myriad of interests that are at play in this environment. To claim, as Bill does, that IANA somehow needs the reserve ability to exercise resource allocation based on its ability to make hasty decisions with no visible rationale (synonyms for 'quick action' and 'long term vision' I believe) is one which I do not believe is in the best interests of the Internet, nor in the best interests of its panopoly of interested parties. Geoff Huston Member, Executive Committee, APNIC * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * From owner-aso-policy@aso.icann.org Sun Feb 6 23:18:16 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id XAA105553; Sun, 6 Feb 2000 23:18:16 +1000 (EST) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id XAA105540 for ; Sun, 6 Feb 2000 23:18:13 +1000 (EST) Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id FAA21472; Sun, 6 Feb 2000 05:18:03 -0800 (PST) From: Bill Manning Message-Id: <200002061318.FAA21472@zephyr.isi.edu> Subject: Re: [aso-policy] RIR proposal To: gih@telstra.net (Geoff Huston) Date: Sun, 6 Feb 2000 05:18:03 -0800 (PST) Cc: aso-policy@aso.icann.org In-Reply-To: <4.2.0.58.20000206220650.00963bf0@mako1.telstra.net> from "Geoff Huston" at Feb 06, 2000 10:39:25 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aso-policy@aso.icann.org Precedence: bulk % There are of course examples in the past where IANA allocations have % been made in a framework where consequent through would suggest % an alternative action. Bill note advocates IANA as a place where % 'reasonable requests' can be made, predicated that in order for % a request to reach IANA the entire RIR structure would've had to % have been subverted in some way in order to get to IANA in any case. "subversion" is not the issue here. what is important is the fact that fundamental changes in the way addressing is managed have occured with some frequency in the past and there is no reason to believe this will not continue into the future. In the evolution of IPv4, two major shifts included the original imposition of the the subnet model (classes) and then the imposition of CIDR. Both these changes were derived from outside the existent RIR nee IR process and were tested in the engineering community with direct access to the IANA for addressing changes. % What is NOT at issue here is the ability of ICANN to set global % policy for the RIRs - what IS at issue is that it is then % most unseemly for IANA to have some independet ability of % allocation OUTSIDE OF THESE VERY POLICIES THAT ICANN WANTS % TO IMPOSE ON THE RIRs my emphasis). Of course if the response % were to be that the allocations would conform to these policies, % then there would be no problem in making the allocation through % the RIR structure in the first place, right? This is a capability that the IANA has always had. The proposal is asking the IANA to abdicate this flexablity to the RIRs. % I would like also to note that much thought has gone into this % proposal, and that thought is based on the RIR policies and % processes to date, and based on the acceptance of the ICANN % structure into the future. These policies reflect what we have % learned about address resource administration in the Internet, and % how we manage to strike a balance between the myriad of interests % that are at play in this environment. To claim, as Bill does, that % IANA somehow needs the reserve ability to exercise resource allocation % based on its ability to make hasty decisions with no visible rationale % (synonyms for 'quick action' and 'long term vision' I believe) % is one which I do not believe is in the best interests of the % Internet, nor in the best interests of its panopoly of interested % parties. True, much thought has gone into the proposal and I don;t think it should be abandoned. I do believe that the policies reflect the RIR lessons of the commodity Internet and it is reasonable for ICANN to take these types of proposals under serious consideration. After all, ICANN is a very new organisation. However it is prudent to note that the whole RIR structure is of recent vintage as well. My particular RIR is about three years old and the others are roughly the same. The IANA task has had about two decades of experience. So yes, I do think it is wise to allow the IANA to retain its ability to delegate as we have seen in the definition and early deployment of the 6bone, before the RIRs had any understanding of the various issues. There are times when a decision must be made -AND- documented when there is no "visible rationale". The net 39 experiment was one recent example. This would not have happened within the construct of the RIR proposal and without it having been managed by the IANA, the Internet would be much worse off now. I'll agree that the IANA retaining its discresionary capability is a potent tool and that it is reasonable to ask that its use receive careful scrutiny. It is unreasonable to abdicate that capability because the "panopoly" of commercial interests wish a stable future. In a bad light, this could be viewed as an attempt by the RIRs to restrict entry into the address registration arena. % Geoff Huston % % Member, Executive Committee, APNIC Are you speaking for the APNIC EC? --bill * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * From owner-aso-policy@aso.icann.org Mon Feb 7 10:09:56 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id KAA107564; Mon, 7 Feb 2000 10:09:56 +1000 (EST) Received: from nico.telstra.net (nico.telstra.net [139.130.204.16]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id KAA107559 for ; Mon, 7 Feb 2000 10:09:54 +1000 (EST) Received: from sao (scotch-finger.telstra.net [139.130.204.8]) by nico.telstra.net (8.8.8/8.6.10) with ESMTP id KAA08873 for ; Mon, 7 Feb 2000 10:53:38 +1100 (EST) Message-Id: <4.2.0.58.20000207103727.00aca9e0@mako1.telstra.net> X-Sender: gih@mako1.telstra.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 07 Feb 2000 10:54:09 +1100 To: aso-policy@aso.icann.org From: Geoff Huston Subject: Re: [aso-policy] RIR proposal In-Reply-To: <200002061318.FAA21472@zephyr.isi.edu> References: <4.2.0.58.20000206220650.00963bf0@mako1.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aso-policy@aso.icann.org Precedence: bulk At 05:18 AM 2/6/00 -0800, Bill Manning wrote: > "subversion" is not the issue here. what is important > is the fact that fundamental changes in the way addressing > is managed have occured with some frequency in the past > and there is no reason to believe this will not continue > into the future. That may well be the case, but surely the process we should use to undertake such change is one of consultation and discussion, involving, these days, ICANN, the ASO and the RIRs. I fail to understand how IANA making address delegations outside of such agreed processes of consultation and discussion can be helpful to anyone at all. % What is NOT at issue here is the ability of ICANN to set global >% policy for the RIRs - what IS at issue is that it is then >% most unseemly for IANA to have some independet ability of >% allocation OUTSIDE OF THESE VERY POLICIES THAT ICANN WANTS >% TO IMPOSE ON THE RIRs (my emphasis). Of course if the response >% were to be that the allocations would conform to these policies, >% then there would be no problem in making the allocation through >% the RIR structure in the first place, right? > > This is a capability that the IANA has always had. The > proposal is asking the IANA to abdicate this flexablity > to the RIRs. Yes - in the same way that a number of other processes and arrangements are changing with the introduction of ICANN into the picture. Either this envisaged 'IANA flexilibity' is within the scope of ICANN policies regarding address allocation or it is not. If it is within the scope of such policies, then there is no point in IANA undertaking such activity, given that the RIRs already allocate addresses under this very same policy, and do so in a fashion that is properly funded and managed. If such envisaged allocations are to be outside the scope of the ICANN policies, then this is a sure recipe for conflict that places ICANN itself at risk. > ... I'll agree > that the IANA retaining its discresionary capability is > a potent tool and that it is reasonable to ask that its > use receive careful scrutiny. Within the ICANN structure such 'careful scrutiny' falls within the purview of ICANN and the ASO. If this is the case, then ICANN has little choice to place any such 'discretionary' activities under the same policy framework as the RIR activities, and we return to the issue that within the ICANN framework there is no scope for the RIR's supply registry, in the guise of IANA, to make its own direct allocations to end entities. * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * From owner-aso-policy@aso.icann.org Mon Feb 7 15:53:11 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id PAA130051; Mon, 7 Feb 2000 15:53:11 +1000 (EST) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id PAA130042 for ; Mon, 7 Feb 2000 15:53:08 +1000 (EST) Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id VAA19084; Sun, 6 Feb 2000 21:52:58 -0800 (PST) From: Bill Manning Message-Id: <200002070552.VAA19084@zephyr.isi.edu> Subject: Re: [aso-policy] RIR proposal To: gih@telstra.net (Geoff Huston) Date: Sun, 6 Feb 2000 21:52:58 -0800 (PST) Cc: aso-policy@aso.icann.org In-Reply-To: <4.2.0.58.20000207103727.00aca9e0@mako1.telstra.net> from "Geoff Huston" at Feb 07, 2000 10:54:09 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aso-policy@aso.icann.org Precedence: bulk % > is the fact that fundamental changes in the way addressing % > is managed have occured with some frequency in the past % > and there is no reason to believe this will not continue % > into the future. % % % That may well be the case, but surely the process we should use % to undertake such change is one of consultation and discussion, % involving, these days, ICANN, the ASO and the RIRs. I fail to % understand how IANA making address delegations outside % of such agreed processes of consultation and discussion can be % helpful to anyone at all. I'm all in favor of consultation and discussion. Its the "only delegations to RIRs" that bothers me. Where would RFC 1918 space or the link-local delegations rest if the IANA could not delegate to other than RIRs? % Either this envisaged 'IANA flexilibity' is within the scope of % ICANN policies regarding address allocation or it is not. /envisaged/pre-existing/ --bill * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * From owner-aso-policy@aso.icann.org Mon Feb 7 20:28:49 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id UAA85015; Mon, 7 Feb 2000 20:28:49 +1000 (EST) Received: from nico.telstra.net (nico.telstra.net [139.130.204.16]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id UAA85010 for ; Mon, 7 Feb 2000 20:28:48 +1000 (EST) Received: from sao (grip.telstra.net [203.10.60.5]) by nico.telstra.net (8.8.8/8.6.10) with ESMTP id VAA10733 for ; Mon, 7 Feb 2000 21:28:46 +1100 (EST) Message-Id: <4.2.0.58.20000207212158.00adeaa0@mako1.telstra.net> X-Sender: gih@mako1.telstra.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 07 Feb 2000 21:29:14 +1100 To: aso-policy@aso.icann.org From: Geoff Huston Subject: Re: [aso-policy] RIR proposal In-Reply-To: <200002070552.VAA19084@zephyr.isi.edu> References: <4.2.0.58.20000207103727.00aca9e0@mako1.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aso-policy@aso.icann.org Precedence: bulk > I'm all in favor of consultation and discussion. Its the > "only delegations to RIRs" that bothers me. Where > would RFC 1918 space or the link-local delegations rest > if the IANA could not delegate to other than RIRs? I'd like to respond to that question. One can take the position, with some justification, that the decisions in the example are not decision of delegation, but are in effect an undertaking NOT to place such addresses into the allocated address pool, and are in in fact an ourtcome of a common policy NOT to delegate the address space. I do not believe that these examples are contrary to the RIR proposal, in that the RIR proposal addresses (ok - bad pun) the process of address delegation. The structure of the proposal is that IANA is the custodian of the unallocated address space. The proposal is one that advocates that the RIRs are the agents through which addresses are placed into the public routing space through the assignment of addresses to entities. * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * From owner-aso-policy@aso.icann.org Tue Feb 8 08:37:32 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id IAA130804; Tue, 8 Feb 2000 08:37:31 +1000 (EST) Received: from prserv.net (out1.prserv.net [32.97.166.31]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id IAA130798 for ; Tue, 8 Feb 2000 08:37:29 +1000 (EST) Received: from hph ([129.37.76.91]) by prserv.net (out1) with SMTP id <20000207223721252021r4mje>; Mon, 7 Feb 2000 22:37:21 +0000 Message-ID: <01c501bf71bb$e25e09e0$f74c2581@asp.infostream.no> From: "Hans Petter Holen" To: Cc: References: <200002060129.RAA02660@zephyr.isi.edu> Subject: Re: [aso-policy] RIR proposal Date: Mon, 7 Feb 2000 23:35:25 +0100 Organization: Infostream ASP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aso-policy@aso.icann.org Precedence: bulk Bill, your comments are definitely interesting, > The IANA > has always had the ability to delegate when reasonable requests > were made. This restricts the ability of the IANA to only act as > a registar to the RIRs. Do you have any reference to this ? Beeing new to this game I have tried to understand the regime of the past, and the only autoritative document presetnly in place that I have found is RFC 2050 stating: IANA The Internet Assigned Numbers Authority has authority over all number spaces used in the Internet. This includes Internet Address Space. IANA allocates parts of the Internet address space to regional IRs according to its established needs. This text does not limit IANA to only allocate address space to the regionlal IRs, but neither does it specify other means of allocating addresses. Not that I think we should limit this discussion to how it was in the past, but I would sincerely like to understand the history of this subject. Do you have concrete suggestions in how to improve the proposal to accomodate your views ? Sincerely Hans Petter Holen * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * From owner-aso-policy@aso.icann.org Tue Feb 8 08:37:34 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id IAA130822; Tue, 8 Feb 2000 08:37:34 +1000 (EST) Received: from prserv.net (out1.prserv.net [32.97.166.31]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id IAA130806 for ; Tue, 8 Feb 2000 08:37:32 +1000 (EST) Received: from hph ([129.37.76.91]) by prserv.net (out1) with SMTP id <20000207223727252021r4mke>; Mon, 7 Feb 2000 22:37:29 +0000 Message-ID: <01c601bf71bb$e72d6c40$f74c2581@asp.infostream.no> From: "Hans Petter Holen" To: "Bill Manning" , "Geoff Huston" Cc: References: <200002061318.FAA21472@zephyr.isi.edu> Subject: Re: [aso-policy] RIR proposal Date: Mon, 7 Feb 2000 23:37:05 +0100 Organization: Infostream ASP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aso-policy@aso.icann.org Precedence: bulk > "subversion" is not the issue here. what is important > is the fact that fundamental changes in the way addressing > is managed have occured with some frequency in the past > and there is no reason to believe this will not continue > into the future. I agree. > In the evolution of IPv4, two major shifts > included the original imposition of the the subnet model > (classes) and then the imposition of CIDR. Both these changes > were derived from outside the existent RIR nee IR process > and were tested in the engineering community with direct > access to the IANA for addressing changes. > I am not shure I follow you here. Shurely the initiatives for making theese changes came from the engineering communicty but at least the last one, introduction of CIDR was at least in Europe properly discussed and passed trough the regional policy forum at RIPE. The introduction of subnets is way past my time, and I would also argue that is well before a fuctional RIR system was in place. > However it is prudent to note that the whole RIR structure > is of recent vintage as well. My particular RIR is about > three years old and the others are roughly the same. The IANA > task has had about two decades of experience. Here I agree fully. But I wonder: is this due to the function of IANA or to the inight of Jon Postel ? > So yes, I do think it is wise to allow the IANA to retain > its ability to delegate as we have seen in the definition > and early deployment of the 6bone, before the RIRs had any > understanding of the various issues. There are times when > a decision must be made -AND- documented when there is no > "visible rationale". The net 39 experiment was one recent > example. This would not have happened within the construct > of the RIR proposal and without it having been managed by the > IANA, the Internet would be much worse off now. I'll agree > that the IANA retaining its discresionary capability is > a potent tool and that it is reasonable to ask that its > use receive careful scrutiny. It is unreasonable to abdicate > that capability because the "panopoly" of commercial interests > wish a stable future. In a bad light, this could be viewed as > an attempt by the RIRs to restrict entry into the address > registration arena. Interesting toughts, my follow-up question then would be: who is IANA, who will make theese desicions ? - the IANA staff (who may change over time) - the ICANN staff (isn't the IANA staff employees of ICANN ?) - the ICANN board ? - the ASO - the ASO Address Cuncil ? -hph * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * From owner-aso-policy@aso.icann.org Tue Feb 8 22:39:15 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id WAA125271; Tue, 8 Feb 2000 22:39:15 +1000 (EST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id WAA125266 for ; Tue, 8 Feb 2000 22:39:12 +1000 (EST) Received: from ripe.net (x30.ripe.net [193.0.1.30]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id NAA18323; Tue, 8 Feb 2000 13:38:05 +0100 (CET) Message-Id: <200002081238.NAA18323@birch.ripe.net> To: Bill Manning Cc: aso-policy@aso.icann.org Subject: Re: [aso-policy] RIR proposal In-reply-to: Your message of Sun, 06 Feb 2000 05:18:03 PST. <200002061318.FAA21472@zephyr.isi.edu> From: Mirjam Kuehne X-Phone: +31 20 535 4444 Date: Tue, 08 Feb 2000 13:38:04 +0100 Sender: owner-aso-policy@aso.icann.org Precedence: bulk Hi Bill, just for the record: Bill Manning writes: [..] * However it is prudent to note that the whole RIR structure * is of recent vintage as well. My particular RIR is about * three years old and the others are roughly the same. The IANA * task has had about two decades of experience. * The RIPE NCC will celebrate its 8th birthday in April. The APNIC has been established 7 years ago as far as I know. Mirjam RIPE NCC [..] * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * From owner-aso-policy@aso.icann.org Wed Feb 9 03:26:10 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id DAA76369; Wed, 9 Feb 2000 03:26:09 +1000 (EST) Received: from access.cc.univie.ac.at (access.cc.univie.ac.at [192.153.174.2]) by whois.apnic.net (8.9.3/8.9.3) with SMTP id DAA76361 for ; Wed, 9 Feb 2000 03:26:05 +1000 (EST) Received: by cc.univie.ac.at (MX V4.1 VAX) id 16; Tue, 08 Feb 2000 18:25:54 MET Date: Tue, 08 Feb 2000 18:25:52 MET From: "Wilfried Woeber, UniVie/ACOnet" To: bmanning@ISI.EDU CC: aso-policy@aso.icann.org, woeber@cc.univie.ac.at Message-ID: <009E55EA.65283072.16@cc.univie.ac.at> Subject: Re: [aso-policy] RIR proposal Sender: owner-aso-policy@aso.icann.org Precedence: bulk Dear Bill, dear Community, please let me start with a statement of sincere recognition, support and appreciation for what IANA has accomplished in the past and what's going to be added to it's track record ion the future! My comments as attached are in no way meant to insult anyone (as a non-native speaker there's always a potential for misusing words and a danger of embarrassing readers without intention and even without knowing it.) As an introduction, I feel it is appropriate to briefly review history (as good as I can - being a new kid on the block), (my) assumptions, and recent developments (which I had the privilege to observe or be involved with). Read on with a grain of salt. IANA was set up and has got a chance to grow in line with, and in support of, the development of the Internet as we know it today. While it was continuously growing and changing, it was still some sort of a very stable and recognized entity, along- side the development of IETF (and friends), the establishment of ISPs (and commercial service providers, eventually) and the birth of the hierarchical and distributed registry model. This stability was based on and did involve a few aspects: - continuous availability of staff that was recognized as an authority to apply to in case of decisions to be taken - funding stability - "natural feedback loops" with a well-known peer community, including the IETF, the Regional Registries, and the other "implicitely recognized" players in the field. I think many would still take all of those things for granted, and "we" still tend to align our postions to fit that model and those assumptions. But, from my point of view, these assumption do no longer apply, at least not all of them. Why? - As one of the biggest blows, we lost Jon, and we're seeing other more recent changes in IANA staff. - There were fundamental changes in IANA's funding structure, and, most importantly, - we saw the establishment of the RIRs, quite a few years ago, and - we saw the establishment of ICANN and the Supporting Organisations. Ok, after giving you my background on the topic at hand, I'll now go to your comments (which are very much appreciated!). =% There are of course examples in the past where IANA allocations have =% been made in a framework where consequent through would suggest =% an alternative action. Bill note advocates IANA as a place where =% 'reasonable requests' can be made, predicated that in order for =% a request to reach IANA the entire RIR structure would've had to =% have been subverted in some way in order to get to IANA in any case. = = "subversion" is not the issue here. what is important = is the fact that fundamental changes in the way addressing = is managed have occured with some frequency in the past = and there is no reason to believe this will not continue = into the future. This is indeed a prudent assumption. = In the evolution of IPv4, two major shifts = included the original imposition of the the subnet model = (classes) and then the imposition of CIDR. Both these changes = were derived from outside the existent RIR nee IR process = and were tested in the engineering community with direct = access to the IANA for addressing changes. While this (i.e. deriving) might be true [to some degree, only!] I do not see why the same goals, and in particualr the testing, could (should??) not be accomplished while working with the RIRs' constituencies, i.e. the ISPs. What am I missing? =% What is NOT at issue here is the ability of ICANN to set global =% policy for the RIRs - what IS at issue is that it is then =% most unseemly for IANA to have some independet ability of =% allocation OUTSIDE OF THESE VERY POLICIES THAT ICANN WANTS =% TO IMPOSE ON THE RIRs my emphasis). Of course if the response =% were to be that the allocations would conform to these policies, =% then there would be no problem in making the allocation through =% the RIR structure in the first place, right? = = This is a capability that the IANA has always had. The = proposal is asking the IANA to abdicate this flexablity = to the RIRs. Yes, the "old" IANA always has had that "right" and flexibility. As to my knowledge, this right was only exercised in very rare circumstances, and after consulting IANA's "natural" peers. However, I'm of the opinion that this "old" IANA is no longer existing. Whatever IANA is going to evolve into, has to be considered as a part/segment/activity/branch of ICANN. Putting that thought into words makes me recognize even more painfully than before that I'm not aware of a published desription or charter for ICANN within the IANA frame-work. Any pointers to such a document would be very helpful for me. In addition to the more formal and policy-related issues, there's an additional, and more down-to-earth aspect as well: keeping track of address "delegations". Now, let me use the RIR terminology which is more precise, I think. Keeping track of IP address allocations and IP assignments, as well as of AS-Numbers for that matter, is one of the basic responsibilites and services provided by the Regional Registries (aka The Adress Registry). This, in turn is (more or less seamlessly) linked to the components of the Routing Registry. So, to summarize, I do not see IANA being any longer the good old traditional, completely "independent" and "ultimately responsible" entity in a position to conduct it's business (with regard to IPv[46] addresses and AS#s and protocol identifiers) "outside" or "alongside" the established ICANN+SO and RIR frame-work. Quite to the contrary, I do perceive IANA as an integral part of ICANN. And ICANN is a fairly new set-up, with lots of new people in key positions which *do* have their individual wisdom to contribute, their strengths and determination to work for and in the best interest of the Internet. But at the same time, this is no longer the "old IANA". And we have already heard about proposals and/or transactions within ICANN/IANA involving address space, which I think should not be possible without external scrutiny. However, there was a valid point made with regard to technical tests and pilot projects, like Net38 and the IPv6 pTLA environment. I agree that the proposed policy document could benefit from clearly defining what address custodianship by ICANN/IANA stands for, what ICANN's/IANA's role with regard to supporting any new technical proposals or solutions would be and what the on-going collaboration with established technical bodies (like the IETF *and* the RIR constituencies) should look like. =% I would like also to note that much thought has gone into this =% proposal, and that thought is based on the RIR policies and =% processes to date, and based on the acceptance of the ICANN =% structure into the future. These policies reflect what we have =% learned about address resource administration in the Internet, and =% how we manage to strike a balance between the myriad of interests =% that are at play in this environment. To claim, as Bill does, that =% IANA somehow needs the reserve ability to exercise resource allocation =% based on its ability to make hasty decisions with no visible rationale =% (synonyms for 'quick action' and 'long term vision' I believe) =% is one which I do not believe is in the best interests of the =% Internet, nor in the best interests of its panopoly of interested =% parties. = = True, much thought has gone into the proposal and I don;t = think it should be abandoned. I do believe that the policies = reflect the RIR lessons of the commodity Internet and it is = reasonable for ICANN to take these types of proposals under = serious consideration. After all, ICANN is a very new organisation. = However it is prudent to note that the whole RIR structure = is of recent vintage as well. My particular RIR is about = three years old and the others are roughly the same. The IANA = task has had about two decades of experience. Yes, the *old* IANA has had about two decades of experience! But at the same time I'm worried about what the IANA is going to look like in the (near) future, and what it's operational environment would be, eventually. = So yes, I do think it is wise to allow the IANA to retain = its ability to delegate as we have seen in the definition = and early deployment of the 6bone, before the RIRs had any = understanding of the various issues. I can follow and support the lines of thought up to the technical aspects, e.g. early deployment, test-beds, and the like, but I cannot agree to the phrase "before the RIRs had any understanding of the various issues". This wording would suggest that the RIRs have an independent life of their own, without any involvement of and feedback from the technical, ISP and user communities. While I cannot comment on the ARIN and/or APNIC region, I'd say this is not true for the ripe region. *Not at all*!!! = There are times when = a decision must be made -AND- documented when there is no = "visible rationale". The net 39 experiment was one recent = example. This would not have happened within the construct = of the RIR proposal and without it having been managed by the = IANA, the Internet would be much worse off now. I don't agree that it would have been impossible to accomplish the same result while involving the RIRs and/or their constituencies! I'd even venture to say that doing it "the other way 'round" would help to avoid the need for taking decisions without a "visible rationale". But again, I read that as mixing technology development and support for new ideas with address allocations and assignments *for production use*. = I'll agree = that the IANA retaining its discresionary capability is = a potent tool and that it is reasonable to ask that its = use receive careful scrutiny. It is unreasonable to abdicate = that capability because the "panopoly" of commercial interests = wish a stable future. In a bad light, this could be viewed as = an attempt by the RIRs to restrict entry into the address = registration arena. Sorry, I can't follow the logic in that paragraph!? What do you propose? To solve a "restricting entry into the address registration arena" problem by adding *one* registry, i.e. IANA to compete with the RIRs? Or do you propose to treat IP addresses and AS numbers like domain names and create a competitive market for the sale of address space? I'm lost.... =% Geoff Huston =% =% Member, Executive Committee, APNIC = = Are you speaking for the APNIC EC? = =--bill =* on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * =* To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * =-------------------------------------------------------------------------------- My comments so far [ as an AC member (not speaking for any RIR, AC or ASO), the RIPE Database Working Group chair and for ACOnet's Local-IR. ] Wilfried -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 __________________________________________________________________________ * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * From owner-aso-policy@aso.icann.org Fri Feb 11 04:54:34 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id EAA134196; Fri, 11 Feb 2000 04:54:33 +1000 (EST) Received: from access.cc.univie.ac.at (access.cc.univie.ac.at [192.153.174.2]) by whois.apnic.net (8.9.3/8.9.3) with SMTP id EAA78787 for ; Fri, 11 Feb 2000 04:54:29 +1000 (EST) Received: by cc.univie.ac.at (MX V4.1 VAX) id 1; Thu, 10 Feb 2000 19:54:14 MET Date: Thu, 10 Feb 2000 19:54:12 MET From: "Wilfried Woeber, UniVie/ACOnet" To: mmr@darwin.ptvy.ca.us CC: aso-policy@aso.icann.org, woeber@cc.univie.ac.at Message-ID: <009E5789.10F7A3F2.1@cc.univie.ac.at> Subject: Re: [aso-policy] RIR proposal Sender: owner-aso-policy@aso.icann.org Precedence: bulk Mike, thank you for responding, and for making me recognize that - as it often happens even after proof-reading your own stuff more than once - that I used the acronyms the wrong way 'round. Please accept my apologies for that mistake! => => Putting that thought into words makes me recognize even more => painfully than before that I'm not aware of a published => desription or charter for ICANN within the IANA frame-work. => Any pointers to such a document would be very helpful for me. = =There is *VERY* extensive documentation available on the icann web =site. The White Paper, Bylaws, MOU's with US Govt and with ASO, ICP-1 =etc. And the staff is happy to assist with any questions about =charter, etc. Of course you right, but what I wanted to type is "desription or charter for IANA within the ICANN frame-work." Again, sorry for potentially having added to the confusion... Wilfried. * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * From owner-aso-policy@aso.icann.org Fri Feb 11 09:03:14 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id JAA134787; Fri, 11 Feb 2000 09:03:13 +1000 (EST) Received: from darwin.ptvy.ca.us ([192.156.200.1]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id JAA134784 for ; Fri, 11 Feb 2000 09:03:10 +1000 (EST) Received: from [192.156.200.2] (mac.darwin.ptvy.ca.us [192.156.200.2]) by darwin.ptvy.ca.us (8.9.3/8.9.3) with ESMTP id RAA21615 for ; Thu, 10 Feb 2000 17:02:47 -0800 Mime-Version: 1.0 X-Sender: mmr@192.156.200.1 Message-Id: Date: Thu, 10 Feb 2000 15:03:08 -0800 To: aso-policy@aso.icann.org From: Mike Roberts Subject: Re: [aso-policy] RIR proposal Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-aso-policy@aso.icann.org Precedence: bulk At 19:54 +0100 2/10/00, Wilfried Woeber, UniVie/ACOnet wrote: > > > Of course you right, but what I wanted to type is > > "desription or charter for IANA within the ICANN frame-work." > > Again, sorry for potentially having added to the confusion... > Wilfried. One of the things that has been in progress as part of the transition activity with the U.S. Government has been the transfer of the IANA responsibilities which the University of Southern California/Information Sciences Institute carried out under its contract with DARPA, to a new contract between the Department of Commerce and ICANN. That agreement has, after some delay, been completed and posted on our web site. The intent of both the USG and ICANN has been to carry on IANA in the same general manner as was done in the past. The pertinent language in the new contract related to IP addresses is - "the contractor [ ie ICANN] shall perform the following IANA functions: - Allocation of IP address blocks. This involves overall responsibility for the allocation of IPv4 and IPv6 address space. It includes delegations of IP address blocks to regional registries for routine allocation, typically through downstream providers, to Internet end-users within the regions served by those registries. It also includes reservation and direct allocation of space for special purposes, such as multicast addressing, cable blocks, addresses for private networks as described in RFC 1918, and globally specified applications." I believe that this language is consistent with the corresponding portions of the White Paper, the ICANN Bylaws, and the ASO MOU. If you think we need more dialog on the subject of a charter for IANA within the ICANN framework, I would be happy to participate. - Mike -- -- * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * From owner-aso-policy@aso.icann.org Fri Feb 11 09:04:35 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id JAA134806; Fri, 11 Feb 2000 09:04:34 +1000 (EST) Received: from darwin.ptvy.ca.us ([192.156.200.1]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id JAA134802 for ; Fri, 11 Feb 2000 09:04:31 +1000 (EST) Received: from [192.156.200.2] (mac.darwin.ptvy.ca.us [192.156.200.2]) by darwin.ptvy.ca.us (8.9.3/8.9.3) with ESMTP id RAA21619 for ; Thu, 10 Feb 2000 17:04:09 -0800 Mime-Version: 1.0 X-Sender: mmr@192.156.200.1 Message-Id: Date: Thu, 10 Feb 2000 15:04:30 -0800 To: aso-policy@aso.icann.org From: Mike Roberts Subject: Re: [aso-policy] RIR proposal Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-aso-policy@aso.icann.org Precedence: bulk At 18:25 +0100 2/8/00, Wilfried Woeber, UniVie/ACOnet wrote: > Dear Bill, > dear Community, >=% What is NOT at issue here is the ability of ICANN to set global >=% policy for the RIRs - what IS at issue is that it is then >=% most unseemly for IANA to have some independet ability of >=% allocation OUTSIDE OF THESE VERY POLICIES THAT ICANN WANTS >=% TO IMPOSE ON THE RIRs my emphasis). Of course if the response >=% were to be that the allocations would conform to these policies, >=% then there would be no problem in making the allocation through >=% the RIR structure in the first place, right? This language confuses the present situation. Under the White Paper, the ICANN Board is responsible for setting global address policy. It does that, in part, based on recommendations of the ASO Council. The ASO Council is responsible, under its MOU with ICANN, for collecting, analyzing and formulating recommendations on address policy. The various staff components involved, for the Council, for the RIR's, for ICANN/IANA, are charged with carrying out approved policy. Since ICANN and its Supporting Organizations are new and still in transition from old arrangements, most of what we do in coming months will represent fresh steps forward. That should neither inhibit work that needs doing, nor foster actions that have not been thoughtfully considered. > > > Putting that thought into words makes me recognize even more > painfully than before that I'm not aware of a published > desription or charter for ICANN within the IANA frame-work. > Any pointers to such a document would be very helpful for me. There is *VERY* extensive documentation available on the icann web site. The White Paper, Bylaws, MOU's with US Govt and with ASO, ICP-1 etc. And the staff is happy to assist with any questions about charter, etc. - Mike Roberts -- -- * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * From owner-aso-policy@aso.icann.org Sun Feb 13 21:54:50 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id VAA157784; Sun, 13 Feb 2000 21:54:50 +1000 (EST) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id VAA157781 for ; Sun, 13 Feb 2000 21:54:47 +1000 (EST) Received: from sao (gunk.telstra.net [203.10.60.2]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id WAA24070; Sun, 13 Feb 2000 22:54:48 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.2.0.58.20000213222744.009abcb0@mako1.telstra.net> X-Sender: gih@mako1.telstra.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 13 Feb 2000 22:55:10 +1100 To: aso-policy@aso.icann.org From: Geoff Huston Subject: Re: [aso-policy] RIR proposal Cc: Mike Roberts In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aso-policy@aso.icann.org Precedence: bulk Mike's posting included the following:.... >"the contractor [ ie ICANN] shall perform the following IANA functions: > > > > - Allocation of IP address blocks. This involves overall responsibility > for the allocation of IPv4 and IPv6 address space. It includes > delegations of IP address blocks to regional registries for routine > allocation, typically through downstream providers, to Internet end-users > within the regions served by those registries. It also includes > reservation and direct allocation of space for special purposes, such as > multicast addressing, cable blocks, addresses for private networks as > described in RFC 1918, and globally specified applications." and noted: >I believe that this language is consistent with the corresponding portions >of the White Paper, the ICANN Bylaws, and the ASO MOU. > >If you think we need more dialog on the subject of a charter for IANA >within the ICANN framework, I would be happy to participate. Not wishing to curtail what could be a productive potential area of dialogue, could I perhaps request one dialogue at a time? At least within the aso-policy at any rate. The subject of the ASO discussion at this point is not the contract between ICANN and Commerce - the discussion is one of the method by which ICANN discharges this function. Let me omit the term 'IANA' `for a second, and phrase the salient points of the RIR proposal: - ICANN discharges its responsibility to undertake the allocation of IP address blocks through the structure of the Regional Registries. - The Registries undertake their function within the framework of global address allocation policies endorsed by ICANN. The point we have been debating for the past few days is the note from Bill Manning that within the scope of the RIR proposal there should be some ability for ICANN to make address allocations outside of the RIR structure. The grounds for such ability have been cited as a desire to allow some allocations to be undertaken hastily (ok, thats a pejorative phrasing :-), I'll accept 'in a timely manner' as an alternative characterization) and outside of the normal scope of ICANN policies and RIR practices (ditto, the term 'flexibility' wcan be used instead). The grounds against such an ability, and in favour of the RIR proposal, have been cited as follows: Allowing such 'quick' and 'flexible' additional allocations to be undertaken by ICANN outside of the RIR practices would be contrary to the concept of a single policy structure for address allocations (lack of policy coherence), contrary to the concept of placing all address allocations to end parties on a uniform footing (lack of fairness), and having due process for all address allocations (lack of accountability and openness). That's where I see we are at the end of a week's dialogue as far as I can tell. I'm unclear how a charter for IANA within the ICANN framework would assist in the further consideration of the RIR proposal at this juncture in terms of the current ASO policy dialogue on this particular topic. regards, Geoff Huston * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * From owner-aso-policy@aso.icann.org Tue Feb 15 05:16:36 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id FAA165925; Tue, 15 Feb 2000 05:16:36 +1000 (EST) Received: from access.cc.univie.ac.at (access.cc.univie.ac.at [192.153.174.2]) by whois.apnic.net (8.9.3/8.9.3) with SMTP id FAA165920 for ; Tue, 15 Feb 2000 05:16:30 +1000 (EST) Received: by cc.univie.ac.at (MX V4.1 VAX) id 3; Mon, 14 Feb 2000 20:16:04 MET Date: Mon, 14 Feb 2000 20:16:03 MET From: "Wilfried Woeber, UniVie/ACOnet" To: mmr@darwin.ptvy.ca.us CC: aso-policy@aso.icann.org, woeber@cc.univie.ac.at Message-ID: <009E5AB0.C80D06F2.3@cc.univie.ac.at> Subject: Re: [aso-policy] RIR proposal Sender: owner-aso-policy@aso.icann.org Precedence: bulk Mike, thank you very much for this clarification: >One of the things that has been in progress as part of the transition >activity with the U.S. Government has been the transfer of the IANA >responsibilities which the University of Southern >California/Information Sciences Institute carried out under its >contract with DARPA, to a new contract between the Department of >Commerce and ICANN. That agreement has, after some delay, been >completed and posted on our web site. Could you please provide me/us with some information about the time-lines involved that led to signing that contract? I suppose this contract has already been completely negotiated and has been ready for signing for quite a while, and in particular, since well before the establishment of the ASO MoU and the AC? Is that correct? > The intent of both the USG and >ICANN has been to carry on IANA in the same general manner as was >done in the past. Is this a strictly bi-lateral agreement, that ICANN and the USG agreed upon? > The pertinent language in the new contract related >to IP addresses is - > >"the contractor [ ie ICANN] shall perform the following IANA functions: > > > > - Allocation of IP address blocks. This involves overall >responsibility for the allocation of IPv4 and IPv6 address space. It >includes delegations of IP address blocks to regional registries for >routine allocation, typically through downstream providers, to >Internet end-users within the regions served by those registries. It >also includes reservation and direct allocation of space for special >purposes, such as multicast addressing, cable blocks, addresses for >private networks as described in RFC 1918, and globally specified >applications." Ahhh, so this has already been set in stone - although using some sort of fuzzy terminology - what the responsibilties are that ICANN has accepted. Still, I don't fully understand what IANA's future role is going to be when ICANN is "the contractor". But that's probably just me... >I believe that this language is consistent with the corresponding >portions of the White Paper, the ICANN Bylaws, and the ASO MOU. > >If you think we need more dialog on the subject of a charter for IANA >within the ICANN framework, I would be happy to participate. > >- Mike Regards, Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 __________________________________________________________________________ * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * From owner-aso-policy@aso.icann.org Tue Feb 15 05:53:25 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id FAA90528; Tue, 15 Feb 2000 05:53:25 +1000 (EST) Received: from darwin.ptvy.ca.us ([192.156.200.1]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id FAA166063 for ; Tue, 15 Feb 2000 05:53:21 +1000 (EST) Received: from [192.156.200.2] (mac.darwin.ptvy.ca.us [192.156.200.2]) by darwin.ptvy.ca.us (8.9.3/8.9.3) with ESMTP id NAA25425; Mon, 14 Feb 2000 13:52:50 -0800 Mime-Version: 1.0 X-Sender: mmr@192.156.200.1 Message-Id: In-Reply-To: <009E5AB0.C80D06F2.3@cc.univie.ac.at> References: <009E5AB0.C80D06F2.3@cc.univie.ac.at> Date: Mon, 14 Feb 2000 11:53:12 -0800 To: "Wilfried Woeber, UniVie/ACOnet" From: Mike Roberts Subject: Re: [aso-policy] RIR proposal Cc: aso-policy@aso.icann.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-aso-policy@aso.icann.org Precedence: bulk At 20:16 +0100 2/14/00, Wilfried Woeber, UniVie/ACOnet wrote: > Mike, > Is this a strictly bi-lateral agreement, that ICANN and the USG > agreed upon? Yes, although the contract also says: "This purchase order, in itself, does not authorize the contractor to make substantive changes in established policy associated with the performance of the IANA functions. Procedures for policy development will remain the subject of a Joint Project Agreement (JPA) between DOC and ICANN. The JPA contemplates that the policy-development procedures developed under the JPA may result in adoption of new or changed policies concerning Internet technical management functions. To the extent those policies require alterations in the manner in which the IANA functions are performed, those alterations may be implemented upon mutual agreement of the parties." Since the Joint Project Agreement between the Department of Commerce and ICANN is based on the White Paper, and since the ICANN Bylaws are based on the White Paper, the net result is that, with respect to IP Address Policy, the ICANN Board will act to adopt or revise address policies within the framework of its Supporting Organizations and in particular, the ASO MOU, which lodges first order responsibility for study, analysis, public review, and recommendation on address policy with the ASO Council. While the JPA is in effect, the USG retains a right of review of ICANN actions in order to ensure that the objectives of the White Paper are achieved. > Still, I don't fully understand what IANA's future role is going to > be when ICANN is "the contractor". But that's probably just me... > IANA has been, and still is, among its other duties, responsible for day to day administration of IP address policy, working as part of a "food chain" that also includes the staffs of the RIR's and, farther downstream, the staffs of ISPs and other organizations receiving address allocations. Its staff is part of ICANN and the address policies it carries out are those adopted by the ICANN Board after a public process has occurred, including recommendations from the ASO Council and other SO Councils as appropriate. The ICANN staff members with responsibility for IANA-related actions include Louis Touton, Joyce Reynolds, Suzanne Woolf, and Michelle Schipper. - Mike -- * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * From owner-aso-policy@aso.icann.org Tue Feb 15 06:08:26 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id GAA91219; Tue, 15 Feb 2000 06:08:25 +1000 (EST) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id GAA166126 for ; Tue, 15 Feb 2000 06:08:17 +1000 (EST) Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id PAA15392; Mon, 14 Feb 2000 15:08:14 -0500 (EST) Received: from jazz (jazz.arin.net [192.149.252.195]) by ops.arin.net (8.9.0/8.9.0) with SMTP id PAA12567; Mon, 14 Feb 2000 15:08:14 -0500 (EST) Message-Id: <4.1.20000214145310.00c386f0@192.149.252.141> X-Sender: kimh@192.149.252.141 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 14 Feb 2000 14:57:37 -0500 To: Mike Roberts , "Wilfried Woeber, UniVie/ACOnet" From: Kim Hubbard Subject: Re: [aso-policy] RIR proposal Cc: aso-policy@aso.icann.org In-Reply-To: References: <009E5AB0.C80D06F2.3@cc.univie.ac.at> <009E5AB0.C80D06F2.3@cc.univie.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aso-policy@aso.icann.org Precedence: bulk At 11:53 AM 2/14/00 -0800, Mike Roberts wrote: >At 20:16 +0100 2/14/00, Wilfried Woeber, UniVie/ACOnet wrote: > >Since the Joint Project Agreement between the Department of Commerce >and ICANN is based on the White Paper, and since the ICANN Bylaws are >based on the White Paper, the net result is that, with respect to IP >Address Policy, the ICANN Board will act to adopt or revise address >policies within the framework of its Supporting Organizations and in >particular, the ASO MOU, which lodges first order responsibility for >study, analysis, public review, and recommendation on address policy >with the ASO Council. While the JPA is in effect, the USG retains a >right of review of ICANN actions in order to ensure that the >objectives of the White Paper are achieved. And yet there's no mention of the ASO anywhere in this contract. Kim > >> Still, I don't fully understand what IANA's future role is going to >> be when ICANN is "the contractor". But that's probably just me... >> > >IANA has been, and still is, among its other duties, responsible for >day to day administration of IP address policy, working as part of a >"food chain" that also includes the staffs of the RIR's and, farther >downstream, the staffs of ISPs and other organizations receiving >address allocations. Its staff is part of ICANN and the address >policies it carries out are those adopted by the ICANN Board after a >public process has occurred, including recommendations from the ASO >Council and other SO Councils as appropriate. The ICANN staff members >with responsibility for IANA-related actions include Louis Touton, >Joyce Reynolds, Suzanne Woolf, and Michelle Schipper. > >- Mike >-- >* on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * >* To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * From owner-aso-policy@aso.icann.org Wed Feb 16 12:18:51 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id MAA85112; Wed, 16 Feb 2000 12:18:49 +1000 (EST) Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id MAA85106; Wed, 16 Feb 2000 12:18:47 +1000 (EST) Received: from guardian.apnic.net (guardian.apnic.net [203.37.255.100]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id MAA85102 for ; Wed, 16 Feb 2000 12:18:44 +1000 (EST) Received: (from mail@localhost) by guardian.apnic.net (8.9.3/8.9.3) id MAA13589; Wed, 16 Feb 2000 12:18:40 +1000 (EST) Received: from hadrian.staff.apnic.net(192.168.1.1) by int-gw.staff.apnic.net via smap (V2.1) id xma013587; Wed, 16 Feb 00 12:18:32 +1000 Received: from wilson (wrk-8.staff.apnic.net [192.168.1.71]) by hadrian.staff.apnic.net (8.9.3/8.9.3) with SMTP id MAA17463; Wed, 16 Feb 2000 12:18:32 +1000 (EST) From: "Paul Wilson" To: Cc: "Jun Murai" , "Pindar Wong" , "Takashi Arano" , "Hyunje Park" , , , "Kilnam Chon" , "Izumi AIZU" Subject: [aso-policy] [aso-announce] APRICOT2000: ICANN Update Session and BOF - 1 March 2000 Date: Wed, 16 Feb 2000 12:18:33 +1000 Message-ID: <007f01bf7824$1f63e760$4701a8c0@wilson.staff.apnic.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-aso-policy@aso.icann.org Precedence: bulk APRICOT2000, Seoul, Korea 28 February - 2 March 2000 http://www.apricot2000.ne.kr === Announcement: Asia Pacific ICANN Update Sessions ALL WELCOME! Panel Session - Wednesday 1 March, 16.00 to 17.30, "Art Center 1" room. Evening BOF - Wednesday 1 March, 18.30 to 20.00, "Cosmos" room. The 90-minute "ICANN Update" panel session will feature reports from Asia Pacific participants in the Internet Corporation for Assigned Names and Numbers (ICANN) and its associated Supporting Organisations, providing a comprehensive update on developments within ICANN from an Asia-Pacific perspective. Six to eight presentations will be possible in the time available, of around 15 minutes each. Time permitting, questions will be fielded from the audience, however further questions and informal discussion will continue in the evening's BOF (Birds of a Feather) session. AGENDA - ICANN UPDATE PANEL SESSION 1. ICANN History overview Izumi Aizu 2. ICANN Board report Jun Murai 3. Names Council report Youn Jung Park 4. Address Council report Takashi Arano 5. DNSO Constituencies report Youn Jung Park 6. DNSO Constituencies report Hirofumi Hotta 7. DNSO Constituencies report Kilnam Chon Panel Chair: Paul Wilson APNIC / ASO Secretariat Panel Members confirmed: Jun Murai ICANN Board Pindar Wong Vice-Chair, ICANN Board Takashi Arano Address Council Hyunje Park Address Council Youn Jung Park Names Council - ncdnh Hirofumi Hotta Names Council - ispcp Kilnam Chon APTLD, DNSO - cctld Izumi Aizu APIA Note: Protocol Council members were invited to participate, however none were able to confirm attendance at APRICOT. === * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-announce * * To unsubscribe: send "unsubscribe" to aso-announce-request@aso.icann.org * * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * From owner-aso-policy@aso.icann.org Thu Feb 17 18:46:45 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id SAA132913; Thu, 17 Feb 2000 18:46:45 +1000 (EST) Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id SAA132912; Thu, 17 Feb 2000 18:46:43 +1000 (EST) Received: from guardian.apnic.net (guardian.apnic.net [203.37.255.100]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id SAA70889 for ; Thu, 17 Feb 2000 18:46:41 +1000 (EST) Received: (from mail@localhost) by guardian.apnic.net (8.9.3/8.9.3) id SAA07323 for ; Thu, 17 Feb 2000 18:46:38 +1000 (EST) Received: from hadrian.staff.apnic.net(192.168.1.1) by int-gw.staff.apnic.net via smap (V2.1) id xma007321; Thu, 17 Feb 00 18:46:36 +1000 Received: from wilson (wrk-8.staff.apnic.net [192.168.1.71]) by hadrian.staff.apnic.net (8.9.3/8.9.3) with SMTP id SAA17917 for ; Thu, 17 Feb 2000 18:46:35 +1000 (EST) From: "Paul Wilson" To: Subject: [aso-policy] [aso-announce] ASO General Assembly and Call for ICANN Board nominations Date: Thu, 17 Feb 2000 18:46:34 +1000 Message-ID: <000101bf7923$7e93b990$4701a8c0@wilson.staff.apnic.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-aso-policy@aso.icann.org Precedence: bulk ANNOUNCEMENT: ASO General Assembly for 2000 and Call for ICANN Board nominations The Address Council of the Address Supporting Organisation is pleased to announce the first ASO General Assembly meeting, to be held on Friday 19 May 2000, in Budapest, Hungary. This meeting will be hosted by RIPE NCC alongside the RIPE-36 meeting, and will be open to all parties with an interest in ASO policy matters. A detailed meeting agenda will be published in due course on the ASO web site, at http://www.aso.icann.org In compliance with the ASO MoU (http://www.aso.icann.org/docs/aso-mou.html), the Address Council and ICANN hereby call for nominations to the ICANN Board, of candidates to fill vacant ASO seats on the ICANN board as they become vacant. The first such seat scheduled to become vacant is currently occupied by Mr. Pindar Wong, who will stand down on 2 November 2000 (the 12 month anniversary of his appointment). However, candidates nominated at this time may also be chosen to fill seats which become vacant before or after this time. Note that appointments to the ICANN board must satisfy the geographic diversity constraints specified in section 3c of the ASO MoU. Any individual may be nominated within this process, with the exception of any official of a national government or a multinational entity established by treaty or other agreement between national governments (ICANN Bylaws Art. V., Sec 5.). Self-nominations are permitted. Nominations should be sent by email to and should state the following details : A. Nominee details 1. Full name 2. Organisational affiliation 3. Email address 4. Physical address 5. Country of residence 6. Telephone contact 7. Biography B. Details of nominating individual 1. Full name 2. Organisational affiliation 3. Email address 4. Country of residence Nominations must be submitted in English and must be received by the ASO Secretariat before 0900 GMT 19 April 2000 (30 days prior to the General Assembly meeting). After nomination all nominees will be contacted via email to confirm their willingness to serve as an ICANN Director. If the nominee is not contactable via email then the nomination will not be confirmed, and nominee must explicitly confirm the nomination for the nomination to be considered confirmed. All confirmed nominations will be listed on the ASO web site (see http://www.aso.icann.org) as soon as they are confirmed. Those wishing to express support for any individuals who have been nominated should use the "ICANN Board - Support of Nomination" Form which will be made available on the ASO web site. The list of nominated individuals and the supporting comments will be passed to the Address Council after all nominees are confirmed, and prior to the General Assembly meeting on 19 May 2000. More information regarding the GA and nominations process will be posted to the ASO web site (http://www.aso.icann.org) in due course. END ______________________________________________________________________ Paul Wilson, Director-General, APNIC http://www.apnic.net ph/fx +61 7 3367 0490/82 ---------------------------------------------------------------------- See you at APRICOT 2000! 28 Feb - 2 Mar http://www.apricot2000.ne.kr ---------------------------------------------------------------------- * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-announce * * To unsubscribe: send "unsubscribe" to aso-announce-request@aso.icann.org * * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * From owner-aso-policy@aso.icann.org Sun Feb 27 00:10:09 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id AAA73471; Sun, 27 Feb 2000 00:10:08 +1000 (EST) Received: from online.no (pilt-e.online.no [148.122.208.24]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id AAA188975 for ; Sun, 27 Feb 2000 00:10:03 +1000 (EST) Received: from hph ([195.225.6.229]) by online.no (8.9.3/8.9.1) with SMTP id PAA21722 for ; Sat, 26 Feb 2000 15:09:55 +0100 (MET) Message-ID: <00bf01bf8063$2511bba0$e506e1c3@asp.infostream.no> From: "Hans Petter Holen" To: Subject: [aso-policy] Fw: Use of IP6.INT Date: Sat, 26 Feb 2000 15:07:54 +0100 Organization: Infostream ASP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aso-policy@aso.icann.org Precedence: bulk FYI, this is perhaps more standards related than policy related, and it will be usefull to keep the discuission withing the IETF. -hph ----- Original Message ----- From: "Thomas Trede" To: Sent: Thursday, February 24, 2000 9:00 AM Subject: Fw: Use of IP6.INT > FYI. > > Regards, > Thomas Trede > > ----- Original Message ----- > From: "Steve Deering" > To: > Cc: "Bob Hinden" > Sent: Wednesday, February 23, 2000 7:15 PM > Subject: Re: Use of IP6.INT > > > > Based on the email exchange a couple weeks ago, regarding placing the new > > bitstring-based reverse DNS lookup tree under .arpa instead of .int, we > > appear to have rough consensus that such a change would create no > technical > > problems and negligible deployment or operational impact at this point. > > Therefore, the chairs propose to tell the IAB and IESG that we are willing > > to make such a change in draft-ietf-ipngwg-dns-lookups-nn.txt, if they > > request it. If there are any previously unvoiced (un-emailed?) objections > > to doing that, please speak up *now*. > > > > By the way, of the two proposed suffixes (.ip6.arpa or .in6-addr.arpa), > > are there any good reasons to prefer one over the other? > > > > Bob and Steve > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org * From owner-aso-policy@aso.icann.org Sun Feb 27 08:40:49 2000 Received: (from majordom@localhost) by whois.apnic.net (8.9.3/8.9.3) id IAA191030; Sun, 27 Feb 2000 08:40:49 +1000 (EST) Received: from mako1.telstra.net (mako1.telstra.net [203.50.0.28]) by whois.apnic.net (8.9.3/8.9.3) with ESMTP id IAA191026 for ; Sun, 27 Feb 2000 08:40:47 +1000 (EST) Received: from sao ([203.10.60.4]) by mako1.telstra.net (8.9.2/8.9.2) with ESMTP id JAA57234; Sun, 27 Feb 2000 09:40:10 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <4.2.0.58.20000227093407.00c46a40@mako1.telstra.net> X-Sender: gih@mako1.telstra.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 27 Feb 2000 09:40:32 +1100 To: "Hans Petter Holen" From: Geoff Huston Subject: Re: [aso-policy] Fw: Use of IP6.INT Cc: In-Reply-To: <00bf01bf8063$2511bba0$e506e1c3@asp.infostream.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aso-policy@aso.icann.org Precedence: bulk It may be that the ASO could endorse a proposal to use the .arpa domain for the v6 reverse address mapping function, and this endorsement be passed to ICANN. Of course all this assumes that this proposal becomes the recommendation of the IETF, and until the relevant drafts have moved through the working group and the IESG the topic may be a wee bit premature for the ASO. * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-policy * * To unsubscribe: send "unsubscribe" to aso-policy-request@aso.icann.org *