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

Mon Aug 2 23:16:11 EDT 2010

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> 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/c9e8347d/attachment.htm>