Policy Manual

Every time new policies are adopted, a new version of the NRPM is posted. The NRPM Change Log links to all
previous versions of the NRPM, as well as details about which policies
were enacted and which sections were modified.

ARIN Meeting Archive

ARIN on the Road
events provide the latest information on ARIN's technical services,
the status of IPv6 adoption, current ARIN policy developments and
updates about ARIN and the RIR system. Archives of our presentations
are also available.

Welcome to the ARIN Vault!

Using the navigation on the page, you can find
information and documents relevant to ARIN's history, or using the
"Search" link above, you can search for specific items. If you wish, you can
return to the main ARIN website.

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

Call
to Order and Announcements

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.

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.

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

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)

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.

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

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.

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 hostmaster@arin.net. 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 hostmaster@arin.net. 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?

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.

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

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

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.

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

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

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.