[up-front disclaimer: apologies or this loooong reply. Maybe it's of help ]
Following on from the comment bt Shane Kerr
Also, what various contact information means is not clear. What administration does the "admin-c:" do exactly?
It is (was [1]) the point of contact in the organisation holding a resource, who or which is allowed/expected to represent the organisation "administratively"
Only update the RIPE
Maybe, but not necessarily.
Database? Coordinate with the RIPE NCC? Is it the CEO of a company? The manager of the IT department?
Maybe, yes, but it can also be an employee which is put in charge of that responsibility. Depends on the internal organisation. Someone or something _inside_ the organisation.
Or an independent contractor who handles all the details of connectivity?
No, that is the entity which would be listed as the tech-c: There is a good chance that an organisation holds resources (e.g. address space, an AS Number) which always remains the same, while the operational aspects may be tendered on a regular basis, out-sourced to a third party, or taken care of collectively with an/other organisation/s. Hence the concept of a role: to eg. describe a NOC
I have to agree that "what is the responsibility" or perhaps just "the role" of the admin-c and tech-c. From what I have read on RIPE documents the role is not at all clear. I believe it said the admin contact has to be at the same address as the network? So what of unattended sites?
You have to take into account that many parties try to use the DB these days in ways and for purposes for which it was not designed from the beginning. At that point in time there were 2 (3?) goals or objectives: 1 Provide an _authoritative_ registry for internet resources (IP address blocks and AS numbers) which were allocated or assigned (distributed) within the framework of RIPE and the RIPE NCC. There is a formal relatinship in place between the RIPE NCC and the LIRs defining the requirements of collectively maintaining these records. This is the IP- and ASN-Registry inside the RIPE DataBase 2 Provide the means to register Routing Policy for Autonomous Systems. This set of data is - from the point of view of the NCC! - NOT authoritative. In the sense that the NCC is not responsible for completeness and/or correctness of entries. This is the Rouitng Registry inside the RIPE DataBase 3 In support of the IP-Address Registry, and as a convenience for the community in the "early days" of the Internet in Europe, there is a mechanism to register DNS Domain objects in the database. The only (important!) functionality that is left here is keeping track of the ReverseDNS Tree for those address blocks which belong to the IP-Address Registry. All the other domain objects were eventually removed, after going through a lengthy migration and clean-up phase, together with many TLD administrations. At that point in time there was no "Spam", (almost) no attacks or break-ins, a limited library of malware, and so on.
There are many questions, and perhaps there should be some attempt to define more accurately what admin-c and tech-c are meant to be used for.
No problem with that. But this probably has to be taken up in other working groups, like the Addess Policy WG, the Routing WG, etc. The DataBase Gang should only provide the tools to implement their semantics.
As internet usage is becoming more of an issue (spam, child porn, etc) I can't help feeling that there should be some formal "responsibility" associated with an inetnum (like we have a "keeper of a vehicle" in the UK who has some responsibilities).
Yes, I fully agree. The interesting part here is that we'll open _many_ BIG cans of worms if we try to progress that. Every attempt until now has got entangled between the colliding interests of the network operators (technical trouble-shooting), law- and intellectual property-rights-enforcement (child porn, copyright violations, etc.) and the _protection of privacy_ of the users. There is at least one region which has proposed to hide name, address and email data on whois queries, in the interest of privacy protection. I didn't have the time to follow up whether it was implemented. But I agree, we may be very close to the point in time where this has to happen, somewhere...
I suspect to go this far would request some legal framework in countries affected,
You bet. I can tell from some private discussions with people from the EU commission that not even between them they have resolved those conflicting points of views.
but RIPE could at least indicate, say, "The admin contact is intended to take responsibility for the IP addresses" or some such, which would be a good basis.
From my point of view, that is exactly the role of the admin-c _at large_ or at least as a fall-back. However the organisation can "delegate" responsibilty for some aspects to other groups, parties, or contacts. This is done in real life! E.g. - for operational aspects we can list a differenet tech-c. - for database maint. there is the maintainer (and notification) mechanism - for routing there is the set of objects in the routing registry - for hacking, intrusion, DoS, and law/(C) stuff there is the machinery to point/link to the Incident Response Team to be contacted for those cases. [Note, that even in that camp there is'nt full consensus yet on how to document the different contacts for different incident types ;-]
Of course, if there was an abuse-c, then this could be a document explaining the detailed role of admin-c, tech-c, and abuse-c.
I don't have any problem with the concept of an abuse-c:, in whatever colour, shape or texture. the real problem that I (still) have after so many years is that we still lack a definition of "abuse", and which part of an organisation is supposed to deal with the "abuse". Also note that usually there is an aspect of "incoming" and "originated" abuse.
Also, the "trouble" field is a good thought - maybe we should add "trouble" to inetnum, as there is already a field name defined for the purpose essentially. Just an idea.
-- Rev Adrian Kennard Andrews & Arnold Ltd / AAISP www.aaisp.net.uk
Regards, Wilfried (this time wearing my hat as DB-WG Chair :-) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Never attribute to malice what can adequately be explained by incompetence.