You're viewing an archived page. It is no longer being updated.
RIPE Meeting: |
36 |
Working Group: |
LIR |
Status: |
Final |
Revision Number: |
1 |
Please mail comments/suggestions on:
LIR Minutes RIPE-36
Minute taker - Eamonn McGuinness (RIPE NCC Hostmaster)
AGENDA
1. Admin
-scribe, participant list, charter, mailinglists
2. Agenda
3. RIPE 35
- minutes
- actions
4. Reports from the Registries
- RIPE NCC
- APNIC
- ARIN
- ICANN
- Status of the Latin and Afrinic
5. ICANN AC Upcoming Election
6. Status of ICANN Ad Hoc Group
7. IP addresses to GPRS infrastructure
8. Microallocations in the ARIN region
9. Minimum Allocation
10. Name-based webhosting
11. AW's for registry's infrastructure (eg. headends)
12. ripe-174 RIPE NCC Conflict Arbitration Procedure
12. Interim report from the ICANN ad Hoc group
--------------------------
3. Action list from RIPE-35 :
Action Owner Status Description
35.1 Chair Publish policy document
35.2 Chair Publish election procedure
35.3 WG Subscribe lir-wg
35.4 NCC PGP Key exchange procedure
35.5 NCC Implement PGP for hostmaster mail
35.6 NCC Make db checking tool available for self audit
35.7 Chair Task Force on addresses to GPRS infrastructure
4. Report from the RIPE NCC - Nurani Nimpuno
http://www.ripe.net/ripe/meetings/archive/ripe-36/presentations/
Some points in the presentation :
- Asused public released
ftp://ftp.ripe.net/tools/asused-public-0.1b.tar.gz
- AS# checker released
http://www.ripe.net/cgi-bin/web147cgi
- New FAQ
http://www.ripe.net/ripencc/faq/index.html
- Hiring Technical Advisor for the Hostmasters
IPv6
- 17 sub-TLAs allocated
- 8 ranges reverse delegated
QUESTIONS
HPH: wait queue 7 days at the moment, when will it be down again to 2
days? Next week or one week before the next RIPE Mtg?
Joao: unfortunately not next week. We have hired more staff, who have
to be trained. We're also looking into tools and processes, haven't
started changing things yet, want to analyse it carefully before.
Trying to have a staffing level that allows us to address variations
in work load.
WW: did not participate in discussion on mailing list. Might have a
bit more relaxed view, knows more about the background of the
NCC. Would like the community to achieve (not just the NCC) to improve
the information flow. We as a group could have done better in spotting
the fact that the problem was growing, could have saved a few months
when the review process would have started earlier. Start discussing:
what is acceptable delay time, what can be done to improve and keep
it. Joao mentioned 2 days turn around time as acceptable, not sure
anymore if this view is shared by the community, used to be acceptable
in the past, maybe not anymore. We all suffer from the problem that we
only see our point of view, NCC only sees their point of view, he as
academic LIR doesn't know the view of commercial LIRs etc. Proposes to
set up a review process to review boundary conditions and what the
process should be. What's number of e-mails in the wait queue, how
many requests, how much resources, are there peaks etc (some of this
is already on the web now). Having this information available would
allow the LIRs to have a tool to adjust their expectations. Not sure
if throwing more and more resources is the solutions. Maybe adjusting
rules may be more effective.
Barbara: suggestions: like to see easier way of communicating when
filling out a request form (like a help desk), not about specific
requests, but just simple questions with filling in form etc. (more
administrative questions). We've being turned away by the RIPE NCC
secretaries and have to wait up to 2 weeks for an answer to a simple
question. Alternatively have separate queues for requests and for
these kind of questions. Also would like to see percentage of request
sizes. Then we figure out what a good comprise between efficiency and
proper management of the IP address space.
Nurani: agrees with suggestions about improving the information
flow. Trying to answer simple questions fast. Will provide these kind
of statistics.
Juergen: agrees with WW but has an additional comment. Looking at
Assignment Windows of the already experienced LIR, Every time NCC
decreases the AW the work load increases.
Nurani: agrees that NCC must be more proactive with increasing AW. Ask
the LIRs also to approach the NCC when they feel it should be
raised. However, must find a good balance with management of IP
space. Easier to rule out mistakes at the start than correcting it
later.
Eamonn: people are moving fast in this business, experienced staff
leaves and leave knowledge gap at the LIR. Some LIRs even ask to
decrease AW, for instance because they don't find the time to train
staff internally. Yes, decreasing AW increases work load, but asks
people to keep the above point also into account when discussing this.
Juergen: surprised that we do not have a new policy draft for the IPv6
policy document. This is unsatisfying.
Joao: we want a global policy draft, there have been various
discussions about that, there seems to be disagreement about one
particular point in the policy, this is the only thing outstanding.
HPH: trying to summarise, most concrete suggestion was to set up a
group to look into information flow and processes, will meet during
the coffee break t set up a charter.
- APNIC Report - Anne Lord
http://www.ripe.net/ripe/meetings/archive/ripe-36/presentations/
75% of members were not using all their /19 (80% ?) after a
year. Proposal to reduce AW to /20. Met with agreement. Implemented 3
months from March.
IPv6
12 allocations. Over half were 6Bone members.
- ARIN Report
http://www.ripe.net/ripe/meetings/archive/ripe-36/presentations/
IPv6
6 requests, 4 blocks allocated.
Harvad: some of us have address space that predates the establishment
of the RIRs, that means that ARIN is currently responsible for
maintaining the DB data and the reverse delegation. How can we
interact with you ?
Richard: modification template on web. There is activity underway to
distribute the records to the region the network is located.
Q: Isn't there a process to do this easier ?
A: Yes, a smoother procedure will be introduced later in the year.
Juergen: all RIRs report about their address utilisation, it is
however difficult to gain an overview over the global IPv4
utilisation.
WW: just want to make sure that whatever is developed for the
distribution also works for the emerging RIRs. What are you going to
do to inform the parties effected by this. Will this be an
administrative issues, a DB issue, a policy issue and where will it
discussed?
Richard: this has not been discussed yet, maybe good idea to set up a
dedicated list for that. Nothing has been done yet, obviously we'll do
everything to inform the community.
- ICANN Report - Louis Touton
http://www.ripe.net/ripe/meetings/archive/ripe-36/presentations/
Very quick, skipped most slides. Slides looked like the ones used by
Andrew McLaughlan in Feb.
- IPv6 (will be important very soon, increased demand on IPv4 due to
new technology, this will increase demand for Ipv6 very quickly)
- General mix of global versus regional address policy (in IPv4 big
goal is aggregation deserves some re-assimilation certainly with Ipv6,
because the scarcity is gone).
- Emerging RIRs
QUESTION:
Randy: if the purpose of spinning was internationalisation is it still
true that the Doc has to approve all changes in ccTLDs?
[eamonn - Did he not ask] "Does the US Department of Commerce still
have authority to make changes to ICANN ?"
Louis: Yes, all changes in the root zone requires formal approval by
the DoC until everything is set up fully. Community needs to gain
confidence.
- Report about emerging RIRs. AfriNIC Meeting Report - Mirjam Kuehne
http://www.ripe.net/ripe/meetings/archive/ripe-36/presentations/
Andrew Brooks from South Africa is coming Thursday to speak more about
this meeting at the Plenary.
QUESTIONS:
WW: What is the function of the listeners ?
Louis: When the RIR gets established it will have 3 seats on the AC,
in the meantime they will just listen as anyone in the public can
listen.
- LacNIC - Joao Luis Silva Damas
Sao Paulo meeting this week (i think).
- Task Force met at the break.
(see HPH slides)
Participants: Daniele Bovio, Joao Damas, Juergen Rauschenbach, Sabine,
WW, HPH (others added later).
They set a Goal; To improve NCC Services to its membership. Anyone
else wants to participate, speak with the Chair.
5. ICANN AC Upcoming Election
(see HPH slide)
6. Status of ICANN Ad Hoc Group
HPH presented some slides prepared by Raimundo Beca who is on the Ad
Hoc Editorial group. No report yet (probably at Yokohama ICANN
Meeting).
7. IP address space for GPRS Infrastructure - Kim Fullbrook
Working party setup after RIPE-35. There was a number of presentations
covering GPRS, UMTS and the bridge to the Internet. Task force
setup. They met in London 2 weeks ago. GPRS Operators asked for their
address requirements from their GPRS networks. Not all were at that
advanced stage. The question of public unique address space for this
was proven. Estimates for address need for infrastructure came to :
~400 GSM providers x ~2000 IP addresses for GPRS n/w's = 800K.
QUESTIONS:
Randy: What kind of a uniformed address policy is needed in order for
roaming to work ?
Kim: Requirement is that they all use unique address space.
Hph: Do we have consensus that public addresses are needed ?
Randy: what is the difference with GPRS with respects to other new
technologies ?
Answer: Nothing is different, thats the point.
Anders Roos: the main reason is that we have about 400 members in the
GSM association, a lot of them will request for address space. In
order to reduce work for all parties, they try to establish a common
policy and procedure.
WW: grateful for the work and the effort done to achieve this. Very
acceptable solution found. Just as a clarification, what was presented
might be new policy for the GSM operators, but is not viewed as new
address allocation policy.
CONCLUDED - SOLVED
8. Microallocations in the ARIN region - Cathy Wittbrodt
ARIN has been received requests for small amounts of PI address
space. ARIN Advisory Council did some research and found that most
people would not have a problem as long as important infrastructure is
defined clearly. TLD server, RIRs and ICANN should be added to the
list of 'critical infrastructure'.
Randy: Why is it necessary to have a unique special infrastructure
defined ? There was for instance special /24s reserved/assigned for
the root NSes. None of them are using them, because they don't need
to.
Dfk: Shares Randys view. What he thinks wants to be achieved, is
notification mechanism (a registry where network addresses can be
registered and ISPs can decide to route that or not). Then you don't
need to decide what is routable ? Addresses are made portable by the
fact that ISPs decide to route them, not made portable by the ISPs to
assign special addresses. Suggests to register the addresses they
already use rather than assigning them special addresses.
Randy: What worries them is that parts of the Internet are fixed that
aren't broken. The reason that the root NSes didn't use the special
addresses is that they were already part of existing networks and are
connected to the Internet, and they aren't being filtered out by
others. Also the ccTLD servers are connected currently and they have
secondaries.
9. Minimum Allocation Proposal from the RIPE NCC - Nurani Nimpuno
Question to the community; Should we lower minimum allocation from a
/19 to a to /20 ?
http://www.ripe.net/ripe/meetings/archive/ripe-36/presentations/
Stats show over 2 years ~60% of /19 allocations were not used (to
80%). We would have saved ~200 /19s if we allocated /20s 2 years ago.
Concerned from the community was to have proper notification of where
the /20s will be allocated from so filters can be adjusted.
Anne: APNIC will be not be starting with a fresh /8. We need to fill
up some of the old blocks first.
Randy: appreciates that and suggests to use certain ranges in a /8 and
publish that.
DFK: suggests to have in a machine readable format what the minimum
allocation of this particular /8 for all RIRs.
Richard: ARIN have stats for 1 year progress of using /20
allocations. Some organisations that received the contiguous /20 chose
not to aggregate their two /20s into one /19.
Randy: nothing he can do about that, but the routing registry can be
used for that. In ARIN's one year experience with that policy how many
of the organisations came back for an additional allocations ?
Richard: 198 organisations received a /20. Initially 37 out those came
back for an additional /20 within 1 year (less than 20%). Hesitant to
free up those other /20s because that wouldn't be contiguous with
another /20 (for another organisations) - tradeoffs to be made.
DFK formulates the conclusion: start allocating /20 from 1.8.2000 and
identify blocks concerned by 15.07.2000. These blocks should be as
long as possible but not smaller than a/10.
NCC also has plenty of space left in 213/8 & 62/8. NCC will allocate
from 62/8 as normal. NCC will keep aggregation in mind but cannot
guarantee it.
10. Name-based Web Hosting - Joao Luis Silva Damas
Question to the floor; Is it reasonable to make all new requests
compliant to http 1.1 ?
ARIN makes it mandatory with some constraints.
APNIC strongly discourages 1.0
WW: Do you have any estimate of the amount of address space that would
be saved assuming one allows for exceptions. What do you think is the
potential gain ? I usually do not like a solution that requires a list
of exceptions to the default.
Joao: address space saved is not as significant as with the change of
minimum allocation change. Don't know the exact number.
Randy: e-commerce requires an address per page. This is common
practice now.
Louis: What would be the burden on the NCC to enforce the policy
change ?
A: Is not that big a deal really, but NCC has the duty to review
policies when there are alternatives out there to conserve address
space.
Security is still an issue, thats why 1.0 is still used.
WW: uses the example of policies for dial up and now a large
proportion of these users are moving to always-on access and get a
fixed address anyway. It would not be worth changing the policy if we
only safe a small amount of addresses but would have to review all
kinds of exceptions.
Anne: isn't there work in the IETF to upgrade http to allow name based
hosting with SSL and e-commerce?
Randy: yes, but it will take a long time until this will be deployed.
Bill: in previous types of discussion when the general concept of
LIRs/RIRs etc came out, the question was raised if the address
delegation policies ???? If such a policy would be implemented he
would want to have it temporary first.
Bill: it is the RIRs duty to use appropriate diligence on protecting
Internet resources.
Randy agrees and thinks that the dial up policies had more a social
effect in that the RIRs were watching. Maybe the web hosting issues
will have a similar effect.
He believes that people care about the right thing if they can do it.
Rob believes that there will be a growing list of exceptions and it
will be awkward for the NCC to check all this.
Consensus is that the policies remains the way it is but that the NCC
strongly recommends to do the right thing if possible.
11. AW's for registry's infrastructure (eg. headends) - Cathy Wittbrodt
This was not really understood by the group. Some registries will only
make address assignments that the NCC consider are part of their
infrastructure. For example, cable operators. An AW is no use to them
because no matter what the size AW they receive, any requests will
still be above it and therefore it forces them to send in ALL requests
to the NCC. Cathy thinks this is unfair to these type of LIRs and wants
the policy changed to allow an AW to be given to its headends for
example. Just some way so that they will not have to send in EVERY
request, even when they are competent.
This should be added to task force. There are many other providers out
there who have the same problem as Cathy's "friend".
Randy suggests to write this up and send it to the mailing list,
because people might not clearly understand how that network is set
up. Why is this different than ISPs with individual POPs ? They also
only have one AW.
12. ripe-174 RIPE NCC Conflict Arbitration Procedure
AOB
Joao showed workload from Hm's per size of request. Could not really
discuss it as there was a power failure. Joao was asked to put this
and other stats on the web.