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 <[email protected]> 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 <[email protected]> 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 [email protected] 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://lists.ripe.net/mailman/listinfo/address-policy-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 -- 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
