[db-wg] Thoughts on 2022-01

Hi Leo

Thanks for the email and thoughts. It seems you have two main concerns
about clarity - verification and compliance. So I will try to expand a
bit more on these concepts without getting too deep into
implementation details. In this email I will focus on verification.

For some people the fact that they feel they 'must' consent to their
personal details being entered into an open, public database to be
allowed to hold internet resources is not a welcome situation. For
others who may have given their consent to publishing personal data,
the degree to which that is 'informed consent' is a grey area. But
there are further problems once this personal data is in the database.
There are many ways that personal data can be abused.
Misrepresentation of responsibilities for resources has always been a
problem. We all accept that the transition from using personal data
for contacts, for example, to using business data is not going to
happen overnight. So there will still be a considerable amount of
personal data in this database for some time.

There are two main ways that data can be misrepresented, or misused,
within the database. One is to make references to someone else's
PERSON, ROLE, MNTNER or IRT objects in your resource objects. This can
be done accidentally by a simple typo in a NIC handle or maintainer
name. Or it can be done deliberately with the intention to divert
attention and responsibility for your resources to someone else. This
cannot be done with ORGANISATION objects because of the mandatory
"mnt-ref:" and optional "ref-nfy:" attributes. It is possible to
periodically inverse query for references to your objects and check if
anyone else is referring to them. But for large organisations with
many resources and secondary objects, even scripting this would be a
major task. Also once someone has referenced your objects you cannot
delete them. You have to make a case to the RIPE NCC to remove
references in other resource holders data so that you can delete your
own objects. The RIPE NCC has acknowledged this to be a problem and
recently proposed adding an optional "mnt-ref:" attribute to the
PERSON, ROLE, MNTNER and IRT objects (NWI-14). If used, these
attributes would eliminate this form of abuse in the database.

The second form of abuse is to copy someone else's personal contact
data and create your own object with that data. This never happens
accidentally. It is a deliberate attempt to deflect responsibility for
use of resources. There is almost nothing anyone can do to prevent
this. Trying to write scripts to do free text searches on
'significant' elements of your details and interpret the results would
be complex and error prone.

Verification of phone numbers and email addresses would prevent this
second form of abuse of personal details. It would also improve the
value of the data in the database by ensuring that these contact
details were 'active' at the time the data was entered into the
database. To propose doing some verification, where possible, is a
principle that we want to apply to the use of the RIPE Database. That
is why it is included in the policy proposal. How this verification
may be done is implementation. But I will expand on my personal
thoughts on this matter as an introduction to the implementation
discussion.

First of all what data should we consider for verification? Probably
phone numbers and email addresses. Phone numbers only appear in the
"phone:" attribute in several object types, ORGANISATION, ROLE, IRT,
PERSON. All of these should be verified. An email address can appear
in several different attributes in many different object types. Not
all of these need to be verified. For example notification attributes
are email addresses. These are for monitoring data changes. They are
not for contacting anyone and generally don't reflect responsibility.
They are often used as an audit trail and most likely never looked at
unless the resource holder has a problem. There would be no point in
verifying these addresses. The emails that need to be verified are in
the same objects as the "phone:" attribute. These are the ones that
are intended to be used to contact someone.

When would we want to verify them? When a new phone number or email
address is added to one of these objects. It would be a one time
verification. The goal of the verification is to ensure the
organisation who holds or uses the resource does have access to the
phone or email address they publish. It also proves that the
communication channel was at least active at the time the data was
entered into the database, reducing the amount of false data entered
into the database. There is no need to do any repeat verifications on
a regular time basis to achieve these goals.

How would the verifications be done? This is not my area of expertise
so these are just some suggestions:
-For email addresses, this could be by sending an email and check for
a reply. Maybe add a unique code to the body of the email that must be
copied to the subject of the reply. This would prevent auto responders
and ticketing systems verifying email address by default.
-For mobile phone, this can be by sending an sms with a code and check
the code is entered into a web form.
-For fixed line phones a code can be sent to a related email address
and check for a reply to the email.
-For fax a code can be automatically sent by email to the fax and
entered into a web form.
The update to an object with a new or changed email address or phone
number (creation or modification) will be held until the verification
is complete. This is similar to the way ROUTE objects were held
pending dual authentication. Phone and email addresses are in
secondary objects. These can be created in advance of creating
resource objects. In a normal workflow for an LIR making an assignment
to an end user, if the end user is going to provide the technical
contact for the assignment they will have to create their own ROLE
object with their contact details before the assignment can be made
referencing it. The verification is done by the end user when they
create the ROLE object. If the LIR is going to be the technical
contact their ROLE object will most probably already exist, so no
additional verification is needed. So disruption to the workflow of
LIRs should be minimal, if any.

We could perhaps implement a service where organisations/LIRs can
pre-verify a list of phone numbers and email addresses linked to
MNTNER objects. Then any objects maintained by this MNTNER object can
have these phone numbers or email addresses added without any delay.
We have to think out of the box to develop ways of doing the
verifications with the minimum disruption to work flow but adding the
benefits of this verification. From the RIPE NCC side this should all
be automated.

Obviously this would be introduced for new data being added to the
database. Even that could be phased in, starting with one object type,
maybe the ROLE object. The backlog of verifying existing data could be
an entirely separate project over time.

I hope this helps to clarify what is meant by verification.

cheers
denis
Proposal author

On Mon, 27 Jun 2022 at 16:51, Leo Vegoda via db-wg <db-wg at ripe.net> wrote:
>
> Hi,
>
> Thank you for producing this proposal. It's important to regularly
> review policy and implementation to ensure we are meeting our legal
> responsibilities.
>
> Parts of the text in this proposal are clear and easy to interpret.
> For example section 3.0 on Notifications is well written.
>
> Other parts are highly ambiguous. The text as written would just lead
> to disputes. For example, "Email addresses added as contact details
> and all phone and fax numbers entered into the RIPE Database must be
> verified." Who must verify them, what must they verify, and when
> should this happen?
>
> Is this just a check that the contact information is syntactically
> correct? Or is this a check that a fax machine is active and used by
> the organization listed alongside it?
>
> It would be helpful to clearly separate the sections defining a
> principle from those defining an implementation. The text on
> verification and compliance is so ambiguous that it's not possible to
> understand what an implementation would look like.
>
> Kind regards,
>
> Leo Vegoda
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/