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@univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140