ARIN VIII Public Policy Meeting - Miami, Florida - 29-30 October 2001 [Archived]

Table of Contents

Day 1

• Call to Order
• ICANN Update
• ASO AC Report
• ASO AC Election Process
• ASO AC Candidates
• RIR Updates
• Emerging RIR Updates
• Internet Resource Evaluation Process
• Joint RIR Statistics
• Global Coordination
• Early Registration Transfers
• New ARIN Database Status
• IPv6 Working Group
• Open Microphone Session

Day 2

• Call to Order
• CLEW
• RFC 2050 Working Group
• GSM Association
• Universal WHOIS
• RWHOIS Discussion
• Policy Proposal 2001-1
• RTMA Working Group
• Policy Proposal-6
• Policy Proposal-2
• Policy Proposal-5
• DBWG
• Policy Proposal-7 (Bulk copies of ARIN WHOIS DB)
• Open Microphone

Minutes of the Public Policy Meeting

Monday, October 29, 2001

Ray Plzak, ARIN President, opened the first day of ARIN’s public policy meeting at 9:00 AM welcoming all those in attendance and making some announcements. The announcements included:

• A remembrance and moment of silence for Jon Postel (1943 - 1998) and Abha Ahuja (1972 - 2001)
• ARIN VIII has 97 registrants
• 22 US states are represented
• Registered attendees also are from Brazil, Canada, Chile, Japan, Mexico, and the Netherlands
• Registered attendees have 63 different titles - ranging from Registration Coordinator to Director of IP Engineering, and Manager of Compliance to Network Manager
• A description of the meeting’s Internet connectivity and terminal room
• Information about the meeting’s registration services help desk to include the location, schedule, and email address

Ray also introduced the Board of Trustee and Advisory Council members in attendance and reviewed the meeting agenda. The agenda was adopted without change and the meeting proceeded.

ICANN Update

Andrew McLaughlin of ICANN provided an update of his organization’s activities. He explained that ICANN coordinates policies relating to the unique assignment of Internet domain names, IP numbers, and port numbers. Among other things, Andrew also gave an update on the status of protocol parameter assignments by the IANA, including some statistics on what has been issued, the workload involved, and IANA’s processing times. He stated that there have been recent improvements in IANA operations and that work was underway to make even more improvements.

It was noted that there has been a recent change in the ICANN Board with Ken Fockler completing his term and Lyman Chapin taking his vacated seat.

The current areas of ICANN’s policy work were described as:

• Increased attention to security/integrity/resiliency/recovery issues by registries, registrars, and DNS root name servers with mention of DNSSEC
• Support for LACNIC and AFRINIC through the ASO
• Improving IANA performance
• Participation in RFC 2050 review
• Watching IPv6 developments
• ICANN Structure

Andrew concluded by stating the administrative steps of transition from the US Government was largely finished and by noting that the first group of new top-level domains were chosen in November of 2000.

Ken Fockler addressed the audience and described his experiences over the last two years as an ICANN Board member. Ken was thanked for his service as an ICANN Board member selected by the ASO in the ARIN region.

Lyman Chapin introduced himself to the audience and expressed his enthusiasm for the role he will play as an ICANN Board member. He invited people to contact him.

ASO AC Report

Cathy Wittbrodt provided an update of the ASO AC’s recent activities. She explained that the business of the ASO AC was being conducted as usual and noted:

• 2001 General Assembly meeting was held in San Francisco
• ASO AC elected Lyman Chapin
• Kenny Huang was elected as APNIC AC member
• Hans Petter Holen was re-elected as RIPE NCC AC member
• ASO AC is observing progress in the establishment of LACNIC and AFRINIC
• ASO AC codified chair and co-chair roles
• Discussion started to review RFC2050 and its current relation to active policy

Cathy concluded by thanking Raimundo Beca for his efforts on the ASO AC. She also encouraged more ISPs to participate in ICANN meetings.

ASO AC Election Process

Susan Hamlin explained the ASO AC election process by highlighting the voting and election procedures.

Susan concluded by noting the bios and statements of support for the candidates are available on website and that the person elected will represent the ARIN region.

Since none of the candidates were present to introduce themselves, Ray Plzak presented the biography of each of the candidates.

ASO AC Candidates

• Timothy J. Biggs
• Dewey Coffman
• Eric Decker
• Christopher Faulkner
• Greg Hiscott
• Roberto Leon
• Peter Schroebel

RIR Updates

Ray Plzak noted that staff from APNIC and RIPE NCC were not present to give updates. APNIC did send slides to ARIN and asked they be presented. Richard Jimmerson of ARIN presented the APNIC update. The update included a description of recent policy developments in the APNIC region.

