RIPE 34

RIPE 34 LIR-WG Minutes 1.2

Chair: Hans Petter Holen
Scribe: Eamonn McGuiness

Agenda

1. Admin
 scribe
 distribute participants list
 charter
 mailing lists

2. Additional agenda points

3. Introduction of the new Registration Service Manager, Nurani Nimpuno
 Meet the RIPE NCC hostmasters

4. RIPE 33
 minutes
 actions

5. Reports from the Regional Internet Registries

6. The RIPE community policy making process (Mirjam Kuhne, RIPE NCC)
 Discussion: Is this well understood?

7. ICANN - ASO
 Current status, further work.
 Definition of the selection procedure for the address council

8. Auditing Results and experiences (Mirjam Kuhne, RIPE NCC)

9. Discuss an additonal value for inetnum status attribute
 (James Aldridge, EUnet)

10. PGP authentication of e-mails to and from hostmaster@ripe.net
 (Maldwyn Morris, RIPE NCC)

11. Release of rtt source code (Maldwyn Morris, RIPE NCC)

12. AOB
12.1 IPv6 policy matters (move to LIR WG?)
12.2 mnt-by from mandatory to optional (Wilfried Woeber, ACONET)
12.3 PI address assignments to end-users (Yuval Shchory, Netvision Ltd.)
12.4 DB support for multiple Domain objects

1. Admin

Eamonn McGuiness volunteered to take notes. The participant list was
circulated and signed by approximately 89 attendees. The Working group
web pages and mailing list were pointed at:

Mailing list: lir-wg@ripe.net
Archive: http://www.ripe.net/mail-archives/lir-wg/index.html
Web pages: http://www.ripe.net/wg/lir/index.html

>From the web pages the following description of the woring group can be
found:

The Local IR working group deals with issues that concern Local
Internet Registries. For example, Local IR operation, and the local
implementation of RIPE policies and procedures are discussed here.

There was consensus that we may need a better formulated charter
stating that the LIR-WG is the open forum where RIPE policy is made.

ACTION LIR-34.1 on Chair to suggest clarification of WG charter.

2. Agenda

The agenda previously circulated to the lir-wg list, was approved and
the following items were added to Any Other Business:

 Wilfried Woeber: RIPE NCC Auditing Activity
 Yuval Shchory: PI Assignments

3. Presentation of RIPE Hostmasters

The new Registration Services Manager Nurani Nimpuno was introduced.
Paula Caslav left the RIPE NCC to go back to the US. Also all
hostmasters present at the meeting were introduced to the audience.

4. Actions

All actions from RIPE 32 were done before RIPE 33. There were no
additional action points from RIPE 33. The WG minutes (published as
part of the plenary minutes) from RIPE 32 were approved.

5. Reports from the Regional Internet Registries

5.1. Report from the RIPE NCC Registration Services Activities (Mirjam
Kuhne)

See http://www.ripe.net/meetings/ripe/ripe-34/pres/

Some highlights of the developments since the last meeting:

Beginning of the year almost 2 new members per calendar day. This has
now slowed down, but is still higher than the last few years,
approximately 1.5 new members per calendar day. Those new members tend
to grow slower than members used to in the past. This means that the
workload is not increasing proportionally to the number of new
members. Due to automation and efficient procedures, there was no
major staff increase even though the number of new members has grown.

The RIPE NCC has started allocating IPv6 addresses, 6 sub-TLAs
allocated so far, smooth start.

The RIPE NCC proposes to change the procedures for reverse delegation
such that only members can submit requests for reverse
delegation. This would decrease the workload of the RIPE NCC and
increase the quality of the DNS. This issue will further be discussed
on the lir-wg mailing list to understand all aspects of such a change.

This item was added to AOB for further discussion but due to time
shortage it was concluded with the following action:

ACTION LIR-34.2 on RIPE NCC to start discussion on changing the
reverse delegation policies, and make sure all aspects of it are fully
understood.

The RIPE NCC is currently busy updating and improving the LIR Training
Course material and delivery. This will be ready before the next RIPE
Meeting.

A few questions were raised after the presentation:

Q: Is there a deadline for the change in procedure for reverse
delegation?

