Re: [arin-ppml] AC Candidates (Chris Tacit)

[Matthew Petach]

On Fri, Oct 27, 2023 at 12:18 PM William Herrin  wrote:

> On Fri, Oct 27, 2023 at 12:08 PM Heather Schiller
>  wrote:
> > We wanted to encourage discussion so we could
> > determine support, but not dominate the conversation.
>
> Hi Heather,
>
> Does holding the substantive discussion in closed meetings while the
> bulk of proposals see little or no public comment on the list equate
> to the AC *not* dominating the conversation?
>

Hi Bill,

I think a slight paraphrasing of the famous line from "Hamilton" sums up
the position of the AC members well:

"Talk less; listen more"

The goal is to hear what the other members of the community have to say,
not to tell the community what *their* position is.
If you want to know their position, read the candidate statements.
Personally, I'd find it off-putting if the AC members were to jump into a
discussion on a proposal with a significant position one way or the other.
Their job is to listen to the community and enact the will of the
community, not to impose their views on the community.

Matt
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Are we an ISP or an End-User? Can our designation change at a later time?

[Matthew Petach]

Hi Jamie,

As someone who faced a similar challenge many years ago, I'll chime in with
my thoughts on the matter...


On Mon, Jan 2, 2023 at 11:32 PM Jamie Nelson 
wrote:

> ARIN newbie here.
>
[...]

>
> Questions:
> 1.) From our reading of the NRPM, it seems like we currently fall
> within the definition of an ISP, but what happens if this changes
> subsequent to our initial allocation? (*)  Likewise, what happens if
> an organization that was directly assigned resources as an end-user
> begins offering Internet services to other organizations?  The NRPM
> does not appear to address these scenarios.
>

You're providing services to people who are not directly employees,
contractors, or otherwise immediately affiliated with your organization.
I was in a similar boat, and after looking carefully at how law enforcement
approached ISPs for information versus end-users, we made a decision
to apply for resources as an ISP, as we provided services to people who
were not directly under our umbrella.

Once your resources are granted under the ISP rules, they remain that
way, even if your ISP business ceases to exist--though, the idea of an
ISP 'ceasing to exist' is a questionable one, since in almost every case,
a successor entity takes over the business, and the number resources
that go with the ISP business follow the customers to the new owner.
See for example the Sprint wireline ISP network being sold to Cogent;
the number resources don't stay with T-mobile, they go with the Sprint
customers currently using them over to Cogent.  If you eventually sell the
colocation business to someone else, you'll have to wrestle with how the
number resources are to be handled.  As such, I would strongly recommend
you allocate your number resources accordingly; if you think the ISP
business
may continue to grow, it may be worth registering 2 different ORG-IDs, one
for your (end-user-like) corporate network, and a separate one for the
(isp-like)
colocation business, so that if in the future you decide to divest the ISP
side
of the business, you can do so without having to perform massive surgery
on your network.  Just a thought on saving some potential renumbering
pain down the road.   ^_^;

3.) Is conversion from ISP to End User (and vice versa) possible if
> the nature of an organization's business changes?  Is it necessary?
>

Lisa already answered this; I would note that there's no secret police that
come after you if your business changes form down the road, it's really
your decision if you feel a better set of policies would apply if you were
to
reclassify your business.


> 4.) Is ISP/end-user status recorded in ARIN's database on a per-prefix
> basis, or is it per-organization?  How does one currently determine
> this status from Whois?  I tried to find examples of organizations
> that would typically be seen as end-users, but there were no clues in
> their organizational Whois results, and Whois queries on their
> prefixes all indicate "NetType: Direct Allocation", just like ISPs, as
> opposed to "NetType: Direct Assignment".  This would be consistent
> with a clue I found in the problem statement of Draft Policy
> ARIN-2022-12, which indicates that "direct assignments are no longer
> being utilized in ARIN databases", but does this then imply that the
> ISP/end-user distinction has been eliminated entirely?
>

Functionally, the distinction is really about checking to see which
policies
your organization falls under when looking at your utilization to see if you
qualify for additional blocks; you should definitely read through
https://www.arin.net/resources/registry/reassignments/
to get a good understanding of the distinction.  So, it's not that a
specific
block is a direct assignment versus a direct allocation, it's that your
ORG-ID falls under utilization requirements for ISPs versus end users;
and because that can change all at once if you request a reclassification
of your organization, trying to identify block-by-block which rules they
fall
under becomes a nearly pointless exercise.


> 5.) Now that ISPs and end-users share the same fee schedule and voting
> privileges, what distinctions remain, other than differences in
> allocation rules and the obligation for ISPs to register
> reassignments/reallocations?
>

As noted in the URL above, even end users aren't immune to the requirement
to track assignment of number resources.  As an ISP, you can punt the
tracking requirement for the number resources to your downstream customer,
or do it yourself; as an end-user, there's nobody else to punt the tracking
to,
it's all in your hands.  But either way, the number resources have to be
tracked,
either through your own Rwhois server, or through the SWIP system.

* It can be assumed for the above questions that our organization type
> (whether ISP or end-user) will not impact the size of the IPv6 prefix
> that we qualify for and request, which we anticipate being /40.  In
> the hypothetical scenario where we would want 

Re: [arin-ppml] Deceased Companies?

[Matthew Petach]

On Tue, Jul 26, 2022 at 5:28 PM Ronald F. Guilmette 
wrote:

> And as I have said, corporate
> entities of this type, together with natural persons, represent the
> overwhelming
> bulk of all ARIN memberships.
>

Fair enough; we'll limit the discussion to private corporations and natural
persons only.

 Today we're just taking about dead member cleanup, or
> the lack thereof.  (We can come back and argue about whether or not ARIN
> should be collecting beneficial ownership information for non-publicly-
> traded companies some other day.)
>
> All that having been said, it _is_ indeed my opinion that it _is_ ARIN's
> job to
> know at least the identities of all of the legal entities that are its
> members.
> And in general, I believe ARIN _does_ know all of that, except when it
> comes to
> deceased entities, where it appear to be blind as a bat.
>

If the corporation closes its doors (is deceased, so to speak), files for
dissolution,
and stops paying its bills, the number resources will be reclaimed; John
has said
so repeatedly.

If the corporation stops doing business, but someone continues to pay the
bills for it on their behalf, I know from experience that ARIN will
continue to
preserve the number resource registrations associated with the entity.

If it's a natural person who held the number resources that passes away,
the estate goes into probate, and if a beneficiary takes over payment of
the ARIN bills, it's unclear how ARIN would ever know the natural person
passed away, as there's no requirement that the next-of-kin furnish a
death certificate to ARIN, or even notify them of the original registrant's
decease.



> >Similarly, when GlobalCrossing was bought by Level3, there was no
> >sudden requirement that every record within ARIN that used to say
> >"GlobalCrossing" now say "Level3" (I mean Qwest) (no wait, I mean
> >CenturyLink) (shoot, no, now I mean Lumen).
>
> Maybe there should be.  Do you have something against Truth in Advertising
> when it comes to public-facing WHOIS records?
>
> (Note: I think that you may possibly be overlooking the possibility that
> just
> because Level3 got acquired by some other legal entity, that DOES NOT
> automatically imply that the legal entity known as Level3, Inc. has itself
> necessarily ceased to exist.  It may still exits and may still be using
> the same resources as it has in the past, all while simply having different
> ownership.)
>
> >Nowhere does the NRPM say that ARINs records must change
> >when the name or owner of a company changes.
>
> Right.  That's what I said.  And thus, because of that obvious hole in the
> rules, I asked John how anybody outside of ARIN could reliably and
> independently
> check to see that ARIN is actually doing what John claims it is doing, i.e.
> cleaning up the leftovers of dead companies and making sure that those
> remnant
> resources get properly assigned to the new legal heirs of the old (and now
> dead)
> company, if any, or properly recycled otherwise.
>


It's the same as the GlobalCrossing/Level3 etc. situation.

We don't know if the old companies still exist as legal entities or not;
it's up to the registrant to update their information as they deem
appropriate.

As long as someone is still paying the bills, we don't know if it's
the same old company under new ownership, or if all the records
were migrated to the new company, and someone just failed to
update the registry appropriately.




>
> >(You can verify this for yourself by searching through ARIN whois
> >records for "global crossing", "Level 3", etc. to see that there has
> >been no requirement that records be immediately updated to show
> >that ownership and control has changed.)
>
> Not only is there apparently no requirement for the WHOIS records to be
> properly updated "immediately" but apparently there is no requirement for
> the WHOIS records to be corrected/updated *ever*.
>
> You may think that's just swell.  I do not.  But in any case, for me this
> also is somewhat of a side-issue at the moment.  My first order concern is
> to
> find out if ARIN really and truly is committed to cleaning up the remnants
> of old, dead and defunct companies and persons that were formerly members
> but that are now "pushing up daisies" as it were.
>
> It is still not 100% clear to me that ARIN is doing that, even in cases
> where the now-dead members are (to use John's words) "brought to the
> attention of ARIN".  ARIN may be doing it, or then again, maybe not.  It
> appears that, as with so many ARIN things, there may be no way for an
> "outsider"
> to know if they are doing it or not.  And even if they are doing it, they
> may perhaps be doing it on a geological time scale, which for me at least,
> would be rather unsatisfying.
>

Again, though, how do you know a company is defunct,
versus dormant, versus under new ownership?

If I had a california company, but decide I don't want to deal with
california business taxes, and I close down the california 

Re: [arin-ppml] Deceased Companies?

[Matthew Petach]

On Tue, Jul 26, 2022 at 2:23 PM Ronald F. Guilmette 
wrote:

>
> To put it another way, if a former and now-defunct ARIN member falls in
> the forrest,
> and if there is no requirement to make any changes in the associated
> public-facing
> WHOIS record(s) after the dead company's membership and resources are
> reassigned to
> some successor entity, then how would anyone outside of ARIN even know
> that any actual
> reassignment had taken place?
>

Ron,

Why would ARIN be the place to track changes of ownership of corporate
entities?

If Elon Musk, for example, were to buy Twitter for $44B, would anyone at
all expect
ARIN records to reflect the change in ownership?

Sure, you can look to SEC records to see the change in ownership; it's not
a
secret; but it's not something that's on ARIN's head to track.

Similarly, when GlobalCrossing was bought by Level3, there was no
sudden requirement that every record within ARIN that used to say
"GlobalCrossing" now say "Level3" (I mean Qwest) (no wait, I mean
CenturyLink) (shoot, no, now I mean Lumen).

Nowhere does the NRPM say that ARINs records must change
when the name or owner of a company changes.  It does require
that POCs be current and updated, and if the previous owner of
an entity is no longer the right POC, I would expect to see an updated
set of POCs for the entity after the change of ownership, but that
would be the extent to which ARIN's publicly visible records would
need to change.

(You can verify this for yourself by searching through ARIN whois
records for "global crossing", "Level 3", etc. to see that there has
been no requirement that records be immediately updated to show
that ownership and control has changed.)

Matt
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] ARIN Guidelines, regarding use in ARIN region, curious question

