[anti-abuse-wg] [db-wg] Options for extending "abuse-c:"

Hi Denis,

On 05/12/2014 05:32 PM, Denis Walker wrote:

> Sorry, another long email. Maybe at some point we have to accept that
> email discussions are not going to resolve this matter :)

I'd have loved to be in Warsaw and bug you directly :) Thanks for
enlighten me, and from your answer I think we are not in wild disagreement.

> To take your last point first - "All in all, fragmenting the syntax of
> objects depending on their intented use seems a too high cost for the
> presented benefits...". We have already done this in a way, which is why
> we are having this whole discussion. The ROLE and ORGANISATION objects
> had an intended use. But no business rules were added to the software to
> enforce the use and there were not even any best common practise rules
> documented. 10+ years down the line and most people have forgotten why
> these objects are there. Now we are trying to build a case to 'do things
> right' and it's seen as too much hassle.

So your wish is to take the current abuse-c implementation as a model
for other contacts, is that correct? I would see merit in that - but I'm
still not wild about the fragmentation: either it is the way forward,
then it should have been said so, and be brought explicitly before the
DB-WG. Before the implementation. Because if it is not (or there is too
much resistance against applying the model to other contacts) then
you're stuck with the two kinds of contacts: to me as a user of the
database (reader or writer) as well as part time DBA that is hugely
annoying.

Supposing I did not misread your intentions, and the abuse-c model is
the right:

> As I understand it, the subnet case is not a large usage requirement, so
> scaling is not an issue. The same syntax is used by "mnt-routes:" so
> there is a precedent for the syntax and we already have the software to
> parse it.

Ok, I didn't know about mnt-routes, and I agree that the subnet case
_should_ be limited. However, it needs to scale if applied to admin-c
and tech-c's, at least much more than for the abuse-c. Maybe the
proposal is enough - you have better data on that than I do - but in any
case we should end up with the same for all contacts. And keep the
necessary flexibility to allow database user to represent their reality.

For example, the possible copyright-abuse-mailbox you are about to
present (I had a peak at the slides): great idea. But in our case (the
'subnet case') that would be a company wide contact, whereas the 'real'
abuse-c is network specific. We are small enough that it does not really
matter (i.e. I'd duplicate the data and be done with it) - but the use
case for flexibility exists.

[...]
> To finally sum up this point for now - we can build and
> provide you with many tools to help you with address management
> information that don't have to work with RPSL format data (but can do).

In my particular case we can live with about anything: not many objects,
infrequent updates. But even then I'd really love coherence in the DB
structure and logic.

> Although it has been forgotten after 10+ years the basic database model
> is  - an organisation is the core of your data. That organisation has
> human resources and Internet resources. The human resources are grouped
> into roles and these roles manage the Internet resources. That is it in
> a nutshell. It sounds simple, but so many layers have been built on and
> around these principles, that the original principles have been
> partially lost.

Sounds like interesting times ahead :) What's wrong with trying to get
back there?

> That core organisation is anyone/thing that manages (some aspect of) an
> Internet resource. If it is an outsourced 24/7 team, an abuse handler or
> an End User doing their own routing. There should be an ORGANISATION
> object to identify them. Everything else hangs off that object.

As not all aspects of an organisation are alike (subnet case), and
duplicating organisations is a mess (and even impossible in cases like
anycast assignments) sub-organisations or departments would be an way to
solve this, within the basic database model?

> For example, if an End User manages the routing for their resource, who
> do you want to contact if their is a routing problem? The End User who
> manages the routing or their LIR who assigned the resource? How are you
> going to contact that End User? From the MNTNER in the "mnt-routes:" of
> the assignment? Which email address should you use from the MNTNER or
> referenced PERSON objects? 

I'd always follow basic logic: the most specific contact adapted to my
request. In this case: the tech-c related to the internet resource or
it's closest parent, because that seems obvious without reading the
database documentation. Any other address only in case of no-reaction /
despair - and then all bets are off anyway.

> Or maybe the ROUTE object where all contact
> information is optional. Following the basic principles there should be
> an ORGANISATION object for the End User with clearly defined contact
> details. It makes sense to follow the basic design. It does not make
> sense to take short cuts and break the basic model.

I completely agree. On the other hand, and that might be personal
preference, about the only thing I'd value above the database model is
coherence in the entries. If only because it is easier to migrate a
coherent mess than half a mess :)

>>
>> Actually, the proposed solution for the "subnet-issue" is very appealing
>> to do the "end-user issue" wrong: what would prevent a LIR to put an
>> abuse-c per end-user assignment in it's org-object? It would probably be
>> easier than to create the organisation objects...
> 
> Yes it would be easier, but wrong. Some things can be managed by
> software business rules, other things need to rely on members following
> the rules.

My point exactly. And I'll always value flexibility about over-tight
rules. If life has taught me anything it's that if the 'wrong' way is
too easy compared to the 'right' (and doesn't come with serious
inconvenience) it will be used. Sometimes only by ignorance. But that's
not something I have to tell the RIPE NCC database team :)

cheers,
Gilles

-- 
Fondation RESTENA - DNS-LU
6, rue Coudenhove-Kalergi
L-1359 Luxembourg
tel: (+352) 424409
fax: (+352) 422473