Re: [address-policy-wg] RIPE Code of Conduct and discussion on this list

[Jan Ingvoldstad]

Dear Working Group,

It is with a heavy heart that I now unsubscribe from this working group.

The discussion climate combined with double standards from the WG co-chairs
regarding the Code of Conduct means that spending effort here leaves a bad
taste in my mouth.

I wish you the best of luck in trying to resolve matters to the best of the
Internet community.
-- 
Jan
-- 

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)

[Jan Ingvoldstad]

On Fri, Jan 12, 2024 at 9:28 AM Sebastian Graf 
wrote:

> Dear Jan!
>

Dear Sebastian,

> Thank you for your reply. But you have not answerred my question.
>
I answered your question, but I did not understand that you intended your
ancillary comment as an additional question. Sorry about that.


> We are all clear/well aware on the fact that the policy states
> (paraphrasing here: resources need to be registered and the registions need
> to have contact information).
>
> We are looking for the DEFINITION of "contact details of the End User.".
> This is not directly defined (as far as i can tell) and is therefore open
> for interpretation.
>
> Unless i missed something?
>
>
> As I understand it, this comes from how contact objects are defined in the
database, and this is what RIPE-804 references.

Denis has provided more detailed context.

RIPE-705 sets specific requirements regarding abuse contact details.

-- 
Jan
-- 

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)

[Jan Ingvoldstad]

On Fri, Jan 12, 2024 at 8:57 AM Sebastian Graf 
wrote:

> Dear Jan!
>

Dear Sebastian, thanks for chiming in!


>
> As mentioned in my previous e-mail: Would you please post the section of
> the policy that you belive has the NCC's interpretation differ from the
> actual wording/language used?
>

https://www.ripe.net/participate/policies/proposals/2023-04

6.2 Network Infrastructure and End User Networks
…

"When an End User has a network using public address space this must be
registered separately with the contact details of the End User. Where the
End User is an individual rather than an organisation, the contact
information of the service provider may be substituted for the End Users."


The removal of this text has seen many strange arguments, such as GDPR
(which is already covered by the text being removed).


Because i have yet to find a section that states explicitly what is
> considered valid vs invalid contact information (other than being out of
> date or information that does not provide a contact to the user in a
> timely manner). Or a section that restricts what kind of data is
> permissable for "contact information".


As I understand it, the RIPE NCC's interpretation, and the one that Tore
leans on, is that the text does not mean that organisation End User contact
details must be published, even though they are not individual users.

The argument therefore appears to be that the text "When an End User has a
network using public address space this must be registered separately with
the contact details of the End User." should be read as "" in the current
policy document, and that changing "When an End User has a network using
public address space this must be registered separately with the contact
details of the End User." to "" changes nothing in the policy.


My stance is that this changes the policy, but that it changes the policy
to be in line with current practice.

(As a side note, 10-15 years ago, my employer received quite a lot of flak
for NOT publishing contact details for every single customer that had the
use of single, dedicated IP addresses, as part of web hosting or colocation
services, with rerference to this very policy. How times change.)

-- 
Jan
-- 

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)

[Jan Ingvoldstad]

On Thu, Jan 11, 2024 at 2:11 PM Tore Anderson  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  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
-- 

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)

[Jan Ingvoldstad]

On Thu, Jan 11, 2024 at 1:11 PM Tore Anderson  wrote:

> Hi Jan,
>

Hi Tore,

skipping your blatant misconception of what constitutes a "conspiracy
theory" ...


> > Continously appealing to RIPE NCC as the authority of policy and
> > policy interpretation is not a good thing.
>
> The RIPE NCC is the secretariat of the RIPE Community and is delegated
> the task of implementing and enforcing the RIPE Community policies, as
> well as to providing training to the LIRs on how to operationalise said
> policies. If that is not an authority worth paying attention to, I do
> not know what is.
>
> After all, any LIR which prefers the RIPE NCC interpretation of the
> policy in this regard is may simply adhere to it and act accordingly,
> and this is commonly done today. Thus the RIPE NCC's interpretation of
> the policy – mistaken or not – ends up becoming the (de facto) way the
> policy is implemented anyway.
>

This statement basically renders the point of a policy working group moot.

-- 
Jan
-- 

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)

[Jan Ingvoldstad]

On Thu, Jan 11, 2024 at 9:45 AM Tore Anderson  wrote:

> Hi Denis,
>
> On 11/01/24 03:20, denis walker wrote:
>
> > This is total madness. You keep saying you have no intention of
> > changing anything else. You keep saying the wording change actually
> > changes nothing in practice. Some other people don't agree with you.
> > Just don't change wording that you claim changes NOTHING and has
> > nothing to do with aggregation and everyone is happy. The fact that
> > you are pushing so hard to make this wording change, you refuse to
> > back down or compromise, you insist on changing wording that changes
> > nothing and has nothing to do with aggregation...proves that you don't
> > believe that yourself. The fact is, I suspect that this is the real
> > change you want. You want to drop the current policy requirement to
> > define assignments with End User contacts. It is the aggregation that
> > is the side issue here. There is no other explanation for why you are
> > insisting so strongly on changing wording that changes nothing.
>
> Here we find ourselves in conspiracy theory land, frankly.


Uh. While questioning your motives is perhaps a bit rude, this is WAY over
the top, Tore.

Please retract this weird accusation, I really don't understand your
motives for trying to label this as having to do with a conspiracy theory.
It tarnishes the discussion.


> It makes zero
> sense, too:
>
> If our ulterior goal was to remove the End User contacts from our own
> assignments we can just go ahead and do so, right now. The RIPE NCC is
> already on the record saying that's totally OK, and we would be
> following in the footsteps of many other LIRs who have already done so.
> Why on Earth would we waste our time on a policy proposal?
>
> If our ulterior goal was to remove the End User contacts from other
> LIRs' assignments, 2023-04 simply doesn't accomplish this goal, because
> it conveys no requirement on LIRs to remove anything from the database
> whatsoever.
>
> The RIPE NCC has not identified any unintended or ulterior side effect
> caused by 2023-04 either, does that mean they are a part of the
> conspiracy too?
>

While you seem to argue that the RIPE NCC is both omniscient and
omnicompetent, I do not think it is that easy.

I simply think that the RIPE NCC and you are mistaken.

Continously appealing to RIPE NCC as the authority of policy and policy
interpretation is not a good thing.

It undermines the community drive behind policies.

If this is where we are going, it seems that we would be just as well off
by letting EU politicians run the show.

-- 
Jan
-- 

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)

[Jan Ingvoldstad]

On Thu, Jan 11, 2024 at 9:40 AM Tore Anderson  wrote:

>
> Your conclusion that this situation results in a policy violation, is
> however entirely contingent on your interpretation of the current policy
> as mandating the publication of the End User's (non-delegated) contact
> information.
>

Please stop misrepresenting this argument.
-- 
Jan
-- 

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)

[Jan Ingvoldstad]

On Tue, Jan 9, 2024 at 3:12 PM Tore Anderson  wrote:

> Hi again Jan,
>
>
Hello again, Tore, and thanks yet again!


> On 09/01/24 13:38, Jan Ingvoldstad wrote:
>
> It is important to also consider the cases where the End Users are
>> organisations that do not have non-PII role addresses.
>>
>> Consider for example a small one-person business, let's say a farm owned
>> by «Farmer Fred». This End User would be a company, not an individual,
>> yet the company is often given the same name as the person owning it (at
>> least here in Norway).
>>
>> The e-mail address might well be farmer.fred@gmail and the phone number
>> might be the Farmer Fred's personal mobile. This would mean that both
>> the name and the contact information for this End User *is* PII and is
>> in scope of the GDPR.
>>
>
> The current interpretation of this part of the GDPR is that "Farmer Fred"
> is permissible to publish.
>
> Whose interpretation? According to the EU Commission: «Personal data is
> any information that relates to an identified or identifiable living
> individual. Different pieces of information, which collected together can
> lead to the identification of a particular person, also constitute personal
> data.»
>
>
> https://commission.europa.eu/law/law-topic/data-protection/reform/what-personal-data_en
>
> «Farmer Fred» – the name of an individual – clearly falls within this
> definition. So does his e-mail address and telephone number. Publishing
> this information requires a lawful basis, e.g., consent. If consent was
> refused, it is not permissible to publish. This is presumably the reason
> why the RIPE NCC states the following in the 2023-04 Impact Analysis:
>
> «Inserting any personal data in the RIPE Database must be in compliance
> with the RIPE Database Terms and Conditions, even when it relates to the
> contact details of the member’s own contact person(s). In particular,
> before anyone updates the RIPE Database with personal data, they must
> obtain the contact person’s informed and expressed consent and ensure this
> data is kept accurate and up-to-date.»
>
> https://www.ripe.net/participate/policies/proposals/2023-04#impact-analysis
>
This is a fairly radical view of how GDPR regulates publishing of personal
data, IMHO erring far to the side of misunderstood caution:

https://commission.europa.eu/law/law-topic/data-protection/reform/rules-business-and-organisations/application-regulation/do-data-protection-rules-apply-data-about-company_en

Does "Farmer Fred" alone "allow the identification of a natural person"?
IMHO it does not, and this seems to be the accepted view in various
publicly databases publishing data regarding companies containing parts of
the name of natural persons.

Basically, any public company register would be illegal according to the
interpretation you lean on here.


> Precisely. The LIR, like a domain name registrar, can simply serve as a
>> proxy between the wider Internet community and its End Users.
>
>
> No, that is not what I wrote.
>
> This is about an automatic email forwarding scheme, not about a
> registration by proxy scheme.
>
> E.g. you register the domainname ripe-example.shop with a registrar within
> the EEA, your email address is published (for EEA-based domainnames,
> anyway) as e.g. qaobuaidbvsas@privacy.example, which is a valid email
> address that is automatically forwarded to e.g. tore+ripe-exam...@fud.no.
>
> The policy is technology agnostic in this respect. An automatic e-mail
> forwarding scheme such as the one you describe is one example of a policy-
> (and presumably GDPR-) compliant way to do it, but that's not the only
> possible option. The LIR could instead opt for operating a human-staffed
> help desk that receives and forwards messages to End Users as appropriate.
>
The policy should be technology agnostic, and when requiring the
publication of contact details for end users, require that such publication
by a LIR conforms to regulations.

