[db-wg] 2022-01 New Version Policy Proposal (Personal Data in the RIPE Database)

Dear DB-WG,

Hoping that this email finds you in good health!

Please find my comments below, inline...

Le lundi 20 juin 2022, Ronald F. Guilmette via db-wg <db-wg at ripe.net> a
écrit :

> In message <CAKvLzuFA0y8mOzPiiy4tHBCRUNUBbQgJc-DD54E-S+0TW=StiA at mail.
> gmail.com>
> denis walker <ripedenis at gmail.com> wrote:
>
> >

>
> >> [...]
> >
> >> What gives you or anyone the right to take away a member's rights to
> have
> >> their true and actual mailing address in their own public WHOIS records?
> >
> >Again you simply don't understand the issue. "their true and actual". This
> >address is 'defined' in the database documentation as "The postal address
> >of a contact related to the organisation". That can be anyone based in any
> >location in the world, as Europol have discovered.
>
> Sounds like a definite problem to me!  So lets fix that.  Let's require
> *at least* the REAL name and address of each member to be present in that
> member's public WHOIS record.
>
> Every new member has to submit some identifying documents at the time they
> first become members, right?  If it is a  corporation, then a copy of the
> formal and legal incorporation document(s) must be submitted as part of the
> application process.  If it is person, then either a copy of that person's
> passport or some other form of government-issued identification document
> must be submitted as part of the new/prospective member's application for
> membership, right?  So we take this "real" member name & address info,
> copy it off those bona fide documents, and stick the same data into the
> member's public-facing WHOIS record.  Is this just, like, too simple,
> or what?
>
>
>

Hi Ronald,
Thanks for your email, brother.

...i agree, you should be a bit fair with Denis :-/

You know, reducing your tone would not, imho,
imply any loss in the value and strength of your
arguments at all :-/

Having said the above, these [1,2,3,4,5] RIPE Lab
 articles provide, imho, interesting discussions,
and very useful information, on topic...
__
[1]: <
https://labs.ripe.net/author/ad_castle/lessons-learned-from-ripe-when-creating-a-new-community-database-in-a-very-different-field/
>
[2]: <
https://labs.ripe.net/author/matt_parker/the-assisted-registry-check-let-us-help-you/
>
[3]: <
https://labs.ripe.net/author/athina/how-were-implementing-the-gdpr-legal-grounds-for-lawful-personal-data-processing-and-the-ripe-database/
>
[4]: <
https://labs.ripe.net/author/denis/review-of-database-consistency-service-dbconstat/
>
[5]: <
https://labs.ripe.net/author/denis/diff-functionality-in-the-ripe-database/>



>
>
> As I have said, if there are natural person journalists, or activists, or
> other folks who have other issues pertaining to lifestyle or whatever, and
> who can make at least a prima facia case that they need to have both (a)
> number resources AND also (b) privacy of their PII, then allow NCC to
> accept their requests to be exempt from publication of their PII on a
> case by case basis.  For everybody else however, what you see (in the
> public
> WHOIS) is what you get, i.e. the real names and the real addresses.
>
> Problem solved!  And everybody's happy.
>
>
>

At least my humble person will be!

Many thanks for this alternative, i fully support.

...imho, a solution of a real problem shouldn't be
implemented, if it removes the ability and solution
that at least network operators (NO) actually have;
 and which allow them to freely and *privately*
communicate each other...(home office addresses
might be considered a distinct concern, though...).

That kind of solutions would remove available,
enventually *good*, solutions (new problems) and
may contribute to more fragmentation within NO's
 community; amongst other possible consequences.


https://labs.ripe.net/author/kranjbar/proposed-improvements-to-dummification-of-personal-data-in-the-ripe-database/#:~:text=It%20has%20been,exposed%20with%20no%20limits
.


https://labs.ripe.net/author/kranjbar/proposed-improvements-to-dummification-of-personal-data-in-the-ripe-database/#:~:text=The%20current%20dummification,the%20data%20protection%20rules
.


https://labs.ripe.net/author/kranjbar/proposed-improvements-to-dummification-of-personal-data-in-the-ripe-database/#:~:text=Proposed%20algorithm
:,the%20objects%20below:


https://labs.ripe.net/author/alexband/improving-the-management-of-ripe-database-objects-with-joint-responsibility/#:~:text=In%20the%20future,who%20query%20it
.




>
> The only people who could be against this are people intent on committing
> fraud or some other kind of nefarious skulduggery on the Internet WHILE
> USING THEIR ASSIGNED NUMBER RESOURCES.
>
>
>

Ronald...this is not what drove my support to your
 proposed alternative :'-(

...and as said, above, imho you absolutely not need
 to use that kind of language to be heard, brother.

Remain blessed, y'all!

Shalom,
--sb.



>
> >> So now, why don't you re-submit this proposal and instead propose that
> *all*
> >> mailing address information, including even the country name, be
> redacted
> >> from the data base for *all* members?
> >
> >It will be optional.
>
> Wait... WHAT???
>
> Could you please repeat that?  I want to make sure that even the people way
> in the back heard that.
>
> So your -actual- proposal is to make *all* WHOIS information for *all*
> classes
> of RIPE members "optional"???
>
> Take your time.  If you misspoke, then by all means, please rephrase so as
> clarify what you really meant to say.
>
>
> Regards,
> rfg
>
> --
>
> [...]



-- 

Best Regards !
__
baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure>
Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/>
__
#‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous
tous! ‪#‎Amen‬!»
‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬
«Comme une biche soupire après des courants d’eau, ainsi mon âme soupire
après TOI, ô DIEU!»(#Psaumes42:2)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20220622/72eaacf1/attachment.html>