ARIN XIII Public Policy Meeting Minutes, Day 2, 20 April 2004 [Archived]

Call to Order and Announcements

Speaker: Richard Jimmerson, ARIN Director of Operations

Presentation (Read-only): PDF

Richard opened the second day of the ARIN XIII Public Policy Meeting at 09:00 PDT. Announcements included thanking Shaw Communications and Big Pipe, Inc. for their sponsorship of the Terminal Room and partial sponsorship of the ARIN social, Telus Corporation for its sponsorship of ARIN’s 5th Annual Foosball Tournament and breakfasts, and Peer 1 Network for its sponsorship of today’s afternoon break.

Richard offered information on the Terminal Room/Learning Center, the ARIN Help Desk, and the ARIN XIII meeting survey. He announced that there had been one agenda change, in that the ICANN Update, which was scheduled for the day before, would be done this morning.

John Curran, as Chairman of the Board, moderated discussions throughout the day.

Policy Proposal 2004-2: Use of HD Ratio for IPv4 Allocations

Introduction: Einar Bohlin, ARIN Policy Analyst

Presentation (Read-only): PDF

• Posted by author - February 6, 2004
• Policy Proposal Introduced - March 17, 2004
• PPML Summary
  • 16 posts
  • 9 different people
  • Initial Discussion:
    • Good idea in general, but there’s concern that large ISPs will be more lax in their IP management.
    • Perhaps we should just relax the 80% to 60%?
  • Additional Discussion: 6 posts, 5 people
    • This is optional, an ISP can choose to be evaluated by the HD ratio

Presenter: Michael Dillon, author

Presentation (Read-only): PDF

Michael presented background on the idea behind offering this proposal. He also provided information on possible impacts following its passage and a detailed description of how to calculate the HD ratio, as outlined in his proposal.

Highlights:

• Use HD ratio paradigm, outlined in IPv6 policy, for IPv4.
• Organizations would still have to meet utilization threshold.
• Benefits increase rapidly as an ISP grows to mid-sized, but policy benefits are not just for large ISPs.
• HD ratio is meant to recognize the fact that overhead increases as amount of allocated space increases.
• The .930 ratio on the most recent block received allows operators to show that they are deploying the last allocation, but avoids unnecessary brinkmanship with their change control timing.

Comments:

• Statements For and Against:

  • People, in general, are going to get lost with something this complicated. This would act as more of a deterrent, with ARIN being the big man on the hill. The way things work now is fine, and this policy would create problems as it would ramp up. One possible effect would be that some companies would have more lax records of their IP utilization. Michael responded that “people in general” will not have to deal with this, only ARIN members, and this policy would only affect the ARIN-ISP relationship.
  • This policy would be hampered by people reading the policy and being confused by using logarithms and the complexities of the math. This would result in ARIN having to deal with an increased load of phone calls.
  • I am undecided about this, and while ARIN’s staff is very busy, this policy would not be impossible to implement. I have four customers who have /20s and they don’t like to do cleanup, so this policy would benefit them. However we don’t know all the effects of the six-month supply policy, so changes at this point might be premature. Michael Dillon responded that to address the new 6-month window, it does increase the planning horizon, but this policy is intended more to ease the burden of overhead for organizations with large, hierarchical networks.
  • As a large ISP, this proposal could only benefit me, and I should agree with it because it seems that looking at the numbers, it makes it easier the larger you get. However, I don’t think we should make policies to accommodate the shortcomings of internal policies at ISPs. The current policies work at all levels as far as I can see, and I don’t really see the point of this proposal. This sounds like something that needs to be addressed within your own company and not taken care of in an ARIN policy. If this proposal were adopted, I could literally strand millions of IP addresses in reserve and still meet the requirements to get more space, as it only gets easier the larger the organization is. This is an irresponsible approach.
  • With an 80% threshold, you are talking about 4/5 of the time, so that gives you a little more than a month to get your act together on IP addresses at a 6-month utilization. That seems like it ought to be enough time.

• Questions/Responses/Clarifications:

  • John Curran asked for feedback from ARIN staff about potential challenges in implementing this proposal. Richard Jimmerson, on behalf of ARIN, replied that if there were a defined point, like .966, that we were using, there would be no challenges at the staff level.
  • I have no specific problem with this proposal, but I question why we need it. It is not really that hard to get to 80%. What is the need that this policy is trying to address? Where are the concrete examples of organizations that are broken because of this? Michael replied that the current 80% threshold is really saying that you have to draw down your available pool to 20% before you can apply for more. There is a turnaround time with ARIN of anywhere from three days to weeks. Even with the policy change to being able to request a six-month supply of addresses, this is still a very painful process. Because of infrastructure and organizational requirements it can take 90 days at my company to deploy addresses. Our network is fairly good sized, and there is a lot of overhead.
  • How much of an effect would this policy have on ARIN having to educate ISPs? How much would this increase ARIN’s workload? Richard Jimmerson, on behalf of ARIN, responded that ARIN would publish tables showing the accepted HD ratio percentages for various size address blocks and that education of ISPs would take some small effort, but nothing strenuous. Richard went on to say that this policy would probably cause more phone calls and that, if passed, ARIN would publish a page on its website devoted to answering questions about this policy. Leslie Nobile, ARIN Director of Registration Services, added that the increased phone calls would have to be addressed by retraining both staff and customers, even if the policy were only optional, and that the overall impact would be huge.