Emerging RIR Updates

LACNIC

German Valdez presented the current status of LACNIC.

AFRINIC

There was no one in attendance from AFRINIC to give a report. Responding to a question, Ray Plzak explained that ARIN is participating in a different capacity with AFRINIC. He noted that ARIN attends AFRINIC meetings and that the AFRINIC Board recently reorganized their efforts, and are placing more emphasis in formalizing documentation. The AFRINIC will start out working out of the RIPE NCC as opposed to its own facility, the location of which has yet to be established. Six languages will be recognized, with English being the official language.

Internet Resource Evaluation Process

Richard Jimmerson described the process and displayed the URL where this information could be found on the website.

He enumerated the seven policy proposals that would be discussed during the meeting and provided information regarding their origin.

2001-1 – posted to mailing list
2001-2 – posted to mailing list
2001-3 – ARIN staff received inquiries
2001-4 – discussed over last few years, common statement with 3 RIRs
2001-5 – discussion
2001-6 – mailing list discussion, open microphone at ARIN VII
2001-7 – previously passed policy, wanted to see this expanded

Question:“How do we assess consensus?”

Answer: It is difficult to gauge consensus and sometimes it comes down to a simple show of hands during the public policy meeting, or a virtual vote on a public policy mailing list. It is not always possible to gain 100% agreement. Everyone is encouraged to participate in the policy process.

Joint RIR Statistics

Leslie Nobile presented a summary of the Internet resource allocation statistics of the three RIRs.

Question: What are the current projections for AS Number depletion?

Answer: Nothing is available at this moment, but information will be presented during tomorrow’s RTMA working group session.

Global Coordination

Richard Jimmerson provided an update of ARIN’s global coordination and outreach activities. It was noted efforts in this area were increased over the past year.

Ray Plzak pointed out the new ARIN logo and mission statement displayed on the banner behind the stage.

Early Registration Transfers

Ray Plzak updated the community on the progress of this ongoing project.

Question: Is there an opportunity to use this process to recover unused IP address space?

Answer: We see this as a side benefit of this project. As the opportunity arises, we will do that. The primary goal is to make sure that in-addr.arpa works properly.

New ARIN Database Status

Cathy Murphy presented an update of the database conversion effort.

Leslie Nobile complemented this presentation by giving a preview of the new templates and web interface.

In addition she mentioned there have been some minor updates to the current templates.

Question: Regarding the update to the current templates, how do we fill out section 1? Do we have to check off our service types every time we duplicate section 1 describing a different IP block?

Answer: Every time you duplicate section 1, just check off what type of services you provide.

Question: How do we report a host change for our RWHOIS server?

Answer: Send a message to rwhois@arin.net and identify the new host information.

Question: Why do you differentiate between IPv4 and IPv6 addresses in the current database? Will this continue with the new database?

Answer: There will be no differentiation in the new database, except what the IP address looks like.

Comment: It is a good idea to publicize this and update the documentation for RWHOIS.

It was noted the proper place to provide feedback about the new ARIN templates is the dbwg@arin.net mailing list.

IPv6 Working Group

Thomas Narten, the working group chair, led the IPv6 policy discussions. He began the session by summarizing the policy issues that needed to be discussed. Takashi Arano presented ( View Presentation ) the summary of the IPv6 policy discussion in the APNIC region followed by David Kessens ( Download Presentation) who discussed the IPv6 policy proposals of the RIPE NCC region. Both Takashi Arano and David Kessens are the working group chairs in their respective regions.

The three main issues that were discussed during this session were:

• Suspension of end of bootstrap phase
• Micro-assignments for exchange points and critical internet infrastructure
• General IPv6 registry policies
  • Minimum allocation size
  • How to verify utilization (HD ration or straight percentages)

After the background of the IPv6 policy discussions that had taken place leading up to the meeting had been thoroughly described, the following proposals were made to the working group:

• ARIN policies w.r.t. IPv6 should closely match those of other RIRs
• Differences must be discussed with other RIRs
• IPv6 discussion to be held on the global IPv6 mailing list (global-v6@lists.apnic.net)
• Desirable to have uniform, global policies.

These proposals generated the following comments from the working group:

• It may be “desirable” but not necessarily possible to achieve. We would have to look at examples of where we agree/disagree rather than cast it in stone. We need to talk about it to see where everyone stands.
• Whether or not this is this something everyone believes in, it is necessary we look to uniform, global policies, although it may not be possible.

The working group chair called for a vote to see if there was support for such policies – The result was general consensus that these are good ideas. After the vote, the following comments were made by the working group:

• Minor policy differences amongst the three RIRs are a good thing. It is good to have this as a general goal, but not to be so specific. Allow the more specific things to be locally defined.
• In regard to exchange point policies, micro allocations – The differences are not so important. Global policy is desirable, but not necessarily as important.
• If there are differences, they should be discussed and documented why there are differences. So therefore it does NOT imply that there are NO differences.
• Policy making on the ARIN perspective – difficult enough gaining consensus within ARIN, may be more cumbersome to gain consensus within global scale.

The working group chair reported that the ARIN BoT ratified a policy decision during their August meeting accepting the recommendation of the IAB/IESG in regard to making assignments to end sites and pointed out that all three RIRs are now using this policy.

The working group chair reported that the ARIN BoT suspended the suspension of the bootstrap phase pending further discussion by the BoT in conjunction with the other RIR communities. It was noted all three RIRs have done this pending adoption of new IPv6 policies.

Takishi Arano reported on the discussions that have taken place in the APNIC region. During and after his presentation, the following dialog ensued:

• Definition of dial up user is not clear. – Yes, we should clarify it better.
• In regard to the notion that existing IPv4 providers should get space based on the size of the infrastructure… it is suggested this be calculated based on the size of their subscriber base, not how much IPv4 address space they have. Some have abundance from historical reasons.

David Kessens reported on the discussions that have taken place in the RIPE NCC region. During and after his presentation, the following dialog ensued:

Question: In regard to IPv6 address space for exchanges, were site locals considered?

Answer: We did talk about it. People felt it was a business need to get “real” v6 addresses. You can do it many ways. Consensus was that it was more appropriate to get addresses from the RIR.

Comment: If you can’t route the exchange blocks, this should be brought up in a community like NANOG. Exchanges may want to advertise this downstream to smaller groups. Some companies just want to run blocks and not be beholden to an ISP.

Comment: As a result of a policy, should we somehow create a global, unique, nonroutable space, then perhaps that is larger than the idea initially intended.

Question: If site local is like net10 addresses, why can’t they be used for exchanges?

Answer: There may be conflicts.

Question: What was the reason that you (RIPE NCC) put the exchanges in a special block.

Answer: Filtering – single most important reason.

Comment: In regard to the RIRs making allocations on nibble boundaries, I think it is a really bad idea.

Comment: The RIPE NCC region believed using nibble boundaries would be operationally easier.

Comment: Be careful with allocating space based solely on administrative ease.

Question: Please clarify operational ease. Quantify the benefit versus the downside.

Answer: There are two ways of looking at it. Yes you can do it. But there are lots of simplifications made at the end. It’s easier to make decisions on bit boundaries. It is more about if you have a certain situation then you can go /35 (for example) versus /36.

Comment: I can understand this logic but as you go left, there’s more room for variances.

Comment: As you get to those situations, you may have to deal with different situations and adjust accordingly.

Question: In regard to using slow start, if that’s not what people want, then what was the alternative?

Answer: In the RIPE NCC region, the perfect solution was not discussed. Rather look at your needs for many years and get addresses for that versus one bit at a time. Seemed that most people felt they were against getting one bit at a time versus trying to see the larger scope of your future needs. However, understood that no one can know completely their future needs. Like to see 2-year estimates. Like to see that once people get their initial allocation, they won’t ever need to come back.

Comment: The RIPE NCC region is aiming for final closure on the IPv6 policy discussion by RIPE 41 in January 2002.

Comment: You may not want to push an interim policy too soon, especially when it could cause fragmentation. You might be jumping the gun a bit before the other communities have had a chance to review it.

Comment: The Asian-Pacific region seemed more in need to have this in place than us (RIPE). The RIPE community feels this is important (as seen on the mail list).

Following the updates from the APNIC and RIPE NCC chairs, the ARIN working group chair placed the IPv6 micro-assignment policy proposal on the floor for discussion. The following items were noted:

• Extend IPv4 micro-allocation policy to IPv6
• Policy would apply to:
  • public exchange points
  • gTLDS, ccTLDS, RIRs, and ICANN
• Note: not routable; useful for global reachability?
• Request for address via other policies allowed
• Some list discussion:
  • Why not use site-local addresses?
  • What is benefit, if address is not routable? (e.g., for gTLDs?)
• RIPE will give /48 addresses for IXS
• APNIC agreed to multiple /64s (before discussions at RIPE)
• Proposal for ARIN:
  • Grant micro-assignments for exchanges
  • Either /64 or /48s are fine?
  • Only grant for exchanges, not other uses

