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 (Owen DeLong)
2. Re: Against 2013-4 (Paul Vixie)
3. Re: Against 2013-4 (Jimmy Hess)
4. Re: Against 2013-4 (Jason Schiller)
----------------------------------------------------------------------
Message: 1
Date: Mon, 3 Jun 2013 20:35:33 -0700
From: Owen DeLong <[email protected]>
To: William Herrin <[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 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
------------------------------
Message: 2
Date: Mon, 03 Jun 2013 20:39:52 -0700
From: Paul Vixie <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Against 2013-4
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Milton L Mueller wrote:
> I would have to oppose most of the statements in this proposed revision of
> the RIR principles.
noting, first, that the author has clarified his intent -- documenting
current principles in the impending absence of rfc 2050, not revising
any principles per se. (i support that goal.)
> ...
>> -----Original Message-----
>> Policy Statement:
>>
>> Section 0: Principles and Goals of the Internet Registry System
>>
>> 0.1. Efficient utilization based on need (Conservation)
>
> This represents confused thinking. Conservation as a principle does NOT
> necessarily mean needs-based allocation. There are many ways to conserve
> number resources without the fiction of technical needs assessment. For
> example, pricing or fees graduated to the number of addresses used is a form
> of conservation. Market trading, in which you bid a scarcity-based price for
> number blocks, is a form of conservation.
i'm not ready to hear arin's current technical needs assessment called a
"fiction". if you really think this, then you should address it
directly, not as a cheap shot buried in a policy debate.
other methods of conservation may be acceptable to ARIN, and could be
proposed. note that market trading is likely to be seen as controversial
and not as a restatement of current policy.
also:
Milton L Mueller wrote:
> ... the consensus within the RIPE APWG is pretty clearly in favor of
> the no need proposal, and the topic is highly controversial even
> within the ARIN region.
i think consensus could have been called either way after the ripe
discussion.
paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20130603/74d2b389/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 3 Jun 2013 23:14:49 -0500
From: Jimmy Hess <[email protected]>
To: William Herrin <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Against 2013-4
Message-ID:
<CAAAwwbVGc5t=apcmqpkowewscwft6of5gdo8m9dzbhllf0b...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 6/3/13, William Herrin <[email protected]> wrote:
> On Mon, Jun 3, 2013 at 9:50 AM, Milton L Mueller <[email protected]> wrote:
>>> 0.1. Efficient utilization based on need (Conservation)
>> This represents confused thinking. Conservation as a
>> principle does NOT necessarily mean needs-based allocation.
> I agree. Needs based allocation has been called into question for good
> reason these past few years. Principles should be things which aren't
> in serious, active dispute.
"Conservation" is the principle.
"Justified need" as a criteria is an implementation detail, that
should be changed as necessary.
Once again... a justification that _principles_ ought to be in a
different document, and not so mutable as "policy".
Principles should not change every year, maybe every 25 years, there
could be a small tweak; they should be the fundamental things
the internet community agrees on that number resource policy should
be based.
They certainly ought not reflect specific things about today's policy
implementation details; like "justified need" as the specific
detail, about the mechanism / how RIRs currently go about
implementing conservation.
--
-JH
------------------------------
Message: 4
Date: Tue, 4 Jun 2013 01:04:18 -0400
From: Jason Schiller <[email protected]>
To: Mike Burns <[email protected]>
Cc: [email protected]
Subject: Re: [arin-ppml] Against 2013-4
Message-ID:
<CAC4yj2VSe95hs-e5DOT=uqufusfyxhrvyph9hbe15quwkjh...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Mike,
Operational need was also intended transfers per RFC 2050.
RFC 2050 section 4:
7. The transfer of IP addresses from one party to another must be
approved by the regional registries. The party trying to obtain
the IP address must meet the same criteria as if they were
requesting an IP address directly from the IR.
___Jason
On Jun 3, 2013 7:43 PM, "Mike Burns" <[email protected]> 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.
>
> 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?
>
> 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 am opposed to 2013-4.
>
> Regards,
> Mike Burns
>
>
>
>
>
> ----- Original Message -----
>>
>> From: David Farmer
>> To: William Herrin
>> Cc: [email protected]
>> Sent: Monday, June 03, 2013 7:11 PM
>> Subject: Re: [arin-ppml] Against 2013-4
>>
>> On 6/3/13 15:52 , William Herrin wrote:
>>>
>>> On Mon, Jun 3, 2013 at 4:24 PM, John Osmon <[email protected]>
wrote:
>>>>
>>>> When (say) MIT asked for space, Class B was too small their needs and
>>>> Class A was the only larger size available. They didn't request a /8,
>>>> they requested a netblock that fit their needs and got a Class A. The
>>>> needs assessment at the time was simply different.
>>>
>>> Hi John,
>>>
>>> Not exactly. IIRC (and the old fogies are free to correct me here) the
>>> predecessor to IPv4 had exactly 256 addresses. When IPv4 was deployed,
>>> each prior user was automatically assigned the /8 corresponding to
>>> their prior address. MIT is one of the organizations which had a
>>> computer using the prior Internet protocol, so they automatically
>>> received a /8
>>
>> I'm not really an old fogie, at least I don't think I am. However,
since I work for an organization with significant Legacy resources, I've
done a bit of research looking through the RFCs that document the earliest
IPv4 assignments, including several for my employer. See, RFCs 790, 820,
870, 900, 923, 943, 960, 990, 997, 1020, 1166.
>>
>> Comparing RFC 776 and RFC 790 it is easy to infer what you say is what
happened in MIT's case, and a few others. However, John is also right, if
you demonstrated need you could get a class A, at least for a some while.
This can also be inferred by comparing RFC 790 and RFC 820, note several
class As were assigned between these two RFCs. Also, along the way through
this series RFCs class As were assigned, RFC 1166 is I think the last RFC
that documented address assignments in an RFC.
>>>
>>> Very few /8's were assigned after that. Anybody who wanted more than a
>>> class B received multiple class B's, not a class A.
>>
>> 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.
>>
>> 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"?
>>
>> The bar was low, but there was a bar even for class Cs, and that bar was
that you were going to use them in a network, "operational need"
>>
>> Therefore, I believe operational need is a principle that MUST be
included. There are valid policy questions of what the proper measure of
operational need for the current times and current protocols are. I
believe the measure of operational need will properly change over time, and
for IPv4 such a time is likely here or upon us very soon. But, a principle
that assignments or allocations are made for operational need is valid and
technically necessary. Equally, we need policies and procedure that
interpret this principle in the light of today's protocols and operational
realities, is also valid and necessary, and the whole point of documenting
operational need as principle.
>>
>>
>> --
>> ================================================
>> 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
>> ================================================
>>
>> ________________________________
>>
>> _______________________________________________
>> 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.
>
>
> _______________________________________________
> 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/843e5dc8/attachment.html>
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 96, Issue 12
*****************************************
