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 <[email protected]> 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://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
