DB-WG Minutes RIPE32 Edinburgh
- Date: Tue, 26 Jan 1999 15:59:32 MET
Dear DB-WG,
attached is the draft minutes for the Edinburgh meeting.
Thanks for the scribe, and apologies for not having been able to
properly distribute them in time.
I'm going to come back to this during the WG meeting on Thursday.
Wilfried.
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10667.907769257.1@localhost
Hi, Wilfried !
I have revised the draft minutes. Here is
the second draft.
Regards,
AMRM
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10667.907769257.2@localhost
Content-Description: Minutes
Minutes of the DB-WG, RIPE-31, Edinburgh, Scotland.
==================================================
The minutes at a glance:
-----------------------
Introduction:
------------
Wilfried Woeber opened the session and welcomed
the participants.
The task of scribe was ascribed to AMRM.
The attendance list was circulated to the
participants.
Agenda Bashing
--------------
The agenda had already been sent to the mailing list. There
were two additions: a proposal to redefine the IPv6 network
object (inet6num) and site; and a proposal to hide the
"notify" attribute in the output from a whois look-up. The
running order or sequence of the agenda was modified to
allowd David Kessens to chair the IPv6 WG.
Minutes from RIPE-30:
--------------------
WW said that the minutes from RIPE-30 had been misplaced,
but that a search for them was in progress.
Actions from RIPE-30:
--------------------
Ronald van der Pol, SURFnet
-To summarise the proposal to allow role objects
in the admin-c attribute
DONE ==> PROPOSAL
RIPE NCC
-To clearly document the use of contact information
in the RIPE db. (This was an implicit action on
the RIPE NCC).
David Kessens
- To circulate a proposal about DNS-style tagging
of NIC-handles.
DONE
Ambrose Magee
-To publish the URL for the inconsistency report
on the DB-WG list
DONE (but this project was suspended in July, 1998).
[NCC
-To implement pgp-authentication in the db software.
DONE]
Summary, with Action Points:
---------------------------
Administration:
Participants: 50 (or 110010, Base2).
Notes by Ambrose Magee.
Actions & Agenda
Regular reports
Internet Draft presentation:
draft-zsako-ripe-dbsec-pgp-authent-00.txt
draft-ietf-rps-auth-01
Recommendations & Decisions:
* Stop special handling of "changed:"
* allow role objects in "admin-c" lines
* semantics of "refer:" alert, control flag
* suppress notification-related attributes,
similar to "changed:" ? No, see previous
item.
Discussion & Input received for semantices and handling of
PGP functionality
=> further input welcome/required !!!
Actions from RIPE #31
---------------------
*AP1* Referral Mechanism:
_NCC_ To document the new mechanism; by default show
authoritative data only and include a hint for the
end-user;
provide a flag to include the "local" object as well.
Circulate to TLD, DNS, DB WG's; require input from TLD's.
*AP2* _WW144_ To circulate the proposal to roll-back the
whois -c change (the "changed:" attribute).
*AP3* _WW144_ With input from _EJB3-RIPE_, to circulate the
proposal to allow role objects to be referenced by the
admin-c attribute.
*AP4* _NCC Registration Services_ To review the impact of this
change and, if required, to specify operational restrictions
(e.g. not to be used in inetnum objects that describe
allocations).
*AP5* _Steve Byrne_ (Steven Burley ???) To circulate a write-up or
description of the proposed nameserver object.
*AP6* _Kevin Hayton_ To send to the DB-WG list his input on naming
RIPE documents and on how to use the names.
*AP7* _NCC_ To release the draft for ripe-157++ asap;
target date: mid-November 1998.
DB-Software-related activites:
- document "changed:"/whois -c option interactions
- develop a proposal on how to generate serial numbers
(for updates) and to retire the "changed" line
- input from the DB-WG to the re-implementation project
is required asap.
- new code to handle the "auth" issues raised in the
Routing WG
- release specification and design information for the
re-implementation asap; DB-WG to provide input; the
new code is to be made available as soon as it is
written.
Minutes of the DB WG, RIPE #31
==============================
[Note from the scribbler: *AP* == Action Point]
RIPE Database Operations Update
-------------------------------
- written by AMRM, but the presentation was given by JLSD1-RIPE
(AMRM was on temporary loan to the Scottish National Opera :-) )
This presentation may be seen at:
http://www.ripe.net/meetings/ripe/ripe-31/pres/r31upd/index.html
RIPE Database Software Development
----------------------------------
Roman Karpiuk gave a presentation on the status of the
development of the RIPE Database Software. (WW144 pointed
out that this is the existing software, not the new
implementation).
This presentation may be seen at:
http://www.ripe.net/meetings/ripe/ripe-31/pres/ripe-db-software/index.html
There was some discussion during and after this presentation.
-Duplicate Person Objects:
Gert Doering, (SpaceNet), asked if fuzzy matching would be done
on duplicate person objects. RK answered that currently, only
simple string comparison would be done.
Janos Zsako, JZ38, (BankNet), suggested that the proposal to disallow
duplicate person objects should be discussed with the ccTLD's.
He suggested that each ccTLD should allow other ccTLD's to add
"notify" attributes to person objects that are referenced by
domain objects from more than one country.
WW144 felt that the ccTLD must be consulted.
-Plans
RK asked for input from the WG.
-Questions && Discussion
+ Referral Mechanism for Domain objects
WW144 thanked the NCC for implementing this referral
mechanism. He suggested that an option be added to
"whois" that forces a whois look-up to return the
local object. He suggested that alternatively, both
(or all objects, if they exist) should be returned -
a sort of recursion. He asked for input.
David Kessens suggested that "-R" be used as the option
or flag to suppress referral or look-ups outside the
RIPE database.
Asger Kring (?), DK ccTLD Registry, said that these
look-ups are often done by end-users and thus, it
would be better to keep things simple. He suggested
that the default behaviour be referral only and that
a "flag" or option be required to get the local object.
David Kessens agreed with this.
WW144 suggested that we reverse the default behaviour
of whois, for _new_ functionality.
DK58 recommended that if a referral is done, then
a notice should be prepended to indicate that recursion
has occured - otherwise, the RIPE NCC may be open to
complaints about the content of someone else's database.
WW144 agreed with this recommendation and pointed out that
the output of whois is already prepended with a copyright
statement.
MN131 suggested that comments on the use of national [TLD]
registries be obtained, in particluar on the replication
of data.
*AP* WW144 asked the NCC to document this proposal and to
circulate it to the mailing lists (DB, TLD, DNS).
NO8 recommended an insistance on feedback from the
TLD-WG. He went on to suggest that the default
behaviour be to show only the authoritative data,
but that a flag would show the local object.
JZ38 again raised the issue of ccTLD's and their
response to the issue of detecting duplicate person
objects and how to handle them.
"changed" attribute
WW144 agreed with RK that the change in the output of
whois was agree in the DB list, but that problems with
updating objects, and the "knock-on" or consequent
problems with the auto-inaddr robot were not seen.
He further suggested that it would be required to
document all these interactions and a proposal would
then be made to the RIPE community. Eventually, we might
use the "-c" flag again.
David Kessens suggested that we roll back to the original
situation and fix the problem. He did not like the idea
of hacking the existing situation.
Hans Petter Holen suggested that an internal history
of the database objects be maintained.
JLSD1-RIPE pointed out that such an internal history
would require internally generated data and that first,
the users must agree to this.
PC111-RIPE explained the problems with the auto-inaddr
robot. The robot checked the inetnum object in the db
to see when a certain assignment was made and to see if
this assignment was done within the range that the
assignment window had at that time.
DK13-RIPE suggested using serial numbers and timestamps
as a method to keep an internal history of the objects.
JLSD1-RIPE agreed in principle with this idea.
JZ38 pointed out that it was not documented that the
first "changed" line should be kept. WW144 supported
this idea.
*AP* WW144 promised to circulate this proposal to the DB mailing
list (i.e. to roll-back the change to the output of whois
and the "changed" line).
He further suggested that the RIPE NCC and the DB WG
devise a method of tracking updates of objects (using
serial numbers ?) and then retire or redefine the
function of the "changed" line.
Role objects in admin-c lines
-----------------------------
EJB3-RIPE, following up the proposal made by RVDP3-RIPE
at RIPE #30, said that the current use of the role
object is limited to non-admin-c attributes. He went
on to say that address space is not assigned to an
individual, but to an organisation. He then made a
presentation about using role object in admin-c lines.
This presentation is available at:
http://
His presentation may be summarised by saying:
the use of the role object in the admin-c line
should be allowed.
- Questions & Discussion
AVA4-RIPE pointed out that NCC Registration Services need
to see when someone leaves a local registry, especially
when that person has experience of LIR procedures and
policy. Currently, when a local registry changes its
admin-c, the top level allocation object must be changed
manually by NCC Registration Services.
EJB3-RIPE replied that the information is still in the
role object.
WW144 recommended that the admin-c for a role object must
reference a person object and not another role object.
*AP* WW144 proposed that role objects should not be allowed for
top level allocation objects. He went on to say that if
there was consensus on this issue, then the boundary
conditions should be defined.
JZ38 agreed with this exception i.e. that role objects
should not be permitted in top level allocation
objects.
DK58 agreed with the proposal and suggested that an
"organisation" object be specified in the new
implementation of the db.
EJB3-RIPE recommended that this proposal be implemented
asap.
*AP* WW144 recommended that the DB WG should accept this
proposal and thanked EJB3-RIPE for making it.
At this point, the session adjourned for coffee.
----- Coffee -----
Suppression of the "notify" attribute in the output of whois
------------------------------------------------------------
WW144 said that there was a proposal from Australia (who ???) to
suppress the "notify" attribute in the output from whois. The
DB WG did not have a strong opinion on this and this proposal
was not considered any more.
IPv6, inet6num and site object
------------------------------
WW144 reminded the DB-WG that, following decisions made at
IETF-42, formal requests for IPv6 address space were sent
to the three regional registries. The regional registries
will design the procedures and co-ordinate the activities.
JLSD1-RIPE showed a template and an example of an inet6num
object in the RIPE database. He requested comments on what
functionality could be added to, or deleted from the object.
He pointed out that there is no "route" object for IPv6, but
said that the Routing WG will look at this.
WW144 discussed the site object; he said that currently it is
used to track tunnelling and IPv6/IPv4 address translation.
He recommended that the DB WG look at the 6 Bone homepage
on the web at
http://www.6bone.net/
and he recommended that they read the RPSL specifications, the
RIPE-181 document and review the inet-rtr object.
Nameserver object
-----------------
Steve Byrne (Steven Burley ??? ) suggested that a "nameserver"
object be used in the RIPE database.
*AP* WW144 asked him to write a proposal and to circulate it on
the DB WG list.
DB Software Re-implementation
-----------------------------
JLSD1-RIPE gave a presentation on the re-implementation of the
db software. This presentation is available at:
http://www.ripe.net/meetings/ripe/ripe-31/pres/reimp/index.html
- Questions && Answers
Kevin Hayton (KH220-RIPE) asked if the new software
would address the security issues as done in the IRR.
He went on to ask if a web-interface [for updates]
would be provided.
JLSD1-RIPE said that the security issues would be
handled in the new implementation and that if required,
a web-interface would be developed.
JLSD1-RIPE went on to say that the new implementation
would have three separate modules: one each for Inetnum,
Domain and Routing object, but that the underlying access
would be the same.
WW144 asked if the progress of the new code would be made
public ?
JLSD1-RIPE replied that there would be regular reports, which
would be quickly followed up with the new code. He went on
to say that the current aim was to support the current
functionality.
SB-RIPE asked if the new code would be written in PERL.
JLSD1-RIPE replied: "No".
WW144 said that he hoped that the package would be
self-contained.
JLSD1-RIPE said that the new implementation would not
specify which SQL engine should be used. Thus, the new
implementation would have a well-defined API and users
could then obtain appropriate drivers. He added that,
initially, MySQL would be used.
AH102-RIPE asked what was the proposed implementation
language.
JLSD1-RIPE replied that it would be C - for reasons
of maintainablility and resources. He went on to say
that if the new code was to adequately support the
RAToolSet, then it must be capable to respond _very_
quickly to look-ups. Thus, a faster response time
was required (e.g. to support prefix authentication,
as supported by the code of the Routing Registry).
WW144 thanked JLSD1-RIPE for his presentation.
Internet Draft on database security
-----------------------------------
WW144 introduced the presentation by JZ38 by saying that
he [JZ38] had written an internet draft and that this
document would be adopted by the RPS WG of the IETF.
JZ38 presentation may be found at
http://
WW144 thanked JZ38 for his presentation and added that the code
was now available on the RIPE NCC's Beta site.
Deployment of PGP in the RIPE db
--------------------------------
JLSD1-RIPE gave a presentation on the deployment of PGP
in the RIPE db. This presentation is available at:
http://www.ripe.net/meetings/ripe/ripe-31/pres/pgp-sup/index.html
He said that licenses would only be be issued for users who
already had a mntner object and that licences would issued
within the next two to three weeks.
JLSD1-RIPE said that details about support would be sent to
the DB-WG mailing list. WW144 asked that that this mail be
also sent to the LIR WG. HPH2/HPH14-RIPE agreed with this.
WW144 emphasised that the licences were for PGP Version 5.0,
although newer versions were available.
Steven Byrne (Burley ???) asked if the licences were issued
to a user.
JLSD1-RIPE replied that the licences were issued on a per
cpu basis; if a user requires more, s/he should ask for
them.
There were no questions about the cost of these licences.
Upgrade of ripe-157
-------------------
JLSD1-RIPE gave a presentation on an upgrade of, and
a replacement for, ripe-157. This presentation is
available at:
http://www.ripe.net/meetings/ripe/ripe-31/pres/ripe157plus/index.html
- Questions && Answers; ripe-157++
Kevin Hayton (KH220-RIPE) said that although the content
of RIPE documents was important, the presentation was
also important. Furthermore, he suggested that the
naming structure be reviewed and that the documents be
redesigned to include hot links to other documents.
WW144 agreed with this idea for html versions of RIPE
documents. He suggested that key documents be given
*AP* generic names. He also asked Kevin Hayton to send his
ideas to the mailing list.
- Questions && Answers; PGP and the RIPE db
Kevin Hayton (KH220-RIPE) asked if the key certificate
object would be listed in the general whois enquiries.
JLSD1-RIPE replied that it would. KH220-RIPE suggested
that this might be a security compromise.
JZ38 said that a user must submit the public key to the
db so that it is available for anyone to check the
signature.
Petra Zeidler, Xlink, felt that sending a key-certificate
object to the RIPE db by e-mail, with no other checks
was risky.
JZ38 felt that the RIPE NCC should identify to whom a
given certificate belongs and that is why they require
that that anyone who requests a key certificate object
must first have a mntner object in the RIPE db. He
added that any problems with this approach would be
detected by the notification mechanism and then the
problem could be solved off-line afterwards.
WW144 pointed out that this is the first attempt to
upgrade security in the RIPE db, but that it is not
the definitive one. The goal was to implement an
useable system, sooner rather than later, although
the shortcomings of the initial implementation were
known.
Petra Zeidler suggested that key certificate objects
should only be visible to the maintainer her/himself.
The meeting felt that there was a danger that some
people will use the PGP key in the RIPE db for other
purposes.
JZ38 recommended that users should check other sources
of public key rings.
Petra Zeidler suggested that the type of key be mapped into
the key certificate object itself.
JZ38 recommended that users should always retrieve the local
key.
Petra Zeidler commented that a key-ring of 1200 keys
would be slow.
AH102-RIPE commented on how to check the authenticity
of a key, instead of the NCC not taking responsibility
for the authenticity of a key.
JZ38 said that people who use PGP should be aware of this.
RPS authorisation && authentication
-----------------------------------
Cengiz Alaettinoglu gave a presentation on RPS authorisation
and distributed RPS. This presentation may be found at:
http://www.isi.edu/~cengiz/talks/
and it is based on these Internet-Drafts:
draft-ietf-rps-dist-00
draft-ietf-rps-auth-01
- Questions && Answers
Kevin Hayton questioned whether or not RPS authorisation
and authentication could cope with multi-homing.
*AP* WW144 and Cengiz Alaettinoglu promised to send the name of
the appropriate draft to the mailing list.
IETF-42 reports
---------------
WW144 said that there were no important reports from IETF-42.
Input from other WG's:
---------------------
Routing WG:
+ An IPv6 Routing Registry is being planned. WW144
invited the DB-WG to give input.
+ IRR Acceptable Use Policy; WW144 asked if this
would form a basis for a code of conduct for the
RIPE db. WW144 invited the DB-WG to contact the
appropriate individuals privately.
AOB:
---
NULL
Close
-----
WW144 thanked the members of the DB-WG for participating that
morning and then formally closed the session.
------- =_aaaaaaaaaa0--
--------------------------------------------------------------------------------
|
you are here: RIPE -> RIPE Maillists > Archives
