Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by denis walker
Colleagues
Here we go again. Let me start by saying that the emphasis and
phrasing of both this email that I am replying to and the impact
analysis seem to have been carefully chosen to show this proposal in a
good way. What I mean by this will become apparent as you read on.
Just to be clear, I object to this proposal. The discussion at RIPE 87
on the need for assignments in the RIPE Database and what contacts
they should contain was very inconclusive. What it did show was that
no one really understands what contacts are needed and what the
current policy required contacts actually mean. Until we have a clear
picture of what this data means and what different stakeholder groups
require, we should not be considering changes on this scale. The RIPE
NCC's impact analysis also completely ignored the impact of this
proposal on the registry system.
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.
Let's look at the RIPE NCC's impact analysis (IA). The IA seems to
focus mostly on the impact this proposal has on the RIPE NCC and its
operations. I accept that the PDP (ripe-781) does suggest most of the
IA will be about the impact on the NCC. But it does also mention the "
registry and addressing systems".
In Section A of the IA it says:
"Acceptance of this proposal will not change the fact that the RIPE
NCC cannot enforce which contact details members add to their IPv4 PA
assignments in the RIPE Database; this will remain their decision."
This is too vague. It is true that it is the LIRs decision if they add
contact A or contact B. However, the current policy says, as we all
know now, an assignment MUST include the contact details of the End
User. The RIPE NCC can and should enforce this policy requirement. The
type of contact should be enforced, but not the specific contact.
Section B of the IA has the title "Impact of Policy on Registry and
Addressing System". The IA only refers to the impact on the addressing
system. It says nothing about the impact on the registry. The registry
has two parts. There is the internal, private registry. This is where
the RIPE NCC stores things like contact details for the NCC to contact
their members, the LIRs. This proposal probably doesn't have any
impact on this part of the registry. The IA should still say that. The
other part is the public registry, the RIPE Database. This proposal
potentially has a huge impact on the public registry, but nothing has
been said about this in the IA. So this raises a question about the
PDP policy itself. Should the RIPE NCC focus ONLY on the impact the
proposal has on the RIPE NCC or should it discuss wider implications
for the Internet and other stakeholders?
In the legal impact (Section D) it says:
"the RIPE NCC would like to note that it is solely the responsibility
of the member to choose which contact details to insert in the INETNUM
object".
This has the same vagueness as the comment in Section A. It then
confuses the issue by talking about personal data. As I pointed out in
my first attempt at a privacy policy last year, 'contact data NOT
EQUAL personal data'. In 99% of INETNUM objects the End User contact
details can be included without making any reference to personal data.
The IA even refers to "contact person". As I pointed out last year,
all contacts should be roles and not people. We are still locked into
the mindset of referring to people.
>
> 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?
'Convenience' is not the best parameter for determining internet
policy. The idea of aligning IPv4 and IPv6 registrations is becoming
an obsession. We should talk about aligning the two registration
systems 'where appropriate'. Also as I said early on in this
discussion, where two systems are mis-aligned, there are two ways to
bring them into alignment. We can make IPv6 registrations work the
same way as IPv4, with suitable technical 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».
Fundamentally changing registration policy requirements "in order to
bring the wording in line with that of the IPv6 policy" is absolutely
the wrong reason to make such a change.
>
> 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.
I answered ref [1] here:
https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/01…
ref [2] (the IA) makes no comment regarding the impact on the registry
and I answered ref [3] here:
https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013…
"we defer to the RIPE NCC’s judgement on this point". Policy is made
by the community. If the RIPE NCC's interpretation of a policy point
is not correct then the community can require that the RIPE NCC
re-evaluates their interpretation.
> 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.
There is a lot in this paragraph. The practice of documenting End User
contact details in the optional "descr:" attributes is already
widespread. That is likely because so many LIRs do understand the
current policy. They have delegated the contact details in the
mandatory attributes. But they realize the policy requires End User
contact details so they add those details in other attributes. Given
that you have put so much emphasis on the 'manual effort required to
create assignment objects in the RIPE Database' I am sure so many LIRs
have not entered this optional detail without good reason.
"we would have expected the community to take action to correct this
situation". The fact that 'the community' did not even realise this
mis-interpretation of address policy by the RIPE NCC for so long,
perhaps says more about the community than the RIPE NCC. There is no
doubt that this is a policy violation. There are many other issues
with the way address policy has been interpreted in recent years that
I could talk about, but no one is interested. The reality is that much
of 'the community' does not pay much attention to the fine detail of
policy or the way it is interpreted.
> 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].
You are correct that the policy does not prohibit the delegation of
contact details. But the policy still clearly requires that End User
contact details MUST be included 'somewhere'. The two points are not
mutually exclusive. (Your ref to US criminal law is irrelevant.)
> 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).
Just as with the IA you have the 'person' mindset lock. Contacts
should be roles, not people. As suggested in the privacy discussion
last year, the roles can include optional person names if the people
so wish. We should all stop using the term 'contact person' and refer
to 'contact role'.
> 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.
You have been very selective here in your interpretation of the stated
goals of the registry system. Firstly it does not state that
'uniqueness' and 'troubleshooting' form an exclusive list of the
reasons for a public registry. Over the years the registry has evolved
to the needs of other stakeholder groups. But if you want to take this
wording literally it also says "The provision of a public registry
documenting address space allocations and assignments must exist." An
aggregation does not document assignments. It simply documents that a
block of address space has been used for assignments. It is not
documenting the actual assignments as required by these defined goals.
You cannot take one sentence literally and then be flexible in your
interpretation of the other sentence.
cheers
denis
>
>
> [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
1 year, 11 months
Re: [address-policy-wg] 2023-04 Who do I speak for?
by Mirjam Kuehne
Hi Denis,
Thank you for explaining how you see your role.
I would like to clarify a few things you mentioned in your mail. I hope
this will be useful especially for RIPE community members who might not
have the long history in the community that some of us have.
1. Regarding the role of the RIPE Community:
The fact that the RIPE community is not a legal entity and that it is
open to anyone who wants to participate, does not mean it is "undefined".
From the beginning, the RIPE community has agreed to document its
decisions and processes as RIPE documents that are publicly accessible.
In the RIPE Terms of Reference (ripe-001) [1] the mission and scope of
RIPE is defined. We have a clearly defined policy development process
and clearly defined governance processes that the community agrees to
follow.
Decisions are made by consensus and RIPE documents go through a defined
community review.
2. Regarding the relation between RIPE and the RIPE NCC:
The RIPE NCC clearly states its role as the secretariat of RIPE in its
mission, activity plan and budget. These are formal documents the RIPE
NCC members vote on.
Also, there is a long track record of the RIPE NCC following guidance
from the RIPE community.
3. Regarding the role of a chair:
It is the responsibility of a chair to listen and to guide discussions,
to summarise and to actively build consensus.
Those of us who serve in a special function or have a leadership role
are aware of the fact that people tend to see us as being in that role.
Therefore we need to take extra care if and when we decide to
participate in a discussion as an individual.
Kind regards,
Mirjam
(RIPE Chair)
[1] RIPE Terms of Reference
https://www.ripe.net/publications/docs/ripe-001
2 years, 1 month
Re: [address-policy-wg] 2023-04 (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Gert Doering
Hi,
On Tue, Nov 07, 2023 at 12:59:53PM +0100, denis walker wrote:
> I am both saddened and yet not surprised by this announcement to move
> this proposal to the review phase.
As per the PDP, the proposer decides whether to move onward after
discussion phase. If the proposer sees value in having a NCC impact
analysis, they might do so even if there was some opposition in
discussion phase - because it might bring clarity on the merits of
arguments either way.
> It doesn't seem to matter what
> anyone says, I suspect this proposal will be approved. You included a
> link to the Policy Development Process (ripe-781). Pity you have not
> followed it.
The text could be a bit more clear here, but
"If the suggested comments and changes are not so significant as
to require a new Discussion Phase, the proposer and WG chairs can
decide to move the proposal to the next phase (Review Phase) with
a new version of the proposal incorporating the necessary edits."
is what gives them the option to move forward - you didn't suggest
massive edits, but to kill the proposal, which is still open.
[..]
> In '2.2 Discussion Phase' it says:
>
> "If the proposer decides to take the proposal to the next phase, they
> need to produce a draft RIPE Document which should be published within
> four weeks after the end of the Discussion Phase, before the proposal
> can be moved to the Review Phase."
There is a draft document. It does not say "a new draft document" here.
(This text is relevant if there was no formal draft document at the
beginning of the Discussion phase, which can be done "to test the waters"
before writing up something)
> This has not been done.
It has.
> "The RIPE NCC will need to publish an impact analysis for the proposal
> 'before' it can be moved to the Review Phase."
>
> This has not been done.
The proposal is not in Review Phase *yet*, and Leo did not suggest
otherwise.
https://www.ripe.net/participate/policies/proposals/2023-04
does not say "in Review Phase".
So indeed, the IA has not been published, but since it's not stating
anywhere "in Review Phase", this is not a contradiction. IAs can take
time, so this is not an instant over-night thing in the best case, and
there is no urgency.
[..]
> This proposal cannot be moved to the review phase under the current
> circumstances, if we are actually following the PDP policy.
It can.
> Let me summarise my objections. The proposer claims this is an
> inconsequential change to address policy that does not permit anything
> to be done that cannot already be done. That has been proven to be a
> false claim. This is a major change to address policy that will
> undermine the whole concept of the public registry that we have
> understood for the last 30 years.
This, in particular, is *your* claim, which I'd like see either backed
or dismissed by the impact analysis - I see this as on way "proven".
So it's very useful to move forward to "Review Phase with a full IA".
> Regardless of the merits of such a
> major change, we cannot allow such a change based on a few "+1"
> comments from a handful of the small group of people who dominate and
> control all policy decisions in this region. AFAIK neither the
> proposer, nor the RIPE NCC, nor the proposal supporters have made any
> attempt to reach out to other stakeholder groups who use the RIPE
> Database to inform them of this discussion, advise them of the
> potential consequences and invite them to join this discussion.
This is not a requirement of the PDP. Proposals are announced to
the PDP-announce-Mailing list, and people interested in policy change
are expected to read this.
Gert Doering
-- NetMaster
--
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
2 years, 1 month
Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
by Tore Anderson
* Carlos Friaças via address-policy-wg:
> So in order to make it clear for the co-chairs, i do oppose this
> proposal, on the grounds that the quality of publicly available
> registration data is likely to decrease if this proposal is approved.
Hi Carlos,
This concern has been addressed at length in the previous phases of the
policy development process, so for the full answer we will refer you
back to those discussions. We will however summarise our position
briefly below:
We do not believe the registration data will degrade as a result of this
proposal. It does in no way encourage or compel LIRs to remove any End
User registration data currently found in the database, nor does it stop
them from adding more End User registration data in the future. In other
words, any LIR that today chooses to publish detailed information about
their individual End User assignments is free to continue to do so after
this proposal is implemented.
Furthermore, there is no reason to expect that the acceptance of this
proposal will entice LIRs to replace detailed individual assignments
with aggregated assignments en masse. This has not happened with IPv6,
where there are currently over twelve times as many ASSIGNED inet6num
objects as there are AGGREGATED-BY-LIR objects. Many of those are rife
with optional End User details shared voluntarily by the issuing LIRs.
We see no reason to believe that LIRs will use AGGREGATED-BY-LIR for
IPv4 inetnum objects in a materially different way.
Finally, we would like to point out that the proposal explicitly
restricts the scope of AGGREGATED-BY-LIR, by stating that «the purpose
and the contact details must be consistent throughout the whole
assignment». That means that the End User registration data that can be
aggregated must be redundant in the first place.
Best regards,
Jeroen & Tore
1 year, 8 months
Re: [address-policy-wg] 2023-04 Proposal Accepted (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Tore Anderson
Hi there,
* APEX NCC ORG
>
> Can you provide an example of using and registering an
> AGGREGATED-BY-LIR object for IPV4?
> Who is this for and when?
>
It has exactly the same use case as AGGREGATED-BY-LIR for IPv6. It is
primarily intended for LIRs which need to make a large number of
essentially identical assignments, which can then be aggregated into a
single database object rather than registering a bunch of redundant objects.
Here's an example, which represent 256 essential identical ASSIGNED PA
objects:
inetnum: 192.0.2.0 - 192.0.2.255
netname: CLOUDPROVIDER-CUSTOMER-VMS
descr: IP addresses dynamically assigned to virtual machines running in
CloudProvider's public cloud infrastructure # this is optional
assignment-size: 32 # this is optional
country: NO
admin-c: CLOUDPROVIDER-RIPE
tech-c: CLOUDPROVIDER-RIPE
status: AGGREGATED-BY-LIR
mnt-by: CLOUDPROVIDER-MNT
source: RIPE
> Is its use mandatory?
>
Not at all, feel free to ignore it and continue doing whatever you've
been doing so far.
> Initially, the assignment policy was discussed as an assignment for
> cloud providers.
> What should a provider do, for example, if it has a status ASSIGNED PA
> object (for example /20),
> splits it into /24 objects also like ASSIGNED PA with additional
> routes obj. for its end clients (without NAT / with NAT)?
>
I do not quite understand this use case. I believe it is not common to
split an ASSIGNED PA object into more specific ASSIGNED PA objects. To
be honest, I didn't even know that was possible. Anyway…
> Is it here an AGGREGATED-BY-LIR status objects? Or NOT?
>
…as I understand it, in your example, the 16 /24 ASSIGNED PA objects
have unique mnt-routes: values. If so, that means you cannot aggregate
the 16 /24s into a single AGGREGATED-BY-LIR object.
Tore
1 year, 7 months
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Tore Anderson
On Wed, 2023-11-29 at 12:28 +0100, Peter Hessler wrote:
> I mentioned this during the WG session but want to bring it up on the
> mailing list, what is the definition of assignment-size.
>
> In the IPv6 implementation of AGGREGATED-BY-LIR there is an
> assignment-size attribute, which is proposed to be optional for the IPv4
> version.
>
> From the inet6num documentation:
> "assignment-size:" - This specifies the common size of all
> individual assignments aggregated into one block with the status
> 'AGGREGATED-BY-LIR'. This attribute is required to be present if the
> inet6num object has this status. The individual assignments do not need
> to be represented in the RIPE Database. But one or more assignments may
> be included if the member wishes to specify them for any reason.
>
> While there is no definition of what "size" means, my understanding is
> that the technical implementation follows the implemention requirements
> of inet6num objects, which is the CIDR size.
>
> However, in IPv4 it is allowed to do CIDR _or_ an arbitrary range of
> addresses. So if one were to create this inetnum object:
>
> inetnum: 192.0.2.0 - 192.0.2.255
> netname: customers of example
> status: AGGREGATED-BY-LIR
> assignment-size: 32
> ...
>
> Here the assignment size is ambiguous. Is it 32 addresses aka a /27, or
> is it a /32 aka 1 address.
>
> I propose that we define this to be a CIDR assignment and they put in
> the number of bits of the netmask, so the above example would be
> assignment-size of /32.
Hi Peter,
Agreed 100%, that is the intuitive understanding, especially
considering that it is already in use like that for inet6num.
I propose that we simply ask the RIPE NCC (hello Angela!) to confirm
that their intended implementation of assignment-size for IPv4 inetnum
is a CIDR prefix length. If it is, and there are no opposing voices
against defining it in that way, I believe there should be no need to
do a v3 of the proposal just to state this explicitly.
(I also suggest that while the NCC is at it, they should document
assignment-size as being a CIDR prefix length for inet6num as well. As
you point the formal definition is not crystal clear there either,
which was a bit of a surprise to me, honestly. But all current inet6num
objects have an assignment-size within the range 31-128, so I guess
LIRs simply get it - unless the database software enforces it by
rejecting updates with values above 128.)
Tore
2 years
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by boggits
On Tue, 21 Nov 2023 at 10:14, Angela Dall'Ara <adallara(a)ripe.net> wrote:
>
> 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 IP
In general, i'm in favour of the proposal, however, it has raised several
questions that I think as a community need to address before we can decide
on the correct approach.
What is the purpose of the registrations on assignments in the RipeDB?
I always understood them as a way of recording who/what was using a piece
of address space so that you can contact the right organisation in the case
of an issue. In this case, there were explicit carve-outs for blocks of
dynamic address space so that the ISP could be contacted to determine who
was using that particular piece of address space at a single time.
Where address space was allocated on a more permanent basis the contact
details of the end site would be added so the organisation who was trying
to address the problem had a direct route to contact that end network. From
a technical point of view, it was useful as a reference to be able to work
out if several IP addresses in a subnet had been allocated to the same
customer or if there was a wider issue. This means that having the
assignment size fixed for each block and included in the RipeDB entry is
rather important.
Over time we have become more concerned about privacy, contact details
being shared, and the maintainability of the database. As such when IPv6
entries were added a specific additional label was created
AGGREGATED-BY-LIR that allowed an LIR to say this block of address space is
allocated to lots of individual organisations, with a boundary of /X please
contact us if you need the contact details for them. Part of the reason for
this was it gave the network operator to create long-lasting address
allocations that were non-dynamic (as opposed to being static) and force
them to register every single end user if they were going to try and be
efficient in their allocation of addresses.
For IPv6 I've not seen any issues raised about the creation of this class
of address (I did ask earlier but got zero feedback)
How does this Policy impact this use?
This policy appears to take the standard approach for IPv6 and apply it to
IPv4 (this is a good thing) it will reduce the number of individual entries
in the system (neutral) and hopefully increase the accuracy (a good thing)
but at the loss of explicitly including the contact details of the end user
site and replacing it with a contact for the LIR (neutral). The last step
appears to be the most controversial as it stops people from going directly
to the source as it were.
I think the operational impact here is a potential issue, some LIRs are
less than stellar in dealing with requests about things listed in the
RipeDB (mostly because of spam) so I can see the concern that some have
raised about not being able to get hold of people. However that's not a
Ripe issue explicitly but rather a function of the world of capitalism
(it's free to send an email, let's send lots of emails, we only need a few
people to respond to make money...)
If we want to fix this problem then maybe we need to add a new capability
onto the db that allows authenticated users to contact LIRs about their
address space (without using the published contact details) in a way that
would allow anti-abuse and LEAs to access the information they need, that
is very much not something that needs discussion in the WG because were
here to talk about address policy.
This policy is optional...
I think people have missed this, from my reading an LIR is not prevented
from continuing to put entries without marking them as aggregated so from
that point of view if you want to continue to include customer details (and
you have their consent) you can still do it.
So with all that said, I think I still support the policy with the caveat
about assignment size mentioned earlier
Thx
J
--
James Blessing
07989 039 476
1 year, 11 months
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Sebastian Graf
Dear Jan!
Thank you for your reply. But you have not answerred my question.
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?
Regards
On 1/12/24 09:21, Jan Ingvoldstad wrote:
>
> 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
>
1 year, 11 months
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Angela Dall'Ara
Dear Denis and colleagues,
I would like to provide some clarification about the scope of the Impact
Analysis provided by the RIPE NCC on policy proposals.
As per the RIPE Policy Development Process [1], the Impact Analysis is
limited to:
• The RIPE NCC's understanding of the proposed policy
• Impact on the registry and addressing systems (including Internet
resource consumption, aggregation and fragmentation)
• Impact on RIPE NCC operations/services/capacity
• Legal impact
All of the above is exclusively from the RIPE NCC's point of view, and
deliberate effort is taken to not include - and therefore not exclude -
any other point of view.
The discussion on the mailing list is open to all stakeholders to
describe the impact they foresee if a proposal is accepted.
I hope this helps.
Kind regards,
Angela Dall'Ara
Policy Officer
RIPE NCC
[1] https://www.ripe.net/publications/docs/ripe-781
On 14/12/2023 04:54, denis walker wrote:
> Colleagues
>
> Here we go again. Let me start by saying that the emphasis and
> phrasing of both this email that I am replying to and the impact
> analysis seem to have been carefully chosen to show this proposal in a
> good way. What I mean by this will become apparent as you read on.
>
> Just to be clear, I object to this proposal. The discussion at RIPE 87
> on the need for assignments in the RIPE Database and what contacts
> they should contain was very inconclusive. What it did show was that
> no one really understands what contacts are needed and what the
> current policy required contacts actually mean. Until we have a clear
> picture of what this data means and what different stakeholder groups
> require, we should not be considering changes on this scale. The RIPE
> NCC's impact analysis also completely ignored the impact of this
> proposal on the registry system.
>
> 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.
> Let's look at the RIPE NCC's impact analysis (IA). The IA seems to
> focus mostly on the impact this proposal has on the RIPE NCC and its
> operations. I accept that the PDP (ripe-781) does suggest most of the
> IA will be about the impact on the NCC. But it does also mention the "
> registry and addressing systems".
>
> In Section A of the IA it says:
> "Acceptance of this proposal will not change the fact that the RIPE
> NCC cannot enforce which contact details members add to their IPv4 PA
> assignments in the RIPE Database; this will remain their decision."
> This is too vague. It is true that it is the LIRs decision if they add
> contact A or contact B. However, the current policy says, as we all
> know now, an assignment MUST include the contact details of the End
> User. The RIPE NCC can and should enforce this policy requirement. The
> type of contact should be enforced, but not the specific contact.
>
> Section B of the IA has the title "Impact of Policy on Registry and
> Addressing System". The IA only refers to the impact on the addressing
> system. It says nothing about the impact on the registry. The registry
> has two parts. There is the internal, private registry. This is where
> the RIPE NCC stores things like contact details for the NCC to contact
> their members, the LIRs. This proposal probably doesn't have any
> impact on this part of the registry. The IA should still say that. The
> other part is the public registry, the RIPE Database. This proposal
> potentially has a huge impact on the public registry, but nothing has
> been said about this in the IA. So this raises a question about the
> PDP policy itself. Should the RIPE NCC focus ONLY on the impact the
> proposal has on the RIPE NCC or should it discuss wider implications
> for the Internet and other stakeholders?
>
> In the legal impact (Section D) it says:
> "the RIPE NCC would like to note that it is solely the responsibility
> of the member to choose which contact details to insert in the INETNUM
> object".
> This has the same vagueness as the comment in Section A. It then
> confuses the issue by talking about personal data. As I pointed out in
> my first attempt at a privacy policy last year, 'contact data NOT
> EQUAL personal data'. In 99% of INETNUM objects the End User contact
> details can be included without making any reference to personal data.
> The IA even refers to "contact person". As I pointed out last year,
> all contacts should be roles and not people. We are still locked into
> the mindset of referring to people.
>
>> 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?
> 'Convenience' is not the best parameter for determining internet
> policy. The idea of aligning IPv4 and IPv6 registrations is becoming
> an obsession. We should talk about aligning the two registration
> systems 'where appropriate'. Also as I said early on in this
> discussion, where two systems are mis-aligned, there are two ways to
> bring them into alignment. We can make IPv6 registrations work the
> same way as IPv4, with suitable technical 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».
> Fundamentally changing registration policy requirements "in order to
> bring the wording in line with that of the IPv6 policy" is absolutely
> the wrong reason to make such a change.
>
>> 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.
> I answered ref [1] here:
> https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/01…
> ref [2] (the IA) makes no comment regarding the impact on the registry
> and I answered ref [3] here:
> https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-November/013…
>
> "we defer to the RIPE NCC’s judgement on this point". Policy is made
> by the community. If the RIPE NCC's interpretation of a policy point
> is not correct then the community can require that the RIPE NCC
> re-evaluates their interpretation.
>
>> 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.
> There is a lot in this paragraph. The practice of documenting End User
> contact details in the optional "descr:" attributes is already
> widespread. That is likely because so many LIRs do understand the
> current policy. They have delegated the contact details in the
> mandatory attributes. But they realize the policy requires End User
> contact details so they add those details in other attributes. Given
> that you have put so much emphasis on the 'manual effort required to
> create assignment objects in the RIPE Database' I am sure so many LIRs
> have not entered this optional detail without good reason.
>
> "we would have expected the community to take action to correct this
> situation". The fact that 'the community' did not even realise this
> mis-interpretation of address policy by the RIPE NCC for so long,
> perhaps says more about the community than the RIPE NCC. There is no
> doubt that this is a policy violation. There are many other issues
> with the way address policy has been interpreted in recent years that
> I could talk about, but no one is interested. The reality is that much
> of 'the community' does not pay much attention to the fine detail of
> policy or the way it is interpreted.
>
>> 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].
> You are correct that the policy does not prohibit the delegation of
> contact details. But the policy still clearly requires that End User
> contact details MUST be included 'somewhere'. The two points are not
> mutually exclusive. (Your ref to US criminal law is irrelevant.)
>
>> 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).
> Just as with the IA you have the 'person' mindset lock. Contacts
> should be roles, not people. As suggested in the privacy discussion
> last year, the roles can include optional person names if the people
> so wish. We should all stop using the term 'contact person' and refer
> to 'contact role'.
>
>> 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.
> You have been very selective here in your interpretation of the stated
> goals of the registry system. Firstly it does not state that
> 'uniqueness' and 'troubleshooting' form an exclusive list of the
> reasons for a public registry. Over the years the registry has evolved
> to the needs of other stakeholder groups. But if you want to take this
> wording literally it also says "The provision of a public registry
> documenting address space allocations and assignments must exist." An
> aggregation does not document assignments. It simply documents that a
> block of address space has been used for assignments. It is not
> documenting the actual assignments as required by these defined goals.
> You cannot take one sentence literally and then be flexible in your
> interpretation of the other sentence.
>
> cheers
> denis
>
>>
>> [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
1 year, 11 months
Re: [address-policy-wg] 2023-04 (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by denis walker
Hi Leo
On Tue, 7 Nov 2023 at 22:04, Leo Vegoda <leo(a)vegoda.org> wrote:
>
> Dear Denis,
>
> Our processes don't move super fast. This is partly deliberate. We
> don't want to railroad the community. It is also practical. There are
> actions to be carried out between the end of one phase and the start
> of another.
>
> The proposers have taken account of the "significant comments or
> changes [...] suggested during the Discussion Phase." They have been
> preparing a draft RIPE Document with help from the RIPE NCC.
>
> The RIPE NCC has been developing an impact analysis. They
> understandably don't start that work until there's a decision on
> whether the proposal will move forward.
>
> All of these things take some time to accomplish. That is why there is
> a small gap between the formal end of the Discussion phase and the
> start of the Review phase.
>
The delays are understandable. Maybe that should be clearly reflected
in the PDP process.
> Your objections have not been ignored. We will schedule time in Rome
> to discuss the objections you have raised.
I look forward to that (remotely).
cheers
denis
>
> Kind regards,
>
> Leo Vegoda for the co-chairs
>
> On Tue, 7 Nov 2023 at 04:00, denis walker <ripedenis(a)gmail.com> wrote:
> >
> > Hi Leo, Colleagues
> >
> > I am both saddened and yet not surprised by this announcement to move
> > this proposal to the review phase. It doesn't seem to matter what
> > anyone says, I suspect this proposal will be approved. You included a
> > link to the Policy Development Process (ripe-781). Pity you have not
> > followed it. Now suggesting we follow a process, Jim Reid will argue I
> > am trying to turn RIPE into some "process heavy organisation". But the
> > PDP is a policy. So do we get to pick and choose which bits of which
> > policies we apply or ignore? If that is the case why not just dump all
> > policy and work to a general understanding. It might be more honest.
> >
> > Let's walk through the PDP as defined in ripe-781. Starting with '2.
> > The Process'.
> >
> > "These phases are detailed below with proposed timelines for the
> > various stages. These may differ for individual proposals, but the
> > actual timelines must be documented."
> >
> > In the opening email Angela stated that the four week Discussion Phase
> > will run until 3 October 2023.
> >
> > "At the end of each phase of the process, one of the chairs of the
> > relevant WG will summarise the state of discussion on the WG mailing
> > list."
> >
> > This has not been done.
> >
> > "In all phases of the RIPE PDP, suggestions for changes to the
> > proposal and objections regarding the proposal must be justified with
> > supporting arguments and then addressed adequately by the proposer or
> > by any supporter of the proposal."
> >
> > I have objected to this proposal on several grounds. I have justified
> > my objections with significant supporting arguments. A number of
> > people have supported the principle of my objections. Some people who
> > initially gave the proposal a "+1" response have since withdrawn that
> > support based on my objections. Neither the proposers, nor their
> > supporters (the +1 brigade), have addressed my objections. Even worse
> > than that, the proposers still deny that this proposal changes
> > anything substantially with regard to address policy. They still claim
> > it does not allow anything to be done that cannot already be done. I
> > have adequately shown this argument to be false. Neither the proposers
> > nor their supporters have even acknowledged this fact. A number of
> > people have agreed that such a fundamental change to address policy
> > should not be introduced as a (hidden) side effect of another,
> > apparently inconsequential, change. If such a change is to be
> > introduced, which may or may not have merits of its own, it should be
> > openly discussed as a separate topic. Given that these objections are
> > highly significant, and that they have been completely ignored by the
> > proposers and supporters and not "addressed adequately", the chairs of
> > the AP-WG cannot declare an initial consensus and move this proposal
> > to the review phase.
> >
> > In '2.2 Discussion Phase' it says:
> >
> > "If the proposer decides to take the proposal to the next phase, they
> > need to produce a draft RIPE Document which should be published within
> > four weeks after the end of the Discussion Phase, before the proposal
> > can be moved to the Review Phase."
> >
> > This has not been done.
> >
> > "The RIPE NCC will need to publish an impact analysis for the proposal
> > 'before' it can be moved to the Review Phase."
> >
> > This has not been done.
> >
> > I am raising these issues today as it is the last day of the
> > discussion phase according to the diagram in Appendix A of ripe-781.
> > Even though the diagram does not agree with the text in ripe-781. I
> > have allowed the 5 weeks after the discussion phase shown in the
> > diagram, rather than the 4 weeks stated in the text.
> >
> > This proposal cannot be moved to the review phase under the current
> > circumstances, if we are actually following the PDP policy.
> >
> > Let me summarise my objections. The proposer claims this is an
> > inconsequential change to address policy that does not permit anything
> > to be done that cannot already be done. That has been proven to be a
> > false claim. This is a major change to address policy that will
> > undermine the whole concept of the public registry that we have
> > understood for the last 30 years. Regardless of the merits of such a
> > major change, we cannot allow such a change based on a few "+1"
> > comments from a handful of the small group of people who dominate and
> > control all policy decisions in this region. AFAIK neither the
> > proposer, nor the RIPE NCC, nor the proposal supporters have made any
> > attempt to reach out to other stakeholder groups who use the RIPE
> > Database to inform them of this discussion, advise them of the
> > potential consequences and invite them to join this discussion.
> > Stakeholder groups like LEAs, government regulators, private
> > investigators, abuse management organisations, security community,
> > researchers, and others (who the Database Task Force never
> > identified).
> >
> > cheers
> > denis
> >
> > On Fri, 27 Oct 2023 at 03:51, Leo Vegoda <leo(a)vegoda.org> wrote:
> > >
> > > Dear WG,
> > >
> > > The Discussion Phase of policy proposal 2023-04 "Add AGGREGATED-BY-LIR
> > > status for IPv4 PA assignments" has now ended. Many thanks to all for
> > > your comments.
> > >
> > > The proposal will now move forward to the Review Phase.
> > >
> > > The RIPE NCC will prepare an impact analysis and a draft RIPE Document.
> > >
> > > More details about the phases of the Policy Development Process are
> > > published here: https://www.ripe.net/publications/docs/ripe-781
> > >
> > > You'll also see an announcement from the RIPE NCC soon.
> > >
> > > Kind regards,
> > >
> > > Leo Vegoda for the co-chairs
> > >
> > > --
> > >
> > > 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
2 years, 1 month