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 (William Herrin)
2. Re: Against 2013-4 (David Farmer)
3. Re: Against 2013-4 (William Herrin)
4. Re: Against 2013-4 (Owen DeLong)
5. Re: Against 2013-4 (Owen DeLong)
6. Re: Against 2013-4 (Bill Darte)
----------------------------------------------------------------------
Message: 1
Date: Mon, 3 Jun 2013 20:20:45 -0400
From: William Herrin <[email protected]>
To: David Farmer <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Against 2013-4
Message-ID:
<cap-gugw3hdekr90u2p7coeyv7dm06pmkcqjmeno-0katzzu...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
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.
> Finally, as was pointed out earlier, operational need was required for all
> assignments. It was noted that even for a class C you had to estimate how
> many hosts were going to be connected, initially, and at one, two and five
> years. As a thought experiment, what do you think John Postel would have
> said, if you answered that question with zero(0), especially for the one,
> two and five year parts of the question. Do you think it might have been
> "come back later"?
As a thought experiment, I think all the forms I've been able to track
down post-dated Jon's (not John's) involvement in the registration
process. If you happen to have copies of any written communications
between him and a registrant from the days of his involvement, I'd
love to read them.
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.
> 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.
"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.
Regards,
Bill Herrin
--
William D. Herrin ................ [email protected] [email protected]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
------------------------------
Message: 2
Date: Mon, 03 Jun 2013 19:27:54 -0500
From: David Farmer <[email protected]>
To: Mike Burns <[email protected]>
Cc: [email protected]
Subject: Re: [arin-ppml] Against 2013-4
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 6/3/13 18:37 , Mike Burns wrote:
> Hi David,
> All that is being demonstrated by your research below is that
> operational need was a principle of allocation of addresses *from the
> free pool*.
> And that makes perfect sense to everybody. You had to have some means to
> fairly distribute the addresses, and the lightest touch of the steward
> would be to just give them away for free to anyone. Of course that would
> allow anybody to claim all the addresses, so the lightest workable touch
> then became giving them away for free to anyone who needed them. And
> that's what we have done, and it has served us well.
You seem to think that IPv4 are the only resources we need to worry
about, IPv6 and ASNs are necessary resources too, these principles also
apply to them. You seem to concede that an operational need principal
is appropriate for IPv6 and ASNs as they have a free pool. Do I read
you correctly?
> With a transfer market, pricing enforces conservation with the lightest
> touch from ARIN stewards.
> The whole point here is that RFC2050 is outdated, right? I agree- it was
> the product of a mindset which did not conceive of a life after the free
> pool exhausts. There is no concept of a transfer market in RFC-2050, so
> why draw the inference that the principle of conservation of free pool
> addresses should be extended to transfers?
I personally agree that the current measure of operational need for IPv4
as we must extend the life of IPv4 through transfers is obsolete.
However, that doesn't mean I think the principle is obsolete, the
principle remains necessary for IPv6, ASNs, and I contend IPv4 as well.
I contend it is only necessary for us to revise the measure of
operational need for IPv4, not obsolete the principle all together.
> The purpose of a market is to allocate scarce resources. It does this
> through pricing the resource. Now that we have this conservation force
> working for us, it is our responsibility as stewards to step back, pat
> ourselves on the back for a job well done with the free pool
> allocations, and concentrate our resources on our primary role as
> registrars. This means we do not create or maintain policies that
> provide an incentive for transfers to occur which are not booked in
> Whois, such as need tests for transfers.
I agree we need a much lighter weight measure of operational need for
IPv4, about now or very soon. However, I also believe the principle of
operational need MUST be maintained, without it we risk all sorts of
issues for the long term viability of IPv6 and ASNs. I don't believe a
vibrant transfer market requires we obsolete the principle of
operational need. We only need to radically rethink our current measure
of operational need for IPv4, which is compatible with a principle of
operational need, and allows us to maintain a common principle for all
resource types.
--
================================================
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: Mon, 3 Jun 2013 21:04:59 -0400
From: William Herrin <[email protected]>
To: David Farmer <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Against 2013-4
Message-ID:
<CAP-guGX125__UkwSie3eYYQ02QKdgL3qW=u-+9hx98aj45q...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Jun 3, 2013 at 8:20 PM, William Herrin <[email protected]> wrote:
> "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.
What'd be helpful would be defining the criteria by which a
replacement tool has to be measured when proving itself.
-Bill
--
William D. Herrin ................ [email protected] [email protected]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
------------------------------
Message: 4
Date: Mon, 3 Jun 2013 20:17:20 -0700
From: Owen DeLong <[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=us-ascii
On Jun 3, 2013, at 12:37 , Steven Ryerse <[email protected]> wrote:
> I take issue with the assumption that "this community" is strongly for needs
> based assignments. Certainly there are folks in this community who
> frequently and sometimes loudly voice their support for needs based
> assignment policies. Then of course there are folks in this community like
> me who are vehemently against needs based assignments and I certainly have
> voiced that frequently and sometimes loudly. There have been others who have
> done so as well from time to time.
It is not an assumption. It is reflected in the numbers each time this question
has been raised in a public policy meeting throughout ARIN's history.
Owen
------------------------------
Message: 5
Date: Mon, 3 Jun 2013 20:25:46 -0700
From: Owen DeLong <[email protected]>
To: Blake Dunlap <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Against 2013-4
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
On Jun 3, 2013, at 16:13 , Blake Dunlap <[email protected]> wrote:
> I for one also see a strong support for needs basis, and a strong minority
> that is obsessed with removing regulation in general. That's just one voice
> though and should be viewed as such, as I believe we should also go with what
> the majority wishes.
To be clear... The current governance structure of ARIN is not based on simple
majority rule.
It requires 10 of the 15 members of the ARIN AC to agree that the community has
arrived at consensus on a fair, technically sound, feasible policy and the
additional affirmation of the majority of the Board of Trustees that the policy
development process was followed and that there are no legal or fiduciary
issues that should prevent the policy from taking effect.
Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20130603/c784d086/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 3 Jun 2013 22:05:13 -0500
From: Bill Darte <[email protected]>
To: William Herrin <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Against 2013-4
Message-ID:
<camapp36o1dkepqht0z+h0qxfbmmt7sppdwm2+1bzrmpblzw...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I really can't quite get my head around the argument that when a resource
like IPv4 gets really scarce, the way to conserve them for the greatest
good it so provide a market that makes them only available to those who can
pay for them regardless of a need to use them for their intended purpose.
Sorry. I'm in support of 2013-4 but I continue to be convinced that
granting allocations and assignments to those who do not 'need' the
addresses to grow the Internet is a good idea for anyone other than those
in the middle.
bd
On Mon, Jun 3, 2013 at 8:04 PM, William Herrin <[email protected]> wrote:
> On Mon, Jun 3, 2013 at 8:20 PM, William Herrin <[email protected]> wrote:
> > "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.
>
> What'd be helpful would be defining the criteria by which a
> replacement tool has to be measured when proving itself.
>
> -Bill
>
> --
> William D. Herrin ................ [email protected] [email protected]
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> 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/20130603/15f1f3b2/attachment.html>
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 96, Issue 11
*****************************************
