- db-wg - mailman.ripe.net

Extending the consultation period for service criticality
by Razvan Oprea 18 Jan '23

18 Jan '23

Dear colleagues, Your input about the criticality rating of the RIPE Database is important. Keeping in mind the busy end of year, and the holidays, we have extended our consultation period until 22 January 2023. Wishing you all a happy new year. Regards, Razvan C. Oprea RIPE NCC

1 1

Performance Evaluation 2022
by Fallon Albrecht 05 Jan '23

05 Jan '23

Hi Ed, Do you have any feedback positive/improvements over my performance in 2022? Cheers, Fallon

1 1

Impact Analysis for NWI-4
by Edward Shryane 16 Dec '22

16 Dec '22

Dear colleagues, Following is the impact analysis for NWI-4 "Role of status: field in multivalued status context", based on the addition of a new status value "ALLOCATED-ASSIGNED PA". The main drawback identified in this proposal is that an inetnum with status "ALLOCATED-ASSIGNED PA" must remain co-maintained between the RIPE NCC and the LIR, and not by the end user. If an end user is required then the earlier alternative proposal to use a tuple (using both prefix and status) is preferable (although technically more complex). Whois Application * Add a new inetnum status "ALLOCATED-ASSIGNED PA". Treat this status as both ALLOCATED PA and ASSIGNED PA. * New allocations will continue to be created with the "ALLOCATED PA" status. * Allow a user to switch the status to and from (only) "ALLOCATED PA" to "ALLOCATED-ASSIGNED PA" themselves. This allows the user to document a single assignment under the allocation. * Follow the same validation rules for both ALLOCATED PA and ASSIGNED PA. This new status has no impact on the validation rules (i.e. no conflict was found between the two status values). * Support the same status hierarchy for ALLOCATED-ASSIGNED PA as for ALLOCATED PA or ASSIGNED PA (e.g. SUB-ALLOCATED PA, LIR-PARTITIONED PA etc.). * An inetnum with status "ALLOCATED-ASSIGNED PA" remains co-maintained by the RIPE NCC. * The inetnum primary key remains the IPv4 address range. Using the same address range with different status values is not allowed. Registry Services * The "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" policy (currently RIPE-733) requires that "All assignments and allocations must be registered in the RIPE Database". This proposal addresses this requirement. * If an LIR wants to create an assignment because they want to document an assignment to an end user, this proposal will not help in this case. The ALLOCATED-ASSIGNED PA inetnum remains co-maintained between the LIR and the RIPE NCC, and not by an end user maintainer. Also any contacts (admin-c, tech-c, abuse-c etc.) are for the LIR and not the end user. * What is missing is that an LIR can not specify an end user customer’s mnt-by and, most importantly, cannot specify the customer’s organisation object. Internal Registry * No impact is expected to the internal registry software. No direct parsing of the status attribute for either inetnum objects was found in interactions with Whois (e.g. organisation changes and transfers). Whois Clients * Clients reading the inetnum status: value must be updated to take account of the "ALLOCATED-ASSIGNED PA" status and treat it as equivalent to both an "ALLOCATED PA" and "ASSIGNED PA" status. Regards Ed Shryane RIPE NCC

1 0

RIPE Database Quarterly Planning Q1 2023
by Edward Shryane 15 Dec '22

15 Dec '22

Dear colleagues, We have published our quarterly plans for Q1 2023 for the RIPE Database: https://www.ripe.net/manage-ips-and-asns/db/quarterly-planning In this quarter, we will continue working on the server-side implementation of NWI-12: NRTMv4 and the migration of the RIPE Database documentation to a new interface. We hope that by providing these plans, we can better inform the community of the ongoing developments on the RIPE Database and get feedback on our work. If you have comments or questions around this, we hope you'll let us know on the list or you can always contact the DB team directly at ripe-dbm(a)ripe.net . Regards Ed Shryane RIPE NCC

1 0

Whois Release 1.105
by Edward Shryane 13 Dec '22

13 Dec '22

Dear Colleagues, RIPE Database release 1.105 has been deployed to the Release Candidate environment. We plan to deploy to production on Tuesday 13th December. This release includes a single change from 1.104: * NWI-19: Change to AS-SET object naming rules (not allowed to create with short format) The release notes are on the website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel… More information on the Release Candidate environment can be found on our website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/rc-release-candid… Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

NWI-10 "Definition of Country" is Complete
by Edward Shryane 02 Dec '22

02 Dec '22

Dear Colleagues, The RIPE NCC has now completed the implementation of phase 3 of NWI-10: "Definition of Country". This work included: * Recording the legal address for all End User organisations with Provider Independent resource(s); * Populating the legal address country code into end user organisation objects in the RIPE database; * Updating the country code in the Extended Delegated Stats for all the Provider Independent resources an end user holds to the legal address country code. * Internal software changes to synchronise changes of legal address country code to the RIPE database and Extended Delegated Stats. More information about NWI-10 is available here: https://labs.ripe.net/author/stefania_fokaeos/our-plan-to-update-country-co… Regards Ed Shryane RIPE NCC

1 0

proposal: disallow creation of new non-hierarchically named AS-SET objects
by Job Snijders 01 Dec '22

01 Dec '22

Dear DB-WG, Speaking in individual capacity. In RFC 2622 section 5 specifies the naming convention for AS-SET objects. https://www.rfc-editor.org/rfc/rfc2622#section-5.1 There basically are two styles: * "short" (example: AS-SNIJDERS) * "hierarchical" (example: AS15562:AS-SNIJDERS) Problem statement ================= In recent weeks a number of hypergiant cloud providers have faced the thorny effects of adversarial AS-SET object naming collisions between IRR databases. An example of this phenomenon is the existence of AS-AMAZON in both RADB and RIPE. According to https://www.peeringdb.com/net/1418 the RADB copy of the object is the the correct one and populated with a number of members entries. The RIPE one is empty, and not under control of Amazon. The existence of the AS-AMAZON object in the RIPE database might cause some operators to inadvertently apply empty prefix-filters to EBGP sessions which in turn causes various problems. It seems Amazon has no recourse to get the AS-AMAZON object removed from the RIPE database; because the existence of that object in the RIPE database does not violate any policies (as far as I know). But perhaps, going forward, this community can do a little bit more to help prevent similar situations from happening to others. Solution proposal ================= I think the solution is to - GOING FORWARD - disallow creation of new AS-SET objects which follow the 'short' naming style. The advantage of hierarchical naming is that the existing authorization rules as applied by the RIPE Whois Server database engine do a decent job of protecting/separating namespaces. 'Grandfathering' existing short-named objects ensures that implementation of this solution proposal causes minimal (if any) disruption to existing workflows. The RIPE database engine blocking creation of short-named AS-SETs might help nudge the industry towards making hierarchical naming the norm. Related work ============ Related work throughout the registry industry: IRRd version 4 forces new AS-SET objects to be structured hierarchically: https://github.com/irrdnet/irrd/issues/408 Kind regards, Job