[Matthew Petach]

On Tue, Jul 26, 2022 at 9:46 AM Michael Peddemors 
wrote:

> Noticing more cases of IP Assignments for a 'company' with a North
> American presence, that simply reassigns/reallocates portions of their
> IP assignments to offshore and foreign companies with no North American
> presence at all..
>
> How does the intent of ARIN guidelines apply, when a 'shell' company is
> formed to provide IP ranges for companies outside of the ARIN region?
>
> Just curious..
>

I'm not a lawyer, I'm not an ARIN staff member, so take everything
I write with less than a grain of salt--but with that said:

I think it's important to understand that ARIN requirements generally
aren't transitive.

That is, a requirement in the NRPM that the entity requesting number
resources
have "a real and substantial connection with the ARIN region" does not in
any
way require the *customers* of that entity also have a real and substantial
connection with the ARIN region.

If I form a company, 'X', and build a network predominantly in the ARIN
region,
fulfilling the requirement that 'X' has "a real and substantial connection
with the
ARIN region", and get number resources based on that; but all of my
customers
end up being mostly outside the region, connecting to one of my edge sites
outside
the ARIN region, no fraud has been perpetrated, because the letter of the
NRPM
has been met.

Now, if the initial company is a "shell" company in the literal sense,
in that it has nothing more than a corporate PO box in the ARIN
region, and no tangible assets (no routers, no network, no servers,
etc.), then yes, there's a case to be made that fraud has been
perpetrated.

However, if the original company *does* have a network within the
ARIN region, and appropriately justified its number resources based
on that infrastructure, even if all of their subsequent customers lie
outside the region, according to the current wording of the NRPM,
no fraud has occurred.

You could try proposing a change to the NRPM that would require
ARIN member entities to ensure all their downstream customers
*also* have "a real and substantial connection with the ARIN region",
but I doubt you'll find much support for that, as it would greatly
increase the up-front cost of vetting customers with no corresponding
increase in revenue to support it.

Thanks!

Matt
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Deceased Companies?

[Matthew Petach]

Oy vey.

We've had this discussion before.

You can't lay a property claim to a number.

Google can't "buy" the number googol, and charge people a license fee to
use it
every time they count that high.

I can't "own" the number "pi" and charge everyone who tries to make a
circle
using it a licensing fee.

I don't "own" my telephone number, and can't sue phone spammers for
spoofing
it when they robocall other people.

IP addresses are just binary numbers.   That's it.

You can't own numbers.

All those networks that ran out of RFC 1918 space and were squatting on
government
blocks?  Not guilty of theft, because the addresses aren't property:
https://www.arin.net/blog/2015/11/23/to-squat-or-not-to-squat/

I know I've configured number resources in my internal networks
that didn't belong to me, and no IP police came busting down my
door.

What matters isn't the IP number resources, it's the agreement
among the community that there will be a coordinated and accepted
injection of those number resources into the global routing table.

Using someone else's IP space internally doesn't matter one whit.

What *does* matter is when you start injecting entries into the global
routing table that go against what the database of record says should
be there.

And that's why John is so explicit that what ARIN is keeping updated
is the single source of truth for what the community has agreed belongs
in the routing table.

But if I configure your number resources internally in my network, good
luck finding any judge that will rule that I have somehow stolen your
property by configuring a binary number in my network devices.

Number resources are just integers, and nobody can lay claim of
property ownership on an integer.

End of story.

Matt


On Mon, Jul 25, 2022 at 12:20 PM Paul E McNary via ARIN-PPML <
arin-ppml@arin.net> wrote:

> That is why I always say John uses "Inside The Beltway" Non-Responsive
> language.
> He just stated to me that number resources are probate-able.
> That means something that has value to the estate or heirs.
> Normally property. Legacy resources were issued without contract.
> So contract law is not valid and it would be over 25 years old.
> So property law should attach.
> I think I hear John saying that, but I need an interpreter/lawyer for
> anything John says.
> You asked him a specific question with a non-responsive answer as I always
> get from him.
>
> - Original Message -
> From: "William Herrin" 
> To: "pmcnary" 
> Cc: "Fernando Frediani" , "arin-ppml" <
> arin-ppml@arin.net>
> Sent: Monday, July 25, 2022 2:12:39 PM
> Subject: Re: [arin-ppml] Deceased Companies?
>
> On Mon, Jul 25, 2022 at 11:18 AM Paul E McNary 
> wrote:
> > Then why the threat?
>
> Hi Paul,
>
> In my opinion? ARIN has a legal house of cards built on the premise
> that there are no property rights in IP addresses. It's "true" until a
> court says otherwise so they want to give the court as few reasons as
> possible to say otherwise. Like any legal threat, the idea is to keep
> the matter out of court be gaining compliance.
>
> Regards,
> Bill Herrin
>
>
> --
> For hire. https://bill.herrin.us/resume/
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Reclamation of Number Resources

[Matthew Petach]

On Sat, Jul 16, 2022, 04:31 Ronald F. Guilmette 
wrote:

> In message  mmkdnponcu0yfn3d2mlvygzq2tfevobzgsr4pb...@mail.gmail.com>
>  Matthew Petach  wrote:
>
> >But if no fault is found, I don't think it's appropriate to have to
> >release documents or records that were used to demonstrate
> >innocence...
>
> I agree 100% with that when it comes to anything that could reasonably be
> construed as "trade secret" or "proprietary" or "business confidential".
>
> As I have stated at some length, I *do not* agree with that when it comes
> to identifying the name, location and other contact details about the
> business (and/or the natural person) that is the member, and when it comes
> to identifying the names and full contact information of any and all
> officers, directors, shareholders, and/or legal representatives of any
> given member that are known to ARIN.  All of that information for *all*
> members should *already* be out on the table, and public, totally
> independent
> of any cases of "fishy facts".
>


Shareholders?Seriously?

*facepalm*

That's never going to work.
How would you even begin to identify all million-plus shareholders of
Facebook?

For public corporations, the named officer information is public, but not
*all* officers and directors.

I mean, this is ppml, so you can propose a policy change to require ARIN to
collect and publish this information, but I'm pretty sure you'll find
there's no support for such an effort among the members, many of whom would
be unhappy to have all that information being published by ARIN.

You generally do good work, Ronald--but I don't think you thought this one
through very carefully first.  ^_^;;

Thanks!

Matt


>
> Regards,
> rfg
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Reclamation of Number Resources

[Matthew Petach]

On Thu, Jul 14, 2022 at 3:29 PM Paul E McNary via ARIN-PPML <
arin-ppml@arin.net> wrote:

> John
> You keep using the word fraud.
> This is not an issue of fraud by my understanding but ARIN POLICY.
> Please correct your misuse of your language. PLEASE
>

Oy vey.

It almost seems like people don't know how ARIN works.  :(

Look, let's talk in plain and simple language.

When you apply for number resources, you're doing so based on your
current *and forecasted* needs for up to two years in the future. [0]

When ARIN staff reviews your submission, they're looking at your
*plans* for the future to evaluate whether those plans fit with the
NRPM requirements.

They cannot see into the future.

If you say "In the next two years, I plan to have a backbone spanning
much of the continental US radiating out from my headquarters in Nevis",
how would you propose ARIN POLICY (your capitalization) be changed
to allow ARIN staff to effectively evaluate your future plans?

All they can do is verify past utilization, and accept that your
attestation
of future plans is what you indeed intend to do and is in line with the
number resource request that was made.

If you want to make number resource allocations be based *solely* on
past utilization that can be verified, how on earth is any new company
supposed to come into existence, with no past to be verified?  All they
have are projections for the future.  That's all any of us had when we
got started--great big plans for the future.   Would any of us ever have
been able to get started and grow, if ARIN staff had simply said "sorry,
you don't have a proven track record, so no ASN or IP addresses for you."

If number resources are being granted based on *future* needs and
projections, there is nothing that can be changed about how ARIN staff
respond to requests, because they have no special, magic view into
the future.  None of us do.

If you don't like ARIN POLICY (to use your capitalization again), then
propose a change to the NRPM.

If you think someone has done something bad, file a fraud report.

