Send ARIN-PPML mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."
Today's Topics:
1. Re: Against 2013-4 (CJ Aronson)
2. Re: Against 2013-4 (David Farmer)
3. Re: Against 2013-4 (William Herrin)
4. Less than 1 hour remaining to register for remote
participation in the PPC@NANOG 58!! (John Curran)
----------------------------------------------------------------------
Message: 1
Date: Tue, 4 Jun 2013 07:29:53 -0600
From: CJ Aronson <[email protected]>
To: Owen DeLong <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Against 2013-4
Message-ID:
<CAC6JZKR1P9Xz+fe8=ZJhXKc-eZcv+bc44S=cyaroj4tpiq1...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Needs basis did indeed exist before 1997 as @Home did not get all of
24.0.0.0/8 but only 24.0.0.0/14 and to get more I had to sit down with Joh
Postel and some other folks to write essentially what the cable policy
still is today. Earlier in the 90s I was working with the InterNic and
before that the SRI NIC on behalf of BARRNet customers to request address
space and to provide justification. That indeed is what -actually-
happened because
I lived it.
The really super cool thing about then (the early 90s) is that the network
was breaking down because of the size of the routing table and we didn't
have CIDR yet. So we would get a block of /24s that we couldn't aggregate
and that made the routing table even bigger. You only got the number of
/24s you could justify because we were running out of /16s. (or back
then.. class Bs)
In the 80s it was certainly easier because the Internet didn't really exist
and no one thought it would be this big. So what did it matter if a
university who needed probably more than a B would get an A? There were
plenty of them right?
----Cathy
On Mon, Jun 3, 2013 at 9:35 PM, Owen DeLong <[email protected]> wrote:
>
> On Jun 3, 2013, at 17:20 , William Herrin <[email protected]> wrote:
>
> > On Mon, Jun 3, 2013 at 7:11 PM, David Farmer <[email protected]> wrote:
> >> Eventually, yes that was the case, and was definitely the case by the
> time
> >> RFC 1366 was published, However it was still technically possible to
> get a
> >> class A even then, look at Section 4.1.
> >
> > Hi David,
> >
> > Regardless of what might have been possible under conditions now past,
> > what actually did happen is that the first IPv4 /8's were preemptively
> > assigned without any kind of needs analysis at all. For smaller
> > requests (for shrinking versions of smaller) the practice of assigning
> > addresses without substantive consideration of "need" continued until
> > 1997. That's what -actually- happened.
>
> THis is not true. What is true is that the needs analysis was rather
> limited and
> consisted, essentially, of determining that anyone running an NCP network
> at the time would need to run an IP network to move forward.
>
> This seems like a pretty reasonable determination of need at the time.
>
> > At a guess, I'd say Jon's response was never "come back later." I'd
> > guess something more along the lines of, "Are you sure you what you
> > want to do really takes that many addresses?" I never met the man, so
> > I can't say that with any confidence.
>
> Jon was a very reasonable and personable man. I have no trouble believing
> David's characterization that he would likely have told someone whose need
> up to 5 years out was 0 hosts that they should come back when that number
> was larger than 0.
>
> I can also accept that he would likely have asked the other question in a
> case
> where someone offered 32 hosts in a request for a class B.
>
> Nonetheless, the point is that your documents do show an implementation of
> needs-basis as a principle that predates ARIN and those that knew Jon have
> consistently stated that he always applied an expectation that addresses
> were
> issued to a specific organization for a specific purpose and should be
> returned
> when that purpose was no longer valid.
>
> While I realize this latter part has not been all that well followed and
> that there
> is a fair amount of money and therefore a fair number of parties pushing
> for
> that part to just sort of fade into obscure history, it does not change
> the fact that
> he stated as much to numerous people on numerous occasions.
>
> >> Therefore, I believe operational need is a principle that MUST be
> included.
> >
> > I respectfully disagree. Needs assessment is a tool for conservation.
> > It's a coarse tool at that... consistently either too permissive or
> > too restrictive. And we use it badly, demanding predictions that
> > depend on unknowable variables, shortening prediction periods to the
> > detriment routing scalability and too frequently failing to check on
> > how the predictions panned out.
>
> Needs assessment serves purposes other than conservation. It also works
> to ensure that resources are handed out in a fair and consistent manner. It
> provides for a certain level of transparency in the operation of the
> registry
> while still protecting some privacy of resource holders.
>
> > "Operational need" is a just a tool that supports conservation for the
> > sake of sustainability. If a better tool proves itself, we shouldn't
> > hesitate to jettison operational need.
>
> Which can be done through the PDP when and if such a tool presents itself.
>
> If adopted, 2013-4 is not an immutable document. It will simply be an
> additional
> part of the NRPM still subject to the same PDP as the rest of ARIN policy.
>
> Owen
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List ([email protected]).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact [email protected] if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20130604/ac030e48/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 04 Jun 2013 12:22:57 -0500
From: David Farmer <[email protected]>
To: Steven Ryerse <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Against 2013-4
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 6/4/13 10:52 , Steven Ryerse wrote:
...
> Who out there knows what all of these stakeholder think? I don?t think
> anybody knows. So to make comments in this forum that presupposes that
> this entire community feels one way or another is inaccurate because
> nobody really knows.
I for one don't presuppose that the whole community feels one way or the
other. However, every time we've touched this set of issues from one
side or the other in the last couple years we have not gained consensus
one way or the other.
> Of course we could ask everyone in the ARIN community to comment.
We are, that is the point of ARIN-2013-4, everyone should take it as
asking the question of the whole ARIN community.
...
> Free markets with reasonable governance always work.
I agree, however what constitutes "reasonable governance" is the very
question being debated.
> Central planning
> and control always fails and always provides uneven results. Needs
> based testing is central planning! The current policies are producing
> uneven results.
>
> It is time to halt the current needs based allocations.
I'll agree the current policy for measuring need has issues, especially
as we move toward IPv4 free pool exhaustion, but that doesn't mean the
principle of need is wrong. If we completely abandon need as a
principle what principle would you put in place that would help ensure
fair distribution of IPv6 and ASN resources?
I believe the real issue is that IPv4 conservation thinking has warp our
sense of what need really means and should be. I want to see a meaning
of need more representative of current IPv6 and ASN policy, or early
'90s IPv4 polices, and not the hyper conservation need polices we have
for IPv4 today.
I agree that the price of IPv4 addresses will be the primary force
determining need for IPv4 going forward, and at least influence IPv6
adoption and demand. However, that doesn't mean that just anyone can
buy IP address, there needs to be some minimal threshold, like actually
operating a network, and being responsive to technical and operational
issues. Also, personally I believe there should be an upper limit on
how much address space you can buy without a more detailed
justification, I've proposed /12 in the past.
In my opinion "free markets with reasonable governance" have some kind
of checks and balances placed on the market, and I believe some minimal
operational need requirement is one of those checks and balances in this
case.
--
================================================
David Farmer Email: [email protected]
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
================================================
------------------------------
Message: 3
Date: Tue, 4 Jun 2013 15:21:34 -0400
From: William Herrin <[email protected]>
To: Jason Schiller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Against 2013-4
Message-ID:
<cap-gugwuogpnkgr9fqdmwungj6rnqh1k97c+8mzrjzjw2m8...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Jun 4, 2013 at 12:17 PM, Jason Schiller <[email protected]> wrote:
> I do value your input and would like to hear specifically
> which concepts that are popping up that have died.
Hi Jason,
The obvious one is heirarchy. There's just one more nail to put in
that coffin: move NRPM 4.2.3.6 over to 4.3.2.2. We still talk about
aggregation a lot but nobody pretends that insisting end users always
get their IPs from their ISP is still credible. Quite the contrary,
the industry is steadily shifting towards resilient, redundant,
multi-homed service.
Others on my hit list include:
Aggregation. Aggregation is an artifact of BGP. Critical while BGP
reigns, it should die quickly when a more scalable protocol rises.
IMO, principles should not die quickly as a result of foreseeable
technology evolution.
Conservation. Conservation where? We maintain three number resources.
Conservation for IPv4 is done. They're gone now. Our concern is making
sure that high value uses aren't starved for addresses while low value
uses hoard them. That means redistribution; conservation has nothing
to do with it.
Conservation for IPv6 is not yet a going concern. The protocol has to
be deployed and if throwing wastefully large blocks of addresses at it
helps, that's exactly what we should do. To an extent, that's what we
*are* doing.
Conservation for AS numbers is not credible. With the change in the
protocol to 32-bit AS numbers and the unrestrained demand curve,
they'll last longer than recorded human history. By which time we can,
if we're still using BGP, make another relatively trivial change to
the protocol.
So just what the heck is this conservation that you speak of as a core
principle of an Internet registry? It's not a core principle! It's
circumstantial and we happen to be in a lull where the circumstance
fits *none* of the number resources we're charged with maintaining.
Justified need. Justified need yields absurd results.
I work a $10M/yr project inside a multi-billion dollar defense
contractor. The project maintains three operational sites 5,000 miles
apart with a couple hundred clustered machines sharing IP addresses
using BGP. Because of the labyrinth created by justified need, I
couldn't just say, "Hey, here's the set up. Sell me IPs." As the
project lead, I can't talk to ARIN at all. I'd have to fight through
dysfunctional corporate heirarchy to even talk to ARIN and then ARIN
couldn't provide the obviously justified addresses to my project
without first examining resource use by the entire multi-billion
dollar company.
So every year my project spends around $4000 of taxpayer money on a
contract to maintain a separate corporation whose sole output is the
payment of a $100 ARIN end-user fee. Because that's the sanest and
*least expensive* path to getting the analysis of justified need to
work out. Ridiculous!
Is a pure market better? That's not yet proven. But for sure it
wouldn't have yielded the absurd result above.
Really, the only thing in draft 2013-4 that I don't immediately
disagree with is uniqueness. Even there I can't help but think of the
work we did here with the CGN /10. Granted it was appropriate to
handle part of the discussion at the IETF, but I'd hate to have seen
the discussion cut off at the knees because of our principle of
uniqueness.
Regards,
Bill Herrin
--
William D. Herrin ................ [email protected] [email protected]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
------------------------------
Message: 4
Date: Tue, 4 Jun 2013 20:05:04 +0000
From: John Curran <[email protected]>
To: "[email protected] List" <[email protected]>
Subject: [arin-ppml] Less than 1 hour remaining to register for remote
participation in the PPC@NANOG 58!!
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
ARIN Community -
At 4:45 PM CDT today, there will be a Public Policy Consultation (PPC) being
held in
conjunction with NANOG 58 in New Orleans. As noted in the attached
announcement,
there is a remote participation available and is free, but you must register in
advance
(and there is less than an hour remaining to do so!)
Thank you!
/John
John Curran
President and CEO
ARIN
Begin forwarded message:
From: ARIN <[email protected]<mailto:[email protected]>>
Subject: [arin-announce] ARIN Public Policy Consultation At NANOG 58 Today at
4:45 CDT
Date: June 4, 2013 9:08:38 AM CDT
To: <[email protected]<mailto:[email protected]>>
If you aren't at NANOG, you can still register as a remote participant
for ARIN's Public Policy Consultation (PPC), which will be webcast this
afternoon beginning at 4:45 PM CDT. The PPC is an open public discussion
of Internet number resource policy, and part of ARIN's Policy
Development Process (PDP).
ARIN will be offering a webcast, live transcript, and Jabber chat
options for remote participants. Registered remote participants may
submit comments and questions to the discussions during the meeting.
Register to attend in person or remotely today at
https://www.arin.net/app/meeting/registration/?action=show_form&meeting_id=53.
Your Jabber ID must be registered by 4:00PM CDT if you wish to
participate. We do encourage you to register early so you have ample
time to test the chat before the session opens.
Current policy proposals up for discussion at this meeting are:
* Recommended Draft Policy ARIN-2013-1: Section 8.4 Inter-RIR Transfers of
ASNs
* Draft Policy ARIN-2013-2: 3GPP Network IP Resource Policy
* Draft Policy ARIN-2013-4: RIR Principles
* Draft Policy ARIN-2013-5: LIR/ISP and End-user Definitions
Learn more at https://www.arin.net/ppc_nanog58/.
Registered NANOG 58 attendees do not need to register to participate in
this session. ARIN welcomes members of the NANOG community who will not
be in Orlando to register as remote participants.
Regards,
Communications and Member Services
American Registry for Internet Numbers (ARIN)
_______________________________________________
ARIN-Announce
You are receiving this message because you are subscribed to
the ARIN Announce Mailing List
([email protected]<mailto:[email protected]>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-announce
Please contact [email protected] if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20130604/ba9db37a/attachment.html>
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 96, Issue 15
*****************************************
