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/
Operational Contacts
- Previous message (by thread): Operational Contacts
- Next message (by thread): New nsf.db in RIPE database format
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Duncan Rogerson
D.Rogerson at nosc.ja.net
Fri Oct 23 17:59:28 CET 1992
> POC for the network. But if <customer> has problems, and <service_provider> > wants to contact <customer>, the appropriate information can be stored > in the general contact information as well. Pls keep in mind, that this > contact information doesn't supersede the named [at]c's in the objects, > but will provider general contact point if the specific poeple are not What I read from this is that we have to distinguish between the service provider's NOC and the customers own NOC. So we should have operational contact details for both the end site and their service provider ? So, assuming we still go with the NOC object idea, that means a NOC object is created for the service provider, and one for the end site's own NOC. Each network the end site registers then has a pointer to their NOC, and also to their service provider's. Does this make sense, or am I falling asleep already seeing as the weekend is here ? :) I just don't think we gain anything having information spread all over the database, that could be maintained much more easily in one object. Dunc
- Previous message (by thread): Operational Contacts
- Next message (by thread): New nsf.db in RIPE database format
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]