Yes. When people post these types of objections they generally get ridiculed and the issues never get put into any minutes or reports because the people involved are practicing a religion and not doing a technical/legal analysis. On 7/28/2012 1:39 PM, Peter Koch wrote:
On Mon, Jul 16, 2012 at 10:02:29AM +0100, Brian Nisbet wrote:
would ask if members could raise any points that they are still uncertain about and state as clearly as possible, their current opinion on the proposal. I have read version 3.0 of 2011-06 and the NCC's impact analysis.
While I agree with some of the goals of 2011-06, I object to the proposal in its current form. In fact, I think it is not even ready for the Review Phase, even though I understand that was the way to invoke the NCC impact analysis. Here's already one reason to object: the proposal itself is hardly comprehensible without said impact analysis but since the latter is not part of the proposal it can only be considered transient. Without even remotely suggesting the NCC was driving policy here, I must say with both hesitance and regret that I am not comfortable with the role the NCC has been dragged into w.r.t 2011-06.
o The proposal and impact analysis are unclear about the aspects of data protection issues for the "abuse-mailbox:" attribute. It appears it is intended to "by definition" avoid PII here. How would that work for address space allocated (or, more importantly, assigned) to a natural person? That said, the proposal is also unclear whether the abuse-c: would apply to PI space, as well.
o The proposal uses unclear language w.r.t. the mandatory nature of the "abuse-c:" attribute:
``This policy introduces a new contact attribute named "abuse-c:", that can be included in inetnum, inet6num and aut-num objects. ''
vs.
``The role objects used for abuse contact information will be required to contain a single "abuse-mailbox:" attribute which is intended for receiving automatic and manual reports about abusive behavior originating in the resource holders' networks.''
o The second paragraph quoted above expresses an expectation regarding the handling of submitted email reports (what else would it mean to be prepared for "receiving automatic and manual reports"?)
o The purpose of the "e-mail:" attribute is given with "other". I do not understand that. I would suggest to separate the targets for 'manual' and 'machine readable' reports. It is natural for any object in the RIPE DB to use the 'email:' attribute for email communication. {this is listed for completeness; i have read the longthread on the topic and don't suggest to rehash. The proposal, in summary, has bigger problems.}
o The proposal is unclear at least about the future of irt: objects.
o Finally, and most importantly, I object to the mandatory nature of the attribute. Neither the impact analysis nor the counter arguments section assess the impact of presence of an abuse (role) object and the resulting actions on maintainers/... LIRs/NCC members.
-Peter