[arin-ppml] 2009.10.21 ARIN 24 meeting notes, second half

[Matthew Petach]

Here's my notes from the second half of today.  Apologies for the delay,
I've been wrestling with trying to get the daily survey link to work, but
had no luck; no love for firefox or ie on my laptop.   So, enough of
trying to get that working, here's the notes.  ^_^;;

Matt





2009.10.21 ARIN 24 notes, day 1, second half

ARIN 24 resumes after lunch

John Curran welcomes everyone back at 1332
hours Eastern time.

We have Advisory Council elections...

Oh, but we talk about policy 2009-6
first.

IANA policy for allocation of ASN blocks.

May 29, 2009, originally proposed.
In discussions in all regions
Allows for one more year for RIRs to make
separate requests for 16bit and 32-bit ASNs.
Treat them separately until Jan 1, 2011.

No liability risk or staff issue, minimal
impact for implementation.
Assessments available online.

12 posts by 5 people, 3 in favour, none against.

Andrew de la Haye will present on it.
Currently, as of Jan 1 2010, IANA will treat it
as an undifferentiated pool.
Currently, 125 32-bit ASNs.
problems:
45% have hardware / software problems
22% peering partners do not accept 32-bit ASNs

Current rate of ASN deployment will run out
around 2012-2014.

Current policy written when worries of earlier
runout seemed imminent.

