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: Fee Philosophy (Matthew Kaufman)
2. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(Owen DeLong)
3. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(cb.list6)
4. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(Steven Ryerse)
----------------------------------------------------------------------
Message: 1
Date: Sun, 07 Apr 2013 22:23:16 -0700
From: Matthew Kaufman <[email protected]>
To: John Curran <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Fee Philosophy
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 4/7/2013 9:34 PM, John Curran wrote:
> On Apr 7, 2013, at 1:31 PM, Matthew Kaufman <[email protected]> wrote:
>
>> On 4/7/2013 4:46 AM, John Curran wrote:
>>> No NRPM change is needed because of the Revised Fee schedule; fees under
>>> the new schedule will be lower for smallest ISPs in any case. The question
>>> is whether the community also provide support for a xx-small category which
>>> is even lower ($500/year) but distinguished by only a /40 IPv6 allocation.
>>> This is being discussed in Draft Policy ARIN-2013-3, and while it is
>>> enabled by the Revised Fee schedule, it is an independent item for the
>>> community to consider and can be adopted or not based on its merits.
>> And what happens when next week ARIN's board comes up with the xxxx-small
>> category at $200/year, distinguished by a /60 IPv6 allocation. Are we
>> supposed to create more bad numbering policy then too?
> Matthew -
>
> You shouldn't support the Draft Policy ARIN-2013-3 if don't believe
> it to be fair and technically sound.
I don't.
> If the draft policy is not
> adopted, the fee schedule entry does not matter.
True.
> If it is supported
> by the community, then the policy change will happen because that
> meant that overall people felt it was fair and technically sound.
Or it will happen because enough people wanted themselves or others to
only need to pay $500 and were able to hold their nose long enough to
ignore the technical soundness while raising their hands. If we could
somehow figure out how to confine people to voting for or against policy
changes based soley on their technical merit we should patent the
process, because it would be useful in so many other venues.
>
> IF the Board were to add a /60 xxx-small category, nothing would
> change unless someone also introduced a policy proposal to lower
> the minimum to that size.
Which they would, because someone would want numbering policy to change
so they could pay less.
> There's no obligation to make a policy
> change, but if some ISPs thought it made sense, you'd likely see
> it get submitted and also discussed here.
No doubt.
> If it were found to be
> supported by the community, it would be adopted and would not be
> "bad numbering policy" but just "policy Matthew doesn't agree with"
If adopted it would be "policy Matthew doesn't agree with" *and* "bad
numbering policy" (at least in the technical-soundness sense). This
isn't the first time that similar reasons have resulted in similarly bad
policy being adopted, you know.
Matthew Kaufman
------------------------------
Message: 2
Date: Sun, 7 Apr 2013 22:27:54 -0700
From: Owen DeLong <[email protected]>
To: "cb.list6" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations for ISPs
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Number resource policy is not the reason mobile phone users are behind CGN
today.
That's an excuse, not a legitimate reason.
Until fairly recently, there were actually several mobile phone operators that
did not place their subscribers behind CGN.
Owen
On Apr 7, 2013, at 19:34 , cb.list6 <[email protected]> wrote:
>
> On Apr 7, 2013 7:19 PM, "Paul Vixie" <[email protected]> wrote:
> >
> > ...
> >
> > cb.list6 wrote:
> >>
> >>
> >> On Apr 7, 2013 12:49 PM, "Paul Vixie" <[email protected]> wrote:
> >> >
> >> > i know that it's a popular viewpoint -- many folks feel that the time
> >> > for needs based allocation is over and that the invisible hand of the
> >> > market is now capable of optimizing the holding of address space and the
> >> > aggregation level of that space into routing table entries.
> >> >
> >>
> >> Popular viewpoint go far in a bottom up process such as arin. In fact, the
> >> whole thing is a popularity contest.
> >
> >
> > i said it was popular, not that it could win a popularity contest.
> >
> >
> >> > so i thought i'd chime in: i consider that case to be extremely unmade
> >> > as yet. even though i am in most other ways a free-marketeer. as
> >> > stewards of a public resource ARIN has always been guided by RFC 2050
> >> > which requires recipients of these public resources to justify their
> >> > need, no matter whether these resources are coming from a central pool
> >> > or a private transfer.
> >> >
> >> > paul
> >>
> >> Does that mean you require an update to rfc 2050 to move ?
> >
> >
> > not at all. i think RFC 2050 was and remains correct in this regard. i'll
> > "move" when and if my mind changes on the matter.
> >
> >> I noticed this http://tools.ietf.org/html/draft-housley-rfc2050bis-01
> >>
> >> ...
> >>
> >> Should 2050bis ask rir not do this fair policy? From what I read in
> >> 2050bis is that is says the rir can make their own policy and 2050 is dead.
> >>
> >> Do you read it differently?
> >
> >
> > i read it to accurately explain that not every RIR still follows the needs
> > based justification described in RFC 2050. it's a description of the
> > current RIR system. 2050bis does not "ask" RIRs to do anything, it's a
> > description of what they actually do.
> >
> >
> >> As it stands, speaking from experience, the justification story in v4 and
> >> v6 drives design choices. That is an unfortunate fact and negatively
> >> impacts system design.
> >
> >
> > i'm intrigued by this statement. i hope you are willing to share some of
> > your experiences as to how needs based justification has negatively driven
> > some design choices.
> >
> > paul
>
> I just wrote a page of explanation and deleted it.
>
> If I have to explain it, you would not understand. And you do not understand
> today's data networks at all. I feel bad and outrageous saying that. But,
> given hundreds of millions of mobile phone users behind cgn today, perhaps
> your question is outrageous
>
> Note that att and vz have both rolled cgn to their dsl subs.
>
> Yet arin is not exhausted.
>
> Interesting?
>
> CB.
>
>
> _______________________________________________
> 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/20130407/ccfc2b19/attachment-0001.html>
------------------------------
Message: 3
Date: Sun, 7 Apr 2013 22:37:18 -0700
From: "cb.list6" <[email protected]>
To: Owen DeLong <[email protected]>
Cc: [email protected]
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations for ISPs
Message-ID:
<CAD6AjGTWeYMU43sy5uBe36UxzQTb1Wehq0uJdiH13o-0xa=h...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Apr 7, 2013 10:31 PM, "Owen DeLong" <[email protected]> wrote:
>
> Number resource policy is not the reason mobile phone users are behind
CGN today.
>
Applications were made prior to the g1 launch.
They were denied.
Cgn grew. Squat was deployed.
First hand account, end of story.
I did not handle the application, that was not my job. My job was to pick
the squat and handle the cgn.
CB.
> That's an excuse, not a legitimate reason.
>
> Until fairly recently, there were actually several mobile phone operators
that did not place their subscribers behind CGN.
>
> Owen
>
> On Apr 7, 2013, at 19:34 , cb.list6 <[email protected]> wrote:
>
>>
>> On Apr 7, 2013 7:19 PM, "Paul Vixie" <[email protected]> wrote:
>> >
>> > ...
>> >
>> > cb.list6 wrote:
>> >>
>> >>
>> >> On Apr 7, 2013 12:49 PM, "Paul Vixie" <[email protected]> wrote:
>> >> >
>> >> > i know that it's a popular viewpoint -- many folks feel that the
time for needs based allocation is over and that the invisible hand of the
market is now capable of optimizing the holding of address space and the
aggregation level of that space into routing table entries.
>> >> >
>> >>
>> >> Popular viewpoint go far in a bottom up process such as arin. In
fact, the whole thing is a popularity contest.
>> >
>> >
>> > i said it was popular, not that it could win a popularity contest.
>> >
>> >
>> >> > so i thought i'd chime in: i consider that case to be extremely
unmade as yet. even though i am in most other ways a free-marketeer. as
stewards of a public resource ARIN has always been guided by RFC 2050 which
requires recipients of these public resources to justify their need, no
matter whether these resources are coming from a central pool or a private
transfer.
>> >> >
>> >> > paul
>> >>
>> >> Does that mean you require an update to rfc 2050 to move ?
>> >
>> >
>> > not at all. i think RFC 2050 was and remains correct in this regard.
i'll "move" when and if my mind changes on the matter.
>> >
>> >> I noticed this http://tools.ietf.org/html/draft-housley-rfc2050bis-01
>> >>
>> >> ...
>> >>
>> >> Should 2050bis ask rir not do this fair policy? From what I read in
2050bis is that is says the rir can make their own policy and 2050 is dead.
>> >>
>> >> Do you read it differently?
>> >
>> >
>> > i read it to accurately explain that not every RIR still follows the
needs based justification described in RFC 2050. it's a description of the
current RIR system. 2050bis does not "ask" RIRs to do anything, it's a
description of what they actually do.
>> >
>> >
>> >> As it stands, speaking from experience, the justification story in v4
and v6 drives design choices. That is an unfortunate fact and negatively
impacts system design.
>> >
>> >
>> > i'm intrigued by this statement. i hope you are willing to share some
of your experiences as to how needs based justification has negatively
driven some design choices.
>> >
>> > paul
>>
>> I just wrote a page of explanation and deleted it.
>>
>> If I have to explain it, you would not understand. And you do not
understand today's data networks at all. I feel bad and outrageous saying
that. But, given hundreds of millions of mobile phone users behind cgn
today, perhaps your question is outrageous
>>
>> Note that att and vz have both rolled cgn to their dsl subs.
>>
>> Yet arin is not exhausted.
>>
>> Interesting?
>>
>> CB.
>>
>>
>> _______________________________________________
>> 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/20130407/6f50c44f/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 8 Apr 2013 06:02:47 +0000
From: Steven Ryerse <[email protected]>
To: Paul Vixie <[email protected]>, Matthew Kaufman
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations for ISPs
Message-ID:
<5b9e90747fa2974d91a54fcfa1b8ad12012f5ce...@eni-mail.eclipse-networks.com>
Content-Type: text/plain; charset="us-ascii"
Arin and this community could of course - rewrite the allocation polices like
the RIPE proposal http://www.ripe.net/ripe/policies/proposals/2013-03 and make
it easier and more straightforward to "qualify" for IP resources. Then
organizations that have been denied allocations (like ours) or organizations
that haven't even bothered to apply to Arin for an allocation for fear of being
denied - could then get resources and be added to the community that pays Arin
fees.
Then maybe Arin's board of directors wouldn't/won't have to approve fee
increases because there would be many more organizations paying fees and Arin's
total revenue would increase.
Arin gets more revenue, Organizations get needed resources, Arin is fulfilling
its Mission, Organizations get lower costs. Sounds like a win-win-win-win to
me.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Paul Vixie
Sent: Monday, April 08, 2013 1:14 AM
To: Matthew Kaufman
Cc: [email protected]
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for
ISPs
...
Matthew Kaufman wrote:
> On 4/7/2013 6:41 PM, Paul Vixie wrote:
>
> ...
>> ... the ARIN fee schedule is based in no way on willingness to pay more.
> Willingness, ability, same thing. Since I started writing this reply,
> John has chimed in to note that if everyone paid the same it would
> need to be $2800/year. So ARIN has happily found a few ISPs that are
> willing to pay so much more than some others can pay as little as $500.
willingness and ability aren't the same thing, but that doesn't matter, because
the fee schedule isn't based on either one.
paul
_______________________________________________
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.
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 94, Issue 25
*****************************************