If you think ARIN staff should be magically able to peer into the future
to figure out if companies are lying about what they plan to do in the
future, you need to get your head out of the comic books, and back
into reality.  We all have optimistic plans for the future.  Not all of
them
turn out the way we expect.  That doesn't make us criminals, and
punishing networks for not being able to predict the future accurately
would be collectively shooting our foot to spite our face.  :(

Thanks!

Matt

[0] see sections
4.2.4.3. Request Size

ISPs may request up to a 24-month supply of IPv4 addresses.

and
4.3.3. Utilization Rate

Organizations may qualify for a larger initial allocation by providing
appropriate details to verify their 24-month growth projection.

The basic criterion that must be met is a 50% utilization rate within 24
months.
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Reclamation of Number Resources

[Matthew Petach]

On Thu, Jul 14, 2022 at 2:35 PM William Herrin  wrote:

> On Thu, Jul 14, 2022 at 2:18 PM Matthew Petach 
> wrote:
> > Note that if there's actual indications of wrongdoing, we already
> > have a means to file a complaint with ARIN, as John has repeatedly
> > pointed out.
>
> Hi Matthew,
>
> I think maybe you missed my point. We don't know how ARIN would treat
> Ronald's information if filed in a formal complaint and can't
> rationally discuss whether that enforcement is consistent with our
> policy-level expectations because ARIN doesn't publish enough details
> about the complaints, their investigations and the results. There
> ought to be a way to open that black box without unduly harming the
> folks who get investigated. Like making it all public upon the
> investigation's conclusion when all the information is on the table.
> Upon finding the complaint unsubstantiated, ARIN could even offer the
> registrant the opportunity to redact anything they considered a trade
> secret before publication. We'd still end up with a heck of a lot more
> information and quite possibly enough information to inform a policy
> discussion.
>
> Regards,
> Bill Herrin
>

Hi Bill,

I think it's reasonable for any positive finding of fault that the
publicly-revealable information about the fault-finding be
made available.

But if no fault is found, I don't think it's appropriate to have to
release documents or records that were used to demonstrate
innocence unless those documents or records had already
previously been made public.  I think it's sufficient for ARIN
to say that the accusation was found to be without merit, and
leave it at that.

Otherwise we're again punishing the innocent victim by forcing
them to dig through the material used and specifically redact
the material before it is released.

How many of us have staff people we can spare to go through
hundreds or thousands of pages of documents to redact material
that was provided to ARIN in confidence before it gets published
to the world?

How many of us would have to take the time to circumscribe or
anonymize network diagrams and internal network allocation
documents before we submitted them to ARIN if we now had
to worry that they might be published to the world based on
someone's unmerited accusation?

When I was submitting resource requests to ARIN, we provided
information at a detail we would never release to the public,
with the understanding it would be seen by ARIN staff only, or
law enforcement if ARIN were to be so compelled.

Would you want your internal network allocations to be made
public, simply because I lodged a frivolous claim of fraudulent
resource allocation against you?  Would you want your network
topology diagrams to be published to the world, just so that everyone
could be satisfied that you really did need the address space in the
areas you had requested, including your future expansion plans for
the next two years?  I'm sure your competitors would be very happy
to see what markets you were planning to expand into ahead of time.

No, we submitted that information to ARIN with the understanding that
it was for ARIN staff eyes only, to evaluate our number resource needs
now and in the near future--not to have it revealed to the world just
so that someone could satisfy themselves that we had committed
no wrong.

Matt
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Reclamation of Number Resources

[Matthew Petach]

On Thu, Jul 14, 2022 at 2:17 PM Matthew Petach 
wrote:

> On Thu, Jul 14, 2022 at 1:14 PM William Herrin  wrote:
>
>>
>>
> "I cannot, in all honesty and good conscience, report something as
>   "fraud" where the set of pertinent facts, as I have elaborated them,
>   *do not* suggest that there has been any fraud, deceit, or
>   misrepresentation of any kind, at least not on the part of the member
>   organization in question."
>
> So, he cannot accuse the specific network in question of committing
> fraud, for there is proof.
>

*sigh*

That should have been "for there is NO proof."

Apologies for not catching that before hitting send.
Hopefully I can forestall the flood of "but that's not what
he said" replies.   ^_^;

Sorry about that!

Matt
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Reclamation of Number Resources

[Matthew Petach]

On Thu, Jul 14, 2022 at 1:14 PM William Herrin  wrote:

> On Thu, Jul 14, 2022 at 12:59 PM Matthew Petach  wrote:
> > On Thu, Jul 14, 2022 at 12:47, William Herrin
> >  wrote:
> > You understand that's not how jurisprudence generally works, right?
> > Court cases and filings are almost always open to the public.
> >
> > But we don't proceed to bring cases to court until enough evidence has
> been gathered to satisfy a reasonable cause for doing so, and we have
> penalties for lawyers who attempt to bring frivolous cases to court.
>
> What have you got to hide? ;)
>

Ha!

I'm sure we've all learned from Eric Schmidt's faux pas with respect to
that notion.   ^_^;


> Seriously though, we file civil cases on reasonable, good faith belief
> and make arrests on probable cause, all of it publicly reported. There
> is a bar but it's not a high bar nor should it be. And we don't
> generally penalize lawyers unless they act in actual bad faith.
>

But the bar for probable cause is considerably higher than
"But Ronald couldn't find proof they were following the law"

Note that if there's actual indications of wrongdoing, we already
have a means to file a complaint with ARIN, as John has repeatedly
pointed out.

What Ronald is doing is accusing ARIN of *not* going after people
he suspects aren't following the law, without submitting any actual
evidence to support the accusation.

This is McCarthyism resurrected.

" “I have here in my hand a list of 205 [State Department employees] that
were known to the Secretary of State as being members of the Communist
Party and who nevertheless are still working and shaping the policy of the
State Department.”

We should not stoop to witch hunt allegations without any supporting
evidence being offered.  Ronald indicated he couldn't find evidence of
fraud, and thus wasn't willing to file a fraud report.  He simply said he
couldn't find evidence that the accused networks and individuals *weren't*
committing fraud, and that it was up to ARIN to demonstrate they weren't
complicit in covering up for the entity.  In essence, he's demanding that
ARIN show the world how they go about determining that every company
that has ever applied for number resources is *not guilty* of fraud.

We should *never* put the burden of proving innocence on the victim.

The burden of proof of guilt should be on the accuser's side to produce.

When accusations of fraud are submitted, yes, it's worthy and reasonable
for ARIN to report on the outcome.

But for Ronald to demand that ARIN reveal the details of how ARIN went
about deciding that every company that ever applied for number resources
was *NOT* breaking the law is a witch hunt.  It is a demand to produce
proof
of innocence rather than acting on accusation of guilt with evidence to
back
up the assertion.

Just as it is not the job of the police to check on what each and every one
of
us is doing in our households to make sure we're innocent of all crime, it
is not
ARIN's job to ensure every company that ever applied for number resources
is completely innocent of all crime.  If there is an accusation of fraud,
they should
act on it and investigate it thoroughly.  But absent that, if no evidence
of fraudulent
behaviour is reported, it should not be incumbent on ARIN staff to justify
why they
have not taken action against every company that ever submitted a request
to
them.

I for one do not wish to turn the ARIN region into that level of
totalitarian regime.

When Ronald finds evidence of fraud, he should report it, and ARIN should
investigate it, and report accordingly if fraud is found.

But to fire broad-based accusations against the ARIN membership and against
ARIN staff without proof is a bridge too far:

"  *)  How many more memberships are currently sitting on ARIN's books that,
  as in this case, obviously should never have been there, and what
  effort, if any, will ARIN now expend to find them and to terminate
  the memberships involved?"

If it's obvious (ie, there is proof of fraud), then why is Ronald unwilling
to
file a complaint against the networks in question?

He himself admits he can find no evidence of fraud:

"I cannot, in all honesty and good conscience, report something as
  "fraud" where the set of pertinent facts, as I have elaborated them,
  *do not* suggest that there has been any fraud, deceit, or
  misrepresentation of any kind, at least not on the part of the member
  organization in question."

So, he cannot accuse the specific network in question of committing
fraud, for there is proof.

But he is willing to accuse ARIN staff of not finding the very proof he
himself has been unable to find.

If there is clear evidence of fraud that ARIN is overlooking, and that
evidence can be produced, I might have some sympathy for what Ronald
is demanding.

But to simply claim that ARIN staff ar

Re: [arin-ppml] re-org question

[Matthew Petach]

On Fri, Nov 4, 2016 at 7:55 PM, Owen DeLong  wrote:
> You can return as small as a /24.
>
> If you’re using half, then you can keep it.
>
> So, at most, you have to renumber 126 hosts out of each of half of your /25s.
>
> How is this not minimal again?
>
> Owen


I suspect Owen is trolling for effect here.

Renumbering 126 hosts out of 255 is only
slightly less than half.

I'm guessing Owen would be unhappy, were he to be
told by his doctor that he needed a surgical operation
in which a minimal amount of his body mass would be
removed; but upon delving deeper, found that the
doctor would be removing slightly less than half his
body.

Using the term "minimal" to apply to renumbering
nearly half a block strays well past the realm of
'stretching the definition' into the neighborhood of
'trolling'.

If the community does indeed think the language
should stay, and that renumbering should be required,
we should perhaps put some clarity around what is
expected.  If an organization is using 40% of each /24,
would the ARIN community be happy if the organization
renumbered such that alternating /24s were now 80%
filled, and returned every other /24 to ARIN, as individual
/24 subnets?  That would meet the letter of the law, so
to speak, but would ensure those blocks could never
be aggregated into a larger allocation.  (As a side note,
this could be a good way to ensure a steady supply of /24s
for small entrants, while ensuring no larger entity can ever
make use of them.)

For the record, I think the sentence is confusing, and
should have the "will" replaced with "may", to read as
follows:

"ARIN will proceed with processing transfer requests even if the
number resources of the combined organizations exceed what
can be justified under current ARIN policy.  In that event, ARIN *may* work
with the resource holder(s) to transfer the extra number resources to
other organization(s) or accept a voluntary return of the extra number
resources to ARIN."

emphasis on *may* included only to make it clear which word
was changed; emphasis need not stay in the resulting NRPM
text.  That should clear up confusion about it being a requirement,
and instead make it clear this is an optional exercise.

Thanks!

Matt
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Recommended Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments

[Matthew Petach]

On Fri, Jun 26, 2015 at 3:22 PM, William Herrin  wrote:

>
> Maybe there's a third way we're not seeing, like retiring e, adding
> the new element as f, and then re-inserting the catchall some other
> way, point g or as a sentence that follows the ordered list.

Oooh, I like that--remove the catch-all from the
ordered list, and make it a separate sentence
after the list:

"Finally, an organization may also qualify by
providing a reasonable technical justification
indicating why IPv6 addresses from an ISP
or other LIR are unsuitable."

I'd support this proposal with the catch-all
moved to a separate sentence after the
list, and the list item lettering being kept
consistent before and after the change
for all other list items.

Matt

>
> Regards,
> Bill
>
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks

[Matthew Petach]

I am OPPOSED to the proposal as written;
I think it's a bridge too far.  I would instead
support a compromise as has been discussed
of a total of one /22 per year per org-ID transferrable
needs-free; I would recommend the hold period
be two years from transfer date (ie, you may not
transfer that block of addresses again for 24
months so long as you remain a solvent
business entity; if you become insolvent,
ARIN can arm wrestle with the court over
control of the number resource).  Any
transfer larger than a /22 would still be
subject to need analysis.

Matt


On Thu, Sep 24, 2015 at 6:20 PM, Dani Roisman  wrote:
> | Date: Wed, 23 Sep 2015 16:53:59 -0400
> | From: ARIN 
> | To: arin-ppml@arin.net
> | Subject: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based
> |   evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks
> | Message-ID: <56031167.1010...@arin.net>
> | Content-Type: text/plain; charset=utf-8; format=flowed
> |
> | Draft Policy ARIN-2015-9
> | Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4
> | transfers of IPv4 netblocks
> |
> | On 17 September 2015 the ARIN Advisory Council (AC) accepted
> | "ARIN-prop-223 Eliminating needs-based evaluation for Section 8.2, 8.3,
> | and 8.4 transfers of IPv4 netblocks" as a Draft Policy.
> |
> | Draft Policy ARIN-2015-9 is below and can be found at:
> | https://www.arin.net/policy/proposals/2015_9.html
>
> Greetings,
>
> There has been some stimulating dialog about the merits of 2015-9.  I'd like 
> to ask that in addition to any overall support or lack thereof, you also 
> review the policy language and comment specifically on the changes proposed:
> a) For those of you generally in support of this effort, are there any 
> refinements to the changes made which you think will improve this should 
> these policy changes be implemented?
> b) For those of you generally opposed to this effort, are there any 
> adjustments to the policy changes which, if implemented, would gain your 
> support?
>
> --
> Dani Roisman
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] What the heck is OIX? (was RE: Draft Policy ARIN-2014-21: Modification to CI Pool Size per Section 4.4)

[Matthew Petach]

Keith--it's a way to cite support from 3rd-party
elements that aren't presented here, allowing
one to claim support without the rest of the
community having an easy way to debate
or disagree with that support.  Somewhat
along the same lines as Steve's appeal
to the sentiments of the unvoiced masses
of small businesses.

Not that I'm disparaging the work Open-IX
does; it's a wonderful organization.  But to
cite support from unrelated mailing lists
seems akin to saying but all my friends
on Facebook say I should be given a /8
without justification.  It may in fact be true
that all your friends on facebook say that;
but is it relevant, and should it carry any
weight in the debates here?  That's much
harder to pin down.

Putting it the other way around...would the
nice people on Open-IX change their rules
based on the comments that are made here?
Or would they be dismissed as not germane
to the decision?  For better or for worse, I think
there's a strong current of if they want their
voice to matter, they can come here and say
it where the rest of us are present in just about
every purpose-specific mailing list.

If one were to create a mailing list of concerned
small businesses advocating the propagation of
the internet, and on that mailing list, there was
unequivocal support for a flat IPv4 allocation
scheme; every org-ID gets a /16, regardless
of need (no matter how big or how small the
org), and all other space shall immediately
be reclaimed and redistributed to the rest
of the entities in the region--why, I dare say
we'd be quick to dismiss that mailing list
archive as not relevant, and not sufficient
evidence of community support to warrant
reclaiming massive amounts of IP space
from existing registrants.

In short (well, no, not really--I don't really seem
to do brevity well at all)--I think we need to be
very careful of accepting 3rd party support as
anything other than hearsay, and accord it the
same status as hallway conversations at
ARIN meetings; while they're nice to have,
and can help guide the shepherds in adjusting
wording of proposals, I don't think they should
carry any weight in the voting and decision
process.

Thanks!

Matt




On Fri, Dec 26, 2014 at 5:21 AM, Keith W. Hare ke...@jcc.com wrote:

 Martin,



 So, what the heck is OIX, and why do I care about discussions there?



 A quick web search for OIX gives me:



 · Open Identify Exchange

 · Online Incentives Exchange

 · Open Identity Exchange UK

 · Open-IX Association

 · Etc.



 The Urban Dictionary defines Oix as “Officially a word you are allowed to
 use in scrabble when you are out of letters at the very end and this is all
 you have left.”



 From what I know about OIX without diving into random web pages, this
 definition seems the most appropriate.



 Keith



 *From:* arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] *On
 Behalf Of *Martin Hannigan
 *Sent:* Thursday, December 25, 2014 7:27 PM
 *To:* Owen DeLong; David Farmer; Scott Leibrand
 *Cc:* arin-ppml@arin.net
 *Subject:* Re: [arin-ppml] Draft Policy ARIN-2014-21: Modification to CI
 Pool Size per Section 4.4





 I'll point this list at a public viewable URL to a proper thread there.
 Not sure why people need to actually subscribe, either way. I also can't
 force (and won't advocate) people to waste their time like that on either
 list.



  There are AC members there. They too can report their observations back
 to the Politburo. I'm sure you'll be well informed.



 Best,



 -M






 On Dec 25, 2014, at 18:53, Owen DeLong o...@delong.com wrote:

 I’m not part of the OIX discussions, so I certainly won’t be considering
 anything from OIX that isn’t posted to PPML in any of my deliberations on
 policy.



 Owen



 On Dec 23, 2014, at 20:22 , Scott Leibrand scottleibr...@gmail.com
 wrote:



 For future comments from OIX participants, it will also be helpful to
 include PPML, so any discussion of policy pros and cons can occur directly,
 and there isn't any further unnecessary back and forth (and potentially
 delays) due to inconsistent assumptions. (I saw a fair bit of that watching
 the two independent discussions so far.)

 -Scott

 On Tue, Dec 23, 2014 at 1:22 PM David Farmer far...@umn.edu wrote:

 On 12/23/14, 17:08 , Martin Hannigan wrote:
  On Tue, Dec 23, 2014 at 5:57 PM, David Farmer far...@umn.edu
  mailto:far...@umn.edu wrote:
 ...
  I went back and reviewed the thread, there was some support for the
  ideas that spawned the proposal, but no specific text was posted at
  that time.  Since the Draft Policy and the specific text was posted
  there has now been two statements of support and no opposition.
 
  Its fair to expect that the OIX commentary, documented in full public
  view, should count as support. That would be more than two.
 ...
  I'd be happy to work toward getting this to San Antonio as a
  Recommended Draft Policy.  However, the normal path would be Draft
 

Re: [arin-ppml] 2014-14, was Internet Fairness

[Matthew Petach]

I oppose the proposed policy as currently drafted.
The notion of a /16 being small is ludicrous.
By the time you need a /16, you have enough
staff to handle tracking your SWIP/rwhois data
for your customers, and justifying needs is just
part and parcel of running your business.

I would support a modified version of the policy
that stipulated a single needs-free transfer of a /22
per year per org-ID as a means to help support truly
small entities getting going.
I would further encourage a cap; such needs-free
transfers would only apply to org-IDs so long as
they remain in the small category based on
overall cumulative holdings.  Once an org-ID
exceeded the total holdings allowed in the small
category, it's time to trade in the diapers for the
big-boy pants, and track your utilization and
show demonstrated need over time.

Thanks!

Matt
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Fwd: [ARIN-20140107-F1419] Fraud Report on CloudRadium LLC

[Matthew Petach]