• Suggestions:

  • I have no general problem with this policy, though it does seem you are asking ARIN to change to accommodate your company’s own broken mechanisms. I do have a problem with the .930 ratio [on the most recently received allocation]. I would want a last block ratio that was less lax. I would prefer something like .95 instead of .93.
  • After the [WSIS] discussions yesterday, we should all realize how important perceptions are, though of course we can’t let perceptions drive all of our decisions and policies. If this proposal is ratified, and ARIN puts up a chart on its website showing that the larger the address space you have, the easier it becomes to get more, this could be misconstrued by people who do not take the time to understand the basis of this. They would then start saying how much favoritism there is for large companies. As an option for consideration, if the current flat 80% rate is onerous, maybe we should review that and lower that rate, rather than provide a scale based on size.

Polling of consensus:

Question : Approve of Policy 2004-2?
Yes? 1 No? 22

Policy Proposal 2004-1: Defining Utilization of IPv4 Addresses

Introduction: Einar Bohlin, ARIN Policy Analyst

Presentation (Read-only): PDF

• Posted by author - February 11, 2004
• Policy Proposal Introduced - March 17, 2004
• PPML Summary
  • 12 posts
  • 8 different people
  • Initial Discussion:
    • Should definitions be in policy?
    • This would seem to be a necessary and well constructed policy.
    • The proposal does not seem to state anything new.
  • After formal posting to PPML
    • No discussion.

Presenter: Michael Dillon, author

Michael presented the proposal.

Highlights:

• A lot of people do not understand how the utilization rate for blocks allocated to an ISP is calculated.
• Not currently spelled out in ARIN policy.
• Basically this is a codification of how I believe ARIN staff already does this calculation.
• This policy proposal is not meant to change any existing ARIN policy.

Comments:

• Statements For and Against:
  • I don’t believe this proposal is complete. When I used to do this, I would require my customers to justify their requests per RFC 2050 initial utilization and provide ongoing utilization and network diagrams, because when I would go to ARIN for more address space, they would sometimes ask for this information. It was not enough to say “here is your block, you better use it efficiently,” I actually had to have information from the customers about their plans to use the space and what their actual utilizations were. The current ARIN policy also points to RFC 2050, and that seems to be what is missing regarding providing utilization information.
• Questions/Responses/Clarifications:
  • My only concern is in paragraph 2, as it says that a block is not utilized if you had to use it for your own infrastructure and I believe that is a mistake [in terms of current ARIN policy]. Michael replied that it did seem to be a mistake and that he would rely on the AC to address the exact wording.
  • I would like some analysis by ARIN staff as to how closely this proposal matches current policy. Are there any changes to what is in practice now? And as a corollary, is this simply a definition of terms, and if so, would the forthcoming glossary we heard about address the need for this? Richard Jimmerson, on behalf of ARIN, replied that there are a lot of things ARIN asks for when evaluating the utilization of address space by organizations. This information is outlined on ARIN’s website, but perhaps not in the detail people would like. I am not speaking for or against the policy, but perhaps what we need is a guidelines page that clearly defines exactly what ARIN staff asks for. Some of these things can be better defined in the glossary. It is true, for instance, that if an ISP allocates or assigns a block of addresses to a downstream, and it does it in the appropriate manner, that full block is considered utilized. I do not know if this is specifically stated anywhere on the website.
  • Do you think it is important that this show up as a policy statement, or is it sufficient that it be clarified in a glossary and other existing documents? Michael responded that he believed it was important that things like this be explicitly stated in policy so that the staff is actually implementing the policy. Michael went on to say that things like this should flow from the policy and that was why he made the proposal.
  • How do the plans to make RFC 2050 obsolete relate to this policy? Would this policy help in that effort? Richard Jimmerson, on behalf of ARIN, responded that ARIN staff has recently completed an analysis of RFC 2050 in comparison to current ARIN policy. In that analysis it was apparent that there are going to be areas of RFC 2050 that will need to be extracted and made into ARIN policy before we can retire the RFC or we are going to need to refer to an obsolete RFC in our policy documentation. Not all of the areas in RFC 2050 that are not reflected in current ARIN policy cover utilization, but some of them do.

Polling of consensus:

Question : Approve of Policy 2004-1?
Yes? 5 No? 1

RTMA Working Group

Presenter: Cathy Wittbrodt, Working Group Chair

Cathy announced that due to lack of interest and involvement, the working group will be dissolved. The RTMA mailing list will still exist and the routing table updates will still go out. In addition, Cathy announced that the work she had been doing relating to this working group would probably continue, but that there seemed to be no interest in keeping RTMA as an active working group.

Comments:

• No comments from the floor

Near-Real-Time Publication of Allocated Netblocks

Presenter: Leo Bicknell, ARIN AC

Presentation (Read-only): PDF

Leo Bicknell, as a member of the ARIN Advisory Council, gave a presentation on this topic. Leo made clear that while this was not a policy proposal, the ARIN AC and staff were looking for input from the community about this issue.

