Hi Sascha, On 15/10/2012 16:27, Sascha Luck wrote:

That is exactly why I strongly oppose this proposal. Publishing the sponsoring LIR for a PI assignment creates an appearance of responsibility on the part of the sposoring LIR, for the actions of the PI assignee, *that does not exist*.

thanks for your comments. Can you explain how this link doesn't exist if the sponsoring LIR has requested RPKI certification on behalf of the PI end user, and why this contractual link is invalid in this situation?

Registering this administrative relationship creates an attack surface for harassment and extortion of sponsoring LIRs by copyright trolls, anti-spam extortionists and others of that ilk and infringes on the right of a business (such as a LIR is) not to reveal any and all commercial relationships they may have with other parties.

Much the same argument could be made about the requirement to register PA address space assignees in the RIPE DB. Yet we accept that this is a good thing. Nick

On 15/10/2012 17:48, Sascha Luck wrote:

That is an argument against RPKI rather than one in favour of sponsoring-LIR registration, IMO. To whit, the imposition of a hierarchical structure on a non-hierarchical internet and the creation of "chains-of-responsibility" from thin air where none exist (and shouldn't exist). It would be better to have the end-user rpki-register their own resources with the RIR (who can easily verify their validity)

Nevertheless, we are where we are and although you may not like RPKI, it exists and we have to deal with. Part of this is to put sensible policies in place to handle it. Regarding PI resources, a contractual link between the RIPE NCC and the end user exists, and the NCC has implemented RPKI using this chain of contracts. Changing this would require a direct contractual link between the end user and the RIPE NCC. If you want to change it, then why not fly a policy proposal in that direction? Or if you feel strongly enough, float a policy proposal to drop rpki? But as it is, my point stands: there is no easy visibility into the rpki contractual side of things according to current RIPE policy, and this is a weakness which harms abuse handling. This, btw, is separate to the general abuse issue noted in the "Arguments For" section of the proposal for providing a mechanism for being able to contact a LIR to apply their AUP to an abusing End User. Not sure why you're arguing that there is a problem with it. Abusing end users exist and hide where they can.

Not all of these relationships are actually registered, viz DSL or wireless broadband dynamic ranges.

No, not all, but every one where the address range is >= /29. This is a very large number of assignments indeed.

With PI it's not the same situation *at all*. PI space is provider-*independent* and thus may be one last way to prevent a LIR becoming collateral damage in an attack on the end-user (eg a politically controversial organisation)

This makes very little sense. If there's a perceived issue with a PI resource End User, then their legal name and contact details are already in the RIPE database so for the most part, it will be the end user who gets the flack. And if for some reason their LIR ends up with collateral damage and feels they need to drop them as clients (I'm sure this happens from time to time), then there are 8000 other LIRs in the RIPE service region who can take the transfer. Nick

On 15/10/2012 20:38, Sascha Luck wrote:

To re-iterate, a LIR is *not* responsible for "abuse" perpetrated by the end-user, your proposal is merely trying to create this responsibility out of thin air and ex post facto. (I assume this requirement is intended to apply to existing contracts)

My goodness, I have no idea where you pulled that one from. :-)

This proposal is, by this argument, working into the hands of certain parties (you know who you are) whose mission in business is to impose their political and moral beliefs on the internet in general and will most certainly use this information to put pressure on LIRs to cancel their contracts with, or refuse to sponsor, "unwelcome" end-users.

Ok, I'm going to call a halt at this stage. I'm really not interested in arguing against scary conspiratorial hand-waving and defending this policy proposal against allegations that the sky is going to fall. I don't think that the sky is going to fall, or that the policy is going to cause sinister attacks to occur with chilling effects. In fact, I can't see even a single black helicopter. For the record let me state that I do think that this proposal is a generally sensible clarification of the current policy which is fully consistent with other similar current policies concerning information availability and IETF recommended practices and all that sort of thing. Nick

2012-10-16 00:42, Sascha Luck skrev:

On Mon, Oct 15, 2012 at 11:12:21PM +0100, Nick Hilliard wrote:

...

On 15/10/2012 20:38, Sascha Luck wrote:

I don't think that the sky is going to fall, or that the policy is going to cause sinister attacks to occur with chilling effects. In fact, I can't see even a single black helicopter.

Well, you're thinking wrong - such (attempted) attacks have already happened against the NCC, including one that is currently pending judicial review. While the NCC may well be able to fend these off, I'm not convinced that all LIRs have the resources or the willingness.

First. I'm in favor of this proposal if the sponsoring LIR is clearly stated in the resource. Would it be to much to ask if the record in the db would reflect the relationship between sponsering LIR and the object maintainer? It could be as lightweight as "databasehelper-mnt" or something more suitable. Secondly. We have done this for a number of years now, but in a slightly different way. We are transparent with our resources in RIPE. I would say that the sky will not fall down. At least not in Sweden. We get about 0.8% "DMCA take down requests" or similar in proportion to the number of assignment resources in the RIPE database that we have. We just have to politely respond to them and explain the situation. I think the average "take down" requester does not know how things work for the RIR/LIR. I can see a problem in a country where the law is in favor of "take down" requester. At least in Sweden, we see this much like National Land Survey. They have the responsibility for registering property, but not the operational responsibility for what happens there. If this is a problem for the RIPE region at large, I think we have to consider the proposal again. If not, see the first paragraph. /Bengt Gorden