Or you could take the other stance and stop publishing *any* contact
details regarding an object, because you cannot know whether the
information is personal data or not.

The current stance is just not logical.


>
> I think that because the WG discussion has almost exclusively revolved
> around this alleged changing of policy requirements to publish End User
> contact information (which may or may not be PII), it is easy to lose track
> of what this proposal is *actually* all about. We are talking about two
> different things:
>
> 1) The actual intention behind the proposal: Making it possible to
> aggregate multiple IPv4 End User assignments that have consistent contact
> information and purpose into a single databa

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

[Jan Ingvoldstad]

On Tue, Jan 9, 2024 at 1:23 PM Tore Anderson  wrote:

> Hi Jan,
>

Hi Tore and thanks for coming back so quickly.


>
> On 09/01/24 10:51, Jan Ingvoldstad wrote:
> > On Sat, Dec 16, 2023 at 7:55 PM Tore Anderson  wrote:
> >
> > The second – alleged – change is the one that has been discussed the
> > most on the mailing list. The argument here is that your two ASSIGNED
> > PA objects above are actually in violation of *current* policy,
> > because
> > they delegate all the contact information to you (the ISP/LIR). The
> > claim is that current policy requires non-delegated contact
> > information
> > for the End User to be published in the object (not necessarily in
> > admin-c/tech-c, but “somewhere”).
> >
> > If 2023-04 passes, your two ASSIGNED PA assignments above will
> > definitely be policy compliant (even before they are possibly
> replaced
> > with an AGGREGATED-BY-LIR object). There is no disagreement about
> > this,
> > as far as we know.
> >
> > So the question is whether or not your two ASSIGNED PA objects are
> > permitted under *current* policy. If they are, then 2023-04 does not
> > change anything in this regard; the “legal status” of your objects
> > will
> > remain the same – i.e., they are not violating policy – after 2023-04
> > passes (or fails) as it is under current policy.
> >
> > We believe your two objects are not in violation of today’s policy,
> > which means 2023-04 will exact no change to their “legal status”. We
> > have elaborated on why in this message, under the heading «Does
> > 2023-04
> > change the contact registration requirements for assignments?»:
> >
> >
> https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/013913.html
> >
> > We hope this provides the clarification you requested.
> >
> >
> > Regrettably it does not, and it also raises the question of whether
> > you have forgotten the definition of "end user" and confused it with
> > "private person".
> >
> > 4.
> > An obligation to publish the End User’s contact information in the
> > RIPE database will constitute a violation of Article 6(3) of the
> > RIPE Database Terms and Conditions[5] and Article 6(1)(a) of the
> > GDPR[6], if the End User’s contact person has not given explicit
> > consent to such publication. We believe that the RIPE policy
> > cannot reasonably be interpreted to require LIRs to break EU law
> > (and even if it explicitly did require that, EU law would still
> > take precedence).
> >
> >
> > This is misleading, as posting the contact details of an end user
> > **does not necessarily require that you post PII** (person identifying
> > information). You can use a company role and a company role's email
> > address. This is also quite common in the RIPE database today, as far
> > as I can tell.
>
> It is important to also consider the cases where the End Users are
> organisations that do not have non-PII role addresses.
>
> Consider for example a small one-person business, let's say a farm owned
> by «Farmer Fred». This End User would be a company, not an individual,
> yet the company is often given the same name as the person owning it (at
> least here in Norway).
>
> The e-mail address might well be farmer.fred@gmail and the phone number
> might be the Farmer Fred's personal mobile. This would mean that both
> the name and the contact information for this End User *is* PII and is
> in scope of the GDPR.
>

The current interpretation of this part of the GDPR is that "Farmer Fred"
is permissible to publish.


>
> Therefore, if Farmer Fred exercises his rights under the GDPR to object
> against / not give consent to the publishing of his PII in the RIPE DB,
> you (the LIR) have a problem. Proceeding to publish this contact
> information over Farmer Fred's objections opens you up to legal risk
> (not to mention souring the relationship with your customer).
>

The solution here would be to not publish (and not require the publication
of) personal phone numbers (or personal addresses), and to clearly make
this a requirement in the policy regarding what End User information is
published.

Similarly, that requirement must be there for *any* contact object, not
just End Users.

You cannot know if the LIR's phone numbers are personal or not, or can you?


>
>
> > Additionally, this is what we in the registrar business consider a
> > solved problem. In the event that the end user 

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

[Jan Ingvoldstad]

On Sat, Dec 16, 2023 at 7:55 PM Tore Anderson  wrote:

> Hi Jan,
>

Hi Tore, thanks for responding, and sorry for the extreme response lag on
my part.

The second – alleged – change is the one that has been discussed the
> most on the mailing list. The argument here is that your two ASSIGNED
> PA objects above are actually in violation of *current* policy, because
> they delegate all the contact information to you (the ISP/LIR). The
> claim is that current policy requires non-delegated contact information
> for the End User to be published in the object (not necessarily in
> admin-c/tech-c, but “somewhere”).
>
> If 2023-04 passes, your two ASSIGNED PA assignments above will
> definitely be policy compliant (even before they are possibly replaced
> with an AGGREGATED-BY-LIR object). There is no disagreement about this,
> as far as we know.
>
> So the question is whether or not your two ASSIGNED PA objects are
> permitted under *current* policy. If they are, then 2023-04 does not
> change anything in this regard; the “legal status” of your objects will
> remain the same – i.e., they are not violating policy – after 2023-04
> passes (or fails) as it is under current policy.
>
> We believe your two objects are not in violation of today’s policy,
> which means 2023-04 will exact no change to their “legal status”. We
> have elaborated on why in this message, under the heading «Does 2023-04
> change the contact registration requirements for assignments?»:
>
>
> https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-December/013913.html
>
> We hope this provides the clarification you requested.
>

Regrettably it does not, and it also raises the question of whether you
have forgotten the definition of "end user" and confused it with "private
person".

  4.
> An obligation to publish the End User’s contact information in the RIPE
> database will constitute a violation of Article 6(3) of the RIPE Database
> Terms and Conditions[5] and Article 6(1)(a) of the GDPR[6], if the End
> User’s contact person has not given explicit consent to such publication.
> We believe that the RIPE policy cannot reasonably be interpreted to require
> LIRs to break EU law (and even if it explicitly did require that, EU law
> would still take precedence).


This is misleading, as posting the contact details of an end user **does
not necessarily require that you post PII** (person identifying
information). You can use a company role and a company role's email
address. This is also quite common in the RIPE database today, as far as I
can tell.

Additionally, this is what we in the registrar business consider a solved
problem. In the event that the end user is a private person, you instead by
default post anonymized information and e-mail addresses. In the case of
e-mail addresses, the typical solution is to post a randomized e-mail
address that acts as a forwarding address, and that this address is rotated
according to the registrar's internal criteria. In the case of RIPE, it
would be the LIR's responsibility, I guess.

So this argument regarding publication of PII is void.
-- 
Jan
-- 

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)

[Jan Ingvoldstad]

Hello,

Can the proposers please clarify how a change, that is claimed to change
nothing, is a necessary change?

Unless this is resolved, I oppose the change.

-- 
Jan
-- 

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 Are anonymised assignment objects valid?

[Jan Ingvoldstad]

Hi, and sorry for not engaging in this discussion at an earlier point in
time.

On Mon, Oct 2, 2023 at 6:09 PM Sander Steffann  wrote:

>
> I personally have no problem with this change. I recognise the importance
> of documenting every end-user’s contact details, as end-users were often
> actively involved in running their network. But in this day and age of
> outsourcing, the value of the information is much lower than it used to be.
>
> I’m not saying that there is no value anymore! There are many cases where
> resource holders are actually network operators with relevant information
> in the DB, but I don’t think that changing the policy will cause them to
> suddenly stop creating DB objects. And for those who don’t *want* to
> document things, they have already found ways around that in the current
> implementation of the policy.
>

I sort of agree with the reasoning, however: sloppy contact details have
real world consequences.

They result in blocklisting of entire IP ranges, for email, or even for
other kinds of network traffic, because the contacts listed are "dummy"
contacts.

Denis is, although wordy and repetitive, pretty much dead on with the
reasoning.

However, I do not think it is necessary to require person names or other
direct PII.

Roles and role addresses could be encouraged.

In some parts of the Internet, there are regulatory requirements that abuse
departments answer and deal with complaints in a timely manner. These time
limits are fairly short.

Just because e.g. Google and Microsoft laugh in the face of such
requirements and provide dysfunctional contact points, does not make it
okay, nor an obvious matter of policy change to remove the requirement.


>
> I think the best way forward would be:
> - encourage operators to document *useful* contact info (a SHOULD)
> - don’t require what we don’t/won’t/can’t enforce (no MUST)
>

I disagree, the MUST should be there.


> - realise that the current internet is not the internet that this DB was
> designed for
>

Might as well stop issuing policy at all, then.


> - align IPv4 and IPv6 requirements/standards where possible
>

I see no reason why policyregarding contact details should differ between
IP versions.

-- 
Cheers,
Jan
-- 

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] IXP pool lower boundary of assignments

[Jan Ingvoldstad]

On Tue, Nov 8, 2022 at 9:46 AM Matthias Wichtlhuber <
matthias.wichtlhu...@de-cix.net> wrote:

>
> I don't get the point of the /29 discussion anyways. It is based on the
> false assumption that we need to stretch the pool to eternity and beyond.
> We need to stretch the pool until we can test and establish IPv4 over IPv6
> peering LANs. A /26 default is perfectly fine for that.
>

What's preventing "us" from testing and establishing this right now?

Is it a lack of impending doom?

Also, another argument I feel is missing is that 100% overprovisioning
seems to be perhaps reasonable at very small sizes, but unreasonable at
greater sizes.

Room for reasonable growth is not merely about percentages.

