[arin-ppml] 2009.10.22 ARIN 24 meeting notes, day 2, part 1

[Matthew Petach]

Sorry, these were my "before lunch" notes, but I dashed off to
grab lunch before sending them out, so they're a bit late this
time, apologies for that.  ^_^;

Matt



2009.10.22 ARIN day 2 morning session

John Curran calls the meeting to order promptly
at 0900 hours Eastern time.

Welcome back everyone, hope you had a good time
exploring Dearborn last night.  Welcome back to
the remote participants.

NRO election winner was louie lee

Daily survey
http://www.arin.net/surveys/ARIN-XXIV

today's winner is a $120 carbon offset
gift certificate

Night at the museum tonight,
6:30 to 10:30 at the Henry Ford Museum
food, fun, dancing, booze, lots of cool stuff.

Get social!  If you see something good at the
meeting, you can post it on facebook or twitter.

facebook/teamARIN

Thanks to Arbor and Merit as sponsors.

Meeting rules are explained for approaching the mic

Agenda
IPv6/IETF/IAB report
RIR updates
NRO NC report
NRO activities report
policy experience report

WHOIS RESTful web service

policies:
2009-5: IPv6 for multiple discrete
2009-3: IPv4 for RIR
2009-8: equitable runout

IPv6 IAB/IETF activities report
Marla will give that report

This is not an official IETF report; there is no official
liason between IETF and RIRs.

routing area work group
IP fast reroute using Not-via address

IPv6 maint working group (6man)
five documents in the workds
one doc in IESG processing

V6 ops, five active documents
router vendor docs are being worked on to help shepherd
vendor CPE efforts.

also one recommending document, but non-binding

SHIM6 WG
little action, only one active document

BEHAVE WG
7 active documents
v6 to v4 translation via algorithmic translations
DNS64, how to deploy with v6/v4 translators
NAT64, NAT from v6 clients to v4 servers
IESG processing 2 BEHAVE docs now

Secure inter-domain routing (sidr)
buttload of active documents on the slide
lots of what-if scenarios about what will happen
 if ITU takes over
path validation being discussed, even though part of
 another working group

Softwire
not much new in active docs
4 more docs published as RFCs

DNS Operations (DNSOP)
3 active documents
changing dns returns during network incidents, what are
ethics of it.

DNS extensions (DNSEXT)
9 active
1 published

OpSEC
1 active document
and 1 published RFC

Global Routing Operations (GROW)
9 active documents

Locator/Identifier Separation (LISP)
new group met at Stockholm
5 active documents

Hiroshima IETF
Nov 8-13
IETF BOF wiki has info on it.

Reference, next meeting
http://tools.ietf.org/bof/trac/wiki

Paul Wilson, APNIC update

Services
policy updates
priority activities
next meetings

major resource delegations at APNIC
IPv4 /8s growing (2009 numbers not complete)
ASNs may be flattening out
IPv6 on the rise (individual delegations)
 2008 and 2009 huge growth

Service levels
2000 members, July 2009 largest month on record
for new members
many member LIRs, though, about a 1000 members
in those
APNIC now averages 1400+ per month helpdesk
enquiries, growing over last year
allocations of space growing slowly, will slightly
exceed last year 100 per month to 105 per month

APNIC 28 policy outcomes
4 reached consensus, still subject to final call
prop-050 -- v4 address transfer policy--receipt subject
  to approval according to current policies
prop-073 -- simplify v6 allocation to existing v4 allocation
prop-074 -- global policy on IANA block allocations
prop-075 -- recovery of unused AS numbers in region

No consensus on 3 policies
prop-077 -- historical address transfer (currently needs no
  justification when transferring) -- proposed to require
  current justification
prop-078 -- reserve /10 out of last /8 for v4 to v6
  deployment; needs more modifications
prop-076 -- requiring further aggregation for v6 blocks
  from LIRs to single announcement

