Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

[Peter Hessler]

I still support the proposal as-is.  The proposed change does not
weaken any data that is in the database, and in fact may allow it to be
more obvious that these address ranges are used by end users rather than
be unclear what their status is.

Furthermore, I will state that Denis' objections are not relevant to the
proposal.  The proposers, various people on the lists (including myself),
and the RIPE NCC themselves all state the opposite of what Denis is
saying.  In addition the proposers have, in my opinion, addressed the
concerns stated.

-peter


On 2023 Nov 21 (Tue) at 11:13:57 +0100 (+0100), Angela Dall'Ara 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@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

Re: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04

[Peter Hessler]

On 2023 Dec 15 (Fri) at 14:28:13 +0100 (+0100), Tore Anderson wrote:
:To that end, you might want to submit a policy proposal that would
:clarify for the RIPE NCC what the correct implementation should be, so
:that their procedures are brought in line with your expectations. If
:you do that, we can put 2023-04 on hold pending the outcome of your
:proposal.
:

Please don't do that.  Denis wishing to change policy should not block
this proposal.

Additionally, I believe that Denis' proposal on this topic is unlikely to
reach concensous, as you can guess from reading the acrimonious
discussion across several lists.


:Best regards,
:Tore and Jeroen

-peter

-- 

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

Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

[Peter Hessler]

On 2023 Nov 29 (Wed) at 16:41:14 +0100 (+0100), Gert Doering wrote:
:Hi,
:
:On Wed, Nov 29, 2023 at 12:28:04PM +0100, Peter Hessler wrote:
:> 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.
:
:Seconded.  Well spotted.
:
:Maybe even make the syntax require the "/", at all times, so it's visually
:clear right away.  "This is a /32, not a 32 which might be either"
:
:gert

I don't mind requiring a "/", but I very much want it to stay in sync
with the IPv6 syntax.  If we add this to the IPv4 implementation for
parity, we shouldn't change it to take it out of parity.  :)

-peter


-- 
Overdrawn?  But I still have checks left!

-- 

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

Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

[Peter Hessler]

Hi everyone,

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.

-peter

-- 

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

Re: [address-policy-wg] 2023-04 Who do I speak for?

[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  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

-- 

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

Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

[Peter Hessler]

On 2023 Sep 11 (Mon) at 19:14:05 +0200 (+0200), denis walker wrote:
:On Mon, 11 Sept 2023 at 18:33, Peter Hessler  wrote:
:>
:> On 2023 Sep 11 (Mon) at 16:09:58 + (+), Brian Storey wrote:
:> :Does this not contradict other purposes / objectives of the registry, 
including the principles of registering public networks or am I missing 
something?
:> :
:>
:> This behaves the same as the IPv6 version, which has not had this
:> problem yet.
:
:Maybe because IPv4 is still dominant for networks...
:

That should not be a blocker for this policy.  And if a solution is
needed/found, then it should be in a different policy that fixes it for
both. 



-- 
Just remember: when you go to court, you are trusting your fate to
twelve people that weren't smart enough to get out of jury duty!

-- 

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

Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

[Peter Hessler]

On 2023 Sep 11 (Mon) at 16:09:58 + (+), Brian Storey wrote:
:Does this not contradict other purposes / objectives of the registry, 
including the principles of registering public networks or am I missing 
something?
:

This behaves the same as the IPv6 version, which has not had this
problem yet.



-- 
MESSAGE ACKNOWLEDGED -- The Pershing II missiles have been launched.

-- 

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

[address-policy-wg] 2023-02 Minimum Size for IPv4 Temporary Assignments

[Peter Hessler]

I support this proposal.

I initially was confused on the second clause of the new text for section
3.3, but it became clear when I read the entire context within the new
proposal.

-peter

-- 
Weinberg's First Law:
Progress is made on alternate Fridays.

-- 

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

Re: [address-policy-wg] 2019-02 Review Phase (IPv4 Waiting List Implementation)

[Peter Hessler]

On 2019 May 12 (Sun) at 11:56:02 +0200 (+0200), Hansen, Christoffer wrote:
:
:On 07/05/2019 12:57, Randy Bush wrote:
:> On 06/05/2019 13:10, Marco Schmidt wrote:
:>> Policy proposal 2019-02, "IPv4 Waiting List Implementation"
:>> is now in the Review Phase.
:>
:> we are here to do what we can to make the internet work. this
:> helps by making connectivity as available as possible given
:> the circumstances.
:
:Agrees with Randys comment.
:
:+1 from here.
:
:   -Christoffer
:

I also agree with the policy proposal.


-- 
Of course there's no reason for it, it's just our policy.

Re: [address-policy-wg] Clarification of policy requirements for contact information

[Peter Hessler]

On 2019 Apr 09 (Tue) at 11:28:19 +0200 (+0200), Jan Ingvoldstad wrote:
:On Tue, Apr 9, 2019 at 11:16 AM Peter Hessler  wrote:
:
:>
:> Concrete suggestion:
:> I think that person objects should have the address and phone attributes
:> be changed from mandatory to optional.
:>
:
:And that means optional as in opt-in, not opt-out.
:

Correct.


:> It may also be worthwhile for there to be a *private* way to register
:> addresses with RIPE NCC so they can use it for verification without
:> violating the privacy of natural persons.
:>
:
:Yup.
:
:Additionally, in the cases where all contact objects are personal with
:contact information hidden, there needs to be an abuse object that can be
:used. The quality of actually usable abuse contact information is
:regrettably low across RIR databases, contact information quality is not a
:RIPE specific problem.
:

I strongly disagree, but that is another topic.

-- 
Bennett's Laws of Horticulture:
(1) Houses are for people to live in.
(2) Gardens are for plants to live in.
(3) There is no such thing as a houseplant.

Re: [address-policy-wg] Clarification of policy requirements for contact information

[Peter Hessler]

At my current job we have a single Org object and a shared mntner object,
and each employee within the network group has their own person and
mntner objects to avoid sharing passwords and for auditability.  As is
obvious, this can grow quite quickly even for a small LIR.  LIR person
accounts all use the same HQ address and phone information.

I am *also* an end-user, as I have a few PI allocations issued to my
natural person and not to my employer.  So I have a separate person and
mntner objects for that.

I am generally comfortable with the groups I have a contract with
having my home address and my home phone number.  (to spell it out, my
Sponsoring-LIR, and RIPE NCC).  I am *not* happy for that data to be
published widely on the internet, so I have censored them on purpose
(with a reference that the sponsoring-lir has my actual contact details).
The email address does get delivered to me.

(as a side note: I would like to join RIPE as a LIR, but are not willing
to have my home address publicized so I have not done so.)


Concrete suggestion:
I think that person objects should have the address and phone attributes
be changed from mandatory to optional.

It may also be worthwhile for there to be a *private* way to register
addresses with RIPE NCC so they can use it for verification without
violating the privacy of natural persons.

-peter


On 2019 Apr 09 (Tue) at 08:46:55 + (+), Kennedy, James via 
address-policy-wg wrote:
:Hi everyone,
:For those not already aware of recent discussions on the topic, there is an 
ever increasing need primarily for network operators and others running the 
internet, but also CSIRTs, certain governmental bodies, LEAs and more to have 
contact details for IP networks correct at all times in the RIPE database.
:
:This is actually required by RIPE policy and is one of the database’s 
fundamental missions but as flagged during the RIPE77 meeting, on the RIPE 
mailing lists and felt daily by those managing IP networks it is clear that 
improvements are very much needed to help contact registration accuracy and 
ease of maintenance.
:•   Community members have questioned the reliability of the RIPE database 
today – Whois has been described as “broken”, “a horrible mess”, even “should 
be gotten rid of”
:•   +2M PERSON objects were found in the database though the number of 
LIRs is less than 22K
:•   The increasing amount of contact data has become more difficult for 
operators to manage, which also puts IP number resources at risk of hijacks and 
even deregistration
:•   The RIPE NCC is challenged with contacting and validating IP network 
holders, with additional pressure stemming from the growing monetary value of 
IP resources
:
:It is our responsibility as the RIPE community to build and implement 
improvements as and when needed. To echo Hans Petter’s comment during the RIPE 
NCC Services WG at RIPE77 – we made the mess, we must clean it up!
:
:Rather than just mandating the RIPE NCC to perform validation exercises on 2M 
PERSON objects, we would like to start by re-evaluating exactly what contact 
info the community actually wants in the database and then consider if the 
current RIPE policies sufficiently reflects this. Please see Denis’ mail below 
for contact detail references in current policies.
:
:So we ask the community – please can you please tell us what contact info do 
you want to see in the RIPE database? Do it differ per type of IP network user 
– LIRs and PA/PI End Users, orgs and individuals (sole trader or residential), 
3rd parties managing IP resources on behalf of an LIR/org/individual, etc.?
:
:Regards,
:James
:
:
:From: address-policy-wg [mailto:address-policy-wg-boun...@ripe.net] On Behalf 
Of ripedenis--- via address-policy-wg
:Sent: 22 March 2019 11:00
:To: address-policy-wg@ripe.net
:Subject: [address-policy-wg] Clarification of policy requirements for contact 
information
:
:Colleagues,
:
:Elvis, James and myself have started talking about personal data in the RIPE 
Database. I said we would bring sub issues to the community when we need 
direction or clarification. We looked at three policy documents maintained by 
AP-WG and have a few questions.
:
:Before we look at WHERE and HOW the data is stored, we would like to get 
community feedback on exactly WHAT contact details should be published as per 
current policies?
:
:Below are the quotes and links to the 3 policy documents we looked at.
:
:cheers
:denis
:co-chair DB-WG
:
:
:In the "IPv4 Address Allocation and Assignment Policies for the RIPE NCC 
Service Region" (ripe-708) [1] first mention about contact data is 4.0:
:
:"4.0 Registration Requirements
:
:All assignments and allocations must be registered in the RIPE Database. This 
is necessary to ensure uniqueness and to support network operations.
:
:Only allocations and assignments registered in the RIPE Database are 
considered valid. Registration of objects in the database is the final step in 
making an 

Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)

[Peter Hessler]

I support this proposal.

1) the intent of the last /8 policy is for new participants to go from 0
to not-0 IPv4 addresses.  While not-0 IPv4 addresses may not be enough
for a limited number of business cases, it *is* enough to bootstrap a
company (e.g. website, dns, email, nat64, etc).

2) When RIPE NCC is unable to allocate a contiguous /22, we are scraping
the bottom of the barrel.  A single /24 allocation helps the not-0
participants.

3) A /24 is the smallest allocation that is actually usable on the
internet.

4) While there is a belief The Internet(tm) should just up and migrate
to IPv6, that is unrealistic.  E.g. Twitter, Amazon, Reddit, Github, and
*many* home/business ISPs around the world do not even IPv6.  Whinging
about it in policy groups doesn't change that *fact*.

Yes, I prefer that people use IPv6.  But reality says IPv4 is still
important for new participants.



On 2019 Feb 04 (Mon) at 13:04:26 +0100 (+0100), Marco Schmidt wrote:
:Dear colleagues,
:
:A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24"
:is now available for discussion.
:
:This proposal aims to reduce the IPv4 allocation size to a /24 once the
:RIPE NCC is unable to allocate contiguous /22 ranges.
:
:You can find the full proposal at:
:https://www.ripe.net/participate/policies/proposals/2019-02
:
:As per the RIPE Policy Development Process (PDP), the purpose of this
:four week Discussion Phase is to discuss the proposal and provide
:feedback to the proposer.
:
:At the end of the Discussion Phase, the proposer, with the agreement of
:the WG Chairs, will decide how to proceed with the proposal.
:
:We encourage you to review this proposal and send your comments to
: before 5 March 2019.
:
:Regards,
:
:Marco Schmidt
:Policy Officer
:
:

-- 
Bacchus, n.:
A convenient deity invented by the ancients as an excuse for
getting drunk.
-- Ambrose Bierce, "The Devil's Dictionary"

Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)

[Peter Hessler]

On 2019 Feb 05 (Tue) at 08:53:21 +0100 (+0100), ga...@nethinks.com wrote:
:That is an option. But in order to not punish late entries to the
:market, it should also include a fixed timeframe when EVERYBODY has to
:stop using v4 (at least on the public Internet) ... I don't see any
:technical reason why providers all over the world still aren't able (or
:willing) to do v6 ... of course I know you can't force customers to
:provide services on v6 (or even to use v6 - I believe of our customers,
:maybe 1% actively use v6, and another few percent use it unknowingly :) ).
:From our point of view, we could drop external v4 pretty quickly if it
:weren't required to reach (or be reached) by v4-only users/services ...

Then come back when you have a solution to force GitHub, Twitter,
Amazon, and a lot more, to launch an IPv6 version of their website.


-- 
Command, n.:
Statement presented by a human and accepted by a computer in
such a manner as to make the human feel as if he is in control.

Re: [address-policy-wg] proposal to remove IPv6 PI

[Peter Hessler]

On 2018 May 19 (Sat) at 18:11:39 +0200 (+0200), Kai 'wusel' Siering wrote:
:Am 19.05.2018 um 12:07 schrieb JORDI PALET MARTINEZ via address-policy-wg:
:> My proposal is NOT to stop IPv6 PI,
:
:Alternative facts? The title says "to remove IPv6 PI".
:
:> As I explained already, the intent is not to increase the end-user fees so 
they pay the same as an LIR, but to have some "proportionality" and to pay for 
the "real" NCC cost (which maybe still 50 euros, or maybe not, I don't know 
that, it is something that the NCC should calculate).
:
:I've read multiple times that costs are out of scope for the APWG. So without 
a change towards a per resource fee structure – which is out of scope here –, 
the proposed change forces PIv6 holders to either become a LIR at 1400,-- 
EUR/year or abandon their assignment.
:
:Regards,
:-kai
:
:

If my choices are to pay 28x my current fee or abandon using IPv6, I
will abandon using IPv6.  Quite simply, I can't afford it and **it isn't
worth it**.

Since I would like to use IPv6, I am very strongly against this proposal.


-- 
Law of the Perversity of Nature:
You cannot successfully determine beforehand which side of the
bread to butter.

Re: [address-policy-wg] inputs on possible policy proposal for IPv6

[Peter Hessler]

On 2018 May 02 (Wed) at 07:25:12 -0500 (-0500), JORDI PALET MARTINEZ via 
address-policy-wg wrote:
:Hi all,
:
:As you probably know, ARIN amended some time ago their IPv6 policy proposal 
in order to make sure that the allocations to LIRs are aligned to the nibble 
boundary.
:
:In the context of another discussion in AfriNIC, Owen DeLong, suggested that 
we could do something similar.
:
:I'm considering submitting a policy proposal in each RIR (RIPE, AfriNIC, 
LACNIC, APNIC), for that, but I will like to get some inputs before, and 
"sense" the feeling about that of the participants.
:
:Note that in the case of RIPE, we have a big difference with the other RIRs, 
because all them start with /32, while we updated our policy several years ago 
(because 6rd deployment), to allocated /29. This means that if we go for this 
policy, it will be justified to "upgrade" all the /29 allocations to a /28.
:

Using this justification, would that also grow all IPv6 PI /48s to a /44,
or only those that are not already at a nibble boundary?


:This is the example that Owen sent to the AfriNIC list:
:
:1. Figure out the number of end sites you expect to serve in your largest 
aggregation point
:   in 3-5 years.
:2. Round that to a nibble boundary (with a 25% minimum free space) (1-12 
end sites = 4 bits,
:   13-192 end sites = 8 bits. 193-3,072 end sites = 12 bits, 3,073-49,152 
end sites = 16 bits,
:   49,153-786,432 = 20 bits, etc.)… Call this E.
:3. Figure out the number of aggregation points you expect to have in 3-5 
years. Round that up
:   to a nibble boundary with a 25% minimum free space (same as in step 2). 
Call this A.
:4. 48-(A+E) = prefix size.
:
:   Example: An ISP has 42,000 customers in it’s largest end site. It has 
128 end sites.
:   E = 16, A = 8, 48-(16+8) = 48-(24) = 24, this ISP should get a 
/24.
:
:So, would you agree in doing something on this line?
:
:Thanks in advance for any inputs!
:
:Regards,
:Jordi
: 
: 
:
:
:
:**
:IPv4 is over
:Are you ready for the new Internet ?
:http://www.consulintel.es
:The IPv6 Company


-- 
Broad-mindedness, n.:
The result of flattening high-mindedness out.

Re: [address-policy-wg] 2016-04 Review Phase *extended* (IPv6 Sub-assignment Clarification)

[Peter Hessler]

On 2017 Nov 25 (Sat) at 20:00:51 +0100 (+0100), Gert Doering wrote:
:Dear AP WG,
:
:On Thu, Oct 19, 2017 at 03:08:07PM +0200, Marco Schmidt wrote:
:> Policy proposal 2016-04, "IPv6 Sub-assignment Clarification" is now in the 
Review Phase.
:[..]
:> We encourage you to read the proposal, impact analysis and draft document 
and send any comments to  before 17 November 2017.
:
:The chairs have convened, and come to the conclusion that we do not
:have had enough input yet.
:
:We've heard a few voices on the list that state "this proposal is good, 
:go forward with it".  We've heard a few voices at the RIPE meeting that 
:wanted "something else" - of those, only Jordi has made it to the list,
:and the resonance to his alternative was not met with unanimous support
:either (Elvis wants it, Nick opposes it, no other clear statements on
:that aspects).
:
:Max has brought up the topic at DENOG9 last week, to elicit more people into
:adding input into this discussion - which would be helpful in evaluating
:(rough) consensus.
:
:Thus, we've decided that we will extent the review period by four weeks.
:
:Marco will send the formal announcement early next week.
:
:Gert Doering
:-- APWG chair

I support this proposal.


-- 
Cynic, n.:
One who looks through rose-colored glasses with a jaundiced eye.

Re: [address-policy-wg] clarification on RIPE Resource Transfer Policies (ripe-682) Section 2.0

[Peter Hessler]

On 2017 May 23 (Tue) at 14:35:01 +0200 (+0200), Gert Doering wrote:
:Hi,
:
:On Tue, May 23, 2017 at 02:10:06PM +0200, Peter Hessler wrote:
:> 
https://www.ripe.net/publications/docs/ripe-682#2-0-transfers-within-the-ripe-ncc-service-region
:> 
:> I saw this restriction:
:> 
:> """
:> Allocated resources may only be transferred to another RIPE NCC member.
:> Provider Independent resources may be transferred to:
:> 
:> * A RIPE NCC member; or
:> * An entity that has a contractual relationship with a RIPE NCC member
:>   in accordance with the RIPE Policy,
:> """
:> 
:> Note the difference between Allocated (PA) and Provider Independent (PI).
:> 
:> Is this split intentional?  Would a proposal to unify both under the
:> existing PI rules be welcome?
:
:This split is intentional - a PA holder can only be a LIR, while a PI
:can be held by a LIR or by a non-LIR end user, provided they have a
:contractual relationship with a LIR.
:
:So unless we change the whole model of "who can hold which address space"
:(and abandon the PA/PI distinction while at it) the transfer policy 
:document just reflects what address policy always required for the
:initial holder of a given "bag of numbers".
:
:Gert Doering
:-- NetMaster
:-- 
:have you enabled IPv6 on something today...?
:
:SpaceNet AGVorstand: Sebastian v. Bomhard
:Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
:D-80807 Muenchen   HRB: 136055 (AG Muenchen)
:Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279

Right now I don't feel like trying to change the whole model, so the
policy makes sense as it is.

Thanks!


-- 
A day for firm decisions!  Or is it?

[address-policy-wg] seperate subject, because people can't follow directions

[Peter Hessler]

On 2016 Oct 20 (Thu) at 12:38:55 +0200 (+0200), Netskin NOC wrote:
:On 20.10.2016 12:30, Gert Doering wrote:
:>This is a separate discussion, and should not be done under the Subject:
:>of 2016-03.
:>
:>Folks, I understand that e-mail is hard.  But give it a try.
:
:I know and thus didn't start a discussion about the topic, I just suggested
:it...probably by reviving the old thread I mentioned.
:

THEN CHANGE THE SUBJECT!  This isn't rocket science, or even science at
all.

-- 
When Marriage is Outlawed,
Only Outlaws will have Inlaws.

Re: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy)

[Peter Hessler]

Ciprian

You have invoked Nazis and Hitler in two different emails to this list.

This is incredibly offensive, for so many reasons.

You need to calm down, and think very serious thoughts about your
behaviour on this list.  Nobody, and certainly NOT Gert or anyone else
on a mailing list deserves to be treated that way.

-peter

Re: [address-policy-wg] Idea for aggregating IP addresses

[Peter Hessler]

Hi

Clarification question.

Are you requesting that non-continuous IPv4 blocks be exchanged for the
equivalent size in a single continuous IPv4 block that does not match the
previously issued IPv4 addresses, or do you want to take continuous IPv4
blocks and combine them?


On 2016 Sep 22 (Thu) at 14:37:25 +0200 (+0200), Ping IP wrote:
:Hello,
:
:One of the goals of RIPE is to aggregate IP addresses. I'd like to suggest
:the ability for a LIR and End User to exchange number of blocks of IP
:ranges for a greater block.
:
:For example:
:LIR/End User has 4 different /22 subnets and LIR/End User can exchange
:these subnets for 1 x /20 subnet.
:
:This gives a LIR or End User the possibility to announce larger IP subnets
:to the Internet. Helping the goal of aggregating the IP addresses on the
:Internet.
:
:According one of the RIPE trainer, this is currently not possible according
:the RIPE policy. Because there's no policy to give a LIR/End User this
:ability.
:
:I'm curious to what you think of this idea.
:
:Best regards,
:
:Abdelouahed
:Ping IP network

-- 
People will accept your ideas much more readily if you tell them that
Benjamin Franklin said it first.

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

[Peter Hessler]

On 2016 Jun 20 (Mon) at 10:04:33 +0200 (+0200), Gert Doering wrote:
:But I'm close to giving up on this and calling a ban on further changes
:to the IPv4 policy

+1


-- 
The human race is a race of cowards; and I am not only marching in that
procession but carrying a banner.
-- Mark Twain

Re: [address-policy-wg] IPv4 reserved space

[Peter Hessler]

Implementation detail: many operating systems hard-code that range as
invalid network space.  The effort to make it available would be _less_
than getting everyone else in the world upgraded to IPv6.



On 2016 Jun 11 (Sat) at 21:45:03 +0300 (+0300), NTX NOC wrote:
:Dear all,
:
:As we see ISPs and community would like to have more IPv4 space in use.
:
:I would like to ask a question what do people think about other side of
:IPv4 numeration space. Because we have in IPv4 a lot of addresses not in
:use at all but that space could be easy used.
:
:240.0.0.0/4Reserved (former Class E network)   RFC 1700
:
:it's 16 */8 networks. More then 256 Millions of routable and never used
:IPv4. 185/8 network has about 6.4M free and total RIPE has about 15M
:free IPv4 and we all say 185/8  will be enough for 2-3 years and rest -
:for some more time. But 256 M Ipv4 space could be enough for years!
:
:Space reserved for future Use. But will the future come to us or not?
:
:https://en.wikipedia.org/wiki/IPv4
:https://tools.ietf.org/html/rfc1700
:
:Is far as I see routers could easy start to use that IP space. People
:spend a lot of time and money to get some IPs but not to ask IANA to
:allow use this space. Technically it's very easy to start use IPs from
:such ranges.
:
:What does community thinks about it?
:
:Yuri
:

-- 
Isn't it interesting that the same people who laugh at science fiction
listen to weather forecasts and economists?
-- Kelvin Throop III

Re: [address-policy-wg] agreement

[Peter Hessler]

On 2016 May 11 (Wed) at 14:42:02 +0200 (+0200), Radu-Adrian FEURDEAN wrote:
:On Wed, May 11, 2016, at 08:53, Gert Doering wrote:
:
:> Would you have preferred the ARIN way?  "Oops, we have reached
:> exhaustion, nothing left, good buy to new entrants"?
:
:My understanding is that ARIN is not yet "dry". There still is some
:space available within 23.128.0.0/10 under NRPM 4.10 (which is supposed
:to be pretty restrictive, but I saw networks that prove me otherwise).
:And they still allow "further allocations" from that block (provided the
:"restrictive" conditions are met for all blocks). And it's evey 6 months
:not every 18 months.
:
:So it seems that issuing IPv4 space is still possible even after you cry
:out loud everywhere that you have none left. Don't tell me we (small
:LIRs) have to do the same with only a /22 in stock :)
:
:--
:Radu-Adrian FEURDEAN
:fr.ccs
:

The 23.128/10 block is ONLY for /24-/28 allocations.  These are not
intended as general purpose IP blocks, and are ONLY allowed to be used
for the IPv6 trasition (DNS servers, NAT64 gateways, etc).  People
violating the ARIN rules shouldn't be used as an excuse for us to change
the rules in RIPE.

https://www.arin.net/announcements/2014/20140130.html

ARIN does not count them as part of the available ranges for
allocation, so we should not assume they are part of the normal pool.


-- 
If you're going to do something tonight that you'll be sorry for
tomorrow morning, sleep late.
-- Henny Youngman

Re: [address-policy-wg] Comment on IPv4 depletion rate for proposal 2015-05

[Peter Hessler]

This was called "Provider Independent" and for IPv4, it was killed off
some years ago.

You can still get PI IPv6 space, however.


On 2016 May 10 (Tue) at 13:12:58 +0100 (+0100), Aled Morris wrote:
:I am troubled by the new members joining RIPE purely to obtain IPv4 address
:space.
:
:Perhaps (shields up!) RIPE could simply offer /22 for purchase at the same
:price as membership (???3,400 i.e. joining fee + 1 year subs) to anyone who
:wants one since they can get one anyway by joining.
:
:It would save the admin overheads and would identify members as those
:actually committed to performing as LIRs.
:
:I can't imagine this will be a popular suggestion, I'm just putting it out
:there.
:
:Aled

-- 
WARNING TO ALL PERSONNEL:

Firings will continue until morale improves.

Re: [address-policy-wg] agreement

[Peter Hessler]

On 2016 May 09 (Mon) at 14:19:43 +0200 (+0200), Riccardo Gori wrote:
:Hi Sander,
:
:Il 09/05/2016 10:42, Sander Steffann ha scritto:
:>Hello Ehsan,
:>
:>>we are agree about the Last /8 Allocation Criteria Revision proposal .
:>>https://www.ripe.net/participate/policies/proposals/2015-05
:>thank you for expressing your support. However, at this point in the 
discussion we have seen enough support but not enough work solving the 
objections that have een raised. That is what is needed currently to work 
towards consensus. Without addressing those objections this policy proposal 
gets stuck.
:Can you please summarize us the main objections about this 2015-05 policy so
:that people can try to address a solution to those?

My main objection to this proposal is simple:  It depletes the available
pool for _new_ participants faster.  I strongly believe any new actor
should be able to go from zero to non-zero with the addresses available
from RIPE.  For an actor with non-zero addresses to get more addresses,
there is a secondary market.

Since that is the base of my objection, I do not see any way that a
middle ground can be met.  Based on my understanding of the other
objections, I believe this is held by at least a few others from the
objection side.

I appreciate the effort put into this proposal, but I do not think any
solution can be proposed.

(note: my stance is based on forming a LIR simply to get any amount of
announcable addresses.)

-- 
Quick!!  Act as if nothing has happened!

Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)

