Dear Emmanuel,

From EUROPOL perspective, we observe with interest, the proposed measure, considering the digital investigation matters, While consulting colleagues also at national level and partners, we have identified various points on which we would thank you to bring information, for our better understanding.

First of all, let me clarify something about PI, which might have been missed: Technically, PI is the dream of LEA; PI is held by _one_ entity, and _one_ entity is responsible for it. Meaning: No matter how the PI is ultimately used, from a formal/policy perspective this is the _one_ case where you technically get full information on the entity using the address space from a simple 'whois 2001:db8::'; Details below inline.

1) With the addition of the nibble boundary, how do we ensure that the policy complies with the “Registration goal”, which is essential for Internet troubleshooting and avoiding abuse? Are PIs required to register End Site information ? What type of information is recorded by PI and how is this information made accessible to a requesting Authority?

To be honest, this is partially even an annoyance for me as a PI holder; i.e., the inability to provide documentary information for which parts of my infrastructure I use parts of a prefix; I would, e.g., like to signal which addresses are loopback/transfer addresses, and which host my services. There is a chicken-egg-problem between the database and documentation of usage (which does not necessarily constitute assignments) in the RIPE database for PI. This is an artifact of the strong tie between PA assignments and PI assignments, and the varying use in practice between them (independently routed for PI etc.) and the strong notion of usage documentation necessarily being sub-assignments in current policy (DB wise); Metaphorically speaking: By opening this point we get an egg, which we can then use to later hatch the egg into a chicken by discussing the option of documentation entries in the DB being enabled. However, these are two (interdependent yet different) steps/policy proposals, that should be taken subsequently. From a practical perspective, the change introduced here (enabling the above) does not deteriorate the situation beyond the status quo, though. As such, it should generally be an acceptable intermediate step, and as such even be in your interest as well.

What type of information is recorded by the End User, for example about his End-Sites?

The exact information requested by the NCC is an implementation matter, and as such out of scope for the policy. In the past, however, the NCC usually requested information on the address of an endsite.

How they provide information when requested by an Authority, ensuring that they comply with “Registration goal”?

The registration goal is a term of Internet governance, and does not have the purpose to provide LEA with accurate or current information. Those purposes are independently regulated in national legislation as applicable to each independent member. In general, though, I would argue that the PI DB entries will (see also the introductory paragraph) always provide (KYC verified) information on the responsible entity that is required to provide this information accurately as specified in applicable national law. Please note, though, that I am not a legal scholar or lawyer, and this is merely a personal reading of the situation.

How to ensure that an IP range is used by a single party and not more?

This, in general, is a difficult thing to always ensure, as 'use' is always an underdefined statement. For example, use of PI for providing, e.g., an open WiFi network, running HotSpots, or running TOR services is already permissible. Limiting those use-cases--in my understanding of the RIR system--does not fall into the policy prerogative of RIRs.

2) When a PI receives a larger prefix for more than one End-Site instead of two smaller prefix, how they have to distribute IPs in those range? Are they obliged to distribute them evenly, or can they simply use most of them at one of the End-Sites and leave some others at the remaining site? How to prevent the “Fragmentation” of a larger prefix between different End Sites (instead of having them use contiguous IP ranges)?

The policy does not provide explicit guidance on addressing schemes, and I would argue that this is out-of-scope, again.

Couldn’t they just demonstrate the need of small End-Sites to get a larger pool of IPs for a single End-Site (or stockpiling them), violating the “Conservation goal”?

As discussed previously, this is _already_ the case, with one notable difference: Under the current policy you would, e.g., have 15 different prefixes assigned to one EU, supposed to be used on 15 different end-sites (with no guarantees that this is actually being done). These prefixes may or may not be announced continuously. With the proposed policy change, the EU would receive one /44 ( 16 /48); This should, in fact, make attributing prefixes to an EU easier, with the end-site distribution not getting more difficult than now.

3) How to avoid unlawful internal renumbering in case of end-site growth after assignment of a larger prefix?

To the best of my knowledge, the RIRs hold no authority over a members or networks desired address policy. Similarly, I am not aware of any legislation requiring specific numbering plans. If 'unlawful' is meant to mean 'not aligned to policy', the above holds, i.e., this is already not being monitored (or possible to be monitored).  

4) How should the relationship between an End Site and a newly acquired interval be recorded by PI? How the PI should manage the reverse lookup and how the PI delegates to end-user organizations the responsibility of managing the reverse lookup zone corresponding to the given address?

Please note that 'the PI' is a number assignment, and not an actor. If I read PI as 'End User' here, though, this question makes no sense. A core component of PI is that it is held by _one_ entity. The holder _is_ the end-user organization. Sub delegations that--essentially--move address space outside of a PI assignment holders network are not permissible by policy.

5) How to prevent PI being abused for providing ISP services and how to get information about the End Users if it happens?

The policy now _explicitly_ prohibits the use of PI for providing ISP services. In practice, though, this will be difficult to prove. Still, I would assume that the NCC always appreciates 'suggestions' for 'insistingly offering' a friendly ACR for the holders of a specific set of resources, if there is evidence of severe policy violations.

6) Where are the Authorities supposed to get information about who is the entity using the /56 prefix range if there is no sub-assignment?

Similar as of now, depending on legislation. For example, in Germany, if LEA would like to obtain information on the holder of the Internet connection that used 46.78.23.42 at a specific point in time, they would request a "Bestandsdatenauskunft" to Deutsche Telekom. Deutsche Telekom would then hand over the "Bestandsdaten" (Name and Address of the connection holder) as available under applicable law. With PI, the holder to be contacted would be either a _specific_ company or individual person, under the base-line that this entity as recorded in the database is solely responsible for that network (even if a device in that network is operated by a third party; It _must_ be the network of the assignment holder). Arguably, this would even be slightly easier with PI, as LEA can operate under the base-assumption of "the /56 is actually used by the registered holder", likely opening up a path for a more... insistent conversation style. -- As a more general note on the comments, though: They highlight, in my opinion, some room for perspective changes when it comes to the conceptualization on the RIR system and the connection between 'what policies say' and 'what non-law(-and-policy)-abiding entities are (able to be) doing'; The policies of an RIR (and, pretty much, also laws and national policies) are generally only effective when dealing with generally law abiding entities. If an entity wants to perform malicious actions, they have _plenty_ of options to ensure that they do not need to leave traces in the database (or provide anything that allows a 'Bestandsdatenauskunft' to anyone who might be willing _and_ able to cooperate with LEA). Meaning: The caveats discussed here are not really relevant when dealing with malicious actors, while they do not apply to entities that are willing to--at least--follow policies and/or local laws, as these would just provide a 'Bestandsdatenauskunft'. I would be happy to have a longer chat about that context off-list, given that this discussion likely expands beyond the scope of this policy proposal. With best regards, Tobias