Hi Aftab, all,
In my opinion, the policy text + the explanations/presentation provided by the authors + the “additional information” section of the policy proposal, was providing the information to avoid this type of issues. Of course, the secretariat could take different implementation approaches, but the fact that we worked the details in the “additional information” was precisely because we foresee some possible issues and we suggested some implementation details to avoid them. I recall I’ve already sent a couple of emails to respond to some of those issues after a presentation of George, they should be archived. Actually, I think one of those emails that I’ve sent was not responded. I was asking there if some of the issues require an update of the policy via a new proposal. Could the secretariat take a look and tell us? Trying to summarize: IRT was meant to (optionally) disappear at some point, or be an “alias” of abuse-c. Initially it is expected that the “main” abuse-c is created as a duplicate of the existing IRT. Each organization need to define if they want additional abuse-c for different set of resources. For example, you may have a different abuse handling team for IPv6 and IPv4, or even for different IPv4 blocks; you may want to have a customer-assigned block to be handled by the customer abuse team, etc. I don’t think Country and Phone should be mandatory, but of course, instead of bogus data should be empty, if no data is available. Note that I’m also not opposed to have them with mandatory Country and Phone, but the full idea of the validation process is to have a “working email” so if the working email being validated doesn’t work, the policy escalate to other contacts and those contacts, should already have the right country and phones, right? So, I don’t think this specific topic requires a policy update, unless I’m missing something? Regards, Jordi @jordipalet El 27/5/21 6:19, "Aftab Siddiqui" <[email protected]> escribió: Hi Everyone, As some of you have already seen the discussion [1] on twitter, started by Fakrul. Just sharing the problem here. As part of some of the additional request/reference in prop-125 (Validation of “abuse-mailbox” and other IRT emails) "APNIC will publish the IRT also as abuse-c, in order to facilitate the search in whois, for the same information, regardless if looking for abuse-c or IRT. This is done in order to assimilate the IRT to the majority of the RIRs where it is abuse-c." APNIC Secretariat implemented this by adding "abuse-c" attribute in the inetnum (example below) and inet6num. inetnum: 103.162.142.0 - 103.162.143.255 netname: ISAL-SG descr: Internet Society Asia Limited descr: 3 Temasek Avenue Level 21 Centennial Tower country: SG org: ORG-ISAL1-AP admin-c: ISAL1-AP tech-c: ISAL1-AP abuse-c: AI706-AP The abuse-c attribute requires NIC-handle but which NIC-handle? There can be many NIC-handle within the organisation but one organisation can only have one IRT object. So, APNIC generated a new "role object" using the data from the IRT-object. Now, the problem is that role object has some mandatory field as per APNIC whois policy defined here [2], which either doesn't exist (country) or are optional (phone) in IRT object i.e. role: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] country: [mandatory] [single] [ ] phone: [mandatory] [multiple] [ ] irt: [mandatory] [single] [primary/lookup key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] When APNIC auto generated the data for this new abuse-c NIC-handle, they filled it with bogus data. role: ABUSE ISALSG address: 3 Temasek Avenue Level 21 Centennial Tower, Singapore Singapore 039190 country: ZZ phone: +000000000 The APNIC Secretariat is seeking suggestions to fix this problem as to how to fill up the missing information. IMO, a simple way would be to make Country (ISO-3166) and Phone number mandatory in the IRT object (currently they are optional). This can be done during the next IRT validation cycle. Btw, Country Code in the role object is not a mandatory attribute (it doesn't exist) as per RFC2622 [3] but it is as per APNIC whois policy. [1] - https://twitter.com/rapappu/status/1397522066002247686?s=21 [2] - https://www.apnic.net/manage-ip/using-whois/guide/role/ [3] - https://datatracker.ietf.org/doc/html/rfc2622#section-3.3 Regards, Aftab A. Siddiqui ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] https://mailman.apnic.net/mailman/listinfo/sig-policy
