It is odd that one would support the existence of a Whois database that tells anyone and everyone what organization is the registered holder of an address block, and at the same time be against documenting the movement (transfer) of a block from one holder to another. Do you believe the Whois data should all be private? As long as there is a Whois database, it will be possible to know where the address blocks go. The proposal simply makes it easier to track and analyze. So, unless he is willing to advocate eliminating Whois altogether, Sascha Luck's idea to "anonymize all transfer data" doesn't make a lot of sense to me. The reasons for making the address market easier to track are primarily policy-related, rather than "operational". The reasons for knowing the buyers and sellers in successful transfers are clearly explained in the initial proposal. We need to be able to assess how the market is working and its economic consequences. The market itself will work better and more efficiently with more transparency. You cannot buy and sell companies (legal persons) without the existence of the transaction and a large amount of other information about the companies being known. In most countries (not sure about all of Europe) buyers and sellers of real estate - houses, land - are completely public, as is the price and taxes paid for the property. And all the other RIRs with a transfer market make this information public. I think, therefore, the burden of proof is on those who would want to keep it hidden - actually not hidden, but just harder to access. What is the point of that? Why should RIPE region be an exception to the rest of the world?

-----Original Message----- I'd go one further and anonymise all transfer data. Who has an operational *need-to-know* this data?

rgds, Sascha Luck

-----Original Message-----

Yes, actually, or at least *more private*. IP space is not just allocated/assigned to corporations but also to private individuals.

I am quite sympathetic to that, for natural (as opposed to legal) persons, but that whole issue is not relevant to this policy proposal. You are considering a policy change for the Whois, not for transfers transparency. Please don't confuse the two.

Who might that "we" be who need to assess how the market is working? It seems to me that this sort of data (nicely aggregated lists of address space transfers and refusals) would mostly be useful to marketroids. Especially those who have various "get IP quick" scams on offer.

On the contrary, brokerages would benefit from less transparency. Specialized brokerages, or what you somewhat insultingly refer to as "marketroids," will be easily able to analyze the Whois data to find out what transactions took place. It will pay them to know this and so you have widened the gap between what they know and what the rest of us know. It is the rest of us who will be left in the dark. The less we all know about the supply and demand conditions, the higher the margins and less efficient the market will be. So the "we" who need to assess the market are network operators who may be considering participating in that market, policy makers who want to know how well it is working, and policy researchers who want to answer the questions policy makers have.

For one thing, personal data in the EU remains the property of the individual. This is not the case, eg. if it somehow gets to the US

IP numbers will be traded in blocks. They do not function as PII (personally identifiable information) until and unless they are assigned to specific individuals as IP addresses. Therefore there are no issues related to data protection in a market transparency policy. And again, the information is there, we are just making it more accessible. Once again, you are confusing some of your concerns about privacy with Transparency in Address Block Transfers. The proposed policy 2012-05 neither improves the privacy situation nor makes it any worse than it is now. If you want to propose a Whois privacy policy to RIPE I would encourage you to do so, but by latching on to this policy, you are barking up the wrong tree.

Sascha, On Tue, Sep 4, 2012 at 8:59 PM, <lists-ripe@c4inet.net> wrote:

On Tue, Sep 04, 2012 at 05:29:19PM +0000, Milton L Mueller wrote:

...

You are considering a policy change for the Whois, not for transfers transparency. Please don't confuse the two.

Please do not accuse me of something *you* brought into this discussion. I admit fault for falling into your trolling net though.

I am not sure I got what you mean.

Anyway, as long as all information like personal names, phone numbers, addresses and email are removed from these publications, I consider them suitably anonymised for the purposes of this policy.

I share Milton's view that a name (etc) of a person acting in business is not personal only, however, a business ID, what is public information. This is the rule in my country which is not in the US and won't be.

What you said: sometimes purely personal data also included in the whois database. Milton and I understood this argument, and Milton answer was: this is a "whois problem". I would say, this is problem of keeping the address allocation process transparent while allowing hiding individual only information, Milton's and my approach may be the same.

rgds, Sascha Luck

There is a trade-off: I vote for the trancparency of the address allocation (and any change in the address allocated). Thanks, Géza

