Hello, On 6 May 2004, at 09:25, Ulrich Kiermayr wrote:
Hello,
To put together a Proposal for how a Referece solution could be done .
See comments below.
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.
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. 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". 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. 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. 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 still looking at tactics. More in follow-up. ATB, Niall