DB-WG Minutes RIPE32 Edinburgh

  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 at ripe.net>

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 at ripe.net>
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--
--------------------------------------------------------------------------------