21 50

NWI-10 Populating End User Organisation Country Attribute
by Edward Shryane 01 Dec '22

01 Dec '22

Dear colleagues, As I mentioned in the Operational Update during the DB-WG session at RIPE85 last week (slide 16): https://ripe85.ripe.net/wp-content/uploads/presentations/111-DB-WG-Operatio… *today* the DB team will populate the "country:" attribute in approximately 20K organisation objects in the RIPE database. This will be done for end user organisations with resources allocated or assigned by the RIPE NCC, with the country code value where the resource holder is legally based. We are continuing work internally on the remaining end user organisations without a country code, and software changes for synchronisation during resource requests. Regards Ed Shryane RIPE NCC

5 9

Issue with authorization in hierarchical as-sets
by Cynthia Revström 21 Nov '22

21 Nov '22

Hi DB-WG, While looking into the discussion about requiring hierarchical as-sets I wanted to see if all current hierarchical as-sets were authorized by the ASN holders and I found two separate issues (in my opinion). I could find at least two cases of hierarchical as-sets that were likely created before RIPE and RIPE-NONAUTH split. They are using APNIC ASNs and there are aut-num objects for both of them in RIPE-NONAUTH, but the as-sets are still in RIPE. I am not sure of the scope of this issue or if others consider it an issue, but it seems like that should possibly get cleaned up, or at least get checked out. I only tried to check if there were any occurrences of this, not trying to find a complete list, so I just checked for any 32-bit APNIC ASNs in the db dump using grep. For those who want to look at it, the grep command I used was: grep '^as\-set:\s*[Aa][Ss][1][3-6][0-9][0-9][0-9][0-9]' ripe.db.as-set There is also another issue related to authorization when it comes to hierarchical as-sets. While authorization by a maintainer listed as mnt-by on the aut-num object is required to create an as-set, that maintainer can then later be removed and there is no force-delete option like there is for inet(6)num delegations. I think that a force-delete option should be implemented so any maintainer with mnt-by on the relevant aut-num can delete an as-set. I think that it would also be helpful to introduce a "associated as-set objects" list to the DB web UI, just like there is for associated route objects currently. Something that could be an issue is the cleanup, what happens with an hierarchical as-set when the relevant ASN is de-registered? Maybe someone on the DB team could clarify? -Cynthia

2 1

2022-01 Policy Proposal Withdrawn (Personal Data in the RIPE Database)
by Angela Dall'Ara 17 Nov '22

17 Nov '22

Dear colleagues, The policy proposal 2022-01, "Personal Data in the RIPE Database” has been withdrawn. The goal of this proposal was to allow the publication of verified Personal Data in the RIPE Database only when justified by its purpose. The proposal is archived and can be found at: https://www.ripe.net/participate/policies/archived-policy-proposals/archive… Reason for withdrawal: The proposer felt that the scope of this proposal was too wide and decided to withdraw the proposal. Raised concerns like the potential consequences of the consent based publication of personal data and the efficacy of their verification might be addressed in future discrete proposals. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

1 0

Recognisition of Kosovo and adding of LIR signup options with Kosovo as well as XK in inet(6)num
by William Weber 17 Nov '22

17 Nov '22

Hi, As the Netherlands recognise the Republic of Kosovo as sovereign nation (see 1), and the EU does as well (see 2) there should be a way to include the proposed 2 letter country code (XK, see 3) as option for inet(6)num objects. The EU and other multinational organisation (IMF, SWIFT etc., see 4) use this code already since independence in 2008, and it is the currently reserved ccTLD for Kosovo as well. Kosovo also has a unique phone number prefix assigned (+383) by the ITU (see 5). It makes no sense that EU and AP is available (which are not countries, AP is not even in ISO-3166-2), but XK is not. I am aware the the X* series of codes is reserved and not permanently assigned, however UN Security Council resolution 1244/99 (see 6) mandates the use binding to all UN members. Please let me know how to bring in a draft resolution to adopt the ability to use Kosovo as legitimate country option in RIPE database objects, as well as the LIR sign up. It is the ONLY country that is recognised by both the Netherlands and the EU that cannot be used to sign up as a LIR and my client - a Telecoms company in Pristina that wants to stay anonymous at this time to avoid issues with Serbia - feels their right is violated by having to use either Serbia or Albania as billing location, and sees uncertainty in applicable laws and taxation with this. Thank you, William Weber (LIR Portal user: william(a)william.si, multiple LIRs managed) 1: https://web.archive.org/web/20080430070042/http://www.minbuza.nl/en/news/ne… Kosovo.html 2: https://ec.europa.eu/neighbourhood-enlargement/countries/detailed-country-i… 3: https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#User-assigned_code_elements 4: https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Glossary… 5: https://www.itu.int/dms_pub/itu-t/oth/02/02/T02020000FD0001PDFE.pdf 6: https://www.nato.int/kosovo/docu/u990610a.htm

13 22

Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
by William Weber 16 Nov '22

16 Nov '22