Highlights:

• Network and server operators would like to filter/restrict access from unallocated netblocks.
• Currently, services exist that take RIR data and produce near-real-time reports in other formats.
• The problems with this are:
  • Not all parties are willing to trust these “intermediate” sources
  • Translation from existing RIR formats can cause delays/errors
  • Often include additional information not related to unallocated netblocks
• ARIN could provide its own “trustworthy” information in additional formats, though this would require 24x7 service for a real-time feed and ARIN would have to expend resources to accomplish this.
• Unless other RIRs offer a similar or coordinated service, it’s unlikely those who want the data would bother with “ARIN Only” data.

Comments:

• Do you propose a feed of allocated prefixes or a feed of unallocated prefixes? Leo replied that this is a question still to be resolved and asked the audience for a preference.
• From my perspective, the most useful format for this feed would be BGP of the unallocated space. It would also be desirable if there were a way for the people who have received allocations from ARIN to inject their end-user assignment data or lack of assignment data back into that feed. However, I do see a lot of liability and trust issues that evolve from that. It would be worthwhile for ARIN to look at this issue, take it on as a research project, and take the lead in seeing if we can develop something useful because I think it would be good for the community in general.
• As soon as we start getting into this, we’re going to find that it is more complex than we hoped for. However, I think something like this is something ARIN should go forward with, as it is closer to the source data. I very much support this sort of work.
• I also support this kind of work. This is important because ARIN is the source of the information and it should be our duty to provide this information in the formats that are appropriate and useful. It is important for the community to look long term at protocols and what should be done in authenticating route announcements and their sources. The lack of an authoritative source of information could stifle several applications and protocols because no one will have the ability to authenticate the sources and have a central look-back point. Not a simple issue, but its importance and value mean that it is something the community needs to take seriously.
• I also support this work. I think it is a great idea for ARIN to be involved. On the issue of publishing the unallocated or allocated prefixes, I think publishing both would be a great idea. It would allow third-parties to compare the data sets and establish greater trust as to their accuracy. In fact, there may be other attributes of the address blocks that ARIN could publish. Each format so far mentioned for the feed could have issues, but there are a variety of formats for this data that could be explored.
• Cathy Wittbrodt, of the ARIN AC, stated that this would seem to be something that should also be brought up at the NANOG meeting in May 2004. I am wholly in favor of this in some incarnation and was wondering if people agreed it should be brought up there. She volunteered to do this if people thought it was a worthwhile exercise.
• One thing that strikes me about this is that people seem to be focused on IPv4 with this, and I was wondering if there would be a scaling issue if it was implemented in IPv6. Just something to think about long term.
• I am in favor of this. It is better to have an official source for this kind of information. It would also be best to publish in more than one format, as it would help verify the accuracy of the data.
• Scott Bradner, Secretary of the ARIN Board of Trustees, brought up that the AC charter does not include defining work items for staff, which is what this would entail. He went on to say that it doesn’t mean that the AC shouldn’t do it. If the Board of Trustees wants the AC to examine the issues here and to make a suggestion, then the Board would need to formally request that the AC do that.
• One suggestion as to how some of this might be implemented is that it could be handled like the root servers, where ARIN is not directly buying the hardware and such, but where they would control the hardware and distribution of the feed. This might reduce the cost and ongoing maintenance issues. I am sure we would have no problem finding people willing to host these machines.
• These particular sets of issues have surfaced a couple of times in years past, and asking ARIN to take on this task is a fine thing, but to really work, each ARIN member should use the same processes to announce what we have assigned, as a space management tool. So I would request that if ARIN staff is going to spend time on this that they develop tools that members can use for managing their space.
• I am in support of this with coordination among the RIRs. On the point of data delivery, when this is brought to NANOG, we might want to consider using the anycast protocol to allow for better security and to mitigate attacks against this data.

ICANN Update

Presenter: Paul Verhoef, Vice President for Policy Development Support

Presentation (Read-only): PDF

Paul Verhoef, on behalf of ICANN, provided a presentation on recent ICANN achievements and activities, as well as a general overview of ICANN’s operations and structure.

Highlights:

• ICANN has completed its organizational restructure and recruitment effort.
• Formation of At-Large structures.
• Opened new office in Brussels, Belgium.
• Work on MoU extension/finalization.
• ICANN has been in consultation with many organizations, across many different levels of joint interest.
• Developed strategic plan with prioritization of activities.
• Challenges for ICANN include: operational credibility, consensus building, and lack of widespread agreement on its role.

Comments:

• You mentioned that you might have 8 to 10 people eventually working in your office in Brussels. What would they be doing? Paul responded that he expected a number of them to be involved in the policy development process, and that there would likely be 1 to 2 people doing IANA-related work as well. Paul went on to say that because of time zones, staff there would increase the amount of coverage available, and some technical back-up might prove useful. He added that they have not worked through all the issues yet, but that is the general outline of what they currently have in mind.

Database Implementation Working Group (DBWG)

Presenter: Cathy Murphy, ARIN Principal Software Engineer

Presentation (Read-only): PDF

