[address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database)

Denis,

Thanks for repeating your position. Once again. It is already noted.

> Unfortunately, the Task Force did not attempt to identify most of these
'other' stakeholders or what data they need or why. So […]

You are wrong, Denis. The task force did in fact consider all stakeholders
that we could possibly think of, and their needs for the database. We
decided not to create and publish a definitive list of stakeholders in our
report because, well, who are we to decide who qualifies or not as a
legitimate stakeholder of the RIPE database in 2021? Should such a list be
reviewed annually to be kept up-to-date and accurate? Should there also be
an accompanying list of their (changing) individual requirements
maintained, and why? Who should do all that work, how? Looking forward to
reading your list :)

In the meantime, rather than perpetually navel gaze or crusade for a new
RIPE database, the scope of this proposal - and focus of this discussion -
is the potential change of address policy that states holders of PA IPv4
'must' register assignments in the database to 'should' register
assignments. For the reasons outlined in the proposal, which to me
personally read clear and reasonable.

We would love to hear what others in the working group think about this
policy proposal. The more people we have sharing their thoughts, the better
and healthier for the working group!

Regards,
James

On Fri, Oct 7, 2022 at 11:45 PM denis walker <ripedenis at gmail.com> wrote:

> Hi Jeroen
>
> Your terminology is very confusing. You talk only about allocations
> and sub-allocations and keep referring to INETNUMs. You never once
> mention assignments. So my first question is what exactly is it that
> you want to be optional?
>
> The current policy says:
>
> 3.0 Goals of the Internet Registry System
> ...4.Registration: The provision of a public registry documenting
> address space allocations and assignments must exist. This is
> necessary to ensure uniqueness and to provide information for Internet
> troubleshooting at all levels.
> ----
> 4.0 Registration Requirements
> All assignments and allocations must be registered in the RIPE
> Database. This is necessary to ensure uniqueness and to support
> network operations.
> ----
> 6.2 Network Infrastructure and End User Networks
> ...When an End User has a network using public address space this must
> be registered separately with the contact details of the End User.
> ----
>
> The message from the current policy is very clear. End Users operating
> public networks must be documented in the RIPE Database. There are two
> historical reasons given, uniqueness AND network operations. You have
> focused your argument on the fact that uniqueness of allocations is no
> longer needed. But you have ignored the other stated reason. Using the
> database to contact network operators for troubleshooting is one of
> the original purposes of the database. So if you now want this
> information to be optional and entered if an LIR feels like it, you
> need to justify why internet troubleshooting is no longer necessary at
> an End User network level.
>
> When we talk about the purposes of the database we are not talking
> about the purposes of the database as a container. We mean the
> purposes of the data contained within the database. Over time this
> data in the RIPE Database about End Users has been used, for example,
> by LEAs and other investigators to identify the users as well as for
> internet operational problem solving.
>
> The Database Task Force acknowledged in their report (ripe-767) that
> there are now different stakeholders who use the RIPE Database for
> different reasons:
>
> 2. The Difference between the RIPE Database and the RIPE Registry
> The information disclosed in the RIPE Database aims to facilitate
> cooperation and coordination between network operators and other
> stakeholders for a variety of operational tasks, including
> troubleshooting and preventing outages.
> ---
> 3. Why are we reviewing the RIPE Database functionality now?
> The RIPE Database provides essential information to members of the
> RIPE community, which helps them to keep individual networks and the
> overall Internet running in their region. Many stakeholders depend on
> the accuracy and availability of the data stored in the database to do
> their job properly, especially regarding cybersecurity. Some database
> users, such as ISPs or IXPs, have been part of the RIPE community for
> years, while others are relatively new, such as Law Enforcement
> Agencies (LEAs) or regulators. These user groups have different needs
> and expectations regarding the database
> ---
> 5.1 Data accuracy
> The data added to the database should be accurate to ensure uniqueness
> of Internet number resources and to provide reliable registration
> information to all parties involved in network operations. For
> example, contact details or information about a specific assignment
> should be accurate to facilitate contact with and identification of
> the organisation holding the assignment.
> ---
> 6.4 Purpose: Facilitating Internet operations and coordination
> The RIPE Database should facilitate communication and cooperation
> among stakeholders for the following reasons:
> -Operational issues such as measuring or troubleshooting networks
> -Handling abuse cases, supporting the handling of cyber incidents and
> supporting LEA investigations
> ---
>
> Unfortunately, the Task Force did not attempt to identify most of
> these 'other' stakeholders or what data they need or why. So we are
> left in a position where it has been acknowledged that many different
> stakeholders exist that need data currently provided by the public IP
> address registry, but who or what is unknown. There may well now be
> stakeholders with very legitimate reasons for needing accurate
> assignment data. Until we know more about these stakeholders we cannot
> make informed decisions about the content of the database. But the
> Task Force then went on to make a recommendation about assignments
> based on the rationale "A core reason for registration of IPv4 PA
> assignments was to justify an LIR’s need for additional IPv4 allocated
> address space. However, since the RIPE NCC ran out of IPv4 in 2019,
> this policy has been rendered obsolete." Just as you are doing in this
> proposal, they conveniently ignored the main reason(s) for documenting
> assignments and focused on one obsolete reason.
>
> The Task Force recommendation was "that as resource holders have full
> responsibility over the registration of their IPv4 PA assignment(s),
> they are free to make assignments or not." Which is also the basis of
> your proposal. The people entering data into a public IP address
> registry are not necessarily the ones who should be able to decide
> what data must be contained in the registry. You need to consider the
> requirements of different aspects of the industry and even the needs
> of the wider (public) community (the stakeholders).
>
> I do not think we are currently in a position to make an informed
> decision on this Task Force recommendation or your policy proposal.
>
> cheers
> denis
> co-chair DB-WG
>
>
> On Fri, 7 Oct 2022 at 16:31, Jeroen Lauwers <jlauwers at a2b-internet.com>
> wrote:
> >
> > Hi Denis,
> >
> > Again we are back to asking the question, "What is the purpose of the
> > RIPE Database in 2022?". I know this is like the elephant in the room.
> > I know most people look the other way every time I mention this topic.
> >
> >
> > This policy proposal is not about the goal of the database itl is just
> about how far we obligate LIRs in filling in information for inetnum
> objects and how much freedom we give the LIR to decide it by themself. So
> technically the goal of the database stays the same.
> >
> > BUT it is so fundamental to many discussions we are having. For
> > example, is the database still purely (or even primarily) only for
> > 'operational purposes'? A term used so often that, like so many other
> > terms used in this industry, is not even defined anywhere. Is using
> > the content of the RIPE Database to stop the use of an IP address for
> > criminal  activity an 'operational purpose'. If someone is operating a
> > network using a block of IP addresses and abusing other users of the
> > internet, then surely knowing who is using that block of addresses and
> > being able to contact them has 'operational' value.
> >
> >
> > For sure we always need to keep this in mind. And I think it would be a
> good subject to discuss in the database working group. But so far I don’t
> see any reasons to be insecure about this after changing this policy.
> >
> >
> > As Sander said, knowing how much of an allocation is in use was a side
> > effect of this policy. Knowing who is operating a network on a block
> > of addresses, and being able to contact them, is the real purpose of
> > this policy requirement to document assignments. If we allow LIRs to
> > choose what info to add to the database, those LIRs that knowingly
> > provide resources and services to abusive end users will obviously
> > choose not to document it. That may be used as a selling feature to
> > abusive end users, to obscure and delay their identification. Whilst
> > most LIRs take abuse seriously we all know there are some that don't.
> >
> >
> > You are totally right. That is why this is only about inetnum objects.
> The LIR gets still obligated by the terms and conditions to fill in enough
> information for contacting efficient the maintainer as also By the Abuse
> Contact Management in the RIPE Database policy for having an abuse contact.
> >
> > Kind regards,
> >
> > Jeroen
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change
> your subscription options, please visit:
> https://mailman.ripe.net/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20221008/d9315899/attachment.html>