top 10 resource allocations
every 2 years does member survey to assess where resources
should be allocated
1: research and dev activies
2: support network engineering education

...

Research and Development
 work with other RIRs on RPKI
 DNS service dynamics
 DNSSEC implementation
 anycast deployment
expand network monitoring and reporting
 test traffic measurement (TTM)
  sponsorship of 12 AsiaPac nodes (part of RIPE NCC)
 day in the life of the internet (DITL)
 provided 478+ GB of DNS traffic to it

Education
 support network engineering education in the region
 training team active in org
 develop institutional links
 training lab expansion (online training)
 more security training with Team Cymru
 tunneling project with AUSCert
E-learning and self paced learning

IPv6
support more IPv6 deployment
 coordinate and promote v6 activities across whole region
 ICONS IPv6 wiki
 IPv6 messages, materials, outreach, and information
 IPv6 workshop for APEC TEL 40
  very good presence there; strong public interest in
  broadband.

Services
streamline request and allocation process
MyAPNIC features
integrate membership sign-up and resource request form
automate data exchange using web services, provide secure
 channels, link member DSNSEC signed zones to APNIC signed zones

Other:
development of resource certification to support routing security
RPKI for members
more DNS root servers in AP region
 deployments in Taiwan, Mongolia
 deployment of TTM at root server locations

APNIC meeting
Kuala Lumpur, Feb 23 - 5 Mar 2010
with APRICOT 2010

More APNIC meetings
Aug 2010, bangkok,

APNIC 31 / APRICOT 2011
 Hong kong
 joint meeting with APAN
 21-25 Feb 2011

NRO Number Council report, Martin Hannigan
NRO NC, Martin Hannigan, Louie Lee, Jason Schiller

process global policy
appoint 2 board members to the ICANN board of trustees
function adminstratively; write proceedures, execute

New stuff
appointed Ray Plzak to ICANN BoT

working on global policies
2009-6:
2009-3:

Need another ICANN board member soon, too.

RIPE re-elects Dave Wilson
APNIC relects Dr Kenny Huang
See you at ARIN 25

We're ahead of schedule so we'll see if Lixia
can do her demo now instead of later.

Demo of allocation vs routes

She's not looking for testers, per se; the system
won't handle many users.  Looking for feedback, it's
demoware.

Cathy Aaronson gets most of the credit; this is her
second meeting; first was in 2002, when minimum allocation
getting moved from /20 to /22.  Cathy asked if the minimum
size changes, will that affect routing table size?
Lixia said "don't worry"--but now we have an interest
in actually visualizing the impact.
She had one of her students do this as a project.
One of her other students did Cyclops
cyclops.cs.ucla.edu, shows if someone else announces
your blocks

The screen can't really show it; each block on the
screen is a /8
The fills and colours show the reserved, allocated,
multicast, legacy, and each RIR allocated block.

you can check the RIR allocation, and it shows the
colours of how the block is allocated
You can keep clicking to drill in more and more
and eventually get down to specific records for each
individual allocation

More interesting bit is the "what is seen via BGP"
it shows the span of BGP announcements; one allocation,
one announcement for 18/8.

Apple, 17/8, you see many announcements (92) along
with their /8 advertisement.

If you can help them figure out the best way to
visualize the data on where exactly the blocks
are being announced, come talk to her.

Draft policy 2009-5 still isn't ready to start yet.

LACNIC update?
Ricado Patara
still growing in number of allocations
membership growing; just reached 1000 members
staff increasing every year, up to 22 now

Membership evolution over time
small blocks is largest growing segment
1033 members
2 NIRs, members of NIRs are also members of
LACNIC

registration services data
number of allocations made, v4 vs v6 vs ASNs
chart shows some growth in v6

policy development
new process (PDP) since last year introducing expedite
 process
only one meeting per year, may need faster process
2 co-chairs
 francisco aria (mexico)
 nicolas antonielly (uruguay), elected May 2009


Policy under discussion
ratified by board, to be implemented shortly
 2009-01
 2009-02
 2009-03

last-call:
 2009-08: IANA policy for RIR allocations of ASNs

LACNIC XII meeting
in panama city, may 24 to may 29 2009
300 people from 40 economies

LACNIC Caribbean 2 meeting
July 16-17, trinidad/tobago
70 attendees, 17 countries

IPv6 tour 2008-2009
visited: TT, AN, DO, PA, PE, BO, EC, CO PY, BZ, NI

Frida program
some money for ISP programs; call for projects finished
beginning of october; soon will announce project selected
for funding

Outstanding Achievement Award
First award, Ms. Ida Holz, head of central computer
 service of university of the republic, Uruguay

Public affairs
Government working group
 facilitate communication w/gov regarding Internet resources
 admin
1st meeting held in

Organized CITEL
workshop on regional interconnection

+RAICES project
anycast copies of f-root to be installed
Sint Martin most recent deployment

RPKI--issue certificate for each IP allocation
DNS platform upgrade/DNSSEC deployment
already signing lacnic.org as test bed.

Any questions?  Nope.


OK, back to policy:
draft policy 2009-5: multiple discrete networks
allows IPv6 initial and subsequent allocations for
 discrete networks within single org.

No legal impact
staff impact minimal

28 posts, 12 people
3 in favour, none against

Heather Schiller will do the AC presentation

proposed to solve the problem of organizations that have
several discrete and totally separate networks.
IPv4 already allows this; this basically brings IPv6
into similar alignment.

Text stayed same as 4.5 for IPv4
except for utilization requirements
IPv4 has the specific utilization language.

This just requires that you show you have a separate
network requirement, following criteria in section
6.5.2 (which you can read in your NRPM program guide)

Kevin Loch, Carpathia networks -- he does run multiple
discrete networks today, he fully supports it.

Kevin Oberman, ESnet, assuming the first part of 2009-7
was passed, it would completely obviate the need for
this, would it not?

David Williamson, tellme; if you get a single /48 as
an end site, if you have multiple sites, you can't
really break up the /48 into routable blocks, so 2009-7
doesn't cover this.  He supports this policy, it sounds
like?

Owen DeLong, HE.net, they have many customers who have
expressed a need for this policy; a video delivery
company for example needs this; he supports the policy
completely.

Leo Bicknell, ARIN AC, he supports the policy.  This
applies to a small number of people, but for whom it
is very important.
Can we get an idea of how many people have a need
like this?

A: ARIN does not have this in any type of stastical
model, right?  Leslie notes that she does have the
data, it's just not auto-accessible.  Will it change
his answer?

Cathy Aaronson, Cascadia, she responds to Kevin about
why removing /32 aggregate requirement doesn't help.
She had 2 divisions with 2 different business models;
one was mostly utilized, the other barely used; she
couldn't split the /32 into 2 /33s, she really did
need a second block for the second network.
She is totally in support of the policy.

Andrew Dul, wrote original v4 proposal, he supports
the v6 proposal; it did make things easier for ARIN;
it is about the way companies do business today.
ARIN needs to foster v6 on the internet, we need
to support companies in their ability to do business,
and this is one way in which companies do business.
In terms of removing single /32 announcement, he doesn't
think this solves it either, same reasons as Cathy.

Kevin Oberman comes back and after Cathy's explanation,
he now supports this fully.

Jason Schiller, Verizon, he is in favour of it even
though it does add more routes into the global table.
He can see a need for this for multiple stub networks;
it should not lead to a large increase in global routing
tables.
In v4 flavour, there is a requirement where the overall
utilization of all discrete networks is looked at.
It is not clear if the v6 policy should have the same
language; but it's not clear if we should have same language,
but we may have a check to make sure earlier allocations
are being used.

David Farmer, U of Minn--is it staff's opinion that this
applies to end site as well as ISPs?
A: Yes, applies to both.
Then he does support it.