3 options
do nothing
extend by a year (cons, less incentive to get 32-bit
 working, we'll end up here again in 1 year)
or just run out of 16-bit.

This pushes for option 2; keep differentiated pool
for 1 more year while we keep pushing for 4-byte.

It's under discussion or in last call in all regions
at this point.

No questions about it.

Scott Liebrand, Internap, he supports this proposal;
we have code, we're moving forward, but it still
needs a bit more fixing.

Leo Bicknell, ISC, he supports the proposal; the
appropriate place is for LIR to put pressure for
this on vendors.  He wants it extended for forever,
and thinks we'll be back here in a year.  But he'll
support it as it is.

Owen DeLong supports it; he doesn't think the year
timeframe matters, they won't last much beyond that
anyhow.  This policy helps, RIR policies he proposed
didn't help much, esp. in terms of staff efforts
involved.

Any other comments, discussion, proposal.

Discussion closes.

People and room to do show of hands in room and
remotely.

One show of hands; in favour, and then opposed.
In Favour: 72  Against: Zero
135 participants


Judd describes election procedures for board of
trustees and advisory council

Today at 3pm, after the candidate speeches,
voting will open, and will stay open for
10 days.

Candidate speeches will be available online as
well.

Select 3 people for board of trustees, 5 for
Advisory Council

Only the 1 DMR may vote in these elections; they
were established on October 7th.  In good standing
with ARIN, and mail on file with email domain from
personal account registering for it.

Voting procedures
https://www.arin.net/app/election/
register (or log in)
vote
CONFIRM your vote.  Make sure you confirm it,
 and don't just close your browser!

Advisory Council Candidate speeches
(text or video available on the voting site)
[notes in brackets are for jogging my memory, and are
 not to be taken as any type of commentary on or about
 any particular candidate]
Mark Bayliss
John Brown
Rudolf Daniel (video presentation)
Steve Feldman
Wes George -- [Sprint v6 testbed, and working on v6
 deployment.  No specific agenda.]
Chris Grundemann
Stacy Hughes
Kevin Hunt
Mark Johnson
Ed Kern--[platform is to prevent scope creep in ARIN;
 the controls should remain with the operators]
Chris Morrow--[Google now, UUnet before]
Bill Sandiford
Christopher Savage
Heather Schiller
Rob Seastrom
Scott Weeks
Tom Zeller

Next up, Board of Trustees candidates:
Paul Anderson
Scott Bradner
Lee Howard
Aaron Hughes
Frederick Silny (video)

OK, that completes candidate speeches.

So, Andy Newton will do the ARIN templates
presentation early.

Cathy comes to the mic.
A little side discussion about people working together
to come up with more streamlined process to clean blocks
to give into free pool; we'll need to shorten the timeline
to less than a year.   What do people think, and who can
work with her on it?
Apparently there's a process for domain names that can
be a starting point.
John volunteers Leslie Nobile.

Eric Kline--domain names have a process for cleaning
them, it takes about five days to clean up; he'd like
to try to develop process to do that with IP names.

Chris Morrow--Google.
ARIN publishes the list of blocks that get reclaimed;
the current blacklist operators could follow the RSS
feeds; but most of them are lazy.  It's a pain to try
to get them take action.  It could be an exercise in
futility trying to push it.

Now we have Andy Newton doing presentation on
retiring ARIN email templates.

Consultation sent to arin-consult at arin.net
on sept 25th.
 feedback on when and if to retire email templates
 (NOT SWIP--just POC contacts, orgIDs, etc)

Consultation is about templates not backed by an
automated system.
ORG/POC templates
requests for new resources
non-automated
 ARIN seldom processes them automatically
 likelihood for human email exchange
 not conducive for automation

Email is insecure
 234,246 POCs
 19 use X.509
 48 use PGP
adoption of security measures is very low
SPAM clogs inboxes, filters catch replies
non-interactive
non-intuitive

Nothing is for Free
there are costs to continuing dual operations
maintenance
training/support


Engineering time to fix bugs
ops staff to keep systems running
continued management of certificate authority
 security practices
 key rollovers

Training and support
help desk needs to understand both systems
training methods and docs need to list both
for new users, email templates add to array of confusion

New development conflicts
slows data model changes
new systems must accomodate legacy behaviour
legacy systems do not know about newer systems
 IRR wall
 inflight X tickets
considerably slows new development

Adoption curve for POC curve; web pretty
much always higher

Online experience
immediate feedback through web forms
new X tickets can be tracked by users
Online help.

Online reporting, users can view their related records
and resources

Security
ARIN Online requires password authentication over HTTPS
Mitigates hostile POC takeovers
 POCS lead to ORGs which then lead to the keys to the
 kingdom, resources

What should we do?
should new development be slowed by legacy systems?
Given that users are switching to ARIN Online, should
users who wish

Give feedback
arin-consult at arin.net

Aaron Hughes--he sent objection about SWIPs.
he tried to log in, and got error about the system
being down.  This has to be 100% reliable in order
for this to be acceptable!
A: Well, email isn't 100% reliable either, and they
have to work with helping people on their templates.

OK, so templates can't be phased out until track
record is more reliable.

Joe Mamon likes paper trail; he would like email
to be kept active until disuse shows it ready for
retirement.

Martin Hannigan uses this and only this to handle
records; he likes the export function to do audits
of his space.  It's likely SMTP had issues for Aaron
that were transparent to him, if he'd checked his
queues.
Concern about fees being needed to

Peter from Cablevision--ran into issue with
signing POCs to ORG-IDs--will that process
be functionally available?
A: That feature is now active on website.

Arcadia speaker at mic--people still use email
system for a reason; make the new system usable
so people have no reason to use email system.

Leo Bicknell applauds new system, and thinks that
time to deprecate email when statistics show that
users have moved to new system, and have largely
moved off the email system.

Joe, comment--also possibility that unsecured
templates could be deprecated, and only PGP
or X.509 be accepted.

John asks if there's reliable, stable ARIN Online
with widespread adoption, would they still need to
keep the email system around?

Scott Liebrand, Internap--early comments are in line
with what he was going after.  We need a paper trail
through the online system; don't make everything
hostage to web internal system; provide copy to
people at each transaction.

Rob Seastrom--how adopted is widely adopted and
how much time would you give it?
Substantial outreach time is needed to let the
community know that we will be phasing a mode
of access out.
The number to start with should be single digit
number of years.

Owen DeLong, he.net, doesn't feel that retiring
the templates is valuable; it's just another way
to get data into system; he would propose the
system should be able to take templates in, and
be able to process them into the new system as
a parallel input.

Scott Bradner says we need to watch the numbers;
if people are still using it, giving an arbitrary
deadline will annoy people.

David Farmer, U of Minn--a suggestion from cyberspace
that we deprecate insecure templates.  Let's do that,
and raise the security of the system as a whole, and
may be the way to thump the system.

Aaron Hughes--one quite useful way to promote webservice
is to add autoresponder at top of emails listing the
URL for the new service, alerting them of the new
system.

Rob Seastrom notes it won't get to everyone, even
though it's a great idea.  And at the top, note
that they're using a deprecated system that will
be going away eventually.

Stan Barber, ThePlanet--Would there be programmatic
interfaces to this, like XML?  For ORGs and POCs.
A: nothing on the roadmap about doing those.
At last meeting, they talked about SWIP templates,
and decided they'd have to do at least that.  They
have some ideas, they might be able to extend to
regular POC and ORG forms.  Being able to create
ORGs and POCs for customers would be good.

Kelly, utah edu network.  What about server maintenance,
full redundancy, downtime, fault tolerance, etc.
email has store-and-forward to deal with service
interruptions.

Kevin Oberman, ESnet--does ARIN website meet ADA
section 508?
A: Yes, it does, they have an external
agency that helps with testing and verifying that.

Now it's breaktime!!

Info center up there, meet staff, watch videos,
help desks are open, billing helpdesk is available
by appointment, and don't forget to vote, it closes
at 5pm for NRO!!

For DMRs, if you're using same email, you'll see
all entries under that domain on same voting page.


John Curran starts us up after break at 1532 hours
Pacific time.

Mark Kosters is up next to talk about LAME testing
and next steps.

ARIN has been doing LAME DNS testing for some time
now.

Lame delegation process
delegations tested daily until test good or
removed.

If still lame after 30 consecutive days of testing,
POCs notified

If still lame 30 days after initial notification,
POCs notified again.

If still lame another 30 days after that, delegation
is analyzed manually, nameservers stripped if delegation
determine to be wrong

LAME:
 no A record for name server
 not responsive (times out)
 doesn't think it's authoritative for reverse zone
  (no A bit)
 no SOA record for reverse zone

Leslie provided following report at ARIN 22
problems observed--no clear way of detecting a lame
 delegation
potential legal liability
operationally significant time spent on development,
notification, and followup

Service issues with current lame system
turning off working delegations
 delegations in dns for a /16 when they have a /19
 incorrectly configured DNS servers
substantial customer support

John challenged him to come up with a better
way to define lame.

3 tests:
 Issue an SOA query for the delegation; if server
 responds, delegation is good.  Note that AA bit
 doesn't have to be set on the response

If that fails, fill out the dotted quad for the
 delegation, issue a PTR request; if the AA bit
 is set, the delegation is good.

If test 2 fails, provide 3 random PTR queries for
 dotted quads that reside in the delegation; if any
 of three tests gets an answer, the delegation is
 good; note AA bit does not need to be set

Consensus--is relaxed algorithm worthy?

Leo Bicknell--ISC; comments in 2 directions.
this is hard to define, it would be useful for
ARIN to actually define what they *expect* of
people who run nameservers to.  It is much
easier to tell them they were removed due to
failing tests, if we first explicitly list
what their requirements are for running a DNS
server.
Also, people throw into lame 2 problem.
LAME--down the tree server replied with a reply
that the up-the-tree server didn't agree with.
But that's predecated on a response.
Servers that are non-responsive (missing) is
a totally different problem, and should be
addressed differently.  The non-response
problem could be an issue with ARIN routing,
the internet at large, etc.


Some dude at back mic talked about not liking
point 3, as during a transition, the response
coming back will be from an unexpected server.
Would be good to have a tool on website so that
people can perform self-test to make sure that
their DNS server is working properly.
A: If you do transfer, you update your NS set
first for it; so people in that part of the
tree should still go to the right servers.

Oh, he was talking about the reverse zone, in
case your upstream still has records for your
/19 within the /16.

What is TTL of delegation from ARIN to space
holder?  2 days?  That could cause operational
issues for email holders, for example.

Center front, Andrew--if there's an org that
considers their blocks private, don't allow
external queries, but it works fine on the
inside?
A: some entitities do have internal blocks,
and they flag those delegations; the pain point
they try to address is ones visible to the
external internet.

Leo Bicknell--ISC--curious, thinking forward a
few days; reverse zone DNSSec signed, will this
check DS in parent vs child, and if mismatches
there would count as lame?
A: good point, but let's solve this first.

Q: in that case, before the reverse zones are
signed, ARIN should publish the rules for DS
keys in a zone, and if action will be taken
if DS keys are out of synch.  At least one
key must validate signatures for validating
servers to work; should cases of no keys
matching be considered LAME or not?  Define
it!

David Farmer, U of Minn, the changes being
proposed are reasonable, need to think about
them a little longer; suggestions for process.
This might be something we work with RIR
brethern, and put an informational RFC, or
a BCP document.
A: definitely, we'd like to expose this to
the other RIRs, to get more people aware of
it.  But we want to get it working within
ARIN community first, definitely.

Not everybody's day job here is working with
DNS; mostly people here are router people.
Might be good to get people with DNS as they
day job.

Final comment, OwenDeLong, He.net.  He'd like
to not redefine LAME; he does like these as
criteria for what gets removed or not removed
from the zone file, and publishing these as
rules for people to follow.  DNSSec is likely
to force this issue along as well.

Will this be done for ip6.arpa as well?

Will be thinking about it.

Draft policy 2009-7, open access to IPv6.

Proposed 29 May 2009, draft 31 Aug 2009,
under discussion in other registries.

Removes requirement to advertise the single
aggregate, and removes requirement to be ISP
in ARIN region.

legal risk; could encourage fraud.

staff concerns; leaves only qualification to be
an ISP to get space.

Could be unfair to end sites, which would need
to justify a /48, but could easily get a /32.

Excerpts from PPML discussions are citing.

Now over to Cathy to present.
This was a very old policy, written a very long
time ago.

She started rewriting the policy for the Carribbean
region, and then thought it might be good to apply
to everyone.

Most regions changed original language anyhow early
on.

Policy statements
removes the "advertising single aggregate"
and removes "200 site" requirement.

Pros:
promotes IPv6 adoption
facilitates innovation and progress
currently can't announce more specifics for traffic
 engineering
current policy doesn't allow for more specifics for
 anycast
current policy doesn't allow for more specifics to
 fight a hijacked /32.

Cons:
routing table growth

Anyone want to say anything.

Marla from FT.
She wants to take the /32 aggregate out, that
part doesn't belong.
She isn't sure the 200 part should be taken out,
as per the legal advisory about the abuse concerns.

Aaron Hughes; looking for clarification from legal
on this; is same text provided for v4 space?  This
seems to protect resources from people lying?
wouldn't v4 need similar protection language?

A: Steve said not fatally flawed...
He understands goal we're trying to achieve, but it
opens up policy to allow lots of unsavory people to
get space with the changes.

Aaron does support the policy.  As a new organization,
he had to acquire v4 space to build a v6-only network.

Doni from PeakWeb supports the policy.  The current
policy leaves a portion of our membership stranded.
Ah.  This policy change does remove the "known ISP"
part removed.

And Aaron would be happy with it with 200 sites
still in it, but "known ISP" removed.

Doni notes that smaller networks with less than 200
still have to lie.

Dan Alexander, Comcast.  Cathy said these were removed
from other RIRs; do the other RIRs have criteria they
put in place of these, or are they as liberal as the
proposed language would be?

RIPE says they got rid of 200 end sites, and the
ISP requirement is gone.

APNIC was proposing to strengthen aggregation by
pushing for additional aggregation, but that was
defeated.  End site requirement is still there.

LACNIC removed 200 sites; they ask for aggregate
to be announced within 1 year, and to provide
service within 2 years.

Kevin Oberman, ESnet--likes half, not likes the
other half.  First change, allowing de-aggregation
isn't about open access to IPv6.  The second half
is entirely too liberal to do all at once; but we
need to take smaller steps to get there, not just
open the door to anyone who can breathe and send
email.  It's just a bit *too* liberal.

John someone, it strikes him the panel at IPv6
panel is that there's a problem with current policy.
The idea of having to consume some scarce v4 resource
to get unscarce v6 resource is just wrong, and needs
to go away.
No limitations on getting space at all abrogates our
stewardship of scarce slots in the routing tables.

Cathy responds noting that ARIN does not dictate to
operators what routing policy should be.

This conversation at open mic last night...there's a
difference between between "there can be only one"
and "there are no constraints"--can we find something
in between that allows for good operations as well
as good stewardship without throwing the gate wide
open.
If you get a lot of growth very fast in IPv6 routes,
and don't constrain it, the fears of gradual growth
people worry about will be nothing compared to worries
of routers falling over.

Jason Schiller--clarification question; confused on
6.5.1.1b; it says "be known ISP *or* to provide 200
customers in next 2 years"--if a new entity starts
up with 200 customers, is not a known ISP, would they
get addresses.

Aaron notes he was denied on that count; he requested
a /32 for 200 customers over the next five years, but
was not a known v4 ISP.

Currently, the language requires ARIN to evaluate the
stated business plan and make a value judgement.

Jason is still confused if we have a policy problem,
or an implementation problem?

If you apply, you will need to submit a business plan
that shows how you will get those 200 customers.

In that case, he is opposed to this policy, as the bar
is sufficiently low; with no requirement, the bar is
too low, and even his house would qualify as an ISP.

Igor, Yahoo--completely for part 1, and feels that it
is a hinderance to development of the IPv6 internet,
especially for content providers to develop this.
And please leave operational problems to operators;
the operators will take care of the routing table
size issues.
As far as part 2; really wish we could vote on part
1 separately.
Is fee schedule for ISP separate for end site?
Those fees are waived now, and will expire or be
extended on December 31st.

If you apply for v6 only; end users pay 1 time fee,
and then nominal maintenance.
ISPs pay for allocation, and pay same amount each
year on their total allocated block.

Couldn't the fee be used to disincent abuse of
the system?

Joe says we need to have a better end site plan.

Scott speaks for Chris--says single aggregate is bad,
need to remove it.  He doesn't think dropping 200 end
site would be good.

Leo Bicknell ISC, first half he agrees with, it doesn't
reflect reality, and operators are better poised to
react as needed to changes, as routers grow, etc.
Second half of proposal; agree that given Aaron's
type of situation, the current situation is very flawed.
We need to set a reasonable criteria for the bar at
some level.
Right now, interest in v6 is low; few people will
start up v6 only businesses.
However, over time, that will become more interesting.
Transition may happen quickly.  If we remove all limits,
we could have hundreds of thousands of people trying
to get space in too short a time for policy process.
The problem of people not being able to qualify with
real plans is real, but he doesn't support the second
part as it stands.

Owen DeLong, he.net; he feels 200 end site is too
steep.  Some requirement is worthwhile.  Would be
good input to AC if we can get a range sense of what
a better bar should be.
otherwise, good policy, the removal single aggregate
are needed.

random person at mic agrees part 1 needs to go away,
otherwise the /32 used for anycast is stupid, the
reasons for it are solid.
For part 2, we have other things we require in v4
for doing this; can we tie v6 rules to same boundries
and qualify for it to get v6, but not actually take
it.

Kevin Oberman, in response to tom, current policy
does not require you to get IPv4 space before getting
IPv6.
Stewardship in terms of forwarding table sizes is
not an ARIN issue, and that is a constantly sliding
bar.  The economics will control how networks are
run, regardless of what policies ARIN sets, as one
network rejects prefixes that ARIN allocates today.

Igor from Yahoo--given that many people are in favour
of part 1, and more discussion is needed for part 2;
can we split it?
They can poll the two parts separately, and AC can
take that under advisement.

So far, nobody has said the routing aggregate part
needs to stay; if you support that, please go to the
mic!
And if you'd like to see a requirement for the
block to be announced within a certain period of
time like LACnic, please speak up.

David Farmer, UofMinn, he supports first part of
policy, he echoes discomfort with lack of criteria
for part 2.
And proposals for working on end user part of
assignment policy will be forthcoming; it is on
the list of policies that will be worked on
very soon; he will be working on it shortly, so
please talk to him if you have ideas about it.

While he agrees that operators are more than
capable of setting and defending policies, he
feels ARIN is responsible for providing hooks
for providers to hang their policies on.

John will close mics shortly.

Chris Grundeman, he would support splitting policy
in two, and supports first half.  If ARIN wants to
preserve table slots, start allocating sparsely!

For second half, 200 users in 5 years is not a
challenge for any starting ISP; he's hit more
than that as a four person ISP.  That part does
need more work.

Center front.  Kevin Loch, Carpathian network,
he supports part 1 strongly; part 2, he's concerned
about frivolous applications.  Economic hurdles,
$2250/year with no waiver for /32; 75% waiver this
year, so at least $500 even today.  And you can't
get resources from ARIN without some legal entity,
some LLC, etc.?
A: No, does not think there is a requirement for
a separate legal entity.  You must be an organization,
not an individual.

Kevin Oberman, es.net; a family is an organization. :)
There is a difference between stewarding the address
allocations to allow for rational policies, vs enforcing
policies.

