Re: Extension for an abuse contact in Domain objects?
Luis Muñoz <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
On Oct 29, 2012, at 10:50 AM, Michele Neylon :: Blacknight wrote: > Most of our registrants wouldn't know what what to do with an abuse report. As a hosting provider and registrar we end up having to pro-actively contact our clients when there are issues and explain to them in simple terms how to remedy them. > While I can see that kind of thing being of use to the more technically minded registrant I'd imagine that they're in a minority and would probably be more likely to have some kind of reseller access if they were registering larger number of domains .. Yes, the technical illiteracy argument is a very powerful deterrent. The same argument could be made about Tech contacts and the like, which in many cases end up being handled by a (hopefully better) informed third party. IMO this would be a point against a "mandatory" contact. I think having an optional abuse contact defined for Domain objects would allow knowledgeable Registrants a mechanism to advertise the existence of this POC (and to some extend, a working abuse contact could be a data point in and on itself). Less inclined Registrants could simply refrain from providing this information, so the fallback would be the current status quo. More competent Registrants would use this optional POC to advertise their preferred email for receiving complaints, sparing hosting technical contacts -- which in many cases belong to different organizational structures -- from having to sort through reports destined for other groups. Certainly having a "back-office" solution (via web UI or an off-band process) to manage this type of contact information would work for smaller volumes, but having API support for this would negate the need to provide such access for this purpose. Current resellers would then use the existing interfaces to provision this information just as they do with the rest of their contact data. Best regards -lem _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg