RIPE Database Requirements Task Force BoF
Dear colleagues, The RIPE Database Requirements Task Force (DBTF) will organise its BoF on Wednesday, 6 May from 14h00-15h00 CEST via Zoom. During this BoF, the DBTF will present its latest work and invite participants to discuss what functionality the RIPE Database should provide in the future. The presentation will include quick polls and will be followed by a moderated Q&A. You can register for the BoF at (no Zoom account required): https://ripe.zoom.us/meeting/register/tJMkd-yhrz4uHNDuOIBm8hGvcj8DSDK1Ybog <https://ripe.zoom.us/meeting/register/tJMkd-yhrz4uHNDuOIBm8hGvcj8DSDK1Ybog> We look forward to discussing the future of the RIPE Database with you! Kind regards, Bijal Sanghani on behalf of the DBTF
Dear colleagues, Ahead of today’s BoF, we would like to share with you a working document listing the RIPE Database purpose and other usage. Please note that this is still a draft and that we are sharing it now only to facilitate the discussion during the BoF. You can register to the BoF at (no Zoom account required): https://ripe.zoom.us/meeting/register/tJMkd-yhrz4uHNDuOIBm8hGvcj8DSDK1Ybog See you soon online! Cheers, -- Shane *RIPE Database Purpose (draft)* -- Provide registration information of Internet number resources The RIPE Database contains various data sets for all Internet number resources administered by the RIPE NCC. This information is vital for the stability and growth of the global Internet system and allows users to find information for network troubleshooting and Internet coordination. As the Internet grows in scale and importance, it is imperative that resource holders maintain their information in the database to avoid inaccurate information which can slow down communication and misdirects investigations. All resource holders have agreed to adhere to the RIPE NCC policies which include keeping registration information up to date. -- Facilitating communication about usage of the resources The RIPE community has tasked the RIPE NCC to manage the RIPE Database as a public service, therefore the RIPE Internet Number Registry (RIPE INR) is designed to contain all of the needed information from the Internet number resources managed by the RIPE NCC within its service region. These details in the RIPE Database are maintained jointly by the RIPE NCC together with the resource holders and can easily be consulted at any time by community members. The members, through the availability of the RIPE Database, are facilitated in their tasks of coordinating between network operators (network problem resolution, outage notification etc.). The accuracy and availability of the RIPE Database ensure the correct availability of information related to the resources and their holders and maintainers (RIPE INR) and the uniqueness of Internet number resources usage through registration. The registry plays an important part in the operational coordination between Internet operators, because the design of the RIPE Database has to provide accurate registration information of the Internet number resources in order to meet a variety of operational requirements. Transparency and accountability of the administration of Internet number resources has always been very important, and the correct publication of the registry is an essential element of this transparency and accountability. -- Publishing routing policies by network operators (RIPE IRR) An important subset of the RIPE Database is the RIPE Routing Registry which holds information about routing on the Internet. The routing information is stored in routing policy information described in Autonomous System (AS) objects. The information in these AS objects shows how a particular network is routed on the internet. Announcing routing policies in the routing registry gives network operators an opportunity to configure their routers and filters accordingly. The RIPE Routing Registry is a part of the Internet Routing Registry (IRR), a collection of databases that mirror each other. The IRR is a globally distributed routing information database purposed to ensure the stability and consistency of Internet-wide routing by sharing information between network operators. -- Reverse Domain Name System (rDNS) The DNS Reverse Mapping is a DNS based service to map IP addresses back to domain names. The reverse DNS tree is structured to follow the address 'hierarchy' for both IPv4 (on octet boundaries) and IPv6 (on nibble boundaries). There is no formalised DNS mapping service for ASNs. Since the DNS reverse mapping is closely tied to the address space, delegations usually go to the party registered as holder for that particular address space. Providing DNS reverse mapping management functions (which do not include DNS name service itself) can be seen as a genuine function of both an RIR and an LIR. The RIPE Database is used as a provisioning and documentation tool for reverse DNS for IP addresses under RIPE NCC management. This enables the use of the core address registry for provisioning authorisation purposes (reverse mapping follows inetnum: and inet6num:). There are operational procedures, including technical checks, that guide the operation of the reverse DNS by the RIPE NCC. Those have been developed and maintained under guidance from the DNS and Database working groups. Other, non DNS specific, general rules apply to the objects used for provisioning reverse DNS to the database. -- The RPKI Database The Resource Public Key Infrastructure (RPKI) allows digital certificates to be associated to number resources, thereby providing resource holders with proof of holdership. Each LIR operates its own Certificate Authority (CA) or CA hierarchy, which is signed by the RIPE NCC's CA. The RIPE NCC acts as a root CA for RPKI, and provides the option both to host CA services for each LIR, and also the option to delegate this authority to a CA operated by the LIR. Although it has not traditionally been considered to be part of the RIPE Database, the portion of the RPKI hosted by the RIPE NCC relates to registration information for networks in the RIPE NCC service region. As such, it references and complements the RIPE Database. ------------------- Other Usage ------------------- -- Research into network operations and topology The RIPE Database provides researchers insight into the existing state of the internet and allows them to explore ways in which it can be improved. -- ENUM The ENUM Tier 0 registry is run by the RIPE NCC in response to a request from the Internet Architecture Board (IAB). The RIPE Database is used as a provisioning tool for the technical part of the DNS delegations under E164.ARPA. Registrations are approved by the ITU-T TSB, other decisions (e.g. introduction of DNSSEC) are coming from the IAB. While the ENUM has been subject of a specialised RIPE working group (ENUM WG, topic later inherited by the DNS WG), policy making was and is not a matter of these WGs. While ENUM is DNS based and not a genuine RIR function, when the task was assigned to the NCC, "domain:" objects were in much wider use in the RIPE Database - back then also several ccTLDs had used the RIPE Database as their "whois" repository. The naming structure of E164.ARPA is remotely comparable to the DNS reverse tree and the RIPE NCC as a neutral party fit in the role of a technical operations provider. -- Geolocation The RIPE Database provides functionality that allows resource holders to provide information about where IP addresses are used. Users can query the database directly for this information, and in addition software tools exist which in turn query the database or download the information regularly from database dumps. -- Enabling transfer of IP resources The RIPE Database is used to identify official holders of Internet number resources and their contact information which may be used for transfer purposes. The transfer of an Internet number resource from one party to another must abide by the RIPE Resource Transfer Policies and is not valid unless it is correctly reflected in the RIPE Database. The original resource holder remains responsible for an Internet number resource until the transfer to a receiving party is completed.
On 6 May 2020, at 12:26, Shane Kerr wrote: https://ripe.zoom.us/meeting/register/tJMkd-yhrz4uHNDuOIBm8hGvcj8DSDK1Ybog Shane, Thank you for the invitation. I cannot find any information why I have to provide registration information, who will hold that information and what the privacy rules for this information are. Can you enlighten me there? Daniel
oh goodie. and then i get "Recaptcha error, Please try again." randy
On 6 May 2020, at 13:47, Randy Bush wrote:
oh goodie. and then i get "Recaptcha error, Please try again."
randy
At least you can recognise US sidewalks. Some people from many places have trouble with that. … ;-)
oh goodie. and then i get "Recaptcha error, Please try again." At least you can recognise US sidewalks. Some people from many places have trouble with that. … ;-)
i was not even shown a recaptcha, let alone narrow sidewalks which make one nervous in times of plague separation. my browser is a bit conservative. randy
On 6 May 2020, at 13:53, Randy Bush wrote:
i was not even shown a recaptcha, let alone narrow sidewalks which make one nervous in times of plague separation. my browser is a bit conservative.
If your browser blocks the captcha you must be a bot. ;-) Daniel PS: Sorry for spamming the list. This started as a private rant between like-minded greybeards and I did not notice it escaped. :-(
Hi, Thanks to the Task Force for sharing this draft. It's a helpful start. It would be nice to see more precision in the purposes for each section. Ideally, each section would have a list of purposes clearly described at its start, supported by concise reasoning. Where appropriate, it would be helpful to explicitly call out purposes that are out-of-scope along with the reason. Limiting the scope is probably important for all the sections but is particularly important for the "Other Usage" section as that could easily balloon. I'm glad that the TF called out the possibility of including materials related to RPKI within the scope of the RIPE Database. More detail on this section would be interesting. Kind regards, Leo Vegoda
participants (5)
-
Bijal Sanghani
-
Daniel Karrenberg
-
Leo Vegoda
-
Randy Bush
-
Shane Kerr