A: Before the end of the year: We are currently re-writing the inaddr
robot and would like to implement this change at the same time.
Comment: We need to think about the implications for address space
originally assigned by last resort registries.

Q: Test Traffic Measurement will be part of membership services in
2000. How will the RIPE NCC charge for it?

A: It will be a different type of membership service than registration
services, because the users are not necessarily the same. We are
slowly moving TTM in this direction and need to further investigate an
exact charging scheme for it.

Q: Are all statistics shown during the presentation also visible on
the web site and are they kept up to date?

A: They will be stored on the web site as part of the presentation,
but we will also put them on the statistics pages.

ACTION LIR-34.3 RIPE NCC: store statistics on web site and keep them
up to date.

Q: Can we get support from the RIPE NCC for addresses that have been
assigned by the InterNIC?

A: Yes, you can, we currently provide administrative support for our
members. We are also working on a more structural solution, so that
the assignments are stored in the DB of the region the network is
operated in, even if the addresses have been originally assigned by
the InterNIC. We will also work together on a technical solution for a
distributed reverse delegation.

5.2. Report from the APNIC (Kyoko Day)
See http://www.ripe.net/meetings/ripe/ripe-34/pres/

Some highlights:

IP distribution is growing in the region even though there was a dip
due to the economic crisis in Asia. The growth during this year is
mainly due growth in India and Australia.

Priorities for the next period: review of the APNIC
membership-charging scheme. Currently the categories Small, Medium,
Large are self-determined (like the RIPE NCC charging scheme was
before 1997).

5.3. Report from ARIN

Unfortunately no one from ARIN could attend the Meeting. Mirjam Kuhne
announces that ARIN will hold their AGM in October in conjunction with
a first open policy meeting and the second meeting of ARIN WGs
(18.10. - 20.10.1999)

5.4. Reports from other regions

At the ICANN Meeting in Santiago in August ICANN welcomed the
developments in Africa and Latin America. In Latin America various
groups have been co-operating and form the LatinNIC, they proposed a
draft paper, which they asked the existing RIRs to review. The Interim
Board of the AfriNIC is currently reviewing proposals of potential
AfriNIC hosts.

6. Policy Development in the RIPE community

Mirjam Kuhne gave a presentation to describe how policy is developed
in this region and how people can participate in this process. See
http://www.ripe.net/meetings/ripe/ripe-34/pres/ for details.

The process is simple, open to anyone and based on consensus. After
Mirjams presentation, Hans Petter asked wether the WG felt that the
process was open enough or if it needed to be changed to make it more
open. Mark McFadden from CIX explicitely stated that the processes
in RIPE are truely open and do not need to change. The WG
Participants were in agreement that these are true open processes and
that there is no need to change them. During the discussion that
followed it became apparent that more effort must be spent to make the
existence of RIPE known to the outside world and to clearly
distinguish it from the RIPE NCC. A comment was made that the RIPE
community and the RIPE NCC membership is mainly comprised of small
ISPs and that the policies and guidelines are sometimes difficult to
be implemented by larger ISPs.

Hans Petter understands the concern, but has experienced that
difficult or unusual cases were handled on a case by case bases
usually solved in the end.

The question was raised if there is a voting procedure to finalise
agreements and policies? Hans Petter clarifies that there is normally
general agreement and a voting procedure was not necessary. Someone
thinks that people might be intimidated to speak up on the mailing
list and that LIRs in particular might be afraid that their
performance as LIR will be questions if they raise their opinion on
the mailing list. Mirjam clarifies that the RIPE WG mailing lists are
open and independent and not directly linked with the operations of
the RIPE NCC and individual members. Maybe this needs to be made known
more widely.

ACTION LIR-34.4 on the Chair to form a Task Force to document and
publish the current procedures for policy development.

Volunteers to this task force were to contact the chair after the meeting.
Further process will be:
- - announce the charter of the task force to the mailinglist
- - Interested parties may volunteer
- - A draft will be posted to lir-wg for discussion
- - A second draft will be based on that discussion
- - The document will be endorsed by consensus at RIPE 35

The outcome of this task force will be useful not only to the working
group members but also externally to promote the openness of RIPE.

7. ICANN - ASO