Cathy Murphy, on behalf of ARIN and standing in for Ginny Listman, ARIN’s Director of Engineering and Working Group Chair, presented an update on ARIN database issues, including an engineering update and NRO technical coordination.

Highlights:

• Database cleanup, including converting detailed reassignments to simple reassignments.
• New Disaster Recovery Plan for ARIN external services (DNS, FTP, web, WHOIS, RWhois, Routing Registry, Mail).
• Referral Server Field is currently informational WHOIS display only. The next step is to use referral server attribute to generate root RWhois referrals, which will require notification of address holders with existing RWhois referrals.
• Various proposals on DBWG with regard to the referral server attribute.
• The NRO Engineering Coordination Group has been formed to work on joint engineering issues, such as Joint WHOIS, CRISP, and ERX.
• Early Registration Transfer (ERX): Transfer of early registrations in classful B address space is now completed. Early registrations of classful C address space are next.
• New POC types proposed during the CA tutorial on Sunday. Further discussion will take place on the DBWG mailing list.

Comments:

• I guess there is some interest in [adding referral server attribute to network records], but ARIN staff would be the ones to know whether you have any organizations that want only one of their networks on RWhois and not any other ones. Have there been any requests like that? Cathy responded that except for one individual, ARIN has not seen a whole lot of support indicated. Richard Jimmerson, on behalf of ARIN, added that he believed the only feedback ARIN has received on this issue was from the original policy proposal, and then only from one person. He added that he was unsure about making these additional changes based on the feedback from a single individual.
• These attributes only affect people using RWhois, right? What percentage of ARIN subscribers are actually using RWhois anymore? Cathy responded that there are about 250 organizations who have registered RWhois servers now in WHOIS, though we have not done a comparison between how much reassignment information there is and how much is actually in WHOIS. That is something we can do and post to the DBWG mailing list.
• How many of those 250 organizations have RWhois servers that are responsive right now? Cathy replied that ARIN has not done testing recently, but in the past it surveyed and found about 30 responsive servers, which is about 15%.
• My company is implementing an RWhois server that will be available 24x7, and I think it would be valuable to have the referral server on the network record. However, not all of the netblocks in our organization use RWhois, and we may still choose to SWIP some of those records. This process would also enable us to migrate networks from the ARIN WHOIS to our RWhois.
• Do you think that having the operational server requirements of RWhois servers put in policy will actually help those running RWhois servers? I think people will either say “Okay, I have to keep these things up and running,” or they will just go back and start using SWIP. Cathy responded that ARIN doesn’t really know, but current practice for many is to turn their RWhois servers on only when they come to ARIN to get their next allocation and then they turn them off again. So if policy proposal 2003-5 is passed and they are required to keep them up all the time, and there is a concern over customer privacy, that might reduce the number of organizations using RWhois. Any other predictions would be pure speculation at this point.
• I just want to remind everyone that the referral server policy was intended not only for WHOIS, but for any future protocol that will replace it, like CRISP. So whatever we are doing right now should not only address the current situation, but should also address the needs of people using future protocols to have the tools available and that they are easy to use.
• We do have an operation impact concerning this, and we need to have a policy in place that deals with this now and we need to move forward with this.
• In regards to CRISP, and specifically the IRIS protocol, you might mention how to use it and things like that. The Internet drafts on these topics are available by going to IETF web pages mentioned in the presentation and going down to the bottom of the page.

DBWG - Cryptographic Authentication

Presenter: Tim Christensen, ARIN Database Administrator

Presentation (Read-only): PDF

Tim presented an update on the status and implementation of Cryptographic Authentication (CA) at ARIN. His presentation provided the background of ARIN CA, an X.509 authentication overview, CA’s current status, and next steps.

Highlights:

• The community asked for authentication choices including passwords, PGP, and X.509. ARIN evaluated these methods to determine which should be completed first and chose X.509. Other appropriate methods will be implemented in succession, followed by an analysis of how well the implementation went, and then we will move on to the next one. Once this is done, and the level of adoption is looked at, we will consider deprecating MAIL-FROM authentication at ARIN.
• X.509 authentication mechanism has been deployed. Several POCs are in the process of adopting X.509 strong authentication at this time.
• ARIN conducted a CA workshop in Vancouver on Sunday, April 18, 2004. Templates, FAQs, and other resources are available at http://ca.arin.net/request .
• The next steps, within the implementation of X.509, are to expand use of X.509 certificates to include more POCs, not just POCs associated with Subscriber Members. Use of certificates within the ARIN website is also planned.

Comments:

• Are other RIRs doing a similar thing and is there a plan for cross-certification between the RIRs? Tim responded that the other RIRs have deployed X.509 certificates for various purposes. On the second point of cross-certification, there are currently no plans to do that, but it is something we can explore and may happen within the context of the NRO Engineering Coordination Group.
• One of the things I think we need to be careful about, in regards to cross-certification, is the issue of liability as we do not want to be dependent on other parties.

Policy Proposal 2003-16: POC Verification

Introduction: Einar Bohlin, ARIN Policy Analyst

Presentation (Read-only): PDF

• Introduced - August 11, 2003
• Presented at ARIN XII
• Revised March 22, 2004
• PPML Summary
  • No discussion on PPML

Presenter: Andrew Dul, ARIN AC

