Skip to main content

You're viewing an archived page. It is no longer being updated.

RIPE 40

RIPE Meeting:

40

Working Group:

Tools

Status:

1st Draft

Revision Number:

1

RIPE-40

Minutes - TOOLS

Minutes of the TOOLS Working Group

Date: 02-10-2001

Chairman: Manuel Valente

Scribe: Can Bican

Manuel explained the aim of the working group, being a group for tools
related to Ripe Ncc. Existing and new tools will be presented, along with
discussions.

He revised the agenda:

1. IPMT tool

2. RAToolSet

3. PGP for hostmasters

4. whois library

5. webwhois script

6. AOB

Manuel asked for any comments concerning last working group. No comments
from the audience was received.

IPMTTool:

- ---------

Development of a tool for LIRs - management of IP allocations, assignments,
requests.

Release of current tool Guy Vegoda - www.robobijal.org - one of the most
powerful tools. Development is open to community. Downloadable from the web
site. It has an internal database and contains everything needed to process
IP allocations. Ripe Ncc decided to provide development help for this tool.
There is a mailing list on Ripe '[email protected]'.

IRRToolset:

- -----------

The tool is for the Internet routing registry project. This is a set of tools
for Routing Policy Analysis and Configuration, consisting of utilities like
rtconfig, prtraceroute, ... Formerly this was known as RAToolset.

Question: are these tools also available for ipv6?

Andrei Robachevsky: Not yet, but we're picking up suggestions for development. At the moment we're trying to migrate.

question: is there a request for ipv6 as requests?

answer by andrei and nurani: no

PGP for Hostmasters:

- --------------------

The idea is that hostmasters can be contacted by PGP. There are three
phases in transition from current practice to using PGP:

1. signing: all hostmaster mails will be signed to ensure the source.

2. encryption-decryption: hostmasters will encrypt mails and accept only
encrypted mails. Right now, anyone could pretetend they're from a
particular LIR. Thus, this will help Lirs in their interaction with hostmasters.
there will only be 'one' key for all hostmasters, so
there is no need for LIRs to collect numerous keys, each different for each
hostmaster.

3. key management: Ripe will be accepting keys from LIRS for
authentication.

Whois library

- -------------

Format of whois output is rpsl(text). Returned results are objects.
There are lots of tools and scripts to manipulate whois database using
these. All have
similar tasks. Ripe Ncc considered that a c library will be very useful for
community members developing applications for whois.

requirements: parsing and validation of objects. This library will use the
internal code of the whois daemon of ripe ncc. So, updates in development
will be easier. We also intend after the completion of library to build a
perl library as an interface. API is still under development. We expect it
by the end of this year.

WebWhois:

- ---------

New web interface to whois database. Andy presents this web interface.

Nurani, as answer to questions regarding submission if ipv6 objects: in the request form, we ask you to describe which address range
will be announced thorugh this as, and it can be used for both v4 and v6
addresses, not to confuse this.

Andy presenting Whois CGI Interface:

- ------------------------------------

Questions from Andy: How many people used the web interface? ( a few ) How many of them are technical? ( most )

The old CGI was outdated. It also lacked some user friendly features. And,
management wanted it.

It is intended for both power users and newbies. It also had to be flexible
enough to construct complex and simple queries and intuitive to use.

How it was developed?

1. Button driven.

2. Simple and Advanced search screen

3. Simple form- command line interface

4. advanced form-gui utilising checkboxes, scrollboxes, etc.

5. Hypertext links provide help text windows. Help texts had to be more
descriptive than, for example, Apnic's tool.

Advanced search options are grouped logically - taking the reference guide
document as a reference. It is developed using CGI.pm module and
internally written OO perl modules.
CGI::Application module extension to CGI.pm hasn't been used, could be
considered to use in future. Tested by
hostmasters as they are 'typical users'. Their feedback was invaluable in
refining the help texts.

url: Not publicly available yet.

Future Enhancements:

* Add frames to display indexes of results. It will be handy when there are
lots of objects returned.

* Expand the scope of the help text to be more interactive, to compansate for
the reference manual.

Further information:

http://www.ripe.net/ripe/docs/databaserefmanual.html

Questions: due to apnic and other experience, a couple of suggestions:
first: don't do anything that requires javascript, because most users
won't use it. Second, don't play with the text output in html. Don't enforce the
frame environment, since it is very annoying to the end user for
flexibility.

Andy: Javascript can be turned off. If they turn it off, they don't need help (opposition from audience : provide links instead of js popup windows).

George Michaelson from APNIC about APNIC's services:

- ----------------------------------------------------

MyAPNIC Project: Features and Facilities - Prototype Demo

the idea: more member concious.

* to provide a secured member service web interface, allowing each member
to access private information and invoke specific APNIC services. This
project is a continuation of CA prototyping.

Member's reluctance to update whois database, postponing it until they need
additional resources, due to hard-to-use interface.
Skill gaps, creating extra workload to APNIC's hostmasters.
Sensitive information set between APNIC and members requiring better
protection.
Mail based request forms prone to typo error, reducing productivity.
A challenge to increase membership value.

myapnic provides a unique member's view.

Apnic database consists of:

- - whois

- - finance/admin

- - training

- - request tracker

Features:

* easy to use:
encouraging members to update their internet resource database usage,
shortens learning curve,
simple, user only sees his/her assigned screens,
prefilled forms of APNIC already have the information.

* secure:
protected with both server and client authentication (ssl),
apnic act as the trusted CA - customers require an elevated for trust for
sensitive transactions,
information visible only to those who have the right credentials (bound
to the client certificate).

* flexible:
allows each member to setup their own user base and authority which suits
their organization structure,
provides a platform for further service enhancements.

Joao: to community: would you like to access directly to your information before asking hostmasters?

( no objections )

AOB?

None.

Tools from the audience?

None.

website at http://www.ripe.net/tools/

Questions?

None.