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 structure (William Herrin)
2. Re: Draft Policy ARIN-2013-2: 3GPP Network IP Resource Policy
(Masato Yamanishi)
3. Re: fee structure (John Curran)
4. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(David Farmer)
5. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(John Curran)
6. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(David Farmer)
----------------------------------------------------------------------
Message: 1
Date: Fri, 29 Mar 2013 14:16:40 -0400
From: William Herrin <[email protected]>
To: McTim <[email protected]>
Cc: [email protected]
Subject: Re: [arin-ppml] fee structure
Message-ID:
<cap-gugv9dtgo+egfngs4meeqehdnyapwmwzqnddj+mquhgf...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Mar 29, 2013 at 12:55 PM, McTim <[email protected]> wrote:
> AFAIK, folk involved in resource policy making don't "vote" on the
> policies, it is done by consensus.
Hi,
This is not correct. In fact, the word "consensus" appears only twice
in the current policy development process document, one of those in
the following context: "If consensus is not achieved [...] the
President may facilitate the selection process."
In practice, a policy is adopted through a series of votes: several by
the advisory council followed by a final vote by the board of
trustees. The members of the board and advisory council are in turn
elected by a vote only of ARIN's members.
Policy proposals are informed by public input and public debate and
often originate from non-ARIN members. But procedurally, adopting
policy is not bound to adhere to the prevailing public viewpoint,
either directly or through representation.
Regards,
Bill Herrin
--
William D. Herrin ................ [email protected] [email protected]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
------------------------------
Message: 2
Date: Fri, 29 Mar 2013 11:11:47 -0700
From: Masato Yamanishi <[email protected]>
To: Scott Leibrand <[email protected]>
Cc: ARIN-PPML List <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-2: 3GPP Network IP
Resource Policy
Message-ID: <cd7b25d0.3ec28%[email protected]>
Content-Type: text/plain; charset="UTF-8"
Scott,
Can we assume it intends to change the IPv4 policy only?
Though the problem statement describes about IPv4,
the policy statement doesn't specify IPv4 or both.
Rgs,
---
Masato Yamanishi
Softbank Telecom America (former Japan Telecom America)
On 13/03/27 12:41, "William Herrin" <[email protected]> wrote:
>On Wed, Mar 27, 2013 at 2:32 PM, Scott Leibrand <[email protected]>
>wrote:
>> As one of the AC shepherds for the policy, I am hoping to have a
>>discussion,
>> both here on PPML at at the upcoming ARIN meeting, to cover a few key
>> points:
>>
>> - Is the problem statement clear to the community?
>
>Yes. Existing software limitations make it difficult to impossible to
>run a reliable 3GPP network at greater than around 40% utilization of
>addresses versus connected subscribers. Current ARIN standards require
>80% (?) utilization.
>
>> - Do you feel that it is an important problem to try to solve?
>
>Yes.
>
>> - If so, how would you prefer we approach solving it?
>
>Dual stack: IPv4 CGN plus IPv6.
>
>This problem is not unique to 3GPP architectures. Virtually every
>eyeball network has a version this problem with similarly scoped
>technical limitations. The ship sailed on solving it with more IPv4
>addresses years ago. What's "special" here that makes it any different
>from everybody else's unmet need?
>
>Regards,
>Bill Herrin
>
>
>--
>William D. Herrin ................ [email protected] [email protected]
>3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
>Falls Church, VA 22042-3004
>_______________________________________________
>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.
------------------------------
Message: 3
Date: Fri, 29 Mar 2013 18:44:53 +0000
From: John Curran <[email protected]>
To: William Herrin <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] fee structure
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="Windows-1252"
On Mar 29, 2013, at 2:16 PM, William Herrin <[email protected]> wrote:
> In practice, a policy is adopted through a series of votes: several by
> the advisory council followed by a final vote by the board of
> trustees. The members of the board and advisory council are in turn
> elected by a vote only of ARIN's members.
>
> Policy proposals are informed by public input and public debate and
> often originate from non-ARIN members. But procedurally, adopting
> policy is not bound to adhere to the prevailing public viewpoint,
> either directly or through representation.
Bill -
That is not correct.
Under the Policy Development Process (which is adopted by the ARIN Board
and binding on participants in the process, including the ARIN Advisory
Council), draft policies are to be "supported by the community" and
documented accordingly in order for the AC to recommend for adoption -
<https://www.arin.net/policy/pdp.html>
> 4. Recommendation of Draft Policies
>
> The Advisory Council develops and refines Draft Policies until they are
> satisfied that the Draft Policy meets ARIN's Principles of Internet Number
> Resource Policy (Part One, Section 4). Specifically, these principles are:
> ? Enabling Fair and Impartial Number Resource Administration
> ? Technically Sound
> ? Supported by the Community
> Guided by the discussion of the Draft Policy on the PPML, Public Policy
> Consultations with the community (if any) and its best judgment, the AC
> assesses the conformance of each Draft Policy to these principles and
> documents the result in an assessment section within the Draft Policy. ...
This is then confirmed as a result of a Public Policy Meeting and public
Last call before the policy is send to the ARIN Board of Trustees for
ratification. The Board routinely confirms the community support during
its review of the policy's development process before ratifying policy
changes.
The AC is _bound_ by adopted processes to recommend policies _supported
by the community_ and the Board serves to confirm that this occurs.
Thanks,
/John
John Curran
President and CEO
ARIN
------------------------------
Message: 4
Date: Fri, 29 Mar 2013 13:47:41 -0500
From: David Farmer <[email protected]>
To: Brandon Ross <[email protected]>
Cc: ARIN PPML <[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; format=flowed
On 3/29/13 10:37 , Brandon Ross wrote:
> On Thu, 28 Mar 2013, David Farmer wrote:
>
>> I'd change that a little and add another subsection;
>>
>> 6.5.2.1(g): An LIR that requested a /36 or /40 initial allocation is
>> entitled to increase said allocation's size to /36 or /32. This
>> change is not a subsequent allocation as described in 6.5.3.
>> Additionally, a minimum of a /32 will be reserved for all such LIRs to
>> facilitate this expansion.
>
> I'm good with that.
>
>> 6.5.2.1(h): An LIR that received a /32 initial allocation before the
>> availability of the /36 and /40 initial allocation sizes is entitled
>> to a one-time decrease of their allocation size to /36 or /40. Such
>> an LIR will retain the first (lowest numbered) subnet or the last
>> (highest numbered) subnet of their original block.
>
> What benefit does it give the community to limit reduction in allocation
> size to only those that were issued earlier and only once? I am against
> that change as plenty of organizations may make initial errors in their
> allocation requests and might want to move back to a smaller size later.
The primary issue I want to avoid people going up and down several
times. I guess we don't need restrict it to people who received a /32
before the /36 or /40 were available. So, I'd be OK everyone having one
opportunity to reduce form /32 to /36 or /40.
Unless you intended to create a generic ability to reduce your
allocations that would apply to everyone and not just to the x-small and
xx-small categories. But that wasn't explicitly clear, and I took it
that it was intended to allow low end adjustments. I'd like other to
weigh in on if there should be a generic ability to reduce your IPv6
allocation.
--
================================================
David Farmer Email: [email protected]
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 1-612-626-0815
Minneapolis, MN 55414-3029 Cell: 1-612-812-9952
================================================
------------------------------
Message: 5
Date: Fri, 29 Mar 2013 19:05:13 +0000
From: John Curran <[email protected]>
To: David Farmer <[email protected]>
Cc: ARIN PPML <[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="us-ascii"
On Mar 29, 2013, at 2:47 PM, David Farmer <[email protected]> wrote:
> The primary issue I want to avoid people going up and down several times.
Why would this be expected, and/or a concern?
> I guess we don't need restrict it to people who received a /32 before the
> /36 or /40 were available. So, I'd be OK everyone having one opportunity to
> reduce form /32 to /36 or /40.
The challenge, of course, is that circumstances do change, and (for example)
a party that thought it wanted to move up to /32 might change its mind a year
later...
ARIN is here to serve the community, so the normal response to any request
should be "Yes", unless there a clear reason (example, potential impacts
to other parties) that something should be prohibited by policy. Is that
the case here, and can you elaborate on the policy concern that you see?
> Unless you intended to create a generic ability to reduce your allocations
> that would apply to everyone and not just to the x-small and xx-small
> categories. But that wasn't explicitly clear, and I took it that it was
> intended to allow low end adjustments. I'd like other to weigh in on if
> there should be a generic ability to reduce your IPv6 allocation.
Specific policy regarding return of IPv6 space might be necessary if you want
ARIN not to accept returns (or only accept whole blocks and not partial, etc.)
/John
------------------------------
Message: 6
Date: Fri, 29 Mar 2013 14:10:39 -0500
From: David Farmer <[email protected]>
To: William Herrin <[email protected]>
Cc: ARIN PPML <[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; format=flowed
On 3/29/13 12:59 , William Herrin wrote:
> On Thu, Mar 28, 2013 at 9:10 PM, David Farmer <[email protected]> wrote:
>> On 3/28/13 18:04 , William Herrin wrote:
>>> "6.5.2.1(b): In no case shall an LIR receive smaller than a /32
>>> allocation unless they specifically request a /36 or /40. In no case
>>> shall an ISP receive more than a /16 initial allocation.
>>>
>> 6.5.2.1(g): An LIR that requested a /36 or /40 initial allocation is
>> entitled to increase said allocation's size to /36 or /32. This change is
>> not a subsequent allocation as described in 6.5.3. Additionally, a minimum
>> of a /32 will be reserved for all such LIRs to facilitate this expansion.
>
> Hi David,
>
> Isn't that last line business process rather than number policy? The
> first line effectively requires ARIN to reserve or take some other
> action to keep the full /32 available for the LIR's expansion. But the
> last line dictates how: by explicitly reserving the space.
Yes, probably. I added the last sentence to make it abundantly clear,
that is the intended effect of the first sentence. If John and staff
interpret the first sentence as requiring ARIN to reserve a /32 for
anyone with a x-small or xx-small IPv6 allocation, then I would be happy
to remove the last sentence. But, if there is anyway to interpret the
first sentence as not requiring the a hard reservation of a /32 then I
think I'd prefer to leave the sentence in.
What do other think?
Thanks.
--
================================================
David Farmer Email: [email protected]
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 1-612-626-0815
Minneapolis, MN 55414-3029 Cell: 1-612-812-9952
================================================
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 93, Issue 28
*****************************************
