From brian.nisbet at heanet.ie Sun May 2 19:32:21 2010 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Sun, 02 May 2010 18:32:21 +0100 Subject: [anti-abuse-wg] Updated RIPE 60 WG Agenda Message-ID: <4BDDB725.5030006@heanet.ie> Hi, This is mostly some confirmations and clarifications, however as there has been no notable progress on the BCP documentation that will be relesed to the list between now and RIPE 61, so it has been removed from agenda. I've also sent the email to the right address this time... Anti-Abuse Working Group Agenda - RIPE 60 Location: - Bohemia I Date: Thursday, 6 May 2010, 16:00-17:30 Anti-Abuse Working Group Home Page A. Administrative Matters * Welcome * Select a scribe * Jabber Monitor * Microphone Etiquette * Approve Minutes from RIPE 59 * Finalise agenda B Update * B1. Network Abuse Update - Richard Cox * B2. Recent List Discussion - Abuse contacts, Sanctions, etc. C. Technical Measures * C1. RIPE NCC Tools update - Paul Palse, RIPE NCC D. Interactions * D1. Working Groups * D2. Law Enforcement Interaction - Wout de Natris, LAP * D3. RIPE NCC LEA Interactions Update - Jochem de Ruig, RIPE NCC X. A.O.B. Z. Agenda for RIPE 61; Plenary Presentations See you all on Thursday! Thanks, Brian. From tk at abusix.org Mon May 3 09:56:11 2010 From: tk at abusix.org (Tobias Knecht) Date: Mon, 03 May 2010 09:56:11 +0200 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal Message-ID: <4BDE819B.1050608@abusix.com> Hello, this proposal was planned to be published end of May. But so many people asked me to publish it earlier and hopefully before RIPE-60 in Praha, so I will. This proposal is more or less a copy of our proposals for AfriNIC and APNIC. The APNIC proposal will be acknowledged today. The AfriNIC proposal will be discussed in Kigali end of this month. I will not be able to come to RIPE-60, but I hope that this proposal finds a little spot to be discussed in the Anti-Abuse Working Group Meeting. If you have questions, ideas or anything else that could help, let me know. 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 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: abuse-contact-policy-proposal.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From info at streamservice.nl Mon May 3 11:19:12 2010 From: info at streamservice.nl (Stream Service) Date: Mon, 3 May 2010 11:19:12 +0200 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <4BDE819B.1050608@abusix.com> References: <4BDE819B.1050608@abusix.com> Message-ID: <0b0801caeaa1$b4904b30$1db0e190$@nl> > -----Original Message----- > From: anti-abuse-wg-admin at ripe.net [mailto:anti-abuse-wg- > admin at ripe.net] On Behalf Of Tobias Knecht > Sent: Monday, May 03, 2010 9:56 AM > To: anti-abuse-wg at ripe.net; Brian Nisbet; Richard Cox > Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal > > Hello, > > this proposal was planned to be published end of May. But so many > people asked me to publish it earlier and hopefully before RIPE-60 in > Praha, so I will. > > This proposal is more or less a copy of our proposals for AfriNIC and > APNIC. The APNIC proposal will be acknowledged today. The AfriNIC > proposal will be discussed in Kigali end of this month. > > I will not be able to come to RIPE-60, but I hope that this proposal > finds a little spot to be discussed in the Anti-Abuse Working Group > Meeting. > > If you have questions, ideas or anything else that could help, let me > know. > > 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 Hello Tobias, This proposal sounds great! Regards, Mark From ripe-anti-spam-wg at powerweb.de Mon May 3 11:44:17 2010 From: ripe-anti-spam-wg at powerweb.de (Frank Gadegast) Date: Mon, 03 May 2010 11:44:17 +0200 Subject: [anti-abuse-wg] Abuse Contact Information Message-ID: <4BDE9AF1.1080903@powerweb.de> Hi, I like to recommend the following extension to Tobias' proposal: I should be noted that access to personal objects via whois is currently limited, what blocks automated abuse report generation. It is likely that these limits also apply for IRT objects. I recommend to publish a list of all IRT-objects on RIPEs ftpserver for mirroring, maybe restricted to RIPE members only or to explicitly drop all limits for IRT queries (if somebody is concerned about email harvesting it should be clear that harvesting will happen anyway via whois, API or webservice, whatever limits are used). It should also be noted in the proposal that IRT-objects have to bereturned also via the whois "-b" option. Kind regards, Frank -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank at powerweb.de -- Mit freundlichen Gruessen, -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank at powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank at powerweb.de From tk at abusix.com Mon May 3 12:12:33 2010 From: tk at abusix.com (Tobias Knecht) Date: Mon, 03 May 2010 12:12:33 +0200 Subject: [anti-abuse-wg] Abuse Contact Information In-Reply-To: <4BDE9AF1.1080903@powerweb.de> References: <4BDE9AF1.1080903@powerweb.de> Message-ID: <4BDEA191.3020301@abusix.com> Hello together, > I like to recommend the following extension to Tobias' proposal: > > I should be noted that access to personal objects via > whois is currently limited, what blocks automated abuse > report generation. > > It is likely that these limits also apply for IRT objects. RIPE Database Query Reference Manual [1] says in chapter "2.12 Access Control for Queries" the following: "The control mechanism is based on the amount of contact information (contained in person and role objects) that is returned because of queries made for an IP address." Is the IRT Object a person or role Object? Is it handled the same way? Are there any restrictions? The other opportunity would be to use the new and really great AbuseFinder API [2] as soon as it is ready to use in production. > I recommend to publish a list of all IRT-objects on RIPEs > ftpserver for mirroring, maybe restricted to RIPE > members only or to explicitly drop all limits for > IRT queries (if somebody is concerned about email harvesting > it should be clear that harvesting will happen anyway via > whois, API or webservice, whatever limits are used). Restricted Access to a file is not the solution. What about non RIPE members like ISPs from the APNIC or ARIN region? Unlimited access to IRT Objects could make sense, but I would like to restrict it a bit more and let's say stop restrictions while using the "-b" flag. That would make 100% sense. That way it would be possible to query the addresses for automatic abuse handling (abuse-mailbox attribute), but secure the e-mail attribute for personal contact. > It should also be noted in the proposal that IRT-objects > have to bereturned also via the whois "-b" option. Over all I think this is something that should be thought about, but nevertheless it is not the main intention of this proposal to change query policies. It's about making the IRT Object mandatory. It's the decision of the community, if this proposal, shall be extended. Thanks, Tobias [1] http://www.ripe.net/db/support/query-reference-manual.pdf [2] http://labs.ripe.net/content/abuse-finder -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From Jamie.Stallwood at imerja.com Mon May 3 13:27:31 2010 From: Jamie.Stallwood at imerja.com (Jamie Stallwood) Date: Mon, 3 May 2010 12:27:31 +0100 Subject: [anti-abuse-wg] Abuse Contact Information References: <4BDE9AF1.1080903@powerweb.de> <4BDEA191.3020301@abusix.com> Message-ID: <7B640CC73C18D94F83479A1D0B9A140402AD3279@bhw-srv-dc1.imerja.com> Web forms are possibly easier to secure and possibly more reliable way to ensure reports are delivered? Maybe there is a case to have a abuse-webform: type object in the IRT? (perhaps a question for db-wg!) Kind regards Jamie Stallwood -- Jamie Stallwood Security Specialist Imerja Limited Tel: 07795 840385 jamie.stallwood at imerja.com -----Original Message----- From: anti-abuse-wg-admin at ripe.net on behalf of Tobias Knecht Sent: Mon 5/3/2010 11:12 To: anti-abuse-wg at ripe.net Subject: Re: [anti-abuse-wg] Abuse Contact Information Hello together, > I like to recommend the following extension to Tobias' proposal: > > I should be noted that access to personal objects via > whois is currently limited, what blocks automated abuse > report generation. > > It is likely that these limits also apply for IRT objects. RIPE Database Query Reference Manual [1] says in chapter "2.12 Access Control for Queries" the following: "The control mechanism is based on the amount of contact information (contained in person and role objects) that is returned because of queries made for an IP address." Is the IRT Object a person or role Object? Is it handled the same way? Are there any restrictions? The other opportunity would be to use the new and really great AbuseFinder API [2] as soon as it is ready to use in production. > I recommend to publish a list of all IRT-objects on RIPEs > ftpserver for mirroring, maybe restricted to RIPE > members only or to explicitly drop all limits for > IRT queries (if somebody is concerned about email harvesting > it should be clear that harvesting will happen anyway via > whois, API or webservice, whatever limits are used). Restricted Access to a file is not the solution. What about non RIPE members like ISPs from the APNIC or ARIN region? Unlimited access to IRT Objects could make sense, but I would like to restrict it a bit more and let's say stop restrictions while using the "-b" flag. That would make 100% sense. That way it would be possible to query the addresses for automatic abuse handling (abuse-mailbox attribute), but secure the e-mail attribute for personal contact. > It should also be noted in the proposal that IRT-objects > have to bereturned also via the whois "-b" option. Over all I think this is something that should be thought about, but nevertheless it is not the main intention of this proposal to change query policies. It's about making the IRT Object mandatory. It's the decision of the community, if this proposal, shall be extended. Thanks, Tobias [1] http://www.ripe.net/db/support/query-reference-manual.pdf [2] http://labs.ripe.net/content/abuse-finder -- Imerja Limited Tel: 0870 8611488 | Fax: 0870 8611489 | 24x7 ISOC: 0870 8611490 | Web: www.imerja.com Registered Office: Paragon House, Paragon Business Park, Chorley New Road, Horwich, Bolton BL6 6HG Registered in England and Wales No. 5180119 VAT Registered No. 845 0647 22 ISO Registered Firm No. GB2001527 This email is confidential and intended solely for the person or organisation to which it is addressed. It may contain privileged and confidential information. If you are not the intended recipient(s) you should not use, copy, distribute or take any action or reliance on it, since to do so is strictly prohibited and may be unlawful. If you have received this transmission in error please notify the sender immediately by email reply and delete it from your system. E-mail messages are not secure and attachments could contain software viruses which may damage your system. Whilst every reasonable precaution has been taken to minimise this risk, Imerja Limited cannot accept any liability for any damage sustained as a result of these factors. You are advised to carry out your own virus checks before opening any attachment. Any views or opinions expressed in this e-mail are solely those of the author and do not represent those of Imerja Limited unless otherwise stated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcoh at marcoh.net Mon May 3 15:21:44 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Mon, 3 May 2010 15:21:44 +0200 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <4BDE819B.1050608@abusix.com> References: <4BDE819B.1050608@abusix.com> Message-ID: <02A29992-EC58-465E-BDCA-068F818D0CBF@marcoh.net> (Wearing my private citizen head) > 4.3 Delete abuse-mailbox fields in all objects that do not define an IRT, and delete > the trouble field everywhere in 2011. This is a really bad idea, there is no guarantee those objects will allready be updated to link to an IRT object, nor is there a guarantee those objects will ever be updated to start linking to IRT. So you end up throwing away perfectly good data and end up with even more difficulties to find contact details. Marco From mark at streamservice.nl Mon May 3 16:57:02 2010 From: mark at streamservice.nl (Mark Scholten) Date: Mon, 3 May 2010 16:57:02 +0200 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <02A29992-EC58-465E-BDCA-068F818D0CBF@marcoh.net> References: <4BDE819B.1050608@abusix.com> <02A29992-EC58-465E-BDCA-068F818D0CBF@marcoh.net> Message-ID: <0b9001caead0$e3dfc2b0$ab9f4810$@nl> > -----Original Message----- > From: anti-abuse-wg-admin at ripe.net [mailto:anti-abuse-wg- > admin at ripe.net] On Behalf Of Marco Hogewoning > Sent: Monday, May 03, 2010 3:22 PM > To: anti-abuse-wg at ripe.net > Subject: Re: [anti-abuse-wg] Abuse Contact Information - Policy > Proposal > > (Wearing my private citizen head) > > > 4.3 Delete abuse-mailbox fields in all objects that do not define an > IRT, and delete > > the trouble field everywhere in 2011. > > This is a really bad idea, there is no guarantee those objects will > allready be updated to link to an IRT object, nor is there a guarantee > those objects will ever be updated to start linking to IRT. So you end > up throwing away perfectly good data and end up with even more > difficulties to find contact details. Is it acceptable for you if this is done when there is an IRT (and require it to have an IRT before 2013)? Mark From marcoh at marcoh.net Mon May 3 17:23:20 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Mon, 3 May 2010 17:23:20 +0200 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <0b9001caead0$e3dfc2b0$ab9f4810$@nl> References: <4BDE819B.1050608@abusix.com> <02A29992-EC58-465E-BDCA-068F818D0CBF@marcoh.net> <0b9001caead0$e3dfc2b0$ab9f4810$@nl> Message-ID: <3904EF53-1A4D-48EE-AEE4-596CEE0E221F@marcoh.net> > Is it acceptable for you if this is done when there is an IRT (and require > it to have an IRT before 2013)? I don't think you can 'require it to have an IRT by 2013', there are orphans and stale object, those will not magically will get an IRT attached. But we are getting into details where I think we first have to see where this proposal goes. I merely just pointed out there was a design oversight. Now concerning the proposal, IMHO it won't solve any of the problems. You get less data, but still no guarantee it's there or it's correct. This does not add anything compared to the current model. As a simple and alternative suggestion: Make the abuse-mailbox atrribute mandatory for inetnum and inet6num That was the original proposal at the start of the century when we introduced the abuse-mailbox stuff, by that time there was also a very lenghy discussion on IRT being an alternative. Please refer to the archives of the database working group for records on these discussions. Marco (as a private citizen) From tk at abusix.com Mon May 3 18:17:16 2010 From: tk at abusix.com (Tobias Knecht) Date: Mon, 03 May 2010 18:17:16 +0200 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <3904EF53-1A4D-48EE-AEE4-596CEE0E221F@marcoh.net> References: <4BDE819B.1050608@abusix.com> <02A29992-EC58-465E-BDCA-068F818D0CBF@marcoh.net> <0b9001caead0$e3dfc2b0$ab9f4810$@nl> <3904EF53-1A4D-48EE-AEE4-596CEE0E221F@marcoh.net> Message-ID: <4BDEF70C.7000604@abusix.com> Am 03.05.2010 17:23, schrieb Marco Hogewoning: >> Is it acceptable for you if this is done when there is an IRT (and >> require it to have an IRT before 2013)? > > I don't think you can 'require it to have an IRT by 2013', there are > orphans and stale object, those will not magically will get an IRT > attached. But we are getting into details where I think we first have > to see where this proposal goes. I merely just pointed out there was > a design oversight. Just for clarification. This part came from the plan by APNIC to do something like an yearly frequent update request in combination with not having something like abuse-mailbox attributes or anything else activated in the whois database. The idea was to ask every member to update or accept their whois records once a year actively. Like .com registrars doing it already. I think this is a good idea as well, and this is brought into a proposal for APNIC very soon. I think we should agree on not accepting to create new or change abuse-mailbox attributes after a specific date. That is absolutely fine with me. If there will be a proposal where network owners will be forced to update their whois records yearly, we could put the cleanup into this proposal as well. > Now concerning the proposal, IMHO it won't solve any of the problems. > You get less data, but still no guarantee it's there or it's correct. > This does not add anything compared to the current model. Exactly and this is the reason, why this proposal is a good one in my opinion, it's not adding anything, but it makes it far easier to understand the data. The point with this proposal is, that it should give a understandable definition how abuse contact information "have" to be published. This proposal shall show only a single place where abuse contact information can be found and not several that create confusion even within the RIPE members community. Another advantage is the fact that APNIC and probably AfriNIC will use the same way, which makes things much more easy on a global sight. > As a simple and alternative suggestion: > > Make the abuse-mailbox atrribute mandatory for inetnum and inet6num We discussed that as well, but there were several things that made it more complicated. 1.) there is no abuse-mailbox attribute within the inetnum and inet6num objects. That means this will need a major change in database. 2.) There is only the opportunity of publishing an email-address. Where do you want to publish further information? Phone numbers a personal contact address, ...? 3.) IRT-Objects exists, it's already there, The only thing that has to be changed is the fact that it has to be mandatory and contains a mandatory abuse-mailbox attribute. > That was the original proposal at the start of the century when we > introduced the abuse-mailbox stuff, by that time there was also a > very lenghy discussion on IRT being an alternative. Please refer to > the archives of the database working group for records on these > discussions. I have read the really interesting discussion. Both ideas, IRT-Object and abuse-mailbox attribute are good. That's the reason why we are using both in our proposal. We just change the place where it should occur. Thank you for your feedback. Tobias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From brian.nisbet at heanet.ie Tue May 4 11:01:47 2010 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Tue, 04 May 2010 10:01:47 +0100 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <4BDE819B.1050608@abusix.com> References: <4BDE819B.1050608@abusix.com> Message-ID: <4BDFE27B.3010908@heanet.ie> Tobias, > this proposal was planned to be published end of May. But so many people > asked me to publish it earlier and hopefully before RIPE-60 in Praha, so > I will. > > This proposal is more or less a copy of our proposals for AfriNIC and > APNIC. The APNIC proposal will be acknowledged today. The AfriNIC > proposal will be discussed in Kigali end of this month. > > I will not be able to come to RIPE-60, but I hope that this proposal > finds a little spot to be discussed in the Anti-Abuse Working Group Meeting. Thanks for this submission. I think that the best course of action is to discuss it on Thursday and get some additional feedback on the proposal. We'll then take what's been said on list, combine the two and we'll contact you with the plan of putting this into the RIPE policy development process. Regards, Brian. From leo.vegoda at icann.org Wed May 5 20:00:09 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 5 May 2010 11:00:09 -0700 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <4BDE819B.1050608@abusix.com> References: <4BDE819B.1050608@abusix.com> Message-ID: <2554CD8F-9E32-4CF6-9F19-DECABCA99473@icann.org> Hi, On 3 May 2010, at 12:56, Tobias Knecht wrote: > > this proposal was planned to be published end of May. But so many people > asked me to publish it earlier and hopefully before RIPE-60 in Praha, so > I will. > > This proposal is more or less a copy of our proposals for AfriNIC and > APNIC. The APNIC proposal will be acknowledged today. The AfriNIC > proposal will be discussed in Kigali end of this month. > > I will not be able to come to RIPE-60, but I hope that this proposal > finds a little spot to be discussed in the Anti-Abuse Working Group Meeting. On the proposal to "Institute a mandatory reference to an IRT object in inetnum, inet6num and aut-num objects." I note that there does not seem to currently be a technical need for this. According to the query reference manual: "Not every inet(6)num object needs to contain a reference to the irt object that applies to its range. A reference to an irt object does not apply only to the inet(6)num object that contains the reference. It also applies to all the inet(6)num objects that are 'more specific' to the one containing the reference. The irt reference only needs to be placed in the least specific encompassing object to apply to a whole hierarchy of objects. This makes it easier to apply and maintain." Also, I suspect that the requirement to add a reference to an IRT object when updating an inet(6)num will just result in fewer updates and an additional degradation in the quality of the registration and contact data provided. It is possible that I am wrong, so as a similar proposal has already been accepted by APNIC, perhaps this section of the proposal could be delayed until APNIC can present data showing the effect of this part of the policy on their data quality. Regards, Leo From tk at abusix.org Wed May 5 23:27:27 2010 From: tk at abusix.org (Tobias Knecht) Date: Wed, 05 May 2010 23:27:27 +0200 Subject: [anti-abuse-wg] Abuse Contact Information - Policy Proposal In-Reply-To: <2554CD8F-9E32-4CF6-9F19-DECABCA99473@icann.org> References: <4BDE819B.1050608@abusix.com> <2554CD8F-9E32-4CF6-9F19-DECABCA99473@icann.org> Message-ID: <4BE1E2BF.6000506@abusix.org> Hello > Also, I suspect that the requirement to add a reference to an IRT > object when updating an inet(6)num will just result in fewer updates > and an additional degradation in the quality of the registration and > contact data provided. It is possible that I am wrong, so as a > similar proposal has already been accepted by APNIC, perhaps this > section of the proposal could be delayed until APNIC can present data > showing the effect of this part of the policy on their data quality. Just a few words to this. I know that this proposal is just the first of a row of proposals that will lead to a more perfect system. ;-) For example. I start working with the APNIC policy office on the so called "frequent update request" proposal. This is a service APNIC wanted to start, but wanted to have a feedback from their members, that's why a proposal will be released. This "frequent update request" proposal shall find a way how APNIC (later AfriNIC and RIPE) can contact their members and requests perodically (yearly) updates or verifications on all objects. This proposal plans to solve problems like you and Marco Hogewoning mentioned. The idea for this proposal is not new. .com registrars are already having such mechanisms in place, and they work pretty well, as we have heard. At the end this first proposal shall just define a way where abuse contact information has to be in future and how this has to be handled with new ranges and with updates. The next proposal can find a way of requesting frequent updates. It's a step by step plan, but we should start somewhere. ;-) Thanks for your comments. Have all a nice RIPE-60 a good discussions tomorrow. Tobias From tk at abusix.com Fri May 28 21:11:47 2010 From: tk at abusix.com (Tobias Knecht) Date: Fri, 28 May 2010 21:11:47 +0200 Subject: [anti-abuse-wg] IRT-Object Documentation Message-ID: <4C001573.8080306@abusix.com> Hello together, we are asking lots of people every day to add IRT Objects to their inet(6)num. And several people started to do so in the last weeks, which I think is pretty cool. But a lot of people who want to create an IRT Object usually go to any search engine and look for "irt" and "ripe" and the first link they get is this one: http://www.ripe.net/db/support/security/irt/ But this link is really outdated. For example: signature: [mandatory] [multiple] [ ] encryption: [mandatory] [multiple] [ ] are not mandatory anymore, regarding to this document http://www.ripe.net/db/support/update-reference-manual.html#1.2.9 A missing fact for example is the abuse-mailbox attribute which is missing and should be inserted like this: abuse-mailbox: [optional] [multiple] [inverse key] Could please anybody at RIPE update this FAQ article or delete it and forward it to correct documentation, since people who want to use it get irritated by different information on the RIPE website. If this is the wrong working group, I'm sorry, please let me know which would be a better place to ask for this. Thanks and have a nice weekend. Tobias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: