Re: [address-policy-wg] Draft Address Policy WG Agenda for RIPE 87, Rome
by Leo Vegoda
Hi,
Here's an updated agenda. Item H has changed to a broader discussion.
Kind regards,
Leo
Session 1 starts: 09:00
A. Introduction [5 min]
B. Chair Selection [10 min]
C. NRO NC / ICANN ASO AC Update [10 min]
Hervé Clement and/or Sander Steffann
D. Registry Services Update Followed by Q&A [15 min]
Marco Schmidt, RIPE NCC
E. Policy Update Followed by Q&A [15 min]
Angela Dall'Ara, RIPE NCC
F. Discussion: What is the purpose of IPv4 assignment registration in
2024? [30 mins]
[co-chairs to show 1 discussion slide]
Session 1 ends: 11:00
☕
Session 2 starts: 11:30
G. 2023-04: Add AGGREGATED-BY-LIR status for IPv4 PA assignments [25 mins]
Jeroen Lauwers, A2B Internet
Tore Anderson, Redpill Linpro
H. The Future of IPv6 Policy [25 mins]
Introdicuing ideas for change and setting priorities
(Discussion)
I. AOB [10 mins]
Session 2 ends: 12:30
On Thu, 9 Nov 2023 at 11:57, Leo Vegoda <leo(a)vegoda.org> wrote:
>
> Hi,
>
> Here is our draft agenda for Rome.
>
> We can make refinements if needed, so please contact the chairs if you
> would like us to add or change something.
>
> Kind regards,
>
> Leo
>
> Session 1 starts: 09:00
>
> A. Introduction [5 min]
>
> B. Chair Selection [10 min]
>
> C. NRO NC / ICANN ASO AC Update [10 min]
> Hervé Clement and/or Sander Steffann
>
> D. Registry Services Update Followed by Q&A [15 min]
> Marco Schmidt, RIPE NCC
>
> E. Policy Update Followed by Q&A [15 min]
> Angela Dall'Ara, RIPE NCC
>
> F. Discussion: What is the purpose of IPv4 assignment registration in
> 2024? [30 mins]
> [co-chairs to show 1 discussion slide]
>
> Session 1 ends: 11:00
>
> ☕
>
> Session 2 starts: 11:30
>
> G. 2023-04: Add AGGREGATED-BY-LIR status for IPv4 PA assignments [25 mins]
> Jeroen Lauwers, A2B Internet
> Tore Anderson, Redpill Linpro
>
> H. Improving IPv6 PI Policy [25 mins]
> Tobias Fiebig
>
> I. AOB [10 mins]
>
> Session 2 ends: 12:30
1 year, 1 month
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Jan Ingvoldstad
On Thu, Jan 11, 2024 at 9:45 AM Tore Anderson <tore(a)fud.no> wrote:
> Hi Denis,
>
> On 11/01/24 03:20, denis walker wrote:
>
> > This is total madness. You keep saying you have no intention of
> > changing anything else. You keep saying the wording change actually
> > changes nothing in practice. Some other people don't agree with you.
> > Just don't change wording that you claim changes NOTHING and has
> > nothing to do with aggregation and everyone is happy. The fact that
> > you are pushing so hard to make this wording change, you refuse to
> > back down or compromise, you insist on changing wording that changes
> > nothing and has nothing to do with aggregation...proves that you don't
> > believe that yourself. The fact is, I suspect that this is the real
> > change you want. You want to drop the current policy requirement to
> > define assignments with End User contacts. It is the aggregation that
> > is the side issue here. There is no other explanation for why you are
> > insisting so strongly on changing wording that changes nothing.
>
> Here we find ourselves in conspiracy theory land, frankly.
Uh. While questioning your motives is perhaps a bit rude, this is WAY over
the top, Tore.
Please retract this weird accusation, I really don't understand your
motives for trying to label this as having to do with a conspiracy theory.
It tarnishes the discussion.
> It makes zero
> sense, too:
>
> If our ulterior goal was to remove the End User contacts from our own
> assignments we can just go ahead and do so, right now. The RIPE NCC is
> already on the record saying that's totally OK, and we would be
> following in the footsteps of many other LIRs who have already done so.
> Why on Earth would we waste our time on a policy proposal?
>
> If our ulterior goal was to remove the End User contacts from other
> LIRs' assignments, 2023-04 simply doesn't accomplish this goal, because
> it conveys no requirement on LIRs to remove anything from the database
> whatsoever.
>
> The RIPE NCC has not identified any unintended or ulterior side effect
> caused by 2023-04 either, does that mean they are a part of the
> conspiracy too?
>
While you seem to argue that the RIPE NCC is both omniscient and
omnicompetent, I do not think it is that easy.
I simply think that the RIPE NCC and you are mistaken.
Continously appealing to RIPE NCC as the authority of policy and policy
interpretation is not a good thing.
It undermines the community drive behind policies.
If this is where we are going, it seems that we would be just as well off
by letting EU politicians run the show.
--
Jan
11 months, 2 weeks
Re: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04
by Tore Anderson
Hi Denis,
On Fri, 2023-12-15 at 14:20 +0100, denis walker wrote:
> We have been through all these arguments before, but it is the review
> phase now so they need to be repeated.
Indeed. We will now restate our responses too, as required by the PDP.
That said, there are no new arguments presented, so anyone reading this
should feel free to skip the rest of this message.
> On Thu, 14 Dec 2023 at 16:34, Tore Anderson <tore(a)fud.no> wrote:
> >
> > «As of August 2023, there were 19,221 PA allocations without any child
> > PA assignments held by 10,052 LIRs (…) Since the RIPE Database
> > Requirements Task Force published their report in May 2021, the PA
> > allocations without any child assignment have grown by 18.4 percent.»
>
> 18.4% of 19,221 is 3536. How many /24 allocations were made in that
> time period that quite likely don't have assignments?
We will ask the RIPE NCC to provide the working group with the updated
statistics you request here.
>
> > We hypothesise that this trend is least partially caused by LIRs
> > considering that registering all assignments individually is too
> > labour-intensive and not worth the effort, especially in highly dynamic
> > environments where individual (but otherwise identical) assignments
> > rapidly come and go.
>
> Pure speculation without any numbers.
We have no hard data that prove (or disprove) this hypothesis, that is
true. We have not surveyed the LIRs in question to ask them why they
opt not to register assignments. That said, as we do have quite a bit
of experience as LIR hostmasters (including working with highly dynamic
network environments), we would prefer to call the hypothesis an
educated guess, rather than pure speculation.
> But what you are suggesting is that some LIRs don't consider it worth
> the effort to comply with RIPE policy and don't want to get involved
> in discussions to change the policy.
Regrettably, yes.
> I don't agree with your proposal but at least you are trying to
> change something you don't agree with.
We do appreciate you recognising that.
> As for the labour intensity, we know the answer to that, but no one
> will even talk about updating the 25 - 30 year old RIPE Database
> design, data model and technology...
We don't doubt that updating the RIPE database design, data model and
technology is a good idea, but we believe this question falls outside
of the scope of proposal 2023-04 (and the AP-WG charter entirely).
> As for 2023-04 increasing the level of End User assignment coverage,
> this is pure fantasy. In theory you could perhaps argue that the
> 'coverage' has increased if many LIRs create aggregated objects and
> claim that many assignments have been made from within that block.
If a WHOIS lookup of an IPv4 address that today will return an
ALLOCATED PA object (even though it is in fact assigned and in use) but
after the implementation of 2023-04 will return an AGGREGATED-BY-LIR
object, then we consider that the assignment coverage has increased.
> But the End User details will be completely lost within that
> amorphous block.
We believe this concern has been addressed in the following 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…
> Not even the assignment boundaries can be deduced.
As mentioned in the proposal text itself, we did not see any
independent justification for making the assignment-size attribute
mandatory in IPv4, as its use in the calculation of the HD-ratio in
IPv6 is not applicable.
That said, if you or anyone else in the working group can identify and
clearly articulate an independent justification for making the
assignment-size attribute mandatory in IPv4 too, then we will certainly
give that due consideration and possibly amend the proposal
accordingly.
> Many other LIRs may well anonymize their future or even already
> existing assignments by removing all references to the End User's
> identity and contact details. This may be done at the request of the
> End User. Or it may be done because the LIR has adopted a policy of
> not entering any details of their customers (End Users) into a public
> database. I have spoken to LIRs who have made it clear that it is
> already their policy regardless of current RIPE address policy
> requirements. They consider it commercially sensitive data.
We believe these concerns have been addressed in the following 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…
> There are technical solutions to mitigate this but again no one will
> talk about the database.
We assume you refer to improving the RIPE database technology here,
which we have answered earlier on in this message.
>
> > 2023-04 would provide these LIRs a less labour-intensive option to
> > register such assignments. Whether or not they would avail themselves
> > of the new option is of course an open question, but it seems clear
> > that something has to be done if the current trend towards less
> > assignment coverage in the database is to be reversed.
>
> Less labour intensive by dumping the detail. This is about
> eliminating a problem rather than solving the problem, again because
> no one will talk about technical solutions. You cannot define a trend
> based on two measurement points. I agree something does need to be
> done to get more LIRs complying with RIPE policies. But changing the
> registration rules so that more people appear to follow them is not
> the way forward.
We believe the concerns about «dumping the detail» and «changing the
registration rules» have been addressed in the following 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…
As for the «technical solutions» part, we assume you refer to improving
the RIPE database technology, which we have answered earlier in this
message.
> >
> > Taking into account the current policies and procedures, we suspect
> > that the information about the End Users that LEAs can obtain
> > directly from the RIPE database is inserted there voluntarily in
> > the first place.
>
> Or because some LIRs have correctly interpreted the current policy.
We do not believe that interpretation to be correct, as noted in the
following 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…
>
> It is a good idea to align the IPv4 and IPv6 systems of registration
> 'where appropriate'.
Agreed.
> But maybe copy and paste without due consideration is not the best
> way to do it.
We believe we have given this due consideration prior to submitting the
proposal. We have looked at how AGGREGATED-BY-LIR is being used in IPv6
(it appears to be popular amongst LIRs as there are almost 60k such
objects in the database) and contrasted this with how there is an
ongoing challenge with LIRs not registering their IPv4 assignments at
all (cf. ripe-767 section 6.1.2).
We truly believe AGGREGATED-BY-LIR strikes a good balance here,
otherwise we would not have submitted our proposal.
> There are differences. In those "many years" of aggregating IPv6
> assignments not much of the internet was using IPv6. So it is not a
> valid argument to say there have been no problems with aggregating
> IPv6 over those "many years" so it must be OK. As more of the
> internet moves to IPv6, maybe we will start to see the problems that
> have been insignificant in the past.
IPv6 is extensively used nowadays, yet so far we have not seen anyone
describing any problems caused by AGGREGATED-BY-LIR in IPv6 (much less
attempt to fix them). If there truly were any problems with IPv6
AGGREGATED-BY-LIR, we would have expected them to manifest by now.
We have not seen any reason to expect that IPv4 AGGREGATED-BY-LIR would
be any more (or less) problematic than IPv6 AGGREGATED-BY-LIR.
> Maybe we will need to expand the IPv6 registration of assignments to
> match the current IPv4 policy.
That is certainly something the community could do if it wanted. That
would not be our preferred approach, though, as we fear this might
import the problem of LIRs not registering assignments (cf. ripe-767
section 6.1.2) from IPv4 into IPv6, do nothing to help with the labour
intensiveness of keeping the RIPE database up to date in highly dynamic
environments (rather it would introduce or aggravate that problem in
IPv6), as well as leave us with a major headache about what to do with
the ~60k invalidated AGGREGATED-BY-LIR inet6num objects.
> Again there are technical solutions here that no one will talk about.
We assume you refer to improving the RIPE database technology here,
which we have answered earlier on in this message.
Best regards,
Jeroen and Tore
1 year
Re: [address-policy-wg] 2023-01 Extended Discussion Phase (Reducing IXP IPv4 assignment default size to a /26)
by Steven Bakker
Hi,
Looks good to me.
-- Steven
On Mon, 2023-04-24 at 09:01 +0200, Angela Dall'Ara wrote:
> Dear colleagues,
>
> The policy proposal 2023-01, "Reducing IXP IPv4 assignment default
> size to a /26" is now in the extended Discussion Phase.
>
> This proposal modifies the default size of IPv4 assignments for IXPs
> from a /24 to /26 and clarifies the return of the assignments
> previously issued for their IXP peering LAN.
>
> The Discussion Phase has been extended as there was some support for
> the concept, but no feedback was sent on v 2.0.
>
> As per the RIPE Policy Development Process (PDP), the purpose of this
> five-week Discussion Phase is to discuss the proposal and provide
> feedback to the proposers.
> If you support this version of the proposal (v 2.0), please indicate
> that support with a simple message to the mailing list.
> If you have objections or would like a change, please provide that
> feedback to the mailing list.
>
> At the end of the Discussion Phase, the proposers, with the agreement
> of the WG Chairs, will decide how to proceed with the proposal.
>
>
> You can find the full proposal at:
> https://www.ripe.net/participate/policies/proposals/2023-01
>
> The PDP document can be found at:
> https://www.ripe.net/publications/docs/ripe-781
>
>
> We encourage you to review this proposal and send your comments to
> address-policy-wg(a)ripe.net before 29 May 2023.
>
>
> Kind regards,
>
> Angela Dall'Ara
> Policy Officer
> RIPE NCC
1 year, 8 months
Re: [address-policy-wg] 2023-04 Who do I speak for?
by Gert Doering
Hi,
On Mon, Oct 16, 2023 at 09:09:47PM +0200, denis walker wrote:
> Another interesting observation is that before the current chairs of
> the DB-WG, ALL previous chairs only ever signed any email with their
> first name. None of them ever signed anything 'as' a co-chair. Looking
> at other mailing lists, including this AP-WG, most chairs
> intermittently sign emails (at least on their own list) with or
> without the chair title suffix. Again this goes back to the beginning
> of time. So there doesn't seem to be any convention on how chairs sign
> emails. Maybe I'll just sign with my name (as many others do), then I
> can't be criticised for wearing the wrong hat.
I've had to decide what to put under my name a few times in the last
years... one part of it was "inside 'my' working group" (then AP) - I
tried to only sign as "APWG chair" when it was in the formal role
("call to order", "summarize a discussion", "announce something"),
and putting something else there, like "speaking as LIR contact", when
expressing my more personal opinions, based on experience in that role.
More interesting is "taking part in a different working group's decision"
- there is good reason for "speaking up as WG chair of another WG", like
"my WG tasked me to bring across a WG position" or "from experience in
our WG, I can offer some advice" - but for me, this always was exceptional,
and when I took part in a debate of personal opionions, I tried to leave
the WG out of it ("I do not know what my WG wants, so I cannot speak
for them")...
But you're right this has never been formalized - and I'm not sure it
can be done easily. WGs are different, people are different, personalities
are.
Gert Doering
-- frequent mailing list poster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
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 Thu, Jan 11, 2024 at 1:11 PM Tore Anderson <tore(a)fud.no> wrote:
> Hi Jan,
>
Hi Tore,
skipping your blatant misconception of what constitutes a "conspiracy
theory" ...
> > Continously appealing to RIPE NCC as the authority of policy and
> > policy interpretation is not a good thing.
>
> The RIPE NCC is the secretariat of the RIPE Community and is delegated
> the task of implementing and enforcing the RIPE Community policies, as
> well as to providing training to the LIRs on how to operationalise said
> policies. If that is not an authority worth paying attention to, I do
> not know what is.
>
> After all, any LIR which prefers the RIPE NCC interpretation of the
> policy in this regard is may simply adhere to it and act accordingly,
> and this is commonly done today. Thus the RIPE NCC's interpretation of
> the policy – mistaken or not – ends up becoming the (de facto) way the
> policy is implemented anyway.
>
This statement basically renders the point of a policy working group moot.
--
Jan
11 months, 2 weeks
Re: [address-policy-wg] 2023-04 Are anonymised assignment objects valid?
by Jan Ingvoldstad
Hi, and sorry for not engaging in this discussion at an earlier point in
time.
On Mon, Oct 2, 2023 at 6:09 PM Sander Steffann <sander(a)steffann.nl> wrote:
>
> I personally have no problem with this change. I recognise the importance
> of documenting every end-user’s contact details, as end-users were often
> actively involved in running their network. But in this day and age of
> outsourcing, the value of the information is much lower than it used to be.
>
> I’m not saying that there is no value anymore! There are many cases where
> resource holders are actually network operators with relevant information
> in the DB, but I don’t think that changing the policy will cause them to
> suddenly stop creating DB objects. And for those who don’t *want* to
> document things, they have already found ways around that in the current
> implementation of the policy.
>
I sort of agree with the reasoning, however: sloppy contact details have
real world consequences.
They result in blocklisting of entire IP ranges, for email, or even for
other kinds of network traffic, because the contacts listed are "dummy"
contacts.
Denis is, although wordy and repetitive, pretty much dead on with the
reasoning.
However, I do not think it is necessary to require person names or other
direct PII.
Roles and role addresses could be encouraged.
In some parts of the Internet, there are regulatory requirements that abuse
departments answer and deal with complaints in a timely manner. These time
limits are fairly short.
Just because e.g. Google and Microsoft laugh in the face of such
requirements and provide dysfunctional contact points, does not make it
okay, nor an obvious matter of policy change to remove the requirement.
>
> I think the best way forward would be:
> - encourage operators to document *useful* contact info (a SHOULD)
> - don’t require what we don’t/won’t/can’t enforce (no MUST)
>
I disagree, the MUST should be there.
> - realise that the current internet is not the internet that this DB was
> designed for
>
Might as well stop issuing policy at all, then.
> - align IPv4 and IPv6 requirements/standards where possible
>
I see no reason why policyregarding contact details should differ between
IP versions.
--
Cheers,
Jan
1 year, 2 months
Re: [address-policy-wg] @EXT: FW: 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Leo Vegoda
Dear Emmanuel KESSLER,
Thank you for participating in the RIPE community.
You referenced the 2016 MoU between RIPE NCC and EUROPOL in your most
recent comment. It's important to note that this Working Group is a
RIPE community activity and not a RIPE NCC activity.
The RIPE community is open to participation by anyone and is not a
legal entity. The RIPE NCC is the legal entity that provides
secretariat services to the RIPE community.
We welcome your participation in RIPE's Policy Development Process and
input on the current proposal.
Kind regards,
Leo Vegoda, for the Address Policy WG co-chairs
On Wed, 20 Dec 2023 at 03:07, Kessler, Emmanuel
<Emmanuel.Kessler(a)europol.europa.eu> wrote:
>
> 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
>
>
>
>
>
>
>
>
>
>
>
> -----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
>
> --
>
> 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
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Tore Anderson
Hi again Jan,
On 09/01/24 13:38, Jan Ingvoldstad wrote:
>
> 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.
Whose interpretation? According to the EU Commission: «Personal data is
any information that relates to an identified or identifiable living
individual. Different pieces of information, which collected together
can lead to the identification of a particular person, also constitute
personal data.»
https://commission.europa.eu/law/law-topic/data-protection/reform/what-pers…
«Farmer Fred» – the name of an individual – clearly falls within this
definition. So does his e-mail address and telephone number. Publishing
this information requires a lawful basis, e.g., consent. If consent was
refused, it is not permissible to publish. This is presumably the reason
why the RIPE NCC states the following in the 2023-04 Impact Analysis:
«Inserting any personal data in the RIPE Database must be in compliance
with the RIPE Database Terms and Conditions, even when it relates to the
contact details of the member’s own contact person(s). In particular,
before anyone updates the RIPE Database with personal data, they must
obtain the contact person’s informed and expressed consent and ensure
this data is kept accurate and up-to-date.»
https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis
> 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.
Indeed, and it is our opinion that this solution is already available
today, as the RIPE NCC has confirmed that according to their current
policy interpretation and procedures, not publishing Farmer Fred's PII
in the RIPE DB is compliant with today's policy. This will continue to
be the case after 2023-04 is implemented, so no change there.
> 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?
LIRs' contact information is definitively out of scope of 2023-04.
2023-04 only concerns itself with *assignments* (made by LIRs to End
Users), not *allocations* (made by the RIPE NCC to LIRs).
(That said, LIRs' contact information is also subject to the RIPE
Database Terms and Conditions.)
> 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 <mailto:tore%2Bripe-example@fud.no>.
The policy is technology agnostic in this respect. An automatic e-mail
forwarding scheme such as the one you describe is one example of a
policy- (and presumably GDPR-) compliant way to do it, but that's not
the only possible option. The LIR could instead opt for operating a
human-staffed help desk that receives and forwards messages to End Users
as appropriate.
> 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.
I think that because the WG discussion has almost exclusively revolved
around this alleged changing of policy requirements to publish End User
contact information (which may or may not be PII), it is easy to lose
track of what this proposal is *actually* all about. We are talking
about two different things:
1) The actual intention behind the proposal: Making it possible to
aggregate multiple IPv4 End User assignments that have consistent
contact information and purpose into a single database object. This is
not possible today, and that is what we want to make that possible, in
the same way it is already possible in IPv6.
2) The *alleged* change to what kind of End User contact information is
required to be published in the RIPE database. We have never had any
intention of changing this in any way, and the Impact Analysis and other
statements from the RIPE NCC confirm that the proposal does not change
it either.
In short: 1) is an intentional and desired change from today, while 2)
is *not* a change from today – intentionally so.
So maybe we could discuss 1) instead of 2) going forward? :-)
> 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.
As noted in 2) above, the proposal in its current form does not cause
any «removal» of any End User contact information publishing requirement
compared to current policy. It merely upholds the status quo, which has
been confirmed by the RIPE NCC on multiple occasions. However, if you
are dismissing the RIPE NCC's clarifications on this subject in the
Impact Analysis and elsewhere as not factual, then there is not much
more to discuss and we would simply have to agree to disagree.
> 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.
Any effort to «clearing up the PII mess» has always been outside the
scope of this proposal. This proposal is simply not about PII or contact
information. That could be a subject for another policy proposal, of
course, but one thing at a time.
Tore & Jeroen
11 months, 2 weeks
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 8:57 AM Sebastian Graf <ripe-lists(a)sebastian-graf.at>
wrote:
> Dear Jan!
>
Dear Sebastian, thanks for chiming in!
>
> 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?
>
https://www.ripe.net/participate/policies/proposals/2023-04
6.2 Network Infrastructure and End User Networks
…
"When an End User has a network using public address space this must be
registered separately with the contact details of the End User. Where the
End User is an individual rather than an organisation, the contact
information of the service provider may be substituted for the End Users."
The removal of this text has seen many strange arguments, such as GDPR
(which is already covered by the text being removed).
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".
As I understand it, the RIPE NCC's interpretation, and the one that Tore
leans on, is that the text does not mean that organisation End User contact
details must be published, even though they are not individual users.
The argument therefore appears to be that the text "When an End User has a
network using public address space this must be registered separately with
the contact details of the End User." should be read as "" in the current
policy document, and that changing "When an End User has a network using
public address space this must be registered separately with the contact
details of the End User." to "" changes nothing in the policy.
My stance is that this changes the policy, but that it changes the policy
to be in line with current practice.
(As a side note, 10-15 years ago, my employer received quite a lot of flak
for NOT publishing contact details for every single customer that had the
use of single, dedicated IP addresses, as part of web hosting or colocation
services, with rerference to this very policy. How times change.)
--
Jan
11 months, 2 weeks