[arin-ppml] ARIN-PPML Digest, Vol 186, Issue 3
Jon Bachtold
jcbach at cirbn.org
Wed Dec 16 09:08:22 EST 2020
Just some quick thoughts. Nothing I would fall on my sword over.
1a. Do you feel that we should place an upper limit on the size of the smaller block
received in the process?
Yes, with an appeal process for unique scenarios.
1b. If so, what should that upper limit be?
Start small, /23 should be enough to get the effort moving, force justification that is easily verifiable for increasing it.
2. Do you support limits on the time period allowed for renumbering?
2a. If so, how long?
6 months to 1 yr depending on type of org and size of small block
2b. If so, what consequences should there be for exceeding the time limit?
Not sure what you can do besides increase billing cost/penalty fee, or provide some kind of allocation hook.
3. Should any additional restrictions or prohibitions be placed on use of waitlist
space in these transactions?
3a. Restrictions on waitlist providing the smaller block?
3b. Restrictions on waitlist space being transferred out?
4. Do you support the policy as currently written?
Yes
5. If not, would you support it with the changes suggested in your answers above?
Jon Bachtold
Chief Technology Officer
CIRBN, LLC
Tel:309-820-7321
Email: jcbach at cirbn.org
Web: www.cirbn.org
200 W Front St, Ste 500A
Bloomington, IL 61701
On 12/16/20, 7:28 AM, "ARIN-PPML on behalf of arin-ppml-request at arin.net" <arin-ppml-bounces at arin.net on behalf of arin-ppml-request at arin.net> wrote:
Send ARIN-PPML mailing list submissions to
arin-ppml at arin.net
To subscribe or unsubscribe via the World Wide Web, visit
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.arin.net%2Fmailman%2Flistinfo%2Farin-ppml&data=04%7C01%7Cjcbach%40cirbn.org%7C8124a7e446db4cba68cc08d8a1c672f4%7C2ea443f603e44fb693494797073fdcad%7C0%7C0%7C637437221002429104%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=991Xc0uGDAb2VIFMB3EA6Gc3b4%2Fqj8d2xBeKzTMH2R0%3D&reserved=0
or, via email, send a message with subject or body 'help' to
arin-ppml-request at arin.net
You can reach the person managing the list at
arin-ppml-owner at arin.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."
Today's Topics:
1. ARIN-2020-6: Allowance for IPv4 Allocation ?Swap?
Transactions via 8.3 Specified Transfers and 8.4 Inter-RIR
Transfers (Owen DeLong)
2. Re: ARIN-2020-6: Allowance for IPv4 Allocation ?Swap?
Transactions via 8.3 Specified Transfers and 8.4 Inter-RIR
Transfers (Mike Burns)
3. Re: ARIN-2020-6: Allowance for IPv4 Allocation ?Swap?
Transactions via 8.3 Specified Transfers and 8.4 Inter-RIR
Transfers (Owen DeLong)
4. Re: Revised - Draft Policy ARIN-2020-8: Clarify and Update
4.2.1.2 Annual Renewal Fee (Owen DeLong)
----------------------------------------------------------------------
Message: 1
Date: Tue, 15 Dec 2020 11:38:00 -0800
From: Owen DeLong <owen at delong.com>
To: arin-ppml <arin-ppml at arin.net>
Subject: [arin-ppml] ARIN-2020-6: Allowance for IPv4 Allocation ?Swap?
Transactions via 8.3 Specified Transfers and 8.4 Inter-RIR Transfers
Message-ID: <27E1506D-3ED8-4797-A2BF-D42B09D991B9 at delong.com>
Content-Type: text/plain; charset=utf-8
Dear ARIN community,
We (the AC, and specifically the proposal shepherds) need to solicit some additional feedback in order to better know the community?s desire with regards to this policy. Specifically, we?d like to ask the following questions:
1a. Do you feel that we should place an upper limit on the size of the smaller block
received in the process?
1b. If so, what should that upper limit be?
2. Do you support limits on the time period allowed for renumbering?
2a. If so, how long?
2b. If so, what consequences should there be for exceeding the time limit?
3. Should any additional restrictions or prohibitions be placed on use of waitlist
space in these transactions?
3a. Restrictions on waitlist providing the smaller block?
3b. Restrictions on waitlist space being transferred out?
4. Do you support the policy as currently written?
5. If not, would you support it with the changes suggested in your answers above?
Thanks for your attention to this matter,
Owen DeLong
ARIN AC
------------------------------
Message: 2
Date: Tue, 15 Dec 2020 16:32:57 -0500
From: "Mike Burns" <mike at iptrading.com>
To: "'Owen DeLong'" <owen at delong.com>, "'arin-ppml'"
<arin-ppml at arin.net>
Subject: Re: [arin-ppml] ARIN-2020-6: Allowance for IPv4 Allocation
?Swap? Transactions via 8.3 Specified Transfers and 8.4 Inter-RIR
Transfers
Message-ID: <037101d6d329$db5bba70$92132f50$@iptrading.com>
Content-Type: text/plain; charset="UTF-8"
Hi Owen,
Thanks for spurring conversation on this proposal.
In my experience those who frequently want to acquire a small block to renumber into are holders of much-larger blocks who can realize higher prices if they sell their much-larger block intact. The market is rewarding larger block sizes with higher unit prices these days.
But how can they justify the small block they need to renumber into, since they usually have many more addresses than they are currently using?
The workaround of a second ORG made it easier for the second ORG to acquire space, as it had none.
But if we just adopt this policy language, the problem of the acquisition of the smaller block remains.
I would likely advise my clients to choose the workaround.
Actually I think the policy intention is good but it should be implemented in a different way.
Recipients of 8.3 or 8.4 transfers can choose an option which avoids any needs-test in exchange for a promise to transfer out eight times the number received within a year. Only one option can be active at a time. These Recipients would be excluded from current source restrictions.
I think the policy needs to consider the justification problem for recipients of the small block they need to renumber into, in addition to the exclusion of these companies from the source restrictions, or it only provides half the reason to avoid the workaround.
(Also I think there should be no needs-tests or source-restrictions as conservation is provided by price and address turnover is not a BAD THING. ?)
Regards,
Mike
-----Original Message-----
From: ARIN-PPML <arin-ppml-bounces at arin.net> On Behalf Of Owen DeLong
Sent: Tuesday, December 15, 2020 2:38 PM
To: arin-ppml <arin-ppml at arin.net>
Subject: [arin-ppml] ARIN-2020-6: Allowance for IPv4 Allocation ?Swap? Transactions via 8.3 Specified Transfers and 8.4 Inter-RIR Transfers
Dear ARIN community,
We (the AC, and specifically the proposal shepherds) need to solicit some additional feedback in order to better know the community?s desire with regards to this policy. Specifically, we?d like to ask the following questions:
1a. Do you feel that we should place an upper limit on the size of the smaller block
received in the process?
1b. If so, what should that upper limit be?
2. Do you support limits on the time period allowed for renumbering?
2a. If so, how long?
2b. If so, what consequences should there be for exceeding the time limit?
3. Should any additional restrictions or prohibitions be placed on use of waitlist
space in these transactions?
3a. Restrictions on waitlist providing the smaller block?
3b. Restrictions on waitlist space being transferred out?
4. Do you support the policy as currently written?
5. If not, would you support it with the changes suggested in your answers above?
Thanks for your attention to this matter,
Owen DeLong
ARIN AC
_______________________________________________
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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.arin.net%2Fmailman%2Flistinfo%2Farin-ppml&data=04%7C01%7Cjcbach%40cirbn.org%7C8124a7e446db4cba68cc08d8a1c672f4%7C2ea443f603e44fb693494797073fdcad%7C0%7C0%7C637437221002429104%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=991Xc0uGDAb2VIFMB3EA6Gc3b4%2Fqj8d2xBeKzTMH2R0%3D&reserved=0
Please contact info at arin.net if you experience any issues.
------------------------------
Message: 3
Date: Tue, 15 Dec 2020 14:34:41 -0800
From: Owen DeLong <owen at delong.com>
To: Mike Burns <mike at iptrading.com>
Cc: arin-ppml <arin-ppml at arin.net>
Subject: Re: [arin-ppml] ARIN-2020-6: Allowance for IPv4 Allocation
?Swap? Transactions via 8.3 Specified Transfers and 8.4 Inter-RIR
Transfers
Message-ID: <1ADF8596-6A61-48AB-B755-222C174E9198 at delong.com>
Content-Type: text/plain; charset=utf-8
> On Dec 15, 2020, at 1:32 PM, Mike Burns <mike at iptrading.com> wrote:
>
> Hi Owen,
>
> Thanks for spurring conversation on this proposal.
>
> In my experience those who frequently want to acquire a small block to renumber into are holders of much-larger blocks who can realize higher prices if they sell their much-larger block intact. The market is rewarding larger block sizes with higher unit prices these days.
>
> But how can they justify the small block they need to renumber into, since they usually have many more addresses than they are currently using?
>
> The workaround of a second ORG made it easier for the second ORG to acquire space, as it had none.
>
> But if we just adopt this policy language, the problem of the acquisition of the smaller block remains.
> I would likely advise my clients to choose the workaround.
>
> Actually I think the policy intention is good but it should be implemented in a different way.
> Recipients of 8.3 or 8.4 transfers can choose an option which avoids any needs-test in exchange for a promise to transfer out eight times the number received within a year. Only one option can be active at a time. These Recipients would be excluded from current source restrictions.
Playing devils advocate for a moment, how would we prevent either of the following abuse scenarios:
1. This allows virtually any ORG to acquire 1.125x their current holdings and use all of the
addresses (smaller block + original holdings).
2. An ORG considering selling some (or all) of its IPv4 holdings decides that a 1.125x
multiplier on their ROI is appealing and even though they don?t need the space for
renumbering, chooses to take this option as a way to get a revenue bump.
> I think the policy needs to consider the justification problem for recipients of the small block they need to renumber into, in addition to the exclusion of these companies from the source restrictions, or it only provides half the reason to avoid the workaround.
>
> (Also I think there should be no needs-tests or source-restrictions as conservation is provided by price and address turnover is not a BAD THING. ?)
We agreed to disagree about this a long time ago. Of course, you are free to support a policy proposal to eliminate needs tests and/or source restrictions and try to build consensus around it if you feel that?s the right way to go. Should you need help drafting such, I am available to assist.
Owen
>
> Regards,
> Mike
>
>
>
>
> -----Original Message-----
> From: ARIN-PPML <arin-ppml-bounces at arin.net> On Behalf Of Owen DeLong
> Sent: Tuesday, December 15, 2020 2:38 PM
> To: arin-ppml <arin-ppml at arin.net>
> Subject: [arin-ppml] ARIN-2020-6: Allowance for IPv4 Allocation ?Swap? Transactions via 8.3 Specified Transfers and 8.4 Inter-RIR Transfers
>
> Dear ARIN community,
>
> We (the AC, and specifically the proposal shepherds) need to solicit some additional feedback in order to better know the community?s desire with regards to this policy. Specifically, we?d like to ask the following questions:
>
> 1a. Do you feel that we should place an upper limit on the size of the smaller block
> received in the process?
>
> 1b. If so, what should that upper limit be?
>
> 2. Do you support limits on the time period allowed for renumbering?
>
> 2a. If so, how long?
>
> 2b. If so, what consequences should there be for exceeding the time limit?
>
> 3. Should any additional restrictions or prohibitions be placed on use of waitlist
> space in these transactions?
>
> 3a. Restrictions on waitlist providing the smaller block?
>
> 3b. Restrictions on waitlist space being transferred out?
>
> 4. Do you support the policy as currently written?
>
> 5. If not, would you support it with the changes suggested in your answers above?
>
> Thanks for your attention to this matter,
>
> Owen DeLong
> ARIN AC
>
> _______________________________________________
> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.arin.net%2Fmailman%2Flistinfo%2Farin-ppml&data=04%7C01%7Cjcbach%40cirbn.org%7C8124a7e446db4cba68cc08d8a1c672f4%7C2ea443f603e44fb693494797073fdcad%7C0%7C0%7C637437221002429104%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=991Xc0uGDAb2VIFMB3EA6Gc3b4%2Fqj8d2xBeKzTMH2R0%3D&reserved=0
> Please contact info at arin.net if you experience any issues.
>
------------------------------
Message: 4
Date: Tue, 15 Dec 2020 14:42:45 -0800
From: Owen DeLong <owen at delong.com>
To: ppml at rsuc.gweep.net
Cc: "arin-ppml at lists.arin.net" <arin-ppml at arin.net>
Subject: Re: [arin-ppml] Revised - Draft Policy ARIN-2020-8: Clarify
and Update 4.2.1.2 Annual Renewal Fee
Message-ID: <D0F2B099-127E-4924-A8E3-28967DAE7A83 at delong.com>
Content-Type: text/plain; charset="utf-8"
[really big snips]
>
> In the interest of both simplification and striving to eliminate
> the fee or contract details within policy, I'm a fan of Mr Woodfield's
> suggestion for simple generalization. What do folks think about:
>
> 2.X Registration Services Agreement (RSA)
>
> Number resources allocated or assigned by ARIN under these policies are
> subject to a contractural agreement between ARIN and the resource holder.
> Throughout this document, any and all forms of this agreement, past or
> future, is simply referred to as the Registration Services Agreement
> (RSA). This agreement covers terms, rights, responsibilities and
> conditions of service; failure to adhere to the RSA may result in
> revocation of number resources.
>
> Cheers,
>
> Joe
I like it, but I suggest ??are simply referred to by the term Registration Services Agreement (RSA)??
Alternatively, ??each and every form of this agreement (past, present, and future), is referred to as??
I would leave off the last sentence. It gets into spelling out what?s contained in the RSA which I believe is out of scope for the PDP.
To clarify, proposed alternate version:
2.X Registration Services Agreement (RSA)
Number resources allocated or assigned by ARIN under these policies are
subject to a contractural agreement between ARIN and the resource holder.
Throughout this document, any and all forms of this agreement, past or
future, are simply referred to as the Registration Services Agreement
(RSA).
Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.arin.net%2Fpipermail%2Farin-ppml%2Fattachments%2F20201215%2F567f0c70%2Fattachment.htm&data=04%7C01%7Cjcbach%40cirbn.org%7C8124a7e446db4cba68cc08d8a1c672f4%7C2ea443f603e44fb693494797073fdcad%7C0%7C0%7C637437221002429104%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=y4HbUsT6oSu4NntSYkk4M6%2BpJQnA2Nd0CkMV6CpmBxg%3D&reserved=0>
------------------------------
Subject: Digest Footer
_______________________________________________
ARIN-PPML mailing list
ARIN-PPML at arin.net
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.arin.net%2Fmailman%2Flistinfo%2Farin-ppml&data=04%7C01%7Cjcbach%40cirbn.org%7C8124a7e446db4cba68cc08d8a1c672f4%7C2ea443f603e44fb693494797073fdcad%7C0%7C0%7C637437221002429104%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=991Xc0uGDAb2VIFMB3EA6Gc3b4%2Fqj8d2xBeKzTMH2R0%3D&reserved=0
------------------------------
End of ARIN-PPML Digest, Vol 186, Issue 3
*****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20201216/fc071256/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image610804.png
Type: image/png
Size: 19215 bytes
Desc: image610804.png
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20201216/fc071256/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image980513.png
Type: image/png
Size: 641 bytes
Desc: image980513.png
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20201216/fc071256/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image160928.png
Type: image/png
Size: 642 bytes
Desc: image160928.png
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20201216/fc071256/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image882521.png
Type: image/png
Size: 675 bytes
Desc: image882521.png
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20201216/fc071256/attachment-0003.png>
More information about the ARIN-PPML
mailing list