The following discussion ensued:

Comment: It seems calling /48 a micro-allocation is wrong.

Comment: Anyone who can prove they need more than /64 can apply to receive a second /64 instead of receiving a /48 by default.

Question: What type of attributes does one want to see a root server fulfill. If a root server is not a part of this policy, then how should roots be addressed as we move forward. Have there been any thoughts on this?

Answer: What does the community think about this?

Comment: Roots should certainly receive routable addresses. There should be some thoughts on how the root operators be allocated space, versus ISPs.

Comment: Yes, this is worth exploring, but there are a lot of issues to be discussed. More details to be discussed and researched. Certainly can see making root servers a special case, but must be careful to determine what others need to be made special cases.

Comment: It seems the APNIC (/64) seems better suited than the RIPE policy, as seen in Japan and LA and some other places. As to root server addressing, the root server advisory committee should take this up.

Comment: There should be some thought given to the definition of an exchange point. It is possible, over time, you will find smaller groups who may want to exchange things, particularly needing IP space that isn’t global.

Comment: Be careful of administrative ease, in the past we have gotten in trouble for doing things just because they were easy.

Following some further discussion, the working group chair asked for a consensus vote: Should ARIN create a special policy for assigning IPv6 address space to exchange point operators?

Yeas: Majority
Nays: one
Abstain: one

Should we first define an exchange point operator?

Yeas: Majority
Nays: none

It was decided by the working group that an exchange point operator must first be defined and then ARIN would move to make a policy. Discussion will take place on the mailing list.

Question: If you are on the ARIN IPv6 mailing list, are you automatically subscribed to the global-v6 list?

Answer: You have to subscribe to both.

The next item of discussion for the working group was general IPv6 allocation policies. The working group chair outlined the following basic principles:

• 5 goals of address policy: uniqueness, registration, aggregation, conservation, fairness
• In IPv4, all should be kept in balance
• In IPv6, higher priority in aggregation, lower in conservation

The chair asked the group if these were reasonable principles. He received the following comments:

Comment: There are lots of places to aggregate – higher priority to aggregation across the board?

Comment: Pay attention to allow the ISP to expand within its block versus having to get another.

Comment: How do we allocate space to ISPs so they don’t fragment? The vast majorities don’t have to deal with ISPs, they have to deal with customers who want to multi-home. It doesn’t matter what we do if we have the same problems with multi-home.

Comment: We should be concerned with the growth of engineered prefixes, not multi-homing. Routing protocols need fixing. We will discuss tomorrow.

Comment: We have some control over the ability to conserve space. No control over allocation of space – ISP control. Can we as ARIN can give priority to one over or rather than (?) another without the control?

Comment: We have the ability to prevent ISPs from aggregation. We should be able to do sparse (reservations without actually doing reservations) allocation.

Comment: We don’t want to make the situation worse. Sparse allocation has a lot of promise – leave room for a lot different things.

Comment: The RIR can influence aggregation, but it is really is up to the ISP. We can help them in their endeavors. The principle definition is to manage the resources that we have. We need to effectively utilize the space. We need to be concerned with conservation.

The working group chair invited discussion about allocation criteria and size.

Initial Criteria

• Organization needs to fulfill the subsequent allocation criteria applied to /36 level.
• Initial allocation – an org that does not have initial allocation and applies for /36 must make sure that they have at least that many customers. The threshold for the first allocation, you’d have to have that many customers in order to get that initial allocation.

Size

• Option 1 (APNIC Consensus) Shorter prefix of either:
  Slow start

The fixed /32 as default, or Evaluation of existing IPv4 infrastructure by RIR if larger space necessary (more can be allocated if an need can be demonstrated)

• Option 2 (Dave Pratt Proposal):
  /28
  Note: /35 is not acceptable since it is not practical by operational point of view

Comment: No advantage to Option 2 if Option 1 is accepted.

Comment: Keeping 4-bit boundary is highly preferable by RIPE community, but it is just preferable and not critical by APNIC community.

Subsequent allocation Criteria

• Option 1 (APNIC consensus)
  Subsequent allocation is allowed when a certain HD-Ratio utilization level is reached. The value of HD-Ratio to apply may be between 0.8-085, which requires the further detailed study to fix it.
• Option 2 (Dave Pratt Proposal):
  Simple 10% utilization (HD-Ratio is complicated, and 210% is about a mean value when taking HD-Ratio of 0.8).

Note: APNIC Community and RIPE community agree to relax the criteria from the current criteria of 80% utilization.

Question: What is the number you’re shooting for and how do you determine that? Are people comfortable with the HD-Ratio?

