From athina.fragkouli at ripe.net Mon Oct 3 13:51:37 2011 From: athina.fragkouli at ripe.net (Athina Fragkouli) Date: Mon, 03 Oct 2011 13:51:37 +0200 Subject: [acm-tf] acm task force meeting draft minutes Message-ID: <4E89A1C9.3020807@ripe.net> Hello all, Please find attached the draft minutes from our meeting in September. If you have any questions, please let me know. Thank you. Kind regards, Athina Fragkouli RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: ACM TF meeting September 2011 DRAFT minutes.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 15865 bytes Desc: not available URL: From tk at abusix.com Thu Oct 6 15:48:17 2011 From: tk at abusix.com (Tobias Knecht) Date: Thu, 06 Oct 2011 15:48:17 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E85A738.20402@ripe.net> References: <4E79B21F.2080807@abusix.com> <4E84E0F2.3040206@CC.UniVie.ac.at> <4E85A738.20402@ripe.net> Message-ID: <4E8DB1A1.7000907@abusix.com> 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 >> > 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 ) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From vesely at tana.it Thu Oct 6 19:03:08 2011 From: vesely at tana.it (Alessandro Vesely) Date: Thu, 06 Oct 2011 19:03:08 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E8DB1A1.7000907@abusix.com> References: <4E79B21F.2080807@abusix.com> <4E84E0F2.3040206@CC.UniVie.ac.at> <4E85A738.20402@ripe.net> <4E8DB1A1.7000907@abusix.com> Message-ID: <4E8DDF4C.1000800@tana.it> On 06/Oct/11 15:48, Tobias Knecht wrote: > > do we really need to go that deep into technical details while writing > the proposal? I think RIPE NCC ought to choose the implementation, but we should be quite clear about what we want. Specifically, the proposal has to bring enough insight to show what's wrong with the abuse-mailbox. I mean, if we pretend for a minute that abuse-mailbox were not there, what part of the proposal says that such solution would not meet our requirements? > For clean-up we want: > > Deprecate 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. From denis at ripe.net Mon Oct 10 15:27:09 2011 From: denis at ripe.net (Denis Walker) Date: Mon, 10 Oct 2011 15:27:09 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E8DB1A1.7000907@abusix.com> References: <4E79B21F.2080807@abusix.com> <4E84E0F2.3040206@CC.UniVie.ac.at> <4E85A738.20402@ripe.net> <4E8DB1A1.7000907@abusix.com> Message-ID: <4E92F2AD.2000601@ripe.net> 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 >>> > 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 ) > From denis at ripe.net Mon Oct 10 15:40:16 2011 From: denis at ripe.net (Denis Walker) Date: Mon, 10 Oct 2011 15:40:16 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E92F2AD.2000601@ripe.net> References: <4E79B21F.2080807@abusix.com> <4E84E0F2.3040206@CC.UniVie.ac.at> <4E85A738.20402@ripe.net> <4E8DB1A1.7000907@abusix.com> <4E92F2AD.2000601@ripe.net> Message-ID: <4E92F5C0.80203@ripe.net> 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 >>>> > 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 ) >> > > From ale at tana.it Mon Oct 10 16:24:25 2011 From: ale at tana.it (ale at tana.it) Date: Mon, 10 Oct 2011 16:24:25 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E92F5C0.80203@ripe.net> References: <4E79B21F.2080807@abusix.com> <4E84E0F2.3040206@CC.UniVie.ac.at> <4E85A738.20402@ripe.net> <4E8DB1A1.7000907@abusix.com> <4E92F2AD.2000601@ripe.net> <4E92F5C0.80203@ripe.net> Message-ID: <4E930019.8040407@tana.it> On 10/Oct/11 15:40, Denis Walker wrote: > "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." +1, the above paragraph works for me (assuming abuse-mailbox does not satisfy that criterion.) Do we expect that some end-users will apply for overriding an abuse-c with the data of their own abuse-teams? From denis at ripe.net Mon Oct 10 16:50:48 2011 From: denis at ripe.net (Denis Walker) Date: Mon, 10 Oct 2011 16:50:48 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E930019.8040407@tana.it> References: <4E79B21F.2080807@abusix.com> <4E84E0F2.3040206@CC.UniVie.ac.at> <4E85A738.20402@ripe.net> <4E8DB1A1.7000907@abusix.com> <4E92F2AD.2000601@ripe.net> <4E92F5C0.80203@ripe.net> <4E930019.8040407@tana.it> Message-ID: <4E930648.5050902@ripe.net> On 10/10/11:42 4:24 PM, ale at tana.it wrote: > On 10/Oct/11 15:40, Denis Walker wrote: >> "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." > > +1, the above paragraph works for me (assuming abuse-mailbox does not > satisfy that criterion.) > > Do we expect that some end-users will apply for overriding an abuse-c > with the data of their own abuse-teams? > > Just to be clear on what this means. The technical suggestion is for the "abuse-c:" attribute to reference a ROLE object with a "role-type:" set to abuse. In this ROLE object there will be an "abuse-mailbox:" attribute. Because of the hierarchical nature, if an end user has their own abuse team, they can reference their own abuse type ROLE object with an "abuse-c:" in the INETNUM object for their assignment. This will override the LIRs abuse team reference only for this one assignment. cheers denis From vesely at tana.it Mon Oct 10 19:12:04 2011 From: vesely at tana.it (Alessandro Vesely) Date: Mon, 10 Oct 2011 19:12:04 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E930648.5050902@ripe.net> References: <4E79B21F.2080807@abusix.com> <4E84E0F2.3040206@CC.UniVie.ac.at> <4E85A738.20402@ripe.net> <4E8DB1A1.7000907@abusix.com> <4E92F2AD.2000601@ripe.net> <4E92F5C0.80203@ripe.net> <4E930019.8040407@tana.it> <4E930648.5050902@ripe.net> Message-ID: <4E932764.6080501@tana.it> On 10/Oct/11 16:50, Denis Walker wrote: > On 10/10/11:42 4:24 PM, ale at tana.it wrote: (oops, sorry I picked up the wrong From:) >> On 10/Oct/11 15:40, Denis Walker wrote: >>> "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." >> >> +1, the above paragraph works for me (assuming abuse-mailbox does not >> satisfy that criterion.) >> >> Do we expect that some end-users will apply for overriding an abuse-c >> with the data of their own abuse-teams? > > Just to be clear on what this means. The technical suggestion is for the > "abuse-c:" attribute to reference a ROLE object with a "role-type:" set > to abuse. In this ROLE object there will be an "abuse-mailbox:" attribute. Yeah, it sounds tricky. Right now one can set abuse-mailbox in a number of objects. We want to add yet another role object for abuse contacts. I have two questions: 1. How does it reduce the workload on resource holder? 2. Is there a plan to change the intended use of the abuse-mailbox attribute at some point in time after the introduction of abuse-c? > Because of the hierarchical nature, if an end user has their own abuse > team, they can reference their own abuse type ROLE object with an > "abuse-c:" in the INETNUM object for their assignment. This will > override the LIRs abuse team reference only for this one assignment. Fine, I'd propose to add some text similar to the last quoted paragraph as well. I say /similar/ because of the LIR; do you actually mean the mntner? From denis at ripe.net Tue Oct 11 17:44:39 2011 From: denis at ripe.net (Denis Walker) Date: Tue, 11 Oct 2011 17:44:39 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E932764.6080501@tana.it> References: <4E79B21F.2080807@abusix.com> <4E84E0F2.3040206@CC.UniVie.ac.at> <4E85A738.20402@ripe.net> <4E8DB1A1.7000907@abusix.com> <4E92F2AD.2000601@ripe.net> <4E92F5C0.80203@ripe.net> <4E930019.8040407@tana.it> <4E930648.5050902@ripe.net> <4E932764.6080501@tana.it> Message-ID: <4E946467.4020100@ripe.net> HI Alessandro As far as I understand the proposal you are considering is to add the "abuse-mailbox:" attribute to the ROLE object, along with a new attribute "role-type:". Business rules in the software will make sure that "abuse-mailbox:" must be added to any ROLE object used for abuse handling and referenced by an "abuse-c:" attribute. Then as a follow up, after this policy implementation has been deployed, there will be a clean up phase where all "abuse-mailbox:" attributes in other object types will be migrated/merged/deleted. The syntax of the other object types can then be changed to deprecate this attribute from anywhere other than the ROLE object. So in the end you only have the "abuse-mailbox:" attribute in one place. With the attribute in only one place and implemented using the hierarchical nature of the resources, the workload on resource holders will be kept to a minimum. In my previous email you can replace 'LIR' with 'holder of a less specific resource'. regards denis On 10/10/11:42 7:12 PM, Alessandro Vesely wrote: > On 10/Oct/11 16:50, Denis Walker wrote: > >> On 10/10/11:42 4:24 PM, ale at tana.it wrote: > (oops, sorry I picked up the wrong From:) > >>> On 10/Oct/11 15:40, Denis Walker wrote: >>>> "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." >>> >>> +1, the above paragraph works for me (assuming abuse-mailbox does not >>> satisfy that criterion.) >>> >>> Do we expect that some end-users will apply for overriding an abuse-c >>> with the data of their own abuse-teams? >> >> Just to be clear on what this means. The technical suggestion is for the >> "abuse-c:" attribute to reference a ROLE object with a "role-type:" set >> to abuse. In this ROLE object there will be an "abuse-mailbox:" attribute. > > Yeah, it sounds tricky. Right now one can set abuse-mailbox in a > number of objects. We want to add yet another role object for abuse > contacts. I have two questions: > > 1. How does it reduce the workload on resource holder? > > 2. Is there a plan to change the intended use of the abuse-mailbox > attribute at some point in time after the introduction of abuse-c? > >> Because of the hierarchical nature, if an end user has their own abuse >> team, they can reference their own abuse type ROLE object with an >> "abuse-c:" in the INETNUM object for their assignment. This will >> override the LIRs abuse team reference only for this one assignment. > > Fine, I'd propose to add some text similar to the last quoted > paragraph as well. I say /similar/ because of the LIR; do you > actually mean the mntner? > > > From vesely at tana.it Tue Oct 11 20:23:15 2011 From: vesely at tana.it (Alessandro Vesely) Date: Tue, 11 Oct 2011 20:23:15 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E946467.4020100@ripe.net> References: <4E79B21F.2080807@abusix.com> <4E84E0F2.3040206@CC.UniVie.ac.at> <4E85A738.20402@ripe.net> <4E8DB1A1.7000907@abusix.com> <4E92F2AD.2000601@ripe.net> <4E92F5C0.80203@ripe.net> <4E930019.8040407@tana.it> <4E930648.5050902@ripe.net> <4E932764.6080501@tana.it> <4E946467.4020100@ripe.net> Message-ID: <4E948993.6020607@tana.it> Hi, On 11/Oct/11 17:44, Denis Walker wrote: > As far as I understand the proposal you are considering is to add the > "abuse-mailbox:" attribute to the ROLE object, along with a new > attribute "role-type:". Business rules in the software will make sure > that "abuse-mailbox:" must be added to any ROLE object used for abuse > handling and referenced by an "abuse-c:" attribute. Yep, that's what you and Tobias suggested in May, and we've agreed upon, as far as I can understand. > Then as a follow up, after this policy implementation has been deployed, > there will be a clean up phase where all "abuse-mailbox:" attributes in > other object types will be migrated/merged/deleted. The syntax of the > other object types can then be changed to deprecate this attribute from > anywhere other than the ROLE object. So in the end you only have the > "abuse-mailbox:" attribute in one place. Right, I vaguely remembered this idea too. I would choose a new attribute. Say "role-mailbox", "report-mailbox", "abuse-reports-to", or anything to that meaning. It is only a name, but it might prevent someone from wondering whether "abuse of the abuse-c" is what is being meant there. > With the attribute in only one place and implemented using the > hierarchical nature of the resources, the workload on resource holders > will be kept to a minimum. It seems that we could have obtained something quite similar, in terms of workload on resource holders, by mandating an abuse-mailbox on the mntner and then having the abuse-finder deliver that address as a last resort. Instead we consider changing the DB structure. IMHO, we should justify our choice. I'd reword it like so: The "abuse-c:" reference to an abuse handler should make use of the hierarchical nature of the resource data so as to facilitate good database design, and to be consistent with how generic Internet users perceive service provider's duty[*], while keeping a minimal workload on resource holders. [*] Do they? I have no specific data to support this point. We should word this better... > In my previous email you can replace 'LIR' with 'holder of a less > specific resource'. This yields Because of the hierarchical nature, if an end user has their own abuse team, they can reference their own abuse type ROLE object with an "abuse-c:" in the INETNUM object for their assignment. This will override the holder of a less specific resource abuse team reference only for this one assignment. This seems to be a good explanation, doesn't it? From brian.nisbet at heanet.ie Thu Oct 13 14:21:52 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Thu, 13 Oct 2011 13:21:52 +0100 Subject: [acm-tf] RIPE 63 Task Force Meeting Message-ID: <4E96D7E0.3010803@heanet.ie> Colleagues, As we discussed at the last phone conference we would like to schedule a meeting at RIPE 63. The current best suggestion is to start at 10:00 on Monday 31st October in a room that the NCC will source for us. We've timetabled two hours for this meeting, but hopefully it won't need all of that. I would encourage everyone to read Tobias' proposal and to comment (and I realise I've been very remiss in this myself), in order that we may be able to circulate it to the community shortly before, or perhaps even during, the meeting. Thanks, Brian. From pk at DENIC.DE Thu Oct 13 15:58:22 2011 From: pk at DENIC.DE (Peter Koch) Date: Thu, 13 Oct 2011 15:58:22 +0200 Subject: [acm-tf] RIPE 63 Task Force Meeting In-Reply-To: <4E96D7E0.3010803@heanet.ie> References: <4E96D7E0.3010803@heanet.ie> Message-ID: <20111013135822.GR28724@x27.adm.denic.de> Brian, > As we discussed at the last phone conference we would like to schedule a > meeting at RIPE 63. The current best suggestion is to start at 10:00 on > Monday 31st October in a room that the NCC will source for us. We've thanks, I'll attend. However, given that the tutorials start at 0900 and we're aiming at 2 hrs, could we sync the end to 1230 and thus begin at 1030 instead? Unless somebody recommends beginnenbg _and_ end of the RPKI tutroial instead of a prolonged start ... Thanks, Peter From brian.nisbet at heanet.ie Thu Oct 13 19:08:52 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Thu, 13 Oct 2011 18:08:52 +0100 Subject: [acm-tf] RIPE 63 Task Force Meeting In-Reply-To: <20111013135822.GR28724@x27.adm.denic.de> References: <4E96D7E0.3010803@heanet.ie> <20111013135822.GR28724@x27.adm.denic.de> Message-ID: <4E971B24.7010404@heanet.ie> On 13/10/2011 14:58, Peter Koch wrote: > Brian, > >> As we discussed at the last phone conference we would like to schedule a >> meeting at RIPE 63. The current best suggestion is to start at 10:00 on >> Monday 31st October in a room that the NCC will source for us. We've > > thanks, I'll attend. However, given that the tutorials start at 0900 > and we're aiming at 2 hrs, could we sync the end to 1230 and thus > begin at 1030 instead? Unless somebody recommends beginnenbg _and_ > end of the RPKI tutroial instead of a prolonged start ... If nobody has an objections to this, and I certainly don't, I'm perfectly happy with scheduling a 10:30 CET start. Brian. From vesely at tana.it Thu Oct 13 20:37:44 2011 From: vesely at tana.it (Alessandro Vesely) Date: Thu, 13 Oct 2011 20:37:44 +0200 Subject: [acm-tf] RIPE 63 Task Force Meeting In-Reply-To: <4E971B24.7010404@heanet.ie> References: <4E96D7E0.3010803@heanet.ie> <20111013135822.GR28724@x27.adm.denic.de> <4E971B24.7010404@heanet.ie> Message-ID: <4E972FF8.3080200@tana.it> On 13/Oct/11 19:08, Brian Nisbet wrote: > On 13/10/2011 14:58, Peter Koch wrote: >> >> thanks, I'll attend. However, given that the tutorials start at 0900 >> and we're aiming at 2 hrs, could we sync the end to 1230 and thus >> begin at 1030 instead? Unless somebody recommends beginnenbg _and_ >> end of the RPKI tutroial instead of a prolonged start ... > > If nobody has an objections to this, and I certainly don't, I'm > perfectly happy with scheduling a 10:30 CET start. Athina's minutes report that Ideally the proposal should be published to the community before RIPE 63, so that the discussion-phase of the proposal coincides with the RIPE meeting. It seems we have a couple of weeks to publish our proposal. In case we can do so, it may be more interesting to have our meeting /after/ the anti-abuse meeting, which is on Tuesday evening, in order to decide how to proceed based on their comments. In case we miss that, it'd be better to arrange so that our Monday meeting may continue until the proposal is finally published :-) From brian.nisbet at heanet.ie Fri Oct 14 10:33:11 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Fri, 14 Oct 2011 09:33:11 +0100 Subject: [acm-tf] RIPE 63 Task Force Meeting In-Reply-To: <4E972FF8.3080200@tana.it> References: <4E96D7E0.3010803@heanet.ie> <20111013135822.GR28724@x27.adm.denic.de> <4E971B24.7010404@heanet.ie> <4E972FF8.3080200@tana.it> Message-ID: <4E97F3C7.90508@heanet.ie> "Alessandro Vesely" wrote the following on 13/10/2011 19:37: > On 13/Oct/11 19:08, Brian Nisbet wrote: >> On 13/10/2011 14:58, Peter Koch wrote: >>> >>> thanks, I'll attend. However, given that the tutorials start at 0900 >>> and we're aiming at 2 hrs, could we sync the end to 1230 and thus >>> begin at 1030 instead? Unless somebody recommends beginnenbg _and_ >>> end of the RPKI tutroial instead of a prolonged start ... >> >> If nobody has an objections to this, and I certainly don't, I'm >> perfectly happy with scheduling a 10:30 CET start. > > Athina's minutes report that > > Ideally the proposal should be published to the community before > RIPE 63, so that the discussion-phase of the proposal coincides > with the RIPE meeting. > > It seems we have a couple of weeks to publish our proposal. In case > we can do so, it may be more interesting to have our meeting /after/ > the anti-abuse meeting, which is on Tuesday evening, in order to > decide how to proceed based on their comments. Yes, but time begins to get very tight at that point. I would like to aim for Monday, see what is said on Tuesday and during the week and if necessary, which it may well be, organise a conference call for soon after the meeting. > In case we miss that, it'd be better to arrange so that our Monday > meeting may continue until the proposal is finally published :-) I sincerely believe that if we're talking about this for more than about two hours, we aren't making any progress. Brian. From vesely at tana.it Fri Oct 14 15:57:01 2011 From: vesely at tana.it (Alessandro Vesely) Date: Fri, 14 Oct 2011 15:57:01 +0200 Subject: [acm-tf] RIPE 63 Task Force Meeting In-Reply-To: <4E97F3C7.90508@heanet.ie> References: <4E96D7E0.3010803@heanet.ie> <20111013135822.GR28724@x27.adm.denic.de> <4E971B24.7010404@heanet.ie> <4E972FF8.3080200@tana.it> <4E97F3C7.90508@heanet.ie> Message-ID: <4E983FAD.40801@tana.it> On 14/Oct/11 10:33, Brian Nisbet wrote: > "Alessandro Vesely" wrote the following on 13/10/2011 19:37: >> It seems we have a couple of weeks to publish our proposal. In case >> we can do so, it may be more interesting to have our meeting /after/ >> the anti-abuse meeting, which is on Tuesday evening, in order to >> decide how to proceed based on their comments. > > Yes, but time begins to get very tight at that point. Isn't the proposal very nearly complete? Tobias, can you post the whole doc as-is, according to your perception of the TF's desiderata? The only point that is not clear to me --because I ignore prior history-- is the nature of the "varying expectations" that different communities seem to have developed, according to the background given in https://www.ripe.net/ripe/groups/tf/abuse-contact , which I'd like to be mentioned in the proposal. > I would like to aim for Monday, see what is said on Tuesday and > during the week and if necessary, which it may well be, organise a > conference call for soon after the meeting. > I sincerely believe that if we're talking about this for more than > about two hours, we aren't making any progress. Yes, as you say we don't actually "work" at a meeting. Don't know why. How about two 1-hour meetings instead? (With either a short or a long break in between.) From pk at DENIC.DE Fri Oct 14 16:57:14 2011 From: pk at DENIC.DE (Peter Koch) Date: Fri, 14 Oct 2011 16:57:14 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E79B21F.2080807@abusix.com> References: <4E79B21F.2080807@abusix.com> Message-ID: <20111014145714.GB28724@x27.adm.denic.de> Tobias, all, > I suggest going through a typical policy text step by step and as warm > up starting with the "Summary of Proposal", the "Summary of a current > problem" and the situation on other RIRs. i think this was a good wake-up call, but not the ideal way to get to a deliverable text. > Currently within the RIPE region, the biggest problem for network > operators is to know the best place to publish abuse contact information > (irt, "abuse-mailbox:", "remark-fields:", and in addition to that, in > which object they should publish them?). On the other hand abuse > reporting parties having a huge problem with finding a correct abuse > contact in the variety of possibilities. I disagree with this part of the problem statement, at least i consider it vastly exaggerated. A (non-representative) poll among a large number of German (speaking) CSIRTs did not confirm that they felt any problems making them selves known as "in charge" for their constituency. We need to frame the different target audiences to justify the proposal and gain support (and, actually, to design it well in the first place). With that, we need to differentiate between the means of the DB itself, which is DB objects, attributes, and rules and methods for links between these as well as ways to frame queries and deliver responses. > This proposal will help to stop uncontrolled growth and solves the above > mentioned problems. ... and we should refrain from too ambitious promises. -Peter From pk at DENIC.DE Fri Oct 14 17:20:15 2011 From: pk at DENIC.DE (Peter Koch) Date: Fri, 14 Oct 2011 17:20:15 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E930648.5050902@ripe.net> References: <4E79B21F.2080807@abusix.com> <4E84E0F2.3040206@CC.UniVie.ac.at> <4E85A738.20402@ripe.net> <4E8DB1A1.7000907@abusix.com> <4E92F2AD.2000601@ripe.net> <4E92F5C0.80203@ripe.net> <4E930019.8040407@tana.it> <4E930648.5050902@ripe.net> Message-ID: <20111014152015.GC28724@x27.adm.denic.de> Denis, all, On Mon, Oct 10, 2011 at 04:50:48PM +0200, Denis Walker wrote: > On 10/10/11:42 4:24 PM, ale at tana.it wrote: > > On 10/Oct/11 15:40, Denis Walker wrote: > >> "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." > > > > +1, the above paragraph works for me (assuming abuse-mailbox does not > > satisfy that criterion.) I'm not sure who or what this principle would apply to: 1) the proposal in general (motherhood and apple pie ...) 2) the maintainer when selecting the traget for abuse-c 3) the query strategy within the DB interface (assuming there are objects inthe hierarchy with "abuse-c" and such without > Just to be clear on what this means. The technical suggestion is for the > "abuse-c:" attribute to reference a ROLE object with a "role-type:" set > to abuse. In this ROLE object there will be an "abuse-mailbox:" attribute. The per-object attribute "abuse-mailbox" was, IMHO, a design violation and therefore I support a per-object attribute "abuse-c" (where appropriate) with a limk/handle to a role object. Consolidation and migration strategy to be defined. Making the "abuse-c" mandatory does still not sound convincing to me. For that "role" like object (somewhere between tech-c/role/irt) the details need to be hashed out, but i'm struggling with the attribute "abuse-mailbox" for two reasons: 1) it carries legacy; 2) it is inconsistent with other objects: we say email: in both tech-c and admin-c kind of objects and do not say tech-mailbox or admin-mailbox; If we want to differentiate between plain text/prose (email:) and ARF like reporting, then let's define a second attribute, e.g., "automated-report" or the likes. > Because of the hierarchical nature, if an end user has their own abuse > team, they can reference their own abuse type ROLE object with an > "abuse-c:" in the INETNUM object for their assignment. This will > override the LIRs abuse team reference only for this one assignment. IRT objects used to be subject to a TI based oversight, but my understanding is we want these abuse-role objects to be freely creatable. Creating a reference to an abuse-role will need authorization (either by maintainer or otherwise). The question of a 'bottom up' or 'top down' search for the abuse-role reference is one of the presentation system, not necessarily inherent to the DB, unless the DB ought to support search advice. More precisely, is there a point in enabling, say, the ISP to add their abuse-object to responses where a customer provided their own. I think there are pros and cons in both directions. -Peter From denis at ripe.net Fri Oct 14 18:12:08 2011 From: denis at ripe.net (Denis Walker) Date: Fri, 14 Oct 2011 18:12:08 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <20111014152015.GC28724@x27.adm.denic.de> References: <4E79B21F.2080807@abusix.com> <4E84E0F2.3040206@CC.UniVie.ac.at> <4E85A738.20402@ripe.net> <4E8DB1A1.7000907@abusix.com> <4E92F2AD.2000601@ripe.net> <4E92F5C0.80203@ripe.net> <4E930019.8040407@tana.it> <4E930648.5050902@ripe.net> <20111014152015.GC28724@x27.adm.denic.de> Message-ID: <4E985F58.3040006@ripe.net> Hi Peter My responses are inline below. cheers denis On 14/10/11:42 5:20 PM, Peter Koch wrote: > Denis, all, > > On Mon, Oct 10, 2011 at 04:50:48PM +0200, Denis Walker wrote: > >> On 10/10/11:42 4:24 PM, ale at tana.it wrote: >>> On 10/Oct/11 15:40, Denis Walker wrote: >>>> "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." >>> >>> +1, the above paragraph works for me (assuming abuse-mailbox does not >>> satisfy that criterion.) > > I'm not sure who or what this principle would apply to: > > 1) the proposal in general (motherhood and apple pie ...) > 2) the maintainer when selecting the traget for abuse-c > 3) the query strategy within the DB interface (assuming there are > objects inthe hierarchy with "abuse-c" and such without My reasoning for suggesting something along these lines was to avoid the situation in APNIC where they added a reference to every INET(6)NUM object. This resulted in millions of repeated, redundant references. That is a bad design from every angle. So my point was that if the policy is going to include any details of design or implementation it is better to promote good design than bad design. You may decide to keep the policy to outlining the principles of what you want and not touch at all on design. Then after the policy is approved, the RIPE NCC can propose a detailed design to the TF for final consideration before we implement anything. > >> Just to be clear on what this means. The technical suggestion is for the >> "abuse-c:" attribute to reference a ROLE object with a "role-type:" set >> to abuse. In this ROLE object there will be an "abuse-mailbox:" attribute. > > The per-object attribute "abuse-mailbox" was, IMHO, a design violation and therefore > I support a per-object attribute "abuse-c" (where appropriate) with a link/handle > to a role object. Consolidation and migration strategy to be defined. > > Making the "abuse-c" mandatory does still not sound convincing to me. > For that "role" like object (somewhere between tech-c/role/irt) the details need > to be hashed out, but i'm struggling with the attribute "abuse-mailbox" > for two reasons: 1) it carries legacy; 2) it is inconsistent with other > objects: we say email: in both tech-c and admin-c kind of objects and > do not say tech-mailbox or admin-mailbox; As the new usage is similar but not identical to the current "abuse-mailbox:" a new name may well help with clarity in explaining the new design. Mandatory or not is completely outside the technical scope so I will keep out of that discussion. It is just a matter of defining appropriate business rules when you decide what you want. > > If we want to differentiate between plain text/prose (email:) and ARF like reporting, > then let's define a second attribute, e.g., "automated-report" or the likes. > >> Because of the hierarchical nature, if an end user has their own abuse >> team, they can reference their own abuse type ROLE object with an >> "abuse-c:" in the INETNUM object for their assignment. This will >> override the LIRs abuse team reference only for this one assignment. > > IRT objects used to be subject to a TI based oversight, but my understanding is > we want these abuse-role objects to be freely creatable. > > Creating a reference to an abuse-role will need authorization (either by maintainer or > otherwise). One of the benefits of implementing this "role-type:" is that it is extendible beyond just abuse handling. You can define whatever role you need, abuse handling, csirt team, customer support, billing, sales, etc. To define any new role, say abuse handling, you add a new type 'abuse'. Optionally define a new "xxx-c:" attribute and which objects can include it. Then define a set of business rules to apply to this role. So if you want an 'abuse' type role to be creatable by anyone, only referenced by an "abuse-c:" in certain objects, requiring authorisation to add a reference and searchable by some hierarchical way we can define the business and syntax rules to do that. If you then want an 'irt' or 'csirt' type role that requires authorisation to create and reference, only referenced by a "csirt-c" in certain objects, etc we can define the business and syntax rules to do that. > > The question of a 'bottom up' or 'top down' search for the abuse-role reference > is one of the presentation system, not necessarily inherent to the DB, unless the > DB ought to support search advice. More precisely, is there a point in enabling, > say, the ISP to add their abuse-object to responses where a customer provided their > own. I think there are pros and cons in both directions. Again with this role type model all this is just a matter of defining the business rules. If the policy defines the responsibilities, we can write the business logic to return the available data. > > -Peter > > From vesely at tana.it Fri Oct 14 18:55:44 2011 From: vesely at tana.it (Alessandro Vesely) Date: Fri, 14 Oct 2011 18:55:44 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <20111014152015.GC28724@x27.adm.denic.de> References: <4E79B21F.2080807@abusix.com> <4E84E0F2.3040206@CC.UniVie.ac.at> <4E85A738.20402@ripe.net> <4E8DB1A1.7000907@abusix.com> <4E92F2AD.2000601@ripe.net> <4E92F5C0.80203@ripe.net> <4E930019.8040407@tana.it> <4E930648.5050902@ripe.net> <20111014152015.GC28724@x27.adm.denic.de> Message-ID: <4E986990.1080906@tana.it> On 14/Oct/11 17:20, Peter Koch wrote: > > Making the "abuse-c" mandatory does still not sound convincing to me. > For that "role" like object (somewhere between tech-c/role/irt) the details need > to be hashed out, but i'm struggling with the attribute "abuse-mailbox" > for two reasons: 1) it carries legacy; 2) it is inconsistent with other > objects: we say email: in both tech-c and admin-c kind of objects and > do not say tech-mailbox or admin-mailbox; > > If we want to differentiate between plain text/prose (email:) and ARF like reporting, > then let's define a second attribute, e.g., "automated-report" or the likes. Yes, I proposed similar names ("role-mailbox", "report-mailbox", "abuse-reports-to", on 11 Oct, but cannot find it in the archives...) We obviously cannot mandate what format complainants will use. Suggesting best practices is also beyond our scope. Most likely, we cannot even mention what minimal processing should received complaints undergo. At any rate, when a LIR has set its abuse-c, its customers will inherit it and thus satisfy any mandate that we might have imposed. Hence, making the "abuse-c" mandatory won't serve the purpose of motivating or informing mailbox providers. > Creating a reference to an abuse-role will need authorization > (either by maintainer or otherwise). Yes. If they don't fully trust the customer, they can keep the contact internally and forward the complaints, after counting them. Is this also out of scope, even as an informal suggestion? > The question of a 'bottom up' or 'top down' search for the abuse-role reference > is one of the presentation system, not necessarily inherent to the DB, unless the > DB ought to support search advice. More precisely, is there a point in enabling, > say, the ISP to add their abuse-object to responses where a customer provided their > own. I think there are pros and cons in both directions. IMHO, the more to the bottom the better, as long as one can trust that complaints are being taken care of. The count-and-forward model might minimize network traffic, with respect to a complainant sending CCs to upper ISPs, as forwarded messages are likely transmitted on a network provider's own wires. From tk at abusix.com Sat Oct 15 13:04:49 2011 From: tk at abusix.com (Tobias Knecht) Date: Sat, 15 Oct 2011 13:04:49 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E985F58.3040006@ripe.net> References: <4E79B21F.2080807@abusix.com> <4E84E0F2.3040206@CC.UniVie.ac.at> <4E85A738.20402@ripe.net> <4E8DB1A1.7000907@abusix.com> <4E92F2AD.2000601@ripe.net> <4E92F5C0.80203@ripe.net> <4E930019.8040407@tana.it> <4E930648.5050902@ripe.net> <20111014152015.GC28724@x27.adm.denic.de> <4E985F58.3040006@ripe.net> Message-ID: <4E9968D1.8060504@abusix.com> Hi all, >> On Mon, Oct 10, 2011 at 04:50:48PM +0200, Denis Walker wrote: >> >>> On 10/10/11:42 4:24 PM, ale at tana.it wrote: >>>> On 10/Oct/11 15:40, Denis Walker wrote: >>>>> "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." >>>> >>>> +1, the above paragraph works for me (assuming abuse-mailbox does not >>>> satisfy that criterion.) >> >> I'm not sure who or what this principle would apply to: >> >> 1) the proposal in general (motherhood and apple pie ...) >> 2) the maintainer when selecting the traget for abuse-c >> 3) the query strategy within the DB interface (assuming there are >> objects inthe hierarchy with "abuse-c" and such without > > My reasoning for suggesting something along these lines was to avoid the > situation in APNIC where they added a reference to every INET(6)NUM > object. This resulted in millions of repeated, redundant references. > That is a bad design from every angle. So my point was that if the > policy is going to include any details of design or implementation it is > better to promote good design than bad design. You may decide to keep > the policy to outlining the principles of what you want and not touch at > all on design. Then after the policy is approved, the RIPE NCC can > propose a detailed design to the TF for final consideration before we > implement anything. I fully agree to the part with not promoting design information within the proposal. How RIPE NCC is keeping their things together is imho nothing that should be under discussion. As far as I know we do not discuss which hardware they use, which programming language they use and we should not discuss which database and which database model they use. I agree with Denis that we can talk through this in this TF, but not in the community. Community had the chance to be part of the TF and join the discussion. That's why we are here, because we took the chance. >>> Just to be clear on what this means. The technical suggestion is for the >>> "abuse-c:" attribute to reference a ROLE object with a "role-type:" set >>> to abuse. In this ROLE object there will be an "abuse-mailbox:" attribute. >> >> The per-object attribute "abuse-mailbox" was, IMHO, a design violation and therefore >> I support a per-object attribute "abuse-c" (where appropriate) with a link/handle >> to a role object. Consolidation and migration strategy to be defined. >> >> Making the "abuse-c" mandatory does still not sound convincing to me. >> For that "role" like object (somewhere between tech-c/role/irt) the details need >> to be hashed out, but i'm struggling with the attribute "abuse-mailbox" >> for two reasons: 1) it carries legacy; 2) it is inconsistent with other >> objects: we say email: in both tech-c and admin-c kind of objects and >> do not say tech-mailbox or admin-mailbox; > > As the new usage is similar but not identical to the current > "abuse-mailbox:" a new name may well help with clarity in explaining the > new design. Changing the abuse-mailbox attributes name or not is not that important in my opinion. It can lead to clarification, but it also can lead to confusion and the "wtf, yet another abuse thing in the whois?" feeling. And imho abuse-mailbox or postmaster-mailbox are common known wordings. Changing it leads probably to confusion. I will send another message within the next minutes which contains a version of the policy text with hopefully all discussed changes. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From tk at abusix.com Sat Oct 15 13:18:48 2011 From: tk at abusix.com (Tobias Knecht) Date: Sat, 15 Oct 2011 13:18:48 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E7A038A.8050204@tana.it> References: <4E79B21F.2080807@abusix.com> <4E7A038A.8050204@tana.it> Message-ID: <4E996C18.8020207@abusix.com> Hi all, as promised, the new corrected version with hopefully all wishes and corrections integrated. Please let me know if I missed something and I will correct it in the next version. May be we can go from there, since I understood, that this is kind of common sense of what needs to be done and mentioned by the proposal. Feel free to suggest, correct and improve things. :-) ##### Summary of the proposal: This is a proposal to introduce a new (mandatory) contact attribute named "abuse-c:", which can be referenced by inetnum, inet6num and aut-num objects. It provides a more efficient way for maintainers to organize their provided information and helps to increase accuracy and efficiency in routing abuse reports to the correct network contact. In addition to that, it helps all kinds of institutions (legal, law enforcers, reporting organizations and much more) to find the correct abuse contact information more easily. ##### Summary of the current problem: Network owners increasingly operate dedicated abuse handling departments, distinct from the basic operations department. More and more network owners and other institutions are also starting to exchange data about abusive behavior with each other, to more quickly allow networks to identify internal abuse, external abuse, and other security problems. Currently within the RIPE region, it is a problem for network operators to determine the best place to publish abuse contact information (irt, "abuse-mailbox:", "remark-fields:", and in addition to that, in which object they should publish them). As a consequence, it is a huge problem for all kinds of institutions (legal, law enforcement, reporting organization and others) to find the correct abuse contact in the variety of possibilities. ##### Situation in other RIRs AfriNIC: Policy Proposal AFPUB-2010-GEN-006 is awaiting implementation. http://www.afrinic.net/docs/policies/AFPUB-2010-GEN-006-draft-02.htm APNIC Policy Proposal "prop-079: Abuse contact information" was implemented in November 2010. http://www.apnic.net/policy/proposals/prop-079 ARIN: An abuse-POC exists for Organisational ID identifiers. https://www.arin.net/knowledge/database.html#abusepoc ARIN decided to make abuse-c mandatory. https://www.arin.net/announcements/2011/20110718.html LACNIC: An "abuse-c:" exists for aut-num, inetnum and inet6num objects. http://lacnic.net/en/politicas/manual4.html ##### Policy Text This is a proposal to introduce a new (mandatory) contact attribute named "abuse-c:", which can be referenced by inetnum, inet6num and aut-num objects. The "abuse-c:" reference to an abuse handler should make use of the hierarchical nature of the resource data to minimize the workload on resource holders and facilitate good database design. The role should contain the following attributes: ... address: [mandatory] phone: [optional] fax-no: [optional] e-mail: [mandatory] [single] abuse-mailbox: [mandatory] [single] ... The difference between "e-mail:" and abuse-mailbox:" is in the usage of both. "abuse-mailbox:" is intended for receiving automatic and manual reports about abusive behavior originating the resource holders networks, while the "e-mail:" attribute shall be used for private conversations between the resources holder(s teams) and external persons or institutions. #### Open Questions from my side. - Can we put the rename of "mnt-irt:" into "irt-c:" into this proposal? Or do we need another one for this? - @Denis: How can we organize the cleanup process. Do you have already a more specific idea on what steps we should go? Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From denis at ripe.net Sun Oct 16 21:37:38 2011 From: denis at ripe.net (denis at ripe.net) Date: Sun, 16 Oct 2011 21:37:38 +0200 (CEST) Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E996C18.8020207@abusix.com> References: <4E79B21F.2080807@abusix.com> <4E7A038A.8050204@tana.it> <4E996C18.8020207@abusix.com> Message-ID: <52415.83.160.50.2.1318793858.squirrel@webmail.ripe.net> > Hi all, > > as promised, the new corrected version with hopefully all wishes and > corrections integrated. Please let me know if I missed something and I > will correct it in the next version. > > > > Open Questions from my side. > > - Can we put the rename of "mnt-irt:" into "irt-c:" into this proposal? > Or do we need another one for this? > > - @Denis: How can we organize the cleanup process. Do you have already a > more specific idea on what steps we should go? > > > This is for the TF to decide on but my suggestion would be to make any cleanup part of the implementation. Once you have a policy stating how you want abuse details to be handled, then the RIPE NCC can draft an implementation plan explaining how to achieve what the policy requires. This plan can include details of cleaning up legacy data. You could also consider changing the IRT to a role type as part of the implementation and cleanup. So if the TF discusses the outline of how you would like this to be done, the RIPE NCC can include all this in the draft implementation plan and submit that to the TF or the WGs (DB and AA) for final approval. cheers denis From pk at DENIC.DE Mon Oct 17 11:52:31 2011 From: pk at DENIC.DE (Peter Koch) Date: Mon, 17 Oct 2011 11:52:31 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E985F58.3040006@ripe.net> References: <4E84E0F2.3040206@CC.UniVie.ac.at> <4E85A738.20402@ripe.net> <4E8DB1A1.7000907@abusix.com> <4E92F2AD.2000601@ripe.net> <4E92F5C0.80203@ripe.net> <4E930019.8040407@tana.it> <4E930648.5050902@ripe.net> <20111014152015.GC28724@x27.adm.denic.de> <4E985F58.3040006@ripe.net> Message-ID: <20111017095231.GM28724@x27.adm.denic.de> Hi Denis, > >>> On 10/Oct/11 15:40, Denis Walker wrote: > >>>> "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." > My reasoning for suggesting something along these lines was to avoid the > situation in APNIC where they added a reference to every INET(6)NUM > object. This resulted in millions of repeated, redundant references. > That is a bad design from every angle. So my point was that if the i can see lots of disadvatages, but the one advantage is that of clarity: everything related to an objct is directly referred to, no magic search applies. It's a question of precedent whether such exploitation of hierarchy is feasible within the DB context. I believe we indeed have such precedents, maybe in the domain objects in the reverse space, so i could live with such an approach. However, this isn't the only way to go and neither the only response to "good database design". That attitude sounds a bit overdone. > One of the benefits of implementing this "role-type:" is that it is > extendible beyond just abuse handling. You can define whatever role you > need, abuse handling, csirt team, customer support, billing, sales, etc. > To define any new role, say abuse handling, you add a new type 'abuse'. > Optionally define a new "xxx-c:" attribute and which objects can include > it. Then define a set of business rules to apply to this role. Do we have any precedent to this and does it increase operational clarity to have 'sub types' for db objects? I'm not sure i understand the benefit that would go beyond the current limited scope. -Peter From pk at DENIC.DE Mon Oct 17 11:58:51 2011 From: pk at DENIC.DE (Peter Koch) Date: Mon, 17 Oct 2011 11:58:51 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E9968D1.8060504@abusix.com> References: <4E85A738.20402@ripe.net> <4E8DB1A1.7000907@abusix.com> <4E92F2AD.2000601@ripe.net> <4E92F5C0.80203@ripe.net> <4E930019.8040407@tana.it> <4E930648.5050902@ripe.net> <20111014152015.GC28724@x27.adm.denic.de> <4E985F58.3040006@ripe.net> <4E9968D1.8060504@abusix.com> Message-ID: <20111017095851.GN28724@x27.adm.denic.de> On Sat, Oct 15, 2011 at 01:04:49PM +0200, Tobias Knecht wrote: > I fully agree to the part with not promoting design information within > the proposal. How RIPE NCC is keeping their things together is imho > nothing that should be under discussion. As far as I know we do not > discuss which hardware they use, which programming language they use and > we should not discuss which database and which database model they use. i beg to differ: nobody is talking about HW or programming language, but the type of objects and their relations has always been subject to community discussion and i believe this fruitful interaction is part of the reason why the RIPE DB is successful. > I agree with Denis that we can talk through this in this TF, but not in > the community. Community had the chance to be part of the TF and join > the discussion. That's why we are here, because we took the chance. This is not how this community works. Our output is subject to review and we would be ill advised not to take operational considerations into account. "design" is not about implementation details, it is about concepts. And should we suggest to exploit the hierarchy in registered objects it is part of our job to define what operators can expect. -Peter From tk at abusix.com Mon Oct 17 12:36:54 2011 From: tk at abusix.com (Tobias Knecht) Date: Mon, 17 Oct 2011 12:36:54 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <20111017095851.GN28724@x27.adm.denic.de> References: <4E85A738.20402@ripe.net> <4E8DB1A1.7000907@abusix.com> <4E92F2AD.2000601@ripe.net> <4E92F5C0.80203@ripe.net> <4E930019.8040407@tana.it> <4E930648.5050902@ripe.net> <20111014152015.GC28724@x27.adm.denic.de> <4E985F58.3040006@ripe.net> <4E9968D1.8060504@abusix.com> <20111017095851.GN28724@x27.adm.denic.de> Message-ID: <4E9C0546.90104@abusix.com> Am 17.10.11 11:58, schrieb Peter Koch: > On Sat, Oct 15, 2011 at 01:04:49PM +0200, Tobias Knecht wrote: > >> I fully agree to the part with not promoting design information within >> the proposal. How RIPE NCC is keeping their things together is imho >> nothing that should be under discussion. As far as I know we do not >> discuss which hardware they use, which programming language they use and >> we should not discuss which database and which database model they use. > > i beg to differ: nobody is talking about HW or programming language, but the > type of objects and their relations has always been subject to community > discussion and i believe this fruitful interaction is part of the reason > why the RIPE DB is successful. I fully agree that type of objects and their relations are part of the discussion. But I do not agree that the way RIPE NCC splits up their database design and business logic part should be part of a community discussion. These are imho 2 completely different things. >> I agree with Denis that we can talk through this in this TF, but not in >> the community. Community had the chance to be part of the TF and join >> the discussion. That's why we are here, because we took the chance. > > This is not how this community works. Our output is subject to review > and we would be ill advised not to take operational considerations > into account. > > "design" is not about implementation details, it is about concepts. > And should we suggest to exploit the hierarchy in registered objects > it is part of our job to define what operators can expect. Yes I fully agree that our output is object to review. No doubt about that. Community should review the idea of the abuse-c, the idea of the cleanup with the renaming of mnt-irt and some other things. And exactly these things should be part of the policy proposal. I do not see the need for community to review implementation techniques and database design within the policy proposal for abuse contact information. We're supposed to come up with a policy proposal about the abuse contact information. And that is what we should do. We want to have a abuse-c with these and those attributes. We want to have a cleanup to get rid of old things. We want to rename the mnt-irt into irt-c because it is a contact as well and renaming makes it more consistent. That's what this proposal and this taskforce is all about. The implementation has nothing to do with the proposal itself. Making a copy of tech-c and just putting it into the database would work the same way. So the need for abuse contact information and the implementation of a new way of storing things in the database are two different things. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From denis at ripe.net Mon Oct 17 13:14:35 2011 From: denis at ripe.net (Denis Walker) Date: Mon, 17 Oct 2011 13:14:35 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <20111017095231.GM28724@x27.adm.denic.de> References: <4E84E0F2.3040206@CC.UniVie.ac.at> <4E85A738.20402@ripe.net> <4E8DB1A1.7000907@abusix.com> <4E92F2AD.2000601@ripe.net> <4E92F5C0.80203@ripe.net> <4E930019.8040407@tana.it> <4E930648.5050902@ripe.net> <20111014152015.GC28724@x27.adm.denic.de> <4E985F58.3040006@ripe.net> <20111017095231.GM28724@x27.adm.denic.de> Message-ID: <4E9C0E1B.8070802@ripe.net> HI Peter On 17/10/11:43 11:52 AM, Peter Koch wrote: > Hi Denis, > >>>>> On 10/Oct/11 15:40, Denis Walker wrote: >> One of the benefits of implementing this "role-type:" is that it is >> extendible beyond just abuse handling. You can define whatever role you >> need, abuse handling, csirt team, customer support, billing, sales, etc. >> To define any new role, say abuse handling, you add a new type 'abuse'. >> Optionally define a new "xxx-c:" attribute and which objects can include >> it. Then define a set of business rules to apply to this role. > > Do we have any precedent to this and does it increase operational clarity > to have 'sub types' for db objects? I'm not sure i understand the benefit > that would go beyond the current limited scope. > > -Peter > In a way I would say we do have a precedence for this. The INET(6)NUM objects have a "status:" attribute. Depending on the value of this we have a whole series of different business rules that apply. So you can 'see' the status as a form of sub-type. Also with MNTNER objects. Although they don't have a sub-type, they are referenced in many different ways. Again depending on how you reference a MNTNER different business rules apply. This is a form of (badly designed) sub-typing by overloading the MNTNER object references with different types of authorisation. Personally I do think sub-typing can improve clarity and usability, if done well. If you try to map an organisation onto the RIPE Database there are many different uses for 'role'. This object is quite flexible, but it has never been used properly since it was introduced. Maybe by introducing sub-types we can 're-advertise' this object and finally get people to group people (PERSON objects) into roles and reference the ROLE object everywhere else. cheers denis From vesely at tana.it Mon Oct 17 13:23:55 2011 From: vesely at tana.it (Alessandro Vesely) Date: Mon, 17 Oct 2011 13:23:55 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E996C18.8020207@abusix.com> References: <4E79B21F.2080807@abusix.com> <4E7A038A.8050204@tana.it> <4E996C18.8020207@abusix.com> Message-ID: <4E9C104B.10702@tana.it> A couple of notes... On 15/Oct/11 13:18, Tobias Knecht wrote: > > Policy Text > > This is a proposal to introduce a new (mandatory) contact attribute > named "abuse-c:", which can be referenced by inetnum, inet6num and > aut-num objects. The "abuse-c:" reference to an abuse handler should > make use of the hierarchical nature of the resource data to minimize the > workload on resource holders and facilitate good database design. It is not clear from that text that we want abuse-c to be inherited. IMHO, optimizations and database principles should be considered a fortunate coincidence. The semantic point is that we consider ISPs responsible for the kind of traffic that their customers operate. (The recent A2B vs Spamhaus story may illustrate this concept.) > The role should contain the following attributes: > > ... > address: [mandatory] > phone: [optional] > fax-no: [optional] > e-mail: [mandatory] [single] > abuse-mailbox: [mandatory] [single] * domain-name: [mandatory] [single] I re-propose adding a domain, the main domain that the abuse team belongs to, in order to avoid the email addresses to be meaningful in that respect. For example, one might want to outsource an abuse-mailbox, or to use external domains for fault-tolerance. From tk at abusix.com Mon Oct 17 13:51:03 2011 From: tk at abusix.com (Tobias Knecht) Date: Mon, 17 Oct 2011 13:51:03 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E9C104B.10702@tana.it> References: <4E79B21F.2080807@abusix.com> <4E7A038A.8050204@tana.it> <4E996C18.8020207@abusix.com> <4E9C104B.10702@tana.it> Message-ID: <4E9C16A7.9020602@abusix.com> Am 17.10.11 13:23, schrieb Alessandro Vesely: > A couple of notes... > > On 15/Oct/11 13:18, Tobias Knecht wrote: >> >> Policy Text >> >> This is a proposal to introduce a new (mandatory) contact attribute >> named "abuse-c:", which can be referenced by inetnum, inet6num and >> aut-num objects. The "abuse-c:" reference to an abuse handler should >> make use of the hierarchical nature of the resource data to minimize the >> workload on resource holders and facilitate good database design. > > It is not clear from that text that we want abuse-c to be inherited. > IMHO, optimizations and database principles should be considered a > fortunate coincidence. The semantic point is that we consider ISPs > responsible for the kind of traffic that their customers operate. > (The recent A2B vs Spamhaus story may illustrate this concept.) Any suggestions for a better wording? >> The role should contain the following attributes: >> >> ... >> address: [mandatory] >> phone: [optional] >> fax-no: [optional] >> e-mail: [mandatory] [single] >> abuse-mailbox: [mandatory] [single] > * domain-name: [mandatory] [single] > > I re-propose adding a domain, the main domain that the abuse team > belongs to, in order to avoid the email addresses to be meaningful in > that respect. For example, one might want to outsource an > abuse-mailbox, or to use external domains for fault-tolerance. Doesn't this destroy the simplicity for huge ISPs? United Internet is 1&1 (1und1.de, 1and1.co.uk, 1and1.com, and lots more), web.de and GMX (gmx.de, gmx.at, gmx.ch, gmx.com...) ... 1.) Which one would be the correct domain-name? 2.) The addresses are not that meaningful, but isn't the company the role belongs meaningful enough? I think this may lead into more trouble than additional value. Thanks, Tobias -- abusix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From ops.lists at gmail.com Mon Oct 17 14:04:43 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 17 Oct 2011 17:34:43 +0530 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E9C0E1B.8070802@ripe.net> References: <4E84E0F2.3040206@CC.UniVie.ac.at> <4E85A738.20402@ripe.net> <4E8DB1A1.7000907@abusix.com> <4E92F2AD.2000601@ripe.net> <4E92F5C0.80203@ripe.net> <4E930019.8040407@tana.it> <4E930648.5050902@ripe.net> <20111014152015.GC28724@x27.adm.denic.de> <4E985F58.3040006@ripe.net> <20111017095231.GM28724@x27.adm.denic.de> <4E9C0E1B.8070802@ripe.net> Message-ID: Quick question - will this new proposed abuse contact object be searchable in RIPE using the -i flag? whois -h whois.ripe.net -i mnt-by foo etc From denis at ripe.net Mon Oct 17 14:31:08 2011 From: denis at ripe.net (Denis Walker) Date: Mon, 17 Oct 2011 14:31:08 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: References: <4E84E0F2.3040206@CC.UniVie.ac.at> <4E85A738.20402@ripe.net> <4E8DB1A1.7000907@abusix.com> <4E92F2AD.2000601@ripe.net> <4E92F5C0.80203@ripe.net> <4E930019.8040407@tana.it> <4E930648.5050902@ripe.net> <20111014152015.GC28724@x27.adm.denic.de> <4E985F58.3040006@ripe.net> <20111017095231.GM28724@x27.adm.denic.de> <4E9C0E1B.8070802@ripe.net> Message-ID: <4E9C200C.2020709@ripe.net> On 17/10/11:43 2:04 PM, Suresh Ramasubramanian wrote: > Quick question - will this new proposed abuse contact object be > searchable in RIPE using the -i flag? > > whois -h whois.ripe.net -i mnt-by foo etc > > We can make the "abuse-c:" attribute inverse searchable. But what is the use case? What question do you want this query to answer? whois -h whois.ripe.net -i abuse-c crew-ripe What this will tell you is what objects in the RIPE Database have an abuse-c with the value crew-ripe. It is a list of objects that this abuse handler is responsible for. It is the opposite of the Abuse Finder. This says I have a resource, now tell me who is responsible for the abuse handling. You are saying I have an abuse handler, now tell me what resources he is responsible for. cheers denis From brian.nisbet at heanet.ie Mon Oct 17 15:39:34 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Mon, 17 Oct 2011 14:39:34 +0100 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E9C104B.10702@tana.it> References: <4E79B21F.2080807@abusix.com> <4E7A038A.8050204@tana.it> <4E996C18.8020207@abusix.com> <4E9C104B.10702@tana.it> Message-ID: <4E9C3016.8000708@heanet.ie> "Alessandro Vesely" wrote the following on 17/10/2011 12:23: > A couple of notes... > > On 15/Oct/11 13:18, Tobias Knecht wrote: >> >> Policy Text >> >> This is a proposal to introduce a new (mandatory) contact attribute >> named "abuse-c:", which can be referenced by inetnum, inet6num and >> aut-num objects. The "abuse-c:" reference to an abuse handler should >> make use of the hierarchical nature of the resource data to minimize the >> workload on resource holders and facilitate good database design. > > It is not clear from that text that we want abuse-c to be inherited. > IMHO, optimizations and database principles should be considered a > fortunate coincidence. The semantic point is that we consider ISPs > responsible for the kind of traffic that their customers operate. > (The recent A2B vs Spamhaus story may illustrate this concept.) I would have said that we want it to be inheritable, rather than inherited by conceptual default. I may have misinterpreted the feeling of the TF, but this is something we'll have to be very careful about and "responsible" is a big word. If this is phrased or spun in such a way that people believe that it will make them and all of their networks immediately responsible for traffic coming from a separate AS & PI block that they route, I think we won't even get out of the starting gate. Brian. From ops.lists at gmail.com Mon Oct 17 18:13:11 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 17 Oct 2011 21:43:11 +0530 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E9C200C.2020709@ripe.net> References: <4E84E0F2.3040206@CC.UniVie.ac.at> <4E85A738.20402@ripe.net> <4E8DB1A1.7000907@abusix.com> <4E92F2AD.2000601@ripe.net> <4E92F5C0.80203@ripe.net> <4E930019.8040407@tana.it> <4E930648.5050902@ripe.net> <20111014152015.GC28724@x27.adm.denic.de> <4E985F58.3040006@ripe.net> <20111017095231.GM28724@x27.adm.denic.de> <4E9C0E1B.8070802@ripe.net> <4E9C200C.2020709@ripe.net> Message-ID: Well - I find it useful to search for bad actors who get multiple netblocks on RIPE whois -h whois.ripe.net -i mnt-by OBJECT gets me all the netblocks the botmaster / spammer has, if I choose the query (admin-c, tech-c, mnt-by etc) correctly - and of course crosscheck by noting the same badness in those other blocks I find. If the spammer says his abuse-c is unsubscribe at gmail.com that's yet another way for me to find him On Mon, Oct 17, 2011 at 6:01 PM, Denis Walker wrote: > We can make the "abuse-c:" attribute inverse searchable. But what is the > use case? What question do you want this query to answer? > > whois -h whois.ripe.net -i abuse-c crew-ripe > > What this will tell you is what objects in the RIPE Database have an > abuse-c with the value crew-ripe. It is a list of objects that this > abuse handler is responsible for. > > It is the opposite of the Abuse Finder. This says I have a resource, now > tell me who is responsible for the abuse handling. You are saying I have > an abuse handler, now tell me what resources he is responsible for. -- Suresh Ramasubramanian (ops.lists at gmail.com) From vesely at tana.it Mon Oct 17 19:02:12 2011 From: vesely at tana.it (Alessandro Vesely) Date: Mon, 17 Oct 2011 19:02:12 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E9C3016.8000708@heanet.ie> References: <4E79B21F.2080807@abusix.com> <4E7A038A.8050204@tana.it> <4E996C18.8020207@abusix.com> <4E9C104B.10702@tana.it> <4E9C3016.8000708@heanet.ie> Message-ID: <4E9C5F94.30704@tana.it> On 17/Oct/11 15:39, Brian Nisbet wrote: > "Alessandro Vesely" wrote the following on 17/10/2011 12:23: >> A couple of notes... >> >> On 15/Oct/11 13:18, Tobias Knecht wrote: >>> >>> Policy Text >>> >>> This is a proposal to introduce a new (mandatory) contact >>> attribute named "abuse-c:", which can be referenced by inetnum, >>> inet6num and aut-num objects. The "abuse-c:" reference to an >>> abuse handler should make use of the hierarchical nature of the >>> resource data to minimize the workload on resource holders and >>> facilitate good database design. >> >> It is not clear from that text that we want abuse-c to be inherited. >> IMHO, optimizations and database principles should be considered a >> fortunate coincidence. The semantic point is that we consider ISPs >> responsible for the kind of traffic that their customers operate. >> (The recent A2B vs Spamhaus story may illustrate this concept.) > > I would have said that we want it to be inheritable, rather than > inherited by conceptual default. My understanding is that an ISP, maintainer of the whois record, should not thoughtlessly override the default. To wit, the hierarchical nature of the resource data is built after reality, not the other way around. > I may have misinterpreted the feeling of the TF, but this is > something we'll have to be very careful about and "responsible" is > a big word. If this is phrased or spun in such a way that people > believe that it will make them and all of their networks > immediately responsible for traffic coming from a separate AS & PI > block that they route, I think we won't even get out of the > starting gate. Absolutely agreed. I said "responsible" in the sense of being awake at the wheel, not "liable". But you're right that that word may have disrupting effects. I'll use "not-automated" in my reply to Tobias, which is the most watered-down synonym that I can think of. From vesely at tana.it Mon Oct 17 20:29:48 2011 From: vesely at tana.it (Alessandro Vesely) Date: Mon, 17 Oct 2011 20:29:48 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E9C16A7.9020602@abusix.com> References: <4E79B21F.2080807@abusix.com> <4E7A038A.8050204@tana.it> <4E996C18.8020207@abusix.com> <4E9C104B.10702@tana.it> <4E9C16A7.9020602@abusix.com> Message-ID: <4E9C741C.1080908@tana.it> On 17/Oct/11 13:51, Tobias Knecht wrote: > Am 17.10.11 13:23, schrieb Alessandro Vesely: >> A couple of notes... >> >> On 15/Oct/11 13:18, Tobias Knecht wrote: >>> >>> Policy Text >>> >>> This is a proposal to introduce a new (mandatory) contact attribute >>> named "abuse-c:", which can be referenced by inetnum, inet6num and >>> aut-num objects. The "abuse-c:" reference to an abuse handler should >>> make use of the hierarchical nature of the resource data to minimize the >>> workload on resource holders and facilitate good database design. >> >> It is not clear from that text that we want abuse-c to be inherited. >> IMHO, optimizations and database principles should be considered a >> fortunate coincidence. The semantic point is that we consider ISPs >> responsible for the kind of traffic that their customers operate. >> (The recent A2B vs Spamhaus story may illustrate this concept.) > > Any suggestions for a better wording? How about The "abuse-c:" reference to an abuse handler should make use of the hierarchical nature of the resource data, so that a given abuse team retains its relationship with the relevant resources until a different "abuse-c:" reference explicitly overrides it for a given assignment. Such transfers of abuse handling to less specific assignments are not meant to be automated, yet they minimize the workload on resource holders and facilitate good database design. ? >>> The role should contain the following attributes: >>> >>> ... >>> address: [mandatory] >>> phone: [optional] >>> fax-no: [optional] >>> e-mail: [mandatory] [single] >>> abuse-mailbox: [mandatory] [single] >> * domain-name: [mandatory] [single] >> >> I re-propose adding a domain, the main domain that the abuse team >> belongs to, in order to avoid the email addresses to be meaningful in >> that respect. For example, one might want to outsource an >> abuse-mailbox, or to use external domains for fault-tolerance. > > Doesn't this destroy the simplicity for huge ISPs? United Internet is > 1&1 (1und1.de, 1and1.co.uk, 1and1.com, and lots more), web.de and GMX > (gmx.de, gmx.at, gmx.ch, gmx.com...) ... > > 1.) Which one would be the correct domain-name? The most important, according to their marketing taste. But a domain-name should be preferred if it has MX or NS records leading to IP addresses within the same object where the (main) reference to the given abuse-c is going to be put. > 2.) The addresses are not that meaningful, but isn't the company the > role belongs meaningful enough? Yes, we could set a "company-name" instead, but then we'd get stuff like "1&1 Internet Inc." (instead of 1and1.com) or "1&1 Mail & Media Inc." (gmx.com) that are less searchable and less meaningful than the domain names. As abuse-handling is rather cooperative than legally-enforced, I'd consider practical domain-names better than official company-names. For the meaning, we have lots of ways to go from domain names to IP addresses, but only rDNS for the way back. Since rDNS is often unreliable, people look after the @ in email contacts, thereby attributing them a meaning that addresses were not supposed to have. > I think this may lead into more trouble than additional value. Would "optional" be more manageable? From denis at ripe.net Tue Oct 18 13:21:57 2011 From: denis at ripe.net (Denis Walker) Date: Tue, 18 Oct 2011 13:21:57 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E9C741C.1080908@tana.it> References: <4E79B21F.2080807@abusix.com> <4E7A038A.8050204@tana.it> <4E996C18.8020207@abusix.com> <4E9C104B.10702@tana.it> <4E9C16A7.9020602@abusix.com> <4E9C741C.1080908@tana.it> Message-ID: <4E9D6155.2020204@ripe.net> HI Alessandro Perhaps I can play devils advocate here and put a couple of questions to you. These are not technical issues so I won't express any opinion either way. I will just throw the questions out for you and the other TF members to consider. (Although they do touch on some technical issues as well.) On 17/10/11:43 8:29 PM, Alessandro Vesely wrote: >> Any suggestions for a better wording? > > How about > > The "abuse-c:" reference to an abuse handler should make use of > the hierarchical nature of the resource data, so that a given > abuse team retains its relationship with the relevant resources > until a different "abuse-c:" reference explicitly overrides it for > a given assignment. Such transfers of abuse handling to less > specific assignments are not meant to be automated, yet they > minimize the workload on resource holders and facilitate good > database design. > > ? Brian mentioned the issue of responsibility. With the IRT object we assumed responsibility in a network hierarchy as recorded in the RIPE Database? So for any IP address an IRT object referenced by the most specific encompassing object held the relevant contact details (if any IRT object was found). Can you assume the same responsibility structure for abuse handling? Will an LIR, by default, be responsible for all abuse complaints for their (PA assignments and sub allocations) customers who don't manage it themselves? That is the practical reality of using this network hierarchy in this way, especially if you make it mandatory that an "abuse-c:" is referenced at some point in all hierarchies. You said above "a different abuse-c: reference explicitly overrides it for a given assignment". This is the case now for IRT. For abuse handling do you want this to 'override' or 'take precedence over' a less specific reference? The Abuse Finder tool should be promoted as the preferred way for anyone to find abuse contact details in the RIPE Database. There is a web form for 'the public' to use for one off enquires and we have an API for 'power users' to use for doing many queries. The logic of the Abuse Finder can be made to do whatever you want. So if you want the 'override' option in the hierarchical lookups we can stop searching at the first encompassing object with an "abuse-c:". If you want the 'take precedence over' option we can continue up the hierarchy until we get to an allocation and select all "abuse-c:" attributes found. As the Abuse Finder is a tool that interprets raw whois queries we can structure the output any way you want. So with a precedence option we could clearly show which addresses should be used first for any complaint. But also list alternatives to use if the primary option does not respond. There was some talk earlier about best practices. If you have (or write) such a document this could be referenced in the Abuse Finder output. I know the TF was set up to decide where to 'put' abuse contact details. But in order to finalise where to put the data, some thought must also be given into how the data will be found and what interpretation can be applied to the data. Maybe the answers to these questions are obvious. But at least you will have thought about it and have a clear answer ready if these questions are asked when you present your policy to the community. > >> 1.) Which one would be the correct domain-name? > You are suggesting adding a mandatory attribute, but are you sure all resource holders will have valid data to put in this mandatory attribute? Your assumption here is that all IP and AS resource holders have a domain name. Is that true? cheers denis From vesely at tana.it Tue Oct 18 19:58:39 2011 From: vesely at tana.it (Alessandro Vesely) Date: Tue, 18 Oct 2011 19:58:39 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E9D6155.2020204@ripe.net> References: <4E79B21F.2080807@abusix.com> <4E7A038A.8050204@tana.it> <4E996C18.8020207@abusix.com> <4E9C104B.10702@tana.it> <4E9C16A7.9020602@abusix.com> <4E9C741C.1080908@tana.it> <4E9D6155.2020204@ripe.net> Message-ID: <4E9DBE4F.6060101@tana.it> On 18/Oct/11 13:21, Denis Walker wrote: > On 17/10/11:43 8:29 PM, Alessandro Vesely wrote: >> >> The "abuse-c:" reference to an abuse handler should make use of >> the hierarchical nature of the resource data, so that a given >> abuse team retains its relationship with the relevant resources >> until a different "abuse-c:" reference explicitly overrides it for >> a given assignment. Such transfers of abuse handling to less >> specific assignments are not meant to be automated, yet they >> minimize the workload on resource holders and facilitate good >> database design. > > Brian mentioned the issue of responsibility. With the IRT object we > assumed responsibility in a network hierarchy as recorded in the RIPE > Database? So for any IP address an IRT object referenced by the most > specific encompassing object held the relevant contact details (if any > IRT object was found). Can you assume the same responsibility structure > for abuse handling? Well, that's the idea the text is meant to convey. > Will an LIR, by default, be responsible for all abuse complaints > for their (PA assignments and sub allocations) customers who don't > manage it themselves? That is the practical reality of using this > network hierarchy in this way, especially if you make it mandatory > that an "abuse-c:" is referenced at some point in all hierarchies. Yes, as soon as a LIR sets an abuse-c, it becomes "responsible". As far as the proposal goes, it can just set, say, noreply at LIR and boast of being fully compliant with it. BitBucket at LIR would be a slightly better choice. Piping complaints to a tool that is able to extract some information, e.g. the IP numbers of both the spammer and the complainant, allows to collect interesting data. I would call the latter a passably decent solution, assuming such data will be used. Obviously, running a full blown abuse team involves costs that competitive providers may want to shun. > You said above "a different abuse-c: reference explicitly overrides it > for a given assignment". This is the case now for IRT. For abuse > handling do you want this to 'override' or 'take precedence over' a less > specific reference? I don't have direct experience of IRTs, but my understanding is that network providers are much more in touch with one another than mailbox providers --except possibly for huge ones. Hence, although mnt-irt and abuse-c are formally similar, trust may be more of a problem for the latter than the former. > The Abuse Finder tool should be promoted as the preferred way for > anyone to find abuse contact details in the RIPE Database. Yes. > There is a web form for 'the public' to use for one off enquires > and we have an API for 'power users' to use for doing many queries. > The logic of the Abuse Finder can be made to do whatever you want. > So if you want the 'override' option in the hierarchical lookups we > can stop searching at the first encompassing object with an > "abuse-c:". If you want the 'take precedence over' option we can > continue up the hierarchy until we get to an allocation and select > all "abuse-c:" attributes found. Yes. For the public, the abuse handler does not produce results widely different from regular web-whois queries, albeit it "knows" the history of how abuse contacts came into being and may thus help inexperienced users. For the power users, which I imagine consist of scripts running on various MTAs with minimal user intervention, a single target address should be the default behavior. An interesting idea is described in http://tools.ietf.org/html/draft-newton-et-al-weirds-rir-query For both uses, the major difficulty is to work out what RIR should be queried and take into account any different semantics in the response. > As the Abuse Finder is a tool that interprets raw whois queries we can > structure the output any way you want. So with a precedence option we > could clearly show which addresses should be used first for any > complaint. But also list alternatives to use if the primary option does > not respond. Good point. For feedback-loop, which seems to be the only documented practice right now, any human interaction is done beforehand, and no response is expected after filing a complaint. On the opposite, some acknowledgment from an abuse-c can be useful in some cases. Abuse reporters may want to keep track of the reports they send, and estimate the reactions of abuse teams. In case they decide they don't trust a team, they will want to use the alternative addresses only. By always giving a list of addresses, we may encourage reporters to send reports to all of them. I'd try to avoid such situation, see http://www.rhyolite.com/anti-spam/you-might-be.html#spam-fighter-3 If the reporters have to query the (first, second, ...) alternative contact, the query-log can be used to gauge the average trust that an abuse team scores --we'd better use authenticated queries if we want reliable data. IOW, we may force power users to evaluate abuse teams by providing a tool taking suitable parameters. > There was some talk earlier about best practices. If you have (or write) > such a document this could be referenced in the Abuse Finder output. I try and push for having these practices documented. I trust we'll get to know it when some reliable source publishes something relevant. Conversely, by publishing the experience we'll obtain with the tool, we can stimulate interest in standardizing such practices. > I know the TF was set up to decide where to 'put' abuse contact details. > But in order to finalise where to put the data, some thought must also > be given into how the data will be found and what interpretation can be > applied to the data. > > Maybe the answers to these questions are obvious. But at least you will > have thought about it and have a clear answer ready if these questions > are asked when you present your policy to the community. I don't think they're obvious at all. In particular, I don't know how users perceive the responsibility of network providers. Polls come to mind, as a way of asking. What if we engage the Anti-Abuse attendants in refining a questionnaire, Tuesday afternoon? We might propose them a set of basic questions, such as * Are ISPs responsible for spam sent by their customers? * Spammer supporters are less/equally/more culpable than spammers? * Should ISPs terminate support to a customer as soon as they become aware that it is a spammer? * How should ISPs become aware that a customer of theirs is a spammer? * ... >>> 1.) Which one would be the correct domain-name? >> > > You are suggesting adding a mandatory attribute, but are you sure all > resource holders will have valid data to put in this mandatory > attribute? Your assumption here is that all IP and AS resource holders > have a domain name. Is that true? Hm... most people has a domain name nowadays, it would be interesting to allow "none" (rather than null) for resource holders that actually don't have one. Do they need an abuse-c in that case? It shouldn't be mandatory, since it's the domain owner's interest to set it. From brian.nisbet at heanet.ie Fri Oct 21 15:34:09 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Fri, 21 Oct 2011 14:34:09 +0100 Subject: [acm-tf] RIPE 63 TF Meeting - 10:30 CET 31st October 2011 Message-ID: <4EA174D1.9080105@heanet.ie> Afternoon, As per the subject line, the TF will be meeting at 10:30 CET on Monday 31st October. We'll be meeting in the Schonberg Room in the Hilton Vienna am Stadtpark at 10:30. Kaveh will be along to give Webex information for the meeting for those of you who can't attend physically. Thanks, Brian. From kranjbar at ripe.net Fri Oct 21 15:49:05 2011 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Fri, 21 Oct 2011 15:49:05 +0200 Subject: [acm-tf] RIPE 63 TF Meeting - 10:30 CET 31st October 2011 In-Reply-To: <4EA174D1.9080105@heanet.ie> References: <4EA174D1.9080105@heanet.ie> Message-ID: Hello, Thank you for the announcement Brian. Below comes the instructions for joining the meeting online or via the phone. Kind Regards, Kaveh. ------------------------------------------------------- Meeting information ------------------------------------------------------- Topic: ACM-TF Meeting Date: Monday, October 31, 2011 Time: 10:30 am, Europe Time (Amsterdam, GMT+01:00) Meeting Number: 708 611 201 Meeting Password: acm-tf ------------------------------------------------------- To join the online meeting ------------------------------------------------------- Go to https://ripencc.webex.com/ripencc/j.php?ED=190812767&UID=504528642&PW=NZmQzODU1NDQy&RT=MiMyMg%3D%3D ------------------------------------------------------- Audio conference information ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll-free number (UK): 0800-051-3810 Call-in toll number (UK): +44-20-310-64804 Global call-in numbers: https://ripencc.webex.com/ripencc/globalcallin.php?serviceType=MC&ED=190812767&tollFree=1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Access code:708 611 201 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ripencc.webex.com/ripencc/mc 2. On the left navigation bar, click "Support". To update this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ripencc.webex.com/ripencc/j.php?ED=190812767&UID=504528642&ICS=MIU3&LD=1&RD=2&ST=1&SHA2=pJ6TW9r/XfjoAZ4oGTcf0Ht2u4-DxQzLJvACz5cV11k= To check whether you have the appropriate players installed for UCF (Universal Communications Format) rich media files, go to https://ripencc.webex.com/ripencc/systemdiagnosis.php. http://www.webex.com CCM:+442031064804x708611201# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. You should inform all meeting attendees prior to recording if you intend to record the meeting. Please note that any such recordings may be subject to discovery in the event of litigation. On Oct 21, 2011, at 3:34 PM, Brian Nisbet wrote: > Afternoon, > > As per the subject line, the TF will be meeting at 10:30 CET on Monday 31st October. We'll be meeting in the Schonberg Room in the Hilton Vienna am Stadtpark at 10:30. Kaveh will be along to give Webex information for the meeting for those of you who can't attend physically. > > Thanks, > > Brian. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaveh.ranjbar at ripe.net Fri Oct 21 15:46:24 2011 From: kaveh.ranjbar at ripe.net (Kaveh Ranjbar) Date: Fri, 21 Oct 2011 15:46:24 +0200 Subject: [acm-tf] RIPE 63 TF Meeting - 10:30 CET 31st October 2011 In-Reply-To: <4EA174D1.9080105@heanet.ie> References: <4EA174D1.9080105@heanet.ie> Message-ID: <4CE65405-8150-4707-A2BA-105610662515@ripe.net> Hello, Thank you for the announcement Brian. Below comes the instructions for joining the meeting online or via the phone. Kind Regards, Kaveh. ------------------------------------------------------- Meeting information ------------------------------------------------------- Topic: ACM-TF Meeting Date: Monday, October 31, 2011 Time: 10:30 am, Europe Time (Amsterdam, GMT+01:00) Meeting Number: 708 611 201 Meeting Password: acm-tf ------------------------------------------------------- To join the online meeting ------------------------------------------------------- Go to https://ripencc.webex.com/ripencc/j.php?ED=190812767&UID=504528642&PW=NZmQzODU1NDQy&RT=MiMyMg%3D%3D ------------------------------------------------------- Audio conference information ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll-free number (UK): 0800-051-3810 Call-in toll number (UK): +44-20-310-64804 Global call-in numbers: https://ripencc.webex.com/ripencc/globalcallin.php?serviceType=MC&ED=190812767&tollFree=1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Access code:708 611 201 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ripencc.webex.com/ripencc/mc 2. On the left navigation bar, click "Support". To update this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ripencc.webex.com/ripencc/j.php?ED=190812767&UID=504528642&ICS=MIU3&LD=1&RD=2&ST=1&SHA2=pJ6TW9r/XfjoAZ4oGTcf0Ht2u4-DxQzLJvACz5cV11k= To check whether you have the appropriate players installed for UCF (Universal Communications Format) rich media files, go to https://ripencc.webex.com/ripencc/systemdiagnosis.php. http://www.webex.com CCM:+442031064804x708611201# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. You should inform all meeting attendees prior to recording if you intend to record the meeting. Please note that any such recordings may be subject to discovery in the event of litigation. On Oct 21, 2011, at 3:34 PM, Brian Nisbet wrote: > Afternoon, > > As per the subject line, the TF will be meeting at 10:30 CET on Monday 31st October. We'll be meeting in the Schonberg Room in the Hilton Vienna am Stadtpark at 10:30. Kaveh will be along to give Webex information for the meeting for those of you who can't attend physically. > > Thanks, > > Brian. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tk at abusix.com Fri Oct 28 10:37:20 2011 From: tk at abusix.com (Tobias Knecht) Date: Fri, 28 Oct 2011 10:37:20 +0200 Subject: [acm-tf] Review for Monday TF Meeting Message-ID: <4EAA69C0.7050407@abusix.com> Hi all, I was not really sure in what phase we are at the moment, but it seems that we have a clear direction on how this whole thing should look like at the end. I tried to take care of the suggestions made in the discussions and attached another version of the proposal to this message. Imho it would make a lot of sense to use the Monday Meeting to get wording done and get the last missing points together. As far as I understood missing points are: - What kind of queries can be done. - The Cleanup process. I would suggest that we present the ideas of the task force in the meeting on Tuesday and put the policy text online for community review. Thanks a lot, have a nice weekend and see you on Monday. Tobias -- abusix -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: acm-tf-policy-proposal-28-10-2011.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From brian.nisbet at heanet.ie Fri Oct 28 12:12:18 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Fri, 28 Oct 2011 11:12:18 +0100 Subject: [acm-tf] Review for Monday TF Meeting In-Reply-To: <4EAA69C0.7050407@abusix.com> References: <4EAA69C0.7050407@abusix.com> Message-ID: <4EAA8002.4040905@heanet.ie> Tobias, "Tobias Knecht" wrote the following on 28/10/2011 09:37: > Hi all, > > I was not really sure in what phase we are at the moment, but it seems > that we have a clear direction on how this whole thing should look like > at the end. We have a clear direction, but there is still discussion to be had. The only agenda for Monday remains the current version of the document. > I tried to take care of the suggestions made in the discussions and > attached another version of the proposal to this message. Excellent, thanks for this. > Imho it would make a lot of sense to use the Monday Meeting to get > wording done and get the last missing points together. > > As far as I understood missing points are: > - What kind of queries can be done. > - The Cleanup process. > > > I would suggest that we present the ideas of the task force in the > meeting on Tuesday and put the policy text online for community review. Well, assuming we come to a consensus in the TF on Monday, we'll then report back to the WG. We were tasked with putting a policy together, so my intent would be to take our finalised document and submit it to the PDP, which is, of course, community review. I don't really want to go through that twice. But we have time in the AA-WG agenda for an update, so it should all flow nicely. Brian. From kranjbar at ripe.net Fri Oct 28 13:09:48 2011 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Fri, 28 Oct 2011 13:09:48 +0200 Subject: [acm-tf] RIPE 63 TF Meeting - 10:30 CET 31st October 2011 References: <4CE65405-8150-4707-A2BA-105610662515@ripe.net> Message-ID: Hello all, Just a reminder for joining instructions and a note: the meeting room has been moved from "Schonberg room" to "Mahler room". Meet you on Monday at 10:30 CET :) All the best, Kaveh. Begin forwarded message: > From: Kaveh Ranjbar > Subject: Re: [acm-tf] RIPE 63 TF Meeting - 10:30 CET 31st October 2011 > Date: October 21, 2011 3:46:24 PM GMT+02:00 > To: acm-tf at ripe.net > > Hello, > > Thank you for the announcement Brian. Below comes the instructions for joining the meeting online or via the phone. > > Kind Regards, > Kaveh. > > ------------------------------------------------------- > Meeting information > ------------------------------------------------------- > Topic: ACM-TF Meeting > Date: Monday, October 31, 2011 > Time: 10:30 am, Europe Time (Amsterdam, GMT+01:00) > Meeting Number: 708 611 201 > Meeting Password: acm-tf > > ------------------------------------------------------- > To join the online meeting > ------------------------------------------------------- > Go to https://ripencc.webex.com/ripencc/j.php?ED=190812767&UID=504528642&PW=NZmQzODU1NDQy&RT=MiMyMg%3D%3D > > ------------------------------------------------------- > Audio conference information > ------------------------------------------------------- > To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. > Call-in toll-free number (UK): 0800-051-3810 > Call-in toll number (UK): +44-20-310-64804 > Global call-in numbers: https://ripencc.webex.com/ripencc/globalcallin.php?serviceType=MC&ED=190812767&tollFree=1 > Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf > > Access code:708 611 201 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://ripencc.webex.com/ripencc/mc > 2. On the left navigation bar, click "Support". > To update this meeting to your calendar program (for example Microsoft Outlook), click this link: > https://ripencc.webex.com/ripencc/j.php?ED=190812767&UID=504528642&ICS=MIU3&LD=1&RD=2&ST=1&SHA2=pJ6TW9r/XfjoAZ4oGTcf0Ht2u4-DxQzLJvACz5cV11k= > > To check whether you have the appropriate players installed for UCF (Universal Communications Format) rich media files, go to https://ripencc.webex.com/ripencc/systemdiagnosis.php. > > http://www.webex.com > > CCM:+442031064804x708611201# > > IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. You should inform all meeting attendees prior to recording if you intend to record the meeting. Please note that any such recordings may be subject to discovery in the event of litigation. > > On Oct 21, 2011, at 3:34 PM, Brian Nisbet wrote: > >> Afternoon, >> >> As per the subject line, the TF will be meeting at 10:30 CET on Monday 31st October. We'll be meeting in the Schonberg Room in the Hilton Vienna am Stadtpark at 10:30. Kaveh will be along to give Webex information for the meeting for those of you who can't attend physically. >> >> Thanks, >> >> Brian. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vesely at tana.it Fri Oct 28 19:22:49 2011 From: vesely at tana.it (Alessandro Vesely) Date: Fri, 28 Oct 2011 19:22:49 +0200 Subject: [acm-tf] Review for Monday TF Meeting In-Reply-To: <4EAA8002.4040905@heanet.ie> References: <4EAA69C0.7050407@abusix.com> <4EAA8002.4040905@heanet.ie> Message-ID: <4EAAE4E9.7010005@tana.it> On 28/Oct/11 12:12, Brian Nisbet wrote: > The only agenda for Monday remains the current version of the document. Firmly keeping that as the main task, in my previous post [*] I mentioned the possibility to engage the Anti-Abuse attendants in defining a questionnaire for surveying what people think about reporting abuse to ISPs. Besides abusix's logs, do we have any other sort of evidence that we're on the good track? [*] http://lists.ripe.net/pipermail/acm-tf/2011-October/000145.html (toward the end) > But we have time in the AA-WG agenda for an update, so it should all > flow nicely. From brian.nisbet at heanet.ie Mon Oct 31 00:10:26 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Sun, 30 Oct 2011 23:10:26 +0000 Subject: [acm-tf] Review for Monday TF Meeting In-Reply-To: <4EAAE4E9.7010005@tana.it> References: <4EAA69C0.7050407@abusix.com> <4EAA8002.4040905@heanet.ie> <4EAAE4E9.7010005@tana.it> Message-ID: <4EADD962.5000609@heanet.ie> Alessandro Vesely wrote, On 28/10/2011 18:22: > On 28/Oct/11 12:12, Brian Nisbet wrote: >> The only agenda for Monday remains the current version of the document. > > Firmly keeping that as the main task, in my previous post [*] I > mentioned the possibility to engage the Anti-Abuse attendants in > defining a questionnaire for surveying what people think about > reporting abuse to ISPs. Besides abusix's logs, do we have any other > sort of evidence that we're on the good track? > > [*] http://lists.ripe.net/pipermail/acm-tf/2011-October/000145.html > (toward the end) I'll admit, I missed that, sorry. We can discuss that also. See you all (checks local time) later this morning. Thanks, Brian.