[db-wg] Proposal: Abuse-C as a Reference

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