Over two thirds of current IXPs given the actual growth from 2019 to 2022,
fit within a /27 with *some* overprovisioning.

Combined with the option to request a greater initial size, I'd argue that
*if and only if* the point is to stretch this pool's lifespan, a /27 is
both reasonably large as a minimum size, yet not too large.
-- 
Jan
-- 

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] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database)

[Jan Ingvoldstad]

On Tue, Nov 1, 2022 at 11:25 AM Tore Anderson  wrote:

>
> I think, therefore, that it would be good to bring the policy text
> itself in alignment with the de facto/best practice interpretation most
> of us follow. 2022-02 in its current form is one way to do that, while
> backporting IPv6's AGGREGATED-BY-LIR would be another.
>
>
I don't have anything to add really, just my agreement. Thanks, Tore!

-- 
Jan
-- 

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] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database)

[Jan Ingvoldstad]

On Mon, Oct 24, 2022 at 1:02 PM Leo Vegoda  wrote:

> Hi Jan,
>
> Hi, Leo!


> On Mon, 24 Oct 2022 at 03:50, Jan Ingvoldstad  wrote:
> Does this approach rely on the registered user knowing about their
> network and Internet connection? What happens when everything was
> installed by an external contractor?
>

I'm sorry, I don't understand. What does who installed a network have to do
with this?

You get in touch with an abuse contact, which is supposed to be whoever is
responsible for handling abuse complaints for a network address.

If a contractor's email address is somehow in there, then the contractor
should know that their email address is listed as abuse contact, and when
someone gets in touch about abusive content/behaviour hosted at A.B.C.D,
either do something about it, or forward to the correct contact point.

The same goes for any other scenario.


> As I read the proposal, it is intended to allow LIRs to prune the
> records they believe do not add value. It would enable discretion,
> rather than blind obedience. Is that a negative? If so, why?
>

This is putting the cart before the horse. The proposal should argue why
this is a positive.

-- 
Jan
-- 

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] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database)

[Jan Ingvoldstad]

On Thu, Oct 20, 2022 at 6:10 PM Leo Vegoda  wrote:

> Hi Jan,
>

Hi Leo,


>
> On Wed, 19 Oct 2022 at 05:26, Jan Ingvoldstad  wrote:
> >
> > Contacting the LIR only vaguely makes sense, it's like contacting the
> domain registrar because someone is sending phishing mail from gmail.com.
> In other words, mostly completely useless.
>
> Can you please expand on this? People without your experience might
> not understand the processes you are referring to. Can you explain the
> problems that users need to resolve and the value that registration of
> small assignments in the database brings?
>

Okay. Let's say that there is an ongoing phishing campaign. A CERT or abuse
department investigates, finds that IP address A.B.C.D is hosting malicious
content.

Currently, abuse departments can then use a locally installed whois tool to
query ARIN, RIPE etc. whois databases to find out what the presumed correct
contact point is, both for the purpose of disabling the phishing campaign.

However, if the contact point is a LIR, instead of the end user, this means
that the LIR's abuse department gets all the complaints and police
contacts, increasing workload and delaying action, if any is taken at all.

In phishing and other kinds of IP-traceable abuse, time is of the essence,
so accurate and direct contact information for the party responsible is
vital.

It is therefore better to have a database of contact points with some
errors in it, than a database that, over time, is designed to become
useless.


> > Additionally, introducing this policy change without also doing
> something about historical records, seems pointless.
>
> Can you expand on this, too?
>

If small assignments, for whatever value of "small", do not have value and
are only causing extra work, the obvious thing to do is to purge the
database of these records as well.

However, there is no proposal to do so, and that means that this policy
proposal only suggests making very modest changes in how the database is
managed, with dubious benefits.

-- 
Jan
-- 

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] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database)

[Jan Ingvoldstad]

On Wed, Oct 19, 2022 at 9:37 AM James Kennedy 
wrote:

>
> Under current policy, the LIRs should register 14,744 - 29,488 additional
> Assignment inetnums in the RIPE database. What value would that bring?
>

It brings value in resolving technical issues and IP address abuse issues,
e.g. contacting the correct party when a compromised server participates in
DDoS, spamming/phishing, etc.

Contacting the LIR only vaguely makes sense, it's like contacting the
domain registrar because someone is sending phishing mail from gmail.com.
In other words, mostly completely useless.

Additionally, introducing this policy change without also doing something
about historical records, seems pointless.

See also previous comments from myself, Gert, Denis, and so on.

If you have questions regarding our varying takes on this issue, please
ask! It's easier to discuss when it's clearer that we're reading each other
clearly.
-- 
Jan
-- 

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] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database)

[Jan Ingvoldstad]

Thanks for publishing this proposal.

I don't see how this proposal solves the issues it claims it is introduced
to solve. It rather seems to guarantee that information in the database
will increasingly become stale.

To break it down by rationale:

"One of the main reasons for registering IPv4 PA assignments was that LIRs
could show their use of IPv4 and thus justify the request for an additional
IPv4 allocation from the RIPE NCC. However, this requirement has become
obsolete since the RIPE NCC ran out of IPv4 addresses in 2019."

This merely means that this particular reason is no longer relevant for
IPv4 addresses.

"The application of IPv4 assignment registration policies in the RIPE
Database is inconsistent. Some resource holders flood the database with
tiny assignments (e.g. assignments for individual IP addresses), while many
others do not register any assignments."

This proposal does nothing to resolve the perceived database inconsistency,
there is no proposed cleanup of current database entries.

"This proposal is in line with the data consistency and data minimisation
principles (as defined in the DBTF report [3]:

   - Data stored in the RIPE Database should be adequate, relevant, and
   limited to only what is necessary.
   - It is recommended that resource registration requirements are applied
   consistently."

This proposal does not adequately describe this.

"Reduce the risk of LIRs registering personal data in the public database
for no longer beneficial administrative/policy reasons."

This is a red herring. If this was the goal of a proposal, why not propose
minimizing the amount of personal data, by e.g. restricting the use and
publication of personal names and personal e-mail addresses?

"More flexibility: LIRs can choose for themselves which information they
think is necessary to document and which is not, making it easier to adapt
to different situations."

This appears to be the core and only real argument for the proposal.

As the proposal stands, I am against it.
-- 
Jan
-- 

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] IPv4 waiting list policy

[Jan Ingvoldstad]

On Wed, Dec 8, 2021 at 7:41 PM Randy Bush  wrote:

> >>> C) IPv4 waiting list priority follows the size of existing
> >>> allocations for the LIR. The lower amount of allocations, starting
> >>> with zero, the higher the priority.
> >>
> >> if the purpose of new allocations is to allow entry, why would an LIR
> >> with any existing allocation be given more?
> >
> > That would only happen if there are zero new entrants, as an LIR with any
> > existing allocation would have a lower priority on the waiting list.
>
> i asked why, not how.  imiho, the list should be for *new* entrants,
> period.
>

If there are no new entrants, why should any available netblocks be kept
unavailable for entrants who request additional netblocks?

Not that I think it will ever happen ...

-- 
Jan
-- 

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] IPv4 waiting list policy

[Jan Ingvoldstad]

On Wed, Dec 8, 2021 at 12:26 PM Randy Bush  wrote:

> > C) IPv4 waiting list priority follows the size of existing allocations
> for
> > the LIR. The lower amount of allocations, starting with zero, the higher
> > the priority.
>
> if the purpose of new allocations is to allow entry, why would an LIR
> with any existing allocation be given more?
>

That would only happen if there are zero new entrants, as an LIR with any
existing allocation would have a lower priority on the waiting list.

-- 
Jan
-- 

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] IPv4 waiting list policy

[Jan Ingvoldstad]

This is a good discussion, and a good discussion to have.

On Tue, Dec 7, 2021 at 8:54 PM denis walker  wrote:

> As Gert said, let's apply
> a policy change back to 1/1/21. If someone wants to challenge it in
> court...let them name and shame themselves. As a community/membership
> we should be willing to stand by our principles of fairness and let
> the RIPE NCC go to court to defend these principles. While IPv4 is
> still in use and essential for genuine new startup businesses, let's
> stand up to those who are playing these games for profit...for the
> good of the internet.
>
>
>
...

I am going to go one step further than Gert's proposal. Let's suspend
> the current policy pending a review. In other words, freeze the
> allocation of /24s. I am sure there is nothing in the PDP or anywhere
> else that allows for this. But there probably is nothing that
> disallows it either. Again let's have a legal review and take bold
> action.
>

These suggestions seem to combine nicely with a 60-month block on transfers
(including M) or permanent block of transfers (including M).

I'm a bit hesitant regarding blocking M, but a 60-month block of M
handover would probably suffice.

So, to sum up what I think sounds reasonable (the list is not an "or"-list,
it's an "and"-list):

A) IPv4 address space allocated this year, and for the future, will be
non-transferable.
B) IPv4 address space allocated this year, and for the future, will not be
transferable via M for 60 months after allocation.
C) IPv4 waiting list priority follows the size of existing allocations for
the LIR. The lower amount of allocations, starting with zero, the higher
the priority. The next priorty level can gain resources if an only if noone
of higher priority is waiting for resources.
D) When considering existing allocations for prioritizing the waiting list,
also consider other LIRs within the same corporate structure as the same
LIR.

Process steps:

1) Freeze the allocation of IPv4 address space as soon as possible.
2) Prepare new policies for allocations, transfers, and M
3) Unfreeze allocation when the new policies are in place.

-- 
Jan
-- 

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-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space) to be discussed on Routing Working Group Mailing List

[Jan Ingvoldstad]

On Fri, Nov 1, 2019 at 12:16 PM JORDI PALET MARTINEZ via address-policy-wg <
address-policy-wg@ripe.net> wrote:

> Hi Nick,
>
> My point was also a general observation (not something against any
> specific participant, just taking advantage of this specific example, as a
> mention to "Spanish inquisition" and "routing police" could be interpreted
> in between lines as something different, even if not intended).
>
> There are many non-native English speakers in the RIR communities (at it
> happens in IETF, ICANN, etc.), however, often the native ones forget about
> that and keep using those jargons.
>
> Doing so, you as asking the non-native speakers to spend 4-5 more times to
> read each message, to google around, looking at Wikipedia, youtube, etc.
>
> Note that I fully understand that for those that are native-speakers, you
> are just using your natural language and expression, but being considerate
> to others may be much easier for you than for non-native to waste their
> time.
>
> Should then we, non-native speakers, start using in the list our own
> languages and expressions that even using google translator, you will not
> catch? Are we discriminating part of the community otherwise?
>

In some regards, you/we already do, as we impose our own English variants
on other list members.

I often need to spend 5-10 times more time reading your messages, than
those of others, because you phrase things differently (and from my
perspective, often awkwardly). It also happens with other non-native
writers.

I silently accept this as the cost of communication across borders with a
common, imperfect language. It's how things are, and I'll just have to try
and make the best of it.

That said, I agree that anyone writing in their native or non-native
English should be well aware that they need to be careful using idioms.
-- 
Jan

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

[Jan Ingvoldstad]

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.


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

This either means that the LIR needs to be the abuse contact, or there
needs to be a delegated abuse contact.

I'm nagging about this, because the Internet is full of abuse, and in the
absence of functional abuse contact points, IP address ranges get
blacklisted or blackholed without any notification reaching the network
owner.

-- 
Jan

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

[Jan Ingvoldstad]

On Wed, Feb 6, 2019 at 3:16 PM Kai 'wusel' Siering  wrote:

> On 06.02.2019 14:36, ga...@nethinks.com wrote:
> >> […] I'd
> >> rather hand that /21 as two /22 to two new LIRs instead of eight /24
> >> to eight new LIRs, since a /24 is basically useless anyway. Especially
> >> if you have to wait 6 or more months for it. (Of course, /22 (in up to
> >> /24 slices) will mean a much longer waiting time, which makes  IPv6
> >> just more interessting. Or IPv4 brokers.)
> > Why is a /24 useless?
>
> Sorry for beeing too brief here: From my perspective, becoming an LIR
> implies the intend to provide service a lot of customers, and I don't
> see how a single /24 would suffice there. That's what I meant with
> "basically useless" (from a business point of view).
>

In that case, IPv4 is "basically useless" from a business point of view.

But that statement is provably false.

Additionally, a lot of business is about providing services that are *not*
connectivity-based, to a lot of customers.

Additionally, a lot of connectivity services can be provided via NAT.

And so on.

This line of argument is not fruitful, sorry. Please abandon it.
-- 
Jan

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

[Jan Ingvoldstad]

On Wed, Feb 6, 2019 at 1:10 PM Kai 'wusel' Siering  wrote:

> On 06.02.2019 12:32, Denis Fondras wrote:
>
> If you keep there /22 and /24 as an option, than there would be no problem.
>
> No please, don't let LIR choose. This will only complicate management of
> resources.
>
>
> It's a simple flag, "/24 sufficienct: yes/no".
>

The flag is simple, and most people will then select "no", because they
want to ensure that they get the most.

Imagine if you were a Dropbox customer, and Dropbox offered two paid
storage plans for $200/mo:

1) 250 GB
2) 1 TB

and then you were presented with the simple flag, "250 GB sufficient:
yes/no"

What would you choose?

My bet is that you would choose "no" and request 1 TB.
-- 
Jan

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

[Jan Ingvoldstad]

On Tue, Feb 5, 2019 at 1:26 PM Alexey Galaev  wrote:

> Hello.
> I strongly oppose this proposal.
> Why there are no proposal with increasing IPv4 Allocations to /19, for
> example?
>

Because you and others who think this is possible and desirable, have not
bothered to do so.

Put up the proposal, with a clear analysis that shows how this can be
realistically implemented.

-- 
Jan

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

[Jan Ingvoldstad]

On Tue, Feb 5, 2019 at 11:16 AM Sander Steffann  wrote:

> Hi Michiel,
>
> > Just another point for discussion: what to do when this /24-only policy
> is in effect and RIPE NCC happens to recover a large chunk (e.g. /16 or
> more) and is able to hand-out multiple /22's again?
>
> The policy explicitly states that once the waiting list policy is in
> effect the old policy is removed. So the large block would be used to
> process requests from the waiting list.
>
>
Yup, and also: a /16 isn't a large chunk in comparison to the waiting list.
It's only 256x /24 blocks. If I read the graphs right, it would be gone in
less than a month.

-- 
Jan

Re: [address-policy-wg] what does consensus mean

[Jan Ingvoldstad]

On Tue, Jan 16, 2018 at 11:40 AM, JORDI PALET MARTINEZ via
address-policy-wg  wrote:

> 1) When you believe you agree with a policy proposal and declare it to the 
> list (so chairs can measure consensus), do you “agree” only with the “policy 
> text” or with the arguments written down in the policy proposal, or with the 
> NCC interpretation (impact analysis), or all of them?

Obviously, if I state only that I agree, I agree that the policy
proposal as written is acceptable, and should be implemented, in light
of whatever arguments and analysis have been made.

> 2) What if the text in those 3 pieces are presenting contradictions or can be 
> easily be interpreted in different ways?

In that case, I have probably not seen the contradictions, or don't
think that they are contradictions.
-- 
Jan

Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)

[Jan Ingvoldstad]

On Fri, Sep 22, 2017 at 3:28 PM, Tom Hill  wrote:
> The concern was that once the minimum size is a /24, as proposed, there
> will be a need to permit /25 or /26 announcements to permit certain
> traffic engineering strategies. Not that /22s will continued to be
> disaggregated. Disaggregation to /24 is bad enough as it is, IMO.

"Well, actually"

This just means that "certain traffic engineering strategies" will no
longer be viable for new entrants.

-- 
Jan

Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)

[Jan Ingvoldstad]

On Thu, Sep 21, 2017 at 1:43 PM, Marco Schmidt  wrote:
> Dear colleagues,
>
> A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 Allocation,
> aiming to preserve a minimum of IPv4 space", is now available for discussion.
>
> The goal of this proposal is to reduce the IPv4 allocations made by the RIPE 
> NCC
> to a /24 (currently a /22) and only to LIRs that have not received an IPv4 
> allocation
> directly from the RIPE NCC before.
>
> You can find the full proposal at:
> https://www.ripe.net/participate/policies/proposals/2017-03/

As laid out, I think this proposal makes sense, and is also presented
in due time before it strictly becomes necessary. That's good.

An IPv4 allocation of this size (and even less, 32 addresses, but,
graaahgh, routing) makes sense to ensure that there can be new
entrants for a long time to come, and doesn't seem overly burdensome
for new entrants.
-- 
Jan

Re: [address-policy-wg] unacceptable conduct and ad-hominem attacks

[Jan Ingvoldstad]

On Wed, Oct 19, 2016 at 2:58 PM, Ciprian Nica  wrote:
>
>
> Unsubscribe, shut up, go away... Next time you'll send me to a
> concentration camp ? No I WILL NOT SHUT UP ! I will always express my
> opinion even if I'm the only one in the world supporting it. A great
> romanian said that the best definition of democracy is "I will fight till
> my last drop of blood so you will have the right to disagree with me".
>
>
Your democratic right is to express your opinions without persecution from
governmental authorities (with certain limitations).

However, this is not a democracy.

Additionally, you do not have the right to force your invective on others.
We are not obliged to listen or read what you write, and as a mailing list
member, you are obliged to at least a minimum of civility and courtesy to
other members of the same list, be they WG chairs, or regular members.

Calling them nazis and implicating that reacting to your behaviour is to
send you to a concentration camp is far, far out of line, and shows that
you're too disconnected from reality to listen to or respect, sorry.
-- 
Jan

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

[Jan Ingvoldstad]

On Wed, Oct 19, 2016 at 3:01 PM, Roger Jørgensen  wrote:

>
> Guess it's a last resort when they see that they are running out of
> arguments? And amazing that
> some people have turned to "personal" attacks here rather than
> discussing the policy at hand.
>
>
> Either way - well handled Gert, you got my full support.
>

I agree completely, thanks for voicing it that way.

Regarding the policy at hand, even considering Nick Hillard's argument
> it's hard to not support
> this policy. It at least try to solve a almost impossible problem to
> solve, better to do some
> than nothing? So a clear support from me.
>

I support the proposal.

The current text appears sufficiently improved to address the concerns
raised, as I see it.

-- 
Jan

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

[Jan Ingvoldstad]

On Mon, Jun 20, 2016 at 11:01 AM, Aleksey Bulgakov 
wrote:

> Hi.
>
> I think there is 2015-01 and it is enough to prevent reselling for
> undistributed 185./8 and others proposals make more problems for all -
> members, RIPE stuff, member's customers. E.g. is multiple accoutns
> when executive board suspend it and then asked to vote to allow it
> again. The IPs aren't burn (it is not oil or gas) even some one sell
> it. Simply the owner is some LIR but not the NCC. May be it will
> increase the price, no more. But the NCC wants to have exclusive
> rights to sell it (but RIPE is not organisation to make profit or I am
> wrong? :) ) and creates new proposals.
>

You are wrong in the sense of "not even wrong".

1) It's not about 185/8
2) It's not "burning" as in setting fire to something, but as in further
reducing the available address space for registration.
3) You've got the whole "ownership" thing mixed up.
4) You've got the whole "rights to sell" thing mixed up.
5) You've got the whole "make profit" thing mixed up.

-- 
Jan

Re: [address-policy-wg] Support for 2016-03 v2.0

[Jan Ingvoldstad]

On Sat, Jun 18, 2016 at 11:38 PM, Daniel Suchy  wrote:

> Hello,
>

Hello,


>
> Do we really want do block new organisations with new allocations, but
> allow old (happy) one to do anything with addresses tehy have...? That's
> not fair.
>

I'm afraid that "fair" in that regard, is impossible to achieve.


> There're organisations, which have large allocations and they're
> sometimes not taking care - they have enough IPv4 addresses, nothing is
> pushing them to implement IPv6, or save address space by implementation
> of some NAT solution. If they decide to sell their business, policy will
> allow that - but, if "new" resource holder will try similar thing,
> policy will ban then?
>

