On 21 Jun 2012, at 22:49, lists@help.org wrote:

...

"Phase one: Implementing the policy" will include a new whois switch being introduced

This will break existing software that makes whois queries for IP's. When you run an IP for possible abuse you don't want one command for ARIN and a different command for RIPE. That is why this issue must be coordinated between different RIR's. Inconstant whois policies is cited as a problem in the latest ICANN whois report and comments:

http://www.icann.org/en/news/public-comment/whois-rt-final-report-11may12-en...

The WHOIS RT report is about domain names and whois. It is NOT about IP addresses Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ http://mneylon.tel/ Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845

"Michele Neylon :: Blacknight" wrote: Hi,

On 21 Jun 2012, at 22:49, lists@help.org wrote:

...

...

"Phase one: Implementing the policy" will include a new whois switch being introduced

This will break existing software that makes whois queries for IP's. When you run an IP for possible abuse you don't want one command for ARIN and a different command for RIPE. That is why this issue must be coordinated between different RIR's. Inconstant whois policies is cited as a problem in the latest ICANN whois report and comments:

http://www.icann.org/en/news/public-comment/whois-rt-final-report-11may12-en...

The WHOIS RT report is about domain names and whois.

It is NOT about IP addresses

A new switch will not break anything, because: - IP whois switches are already different between the RIRs, some RIRs support some switches, others dont (why should there be special RIPE version of the whois program itself, developed by the NCC, when they are all the same ? and why should there be and open source whois, like jwhois that tries to follow all different whois service implementations ?) - some RIRs return objects wich dont belong to them, that might be good or not, but its different - all RIRs have really different objects they store abuse contact information in some examples: doing a whois for an korean IP at APNIC returns objects copies from KRNIC in a really different format compared to what KRNIC supplies, same (and even worse with JPNIC) APNIC uses IRT objects to store abuse contact information, but IRT isnt used much there, most objects arent updated and still use remarks and abuse-mailbox AFRINIC and LACNIC have no IRT AFRINIC is not supporting -B (or I simply did never find an object where it makes a difference) ARIN has about 5 different places ot look, like OrgAbuseHandle and RAbuseEmail, OrgTechEmail or RTechEmail and more LACNIC is proxying all RIRs, but is sometimes simply wrong (simply because they dont supply all whois switches, that RIPE supports) ARIN should be able to at least tell wich RIR is responsible for with network, but this fails. I know a lot of networks (and not only legacy/ERX), where ARIN cannot tell and you have to look at ALL RIRs, to find the right RIR. (btw: somebody pointed out here once, that IANA is not an operational organization, they are at least in one case, because they are supplying whois.iana.org with could be used to find the right RIR for an IP object, but this also fails, because sometimes they dont even know) So, things ARE already broken, our whois parser (and the parsers of all blacklists) knows already about 50 different cases. - inserting a new switch will not turn old switches off - my idea was to really have ONE switch to find the abuse contact email address, simply because we on this list know, where to look, but no normal user knows about all these differences, maybe this switch will then also be implemented at other RIRs - RIPE NCC is having the abuse finder tool, but is not supllying it via whois or any non interactive way, what is sad But again: I simply wanted to have comments, if something likes this should be in the implementation section of the draft or if that should be done later. I think it should be in, because one big reason FOR the proposal is to HAVE one place where to store the abuse contact information and this should be also expressed in the implementation. Having this implemented will also cover the period, where some objects arent touched yet and still store the abuse contact information in old places. This will stop us from having the current situation at APNIC, where the new IRT object is making the situation worse (this was also critizised here). So: implementing a new whois switch including the fallback to the abuse finder tool result will technically lead to the result intended by the draft. Kind regards, Frank

Regards

Michele

-- Mr Michele Neylon Blacknight Solutions Hosting& Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ http://mneylon.tel/ Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845

-- Mit freundlichen Gruessen, -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ======================================================================

I would agree with all the discussion about the various RIR's. Something being "broken" is a matter of perspective so there is no point in arguing over that. I think it highlights the need for at least some kind of standard across the RIR's even if it it is inadequate at this time. It seems to be a waste of time to develop all kinds of local standards. As for the overall process the "outrage" comes from people who keep claiming a "consensus" when the truth of the matter is that most people have no idea what is going on. Millions of people use the domain and IP whois databases every day. There are many automated possibilities for security and these services are being inhibited by a poor whois system. It isn't going to get improved if people can't even figure out what is going on without spending half their life going through transcripts of meetings.

Hi Gilles, first of all thank you for your feedback.

This said, reading the Impact Analysis I see two points that worries me.

Under A.: "The "abuse-c:" attribute must reference a role object".

The policy text does not specify 'role'. And I see no good reason for the NCC to interpret the policy that way. (btw, if a policy needs interpretation even before it is implemented then maybe it might need some refining)

I did that on purpose. :-) The first version of this proposal was very technical and did not really take care about internal RIPE NCC things. The idea now was to shorten it to a minimum and let the maintainers of the DB, the RIPE NCC tech staff, come up with a starting point for further discussion. RIPE NCC tech staff has much more experience in developing and maintaining their database, than I will ever have. ;-)

Under C, phase two: I was under the impression that the policy was to be voluntary at first, and that the mandatory part was to be discussed further on, ideally with some information about the uptake of the object. Now I missed when the restrictive appeared in v.2 of the draft appeared...so be it. But now "The RIPE NCC will also plan to decommission irt objects...".

So if the current, short and simple, policy text is used to sneak in undiscussed features via the impact analysis I have no choice but to object.

I think this is not a completely undiscussed topic at all. We have already talked about the future of the IRT Object. And undiscussed issues are one of the reasons, that Emilio last week and Brian today asked for feedback. I do not see RIPE NCC sneaking in undiscussed features. RIPE NCC was asked to make a suggestion on how to implement the policy text into DB. The irt issue is part of the clean-up that I talked about in the proposal. RIPE NCC just described it in the way they would implement it. Thanks for your feedback, Tobias

Hi,

I certainly hope so :) It certainly makes sense to include feedback from NCC. But if that feedback shows that the policy text is interpreted, then the policy text should be amended accordingly.

I do not see this as a problem at all, quit the opposite. The proposal asks for a place to store abuse contact information and some non technical features around that. As a proposer I do not care about the way it will be implemented. That's one of the reasons a TF was created to get as much input from RIPE NCC tech staff as possible and come up with the best possible way from their point of view. And in this case I appreciate interpretations that make sense.

A fundamental statement of the RIPE NCC is not to create policies, but to implement the policies coming from the community. A large part of its credibility comes from that setup.

RIPE NCC does not create policies. The question is where to put the line between what is a policy and what is implementation. I think on the other extreme it does not make sense if community dictates RIPE NCC how to implement things. Because at the end RIPE NCC has to run and maintain the DB and not the community. But that is a tricky questions that probably can never been answered completely.

So for the 'role' thing: for a proper process either the RIPE NCC feedback needs a clear technical reasoning on why this MUST be role objects, or the requirement should be dropped, or it should be included in the policy text (and then I'd still like to know why).

I maybe have a clue why it's the role object, but I'm not sure. Maybe it's the part about personal and non-personal data. But hei, let's just ask. Does anybody know and I bet people who wrote the impact analysis do, why this should be a role-object?

It has been mentioned several times - but the discussion has always been postponed until after the abuse-c. From your last email on that topic (unless i'm mistaken):

"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."

Although it seem the wrong way around, I can even live with that...and won't go into further details

I can live with that as well. And I will propose this to RIPE NCC, that we will have a look at irt later on.

If it was only discussing possible ways forward, then the wording is appropriate. I'd go even further: supposing that if you need a policy to create an object, I'd expect the same to deprecate one. Any comment from the NCC beyond 'and in case of clean-up the IRT object needs consideration' would be a step into policy-making territory.

Agree. So let's keep the irt discussion out of this policy proposal and review this later. Makes a lot of sense to me and keep focus on the main intend of the proposal.

Now don't get me wrong, I do not suggest that the text from the NCC is a deliberate attempt to avoid a discussion or policy. But the fact that it does exists makes me suggest to have a more narrow policy text, with an explicit reference that IRT objects are to be handled later on.

I think that should be possible. @Emilio, can we change the irt part and add something like this to it. I think it does not hurt in anyway, neither technical nor from a policy perspective. Thanks, Tobias

Thanks Denis for this clarification. Tobias On 25.06.12 16:15, Denis Walker wrote:

Dear Colleagues,

Here is some background information to provide an insight into the reasoning behind the impact analysis and proposed implementation plan made by the RIPE NCC for policy proposal 2011-06.

The RIPE NCC attended the meetings of the RIPE Abuse Contact Management Task Force (ACM TF) to understand the requirements and the underlining issues and advise on implementation details. We have also followed all the discussions on the mailing list. Several points have been raised and the RIPE NCC has been asked to clarify some of these points.

From the proceedings we understood the requirement is to have a single location in the RIPE Database to store abuse contact details for any Internet resource and for this to be applied hierarchically to minimise management effort by the users and avoid unnecessary data duplication in the database.

The reasoning behind the selection of a ROLE object for the task is partly based on our interaction with RIPE NCC member organisations. We understand that abuse handling in the real world is a role within an organisation. It therefore makes sense to map it directly to the ROLE object within the database.

Also the original intention of the database design was to represent people by PERSON objects and to group people into roles using ROLE objects. Then only ROLE objects should be referenced in any other data objects. This avoids a situation which the RIPE NCC is regularly asked to help with when a person leaves a company and in some cases is directly referenced in tens of thousands of objects. This methodology is explained in the RIPE Database Update Reference Manual, but was never enforced in the database software.

The proposal for decommissioning the IRT object was discussed briefly by the ACM TF. The RIPE NCC pointed out that with a general abuse handling ROLE defined, the IRT can be seen as a special case of the general ROLE. It would simplify the user interaction with RIPE database as well as the database design and management if the two were combined. The only reason that it was mentioned in the impact analysis was to point out the similarity of use cases and suggest a review if the policy passes. The RIPE NCC fully supports the view of the policy proposer to consider these as separate issues. The use of the phrase "plan to decommission IRT objects" in the impact analysis was not meant to imply the RIPE NCC would just go ahead and do it. Our intention was to raise the awareness with the community of the similarities of use and seek approval, or otherwise, to merge the IRT functionality with the more general "abuse-c:" implementation.

The Abuse Finder tool available through the ripe.net website is a first iteration. We found it very difficult to define a proper scope for heuristics to identify the correct abuse contacts for any given resource with the current abuse contact documentation methods. A number of users have reported issues with this tool providing the wrong contacts. We held back from modifying the logic pending the outcome of the 2011-06 proposal. If the community agrees on a new method of storing abuse contacts the RIPE NCC will re-write the Abuse Finder tool to use the new contact details. As we have recently re-implemented the RIPE Database query service from scratch, we can also integrate the Abuse Finder directly into the query logic. It will then also be available through a web interface and by the RESTful API.

During the transition from the current swamp of abuse contact data to the 2011-06 method (if approved) the RIPE NCC will aim to provide user tools to assist with updates, where possible.

We hope this answers some of the questions raised regarding the implementation of the policy proposal 2011-06.

Regards, Denis Walker Business Analyst RIPE NCC Database Group