About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section

[db-wg] Draft Minutes from Tallin RIPE meeting

  • To: "Database WG" <
    >
  • From: "Nigel Titley" <
    >
  • Date: Tue, 3 Jul 2007 16:45:22 +0100
  • Priority: normal

Gentlefolk,
 
I've been very remiss in not posting these minutes before, but the extra time has allowed Chris (of the RIPE NCC) and me to give them an extra burnishing.
 
So, don your sunglasses, and view these excellent minutes.
 
Comments welcome
 
Nigel
 

This email and any attachments may be confidential and/or legally privileged. If you have received this e-mail and you are not a named addressee, please inform the sender of this email by sending a return email to the address above and then delete the e-mail and your response from your system. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail. Any views or opinions presented are solely those of the author. Any statements made, or intentions expressed in this communication may not necessarily reflect the view of Easynet. No content herein will bind Easynet or any associated company unless confirmed by the execution of a formal contract by Easynet. Any figures or amounts given in this email are quotations only and are subject to change. Although Easynet routinely screens for viruses, addressees should scan this e-mail and any attachments for viruses. Easynet makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our customers and business, we may monitor and read e-mails sent to and from our server(s).

Easynet Limited a company incorporated and existing under the laws of England and Wales, with company number 2954343 and having its registered office at 44-46 Whitfield Street London, W1T 2RJ.
A. Administrative Matters (5 mins)

    * Scribe - Nigel Titley
    * Distribute participants list
    * Finalise agenda
    	Accepted
    * Approve minutes from RIPE 53
    	Minutes accepted
    * Review of action list

53.5	WW144  	
Wait for the formal consensus of the ENUM Working Group on renaming
NON-REGISTRY to OTHER (in the ORG object type) and then ask the RIPE NCC
to make the change. [Done]

53.4	WW144 	
Alert Routing Working Group about the implications of the ASN16 to ASN32
transition on tools. [Done]

53.3 	RIPE NCC 	
To make sure that if there is a "flag day" for ASN32 behaviour then the
planning and introduction for this is done properly and advertised
appropriately. [Done]

53.2 	RIPE NCC 	
To check and point out this requirement to various software developers:
including but not limited to irrtoolset, quagga etc. [Done, but see below]

53.1 	WW144 	
Close AP50.1 (To make the country attribute on inetnum and inet6num
optional and multiple) and properly reformulate it. [Done 2/1/2007]

51.9  RIPE NCC  	
To contact a subset of the spam tool writers and make sure that they are
aware of the change in behaviour as required by AP51.8 [Done]

51.8 	RIPE NCC 	
To properly implement DB behaviour to always return "irt:" object on
address queries, if it exists. [Done, but see below]

Remote Participation
Jabber chat provided by RIPE NCC

B. Database Update (Jos Boumans, RIPE NCC)

See presentation
	
Database Team
 - 2 new members of the team
	
32bit ASN
 - Has been done to support new numbers. FLAG day was 2/1/2007. 14 are
in use currently. Quagga now supports it.
	
Query behaviour for IRT Objects
 - Changes still in process. Only 1% of inetnums are actually covered by
IRT objects with abuse-mailbox. Final change to add -c flag is backward
incompatible and needs discussion.

Crypt-pw deprecation
 - Started 30/11/2006. 3900 initially in database. 550 conversions in 2
days. Crypt-pw finally removed 22/2/2007.

Documentation
 - Manuals have been brought up to date and one new manual written. It
is proposed that the manuals are not released as RIPE documents to
enable more timely release of the manuals. There was general support for
this. It was also suggested that if necessary, sections could be left as
RIPE documents. For example the User Reference Manual sections could
remain as RIPE documents.

[AP54.2 RIPE NCC + Chairs]
To check through documents and decide how to split manuals into RIPE and
non-RIPE documents.
		
Whois IPv6
 - Now fully integrated into whois.

Operational update
 - Slight increase in queries but otherwise business as usual.

RIPE-DBM
 - Two new members of the team. See presentation for details.

It was noted (Gert Doering) that the lack of references to IRT objects
are due to the lack of -c behaviour and that we should go ahead with the
implementation of this by default. This action has taken considerable
time and we would like to have a flag day very shortly.

[AP54.1 RIPE NCC]
To go ahead with final implementation of IRT query behaviour, within 4
weeks.
	

C. Task-Force on Data Protection Issues (Jochem de Ruig, RIPE NCC)

See Presentation
	
First meeting 7th May at Tallinn.
The whole thing has been made necessary by changes to EU data protection
laws.
	
Proposal to ensure that every object has a maintainer.
	
[AP54.3 RIPE NCC]
Go ahead and investigate ensuring that all objects are maintained,
including timeline and notifications. Submit proposal to the Working Group.
	
It may be necessary to de-automate the creation of maintainer objects.
	
An opt in "white pages" facility within the RIPE Database for industry
related persons is suggested. Some expressions of support for this.
	
[AP54.4 RIPE NCC]
To investigate the provision of a "white pages" facility for industry
related persons.

Discussion on the country attribute.
Support was expressed for retaining the mandatory status of the country
field as it is valuable information. On the other hand the data is being
used to generate other sets of data and hence is being processed in a
data protection sense. The fact that this information is of suspect
value was also raised. Perhaps what we are looking for is an optional
location attribute. The location information is also obtainable from the
ORG object and perhaps this should be mandatory. The RIPE NCC has found
the country attribute useful during the ERX project. We need to
define better the actual required function of this attribute. It was noted that
the country attribute is extremely helpful for research purposes (for
producing the IPv6 report for example) and this information is generally
helpful for the operation of the network.

[AP54.5 DP-TF]
To analyse better the function of the country attribute in inetnum and
inet6num.
	

D. Treatment of Orphaned Objects (Denis Walker, RIPE NCC)

See presentation

Originates from the data protection issue (data must be relevant to the
purpose of the RIPE DB).

Steady rise in unreferenced objects. It was noted that a small number of
people actually want to be in the database and that the removal notice
should offer the means to remain in the database for those who want to
remain in the database just so that people can remain if they wish. A
work around to retain your person object might be to create a poem
object. Reuse of NIC handles caused some comment, as maintainers might
use a NIC handle not understanding that they had possibly changed. It
was suggested that objects should be quarantined rather than deleted.
Concern was expressed that there may be external references into the
database. The issue of NIC handles shared with the ARIN database was
also raised.

General consensus was that we do need to get rid of the unreferenced
objects but there was no consensus.

[AP54.6 RIPE NCC]
To summarise the discussion and write up for the mailing list


Y. Input From Other Working Groups/Task Forces

Resource Certification Task Force (impact on RIPE Database, if any)
[Nigel Titley]. For full CA-TF report please see:
http://www.ripe.net/ripe/meetings/ripe-54/presentations/Certification_Task_Force.pdf

There will probably be an effect, but this is not yet known.

DNS: Retire "rev-srv:" attribute in inetnum: (Peter Koch, DENIC)

See presentation.
 - Summary is that this is no longer needed as it also appears in the
domain object.
 - The top 5 maintainers account for the majority of objects mainly
because this is hard coded in their software.
    	
[AP54.7 RIPE NCC]
To prepare a plan for removal of the rev-srv attribute from the inetnum,
inet6num objects.
    	
Z. A.O.B

WW144 asked if the mandate and/or the chairs of the group needed
changing. There was no enthusiasm for replacing the clown at the front
or of changing his mandate.

 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | © RIPE Community. All rights reserved.
RIPE.NET Homepage LIR Portal RIPE Community