Dear Aftab Bhai,
Thanks for pitching in.
As I understand, the template being used to implement prop-125 is of role object where in the data flows from irt object. Now as country does not exist and phone number is optional in irt object but the role object template has both country and phone number mandatory, the implementation was done by making country as ZZ and in case where phone number is not there in irt, it is hard coded to appear as +0000000.
Now the way ahead being suggested is to change the role object template wherein country will be removed and phone number will be made optional. So unless there is a pressing need to use the role object template, to fix this, if the irt object template is considered for creating abuse role object instead of role object template, there is possibly no requirement to change the role object template.
--
________________________________________________________
Anupam Agrawal | India Internet Foundation - Chair | 91 990 399 2838
Having the country information is definitely an advantage. If the phone number is made optional, then the issue of phone field getting populated with +00000000 will still be there if the phone number is not given.
I totally agree that country information (Country Code) is important but we can lookup that info in inetnum/inet6num, autnum, organization and person objects where Country attribute is mandatory.
The current reason for filling a phone number with +00000000 is because it's a mandatory attribute and can't be left blank, once it becomes an optional attribute then there is no need to fill it up at all.
Pardon my ignorance but the current APNIC model - it is causing an issue exactly where?
The new Abuse role object was created by APNIC (adding IRT object data + bogus data) as the consequence of adding abuse-c attribute, it was suggested in prop-125.
Why does it matter to get rid of bogus data? - We have been trying to clean up the whois data for a long time, even prop-125 was an effort towards the same thing and adding a new role object with some bogus data is definitely not something we should ignore. OTOH, yes it doesn't impact while parsing the object for the abuse email.