[arin-ppml] Draft Policy ARIN 2020-3

Chris Woodfield chris at semihuman.com
Mon Oct 12 20:09:26 EDT 2020


Scott - can confirm from my own experience you are correct. An end-user that signs to the RSP is considered an ISP from both a fee and policy perspective, and as John stated, is a one-way conversion. As mentioned previously, the ability to utilize SWIP to reassign blocks need not be in an ISP-to-customer context; there are a number of reasons an organization may wish to publish SWIP data for blocks assigned internally. 

Hope this clarifies things :)

-C

> On Oct 12, 2020, at 4:44 PM, scott at solarnetone.org wrote:
> 
> Thanks for the clarification, John.
> 
> On Mon, 12 Oct 2020, John Sweeting wrote:
> 
>> 
>> 
>> On 10/12/20, 7:09 PM, "ARIN-PPML on behalf of Andrew Dul" <arin-ppml-bounces at arin.net on behalf of andrew.dul at quark.net> wrote:
>> 
>>   On 10/12/2020 3:40 PM, scott at solarnetone.org wrote:
>>   > Hi Andrew,
>>   >
>>   >>>
>>   >>> Unfortunately, the only way to have redundancy in your upstream while
>>   >>> keeping connectivity to your network address is to be an ISP by this
>>   >>> definition, even if you offer no network services to other
>>   >>> organizations.
>>   >>> This is because an AS is required to perform BGP, which is critical to
>>   >>> maintaining connectivity to a multi-homed network through outage of
>>   >>> one or more connected circuits.
>>   >>
>>   >>
>>   >> ARIN's definition of ISP/end-user is related to the services ARIN offers
>>   >> to an organization and may not be specifically tied to a "classic"
>>   >> definition of an ISP.
>>   >
>>   > Precisely what I was trying, if failing, to express.  David's post
>>   > clarified the delineation.  I see from the NRPM that there is a minor
>>   > difference in fee schedule too.  For example, an end user with a /44
>>   > or /48 of v6, a /24 of v4, and an ASN would pay approximately
>>   > $200/year more than a 3x-small, and $50 less than a 2x-small.
>>   >
>>   > This applies, however, only to those who do not subscribe to the
>>   > Registration Services Plan, if I understand correctly, as subscribing
>>   > to said plan converts one from End User to ISP automatically.
>>   > Needless to say, there are organizations that are end users by
>>   > functional definition here, but subscribe to the service plan, and/or
>>   > choose to be an ISP for other reasons.
>> 
>>   My understanding is that subscribing to 'Registration Services Plan'
>>   does not change you from an end-user to ISP, it just gives you access to
>>   the services available under that plan and the resulting fee schedule.
>>   You can presumably decide to go back to classic 'pay by the resource
>>   option' as an end-user if you didn't need the extra services or
>>   preferred the alternate fee calculation.
>> 
>> (JS) Converting to an Registration Services Plan is a one time, one way action. There is no converting back to EU 'pay by the resource option' once an organization has completed actions necessary to convert to Registration Services Plan.
>> 
>> 
>>   >
>>   >>
>>   >>
>>   >>>
>>   >>>>
>>   >>>> An end-user organization who would be eligible to obtain an /48 under
>>   >>>> 6.5.8 of the NRPM.
>>   >>>>
>>   >>>> https://www.arin.net/participate/policy/nrpm/#6-5-8-direct-assignments-from-arin-to-end-user-organizations
>>   >>>>
>>   >>>>
>>   >
>>   > True, but I was referring to protocol version agnostic multi-homing.
>>   > Would an end user also qualify for 4.10 v4 space by requesting a /44
>>   > or /48 directly from ARIN?
>>   >
>>   I believe the answer is yes, 4.10, is agnostic to your ISP/End-user
>>   status w/ ARIN.
>> 
>>   >>>>
>>   >>>> This draft policy ARIN-2020-3 is specifically related to ISPs.
>>   >>>
>>   >>> I believe you are making a misclassification here.  Once these
>>   >>> organizations have AS and/or address resources, they are considered an
>>   >>> ISP for these purposes, despite their end use case.
>>   >>
>>   >> I disagree, others feel free to correct me.
>>   >
>>   > You are right.  Pardon my confusion.
>>   >
>>   > Scott
>>   >
>>   >
>>   >>
>>   >>
>>   >>
>>   >>>>
>>   >>>>
>>   >>>>>>
>>   >>>>>> Andrew
>>   >>>>>>
>>   >>>>>> On 10/12/2020 12:26 PM, scott at solarnetone.org wrote:
>>   >>>>>>> Hi Chris,
>>   >>>>>>>
>>   >>>>>>> I wonder what percentage of 2x-small Resource holders have a /24 of
>>   >>>>>>> v4, and would otherwise qualify for 3x-small status but for
>>   >>>>>>> their v6
>>   >>>>>>> allocations, and what percentage of all ASs registered with ARIN
>>   >>>>>>> that
>>   >>>>>>> represents.  This represents the the total who could "downgrade"
>>   >>>>>>> to a
>>   >>>>>>> nano-allocation, were that a option.  It would be easy to derive
>>   >>>>>>> from
>>   >>>>>>> that the maximum effect on ARIN's finances, if they all chose to
>>   >>>>>>> take
>>   >>>>>>> that option.
>>   >>>>>>>
>>   >>>>>>> Scott
>>   >>>>>>>
>>   >>>>>>> On Mon, 12 Oct 2020, Chris Woodfield wrote:
>>   >>>>>>>
>>   >>>>>>>> Agreed. To be clear, I did not intend for my question to imply
>>   >>>>>>>> that
>>   >>>>>>>> the goal of keeping the proposal revenue-neutral was in any way
>>   >>>>>>>> dishonorable - ARIN’s financial stability is obviously in the
>>   >>>>>>>> community’s best interests. But we should have informed consent
>>   >>>>>>>> as to
>>   >>>>>>>> how that stability is achieved, and as such, clarifying the
>>   >>>>>>>> intention
>>   >>>>>>>> of the clause is helpful.
>>   >>>>>>>
>>   >>>>>>>
>>   >>>>>>>
>>   >>>>>>>>
>>   >>>>>>>> Thanks,
>>   >>>>>>>>
>>   >>>>>>>> -C
>>   >>>>>>>>
>>   >>>>>>>>> On Oct 12, 2020, at 11:06 AM, scott at solarnetone.org wrote:
>>   >>>>>>>>>
>>   >>>>>>>>> Hi Chris,
>>   >>>>>>>>>
>>   >>>>>>>>> Indeed.  To be fair, I think the price is fair for value
>>   >>>>>>>>> received,
>>   >>>>>>>>> speaking as a 2x-small ISP with a /36.  I was able to lower my
>>   >>>>>>>>> recurring costs and increase my available address pool by
>>   >>>>>>>>> bringing
>>   >>>>>>>>> up an AS at the 2x-small rate.  Allowing the smallest ISPs to
>>   >>>>>>>>> implement IPv6 without additional financial cost seems a prudent
>>   >>>>>>>>> way
>>   >>>>>>>>> to overcome barriers to adoption.
>>   >>>>>>>>>
>>   >>>>>>>>> Scott
>>   >>>>>>>>>
>>   >>>>>>>>> On Sun, 11 Oct 2020, Chris Woodfield wrote:
>>   >>>>>>>>>
>>   >>>>>>>>>> Thanks Andrew, and good catch - both Scott and I missed that
>>   >>>>>>>>>> clause, obviously. It appears that this is in place in order to
>>   >>>>>>>>>> meet the stated goal of this proposal being revenue-neutral for
>>   >>>>>>>>>> ARIN? If so, it would be great to clarify so that community
>>   >>>>>>>>>> members
>>   >>>>>>>>>> can make a more informed evaluation as to whether or not to
>>   >>>>>>>>>> support
>>   >>>>>>>>>> the clause. If there are other justifications for the clause’s
>>   >>>>>>>>>> presence, I’d be interested to hear them.
>>   >>>>>>>>> 2~>
>>   >>>>>>>>>> Thanks,
>>   >>>>>>>>>>
>>   >>>>>>>>>> -C
>>   >>>>>>>>>>
>>   >>>>>>>>>>> On Oct 11, 2020, at 10:24 AM, Andrew Dul <andrew.dul at quark.net>
>>   >>>>>>>>>>> wrote:
>>   >>>>>>>>>>>
>>   >>>>>>>>>>> The current draft policy text disallows returns to lower than a
>>   >>>>>>>>>>> /36, so
>>   >>>>>>>>>>> I would say that organization which took a /36 would not be
>>   >>>>>>>>>>> permitted to
>>   >>>>>>>>>>> go down to a /40.
>>   >>>>>>>>>>>
>>   >>>>>>>>>>> "Partial returns of any IPv6 allocation that results in less
>>   >>>>>>>>>>> than
>>   >>>>>>>>>>> a /36
>>   >>>>>>>>>>> of holding are not permitted regardless of the ISP’s current or
>>   >>>>>>>>>>> former
>>   >>>>>>>>>>> IPv4 number resource holdings."
>>   >>>>>>>>>>>
>>   >>>>>>>>>>> Andrew
>>   >>>>>>>>>>>
>>   >>>>>>>>>>> On 10/9/2020 2:04 PM, Chris Woodfield wrote:
>>   >>>>>>>>>>>> Hi Scott,
>>   >>>>>>>>>>>>
>>   >>>>>>>>>>>> Given that ARIN utilizes a sparse allocation strategy for IPv6
>>   >>>>>>>>>>>> resources (in my organization’s case, we could go from a /32
>>   >>>>>>>>>>>> to a
>>   >>>>>>>>>>>> /25 without renumbering), IMO it would not be unreasonable for
>>   >>>>>>>>>>>> the allocation to be adjusted down simply by changing the mask
>>   >>>>>>>>>>>> and keeping the /36 or /32 unallocated until the sparse
>>   >>>>>>>>>>>> allocations are exhausted. Any resources numbered outside the
>>   >>>>>>>>>>>> new
>>   >>>>>>>>>>>> /40 would need to be renumbered, to be sure, but that’s most
>>   >>>>>>>>>>>> likely less work than a complete renumbering.
>>   >>>>>>>>>>>>
>>   >>>>>>>>>>>> That said, I’ll leave it up to Registration Services to
>>   >>>>>>>>>>>> provide a
>>   >>>>>>>>>>>> definitive answer.
>>   >>>>>>>>>>>>
>>   >>>>>>>>>>>> -C
>>   >>>>>>>>>>>>
>>   >>>>>>>>>>>>> On Fri, 9 Oct 2020, scott at solarnetone.org wrote:
>>   >>>>>>>>>>>>>
>>   >>>>>>>>>>>>>> Hi All,
>>   >>>>>>>>>>>>>>
>>   >>>>>>>>>>>>>> I am in favor of this draft, and am curious as to how
>>   >>>>>>>>>>>>>> resource
>>   >>>>>>>>>>>>>> holders who were not dissuaded by the fee increase will be
>>   >>>>>>>>>>>>>> impacted by the policy change. While they indeed have more
>>   >>>>>>>>>>>>>> address space than /40, they may also not need the
>>   >>>>>>>>>>>>>> additional
>>   >>>>>>>>>>>>>> address space.  Some might prefer the nano-allocation given
>>   >>>>>>>>>>>>>> the
>>   >>>>>>>>>>>>>> lower cost.  Will they be required to change allocations,
>>   >>>>>>>>>>>>>> and
>>   >>>>>>>>>>>>>> renumber, in order to return to 3x-small status and
>>   >>>>>>>>>>>>>> associated
>>   >>>>>>>>>>>>>> rate?
>>   >>>>>>>>>>>>>>
>>   >>>>>>>>>>>>>> Scott Johnson
>>   >>>>>>>>>>>>>> SolarNetOne, Inc.
>>   >>>>>>>>>>>>>> AS32639
>>   >>>>>>>>>>>>>> _______________________________________________
>>   >>>>>>>>>>>>>> ARIN-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:
>>   >>>>>>>>>>>>>> https://lists.arin.net/mailman/listinfo/arin-ppml
>>   >>>>>>>>>>>>>> Please contact info at arin.net if you experience any issues.
>>   >>>>>>>>>>>>>>
>>   >>>>>>>>>>>>> _______________________________________________
>>   >>>>>>>>>>>>> ARIN-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:
>>   >>>>>>>>>>>>> https://lists.arin.net/mailman/listinfo/arin-ppml
>>   >>>>>>>>>>>>> Please contact info at arin.net if you experience any issues.
>>   >>>>>>>>>>>>>
>>   >>>>>>>>>>>> _______________________________________________
>>   >>>>>>>>>>>> ARIN-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:
>>   >>>>>>>>>>>> https://lists.arin.net/mailman/listinfo/arin-ppml
>>   >>>>>>>>>>>> Please contact info at arin.net if you experience any issues.
>>   >>>>>>>>>>>
>>   >>>>>>>>>>>
>>   >>>>>>>>>>
>>   >>>>>>>>
>>   >>>>>>>>
>>   >>>>>>
>>   >>>>>>
>>   >>>>
>>   >>>>
>>   >>
>>   >>
>> 
>>   _______________________________________________
>>   ARIN-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:
>>   https://lists.arin.net/mailman/listinfo/arin-ppml
>>   Please contact info at arin.net if you experience any issues.
>> 
>> 
> _______________________________________________
> ARIN-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:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.




More information about the ARIN-PPML mailing list