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/
Unique NIC/RIPE/xxx-Handles
- Previous message (by thread): Unique NIC/RIPE/xxx-Handles
- Next message (by thread): Unique NIC/RIPE/xxx-Handles
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Wilfried Woeber, UniVie/ACOnet
woeber at cc.univie.ac.at
Fri Jul 23 17:31:00 CEST 1993
Dear DB-folks, during the IETF we (Daniel K, Ruediger V and me) had a short ad-hoc meeting and identified some aspects of the RIPE-DB business that should be addressed and discussed. One of them, and quite urgently needed is to agree on structure and procedures to obtain unique handles for people who do not (yet) have NIC handles. One of the ideas we talked about was to go to a structure like NIC-XY999 (derived from the current NIC-Handles by prepending NIC-) RIPE-XY999 (newly assigned within the RIPE community) Reudiger even thought about adding even more structure like RIPE-Provider_ID-XY999, or RIPE-XY999-Provider_specific... The issue here is whether we want to have the Provider_ID as part of the hierarchy tree. My personal preference is the RIPE-XY999[-optional-Provider_specific...] format, the handle being unique without the Provider part. Another question is where and how to register/assign these handles. One possibility could be to have this as a service from and at the NCC, say assigned by some script. A Different approach would be to assign them somehow at the Local-IRs. Could you please comment on these? I'd like to have some form of consensus ready for approval at the next RIPE meeting. Best regards, Wilfried.
- Previous message (by thread): Unique NIC/RIPE/xxx-Handles
- Next message (by thread): Unique NIC/RIPE/xxx-Handles
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]