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, <[email protected]> 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 <[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. > > > > 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 <[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 >
-- 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
