From brian.nisbet at heanet.ie Thu Sep 1 13:32:51 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Thu, 01 Sep 2011 12:32:51 +0100 Subject: [acm-tf] Next task force meeting In-Reply-To: <4E566109.6000802@ripe.net> References: <4E566109.6000802@ripe.net> Message-ID: <4E5F6D63.1040600@heanet.ie> Colleagues, We've had a very low rate of response to this poll. Could you please take a look and indicate your availability. If the dates suggested are not suitable for a productive meeting, we can look at rescheduling. Thanks, Brian. "Kaveh Ranjbar" wrote the following on 25/08/2011 15:49: > Hello, > > We are planing to close this poll and finalize the date by first of > September, so could you please kindly fill in the poll if you haven't > done it yet? > > Kind Regards, > Kaveh. > > --------------------------------------------------------------------- > > Hi, > > As it was decided in the last online meeting, the next task force > meeting should happen around mid-September. > > Participation is open to Abuse Contact Management Task Force members. > In order to mark the days you can participate, please visit: > > http://www.doodle.com/wt9ukh6fdfac4rhg > > In order to make it easier for us to find the best possible time slot > for all participants, please kindly mark as many slots as you can. > > > Kind Regards, > > Kaveh. > > > -- > Kaveh Ranjbar > Database Group Manager, RIPE NCC > > > From vesely at tana.it Sat Sep 3 20:01:42 2011 From: vesely at tana.it (Alessandro Vesely) Date: Sat, 03 Sep 2011 20:01:42 +0200 Subject: [acm-tf] Next task force meeting In-Reply-To: <4E5F6D63.1040600@heanet.ie> References: <4E566109.6000802@ripe.net> <4E5F6D63.1040600@heanet.ie> Message-ID: <4E626B86.3070802@tana.it> On 01/Sep/11 13:32, Brian Nisbet wrote: > > We've had a very low rate of response to this poll. I'd suggest that next doodle's table be designed as the complement; that is, participants mark the dates that they /cannot/ participate. Easier. From brian.nisbet at heanet.ie Wed Sep 7 13:23:12 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Wed, 07 Sep 2011 12:23:12 +0100 Subject: [acm-tf] Next task force meeting In-Reply-To: <4E626B86.3070802@tana.it> References: <4E566109.6000802@ripe.net> <4E5F6D63.1040600@heanet.ie> <4E626B86.3070802@tana.it> Message-ID: <4E675420.2080007@heanet.ie> "Alessandro Vesely" wrote the following on 03/09/2011 19:01: > On 01/Sep/11 13:32, Brian Nisbet wrote: >> >> We've had a very low rate of response to this poll. > > I'd suggest that next doodle's table be designed as the complement; > that is, participants mark the dates that they /cannot/ participate. > Easier. That could be a very big subset. However, if you could mark your availability on the poll before 17:00 CEST today, that would be very much appreciated. Thanks, Brian. From vesely at tana.it Wed Sep 7 16:27:58 2011 From: vesely at tana.it (Alessandro Vesely) Date: Wed, 07 Sep 2011 16:27:58 +0200 Subject: [acm-tf] Next task force meeting In-Reply-To: <4E675420.2080007@heanet.ie> References: <4E566109.6000802@ripe.net> <4E5F6D63.1040600@heanet.ie> <4E626B86.3070802@tana.it> <4E675420.2080007@heanet.ie> Message-ID: <4E677F6E.2070007@tana.it> On 07/Sep/11 13:23, Brian Nisbet wrote: > "Alessandro Vesely" wrote the following on 03/09/2011 19:01: >> On 01/Sep/11 13:32, Brian Nisbet wrote: >>> >>> We've had a very low rate of response to this poll. >> >> I'd suggest that next doodle's table be designed as the complement; >> that is, participants mark the dates that they /cannot/ participate. >> Easier. > > That could be a very big subset. Not if you fix a target week, say. > However, if you could mark your availability on the poll before > 17:00 CEST today, that would be very much appreciated. Ok, since you insist. I don't think it'd add much to the certainty that I'll be actually able to join, but I clicked through there to demonstrate that simple problems can indeed be solved with minimal effort by acting on the mailing list. Why don't we do so more often? This list looks crestfallen... > Thanks, Thank you for answering :-) From kranjbar at ripe.net Thu Sep 8 11:16:58 2011 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Thu, 08 Sep 2011 11:16:58 +0200 Subject: [acm-tf] Fwd: Meeting invitation: ACM-TF Meeting In-Reply-To: <182389752.1315469088897.JavaMail.nobody@jln1wl014.webex.com> References: <182389752.1315469088897.JavaMail.nobody@jln1wl014.webex.com> Message-ID: <4E68880A.80403@ripe.net> Hello, Thank you for participating in the poll, after going through results with Brian we have finalized the date and time of the meeting. Next ACM-TF online meeting is scheduled for 20th September at 15:00 CEST to 17:00 CEST (13:00 to 15:00 GMT), please find joining instructions below. Kind Regards, Kaveh. ------------------------------------------------------- Topic: ACM-TF Meeting Date: Tuesday, September 20, 2011 Time: 3:00 pm, Europe Summer Time (Amsterdam, GMT+02:00) Meeting Number: 701 417 430 Meeting Password: 12345 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ripencc.webex.com/ripencc/j.php?ED=186586027&UID=1263489392&PW=NZjdkYjhiY2Y4&RT=MiMyMg%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 12345 4. Click "Join". To view in other time zones or languages, please click the link: https://ripencc.webex.com/ripencc/j.php?ED=186586027&UID=1263489392&PW=NZjdkYjhiY2Y4&ORT=MiMyMg%3D%3D ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- 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=186586027&tollFree=1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Access code:701 417 430 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ripencc.webex.com/ripencc/mc 2. On the left navigation bar, click "Support". You can contact me at: mhessing at ripe.net 31-20 535 4364 To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ripencc.webex.com/ripencc/j.php?ED=186586027&UID=1263489392&ICS=MI&LD=1&RD=2&ST=1&SHA2=1Se0CMjr7YdjHinAwTFCGte0x-kFN17oogRl3kzYtf0=&RT=MiMyMg%3D%3D The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ripencc.webex.com/ripencc/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+442031064804x701417430# 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. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. From vesely at tana.it Wed Sep 14 13:41:53 2011 From: vesely at tana.it (Alessandro Vesely) Date: Wed, 14 Sep 2011 13:41:53 +0200 Subject: [acm-tf] How about a DNS-based interface? Message-ID: <4E709301.2060102@tana.it> Hi all, one question I'd like to put next Tuesday (if I'll be able to connect) is if it would be feasible/convenient to have the IP-address to point-of-contact database available via DNS, with central delegation similar to in-addr.arpa, but not going beyond RIRs. RIRs would populate TXT records with the email address, copying the data present on the whois database. I think this would definitely boost the usability of that data, as it (1) leverages a powerful cache mechanism, and (2) provides a well-known interface, uniform across all RIRs. The global DNS should be named something like _poc.iana.org, or similar global name. Thus, we should seek more sponsors. But do we ourselves like the idea? For IPv6 the problem is more difficult but less urgent. The increased difficulty lays in the cache blasting that would result if clients queried a lot of addresses. There is a proposal[JL] to avoid that by forcing clients to discover the granularity of an IPv6 allocation and then query the correct range. That doubles the number of queries but increases the likelihood of cache hits. [JL] John Levine, 27 Nov 2010 23:47:32 -0500 "Implementing IPv6 DNSBLs" http://www.irtf.org/mail-archive/web/asrg/current/msg16434.html From brian.nisbet at heanet.ie Mon Sep 19 16:55:41 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Mon, 19 Sep 2011 15:55:41 +0100 Subject: [acm-tf] Agenda, Meeting 20th September 15:00 CEST Message-ID: <4E7757ED.3060403@heanet.ie> Afternoon, For tomorrow's meeting I'd like to address the following points: 1) Further Discussion on June Technical Conversation. 2) Drafting of initial proposal. 3) Clarification as regards sponsoring LIR/2010-10. 4) RIPE 63 - Meeting? Feedback to DB & AA 5) AOB Tomorrow's meeting might be brief, but we shall see. Thanks, Brian. From kranjbar at ripe.net Tue Sep 20 12:02:30 2011 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Tue, 20 Sep 2011 12:02:30 +0200 Subject: [acm-tf] Fwd: Fwd: Meeting invitation: ACM-TF Meeting In-Reply-To: <4E68880A.80403@ripe.net> References: <4E68880A.80403@ripe.net> Message-ID: <4E7864B6.8000104@ripe.net> Hello, Just a reminder for Today's meeting. Regards, Kaveh. -------- Original Message -------- Subject: [acm-tf] Fwd: Meeting invitation: ACM-TF Meeting Date: Thu, 08 Sep 2011 11:16:58 +0200 From: Kaveh Ranjbar To: acm-tf at ripe.net Hello, Thank you for participating in the poll, after going through results with Brian we have finalized the date and time of the meeting. Next ACM-TF online meeting is scheduled for 20th September at 15:00 CEST to 17:00 CEST (13:00 to 15:00 GMT), please find joining instructions below. Kind Regards, Kaveh. ------------------------------------------------------- Topic: ACM-TF Meeting Date: Tuesday, September 20, 2011 Time: 3:00 pm, Europe Summer Time (Amsterdam, GMT+02:00) Meeting Number: 701 417 430 Meeting Password: 12345 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ripencc.webex.com/ripencc/j.php?ED=186586027&UID=1263489392&PW=NZjdkYjhiY2Y4&RT=MiMyMg%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 12345 4. Click "Join". To view in other time zones or languages, please click the link: https://ripencc.webex.com/ripencc/j.php?ED=186586027&UID=1263489392&PW=NZjdkYjhiY2Y4&ORT=MiMyMg%3D%3D ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- 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=186586027&tollFree=1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Access code:701 417 430 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ripencc.webex.com/ripencc/mc 2. On the left navigation bar, click "Support". You can contact me at: mhessing at ripe.net 31-20 535 4364 To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ripencc.webex.com/ripencc/j.php?ED=186586027&UID=1263489392&ICS=MI&LD=1&RD=2&ST=1&SHA2=1Se0CMjr7YdjHinAwTFCGte0x-kFN17oogRl3kzYtf0=&RT=MiMyMg%3D%3D The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ripencc.webex.com/ripencc/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+442031064804x701417430# 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. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. From tk at abusix.com Wed Sep 21 11:45:03 2011 From: tk at abusix.com (Tobias Knecht) Date: Wed, 21 Sep 2011 11:45:03 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal Message-ID: <4E79B21F.2080807@abusix.com> Hello, as we decided yesterday in the conference call we will start working on a policy proposal from now on to have our new proposal ready for discussion at RIPE 63. 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. ##### Summary of the proposal: This is a proposal to introduce a new contact attribute named abuse-c, which can be references by inetnum, inet6num and aut-num objects. It provides a more accurate and efficient way for abuse reports to reach the correct network contact and helps reporting institutions 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, 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. This proposal will help to stop uncontrolled growth and solves the above mentioned problems. ##### 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 ##### I copied some of the text parts from my former proposal to have an easy kick-off. I guess this will be enough for a warm-up, so please feel free to change, comment and discuss the parts above and as soon as we have a rough consensus here we can start talking "Policy Text". Thanks, Tobias -- | Tobias Knecht | CEO | abusix UG (haftungsbeschraenkt) | tk at abusix.com | http://abusix.com | Postfach 210127 | 76151 Karlsruhe | Germany | --- | Register of Companies(Handelsregister): HRB 707959 | District of Court(Amtsgericht) Mannheim/Germany | Registered Office: Karlsruhe/Germany | CEO: Tobias Knecht Follow abusix on Twitter! http://twitter.com/abusix -------------- next part -------------- An embedded message was scrubbed... From: Denis Walker Subject: [acm-tf] some thoughts on issues raised today Date: Wed, 15 Jun 2011 21:49:36 +0200 Size: 6944 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 vesely at tana.it Wed Sep 21 17:32:26 2011 From: vesely at tana.it (Alessandro Vesely) Date: Wed, 21 Sep 2011 17:32:26 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E79B21F.2080807@abusix.com> References: <4E79B21F.2080807@abusix.com> Message-ID: <4E7A038A.8050204@tana.it> A add some +1s to agree with Tobias' text, and propose a few changes. On 21/Sep/11 11:45, Tobias Knecht wrote: > ##### > > Summary of the proposal: > > This is a proposal to introduce a new contact attribute named abuse-c, > which can be references by inetnum, inet6num and aut-num objects. +1 > It provides a more accurate and efficient way for abuse reports to > reach the correct network contact It is more efficient for the maintainers. Isn't this the most relevant change with respect to abuse-mailbox? > and helps reporting institutions to find the correct abuse contact > information more easily. +1 > ##### > > Summary of the current problem: > > Network owners increasingly operate dedicated abuse handling > departments, distinct from the basic operations department. +1 > 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. +1 > 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. Hm... I'd reword this slightly. E.g. like so 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/ abuse reporting parties /to find the/ correct abuse contact in the variety of possibilities. > This proposal will help to stop uncontrolled growth and solves the above > mentioned problems. +1, but we should avoid effects like http://www.xkcd.com/927/ > ##### > > 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 +1 > ##### From tk at abusix.com Thu Sep 29 10:50:39 2011 From: tk at abusix.com (Tobias Knecht) Date: Thu, 29 Sep 2011 10:50:39 +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: <4E84315F.1060005@abusix.com> Hi, anybody else? Some changes, ideas, suggestions? Thanks, Tobias Am 21.09.11 17:32, schrieb Alessandro Vesely: > A add some +1s to agree with Tobias' text, and propose a few changes. > > On 21/Sep/11 11:45, Tobias Knecht wrote: >> ##### >> >> Summary of the proposal: >> >> This is a proposal to introduce a new contact attribute named abuse-c, >> which can be references by inetnum, inet6num and aut-num objects. > +1 > >> It provides a more accurate and efficient way for abuse reports to >> reach the correct network contact > > It is more efficient for the maintainers. Isn't this the most > relevant change with respect to abuse-mailbox? > >> and helps reporting institutions to find the correct abuse contact >> information more easily. > +1 > >> ##### >> >> Summary of the current problem: >> >> Network owners increasingly operate dedicated abuse handling >> departments, distinct from the basic operations department. > +1 > >> 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. > +1 > >> 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. > > Hm... I'd reword this slightly. E.g. like so > > 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/ abuse reporting parties > /to find the/ correct abuse contact in the variety of possibilities. > >> This proposal will help to stop uncontrolled growth and solves the above >> mentioned problems. > +1, but we should avoid effects like http://www.xkcd.com/927/ > >> ##### >> >> 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 > +1 > >> ##### > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: OpenPGP digital signature URL: From Woeber at CC.UniVie.ac.at Thu Sep 29 23:19:46 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 29 Sep 2011 21:19:46 +0000 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E79B21F.2080807@abusix.com> References: <4E79B21F.2080807@abusix.com> Message-ID: <4E84E0F2.3040206@CC.UniVie.ac.at> Hi Tobias! Thanks for casting the set of ideas into a draft text, and my apologies for being off-line for a while in the TF. There were some sound reasons for that, unfortunately. Before I go into details, let me double-check that I am not completely off-track: Does this draft assume that we will (eventually) build an implementation along the lines of Denis' idea to use an extended "role" approach[1]? As a side-line, I may want to offer some word-smithing later on to make it (imho) easier to digest and to accept for some parties. I presume we want to have an implementation asap :-) 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? Regards, Wilfried. [1] which I pretty much like, btw. Thanks, Denis! Tobias Knecht wrote: > Hello, > > as we decided yesterday in the conference call we will start working on > a policy proposal from now on to have our new proposal ready for > discussion at RIPE 63. > > > 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. > > ##### > > Summary of the proposal: > > This is a proposal to introduce a new contact attribute named abuse-c, > which can be references by inetnum, inet6num and aut-num objects. It > provides a more accurate and efficient way for abuse reports to reach > the correct network contact and helps reporting institutions 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, 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. > > This proposal will help to stop uncontrolled growth and solves the above > mentioned problems. > > ##### > > 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 > > ##### > > I copied some of the text parts from my former proposal to have an easy > kick-off. I guess this will be enough for a warm-up, so please feel free > to change, comment and discuss the parts above and as soon as we have a > rough consensus here we can start talking "Policy Text". > > Thanks, > > Tobias > > > -- > | Tobias Knecht | CEO | abusix UG (haftungsbeschraenkt) > | tk at abusix.com | http://abusix.com > | Postfach 210127 | 76151 Karlsruhe | Germany > | --- > | Register of Companies(Handelsregister): HRB 707959 > | District of Court(Amtsgericht) Mannheim/Germany > | Registered Office: Karlsruhe/Germany > | CEO: Tobias Knecht > > Follow abusix on Twitter! http://twitter.com/abusix > > > > ------------------------------------------------------------------------ > > Subject: > [acm-tf] some thoughts on issues raised today > From: > Denis Walker > Date: > Wed, 15 Jun 2011 21:49:36 +0200 > To: > acm-tf at ripe.net > > To: > acm-tf at ripe.net > > > Dear Colleagues, > > I was thinking about a couple of points made during the discussion today > while on the train home (yes I know I should get a life but I just had > to write it down). In particular the points about (not) introducing a > new NIC hdl suffix (-abuse) and the need to create multiple ROLE objects > with duplicated data for small organisations. An idea came to mind that > addresses both these issues, fits even better within our current data > model and is extensible. > > Suppose we introduce a new attribute to the ROLE object: > role-type: [mandatory] [multiple] [] > > and allow this initially to take one of three values: > > STANDARD All the current ROLE objects would fit with this type > ABUSE For ROLE objects holding abuse contact data > IRT For ROLE objects holding IRT contact data > > We then add two new contact attributes "abuse-c:" and "irt-c:" > (replacing "mnt-irt:"). These can only reference ABUSE and IRT ROLE > object types respectively. All role based contact information is now > held in the one object type, ROLE. All references to contact details are > from the same type of attribute, "xxx-c:". There is no need for a new > NIC hdl suffix. Existing ROLE objects with their current NIC hdls can be > used for any of these roles. There is no need for a separate IRT object > referenced by a maintainer like attribute. The ROLE object with > "role-type: IRT" and referenced by an "irt-c:" replaces it. > > The syntax for the ROLE object then becomes a superset of all the > attributes needed for each of these roles. All these attributes can be > defined as OPTIONAL by syntax. Their use in each type can be defined by > business rules as one of: > > REQUIRED - must have > ALLOWED - can have > NOT ALLOWED - can't have > > Suppose we have the following superset of optional attributes for all > role types: > > abuse-mailbox: > e-mail: > phone: > irc: > url: > im: > signature: > encryption: > irt-nfy: > > One example set of business rules could be: > > STANDARD ROLE > > REQUIRED > e-mail: > ALLOWED > phone: > NOT ALLOWED > abuse-mailbox: > irc: > url: > im: > signature: > encryption: > irt-nfy: > > ABUSE ROLE > > REQUIRED > abuse-mailbox: > ALLOWED > phone: > e-mail: > irc: > url: > im: > NOT ALLOWED > signature: > encryption: > irt-nfy: > > IRT ROLE > > REQUIRED > e-mail: > signature: > encryption: > ALLOWED > phone: > irt-nfy: > NOT ALLOWED > abuse-mailbox: > irc: > url: > im: > > Filtering and access control limits (ACL) could also apply differently > to the different role types. For STANDARD and IRT ROLE objects query > filtering (negated with the -B flag) could apply to all attributes > containing an email address (as it does now). ACL will apply to the > number of these role types a user queries. For the ABUSE ROLE objects > filtering should only apply to database management attributes like > "notify:" and "changed:". The operational specific attributes like > "abuse-mailbox:" and "e-mail:" will not be filtered. Also no ACL will > apply to queries for these role types. > > By allowing "role-type:" to be a multiple attribute, one ROLE object can > take on more than one role. But with the caveat that the least > restrictive rules for a role type will apply. So for a small company > with only one set of people who do everything, one ROLE object can be > defined as both STANDARD and ABUSE. The business rules will be a > composite of these two role types. No ACL will apply to queries for this > ROLE object as it is an ABUSE role type, even though it is also a > STANDARD role type. It becomes a user choice between convenience and > control. > > To summarise, one object type can be used to define any type of contact > role. We currently have a need for three types. Any new type can be > added in the future by defining a new type value. Business rules can > define the arrangement of attributes per type from a superset of > attributes, including any new ones added later. All contacts should be > referenced by attributes of the format "xxx-c:" and again business rules > can restrict the type of role these attributes can reference. > > I hope this provides some helpful thoughts on these two issues and also > takes another step in the direction of simplifying the data model. > > cheers > denis > From ops.lists at gmail.com Fri Sep 30 04:01:26 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 30 Sep 2011 07:31:26 +0530 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: <4E84E0F2.3040206@CC.UniVie.ac.at> References: <4E79B21F.2080807@abusix.com> <4E84E0F2.3040206@CC.UniVie.ac.at> Message-ID: This would be ideal because doing away with it might cause breakage elsewhere. I would suggest abuse contact information for AS contacts, mnt-by etc contacts too where relevant. On Fri, Sep 30, 2011 at 2:49 AM, Wilfried Woeber, UniVie/ACOnet < Woeber at cc.univie.ac.at> 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 -------------- An HTML attachment was scrubbed... URL: From denis at ripe.net Fri Sep 30 13:25:44 2011 From: denis at ripe.net (Denis Walker) Date: Fri, 30 Sep 2011 13:25:44 +0200 Subject: [acm-tf] Abuse Contact Information - Policy Proposal In-Reply-To: References: <4E79B21F.2080807@abusix.com> <4E84E0F2.3040206@CC.UniVie.ac.at> Message-ID: <4E85A738.20402@ripe.net> 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 )