On Wed, Oct 15, 2014 at 10:03 PM, Owen DeLong o...@delong.com wrote:


 On Oct 14, 2014, at 16:16 , Ted Mittelstaedt t...@ipinc.net wrote:

 We had a situation in my city, the story just broke as a matter of fact,
 last week, about a group of tow truck drivers in cahoots with an
 owner of several wrecking yards who were crushing stolen cars.  A city
 employee was also involved.


 Interesting.

 This had been going on for the last 20 years or so.


 Impressive.

 The story broke a week AFTER the police chief announced his resignation.

 The police department and DMV and other officials involved all tried
 to pull that BS excuse that they had been investigating it all this
 time.  But the paper that broke the story published addition info
 showing that this was a big fat lie, they had only started an
 investigation a year ago.


 So you apparently had an incompetent (or worse) chief of police. Not sure
 what this has
 to do with the current ARIN situation unless you are claiming that the
 ARIN staff is
 similarly corrupt or incompetent (which I don't believe for a second).


I think it's perfectly clear that he's bringing up this
parallel situation to highlight his concern that the
ARIN staff is using our registration fees to CRUSH CARS!

This is an ecological travesty of the highest magnitude;
if ARIN staff members are misusing our registration fees
in this way, they must be stopped!  We must immediately
formulate policy language that stipulates any embezzled
funds must *only* be used to RECYCLE cars, and not
CRUSH them!



OK.  On a more serious note--having been on the other
side of public accusations in the past, there's a lot to
be said for keeping the investigation circumspect, at
least initially.  If the allegations turn out to be false, it
can still be highly damaging to people's reputations to
simply have such allegations made in public.

I think it would be good for ARIN to send a note
back saying thank you for bringing this to our
attention -- but I would not expect to see any
further communication from them one way or
the other while the investigation is underway.

Until true evidence of wrongdoing has been
uncovered, it's one person's word against
another--and in business, the wrong allegations
can drag a company down, even when they
turn out to be unfounded.

Bringing it back to the charter of PPML--would
you like policy to be proposed that guides ARIN
staff on timely replies back to fraudulent behaviour
notifications--as that's really the only reason I
could see for bringing the topic up here, as
opposed to other ARIN governance lists.

Thanks!

Matt
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Micro-allocation policy proposal draft

[Matthew Petach]

On Mon, Sep 22, 2014 at 10:56 AM, Andrew Dul andrew@quark.net wrote:

  Hello,

 At the Chicago meeting there was some discussion around the
 micro-allocation policy (section 4.4) of the NRPM.  I committed to the AC
 to produce a draft update to this section based upon feedback that I heard
 from the community.  Below you will find a draft update.

 This has not yet been submitted to the policy process.  I wanted the
 community to validate that they still would like these type of changes to
 be considered before formal work on this section started.



Andrew,

Can you clarify what was voiced at the meeting
in terms of what was broken about 4.4 that
needed fixing?

It's hard to understand the motivation for these
changes without knowing what the problem is
that is trying to be solved.

Thanks!

Matt
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2014-20: Transfer Policy Slow Start and Simplified Needs Verification

[Matthew Petach]

On Thu, Sep 4, 2014 at 8:34 AM, Jason Schiller jschil...@google.com wrote:

 Bill,

 Thank you.

 The intent was NOT to remove the requirement for in-region recipients of
 transfers to sign an RSA.

 My apologies.

...

 Option 2 - single bullet for meet ARIN policy and sign RSA (8.3 as the
 model text)
 - replace the whole 24-month text and meet ARIN policy text in 8.3
 with a bullet that included sign the RSA and meet ARIN policy under one
 bullet and is parallel to text in 8.4 (minus within the ARIN region)


verily I say unto thee, supporteth
option the second I do.

 Does the community and ARIN staff agree that the thee options have the
same policy implications?

this bit of the community agrees with
thee that the thee options have the
same policy implications, aye.

 Recipients will be subject to current ARIN policies and sign an RSA for
the resources being received.

Thumbs up on that text, aye.

Thanks!

Matt
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] ARIN 2014-13

[Matthew Petach]

On Sat, Jul 19, 2014 at 11:04 AM, Steven Ryerse 
srye...@eclipse-networks.com wrote:

 I've said this before, but this proposal might help an Org that only needs
 a /24 but I think it will hurt an Org that needs a /20 or a /22 as the
 needs test that are applied will force them into qualifying for the /24 but
 not the /20 or /22 they legitimately need.


Steve,

I count four uses of the word need in that sentence;
I suspect part of the problem here is that you're using
need in two different ways, while the rest of the list
is thinking of just one use of the word need.

You say
I think it will hurt an Org that needs a /20 or a /22
--ok, we've established their org has a requirement
for a certain size block--to keep it straight, let's
say their use case requires a /22.

You than continue by saying
as the needs test that are applied will force them into qualifying for the
/24
--here's where the confusion starts; you seem to
be saying the needs test will evaluate their stated
requirement, and determine only a /24 is actually
required for their use case.  That is, the evaluation
of the requirements by the Org are different than the
evaluation of the requirements by ARIN.

You then conclude by saying
but not the /20 or /22 they legitimately need.
--here, the use of legitimately need seems to
be designed to try to frame it in opposition to
the need of needs test used in the previous
clause, and seems to focus on reinforcing the
idea that the Org has evaluated their requirements
differently from ARIN.

As humans, we sometimes have a tendency to
think we know best; that when we come up with
an idea, it's somehow the best possible idea, the
best possible way to approach a situation.  And
yet, it's not uncommon to find that others have
in the past come up with similar ideas, with
possibly slightly different solutions, some of
which might actually be more efficient when
viewed objectively.

Part of the drive here from the community is
to help guide organizations into using the most
efficient solutions we have available to us as a
whole.  In the past, people thought that web hosting
meant you needed a different IP address for every
virtual host you ran; I know I configured my early
web farms that way.  But then use of the Host:
header became more widespread, and we slowly
learned we didn't need to allocate huge swaths of
IP space to webservers just to handle multiple
virtual hosts.  We've codified that knowledge into
the allocation guidelines, so that future Orgs that
show up asking for a /22 so that they can run
multiple virtual hosts on their one server can be
gently steered towards how to configure their
servers in a more efficient manner, using less
of a scarce resource.

This doesn't mean the Org coming with the request
for a /22 didn't feel they had a completely legitimate
need, that their installation *required* the full block
of address space.  In their eyes, that was what was
needed, and anyone saying otherwise was trying
to stop them from doing business.  But from an
outside perspective, the Org was attempting to make
use of a less efficient way to run their web farm,
and pushing back on the request with a nudge towards
a more efficient means of serving virtual hosts off
a single IP address would be the only reasonable
response; it would be unethical for the community
to not help guide that Org towards a more efficient
mode of operation.

I've never seen an organization get turned down
for IP space that could clearly document the
basis for their IP address requirements.  I *have*
been turned down myself, in the past, when my
thoughts on what number resources were required
did not follow the best practices for the industry;
and I took the gentle rejection and recommendation
to heart, learned a better way to do virtual hosting,
and came back with an updated request that better
matched what the industry best practices actually
required.

What we're doing here is not trying to stifle new
businesses; what we want to do is make sure that
new businesses understand that there are efficient
ways to use resources, and inefficient ways to use
resources, and as a community, we're trying to steer
those businesses towards using the resources in the
most efficient way we've discovered so far.

So, getting back to your original statement, with its
somewhat confusing 4 uses of the word needs, I
think a clearer statement of  your concern would
have been:

I've said this before, but this proposal might help an Org
that only optimally requires a /24 but I think it will hurt an
Org that thinks their application will require a /20 or a /22,
but the needs test that are applied will recommend a more
efficient solution that only requires a /24, not the /20 or /22
they initially felt would be needed.

If the organization truly has a 'legitimate need', in that
they are already working towards the most efficient
solution the industry is aware of, and have documented
their application of that best practice, I don't think these
proposals 

Re: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks

[Matthew Petach]

On Mon, Jun 30, 2014 at 4:59 PM, Martin Hannigan hanni...@gmail.com wrote:


 Scott,

 Asking me to do the work the AC is supposed to do is like asking a nun to
 certify their virginity.


In the interests of supporting our community, I volunteer to ...

oh, wait.  Wrong question.

I mean I support this proposal.

Matt



 I made my point and I feel zero need to defend what is completely obvious
 and on the record.

 As I explained to our CEO and President, feel free to demonstrate
 otherwise.

 Best,

 Martin



 On Jun 30, 2014, at 19:38, Scott Leibrand scottleibr...@gmail.com wrote:

 Martin,

 I felt the objections raised at previous meetings were addressed, not
 ignored. Can you clarify how you feel that this policy would make it harder
 for a recipient to qualify to receive space via transfer? The intent here
 is to allow organizations to create new discrete networks and qualify for
 space from them. If you think it will do the opposite, it's worth detailing
 how and why.

 It's also worth noting that, by documenting the basic requirements for
 such networks, it also reduces ARIN staff's discretion and provides
 additional policy certainty.

 Scott

 On Jun 30, 2014, at 3:58 PM, Martin  Hannigan hanni...@gmail.com wrote:

 Objection, with the majority of the community from the previous ARIN
 meeting, recent NANOG PPC and other comments and fora discussion.

 But don't let that stop the ARIN AC from moving it forward in its
 obsession with controlling v4 markets.

 Best,

 -M


 On Jun 30, 2014, at 17:34, CJ Aronson c...@daydream.com wrote:

 Hi everyone

 Does anyone have comments on this recommended draft policy?

 Thanks!
 Cathy


 On Tue, Jun 24, 2014 at 2:16 PM, ARIN i...@arin.net wrote:

 The ARIN Advisory Council (AC) met on 19 June 2014 and decided to
 send the following to last call:

   Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New
 Multiple Discrete Networks

 Feedback is encouraged during the last call period. All comments should
 be provided to the Public Policy Mailing List. This last call will
 expire on 8 July 2014. After last call the AC will conduct their
 last call review.

 The draft policy text is below and available at:
 https://www.arin.net/policy/proposals/

 The ARIN Policy Development Process is available at:
 https://www.arin.net/policy/pdp.html

 Regards,

 Communications and Member Services
 American Registry for Internet Numbers (ARIN)


 ## * ##


 Recommended Draft Policy ARIN-2013-8
 Subsequent Allocations for New Multiple Discrete Networks

 Date: 16 May 2014

 AC's assessment of conformance with the Principles of Internet Number
 Resource Policy:

 This proposal enables fair and impartial number resource administration
 by documenting how to get a new block for a new discrete network. Previous
 versions of the policy did have this information and over time it has been
 removed.

 This proposal is technically sound. There is a need for discrete networks
 and an organization should have a policy that would allow it to create a
 new discrete network.

 This proposal is supported by the community. There has been some concern
 about the criterial that will be used and this version has been updated
 with the current thinking on the criteria.

 Policy Statement:

 IPv4:
 Add the following statement to section 4.5.4.
 Upon verification that the organization has shown evidence of deployment
 of the new discrete network site, the new network(s) shall be allocated the
 minimum allocation size under section 4.2.1.5 unless the organization can
 demonstrate additional need using the immediate need criteria (4.2.1.6).

 IPv6:
 Add an additional reference to section 6.11.5.b such that it references
 both the initial allocation and subsequent allocation sections of the IPv6
 LIR policy.
 Each network will be judged against the existing utilization criteria
 specified in 6.5.2 and 6.5.3 as if it were a separate organization...

 Comments:
 a. Timetable for implementation: immediate
 b. This policy is being proposed based upon the Policy Implementation 
 Experience Report from ARIN 32.
 https://www.arin.net/participate/meetings/reports/
 ARIN_32/PDF/thursday/nobile-policy.pdf
 c: Older versions of the MDN policy did contain new network criteria.
 This criteria appears to have been dropped during subsequent rewrites of
 the MDN policy. The organization must not allocate a CIDR block larger
 than the current minimum assignment size of the RIR (currently /20 for
 ARIN) to a new network. (https://www.arin.net/policy/
 archive/nrpm_20041015.pdf)
 ___
 PPML
 You are receiving this message because you are subscribed to
 the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
 Unsubscribe or manage your mailing list subscription at:
 http://lists.arin.net/mailman/listinfo/arin-ppml
 Please contact i...@arin.net if you experience any issues.


 ___
 PPML
 You are receiving this 

Re: [arin-ppml] LAST CALL: Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy

[Matthew Petach]

I support the newly-redlined version of the draft.

Matt


On Tue, Jun 24, 2014 at 2:42 PM, David Farmer far...@umn.edu wrote:

  To help additionally highlight the changes to the Policy Text since the
 15 May 2014 version that the AC recommended; I'm including this HTMLized
 red-lined version of the Last Call Policy Text below.  Only the changes
 since the 15 May 2014 version that the AC recommended are being
 highlighted.  As stated these changes are considered editorial in nature
 and are not intended to change the intent or meaning of the policy, only
 clarify the original intent. The red text has been added and red text with
 a strike-through has been deleted.

 ---
 11.7 Resource Allocation Guidelines

 The Numbering Resources requested come from the global Internet Resource
 space, do not overlap currently assigned space, and are not from private or
 other non-routable Internet Resource space. The allocation size should
 shall be consistent with the existing ARIN minimum allocation sizes,
 unless smaller allocations are intended to be explicitly part of the
 experiment. If an organization requires more resources than stipulated by
 the minimum allocation sizes in force at the time of their its request, their
 experimental documentation should have the request must clearly described
 and justified justify why this a larger allocation is required.

 All research allocations must be registered publicly in whois. Each
 research allocation will be designated as a research allocation with a
 comment indicating when the allocation will end.
 ---

 If you are not using a HTML compatible email client then please refer to
 the clean text included in the original Last Call email, it will be
 difficult to interpret the above text without a HTML compatible email
 client.

 Thanks.

 --
 
 David Farmer   Email: far...@umn.edu
 Office of Information Technology
 University of Minnesota
 2218 University Ave SE Phone: 1-612-626-0815
 Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
 


 ___
 PPML
 You are receiving this message because you are subscribed to
 the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
 Unsubscribe or manage your mailing list subscription at:
 http://lists.arin.net/mailman/listinfo/arin-ppml
 Please contact i...@arin.net if you experience any issues.

___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] About needs basis in 8.3 transfers

[Matthew Petach]

On Tue, Jun 3, 2014 at 12:31 PM, David Huberman 
david.huber...@microsoft.com wrote:

  We had a discussion today at NANOG in the ARIN PPC about needs-basis in
 8.3 transfers.



 I’d like to state the following, and then let’s see where the discussion
 takes us:



 My team runs an AS. And yep, we’re a pretty big company.  We rely on IPv4
 today for most of our numbering, and will continue to do so for the next
 couple of years.[1]  In the coming year, when we can’t get space from ARIN
 or other RIRs, we have to turn to the market for our IP address needs.   We
 may choose to buy more than a 2 year supply, because it may make business
 sense for us to do so.   ARIN policy, however, only allows us to take the
 IP addresses we buy and transfer the portion which represents a 2 year
 need.   The rest will remain in the name of whoever sold the IP addresses
 to us.



 Why is this result good for the operator community?  Wouldn’t it be better
 if ARIN rules allowed us to transfer into our name all the IP addresses
 which we now own?



 Regards,

 /david



 [1] We’re working on increasing IPv6 presence in our network and our
 products, but large corporations move slowly ;)


See, this is why I support maintaining the
needs-based decisionmaking around number
allocations.

Because it's far too easy for a really big company
with a couple of billion dollars in the bank to decide
that IPv6 is just too hard, and it's easier to buy up
large blocks of IPv4 space, and keep their critical
resources on v4 addresses--which, if those resources
are crucial enough, could artificially drive up demand
for IPv4.

As a purely hypothetical exercise, let's consider
the three major smartphone OS vendors; each
of them have over $100B in assets in the bank
at the moment; and each of them have a relative
lock on the mobile phone OS for a given set of
handset hardware.  If they each decided that
IPv6 was too hard, and they could get enough
IPv4 space on the unrestricted market (remember,
with over $100B each in assets, at $12/IP, each
of them could in theory be able to afford every
remaining IP address on the planet, with cash
left over).  If they kept their software update
servers on IPv4, they'd have a lock on over
a *billion* endpoints[1] that they would force a
requirement for IPv4 onto.  That would
generate an ongoing demand for IPv4
resources which they would have an
ironfisted control over.  Any mobile carrier
that wanted to provide service for a
smartphone would have to ensure the
phone could reach the IPv4-only software
update servers.

Yes, this is a bit of hyperbole; I'm not expecting
the big three smartphone OS vendors to go out
and buy up all the IPv4 space remaining, just to
have absolute control over the global portable
communications infrastructure.  But the numbers
do indicate that would be a not-infeasible scenario.

Even Apple alone, with their assets in the bank,
could afford to buy up every remaining IPv4
address at current market prices; requiring just
ios devices alone to speak IPv4 to get software
updates would force pretty much every major
mobile carrier in the world to have to maintain
IPv4 infrastructure for the foreseeable future,
and could potentially put them into a situation
where they would have to lease IPv4 addresses
for their handsets from Apple, in order to be
able to provision their own customers.

The ability for one entity to control both ends
of the connection; at the client device, and on the
server side, and with enough cash and assets
to create a monopoly on the means by which
those two endpoints communicate...see, that's
why I will continue to vote in favour of needs-based
justification for resources; because the temptation
to have that level of absolute control over a
resource is too risky to leave without some level
of community input as well.

Thanks!

Matt
(being paranoid, yes--but also recognizing
that greed can drive anti-social behaviours)
P.S. Apologies to Apple--I used you simply as an example
to highlight that in responding to David, I did not mean to
imply in any way that my concern was only about Microsoft;
any of the dominant smartphone OS vendors has the same
level of capability at this point in time.

[1]
http://www.bloomberg.com/news/2012-10-17/smartphones-in-use-surpass-1-billion-will-double-by-2015.html
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] About needs basis in 8.3 transfers

[Matthew Petach]

On Wed, Jun 11, 2014 at 7:59 AM, Mike Burns m...@iptrading.com wrote:

Hi Matt,

  I put my comments below your signature.

  Regards,
  Mike


  See, this is why I support maintaining the
 needs-based decisionmaking around number
 allocations.

 Because it's far too easy for a really big company
 with a couple of billion dollars in the bank to decide
 that IPv6 is just too hard, and it's easier to buy up
   large blocks of IPv4 space, and keep their critical
 resources on v4 addresses--which, if those resources
 are crucial enough, could artificially drive up demand
 for IPv4.

 Matt

 Hi Matthew,

 It would be simple to see that somebody is buying up IPv4 addresses and
 the price would rise accordingly, thwarting his plans.
 Anybody engaged in that behavior would have to first find the sellers, a
 considerable problem, and impossible to do silently.


Except that one conspicuous feature of a market is that it
brings together the sellers in one place so that the buyers
can find them.

The stock market wouldn't work terribly well if everyone
did everything individually.  It only works because there's
a common place where buyers and sellers congregate
together.


 Then he would have to do hundreds and hundreds of transactions, which
 would take a long time and everybody would see it in the public transfer
 lists posted by the RIRs.


As every hostile takeover expert in investment banking
on wall street can tell you, you don't do the transactions
under your own name; you have holding companies
start doing the transactions, a bit at a time, so that you
can fly under the radar as long as you can, until it's
too late for anyone else to react and change the outcome.



 Worldwide there have been less than 1500 transfers.
 My rough number is about 24 million total addresses have been bought or
 sold since 2010, leaving out intra-company transfers.

 You seem to think there is somebody, somewhere you can tap on the shoulder
 and offer a couple of billion and he can transfer hundreds of millions of
 addresses to you.  Without the needs test, you can be sure every transfer
 will be booked and visible, unlike those transfers driven underground by
 the needs test. That visibility, and innate seller fragmentation,  is our
 protection against this kind of scheme.


And that open visibility works *so* well for preventing
hostile takeovers in the stock market, right?

Oh wait--that's why companies enact poison pill
clauses; because often the transactions are so
distributed and so randomized that by the time
you realize you're being taken over, it's too late
to stop it; so the poison pill allows you to dilute
the stock to the point where the hostile takeover
has to chase an asymptotic curve.

