[arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers
David Farmer
farmer at umn.edu
Fri Jan 19 15:23:11 EST 2018
For additional background, see the ARIN 40 Policy Experience Report;
Slides 10 - 13, and on the video from 6:30 to 8:30, questions follow.
Slides: https://www.arin.net/vault/participate/meetings/reports/ARIN
_40/PDF/PPM/sweeting-policy-experience.pdf
Transcript: https://www.arin.net/vault/participate/meetings/
reports/ARIN_40/ppm1_transcript.html#anchor_5
Video: https://www.youtube.com/watch?v=QVsfVMG_6fA
On Fri, Jan 19, 2018 at 11:11 AM, Jason Schiller <jschiller at google.com>
wrote:
> Can you clarify the problem (I'm confused).
>
I think you summrized it well, there is a inconsistency between 4.2.2 and
8.5.4 for ISPs, but 4.3.2 and 8.5.4 are consistent for end-users.
What do we want to do about it?
> What I expect to happen and an ISP under 4.2.2 can get an initial
> allocation of between a /24 and a /21 inclusive.
> They will be slow started because they have no history. They can get a 2
> year supply, and will need to make it
> 80% utilized before they can come back for more..
>
> Utilized means:
>
> - If an IP block is allocated/assigned to a customer and one of the
> following is true:
> - the customer can show justification for 25% utilization in 30 days
> 50% in 1 year
> - the customer can show a discreet multi-homing requirement each /24
> - the residential market area IP block is at least 50% utilized
> - the residential market area is TPIA and
> - initial assignments to each piece of hardware is the smallest
> possible
> - additional assignments to each piece of hardware only made after
> 80% utilization
> - additional assignments to each piece of hardware is not more than
> a 2 year supply
>
> Then that space is considered 100% utilized
>
> IP space in use by the ISP is counted as utilized.
> This includes network and broadcast addresses for subsets in use.
>
>
> Under 8.5.4
> They can transfer pre-approval for a /24 no questions asked if they have
> no direct IPv4.
>
> If they have a direct IPv4, or want pre-approval for more than a /24 then
> they
> need to show how they will use 50% of the requested space in 24 months.
>
>
>
> What is weird is post last /8, ISP could only get a 90 day supply on slow
> start and then
> had to come back. So request for ARIN space were 1/8 the size (90 days)
> of what could
> be request on the transfer market (2 years). We adjusted this back to a
> two year supply to
> mirror the transfer window of time and simplify things (which I opposed at
> the time,
> but now that it is changed standby it).
>
> ___Jason
>
>
>
>
>
>
> On Thu, Jan 18, 2018 at 7:33 PM, Owen DeLong <owen at delong.com> wrote:
>
>> We could also simplify section 8 to state that the minimum transfer size
>> is /24 and that initial requests for transfer are governed by officer
>> attestation limits unless a larger size is needed.
>>
>> Owen
>>
>> On Jan 18, 2018, at 4:32 PM, David Farmer <farmer at umn.edu> wrote:
>>
>>
>> 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
>> <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.
>>
>
>
>
> --
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006>
>
>
--
===============================================
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 <(612)%20626-0815>
Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952>
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20180119/01f649fc/attachment.htm>
More information about the ARIN-PPML
mailing list