[arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers
David Farmer
farmer at umn.edu
Thu Jan 18 19:32:14 EST 2018
Looking at this a little more closely;
Section 8.5.4 has a common size for both initial allocations and
assignments or in other words an initial transfer size of /24.
Whereas in section 4 the initial allocations and assignments sizes differ;
with section 4.2.2 having an initial ISP allocation size of /21 and section
4.3.2 having an initial end-user assignment size of /24.
So, I believe the easiest way to harmonize section 4 and 8 is to harmonize
section 4.2.2 with section 4.3.2 at /24.
Otherwise, we need to make section 8 more complicated and distinguishing
between initial allocations and assignments sizes.
So which way should we go?
Thanks.
On Thu, Jan 18, 2018 at 5:17 PM, Owen DeLong <owen at delong.com> wrote:
> Well, section 4 doesn’t govern transfers since we decoupled it anyway, so
> I’m not sure if we want to make staff behavior consistent or not. I would
> argue that moving the transfer boundary to /21 would make more sense than
> moving the section 4 boundary to /24, if we are going to synchronize them.
>
> However, as you point out, transfers are governed by 8.5.5 and only free
> pool is governed by section 4 unless section 4 is referenced by section 8.
>
> As you may recall, I opposed this decoupling because of the confusion and
> disparity in protocol I expected to result. Now we’re exactly where I
> predicted we’d be.
>
> Owen
>
> On Jan 18, 2018, at 3:03 PM, David Farmer <farmer at umn.edu> wrote:
>
> From the updated problem statement: If an organization applies under
> section 8 first they are initially qualified for a /24, larger allocations
> require additional documentation as noted in 8.5.5.
>
> Again, whether a change in policy or staff practice, what do we want to
> happen?
>
> On Thu, Jan 18, 2018 at 4:38 PM, Owen DeLong <owen at delong.com> wrote:
>
>> The existing language “up to a /21” is consistent with staff allowing you
>> to obtain a /24 via transfer.
>>
>> Are you telling me that staff is refusing /21 transfers, but allowing /24
>> transfers to new ISPs without further justification? If so, I would argue
>> that current staff practice is in error vs. policy language.
>>
>> Owen
>>
>> On Jan 18, 2018, at 2:37 PM, David Farmer <farmer at umn.edu> wrote:
>>
>> Owen,
>>
>> Yep, that was an editing error, it should have been;
>>
>> 4.2.2. Initial allocation to ISPs
>>
>> All ISP organizations without direct assignments or allocations from ARIN
>> qualify for an initial allocation of a /24. Organizations may qualify for a
>> larger initial allocation by documenting how the requested allocation will
>> be utilized within 24 months.
>>
>> On Thu, Jan 18, 2018 at 4:26 PM, Owen DeLong <owen at delong.com> wrote:
>>
>>> I see no reason to move the boundary for an ISP initial allocation from
>>> /21 to /24.
>>>
>>
>> Well that seems to be staff intrupretation if you are getting an initial
>> allocation via a transfer, how would you reslove this then?
>>
>> Thanks.
>>
>>
>>> I certainly see no reason for “up to a /24” as there’s nothing smaller
>>> available and even if it were, it wouldn’t be useful in any foreseeable
>>> environment.
>>>
>>> Owen
>>>
>>> On Jan 18, 2018, at 2:21 PM, David Farmer <farmer at umn.edu> wrote:
>>>
>>> David,
>>>
>>> The resolution you suggest below seems like a different policy proposal
>>> to me, one with a significantly broader scope than this draft policy has.
>>> But I think it is a valid question for the community to consider, it's just
>>> not really the problem statement in question for this Draft Policy.
>>>
>>> So, back within the scope of this Draft Policy as the shepherd, I plan
>>> to push forward Andrew's updated Problem Statement with a Policy Statement
>>> that harmonizes and simplifies the text in section 4.2.2 as an official
>>> update to this Draft Policy to get the conversation moving again.
>>>
>>> The current text of 4.2.2 is;
>>>
>>> 4.2.2. Initial allocation to ISPs
>>>
>>> All ISP organizations without direct assignments or allocations from
>>> ARIN qualify for an initial allocation of up to a /21, subject to ARIN's
>>> minimum allocation size. Organizations may qualify for a larger initial
>>> allocation by documenting how the requested allocation will be utilized
>>> within 24 months. ISPs renumbering out of their previous address space will
>>> be given a reasonable amount of time to do so, and any blocks they are
>>> returning will not count against their utilization.
>>>
>>> The text "subject to ARIN's minimum allocation size" seems extraneous.
>>> And, post runout renumbering and returning any address space
>>> seems unlikely, so let's just eliminate that whole sentence.
>>>
>>> I propose we simplify that to the following;
>>>
>>> 4.2.2. Initial allocation to ISPs
>>>
>>> All ISP organizations without direct assignments or allocations from
>>> ARIN qualify for an initial allocation of up to a /24. Organizations may
>>> qualify for a larger initial allocation by documenting how the requested
>>> allocation will be utilized within 24 months.
>>>
>>> Below is the policy update that results;
>>>
>>> Thanks
>>>
>>> --------
>>>
>>> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4
>>> ISP Transfers
>>>
>>> Problem Statement:
>>>
>>> It was noted in the ARIN 40 Policy Experience Report, that there is an
>>> inconsistency in the initial block size for ISPs. Section 4.2.2 notes that
>>> the initial ISP block size should be /21 whereas the initial block size in
>>> 8.5.4 is noted as "minimum transfer size" which is effectively a /24. This
>>> causes ISP organizations to be approved for different initial block size
>>> depending on if they first apply for a transfer directly under section 8 or
>>> if they apply for a block under section 4. This policy is intended to
>>> clarify this issue, by setting a consistent ISP initial IPv4 block size. It
>>> was noted that ARIN staff current operational practice is to allow
>>> qualified ISPs an initial /21 for Section 8 transfers when they first apply
>>> and are approved under section 4. If an organization applies under section
>>> 8 first they are initially qualified for a /24, larger allocations require
>>> additional documentation as noted in 8.5.5.
>>>
>>> Policy Statement:
>>>
>>> Change section 4.2.2 as follows;
>>>
>>> 4.2.2. Initial allocation to ISPs
>>>
>>> All ISP organizations without direct assignments or allocations from
>>> ARIN qualify for an initial allocation of up to a /24. Organizations may
>>> qualify for a larger initial allocation by documenting how the requested
>>> allocation will be utilized within 24 months.
>>>
>>> Comments:
>>>
>>> Timetable for implementation: Immediate
>>>
>>>
>>> On Thu, Dec 7, 2017 at 11:37 PM, David Huberman <daveid at panix.com> wr
>>> ote:
>>>
>>>> Thank you for the clarification. I think the staff practice is a
>>>> reasonable approach and I don’t think change is needed in policy for this.
>>>>
>>>> The updated Problem Statement reveals the real issue here - the one we
>>>> need to figure out as a community. What to do about all the requests each
>>>> month for IPv4 addresses under section 4?
>>>>
>>>> Is it time to pass a policy to direct staff to no longer accept section
>>>> 4 requests (except the ones they still fill like critical infrastructure)?
>>>> I wonder what the downside of such a policy would be - anyone know?
>>>>
>>>>
>>>>
>>>> On Dec 7, 2017, at 11:47 PM, Andrew Dul <andrew.dul at quark.net> wrote:
>>>>
>>>> It was noted to me by ARIN staff, that this updated problem statement
>>>> doesn't accurately reflect ARIN's current practice. Below I suggest
>>>> another updated problem statement.
>>>>
>>>> *Problem Statement: *
>>>> It was noted at the ARIN 40 Policy Experience Report, that there is an
>>>> inconsistency in the initial block size for ISPs. Section 4.2.2 notes that
>>>> the initial ISP block size should be /21 whereas the initial block size in
>>>> 8.5.4 is noted as "minimum transfer size" which is effectively a /24. This
>>>> causes ISP organizations to be approved for different initial block size
>>>> depending on if they first apply apply for a transfer directly under
>>>> section 8 or if they apply for a block under section 4. This policy is
>>>> intended to clarify this issue, by setting a consistent ISP initial IPv4
>>>> block size. It was noted that ARIN staff current operational practice is to
>>>> allow qualified ISPs an initial /21 for Section 8 transfers when they first
>>>> apply and are approved under section 4. If an organization applies under
>>>> section 8 first they are initially qualified for a /24, larger allocations
>>>> require additional documentation as noted in 8.5.5.
>>>>
>>>>
>>>
>>>
>>> --
>>> ===============================================
>>> David Farmer Email:farmer at umn.edu
>>> Networking & Telecommunication Services
>>> Office of Information Technology
>>> University of Minnesota
>>> 2218 University Ave SE
>>> <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g>
>>> Phone: 612-626-0815 <(612)%20626-0815>
>>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952>
>>> ===============================================
>>> _______________________________________________
>>> 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.
>>>
>>>
>>>
>>
>>
>> --
>> ===============================================
>> David Farmer Email:farmer at umn.edu
>> Networking & Telecommunication Services
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SE
>> <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g>
>> Phone: 612-626-0815 <(612)%20626-0815>
>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952>
>> ===============================================
>>
>>
>>
>
>
> --
> ===============================================
> David Farmer Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE
> <https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g>
> Phone: 612-626-0815 <(612)%20626-0815>
> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952>
> ===============================================
>
>
>
--
===============================================
David Farmer Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20180118/7ec730a4/attachment.htm>
More information about the ARIN-PPML
mailing list