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: [email protected]
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 [email protected]"
<[email protected] on behalf of [email protected]> wrote:
Send ARIN-PPML mailing list submissions to
[email protected]
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
[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. 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 <[email protected]>
To: arin-ppml <[email protected]>
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: <[email protected]>
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" <[email protected]>
To: "'Owen DeLong'" <[email protected]>, "'arin-ppml'"
<[email protected]>
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: <[email protected]>
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 <[email protected]> On Behalf Of Owen DeLong
Sent: Tuesday, December 15, 2020 2:38 PM
To: arin-ppml <[email protected]>
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 ([email protected]).
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 [email protected] if you experience any issues.
------------------------------
Message: 3
Date: Tue, 15 Dec 2020 14:34:41 -0800
From: Owen DeLong <[email protected]>
To: Mike Burns <[email protected]>
Cc: arin-ppml <[email protected]>
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: <[email protected]>
Content-Type: text/plain; charset=utf-8
> On Dec 15, 2020, at 1:32 PM, Mike Burns <[email protected]> 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 <[email protected]> On Behalf Of Owen DeLong
> Sent: Tuesday, December 15, 2020 2:38 PM
> To: arin-ppml <[email protected]>
> 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 ([email protected]).
> 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 [email protected] if you experience any issues.
>
------------------------------
Message: 4
Date: Tue, 15 Dec 2020 14:42:45 -0800
From: Owen DeLong <[email protected]>
To: [email protected]
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Revised - Draft Policy ARIN-2020-8: Clarify
and Update 4.2.1.2 Annual Renewal Fee
Message-ID: <[email protected]>
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
[email protected]
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
*****************************************
_______________________________________________
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