Andrew presented information on the proposal.

Highlights:

• During ARIN XII, there seemed to be consensus that the text of this policy needed to be clarified. The AC then developed new text for the policy, and that is what is now being presented.
• A question for this meeting is whether there exists consensus that we need to move forward with the process of verification of Points of Contact (POCs).

Comments:

• Statements For and Against:

  • The only concern I have is that the policy does not define any kind of rate-limiting, so that if individuals wanted to abuse the process by taking up staff time or the time of POCs, they could. For example, someone could continually request POC verification. Andrew responded that the text did have a reference to a reverification window of 1 year, but he believed that had now been changed to 3 months or it may have been removed. If someone wanted to abuse this process, they could under this policy. [Andrew Dul later corrected his statement to say that the current proposal has a verification window of 6 months.]
  • One of the problems is that many do not know that ARIN does verify POC information on its own, and they do not know how to contact ARIN about this issue. This policy would publicize this process, and if a POC is marked as verified in WHOIS, people will not submit a report that it is invalid. Richard Jimmerson, on behalf of ARIN, replied that ARIN does receive notification from members of the community about out-of-date POC information through [email protected]. After receiving these notifications, ARIN staff investigates, and if they are unable to verify the information, they add a note to the comments field that is displayed in WHOIS output.
  • I do not have anything against ARIN doing this type of thing, but I am not sure it needs to be spelled out in policy. We should not get down to this level of micro-management of ARIN staff activities. However, it does seem reasonable that ARIN verify POC information and publish information denoting the success of that verification.
  • The goal of this is not necessarily to have it in policy, but that people are able to know that ARIN does do reverification of POC information and are able to submit complaints through a special form on the ARIN website. Richard Jimmerson, on behalf of ARIN, replied that ARIN does receive reports about these issues, and asks that the organizations update their information. If ARIN staff is unable to verify the information, it is noted in WHOIS. ARIN also has other projects that address this issue, such as the database cleanup Cathy Murphy mentioned during the DBWG Update. ARIN does not have an ongoing project where we are continually verifying POC information. Richard also added that as footer to every WHOIS answer, there is a statement that says “If contact information is out of date or incorrect, please contact [email protected]. Include all relevant information in your e-mail and ARIN will investigate the matter.”
  • A possible benefit of this policy is that the community would be able to see that ARIN has, in good faith, attempted to verify information. However, I think that 6 months is too aggressive, and needs to be rethought.

• Questions/Responses/Clarifications:

  • Why is this significantly better than the current process of e-mailing it? This proposal makes specific mention to a web form. Andrew responded that the policy was describing the internal ARIN process, and that it simply meant that ARIN staff would make this information available to the public, rather than ARIN independently verifying the POC’s information.
  • Does ARIN staff have any estimate as to the impact this would have on its operations? Andrew replied that the AC did ask the staff what the impact would be after ARIN XII and they prepared a report. After consulting with staff, I posted an edited version of the report to the mailing list a number of months ago and I do not remember seeing any responses. Andrew went on to say that the report could be summarized to say that this policy would increase demands on the staff, both in terms of handling people going through the process and in terms of database changes to WHOIS and back-end databases. It would be a significant amount of work for ARIN to provide this information.

• Suggestions:

  • Could we replace “6 months” with “reasonable time frame” and let the staff figure out what was best?

Polling of consensus:

Question : Approve of Policy 2003-16?
Yes? 13 No? 2

Policy Proposal 2004-4: Purpose and Scope of ARIN WHOIS Directory

Introduction: Einar Bohlin, ARIN Policy Analyst

Presentation (Read-only): PDF

• Introduced - March 17, 2004
• Presented at ARIN XII
• Revised March 22, 2004
• PPML Summary:
  • 8 posts
  • 4 different people
  • The ISPs should be considered the primary contact.
  • I want to see SWIPs published for every legitimate record.
  • Does paragraph 7 define the contents of a WHOIS record?

Presenter: Michael Dillon, author

Michael presented information relating to the proposed policy.

Highlights:

• This proposal attempts to put into policy a definition of the basic purpose of WHOIS.
• Listing contact information is useless if it doesn’t assist in resolving issues.
• Would require an “opt-in” model that requires people to agree that they are ready, willing, and able to be responsive.
• Require that contacts listed in WHOIS be periodically contacted to verify information.
• WHOIS would contain, directly or indirectly, a record of all address blocks sub-allocated or assigned by those indicated in point 3 of this policy.

Comments:

• Statements For and Against:
  • Almost all SWIPs are currently processed automatically and do not require any staff time. If large ISPs wanted to demand, via their own contracts with their customers, that they all take this step, ARIN staff would now have to step into that automated process and establish this two-way relationship with an awful lot of people. Michael responded that this agreement could be handled through a click-through process on the ARIN website. This is not perhaps as strong as a contractual agreement, but is a lot better than what we have now.
  • I worry that many of the people listed in WHOIS are not legally able to enter into an agreement for their corporations, so this click-through agreement would be meaningless. Michael replied that there is nothing in the policy that ARIN would ever be enforcing in a court of law, and that by agreeing to the requirements, people, and by extension their organizations, would not be contractually obligated to do anything. John Curran added that a policy like this would get review by legal counsel.
  • If there is no desire for ARIN to take any direct action and there is no system that can legally enforce these guarantees, it seems like this results in nothing changing, so why do we need it in the first place?
  • With what has just been said [in regard to a click-through agreement], I agree and it could be done easily and should have been done before. Also, to go back to another point, it is important for organization names to be listed in WHOIS, as this is useful to many people. This kind of information should be covered by a privacy policy and saying that organization names and addresses are not useful is just not correct.
  • With the large number of reassignment records currently in the database, ARIN would need to go back and purge, or “clean,” these records. This would cause the loss of a lot of information in the database, and people need to be aware of this. Because once that information is gone, we will not be able to get it back. Michael responded with a reminder of the DBWG presentation that had just been made and the mention of getting rid of some contact information because it essentially wasn’t valid. Obviously, this policy will require the review of all contact information and the removal of invalid information. However, the information in ARIN’s WHOIS is separate from ARIN’s internal databases, so this information will still exist internally at ARIN.
  • Even after the database changes, each of the approximately 645,000 reassignment records will still have a name and address that is associated with a simple reassignment. This policy says we will not publish this information any more. Michael responded that this policy only addresses published information, other information would still be kept internally at ARIN.
  • In the last year and a half, my position on this has not changed. I am still not in favor of this policy. I am happy with current policies and procedures in this area and do not find it too hard to do a little research if I run across a POC that has incorrect information.
• Questions/Responses/Clarifications:
  • Which agencies are needed to use point 6 of the proposal, in relation to how the registration is done now? What is meant by “directly or indirectly” in point 6? Finally, as part of this opt-in process, are you proposing that ARIN stops accepting generic [role account] e-mail addresses? Michael replied that he was not proposing that ARIN stop accepting generic [role account] e-mail addresses, or any kind of e-mail addresses. This proposal is simply trying to establish a chain of two-way relationships that can be tracked reliably.
  • The proposal mentions “guarantee” in a number of places. Is there something in there about failure to meet those guarantees? There could be a lot of pressure for ARIN to hold people to these commitments. Michael responded that there were no consequences, other than the fact that if there is a failure to meet a guarantee, this would be noted, and anyone could contact the upstream ISP or their boss and say “Did you know this person guaranteed to do such and such and they have not followed through?” ARIN is not a police organization.
  • Is it the intent of the policy for ARIN, upon its first receipt of information, to do a verification immediately, and then periodically thereafter? Michael replied that the verification would be done upon ARIN’s receipt of the information and it would probably be more efficient to use the same automated process for both the initial verification and the follow-ups.
  • It would be interesting to hear from ARIN staff about what the projected workload would be to verify every POC that comes in, and every POC already in the database. Leslie Nobile, on behalf of ARIN, responded that ARIN currently gets about 40,000 reassignment templates each month and that she wasn’t sure how current staff could verify all of that. She added that ARIN currently does verify every Admin and Tech POC that is registered with a new organization, which is already a lot of work, but that ARIN has not taken any steps to extend this into reassignments.
• Suggestions:
  • The policy states that WHOIS would include records for all space that was assigned by ARIN’s predecessor, but some of these records have been handed off to the appropriate RIRs through the ERX project. This needs to be clarified. Michael replied that he believed the AC could reword it to specify records for address space only within the ARIN region.
  • Instead of specifying which organizations should be listed or not listed, I think we should have the policy say that the listing of organizations is defined by a separate privacy policy, which would also need to be created.
  • I agree with the idea of a separate privacy policy, otherwise I think this specific policy is a good one. In regard to privacy, I think it best to say “may not” instead of “will not” in regard to identifying. If an organization wants to publish its contact information instead of relying on its contact, that should be up to it. Michael responded that this policy is not intended to address privacy in any way, only to identify what information for organizations should be published to assist in research and statistical analysis.

Polling of consensus:

Question : Approve of Policy 2004-4?
Yes? 6 No? 12

Policy Proposal 2003-9: WHOIS Acceptable Use Policy

Introduction: Einar Bohlin, ARIN Policy Analyst

Presentation (Read-only): PDF

• Introduced - March 6, 2003
• Presented at ARIN XI
• Revised and presented at ARIN XII
• Reviewed - ARIN’s Legal Counsel in February 2004
• Revised - Author - April 14, 2004
• PPML Summary:
  • No discussion on PPML

Presenter: William Leibzon, author

Presentation (Read-only): PDF

William presented information relating to this proposal.

Highlights:

• Proposal started in 2002 to prevent abuse of ARIN WHOIS data.
• Provides for one unified policy that deals with distribution of ARIN WHOIS data.
• Allows individual users to request bulk WHOIS data (currently can only be done by organizations).
• Allows for bulk WHOIS data to be obtained by requesting hard media (and not only through public Internet protocol such as FTP).
• Although policy had support during ARIN XII meeting in Chicago, afterward it was pointed out by ARIN Counsel that public policy can not include text of legal document (which AUP is).

Comments:

• Statements For and Against:
  • I think it is a mischaracterization to say this policy doesn’t have “teeth.” It is a policy based on protection, rather than the active tracking down of those who violate the policy.
• Questions/Responses/Clarifications:
  • Alec Peterson, on behalf of the ARIN AC, said that a concern of the AC was that whatever legal text is put in place regarding this is pointless without an enforcement mechanism, and that with an enforcement mechanism, it opens up a wide variety of issues like liability. This was echoed by the legal opinion the AC received from ARIN’s counsel. Steve Ryan, as ARIN’s Counsel, added that the concern was the instance of a known violation. As such behavior might or might not violate the applicable laws of countries within the ARIN region, there is no real remedy to be had. Furthermore, as a non-legal matter, simply denying access would be quite inadequate. As counsel, I am not worried about cutting off somebody who is violating law and public policy in this way if we need to do that, but it does create situations where ARIN could incur substantial costs. However, I do not have a specific recommendation concerning the current text, I only advise that the potential operational impacts should be considered throughout your deliberations. Language at least giving guidance to ARIN staff about enforcement should be included in the policy.
• Suggestions:
  • It is not clear to me that enforcement measures need to be outlined in every individual policy. At some point, enforcement could be outlined in a separate policy that could cover violations of any ARIN policy.
  • I agree that a separate enforcement policy would be good.

Polling of consensus:

Question : Approve of Policy 2003-9?
Yes? 5 No? 3

Preview of Cataloging ARIN Policies and ARIN Glossary of Terms

Presenter: Richard Jimmerson, ARIN Director of Operations

Presentation (Read-only): PDF

Richard previewed the idea of enumerating the ARIN policies for easy reference and documentation clarity. The goal is to replace the current ARIN policy web pages with a single document containing numbered and lettered sections. Challenges include unintended policy changes and community mapping of existing documentation to a new document. The proposed timeline for this project is as follows:

• May 2004, draft document and accompanying mapping materials submitted to the Advisory Council for initial review.
• June - July 2004, insert draft text into Internet Resource Policy Evaluation Process for community review and publish on web page dedicated to this documentation project.
• July - October 2004, discuss on PPML and add to agenda for ARIN XIV Public Policy Meeting in Reston, VA, US.
• November - December 2004, acceptance and ratification of new document via IRPEP.

Comments:

• When you put out the review process instructions, it should be made clear that this is not meant to change policy, but simply to number and catalog existing policies. Otherwise it could end up being a huge discussion that wouldn’t be particularly useful. Richard responded that ARIN would be sure to include instructions to that effect.
• Gerard Ross, on behalf of APNIC, added that it sounded like a very good initiative He added that in regard to numbering, a decision will have to be made at some point regarding amendments, as it can get terribly complicated. Gerard went on to say that in the APNIC region, it is handled a little differently, in that they have established a separate editorial policy. The APNIC Secretariat has a specific role in documenting the results of the policy development process, and it may be worth taking a look at something along those lines for this document.
• At some point we need to figure out a policy for making old policies obsolete, or at least a procedure. Policies do not necessarily sound the same 10 years from now, so some of them are going to need to be retired. However, that does not have to be addressed at the same time as this project.
• Would the community like to see one document, as was shown here, or would they like separate documents for IPv6, IPv4, ASNs, and the like? Gerard Ross, on behalf of APNIC, replied that APNIC is actually now consolidating all of its various policy documents into one. Leo Vegoda, on behalf of RIPE NCC, added that in his region they just broke their single document into separate documents for each protocol, and then there is a general policy and a few exceptions. It is a difficult balance.
• Richard Jimmerson said that he thought it was interesting to find out the different approaches from the other RIRs. These different approaches were discussed early on in the process internally at ARIN, and there are advantages and disadvantages to each. During the community review of the draft of this, it will be very important for everyone to confirm that everything that is currently in policy is reflected in this new document.
• I would suggest keeping it in one document just so that the numbering doesn’t get messed up.

Maintenance Fee Update

Presenter: Lee Howard, ARIN Treasurer

Presentation (Read-only): PDF

Lee presented an update on ARIN’s maintenance fees.

Highlights:

• Micro-allocations will have an initial fee of $1500 and annual renewal fees of $1250. Micro-allocation fees include ARIN membership.
• Micro-assignments will have an initial fee of $1500 and annual maintenance fees of $100.
• Legacy space holders will be subject to a $100 annual maintenance fee that is waived until the holder requests a service from ARIN. After initial request, holder is subject to the same maintenance fees as assignments.
• The initial fee for an IPv6 allocation is $2500 for a /32, with an annual renewal fee of $2250. The next bit up doubles the fee (/31 for $4500, /30 for $9000, etc.). IPv6 fees are currently waived.
• What should IPv6 assignment fees be? $2250 for initial assignment and $100 annual maintenance fee?

Comments:

• I believe that 90% of $1,500 is not $1,250. Lee Howard responded that is correct, the presentation is in error.
• When a holder of legacy space requests some kind of change, it would cost them $100 and then they would be billed thereafter, correct? Lee responded that was correct.
• In regard to fees for assignments and allocations, it seems to me that there is more involved in allocations, as there is the subsequent reassignment of that space, so allocations incur more cost to ARIN. I do not think they should be the same price.
• Once legacy holders start paying fees, do they become members? Lee responded that, as with end-users, the intent is not to require holders of legacy space to become members. Any holder of legacy space can become a member, as can any individual or organization, for the $500 non-subscriber membership fee. If the legacy space holder was an ISP and wanted to become a subscriber member, we would welcome their $2,250, $4,500, or $9,000 a year, which would be the renewal fee, but for cost effectiveness it would seem that a non-subscriber membership would be the way to go.

