[address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Colleagues

Here we go again. Let me start by saying that the emphasis and
phrasing of both this email that I am replying to and the impact
analysis seem to have been carefully chosen to show this proposal in a
good way. What I mean by this will become apparent as you read on.

Just to be clear, I object to this proposal. The discussion at RIPE 87
on the need for assignments in the RIPE Database and what contacts
they should contain was very inconclusive. What it did show was that
no one really understands what contacts are needed and what the
current policy required contacts actually mean. Until we have a clear
picture of what this data means and what different stakeholder groups
require, we should not be considering changes on this scale. The RIPE
NCC's impact analysis also completely ignored the impact of this
proposal on the registry system.

On Wed, 13 Dec 2023 at 19:14, Jeroen Lauwers <jlauwers at a2b-internet.com> wrote:
>
> Dear colleagues,
>
> Though we recognise that most of you are probably busy preparing for the upcoming holidays, we would like to ask you to share your opinion on proposal 2023-04. Remember that Policy Development Process requires any comments made during the Discussion phase must be repeated during the Review phase in order to count towards or against rough consensus, as your views can now take the RIPE NCC’s Impact Analysis into account.

Let's look at the RIPE NCC's impact analysis (IA). The IA seems to
focus mostly on the impact this proposal has on the RIPE NCC and its
operations. I accept that the PDP (ripe-781) does suggest most of the
IA will be about the impact on the NCC. But it does also mention the "
registry and addressing systems".

In Section A of the IA it says:
"Acceptance of this proposal will not change the fact that the RIPE
NCC cannot enforce which contact details members add to their IPv4 PA
assignments in the RIPE Database; this will remain their decision."
This is too vague. It is true that it is the LIRs decision if they add
contact A or contact B. However, the current policy says, as we all
know now, an assignment MUST include the contact details of the End
User. The RIPE NCC can and should enforce this policy requirement. The
type of contact should be enforced, but not the specific contact.

Section B of the IA has the title "Impact of Policy on Registry and
Addressing System". The IA only refers to the impact on the addressing
system. It says nothing about the impact on the registry. The registry
has two parts. There is the internal, private registry. This is where
the RIPE NCC stores things like contact details for the NCC to contact
their members, the LIRs. This proposal probably doesn't have any
impact on this part of the registry. The IA should still say that. The
other part is the public registry, the RIPE Database. This proposal
potentially has a huge impact on the public registry, but nothing has
been said about this in the IA. So this raises a question about the
PDP policy itself. Should the RIPE NCC focus ONLY on the impact the
proposal has on the RIPE NCC or should it discuss wider implications
for the Internet and other stakeholders?

In the legal impact (Section D) it says:
"the RIPE NCC would like to note that it is solely the responsibility
of the member to choose which contact details to insert in the INETNUM
object".
This has the same vagueness as the comment in Section A. It then
confuses the issue by talking about personal data. As I pointed out in
my first attempt at a privacy policy last year, 'contact data NOT
EQUAL personal data'. In 99% of INETNUM objects the End User contact
details can be included without making any reference to personal data.
The IA even refers to "contact person". As I pointed out last year,
all contacts should be roles and not people. We are still locked into
the mindset of referring to people.

>
> Here are some questions for the WG to get the discussion started: Do you already use AGGREGATED-BY-LIR when registering IPv6 assignments? Would you find it convenient and useful to be able to register IPv4 assignments in the same way? Does 2023-04 address this use case well in its current form, or could you think of any potential improvements?

'Convenience' is not the best parameter for determining internet
policy. The idea of aligning IPv4 and IPv6 registrations is becoming
an obsession. We should talk about aligning the two registration
systems 'where appropriate'. Also as I said early on in this
discussion, where two systems are mis-aligned, there are two ways to
bring them into alignment. We can make IPv6 registrations work the
same way as IPv4, with suitable technical improvements.

>
> We hope you will find the time to let your voice be heard!
>
> The Policy Development Process requires the proposers to adequately address any suggestions for changes or objections to the proposal in each phase, which we will do below.
>
> 1. Does 2023-04 change the contact registration requirements for assignments?
>
>
> The argument made is that the statement «When an End User has a network using public address space this must be registered separately with the contact details of the End User» found in the current policy (and removed by 2023-04 in order to bring the wording in line with that of the IPv6 policy), implicitly requires LIRs to register non-delegated/outsourced contact information for the End User in the RIPE database, not necessarily in the mandatory «admin-c» or «tech-c» attributes, but possibly in an optional attribute like «descr», «org» or «remarks».

Fundamentally changing registration policy requirements "in order to
bring the wording in line with that of the IPv6 policy" is absolutely
the wrong reason to make such a change.

>
> Proposers’ response:
>
> We do not believe so, for the following reasons, and keeping the current practice and policies in consideration:
>
> The RIPE NCC does not consider that 2023-04 changes the contact registration requirements in any way[1][2][3]. Absent any (rough) consensus in the Working Group to the contrary, we defer to the RIPE NCC’s judgement on this point.

I answered ref [1] here:
https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013860.html
ref [2] (the IA) makes no comment regarding the impact on the registry
and I answered ref [3] here:
https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013896.html

"we defer to the RIPE NCC’s judgement on this point". Policy is made
by the community. If the RIPE NCC's interpretation of a policy point
is not correct then the community can require that the RIPE NCC
re-evaluates their interpretation.

> The practice of creating assignments with all contact information delegated is already widespread. If this was a policy violation made possible due to the RIPE NCC implementing RIPE policy incorrectly, we would have expected the community to take action to correct this situation. However, no such policy proposal has been put forward by the community.

There is a lot in this paragraph. The practice of documenting End User
contact details in the optional "descr:" attributes is already
widespread. That is likely because so many LIRs do understand the
current policy. They have delegated the contact details in the
mandatory attributes. But they realize the policy requires End User
contact details so they add those details in other attributes. Given
that you have put so much emphasis on the 'manual effort required to
create assignment objects in the RIPE Database' I am sure so many LIRs
have not entered this optional detail without good reason.

"we would have expected the community to take action to correct this
situation". The fact that 'the community' did not even realise this
mis-interpretation of address policy by the RIPE NCC for so long,
perhaps says more about the community than the RIPE NCC. There is no
doubt that this is a policy violation. There are many other issues
with the way address policy has been interpreted in recent years that
I could talk about, but no one is interested. The reality is that much
of 'the community' does not pay much attention to the fine detail of
policy or the way it is interpreted.

> Outsourcing and delegation of contact information is a common practice across many industries, including in networking and information technology. There is no policy language that explicitly prohibits this for IPv4 assignments. Absent that, we believe any implicit prohibition found “between the lines” is essentially «void for vagueness»[4].

You are correct that the policy does not prohibit the delegation of
contact details. But the policy still clearly requires that End User
contact details MUST be included 'somewhere'. The two points are not
mutually exclusive. (Your ref to US criminal law is irrelevant.)

> An obligation to publish the End User’s contact information in the RIPE database will constitute a violation of Article 6(3) of the RIPE Database Terms and Conditions[5] and Article 6(1)(a) of the GDPR[6], if the End User’s contact person has not given explicit consent to such publication. We believe that the RIPE policy cannot reasonably be interpreted to require LIRs to break EU law (and even if it explicitly did require that, EU law would still take precedence).

Just as with the IA you have the 'person' mindset lock. Contacts
should be roles, not people. As suggested in the privacy discussion
last year, the roles can include optional person names if the people
so wish. We should all stop using the term 'contact person' and refer
to 'contact role'.

> The policy’s stated goal of registering assignments is «to ensure uniqueness and to provide information for Internet troubleshooting at all levels»[7]. Requiring LIRs to publish the contact information of End Users who often will not have any knowledge or capability to aid with troubleshooting does work towards this attaining goal. On the contrary, delegating the contact information to the LIR/ISP may well be the only way to attain this goal.

You have been very selective here in your interpretation of the stated
goals of the registry system. Firstly it does not state that
'uniqueness' and 'troubleshooting' form an exclusive list of the
reasons for a public registry. Over the years the registry has evolved
to the needs of other stakeholder groups. But if you want to take this
wording literally it also says "The provision of a public registry
documenting address space allocations and assignments must exist." An
aggregation does not document assignments. It simply documents that a
block of address space has been used for assignments. It is not
documenting the actual assignments as required by these defined goals.
You cannot take one sentence literally and then be flexible in your
interpretation of the other sentence.

cheers
denis

>
>
> [1] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013856.html
> [2] https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis
> [3] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013892.html
> [4] https://www.law.cornell.edu/wex/void_for_vagueness
> [5] https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms
> [6] https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#d1e1888-1-1
> [7] https://www.ripe.net/publications/docs/ripe-804#3
>
> 2. The «assignment-size» attribute should be a CIDR prefix length
>
> Leaving it undefined could result in some LIRs using it to represent an IPv4 address count, while others would use it to represent a CIDR prefix length.
>
> Proposers’ response:
>
> We agree «assignment-size» should be a CIDR prefix length. We understand that, if proposal 2023-04 would be accepted, the RIPE NCC could implement the «assignment-size» attribute for IPv4 inetnum objects to be a CIDR prefix length, and document it as such. Therefore we do not believe it is necessary to spell this out explicitly in the policy document (it is not spelled out in the IPv6 policy document either).
>
>
> Thank you for your attention and enjoy your holidays!
>
> Best regards,
> Jeroen and Tore
>
>
> Op 21 nov. 2023, om 11:13 heeft Angela Dall'Ara <adallara at ripe.net> het volgende geschreven:
>
>
> Dear colleagues,
>
> Policy proposal 2023-04, “Add AGGREGATED-BY-LIR status for IPv4 PA assignments”, is now in the Review Phase.
>
> The goal of this proposal is to introduce the AGGREGATED-BY-LIR status for IPv4 PA assignments to reduce LIR efforts in registration and maintenance.
>
> This proposal has been updated and it is now at version 2.0. The proposed policy text did not change, the only difference is that the section "Arguments opposing the proposal" includes a reference to the last round of discussion.
>
> The RIPE NCC has prepared an impact analysis on this proposal to support the community’s discussion.
>
> You can find the proposal and impact analysis at:
> https://www.ripe.net/participate/policies/proposals/2023-04
> https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis
> And the draft document at:
> https://www.ripe.net/participate/policies/proposals/2023-04/draft
>
> As per the RIPE Policy Development Process (PDP), the purpose of this four-week Review Phase is to continue the discussion of the proposal taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.
>
> At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus.
> It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.
>
> We encourage you to read the proposal, impact analysis and draft document and to send any comments to address-policy-wg at ripe.net before 20 December 2023.
>
> Kind regards,
> Angela Dall'Ara
> Policy Officer
> RIPE NCC
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/
>
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/