RIPE 46 Amsterdam, Netherlands DATABASE WORKING GROUP, 1st SESSION 2003/09/03 A. Administrative Stuff: Scribe Can Bican B. Action Items 45.3 to expose development process inside RIPE NCC database department: SK: we moved whois to sourceforge. We are thinking about the rest of it. WW: considered to be done. 45.1 add maintainer contact to erx mail exchange. Done. C. WORKING GROUP MANDATE AND CHARTER: WW: I ask you to review the old mandate of the group and other working groups and try to find out if we have any overlapping with those. We want to avoid doing the same thing in two different working groups. Any ideas? SK: My initial idea was to split database update. Software we develop, and the service level would go to services working group. I'm open to any suggestions from the community. WW: I usually prefer new functionality from user working groups. Then we can (db-wg) can deal with the implementation. I'd like to come back to this issue tomorrow at the end of the meeting of this working group. You can send either to the mailing list or to me. D. DB Operational Update (SK): - Statistics: -- number of objects going down, query and update rate is getting higher. -- Historical contents displayed, Person cleanup and SK TLD removal mentioned. -- irt objects increased by ~150%. -- domain objects declined, and inet6nums increased. -- Update sources displayed. -- Gentle increase in syncupdates, up to 10% expected. -- query load is increasing, but no operational problems. -- domain referral queries are on the rise. -- so many people query database that it's a public service than a member service. -- no news in database ops, and it's good news! Unreferenced person cleanup: -- 35% of unrefed person objects are deleted. Process began in 29 May 2003. -- ripe-dbm receives about 70 tickets per day. -- spam still a problem. We filter spam, and notify senders that we filtered them. -- ripe-dbm is an open mailbox. -- version 3.2.0 has been published. Denial messages now contain client IP. There are also several internal changes. -- rpslng server prototype and changes to irrtoolset has been published. Supports ipv6 and multicast RPSL objects. Prototype sees little use. Proposals: - status attribute changes - x509 changes - org object Previous proposals: - default to protected inetnum inet6num domain: - seperate presentation - notification for more specific. Done - removal of cross notifications: partially done. - reclaim functionality, mnt-lower on set objects: ongoing - CIDR to range conversion for inetnum. - route authorization for more specifics, to improve aggregation. No action, not forgotten: - deprecate NONE - CRISP - RIRs submitted a requirements draft. Expect to operate in conjunction to whois. -- End of the Presentation WW: who knows about irrtoolset and rpslng? (some people raise hands) Is irrtoolset using one server for ipv4 and other for ipv6? KP: It doesn't have this functionality yet. WW: How many of those cross notification stuff are in the database? SK: Not so much, but no figures. WW: Where are the RIR requirements for CRISP? SK: It's probably in the ietf page. But we can send it to the list. --------- E. The status: attribute (SK): - Current state explained (allocated pa/pi, etc...) - PA and PI have nonobvious meanings. There are no enforcement of rules. There are differences between ipv4 and ipv6. Unspecified status is overused. Many objects have no status at all. - recent draft document proposes a lot of status values. - feedback from apnic: "that's a lot of rules! Maybe two attributes would be clearer." - organization object could make registry clear, by using a simple status, combined with the org object. - sub allocation policy depends on this attribute. LIRs are also waiting. These changes should be done once. So the proposal is to implement a simple change: SUB ALLOCATED. -- End of the presentation WW: Which parties consensus do we need to go ahead with this proposal? Anyone against this proposal? (no one objects) SK: Let's bring this up in the planary. -- End of the presentation F. Organization object Proposal (EG): - Idea: Provide information about an organization, LIR, or any other company, university, charity. Add a mechanism to tag objects to reference via the org: attribute. Also the ability to find objects held by an organisation, with an inverse query. - (Object template displayed) - unique id for each organization, basically a nic handle. It will be regenerated and reuse won't be allowed. - org-name and org-type are obvious in usage. Org-name is a lookup key, is ascii only. Org-type is IANA, RIR, NIR, LIR or NON-REGISTRY. - org: attribute in all objects, points to an organisation object representing the entity that hold the object. Mandatory in allocation inet(6)nums. Mandatory(?) in aut-nums, optional otherwise. - authorization checks: adding an org attribute requires authentication from the holder of the organization object. Removing the reference won't require any authentication from the organization object holder. - examples for the object and the references presented --> WW: does the addition need both authentications? --> EG: Yes. - querying for the objects presented, like 'whois -r -i org ORG-RT34-RIPE'. This will return all inetnums, etc that references this object. - queries will also return relevant organization object: inetnum: organization: person: person: this can be turned off by '-r' flag. - Deployment: Each LIR receives an organization object. Preliminary plan is presented, available in the presentation. - open issues: business-id: proposal. Motivation is not clear, the query user would not know what to do with it and remarks: attribute can be used instead. - open issue: put org: attribute in the organisation object itself? Could be useful to show dependencies among organizations. - open issue: mandatory in aut-num: or not? - do we really want to have these open issues? HPH: The idea is to create a strong mapping between the organization and the company. It will make it possible to track companies. ??: Not all organisations has this information. So it can't be mandatory, so it better should be put into remarks. JM: For hijacking purposes, hackers look for closed businesses. If we collect this ID, we can make sure the work is valid. HN: we have ERX transfers, so we need to have also 'ALLOCATED BY ERX'. EG: Not all of these statuses are handled by LIRs. SK: We have 'EARLY REGISTRATION' status already. We don't have strict guidelines, so we change or keep the information depending on the response from owners. ??: Do you have status fields for suballocations? SK: Policy is to implement. ??: suggestion for business id: We can have a prefix to point to the country code and the type of the number? EG: What's the point in having another attribute? JSD: the point is to parse it. EG: I propose implementing this later. ??: how to convert he information from person/role to organisation? EG: We can create multiple person objects. AV: May it be a restriction to have only one org reference? EG: If there are multiple duties, there are already multiple person objects. WW: Why not restrict the org link to 1? For assignments, this may be required. EG: we can think about it more. If there is a use case, we should implement it. AV: observation - who is required to approve the link to an org object? in irt, they have two authentications. Maybe this scheme can also be implemented in org objects. ??: we can have the same problems implementing authorization as we had in route authorizations. EG: we can enable some changes through lir-portal. WW: I think different update paths shouldn't provide different capabilities. SK: I think it may be plausible implement maintainer authentication only for specific attributes. WW: I want to come back to HP's explanation of why he wants a business id. The intention is reasonable, but should also be discussed in different working groups. Also making it mandatory may be problematic for legacy address space. EG: any organization can create an organization object.