Hi Ed
Thanks for the update. However I have a number of concerns about the direction here. You seem to have assumed that the way forward is to make e-mail mandatory in the PERSON object. That is simply not going to happen, as I have explained in other responses. If you attempted that by any means it is unlikely to succeed. I also don't think it is a good idea from either a privacy or data accuracy pov. Adding another million items of personal data to the RIPE Database is a very bad idea. I already have doubts about how much of the existing contact data is there with 'clear consent'. PERSON objects are by their very nature personal. If you try to force people to give an email address when they don't want to, it is unlikely to be a valid address. The quality of contact data may plunge to new depths.
Again a lot of this comes down to understanding contact data. What type of contact information do we need and how and where should it be referenced from in the database? What is the difference between the ROLE and PERSON objects? How much actual 'personal' information is needed? We don't have answers to any of these types of questions.
Another possibility is to make the "tech-c:" attribute in the ORGANISATION object a required attribute, like "abuse-c:". So for ORGANISATION objects with type 'LIR' it effectively becomes a mandatory attribute. We could then require it to reference a ROLE object where "e-mail:" is already mandatory. Apply the same hereditary mechanism we use for "abuse-c:" and we have a default technical contact e-mail address available for all resources. As you go down into the more specific INET(6)NUM objects, they already have a mandatory "tech-c:" attribute. Often these are just copies of the resource holder's information. Endlessly duplicated information. As with "abuse-c:" we could make "tech-c:" optional in the INET(6)NUM objects. If it is not there we inherit from the resource holder's ORGANISATION object. Or you can add in an optional localised "tech-c:"
We know this is a manageable possibility to achieve. We did it with "abuse-c:". So we do the same with "tech-c:" in the ORGANISATION objects for resource holders, forcing a reference to a ROLE object. Then we make "tech-c:" optional in INET(6)NUM objects. For this purpose we completely ignore the PERSON objects. It will again take a few years to deploy the mandatory ORGANISATION data. Then many more years for the duplicated, now optional, INET(6)NUM data to fade away. But for that it doesn't matter how long it takes. It is optional and it is just duplicated data. It doesn't matter if it is there or not.
Because we will then be forcing the addition of mandatory data into the LIR's ORGANISATION objects, as we did with "abuse-c:", with RIPE NCC follow ups, it would need to be done as a policy, not an NWI.
Adding additional contact methods could be done in parallel to this. We could also add a rule that the new contact methods can only be added to a ROLE object and not a PERSON object. So anyone wanting to use a new contact method may have to switch from PERSON to ROLE, which has the mandatory e-mail and optional phone. So some of the false phone numbers may disappear.
cheers
denis
The DB team are working on a Solution Definition for NWI-20 and I'd like some feedback on the points that Denis has rasied before we proceed further.
Firstly, do we need to use the Policy Development Process to make e-mail mandatory on person objects? E-mail is already mandatory on organisation and role but not on person. I couldn't find a reason for this inconsistency in existing policies, or any requirement to make it so.
Secondly, do we need to cleanup existing person objects if e-mail is changed to be mandatory? Half of the existing 2 million person objects do not have an e-mail attribute. It seems unlikely that maintainers will add e-mail retrospectively. We could add validation to require e-mail only when person objects are updated, however most person objects are created and never updated again. We could add validation to require e-mail when a person is added as a contact on another object, however most exising persons are referenced from a single assignment and then never referenced again.
Thirdly, should mandatory e-mail remain part of NWI-20, in addition to creating new contact types? Multiple people in this thread have asked for it, but perhaps the changes can be made in phases, and the wider issues that Denis has raised can be tackled separately.
Regards
Ed Shryane
RIPE NCC