[acm-tf] Abuse Contact Information - Policy Proposal

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>)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 307 bytes
Desc: OpenPGP digital signature
URL: <https://www.ripe.net/ripe/mail/archives/acm-tf/attachments/20111006/9dd728a7/attachment.sig>