Hi Jordi, Aftab and all,
Thanks for your support. It's a known post implementation operational
issue. We discussed it internally and agreed to sync APNIC Whois code
with the RIPE NCC and AfriNIC Whois Databases, and report the details at
APNIC 52.
Regards
Sunny
On 27/05/2021 10:22 pm, Aftab Siddiqui wrote:
Hi Jordi,
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.
I have the same opinion.
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.
Yes, It wasn't mentioned in the policy that a new role object should
be created and filled with IRT object's attributes. I don't see any
reason for an update in the policy, it's an operational issue BUT if
the Secretariat believes that they can't make any changes and require
policy support then please let us know.
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.
I agree with the latter part.
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.
Well, NO. Let's stick to what was proposed in prop-125 :)
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?
Country and Phone number fields are mandatory as per the APNIC whois
policy and can't be left blank, that's why they are filled with ZZ
(ISO-3166 code for user defined country) and +000000000 as phone
number. Validation is not an issue here as the email address attribute
exists in both objects and has been verified.
* sig-policy: APNIC SIG on resource management policy *
_______________________________________________
sig-policy mailing list
[email protected]
https://mailman.apnic.net/mailman/listinfo/sig-policy
--
_______________________________________________________________________
Srinivas (Sunny) Chendi
Senior Advisor - Policy and Community Development
Asia Pacific Network Information Centre (APNIC) | Tel: +61 7 3858 3100
PO Box 3646 South Brisbane, QLD 4101 Australia | Fax: +61 7 3858 3199
6 Cordelia Street, South Brisbane, QLD | http://www.apnic.net
_______________________________________________________________________
* sig-policy: APNIC SIG on resource management policy *
_______________________________________________
sig-policy mailing list
[email protected]
https://mailman.apnic.net/mailman/listinfo/sig-policy
