> Presumably in the situation you quote, would that not be the IRT object? > > The danger I see in this proposal is another mailbox field (ether direct or inherited) which actually adds no clarity and falls into disuse. > > are you proposing this in the ripe community? Or is IRT adequate there? (since you quote it in the policy but don't elude to effectiveness) > > note that APNIC also has the IRT object. Yes the IRT Object would do it. Whenever I didn't notice that APNIC has an IRT object, because we have never seen an IRT Object in the APNIC Database. The problem with the IRT Object is, that nobody knows what it is. We see that at RIPE every day. When we suggest people to publish one. But to be honest I have to rethink this proposal if there is an IRT Object in place. (1) There must be a future policy that talks about frequent update requests. (2) Why not making the IRT-Object mandatory. (That's what we will try at RIPE as well) >>> The website lists: >>> >>> "trouble | Can be used to include details on where to send abuse >>> complaints." >>> >>> and while it reflects a set of data: >> And how do you parse this? >> >> trouble: Don't send any abuse reports to abuse at domain dot tld >> >> or >> >> trouble: Send abuse reports to abuse (at) domain (dot) tld >> > > Fair point.. although I don't think i've seen the former example. whois 131.111.0.0/16 | grep remarks Okay, it's not APNIC and it is not a trouble, but such things exist. >> One point for all abuse information. To be honest I think after getting >> this proposal aknowledged there would be a perfect follow up to get rid >> of abuse-mailbox and of trouble fields because they are not neccessary >> any more. >> > > so above you say "flexibility".. and here you say "simplification" (paraphrasing). > > Maybe you can combine the approaches? I would like to to. So if there are ideas on how we can put everything needed in one or 2 or 3 poroposals, I'm absolutly happy to do that. >> IMHO this is nothing that has to be cleared in this proposal, but > > I disagree.. The results of this proposal requires APNIC to do *something*. > > The extent of that *something* is not clear. Full-ACK, but does it make sense to define to have an update request for an abuse-c (IRT) and leave out the other fields? And does it make sense to add this request for all others roles and person objects into a proposal about abuse-c (IRT). >> nevertheless this is a good question. After some other comments I >> started to think about a quiet different solution. >> >> How about making the filed mandatory for new allocations. That would be >> not a problem. Let it open for existing allocations. That way you do not >> have the above mentioned problem. And the second and more important >> thing is, that you exactly know that the abuse-c fields are okay, >> because they are new. So data should be accurate. > > So in a database schema you are actually making the field "optional" but institutionally recommended for new allocations. No need to do make it mandatory in the databse schema. You can just make it mandatory in the application. But even that was just an idea. >> In addition with another proposal of deleting trouble-fields and >> abuse-mailbox attributes will force lot's of poeple adding abuse-c >> fields. So they are new again. Last but not least finding a way of >> keeping the data accurate this would work perfectly in my opinion. > > I look forward to your amended proposal. Me too ;-) >>> "more and more" appears vague. do you have any statistics? (section >>> 2) >> We have a statistic about how many IP ranges do not have propoer abuse >> contact information. And we have a round 20 ISPs within APNIC asking us >> to change the address were we should send abuse reports to. > > is that: > 1) because they don't want to get the reports from you? > or > 2) because they _trust_ you and want you to have a good contact point, but not some 'others'? It's about receiving loads of reports from us and others at a personal tech-c address. >> But we are >> working automatically so we any many other reporters in the world would >> like to see the single point of abuse-contact in the SPNIC whois >> information. >> > > how many reporters? and what is the breakdown of them, ie ISP, LEA, CERT, ABUSIX-type org?? There is a govermental project going on in Germany and spreading to Europe at the moment. This project calls any kind of institution that has abuse data available to share it with the responsible partner. At the moment this project is aknowledged, but there are still some minor things to fix. So the things we (abusix) is doing is just a first step of what will hapen in future. There are already some ISPs testing their reporting mechanisms. But not really high volume. >>> I believe your disadvantages are understated. The examples above >>> suggest that the whois data is not consistent to the whois schema. >>> Adding a further change bites into a whois database consistency >>> issue, that really shouldn't exist, but does where the APNIC >>> secretariat will probably need to expend significant resources on >>> rectifying, provided they have resources to spare. >> The abuse-c is nothing else than an object somebody can link a handle >> (role or person) to. I can not see a problem with inconsistency. >> > > The inconsistency appears to exist already. It will no doubt cost resources to fix. > (ie objects with attributes that don't conform to schema/templates) So in adding this new object, a prudent organisation would clean up the data they had already, or at least do so in the process of adding the abuse-c attribute. The same would happen if we make the IRT Object mandatory ?!?! >>> I would suggest that serious levels of contact information is not >>> found in whois, and if you wanted to try to 'force' the information >>> out of member organisations via the RIR I would suggest an RIR >>> facilitated LEA or 'trusted entity' web portal that provides a deeper >>> look into networks (under the conditions of the membership agreement) >>> to be of more use as less organisations would redirect those contacts >>> to /dev/null >> Full Nack. >> I don't like trusted entity webportals. Because you will always need >> somebody to decide what ist trustworthy and what is not. And my feeling >> about trust might be different from yours and the others. So who should >> decide that? >> > > Trust in that space is a contractual item, and limited to those who are capable of meeting it. law enforcement agencies , national/state CERT teams, etc. IMHO that is not right. Trustlevels are a personal decisions. I have to decide who is trustworthy and who is not. Everybody has to do so. I do not want to have an internet that tells me and others who is trustworthy. I have to understand to goals of everybody to make the decsion if I wanna trust or not. And there are even governmental decisions or goals that won't fit in my personal world. So I will not support and trust these ideas. And why are we or you or anybody else less trustworthy than a cert or a governmental institution? >> As already mentioned above. We can not force anybody to be good. But we >> can help them who decided to be good to get better. This proposal is for >> all the APNIC network owners that send us emails and told us, that they >> wanna handle their abuse and asked us to change the addresses, because >> they have an abuse department, but no chance to publish their stuff in >> an appropriate way. >> > > So 20 ISPs? yeah (from above)? So you want to make a change that provides 20 APNIC members with use of abuse-c. (of a membership of 2000+ members?) That's what we know about. And if these 20 ISPs can make a better job with this proposal, it's worth doing so. My opinion. Thanks, Tobias
Attachment:
signature.asc
Description: OpenPGP digital signature