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

Alexander, Daniel Daniel_Alexander at Cable.Comcast.com
Mon Aug 2 21:58:05 EDT 2010


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> 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
>> > 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> 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).
>>> >> 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.
>>> >>
>> >
>> > --
>> > @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).
>> > 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.
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100802/1a4131b0/attachment.htm>


More information about the ARIN-PPML mailing list