- db-wg - mailman.ripe.net

2022-01 v2 Personal Data in the RIPE Database
by Cynthia Revström 29 Jun '22

29 Jun '22

Hi db-wg, I just want to say that I mostly support the current proposal of 2022-01 (v2). I would prefer it if the following section was reworded in some way to make it more clear how the full home address is never justified and how the default should be no address at all for individuals. Also I think it should be changed to assume that any address an individual is operating from is a home address unless the individual themselves clearly say that it is not a home address. I would still support it in its current form without these changes but I would strongly prefer if these were made to prevent any confusion or ambiguity. (this section is part of 1.0 Organisations) <quote> The name of the organisation (which may be the personal data of a natural person) holding an Internet resource or managing part of an Internet resource, for example a sub-allocation, or using a block of addresses, is an essential part of the public registry. This identification is one of the principal purposes of the database. Any valid address could be helpful. Different types of addresses can be considered including postal addresses. The name and address of a natural person holding or using a resource and operating from a home address are the only personal data that can be justified to be published in the RIPE Database, provided there is documentary evidence held by the RIPE NCC, or a sponsoring LIR, or any resource holder that registered the subject’s details in the RIPE Database, that the natural person has consented to their name and address being published in this public registry. This consensual identification is a requirement of the public registry for holding an Internet resource or managing or using part of an Internet resource. A postal address may optionally be added by the resource holder or manager. Where the resource holder, manager or user is a natural person, the parts of any type of address more specific than country and region must not be entered in any object attribute. </quote> -Cynthia

1 0

Re: [db-wg] Request for the correct review of document link
by Christian Nzhie 29 Jun '22

29 Jun '22

> > Good morning folk, I was reading this archive on the folowing link > https://www.ripe.net/ripe/mail/archives/db-wg/2022-June/007459.html > and I saw this > > The PDP document can be found at:https://www.ripe.net/publications/docs/ripe-710 > > However, when I click on the above link to review the proposal, I am > seeing the following red notice: This document is obsoleted by ripe-781 > <https://www.ripe.net/publications/docs/ripe-781> > So, please, kindly provide the correct link of version 2 under review... > Thanks in advance... > Christian Nzhie. >

2 1

RIPE Database Quarterly Planning Q3 2022
by Edward Shryane 29 Jun '22

29 Jun '22

Dear colleagues, We have published our quarterly plans for Q3 2022 for the RIPE Database: https://www.ripe.net/manage-ips-and-asns/db/quarterly-planning We recently made usability improvements to the website and in this quarter we’re planning on migrating the RIPE Database documentation to a new interface. We will announce on the list when this is ready. The goal of our quarterly planning is to communicate the work we’re doing for the coming months, get your input and start a discussion on other developments we should work on. 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

Updating Descr part of object with # results in No Operation
by Sascha E. Pollok 28 Jun '22

28 Jun '22

Hi everyone, I just tripped over something today which I have never noticed after >20 years of using the RIPE DB :-) It might be explained somewhere but I haven't found anything so here it is. I am updating an inetnum object from: descr: Testobject Ticket #12345 to descr: Testobject Ticket #123456 using Syncupdate. This results in a "No Operation" (Warning: Submitted object identical to database object). Is this intentional? It works if I remove the # and add it again in a second step. I assume it's something about it being interpreted as a comment but even if that's the case, I should still be able to update it. Can someone enlighten me? Thank you and best regards Sascha

4 7

2022-01 V2 Resource Holders Address
by denis walker 27 Jun '22

27 Jun '22

Colleagues I have listened to your comments in recent discussions and had some preliminary talks with the RIPE NCC about what could be implemented. So now we have a second version of my proposal on personal data. I was getting comments from people that LEAs need addresses for their investigations, but also people had serious privacy concerns about publishing their home address in the database. I was considering the idea of publishing addresses with restricted access. However it seems that it is almost impossible to confirm the identity of LEAs (even from within our own region, never mind globally) and perhaps other NGOs that could be eligible to access this restricted data. So that idea is not viable. Then there was an issue over data quality of the addresses currently published in the database. In the ORGANISATION object the address is assumed to be a postal address. This mandatory address is entered and managed by the resource holders. No verification is done on this address. In the database documentation it says: "This is a full postal address for the business contact represented by this organisation object." That could be anyone. They don't even need to be located in the country where the organisation operates it's business. Being so loosely defined, any kind of verification would be impossible. That makes this address almost meaningless. It is on the same level as the "country:" attribute in resource objects. It only has meaning to whoever manages the data. Also by having this unverifiable address mandatory, we are almost inviting those who don't want to be easily located to enter false data. Especially as it is almost impossible to identify any of this postal address data as being true or false. I am therefore suggesting we make this postal address an optional attribute. If any resource holder wishes to enter this optional postal address they can do so. But if it is a personal address they must not enter more than region and country. The full personal address of a natural person must not be entered into the database in any object type. Optional data, when provided, is more likely to be accurate. Making this address optional is in line with a recommendation of the RIPE Database Task Force. Some will still argue that false data is useful if 'bad actors' enter the same false data in different places. That offers investigators an opportunity to cross reference this (false) data over different objects using the free text search facility of the database. In some cases this may be the only way to make these data links. Doing this has many problems. We cannot justify preserving false data in the database to allow some people to use an 'accidental feature'. There is no guarantee the same false data will be used in multiple places. There is a defined purpose of the database that allows LEAs to use public information from the database as part of their investigations. This purpose is actually about granting permission to LEAs to use available data. It does not define any data to be published in the database for the sole benefit of LEAs. So there is no purpose requiring this postal address to be published in the database. Optional is therefore a convenience for anyone who wishes to enter it. cheers denis policy proposer

4 20

2022-01 New Version Policy Proposal (Personal Data in the RIPE Database)
by Angela Dall'Ara 24 Jun '22

24 Jun '22

Dear colleagues, RIPE policy proposal 2022-01, "Personal Data in the RIPE Database" is now available for discussion again. 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. This proposal has been updated following the last round of discussion and is now at version 2.0. Some of the differences from version 1.0 include: - Publishing only country and region for natural persons - Making the current postal address publication optional for all - Allowing for the publication of different types of addresses in the future You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2022-01 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-710 We encourage you to review this proposal and send your comments to db-wg(a)ripe.net before 15 July 2022. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

5 20

Re: [db-wg] [anti-abuse-wg] Proposal 2022-01
by denis walker 24 Jun '22

24 Jun '22

Yes Carlos you are absolutely right. There is no suggestion whatsoever that any membership will be revoked or any resources de-registered if any verification fails. Cheers denis Proposal author On Thu, 23 Jun 2022, 11:48 Carlos Friaças via anti-abuse-wg, < anti-abuse-wg(a)ripe.net> wrote: > > > Hi, please see inline. > > > On Thu, 23 Jun 2022, Ronald F. Guilmette wrote: > > > Just curious... How many of you folks have actually read sections 4.0, > 5.0, > > and 6.0 of this pending proposal from the Database Working Group? > > Read it just now. :-) > > > > https://www.ripe.net/participate/policies/proposals/2022-01 > > > > I suspect that many of you are going to want to read those sections > before > > you have your memberships revoked for non-compliance. > > I can't read any details about membership revokation. Also i don't see it > as implicit. > > The three sections make perfect sense to me. In section 6.0, if i > understood correctly this won't apply to legacy resources which are still > out of any contractual relationship -- which also seems fine. > > > Regards, > Carlos > > > > 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/anti-abuse-wg > > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/anti-abuse-wg >

2 1

test database
by denis walker 22 Jun '22

22 Jun '22

Hi Why can I not create an AUT-NUM object in the test database using the web UI? It is not in the drop down menu on the create page. That of course means I can't create ROUTE(6) objects either. So I can't do anything with the routing registry in test mode. Although there is an orange banner across the top of the page saying 'TEST Environment' all the left hand index items refer to the RIPE Database. This is confusing. I would prefer them to refer to the TEST Database. cheers denis co-chair DB-WG

2 4

2022-01 Policy Proposal, Personal Data in the RIPE Database V2
by William Sylvester 13 Jun '22

13 Jun '22

All, I wanted to notify the workgroup that there is a new version of the Personal Data Proposal coming, it would be best to save any comments for the discussion period of that version. Please let me know if you have any questions. Thanks, William DB-WG Co-Chair

1 0

rfc2770
by Max Tulyev 03 Jun '22

03 Jun '22

Hi All! May be you know, if you have a 16-bit ASN, you have a /24 IPv4 network reserved for you for multicast purposes. It is 233.asnum-hi-octets.asnum-lo-octets.0/24: https://datatracker.ietf.org/doc/html/rfc2770 My ASN is 29632, so the prefix is 233.115.192.0/24 I would like to start using it (well, for testing purposes now). To do so, I need a route object in the RIPE database. How can I create it?

5 6