[acm-tf] Abuse Contact Information - Policy Proposal

Hi Tobias

Just thinking about this again, you may want to make a reference to this
principle (without going deeply into the implementation details) in the
proposal with a comment something like this:

"The "abuse-c:" reference to an abuse handler should make use of the
hierarchical nature of the resource data to minimise the workload on
resource holders and facilitate good database design."

This would summarise what I said in more detail below.

cheers
denis


On 10/10/11:42 3:27 PM, Denis Walker wrote:
> 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>)
>>
> 
>