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

Dear Collegues!

Looking at the impact analysis, the proposal and reviewing the arguments 
- i would like to agree with this proposal.

In the best case scenario it may improve the accuracy of database 
entries. I also belive it will aid the goals of the registry because 
this way the usage of inetnums can be documented more clearly.

Kind Regards


On 12/13/23 19:14, Jeroen Lauwers 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.
>
> 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?
>
> 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».
>
>
>       Proposers’ response:
>
> We do not believe so, for the following reasons, and keeping the 
> current practice and policies in consideration:
>
> 1.
>     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.
> 2.
>     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.
> 3.
>     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].
> 4.
>     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).
> 5.
>     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.
>
>
> [1] 
> https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/013856.html 
> <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 
> <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 
> <https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013892.html>
> [4] https://www.law.cornell.edu/wex/void_for_vagueness 
> <https://www.law.cornell.edu/wex/void_for_vagueness>
> [5] 
> https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms 
> <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 
> <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 
> <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/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20231213/ca27c4a9/attachment.html>