Answer: Read the RFC. From the formula perspective – if you have enough bits to play enough, then you have a number of bits in the middle to play with. If you have n bits, it allows you to allocate 2n…you get this ratio of 2:1. When you get to 80%, that’s where things get tight. Formula was based on looking on telephone numbers. Can’t compare the utilization rule used historically. The last time HD-Ratio was mentioned at the initial discussion of v6.

Comment: HD-Ratio as a percentage – is not a percentage. I detest using the term “HD-Ratio” because it confuses people. Just by talking in straight percentages, there is a straight correlation of straight percentages and HD-Ratio. 1:1 correspondence in HD-Ratio and percentages.

The working group chair asked the group, “Does anyone have a strong feeling one way or another if utilization is shown as a HD-Ratio or a straight percentage?

Comments from group:

• It makes more sense to put it into something that people can relate to. Put it into a chart versus another mathematical formula. Simpler is better.
• Subjective and HD-Ratio sounds “Precise.” Misleading.
• Stuck on utilization – I’m confused what constitutes “utilization.” How do you tell?
• Other registries don’t have the same situation as ARIN. Seems like ARIN members are more sensitive than other regions.
• HD-Ratio vs. Utilization. Do something different than other Industries? Does this matter?
• Don’t do it different just because it’s different.
• Prefer something that makes it clearer to ARIN customers than just having a uniform global formula. Perhaps have it both ways?

Subsequent Allocation Size:

• Option 1 (APNIC consensus) Shorter prefix of either;
  • Previous (n-1)th allocation size minus 1 as default (any org can obtain, at least, one bit shorter prefix if it satisfies with the HD-Ratio criteria), or
  • Evaluation of two-year demands submitted to RIR if larger space necessary
• Option 2 (DP proposal) between 2 and 5 bits so as to raise the request to the next 4 bit boundary

Note: Keeping 4-bit boundary is highly preferable by RIPE community, but it is just preferable and not critical by APNIC community.

Comments:

• Allocations to ISPs – we should not worry about preserving a nibble boundary. If it works/it works, but we shouldn’t go out of our way for it. (Majority seems to agree).
• Slightly more complex operationally to work without nibble boundaries.
• DNS purposes – may be easier to deal with on a nibble boundary. Is this an all or nothing case?
• Benefit is proportional to the number of those using it.
• Benefit for delegator than the delegatee.

The next step following this policy discussion was described by the working group chair as:

• Follow up discussions on global-v6 list
• Produce revised proposal:
  • Includes more detail
  • Clearly identifies where there is agreement
  • Indicates issues under discussion

Before closing the session, the group expressed an interest in taking a consensus vote on assigning IPv6 address space to exchange point operators. The group was asked if they preferred /48, /64, or no assignments to exchange point operators.

/48: 7 votes
/64: 19 votes
No: 3 votes

Comments:

• No size, depends on how many they’re going to open. Allocation based on whatever is deemed appropriate.
• I prefer a /56, even if they’re wasteful.
• I support /64 for peering mesh, if you need more then you can get another /64. You don’t need a /48.
• We still need a definition of exchange point operator.

Open Microphone Session

There were no comments made during the open microphone session.

Minutes of the Public Policy Meeting, Day 2

Tuesday, October 30, 2001

Announcements and Agenda Review

• Thanks for attending the ARIN VIII Social
• Eric Decker – ASO AC election winner
• Connectivity/Terminal Room information
• Registration Services helpdesk information
• PPM – Tuesday agenda reviewed and adopted

CLEW (Community Learning and Education Working Group)

Bill Darte, the working group chair, described the purpose of CLEW and how it relates to the ARIN mission statement. He encouraged the attendees to use CLEW as a means to express their needs for education in the registry process.

Bill solicited comments from the attendees by asking, “What are some of the tutorials you’d like to see?” An attendee voiced concern over the integrity of the delegations and asked what ARIN plans to do in the area of authentication. Cathy Murphy responded by noting that this subject would be covered in her afternoon discussion.

Bill asked if anyone had an educational suggestion for an operational situation, and encouraged attendees to participate using the CLEW mailing list.

Another attendee pointed out that the problems most people have with the registration process could be solved using FAQs.

RFC 2050 Working Group

Mark McFadden, chairman of this new working group, summarized its charter, explained the discussions that have taken place leading up to this meeting, and identified the milestones.

Mark noted this is an ongoing process and that people should expect these discussions to take place for many months. He stressed the importance of this project and strongly encouraged people to participate.

Question: Citing the process as it currently stands, can you give a realistic timeframe for the completion of the document(s) that might result from this process? Can consensus (due to the broader constituencies) be achieved?

Answer: I think it can be done in 6 months. I think the advice from those participating in the discussion thus far have said you’re nuts to think you can get it done in 6 months. I’m more concerned about the process getting started, rather than when it will be completed.

_ WG Member: _ I think there are other things we need to talk about other than getting together a document. Policy is always changing, so this document needs to be really big, therefore, it loses its usefulness. Policy is different for different registries – different policies for different regions.

_ McFadden: _ Compare policies from different regions. I thought there were many commonalities. You feel differently?

_ WG Member: _ I believe there are glaring differences. I think we should look for a different document to put out. Protocol changes in very discreet sets, ARIN policy is extremely fluid because things change.

_ WG Member: _ I think having a document that can change, with referential components designed in it (ex: if there’s already a doc, reference that doc versus rewriting it), would be good. Deal with basic levels – make a document that can grow (versus static, as 2050 is).

_ WG Member: _ 2050 as a snapshot – a thought of what had occurred at that moment, you can never replace it. Creating another equivalent document – I don’t know if it’s best to create a living document. You might just want to show what’s happening now. Might change focus and gain closure and get document done now.

_ McFadden: _ That is a good point; we may be able to get that done.

_ David Conrad: _ 2050 was actually intended to be a snapshot of the addressing policy of earlier RFCs ridiculously out-of-date,how things actually happened. It still took 2 years to get the document finished. A large part of the delays were results from internal IEFG discussion of were the snapshots were appropriate. I was originally tasked with getting a replacement for 2050 and very quickly determined that it was possible to derive a replacement document within a reasonable amount of time. The regional registries were a much better venue to derive policy docs. Submit a new document to IETF as a “Take it if you want it” document.

_ WG Member: _ I applaud you for taking this on, I think this is a worthwhile venture. I think this is a descriptive document. A snapshot can be useful. A single snapshot will appear just as long-in-tooth as 2050. I think we need to expand that view and know that when this new version gets put to bed, we’ll have to start the next version.

_ WG Member: _ Again, make it a referential document. Summarizes differences, but then direct the reader to documents that explain the differences. Documentary or directives.

The working group chair ended the session by reiterating the importance of working group feedback on the mailing list.

GSM Association – Numbering GPRS Infrastructure and Mobile Terminals

Steve Ali of the GSM Association presented an update of GPRS needs for IP address space. This is the same presentation that was made by Kim Fullbrook during the recent RIPE NCC meeting.. It was noted that a GSM Association document describing these issues was recently published and that a link to it was posted to ARIN’s public policy mailing list for review.

The main points of Steve’s presentation describe that GPRS operators will request IP address space using existing RIR policies and procedures and that mobile terminals will use dynamic addressing, limiting the number of unique IP addresses needed. It was also pointed out that the true requirement of IP addresses for mobile terminals cannot be determined until future applications have been developed.

Attendees thanked him for his update and expressed an interest to learn more about new applications for handsets and their IP address space requirements as they become available.

When asked if the audience believed a special policy should be created for mobile handsets or if a working group should be established for further discussion, it was decided this was not needed at this time and that normal ARIN policies should be applied.

Universal WHOIS

Mark Kosters introduced the topic of a universal WHOIS lookup service and explained why VeriSign was undertaking this new project. VeriSign has committed to this undertaking in an agreement with ICANN and is seeking input and requirements from the RIR communities.

Question: IRRd was not mentioned, will this be addressed?

Answer: This is one of the things that is not a viable solution because it is based on a centralized model, where the various sites must peer with each other, which does not scale very well with a large number of participants.

Question: Will WHOIS output be available in RPSL?

Answer: This is something that will need to be decided during the requirements phase of the project.

RWHOIS Discussion

Cathy Murphy presented the background and status of RWHOIS development by ARIN.

Several people provided feedback on what they would like to see in regards to the further development of RWHOIS. The feedback included:

• Recommended small elegant programs
• Less complication
• Continue to use telnet as the client/server protocol
• Develop easy-to-use, intelligent client option
• Configurable server options to provide greater implementation flexibility
• Documentation, documentation, documentation
• Simplify server administration
• Current software sucks – make it better
• Replace database back-end

Question: Could you describe where the bug fix for the recently discovered RWHOIS exploit can be found?

Answer: Yes. The fix can be found at

http://www.rwhois.net/
ftp://ftp.arin.net/pub/rwhois/rwhoisd-1.5.7.2.tar.gz

Question: Is this a long term project?

Answer: A new beta version should be available by the next ARIN meeting.

