[acm-tf] Draft Minutes for ACM-TF Meeting, Monday May 2nd 2011

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.


-----------------------------------------------------------


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)

 


 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.ripe.net/ripe/mail/archives/acm-tf/attachments/20110503/2ffa8056/attachment.html>