> Limiting database updates to only accounts associated with LIR sounds reasonable. I cannot support this unless it is limited to AS-SET and similar; i for example hand out IPv6 prefixes to endusers and that would be impossible if they are unable to create MNT/Person/ORGs. I support this in general for AS-SET which makes no sense to have access to unless you have an ASN, but the startup maintainer process should stay the same. Same for ORGs - to request ASNs the enduser needs an ORG and i as LIR should not have to create that or even have MNT-BY on it. — William Sent from my iPhone > On 16.11.2022, at 12:00, db-wg-request(a)ripe.net wrote: > > Send db-wg mailing list submissions to > db-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.ripe.net/mailman/listinfo/db-wg > or, via email, send a message with subject or body 'help' to > db-wg-request(a)ripe.net > > You can reach the person managing the list at > db-wg-owner(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of db-wg digest..." > > > Today's Topics: > > 1. Re: proposal: disallow creation of new non-hierarchically > named AS-SET objects (Pierfrancesco Caci) > 2. Re: proposal: disallow creation of new non-hierarchically > named AS-SET objects (Yang Yu) > 3. Re: proposal: disallow creation of new non-hierarchically > named AS-SET objects (Teun Vink) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 16 Nov 2022 10:48:18 +0100 > From: Pierfrancesco Caci <pcaci(a)pccwglobal.com> > To: Job Snijders via db-wg <db-wg(a)ripe.net> > Subject: Re: [db-wg] proposal: disallow creation of new > non-hierarchically named AS-SET objects > Message-ID: <20221116104818.25bba55e(a)lavoro.tippete.net> > Content-Type: text/plain; charset=US-ASCII > > Hi > Speaking as be.ccafrique and uk.pccwg-uk I support Job's proposal. > > Pf > >> On Mon, 14 Nov 2022 17:41:16 +0000 >> Job Snijders via db-wg <db-wg(a)ripe.net> wrote: >> >> CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe. >> >> Dear DB-WG, >> >> Speaking in individual capacity. >> >> In RFC 2622 section 5 specifies the naming convention for AS-SET >> objects. https://www.rfc-editor.org/rfc/rfc2622#section-5.1 >> There basically are two styles: >> >> * "short" (example: AS-SNIJDERS) >> * "hierarchical" (example: AS15562:AS-SNIJDERS) >> >> Problem statement >> ================= >> In recent weeks a number of hypergiant cloud providers have faced the >> thorny effects of adversarial AS-SET object naming collisions between >> IRR databases. >> >> An example of this phenomenon is the existence of AS-AMAZON in both RADB >> and RIPE. According to https://www.peeringdb.com/net/1418 the RADB copy >> of the object is the the correct one and populated with a number of >> members entries. The RIPE one is empty, and not under control of Amazon. >> >> The existence of the AS-AMAZON object in the RIPE database might cause >> some operators to inadvertently apply empty prefix-filters to EBGP >> sessions which in turn causes various problems. >> >> It seems Amazon has no recourse to get the AS-AMAZON object removed from >> the RIPE database; because the existence of that object in the RIPE >> database does not violate any policies (as far as I know). But perhaps, >> going forward, this community can do a little bit more to help prevent >> similar situations from happening to others. >> >> Solution proposal >> ================= >> I think the solution is to - GOING FORWARD - disallow creation of new >> AS-SET objects which follow the 'short' naming style. >> >> The advantage of hierarchical naming is that the existing authorization >> rules as applied by the RIPE Whois Server database engine do a decent >> job of protecting/separating namespaces. 'Grandfathering' existing >> short-named objects ensures that implementation of this solution >> proposal causes minimal (if any) disruption to existing workflows. >> >> The RIPE database engine blocking creation of short-named AS-SETs might >> help nudge the industry towards making hierarchical naming the norm. >> >> Related work >> ============ >> Related work throughout the registry industry: IRRd version 4 forces new >> AS-SET objects to be structured hierarchically: >> https://github.com/irrdnet/irrd/issues/408 >> >> Kind regards, >> >> Job >> >> -- >> >> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg >> > > > -- > Pierfrancesco Caci <pcaci(a)pccwglobal.com> > VP Network & Security Architecture - AS3491 Peering Coordinator > Tel.: +39 0287 049 871 > www.pccwglobal.com > > This message (and any attachments) may contain information that is > confidential, proprietary, privileged or otherwise protected by law. > The message is intended solely for the named addressee (or a person > responsible for delivering it to the addressee). If you are not the > intended recipient of this message, you are not authorized to read, > print, retain, copy or disseminate this message or any part of it. If > you have received this message in error, please destroy the message or > delete it from your system immediately and notify the sender. PCCW > Global cannot guarantee that this e-mail is secure, error-free and/or > virus-free as e-mail messages could be intercepted, altered, corrupted, > lost, delayed or become incomplete and/or infected by viruses in the > course of their transmission. PCCW Global and the sender therefore do > not accept liability for any loss or damage arising from any errors or > omissions in the contents of this e-mail. > > > > > ------------------------------ > > Message: 2 > Date: Wed, 16 Nov 2022 04:06:57 -0600 > From: Yang Yu <yang.yu.list(a)gmail.com> > To: denis walker <ripedenis(a)gmail.com> > Cc: Job Snijders <job(a)sobornost.net>, db-wg(a)ripe.net > Subject: Re: [db-wg] proposal: disallow creation of new > non-hierarchically named AS-SET objects > Message-ID: > <CAFwKRnR1U7X99nXsE_pqk982Hf4BXOZ9RoV+Aa7Y4C-Zyu=4fA(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > I support this proposal. > >> It seems Amazon has no recourse to get the AS-AMAZON object removed from >> the RIPE database; because the existence of that object in the RIPE >> database does not violate any policies (as far as I know). > > Also ran into this issue and would like to see policy support to > handle this kind of abuse. > >> On Mon, Nov 14, 2022 at 3:08 PM denis walker via db-wg <db-wg(a)ripe.net> wrote: >> Interesting timing. I was about to make the same suggestion but for a >> different reason...accountability. Currently ANYONE can create a set >> object in the RIPE Database. You can be completely anonymous, not a >> member or LIR, hold no resources. All you need to do is create a ROLE, >> MNTNER and set object. > > Anyone with an email can make a RIPE account and start creating > objects in RIPE database. In other registries there are usually some > safeguards on user / mntner object creation. Limiting database updates > to only accounts associated with LIR sounds reasonable. > > > Yang > > > > ------------------------------ > > Message: 3 > Date: Wed, 16 Nov 2022 11:19:17 +0100 > From: "Teun Vink" <teun(a)bit.nl> > To: "Job Snijders" <job(a)sobornost.net> > Cc: db-wg(a)ripe.net > Subject: Re: [db-wg] proposal: disallow creation of new > non-hierarchically named AS-SET objects > Message-ID: <A2DF4E9C-3BA7-415C-8C0A-FDBE11BF9736(a)bit.nl> > Content-Type: text/plain > > Hi all, > > On 14 Nov 2022, at 18:41, Job Snijders via db-wg wrote: > [...] >> Solution proposal >> ================= >> I think the solution is to - GOING FORWARD - disallow creation of new >> AS-SET objects which follow the 'short' naming style. >> > > I support this proposal. > > Kind regards, > -- > Teun Vink > BIT | teun(a)bit.nl | +31 318 648 688 > KvK: 09090351 | GPG: 0xFC8B25D6 | RIPE: TEUN-RIPE > > > > ------------------------------ > > Subject: Digest Footer > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg > > > ------------------------------ > > End of db-wg Digest, Vol 135, Issue 8 > *************************************

1 0

RIPE 85 session
by denis walker 08 Nov '22

08 Nov '22

Colleagues I would like to apologise for missing the DB-WG session at RIPE 85. I was taken ill the night before with severe gastric problems, which I have only recently recovered from. Now I am still recovering from covid also. I would like to thank my co-chair William for stepping in at the last minute to run the whole show. I have some comments to make on each presentation, but don't expect much from me this week. I will start to get my head round these issues again next week. cheers denis co-chair DB-Wg

1 0

Support for "::" notation in the "members" field
by James Bensley 04 Nov '22

04 Nov '22

Dear Working Group, I want to discuss a format change to the "members" field of the AS-SET and Route-Set objects in the RIPE DB. I do not know what the process is for this so please guide me if this is the wrong place to raise this. Specifically, I want to discuss adding supported for the "::" source notation in the "members" field of an AS-SET or Route-Set. Currently my AS-SET might look like the following when the tree is fully expanded: as-set: AS4200000011:AS-EXAMPLE-11 -> members: AS4200000011 -> members: AS4200000012:AS-EXAMPLE-12 - -> members: AS4200000012 - -> members: AS4200000021 -> members: AS4200000013:AS-EXAMPLE-13 - -> members: AS4200000013 - -> members: AS4200000022:AS-EXAMPLE-22 - - -> members: AS4200000031 When a peer or upstream is building the prefix lists towards me (AS4200000011), they need to generate a prefix list for my entire AS tree/route set tree. The problem is that historically objects with the same name have been registered in different IRR databases. This causes a problem because it's not clear which IRR DB should be used to pull the prefix list for a given ASN. For example, AS-GOOGLE current exists in RIPE and APNIC IRR DBs, but the AS-SET in both DBs is empty: $whois -h whois.ripe.net AS-GOOGLE | grep -E "as-set|members" as-set: AS-GOOGLE $whois -h whois.apnic.net AS-GOOGLE | grep -E "as-set|members" as-set: AS-GOOGLE As per Google's peeringdb page, the correct data source for their AS-SET is RADB: https://www.peeringdb.com/net/433 $whois -h whois.radb.net AS-GOOGLE | grep -E "as-set|members" as-set: AS-GOOGLE members: AS11344 members: AS13949 members: AS15169 ... The above query to RADB produces the correct information. Historically people have registered objects with the same AS-SET or Route-Set name, in different IRR DBs, both by accident and maliciously, and this practice continues today. It is very difficult to get these issues resolved in a timely manner and the result on daily operations is that we can't establish a new peering session with a customer/peer/upstream or update our prefix list facing an existing customer/peer/upstream because we can't generate the prefix towards them. We need to be able to signal which IRR DB is authoritative for an AS-SET or Route-Set object. For this reason I ask, what it would take to allow the use of the "::" indicator in the "members" field of an AS-SET and Route-Set so that in my own AS-SET I can specify the correct source for the direct members (my customers), and in their AS-SET's they can specify the correct source for each of their customers, and so on all the way down the tree, so that I end up with my AS-SET tree looking like the following when fully expanded: -> members: RIPE::AS4200000011 -> members: RADB::AS4200000012:AS-EXAMPLE-12 - -> members: RIPE::AS4200000012 - -> members: ARIN::AS4200000021 -> members: ARIN::AS4200000013:AS-EXAMPLE-13 - -> members: APNIC::AS4200000013 - -> members: ARIN::AS4200000022:AS-EXAMPLE-22 - - -> members: RADB::AS4200000031 Kind regards, James Bensley (he/him) Network Team Inter.link GmbH Boxhagener Str. 80, 10245 Berlin, Germany Email: hello(a)inter.link, Phone: +49-030-577123821 Registry: Local court Charlottenburg, HRB 138876 Managing directors: Marc Korthaus, Theo Voss

2 2

Privacy proposal, concerns
by Frank Breedijk 27 Oct '22

27 Oct '22

Dear all, I’m new to this mailing list, but joined because I’m concerned about this policy proposal: https://www.ripe.net/participate/policies/proposals/2022-01 <https://www.ripe.net/participate/policies/proposals/2022-01> I am a volunteer for DIVD, the Dutch Institute for Vulnerability Disclosure. We are a non profit organisation that aims to make the digital world safer by reporting vulnerabilities we find in digital systems to the people who can fix them. For this we heavily reply on whois and the underlying database like RIPE NCC’s DB. (For more information see https://www.divd.nl <https://www.divd.nl/> and https://csirt.divd.nl <https://csirt.divd.nl/>) We are very concerned about the impact this proposal may have on us and on RIPE NCC. The basis of the proposal is good. Let’s stop collecting and publishing PII in RIPE DB, especially where it doesn’t serve the purpose of the DB. But RIP NCC is setting itself up for a lot of trouble by going to “permission” as the GDPR ground for processing instead of “legitimate interests pursued by the controller” Especially this line in the proposal can be explained as such: “All organisations holding resources allocated or assigned by the RIPE NCC, or documented in the RIPE Database, must sign a declaration that they have read and understood this policy and that either all the data for their organisation and resources contained in the RIPE Database is fully compliant with this policy or they are working towards full compliance.” With this statement in the policy it is quite possible that RIPE NCC at some point will have to choose between two evils: a) Either revoking all resources of those parties that did not sign a declaration b) Removing all PII of those parties from the database. What would the impact be? I analyzed 7476 IP addresses that popped up in a certain case using ripeSTAT and whois (see attachment) 458 Afrinic 1052 APNIC 1277 ARIN 190 LACNIC 4090 RIPE 409 no RIR in ripeSTAT abuse finder API I marked all email addresses that were not clearly a “function”/group/department mailbox as personal. If we could not report to email addresses that were personal we would not be able to report abuse to 929 out of 7476 ip addresses. (~12%) 201 of these IP addresses belong to the rir RIPE. (of the 4090 marked as belonging to RIPE, about 5%) 180 of these come from the ripeSTAT API, so they come from a CONTACT record, not a PERSON record. In only 21 cases I had to resort to whois to get a PERSON record. Conclusion: A small but significant portion of “abuse” addresses are “personal” Most of these are in CONTACT records not PERSON records. Besides these email addresses, RIPE NCC will have to do the work to be GDPR compliant for other PII anyway. IP addresses are considered PII in The Netherlands, a work/group phone number/email can still be PII, e.g. in the case where the company is a single person company or the company name can be traced back to a natural person, so going this route creates a lot of work and doesn’t actually reduce the compliance load on RIPE NCC. Regards, Frank Breedijk +31643822637

3 5

2022-01 Review Phase (Personal Data in the RIPE Database)
by Angela Dall'Ara 20 Oct '22

20 Oct '22

Dear colleagues, Policy proposal 2022-01, "Personal Data in the RIPE Database", is now in the Review Phase. The goal of this proposal is to allow the publication of verified Personal Data in the RIPE Database only when they are justified by its purpose. The proposal has been updated to version 3.0 after the last round of discussion. This version differs from version 2.0 as follows: - it is not explicitly proscribed to enter the name of a person in role objects - the verification of fax numbers is not required The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community’s discussion. You can find the proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2022-01 https://www.ripe.net/participate/policies/proposals/2022-01#impact-analysis And the draft documents at: https://www.ripe.net/participate/policies/proposals/2022-01/draft As per the RIPE Policy Development Process (PDP), the purpose of this four-week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments to <db-wg(a)ripe.net> before 4 November 2022. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

5 6

Agenda RIPE85 - Database Working Group
by William Sylvester 11 Oct '22

11 Oct '22

Below is the agenda for the Database Working Group for RIPE85. If you would like to present, have questions, comments, or requested changes please let the chairs know. Best regards, William & Denis DB-WG Chairs A. Introduction - 10 min * Welcome * Scribe * Jabber * Chairs & Succession Planning * Agenda B. NWI Update – 20 mins Denis Walker, Co-Chair DB-WG C. Operational Update– 20 mins Edward Shryane, RIPE NCC D. Geofeed Discussion – 10 mins Denis Walker, Co-Chair DB-WG E. Proposal 2022-01 – 10 mins Denis Walker, Co-Chair DB-WG Z. AOB (open discussion)

2 1

RIPE Database Service Criticality Questionnaire
by denis walker 10 Oct '22

10 Oct '22

Colleagues [Apologies to Job for copying your email from the Routing WG but you explained it well :) ] The RIPE NCC has asked the Database WG Chairs to facilitate a working group conversation on framing the RIPE Database service subcomponents in terms of criticality. At the bottom of this email is a form that focuses on three components: confidentiality, integrity and availability. Each component is split into three questions (a, b, and c), a total of 9 questions are being put forward to the working group. We envisage this process to be a public consultation: WG participants can submit (free-form) responses, and also chime in by replying to each other's responses; hopefully bringing us to a degree of consensus in the coming weeks. We believe this is a unique opportunity to help the RIPE NCC! The goal is to help the RIPE NCC develop a deeper understanding of how the moving parts fit together, which in turn helps decide where and how to invest resources. >>> Your feedback is much appreciated! <<< cheers, denis, William DB WG co-chairs ----------------------- FORM STARTS HERE ----------------------- Service Criticality Form - RIPE Database Introduction ------------ This form is used to gather input from the community on the service criticality of the RIPE database. The framework is detailed in https://labs.ripe.net/author/razvano/service-criticality-framework/ The service criticality has three components: * Confidentiality What is the highest possible impact of a data confidentiality -related incident (data leak)? * Integrity What is the highest possible impact of a data integrity -related incident (hacking)? * Availability What is the highest possible impact of a service availability -related incident (outage)? All our services are designed with at least 99% availability, so please consider outages of up to 22 hours. Service Purpose --------------- The RIPE Database is the public internet registry for the RIPE NCC region, comprised of: * Internet Number Registry * Internet Routing Registry * Reverse Delegations The critical parts of the service are: * Query (Port 43, REST API, NRTM, Web Application) * FTP dumps (whole database and split files) The non-critical part of the service is: * Update (REST API, Mailupdates, Syncupdates) Service Criticality ------------------- Please review the following three areas. (1) Global Routing Incident Severity * Low (No / negligible impact) * Medium (One or a few ASes are unavailable) * High (Many ASes in a region are unavailable) * Very High (Global Internet routing disruptions) Please rate the incident severity (Low to Very High) in the following three areas. Please explain why. (a) Confidentiality (Impact level of incidents such as data leaks) (b) Integrity (Impact level of incidents such as hack attempts) (c) Availability (Impact level of service outage incidents, up to 22 hours per quarter) (2) IP addresses and AS Numbers Incident Severity * Low (No / negligible impact) * Medium (Local disruptions (registration information not being available for some entities)) * High (Regional disruptions (registration information not being available for the RIPE NCC region)) * Very High (Global disruptions (lack of registration information for all AS Numbers and IP addresses)) Please rate the incident severity (Low to Very High) in the following three areas. Please explain why. (a) Confidentiality (Impact level of incidents such as data leaks) (b) Integrity (Impact level of incidents such as hack attempts) (c) Availability (Impact level of service outage incidents, up to 22 hours per quarter) (3) Global DNS Incident Severity * Low (No / negligible impact) * Medium (Local disruptions) * High (Regional disruptions) * Very High (Global disruptions) Please rate the incident severity (Low to Very High) in the following three areas. Please explain why. (a) Confidentiality (Impact level of incidents such as data leaks) (b) Integrity (Impact level of incidents such as hack attempts) (c) Availability (Impact level of service outage incidents, up to 22 hours per quarter)

