Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Kai 'wusel' Siering
Am 15.12.23 um 15:11 schrieb Peter Hessler:
> I still support the proposal as-is. The proposed change does not
> weaken any data that is in the database, and in fact may allow it to be
> more obvious that these address ranges are used by end users rather than
> be unclear what their status is.
>
> Furthermore, I will state that Denis' objections are not relevant to the
> proposal. The proposers, various people on the lists (including myself),
> and the RIPE NCC themselves all state the opposite of what Denis is
> saying. In addition the proposers have, in my opinion, addressed the
> concerns stated.
>
> -peter
+1
Regards,
-kai
--
"Getdate firmly believes that years after 1999 do not exist; getdate
will have to be killed by the year 2000."
-- From the "Bugs" section of cnews-020592/libc/getdate.3
1 year, 2 months
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Jan Ingvoldstad
On Tue, Jan 9, 2024 at 1:23 PM Tore Anderson <tore(a)fud.no> wrote:
> Hi Jan,
>
Hi Tore and thanks for coming back so quickly.
>
> On 09/01/24 10:51, Jan Ingvoldstad wrote:
> > On Sat, Dec 16, 2023 at 7:55 PM Tore Anderson <tore(a)fud.no> wrote:
> >
> > The second – alleged – change is the one that has been discussed the
> > most on the mailing list. The argument here is that your two ASSIGNED
> > PA objects above are actually in violation of *current* policy,
> > because
> > they delegate all the contact information to you (the ISP/LIR). The
> > claim is that current policy requires non-delegated contact
> > information
> > for the End User to be published in the object (not necessarily in
> > admin-c/tech-c, but “somewhere”).
> >
> > If 2023-04 passes, your two ASSIGNED PA assignments above will
> > definitely be policy compliant (even before they are possibly
> replaced
> > with an AGGREGATED-BY-LIR object). There is no disagreement about
> > this,
> > as far as we know.
> >
> > So the question is whether or not your two ASSIGNED PA objects are
> > permitted under *current* policy. If they are, then 2023-04 does not
> > change anything in this regard; the “legal status” of your objects
> > will
> > remain the same – i.e., they are not violating policy – after 2023-04
> > passes (or fails) as it is under current policy.
> >
> > We believe your two objects are not in violation of today’s policy,
> > which means 2023-04 will exact no change to their “legal status”. We
> > have elaborated on why in this message, under the heading «Does
> > 2023-04
> > change the contact registration requirements for assignments?»:
> >
> >
> https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/013…
> >
> > We hope this provides the clarification you requested.
> >
> >
> > Regrettably it does not, and it also raises the question of whether
> > you have forgotten the definition of "end user" and confused it with
> > "private person".
> >
> > 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).
> >
> >
> > This is misleading, as posting the contact details of an end user
> > **does not necessarily require that you post PII** (person identifying
> > information). You can use a company role and a company role's email
> > address. This is also quite common in the RIPE database today, as far
> > as I can tell.
>
> It is important to also consider the cases where the End Users are
> organisations that do not have non-PII role addresses.
>
> Consider for example a small one-person business, let's say a farm owned
> by «Farmer Fred». This End User would be a company, not an individual,
> yet the company is often given the same name as the person owning it (at
> least here in Norway).
>
> The e-mail address might well be farmer.fred@gmail and the phone number
> might be the Farmer Fred's personal mobile. This would mean that both
> the name and the contact information for this End User *is* PII and is
> in scope of the GDPR.
>
The current interpretation of this part of the GDPR is that "Farmer Fred"
is permissible to publish.
>
> Therefore, if Farmer Fred exercises his rights under the GDPR to object
> against / not give consent to the publishing of his PII in the RIPE DB,
> you (the LIR) have a problem. Proceeding to publish this contact
> information over Farmer Fred's objections opens you up to legal risk
> (not to mention souring the relationship with your customer).
>
The solution here would be to not publish (and not require the publication
of) personal phone numbers (or personal addresses), and to clearly make
this a requirement in the policy regarding what End User information is
published.
Similarly, that requirement must be there for *any* contact object, not
just End Users.
You cannot know if the LIR's phone numbers are personal or not, or can you?
>
>
> > Additionally, this is what we in the registrar business consider a
> > solved problem. In the event that the end user is a private person,
> > you instead by default post anonymized information and e-mail
> > addresses. In the case of e-mail addresses, the typical solution is to
> > post a randomized e-mail address that acts as a forwarding address,
> > and that this address is rotated according to the registrar's internal
> > criteria. In the case of RIPE, it would be the LIR's responsibility, I
> > guess.
>
> Precisely. The LIR, like a domain name registrar, can simply serve as a
> proxy between the wider Internet community and its End Users.
No, that is not what I wrote.
This is about an automatic email forwarding scheme, not about a
registration by proxy scheme.
E.g. you register the domainname ripe-example.shop with a registrar within
the EEA, your email address is published (for EEA-based domainnames,
anyway) as e.g. qaobuaidbvsas(a)privacy.example, which is a valid email
address that is automatically forwarded to e.g. tore+ripe-example(a)fud.no.
> This voids
> any policy requirement to (possibly illegally) publish Farmer Fred's PII
> in the RIPE DB. As stated in the Impact Analysis, the RIPE NCC is of the
> opinion that this (already widespread) practice is permitted by current
> policy, and will continue to be permitted after 2023-04 is implemented.
> In other words, just like in the registrar business, this is an already
> solved problem, which will continue to be solved after 2023-04 is
> implemented. It is in this respect that we say that 2023-04 will not
> bring about any change – it ain't broken, and we're not fixing it.
>
> The claim that has been made is that *current* policy does not allow
> LIRs to serve as proxies in this manner, and that the RIPE NCC has not
> been implementing current policy correctly by allowing it. It is further
> claimed that 2023-04 will bring about an (undesired) change in that it
> will allow LIRs to serve as proxies. However, for the reasons already
> discussed we are of the opinion the premise this argument rests on is
> incorrect, hence we do not believe 2023-04 will effect any change.
>
> We hope this clarifies the clarification. :-)
>
I was kindof trying to avoid that argument again.
But sure, as you bring it up again.
This opinion is obviously a logical impossibility.
There is no way that you can change something and at the same way
legitimately claim that the change is not a change.
If it is true that the current practice is both widespread and accepted,
then *no change is necessary*.
If a change is necessary, it is logically because there is a widespread and
accepted practice of publishing End Users' contact information.
The argument is therefore nonsensical, sorry.
You have not actually addressed this concern and objection, you have merely
restated claims and opinions that do not actually do so.
I therefore again urge you to resubmit the proposal *without* this removal.
Then, if this part of the policy change is of importance, resubmit it as a
separate proposal, and preferably clearing up the PII mess a bit more. I
have no beef with clearing that up.
--
Jan
1 year, 1 month
Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by denis walker
On Mon, 11 Sept 2023 at 18:09, Brian Storey <Brian.Storey(a)gamma.co.uk> wrote:
>
> Hi Tore,
>
> Does this not contradict other purposes / objectives of the registry, including the principles of registering public networks or am I missing something?
+1
my thoughts exactly
cheers
denis
co-chair DB-WG
>
> Many thanks,
> Brian
>
> -----Original Message-----
> From: address-policy-wg <address-policy-wg-bounces(a)ripe.net> On Behalf Of Tore Anderson
> Sent: Monday, September 4, 2023 12:22 PM
> To: Andrii Syrovatko <andrey_syrovatko(a)trifle.net>; address-policy-wg(a)ripe.net; adallara(a)ripe.net
> Cc: APEX NCC ORG <registry(a)apex.dp.ua>; Trifle NOC <noc(a)trifle.net>
> Subject: Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
>
> * APEX NCC ORG
>
> > Hello, Team!
> > I read the offer provided:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ripe.net%2Fparticipate%2Fpolicies%2Fproposals%2F2023-04&data=05%7C01%7
> > Cbrian.storey%40gamma.co.uk%7C3a23e9f95d904f83274a08dbad391d6b%7C743a5
> > d9f11234f3f8fcf5766b8ad8bf9%7C0%7C0%7C638294233043320645%7CUnknown%7CT
> > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> > 6Mn0%3D%7C3000%7C%7C%7C&sdata=9dEJGnNWdlapbyyzjM5qgJvn%2BB6G%2BGp6jjmu
> > %2FcDzZPY%3D&reserved=0
> > three times.
> > However, I still don't understand the real reason for introducing the
> > AGGREGATED-BY-LIR status The text of the proposal contains only
> > general provisions.
> > Can you provide a more detailed description and examples?
>
> Hi Andrii!
>
> There are several possible examples, but let me give you just one:
>
> Let's say you're a small cloud VPS provider in the business of leasing out virtual machines to small businesses and private individuals. Your cloud management software dynamically assigns IPv4 addresses out of
> 192.0.2.0/24 to customers, so you have for example:
>
> 192.0.2.1/32 = assigned to Alice's first VM - used for a web server
> 192.0.2.2/32 = assigned to Bob - used for a Minecraft server
> 192.0.2.3/32 = assigned to Bob's hair salon business = web server
> 192.0.2.4/32 = assigned to Alice's second VM - mail server
>
> …and so on.
>
> Current policy requires you to register four individual INETNUM assignments of size /32 for the above four virtual machines.
>
> However, due to the GDPR requirements, you usually cannot put Alice's and Bob's names or contact info into the RIPE database, so instead you typically substitute your own (this is allowed by policy).
>
> That means you have now four individual INETNUMs with identical contact information (your own). You need to add or remove these /32 INETNUMs as customer VMs come and go. You can automate this, but it is a pointless exercise in any case.
>
> To avoid this, we propose allowing you to create a single INETNUM that covers the entire 192.0.2.0 - 192.0.2.255 range, just like you can already do with any IPv6 assignments made to the same VMs. This aggregated object will cover all customer VMs in your cloud infrastructure, present and future, and makes it so that you don't have to send a RIPE database update every time a customer VM is provisioned or discontinued.
>
> Tore
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.rip…
> --
>
> 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
1 year, 5 months
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Cynthia Revström
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(a)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(a)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/01…
> > [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/013…
> > [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#d…
> > [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(a)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(a)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://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
>
1 year, 2 months
Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Tore Anderson
* APEX NCC ORG
> Hello, Team!
> I read the offer provided:
> https://www.ripe.net/participate/policies/proposals/2023-04
> three times.
> However, I still don't understand the real reason for introducing the
> AGGREGATED-BY-LIR status
> The text of the proposal contains only general provisions.
> Can you provide a more detailed description and examples?
Hi Andrii!
There are several possible examples, but let me give you just one:
Let's say you're a small cloud VPS provider in the business of leasing
out virtual machines to small businesses and private individuals. Your
cloud management software dynamically assigns IPv4 addresses out of
192.0.2.0/24 to customers, so you have for example:
192.0.2.1/32 = assigned to Alice's first VM - used for a web server
192.0.2.2/32 = assigned to Bob - used for a Minecraft server
192.0.2.3/32 = assigned to Bob's hair salon business = web server
192.0.2.4/32 = assigned to Alice's second VM - mail server
…and so on.
Current policy requires you to register four individual INETNUM
assignments of size /32 for the above four virtual machines.
However, due to the GDPR requirements, you usually cannot put Alice's
and Bob's names or contact info into the RIPE database, so instead you
typically substitute your own (this is allowed by policy).
That means you have now four individual INETNUMs with identical contact
information (your own). You need to add or remove these /32 INETNUMs as
customer VMs come and go. You can automate this, but it is a pointless
exercise in any case.
To avoid this, we propose allowing you to create a single INETNUM that
covers the entire 192.0.2.0 - 192.0.2.255 range, just like you can
already do with any IPv6 assignments made to the same VMs. This
aggregated object will cover all customer VMs in your cloud
infrastructure, present and future, and makes it so that you don't have
to send a RIPE database update every time a customer VM is provisioned
or discontinued.
Tore
1 year, 6 months
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Sebastian Graf
Dear Jan!
As mentioned in my previous e-mail: Would you please post the section of
the policy that you belive has the NCC's interpretation differ from the
actual wording/language used?
Because i have yet to find a section that states explicitly what is
considered valid vs invalid contact information (other than being out of
date or information that does not provide a contact to the user in a
timely manner). Or a section that restricts what kind of data is
permissable for "contact information".
Kind Regards
On 1/12/24 07:25, Jan Ingvoldstad wrote:
> I also do not understand what makes it so hard to say that: "Yes, the
> current policy does state something else than NCC's interpretation of
> it does, and therefore current practice contradicts (or appears to
> contradict) policy. However, we, the proposers, believe that the
> current practice makes for the best policy, and therefore propose
> amending the policy to reflect practice."
1 year, 1 month
[policy-announce] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Sylvain Baya
Dear address-policy WG,
Hope this email finds you in good health!
Please see my comments below, inline...
Thanks.
Le vendredi 15 décembre 2023, Peter Hessler <phessler(a)theapt.org> a écrit :
> I still support the proposal as-is. The proposed change does not
> weaken any data that is in the database, and in fact may allow it to be
> more obvious that these address ranges are used by end users rather than
> be unclear what their status is.
>
>
Hi Peter,
Thanks for your email, brother.
>
> Furthermore, I will state that Denis' objections are not relevant to the
> proposal.
>
...this statement might have not sufficiently
considered the fundamental issues raised by
him.
> The proposers, various people on the lists (including myself),
> and the RIPE NCC themselves all state the opposite of what Denis is
> saying.
>
...i have to step in; because i think it should not be
about the number of occurrence of an argument.
...imho! consensus should not be attained when fundamental issues such as a
misinterpretation
of a policy, or its misimplementation, might have
occured silently.
What's the process in the event of such a claim ?
...imho, i'm not sure that we should just move on
without first correcting the mistinterpretation
issue identified :-/
Without restoring the truth, it would be really tough
to correctly evaluate the risks regarding proposed
changes around the actual policy.
> In addition the proposers have, in my opinion, addressed the
> concerns stated.
>
...as the core problem is above them; they stated
that they refer to the Staff who produced the IA
(Impact Analysis); avoiding the hot topic :-/
The issue raised by Denis remains unaddressed...
...imho!
...i stand with him; asking for a pause regarding
the progress of this policy proposal.
Shalom,
--sb.
> -peter
>
>
> On 2023 Nov 21 (Tue) at 11:13:57 +0100 (+0100), Angela Dall'Ara wrote:
> [...]
--
Best Regards !
__
baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure>
Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/>
__
#LASAINTEBIBLE|#Romains15:33«Que LE #DIEU de #Paix soit avec vous
tous! #Amen!»
#MaPrière est que tu naisses de nouveau. #Chrétiennement
«Comme une biche soupire après des courants d’eau, ainsi mon âme soupire
après TOI, ô DIEU!»(#Psaumes42:2)
1 year, 2 months
Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
by Gert Doering
Hi,
On Tue, Apr 09, 2024 at 04:31:06AM +0200, denis walker wrote:
> Tore you are absolutely right, the cat is out of the bag...but which
> cat? You seem fine about how the RIPE NCC has been mis-interpreting
> policy for 10 years and how they have no power to enforce it other
> than the nuclear option, which we all know they will not use. The
> revelations from this discussion have completely changed the landscape
> for RIPE policy. It has been totally undermined.
There is no "change of landscape" or "undermining of policy" here - to
anyone following address policy it was always clear that there is
some leeway in registering end user assignments (INFRA-AW), and that
the NCC cannot enforce correctness of all data.
They can and do audits, and back when there was still new space to
be had, such an audit could have very unpleasant consequences - namely,
reducing the AW to 0, and refusing allocation of new blocks, until
documentation was fixed. Since there is no more v4 space at the NCC,
all these levers are gone (through no fault of policy or the NCC).
Also it was discussed a number of times here on the list and in the
meetings what LIRs should put into the admin-c: and tech-c:, given that
natural persons being involved might not agree to be listed in a public
database with their personal information. So "register the NOC here",
and for single user end customers "register the LIR contacts" has been
established practice for a long time.
So while I totally agree that we all (as "the LIRs in the RIPE region")
might not have been following policy to *the letter*, overall most of us
followed it to the *spirit* - "put someone in there that will take
responsibility and can take action if needed" (which the letter "put
someone in who is on-site" will not achieve).
Should we work on improving the documents? By all means, yes.
Has this anything to do with 2023-04, or the last call for it? Hardly.
Gert Doering
-- speaking as LIR contact, and with some policy experience
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard,
Ingo Lalla, Karin Schuler
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
10 months, 3 weeks
@EXT: FW: 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Kessler, Emmanuel
Dear all,
Thanks for the various points provided after my last message of the 13th December.
we are assessing them with our colleagues of the police forces and we have shared with cybersecurity actors the EU.
>From Law enforcement perspective, we would consider highly reasonable that RIPE organises a full consultation with relevant stakeholder groups that use RIPE data basis, to fully assess the impact and their needs.
Such consultation would be necessary and legitimate as considering the official agreement signed on 2016 between RIPE NCC and EUROPOL that states that both parties, in accordance with their respective mandates, inform each other about the implementation of their respective mandates in the area of cybercrime, inform each other of programmes of potential interest in order to identify possibilities for joint activities and mutual contributions.
As already mentioned, we were informed only recently about the proposal that would need full assessment that takes time.
Any new loss of information linked with aggregation of IPV4, would mean less criminals identified and more victims targeted or in life danger.
Such losses of information would also conflict with current EU regulatory activities against the "going dark matter" (loss of access to information for LE authorities for judicial purposes).
This problem is highly identify at EU level, and I would also prefer to prevent any future misunderstanding between actors in RIPE and EU actors, would the measure be adopted in an hasty way...
>From reading your points, I observe that beyond text, is the matter of the real implementation by LIRs and others...we need to clarify and ensure that.
Thanks for your understanding and constructive spirit.
Regards
Emmanuel KESSLER
Emmanuel KESSLER
Head of Team - Prevention/Outreach
Europol - O3 European Cyber Crime Centre (EC3)
Eisenhowerlaan 73, 2517 KK
The Hague, The Netherlands
Phone: [Moderated] / mobile [Moderated]
www.europol.europa.eu<http://www.europol.europa.eu/>
[cid:image001.png@01D8169D.5B765D70]
-----Original Message-----
From: denis walker <ripedenis(a)gmail.com>
Sent: 15 December 2023 15:05
To: Jeroen Lauwers <jlauwers(a)a2b-internet.com>
Cc: RIPE Address Policy Working Group <address-policy-wg(a)ripe.net>; Gert Doering <gert(a)space.net>; Kessler, Emmanuel <Emmanuel.Kessler(a)europol.europa.eu>
Subject: Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
This email originated from outside Europol. Do not click links or open attachments unless you recognize the sender and know the content is safe.
The external address that sent the message is: denis1(a)gmail.com
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(a)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-Septemb
> er/013856.html [2]
> https://www.ripe.net/participate/policies/proposals/2023-04#impact-ana
> lysis [3]
> https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-Novembe
> r/013892.html [4] https://www.law.cornell.edu/wex/void_for_vagueness
> [5]
> https://www.ripe.net/manage-ips-and-asns/db/support/documentation/term
> s [6]
> https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0
> 679#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(a)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-ana
> lysis
> 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(a)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://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
1 year, 2 months
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Jan Ingvoldstad
On Fri, Jan 12, 2024 at 9:28 AM Sebastian Graf <ripe-lists(a)sebastian-graf.at>
wrote:
> Dear Jan!
>
Dear Sebastian,
> Thank you for your reply. But you have not answerred my question.
>
I answered your question, but I did not understand that you intended your
ancillary comment as an additional question. Sorry about that.
> We are all clear/well aware on the fact that the policy states
> (paraphrasing here: resources need to be registered and the registions need
> to have contact information).
>
> We are looking for the DEFINITION of "contact details of the End User.".
> This is not directly defined (as far as i can tell) and is therefore open
> for interpretation.
>
> Unless i missed something?
>
>
> As I understand it, this comes from how contact objects are defined in the
database, and this is what RIPE-804 references.
Denis has provided more detailed context.
RIPE-705 sets specific requirements regarding abuse contact details.
--
Jan
1 year, 1 month