Mike, rear mic, a minnow in a shark tank; his business
model is slightly different, supports medical facilities
across country, provides /27s and /28s right now; if
he is considered a known ISP now; but if you ask him
to show a business plan on business model, he can't
meet that criteria.  As Cathy asked, he would support
a plan like LACNIC with time-based criteria, not size.

Jason Schiller, Verizon--some people may not qualify
for 200 sites in 5 years, and are using known ISP
clause as easy out to justify space.
how about 3 parts;
advertise single aggregate
known ISP as third part
200 sites in 5 years as third part.
Some might support policy with combination of the
three items.
He does not support the policy.
Strike known ISP, and then would support it with
keeping aggregate in place, and the 200 sites rule.

That concludes discussion.

Now, show of hands; draft policy as written first?
In favour?  27
Opposed?    48
in room 147

same policy; instead of removing requirement for
200 end sites, reduce from 200 to 100.
in favour: 42
against:   22
participants, 147

Many questions about clarifying what we're voting
on get addressed.

What about removing only the single aggregate
statement, and leaving the minimum customer
requirement?
in favour: 64
against:   10
participants: 147


This concludes the polic portion for today.

Open mic portion...be courteous, identify yourself
at the mic.

Leo Bicknell--if you attended 2 part ARIN/NANOG
panel, there was near universal agreement that 2009-1
was hard to understand.
Most people didn't come up to talk about it.
Why didn't more people comment on it today?

Igor from yahoo notes the people who spoke last
night were too hung over to make it the morning
to talk.
He'd like to see a flow chart of how it's supposed
to work, it's too confusing as it stands now.

Tom Daly, dynamic networks, the day job needed some
love too.

Scott Bradner asks if he will take the advice for
putting the flow chart to make it more understandable
Yes, they will try.

Cathy asks if Tom Daly can explain why he finds the
transfer policy confusing.

It seems nuance of removing M&A activity didn't
come out at him; he might have been dense at the
time.

Igor, Yahoo, notes that M&A makes it confusing; is
it or, and, or what that; those sections seem to
be in conflict.

mic open for all topics.

martin hannigan, akamai, some traffic about some
AC  non-comm issues; what happened, and what will
be done in the future?
A: won't be discussed during current elections,
but after the elections close, will be explained.

Doni, peakweb, discussions around integrity of
v4 routing table and future abuses.
The topic is authoritative routing registry
that ties prefix to originating ASN.
for recent v4 requests, originating ASN has
been added as optional field.  There are multiple
routing registries in use, some public, some private.
He would like to get feedback about developing
an authoritative routing registry; we would decide
on which of the one would be the authoritative one,
and all of the others would get folded into it.

A: There are many IRRS out there; hard to envision
how to get to a single worldwide routing registry;
it's a bit bigger than just ARIN.

Mark Kosters, CTO, ARIN; ARIN also mirrors everyone
else, so even though there's islands of where the
information resides, you can get a comprehensive
view; only about 50% of the information is
valid in the registry.
There is an emerging system getting put in place,
resource certification; ARIN and other RIRs are
testing it,
rpki-pilot.arin.net, it may subsume other projects
over time.

Right now, this is more about the certification
process, not the single-uber-source.

lea roberts, ARIN AC, stanford university.
comment on 2009-7; ARIN doing sparse allocation
benefit to community.  It's not a policy issue,
it's implementation; could we at least space
the allocations out a bit more?

Anyone want to speak against ARIN doing sparse
allocations?

By end of meeting Friday, he will have timeline
for sparse allocations!

Lee Howard, TWC, earlier during week there was
a suggestion that Aaron Hughes write a best
current practices document around it.  Nobody
has figured out which space that work should
happen in, though.

Should ARIN handle/facilitate this type of
work.

Jason schiller, Verizon; best current practices
document is good, but need a process like what
we do here, community writes their thoughts on
what would be best, produce a living document
that changes over time; don't write what you
can and can't route; it's not a binding document,
but a best common practices document would be
good.

Owen DeLong, HE.net, it's a great idea to develop
BCP document; set aside a new category on a wiki
and he can work with Aaron to develop it on the
ipv6 wiki.