2 2

Whois Release 1.104
by Edward Shryane 10 Oct '22

10 Oct '22

Dear Colleagues, RIPE Database release 1.104 has been deployed to the Release Candidate environment. We plan to deploy to production on Monday 10th October. This release includes the following main changes: * Allow Grouping (-G) flag in Whois Search API (#1077) * cidr0 notation for rdap response (#1068) * Remove whois tags (#1059) * Added text/plain to Search and REST APIs (#1054) * Add comment not NOOP (#1052) * Do not allow comments in managed attributes (#1045) * Use documentation prefix 192.0.2.0/24 (#1044) * Organisation country: is modifiable for end-user orgs without RIPE NCC resources (#1041) * Do not return deleted versions (#1015) * Redirect empty requests to syncupdates help (#1011) The release notes are on the website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel… More information on the Release Candidate environment can be found on our website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/rc-release-candid… Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

RIPE Database Quarterly Planning Q4 2022
by Edward Shryane 26 Sep '22

26 Sep '22

Dear colleagues, We have published our quarterly plans for Q4 2022 for the RIPE Database: https://www.ripe.net/manage-ips-and-asns/db/quarterly-planning In this quarter, we will start implementing the RDAP cidr0 and NRO profiles. We are also continuing work on the Service Criticality framework and on the RIPE database documentation. We hope that by providing these plans, we can better inform the community of the ongoing developments on the RIPE Database and get feedback on our work. If you have comments or questions around this, we hope you'll let us know on the list or you can always contact the DB team directly at ripe-dbm(a)ripe.net . Regards Ed Shryane RIPE NCC

1 0

NWI-13 Geofeed Legal Analysis
by Maria Stafyla 26 Sep '22

26 Sep '22

Dear colleagues, Following the legal update we provided on NWI-13: Geofeed at the DB WG session at RIPE 84, here is our analysis in case further discussion on this topic is needed. Executive Summary: -The RIPE Database is meant to contain specific information for its documented purposes. -Information inserted in the geofeed attribute could in some cases qualify as personal data. -The current purposes could explain geolocation information to be inserted only for ‘scientific research into network operations and topology’. -This purpose does not justify the processing of personal data; therefore restrictions had to be put in place to avoid the processing of unnecessary personal data. -The restrictions are now implemented based on the status of the registration. -If the purposes of the RIPE Database have changed in the meantime, this should be established via the community processes and documented. In that case we will re-evaluate the situation and the need for restrictions. Until then, the restrictions remain necessary. Legal Analysis: The RIPE Database is meant to contain specific information for the purposes that are defined in the RIPE Database Terms and Conditions. In terms of the _personal data_ inserted in there, the purpose that justifies its publication is to facilitate the coordination of network operations for the smooth and uninterrupted operation of Internet; this purpose explains why contact details of resource holders or their appointed contact persons are required. Before any new type of personal data is permitted to be inserted in the RIPE Database, we must evaluate if their processing is required for the purposes already defined and their processing can be considered in line with the basic personal data processing principles. Although it is the responsibility of the party inserting personal data to ensure that they have the appropriate legal grounds before doing so, the RIPE NCC has also shared responsibilities with regards to the personal data in the RIPE Database. This is because the RIPE NCC is the party that is making the RIPE Database available and implements the instructions given by the RIPE community. As mentioned in the Legal Review Impact Analysis, if the geofeed attribute is inserted for registrations of assignments that are reasonably assumed to be related to one individual user, then the attribute will be considered as containing personal data and GDPR will apply. This is why we have proposed to implement restrictions. These restrictions are essential to avoid any processing of personal data that is not required or necessary for the *currently defined* purposes of the RIPE Database and to limit the RIPE NCC's liability as a party with shared responsibilities in relation to the personal data inserted in the RIPE Database. Regarding the _(non-personal) data _inserted in the RIPE Database, it is also paramount that only data that is needed for the defined purposes of the RIPE Database is inserted. According to the RIPE Database Terms and Conditions, introducing the geofeed attribute (with restrictions) would be considered in line and acceptable to be used only for scientific research into network operations and topology (see Art. 3). We also understand that the purposes the RIPE Database must fulfil are not static but evolve over time. The RIPE Database Requirements Task Force has recently concluded its work and, with regard to geolocation, it has established that, although there is an active user group for geolocation data, geolocation itself is not an objective that the RIPE Database should fulfil. If the community's interests have changed since then and it is now agreed that geolocation is one of the purposes the RIPE Database must fulfil, this should be decided via the community's processes and reflected in the RIPE Database Terms and Conditions. In line with the data management principles proposed by the RIPE Database Requirements Task Force, it would be prudent to approach this issue holistically, taking into account that other geolocation information is already provided in the RIPE Database (i.e. geoloc, country code attributes in ORG and resource objects). On the basis of a new purpose for the geolocation information, we could then reassess the situation to understand whether the restrictions on the geofeed attribute are still necessary or whether it is justified to process personal data for this purpose. Kind regards, Maria Stafyla Senior Legal Counsel RIPE NCC

16 44

geolocation and current purposes
by denis walker 22 Aug '22

22 Aug '22

Colleagues I have spent some time thinking about the wording of the current purpose of the RIPE Database in relation to geolocation services. In some ways the purposes are very loosely written. That means they are open to interpretation. I think they can be interpreted to cover the "geofeed:" attribute. Some people have expressed this view but it is not sufficient to just say it, you need to justify the viewpoint. I will attempt to do that. "Facilitating coordination between network operators (network problem resolution, outage notification etc.)" The first point is the 'etc'. That means the example list is not exclusive. It doesn't even define the types or categories of coordination. So basically any coordination between network operators is included. 'Facilitating' means 'to make things easy'. So the database exists to make any coordination activity between network operators easy. So in what ways is "geofeed:" going to make it easy for network operators to coordinate some activity? One of the ways network operators have talked about how they want/need to use "geofeed:" data is to provide content based on location of an IP address. If a content providing network operator wishes to offer this content to anyone in a specific location, that can be seen as a coordination activity. The content provider can coordinate with other network operators to establish that their customers are within this location so they can access this content. If this interpretation is accepted by the community then the context has changed. The legal team can now reassess their advice in the context that the use of the "geofeed:" data is now covered by the existing database purposes. But there are other questions that the legal team also needs to consider. The "geofeed:" attribute references data external to the RIPE Database that neither the RIPE NCC nor the RIPE community has any control, management or perhaps even influence over. This data may contain PII. Although the maintainer of that external data is responsible for its content, does the RIPE NCC have any (joint) accountability or liability as the data controller and facilitator of the RIPE Database? Nic Handles are considered to be PII as they reference objects that contain PII. But these objects are also contained within the RIPE Database. The geofeed csv files are external to the RIPE Database. Do the references to them still constitute PII? Given that we are currently discussing a policy proposal governing the use of personal data in the RIPE Database, here we have a mechanism where resource holders can publish full postal address details of end users who are natural persons and link that published data to the resources in the RIPE Database. Given that these files are published by holders of RIPE resources and referenced by the RIPE Database, should the content of these files follow RIPE policies? (I'm not suggesting any validation of the contents, but perhaps resource holders should be responsible for applying policies to this content.) The T&C is a legal document. In the event of any dispute, lawyers make a lot of money by analysing and interpreting documents like this. Although the loosely written purposes may now be interpreted to cover geolocation data, there are still significant problems with the way the purposes are written. A review would still be beneficial. The T&C are mostly in the background during day to day operations. Just as the terms of an insurance policy can be irrelevant for years. The one time it matters is when you want to make a claim, or in the case of the database if someone ever makes a legal challenge over any aspect of its use or content. At that point, if the purposes can be widely interpreted, then the outcome is uncertain. It would be advantageous to all parties if the purposes were clear and precise with little room for interpretation. Whenever this issue is raised some people make the cynical comments that there has never been any legal challenge and there is no queue of people waiting to do so and common sense has always prevailed (in the past). It only needs one. Other RIRs have been involved in legal actions. Don't wait until your house is flooded before checking your insurance policy to see if you are covered. Another clear issue with this purpose's wording is that use of contact details in the database is only allowed by network operators to contact other network operators ("between network operators"). In this sense the purpose is very precise. Use of contact details by the public, non member organisations, investigators, CSIRT teams (unless they are also operators) and LEAs is not allowed under these T&C. Something to think about... cheers denis co-chair DB-WG

