May 17 Task Force Findings / Recommendations

May 17 WG Meeting, 07/21/2000

Proposed Agenda:

1. Scope and goal of discussion
2. Description of current procedures for obtaining address space,
assignment windows, approvals
3. New LIR growth
4. Assignment window
5. Response time and emergency measures
6. Usage Criteria
7. Category priorities
8. accessibility and communication
9. tools



List of attendees

Nurani
Joao
Anne
Wilfred
Stephen
Barbara
Daniel
Sabine
Gert


1. Scope and goals of discussion
 Propose changes to policies and procedures for address assignments to
ultimately be submitted to LIR WG, with the clarification of best
practices and tangible steps to achieving those goals. This group will
not determine how RIPE NCC internally achieves those goals.

2. Current status of procedures

a. Process includes sanity checks that may be delegated to LIRs

b. Previously no automatic review of Assignment window, now
auto reminders in place, made difficult by no flagging of good/bad
tickets, no record of why assignment window was denied i.e.. The quality
of the LIR requests will be flagged so a more informed decision of the
AW status can be made.

c. Wait queue due mostly to under staffing combined with significant
increase in new LIR growth.

d. Improving ripe-141 instructions (ripe-185) may cut down on common
time-consuming errors. Although the form provides the hostmasters with
enough detail to approve/decline a request it is very sparse on helpful
comments for the engineer/customer filling in the details.

3. New LIRs

a. Nurani provided information on how many new LIRs  are being added,
current rate is ~80/month

b. Who is becoming an LIR? Should we actively discourage LIR's some how?
Raise the setup fee? See 3d.

c. LIRs are coming in a at a much faster rate than previously, ask RIPE
to review resources consumed in supporting LIRs and whether it would be
appropriate to create a specialized group for dealing with LIR
applications, education, etc.

d. Also, review new LIR fees to see if they cover resources consumed by
the application and education process, a new LIR takes up more time and
resources than does a large well established registry with experienced
Hostmaster. But this creates a problem when the same country with more
than one registry uses the same engineers how do you justify charging
them more? and how do you track the experienced engineers, we could end
up creating a market for exirienced RIPE hostmasters.

4. Assignment window

a. Safety net would provide a certain measure of business performance,
problem is that safety nets can be abused if not implemented properly.

b. Flexible assignment window offers more security from abuse and a
traceable audit.

c. This becomes a problem of registration accuracy and address
conservation, random audits difficult to perform.

d. Consensus is that some process of flexible assignment windows will be
appropriate to implement but it will have an upper limit.

e. Run the db audit at the time of the assignment window increase, with
all errors fixed for qualification. This would take the place of audits
at each assignment approval request. This could also be part of the
LIR's responsibility to provide a valid clean audit, rather than the
hostmaster running it. It is also a measure of whether they are really
competent and deserve a larger AW.


5. Category priorities: should different categories of request have
different priorities in the queue? i.e. contact requests are not the
same
as IP requests but how do you decide how important each type is?

a. once we reach our goal of having a reasonable wait queue, this issue
becomes moot.

b. if we reach a point where queue exceeds maximum point, then
prioritization becomes useful.

c. should be looked at in conjunction with response time measures.

6.  Accessibility

a. Phone help desk runs into problems of accessibility for language and
cost factors

b. Possible to set up email help desk as a test mode, possibly a three
month trial

c. Translation of ripe-142 and ripe-185 and other supporting address
space documents to other languages to improve communication and
education for LIRs.

7.  Response time
a. Flexible assignment windows when acceptable limit is exceeded.

b. When a ticket is in the queue for longer than the target RTT, then
certain simplification efforts would kick in. These could be with
multiple levels of intervention, and could be invisible to the LIR as a
separate process.

c. Once a ticket hits the maximum RTT, a special response would occur,
which would be marked as unique and auditable and the special response
should be capped at a certain level (e.g. /22, or number of approvals
per LIR, or other set criteria)

d. RTT is defined as getting meaningful response from hostmaster (the
initial human response) to ticket request, and should apply for each
iteration of reply, not for overall ticket assignment

e. The limiting criteria can be described as:
Response times.

1-2 days - Normal and acceptable
3-4 days - Request simplification processes put in place. Or AW +1
applied on temp basis below /22
5+ days  - Auto approval with auditable response on all requests in
queue
over 4 days up to /22

8.  Usage Criteria  /20 criteria
a. When an LIR gets a /20 as an initial allocation, they may run into a
utilization issue at the 80% mark (12.8 used, 3.2 available) with one
customer able to eat this space up an LIR could end up with no IP's to
assign till more allocated. Again this is only with a high wait queue
once the queue is under control this also becomes moot.

b. Proposal is that if the growth is happening in a very short amount of
time, the utilization level could be set at an amount smaller than 80%,
offering a buffer for growth. So if an LIR can show fast take up at less
than 80% the rest of the /19 will be allocated.

9. Tools

a. db audit tool for LIRs to run before submitting requests for
allocations thus removing the need for Hostmasters to run exhaustive
audits when the problems are caused by the LIR. In other words get your
house in order before even coming back to RIPE NCC for more space.
b. Improved user interface to forms such as the 141 syntax checker.

10. Feedback useful for evaluating the changes proposed are the
collection of statistics regarding IP assignments, LIR growth, and other
elements impacting this process. This should be done on a continuous
basis with a web page resource for the community.

11.  We will distribute minutes to the TF, then distribute them to the
LIR WG and we will prepare a presentation for the September RIPE NCC
meeting.



Your Fellow RIPE Members

May17TF