Chris Grundeman, the ipv6 wiki on ARIN's website
is a good place to start; perhaps it needs a little
coaxing.  We can get the ball rolling.

Aaron, a repository somewhere would be good, the
better place for this would be program committee
at NANOG; but if we start something as ARIN, it
won't have good operational support to make it
useful.

Closing floor to new topics.

Stacy, question remotely.  If you are a legacy
v4 holder, must you sign legacy RSA in order to
get v6 resources.
To get IPv6 resources, you must sign RSA for the
v6 resources, but v4 is not covered under it.

Cathy wants more discussion around LACNIC
requirements:
1 be LIR or ISP
2 document plan for services to be offered to other
 clients, cell phones, departments,
3 a single aggregate route will be advertised within
 12 months
4 offer Ipv6 services within LACNIC region within
 24 months.

Perhaps this would be better than our 100 or 200
number?

Scott Liebrand--hearing that made his head hurt,
and think of 2008-2, first transfer policy.

Cathy responds that there's a large number of
prefixes that have never been announced into the
table.


Chris Grundeman, he talks about not needing to
announce space.  We don't require that under
IPv4.

Cathy notes that this is for ISP policy; and they
require within 24 months to be reselling or
providing services.

Chris Morrow, Google, it would be difficult to
go back and push people to announce blocks on
the Internet.  Making a requirement to announce
it is not good for large private networks.

