This is the email I was referring to:

 

https://mailman.apnic.net/mailing-lists/sig-policy/archive/2020/09/msg00004.html

 

There are a couple of emails after this one.

 

I think we need to get clear responses from the secretariat if “anything” 
requires a policy update, or it is just implementation details that they can 
adjust without working out a policy proposal.

 

Regards,

Jordi

@jordipalet

 

 

 

El 27/5/21 8:31, "JORDI PALET MARTINEZ" <[email protected] en 
nombre de [email protected]> escribió:

 

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:

 

1)      IRT was meant to (optionally) disappear at some point, or be an “alias” 
of abuse-c.

2)      Initially it is expected that the “main” abuse-c is created as a 
duplicate of the existing IRT.

3)      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.

4)      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.


**********************************************
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



**********************************************
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

Reply via email to