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 sig-policy@lists.apnic.net https://mailman.apnic.net/mailman/listinfo/sig-policy