No, the new policy does not ban selling their business (merger/acquisition).

My point is simple - there should be ONLY ONE POLICY - independent on
> time of allocation. Such policy must limit not only new LIRs (using
> addresses from last /8), but also old LIRs holding addresses from old
> allocations.
>

Why do you want to do that?


>
> And if we really want to reclaim some address space, we should review
> current allocations - in terms of current situation in IPv4 world.
>
>
How do you propose to go about that?

-- 
Jan

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

[Jan Ingvoldstad]

On Sat, Jun 18, 2016 at 8:43 PM, Radu-Adrian FEURDEAN <
ripe-...@radu-adrian.feurdean.net> wrote:

>
> What exactly means stockpiling ? Opening additional LIRs to satisfy one
> organisation's own need ?
>

No, to "stockpile" is to store something without using it. "Need" doesn't
come into it.


> In what is stockpiling "last /8 space" worse than "stokpiling IP space"
> in general ? Especially for already-acquired space ?
>
>
What is done, is done.

Stockpiling *more* space means there will be even less even more quickly
for future LIRs, or fewer future LIRs, and it also increases operating
costs, because the IP space available on the market becomes less even more
quickly.

You seem to think it's a problem that already-acquired space is "unused",
why don't you think it's a problem that even more space stays "unused"?

-- 
Jan

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

[Jan Ingvoldstad]

On Sat, Jun 18, 2016 at 3:46 PM, Arash Naderpour 
wrote:

>
> >This proposal actually will only disadvantage "young LIRs" if they want to
> do stuff with their /22 that is frowned upon by the community - namely,
> trade, instead of "use for customers".
>
> That's not true, it can affect any holder of /22 from 185/8


Can you please stop writing that? It is not about 185/8. It's about all
allocations made after a certain point in time.


> not only "young
> LIRs".
> Even if it was limited to "young LIRs" it was not acceptable to me as they
> need to be treated same as "old LIRs", These who become a member earlier
> already have enough advantage over the newer ones, and this policy grant
> them more and I cannot agree with that.
>

I really cannot see how that is true. The policy proposal provides new LIRs
with better protection from "shark" LIRs who don't want to run businesses
with their allocated space.

The proposal is all about protecting new LIRs who actually will do
assignments with their allocated space.

I do agree, though, with the repeated criticism about how M is handled.
-- 
Jan

Re: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)

[Jan Ingvoldstad]

On Thu, Jun 9, 2016 at 11:04 AM, Sylvain Vallerot <
sylvain.valle...@opdop.net> wrote:
>
> These would be correct if applied to End Users, unfortunately your
> proposition is applying to LIRs.
>
> So as I understand it, 2016-03 results in making a LIR's dimension
> void, e.g. to assimilate a LIR to an End User.
>

Several (and I would say many) LIRs _are_ end users, and the distinction
between LIR and end users is not, as far as I have understood past and
current policy, not intended to be watertight.

In other words, it's fine for a LIR to be an end user, and in principle, it
seems sensible that policy acknowledges that, but avoids making unnecessary
limitations that interfere with that.



>
> So I oppose this proposal.
>
> As I already explained some time ago, a fair "last /8" policy
> evolution should tend to apply abuse control on End Users and let
> LIRs make an independant job correctly : there is no point in
> having LIRs limited in distributing IP ressources to new born ops,
> and the new born ops shall not be forced to become LIRs to exists.
>

This has already happened. There has been a huge amount of new LIRs
registered in order to acquire a share of the remaining pool.

Your arguments do not seem to be arguments against 2016-03, but against
current policy.

If you want to change current policy, you should do as the authors of
2015-05 and 2016-03: gather support, make a proposal yourself.


Please note that I'm not flagging any preference for or against the policy
proposal. I think it's a bit too much like deck chair rearrangement, and my
feelings for it are more "meh" than anything else, at least for now. :)
-- 
Jan

Re: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)

[Jan Ingvoldstad]

On Sun, May 22, 2016 at 2:52 PM, Radu-Adrian FEURDEAN <
ripe-...@radu-adrian.feurdean.net> wrote:

> On Sun, May 22, 2016, at 13:02, Jan Ingvoldstad wrote:
> > You seem to be confused about what constitutes non-profit and what
> > constitutes for-profit or "commercial". Making _a_ profit does not
> > automatically make you a for-profit/commercial enterprise.
>
> Investment fund would probably be more appropriate. So is it possible to
> have a non-profit investment fund ? For me "non-profit" means not
> actively seeking profit; target being a zero end-of year result.
>

I see no evidence that the RIPE NCC is "actively seeking profit" in any
reasonable sense of that phrase.

Could you please take that rhetoric out by the barn, shoot it, and bury it
in a deep grave, so we don't have to see it anymore?

-- 
Jan

Re: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)

[Jan Ingvoldstad]

On Sun, May 22, 2016 at 12:45 PM, Radu-Adrian FEURDEAN <
ripe-...@radu-adrian.feurdean.net> wrote:

> Remco,
>
> As you may know, the "multiple LIRs" is for the moment least expensive
> way of getting around the "one /22" restriction. Combined withe the
> removal of "need checking", this very much looks like selling /22 to
> anybody willing to pay a sign-up and at least one year of membership.
>
> This may not have been intentional, but it looks to me as a first step
> to "turning commercial".
>
> With your proposal, while the idea was to discourage the "multiple LIR"
> practice, I have very serious doubts that it will happen this way. Given
> the current market price (which is only the most important show-stopper,
> but not the only one), with your proposal it would take about 5 years of
> membership to get at a similar level. With all that money going to the
> NCC. IF the NCC really whishes to keep its not-for-profit status, this
> will result in reduced membership, one reduced membership for older
> LIRs, but several memberships for the LIRs in "desperate need" (mostly
> small new ones).
>
>
I don't find your response clarifying in the least.

You seem to be confused about what constitutes non-profit and what
constitutes for-profit or "commercial". Making _a_ profit does not
automatically make you a for-profit/commercial enterprise.
-- 
Jan

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

[Jan Ingvoldstad]

On Sun, May 22, 2016 at 10:36 AM, Gert Doering  wrote:
>
>
> New LIRs - holders of /22 - have all the incentives to deploy IPv6
> already (because they do not have enough IPv4 to number everything with
> public v4 addresses) - but how would such a policy incentivize a big
> content provider that has enough v4, is not growing in number of external
> visible services (= doesn't need more v4 addresses), and has no v6?
>
> These are the sore spots today: content and cloud providers - and neither
> are likely to fall under this policy.
>
>
Thank you, Gert, for this very concise summary of the major grief that
cannot and will not be solved, neither by 2015-05 nor by 2016-03.


-- 
Jan

Re: [address-policy-wg] Splitting 2015-05 in two

[Jan Ingvoldstad]

On Sat, May 14, 2016 at 9:35 AM, Radu-Adrian FEURDEAN <
ripe-...@radu-adrian.feurdean.net> wrote:

> On Tue, May 10, 2016, at 16:39, Niall O'Reilly wrote:
> >   If it were my proposal, here's how I would go about it.
> >
> >   Withdraw the current proposal.
> >   The proposer can always do this during the process.
> >
> >   Introduce two new proposals (2016-somenumber and 2016-someothernumber)
> >   respectively containing the "Part A" and "Part B" material from the
> >   current proposal.
>
> Hello,
>
> As the proposal was written,


Yep, and this is why the suggestion starts with "withdraw the current
proposal", also because that will make it easier to proceed.


> the "part B" (allocation condition
> including v6 deployment) would have no sense on its own, since it only
> applies to the results of "part A" (further allocations).
>

This is indeed a weakness of the current proposal.


> In order to have a "part B" that makes any sens, it would mean that
> current rules for allocation of the "first /22 from last /8" would have
> to change:
>  - for a "real" first allocation (LIR that never received a v4
>  allocation before) either conditions would not apply, or a new system
>  would have to be created where the allocation is time-limited, and at
>  the end of time limit the allocated block is either returned (condition
>  not met) or made "regular allocation" (condition met).
>  - for LIRs that had previously allocated IPv4 space, condition applied
>  directly.
>
>
This seems like putting the cart before the horse.

Allocation conditions should be introduced _first_, as a "part A".

Then a separate proposal for additional allocations should be introduced
_second_, as a "part B".

This corresponds well to your own claim that your proposal intends to
preserve the pool, and should not deplete it rapidly, and will perhaps even
make it possible to proceed.

To me, this is the test of whether you actually stand by that claim.

-- 
Jan

Re: [address-policy-wg] agreement

[Jan Ingvoldstad]

On Tue, May 10, 2016 at 10:02 AM, Radu-Adrian FEURDEAN <
ripe-...@radu-adrian.feurdean.net> wrote:

> Hi,
>
> On Mon, May 9, 2016, at 14:50, Sander Steffann wrote:
> > Indeed. It all comes down to "the needs of those in the next few years
> > with no IPv4 addresses" vs "those today who have only one /22".
>
> I find the situation a little more complex than that:
>  - First, the "in a few years with no IPv4" is not so far away. Even
>  with current policy, it is for 2020, with a lot of chance 2021. With
>  the proposal, worst case scenario is that we MAY loose up to 18 months
>  (more likely something in the 6-12 months range ). Which is not
>  completely sure (as Martin Huněk noted a few messages ago).
>  - Second, right now the NCC is just handing out /22 to whoever can pay
>  for them (with only a small extra administrative restriction during the
>  last 6 months). For me this is plain "selling IP addresses" (concept
>  that the NCC avoided like hell int the past), and it is also defeating
>  the "keep space for later entrants" purpose. No need check (as in "do
>  you really need that space" *), no requirement to deploy IPv6 of any
>  kind, just a simple "pay to have it".
>

This could be solved without introducing yet another way to deplete the
remaining pool.

The problem with 2015-05, is its similarity to how certain acts of Congress
in the US come to pass:

You bundle what you want with something else, to sweeten the deal.

So here is how you can fix the deadlock:

Unbundle. Split the proposal in two parts.

Part A: Additional requirements for IPv4 allocations

Part B: Additional periodical IPv4 allocations for existing LIRs

This would, for instance, make it easy for me to say "yes" to part A, and
"no" to part B, instead of "no" to the entire package.
-- 
Jan

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

[Jan Ingvoldstad]

On Fri, Apr 22, 2016 at 2:29 PM, Radu-Adrian FEURDEAN <
ripe-...@radu-adrian.feurdean.net> wrote:

>
> You are talking about people addicted to Coca-Cola. You can't just ask
> them to plain stop drinking Coca-Cola, as long as you have some (and
> even if you no longer have, it's still difficult). You can just say "If
> you start drinking water, there may be some small amounts until you
> fully switch to water". At least that's the idea. And it's suposed to
> only be applied to small guys, since the big ones still have large
> stocks to support the transition.
>

I'm sorry, this reasoning simply doesn't make sense to me, in spite of the
slightly condescending answer from Adrian, and your continued use of the
analogy.

There is little evidence to support that line of reasoning, and all too
much against it.

Additionally, little thought seems to have been spent considering how this
should be implemented, I mostly see some hand-waving here.

My feeling is that this policy will serve two groups in particular:

- Speculants
- Spammers who want "clean" IPv4 space for their ventures, because IPv6
spamming isn't useful yet

While this clearly isn't the intent you have stated in your policy, I
believe this is what it will be used for, regrettably.
-- 
Jan

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

[Jan Ingvoldstad]

On Thu, Apr 21, 2016 at 10:19 PM, Radu-Adrian FEURDEAN <
ripe-...@radu-adrian.feurdean.net> wrote:
>
> Small guys are either among the first or among the last to do it. You
> can find incetives from them (??? extra /22 ???)
>

This is a part of reasoning I don't understand.

"We would like for you to stop drinking Coca-Cola (IPv4) and instead drink
water (IPv6). Here, have some more Coca-Cola."

How is that an incentive for drinking water?

It's not. It's an incentive for _continuing_ drinking Coca-Cola, because
hey, maybe the nice fools will give you more Coca-Cola also the next time
you run out.

-- 
Jan

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

[Jan Ingvoldstad]

On Sun, Apr 17, 2016 at 9:31 AM, Adrian Pitulac  wrote:
>
>
> Jan, I think you should read my previous posts, I've come up with several
> arguments, none of which have been seriously discussed and analyzed.
>

I have read your arguments, and they have been previously discussed and
analyzed.


>
> Also FYI I've been reading the discussions here for a long time, and this
> intervention is my first because I see the same explanation again and again
> without no base.
>
> This should be a discussion on arguments not just a presentation of
> personal "default" denial of any change to policy. This is what I saw until
> now. I was under the impression that people here can start a discussion and
> analyze the *for* and *against* arguments until we reach a conclusion. Am I
> wrong?
>
>
Well, insofar that you yourself have not presented any thorough arguments
or analysis yourself, you are right.

But others have.

That you choose to disregard these arguments and analysis, is really your
problem, and your problem alone. Repeating your talking point does not
help, and it only makes your arguments look weaker.

Frankly, your arguments have made me even more certain that this policy
needs to be stopped, and the current policy has to stay in place to ensure
some opportunity for future entrants.

PS: My point of view directly disadvantages my employer, who could stand to
gain financially from the proposal, which allows for more stockpiling of
IPv4 resources for future scarcity.
-- 
Jan

Re: [address-policy-wg] Working group chair rotation 2

[Jan Ingvoldstad]

On Mon, Feb 8, 2016 at 9:24 PM, Sander Steffann  wrote:

> Hello working group,
>

Hi there!


> A year has passed since we implemented our working group chair rotation
> mechanism, so it is time for one of the APWG chairs to offer his place in
> case the working group would like to see a change of chair. This time it is
> my turn to step down, and I will do so in the APWG session at RIPE 72 in
> Copenhagen. So this is the time for candidates to volunteer and make
> themselves known here on the list! To be considered candidates must make
> themselves know before the start of RIPE 72.
>
> So, let me start by volunteering again :)  I would love to serve this
> working group for another term as one of its chairs. A short introduction
> for those who don't know me:
>

Well re-volunteered!

I essentially want to use what I have learned in the last 9 years and
> continue to guide the working group in always-improving ways.
>
>
I think you've done a splendid job so far, and I agree with all the
positive noises being made in favour of your continued chair occupancy.

That said, I do think it would be interesting if there were other
candidates, even though it's a tall order to try to fill your shoes.

-- 
Jan

Re: [address-policy-wg] 2015-05

[Jan Ingvoldstad]

On Mon, Nov 2, 2015 at 1:16 PM, Dominik Nowacki 
wrote:

>
> I think the policy should allow for the subsequent allocations from the
> last /8, but only if the space is not only not transferred out of the LIR
> account in the period of 18 months AND the LIR was not renting the space
> from the last /8 to another entities within the last 18 months period
> (solely, not as part of another service).
>
>
>
> What do you think ?
>

How do you propose that RIPE NCC go about acquiring that information and
enforcing that regulation?

Is there a bit of confusion regarding what a LIR is?

https://www.ripe.net/manage-ips-and-asns/resource-management/faq/independent-resources/phase-three/what-is-a-local-internet-registry-lir
-- 
Jan

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

[Jan Ingvoldstad]

On Tue, Oct 20, 2015 at 3:15 PM, Tom Hill  wrote:

> On 20/10/15 14:02, James Blessing wrote:
> > Can we limit it this to a /X to see what the impact is before
> > throwing the entire remaining v4 space under a bus?
>
> I was thinking the very same, actually.
>
> If we're thinking that the current policy has been too conservative,
> it seems like we should be cautious not to swing too far in the other
> direction (too liberal).
>
>
Here's a thought experiment:

Set aside a /12 pool for this particular purpose.

This means that up to 1024 additional allocation requests may be made.

It means that it is predictable, and according to those who complain the
most about the strict policy, should be more than ample enough to handle
those who think they need more IPv4 space.

There would not need to be any further restrictions than those that are
already in the policy and this proposal.

Pro:

- ensures that we don't accidentally "liberate" our RIR of its current pool
- ensures that small actors get a bit more

Con:

- still unfair to greater LIRs
- only a small pool, which risks being a "oh, cool, it's gone" experiment

-- 
Jan

Re: [address-policy-wg] Opposing policy 2015-01

[Jan Ingvoldstad]

On Sat, Jul 11, 2015 at 7:30 PM, Petr Umelov p...@fast-telecom.net wrote:

 Hello, WG.

 I understand you will approve this proposal in any case, you have made a
 decision in January and should comply with formalities.

 However I see many companies began to open multi LIR accounts and receive
 additional allocations.

 E.g.
 netname: NL-PCXCOP-20150707
 netname: NL-PCXMAD-20150707

 netname: DK-BORNFIBER5-20150709
 netname: DK-BORNFIBER9-20150709

 netname: ES-RULZ2-20150710
 netname: ES-RULZ3-20150710

 netname: ES-SUNNY2-20150710
 netname: ES-SUNNY3-20150710

 Traders don't want to lose their profit and will begin to provide services
 to help open new accounts for the same company and companies will be do it
 by themselves.

 Thus IPv4 pool will be exhausted during 1-2 years.

 I understand the RIPE NCC dislike someone makes profit using RIPE's
 resources but we should not make emotional decisions.


Absolutely, and therefore I suggest that since the above appears to be a
big problem for you, that you write down a proposal that will handle this
particular problem.

Most people want to scratch their itch, and if you scratch it by writing a
proposal, your itch can, perhaps, be scratched too.

But if you don't write that proposal, nothing will happen, and maybe your
worst fears will come true, through your own inaction.

It's best that those who see a problem, are the ones to attempt addressing
it.
-- 
Jan

Re: [address-policy-wg] Opposing policy 2015-01

[Jan Ingvoldstad]

On Sat, Jul 11, 2015 at 8:47 PM, Petr Umelov p...@fast-telecom.net wrote:

 Don't tell then I did not warn :)

 When you will come to your senses and will start the multi LIR hole
 closing during 6 months, IPv4 will be exhausted


When will you actually DO something, and not just demand that others take
action to solve a problem YOU want fixed?

I'm starting to think that you're not really bothered by this hole, and
that you want it to stay open, but keep on complaining that OTHERS aren't
doing your job.
-- 
Jan

Re: [address-policy-wg] address-policy-wg Digest, Vol 47, Issue 9

[Jan Ingvoldstad]

On Mon, Jul 6, 2015 at 2:48 PM, Shahin Gharghi sha...@gharghi.ir wrote:

 Hi

  I would be happy to support returning this proposal to the discussion
 phase, but only if there are compelling reasons to do so. To date nobody
 has made the case for taking that action. Although some have asked for
 this, nobody has put forward anything to justify these requests. The case
 has not been made yet. It?s up to you and your fellow travellers to make
 that case.
 

 The problem is: The person who should justify the criticisms, never
 does! And he is
 supporting the proposal so that he will never return it to the
 discussion phase...


I'm not quite sure what you're trying to say here.

I completely agree that the person(s) who should justify the criticisms,
never do(es).

One of those persons is *you*.

There are no other persons, than the ones who voice the criticism itself,
who need to justify that criticism.

I, or any other WG member, or WG chair, are in no way obliged to write your
justification for you.

-- 
Jan

Re: [address-policy-wg] Opposing policy 2015-01

[Jan Ingvoldstad]

On Wed, Jul 1, 2015 at 11:21 AM, Vladimir Andreev vladi...@quick-soft.net
wrote:

 Please don't tell about Last Call.

 In Review you also didn't considered point of view which differs from you
 own.


The point of views you have expressed, HAVE been discussed, and they have
been considered previously, by the working group.

You are free to feel that they haven't been adequately considered, and that
point is adequately made.

However, your point of view didn't gain consensus, or even break consensus.

At this point in time, it's too late for you to raise the same points
again, no matter how much you disagree with how things stand.

At this point in time, you may raise NEW concerns. You haven't, though.

I see that you feel it's more important to make noise, than to follow the
procedures.

If you really felt so strongly about this, which I sincerely doubt, you
would have started the process with a counter-proposal, annulling the
effects of 2015-01. You could have had a new proposal on the table right
away, and the PDP could have started, and if your proposal gained
consensus, it could have taken effect early next year.

But your choice is to make noise instead. This is disrespectful to us other
group members.


PS:

WG chairs, my apologies for posting this, but I really, really felt the
need to point out that this isn't just something of Gert's doing.
-- 
Jan

Re: [address-policy-wg] [policy-announce] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations)

[Jan Ingvoldstad]

On Thu, Jun 11, 2015 at 11:36 AM, Vladimir Andreev vladi...@quick-soft.net
wrote:


 As mentioned many times during debates AP WG has no relations to financial
 questions.

 In such case WHY does current policy appeal to finances?


Your conflating two different areas into one.

You're also confusing current and proposed.

Additionally, you're attacking parts of sentences completely out of context.

-- 
Jan

Re: [address-policy-wg] Next steps for new LIRs

[Jan Ingvoldstad]

On Thu, Jun 11, 2015 at 7:55 PM, Staff off...@ip4market.ru wrote:


 Let's say give new LIR /21 (2048IP). It will be more then enough for
 several years. And I will tell why. Becouse it will drop the market
 price low and stop some speculations. And a lot of people will start
 selling resources that they don't need. And people who need IPs - they
 will be able to get enough from RIPE in standard way. There is no
 secrets here. Everything is clear. If more people work in this clear and
 fair way - the more people will offer own IPs for others.

 There will be no luck of IPs. Just more redistribution.

 What do community thinks?


You seem to lack an argument as to why 2048 addresses would make everything
so much better than 1024 addresses.

-- 
Jan

Re: [address-policy-wg] PDP issues

[Jan Ingvoldstad]

On Wed, Jun 10, 2015 at 1:31 PM, Sascha Luck [ml] a...@c4inet.net wrote:


 Most proposals have some rationale against and
 a -1 can just as easily be construed to mean I agree with the
 rationale against and therefore oppose the proposal.


But _which_ of the rationales against do they agree with?

For a +1, that's very easy: it's the proposal that was linked to.

For a -1, they at the very least could point out what it is they think is
wrong, and how.

Apparently, for these particular sock puppets, even copy+paste is beyond
any effort they're willing to expend, and I believe that as much weight
should be put on the side of those opinions: nearly none.

The +1s we see here hold an entirely different weight: they're support
for a proposal that's ALREADY been through lenghty discussion process, with
ample time to raise objections, influence the actual text, and so on.

In other proposals, this excellent process has resulted in not only better
wording and in some cases significantly changed proposal texts, but also in
the complete workover or even withdrawal of the proposal in question.

So I believe both sides should be required to argue their point.


This kind of policy that you suggest, promotes false equality, and is
damaging to a fair and reasonable process.

-- 
Jan

Re: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published

[Jan Ingvoldstad]

On Wed, Jun 10, 2015 at 3:38 PM, r...@ntx.ru r...@ntx.ru wrote:

 Greetings again,

 Sorry that I joined this discussion with delay, but as i was found a lot
 of people didnt get notified or get in touch with this discussion as
 myself. Currently I discuss this things at ENOG9 with people.

 I would like to ask you some more days for discussion becouse a lot of
 people are busy at enog9 and some europe meetings but good idea to wait for
 their opinion too.


...




 Please give some days for discussion if that possible.


You are, regrettably, too late. You have already had nearly four months
since the policy change proposal was announced:

https://www.ripe.net/ripe/mail/archives/policy-announce/2015-February/000444.html

Just like I had to face that I missed a bunch of decisions before I joined
this mailing list, you have to face that you missed the boat on this one,
sorry.
-- 
Jan

Re: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published

[Jan Ingvoldstad]

On Wed, Jun 10, 2015 at 6:04 PM, Vladimir Andreev vladi...@quick-soft.net
wrote:

 Hi!

 According to PDP it's possibly to change any proposal's state to
 Discussion or Withdraw after Review phase.


That's true, but _right now_, he is too late.

If there is a new discussion phase, he can voice his opinions then.

It's also possible for him to launch his _own_ proposal.
-- 
Jan

Re: [address-policy-wg] 2015-02 Draft Document and Impact Analysis Published (Keep IPv6 PI When Requesting IPv6 Allocation)

[Jan Ingvoldstad]

On Mon, Jun 8, 2015 at 3:43 PM, Marco Schmidt mschm...@ripe.net wrote:


 We encourage you to read the draft document text and send any comments
 to address-policy-wg@ripe.net before 7 July 2015.


There really isn't much to say, except to express my full support.
-- 
Jan

Re: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations)

[Jan Ingvoldstad]

On Tue, Jun 9, 2015 at 8:25 PM, Ciprian Nica off...@ip-broker.uk wrote:

 We all hate some things, wish for others... But making the life harder
 is not equal to solving the problem.


Solving the problem 100% and perfectly is utopia.

This is one step in the right direction, and as we are discussing how to
ensure both some fairness and predictability, there will be more steps.

So instead of fighting every single step along the way, please help us move
along.
-- 
Jan

Re: [address-policy-wg] 2014-03 Review Period extended until 19 May 2015 (Remove Multihoming Requirement for AS Number Assignments)

[Jan Ingvoldstad]

On Tue, May 19, 2015 at 6:32 PM, David Huberman 
david.huber...@microsoft.com wrote:


 In 2014 there were 12 organizations that elected to receive a 4-byte AS
 number and later came back to ARIN to exchange it for a 2-byte AS number.
 Each of these organizations stated issues with their transit providers
 either unwilling or unable to accept the use of a 4-byte AS number by a
 customer.


It's seems as if the transit providers are mentioned a bit too frequently
here.

Does anyone have any information about how long it would take to get
transit providers 4-byte-ready?

-- 
Jan

Re: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size)

[Jan Ingvoldstad]

On Wed, May 13, 2015 at 11:56 AM, Roger Jørgensen rog...@gmail.com wrote:


 Are work being done in several forums on interplanetary communication,
 both with thoughts on delay and on address space. AFAIK some of it is
 already in production to using IPv6... wish my memory worked today so
 I could remember where I saw that discussion :-(


In the more immediate future, I think the main concern will be IOT-related.
(IOT = Internet of Things)

While this is a bit of a lame buzzword now, something on the scale of what
Manfred Macx et al have in the early chapters of Charles Stross's
Accelerando, may very well be how things work in a couple of decades. It's
hard to predict.

In any case, what's most important to us now, is to at least be aware of
the potential challenges, and not enact policies that will make the future
much more difficult.

And, again, I don't think the proposal discussed here poses such a problem.
-- 
Jan

Re: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations)

[Jan Ingvoldstad]

On 12. mai 2015, at 17.41, Sascha Luck [ml] a...@c4inet.net wrote:
 
 On Tue, May 12, 2015 at 05:01:58PM +0200, Gert Doering wrote:
 Actually while it was according to the letter of the policy, I
 think it will be hard to find someone to actually say it was
 according to the spirit of the last-/8 policy.  So I'd
 challenge the reasonable in your statement.
 
 A LIR now joining the RIPE NCC has no way of determining what the
 spirit of a policy is. (bar, perhaps, reading all apwg
 discussions leading to it) The letter of the document is all that
 counts and IPRAs can't make determinations based on the spirit
 either, otherwise this proposal would not be necessary.

You have a point about the spirit of the policy not necessarily being clear 
from the policy's text.

That said, I find it hard to read the current policy in a way where you could 
reasonably make the assumptions you make a case for defending.

The document isn't limited to a 5.5 that stands on its own, and anyone reading 
this point alone cannot honestly claim to act in good faith.

Additionally, the loophole in the policy is a clear discrepancy, one which an 
interested party would ask for clarification about and not merely pretend 
wasn't there.

Going along the route you've chosen therefore seems somewhat disingenuous to 
me, sorry.

-- 
Cheers,
Jan

Re: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size)

[Jan Ingvoldstad]

On Mon, May 11, 2015 at 7:19 PM, Sascha Luck [ml] a...@c4inet.net wrote:

 On Mon, May 11, 2015 at 03:58:46PM +0200, Jan Ingvoldstad wrote:

 As Nick states, I'd be interested to see a real life addressing plan
 which
 needed more than this amount of bit space. I'd actually be interested to
 see a real life addressing plan that needed a /32 bit address space, where
 the need isn't constructed based on the mere possibility of getting that
 space instead of merely e.g. a few hundre million times of the entire IPv4
 space.


 The way I read the proposal, it is not about assignment sizes but
 about a aggregation vs conservation conflict. The proponents have,
 AIUI, a problem where they might not fully
 assign a /32 or /29 allocation but have different routing
 policies for parts of their network, which cannot be satisfied
 without violating s3.4 of ripe-641.


Apparently, my point was not very reader friendly, so I'll try again:

Routing-wise, someone with 64 billion billion billion addresses, have about
16 billion billion ways to route the entire IPv4 internet, within the
address space constraints of a /32 allocation.

Even if we pretend that it's an extremely useful and necessary thing to
have a /64 per end user, so that each end user can enumerate and route the
entire EUI-64 space, a /32 is still the same as the entire IPv4 space.

That there is a need for allocating as much as a /32 in the first place
is a design failure in how the addressing segmentation has been handled, in
my opinion. It's the IPv4 /8 allocation mistake all over again.

Also, as I said, and obviously have to repeat for some people: that cat is
out of the bag. It is what it is.

But there is no need to compound this design failure.
-- 
Jan

Re: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size)

[Jan Ingvoldstad]

On Tue, May 12, 2015 at 2:34 PM, Sascha Luck [ml] a...@c4inet.net wrote:

 On Tue, May 12, 2015 at 01:28:39PM +0200, Jan Ingvoldstad wrote:

 Apparently, my point was not very reader friendly, so I'll try again:
 Routing-wise, someone with 64 billion billion billion addresses, have
 about
 16 billion billion ways to route the entire IPv4 internet, within the
 address space constraints of a /32 allocation.


 In theory, yes. But the policy currently contradicts itself to an
 extent.

 Section 3.8 of ripe-641 clearly states: In IPv6 address policy,
 the goal of aggregation is considered to be the most important.
 ss3.4 and 3.5 bear that out also.

 Yet, s5.1.2 seems to exclude aggregation as a valid reason for an
 allocation. The Proposal merely attempts to remove this
 contradiction.


Well, yes, that's why I first wrote This change makes sense … I support
it.
-- 
Jan

Re: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size)

[Jan Ingvoldstad]

On Tue, May 12, 2015 at 3:40 PM, Tim Chown t...@ecs.soton.ac.uk wrote:

 We’re to date only allocating from 1/8th of the overall IPv6 address space.


Which is actually an immensely huge part of it.


 There’s 7/8ths remaining in which policy can be changed, if required.


Yes, fortunately.



 And I would put a bet on IPv6 not being the mainstream global /
 interplanetary communication protocol in hundreds of years, but I won’t be
 around to collect, so….


Perhaps it won't, but if it won't, then the IPv6 design has failed. IPv4
already has been around for 34 years or so (IIRC, we got it in 1981), and
will be something we have to work with for a couple of decades or more,
depending on whether IPv6 actually can replace IPv6 use that quickly. So
let's say, for simplicity's sake, that IPv4's lifetime turns out to be
50-60 years.

If IPv6 shouldn't be the mainstream communication protocol for the
timeframe I mentioned, someone had best get started on IPv7.



 On the /64 boundary, I’d point you at RFC7421.


Well, I guess that's a nice document to point people to, if they're
unfamiliar with the history of IPv6 and the issues that have been raised.
I'll be sure to mention it if I run into someone who needs it, thanks!

-- 
Jan

Re: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size)

[Jan Ingvoldstad]

On Tue, May 12, 2015 at 2:26 PM, Mathew Newton 
mathew.newton...@official.mod.uk wrote:

 Hi Jan,


Hi again, Matthew, and thanks for answering.



 -Original Message-
  From: address-policy-wg [mailto:address-policy-wg-boun...@ripe.net] On
 Behalf Of Jan Ingvoldstad
  Sent: 12 May 2015 12:33

  How do you manage your IPv4 space, then?

 Not wishing to sound flippant, but the answer to that really is 'with some
 difficulty'. This is despite being in the fortunate position of holding a
 /8 IPv4 allocation (amongst other, smaller, ranges) in addition to
 widespread usage of (overlapping) RFC1918 address space.

  Do you actually have routing that needs more than 8 total IPv4 spaces?

 I cannot answer that directly because it is, in my view, a false dichotomy
 as it is far more complicated a situation than that.


What it does give you, is the opportunity to create 2048 times the amount
of routes you could in your current IPv4 /8, without worrying about the
things you could do in your internal networks with the remaining part of
the /64.

Besides which, migration to IPv6 would be a wasted opportunity if it was
 rolled out and configured in exactly the same way as IPv4 given all the
 existing problems and constraints that would continue to persist.


Oh, I agree with that. Over here, we actively abuse the system by randomly
generating /80 addresses for internal use, and reusing those in ways that
apparently never were intended by those who designed the IPv6 address
specification.

What I do think is a problem, though, is that IPv6 address space is
considered so plentiful that we're repeating the mistakes of when we
thought the IPv4 address space was plentiful.

I don't see a big problem with RIPE NCC evaluating requests for allocations
up to e.g. /24 in some very rare cases.

However, these things have a way of sliding down a slippery slope, and the
IPv6 address space is most likely what we're going to be stuck with for our
systems' lifetimes. The prospective system lifetimes are long, perhaps on
the order of hundreds of years.

And that's actually something we need to keep in mind when setting policy
today.
-- 
Jan

Re: [address-policy-wg] 2015-02 New Policy Proposal (Keep IPv6 PI When Requesting IPv6 Allocation)

[Jan Ingvoldstad]

On Tue, Apr 14, 2015 at 2:52 PM, Marco Schmidt mschm...@ripe.net wrote:


 Dear colleagues,

 A proposed change to RIPE Document IPv6 Address Allocation and Assignment
 Policy
 is now available for discussion.

 You can find the full proposal at:

 https://www.ripe.net/participate/policies/proposals/2015-02


This proposal is eminently sensible, and I support it.
-- 
Jan

Re: [address-policy-wg] Transfer Requirements for IPv4 Allocations

[Jan Ingvoldstad]

On Tue, Apr 28, 2015 at 2:12 AM, Infinity Telecom SRL i...@infinitytelecom.ro
 wrote:

  Hello,


 This is the question:  Could any of you have your company survive with
 only a /22 (and 10-15 $/IP extra, 256/512/1024 packs towards 15$/IP) ? 


Ok, I'll bite, as you seem to have a hangup about this.

This depends a lot on what the business is.

My employer is situated in one of the top 5 most expensive countries in the
world (Norway, you may have heard about it), so in order to be competitive,
we have to keep the gap between revenue and expenses minimal.

Any price increase from our partners/vendors affects that negatively, and
in some regards, 2015 started badly for us with a weakened currency towards
the Euro, USD, and most other currencies.

You probably think you know where this is leading, that I would post a
statement agreeing with you, that the answer to your question is a
resounding no.

If so, you're wrong.

The answer is a very clear yes.


Additionally, you have a hangup about survival.

For most of us who are already doing business, I believe the problem is not
about SURVIVAL. If it is, there is something very wrong with your business
model.

The problem is about GROWTH potential, though, and that potential is best
with IPv6, not IPv4.

IPv4's growth potential is a dead end, and that's been well-known for
several years. Get over it.

-- 
Jan

Re: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size)

[Jan Ingvoldstad]

On Tue, Apr 28, 2015 at 2:00 PM, Marco Schmidt mschm...@ripe.net wrote:


 Dear colleagues,

 A proposed change to the RIPE Document IPv6 Address Allocation and
 Assignment Policy now is open for discussion.

 The proposal aims to expand the criteria for evaluating initial IPv6
 allocations larger than a /29. The RIPE NCC would consider additional
 aspects beyond only the number of existing users and extent of the
 organisation's infrastructure.

 You can find the full proposal at:

 https://www.ripe.net/participate/policies/proposals/2015-03



I think this change makes sense.

Although I'd personally like to see stricter requirements and smaller
allocations sizes for IPv6 in general, the proposed change does not make
things worse from my point of view.

So I support it. :)
-- 
Jan

Re: [address-policy-wg] 2015-01 Draft Document and Impact Analysis Published (Alignment of Transfer Requirements for IPv4 Allocations)

[Jan Ingvoldstad]

On Mon, May 11, 2015 at 1:43 PM, Marco Schmidt mschm...@ripe.net wrote:


 You can find the full proposal and the impact analysis at:

 https://www.ripe.net/participate/policies/proposals/2015-01

 and the draft document at:

 https://www.ripe.net/participate/policies/proposals/2015-01/draft

 We encourage you to review this proposal and send your comments to
 address-policy-wg@ripe.net before 9 June 2015.


The proposed change is sensible and clarifies what I have understood as the
intent when the current policy was created.

I could wish for more, but that is for another discussion and another
change proposal. :)
-- 
Jan

Re: [address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size)

[Jan Ingvoldstad]

On Mon, May 11, 2015 at 11:10 AM, Gert Doering g...@space.net wrote:


 Slightly off-track, but you made me curious.  Given the number of /29s and
 /32s available in FP001, and the potential numbers of LIRs in the future
 (like, things explode and we'll see 100.000 LIRs) - where do you see the
 problem with our allocation sizes?


It's the old argument about quadrillions upon quadrillions (and more), and
how it's setting up for possible future failure in a way that's going to be
impossible to reverse at a later point in time.

I do think it's too late to put the cat back in the bag, at least for large
parts of how IPv6 addressing is handled, but I also don't think we need to
compound failure with failure.

I think we should balance between too big (aka: FP001 fills up, and
 new LIRs won't be able to get what they need [or we start using FP010])
 and too small (aka: LIRs will have to squeeze inside, and resort to
 unwanted behaviour, like give customers only a single /64 or even
 single /128).


I'm not sure that this is undesirable behaviour.

If it's undesirable, it's because the entire system has been rigged to
create the situation where it is undesirable, and then that is used as an
excuse for what I consider excesses.



 I see /32 as default, up to /29 if you ask as very reasonable middle
 ground...


It is far more than reasonable, and even though someone can legitimately
claim that they are making a setup where they can _use_ the entire IPv6
address space themselves by creating some convoluted network segmenting
scheme, it doesn't mean it's reasonable to do so.

Sure, having a /32 or greater permits us to easily use hexadecimal notation
for 4-bit granularity network segmenting.

I remain unconvinced, though, that this is necessary, even with an internet
of things that's on the level of Karl Schroeder's Ventus.

The change in policy text doesn't do anything about the practical limit,
except leaving more up to the good minds at the NCC to consider this.

Ideally, I'd think that there should be a hard limit at /29, and that there
should be very good reasons – reasons that need to be taken as a policy
debate or something like that – to go beyond that size.

As Nick states, I'd be interested to see a real life addressing plan which
needed more than this amount of bit space. I'd actually be interested to
see a real life addressing plan that needed a /32 bit address space, where
the need isn't constructed based on the mere possibility of getting that
space instead of merely e.g. a few hundre million times of the entire IPv4
space.
-- 
Jan

Re: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8)

[Jan Ingvoldstad]

On Mon, Dec 1, 2014 at 9:25 AM, Daniel Baeza (Red y Sistemas TVT) 
d.ba...@tvt-datos.es wrote:

 At least Im not the only one saying IPv6 isnt really deployed.


I'm not saying it isn't really deployed, so if you counted me as some sort
of support to your claim, you need to rethink that.



 As you all can see, Only a 5% of Google traffic is v6.


Did you look at the curve for the uptake of v6 traffic?

You've been making theses IPv6 isn't really deployed claims for a pretty
long time now.

Meanwhile, IPv6 traffic at Google has more than tripled.

Prediction:

You'll be making the claim when IPv6 traffic is 10%, 20%, 40%, and even 50%.
-- 
Jan