[address-policy-wg] 2006-04 New Draft Document Published (Contact e-mail Address Requirements)
- Previous message (by thread): [address-policy-wg] 2006-04 New Draft Document Published (Contact e-mail Address Requirements)
- Next message (by thread): [address-policy-wg] 2006-04 New Draft Document Published (Contact e-mail Address Requirements)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Wilfried Woeber, UniVie/ACOnet
Woeber at CC.UniVie.ac.at
Tue Oct 31 11:20:45 CET 2006
Michael.Dillon at 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.
- Previous message (by thread): [address-policy-wg] 2006-04 New Draft Document Published (Contact e-mail Address Requirements)
- Next message (by thread): [address-policy-wg] 2006-04 New Draft Document Published (Contact e-mail Address Requirements)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]