<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html style="direction: ltr;"> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body style="direction: ltr;" bidimailui-charset-is-forced="true" bidimailui-detected-decoding-type="UTF-8" text="#000000" bgcolor="#ffffff"> <style>@font-face { font-family: "Courier New"; }@font-face { font-family: "Wingdings"; }@font-face { font-family: "Cambria"; }p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: "Times New Roman"; }p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph { margin: 0cm 0cm 0.0001pt 36pt; font-size: 12pt; font-family: "Times New Roman"; }p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst { margin: 0cm 0cm 0.0001pt 36pt; font-size: 12pt; font-family: "Times New Roman"; }p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle { margin: 0cm 0cm 0.0001pt 36pt; font-size: 12pt; font-family: "Times New Roman"; }p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast { margin: 0cm 0cm 0.0001pt 36pt; font-size: 12pt; font-family: "Times New Roman"; }div.Section1 { page: Section1; }ol { margin-bottom: 0cm; }ul { margin-bottom: 0cm; }</style> Hello, Please find the draft of yesterday's meeting minutes below. Special Thanks to Denis and Athina who have prepared this document. Kind Regards, Kaveh. ----------------------------------------------------------- <style>@font-face { font-family: "Courier New"; }@font-face { font-family: "Wingdings"; }@font-face { font-family: "Cambria"; }p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: "Times New Roman"; }p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph { margin: 0cm 0cm 0.0001pt 36pt; font-size: 12pt; font-family: "Times New Roman"; }p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst { margin: 0cm 0cm 0.0001pt 36pt; font-size: 12pt; font-family: "Times New Roman"; }p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle { margin: 0cm 0cm 0.0001pt 36pt; font-size: 12pt; font-family: "Times New Roman"; }p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast { margin: 0cm 0cm 0.0001pt 36pt; font-size: 12pt; font-family: "Times New Roman"; }div.Section1 { page: Section1; }ol { margin-bottom: 0cm; }ul { margin-bottom: 0cm; }</style> Acm-tf Amsterdam, 2 May 2011 1) Participants: Brian Nisbet (Chair) Wilfried Woeber Peter Koch Tobias Knecht Piotr Strzyzewski Kauto Huopio Alessandro Vesely For the RIPE NCC: Jochem Ruig Kaveh Ranjbar Denis Walker Athina Fragkouli 2) Task Force Charter - Discuss updated charter proposal 3) ACM policy principles (what are the conditions the policy has to meet?) - Discuss principles for the policy proposal 4) ACM policy requirements (what do we want to achieve with the policy proposal?) 5) ACM policy content 6) ACM policy implementation Discussion on agenda points 2-6 · The problem is the confusion that people do not know where to put their abuse contact and the accuracy of this information · The main principle is for a single consistent way to handle abuse contacts · Abuse contact must lead to a responsible party · The email address must receive emails without restriction · Users with large number of objects must be able to manage the system with minimum effort · Email address but url or other ways may be more appropriate for accuracy purposes -> Action on Kauto: to share with the task force relevant Finish regulations · 2 functions of the database: registration of public resources and repository of contact details. Both aspects have to be taken into account · ISPs are not the only network operators, there are others with different requirements whose resources may not be publicly available in the Internet and therefore may not need to have an abuse contact. The url idea also implies you are reachable on the public Internet · Accuracy applies to all contacts, not only abuse · The IRT object was design to allow outsourcing of abuse management · All requirements have to be explicit; putting objects will not solve the problem by itself · The abuse complaints procedures should not be part of this first initiative · Someone should handle the abuse, it doesn’t have to be the ISP, it could be the upstream, some hierarchical model or outsourced to a third party · There was talk about the RIPE NCC auto-generating date stamps as any object in the database is changed. But it was made clear that it would not be the RIPE NCC that assigns any credible meaning to these date stamps. The organizations have to build their own trust on the information they are receiving. Abuse contact, and trust information should be considered as separate issues · The policy that will come out of this is very important and can have 3 possible degrees of influence: 1. You must have a place to put the abuse contact. 2. 1+you must verify the validity of the email address. 3. 2+you must verify the effectiveness of processing abuse reports. Number 3 is unrealistic and any such policy will be unlikely to achieve community consensus. Number 1 is the most practical as a first step · There were a number of concerns regarding hierarchical models. o Upstream providers are not recorded in the RIPE DB. o They cannot be held reliable by default, even those that make assignments cannot be held liable by default. o Although the DB does not record the upstream information, the providers know who the upstream is. If the parties agree on handling abuse information the IRT object can accommodate this hierarchical arrangement. Following from the above discussion the basic requirements were summarised as: · to have a single point of contact that o may be hierarchical, o can be simply queried to return a single piece of information o is easily configured and referenced by others · to separate storage in the DB from querying the DB and presentation of the information Open issues: · From an implementation point of view the question was raised whether a new object is required or if the existing IRT would satisfy all the requirements? · What should be mandatory? An abuse reference on every single resource record or abuse references for resources grouped within hierarchies? -> Action on Brian: to give feedback on Thursday in both AA-WG and DB-WG -> Action on the RIPE NCC: To draft minutes and slides for WG presentations -> Action on the RIPE NCC: to update the acm-tf webpage Next meeting: end of May, beginning of June and meeting after that on September (check clashes with other meetings, eg. ICANN) </body> </html>