If you are against this, speak up.

Joe Maimon, remote comment; policy as written appears
to prevent opening the floodgates,...[I lose last part,
as scott is speaking too quietly and quickly to make out.]

microphones are now closed.

Now we vote on 2009-5:
in favour: 79
opposed:   zero
total in room and remote: 146

ACSP
Open consultation question and answer process;
a quick summary of these will be coming up momentarily

This is basically a suggestion box
provides a formal mechanism for the community to suggest
change or additions or suspension of ARIN services or practices

This allows for public view for issues, to make sure that
a formal response is issued.

There's also staff initiated questions that are raised to
the community

Changes to ARIN resource revocation procedures
Should overdue period be shortened to 6 months
from 12 months before address block is reassigned.

At 6 month mark, it would be revoked, and be
announced to the community in a feed; that way,
it would be in hold-down for six months before
getting re-assigned.

Comments on this are welcome.

Changes to ARIN RSS feed
add daily recovered address space to the RSS feed
should it be extended to provide data in XML to allow
 for programmatic sucking into databases?
but that could be an announcement of blocks open
for hijacking.

Retiring ARIN email POC templates
It's out there, we talked about it yesterday.

Please feel free to put comments on ARIN discuss
mailing list.

Break time, talk to info center, see materials,
election help desk is open, billing help desk is
open, be back at 11.

BREAK TIME!

We come back from break, and jump into the NRO
activities report from Adiel Akplogan
(Numbers Resource Organization)
 RIRs working together

Current office holders
 Adiel, Axwl, and Raul (AfriNIC, RIPE NCC, LACNIC)
NRO coordination groups
 ECG (engineering)
 CCG: (communications coordination)
 PCG (public relations)

NRO expense distribution 2008
 AfriNIC 3.2
 APNIC  26.5
 ARIN   27.3
 LACNIC

ICANN meetings
Mexico City, 1-6 March 2009
 present status of IPv4, IPv6, what we're doing about it

Future meeting next week in Seoul

Internet Governance Forum
NRO-EC represented in MAG (Raul Echeberria)
Next meeting, Nov 15-18 in Egypt

International cooperation
ITU
 provide internet number stats to ITU members
 participate in Telecom World
 Meeting with ITU to understand IPv6 address management
OECD
 NRO has joined ITAC
 contributing to several OECD meetings

Timeline for IPv6 support by RIRs
ip6.arpa delegation planning
DNSSEC planning
resource certification coordination

Addressing IPv4/IPv6 issues

Retreat outcome
Create new public affairs coordination group (PCG)
decided on some permanent distribution of some NRO functions
CG chairs and EC chair to come from same RIR starting 2010
Agree on limiting ASN 2-byte allocations to RIRS to 2 per RIR.


Update from the RIPE NCC
Vital statistics
6388 members
 over 1000 members from russia alone
Budget of 15.2M EUR
staff: 112
stable board composition
long term improving efficiency

Planning for 2010
general meeting in october
 draft activity plan/budget (17.5M EUR)
 draft charging scheme (slight rise next year)
articles of association
 simplify election proceedure
 enable e-voting for remote participation

Yet another k
k-root node in Africa deployed.
Will talk to LACnic about south america

TTM partnership with APNic
 new node in pakistan, more to follow
BGPviz
RIS backend arch improvements, 10x faster
Hard at work on new portal

Customer service highlight
remember 2007-01
 get a grip on those PI assignments
As per 24-08-2009
1935 out of 4900 registries have participated
9101 out of 27k resources have status set

Training and IPv6
IPv6 testimonials (interviews with members from the
 community about their experiences with IPv6
 published on IPv5ActNow and Youtube
 short per-topic cuts

e-learning news
DNS SEC e-learning
 first module published

Science group
making progress on quality and consistency of mostly
historical registration data.

new tools:
REX (resource explorer)
 dig up historical records for past 10 years on block
Netsense
 status of internet
INRDB

RIPE Labs
 Robert Kisteleki
Forum for presenting new ideas and tools
http://labs.ripe.net/
launched at October RIPE

still getting the bugs worked out, it can
be a bit slow at times, but coming along nicely.
Not meant to be RIPE NCC, but for whole community

External relations and communications
donated sizeable amount of paul rendeks' time to
 NRO for PR and Comms effort
Also, secretariat support for ASO (heavy hit on
 resources)
strong support for EU IPv6 survey
 600 responses
 similar to previous ARIN study
 recently completed by APNIC

Outreach
17-18 sept, Moscow
21 setp roundtable for gov't and regulators
22 sept LEA Workshop
5-9 october RIPE 59 as well as ITU telecom World, Geneva

Meetings
regional meeting in beirut, 28/29 October
RIPE 60 (3-7 May 2010)

Suggestion--next year, warm up the room!!


Draft 2009-3: Global policy, allocation of
Similar in every region but ARIN; adopted in other regions
or in discussion.
Does it help to have a global policy that's different
in each region?

Don't get hung up on exact wording, we may need to
adjust a bit with ASO

Original proposal required return of address space to
IANA.

ARIN required legacy space to go to IANA, other space
return was 'optional';

reworked it; now says RIRs "may" return space to IANA.
New IANA to RIR IPv4 allocation policy; 1/10th of IANA
free pool to each RIR upon request, every 6 months

No legal risk
staff concerns; fractured /8s, serious reverse DNS
 concerns

staff concerns; will take more work, but won't be
 impossible to do.

54 posts, 15 people,
1 in favour, 5 against

If we use term "may", it becomes suggestion rather than
policy; better places for suggestions.

Once the free pool is exhausted (IPv4), no policy for
IANA redistributing blocks smaller than /8, or for RIRs
to share/transfer between them.

This creates a new global pool of returned space that
can be divided among RIRs.

The concerns mainly focus on the mandatory return of
the full block.

The policy was revised to only return if it was
designated for return under local policies or
proceedures.

any space designated for return would still follow
the same formula as originally proposed.

concerns: reverse dns implications for fractured /8s.
Now you delegate all the sub-blocks.
Not an insurmountable obstacle.

Should we be fragmenting returned space among RIRs?

Possibly this policy won't get much use since it's
optional, so why bother

Should we move it forward/why?
avoid having smaller returned space get stuck in IANA
because it's less than a /8
provides mechanism to move space between regions if
 appropriate

All the other RIRs want to do this, let's show them
that we want cooperate in good stewardship

provides more flexibility for working with reclaimed
space in the future.

Floor is open for discussion of policy 2009-3:

Leo Bicknell, ISC, thinks concepts involved are of paramount
importance; we need to get space back from RIRs back to IANA.
But original policy and amended policy go about it in the
worst possible way, and create many problems for NRO.
Policy combines policy to give space to RIRs (global
issue, needs all 5 RIRs), with problem of RIR returning
space to IANA (a local issue within each RIR).
second thing, ommission in original document, no requirement
that IANA use needs-based allocations.  He thinks that there
needs to be clear text explaining the rules behind it)
He opposes both the original and proposed change.

Owen DeLong -- HE.net -- creating problems for NRO isn't
a reason to object to a policy.  The policy makes it up
to each RIR to return space as they see fit.
Can we put policy into process with NRO, and then let
NRO work it with the other RIRs to see if they want to
adopt it with changes proposed

Martin Hannigan, Akamai, he is opposed to policy, feels it
is lipstick on the pig.  RIR transfer policy is the heart
of matter.  A global transfer policy would be a better
starting point.  This is a problem in that it applies to
just legacy space; needs to apply to all IP space.
Fulfillment concern; at 10%, some may

Joe Maimon CHL--if ARIN is only one to adopt with optional
"may" clause, won't other RIRs call foul?

