[arin-ppml] FYI -- RIPE-605 Services to Legacy InternetResource Holders

[David Conrad]

John,

On Feb 17, 2014, at 3:48 AM, John Curran <jcurran at arin.net> wrote:
>  The operational impact is actually the consequence of the service
>  provider who makes use of address space which is assigned to another;
>  it's not materially different than attempts at IP block hijacking 
>  that we see from time to time.   

It is worrisome that you do not see a "material differen[ce]" between theft actionable by real live law enforcement and a mutually agreeable exchange of resources allocated at a time when no explicit policy constraints declared such exchange forbidden.

>  If the registry is to be operated without any policy on transfers,
>  that is indeed possible, but again that should be decided by the 
>  community.

Red herring. I've said before this isn't about registry policy. This is about not damaging the registration database.

>  If this had only been made clear by the authors of RFC 2050, we could 
>  have saved more than a decade of policy working group meetings in every 
>  region...

See, this is why I object to treating 2050 as sacred text.

It was a "best current practice" in 1996. It addressed specific concerns the registries had and documented registry operation at that time. It was not ever intended to answer all questions about how Internet address registries should be operated for all time. It was a snapshot intended to explain to people who interacted with the registries what we were doing, how, and why. In 1996.

Now will you stop referring to it?

> Can you explain why you now believe that RIRs are not entitled 
>  to operate their registries in accordance with community-developed policy?  

Strawman: ignored.

> Are you saying that the RIRs should not be establishing any policy 
> on legacy address holders?

No. I'm saying any registry policy must not damage the accuracy of the registration database.  The registration database is NOT a weapon to be used by ARIN (or other RIRs) at their discretion. It is a global cooperative construct used by network operators and others for operational purposes beyond the limited scope of ARIN's (or other RIR's) particular needs.

> Are you saying that the RIRs can establish policy on legacy address
> holders, but it should be solely voluntary for compliance,

Hint: RIR policy IS voluntary.

> and in the
> end RIRs should register transfers regardless of circumstances (e.g.
> to a non-existing entity, or of a single /32, etc.)

John, try to remember back to when you operated actual networks. When someone was abusing your network, you could look up that address in the Whois database of "the NIC", call them up and ask them to stop. As a network operator, your needs of the registration database were to identify the actual user of the network at that time for operational purposes.  Not who was originally allocated the network originally. Not what some folks in Chantilly VA thought was appropriate to be in the registration database about that network. The actual user of the network at the time your network was being abused.

In this light, registering a transfer
- to a non-existent entity DOES NOT improve/maintain accuracy, hence no.
- of a single /32 DOES improve/maintain accuracy, hence yes.

Pretending that the registration database is accurate because it only contains information that is acceptable by arbitrary policy at a particular point in time means that the network operator you would NOT be able to rely on the registration database for the purpose it was intended. 

What then, from a network operator's perspective, is the point of the registration database?

> Or is it that RIRs should only be making allocation policy, and not 
> be placing any policy constraints (or only the minimal necessary 
> constraints) in the case of transfers?

Once more with feeling: this isn't about policy (transfer or otherwise).  It is about registration database accuracy. 

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140217/8b6f2876/attachment.sig>