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
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

[db-wg] (no subject)

  • From: "Wilfried Woeber, UniVie/ACOnet" < >
  • Date: Mon, 09 Feb 2004 14:53:42 +0200
  • Cc:

>> Creating irt objects is not any harder than creating a new maintainer,
>> maybe the documentation should focus more on this and less on marketing
>> the TI concept (which apparently only NRENs care about).
>
>First problem with IRT is that in order for it to have any value every LIR
>has to actively modify ALL their inetnum objects......... Now that must mean
>that the intention has never been to make sure all LIRs implement it.

  Sorry, but this just wrong.

  It is exactly one of the advantages (of course you might want to have a
  different point of view :-) that modifying 1 (or a very small number of)
  object(s) would be sufficient - as long as we are talking hierarchical
  (i.e. LIR) address space.

  Tagging the _allocation_ object of an LIR would cover _all_ the
  _assignment_ objects in that block. With the added benefit that you can
  still have a "more specific" or 1st-line pointer in an assignment
  object.

>Next problem is the idea behind IRT, apparently it is to be used by
>companies who outsource handling of abuse - we don't.

  Out-sourcing would be supported, but it is a secondary issue. The
  primary issue is that it allows maintaining the data by the group being
  responsible for a certain function. There are real life situations where
  the role/group/team keeping track of address assignments is _different_
  from the role/group/team being responsible for abuse or incident handling.

If I should use this
>object it should have a normal mnt-by attribute and the following fields
>either removed or made optional: address, signature, encryption, auth.
>
>I can appriciate the need for the features of the IRT object, but WHY can't
>the rest of us get a working solution to our problem?

  "You" (actually we ;-) can certainly get a solution, as soon as there is
  rough consensus in the WG that the approach proposed is _probably_ going
  to work and has a reasonable "price tag" (i.e. the implementation
  effort).

> It doesn't necessarily
>mean that we can't preserve the features of the IRT.
>
>
>
>Med venlig hilsen/Best regards
>
>Christian Rasmussen
>Hosting manager, jay.net a/s
>
>Smedeland 32, 2600 Glostrup, Denmark
>
>Email: noc@localhost
>Personal email: chr@localhost
>Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301
>
>Produkter / Products:
>http://hosting.jay.net

--------------------------------------------------------------------------------

  Wilfried.




  • Post To The List:
<<< Chronological >>> Author    Subject <<< Threads >>>
 

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