From brian.nisbet at heanet.ie Fri Jun 3 10:40:33 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Fri, 03 Jun 2011 09:40:33 +0100 Subject: [acm-tf] Planning next meeting In-Reply-To: <4DE35765.5030909@ripe.net> References: <4DE35765.5030909@ripe.net> Message-ID: <4DE89E01.6090704@heanet.ie> Morning (mostly), Could everyone please take a look at this poll and update their preferences. I think we're aiming for the 15th, nominally, right now, but a bit more indication would be great. Thanks, Brian. "Kaveh Ranjbar" wrote the following on 30/05/2011 09:37: > Hi, > > Thanks for participating in the planning effort, I had a short chat with > Brian and we decided to include 6 more days to the poll in order to find > a time-slot with more attendees available. > > So, please kindly edit your schedule -or participate if you haven't done > so the first time- at http://doodle.com/78y7aqvcck9d9quw > > We will close the poll by the end of Wed. 1st of June. > > Kind Regards, > Kaveh. > > -- > Kaveh Ranjbar > Database Group Manager, RIPE NCC > > > From Piotr.Strzyzewski at polsl.pl Fri Jun 3 10:43:36 2011 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Fri, 3 Jun 2011 10:43:36 +0200 Subject: [acm-tf] Planning next meeting In-Reply-To: <4DE89E01.6090704@heanet.ie> References: <4DE35765.5030909@ripe.net> <4DE89E01.6090704@heanet.ie> Message-ID: <20110603084336.GA17901@hydra.ck.polsl.pl> On Fri, Jun 03, 2011 at 09:40:33AM +0100, Brian Nisbet wrote: > Could everyone please take a look at this poll and update their > preferences. I think we're aiming for the 15th, nominally, right now, but a > bit more indication would be great. Removing some dates (past and irrelevant) from the poll will be nice too. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From kranjbar at ripe.net Fri Jun 3 11:29:21 2011 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Fri, 03 Jun 2011 11:29:21 +0200 Subject: [acm-tf] Planning next meeting In-Reply-To: <20110603084336.GA17901@hydra.ck.polsl.pl> References: <4DE35765.5030909@ripe.net> <4DE89E01.6090704@heanet.ie> <20110603084336.GA17901@hydra.ck.polsl.pl> Message-ID: <4DE8A971.7010107@ripe.net> On 6/3/11 10:43 AM, Piotr Strzyzewski wrote: ... > Removing some dates (past and irrelevant) from the poll will be nice > too. Done. Kaveh. From brian.nisbet at heanet.ie Thu Jun 9 17:08:24 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Thu, 09 Jun 2011 16:08:24 +0100 Subject: [acm-tf] Next Meeting - Wednesday 15th June - 15:00 CEST Message-ID: <4DF0E1E8.6080903@heanet.ie> Afternoon, Sorry for the late notice, hopefully a week is enough, but we're going to go for Wednesday 15th June at 15:00 CEST - 17:00 CEST for our next meeting. The kind folks at the NCC will supply technical details to join the meeting. I'll be circulating an agenda in advance. Thanks, Brian. From kranjbar at ripe.net Fri Jun 10 14:32:01 2011 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Fri, 10 Jun 2011 14:32:01 +0200 Subject: [acm-tf] Meeting invitation: ACM-TF Meeting Message-ID: <4DF20EC1.4020007@ripe.net> Hi, Please find the instructions for joining the upcoming acm-tf online meeting below. The meeting will start at 15:00 CEST and is planned till 17:00, participation is only possible via web or phone. Regards, Kaveh. ------------------------------------------------------- Topic: ACM-TF Meeting Date: Wednesday, June 15, 2011 Time: 3:00 pm, Europe Summer Time (Amsterdam, GMT+02:00) Meeting Number: 706 755 694 Meeting Password: acmtf ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ripencc.webex.com/ripencc/j.php?ED=178623742&UID=1238123427&PW=NYmY4MjZiZWJk&RT=MiMyMg%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: acmtf 4. Click "Join". To view in other time zones or languages, please click the link: https://ripencc.webex.com/ripencc/j.php?ED=178623742&UID=1238123427&PW=NYmY4MjZiZWJk&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 028 1181 Call-in toll number (UK): (0)20 700 51000 Global call-in numbers: https://ripencc.webex.com/ripencc/globalcallin.php?serviceType=MC&ED=178623742&tollFree=1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Access code:706 755 694 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ripencc.webex.com/ripencc/mc 2. On the left navigation bar, click "Support". You can contact me at: lenka.svobodova at ripe.net To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ripencc.webex.com/ripencc/j.php?ED=178623742&UID=1238123427&ICS=MI&LD=1&RD=2&ST=1&SHA2=7vmfaw5Srgks5y4YX3LO1LNRY6CanGw2foot7rF8LxQ=&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:+02070051000x706755694# 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kauto.Huopio at ficora.fi Fri Jun 10 14:39:49 2011 From: Kauto.Huopio at ficora.fi (Huopio Kauto) Date: Fri, 10 Jun 2011 12:39:49 +0000 Subject: [acm-tf] Meeting invitation: ACM-TF Meeting In-Reply-To: <4DF20EC1.4020007@ripe.net> References: <4DF20EC1.4020007@ripe.net> Message-ID: <484D2A54C7AEAF4997B452E7572FB9211285A0D5@loota.laru.local> Greetings, My apologies already: it is highly likely that I can't attend this meeting due to other commitments. Best regards, Kauto Huopio FICORA/CERT-FI > -----Original Message----- > From: acm-tf-admin at ripe.net [mailto:acm-tf-admin at ripe.net] On > Behalf Of Kaveh Ranjbar > Sent: 10. kes?kuuta 2011 15:32 > To: acm-tf at ripe.net > Subject: [acm-tf] Meeting invitation: ACM-TF Meeting > > Hi, > > Please find the instructions for joining the upcoming acm-tf > online meeting below. > > The meeting will start at 15:00 CEST and is planned till > 17:00, participation is only possible via web or phone. > > Regards, > Kaveh. > > ------------------------------------------------------- > > Topic: ACM-TF Meeting > Date: Wednesday, June 15, 2011 > Time: 3:00 pm, Europe Summer Time (Amsterdam, GMT+02:00) > Meeting Number: 706 755 694 > Meeting Password: acmtf > > > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to > https://ripencc.webex.com/ripencc/j.php?ED=178623742&UID=12381 23427&PW=NYmY4MjZiZWJk&RT=MiMyMg%3D%3D > 2. If requested, enter your name and email address. > 3. If a password is required, enter the meeting password: acmtf > 4. Click "Join". > > To view in other time zones or languages, please click the link: > https://ripencc.webex.com/ripencc/j.php?ED=178623742&UID=12381 23427&PW=NYmY4MjZiZWJk&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 028 1181 > Call-in toll number (UK): (0)20 700 51000 > Global call-in numbers: > https://ripencc.webex.com/ripencc/globalcallin.php?serviceType =MC&ED=178623742&tollFree=1 > Toll-free dialing restrictions: > http://www.webex.com/pdf/tollfree_restrictions.pdf > > Access code:706 755 694 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://ripencc.webex.com/ripencc/mc > 2. On the left navigation bar, click "Support". > > You can contact me at: > lenka.svobodova at ripe.net > > > To add this meeting to your calendar program (for example > Microsoft Outlook), click this link: > https://ripencc.webex.com/ripencc/j.php?ED=178623742&UID=12381 23427&ICS=MI&LD=1&RD=2&ST=1&SHA2=> 7vmfaw5Srgks5y4YX3LO1LNRY6CanGw2foot7rF8LxQ=&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:+02070051000x706755694# > > 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 Woeber at CC.UniVie.ac.at Mon Jun 13 13:50:23 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 13 Jun 2011 11:50:23 +0000 Subject: [acm-tf] Next Meeting - Wednesday 15th June - 15:00 CEST In-Reply-To: <4DF0E1E8.6080903@heanet.ie> References: <4DF0E1E8.6080903@heanet.ie> Message-ID: <4DF5F97F.4080409@CC.UniVie.ac.at> Hi Brian, TF Members, I have to submit my apologies for Wednesday, due to collision with an different event. Brian Nisbet wrote: > Afternoon, > > Sorry for the late notice, hopefully a week is enough, but we're going > to go for Wednesday 15th June at 15:00 CEST - 17:00 CEST for our next > meeting. > > The kind folks at the NCC will supply technical details to join the > meeting. > > I'll be circulating an agenda in advance. > > Thanks, > > Brian. Best regards, Wilfried. From brian.nisbet at heanet.ie Mon Jun 13 17:06:05 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Mon, 13 Jun 2011 16:06:05 +0100 Subject: [acm-tf] Draft of RIPE NCC Fuctionality Document Message-ID: <4DF6275D.3060705@heanet.ie> Colleagues, In conversation with Denis Walker from the NCC he let me know that he had a document which proposed a way of dealing with some of the matters the TF is dicussing. I'd like to share this with you today (and, indeed, apologies for not sending it out to you sooner) and discuss it on Wednesday. The document is a design approach based on the current DB model that could form the basis for a policy discussion. I am by no means suggesting this is the only approach, but I do like what is laid out in the document and so I submit it to the TF for discussion. Thanks, Brian. -------------- next part -------------- A non-text attachment was scrubbed... Name: db-AbuseHandlingdesignforthecurrentRIPEDatabasemodel-260511-1348-156.pdf Type: application/pdf Size: 36003 bytes Desc: not available URL: From vesely at tana.it Tue Jun 14 20:08:46 2011 From: vesely at tana.it (Alessandro Vesely) Date: Tue, 14 Jun 2011 20:08:46 +0200 Subject: [acm-tf] Draft of RIPE NCC Fuctionality Document In-Reply-To: <4DF6275D.3060705@heanet.ie> References: <4DF6275D.3060705@heanet.ie> Message-ID: <4DF7A3AE.2010002@tana.it> Hi Brian and all, On 13/Jun/11 17:06, Brian Nisbet wrote: > In conversation with Denis Walker from the NCC he let me know that he > had a document which proposed a way of dealing with some of the > matters the TF is dicussing. I'd like to share this with you today > (and, indeed, apologies for not sending it out to you sooner) and > discuss it on Wednesday. The document is a design approach based on > the current DB model that could form the basis for a policy > discussion. I think working out this kind of stuff is exactly what a mailing list is optimal for doing, as participants can propose snippets of text and give +1/-1 feedback about them in order to reach consensus. If Denis had posted this file to the list in May, we could have begun discussing it then. > I am by no means suggesting this is the only approach, but I do > like what is laid out in the document and so I submit it to the TF > for discussion. I like it too, and have some comments. Foremost, the paper has a section named "What to do if no dedicated abuse handler found", but never actually spells what to do if it /is/ found. It obviously assumes people have (their own) knowledge about that. The document mentions "a web interface for the public to use directly." I hope it doesn't refer to end-users. IMHO end-users should just click This-is-Spam buttons. I think the tool will mostly be used in scripts (for forwarding messages reported as spam to the right handler(s) --a process to be defined). An interactive version would be fine, of course. Care has to be taken for the "e-mail" attribute not to be misunderstood. Abuse reporting is going to be a cooperative effort. Defining abuse contact to be mandatory may result in abuse-mailboxes directly connected to /dev/null, a waste of resources for both setting up and running them. Having TiS buttons directly do nothing in such cases would sort the same effect more cheaply. OTOH, spam scoring tools may learn to take into account whether a message can be reported as spam or not, so I'd rather opt for auto-removal of non-functioning entries. From tk at abusix.com Wed Jun 15 09:19:20 2011 From: tk at abusix.com (Tobias Knecht) Date: Wed, 15 Jun 2011 09:19:20 +0200 Subject: [acm-tf] Draft of RIPE NCC Fuctionality Document In-Reply-To: <4DF7A3AE.2010002@tana.it> References: <4DF6275D.3060705@heanet.ie> <4DF7A3AE.2010002@tana.it> Message-ID: <4DF85CF8.4090909@abusix.com> Hi all, > On 13/Jun/11 17:06, Brian Nisbet wrote: >> In conversation with Denis Walker from the NCC he let me know that he >> had a document which proposed a way of dealing with some of the >> matters the TF is dicussing. I'd like to share this with you today >> (and, indeed, apologies for not sending it out to you sooner) and >> discuss it on Wednesday. The document is a design approach based on >> the current DB model that could form the basis for a policy >> discussion. > > I think working out this kind of stuff is exactly what a mailing list > is optimal for doing, as participants can propose snippets of text and > give +1/-1 feedback about them in order to reach consensus. If Denis > had posted this file to the list in May, we could have begun > discussing it then. If this document would have been accessible in May we would have posted it earlier but there was a major need to change and simplify this document before posting it. > Foremost, the paper has a section named "What to do if no dedicated > abuse handler found", but never actually spells what to do if it /is/ > found. It obviously assumes people have (their own) knowledge about that. Right. That's because this Task Force was build to find a way of publishing abuse contact information in the whois and not create a best practice document for abuse reporting. > The document mentions "a web interface for the public to use > directly." I hope it doesn't refer to end-users. IMHO end-users > should just click This-is-Spam buttons. I agree. Never the less you will not be able to leave end-users completely out of scope. We already have the Abuse Finder (http://apps.db.ripe.net/search/abuse-finder.html) and there was not a problem at all with this tool and end-users. So I think offering a webfrontend like this is needed and does not hurt anybody. > I think the tool will mostly be used in scripts (for forwarding > messages reported as spam to the right handler(s) --a process to be > defined). An interactive version would be fine, of course. Absolutely. But again this can't be done in this Task Force. > Care has to be taken for the "e-mail" attribute not to be misunderstood. I agree. I would change this in the document and make the e-mail attribute mandatory again and not optional. IMHO there is a need for an email address for personal conversation and a need for an email address for reports as well. And absolutely true, there must be a good explanation in the documentation to clarify the difference between both. > Abuse reporting is going to be a cooperative effort. Defining abuse > contact to be mandatory may result in abuse-mailboxes directly > connected to /dev/null, a waste of resources for both setting up and > running them. Having TiS buttons directly do nothing in such cases > would sort the same effect more cheaply. OTOH, spam scoring tools may > learn to take into account whether a message can be reported as spam > or not, so I'd rather opt for auto-removal of non-functioning entries. If we make it optional it will be used as a measurement of network reputation. Which means people will use it as measurement to rate incoming mail/whatever streams. If the rating is getting worse, people will create it, link it to /dev/null just to get better reputation. The only way to figure out if somebody is doing a good job with abuse handling, is to look if the same problems occur over and over again or if they get fixed. But this is as well not a part of this Task Force. Thanks, Tobias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature URL: From tk at abusix.com Wed Jun 15 18:06:06 2011 From: tk at abusix.com (Tobias Knecht) Date: Wed, 15 Jun 2011 18:06:06 +0200 Subject: [acm-tf] abuse-c: email vs. abuse-mailbox clarification Message-ID: <4DF8D86E.3080506@abusix.com> Hi, as promised in the call before I will try to clarify the difference between an email attribute and an abuse-mailbox attribute. e-mail attribute: The e-mail attribute is intended to be the contact for personal communications between 2 or more parties. If I have questions for an abuse department I will send an email to this address. Services could use this address to verify that the for example delisting request is coming from the right person, by sending back a verification to this address. Spamhaus is doing something similar at the moment. abuse-mailbox attribute: This e-mail addresses is exclusively for abuse reports. The reports received by this address are usually handled automatically. Any questions? Let me know. Thanks, Tobias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature URL: From denis at ripe.net Wed Jun 15 20:13:54 2011 From: denis at ripe.net (Denis Walker) Date: Wed, 15 Jun 2011 20:13:54 +0200 Subject: [acm-tf] abuse-c: email vs. abuse-mailbox clarification In-Reply-To: <4DF8D86E.3080506@abusix.com> References: <4DF8D86E.3080506@abusix.com> Message-ID: <4DF8F662.5000406@ripe.net> Hi Tobias Just a suggestion, but I would use the word 'private' rather than 'personal'. If something is thought of as personal we start to think data protection, filtering and access control with limits. In this context I think private also fits quite well with your definition. cheers denis On 15/06/11:25 6:06 PM, Tobias Knecht wrote: > Hi, > > as promised in the call before I will try to clarify the difference > between an email attribute and an abuse-mailbox attribute. > > e-mail attribute: > > The e-mail attribute is intended to be the contact for personal > communications between 2 or more parties. If I have questions for an > abuse department I will send an email to this address. Services could > use this address to verify that the for example delisting request is > coming from the right person, by sending back a verification to this > address. Spamhaus is doing something similar at the moment. > > > abuse-mailbox attribute: > > This e-mail addresses is exclusively for abuse reports. The reports > received by this address are usually handled automatically. > > > Any questions? Let me know. > > Thanks, > > Tobias > > From denis at ripe.net Wed Jun 15 21:49:36 2011 From: denis at ripe.net (Denis Walker) Date: Wed, 15 Jun 2011 21:49:36 +0200 Subject: [acm-tf] some thoughts on issues raised today In-Reply-To: <4DF8F662.5000406@ripe.net> References: <4DF8D86E.3080506@abusix.com> <4DF8F662.5000406@ripe.net> Message-ID: <4DF90CD0.7050203@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 vesely at tana.it Thu Jun 16 19:38:28 2011 From: vesely at tana.it (Alessandro Vesely) Date: Thu, 16 Jun 2011 19:38:28 +0200 Subject: [acm-tf] some thoughts on issues raised today In-Reply-To: <4DF90CD0.7050203@ripe.net> References: <4DF8D86E.3080506@abusix.com> <4DF8F662.5000406@ripe.net> <4DF90CD0.7050203@ripe.net> Message-ID: <4DFA3F94.3060909@tana.it> On 15/Jun/11 21:49, Denis Walker wrote: > 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 Very smart, elegant, and concise. I'm no DB expert, but my reckoning is that existing data can be converted quite smoothly for standard roles. Indeed, several currently defined abuse-mailbox attributes can be kept the way they are, required updates being limited to the addition of an abuse-c with the same handle of the role object where the existing abuse-mailbox is defined. If we agree on this design element, we can then focus the discussion on attributes and their characteristics. This seems to be a good step forward. > 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: Why is the role-type attribute itself omitted from this list? The url attribute is rather unclear. Do we mean "web"? IMHO "url", or "contact-url", is better, but it should appear /instead of/ other contact attributes. For example person: Alessandro Vesely address: Via Luigi Anelli, 13 address: I-20122 Milano address: Italy contact-url: mailto:vesely at tana.it?subject=Hello contact-url: tel:+390236526891 contact-url: fax:+390236527219 contact-url: http://www.tana.it/ abuse-mailbox: abuse at tana.it role-type: standard role-type: abuse nic-hdl: AV1444-RIPE source: RIPE # Filtered Note how e-mail contacts may become more different from an abuse-mailbox. > 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. +1 From vesely at tana.it Thu Jun 16 19:40:23 2011 From: vesely at tana.it (Alessandro Vesely) Date: Thu, 16 Jun 2011 19:40:23 +0200 Subject: [acm-tf] Mailing list archives? Message-ID: <4DFA4007.4080504@tana.it> There seems to be no archive page for this list in http://www.ripe.net/ripe/maillists/archives/. From tk at abusix.com Thu Jun 16 21:12:47 2011 From: tk at abusix.com (Tobias Knecht) Date: Thu, 16 Jun 2011 21:12:47 +0200 Subject: [acm-tf] some thoughts on issues raised today In-Reply-To: <4DF90CD0.7050203@ripe.net> References: <4DF8D86E.3080506@abusix.com> <4DF8F662.5000406@ripe.net> <4DF90CD0.7050203@ripe.net> Message-ID: <4DFA55AF.407@abusix.com> Hi all, I really like the new idea of Denis and from my perspective we should not discuss about it to much, since RIPE NCC Database Group will be responsible for developing the "product" at the end. I think the concerns from yesterdays call that are mentioned by Denis are solved in a pretty smart way. Aren't they? > abuse-mailbox: > e-mail: > phone: > irc: > url: > im: Since we do not know, which channels other than email are used at them moment I would keep it simple and just use the typical attributes for a STANDARD object and add the abuse-mailbox attribute and an url attribute. We should start with a small list and add things when they are needed to avoid unneeded discussions and keep it simple. If there are suggestions coming from the community we can add them or add other attributes later as they show up. Any suggestions or concerns about this? Thanks, Tobias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature URL: From vesely at tana.it Fri Jun 17 16:55:26 2011 From: vesely at tana.it (Alessandro Vesely) Date: Fri, 17 Jun 2011 16:55:26 +0200 Subject: [acm-tf] Feedback loops and other BCPs Message-ID: <4DFB6ADE.8080309@tana.it> The MAAWG BCP http://www.maawg.org/system/files/news/MAAWG_Complaint_Feedback_Loop_BCP_2010-08_0.pdf is being converted to an RFC http://tools.ietf.org/html/draft-jdfalk-maawg-cfblbcp-00 For Europe, I've found statements like this While nearly every U.S. ISP with a webmail option has embraced use of a ?spam? or ?junk? button as a primary mechanism to identify spam, EU ISPs are restricted by law from sharing and using this data. http://www.t-f-m.co.uk/ExhibitorLibrary/125/EC_New_EuropeanEmailDelivery_WP_3.pdf I doubt that is true, in particular if users are informed of what those buttons actually do. Can we cite any counter-statement? I still think we should mention a BCP that describes the way we expect abuse-mailboxes be used. How about mentioning wikipedia? http://en.wikipedia.org/wiki/Spam_reporting Any more BCPs? From denis at ripe.net Fri Jun 17 18:58:57 2011 From: denis at ripe.net (Denis Walker) Date: Fri, 17 Jun 2011 18:58:57 +0200 Subject: [acm-tf] some thoughts on issues raised today In-Reply-To: <4DFA55AF.407@abusix.com> References: <4DF8D86E.3080506@abusix.com> <4DF8F662.5000406@ripe.net> <4DF90CD0.7050203@ripe.net> <4DFA55AF.407@abusix.com> Message-ID: <4DFB87D1.1010506@ripe.net> On 16/06/11:25 9:12 PM, Tobias Knecht wrote: > Hi all, > > I really like the new idea of Denis and from my perspective we should > not discuss about it to much, since RIPE NCC Database Group will be > responsible for developing the "product" at the end. Just to avoid any misunderstandings, the RIPE NCC is happy to suggest technical implementation ideas and advise on data model design issues and take on the responsibility for developing the end product, as long as it fits in with the requirements and policies determined by the Task Force. > > I think the concerns from yesterdays call that are mentioned by Denis > are solved in a pretty smart way. Aren't they? > > >> abuse-mailbox: >> e-mail: >> phone: >> irc: >> url: >> im: Before we get too carried away with these 'attributes', they were just a random set of imaginary names I used to illustrate the idea. Since this design is easily extended we can introduce new contact method attributes to be used in any type of ROLE object whenever the community feels the need for one. regards denis > > Since we do not know, which channels other than email are used at them > moment I would keep it simple and just use the typical attributes for a > STANDARD object and add the abuse-mailbox attribute and an url attribute. > > We should start with a small list and add things when they are needed to > avoid unneeded discussions and keep it simple. If there are suggestions > coming from the community we can add them or add other attributes later > as they show up. > > Any suggestions or concerns about this? > > > > Thanks, > > Tobias > > > From ops.lists at gmail.com Sat Jun 18 04:55:31 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 18 Jun 2011 08:25:31 +0530 Subject: [acm-tf] some thoughts on issues raised today In-Reply-To: <4DFB87D1.1010506@ripe.net> References: <4DF8D86E.3080506@abusix.com> <4DF8F662.5000406@ripe.net> <4DF90CD0.7050203@ripe.net> <4DFA55AF.407@abusix.com> <4DFB87D1.1010506@ripe.net> Message-ID: See folks - I'm happy to see a standard format (though we might do without the 'irc') I'm going to be even happier if the format is standardized across RIRs to some larger extent than it currently is. On Fri, Jun 17, 2011 at 10:28 PM, Denis Walker wrote: >>> > > Before we get too carried away with these 'attributes', they were just a > random set of imaginary names I used to illustrate the idea. Since this > design is easily extended we can introduce new contact method attributes to > be used in any type of ROLE object whenever the community feels the need for > one. -- Suresh Ramasubramanian (ops.lists at gmail.com) From brian.nisbet at heanet.ie Tue Jun 21 18:21:49 2011 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Tue, 21 Jun 2011 17:21:49 +0100 Subject: [acm-tf] Mailing list archives? In-Reply-To: <4DFA4007.4080504@tana.it> References: <4DFA4007.4080504@tana.it> Message-ID: <4E00C51D.6020708@heanet.ie> "Alessandro Vesely" wrote the following on 16/06/2011 18:40: > There seems to be no archive page for this list in > http://www.ripe.net/ripe/maillists/archives/. The mailing list archives will be made public, but the lovely NCC Ops folk tell me that it will take a while, so I don't have an estimated completion time just yet. Brian. From tk at abusix.com Wed Jun 29 16:39:47 2011 From: tk at abusix.com (Tobias Knecht) Date: Wed, 29 Jun 2011 16:39:47 +0200 Subject: [acm-tf] some thoughts on issues raised today In-Reply-To: <4DF90CD0.7050203@ripe.net> References: <4DF8D86E.3080506@abusix.com> <4DF8F662.5000406@ripe.net> <4DF90CD0.7050203@ripe.net> Message-ID: <4E0B3933.7080507@abusix.com> Hello everybody, are there any other thought, concerns, suggestions about the idea of Denis we should discuss? If not I would like to take the next steps and think about how we get these things into a policy formated text. Thanks, Tobias Am 15.06.11 21:49, schrieb Denis Walker: > 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: OpenPGP digital signature URL: