2006-04 New Draft Document Published (Contact e-mail Address Requirements)
PDP Number: 2006-04 Contact e-mail Address Requirements Dear Colleagues We have published a draft document for the proposal described in 2006-04. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-04.html and the draft document at: http://www.ripe.net/ripe/draft-documents/2006-04-draft.html We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 27 November 2006. Regards Filiz Yilmaz RIPE NCC Policy Development Officer
We have published a draft document for the proposal described in 2006-04.
From the draft document: By making the wording of the existing policy about contact information in the RIPE Database more explicit, we should see less spam and abuse and more rapid correction in network operations.
I question the logic of this proposal. While I also would like to see less spam and more rapid correction of network operational issues, I do not believe that this policy addresses these problems at all. A spammer that wants to comply with this policy change merely needs to maintain an abuse contact that delivers all complaints to an email robot which discards them in the same way that the RIPE hostmaster robot discards queries from unknown email addresses. But the policy has a larger problem. It attempts to place a stricter requirement on every organization which has received an assignment from a RIPE member. In this way it places a requirement on virtually every organization, commercial and non-commercial, which exists within our society. I do not believe that this is justified and I do not believe that most organizations have any real role to play in preventing spam or correcting network operational issues. The real issue here is that current RIPE policies allow RIPE members to wash their hands of all network operational issues associated with the addresses which they have assigned to other organizations. It would be far better to fix this policy by making it clear that there is one and only one organization responsible for network operational issues related to an allocated block and that is the RIPE member who received the allocation. If they want to have internal processes and contractual agreements that delegate some of that responsibility, that is OK, but they must nevertheless remain the primary point of contact. RIPE can impose an obligation on organizations who have received an allocation directly from RIPE and it can easily police such an obligation. But once 3rd parties enter the situation, RIPE can only make a lot of noise and create policies that have no teeth which no one really has to follow. The rules and policies surrounding the RIPE database are part of the tradition that we have been blindly following since the days of the ARPAnet when it was neccessary to record all users of the network in order to justify budget allocations. The network climate has change around us but the policies have not sufficiently evolved to meet the new environment. --Michael Dillon
Michael.Dillon@btradianz.com wrote: [...]
The real issue here is that current RIPE policies allow RIPE members to wash their hands of all network operational issues associated with the addresses which they have assigned to other organizations.
To some degree, I think, this is a left-over from the previous millennium when we had (mostly) PI and Last-Resort-Registries per country. In general there was no relationship between the distribution path of addresses and the connectivity, the path for the packets...
It would be far better to fix this policy by making it clear that there is one and only one organization responsible for network operational issues related to an allocated block and that is the RIPE member who received the allocation. If they want to have internal processes and contractual agreements that delegate some of that responsibility, that is OK, but they must nevertheless remain the primary point of contact.
Incidentally, the irt stuff was consciously engineered to support such a view, and to allow the proper registration of such responsibilities, plus the delegation to down-stream entities for PA-Blocks :-) The little disagreement here is that in my opinion the primary point of contact should by the "most down-strem" entity, with the NCC's Member contact to be used as an escalation path, if needed. The rational for this model is: the entity/role/group that is the NCC's member and is managing addres space may not be in aposition to get involved in operational or security aspects. This responsibility may rest with a third party, either within the same corporation or even somewhere else.
RIPE can impose an obligation on organizations who have received an allocation directly from RIPE and it can easily police such an obligation. But once 3rd parties enter the situation, RIPE can only make a lot of noise and create policies that have no teeth which no one really has to follow.
The rules and policies surrounding the RIPE database are part of the tradition that we have been blindly following since the days of the ARPAnet when it was neccessary to record all users of the network in order to justify budget allocations. The network climate has change around us but the policies have not sufficiently evolved to meet the new environment.
Eventually, the results from the Data Protection Task Force may easily require us to do "a bit" of re-modeling...
--Michael Dillon
Wilfried.
The little disagreement here is that in my opinion the primary point of contact should by the "most down-strem" entity, with the NCC's Member contact to be used as an escalation path, if needed.
I agree that this is superior in practice but only if that "most down-stream" contact is READY, WILLING and ABLE to act upon problem reports. It would be wise for a registration policy to allow and encourage the assignees to register such a contact, but the policy can only make it mandatory for LIRs to register such a contact. I think that if RIPE ever did make a sensible and workable policy like this, then the LIRs would put some effort into making sure that their customers have contacts who are READY, WILLING and ABLE to act upon problem reports. But they are closer to those customers and will know where it makes sense to do this and where it does not.
The rational for this model is: the entity/role/group that is the NCC's member and is managing addres space may not be in aposition to get involved in operational or security aspects. This responsibility may rest with a third party, either within the same corporation or even somewhere else.
If RIPE is going to require a working abuse contact then it should point to the group that has this responsibility, not to the group that deals with address management. That is why I stress that the abuse contact must be READY, WILLING and ABLE to act upon problem reports. --Michael Dillon
participants (3)
-
Filiz Yilmaz -
Michael.Dillon＠btradianz.com -
Wilfried Woeber, UniVie/ACOnet