Policy Proposal 2001-1 (Reassignments /29 to /28)

David Huberman introduced the proposal and voiced his support by stating that ARIN’s SWIP process is done manually and results in typical lead times of one to four days. He continued by stating that if ARIN were to lessen the burden on the operator by reducing the smallest SWIP size from a /29 to a /28, that this proposal would be worthwhile. David then opened this proposal up to audience discussion.

Members of the audience observed that SWIP was, for the most part, an automated process. Richard Jimmerson provided clarification by stating approximately 90% of SWIP templates are automatically processed, but that there are templates that do require manual intervention. The reason for this manual processing is due to the legacy database and software currently in use and this will be eliminated with the introduction of ARIN’s new database and software.

After a brief discussion of the issues involved, the following questions were asked of the attendees:

If this policy was changed, how many people would continue to SWIP their /29 reassignments? The majority of the audience raised their hands.

Should we change this policy? A minority of the audience attendees raised their hands in support of the policy change. The majority of the attendees raised their hands in opposition to changing the policy.

RTMA Working Group

Working group chair, Cathy Wittbrodt, moderated the session. She began by presenting the first agenda item: Analysis of RIPE / RIS Project’s BGP Data Analysis.

The working group discussion continued with the following policy proposals:

• Policy Proposal 2001-6 (single org with multiple aggregation points)
• Policy Proposal 2001-5 (micro-assignments for multi-homed sites)
• Policy Proposal 2001-2 (multi-homing as justification for /24 reassignments)

Policy Proposal 6 (single org with multiple aggregation points)

Andrew Dull originally proposed this policy during the open microphone session of ARIN VII and later on the public mailing list. He agreed to moderate the policy discussion at ARIN VIII. Andrew used the following slides to describe the policy proposal and generate discussion.

Following Andrew’s presentation, the following discussion took place.

Comment: ARIN allows for multiple maintainer accounts, and must absolutely continue to do so. This policy proposal is a nice addition, but it should not replace the current ability to hold multiple maintainer accounts. It’s really not ARIN’s business so they should not dictate to businesses whether or not they should multi-home, etc.

Comment: When you have multiple maintainer IDs where 2 are at 20%, but 1 is at 90%, when you ask for another block, the 2 at 20% isn’t being looked at. The utilization must be reasonable before asking for another block.

Question: Is there a lot of demand for multiple maintainers ?

ARIN Answer: There are quite a few companies that fall into this category of having multiple maintainer IDs. Many of they have expressed unhappiness with the current policy and would rather not administer multiple accounts with ARIN.

Question: Is this because of cost?

ARIN Answer: Yes. This situation mostly impacts smaller providers.

Comment: There should be economic pushback of sitting on extra address space.

Comment: Perhaps there could be economic pushback within the same maintainer account. If a provider is numbering multiple aggregates within a single account, there could be a fee for each aggregate.

Comment: Perhaps $2,500 per aggregate would be a good fee.

Question: Has ARIN conducted research to determine what percentage of their annual revenue is realized through companies opening multiple maintainer accounts?

ARIN Answer: Yes. They account for 5%.

Comment: If an ISP has 15 POPs connected, they may be able to abuse this proposed policy.

Comment: The language “discrete, autonomous network” is used in this policy proposal, that does not necessarily mean the same thing as a POP. This would prevent abuse.

Question: Will this new policy prevent companies from opening multiple maintainer accounts if they choose?

Answer: No. This policy will allow organizations to de-aggregate under one account, but does not prevent them from opening several accounts, if they choose.

The allowable time for this policy proposal ended and it was decided it was time for the next agenda item to be discussed. Later in the day, during the open microphone session, time was allowed to continue this policy discussion.

Policy Proposal 2001-2 (multi-homing as justification for /24 reassignments)

Lee Howard introduced this proposal and explained that reassigning /24s to downstream multi-homed customers is already a common practice of ISPs. He further explained that under ARIN current policies, ISPs are forced to “lie” to ARIN to allow for appropriate assignments to downstream multi-homed customers.

Lee proposed that multi-homing should serve as justification for a /24 reassignment, regardless of host requirements. Under current ARIN policies, an end-user reassignment must be justified by demonstration of a 25% immediate need for the given assignment size and a forecasted need for 50% of what block was being assigned.

Discussion of this proposal was positive and gained the general support of the meeting attendees. The majority of the meeting attendees raised their hands when asked it they supported this proposal. Only a small number of people raised their hands in opposition to this proposal.

Public Policy 2001-5 (Micro-assignments for multi-homed sites)

