[arin-ppml] Do people see a middle ground?

Wed Aug 4 00:21:25 EDT 2010

Could some kind of metric be applied?

Such as a minimum ratio of the number of IPv6-only hosts that could interact 
with existing IPv4 hosts per IPv4 address provided under the policy?

I.E.  If each IPv4 address allowed thousands of IPv6-only hosts to
communicate with existing IPv4 hosts, then that would be acceptable.
If each IPv4 address only provided communication for a single IPv6
host, then that would not be acceptible as it would be no better
than it would be no better than dual-stacking the IPv6 hosts.

So somewhere in between there must be a magic number that says
"do better than this and it's worth giving you a piece of the dwindling
IPv4 pie."

Is that number 2?  1 million?  Somewhere in between, like 10 or 256 or
10,000?

Does the number depend on circumstances/protocol, or should it be the
same for everybody?  (If its not constant, then it wouldn't make a
good metric.)

If we can come up with a formula like this, then that should make the
ARIN staff's job much easier and better defined, without worrying about
specific protocols.  The applicant just has to show their expected
ratio and how they derived it.  If the assumptions are reasonable,
and the arithmetic correct, then give them an allocation.

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
-------------- next part --------------
I'll try and make this one of the last questions.

Are there key functionalities that make a transitional technology
"acceptable" for most? Would the policy become more flexible if it were
written around this functionality, rather than trying to maintain a list
the technologies directly? 

-Dan

From: Owen DeLong [mailto:owen at delong.com] 
Sent: Monday, August 02, 2010 11:16 PM
To: Alexander, Daniel
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Do people see a middle ground?

4.10 currently does nothing to define what is a "transitional
technology".

Arguably, addresses for dual-homed hosts could be called a "transitional
technology".

NAT64/IVI/etc. gateways serving a single residential customer could
arguably be called a

"transitional technology".

The reality is that if we allow such uses, there's no set-aside because
these "uses" are

essentially identical to the current "business as usual" (residential
customers generally

get a single IPv4 address today, for example).

Staff has stated that 4.10 is too vague to implement effectively.

When 4.10 was adopted, I recall the discussion both on PPML and at the
microphones

expressly including an expectation that clarifying language for how to
use the /10 would

be generated as we got closer to need. Atlanta may well be the last
public policy meeting

prior to need. As such, I think it is important that we at least bring
something to the floor

for discussion there.

Owen

On Aug 2, 2010, at 6:58 PM, Alexander, Daniel wrote:

Can we get some examples of how 4.10 can be circumvented. That might
help the discussion about how to close any loopholes. 

On 8/2/10 6:22 PM, "Owen DeLong" <owen at delong.com
<x-msg://2052/owen@delong.com> > wrote:

So far, proposal 116 does not establish a review panel and I remain
unconvinced that doing so is the correct approach vs. leaving it to
staff judgment guided by the BoT.

I'm open to any suggestions on a better way to limit abuse, but, it was
made obvious to by a number of people that 4.10 can be easily perverted
into pretty much business-as-usual by the creative leaving no IPv4
addresses
available for true cases of need in order to deploy IPv6. I would hate
to see
us end up in that kind of dead-lock because we failed to address and
close a loophole in a policy that was passed with a general community
understanding of "This is a good placeholder, we'll make it more
specific
when the time comes and we better understand the implications."

While you could well argue that we still don't understand the
implications
significantly better than when 4.10 was enacted, I do not think it is
possible
to argue that the time has not come. Atlanta may well be the last public
policy meeting prior to IANA runout. In fact, I will be very surprised
if it is
not.

As such, I think it is very important to get something on the agenda for
Atlanta
with the possibility of becoming policy, even if we need to tweak it
in last call.

Owen

On Aug 2, 2010, at 2:22 PM, Alexander, Daniel wrote:

> Thank you Chris and Owen for the replies. I think you articulated the
> point better than I did. If we were talking about simply stretching
out
> the last pieces of IPv4 space, both rationing or the technical
> requirements could probably be tweaked to accomplish the same thing.
The
> difference is the attempt to leverage the last pieces of IPv4 to
> facilitate IPv6 deployments.
>
> What I question is whether technology requirements are the proper knob
> to try and turn. Will adding things like review panels and acceptable
> lists of transition technologies actually achieve the objective of
> getting IPv6 deployed, or will it just distract people to debate what
> are acceptable methods in how to get there?
>
> I am trying to understand the policy gap we are trying to fill here.
How
> will the current policy be abused that staff cannot manage? And will
the
> gains achieved in preventing this abuse really be offset by the
addition
> of review panels on what everyone deems "acceptable" transition
> technologies.
>
> Just adding my $.02 to your $.02. Soon we will be rich. :)
> -Dan
>
>
> -----Original Message-----
> From: Chris Grundemann [mailto:cgrundemann at gmail.com]
> Sent: Monday, August 02, 2010 10:27 AM
> To: Alexander, Daniel
> Cc: arin-ppml at arin.net <x-msg://2052/arin-ppml@arin.net> 
> Subject: Re: [arin-ppml] Do people see a middle ground?
>
> On Sun, Aug 1, 2010 at 22:06, Alexander, Daniel
> <Daniel_Alexander at cable.comcast.com
<x-msg://2052/Daniel_Alexander@cable.comcast.com> > wrote:
>>
>> Not too long ago there were policy discussions about rationing the
> last of
>> the IP resources allocated to ARIN. Many were opposed to this. The
> general
>> opinion was that organizations should not be denied needed resources
> now,
>> for something that may be needed later. Then some found a compromise
> in
>> section4.10.
>>
>> Then there are proposals that suggest parking resources for the
future
>> because we cannot be sure what the situation will be two years from
> now.
>> These topics were met with opposition against denying known, current
> needs
>> for unknown circumstances in the future.
>>
>> Finally, there are the discussions about rationing the last bits of
> IPv4
>> space by defining what technologies are worthy of receiving the last
> of the
>> unallocated IPv4 resources.
>>
>> So a couple questions come to mind.
>>
>> Of all the methods being discussed, aren't they just rationing in one
> form
>> or another? If so, they why don't we simplify the conversation and
> ration
>> the last of the IP space by size and timeframe without all the
> requirements
>> on an organization that add to the overhead of ARIN staff? Wouldn't
> the end
>> result be the same?
>
> I don't think it would be the same. They key difference in the
> proposals currently on the table and pure rationing (with no technical
> requirements) is the focus on transitioning to IPv6.
>
>> Should ARIN be defining topologies or technologies for an
> organization? Many
>> argued strongly in the past against this direction. How much will
> really be
>> accomplished fine tuning the use of the last 0.4% of the IPv4 space
> compared
>> to how the other 99.996% is being used?
>
> ARIN should not define topologies or technologies, no. But... If ARIN
> is going to restrict a block of addresses to "transitional
> technologies" than it probably makes sense to define or at least
> explain through example what is meant by "transitional technology."
> Defining a term is not quite the same as defining the specific
> technology or topology to be used. Also - the fight against ARIN
> getting involved in operational matters is a valid one but not one
> that we can take to either extreme. As has also been discussed many
> times before, minimum and maximum allocations and assignments define
> operational practices to some extent, as does efficient utilization
> requirements, needs based justification, etc. There is a balance that
> must be maintained, not an absolute law to be followed. Internet
> stewardship should be the guiding beacon, and sometimes that means
> dipping our toes into issues that have effects on operational
> practice.
>
> To your second point; I would reverse the question: How much will we
> gain by allowing the last 0.4% of the IPv4 space be used just like the
> other 99.996%? Once we level set, then we can ask how much can we gain
> by tweaking the use of that same space. In that context, I think it is
> clear that the bigger win is in tuning the use, rather than taking our
> hands off the wheel.
>
>> Are some forms of rationing more acceptable than others? I'm curious
> if
>> there are some who are opposed to outright rationing but find putting
>> requirements on technologies as an acceptable middle ground? What do
> they
>> feel is the difference or the compromise?
>
> The goal is not to slow the usage of the last piece of unallocated
> IPv4 space (rationing), the focus is on leveraging that last piece to
> accelerate the adoption of IPv6 and the (re)homogenization of the
> Internet (technical restrictions).
>
> $0.02
> ~Chris
>
>> Please let me know your thoughts.
>> Dan Alexander
>> ARIN AC
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
<x-msg://2052/ARIN-PPML@arin.net> ).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net <x-msg://2052/info@arin.net>  if you
experience any issues.
>>
>
> --
> @ChrisGrundemann
> weblog.chrisgrundemann.com
> www.burningwiththebush.com
> www.coisoc.org
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
<x-msg://2052/ARIN-PPML@arin.net> ).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net <x-msg://2052/info@arin.net>  if you
experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100804/bbf73026/attachment.htm>
-------------- next part --------------
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.