[acm-tf] Abuse Contact Information - Policy Proposal

HI Tobias

The technical details I wrote below were in answer to a question from
Wilfried about handling email addresses in hierarchical data. It is
background information. I would not expect you to put any of that in
your proposal.

cheers
denis


On 6/10/11:41 3:48 PM, Tobias Knecht wrote:
> Hi all,
> 
> do we really need to go that deep into technical details while writing
> the proposal?
> 
> Or couldn't we just shorten process by saying, we want for example an
> abuse-c which contains these fields of which these are mandatory and
> these are optional. At the end RIPE NCC could do a presentation and
> bring up the technical idea if at least this is needed.
> 
> Imho this is what we want:
> 
> (mandatory) abuse-c whose content is based on tech-c plus a mandatory
> abuse-mailbox attribute within abuse-c.
> 
> For clean-up we want:
> 
> Depreciate abuse-mailbox attributes in other objects than abuse-c from
> now on. Deletion of all abuse-mailbox references at a specific point in
> time. Changing the name from mnt-irt to irt-c.
> 
> 
> Anything else? Let me know and I try to put this into a text on the
> weekend.
> 
> Thanks,
> 
> Tobias
> 
> 
> 
> 
> 
> 
> Am 30.09.11 13:25, schrieb Denis Walker:
>> HI all
>>
>> What I had in mind for the technical proposal was to preserve the
>> hierarchical and authorisation model from the IRT object for the
>> role-types ABUSE and IRT.
>>
>> So to add a reference to your ABUSE ROLE or IRT ROLE will need
>> authentication. Then you can control who asserts that you will handle
>> these issues for their address space.
>>
>> With the hierarchy, as with the IRT object now, a whois query can search
>> up the hierarchy of INET(6)NUM objects looking for the most specific
>> object that contains the attribute "irt-c:" or "abuse-c:" and can then
>> return the referenced ROLE object.
>>
>> But I would also like to suggest that we don't make this the default
>> query behaviour. As we move forward with new web forms and programmable
>> APIs the basic queries should become more simple. In the past we made a
>> query for an INET(6)NUM object also return IRT objects by default. Then
>> we had to introduce new query flags to negate the new default as many
>> users did not want the extra 'baggage' on a simple query.
>>
>> We have the Abuse Finder that can do all the necessary queries
>> internally to find the information from the hierarchical data. We can
>> also make this functionality available through the query API. We can do
>> the same for IRT data. Then it is easy for users to find this
>> information as a one off with the web forms or use the API to process
>> batches of data. But now users who only want IP address information
>> won't be burdened with all the extra baggage.
>>
>> Some more food for thought.
>>
>> cheers
>> denis
>>
>>
>> On 30/09/11:40 4:01 AM, Suresh Ramasubramanian wrote:
>>> This would be ideal because doing away with it might cause breakage
>>> elsewhere.
>>>
>>> I would suggest abuse contact information for AS contacts, mnt-by etc
>>> contacts too where relevant.
>>>
>>> On Fri, Sep 30, 2011 at 2:49 AM, Wilfried Woeber, UniVie/ACOnet
>>> <Woeber at cc.univie.ac.at <mailto:Woeber at cc.univie.ac.at>> wrote:
>>>
>>>
>>>     For a technical aspect: do we (for hierarchically managed address space)
>>>     intend to preserve the current irt: relevance/coverage and the
>>>     associated
>>>     lookup mechanics for the proposed policy and implementation?
>>>
>>>
>>>
>>>
>>> -- 
>>> Suresh Ramasubramanian (ops.lists at gmail.com <mailto:ops.lists at gmail.com>)
>