On 04/17/2012 11:04 AM, Frank Gadegast wrote:

- the abuse-c will remove all other appearances of abuse contact

nah, won't. but we had that (you can find it in the ml archive if you lost it) regards, Chris

On 04/17/2012 11:46 AM, Tobias Knecht wrote: [...] folks, just read what i already wrote. as i said, essentially nothing has changed. there's no point in going thru all this again. it's all there already. if you lost it, there's the archive (hint: 20111207). follow-ups welcome (i.e. questions that haven't already been answered). regards, Chris

On 17.04.12 11:57, Chris wrote:

On 04/17/2012 11:46 AM, Tobias Knecht wrote: [...]

folks, just read what i already wrote. as i said, essentially nothing has changed. there's no point in going thru all this again. it's all there already. if you lost it, there's the archive (hint: 20111207). follow-ups welcome (i.e. questions that haven't already been answered).

As far as I can see you had 3 main issues with the proposal that time. First was the implementation, which we left out completely this time to concentrate on the main issue of "one" specific abuse contact. As stated in the proposal the implementation will be discussed later after RIPE NCC has done an implementation plan. Second was, that you haven't seen a positive effect because you say that things will stay in the database and we just add another object that makes things more complex. That is in fact only partly true. There is no automatic way of deleting remark fields with abuse contact (freeform in a DB is nearly always a mess). From that perspective we have to wait until maintainers are changing their information. But the remark fields will get obsolete, because there will be an abuse-c in place. So there is already a point that get's less complex and this will be the way people can find abuse contact information. And not only people, RIPE NCCs Abuse Findertool will be able to parse them as well, what is not possible at the moment. The other side, when we are talking about abuse-mailbox attributes. We will not get rid of them, but this proposal will led into a situation where the abuse-mailbox attribute is only shown on whois and other outputs if it is related to an abuse-c. That makes the output again less complex, because there is only "one" abuse-mailbox attribute in a whois output and not 3 with different addresses. In addition to that we have a clear differentiation between personal data and role accounts, which can be communicated by the RIPE NCC when the object will be published. So I can not see any increase of complexity as I couldn't see it in December 2011. The third issue you had, was bulk spamming. I can see it and I can understand this issue. Nevertheless I have to say, that there are already techniques that can solve this problem and would also solve the problem you have at the moment with bulk spamming. So this is not a new problem at all, it is already a problem that needs to be fixed. Besides the implementation, which will come from RIPE NCC and can be discussed further in a later step I see less complexity and operational overhead for resource holders as well. I haven't seen most of your points in late 2011 and I do not see all of them now. Maybe I'm just coming from another corner. Since Community agreed on setting up a Task Force and work on this issue and try to fix the mess in the Database which is as well recognized by RIPE NCC staff with this word "mess" there must be something true about it. Even if it is only something little. So the question is not only what you do not like about the proposal, it's more about how can we fix it. And you haven't come up with ideas about a solution in December. So maybe you have ideas know and want to share them. Thanks, Tobias

On 17.04.12 11:55, Gilles Massen wrote:

On 04/17/2012 11:04 AM, Frank Gadegast wrote:

...

- the abuse-c will remove all other appearances of abuse contact information

If that is true, then please have it say so in the proposal. Currently I worry about the IRT object which is my view more valuable (as in 'complete') than the abuse-c. And the requirement could well be 'have either one (XOR preferred over OR for data consistency) for each inetnum'.

But it really needs to be defined (and/or discussed) beforehand.

First of all thanks for your input and sorry for my delayed answer. I wanted to check with some people here at RIPE 64 about this. I would not tackle the IRT Object in any way with this policy proposal, because imho the IRT object is more used by Certs and not really used by Abuse Departments. The first version of this proposal was going into your direction and was suggesting to use the IRT Object as place for the abuse contact information as well, but in the Task Force we decided that this might be not the right place, for the mentioned reasons. There might be the idea of renaming the mnt-irt into irt-c just to make it more clear, that it is a contact, but this is something we can come up in the RIPE NCC impact analysis. I think we should wait and see how the IRT Object will be handled after this proposal is in place and may be there can be a decision about keeping the IRT Object in place or not, or maybe even changing it to it's origin idea. But I would not like to have this decision in this proposal since it is a different discussion. Hope that helps and thanks again for your input. Tobias

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 19/04/2012 16:37, Adrian wrote:

Are the folks using IRT Objects at a larger scale (e.G. TI) included in this discussion?

I've never seen an IRT object that wasn't created through the TI community. I'll send TI an e-mail to make them aware of this thread. James - -- James Davis 0300 999 2340 (+44 1235 822340) Senior CSIRT Member Lumen House, Library Avenue, Didcot, Oxfordshire, OX11 0SG -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+QMysACgkQjsS2Y6D6yLyhxAD+Ozqv9fJSlwQuOTpoEHKSj/m+ yA0fePy292Rtcr1ScmwBAIQnFto9DmgEL7LptNlVVeuHXJApAs0R7elGizzvJ+sS =HMkn -----END PGP SIGNATURE----- Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

Hello, as promised I asked RIPE NCC staff to provide some stats on IRTs. Thanks for answering that fast. I got the following stats. At the moment there 276 IRT Objects in the DB. The address space covered by these IRT Objects in not trivial to calculate so I do not have numbers on that. But we have stats that are about 4 years old, which tell us that there have been 121 IRT Objects in the DB. These 121 IRT Objects covered 1,7% of the address space that time. That means we have an increase of IRT Objects of approximately 40 per year over the last 4 years. If the coverage factor is still the same we should end up at approximately 3,8 or let's say 4 or even 5% of the address space. Knowing these numbers makes it in my opinion even more clear, that the IRT Object is not a widely used object and there is a lot of space for improvement. How ever this improvement looks like. That's why I would like to wait for an implementation of the abuse-c if we find consensus on that and look at the numbers of the IRT Objects again and start making decisions on what should happen with it. From my perspective at the moment there is everything possible. Discontinuing, changing it or letting it as it is. But that will be a community discussion and decision at that time. Thanks, Tobias On 19.04.12 17:45, James Davis wrote:

On 19/04/2012 16:37, Adrian wrote:

...

Are the folks using IRT Objects at a larger scale (e.G. TI) included in this discussion?

I've never seen an IRT object that wasn't created through the TI community. I'll send TI an e-mail to make them aware of this thread.

James

Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG