2011-06 Review Phase Extension
Colleagues, Thank you all for your discussion on 2011-06, however I will admit that the picture of how the Working Group stands in regards ton consensus is not clear. At various points in time different members of the WG have spoken up, voiced objections, agreed, asked questions or answered questions, but in several circumstances the opinions were still not clear after all the discussion. In order to try to get a clear idea of how to progress and after speaking to the NCC in regards to the PDP I have decided to extend the Review Phase by four weeks to see if that can produce some clarity. I 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 would encourage everyone to read the last mails from Tobias and the NCC (in the guise of Denis Walker) as they address a number of points. While I'm hoping we can get a clearer picture in less than four weeks given that we are now in mid-summer, a decent period of time seemed like a good idea. Thanks, Brian, AA-WG Co-Chair
I will admit that the picture of how the Working Group stands in regards ton consensus is not clear.
The discussions between a small group of people on this list has nothing to do with "consensus." 99.99999% of the affected users have no idea about what is happening. Calling this a "concensus" is delusionsal and/or fraudulent.
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
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
Hi,
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.
I partly agree with you. This proposal is a bit different than what RIPE Community and RIPE NCC is usually looking at, as far as I can remember. And it is sometimes tricky to fit it into the existing processes, but the real funny thing is that there will be a lot of proposals like this in future, promised But I'm absolutely not agreeing with you about the role RIPE NCC is taking here. I think RIPE NCC is at the moment taking their role very seriously and is doing exactly what they need to do. They are consulting from a technical perspective which makes a lot of sense since RIPE NCC has to develop and maintain the system. It was the TFs and communities wish that I rewrite the proposal and keep to deep technical specifications out of it and just define the feature set I'm looking for. But since you have not specified what exactly you do not like at RIPE NCCs role at the moment it is hard to answer more specific.
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.
I'm not sure if I really got your point here, but I will give it a try. I do not see data protection issues with the "abuse-mailbox:" attribute, because it's clearly defined that it is not personal data. And in addition to that it is part of an role object, which usually should not contain personal data either. This is one point that was wanted by me as a proposer and was supported by the TF and the community, that information required to report security incidents must be unrestricted. If IP space is allocated or assigned to a natural person and there is an abuse-c, the abuse-c should not contain the information of the natural person, because it is a role and not a person. And I found this part of Denis' explanation very interesting: "Also the original intention of the database design was to represent people by PERSON objects and to group people into roles using ROLE objects. Then only ROLE objects should be referenced in any other data objects. [...] This methodology is explained in the RIPE Database Update Reference Manual, but was never enforced in the database software." If this original intention would be enforced we would not have this conversation here and maybe this is something we should as well think of in the near future.
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.''
What are we talking here about? The mandatory need of an "abuse-c:" or the mandatory need of an "abuse-mailbox:" attribute within the mandatory "abuse-c:" "The "abuse-c:" will be mandatory for all aut-nums." This one should be clear. "Due the hierarchical nature of IP address objects, at least every direct allocated inetnum and inet6num needs to have an "abuse-c:". Inherited objects might have their own "abuse-c:" attribute or they will be covered by the higher level objects." "abuse-c:" is mandatory for direct allocated inetnums and inet6nums. For all the others it is optional. But if there is an "abuse-c:" object, no matter where it is, it is mandatory that it has an "abuse-mailbox:" attribute. I do not see the confusion here.
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"?)
Is that a problem? Asking for an "email:" attribute in any other object expresses the expectation to receive mail. If you read the mail or not is not part of the policy and can't be forced in any way. This is nothing else than transferring a known and used best practice into a policy text. This has been done at RIPE, ARIN, ..., IETF a thousand times before and is imho the way to go with best practices and common used techniques.
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.}
The address of the "e-mail:" attribute is for communication between the roles and not for receiving reports. It's intended for everything other than reports. For example verification emails, communication between abuse desk of different institutions. Maybe asking questions about reports sent between each other. Maybe exchanging technical information about things and stuff. Just for the completeness: Splitting up into different addresses didn't find imho consensus here, so I think this is not an option at all.
o The proposal is unclear at least about the future of irt: objects.
Right. Because this proposals intent is not to discuss the future of the irt object. We mentioned that at the very beginning and in another thread about this subject we decided with people from the irt community being involved that the irt object is another topic and needs to be reviewed. But whatever will happen with the irt object it is not part of this proposal.
o Finally, and most importantly, I object to the mandatory nature of the attribute.
The "abuse-c:" attribute or the "abuse-mailbox: attribute? Or both? As mentioned above the "abuse-c:" attribute is only mandatory in aut-nums and in direct allocated inetnums and inet6nums. And I do not see any reason that this might be a problem since some internal statistics we have made show that more than 96% of the direct allocations have already published an abuse contact in any way and we were not even able to catch them all for some of the reasons we have discussed here. Talking about the "abuse-mailbox:" attribute I found the other thread about splitting up into automatic and manual report addresses that people are comfortable with the idea of a mandatory "abuse-mailbox:" attribute. It also makes a lot of sense for me, because the "abuse-mailbox:" attribute is already known and used for this purpose, just in a little confusing way. So I'm really interested in hearing more reasons for your objection here no matter if you are talking about the "abuse-c:" or the "abuse-mailbox:" 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.
We have discussed these things here on the list and as far as I can remember we were able to handle counter arguments, such as the mandatory "abuse-c:" for "all" inetnums and inet6nums by changing the policy text. Same with the irt object, which will be reviewed in another step. At the moment I can't remember more than these things, but people who came up with these concerns have later on agreed that their concerns have been heard and solved by changing the policy text, that's why we do not have any more concerns that found a majority and have been accepted as concerns on this list. And I would like to stay on this path and rather find solutions to objections that make sense and find consensus within the community than mentioning them as objections and keep them as objections in the proposal. Thanks for your input and I hope I was able to clarify some things. Tobias
Peter, Obviously Tobias has addressed a number of points, but I wanted to just touch on one particular thing: Peter Koch wrote the following on 28/07/2012 18:39:
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.
Could you be a little more clear with regards to this discomfort? The NCC, in all the conversations we've had with them, have been very happy to assist the community in this regard and while it is acknowledged that there will be work to do, they have given us the message that it is work they will do should the policy be approved. I suppose I'm uncertain of how else we could proceed? As with any policy I want to make sure that there is no doubt the PDP was followed correctly, and while obviously there are other checks & balances, part of this is ensuring that this WG feels things have been undertaken in the correct way. Thanks, Brian.
participants (4)
-
Brian Nisbet -
lists＠help.org -
Peter Koch -
Tobias Knecht