[Peter Hessler]

On 2016 Apr 15 (Fri) at 10:41:56 +0200 (+0200), Gert Doering wrote:
:Hi,
:
:On Thu, Apr 14, 2016 at 05:23:11PM +0100, Aled Morris wrote:
:> The other objection (Jim) seems to be "we should be all-out promoting IPv6"
:> which I think is a laudable goal but unfortunately when used against
:> proposals like this one means that more recent LIRs are disadvantaged
:> against established companies with large pools of IPv4 to fall back on.  It
:> simply isn't possible, today, to build an ISP on an IPv6-only proposition.
:
:Please do not forget the fact that small LIRs are not *disadvantaged*
:by this policy, but actually *advantaged*.
:
:If we didn't have this policy, but just ran out like ARIN did, small 
:startup LIRs today would not be able to get *anything*.  Now they can 
:get a /22.  Is that enough?  No.  Can we fix it, without taking away
:space that *other* small LIRs might want to have, in a few years time?
:
:Gert Doering
:-- APWG chair


This was exactly what happened to me at a previous job, and I am very
happy that we were able to receive even a small-ish allocation of IPs.


-- 
Hanson's Treatment of Time:
There are never enough hours in a day, but always too many days
before Saturday.

Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)

[Peter Hessler]

If you need/want more IPv4 addresses, the marketplace is available.
RIPE should not give more addresses to people that already have some.

Growth into a market that should be killed, should not be encouraged by
RIPE.



On 2016 Apr 14 (Thu) at 15:51:56 +0100 (+0100), r...@scholarwebservices.com 
wrote:
: 
:
:Hello, 
:
:I am in favour of the proposal. Similar to Aled's comments below, we are
:a small entity that is restricted to growth with a single /22. I believe
:the 185/8 should be restricted to new entrants but allowing
:recycled/returned address space (outside of the 185/8) to be allocated,
:providing the LIR has less than a /20 in total. 
:
:Kind regards, 
:
:Gavin 
:
:On 2016-04-14 15:34, Aled Morris wrote: 
:
:> Peter, 
:> 
:> I agree with the proposal because it makes it possible for recent entrants 
into the market to grow. Speaking on behalf of such an entity, it's difficult 
to grow when you're limited to your one /22 in today's market. We (as an 
industry) are not there with IPv6 for this to be the only option. 
:> 
:> Ring-fencing 185/8 for new LIRs is sensible, this policy is really about 
recycling returned addresses and solves a real problem for a lot of recent new 
entrants. 
:> 
:> Of course we are all working on introducing IPv6 but I think we need this 
policy as it complements the allocation from 185/8 for new LIRs with a fair 
mechanism for nurturing LIRs who have filled their initial allocation. 
:> 
:> Aled 
:> 
:> On 14 April 2016 at 13:51, Peter Hessler <phess...@theapt.org> wrote:
:> 
:>> While I appreciate that there are more restricions on who is eligable to
:>> receive new allocations, I am still opposed to this proposal for the
:>> simple reason of "it depletes the IPv4 pool faster, and causes problems
:>> for new entrants".
:>> 
:>> --
:>> Anybody can win, unless there happens to be a second entry.
: 

-- 
The only way to get rid of a temptation is to yield to it.
-- Oscar Wilde

Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)

[Peter Hessler]

While I appreciate that there are more restricions on who is eligable to
receive new allocations, I am still opposed to this proposal for the
simple reason of "it depletes the IPv4 pool faster, and causes problems
for new entrants".


-- 
Anybody can win, unless there happens to be a second entry.

Re: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments)

[Peter Hessler]

On 2015 Nov 12 (Thu) at 18:13:56 +0200 (+0200), Saku Ytti wrote:
:On 12 November 2015 at 09:53, Gert Doering  wrote:
:> Just to play the devil's advocate, who is to evaluate and understand these
:> "cannot be satisfied" reasons?  RIPE IPRAs are typically not BGP experts.
:>
:> Not saying that this is not a good starting point, but we always need to
:> keep in mind that there are good people at the NCC who need to evaluate
:> these requests, and they might not all have the in-depth understanding
:> of technology...
:
:You should be saying this. This is what we got from RIPE NCC trying to
:pull it off. And I agree with them. If hostmasters need to decide, we
:need to tell them what are the rules. i.e. w need to iterate
:acceptable uses, which I don't want. I don't expect to know all use
:cases.
:
:I say this, clearly arrogantly, I think correct approach is:
:
:a) 32b ASN, question asked in form, but not evaluated (just to educate
:ourselves, why do people think they need ASNs) large limit per
:organisation, like 1000 ASN per organisation (LIR fees are low enough
:to justify buying another LIR if you need more ASN).
:b) 16b ASN, must not be stub network, must transit someone (if we can
:verify multihoming today, we can verify transiting tomorrow)
:

Thinking out loud: We could also apply the "last /8 policy" to this.
After it goes into effect, each LIR can request one and only one 16b ASN.
32b ASNs are allocated as normal (with the question asked, but not
evalutated).

-- 
Maintainer's Motto:
If we can't fix it, it ain't broke.

Re: [address-policy-wg] 2014-03 Policy Proposal Withdrawn (Remove Multihoming Requirement for AS Number Assignments)

[Peter Hessler]

On 2015 Nov 10 (Tue) at 04:30:22 + (+), Aftab Siddiqui wrote:
:Just for my understanding, is there any demand for 16b ASN from the
:community?

There is a technical case when attempting to use communities in the
: format.  There is not yet a 32:32b community available,
even in extended communities.  16b:32b and 32b:16b do exist, so I'm not
sure how critical that is.

-- 
The bigger the theory the better.

Re: [address-policy-wg] 2015-05 New Policy Proposal (Revision of Last /8 Allocation Criteria)

[Peter Hessler]

As I said during the WG at RIPE70, I fully support the existing /8
policy because we *were* a late entrant to this Internet game[1], and it
allowed a previous employer of mine to actually get _any_ announcable
IPv4 space.

While I feel sympathy for a business that has issues with not enough
space, I have more sympathy for a business that has zero IP space and
needs one.

I am against this proposal.


[1] Technically, the company had existed for a while with someone else's
IP space, but for practical reasons, the company needed to have an
allocation that belonged to it.


On 2015 Oct 20 (Tue) at 16:27:21 +0200 (+0200), Remco van Mook wrote:
:
:Hi all,
:
:(no hats)
:
:I think this is a very bad idea*. The whole reason the final /8 policy looks 
the way it does (and is as far as I can see working *exactly* as intended) is 
so late entrants to this Internet game have a fair chance of establishing 
themselves without having to resort to commercial alternatives for IPv4 address 
space.
:
:For established LIRs, adding a trickle of additional address space probably 
won???t make a jot of a difference for their business and is likely not going 
to optimise the utilisation of those final scraps. The final /22 is *intended* 
to be used as a migration tool to IPv6, and is a crucial tool at that. I 
consider it a Very Good Thing Indeed that this region had the foresight that 
IPv6 won???t happen overnight once IPv4 runs out** and as long as we???re still 
talking about IPv6 adoption and not IPv4 deprecation, that tool should be 
available for as many organisations as possible.
:
:Finally, introducing this kind of change in policy at this point in time could 
well be argued as being anti-competitive and would end us up in a legal mess.
:
:Remco
:
:* So yes, dear chairs, please consider this e-mail to be against this proposal.
:**Technically we have already run out a number of times, depending on your 
definition. None of those events has been earth-shaking, or induced major 
migrations to IPv6.

Re: [address-policy-wg] 2015-05 New Policy Proposal (Revision of Last /8 Allocation Criteria)

[Peter Hessler]

On 2015 Oct 20 (Tue) at 14:46:54 +0200 (+0200), Marco Schmidt wrote:
:https://www.ripe.net/participate/policies/proposals/2015-05

>From the proposed text:
  5.1.3.2. There is enough space in the free pool to perform the allocation

Is there a definition of "enough space in the free pool"?  Is it a
single /22?

Re: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP

[Peter Hessler]

On 2015 Sep 14 (Mon) at 10:41:44 +0200 (+0200), Radu-Adrian FEURDEAN wrote:
:On Mon, Sep 14, 2015, at 10:03, Tore Anderson wrote:
:> > 3. Further allocation(s) (after the first /22)
:> None of the above. My preference is to maintain the status quo - no
:> additional allocations. I do not quite see why we should change the
:> ??last /8?? policy which in my view has been quite successful (except for
:> the abuse that 2015-01 hopefully helps shut down).
:> 
:> If it ain't broke, don't fix it?
:> 
:> Unless we interpret ??broke?? to mean ??exhausted??. If so, c'est la vie.
:
:I take "broken" as "painful and far enough from exhaustion", so in need
:of a fix.
:Reminder, we are 3 years (precisely) into the "last /8 IPocalypse", and
:RIPE still has more than 0.98 of a /8 available (more likely 0.99).
:

At my previous company, we joined RIPE as a LIR specifically because
there was no other way to get our own IPv4 address space.  As a smaller
orginazation, we NEEDED to get our own IPv4 space to be multi-homed _and_
to provide serivces to our users.

I support the existing policy, and are very concerned with any proposal
that would encourage faster exhaustion of the IPv4 space.

I respectfully disagree with the assertion that the existing last /8
policy is painful for everyone.e