About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section

Re: [address-policy-wg] 2006-04 New Draft Document Published (Contact e-mail Address Requirements)

  • From: "Wilfried Woeber, UniVie/ACOnet" Woeber@localhost
  • Date: Tue, 31 Oct 2006 10:20:45 +0000
  • Organization: UniVie - ACOnet
  • Reply-to: Woeber@localhost

Michael.Dillon@localhost 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.




 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | © RIPE Community. All rights reserved.
RIPE.NET Homepage LIR Portal RIPE Community