Jim, thanks for your clarifications, I better understand your concerns. However, business related ID should be accessible publicly. If I know well, all public procurement require the correct ownership data, etc in Europe, and not just hidden, disguised ones. Best, Géza On Wed, Sep 5, 2012 at 11:00 AM, Jim Reid <jim@rfc1035.com> wrote:

On 5 Sep 2012, at 07:16, Turchanyi Geza wrote:

I share Milton's view that a name (etc) of a person acting in business is

...

not personal only, however, a business ID, what is public information. This is the rule in my country which is not in the US and won't be.

There are many views on what is and isn't Personal Data, even amongst European Data Protection Authorities who are working off the same EU Directives. Don't make the mistake of assuming everyone shares your view or that of your local DPA. Or that those views might or might not change tomorrow.

Strictly speaking any data which identifies a living person constitutes Personal Data. Therefore that data falls within scope of the EU Directives and the prevailing national laws which enacted them. However some, but by no means all, European DPAs take a pragmatic view and consider end user expectations and/or the intent behind publishing Personal Data when deciding what is and isn't acceptable. Other DPAs may take a much more literal approach to what's in the Directive and local law. So what's "legal" in one jurisdiction may well be "illegal" in another even though both positions are based on the same EU Directives. This situation might well apply in non-EU countries which have Data Protection legislation too.

Things can get even murkier if you go into greater detail. For instance my former ISP added contact details for me to the RIPE database when they gave me a /29. This was OK from the DPA's perspective since the intent was reasonable: maintaining an accurate, public database of who was using address space. However it was also not OK because the entries were added without my consent and I had no clear way to update them. Those entries were still in the database several months after the space had been handed back. That wasn't OK either.

Schrodinger's cat has/had a very happy home in Data Protection. :-)

Anyway, this latest rat-holing is somewhat irrelevant. If contact information for IP address resources need to be obscured for whatever reason -- commercial confidentiality, data protection/privacy, preventing spam, etc -- methods for that already exist and could be applied. In some cases, they already are in use. Others may well be invented. Just look at the "imaginitive" solutions found in the domain name world for obfuscating whois data. If we look in the real world, the public registers of physical assets such as shares and property regularly contain entries for things like lawyers's offices, nominee accounts, offshore companies/trusts and so on so that the details of the real owner remain hidden.

[with my DB-WG hat on for a moment...] Sascha Luck wrote:

On Mon, Sep 03, 2012 at 12:28:59PM +0200, Sander Steffann wrote:

...

So... Again your feedback please! Is there anyone who thinks that anonymising details of rejected transfers is a bad idea? (and if so: please explain why)

I'd go one further and anonymise all transfer data.

Is this an issue at all, to begin with, as the rightful holder of the allocation will at any time be recorded in the Numbers Registry, aka the RIPE DB? I may be missing something, though!

Who has an operational *need-to-know* this data?

rgds, Sascha Luck

Wilfried.

Tore Anderson wrote:

* Sander Steffann

...

Looking at the feedback I see two types of responses: - The policy proposal is good as it is - Information on rejected transfer should be anonymised

We could suggest to the proposer to add the 'anonymise rejected transfers' bit to the proposal, but we are not sure if that would gain support on one side while losing support from people who like the policy proposal as it currently is...

So... Again your feedback please! Is there anyone who thinks that anonymising details of rejected transfers is a bad idea? (and if so: please explain why)

I object to publishing information of rejected transfers (and, by extension, rejected pre-approvals).

I concur, strongly. It would be useful, though to have some sort of aggregate data about failures, like e.g. #of failed vs successful transactions, granularity of requests, and the like. I haven't thought to the end of this stick, yet :-)

The NCC does not publish any information about rejected PA allocation requests either, and I don't see why transfers should be any different.

I agree. [...]

I think that a simpler and probably much faster way (no PDP!) to accomplish the desired «transparency in address block transfers» would be to simply ask the NCC to publish historic versions of alloclist.txt,

Well, I don't like the idea of publicly and easily offering such a history. [This is with my security team hat on :-) Although, with the same hat on, I would love to have such a thing...] As the NCC has to shorten the quarantine period for returned or reclaimed addresses, offering this may be painful for the new/current holders of the resource. On top of that, from a formal perspective, if there is no longer a (contractual) relationship with the NCC, I do not see a sound basis for the NCC to make old data publicly accessible.

