Re: [address-policy-wg] 2023-04 Are anonymised assignment objects valid?
by Sander Steffann
Hi,
> I think I mostly agree with Nick here and I feel like Tore is a bit
> dismissive of the concerns raised by denis.
>
> I don't really feel that strongly about this policy proposal in itself
> but I do now see that it is a significantly larger change than Tore
> suggests that it is.
> I wouldn't be surprised if more people who have said "+1" to this
> proposal did so without realizing that it's not such a minor change.
+1 to that! Guilty person right here :)
> As such, I really think that there needs to be more discussion about
> this in the context of changing a meaningful part of the policy.
I totally agree. This is a change that we have to take consciously, not as a side-effect of a different idea.
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 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)
- realise that the current internet is not the internet that this DB was designed for
- align IPv4 and IPv6 requirements/standards where possible
So:
- the ALLOCATION objects will always have validated information enforced by the RIPE NCC
- objects below that are for delegating responsibility and contact points
- if an LIR wants to keep/assume responsibility, very few additional DB objects are needed
I realise there are quite a few potentially controversial statements here, please use this as a thought provoking discussion point ;)
Cheers!
Sander
1 year, 2 months
Re: [address-policy-wg] 2023-04 Who do I speak for?
by Peter Hessler
Denis,
Yes, you are correct that that signing your emails saying you are
co-chair of DB tells the reader that you are speaking on behalf of the
working group. That may or may not be your intention, but that is how
people are reading it. No longer signing your emails "co-chair" would
be a dramatic improvement, for sure. You could also sign them as "not
speaking as co-chair" to be explicit.
A lot of the critisim against you has been based on the understanding
that you are acting as a dictator and pushing your agenda. You might
not agree, but that is how I view your behaviour as co-chair.
-peter
On 2023 Oct 16 (Mon) at 21:09:47 +0200 (+0200), denis walker wrote:
:Hi Mirjam
:
:Thanks for the clarifications. On points 1 and 2 I bow to your better
:judgements.
:
:For point 3 I see your view. But I think I get singled out for unfair
:criticism here. During my reappointment as co-chair of the DB-WG some
:people heavily criticised me for taking part in discussions on mailing
:lists whilst being a co-chair. I believe that was personal and not
:objective criticism. It was suggested that 'I' am doing something no
:other chair has ever done and it is wrong. They have short memories.
:The previous chairs to the current set for the DB-WG were often
:heavily involved in discussion on the database and other mailing
:lists. The chairs before them (including the original chair) were also
:often involved in discussions on multiple lists. So I haven't started
:a new trend. The (co) chairs of the DB-WG (and perhaps other WGs) have
:been involved in discussions on various mailing lists since the lists
:started in 1992.
:
: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.
:
:cheers
:denis
:
:On Mon, 16 Oct 2023 at 16:44, Mirjam Kuehne <mir(a)zu-hause.nl> wrote:
:>
:> 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
1 year, 2 months
Re: [address-policy-wg] 2023-04 (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by denis walker
Hi Gert
Thanks for your comments. But I think you have missed a couple of
important points.
It says in the PDP:
"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."
Let me edit that down a bit:
In all phases of the RIPE PDP...objections...addressed adequately...
So in the discussion phase my objections must be addressed adequately.
The proposers have not even acknowledged my objections and still
maintain the false view that this proposal is inconsequential.
Also you said I haven't suggested any significant change to the
proposal. My objections could be addressed by not removing the line:
"When an End User has a network using public address space this must
be registered separately with the contact details of the End User."
That would be a significant change.
cheers
denis
On Tue, 7 Nov 2023 at 13:13, Gert Doering <gert(a)space.net> wrote:
>
> 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
1 year, 1 month
Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by denis walker
Colleagues
I am so disappointed by this second version of the proposal and the
impact analysis.
Let's start with the changes to the proposal. The addition of
'Arguments opposing the proposal'. This is completely false and
misleading information. This summary of the arguments during the
discussion phase is just unbelievably wrong. No one even made the
argument that you cannot currently create an object with the mandatory
contacts delegated to another party. In regard to these mandatory
contacts I proved that the admin-c must be a contact from the End
User's enterprise. This is based on the definition of admin-c and the
clearly expressed, current version of the address policy. In
particular that well quoted line "When an End User has a network using
public address space this must be registered separately with the
contact details of the End User." Very clear, not subject to
interpretation and non negotiable under the current policy and all
versions of the policy going back over the last 20 years.
In the PDP policy it says "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 still has not been done.
Then we have this crazy 'counter argument'. Let's break it down.
"It is already possible to create such assignments under the current
address policy."
No one has disputed that.
"The RIPE NCC confirmed that they consider these assignments to be
policy compliant and do not require them to be modified during
audits."
During my detailed arguments I proved that this interpretation by the
RIPE NCC of the current IPv4 address policy, and all the versions over
the last 20 years, is incorrect. According to the now famous line
"When an End User has a network using public address space this must
be registered separately with the contact details of the End User."
and the historic, but still valid, definition of the admin-c, it is
clear that the admin-c must be someone from the End User enterprise.
Therefore delegating this to another party is a violation of the
policy. Many LIRs who create assignment objects in the RIPE Database
have understood the current and previous address policy. Even though
they sometimes delegate the admin-c they compensate by adding the name
and address of the End User in the optional descr attributes. This is
not strictly compliant but does adhere to the principle of the policy.
This proposal drops this principle.
Despite the RIPE Chairs and RIPE NCC CEO's recent policy about RIPE
NCC staff being more involved in RIPE community affairs, no one from
the RIPE NCC has joined this discussion to explain the NCC's
interpretation of the current and previous address policy.
"Therefore, the proposed policy change simply leaves the status quo unchanged."
This is straight out of the Donald Trump fake news instruction manual.
When you say something that is not true, keep repeating it, over and
over and over again. Never acknowledge anyone who questions it, never
discuss any arguments raised against it, just keep repeating it. Over
time some people will start to believe it.
I have argued in GREAT detail exactly what this proposal does. By
dropping that famous line "When an End User has a network using public
address space this must be registered separately with the contact
details of the End User." the proposers fundamentally change address
policy and the nature of the public registry. I have presented 'walls
of text' to explain this, which most people probably have not read.
This change allows ALL End Users to be totally anonymised. Even those
who technically manage their own network and handle their own abuse
complaints, they can still be anonymised and have public contact
details available. For LIRs who do not want to put any details of
their customers into the public registry, this change allows for this
complete anonymity. And there are many LIRs who already follow this
philosophy, despite current policy. This change will reduce the RIPE
Database public number registry to the same useless level as a domain
name registry. ALL details of End Users can be hidden behind a court
order firewall.
Following the Trump instruction manual, the proposers still refuse to
acknowledge that this proposal changes anything. They still refuse to
engage with the community in a real discussion on this point. They
still keep repeating the fake news.
It also says in the PDP policy "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." The proposers will not even acknowledge my objections, will
not discuss them and therefore have not adequately addressed them.
Then we move on to the impact analysis (IA). This reads as an 'Impact
on the RIPE NCC Analysis'. There is no mention at all of the impact on
stakeholders who use the data contained within the RIPE Database. In
the PDP policy it does say the IA will contain 'Impact on the
registry'. This is interpretable. I would suggest this covers the
public registry as well as the RIPE NCC's internal registry databases.
But this IA does not even mention the fundamental change to address
policy and the potential consequences to the data contained within the
public registry or the impact that may have on various stakeholder
groups using the RIPE Database. It follows the same line as the
proposers by failing to even acknowledge the severity of the change
this proposal has on the public registry.
>From the Legal Impact section, "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." Also from the 'RIPE NCC's
Understanding' 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 also not true. The policy is very
clear. "When an End User has a network using public address space this
must be registered separately with the contact details of the End
User." So the current policy dictates to the LIR the type of the
contact details they must enter. Even though the individual contact
within that type is their choice.
So with the arguments from the discussion phase having not been
summarised and the objections not having even been acknowledged by the
proposers, and certainly not addressed by them, I still don't see how
this proposal can move to the review phase.
cheers
denis
On Tue, 21 Nov 2023 at 11:13, 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 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
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 2:11 PM Tore Anderson <tore(a)fud.no> wrote:
> Hi Jan,
>
>
Hi Tore,
> On 11/01/24 13:27, Jan Ingvoldstad wrote:
> > On Thu, Jan 11, 2024 at 1:11 PM Tore Anderson <tore(a)fud.no> wrote:
> >
> > 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.
>
> Not at all. Any working group member who is of the opinion that the RIPE
> NCC is interpreting a RIPE Community policy incorrectly, is free to at
> any point submit a policy proposal that clarifies the allegedly
> misinterpreted policy text with the aim to make the RIPE NCC change its
> procedures accordingly.
>
> The RIPE NCC's Impact Analysis will then reveal whether or not the
> proposed new policy text does attain its goal and that the RIPE NCC will
> change its procedures as desired, should the proposal pass.
>
> Finally, the proposal will need to reach (rough) consensus in order to
> confirm that the RIPE Community does indeed concur with the proposer's
> opinion that the old policy was interpreted incorrectly, and that the
> RIPE NCC's procedures ought to change.
>
> Absent this, the RIPE NCC's operationalisation of the policy will stay
> as-is.
>
>
This would make sense if the argument was not so circular.
I also do not understand what makes it so hard to say that: "Yes, the
current policy does state something else than NCC's interpretation of it
does, and therefore current practice contradicts (or appears to contradict)
policy. However, we, the proposers, believe that the current practice makes
for the best policy, and therefore propose amending the policy to reflect
practice."
--
Jan
11 months, 2 weeks
Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
by Rodolfo García Peñas (kix)
Hi,
In my opinion, if we are having this discussion for so long, perhaps it is because the original objective of the proposal, which is "Add AGGREGATED-BY-LIR status for IPv4 PA assignments", is being overstepped.
Constructively, I think that adding the AGGREGATED-BY-LIR option for IPv4 PA assignments is a good idea and should be confined to Section 7.0 (Types of Address Space), as is the case with the other types. Section 6.2 does not currently refer to any type.
In my opinion, it is compatible to include the new type AGGREGATED-BY-LIR while keeping the information in the current section 6.2 to facilitate consensus.
It may be important to analyze situations of non-recording of information in the database, anonymization of information, etc., but this is not related to the proposal to include the new type and should be analyzed separately.
Best Regards,
kix
--
Rodolfo García (kix)
http://www.kix.es/
"I asked him once how to change the key bindings and Dave said 'You use the Change Configuration command. On Unix it is abbreviated as cc.' Dave Conroy and Lawrence Stewart.
Disclaimer: This email expresses my personal views only and does not necessarily reflect the views or policies of any company, organization or institution.
On Tuesday, April 9th, 2024 at 16:50, Gert Doering <gert(a)space.net> wrote:
> Hi,
>
> On Tue, Apr 09, 2024 at 04:31:06AM +0200, denis walker wrote:
>
> > Tore you are absolutely right, the cat is out of the bag...but which
> > cat? You seem fine about how the RIPE NCC has been mis-interpreting
> > policy for 10 years and how they have no power to enforce it other
> > than the nuclear option, which we all know they will not use. The
> > revelations from this discussion have completely changed the landscape
> > for RIPE policy. It has been totally undermined.
>
>
> There is no "change of landscape" or "undermining of policy" here - to
> anyone following address policy it was always clear that there is
> some leeway in registering end user assignments (INFRA-AW), and that
> the NCC cannot enforce correctness of all data.
>
> They can and do audits, and back when there was still new space to
> be had, such an audit could have very unpleasant consequences - namely,
> reducing the AW to 0, and refusing allocation of new blocks, until
> documentation was fixed. Since there is no more v4 space at the NCC,
> all these levers are gone (through no fault of policy or the NCC).
>
>
> Also it was discussed a number of times here on the list and in the
> meetings what LIRs should put into the admin-c: and tech-c:, given that
> natural persons being involved might not agree to be listed in a public
> database with their personal information. So "register the NOC here",
> and for single user end customers "register the LIR contacts" has been
> established practice for a long time.
>
>
> So while I totally agree that we all (as "the LIRs in the RIPE region")
> might not have been following policy to the letter, overall most of us
> followed it to the spirit - "put someone in there that will take
> responsibility and can take action if needed" (which the letter "put
> someone in who is on-site" will not achieve).
>
> Should we work on improving the documents? By all means, yes.
>
>
> Has this anything to do with 2023-04, or the last call for it? Hardly.
>
> Gert Doering
> -- speaking as LIR contact, and with some policy experience
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG Vorstand: Sebastian v. Bomhard,
> Ingo Lalla, Karin Schuler
> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
> --
>
> 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
8 months, 2 weeks
Re: [address-policy-wg] 2023-04 Who do I speak for?
by denis walker
Hi Randy
Right on queue with another typical comment.
On Tue, 17 Oct 2023 at 01:08, Randy Bush <randy(a)psg.com> wrote:
>
> > We simply cannot get many people to talk about many of the RIPE
> > Database issues.
>
> perhaps wg members are deterred by the walls of text with strong
> directives and opinions from a dominating co-chair (who lost the
> election but somehow is still here)?
It took walls of text to make people realise that an apparent simple
policy proposal to do nothing but introduce a new status value,
actually ripped the heart out of address policy and fundamentally
changed it. Whether that is a good or bad idea is not the point. If
that is what you want to do then be open about it and discuss it,
don't hide it. Which makes me wonder about some of those who just said
+1.
At least I have opinions and as Gert said the last time we discussed
this, you are all free to disagree with me and put forward your own
ideas.
>
> nothing the db wg does is worth the effort and pain, so we just go
> have coffee and get back to work.
You would prefer the DB-WG does nothing? Look back through the archive
since the last RIPE Meeting. There has only been one significant
discussion and that was actually about routing policy rather than the
database. I have deliberately said very little in this period. So if
you take out comments from chairs and announcements from the NCC not a
lot happened. None of the open issues have gone anywhere.
Let's have a serious reality check here. It is not ME who has an
agenda or dominates internet policy. It is a small group of the same,
very vocal people who dominate all policy discussion. As it says in
the RIPE NCC survey report:
[Despite high satisfaction with the mailing lists, there are some who
say they are “super old-fashioned and confusing” and have the “same
people commenting all the time”.]
It is the agenda of these 'same people' that dominates internet
policy. These recurring attacks on my style and detailed analysis are
a good diversion tactic to stop people listening to my messages and
thinking about the issues I raise. Classic smoke screen approach. Do
you actually have an opinion Randy on the 25 year old design of the
RIPE Database built around a 25-30 year old data model that is
becoming increasingly difficult to change and needed a 1 day course to
teach people the basics of using it? Or what about the many commercial
investors across this region who received IPv4 allocations from the
RIPE NCC and bought some on the open market, not having a clue about
internet operations, but know how to make a profit? Or the commercial
RIRs sitting below the RIPE NCC who manage all this commercial address
space using a distribution structure that simply cannot be represented
in the current database data model? Or the hundreds of /29 IPv6 blocks
held by these investors that were pretty much unused last time I
checked? These are all issues I have mentioned this year but no one
will talk about any of them. All you want to talk about is the length
of my emails and my style of writing. That gets you out of discussing
the slightly more serious issues in my emails.
I sometimes wonder why I bother. (There, I have given you the one
sentence you can latch on to, comment on sarcastically and ignore the
above paragraph.)
cheers
denis
(btw don't anyone ask me to name any of these investors or commercial
RIRs or mention the address blocks. That is not my job. Do your own
analysis.)
>
> randy
1 year, 2 months
Re: [address-policy-wg] 2023-04 (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by denis walker
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
1 year, 1 month
Re: [address-policy-wg] 2023-04 Who do I speak for?
by denis walker
Hi Mirjam
Thanks for the clarifications. On points 1 and 2 I bow to your better
judgements.
For point 3 I see your view. But I think I get singled out for unfair
criticism here. During my reappointment as co-chair of the DB-WG some
people heavily criticised me for taking part in discussions on mailing
lists whilst being a co-chair. I believe that was personal and not
objective criticism. It was suggested that 'I' am doing something no
other chair has ever done and it is wrong. They have short memories.
The previous chairs to the current set for the DB-WG were often
heavily involved in discussion on the database and other mailing
lists. The chairs before them (including the original chair) were also
often involved in discussions on multiple lists. So I haven't started
a new trend. The (co) chairs of the DB-WG (and perhaps other WGs) have
been involved in discussions on various mailing lists since the lists
started in 1992.
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.
cheers
denis
On Mon, 16 Oct 2023 at 16:44, Mirjam Kuehne <mir(a)zu-hause.nl> wrote:
>
> 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
>
>
>
1 year, 2 months
Re: [address-policy-wg] 2023-04 (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Leo Vegoda
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.
Your objections have not been ignored. We will schedule time in Rome
to discuss the objections you have raised.
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
1 year, 1 month