[db-wg] Proposal: Abuse-C as a Reference
- Previous message (by thread): [db-wg] Proposal: Abuse-C as a Reference
- Next message (by thread): [db-wg] Proposal: Abuse-C as a Reference
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ulrich Kiermayr
ulrich.kiermayr at univie.ac.at
Thu May 6 13:28:52 CEST 2004
Hi, >> This abuse-c inherits all the features of irt as well, resulting in >> just one object for this area [Like in tech-c which is also not >> fine-grained like having something for routing, something for >> hardware, for peering, for .....] > > Yes and no. Not where I think we should focus our thinking just now. I am Coming from the 'using a consistent Mindset designing the features' Point of view. If the Design itself is not based on a consistent way of doing things, we cant expect the 'not into the Database' users to be anything else but confused. >> What can be done to have the 'abuse-mailbox' like in Randy/niall's >> proposal would be the Role/Person object: >> >> This would also make it easier to reference existing data, i.e. the >> one Person NOC where the local guru is admin and tech and abuse. > > > Yes; exploit, leverage, take advantage of [...] what we already have. > > IMHO, a new "reference solution" involves excessive effort for both > development > and deployment. Because? > We already have reference attributes: > admin-c => person/role/org > tech-c => person/role/org > mnt-irt => irt > > Adding a new reference attribute requires modification of primary objects > (inet*num, AS-whatever-the -object-is called). If a parallel reference is > already in place, I don't see that this gives us a useful return on effort. > Since all primary objects of interest must already have a tech-c reference, > we should better say "Because" than "If". Ahem. In what respect this situation is different from adding abuse-mailbox to those primary objects? > I thought we had all agreed we should avoid modifying primary objects > except _in extremis_. An optional distinguished attribute allows > the choice (of what to modify) be made by whoever is responsible for > doing the work. I'm very much in favour of co-locating > decision-making with the effort to which the decision gives rise. > Making the _same_ distinguished attribute available in both primary > (inet*num, AS) and secondary (reference-targets: person, role, org, > irt) objects gives the widest scope for maintainers to do what is > _convenient for them_ whilst retaining overall consistency. Hmmm, maybe I am in a minority group, but for me consistency _is_ convinient. > NCC can (and, if I've understood correctly what was said this morning, > will) advise on the development effort needed for whatever we finally agree on. Better even on all the ideas we have, because it might be input to the desicion-making process. > Complementary to that, we (for some value of "we") have to devise a > least-effort, greatest-effect strategy for reaching "there" from > "here". I keep feeling we're stilllooking at tactics. at least I want to make sure that the plan is useful for a certain time (whatever certain means) and reducing the risk of realising halfway through that we have to turn around and start all over again. lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr at univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140
- Previous message (by thread): [db-wg] Proposal: Abuse-C as a Reference
- Next message (by thread): [db-wg] Proposal: Abuse-C as a Reference
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]