and/or to include a regid/LIR column for resources in delegated-ripencc-extended-latest (for which historic archives are available). This has been recently suggested in the services wg, but it was objected to, because of privacy issues for assignment holders (so irrelevant relevant to this proposal). I think I'll go and revive that thread now...

Oh, and by the way: why specify exactly monthly? As noted above, the NCC has no problems publishing most of this information on a daily basis. If they are able to automatically publish the transfer list daily too, why not let them?

I'd rather like the NCC to come forward with a proposal of how to make the requested data available, and describe its format(!) than prescribing details in a formal policy. The mechanism may even be a webpage or feed that gets updated when the DB gets updated to reflect the transfer :-) Wilfried.

* Milton L Mueller

...

I object to publishing information of rejected transfers (and, by extension, rejected pre-approvals). The NCC does not publish any information about rejected PA allocation requests either, and I don't see why transfers should be any different.

[Milton L Mueller] You have not given us any reason not to provide this information, other than "we haven't done it before" - which I do not accept as a good reason.

I, like the NCC, consider this data to be confidential. Let's say I want to transfer an allocation to another LIR, and want the fact that I've been dealing with said LIR to remain a secret until the deal is done. If the deal falls through due to the failure of the recipient LIR to justify their need for the transferred resource, I don't want the fact I was in negotiations to transfer away 192.0.2.0/24 to become public knowledge.

I will tell you why we need to do this. There are serious concerns in the existing transfer market about potential discrimination in the application of needs assessments, at least in the ARIN region. Needs assessment is not an entirely scientific or objective exercise. Providing basic statistical information about how many applications are rejected avoids undermining confidentiality but also provides some knowledge as to how many attempted transfers are coming in and how many are rejected. If there are complaints about the application of needs assessment criteria - and there already are in other regions - at least the community has some information about

This is a red herring. The proposal does not call for «basic statistical information about how many applications are rejected», it calls for the explicit identification of origin LIR and the address block it intended to transfer away. Also, if the goal of the identification is to combat discrimination in need assessment, isn't it the *receiving* LIR that should be identified? How is the identity of the LIR giving up its allocation, and the identity of the allocation itself, relevant to need assessment? I have no objection to having the NCC publish aggregate information about how many transfer tickets they've handled and how many of them was approved. That said, I'm not so sure we would need to have a policy for it, it might be simpler to just ask them to publish the information in aggregate form. For example, they do something along those lines at http://www.ripe.net/lir-services/resource-management/tools-for-lirs/reponse-... without there being any policy compelling them to.

...

That said, I am not quite sure it is really necessary, as all the requested information (except rejections) is already available: All allocations are listed in alloclist.txt along with their date and holding LIR (reg-id and name). It will be trivial to check for transfers - allocations made after the last /8 policy comes into effect outside of

[Milton L Mueller] Trivial to whom? To someone who has a system set up to constantly track this or who has bulk access to the entire database and can write scripts to check for it on a regular basis?

Yes. It's not difficult. You basically download two files and see what has changed.

This is not reasonable. RIRs need to recognize the significance of the emergence of a transfer market. The attitudes here in RIPE that I detect are incredibly complacent. A market for addresses will profoundly transform the nature of IP number allocation. All RIRs are obligated to do everything they can to make this market easily understood, transparent and efficient. Why shouldn't they? Can you provide a positive reason why not?

I think both the RIPE community and the NCC fully realise that transfers will play a significant role in the near future.

[Milton L Mueller] I think the description you provide of what would be necessary to track this information without the policy proposed in 2012-5 self-evidently proves that this policy is needed. Your approach is complex, expensive and would limit this information to a few specialists who would keep the data proprietary in order to protect their investment in collecting it.

I think you are greatly over-estimating how difficult it is to parse and extract information from the stats files available on the FTP. I think anyone with basic programming or scripting skills would have no problems. I'll be happy to provide you or anyone else with a script that generates the report you want based off the stats files, if the NCC makes all the necessary information available there.

My proposal would make it accessible to anyone. You have not provided any good reason to limit it in that way. You have not provided any costs or harms that would occur if the information is made accessible. Perhaps you can do so?

