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.
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?