5 6

Apologies for spam
by Alun Davies 22 Aug '22

22 Aug '22

Hello all, My apologies to everyone who received my out of office response this morning. Just wanted to note that the relevant messages have now been removed from the archives. Again, sorry for the spam! Best regards, Alun Davies RIPE NCC

1 0

Re: [db-wg] NWI-13 Geofeed Legal Analysis
by peering-ops＠telekom.de 22 Aug '22

22 Aug '22

Can someone at RIPE please stop this. This OOO message is spamming everything. ------ Best regards, Daniel Straßner Deutsche Telekom Technik GmbH Core Networks & First-Line Maintenance (T-CNF) IP Core (IPC) Daniel Straßner Squad Changemanagement Carrier und GK-Connectivity (CMC) Squad Lifecycle Produktionsmodelle Public & Wholesale (PWS) Olgastr. 67, 89073 Ulm +49 731 1003-4775 (Tel.) +49 731 1003-4770 (Hotline) E-Mail: d.strassner(a)telekom.de<mailto:d.strassner@telekom.de> www.telekom.de<http://www.telekom.de/> Life IS FOR SHARING. You can find the obligatory information on www.telekom.de/compulsory-statement-dttechnik BIG CHANGES START SMALL - SAVE RESOURCES BY NOT PRINTING EVERY E-MAIL. Von: db-wg <db-wg-bounces(a)ripe.net> Im Auftrag von Alun Davies via db-wg Gesendet: Montag, 22. August 2022 07:55 An: Alun Davies via db-wg <db-wg(a)ripe.net> Betreff: Re: [db-wg] NWI-13 Geofeed Legal Analysis Hi, I’m out of office till 22 August. Any RIPE Labs related queries can be sent to labs(a)ripe.net and one of my colleagues will get back to you. Cheers, Alun On 22 Aug 2022, at 07:52, Alun Davies via db-wg <db-wg(a)ripe.net> wrote: Hi, I’m out of office till 22 August. Any RIPE Labs related queries can be sent to labs(a)ripe.net and one of my colleagues will get back to you. Cheers, Alun On 22 Aug 2022, at 07:51, Alun Davies via db-wg <db-wg(a)ripe.net> wrote: Hi, I’m out of office till 22 August. Any RIPE Labs related queries can be sent to labs(a)ripe.net and one of my colleagues will get back to you. Cheers, Alun On 22 Aug 2022, at 07:42, Alun Davies via db-wg <db-wg(a)ripe.net> wrote: Hi, I’m out of office till 22 August. Any RIPE Labs related queries can be sent to labs(a)ripe.net and one of my colleagues will get back to you. Cheers, Alun On 29 Jul 2022, at 14:24, Warren Kumari via db-wg <db-wg(a)ripe.net> wrote: On Thu, Jul 28, 2022 at 9:50 PM, Cynthia Revström <db-wg(a)ripe.net> wrote: I am not sure how you came to that conclusion, the way I read Maria's email didn't make me come to a conclusion anything like that. Maria said: The RIPE Database is meant to contain specific information for the purposes that are defined in the RIPE Database Terms and Conditions. The RIPE DB T&C and the DBTF report are not the same and the RIPE DB T&C could be amended. Maria also says: If the community's interests have changed since then and it is now agreed that geolocation is one of the purposes the RIPE Database must fulfil, this should be decided via the community's processes and reflected in the RIPE Database Terms and Conditions. I feel like this directly goes against what you are saying, it seems very clear to me that it is possible to change the purposes. I'll also note that Maria's initial email said: "personal data that is not required or necessary for the currently defined purposes of the RIPE Database" with "currently defined" written in big, bold, flashy letters. It then continues with the paragraph you have quoted above: "If the community's interests have changed since then and it is now agreed that geolocation is one of the purposes the RIPE Database must fulfil, this should be decided via the community's processes…" I happen to think that Geofeed could easily fall into: "Publishing routing policies by network operators (IRR)" — part of my "routing policy" is that 192.0.2.0/24 is in Cologne, and that seems useful for you to know to build your policy as well and / or "Facilitating coordination between network operators (network problem resolution, outage notification etc.)" — you are seeing long latency to 192.0.2.0/24? Geofeeds tells you that that is in Warsaw, so when you contact me you can say something like "200ms seems like a long time to get from Berlin to Warsaw… perhaps we can not route this through Singapore??"" and / or "Scientific research into network operations and topology" — you are doing Internet measurements on latency. Why does traceroute to 192.0.2.0/24 take 3ms and 203.0.113.0/24 take 89ms? Well, Geofeeds tells you that one is in Akureyri and the other is in Lisbon. Seems like worth knowing… But, the bolding of "currently defined" and the "If the community's interests have changed since then…" seems to imply that it is at least worth discussing if we can add Denis suggestion of ""The RIPE Database may contain data that an agreed set of external services may use, require or rely on." and if it does actually need "a resolution by the GM to change the T&C", etc. Even if we successfully argue that Geofeeds fits into one of the above examples, it does seem like having the T&C reflect what people want to be able to use the DB for… W -Cynthia On Fri, Jul 29, 2022 at 3:29 AM Ronald F. Guilmette via db-wg <db-wg(a)ripe.net> wrote: In message <CAKw1M3PZPzwJHoNyGrSAY_2azHeZpTw4aVw7GwCLhmT_qt2CiA(a)mail.gmail.com> =?UTF-8?Q?Cynthia_Revstr=C3=B6m?= <me(a)cynthia.re> wrote: The purposes could change... No, they couldn't. It appears that the RIPE Database Requirements Task Force issued its "final report" sometime late last year, and now the wheels have ground on further to bring us to the point where RIPE legal has issued an official proclamation to the effect that everything that does not comport with the Task Force's final list of defined purposes _must_ be jetisoned and thrown overboard. That would appear to be the short version of where things stand now. Based upon the principal of stare decisis, it would seem to be a bit late in the game to try to roll back any of what has already been adjudicated. Regards, rfg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg

