ASO Open Input Forum

Stockholm, 2 June 2001

    1. Hans Petter Holen (HPH) as the chair of the Address Council gives an update of the AC

Ken Fockler comments that an important task of the AC is the election of ICANN Board members. One important reason for being. Ken asks why the AC decided to put a fair amount of details in the resolution for the Emerging RIRs as recommendation for ICANN. Also wonders what the sequence should be when evaluating applications from emerging RIRs: should the staff deal with it and inform the board about it or should the board receive the application and then decide if they want to direct the staff to evaluate it.

HPH clarifies that it was not the intention to pre-define the sequence of evaluation-steps, this is also up to the board.

Louis Touton expects the AC to work together with ICANN when the case arises.

Azuzena Hernandez from Telefonica Spain (newly elected by ETSI on the Protocol Council) asks what criteria the AC is using for the ICANN board elections.

HPH explains that the AC is looking for a candidate that will be a good ICANN board member in general as well as someone who has an understanding of the ASO issues.

    1. Mark McFadden: Tilting at Windmills – Is Revising RFC2050 Possible?

      • RFC to set principles/technical boundary conditions
      • Global policy document (like the matrix – which is mostly the new RFC2050) which describes allocation policies based on these principles
      • Specific regional documents that describe the procedures used to ensure that these policies are followed.

Mirjam Kuehne believes that there is consensus that the IETF is not the place to make policy, they are there to define technical boundaries and principles. Maybe an RFC is not the best place for IP allocation policies. One reason RFC2050 was actually written because InterNIC/ARIN did not have a policy document. In the meantime, the way policies are developed have become much clearer:

Mark clarifies that he did not mean to suggest to publish the new document as an IETF document.

David Conrad (DRC): noone was particularly exited about RFC2050. He strongly recommends to keep the interaction with the IETF as little as possible. He describes how the process went at the time, it was a long and difficult process. The RIR structure itself is capable to define policies. He also does not believe that there is actually the need for a major effort to re-write this document.

Azuzenza thinks that this is the task of the ASO, it has nothing to do with the PSO or the IETF. Suggests to just abolish the document, if it is out of date. Move it to historic status.

HPH clarifies that policies in the RIPE region do not refer to RFC2050 in many places. Richard Jimmerson confirms that also ARIN does not refer to RFC2050 expect in one area of end-user assignment policies.

Ray Plzak stresses that the RIRs have structures in place to describe policies. RFC2050 should be moved to historic. Let the RIRs publish a principles document and publish it as Internet Draft, then the community can work on it. Also the matrix doc shows that the RIRs together (i.e. the ASO) have mechanisms in place to develop and describe policies.

Paul Wilson confirms that the APNIC also does not refer to RFC2050. Suggests to move it to historic.

Mark believes that there is a need for a global policy document and that the RIRs are providing them. The RIRs are already doing this without anyone from the outside to have to push them.

Paul suggests to use RFC2050 only as background document for new documents.

Louis also stresses that the IETF is not the appropriate place to make IP address policies, everyone seems to agree with that. As said before, the RIRs have mechanisms in place. Mark had mentioned that RFC2050 does not describe RIR operations. But the emerging RIRs doc contains many RIR operations and the existing RIR apply them. He does not agree with Marks approach. Ken agrees.

Barbara Roseman points out that the policy matrix doc refers to RFC2050. Ray clarifies that it refers to the principles in the RFC only. Maybe this needs to be re-stated.

HPH thinks Marks approach is more complicated than necessary.

DRC believes that just abolishing the document would bring out a lot of criticism. Mirjam and Ray agree that new documents need to be in place before and mention that the RIRs are working on this.

Mark wonders what is the way forward. Louis suggest to just let everyone in the ASO work on their various projects and then review it when they are done.

Richard also suggests to let the RIRs work on a doc that states the principles.

HPH wonders if a process is needed by which ASO docs are written.

Mark strongly objects to the way by which the RIRs go away and work on a document. This is not open and transparent. Suggests to have open input forums at ICANN meetings and Regional policy meetings.

Richard notes that this is already happening.

Mirjam explains that the RIRs never just go away and make policy, they just write up what is discussed in the open forums.

Rob Blokzijl believes that the way policies are developed is a valid one and works on a global scale. It is not worth discussing this all over again. We have had these discussions and most people are happy with the way it works.

Barbara believes that the policy comparison matrix a good document, it brings out the differences between the RIRs as well as the policies they have in common.

Maruyama asks who will take the lead in re-writing those documents.

Barbara says that the RIRs are suggesting that they will drive that process.

Paul would be happy to have Mark come to the APNIC and ask for input. If it would be suggested that the RIRs will work on it however, the RIRs will of course be duly bound to it.

    1. Mark McFadden: enum – a US perspective

      • Decided that there should be a common approach – only 1 TLD, no split root!
      • Should be a opt-in model.
      • Should have a single TIER 1 administrator for all of the 14 countries.
      • How is it ensured that the end-user has authority about his or her data
      • Disagreement: in the US there are a number of people that advocate competitive enum zones. Others think this is bad and believe there should be only one enum zone, otherwise there will be DNS conflicts and results cannot be ensured. Mark is a strong believer in the single e164.arpa approach
      • What about countries that want to chose another approach under a different domain name (how would that be possible?)
      • Some people object to have the domain name under .arpa. It is associated with USG (even though this is not true anymore). There are proposals to put it under .int or create a new root or create a new TLD. Mark believes there is still a lot of education to do and it has been agreed to do also use ICANN meetings for that.

Technology is there, protocol RFC2916 works fine. We now need to implement it. There are still issues about implementation details. ITU WG decided that all implementation details are national issues, not international or ITU issues. US set up an ad hoc working group to give suggestions to the USG on how to implement this. Similar efforts are underway in other countries.

The situation in the US is more complicated, because +1 represents 14 countries.

Recommendations made to the USG:

Open issues:

Suggested to set up an independent not-for-profit in the US to handle administration of +1.

Suggested to create an ENUM forum potentially sponsored by industry members. They would develop Tier 1 architecture and administration.

DRC adds that arpa now stands for “Address and routing parameter area” in order to reflect what the domain is used for.

Last modified on 03/03/2020