Unfortunately, in 32-bit land, there's no such
safety belt; we can't issue additional number
resources to prevent a hostile takeover situation
like that.




 IMO, the mobile phone operators are not going to invest and risk billions
 of dollars on a reputationally dangerous ploy like this. Instead they
 simply appropriate some DoD space and run CGN. Or they could turn on IPv6,
 which is not “hard” but which is fruitless in today’s Internet.


I didn't say the mobile phone operators.
They only control one piece of the equation;
they can't effectively lock the communication
channel down.

I said the OS vendors.  They have the capital
and the control of both ends of the socket;
the client device, and the OS upgrade/patch
servers.  Those are the players I'm most afraid
of right now.  And having one of the big three
that has already made one of the biggest
IP space acquisition bids in history step
forward and say hey, we need to be able
to do more of this in an unfettered manner
scares the bejeezus out of me--and I don't
even know what a bejeezus is.





 Although we may not agree on the risks here, are you in agreement that
 limiting needs-free transfers to one /16 per year per registrant would
 effectively obviate the fears of the activity you describe?


A /16 is really freakin' big.  When I'm being paid
(which I'm not at the moment, so these paranoid
delusions are entirely my own, and do not represent
any official stance of any corporate entity of any
sort), it's to run herd over several dozen different
networks, with many different org-IDs.  That would
effectively allow me to do 50 /16 transfers per
year with no justification needed, under different
names; in half a decade, that would allow me to
suck up a /8 with no justification needed.  And
$eventual_dayjob isn't even one of the really big
players; for the really big players, it would be
relatively straightforward to suck up a /8 per year
this way.

I remain unconvinced that removing needs-based
justification for transfers is a healthy notion for a
resource that is absolutely and finitely bounded,
and for which there are billion hostages around
the planet under the control of 3 entities.

I realize I'm paranoid; but that means it's
going to take a lot more confidence in this

Re: [arin-ppml] About needs basis in 8.3 transfers

[Matthew Petach]

On Wed, Jun 11, 2014 at 1:36 PM, Brandon Ross br...@pobox.com wrote:

 On Wed, 11 Jun 2014, Matthew Petach wrote:

  I cannot absolutely prevent you from stealing my furniture
 if you so desire.  However, that doesn't mean I'm not going
 to put a lock on my front door to at least make it harder for
 you, and make it patently clear that you're doing so against
 my express desires.


 As has been mentioned here before, stealing furnature is a criminal
 offence, writing a contract giving exclusive rights to address space is
 not.  That's a pretty crucial difference.  If breaking and entering and
 stealing furnature were legal, the small help of a lock on my porch screen
 door would make little difference to a bad actor.  Locks keep honest
 people honest, but if an activity is not widely agreed to be immoral, locks
 won't help.


The only way an action becomes a criminal offense
is if we bring the government in for enforcement.
Thus far, as a community, we've been doing our
best to not reach out to governments, which means
nothing within the realm of number policy can ever
be a criminal offense.  I would think the community
would still consider some of the number resource
activities to be of a nature equivalent to what would
be called a criminal activity, even if it does not hold
that official designation according to the laws of the
land.

(That is, if I were to willfully announce IP space
registered to someone else, the community would
designate that as wrong and consider it to be
a criminal act, even though no law of the land
says that 32-bit address space has the same
level of consideration as property.)
Putting it another way--it is perfectly legal for
me to hijack  your IP space; there is no law
that disallows it.  Doesn't make it right according
to our community.  So, arguing that one case
is a criminal offense while the other is not a
criminal offense does not make the non-criminal
offense any less wrong; it just means we don't
yet have a law on the books defining it as such.




 I'll ask plainly; for everyone voting for needs-free
 transfers; would you still vote that way, *if in doing
 so, you were guaranteed to not be able to obtain
 any number resources under the new policy*?


I don't have any address resources now, and I don't ever plan on having any
 in the future, so sure, why not?


My apologies; I misunderstood what your
position was--and I thank you for your
feedback to my question.




  If not, I would claim your votes are not guided by
 the good of the community; they're guided by
 self-interest, and a hope and desire that you can
 get something for less effort than you can by following
 the current guidelines.


 Oh really?

 Much like Owen, I have a nice little business of helping small
 organizations navigate the ARIN process to get address space.  It's not a
 majority of my income, but it's pretty nice and easy work for me.  If needs
 basis goes away, guess what else goes away?

 Even though Owen and I are on opposite sides of this coversation, I can
 guarantee you right now that both of us, without fail, are arguing solely
 for what we think is best for the community.

 It's quite ironic that I would make more money by arguing on your side of
 the issue, isn't it?

 Or maybe my conspiracy is to get v4 to run out faster so I can make more
 money on v6 deployment?


I apologize; I meant the you to be addressed to the
broader community, not to a particular individual.  I was
not aware of your activity in this arena, and it is good
background to be aware of; but the statement was
addressed to the plural you rather than the singular
you--dratted English, not giving us a distinctly plural
form of you we can use to make it explicit.

I *will* note that I'm surprised--if you have no interest
in obtaining number resources, what would make you
vote one way vs the other, if the outcome is exactly
the same for you either way?





  I'm sorry.  I'm going to start saying things that
 will offend people, and I'll end up with a bunch
 of pissed off people if I continue.


 I believe you already have.

 Please only question my motives when you have evidence.


Would it help to say that I was questioning
everyone's motives, not just yours?  Or would
that simply make my sin that much more
inclusive?  :/

Thanks for the attitude correction--sometimes
it's good to be smacked in the head when I get
too fired up and start making overly broad
generalizations.

Thanks!

Matt




 --
 Brandon Ross  Yahoo  AIM:
  BrandonNRoss
 +1-404-635-6667ICQ:
  2269442
  Skype:
  brandonross
 Schedule a meeting:  http://www.doodle.com/bross


___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http

Re: [arin-ppml] ARIN Draft Policy 2014-2 Improving 8.4 Anti-Flip Language

[Matthew Petach]

On Mon, May 5, 2014 at 4:23 PM, sandrabr...@ipv4marketgroup.com wrote:

 [...]
 The only thing we don't know is whether this is a one-off problem, or
 whether other companies have the same issue.  I would think other
 companies have the same problem but are not commenting.  I suspect the
 people at ARIN33 felt the problem should be solved, but that it didn't
 apply to them so they are not being as vocal now.  The shepherds could
 contact companies with a profile similar to David Huberman's and see if
 it would be of service to them.


I suspect the number of companies with a profile
similar to Microsoft's can be counted on one hand.  ^_^;

I have no qualms about shuffling addresses to wherever
they may be needed around the planet, regardless of where
they were first issued, so I haven't spoken up about this
policy, because I think it's a solution in search of a
problem.  Do others feel constrained to use IP space
only in one region?

Matt
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] 2-octet and 4-octet ASNs

[Matthew Petach]

On Fri, Apr 18, 2014 at 5:05 PM, Owen DeLong o...@delong.com wrote:

 As I understand it, the perceived issue is:


 [...]


 (Hopefully uncontroversial):
 1.  Authorize IANA to distribute 4-octet ASN pools to the RIRs without
 regard to their consumption of 2-octet ASNs


I'd support that, no concerns.

Matt
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip Language

[Matthew Petach]

On Wed, Mar 5, 2014 at 7:00 AM, Bill Darte billda...@gmail.com wrote:

 On Feb. 21 I sent the message (far below) to PPML asking the community to
 support one of 3 alternatives or propose new language which makes one or
 the other better, or a completely new wording which they believe
 accomplishes the goal of producing policy language that is needed,
 technically sound and improves existing policy in the 8.4 Inter-RIR
 transfer realm.

  [...]



 3. Take an alternative tack and simply restrict transfers on a per-block
 rather than a per-organization basis. e.g. 'No block acquired within the
 past 24 months would be eligible for transfer.' (The time frame is of
 course an arbitrary number at this point.)



I support option #3.

I'm curious if it would be better to reference time
periods from other sections of the NRPM, rather
than hard-coding a specific term here?  IE, if we
limit transfer requests to a 24-month supply, then
tie the anti-transfer period to be the same duration
as the supply length, so that if we extend or contract
the supply length for transfers, this anti-flip language
inherits the same change.   This doesn't affect my
support for option #3, I'm just looking to see if there's
ways we can limit the potential for the NRPM getting
'out of sync' with itself in the future, if we change one
section but don't catch all the related sections like this.

Thanks!

Matt
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised Problem Statement and Policy Text

[Matthew Petach]

On Tue, Sep 17, 2013 at 11:45 AM, David Farmer far...@umn.edu wrote:

 I'm going to break this up into separate sub threads.


 On 9/17/13 10:20 , Matthew Petach wrote:

  On Mon, Sep 16, 2013 at 3:59 PM, David Farmer far...@umn.edu
 mailto:far...@umn.edu wrote:

 On 9/14/13 22:58 , Matthew Petach wrote:

 ...

  change

  a plurality of resources requested from ARIN must be justified
 by technical
 infrastructure and customers located within the ARIN service
 region, and any located
 outside the region must be interconnected to the ARIN service
 region.

 to

  a significant fraction of the resources requested from ARIN
 must be justified by technical infrastructure or customers located
 within the ARIN service region, and any located outside the
 region must be
 interconnected to the ARIN service region.


 If we don't like plurality for whatever reason, I'd suggest;

 a minimum of X% of the resources requested from ARIN must be
 justified by technical infrastructure or customers located within
 the ARIN service region, and any located outside the region must be
 interconnected to the ARIN service region.

 Where X% is something like 20%, 25%, or 30%.


 So, how about something like this, then?

 a minimum of 20% of the *new* resources requested from ARIN must be
 justified by technical infrastructure or customers physically located
 within
 the borders of ARIN member countries, and any technical infrastructure
 or customers located outside the ARIN region must be physically
 interconnected to the ARIN service region


 I will modify the current language adding new making it a plurality of
 new resources requested before the text freeze, I think that clarifies the
 current intent.  Are there any objections to the new resources requested
 language?

 However, I'd like to hear more comments in support of a flat 20% standard
 before I'm willing to make that change, as I think that significantly
 changes the intent, at least in the view of some.  As an Individual I'd
 support a flat 20% standard.  But as the primary shepherd for the proposal,
 I'm a little worried we would loose as much or more support than we would
 gain with that change.  So, I need a better read on what the community as a
 whole thinks of a flat 20% standard before making that change.  No matter
 what, I will include that in the questions I take to the floor of the PPM.