1 0

2022-01 Personal data in the RIPE Database Next Steps
by William Sylvester 04 Aug '22

04 Aug '22

Dear Database Working Group Members, The four-week discussion phase for the policy proposal "2022-01 Personal data in the RIPE Database" ended on 15 July. In agreement with the proposer, we have decided tomove the proposal into the Review Phase but postponed its start to the end of August. This was done keeping in mind that the upcoming vacation period might prevent participation in the discussion and the timely publication of the RIPE NCC Impact Analysis. Please note that the RIPE Database WG Co-Chair Denis Walker is the author of this policy proposal, hence he is not taking part in the decisions regarding consensus. The RIPE NCC Policy Officer will announce the start of the Review phase together with the publication of the policy draft and impact analysis. For reference, here’s a short summary of the discussion so far: Ronald Guilmette posted many messages strongly opposing the proposal, advocating instead for the accurate verification of WHOIS data and for not publishing personal data for privacy reasons only in special legitimate cases. His main points of disagreement were: a) The transparency of the database would suffer, affecting LEAs’ and researchers’ work. b) The postal address is managed solely by the resource holder and not by the RIPE NCC. c) The postal address can already be concealed using, e.g., a PO box. d) Only a minority in the community is asking for the postal address not to be published, which doesn’t justify the effort and cost of implementation. e) More contact details might fall under the same new proposed rule in the future. f) Accepting the proposal would change the historical practice of the RIPE Database. g) There is no legal basis for the proposed changes. The proposer addressed the concerns above as follows: a) The transparency achieved is questionable if it's based on unverified data. b) End Users are not always aware that their address has been entered in the RIPE Database by the LIR. c) Addresses like those of PO boxes do not help LEAs orresearchers. d) Implementation could be supported using the existing ARCs. e) There is no mention of further changes in the proposal. f) Historical practice should not be treated as a requirement. g) Legal aspects should be further clarified by the RIPE NCC legal team. Niels Bakker supported the proposal as it would allow the RIPE NCC to offer a way to prevent LIRs from entering End Users’ personal data in the RIPE Database. Some ideas for modifying the proposal were posted: - Ronald Guilmette suggested to address the verification of contact details entered in the RIPE Database with a separate proposal that he would support, provided that the implementation challenges, costs, and consequences for non-compliance would be clarified. This would split the existing proposal in two: VERIFICATION and REDACTION. - Sylvain Baya, contributed to the discussion and also postedlinks to RIPE Labs articles published in the past about the proposal’s topics. He supported Ronald’s suggestion of allowing the RIPE NCC to accept the requests of exemption from publication of the Personally Identifiable Information (PII) made by natural persons who need Internet resources and can legally demonstrate their privacy requirement. Sylvain also suggested splitting the subject into a set of proposals: one about the general principles for processing data within the RIPE Database, one about *insertion* of PII within the RIPE Database, one about the *query* of the RIPE Database and one for handling the current PII present into the RIPE Database. - Leo Vegoda suggested clearly separating the sections defining a principle from those defining its implementation. - Cynthia Revström supported the proposal and suggested rewording the proposal clarifying that entering the full home address is never justified and that the default should be no address at all for individuals. The assumption should be that any address an individual is operating from is a home address unless the individual themselves clearly say that it is not. Please let me know if you have any questions. Kind regards, William db-wg Co-Chair

1 0