This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
[db-wg] Abuse-C/IRT
- Previous message (by thread): [db-wg] Abuse-C/IRT
- Next message (by thread): [db-wg] Abuse-C/IRT
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Pim van Pelt
pim at bit.nl
Thu May 6 19:45:02 CEST 2004
Hi Wilfried, others, | >should I revert that software | >change and NOT set mnt-irt in the more specifics, or should I leave it | >as is. Opinions ? | | setting it to the _same_ pointer is superfluous or just duplication of | information. I have rolled back the CVS to reflect Jeroen's previous behavior. I was not aware that IRT was meant to be followed upstream until an object was found. | BUT - what you can do with this mechanism is to point to a _different_ | irt object. Either for a subset of your own infrastructure (like a | regional PoP), or as a 1st level contact for your downstreams. .. | And those downstreams can update the contact info without having to | bother you in your role as the _address_ bookkeeping :-) Understood. This is not the case with SixXS. Thanks for the insights to those involved. Also thanks for updating the statistics to reflect which inet6nums are being referenced by an IRT object 'up stream'. -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E)
- Previous message (by thread): [db-wg] Abuse-C/IRT
- Next message (by thread): [db-wg] Abuse-C/IRT
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]