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

Wed Aug 4 09:59:35 EDT 2010

Owen,

I “signed” the petition as you saw. I wanted to point out that it is because of the compromises that you have included. I’m still not convinced that it has gone far enough yet, but it is progress. Changes are still required from my perspective, but we should try to get something done this meeting and not the next.

Best,

-M<

On 8/4/10 12:40 AM, "Owen DeLong" <owen at delong.com> wrote:

My intent in 116 was not so much to create a list as to use a list of examples
as the best tool I had available for defining the functionality and depend on
staff discretion beyond that. Hence the unfortunately vague choice of terms
like "etc." and "technologies not envisioned at the time of this proposal".

I certainly would be happy to amend 116 if anyone has better ways to specify
this.

FWIW, by my count, only 2 more signatures are needed in order for 116 to
see discussion in Atlanta. There is still time to sign the petition.

Even if you do not feel that 116 as currently written is the best policy we can get,
discussing 116 in Atlanta is likely the only chance to do something other than
the current state of 4.10 prior to runout. I am extremely amenable to making
reasonable changes to 116 in order to gain broader community support.

Owen

On Aug 3, 2010, at 7:33 PM, Alexander, Daniel wrote:

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 <http://weblog.chrisgrundemann.com/>
> www.burningwiththebush.com <http://www.burningwiththebush.com/>
> www.coisoc.org <http://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/e00c27c7/attachment.htm>