SIARI - LACNIC’s Statistical Information System

Presenter: German Valdez, LACNIC

Presentation (Read-only): PDF

German presented an overview of LACNIC’s new statistical information system, Sistema Interactivo de Analisis de Recursos de Internet (SIARI). SIARI is a new resource used to present information on how Internet resources (IPv4, IPv6, and ASNs) are administered in LACNIC’s region. The system is available in HTML or Java, for execution on a local network or via the Internet. German then went through several examples using the HTML version and explained each step of the process.

Comments:

• I think this application is very nice and I appreciate you sharing it with us. Is it your intent to offer this software to the other RIRs? German responded that LACNIC would be happy to share this software with its partners in other regions. Richard Jimmerson, on behalf of ARIN, added that ARIN had invited LACNIC to give this presentation so that the attendees could evaluate if this was something ARIN should be working with.

Analysis of Fragmentation of the Legacy Space

Presenter: Alvaro Garcia, UNIVERSIDAD ORT

Presentation (Read-only): PDF

Alvaro presented an analysis of the fragmentation of legacy address space. The objectives of the project were to analyze the information consistency of the Early Registration Transfer Project (ERX) blocks, evaluate the quantity of free addresses, and to verify the fragmentation level of the free addresses in each block.

Comments:

• I am surprised that, if these graphs are right, we are doing such a great job in terms of utilization of legacy space. It looks like we are using 85%, is that a correct assessment? Alvaro Garcia responded that the data was surprising to them as well, and that they estimated there was only a 1% margin of error due to the ERX transfers.
• I assume the data is only based on information from the registries and not information in the routing tables, is that correct? Do you plan on any additional work that incorporated that information as well? Alvaro replied that the data was based on the information from the registries. He added that, in terms of the routing table data, they had done some random sampling, and that the results were convergent.
• Is it correct to say that this analysis doesn’t take into account “real” utilization, meaning what is being used, but only what has been allocated? Looking at these numbers, I don’t think it indicates the space is being utilized well, only that it has been allocated or assigned efficiently.
• William Leibzon, an attendee from Elan Communications, added that he had published some information to the Public Policy Mailing List the last ARIN meeting about the actual utilization of legacy space as reflected in the routing tables before.
• Raúl Echeberría, from LACNIC, said that the interesting conclusion of this survey was that there looks to be the equivalent of 6 /8s that have not been allocated and the fragmentation of this space wasn’t very bad. John Curran, of ARIN, asked if Raul knew of any way to recover that space, as for all practical purposes, it is lost. Raul replied that he had no recommendation, but that this issue was being looked at in other regions.

Open Microphone

• Leo Bicknell called attention to the article in the ARIN newsletter and post to PPML regarding the history of WHOIS and some proposed ideas about the service. He stated there has only been feedback from one person on PPML and encouraged further positive or negative feedback to the post on the list. Andrew Dul complimented Leo on his work.
• Stacy Taylor reintroduced the topic of cable provider policies that was previously discussed at the Public Policy BoF at the ARIN meeting on Sunday. John Curran encouraged more detailed discussion for this open microphone session. Alec Peterson summarized the issues discussed at the policy BoF and established a basis for continuing the discussion.
• An active exchange ensued with a large part of the discussion centering on cable regulatory issues and the ability of cable providers covering the same market area and infrastructure to work within the cable policies of ARIN. There were concerns raised about accessibility of numbering resources from ARIN by newer cable providers entering the markets and infrastructure of legacy providers. ARIN staff stated the current cable policy does allow access and allocations are being made. It was noted there may be some difficulties with the current policy for newer providers requesting their second allocation from ARIN. There was also some discussion and concern that large amounts of numbering resources were being allocated to multiple providers for the same infrastructure that has a finite amount of potential customers. ARIN staff noted that each provider does not receive the maximum amount of IP address space that would be needed to cover the entire potential customer base (homes passed) of a particular infrastructure set. An initial allocation is made to new providers to number head-ends and bring on customers, but additional allocations are made based on their rates of utilization (number of customers).
• It was noted that this is a policy area that deserves further discussion and the ARIN AC agreed to engage in a dialogue with the wider community for a possible new proposal in the future. It was observed that the ARIN AC has solicited feedback and participation on this issue in the past with little response from the community.

Closing Announcements

Richard Jimmerson made closing announcements, including a reminder for attendees who were not staying for the Members Meeting to turn in their wireless cards and to fill out the meeting survey. Richard said that attendees should not expect to have wireless network connectivity beyond 14:00 PDT on Thursday. Richard again expressed thanks to the meeting sponsors: Telus Corporation, Shaw Communications, Big Pipe Inc., and Peer 1 Network. He reminded the audience that the Members Meeting would begin Wednesday at 09:00 PDT.

Adjournment

The meeting was adjourned at 16:44 PDT.

Sponsors