2010/1/30 Tobias Knecht <knut@abusix.org>
Hi Mark,

thank you for your time asking these questions.

> Regarding the following:
>
>  "    - Refer to the nic-handle of a person or role object that contains
>       contact information for the appropriate dedicated abuse handling
>       department"
>
> I am the tech-c for my organisation but the email address registered against
> my nic-handle relates to me personally, not to any relevant abuse role
> account holder.

The status at the moment is, that APNIC suggestst the usage of admin-c
or tech-c for abuse reporting. That way everybody would use your
personal address to report to. As you already mentioned that is not the
good way.

Therefor the idea is to add an abuse-c. And populate it with existing
tech-c information. Which makes no difference to the status now. But it
gives the opportunity to create an role account and populate the abuse-c
with that. So in the very beginning there is no change, the change
happens just if you want it.

The result is more flexibility.


I fundamentally agree with the idea of an abuse-c (or similar) being compulsary; netblock holders should be encouraged to provide actual, legitimate details.

You have to start somewhere.  As Mike Jager? Noted, folks are already automating the process and scraping out admin-c or tech-c POCs, and they may well not change behavior.  However if _everyone_ had an abuse-c and could rely on it actually being valid, folks can change...

(You have to start somewhere. That's part of why I at this stage, approve of this idea.)

 
As I understand the proposal and as I would like to have it implemented
there must be the possibility to add an role object. That is what I
would suggest every netrange owner to add an abuse role account and not
a personal handle.


Excellent.

 
> * What are the obligations of folks to maintain their apnic data as
> accurate?
> * Will there be any validation of these addresses before the data is
> replicated to abuse-c?

That would be good.

I'd like to see it pursued.
I see invalid data in whois detail as a bigger problem than the mandatory-or-not-ness of abuse-c, to be honest.
 

> * Could we present a nice piece of automation that could be sent to tech-c
> folks asking them to quickly supply (via web form or similar)
> updated/revised abuse-c data and populate it that way instead (perhaps with
> a 'if nothing heard, we'll use tech-c' escape clause)
> * Has APNIC considered emailing existing tech-c's as regards this policy,
> thus directly notifying the role holders of the upcoming change (rather than
> relying on those who actively participate in APNIC matters) and
> simultaneously identifying any addresses which 'dont' work' ?

I think an email reminder that tell netrange owners every 3 month to
check if everything is still accurate and klick a link to aknowledge
would be a perfect thing. Sometimes I hear people say, we don't think
about updating our whois information, because we just forget about it.
It's not even intentional.

Annually would be sufficient. My .com domains are subject to a yearly prod by my registrar to ensure the whois data is current... there's precedent here.
 
> One of my pet peeves is whois data that contains invalid details.  Just
> yesterday I found yet-another-ISP with details listed by APNIC specifically
> for 'abuse' purposes, where the mailbox concerned didn't actually exist.  I
> was forced to revert to a scattergun on some 'likely guesses'.
>
> In summary I guess my issues are:
> - Validating that tech-c's are infact aware that their email addresses are
> being recycled for abuse-c
> - Validating that these tech-c/abuse-c's are actually operable and manned.
> - I agree that the tech-c is the obvious starting point but a nice-and-easy
> way for org's to submit standalone abuse-c without drama would likely get a
> lot more useful buy-in on th is otherwise excellent and much-needed idea.

Lot's of good ideas. And I think there is potential for another policy
proposal.


I will be watching for comment from those more learned than myself in this area.  Thanks for the feedback, Tobias and others.

Mark.