Like I said, I have no objection to the proposal other than the part regarding publishing identifying details about rejected transfers. That said, I think there is likely much faster ways to accomplish the desired transparency than going through the PDP. I think going through the PDP is over-engineering. Don't mistake that for opposition to the proposal though.

...

I think that a simpler and probably much faster way (no PDP!) to accomplish the desired <transparency in address block transfers> would be to simply ask the NCC to publish historic versions of alloclist.txt, and/or to include a regid/LIR column for resources in delegated-ripencc- extended-latest (for which historic archives are available). This has been recently suggested in the services wg, but it was objected to, because of privacy issues for assignment holders (so irrelevant relevant to this proposal). I think I'll go and revive that thread now...

[Milton L Mueller] No, that is not "simpler". Not by any reasonable definition of "simple." RIPE could easily make this accessible to all with a few keystrokes and procedural change at the source. Can you explain why it should not?

From the impact analysis: «It is worth mentioning that the RIPE NCC is willing to publish details on resource transfers and a report has not been requested so far».

So yes indeed, «RIPE[sic] could easily make this accessible to all with a few keystrokes». They have stated a willingness to do so, too. So why do we need to change policy, exactly? The PDP is a slow process. It seems to me that it is faster to just ask the NCC to start publishing the desired information. If they refuse to do so, then let's look into compelling them through policy. IMHO, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com

* Milton L Mueller

...

-----Original Message----- Let's say I want to transfer an allocation to another LIR, and want the fact that I've been dealing with said LIR to remain a secret until the deal is done. If the deal falls through due to the failure of the recipient LIR to justify their need for the transferred resource, I don't want the fact I was in negotiations to transfer away 192.0.2.0/24 to become public knowledge.

OK, this is a valid concern, imho. I would propose to modify the language such that statistical aggregates are published rather than individual blocks.

Thanks - that would resolve my objection to the proposal.

...

Also, if the goal of the identification is to combat discrimination in need assessment, isn't it the *receiving* LIR that should be identified?

Correct. Would you object if they were? Would others?

I would. I feel that neither the source nor the recipient of a failed transfer should be named. This extends to the address block itself (from which it would have been trivial to figure out the source.) In summary, my position is that: * Source/dest/prefix for successful transfers should definitively be made public. * Aggregate statistical data both for failed and successful transfers is «nice to have». * Information that identifies the specific parties or resources associated with a failed transaction should *not* be made public.

...

So yes indeed, <RIPE[sic] could easily make this accessible to all with a few keystrokes>. They have stated a willingness to do so, too. So why do we need to change policy, exactly? The PDP is a slow process. It seems to me that it is faster to just ask the NCC to start publishing the desired information. If they refuse to do so, then let's look into compelling them through policy.

Valid points! But on the other hand if we ask them to do it and they don't, then the process becomes even slower, doesn't it? I would prefer to go ahead with the policy change, but as you suggest remove the stuff about failed needs assessments, turn that into a request from RIPE for aggregate statistics.

Are we in agreement on that? If so, I will propose a specific modification of the proposal

Agreed. I would not object to such a proposal. That said, I won't guarantee that I will come out and explicitly support it either (at least not until I've seen you simply ask the NCC to publish the desired data and been refused), but I promise I won't stand in your way. (I think services-wg would be the right place to ask the NCC for the data, by the way.) Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/

* Niall O'Reilly

On 7 Sep 2012, at 08:08, Tore Anderson wrote:

...

* Aggregate statistical data both for failed and successful transfers is «nice to have».

Should the statistics for failure distinguish between the cases "withdrawn" (as when the deal falls through) and "refused" (as when the NCC's resource analysis process determines that the requirements are not met)?

I'm guessing the updated proposal Milton just announced will contain a specification on exactly which data should be included in the stats. (Personally, I love stats and colourful graphs of all kinds so I'll be happy to see the distinction being made.) I remain unconvinced that we need to change address policy in order to get these stats made available, though. It seems more like an NCC service to me - that it would be better to simply ask the NCC «could you please put up a graph on www.ripe.net containing plots X, Y, and Z» and/or «could you please put up a file on ftp.ripe.net containing columns X, Y, and Z». But I won't stand in the way of requesting it through address policy either. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/