The LIR-WG needs to discuss and define the selection procedure for the
RIPE region nominees of the ASO Address Council.

The WG chair had asked Rob Blokzijl, the chair of RIPE, to chair this
part of the discussion because the WG chair was among the nominees for
the Address Council.

This is the first time the RIPE community needs to define a procedure
to select representatives to external bodies. This task is
particularly difficult, because ICANN has introduced some time
pressure: They would like to have ICANN directors elected by the
beginning of October. As the ICANN directors are to be selected by the
address council the address council needs to be selected at this very
RIPE meeting. Therefor the carefully defined time schedules and
deadline for the set up of the Address Council and the selection of
the ICANN directors can not be followed. The RIPE community therefor
needs to define an interim procedure for the initial set of Address
Council members. In the time before the next RIPE meting the procedure
needs to be revisited and refined.

Each candidate submitted a paragraph to motivate why they think they
are suitable for the Address Council. This has been made available on
the RIPE Web pages and copied and distributed among the audience. 3 of
the 8 nominees were present at the LIR-WG meeting.

There was a discussion if the initial candidates should only serve one
year or if they should be prepared to serve 1, 2 and 3 years as
defined in the ASO MoU. The audience agrees that it would create
instability if all members would change after one year and that they
should serve 1, 2 and 3 years respectively. It was suggested that the
address council at their own discretion may ask their seat to be
reconfirmed by the procedures yet to be defined. This

Q: Why was self-nomination was allowed.

A: It is an open process, if a person believes he or she is a suitable
candidate, why should he or she not nominate him or herself?

Q: Can't we use the same procedure that is used for the RIPE NCC
executive board?

A: The problem is that the RIPE NCC membership is a clearly defined
electorate, but in this case the electorate can not clearly be
identified.

The audience dismissed an e-mail selection process for many
reasons. One was the time frame forced upon us, other being the too
difficulty to verify correct votes.

An attempt was made to find general criteria in order to make a
possible pre-selection.

Finally it was suggested to organise an open ballot at the plenary
session. Gordon Lennox from DG-XIII, European Commission warned the WG
not to fall into the trap of pure voting. He admires the open and
transparent processes in the RIPE community and urges the audience to
make sure to have some sort of consensus decision incorporated in the
procedure, either before the voting or after to endorse the decision.


ACTION LIR-34.5 on Rob Blokzijl to summarise this discussion and
present it at the plenary session the following day.

Several ideas for the final procedures were suggested: to look at
USENET voting, the IETF procedures and the RIPE NCC Association
procedures. These will be further discussed on the lir-wg list.

ACTION LIR-34.6 on the Chair to form at task force to define final
Address council selection procedure.

8. Auditing Activity at the RIPE NCC (Mirjam Kuhne)
See http://www.ripe.net/meetings/ripe/ripe-34/pres/

Mirjam clarifies that this activity has been initiated by the LIR-WG
in order to ensure fair distribution of address space. She shows
statistics that have been derived after having performed this activity
for more than a year now. In summary it can be noted that many LIRs
are familiar with policies and procedures and apply them.

One area of attention is the RIPE database. The RIPE NCC works
together with LIRs to maintain and update the information in the
database.

There was some uncertainty regarding the role of the RIPE NCC member
in this process. It was not clear to some attendees if the information
provided by the end-user can or needs to be amended before passing on
to the RIPE NCC. This is specifically related to documentation, which
is provided in local language. After a short discussion it has been
agreed that the RIPE NCC requires a certain set of documentation in
English. It then depends on the service the LIR provides to their
customers. Some LIRs may require their customers to provide the full
set of documentation and in English, some LIR may just collect
information from their customers (in the local language) and then
amend and translate it if sent on to the RIPE NCC.

ACTION LIR-34.7 on the RIPE NCC to document the audit procedure in
more detail and to clarify the role of the NCC and the member during
an audit process and what is expected from each party.

9. Additional value for the status attribute (James Aldridge)

James suggests allowing for more hierarchy in the status attribute of
the inetnum object. The rationale behind this is to allow "sub
allocating" parts of a LIRs address blocks to "sub LIRs". This is
important to large (multi national) ISPs. Also Wilfried Woeber is
looking for additional values to indicate for instance returned
address space that needs to be documented during transition to new.