Bill Manning summarized the pros and cons of instituting this proposed policy, including comments on potential impact to the global routing table and ARIN staff resources. It was also noted a micro-assignment policy achieved consensus in the APNIC region recently and that it will become effective in December 2001.

Question: Is there any assurance of routability if this policy is passed?

Answer: No. The RIRs do not guarantee the routablility of the IP address space they assign.

Question: What is the benefit of this type of policy?

Answer: I can pay my immediate neighbors for reachability.

It was noted by many meeting attendees that this policy proposal pushes multi-homing and may create an unrealistic expectation of routability, as some providers may decide in the future to filter these addresses, regardless of ARIN allocation policies.

After some discussion, the following question was asked:

Should we adopt the proposal as currently written?

Yeas: none
Nays: majority

Should we permanently shelve this proposal?

Yeas: majority
Nays: none

DBWG – Authorization and Authentication Schemes

Cathy Murphy presented an overview of how authorization will work in the new ARIN database and solicited comments regarding authentication methods.

Question: What if all POCs associated with the organization leave? What is the role of the network POC?

Answer: With regards to changes to the organization record, a special request should be sent to hostmaster, as is the current practice. The network POC would be permitted to provide support for the network record.

Question: Regarding returning address space to ARIN, what would happen if the organization POCs returned the address space prior to leaving the organization?

Answer: Any request to return address space will go through a special verification process.

General attendee comments:

• Public key servers “suck” big time. If you are going to use PGP, it is preferable to make face-to-face exchanges
• Certificates are good
• Suggested that paper based authentication (fax) request be an additional option.

There was general feedback that all authentication methods should be made available by ARIN. The question was asked:

Should ARIN accept every authentication method?

Yeas: a few hands
Nays: a few hands

Those who raised their hands in opposition of accepting all authentication methods identified MAIL-FROM as the objectionable authentication method.

Policy Proposal 7 (Bulk copies of ARIN WHOIS DB)

Richard Jimmerson stated the policy proposal and moderated the discussion that followed.

It is proposed ARIN provide a bulk copy of WHOIS output, minus point of contact information, on the ARIN FTP site for download by any organization that wishes to obtain the data providing they agree to ARIN’s acceptable use policy that would accompany the data.

An attendee commented that as long as the proposed policy retains the “minus POC” language, that he had no objections.

There was further discussion about how the AUP would be agreed to. The language of the current proposal states that the AUP would be attached to the data and that an individual who downloaded it would agree to the AUP by default. One attendee expressed that they felt the requestor of the data should physically sign the AUP and that ARIN should keep this documentation on file.

The attendees of the meeting were asked if they supported the policy proposal, as written.

Yeas: majority
Nays: 2

Open Microphone

Richard Jimmerson asked the audience if there were any ARIN issues they would like to discuss that were not already covered on the agenda.

An attendee stated they had difficulty researching AS registration information using three different RIR WHOIS databases. He wanted to know if the RIRs have plans for a comprehensive whois database that will include registration information from all three RIRs.

Richard explained that the RIRs have talked about this in the past, but that it has not recently been considered a priority. The meeting attendee expressed an interest in this becoming a priority. Richard asked the audience if they agreed this should be made a priority and there was a resounding, “yes.”

Another issue related to WHOIS response time was brought up. Cathy Murphy responded by stating ARIN had added a third WHOIS server earlier this year, but due to hardware issues, it had to be removed from production. Cathy assured the audience that ARIN was aware of the issue and that the third server would be re-added to production soon.

It was agreed that the time remaining in the open microphone session would be used to continue the policy proposal 6 discussion ( View Presentation ).

Andrew placed the policy proposal back on the screen and noted a few changes had been made to the language as a result of the discussion that took place earlier in the day.

The discussion continued, as follows:

Comment: There has to be a way to distinguish who should use this new policy and who shouldn’t.

Question: I’m confused. Does the policy refer to multiple networks or autonomous systems?

Answer: Autonomous systems.

Question: Is ARIN financially dependent on the organizations that pay fees for multiple maintainer accounts?

ARIN Answer: No. These organizations account for only 5% of ARIN’s current revenue.

Comment: It seems there is consensus for this proposal and I’m not looking forward to waiting a long period of time to get this passed. I propose we call for a vote of consensus on the principles of this policy proposal and then send it to the Advisory Council for review and final polishing.

The meeting attendees were asked if they approved of the principles of the policy proposal and that it be forwarded to the Advisory Council for review.

Yeas: majority
Nays: 1
Abstain: 1

Andrew Dul volunteered to post the final language of the proposal to the mailing list and then the advisory council would review it, in accordance with the Internet resource policy evaluation process.

Meeting ends.