Colleagues Over the weekend I re-read rfc7020 The Internet Numbers Registry System, from August 2013 https://www.rfc-editor.org/rfc/rfc7020 >From the Abstract: This document provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers.
Now when I say I read something, that usually means I studied it. What matters with most documents in this industry is the detail, not the headings. The DB Task Force made references to rfc7020 in their report. They said "The need to maintain an accurate public record of Internet number resource holders is common to all Regional Internet Registries (RIRs). This is outlined in RFC 7020". They went on to use this to justify the need to publish details in the RIPE Database about allocations made by the RIPE NCC to resource holders. Now this is where detail matters and the Task Force missed an important detail in rfc7020. In RIPE policy and terminology, we allocate resources from the RIPE NCC to a resource holder (LIR). The resource holder then assigns resources to end users. However, in rfc7020 there is no distinction between allocate and assign. It refers to a hierarchy of allocations from IANA all the way down to an end user. This is clearly illustrated in the definition in rfc7020 of an LIR: Local IRs ...LIRs perform IP address allocation services for their customers, typically ISPs, end users, or child LIRs (also known as "sub-LIRs"). So throughout the whole rfc7020 document, all references to allocate or allocation include what we understand in the RIPE region to mean both allocate and assign, as well as allocation and assignment. That means all the goals, principles and comments in rfc7020 apply equally to our allocations and assignments. In rfc7020 it specifies some goals including: 2. Goals Internet number resources are currently distributed according to the following (non-exclusive) goals: ... 3) Registration Accuracy: A core requirement of the Internet Numbers Registry System is to maintain a registry of allocations to ensure uniqueness and to provide accurate registration information of those allocations in order to meet a variety of operational requirements. Uniqueness ensures that IP addresses and AS numbers are not allocated to more than one party at the same time. The Task Force took this to mean what we consider as allocations to LIRs. But this also means what we consider as assignments to end users. So registering our assignments in the RIPE Database is a "core requirement of the Internet Numbers Registry System". rfc7020 goes on to say: 3. Internet Numbers Registry System Structure The Internet Registry (IR) hierarchy was established to provide for the allocation of IP addresses and AS numbers with consideration to the above goals. This hierarchy is rooted in the Internet Assigned Numbers Authority (IANA) address allocation function, which serves a set of "Regional Internet Registries" (RIRs); the RIRs then serve a set of "Local Internet Registries" (LIRs) and other customers. LIRs in turn serve their respective number resource consumers (which may be themselves, their customers, "sub-LIRs", etc.) It concludes with: 7. Security Considerations It is generally recognized that accuracy and public availability of Internet registry data is often an essential component in researching and resolving security and operational issues on the Internet. The bottom line is that we cannot make assignments optional unless we either disregard rfc7020 or we propose to the IETF an update to rfc7020 by removing a large proportion of the current registration data from the goals and core requirements. In fact we should now reconsider the way we register IPv6 assignments in the RIPE Database. rfc7020 makes no distinction between number systems. cheers denis co-chair DB-WG -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