John notes that ARIN "won't" return space due to "may"
clause, it simply doesn't mandate it.  Historically in
this region, we've returned space; but that's no
guarantee of future behaviour.

Scott notes that there are two things global community
wants to accomplish; handle redistribution of space,
and provide pressure on all RIRs to consider global
needs not just local needs when returning space.
Impression is that other regions would rather have
structure set up with optional return; this wouldn't
hurt us, and would help provide that framework.

Paul Wilson, APNIC -- transfer policy in APNIC
requires that recipient justify space they wish to
receive based on requirements.  That is essentially
needs-based policy, in compliance with ARINs policy.

After run-out, the policy is no longer needs-based.

Martin --historical precedent seems to refer to 46/8,
47/8, 50/8; references chosen strategy,
do we really need a policy to identify chosen strategy?

Scott--don't believe there's a way we can modify this
proposal in a way that would make it better.  We can
either support, or reject, in which case the global
policy fails.

Lixia--the one fact people may not be aware of, routing
could make use of which /8 is allocated to which RIR for
doing route aggregation.  From North America to Asia, only
a few exits, so aggregating /8s to regions could be used
to help the global routing table.
She is not in favour of it.

Paul notes the transfer policy is in final call, this
policy is still under discussion.
If this policy were adopted, IANA would still have a
set of address to allocate, so "runout" would not have
actually occurred.
If there is address space at IANA being addressed by
this, then runout has not happened.
If we "runout" and then more space it appears, it's
not clear if we flip back to 'pre-runout' language
or not.

John at rear mike--the perception that the RIR system
of separate regions with bottom up policy building
is incapable of fairly sharing across the globe is
used in arguments that are detrimental to the RIRs.
There may not be much of this space to return
anyhow; it may be that more damage is done to the
structure of the RIR system by worrying about the
possiblity that some space may move away from ARIN
than actually having space move.

Martin Hannigan, Akamai, at any point without a global
policy, any RIR could change their policy away from
this.  For second point, cooperating globally is
good; but there's an expectation that everyone play
by the same rules.  From a business side, there are
concerns about costs related to this.

Mics will close shortly.

Jason Schiller, Verizon, clarify Paul's point.  This policy,
and other flavours, seem to set up a *new* pool called the
recovered IPv4 pool.  It seems that according to 10.4, the
existing policy phase is done through the IANA pool.
If addresses get returned prior to depletion, they will
go into recovered pool, and cannot be touched until the
IANA pool empties, we move into exhaustion phase where
1 final /8 is given to every RIR; at that point, we
are post-runout, and those rules apply.

The trigger condition in APNIC 50 for when they can no
longer receive additional space; until commencement of
use of final /8 is the trigger; if they get final /8,
but use RIR recovered space in the meantime could last
a while.

Joe Maimon, CHL, without mandatory return, policy
has little harm, but also could be useless under
scarcity pressure.  Would also support policy
with return size greater than RIR 6 or 12 month.
The concern about size of legacy space is also
a concern.

mics are now closed.

Leo Bicknell ISC -- can you clarify why these go into
recovered pool instead of IANA pool?

John notes that there's a specific allocation algorithm
on how to evenly divide up the space when regions have
unequal draw rates.
Designed to have even distribution over time; that
can't happen unless it goes into a specific pool with
specific rules.

Jason Schiller, Verizon; if we vote this down, indicate
why we don't like it, so it can be documented so that
other regions can work to address the concerns.
If we vote down either original policy or the proposal,
we should explain why.

Voting on draft policy, 2009-3:
in favour: 21
against:   26
voting members, local and remote: 146


Regardless of which way you voted, talk to the AC members;
let them know what you think; they have a very difficult job
to do on this one!

It's time for lunch, 90 minutes; we're going to be at lunch
until 1330, on second floor in Bistro; take your valuables
with you, no security here.

LUNCH!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20091022/20dd617b/attachment.htm>