The concern I have with plurality is that that I may not know
with certainty that a new request will meet that definition; I may
intend for it to be split 50/40/10 between ARIN/RIPE/LACNIC
regions; but then upon deployment, discover that the LACNIC
backbone nodes required more space than expected, as did
RIPE, and my split ends up being 40/45/15.  Now it's no longer
a plurality of space in the ARIN region.  It's easier to plan to
hit a target percentage than try to hit a multi-way ratio given
the unpredictable and changeable forces that impact real
world rollouts.




 As for some of the other additions I'm not sure physically located within
 the borders of ARIN member countries add much verses located within the
 ARIN service region, or physically interconnected vs. interconnected.
  In your opinion what do these changes add?


(warning--philosophical weeds ahead; feel free to
ignore anything beyond this point as completely
pointless to the actual topic being discussed)

I always wonder what the ARIN service region actually
entails.  I know what country borders are; what do we make
of places like offshore oil platforms (sealand?)--is it covered
by the service region, even if it's not one of the member
countries?  If a business address is listed in the ARIN
'region', but not within the borders of any member country,
does it help the LEA desire prompting this policy?
I realize I'm splitting hairs, so feel free to ignore this
philosophical ramble; under ordinary circumstances,
language like located within the ARIN region is good
enough for us, because we're not concerned with political
boundaries and law enforcement jurisdictions.  I just realized
that if the intent is to provide an address so that a particular
LEA can track down wrongdoers, what do we do about the
portions of the ARIN service region that aren't associated
with a specific country?  Or is the ARIN service region
strictly bound by the borders of the countries involved,
and anything outside of that belongs to a different RIR,
or does it float up to the IANA level?  Which service
region does the IP address pool on a jet airliner flying
over the atlantic ocean belong to?  Does the entity
making use of the addresses go out of compliance
if all the aircraft using the IPs leave the ARIN region
at the same time?

Likewise, does the aircraft's network still count as
being interconnected to the ARIN region, even
with no physical network layer involved?  If that
counts, is it any different from a network that
runs

Re: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised Problem Statement and Policy Text

[Matthew Petach]

On Mon, Sep 16, 2013 at 3:59 PM, David Farmer far...@umn.edu wrote:

 On 9/14/13 22:58 , Matthew Petach wrote:

  Why not simply use a phrase like significant fraction rather than
 plurality?


 The problem with significant fraction, its overly vague, while plurality
 may not be a commonly use every day word, it does have a precise meaning
 and in this context that is more than any other RIR's region. However,
 since there are 5 regions the smallest possible plurality would be slightly
 more than 20% within the ARIN region.  However, in most cases a plurality
 will be more than that.

 Rather than significant fraction, if the community could agree on a
 percentage say 20%, 25%, or maybe 30%, as a minimum percentage within the
 region that would be a little simpler than plurality, and be actually
 something staff could implement. I do not believe significant fraction as
 the standard would give staff a policy that can be implemented.



Can you clarify if this policy only applies
to *new* requests, or if it is meant to apply
to *all* number resources requested from
ARIN?

I have a serious problem with trying to assign
a fixed value if this is meant to apply to existing
as well as new number resources.  But if it it only
applies to new requests, and the requirement for
a plurality of the *new* request being used to service
needs somewhere within the ARIN region, I see that
as less onerous than the notion of a plurality of *all*
number resources having to be within the ARIN
region.




  change

  a plurality of resources
 requested from ARIN must be justified by technical infrastructure and
 customers located within the ARIN service region, and any located
 outside the region must be interconnected to the ARIN service region.

 to

  a significant fraction of the resources requested from ARIN must be
 justified by technical infrastructure or customers located within the ARIN
 service region, and any located outside the region must be interconnected
 to the ARIN service region.


 If we don't like plurality for whatever reason, I'd suggest;

 a minimum of X% of the resources requested from ARIN must be justified by
 technical infrastructure or customers located within the ARIN service
 region, and any located outside the region must be interconnected to the
 ARIN service region.

 Where X% is something like 20%, 25%, or 30%.


So, how about something like this, then?

a minimum of 20% of the *new* resources requested from ARIN must be
justified by technical infrastructure or customers physically located within
the borders of ARIN member countries, and any technical infrastructure
or customers located outside the ARIN region must be physically
interconnected
to the ARIN service region





  (representing a global network that spans 4 RIRs, but has no
 customers, I also advocate changing from and customers
 to or customers, to relieve networks such as the one I work
 for from being unfairly excluded from obtaining ARIN resources.


 I'm ok with technical infrastructure or customers, I've been debating
 between, and, or, and and/or myself.  Are there any objections to
 technical infrastructure or customers?



No objections to technical infrastructure or customers, nope.




  I will also note for the record that as port density increases,
 the number of devices we use is going down, not up.

 They cost a metric shit ton more, and suck up more power
 and need more cooling--but if you're measuring by number
 of boxes rather than capability of boxes, I think the expectation
 that the number of boxes in a network will always be increasing,
 as someone else further down in the thread claimed, is prima
 facie false.


 I don't think we want to be measuring the size of the network, at least
 the number of devices used to build the network.  Just that there is a
 network, or portion of a global network, within the region.



OK; so 20% could be measured in terms of cost of devices in the
ARIN region, rather than device count, in the case of a network
that has a few very large, very expensive network elements in
the ARIN region, but hundreds of small, inexpensive nodes
outside of the ARIN region.





  Matt

 (for the record, while I'm suggesting alternate language that
 I think might be more palatable, as currently proposed,
 I oppose this proposal)


 Do you opposed to the whole approach?  Or, Are there changes to the text
 that would allow you to support the Draft?  Or, is there another approach
 to the problem you would propose?


 I keep feeling like we're approaching the problem from the
wrong angle.  :/  I don't have a better approach yet, but I'm
trying to noodle over it.  Fundamentally, we're trying to ensure
that entities that obtain number resources in the ARIN region
are registered with physical addresses somewhere in the
ARIN region, and that the addresses get used primarily in
the ARIN region, right?   Maybe we should stick to simpler
language like that, rather than explicitly trying to identify

Re: [arin-ppml] Draft Policy ARIN-2013-6: Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors - Revised Problem Statement and Policy Text

[Matthew Petach]

On Thu, Sep 12, 2013 at 7:37 PM, Owen DeLong o...@delong.com wrote:

 
  Plurality seems like an odd choice of word above. The implication is
  that if 21% of the equipment for which I use ARIN addresses is in
  North America, and as long as my use in each of the other four regions
  is 20% or less, I'm good to go.
 
  Well more precisely the lowest possible use within the ARIN region is
 some fraction greater than 20%, with less than or equal to 20% in the other
 four regions.  While possible in reality, this is much more of a contrived
 example that something you would expect to see regularly in the real world.
  However, if you were only operating within the ARIN region and one other
 region you would need greater than 50% in the ARIN region and less that 50%
 in the other region, a simple majority.
 

 As written, I could, for example, have 50.001% in the ARIN region and
 49.999% in one other RIR and be within the proposed requirements.

 However, I think that in a policy like this, it is important to choose
 language which does not limit operator flexibility in unintended ways while
 getting as close as possible to the intended result.

 If anyone has language that they believe will better match policy intent
 (or feels that a different intent would be better for that matter), then
 please express those ideas here.

  That doesn't seem to be what the author was trying to achieve, does it?
 
  I'd agree it wasn't what the authors were originally thinking, but if
 you review the earlier comments there were several people that objected to
 a 50% majority, and plurality was suggested as an alternative, as discussed
 in the Advisory Council Comments sections.
 

 Majority is certainly more problematic than plurality. Plurality might not
 be the best possible choice, either, but nobody, including myself, has yet
 proposed a better alternative. The AC would certainly welcome any improved
 language from the community if anyone has a better idea.



Why not simply use a phrase like significant fraction rather than
plurality?

change

 a plurality of resources
requested from ARIN must be justified by technical infrastructure and
customers located within the ARIN service region, and any located
outside the region must be interconnected to the ARIN service region.

to

 a significant fraction of the resources requested from ARIN must be
justified by technical infrastructure or customers located within the ARIN
service region, and any located outside the region must be interconnected
to the ARIN service region.

(representing a global network that spans 4 RIRs, but has no
customers, I also advocate changing from and customers
to or customers, to relieve networks such as the one I work
for from being unfairly excluded from obtaining ARIN resources.

I will also note for the record that as port density increases,
the number of devices we use is going down, not up.

They cost a metric shit ton more, and suck up more power
and need more cooling--but if you're measuring by number
of boxes rather than capability of boxes, I think the expectation
that the number of boxes in a network will always be increasing,
as someone else further down in the thread claimed, is prima
facie false.

Matt

(for the record, while I'm suggesting alternate language that
I think might be more palatable, as currently proposed,
I oppose this proposal)




 Owen


 ___
 PPML
 You are receiving this message because you are subscribed to
 the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
 Unsubscribe or manage your mailing list subscription at:
 http://lists.arin.net/mailman/listinfo/arin-ppml
 Please contact i...@arin.net if you experience any issues.


___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.