ACTION LIR-34.8 on James (and Wilfried) to write up a proposal and
send it to the LIR-WG mailing list.

10. PGP authentication of mails to and from hostmaster@ripe.net
 (Maldwyn Morris, Software Manager RIPE NCC)

The RIPE NCC would like to offer PGP authentication for mail sent to
the hostmaster@ripe.net. In the first instance this will only be used
for authentication, not for encryption. There is consensus in the WG
that this would be a useful service. As other security mechanisms
(e.g. in the RIPE DB) this will not be a requirement but optional.

ACTION LIR-34.9 on RIPE NCC to proceed with plans to implement PGP as
an option for hostmaster communication.

11. Release of rtt source code (Maldwyn Morris, Software Manager RIPE
 NCC)

There is consensus in the LIR WG that the RIPE NCC may publish the
source code of the rtt ticketing system software.

ACTION LIR-34.10 on RIPE NCC Release source code to rtt due to demand.

12. Any Other Business

12.1 IPv6 policy matters

In principle all address policy related matters should be handled in
the LIR-WG. For this meeting the chair had decided not to include Ipv6
policy matters on the agenda, since the agenda already had possibly
time-consuming items already. It was argued that participants
interested in developing RIPE policy only should have to go to one
working group. The chair agrees in principle, but also sees the
advantages of keeping the policy discussions in the Ipv6 WG where Ipv6
expertise is sure to be present. It was questioned from the audience
what the purpose of the Ipv6 WG would be if not to discuss Ipv6
policy. This was not made particularly clear, but a reference to the
work division between the LIR-WG and the DB-WG was made: the policy
discussions takes place in the LIR-WG while technical implementation
details relating to the database takes place in the DB-WG and is
implemented by the RIPE NCC.

The chair feels it is premature to make a final decision on this, but
senses coming consensus that LIR-WG should do policy development for
IPv4 and IPv6.

ACTION LIR-34.11 on Chair Discuss moving Ipv6 policy matters to
lir-wg.

12.2 PI Assignments (Yuval Shchory)

Eyal wonders if end-users who require PI address space should become
RIPE NCC members themselves in order to obtain address space directly
from the RIPE NCC. Mirjam clarifies that although it is discouraged to
assign PI addresses to end-users it is possible if technically
required. These assignments should not be made out of the PA range
allocated to the LIR; the RIPE NCC will make these assignments from a
separate range in order to avoid holes in the PA range of the LIR.

The desire to obtain PI addresses is not a reason in itself to become
a RIPE NCC member and to obtain a separate allocation from the RIPE
NCC.

There was also a clarification to why use of PI addresses is
discouraged: this relates to the additional burden that individual
route entries for end-users create on the global Internet. The RIPE
policy in this area has thus been carefully worded to promote PA
addresses and CIDR. It is also worth noting that certain big US
providers do not accept fragments of PA addresses from peering
partners (but may do so in transit agreements).

12.3 Reverse delegation process -> discussion on lir-wg to fully
 understand all implications

This came up during Mirjams report. Since we had no time left to
further discuss the aspects of this it was added to the action list to
conclude this discussion on the mailinglist. (See action LIR-34.3)

12.4 DB support for multiple Domain objects

Was not discussed. It was suggested to move the discussion to the db wg.


Actions:
Action Owner Status Description
LIR-34.1 Chair Suggest clarification of WG charter
LIR-34.2 WG Reverse delegation process -> discussion
on lir-wg to fully understand all implications
LIR-34.3 NCC Store statistics on web site and keep them
up to date.
LIR-34.4 Chair Form a task force for documenting the
existing policy process
LIR-34.5 RB suggest a selection procedure for the
plenary
LIR.34.6 Chair Form a task force to define final Address
council selection procedure
LIR-34.7 NCC Clarify LIR-RIR expectations in the audit
process
LIR-34.8 JA additional value for the inetnum "status" field
LIR-34.9 NCC Proceed with plans to implement PGP as
an option for hostmaster communication
LIR-34.10 NCC Release source code to rtt due to demand
LIR-34.11 WG Discuss moving IPv6 policy matters to lir-wg