2012-10-16 12:14, Nick Hilliard skrev:

Hi Bengt

On 16/10/2012 09:44, Bengt Gördén wrote:

...

First. I'm in favor of this proposal if the sponsoring LIR is clearly stated in the resource. Would it be to much to ask if the record in the db would reflect the relationship between sponsering LIR and the object maintainer? It could be as lightweight as "databasehelper-mnt" or something more suitable. Kaveh Ranjbar presented some ideas at the last RIPE meeting which may be relevant to this:

https://ripe65.ripe.net/programme/meeting-plan/db-wg/

Thank you. That saved me some time digging through the "have not seen" sessions. I was at the EIX session at that time.

...

that the sky will not fall down. At least not in Sweden. We get about 0.8% "DMCA take down requests" or similar in proportion to the number of assignment resources in the RIPE database that we have. We just have to politely respond to them and explain the situation. I think the average "take down" requester does not know how things work for the RIR/LIR. I can see a problem in a country where the law is in favor of "take down" requester. At least in Sweden, we see this much like National Land Survey. They have the responsibility for registering property, but not the operational responsibility for what happens there. If this is a problem for the RIPE region at large, I think we have to consider the proposal again. To be honest I really don't see how this is substantially different to open registration for any other details. The principals of open registration are very well established and we all agree that it is a good thing.

Agreed. I'm a firm believer in openness and transparency. This was just a reservation that if the proposal don't get approved I think we need to have another discussion about it. Sorry if that wasn't clear. I need to know the sponsoring LIR for my daily work. /bengt

2012-10-16 13:25, Sascha Luck skrev:

Hi Bengt,

On Tue, Oct 16, 2012 at 12:51:24PM +0200, Bengt G?rd?n wrote:

...

I need to know the sponsoring LIR for my daily work.

Can you go into more detail on this? I'd be really interested in seeing an actual use-case for this information. As is, I can't think of one as it really only signifies that a LIR, at some stage, handled paperwork for an end-user...

Mostly others benefits from this because of our policy to be open. We have a few thousand assigned objects so I think our openness today gives us a lot more in return than the reverse. I think it would work for others too. And now the other way around, which happens. A customer (not our) to a sponsoring LIR (unknown) contacts us to say that they need to change something (route, ipv6 domain, what have you). The first question is "what sponsoring LIR do you have". Typical answer is "what?". Next question is "what upstream provider do you have". ISP XYZ. Still not the sponsoring LIR. I have to start explaining to them what it is. Often they still don't know. They have to ask "someone". When they have asked "someone" the best case scenario is that it's actually a LIR and the case is sorted out. Often in a day or two. Worst case scenario is that we bounce mail back and forth a few days up to several weeks with no outcome. If I could have seen the sponsoring LIR from the start it would have been sorted out in hours/day. The sponsoring LIR is also responsible for updating the RIPE db and knows how to do that. So talking to a person that actually knows what their doing is much more efficient than to be a teacher in the "University of Internet" to person X. /bengt

On 15/10/2012 16:27, Sascha Luck wrote:

"The RIPE resource allocation and assignment policy documents require that Internet number resources be registered 'via a public registry documenting address space allocation and assignment' and notes that 'this is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels'."

Invalid, the resources are registered with the RIR, not the sponsoring LIR.

'this is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels' means that if some information is hiding, then information is not being provided for Internet troubleshooting at all levels. Look, the point of BCP12 is good housekeeping and one of the ways we have on the Internet of implementing good housekeeping is to keep stuff out in the open, not hiding away information in a back room. BCP12 is not a BCP because it contains a whole pile of bad practice, or because that advice is in any way out of date. This is current recommended policy for all Internet object registration.

"This mechanism provides a simple means for End Users to identify with which sponsoring organisation they have a contractual link, in the case this information is unknown to the End User."

Accepted, but the end-user can easily find this information by contacting the RIPE NCC.

Last time I looked, the RIPE NCC service region contained about a billion people, and there were 28000 PI blocks. This doesn't scale. Let's automate it and get a cheaper RIPE NCC which isn't spending money answering stupid questions which can just as easily be answered by a computer.

"This policy simplifies the mechanism for verification and co-ordination between sponsoring organisations when an End User wishes to transfer resources from one sponsoring organisation to another."

Unneccessary, as the actual decision and verification is done by the NCC anyway.

Knowing which organisation you're going to be dealing with in advance will cut down significantly on time and general overhead when dealing with transfers. I.e. you can make prior contact with the remote LIR and have stuff arranged in advance and things will go smoothly. Again: this proposal is about making life easy and better and more consistent with the existing policies which we use. Manual intervention is a pain and inconsistent with this improvement. Nick

Hi Sasha,

That is exactly why I strongly oppose this proposal. Publishing the sponsoring LIR for a PI assignment creates an appearance of responsibility on the part of the sposoring LIR, for the actions of the PI assignee, *that does not exist*.

That is not completely correct... RIPE-452 contains the requirement that the contract between the end-user and the LIR must contain: - Notice that the LIR is responsible for liaising with the resource holder to keep registration records up-to-date So if there is something wrong with the registration records / RIPE database then there is a responsibility for the LIR. - Sander