Closing mics shortly.

Leo Bicknell, ISC, he doesn't like the word
announce; but he does like a requirement that it
be in use within some period of time; could be
announced, but could also be in use on private
network.

Requirements like this could alleviate issues
like this in the IPv4 world.

Every 12 or 24 months, we might re-look at it.
There are a lot of large networks going down
the path to enabling their networks, and are
still in startup phase.  It would be silly to
put 12 month timeframe and spend ARIN cycles
chasing cases where vendors are running late.

But it would be good verify that resources
are being used for *some* purposes.

Chris Grundeman notes that the customer requirement
does the same thing; instead of using announcement
as a bar.  If you don't have customers, you're not
an ISP.

Cathy agrees with it, but we keep dithering over
the actual number.  Basically, they require you
to have visible customers as an ISP, where the
count doesn't matter as much.

Aaron--is there anything in NRPM about resource
review policy for v6; there's no mandated review
and nothing about v6.

Scott asks if it *BLOCKS* resource review for v6?

It's just resources, it doesn't specify which
resource type.

So the legacy resources are the only exemption.

David Farmer, U of Minn, thanks to Cathy for
bringing this up.  We have a lot of work to do
here, there's some obvious things we need to
move forward with on this.

Would like to thank two people:

Leo and Lea, who are leaving the AC for their
many years of service!!

That concludes today, you have dinner on your
own tonight!

Fill out your survey online!
http://www.arin.net/ARIN-XXIV/survey/

Breakfast 8am, meeting 9am, it'll be like it
was today, and stay on target for policy proposals;
other items will shuffle to make those stay
constant to keep the remote participants able to
participate.

We wrap up for the day at 1718 hours Eastern time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20091021/cec9ffd3/attachment.htm>