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

I still oppose this policy and mostly agree with denis.

I don't think it makes sense to push through this policy currently given
the concerns raised and the quite limited potential benefits.

-Cynthia

On Fri, 15 Dec 2023, 15:05 denis walker, <ripedenis at gmail.com> wrote:

> Hi Jeroen
>
> Looking back over this email, there are two things that really stand out
> to me.
>
> "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?"
>
> "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)"
>
> These two statements that you made basically sum up this policy
> proposal. You are suggesting we fundamentally change IPv4 address
> policy for the 'convenience' of operators and to 'align' some words
> between two different policies regardless of the consequences.
>
> When you add to this a comment Gert made at RIPE 87 when he said that
> after 30 years we have no clue as to what the "admic-c:" attribute
> means or why anyone would want to contact them or what they would
> expect to get from such contact. We have maybe 5 or 6 million inetnum
> objects in the RIPE Database, a few million inet6num objects and
> probably tens of thousands of aut-num objects. They all have a
> mandatory admin-c and we don't know why it is there. All we have is a
> 30 year old definition that says it must be an on-site contact for the
> End User in the case of assignment and ASNs.
>
> This is a dreadful situation to be in. I suggest that 2023-04 is
> withdrawn. Then we have a wide reaching consultation with many
> stakeholder groups who use the RIPE Database. Determine what their
> needs are for a public registry. What information they need and would
> like to have in the RIPE Database. Basically do what I expected the
> last database task force to do, produce a business requirements
> document for the RIPE Database as a public registry. Then see where we
> go from there.
>
> cheers
> denis
>
>
> 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.
> >
> > 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:
> >
> > 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.
> > 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.
> > 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].
> > 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).
> > 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
> > [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/
>
> --
>
> 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/20231217/2ead6481/attachment.html>