Re: [arin-ppml] A Redefinition of IPv4 Need post ARIN run-out (was: Re:Against 2013-4)

[Brian Jones]

On Tue, Jun 11, 2013 at 10:42 PM, Martin Hannigan hanni...@gmail.comwrote:

 On Tue, Jun 11, 2013 at 10:24 PM, cb.list6 cb.li...@gmail.com wrote:


 On Jun 11, 2013 7:15 PM, Matthew Kaufman matt...@matthew.at wrote:
 
  When will we start caring about IPv6 and start ignoring IPv4??? Who
 cares if people set up shells to acquire v4 space from others? Let 'em, and
 get v6 deployed already.
 

 +1

 CB


 +1

 Best,

 -M




+1

--
Brian




 ___
 PPML
 You are receiving this message because you are subscribed to
 the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
 Unsubscribe or manage your mailing list subscription at:
 http://lists.arin.net/mailman/listinfo/arin-ppml
 Please contact i...@arin.net if you experience any issues.

___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] A Redefinition of IPv4 Need post ARINrun-out(was:Re:Against2013-4)

[Brian Jones]

See inline comments.
--
Brian


On Thu, Jun 13, 2013 at 10:17 AM, Mike Burns m...@nationwideinc.com wrote:

   Hi Brian,

 Thanks for your thoughts.
 No doubt a more vigorous transfer market will lead to more router
 misconfigurations.
 I think a knowledgeable middle-man could help mitigate that, and would
 take business from the guy getting into the game without networking
 knowledge you mention below.


Hopefully that would be the case but no guarantees if there are no
requirements other than dollars.



 There is real uncertainty when dealing with the registries. A recent
 transaction took nearly a month to complete, most of which was spent in the
 back and forth of a justification. It’s always a fingers-crossed situation
 for buyer and seller. One broker told me she does the “happy dance” every
 time a deal makes it through justification.


I agree that there needs to be an easier way to make reasonable transfers
of addresses.



 Your point about moving to IPv6 is important, because that move is the
 800lb gorilla in the room.
 Nobody knows when the move will happen or  how long it will take, but when
 it happens it is bound to affect IPv4 prices negatively.
 Who would speculate under these conditions?
 What if we limited his total purchases to a /12, or his aggregate holdings
 to a /12, otherwise he would be needs-tested?


A /12 is a lot of address space, but it seems to be a reasonable break
point for a lot of the responders on this list. My hope is that ardent
networkers will push toward IPv6 instead of clinging to legacy addressing.




 Regards,
 Mike




  *From:* Brian Jones bjo...@vt.edu
 *Sent:* Thursday, June 13, 2013 9:30 AM
 *To:* Mike Burns m...@nationwideinc.com
 *Cc:* Mike Burns m...@iptrading.com ; arin-ppml@arin.net
  *Subject:* Re: [arin-ppml] A Redefinition of IPv4 Need post
 ARINrun-out(was:Re:Against2013-4)

 Mike,
 See inline comments.

 On Wed, Jun 12, 2013 at 10:05 PM, Mike Burns m...@nationwideinc.comwrote:

 **
 Hi Brian,

 I understand that there is a danger of overpurchasing (by whomever's
 definition) that comes from the removal of a needs test for transfers.
 In most cases we rely on the price of the addresses to provide some check
 on this practice, as it would for the overpurchasing of any other asset a
 corporation may choose to invest in. I think we should leave those
 definition of what an overpurchase is to the buyers, who will have a range
 of intended purposes, projected growth rates, planning horizons and other
 considerations. At least with a cap of some sort we limit the overpurchase
 risk to overall address usage efficiency.

 A vibrant market is one of the best mechanisms to prevent what you
 mention-the problem of addresses sitting idle while real need exists.



 At the risk of contradicting myself, I'm not sure a vibrant market is the
 *best *answer for the networking community, but I don't disagree that
 what you propose would invigorate the market. See my comments below about
 network stability.



  As the price of addresses rise and transactional roadblocks diminish,
 idle addresses will come into the market. As the need rises, the price will
 rise, driving efficiencies in the utilization of addresses and wringing the
 most efficiency through the highest and best use of the addresses.


 I would agree that as demand rises the prices will increase, but maybe,
 just maybe most folks will be considering the move to IPv6 where these
 contentions and price increases will not exist.



 And as I mentioned, due to the needs test requirement, these early IPv4
 address transactions almost always involve neophyte parties on either side
 of the transaction, separated by language, culture, and an ocean. Often
 these parties are not familiar with their own RIR policy, much less the
 policy of another region. Most of the time the decision to sell or buy
 addresses has to overcome corporate inertia and antipathy to new, unusual,
 and unlikely-to-be-repeated transactions. This means education about the
 RIRs and their position squarely in the middle of the buyer and the seller.

 How likely is this transaction to occur for small allocations like the
 /24 needed by Mr. Ryerse of this thread?

 I contend that removing the needs requirement will allow for less
 uncertainty in what is currently a fraught process for both buyers and
 sellers, leading to more transactions, more price stability, and simpler
 transactions for all parties, including ARIN, who will avoid the time and
 effort of needs testing transfers.



 I appreciate your contention, and it is possible that some of the things
 you mention may actually pan out, but I do not agree with the less
 uncertainty part of your statement. I would contend removing all needs
 assessment would create more uncertainty by promoting that anyone can get
 in the game of brokering IP addresses regardless of their knowledge about
 networking. Also by increasing the amount of times IP addresses get swapped
 around the Internet

Re: [arin-ppml] Fraud reporting question

[Brian Jones]

+1 Owen's remarks.

There’s another possibility which seems entirely likely to me.

Of 146 fraud reports, 2% cover legitimate fraud. Most fraud likely goes
unreported.

As noted by ARIN staff earlier in this conversation, the vast majority of
fraud reports they receive are out of scope…

General ISP complaints
SPAM complaints
etc.

This is not surprising as probably about 1% of all internet users even know
what an RIR is, let alone how to distinguish between RIR Fraud and other
issues.

--
Brian

On Tue, Jun 23, 2015 at 10:45 PM, Owen DeLong o...@delong.com wrote:


 On Jun 23, 2015, at 19:34 , Martin Hannigan hanni...@gmail.com wrote:



 On Tue, Jun 23, 2015 at 6:11 PM, Richard Jimmerson richa...@arin.net
 wrote:

  Hello Adam,

  Thank you for submitting these questions about fraud reporting.

  We have found the fraud reporting system to be very helpful over the
 past few years. We receive many different types of fraud reports through
 this system. Some of them have helped ARIN begin investigations that have
 resulted in both the recovery of falsely registered resources and the
 denial of some IPv4 requests that might have otherwise been issued
 resources.


 According to the fraud results page, ~2% (of 146) resulted in further
 investigation.

  That''s a problem. Either. There is no real fraud or, ARIN is powerless
 to deal with it. The last time ARIN updated the Results page appears to
 be September 2014 based on the last noted ticket number of
 ARIN-20140929-F1760.


 There’s another possibility which seems entirely likely to me.

 Of 146 fraud reports, 2% cover legitimate fraud. Most fraud likely goes
 unreported.

 As noted by ARIN staff earlier in this conversation, the vast majority of
 fraud reports they receive are out of scope…

 General ISP complaints
 SPAM complaints
 etc.

 This is not surprising as probably about 1% of all internet users even
 know what an RIR is, let alone how to distinguish between RIR Fraud and
 other issues.

 Some sort of additional resources like a FAQ on what might or might not be
 out of scope could help to reduce the amount of baseless submissions as
 well as additional questions on the form that if selected nack a report. If
 staff isn't going to keep the page updated why keep it at all?


 On this we agree… The form letter I suggested should contain a link to
 this FAQ, as should the fraud report filing page.

 Owen


 Best,

 -M



 ___
 PPML
 You are receiving this message because you are subscribed to
 the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
 Unsubscribe or manage your mailing list subscription at:
 http://lists.arin.net/mailman/listinfo/arin-ppml
 Please contact i...@arin.net if you experience any issues.



 ___
 PPML
 You are receiving this message because you are subscribed to
 the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
 Unsubscribe or manage your mailing list subscription at:
 http://lists.arin.net/mailman/listinfo/arin-ppml
 Please contact i...@arin.net if you experience any issues.

___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Thoughts on 2015-7

[Brian Jones]

On Fri, Aug 21, 2015 at 10:55 AM, Scott Leibrand <scottleibr...@gmail.com>
wrote:

>
> On Aug 20, 2015, at 7:17 PM, Brian Jones <bjo...@vt.edu> wrote:
>
> Mathew,
> I think we are in agreement on some level. I don't want valuable resources
> to sit idle either. At the same time arbitrarily handing out large blocks
> of resources without any real show of need allows for possible misuse of
> the resources by those who would hang on to them to get a better price or
> for whatever reason they want.
>
>
> The IPv4 free pool is now empty, and there are no more large blocks to
> hand out. Is this still a concern when all blocks must be acquired via
> transfer? If so, can you explain why that's more of a concern under the
> proposed policy than under current policy?
>

The "large blocks" reference I used is probably not the appropriate
wording, but routed blocks matter and should be documented appropriately in
order to help keep the Internet routing tables as accurate as possible. I
still believe some show of need should be present.

Either way the resources sit idle. I am for a reasonable amount of
> justification for the amount of resources that can be consumed in a
> reasonable time period. Defining reasonable in the last two sentences and
> coming to agreement may be the crux of the matter.
>
> If the organization was mistaken about how many or how fast they would use
> the resources, then the process should be able to easily accommodate
> transfer, selling, or returning them as long as they follow procedures to
> ensure that documentation records of the resources can be appropriately
> updated for the good of the Internet.
>
> In the end there is really not a good way to prevent unused addresses
> sitting idle. It is up to the recipients of justified resources to be good
> stewards and use them appropriately and hopefully transfer, sell, or return
> them if they no longer need them.
>
>
> Totally agreed.
>
> -Scott
>
>
> On Aug 20, 2015 9:15 PM, "Matthew Kaufman" <matt...@matthew.at> wrote:
>
>> On 8/20/2015 1:04 PM, Brian Jones wrote:
>>
>>
>> ​I agree with this simplified requirement but would even be willing to
>> accept a 50% within 12 months and 75% in 24 months requirement. Two years
>> is a long time to tie up valuable resources that are not being used. IMHO​
>>
>>
>> I do not understand this reasoning. There is no more free pool. If Org A
>> is not using "valuable resources" and they are transferred to Org B who was
>> mistaken about how fast they will use them, then Org B is also not using
>> "valuable resources". But if instead Org A can't transfer them, then Org B
>> doesn't get them and Org A still has "valuable resources" which are "tied
>> up". They're "tied up" not being used either way... and ARIN can't do
>> anything about it.
>>
>> If you really want to make sure that these resources don't sit unused,
>> make it so that after Org A transfers to Org B then if Org B doesn't use
>> all of them, Org B can sell what they're not using.
>>
>> Matthew Kaufman
>>
>> ___
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
>>
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
>
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks

[Brian Jones]

I find Bill's proposal an interesting middle ground approach. I do not
believe completely eliminating needs-based justification for addresses is
the correct thing to do.

--
Brian

On Fri, Sep 25, 2015 at 4:05 PM, Bill Buhler  wrote:

> Having watched this for the last couple of years let me make a couple of
> observations / one proposal:
>
>
>
> There seems to be a lot of fear on both sides of this debate, on the needs
> test side there seems to be a complete fear of monopolization of the IP
> address space by those with deep pockets.
>
>
>
> On the other side there seem to be a couple of thoughts:
>
>
>
> 1.   It’s a market, markets work best when freed from constraints
> that increase the complexity of non-harmful transactions, and that allowing
> companies to more freely exchange IP resources is not harmful.
>
> 2.Not liking to justify future and current operations to a third
> party / fear of rejection by this process.
>
>
>
> I may not have encapsulated both arguments well, and these have been
> hashed over again and again for the last few years. So what is different
> today? ARIN has allocated every last resource from the free pool, and has a
> long waiting list.
>
>
>
> So what if we strike a compromise? What if some restrictions were put on
> allocation size and frequency without a needs test and left only the truly
> large or frequent transactions to do it. Something like this:
>
>
>
> Every legal entity can obtain up to a /22 from the transfer market every
> year, in up to two transactions. They may not transfer these resources out
> of their network within twelve months. Each legal entity has to occupy a
> unique address (suite level) from any other entity in the ARIN database.
>
>
>
> All transfers larger than a /22 need to have needs based justification
> done based on the current model.
>
>
>
>
>
> If you wanted to speculate, you would need to spin-up dozens of entities
> all with unique mailstops, and you would have to camp on the addresses for
> a year. Meanwhile the small end users and ISPs could obtain up to a /22 of
> a resource that with a lot of careful use of NAT would support a fairly
> large public network.
>
>
>
> Best regards,
>
>
>
> Bill Buhler
>
>
>
> *From:* arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] *On
> Behalf Of *Steven Ryerse
> *Sent:* Friday, September 25, 2015 11:48 AM
> *To:* Owen DeLong
>
> *Cc:* arin-ppml@arin.net
> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating
> needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4
> netblocks
>
>
>
> Owens comment from below:
>
> “2. To the extent that there is supply, anyone who needs addresses can get
> them already. Needs-based evaluation does not prevent those with need from
> getting addresses… It prevents those without need from getting them.”
>
>
>
> Owen’s comment is absolutely false!  It allows large organizing who
> request resources to get what they need or something smaller.  It allows
> medium size organizations who request resources to get what they need or
> something smaller.  It allows small organizations who request resources to
> get what they need or nothing, and there is no other source to get
> resources if ARIN rejects a request, but the open market which Owen and
> others seem to wish did not exist!
>
>
>
> It is time to fix this inequity and removing needs tests would be a big
> help to small organizations who really need resources!
>
>
>
> *Steven Ryerse*
>
> *President*
>
> *100 Ashford Center North, Suite 110, Atlanta, GA  30338*
>
> *770.656.1460 <770.656.1460> - Cell*
>
> *770.399.9099 <770.399.9099>- Office*
>
>
>
> [image: Description: Description: Eclipse Networks Logo_small.png]℠ Eclipse
> Networks, Inc.
>
> Conquering Complex Networks℠
>
>
>
> *From:* arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net
> ] *On Behalf Of *Owen DeLong
> *Sent:* Friday, September 25, 2015 1:24 PM
> *To:* el...@velea.eu
> *Cc:* arin-ppml@arin.net
> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating
> needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4
> netblocks
>
>
>
>
>
> On Sep 25, 2015, at 04:42 , Elvis Daniel Velea  wrote:
>
>
>
> Hi Richard,
>
> On 25/09/15 06:46, Richard J. Letts wrote:
>
> b)
> There is no definitive outcome from the policy change, which makes me feel
> that it's not worth changing -- the problem statement argument is weak at
> best.
>
> the outcome is that everyone that will need IP addresses will be able to
> get them. Isn't that quite definitive and clear?
>
>
>
> Sure, except it isn’t actually an outcome of the proposal on many levels:
>
>
>
> 1. The proposal does nothing to guarantee a supply of addresses or even
> increase the supply.
>
> 2. To the extent that there is supply, anyone who needs addresses can get
> them already. Needs-based evaluation does not prevent those with need from
> getting 

Re: [arin-ppml] Draft Policy ARIN-2015-10: Minimum IPv6 Assignments

[Brian Jones]

I do not think this policy is unsound or unfair, however I do not believe
it will have the intended effect. Network Operators should have the ability
to subnet their address blocks as they see fit without being penalized when
they come back for more addresses. It seems that as long as the allocated
space has been utilized they should be able to successfully request more.

I agree that a /48 makes reasonable sense as an assignment block size for
end sites. It also makes more sense to limit the number of smaller routed
block sizes to keep Internet routing tables from unreasonable growth.

--
Brian

On Thu, Sep 24, 2015 at 3:37 PM, John Springer 
wrote:

> Hi PPML,
>
> There have been a number of public discussions regarding the ins and outs
> of IPV6 subnet allocation. One such starts here:
> http://mailman.nanog.org/pipermail/nanog/2014-October/070339.html
>
> My recollection of the outcomes of these discussions is a sort of rough
> consensus that /48 is a good idea and indeed, many of the calculations used
> to evaluate what size of V6 block an org should request, start with that
> assumtion.
>
> ARIN (speaking as myself, not a member of any group and roughly
> paraphrasing someone more authoritative than I) does not dictate what you
> do with addresses after the allocation has been received. In some cases,
> ARIN looks at what you do with addresses when you come back for more and
> might not give them to you depending on what choices you have made.
>
> That is what this Draft Proposal seeks to do.
>
> I think it is clear that we can do that. Should we?
>
> And if you have an opinion of no, are you able to say because it is
> technically unsound or unfair and partial?
>
> John Springer
>
>
> On Wed, 23 Sep 2015, ARIN wrote:
>
> Draft Policy ARIN-2015-10
>> Minimum IPv6 Assignments
>>
>> On 17 September 2015 the ARIN Advisory Council (AC) accepted
>> "ARIN-prop-224 Minimum IPv6 Assignments" as a Draft Policy.
>>
>> Draft Policy ARIN-2015-10 is below and can be found at:
>> https://www.arin.net/policy/proposals/2015_10.html
>>
>> You are encouraged to discuss the merits and your concerns of Draft
>> Policy 2015-10 on the Public Policy Mailing List.
>>
>> The AC will evaluate the discussion in order to assess the conformance
>> of this draft policy with ARIN's Principles of Internet Number Resource
>> Policy as stated in the PDP. Specifically, these principles are:
>>
>>   * Enabling Fair and Impartial Number Resource Administration
>>   * Technically Sound
>>   * Supported by the Community
>>
>> The ARIN Policy Development Process (PDP) can be found at:
>> https://www.arin.net/policy/pdp.html
>>
>> Draft Policies and Proposals under discussion can be found at:
>> https://www.arin.net/policy/proposals/index.html
>>
>> Regards,
>>
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Draft Policy ARIN-2015-10
>> Minimum IPv6 Assignments
>>
>> Date: 23 September 2015
>>
>> Problem Statement:
>>
>> ISPs may believe that they have an incentive to obtain smaller blocks
>> than they really need, and once they receive their allocation may
>> subsequently issue blocks smaller than their customers may need in the
>> future. This policy seeks to encourage the correct behavior by reiterating
>> the smallest reasonable sub-allocation size and by discounting any space
>> which has been subdivided more finely from any future utilization analysis.
>>
>> Policy statement:
>>
>> Modify section 2.15 from "When applied to IPv6 policies, the term
>> "provider assignment unit" shall mean the prefix of the smallest block a
>> given ISP assigns to end sites (recommended /48)." to "When applied to IPv6
>> policies, the term "provider assignment unit" shall mean the prefix of the
>> smallest block a given ISP assigns to end sites. A /48 is recommended as
>> this smallest block size. In no case shall a provider assignment unit for
>> the purpose of this policy be smaller than /56."
>>
>> Modify section 2.16.1 from "A provider assignment unit shall be
>> considered fully utilized when it is assigned to an end-site" to "A
>> provider assignment unit shall be considered fully utilized when it is
>> assigned in full (or as part of a larger aggregate) to a single end-site.
>> If a provider assignment unit (which shall be no smaller than /56) is split
>> and assigned to multiple end-sites that entire provider assignment unit
>> shall be considered NOT utilized."
>>
>> Comments:
>> Timetable for implementation: IMMEDIATE
>> ___
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
>>
>>
>> ___
> PPML
> You are receiving this 

Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks

[Brian Jones]

On Sep 28, 2015 1:11 PM, "Owen DeLong" <o...@delong.com> wrote:
>
> I’m not going to support anything that provides a blanket exemption from
needs basis.
>
> I will support a change which allows an initial
allocation/assignment/transfer of a minimal block of addresses (up to a /22
for an end-user or up to a /20 for an ISP seems reasonable to me) so long
as it also includes anti-flip protections and some language preventing
spinning up related party entities strictly for address acquisition.
>
> I believe this would address most of the concerns expressed (other than
those seeking to eliminate needs basis altogether).
>
> Owen

Thanks for these thoughts Owen. +1 on your points made here.

>
>> On Sep 26, 2015, at 19:48 , Adam Thompson <athom...@athompso.net> wrote:
>>
>> At this point, I support anything that looks like a compromise so we can
get *any* change in policy at all... So this looks like a decent compromise
to me. Yes, it'll have to be revisited in a couple of years' time; yes, the
specifics probably aren't perfect. The community can change those. The
policy can even be written such that ARIN staff can change them
independently (although this doesn't seem to be a popular model).
>> Insisting on perfection is just hamstringing the entire service
region... both the speculators *and* legitimate users.
>> -Adam
>>
>>
>> On September 26, 2015 8:47:46 PM CDT, Brian Jones <bjo...@vt.edu> wrote:
>>>
>>> I find Bill's proposal an interesting middle ground approach. I do not
believe completely eliminating needs-based justification for addresses is
the correct thing to do.
>>>
>>> --
>>> Brian
>>>
>>> On Fri, Sep 25, 2015 at 4:05 PM, Bill Buhler <b...@tknow.com> wrote:
>>>>
>>>> Having watched this for the last couple of years let me make a couple
of observations / one proposal:
>>>>
>>>>
>>>>
>>>> There seems to be a lot of fear on both sides of this debate, on the
needs test side there seems to be a complete fear of monopolization of the
IP address space by those with deep pockets.
>>>>
>>>>
>>>>
>>>> On the other side there seem to be a couple of thoughts:
>>>>
>>>>
>>>>
>>>> 1.   It’s a market, markets work best when freed from constraints
that increase the complexity of non-harmful transactions, and that allowing
companies to more freely exchange IP resources is not harmful.
>>>>
>>>> 2.Not liking to justify future and current operations to a
third party / fear of rejection by this process.
>>>>
>>>>
>>>>
>>>> I may not have encapsulated both arguments well, and these have been
hashed over again and again for the last few years. So what is different
today? ARIN has allocated every last resource from the free pool, and has a
long waiting list.
>>>>
>>>>
>>>>
>>>> So what if we strike a compromise? What if some restrictions were put
on allocation size and frequency without a needs test and left only the
truly large or frequent transactions to do it. Something like this:
>>>>
>>>>
>>>>
>>>> Every legal entity can obtain up to a /22 from the transfer market
every year, in up to two transactions. They may not transfer these
resources out of their network within twelve months. Each legal entity has
to occupy a unique address (suite level) from any other entity in the ARIN
database.
>>>>
>>>>
>>>>
>>>> All transfers larger than a /22 need to have needs based justification
done based on the current model.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> If you wanted to speculate, you would need to spin-up dozens of
entities all with unique mailstops, and you would have to camp on the
addresses for a year. Meanwhile the small end users and ISPs could obtain
up to a /22 of a resource that with a lot of careful use of NAT would
support a fairly large public network.
>>>>
>>>>
>>>>
>>>> Best regards,
>>>>
>>>>
>>>>
>>>> Bill Buhler
>>>>
>>>>
>>>>
>>>> From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net]
On Behalf Of Steven Ryerse
>>>> Sent: Friday, September 25, 2015 11:48 AM
>>>> To: Owen DeLong
>>>>
>>>>
>>>> Cc: arin-ppml@arin.net
>>>> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating
needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4
netbl

Re: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy

[Brian Jones]

+1 Dave's comments. The question remains, how do we get there...

--
Brian

On Mon, Oct 5, 2015 at 3:45 PM, David Farmer  wrote:

> Again, philosophically I agree with the one policy for all mantra, but how
> do we get there.  I believe the intent of the author is to find bite size
> chunks to move is toward a one policy for all model.
>
> Thanks.
>
>
> On 10/5/15 14:24 , Azinger, Marla wrote:
>
>> I don't support this proposal.  I believe if restrictions are removed,
>> then both End User and ISP should be aligned entirely.  One policy for all.
>>
>> Regards
>> Marla Azinger
>>
>> -Original Message-
>> From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On
>> Behalf Of ARIN
>> Sent: Tuesday, May 26, 2015 11:58 AM
>> To: arin-ppml@arin.net
>> Subject: [arin-ppml] Draft Policy ARIN-2015-3: Remove 30 day utilization
>> requirement in end-user IPv4 policy
>>
>> Draft Policy ARIN-2015-3
>> Remove 30 day utilization requirement in end-user IPv4 policy
>>
>> On 21 May 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-217
>> Remove 30 day utilization requirement in end-user IPv4 policy" as a Draft
>> Policy.
>>
>> Draft Policy ARIN-2015-3 is below and can be found at:
>> https://www.arin.net/policy/proposals/2015_3.html
>>
>> You are encouraged to discuss the merits and your concerns of Draft
>> Policy 2015-3 on the Public Policy Mailing List.
>>
>> The AC will evaluate the discussion in order to assess the conformance of
>> this draft policy with ARIN's Principles of Internet Number Resource Policy
>> as stated in the PDP. Specifically, these principles are:
>>
>> * Enabling Fair and Impartial Number Resource Administration
>> * Technically Sound
>> * Supported by the Community
>>
>> The ARIN Policy Development Process (PDP) can be found at:
>> https://www.arin.net/policy/pdp.html
>>
>> Draft Policies and Proposals under discussion can be found at:
>> https://www.arin.net/policy/proposals/index.html
>>
>> Regards,
>>
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Draft Policy ARIN-2015-3
>> Remove 30 day utilization requirement in end-user IPv4 policy
>>
>> Date: 26 May 2015
>>
>> Problem Statement:
>>
>> End-user policy is intended to provide end-users with a one year supply
>> of IP addresses. Qualification for a one-year supply requires the network
>> operator to utilize at least 25% of the requested addresses within 30 days.
>> This text is unrealistic and should be removed.
>>
>> First, it often takes longer than 30 days to stage equipment and start
>> actually using the addresses.
>>
>> Second, growth is often not that regimented; the forecast is to use X
>> addresses over the course of a year, not to use 25% of X within 30 days.
>>
>> Third, this policy text applies to additional address space requests. It
>> is incompatible with the requirements of other additional address space
>> request justification which indicates that 80% utilization of existing
>> space is sufficient to justify new space. If a block is at 80%, then often
>> (almost always?) the remaining 80% will be used over the next 30 days and
>> longer. Therefore the operator cannot honestly state they will use 25% of
>> the ADDITIONAL space within 30 days of receiving it; they're still trying
>> to use their older block efficiently.
>>
>> Fourth, in the face of ARIN exhaustion, some ISPs are starting to not
>> give out /24 (or larger) blocks. So the justification for the 25% rule that
>> previously existed (and in fact, applied for many years) is no longer
>> germane.
>>
>> Policy statement:
>>
>> Remove the 25% utilization criteria bullet point from NRPM 4.3.3.
>>
>> Comments:
>>
>> a.Timetable for implementation: Immediate
>>
>> b.Anything else
>> ___
>> PPML
>> You are receiving this message because you are subscribed to the ARIN
>> Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
>>
>> 
>>
>> This communication is confidential. Frontier only sends and receives
>> email on the basis of the terms set out at
>> http://www.frontier.com/email_disclaimer.
>> ___
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
>>
>>
>
> --
> 
> David Farmer   Email: far...@umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 

Re: [arin-ppml] Recommended Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments

[Brian Jones]

I am in favor of this proposal. Relaxing the requirements could foster
further IPv6 adoption.

Brian Jones
bjo...@vt.edu
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Proposal ARIN-2015-8

[Brian Jones]

On Dec 3, 2015 2:35 PM, "Christian Tacit"  wrote:
>
> I am writing on behalf of the ARIN AC to seek additional input from the
community regarding how (or if) we should proceed with ARIN-2015-8.
>
>
>
> The feedback received at ARIN 36 and in subsequent AC discussions has
been very mixed and there is no community consensus for the proposal in its
present form.
>
>
>
> Some of the main points made at ARIN 36 and the subsequent AC meeting
were:
>
>
>
> 1. Orgs should not be able to by-pass the fee structures and other
policy consequences of being classified as ISPs, and the draft policy would
facilitate this type of by-pass;
>
> 2. Some of those who shared the concern in point 1. said that they
would still support allowing Orgs to SWIP to themselves (and possibly to
related Orgs) to facilitate geolocation and this will be even more
important in an IPv6 environment where assigned address blocks are much
bigger and so often not used at one location;
>
> 3. ARIN already allows RWHOIS to be used by End-Users, which leads to
the question of whether this avenue should be foreclosed, End-User SWIPs
should be allowed or the status quo should be left in place;
>
> 4. Should End-Users who want to be able to re-assign records simply
be required to become ISPs?

I am strongly opposed to a requirement for end users to become ISPs solely
for the purpose of re-assigning records. Cost is not the only concern here.

>
> 5. Should the ISP/End-User distinction be eliminated (which is a
bigger discussion outside the scope of the current problem statement)?

Possibly. However if this causes costs to increase for end users, then I
would say no. As a state university keeping ongoing costs to a minimum is
imperative to operation. We don't make money so justifying additional costs
for the same resources is nearly impossible.

>
> 6. If the ISP/End-User fee distinction were eliminated, would there
still be opposition to the draft policy?

This depends on what happens to end user costs, see above.

>
> 7. To what extent is there value or do problems get created if
End-Users can SWIP (i.e., improving the accuracy of database information
vs. possibly facilitating a “grey market” where the true registered users
of numbering resources are not known)? and
>

Improving accuracy of database information is a necessary axiom, but it is
arguable as to whether end user access improves or lessens database
accuracy.

> 8. Does the problem statement need to be reformulated, and if so, how?
>
>
>
> If you would like to see further work on this policy, please let us at
the AC know what form you think that work should take. If you think the
policy should be abandonded altogether we would like to know that as well.
>
>
>
> Thank you.
>
>
>
> Chris
>
>
> Christian S. Tacit,
> Tacit Law
>
> P.O. Box 24210 RPO Hazeldean
> Kanata, Ontario
> K2M 2C3 Canada
>
> Tel: +1 613 599 5345
> Fax: +1 613 248 5175
> E-mail: cta...@tacitlaw.com
>
> This message is intended only for the use of the individual or entity to
which it is addressed and may contain information that is subject to
copyright, privileged, confidential, proprietary or exempt from disclosure
under applicable law. If you are not the intended recipient or the person
responsible for delivering the message to the intended recipient, you are
strictly prohibited from disclosing, distributing, copying or in any way
using this message. If you have received this communication in error,
please notify the sender and destroy or delete copies you may have received.
>
>
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy

[Brian Jones]

I support this proposal as written.
__
Brian Jones
On 16 June 2016 the ARIN Advisory Council (AC) advanced the following Draft
Policy to Recommended Draft Policy status:

ARIN-2016-1: Reserved Pool Transfer Policy

The text of the Recommended Draft Policy is below, and may also be found at:
https://www.arin.net/policy/proposals/2016_1.html

You are encouraged to discuss all Recommended Draft Policies on PPML prior
to their presentation at the next ARIN Public Policy Consultation (PPC).
PPML and PPC discussions are invaluable to the AC when determining
community consensus.

The PDP can be found at:
https://www.arin.net/policy/pdp.html

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)

Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy

Date: 21 June 2016

AC assessment of conformance with the Principles of Internet Number
Resource Policy:

This proposal enables fair and impartial number resource administration by
ensuring that IPv4 resources, which are specially designated for critical
infrastructure and IPv6 transition, are readily available for many years
into the future. This is done by ensuring the resources remain in their
originally designated pool rather than being moved into the general IPv4
address pool via a transfer.  This proposal is technically sound and is
supported by the community.

Problem Statement:

Section 8 of the current NRPM does not distinguish between the transfer of
blocks from addresses that have been reserved for specific uses and other
addresses that can be transferred. In sections 4.4 and 4.10 there are
specific address blocks set aside, based on the need for critical
infrastructure and IPv6 transitions. Two issues arise if transfers of
reserved address space occur under the current language of section 8.
First, if transfers of 4.4 or 4.10 space occur under the current policy
requirements set forth in sections 8.3 and 8.4, the recipients will be able
to acquire space that was originally reserved for a specific purpose
without ever providing evidence that they will be using the space for
either critical infrastructure or IPv6 transition. Second, if we allow an
allocation or assignment from the block reserved in section 4.10 to be
transferred out of the region, it would complicate the single aggregate
from which providers are being asked to allow in block sizes smaller than a
/24. This policy would limit the transfer of addresses from reserved pools.

Policy statement:

Add to Section 8.3 and Section 8.4 under the "Conditions on source of the
transfer:"

Address resources from a reserved pool (including those designated in
Section 4.4 and 4.10) are not eligible for transfer.

Timetable for implementation: Immediate

##

ARIN STAFF & LEGAL ASSESSMENT
Draft Policy ARIN-2016-1
RESERVED POOL TRANSFER POLICY
https://www.arin.net/policy/proposals/2016_1.html

Date of Assessment: 13 June 2016
___
1. Summary (Staff Understanding)

This policy would make IPv4 addresses issued under NRPM 4.4 and 4.10
ineligible for transfer inside the NRPM 8.3 and 8.4 transfer policies.
___
2. Comments

A. ARIN Staff Comments

* If this policy is implemented, ARIN staff would not allow NRPM 8.3 and
8.4 transfers to include IPv4 addresses previously issued under NRPM 4.4
and 4.10 policies.

* ARIN staff would continue to allow IPv4 addresses previously issued under
NRPM 4.4 and 4.10 to be included in Merger and Acquisition (NRPM 8.2)
transfers.

* This policy could be implemented as written.

B. ARIN General Counsel – Legal Assessment

The policy does not create a material legal issue. It should be noted that
ARIN does permit transfers of IPV4 resources pursuant to 8.3 and 8.4. This
policy is an exception to that transferability and is consistent with the
intent and of the policy by which these allocations were made.
___
3. Resource Impact

Implementation of this policy would have minimal resource impact. It is
estimated that implementation would occur within 3 months after
ratification by the ARIN Board of Trustees. The following would be needed
in order to implement:

* Updated guidelines and internal procedures

* Staff training
___
4. Proposal / Draft Policy Text Assessed

Draft Policy ARIN-2016-1
Reserved Pool Transfer Policy

Date: 22 March 2016

Problem Statement:

Section 8 of the current NRPM does not distinguish between the transfer of
blocks from addresses that have been reserved for specific uses and other
addresses that can be transferred. In sections 4.4 and 4.10 there are
specific address blocks set aside, based on the need for critical
infrastructure and IPv6 transitions. Two issues arise if transfers of
reserved address space occur under the current language of section 8.
First, if transfers of 4.4 or 4.10 space occur under the current policy
requirements set forth in sections 8.3 and 8.4, 

Re: [arin-ppml] ARIN-2015-3: Remove 30-Day Utilization Requirement in End-User IPv4 Policy

[Brian Jones]

Looks good to me Dave. I am okay with using criteria or criterion, however
using the strict definition it looks as though criterion is the proper
singular form.

--
Brian

On Wed, Jan 27, 2016 at 5:54 PM, David Farmer  wrote:

> The following is the proposed update for ARIN-2015-3: Remove 30-Day
> Utilization Requirement in End-User IPv4 Policy based on strong support in
> Montreal.
>
> Beyond deleting the 25% bullet as the policy says, their are editorial
> changes as follows to the remaining text;
>
> - It looks weird to have single item bullet list, so merge the two
> remaining sentence fragments into a single sentence.
> - Change "are" to "is", since there is only one remaining criteria
> - Use of "criteria" as a singular is common usage, even though technically
> it's plural.
> - Resulting in "The basic criteria that must be met is a 50% utilization
> rate within one year."
>
> The remaining and resulting text for 4.3.3 is now included in the policy
> text, for editorial clarity.  The original staff and legal suggested
> removing the RFC2050 reference and also pointed out that
> 4.2.3.6 also has a 25% immediate use clause and a RFC2050 reference.
>
> Feedback in Montreal was that deleting the 25% immediate use was a nice
> bite-sized change, and we shouldn't try to do more than that with this
> change, so those changes are not included at this time.
>
> Any additional feedback or comments are appreciated.
>
> Thanks
>
> -
>
> Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in
> end-user IPv4 policy
>
> Date: 27 January 2015
>
> Problem Statement:
>
> End-user policy is intended to provide end-users with a one year supply of
> IP addresses. Qualification for a one-year supply requires the network
> operator to utilize at least 25% of the requested addresses within 30 days.
> This text is unrealistic and should be removed.
>
> First, it often takes longer than 30 days to stage equipment and start
> actually using the addresses.
>
> Second, growth is often not that regimented; the forecast is to use X
> addresses over the course of a year, not to use 25% of X within 30 days.
>
> Third, this policy text applies to additional address space requests. It
> is incompatible with the requirements of other additional address space
> request justification which indicates that 80% utilization of existing
> space is sufficient to justify new space. If a block is at 80%, then often
> (almost always?) the remaining 80% will be used over the next 30 days and
> longer. Therefore the operator cannot honestly state they will use 25% of
> the ADDITIONAL space within 30 days of receiving it; they're still trying
> to use their older block efficiently.
>
> Fourth, in the face of ARIN exhaustion, some ISPs are starting to not give
> out /24 (or larger) blocks. So the justification for the 25% rule that
> previously existed (and in fact, applied for many years) is no longer
> germane.
>
> Policy statement:
>
> Remove the 25% utilization criteria bullet point from NRPM 4.3.3.
>
> Resulting text:
>
> 4.3.3. Utilization rate
>
> Utilization rate of address space is a key factor in justifying a new
> assignment of IP address space. Requesters must show exactly how
> previous address assignments have been utilized and must provide
> appropriate details to verify their one-year growth projection.
>
> The basic criteria that must be met is a 50% utilization rate within one
> year.
>
> A greater utilization rate may be required based on individual network
> requirements. Please refer to RFC 2050 for more information on
> utilization guidelines.
>
> Comments:
> a.Timetable for implementation: Immediate
> b.Anything else
>
> --
> 
> David Farmer   Email: far...@umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> 
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] ARIN-2015-3: Remove 30-Day Utilization Requirement in End-User IPv4 Policy

[Brian Jones]

dance)
> > >
> > >
> > > So two open questions to the community?
> > >
> > > 1. Is the community most comfortable with:
> > >  A. totally vague and open-ended such as "there must be some
> > >   tangible and verifiable claim to show there was a real commitment to
> > > use half the address space within one year and not just a future
> > > projection or business case"
> > >
> > > B. A vague statement with some guidance as to some acceptable
> > > forms of tangible verifiable proof of a real commitment to use half
> > > the IP address within one year.
> > >
> > >C. A very clear list of what proof is considered acceptable
> > >
> > >
> > > 2. If the community prefers B. guidance or C. a very clear list then
> > > what sort of things would the community like to see on that list?
> > >
> > >
> > > On Fri, Jan 29, 2016 at 8:27 AM, McTim <dogwal...@gmail.com
> > > <mailto:dogwal...@gmail.com>> wrote:
> > >
> > >
> > >
> > > On Thu, Jan 28, 2016 at 4:52 PM, Jason Schiller
> > > <jschil...@google.com <mailto:jschil...@google.com>> wrote:
> > >
> > > I support the removal of the 30 day utilization as it is
> > > unreasonable for any larger end-site, who may have a real need
> > > for say a /16, with 65,000 desktops arriving on a loading doc
> > > next week, but an inability to unbox, configure and deploy
> > > 16,384 to the various office locations in 30 days.
> > >
> > >
> > >     agreed.
> > >
> > > However, this is the only provision that has a real, tangible,
> > > and verifiable claim.  Without this check justified need for
> end
> > > users simply becomes a 1 year future looking projection, and
> > > with sufficient arm waving an easy end run around justified
> need
> > > for any end user with no IP space or if they are efficiently
> > > using what they currently hold.
> > >
> > >
> > > good point!
> > >
> > > I could get on board if the maximum sized block permitted on a
> > > purely future looking projection was a /24 and you had to use
> it
> > > prior to getting more.
> > >
> > >
> > > +1
> > >
> > > I could certainly get on board if there were some other
> tangible
> > > and verifiable claim to show there was a real commitment to use
> > > half the address space within one year.
> > >
> > >
> > > Would this language suffice, or would we need a metric of some
> sort?
> > >
> > >
> > > Regards,
> > >
> > > McTim
> > >
> > > __Jason
> > >
> > > On Thu, Jan 28, 2016 at 8:55 AM, Brian Jones <bjo...@vt.edu
> > > <mailto:bjo...@vt.edu>> wrote:
> > >
> > > Looks good to me Dave. I am okay with using criteria or
> > > criterion, however using the strict definition it looks as
> > > though criterion is the proper singular form.
> > >
> > > --
> > > Brian
> > >
> > > On Wed, Jan 27, 2016 at 5:54 PM, David Farmer
> > > <far...@umn.edu <mailto:far...@umn.edu>> wrote:
> > >
> > > The following is the proposed update for ARIN-2015-3:
> > > Remove 30-Day Utilization Requirement in End-User IPv4
> > > Policy based on strong support in Montreal.
> > >
> > > Beyond deleting the 25% bullet as the policy says,
> their
> > > are editorial changes as follows to the remaining
> > > text;
> > >
> > > - It looks weird to have single item bullet list, so
> > > merge the two remaining sentence fragments into a
> single
> > > sentence.
> > > - Change "are" to "is", since there is only one
> > > remaining criteria
> > > - Use of "criteria" as a singular is common usage, even
> > > though technically it's plural.
> > > - Resulting in "The basic criteria that must be met is
> a
> > > 

Re: [arin-ppml] Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers of IPv4 netblocks

[Brian Jones]

Support.

--
Brian

On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer  wrote:

> Good afternoon -
>
>   Based on feedback from Montreal as well as internal discussions, I've
> reworked this policy.
> AC members and ARIN staff are looking for additional feedback, as well as
> your position in terms
> of supporting or opposing this draft policy.
>
>   We'll be discussing this policy, as well as any feedback provided on
> this week's AC teleconference,
> so I'm very appreciative of your input.
>
> Thanks,
>
>   Leif Sawyer
>   Shepherd - ARIN-2015-9
>
> NRPM section 8: https://www.arin.net/policy/nrpm.html#eight
>
> Most current draft policy text follows:
> --
>
> Draft Policy ARIN-2015-9
> Eliminating needs-based evaluation for Section 8.2 and 8.3 transfers
> of IPv4 netblocks
> Original Date: 23 September 2015
> Updated: 16 February, 2016
>
> Problem statement:
> The current needs-based evaluation language in NRPM sections 8.2 and 8.3,
> regarding transfer of IPv4
> netblocks from one organization to another, may cause a recipient
> organization to bypass the ARIN
> registry entirely in order to secure the needed IPv4 netblocks in a more
> timely fashion directly from the
> current holder. The result is that the data visible in ARIN registry may
> become more inaccurate over
> time.
>
> Policy statement:
> This proposal eliminates all needs-based evaluation language for sections
> 8.2 and 8.3, allowing
> transfers to be reflected in the database as they occur following an
> agreement of transfer from the
> resource provider to the recipient.
>
> Section 8.1 Principles:
> - Strike the fragment from the 3rd paragraph which reads
> ", based on justified need, "
> so the resulting text reads
> "Number resources are issued to organizations, not to individuals
> representing those organizations."
> Section 8.2 Mergers and Acquisitions:
> - Change the 4th bullet from:
> "The resources to be transferred will be subject to ARIN policies."
> to:
> "The resources to be transferred will be subject to ARIN policies,
> excluding any policies related to needs-based justification."
>
> - Strike the final paragraph which begins "In the event that number
> resources of the combined organizations are no longer justified under ARIN
> policy ..."
>
> Section 8.3 Transfers between Specified Recipients within the ARIN Region:
> - Change the first bullet under "Conditions on recipient of the transfer"
> from:
> "The recipient must demonstrate the need for up to a 24-month supply of IP
> address resources under current ARIN policies and sign an RSA."
> to:
> "The recipient must sign an RSA."
>
> - Change the 2nd bullet under "Conditions on recipient of the transfer"
> from:
> "The resources to be transferred will be subject to ARIN policies."
> to:
> "The resources to be transferred will be subject to ARIN policies,
> excluding any policies related to needs-based justification."
>
> Comments:
> a. Timetable for implementation: Immediate
> b. Anything else
> As the "free pool" for 4 of the 5 world's RIR's (APNIC, RIPE, LACNIC, and
> ARIN) have now been
> exhausted, networks in need of additional IPv4 addresses have shifted away
> from the practice of
> receiving them from the RIR's resource pool. Instead, networks in need are
> seeking out current holders
> of IPv4 resources who are willing to transfer them in order to fulfill
> that need. Accordingly, the RIR's
> primary responsibility vis-à-vis IPv4 netblock governance has shifted from
> "allocation" to ensuring an
> accurate registry database.
>
> The RIPE registry can be used as a reference of one which has evolved over
> the past couple years to
> shift their focus away from conservation/allocation and towards database
> accuracy. IPv4 netblock
> transfers within that RIR consist merely of validating authenticity of the
> parties requesting a transfer.
> Provided the organizations meet the basic requirement of RIR membership,
> and that the transferring
> organization has the valid authority to request the transfer, the
> transaction completes without any
> "needs-based" review.
>
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] ARIN 2-Byte ASN inventory and issuance (was: Re: 2-byte ASN policy)

[Brian Jones]

On Apr 8, 2016 7:26 PM, "David Farmer"  wrote:
>
> On Thu, Apr 7, 2016 at 2:24 PM, Scott Leibrand 
wrote:
>>
>> Thanks, John.
>>
>> It sounds to me like ARIN is already doing the right thing (saving
2-byte ASNs for people who specifically want them), and that is sufficient
for the time being.  It does not appear that additional restrictions on who
may request a 2-byte ASN are necessary at this time.  If at some point 5+
years down the road the rate of 2-byte ASN demand starts to exceed the
recovered supply and the 2-byte ASN inventory is depleted, we can consider
a waiting list and/or technical requirements for requesting a 2-byte ASN at
that time.
>>
>> Is there any other reason we need to consider taking action sooner?
>
>
> I agree the current procedures are meeting our needs and see no need for
immediate changes.   However, I would suggest the community get regular
reports on the inventory levels for 2-byte ASNs.  Adding a slide to one of
the many reports at the PPMs seems logical, but I'd leave it up to staff to
determine the best mechanism for such reporting.
>
> Assuming we stay on the current trajectory, I think we should look at
this again in about two years.  Hopefully, by then the rate of use for
2-byte ASNs will have slowed even more and any real operational threat from
running out of 2-byte ASNs will be greatly diminished if not non-existent.
If not we should still have sufficient time to plan for a soft landing.
>
>> Was there something else I'm missing that prompted ARIN staff to start
the consultation process around a 2-byte ASN waiting list?
>>
>> -Scott
>
>
> One side issue that came up in this discussion that I think could be
worthy of follow up and/or further discussion.  The number of ASNs in the
routing table that are not properly registered, surprised me a little;
 350+ unregistered ASNs and 900+ prefixes associated with them, were the
easy numbers for me to find.  What I don't know, does that represent a
constant churn of short-term issues, where most of them come and go over a
few months.  Or, are most those chronic long-term issues that are not
getting cleaned up even after several years.  If it's the later, then maybe
we need to do something about that.

+1 - I agree if this is a long term issue we really should be doing
something about it. Good information Thanks David.

>
> Thanks
>
> --
> ===
> David Farmer   Email:far...@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SEPhone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===
>
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy

[Brian Jones]

I support as is.

--
Brian
​ E Jones
Virginia Tech​

--
Brian

On Wed, May 18, 2016 at 7:56 AM, Kevin Blumberg  wrote:

> Andrew,
>
>
>
> I support the proposal as written without the additional transfer language.
>
> I believe that adding in transfers complicates the proposal and based on
> the current available space, will not be needed for a number of years.
>
>
>
> Thanks,
>
>
> Kevin Blumberg
>
>
>
>
>
> *From:* arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] *On
> Behalf Of *Andrew Dul
> *Sent:* May 5, 2016 11:00 AM
> *To:* arin-ppml@arin.net
> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool
> Transfer Policy
>
>
>
> Hello,
>
> As part of the discussions at ARIN 37 the community considered updates to
> the proposed draft policy that would allow organizations to transfer,
> within ARIN, reserved pool resources provided that they met the criteria to
> obtain a block from a reserved pool.
>
> Based upon this feedback we are proposing to update the draft policy text
> as follows.  The AC welcomes your feedback on this proposed text and any
> other feedback on this draft policy.
>
> Thanks,
>
> Andrew
>
>
>
> *Original Policy statement:*
>
> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the
> transfer:"
>
> Address resources from a reserved pool (including those designated in
> Section 4.4 and 4.10) are not eligible for transfer.
>
> *Updated Policy statement:*
>
> Add to Section 8.3 under the "Conditions on recipient of the transfer:"
>
> Address resources from a reserved pool (including those designated in
> Section 4.4 and 4.10) shall only be transferred to organizations which meet
> the current criteria of the reserved pool from which the resource was
> obtained.
>
> Add to Section 8.4 under the "Conditions on source of the transfer:"
>
> Address resources from a reserved pool (including those designated in
> Section 4.4 and 4.10) are not eligible for transfer.
>
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2016-4: Transfers for new entrants

[Brian Jones]

Support.

On Jul 20, 2016 3:39 PM, "John Springer" <3jo...@gmail.com> wrote:

> Dear PPML,
>
> ARIN-2016-4 was accepted as a Draft Policy in June.
>
> https://www.arin.net/policy/proposals/2016_4.html
>
> Expressions of support or opposition to the DP are solicited to assist in
> evaluating what to do with it in the run up to the meeting in Dallas.
>
> At the moment, it appears technically sound and fair to me, but
> expressions of support will be required to advance.
>
> Thank you in advance.
>
> John Springer
>
> On Tue, Jun 21, 2016 at 8:40 AM, ARIN  wrote:
>
>> On 16 June 2016 the ARIN Advisory Council (AC) advanced the following
>> Proposal to Draft Policy status:
>>
>> ARIN-prop-229: Transfers for new entrants
>>
>> This Draft Policy has been numbered and titled:
>>
>> Draft Policy ARIN-2016-4: Transfers for new entrants
>>
>> Draft Policy ARIN-2016-4 is below and can be found at:
>> https://www.arin.net/policy/proposals/2016_4.html
>>
>> You are encouraged to discuss all Draft Policies on PPML. The AC will
>> evaluate the discussion in order to assess the conformance of this draft
>> policy with ARIN's Principles of Internet number resource policy as stated
>> in the Policy Development Process (PDP). Specifically, these principles are:
>>
>>  * Enabling Fair and Impartial Number Resource Administration
>>  * Technically Sound
>>  * Supported by the Community
>>
>> The PDP can be found at:
>> https://www.arin.net/policy/pdp.html
>>
>> Draft Policies and Proposals under discussion can be found at:
>> https://www.arin.net/policy/proposals/index.html
>>
>> Regards,
>>
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>> ##
>>
>> Draft Policy ARIN-2016-4: Transfers for new entrants
>>
>> Date: 21 June, 2016
>> Problem Statement:
>>
>> New organizations without existing IPv4 space may not always be able to
>> qualify for an initial allocation under NRPM 4.2, particularly if they are
>> categorized as ISPs and subject to 4.2.2.1.1. Use of /24. Now that ARIN's
>> free pool is exhausted, 4.2.1.6. Immediate need states that "These cases
>> are exceptional", but that is no longer correct. End user organizations
>> requiring less a /24 of address space may also be unable to acquire space
>> from their upstream ISP, and may instead need to receive a /24 from ARIN
>> via transfer.
>>
>> Policy statement:
>>
>> Replace Section 4.2.2 with:
>>
>> 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 for specified transfers, or three months otherwise. 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.
>>
>> Replace Section 4.3.2 to read:
>>
>> 4.3.2 Minimum assignment
>>
>> ARIN's minimum assignment for end-user organizations is a /24.
>>
>> End-user organizations without direct assignments or allocations from
>> ARIN qualify for an initial assignment of ARIN's minimum assignment size.
>>
>> Replace the first two sentences of Section 4.3.3. Utilization rate to
>> read:
>>
>> Organizations may qualify for a larger initial allocation by providing
>> appropriate details to verify their 24-month growth projection for
>> specified transfers, or 12 months otherwise.
>>
>> Resulting new section 4.3.3 will be:
>>
>> Organizations may qualify for a larger initial allocation, by providing
>> appropriate details to verify their 24-month growth projection for
>> specified transfers, or 12 months otherwise.
>>
>> The basic criterion that must be met is a 50% utilization rate within one
>> year.
>>
>> A greater utilization rate may be required based on individual network
>> requirements. Please refer to RFC 2050 for more information on utilization
>> guidelines.
>>
>> Comments:
>>
>> Timetable for implementation: Immediate
>>
>> Anything else
>>
>> The text in 4.2.2 "for specified transfers, or three months otherwise"
>> and the text in 4.3.3 "for specified transfers, or 12 months otherwise"
>> should be stricken if ARIN-prop-227 is adopted.
>> ___
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
>>
>
>
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> 

Re: [arin-ppml] Community Networks (Was Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM)

[Brian Jones]

--
Brian

On Tue, Aug 9, 2016 at 9:34 PM, Keith W. Hare  wrote:

> David,
>
>
>
> 6.5.2.2 item C requests a plan “with a minimum of 50 assignments within 5
> years”
>
>
>
> 6.5.9.1 says “a community network must demonstrate it will immediately
> provide sustained service to at least 100 simultaneous users and must
> demonstrate a plan to provide sustained service to at least 200
> simultaneous users within one year.”
>
>
>
> Seems to me that it would be easier to create a plan for 50 assignments
> within 5 years than demonstrate providing service to at least 100
> simultaneous users immediately.
>
>
>
> I suppose the reason no one has requested IP space under the community
> networks proposal could be that it seems to only apply to IPv6, and there
> does not yet seem to be a large end-user demand for IPv6 connectivity. Or
> perhaps removing the HD-ratio will simplify the community network section
> enough that it will get used.
>
>
>

​+1​

​I am thinking the same thing, that if the HD-ratio is relaxed or removed
that the community section will start to be used. ​




> Keith
>
>
>
>
>
> *From:* David Huberman [mailto:dav...@panix.com]
> *Sent:* Tuesday, August 9, 2016 6:09 PM
> *To:* Keith W. Hare 
> *Cc:* David Farmer ; arin-ppml@arin.net
> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2016-6: Eliminate HD-Ratio
> from NRPM
>
>
>
>  Keith,
>
>
>
>
>
> Which criterion in 6.5.2.2 (ISP initial) would a small community network
> qualify under? Or 6.5.8.1 (end user initial)?
>
>
>
> Answer: it's been proven by the community networks folks that in many
> cases a requisite couldn't meet any of those criteria. They need special
> language, and got it. :-)
>
>
>
>
>
>
> On Aug 9, 2016, at 2:59 PM, Keith W. Hare  wrote:
>
> From a quick read of the Community Networks section, I don’t see where
> someone saves anything by qualifying as a Community Network.
>
>
>
> So, I support draft policy 2016-6 as written, but would also support a
> proposal that completely eliminates the Community Networks sections.
>
>
>
> Keith
>
>
>
>
>
> Keith W. Hare
>
> ke...@jcc.com
>
> JCC Consulting, Inc.
>
> 600 Newark Granville Road
>
> P.O. Box 381
>
> Granville, Ohio 43023 USA
>
> Phone: +1 740-587-0157
>
> http://www.jcc.com
>
>
>
>
>
>
>
>
>
> *From:* arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net
> ] *On Behalf Of *David Farmer
> *Sent:* Monday, August 8, 2016 11:14 PM
> *To:* arin-ppml@arin.net
> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2016-6: Eliminate HD-Ratio
> from NRPM
>
>
>
> As AC Shepherd, I haven't seen much discussions of this one;  I think the
> Elimination of HD-Ratio is probably fairly non-controversial itself.
>
>
>
> However, in regards to the Community Networks section, I see three
> high-level alternatives for the community to consider;
>
>1. Rewrite the Community Networks section to not reference HD-Ratio, as
> the Draft Policy suggests;
>
>2. Replace the Community Networks section with a generic small ISP
> policy allowing allocations of /40 (qualifying for xxx-small IPv6
> fee category);
>
>3. Remove the Community Networks section all together; It doesn't seem
> to have been used since it was adopted, see Dan Alexander's Policy
> Simplification presentation, slide #4. If we go this way, 2.11 should be
> deleted also;
>
>
>
> https://www.arin.net/vault/participate/meetings/reports/
> ARIN_37/PDF/tuesday/alexander_simplification.pdf#page=4
>
>
>
> I think a rewrite in line with the original intent for the Community
> Networks section is the proper place to start the conversation, and I think
> this Draft Policy does a good job doing that.  However since we need to
> touch the Community Networks section to accomplish the Elimination of
> HD-Ratio, I'd like to hear from some Community Networks to better
> understand why the current policy is not being used.  Is there some problem
> with it? Is it just not necessary? Was it too early? Are Community
> Networks just being requested and recorded as other end user requests?
>
>
>
> Personally, I like the idea of the Community Networks policy, but since no
> one seems to be using it, maybe we should look at why as part of any
> rewrite.
>
>
>
> Comments please, even if you simply support the policy as written.  Also,
> if you know someone involved in operating a Community Network please
> forward this to them, I'd really like to hear from them even if they don't
> want to post to PPML themselves.
>
>
>
> Thanks.
>
>
>
>
>
> On Tue, Jul 26, 2016 at 8:21 AM, ARIN  wrote:
>
> On 21 July 2016, the ARIN Advisory Council (AC) advanced the following
> Proposal to Draft Policy status:
>
> ARIN-prop-231: Eliminate HD-Ratio from NRPM
>
> This Draft Policy has been numbered and titled:
>
> Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM
>
> Draft Policy ARIN-2016-6 is below and can be found at:
>
> 

Re: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers - Text modifications

[Brian Jones]

+1 Dave’s comments.

I support 2016-9. It should hopefully strengthen the accuracy of the whois data.

--
Brian E Jones, CSM, CSPO
NI Virginia Tech
bjo...@vt.edu

> On Jan 24, 2017, at 11:23 PM, David Farmer  wrote:
> 
> In the most general sense a state is a corporation. See; 
> https://en.wikipedia.org/wiki/Corporation#History 
>   Further, in most cases 
> the agencies of a state are not independent but sub-parts of the whole. 
> Therefore, moving resources between agencies should more properly be 
> considered a reorganization of a single entity, in most situations, and not a 
> transfer between separate entities.  Also, I'd expect ARIN would provide some 
> level of deference to sovereign government entities like states, especially 
> in an interagency type situation.
> 
> However, to protect itself, I would expect ARIN would want to ensure they are 
> dealing with someone with the proper authority to act on the state's behalf.  
> So, I could imagine ARIN asking a state (or agency) to provide evidence (such 
> as a quote of applicable statute) of who has authority over the agencies 
> and/or resources in question.  I expect this would be especially be true, if 
> resources were being transferred out of a State's control.
> 
> Thanks.
> 
> On Tue, Jan 24, 2017 at 5:59 PM, Richard J. Letts  > wrote:
> This assumes that only corporate entities merge, acquire, or re-organize. How 
> would state agencies or an inter-institution research group produce the 
> required documentation to facilitate the movement of resources given the lack 
> of independently verifiable information?
> 
> 
> 
> Similarly, a function might be transferred between state agencies, but we 
> might not be acquiring an entire corporate entity (as we’re a state agency).
> 
> 
> 
> Richard
> 
> 
> 
> From: ARIN-PPML  > on behalf of John Springer 
> <3jo...@gmail.com >
> Date: Tuesday, January 24, 2017 at 12:32 PM
> To: "arin-ppml@arin.net "  >
> Subject: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers - Text 
> modifications
> 
> 
> 
> These two changes will leave Section 8.2 looking like this:
> 
> 8.2. Mergers and Acquisitions
> 
> ARIN will consider requests for the transfer of number resources in the case 
> of mergers, acquisitions, and reorganizations under the following conditions:
> 
> The current registrant must not be involved in any dispute as to the status 
> of the resources to be transferred.
> 
> The new entity must sign an RSA covering all resources to be transferred.
> 
> The resources to be transferred will be subject to ARIN policies.
> 
> The minimum transfer size is the smaller of the original allocation size or 
> the applicable minimum allocation size in current policy.
> 
> AND one or more of the following:
> 
> The recipient must provide independently verifiable evidence that they have 
> acquired the assets that use the resources to be transferred from the current 
> registrant.
> 
> OR
> 
> The recipient must show that they have acquired the entire corporate entity 
> which is the current registrant.
> 
> 
> 
> 
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net 
> ).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml 
> 
> Please contact i...@arin.net  if you experience any 
> issues.
> 
> 
> 
> --
> ===
> David Farmer   Email:far...@umn.edu 
> 
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SEPhone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility

[Brian Jones]

It’s legacy space, I support removing the reciprocity requirement.
--
Brian E Jones, CSM, CSPO
NI Virginia Tech
bjo...@vt.edu

> On Jan 20, 2017, at 12:24 PM, Rob Seastrom  wrote:
> 
> 
> Back when we were concerned that our regional free pool might precipitously 
> empty (perhaps via some unforeseen loophole in our transfer regimen) I 
> supported the reciprocity requirement, as a potential countermeasure against 
> that outcome.
> 
> Now that there is no longer a free pool to worry about, this clause has 
> outlived its usefulness.

+1

> 
> I support removing the reciprocity requirement.
> 
> -r
> 
> Sent from my iPad
> 
> On Jan 20, 2017, at 12:09, David Huberman  > wrote:
> 
>> Because they're approaching their last /8 and have maximum block limits in 
>> their policy that go into place for the last /8:
>> 
>> http://afrinic.net/en/library/news/1973-afrinic-is-approaching-ipv4-exhaustion-phase-1
>>  
>> 
>> 
>> 
>> On Jan 20, 2017, at 12:04 PM, Jose R. de la Cruz III > > wrote:
>> 
>>> I agree with Bill. If they are yet to reach runout, why are "external" 
>>> resources required?
>>> 
>>> José
>>> 
>>> On Thu, Jan 19, 2017 at 7:24 PM, William Herrin >> > wrote:
>>> On Thu, Jan 19, 2017 at 3:36 PM, David R Huberman >> > wrote:
>>> > Last week, ARIN staff sent to this list a copy of their response to 
>>> > AFRINIC
>>> > on inter-RIR transfer policy compatability.
>>> >
>>> > The AFRINIC community is considering a one-way transfer policy as a
>>> > bootstrap for the few years until they reach IPv4 runout, at which point 
>>> > it
>>> > would aim to become two-way.
>>> 
>>> Hi David,
>>> 
>>> If AFRINIC hasn't reached IPv4 runout, why do their registrants need
>>> to buy addresses in the ARIN region?
>>> 
>>> I consider reciprocity far more important than needs testing. The LIR
>>> loophole APNIC registrants continue to abuse bothers me.
>>> 
>>> Regards,
>>> Bill Herrin
>>> 
>>> 
>>> 
>>> --
>>> William Herrin  her...@dirtside.com 
>>>   b...@herrin.us 
>>> Owner, Dirtside Systems . Web: >> >
>>> ___
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net 
>>> ).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml 
>>> 
>>> Please contact i...@arin.net  if you experience any 
>>> issues.
>>> 
>>> ___
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net 
>>> ).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml 
>>> 
>>> Please contact i...@arin.net  if you experience any 
>>> issues.
>> ___
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net 
>> ).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml 
>> 
>> Please contact i...@arin.net  if you experience any 
>> issues.
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy

[Brian Jones]

Support with the changes concerning the reserved pool.

On Wed, Oct 26, 2016 at 5:18 PM ARIN  wrote:

> The ARIN Advisory Council (AC) met on 21 October 2016 and decided to
> send Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy
> to Last Call:
>
> The AC provided the following statement to the community:
>
> This proposal is technically sound and enables fair and impartial number
> policy by ensuring that the number resources are used in accordance with
> the terms under which they were granted.  There is significant support
> for this change within the Internet community. Re: Merge into 2016-5.
> The new text "Address resources from a reserved pool (including those
> designated in Section 4.4 and 4.10) are not eligible for transfer."
> should be added to the revised 2016-5 sections 8.3 & 8.4 "Conditions on
> source of the transfer:”.
>
> Feedback is encouraged during the Last Call period. All comments should
> be provided to the Public Policy Mailing List. This Last Call will
> expire on 9 November 2016. After Last Call, the AC will conduct their
> Last Call review.
>
> The full text is below and available at:
> https://www.arin.net/policy/proposals/
>
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
>
> Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy
>
> AC assessment of conformance with the Principles of Internet Number
> Resource Policy:
>
> This proposal enables fair and impartial number resource administration
> by ensuring that IPv4 resources, which are specially designated for
> critical infrastructure and IPv6 transition, are readily available for
> many years into the future. This is done by ensuring the resources
> remain in their originally designated pool rather than being moved into
> the general IPv4 address pool via a transfer. This proposal is
> technically sound and is supported by the community.
>
> Problem Statement:
>
> Section 8 of the current NRPM does not distinguish between the transfer
> of blocks from addresses that have been reserved for specific uses and
> other addresses that can be transferred. In sections 4.4 and 4.10 there
> are specific address blocks set aside, based on the need for critical
> infrastructure and IPv6 transitions. Two issues arise if transfers of
> reserved address space occur under the current language of section 8.
> First, if transfers of 4.4 or 4.10 space occur under the current policy
> requirements set forth in sections 8.3 and 8.4, the recipients will be
> able to acquire space that was originally reserved for a specific
> purpose without ever providing evidence that they will be using the
> space for either critical infrastructure or IPv6 transition. Second, if
> we allow an allocation or assignment from the block reserved in section
> 4.10 to be transferred out of the region, it would complicate the single
> aggregate from which providers are being asked to allow in block sizes
> smaller than a /24. This policy would limit the transfer of addresses
> from reserved pools.
>
> Policy statement:
>
> Add to Section 8.3 and Section 8.4 under the "Conditions on source of
> the transfer:"
>
> Address resources from a reserved pool (including those designated in
> Section 4.4 and 4.10) are not eligible for transfer.
>
> Timetable for implementation: Immediate
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] [ARIN-consult] Community Consultation on CKN23-ARIN Now Open

[Brian Jones]

I support Option 3.

--
Brian


On Wed, Mar 29, 2017 at 1:34 PM Owen DeLong  wrote:

I support recommended option 3.

Owen

On Mar 27, 2017, at 12:39 , John Curran  wrote:

Folks -

We have initiated a community consultation on a possible restructuring
of existing
information in the ARIN registry – this is to address the long-standing
concern that
some have expressed with the association of a “No Contact Known”
point-of-contact
(POC) in some registry records that may have potentially valid Admin
and Tech
contact information.

If you have hold a strong view on this matter, please see the attached
consultation
announcement and participate in the discussion on the arin-consult
mailing list.

Thanks!
/John

John Curran
President and CEO
ARIN

===

Begin forwarded message:

*From: *ARIN 
*Subject: **[ARIN-consult] Community Consultation on CKN23-ARIN Now Open*
*Date: *22 March 2017 at 1:24:12 PM EDT
*To: *

There are thousands of instances of the ARIN Point of Contact (POC)
handle “No, Contact Known” or CKN23-ARIN registered in the ARIN
database, most of them associated with legacy resource records. ARIN
would like the community to review the history of this situation and the
proposed solution and provide us with their feedback.

The creation and addition of this POC handle was due to a combination of
factors.

* In 2002, a database conversion project was done at ARIN that
created a new database structure and added a new record type
(Organization ID) as well as new POC types (Admin, Tech, Abuse and NOC).
When an Org ID didn’t have a clear POC that had been recently updated or
vetted by ARIN staff, the original resource POC remained on the resource
record only and no POCs were added to the Org record at all.
* In a later 2011 database conversion, reverse DNS delegation
switched from per-net to per-zone. This created significant hijacking
potential by allowing resource POCs to change their reverse delegation
without first being verified by staff as legitimate.
* Also in 2011, ARIN added a new business rule that required an Admin
and a Tech POC on all Org records as a way of enhancing data quality.
* Policy 2010-14 was implemented in 2011 and required Abuse POCs on
all Org records.

In order to maintain ARIN’s business rules, comply with policy 2010-14,
and prevent hijackings, several actions were initiated by staff:

* CKN23-ARIN was created to become the Admin and Tech POC on Orgs
that lacked them
* Resource POCs of legacy networks that had never been updated or
validated by ARIN were moved to the Organization record as the Abuse POC
* ARIN’s verification and vetting requirements were thus reinstated
as the Abuse POC had to be vetted before making any changes to the
record, and therefore could not hijack the resource by adding or
changing the nameservers

Over time, the above actions have created several issues:

* It is easy for hijackers to identify and target records with CKN23
(no contact known) as the handle
* POCs that were moved from resource tech to Org abuse are not happy
about no longer having control of their resource record

There are several different courses of action that ARIN could take to
resolve the current situation.

Option 1

Retain the current status and do nothing

Option 2

Restore the resource POCs back to their original state on the
resource record keeping in mind that this would open up the hijacking
risk by giving the original resource POC control of the network without
a verification process
 * Retain the Abuse POC on the Org record
 * Retain CKN23-ARIN as Org POC

Option 3 - **Recommended option**

Restore the resource POC back to their original state on the
resource record.   This will allow contacts historically associated with
a resource record to more readily administer that record going forward.
 * Retain the Abuse POC on the Org
 * Replace CKN23-ARIN with a handle that better explains the record’s
status (e.g. “Legacy Record – See Resource POC”)
 * Lock all resources associated with these legacy records who have
had their resource POC restored. This would ensure that any changes made
by the resource POC would first have to be reviewed by ARIN.

We would like to thank the ARIN Services Working Group (WG) for their
helpful review of the proposed change – while the ARIN Services WG did
not take a formal position in support of or in opposition of the
proposed change, their review led to improvements in presentation of the
options

We are seeking community feedback on this proposed change (Option #3) to
the ARIN Registry database.

This consultation will remain open for 60 days - Please provide comments
to arin-cons...@arin.net.

Discussion on arin-cons...@arin.net will close on 22 May 2017.

If you have any questions, please contact us at i...@arin.net.

Regards,

John Curran
President and CEO
American Registry for Internet 

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

[Brian Jones]

On Tue, Jul 18, 2017 at 4:24 PM Owen DeLong  wrote:

>
> > On Jul 17, 2017, at 16:36 , John Curran  wrote:
> >
> > Albert -
> >
> >  We’ll research into these questions and report back shortly.
> >
> > Thanks!
> > /John
> >
> >> On 17 Jul 2017, at 2:53 PM, hostmas...@uneedus.com wrote:
> >>
> >> Just a couple of questions regarding the carrots and the sticks for the
> ARIN staff:
> >>
> >> Other than those who came back to change their initial /35 to a /32,
> how many ARIN customers have come back for another allocation of IPv6 space
> because they used the first one to the extent the rules require, which I
> think is 75% of /48 block assignments.
>
> Not many…. Yet. I know a few years ago, I filed the first such application
> (or at least so said RSHD at the time) on behalf of my employer at the time
> (HE) which requested (and received) a subsequent /24 to augment their
> existing /32 which was, in fact, more than 75% utilized.
>
> >> And, how many customers have received a first allocation of IPv6?
> >>
> >> Divide, and I can find out what percentage came back for more.
>
> The problem with this theory is that IPv6 is just getting started and the
> vast majority of ARIN customers that have received an initial IPv6
> allocation or assignment haven’t yet achieved full IPv6 deployment even to
> the point of parity with their IPv4 deployment. As such, measurements to
> date will be badly skewed to the low side of future reality.
>
+1
Even heavy users of IPv6 for years such as my organization are just now
realizing that we wished we had opted for for a /27 instead of a /32 now.
Even though we are mostly dual stacked everywhere we are just now seeing
the potential of being able to allocate IPv6 addressing in a more
meaningful way, and with all the research taking place with robots, drones,
driverless vehicles, bio-engineering, aerospace, etc… etc… we really may
have to go back to the well.


> >> What I would like to know is my gut feeling correct, which is that
> after receiving an allocation of IPv6, nearly nobody ever returns to the
> well for more, or at least not like it was back in the IPv4 days when ARIN
> had IPv4 address space to allocate, and thus there are no sticks?
>
> Your gut is definitely correct to date. However, prior performance does
> not predict future results. It’s true that a lot fewer organizations are
> likely to come back for additional IPv6 blocks and all will certainly come
> back less frequently than in IPv4. Nearly nobody is probably true today. It
> will probably remain less than “most” for the foreseeable future, but I
> don’t think “nearly nobody” is a permanent state.
>
> >> Another bit of info I would like to know if possible:  what percentage
> of customers with a v6 allocation has actually put any of their assignments
> into SWIP?  Since the current policy for SWIP in IPv6 is /64 or more, every
> allocation should be there.
>
>
We do have our IPv6 assignment in SWIP, not sure what percentage of folks
do, but it is useful information.


> Again, this isn’t necessarily going to yield accurate results. Many
> providers use RWHOIS as an alternative to SWIP. Many end users receive a
> /48 and it is directly registered by ARIN, so nothing to SWIP. There are
> also other situations (dynamic assignments, etc.) that are legitimately
> unlikely to result in SWIP.
>
> >> The answers are useful to determine as far as the documenting the
> assignment for ARIN, how useful SWIP is for that purpose.
> >>
> >> I have a /48 from 2 upstreams.  Only one is registered.  The other ISP
> does not appear to have ANY SWIP entries, even though I have set up the
> network with static v6 for at least a dozen customers, each of which
> received a /48.
>
> If that is the case, then that ISP is, indeed, in violation of ARIN policy
> and a fraud/abuse report to ARIN would not be out of order.
>
> >> Another "proxy" for to consider in deciding to SWIP or not might be the
> delegation of the reverse DNS for the allocated block. If there is a
> delegation, this is another way to find the technical contact other than
> SWIP if there is a problem.
>
> Not really reliable. In reality, there’s only one POC in the SOA and most
> providers in my experience populate that POC entry with meaningless
> unusable addresses.
>
> Owen
>
> >>
> >> Albert Erdmann
> >> Network Administrator
> >> Paradise On Line Inc.
> >>
> >>
> >> On Mon, 17 Jul 2017, David Farmer wrote:
> >>
> >>> On Mon, Jul 17, 2017 at 2:11 PM, David R Huberman 
> wrote:
> >>>
> 
>  Can you define voluntary?
> >
> > Is the voluntary choice to record a reassignment
> > up to the USP?
> >
> > Or does the choice belong to the end-user?
> >
> 
>  I think that's a business decision the two parties make together. I
> think
>  an ISP can choose to SWIP whatever it wants, and should do so with the
>  consent of the end-user. I think an end-user should be able 

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21

[Brian Jones]

On Mon, Jul 24, 2017 at 2:46 PM Owen DeLong  wrote:

> On Jul 24, 2017, at 04:03 , hostmas...@uneedus.com wrote:
>
> /47 or more addresses is intended to be /47, /46 . /1 and not the
> reverse.  The current language is "/64 or more", and I read that same
> phrase as /64, /63 . /1.  For comparison, the current IPv4 language is
> "/29 or more", and that seems clear to mean /29, /28 . /1, and not the
> reverse.  I do not think the "/X or more" language in the current NRPM or
> the proposal is unclear.
>
> As far as the remainder, I read this draft as two statements connected
> with an OR.  Thus there are 2 classes of assignments that are required to
> be SWIP'ed.  They are:
>
> 1) ANY IPv6 assignment containing a /47 or more addresses.
> 2) ANY sub-delegation of any size that will be individually announced.
>
> Due to rules for the GRT, this means /49 or less is not covered by 2).
> However, should the rules for the GRT ever change, 2) will cover it.  The
> intent of 2) is to require SWIP on ALL sub-delegations, without expressing
> that level, which is outside of ARIN control.
>
>
> There are no rules for the GRT. There are only each ASNs rules for what
> they will accept and announce and what ends up in any particular routing
> table is the intersection of routes accepted and routes advertised by peers.
>
> Just a quick sampling from Route-views:
>
> *  2001:218:200e:100::/56
> 2a01:73e0::1   0 47872 2914 i
> *   2001:67c:22dc:def1::1
>0 31019 41887
> 2914 i
> *   2c0f:fc00::2   0 3741 2914 i
> *   2001:d98::19   0 18106 4657
> 2914 i
> *   2001:418:0:1000::f000
>  17346  0 2914 i
> *   2a00:1728::2d:
>  0  0 34224 2914 i
> *>  2001:418:0:1000::f002
>  11266  0 2914 i
> *  2001:218:200e:200::/56
> 2a01:73e0::1   0 47872 2914 i
> *   2001:67c:22dc:def1::1
>0 31019 41887
> 2914 i
> *   2c0f:fc00::2   0 3741 2914 i
> *   2001:d98::19   0 18106 4657
> 2914 i
> *   2001:418:0:1000::f000
>  17346  0 2914 i
> *   2a00:1728::2d:
>  0  0 34224 2914 i
> *>  2001:418:0:1000::f002
>  11266  0 2914 i
> *  2001:218:200e:300::/56
> 2a01:73e0::1   0 47872 2914 i
> *   2001:67c:22dc:def1::1
>0 31019 41887
> 2914 i
> *   2c0f:fc00::2   0 3741 2914 i
> *   2001:d98::19   0 18106 4657
> 2914 i
> *   2001:418:0:1000::f000
>  17346  0 2914 i
> *   2a00:1728::2d:
>  0  0 34224 2914 i
> *>  2001:418:0:1000::f002
>  11266  0 2914 i
> *  2001:218:200e:400::/56
> 2a01:73e0::1   0 47872 2914 i
> *   2001:67c:22dc:def1::1
>0 31019 41887
> 2914 i
> *   2c0f:fc00::2   0 3741 2914 i
> *   2001:d98::19   0 18106 4657
> 2914 i
> *   2001:418:0:1000::f000
>  17346  0 2914 i
> *   2a00:1728::2d:
>  0  0 34224 2914 i
> *>  2001:418:0:1000::f002
>  11266  0 2914 i
>
> So clearly it is possible to announce  at least a /56 and even maybe a
> /126:
>
> *> 2001:218:4000:5000::338/126
> 2001:d98::19   0 18106 132602 ?
> *> 2001:218:4000:5000::368/126
> 2001:d98::19   0 18106 132602 ?
> *> 2001:218:4000:5000::42c/126
> 2001:d98::19   0 18106 132602 ?
> (though that doesn’t seem to have gotten very far)
>
> But this /64 got a bit further:
>
> *  2001:254:1:b::/64
> 2001:d98::19   0 18106 4635
> 10103 3662 3662 3662 3662 3662 3662 

Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

[Brian Jones]

I'm in favor of this draft and +1 Albert's suggested language for wording
changes.

--
Brian
​ E Jones
​

On Wed, Aug 16, 2017 at 7:10 AM,  wrote:

> I am in favor of the draft, with or without the changes to make it clearer.
>
> I suggest the following language for clarity:
>
> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the NRPM
> that reads "If the downstream recipient of a static assignment of /64 or
> more addresses requests publishing of that static assignment in ARIN's
> registration database, the ISP must register that static assignment."
>
> Since "static assignment" is the term in this section, not netblock, I
> suggest using this term instead of "netblock".  "Of any size" is not
> needed, as the language would require the ISP to register in total whatever
> size the ISP has assigned to the downstream in the ARIN database if
> requested by the downstream recipient, as long as it was /64 or more.
>
> This language would also prevent requests to register only part of an
> assignment. I think this language works in making the intent of the new
> section more clear.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
>
>
> On Tue, 15 Aug 2017, John Santos wrote:
>
> I think that the "/64 or more addresses" and the "regardless of size" are
>> meant to convey that any netblock between a /64 and a /48 can and should be
>> registered if the recipient requests it, even if the block is smaller than
>> the /47 which would make it mandatory.  Perhaps there is better wording
>> that would make this clearer.
>>
>> Three ranges:
>>
>> 1. smaller than /64:  shouldn't be issued, can't be registered.
>> 2. /64 through /48: register at recipient's request
>> 3. /47 or larger: must be registered
>>
>> I agree on dynamic assignments
>>
>> Otherwise, I think this is a much clearer and better update to the
>> proposed policy, and can't find any other reason not to support it.  (I.E.
>> this is a tentative vote FOR, if there is such a thing.)
>>
>>
>>
>> On 8/15/2017 3:59 PM, David Farmer wrote:
>>
>>> I support what I think is the intent, but I have language/editorial nits;
>>>
>>> 1. In 3) below; Which is it "a /64 or more addresses" or "regardless of
>>> size" that requires registration?  I think logically we need one or the
>>> other, or some qualification on "regardless of size" statement.  I think it
>>> is a good idea to not require registration of less than a /64.  But the
>>> current language seems contradictory, and therefore confusing, my
>>> recommendation is delete "regardless of size", from the sentence and
>>> leaving "a /64 or more addresses".  I pretty sure we don't want people
>>> having an expectation that they can request the registration of "their"
>>> /128 address.
>>>
>>> 2. Also in 3) below; It would seem to require even dynamic assignments
>>> be registered if requested, I don't think that is our intent either,
>>> section 6.5.5.1 starts with "Each static IPv6 assignment containing", this
>>> needs a similar qualification.
>>>
>>> Also, I'm fine with the deltas in the policy statement but it would be
>>> helpful to see the final resulting policy block, maybe in a separate email
>>> so we can all see how the result reads.
>>>
>>> Thanks, I think we are getting close, maybe one or two more turns of the
>>> crank.
>>>
>>> On Tue, Aug 15, 2017 at 12:06 PM, ARIN > i...@arin.net>> wrote:
>>>
>>> The following has been revised:
>>>
>>> * Draft Policy ARIN-2017-5: Equalization of Assignment
>>> Registration requirements between IPv4 and IPv6
>>>
>>> Revised text is below and can be found at:
>>> https://www.arin.net/policy/proposals/2017_5.html
>>> 
>>>
>>> You are encouraged to discuss all Draft Policies on PPML. The AC
>>> will evaluate the discussion in order to assess the conformance of
>>> this draft policy with ARIN's Principles of Internet number
>>> resource policy as stated in the Policy Development Process (PDP).
>>> Specifically, these principles are:
>>>
>>> * Enabling Fair and Impartial Number Resource Administration
>>> * Technically Sound
>>> * Supported by the Community
>>>
>>> The PDP can be found at:
>>> https://www.arin.net/policy/pdp.html
>>> 
>>>
>>> Draft Policies and Proposals under discussion can be found at:
>>> https://www.arin.net/policy/proposals/index.html
>>> 
>>>
>>> Regards,
>>>
>>> Sean Hopkins
>>> Policy Analyst
>>> American Registry for Internet Numbers (ARIN)
>>>
>>>
>>>
>>>
>>> Problem Statement:
>>>
>>> Current ARIN policy has different WHOIS directory registration
>>> requirements for IPv4 vs IPv6 address assignments. IPv4
>>> registration is triggered for an assignment of any address block
>>> equal to or greater than a /29 (i.e., eight 

Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

[Brian Jones]

I would be in support of more than a /56.

—
Brian E Jones CSM, CSPO
Network Infrastructure & Services
Virginia Tech
bjo...@vt.edu

On Tue, Jun 6, 2017 at 2:30 PM Leif Sawyer  wrote:

> Good day, PPML!
>
> First, as the primary shepherd for ARIN-2017-5,  I want to thank everybody
> for the spirited
> discussion on this proposal.  It's generated a lot of good feedback for
> the AC to take
> under consideration as we develop the text.
>
> Based on the community feedback, as well as internal dialog, I'm going to
> remove the IPv4
> requirements from the draft policy proposal.
>
> I'll have a new version of the draft text posted to the ARIN website once
> I'm finished with
> the edits and it's approved internally.
>
> It would still be very useful to understand if there's majority community
> support for
> specific nibble boundaries for the IPv6 cut-off.
>
> The boundaries at /60, /56, and /48  have all been discussed.  If one is
> more favorable than
> the other, and you would like to see the proposal edited to use that one,
> we will certainly
> take that under advisory.
>
> Thanks,
>
>   Leif Sawyer
>   ARIN  Advisory Council.
>
>
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network

[Brian Jones]

On Tue, Sep 19, 2017 at 1:20 PM Owen DeLong  wrote:

> I’d like to point out that I just learned of a community network that
> claims they did take advantage
> of the existing policy recently, so there is apparently at least one use
> of the present policy.
>
> I support this draft as an improvement to the existing policy, but I
> believe the argument that the
> community networks policy is never used no longer applies.
>

+1
As wireless becomes more prevalent in communities and small towns there may
be an increase in the number of community networks who wish to use this
part of the policy.


> Owen
>
> On Sep 19, 2017, at 12:29 PM, Chris Woodfield  wrote:
>
> I support this, with the comment that the phrase “volunteers play a large
> role” will be open to interpretation. Is this intentional? I’m fine if that
> is the case, but if not, I’d advocate for a more precise definition.
>
> I also support this policy with the stipulation Chris makes here. It needs
to be open to interpretation or flexible enough to allow for communities to
request the needed resources without too much hassle while meeting the
desirable documentation of resources needs of the ARIN community.

--
Brian



> Thanks,
>
> -C
>
> On Sep 19, 2017, at 8:21 AM, Andrew Dul  wrote:
>
> Hello all,
>
> We will be discussing this draft proposal at the upcoming ARIN meeting
> in San Jose.  If you have comments on the updated draft posted below,
> we'd certainly like to hear from you so we can help shape the
> conversation in person.
>
> We have seen some support for this updated draft, but not a lot.
> Furthermore, have we addressed all of your concerns which you might have
> noted earlier on the 1st version of the policy text.
>
> Thanks,
> Andrew
>
> On 8/24/2017 8:22 AM, ARIN wrote:
>
>
>
> Draft Policy ARIN-2017-8: Amend the Definition of Community Network
>
> Problem Statement:
>
> The Community Networks section of the NRPM has not been used since
> implementation in January 2010. Proposal ARIN-2016-7, to increase the
> number of use cases, was abandoned by the Advisory Council due to lack
> of feedback. Proposal ARIN 2017-2, to remove all mention of community
> networks from NRPM was met with opposition by the community. Many
> responded that the definition of “community network” was too narrow,
> which could be the reason for lack of uptake.
>
> Policy statement:
>
> CURRENT NRPM TEXT:
>
> “2.11. Community Network
>
> A community network is any network organized and operated by a
> volunteer group operating as or under the fiscal support of a
> nonprofit organization or university for the purpose of providing free
> or low-cost connectivity to the residents of their local service area.
> To be treated as a community network under ARIN policy, the applicant
> must certify to ARIN that the community network staff is 100%
> volunteers.”
>
> NEW NRPM TEXT:
>
> “2.11 Community Network
>
> A community network is a network organized and operated by a volunteer
> group, not-for-profit, non-profit, charitable organization, or
> educational institution for the purpose of providing free or low-cost
> connectivity, or other Information Technology services to persons or
> entities within their community. Critical functions may be handled by
> paid staff, but volunteers play a large role in offering services
> available through community networks.”
>
> Comments:
>
> Timetable for implementation: Immediate
> _
>
>
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
>
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
>
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers

[Brian Jones]

I support this policy as revised.

--
Brian

On Wed, Sep 6, 2017 at 2:35 PM ARIN  wrote:

> The following has been revised:
>
> * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR
> Transfers
>
> Revised text is below and can be found at:
> https://www.arin.net/policy/proposals/2017_4.html
>
> You are encouraged to discuss all Draft Policies on PPML. The AC will
> evaluate the discussion in order to assess the conformance of this draft
> policy with ARIN's Principles of Internet number resource policy as
> stated in the Policy Development Process (PDP). Specifically, these
> principles are:
>
> * Enabling Fair and Impartial Number Resource Administration
> * Technically Sound
> * Supported by the Community
>
> The PDP can be found at:
> https://www.arin.net/policy/pdp.html
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> Regards,
>
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
>
>
>
> Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR
> Transfers
>
> Version Date: 6 September 2017
>
> Problem Statement:
>
> AFRINIC and LACNIC are currently considering one-way inter-RIR transfer
> proposals. Those RIR communities feel a one-way policy a policy that
> allows network operators in their regions to obtain space from another
> region and transfer it into AFRINIC and LACNIC may best meet the needs
> of the operators in that region.
>
> ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated
> that ARINs 8.4 policy language will not allow ARIN to participate in
> such one-way transfers. The staff formally indicate to AFRINIC that the
> word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered
> space to transfer directly to AFRINIC (in this context).
>
> ARIN as a community should recognize that other RIR operator communities
> have different needs than we do. We should recognize that:
>
> - network operators in AFRINIC in LACNIC have need to obtain space in
> the market;
>
> - have reasons they think are important to not allow two-way transfers; and
>
> - we should understand that the history of the RIR system has led to
> LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address
> space than ARIN does.
>
> Policy statement:
>
> Add the following sentence after the first sentence of NRPM 8.4:
>
> Inter-RIR transfers may take place to an RIR with a non-reciprocal
> inter-RIR transfer policy only when the recipient RIR has an IPv4 total
> inventory less than the average (mean) of the IPv4 total inventory among
> all of the RIRs.
>
> Timetable for implementation: Upon the ratification of any inter-RIR
> transfer policy at another RIR that is one-way as described in the
> problem statement.
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

[Brian Jones]

Support RDP ARIN 2017-5: Improved IPv6 Registration Requirements as written.

--
Brian Jones

On Tue, Sep 26, 2017 at 1:37 PM Scott Leibrand <scottleibr...@gmail.com>
wrote:

> +1
>
> I support RDP ARIN-2017-5 as written.
>
> -Scott
>
> On Tue, Sep 26, 2017 at 10:31 AM, ARIN <i...@arin.net> wrote:
>
>> On 21 September 2017, the ARIN Advisory Council (AC) advanced the
>> following Draft Policy to Recommended Draft Policy status:
>>
>> ARIN-2017-5: Improved IPv6 Registration Requirements
>>
>> The text of the Recommended Draft Policy is below, and may also be found
>> at:
>>
>> https://www.arin.net/policy/proposals/2017_5.html
>>
>> You are encouraged to discuss all Recommended Draft Policies on PPML
>> prior to their presentation at the next ARIN Public Policy and Members
>> Meeting. PPML and PPC discussions are invaluable to the AC when
>> determining community consensus.
>>
>> The PDP can be found at:
>> https://www.arin.net/policy/pdp.html
>>
>> Draft Policies and Proposals under discussion can be found at:
>> https://www.arin.net/policy/proposals/index.html
>>
>> Regards,
>>
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>>
>>
>>
>> AC's Statement of Conformance with ARIN's Principles of Internet Number
>> Resource Policy:
>>
>> This proposal is technically sound and enables fair and impartial number
>> policy for easier IPv6 Registrations. The staff and legal review noted a
>> single clarification issue which has been addressed. There is ample support
>> for the proposal on PPML and no concerns have been raised by the community
>> regarding the proposal.
>>
>> Problem Statement:
>>
>> Current ARIN policy has different WHOIS directory registration
>> requirements for IPv4 vs IPv6 address assignments. IPv4 registration is
>> triggered for an assignment of any address block equal to or greater than a
>> /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs
>> for an assignment of any block equal to or greater than a /64, which
>> constitutes one entire IPv6 subnet and is the minimum block size for an
>> allocation. Accordingly, there is a significant disparity between IPv4 and
>> IPv6 WHOIS registration thresholds in the case of assignments, resulting in
>> more work in the case of IPv6 than is the case for IPv4. There is no
>> technical or policy rationale for the disparity, which could serve as a
>> deterrent to more rapid IPv6 adoption. The purpose of this proposal is to
>> eliminate the disparity and corresponding adverse consequences.
>>
>> Policy statement:
>>
>> 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike
>> "assignment containing a /64 or more addresses" and change to
>> "re-allocation, reassignment containing a /47 or more addresses, or
>> subdelegation of any size that will be individually announced,"
>>
>> and
>>
>> 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM
>> to strike the text "4.2.3.7.1" and change to "6.5.5.1"
>>
>> and
>>
>> 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by
>> deleting the phrase "holding /64 and larger blocks"
>>
>> and
>>
>> 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the
>> NRPM, to read: "If the downstream recipient of a static assignment of /64
>> or more addresses requests publishing of that assignment in ARIN's
>> registration database, the ISP should register that assignment as described
>> in section 6.5.5.1."
>>
>> Comments:
>>
>> a. Timetable for implementation:
>>
>> Policy should be adopted as soon as possible.
>>
>> b. Anything else:
>>
>> Author Comments:
>>
>> IPv6 should not be more burdensome than the equivalent IPv4 network size.
>> Currently, assignments of /29 or more of IPv4 space (8 addresses) require
>> registration. The greatest majority of ISP customers who have assignments
>> of IPv4 space are of a single IPv4 address which do not trigger any ARIN
>> registration requirement when using IPv4. This is NOT true when these same
>> exact customers use IPv6, as assignments of /64 or more of IPv6 space
>> require registration. Beginning with RFC 3177, it has been standard
>> practice to assign a minimum assignment of /64 to every customer end user
>> site, and less is never used. Th

Re: [arin-ppml] Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6)

[Brian Jones]

I support this draft policy as written.

Brian Jones

On Tue, Nov 21, 2017, 17:42 ARIN <i...@arin.net> wrote:

> On 16 November 2017, the ARIN Advisory Council (AC) advanced
> "ARIN-prop-245: Repeal of Immediate Need for IPv4 Address Space (NRPM
> Section 4.2.1.6)" to Draft Policy status.
>
> Draft Policy ARIN-2017-10 is below and can be found at:
> https://www.arin.net/policy/proposals/2017_10.html
>
> You are encouraged to discuss all Draft Policies on PPML. The AC will
> evaluate the discussion in order to assess the conformance of this draft
> policy with ARIN's Principles of Internet number resource policy as
> stated in the Policy Development Process (PDP). Specifically, these
> principles are:
>
> * Enabling Fair and Impartial Number Resource Administration
> * Technically Sound
> * Supported by the Community
>
> The PDP can be found at:
> https://www.arin.net/policy/pdp.html
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> Regards,
>
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
>
>
>
> Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address
> Space (NRPM Section 4.2.1.6)
>
> Problem Statement:
>
> Section 4.2.1.6 of the ARIN Numbering Resource Policy Manual (NRPM)
> provides that an ISP having an immediate need for IPv4 address space
> that will be utilized within thirty days of a request may obtain a block
> of IPv4 address space of the size specified in section 4.2.1.6 from ARIN
> on an exceptional basis. However, as noted in the ARIN 40 Policy
> Experience Report, since IPv4 exhaustion, obtaining IPv4 addresses in
> this manner is no longer possible as a practical matter. Instead an ISP
> must join the waiting list and wait until it reaches the front of the
> queue to obtain any IPv4 address space, however long that may take. In
> effect, section 4.2.1.6 is non-operative. Accordingly, its continued
> presence in the NRPM is misleading and confusing.
>
> Policy statement:
>
> Section 4.2.1.6 of the NRPM is hereby repealed and section number
> 4.2.1.6 is hereby retired.
>
> Comments:
>
> a. Timetable for implementation: Immediate
>
> b. Comments: Given the constraints created by the exhaustion of IPv4
> addresses, this proposal does not require any changes in the current
> ARIN practices for the allocation of IPv4 address space.
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment

[Brian Jones]

I support this proposal in principle. I'm not sure that 10 days is enough
time to work out a valid POC in some cases. If it is a new POC they need to
be made aware of what it means to be the POC and what is expected of them,
and some folks may want to set up a listserv or email group and make sure
all the members of the group understand the role associated with being a
POC.

--
Brian
​ Jones​

On Tue, Nov 21, 2017 at 5:43 PM, ARIN <i...@arin.net> wrote:

> On 16 November 2017, the ARIN Advisory Council (AC) advanced
> "ARIN-prop-247: Require New POC Validation Upon Reassignment" to Draft
> Policy status.
>
> Draft Policy ARIN-2017-12 is below and can be found at:
> https://www.arin.net/policy/proposals/2017_12.html
>
> You are encouraged to discuss all Draft Policies on PPML. The AC will
> evaluate the discussion in order to assess the conformance of this draft
> policy with ARIN's Principles of Internet number resource policy as stated
> in the Policy Development Process (PDP). Specifically, these principles are:
>
> * Enabling Fair and Impartial Number Resource Administration
> * Technically Sound
> * Supported by the Community
>
> The PDP can be found at:
> https://www.arin.net/policy/pdp.html
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> Regards,
>
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
>
>
>
> Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment
>
> Problem Statement:
>
> Some large ISPs assign individuals to be POCs for reassigned blocks
> without consultation of the individual they are inserting into Whois. One
> year later, the POC is contacted by ARIN as part of Annual POC Validation
> policies.  The POC often does not know who ARIN is, what Whois is, and why
> they are in Whois.
>
> This policy proposal seeks to improve the situation where a POC is
> unwittingly and unwantingly inserted into Whois.
>
> It also seeks to mitigate the significant amount of time that ARIN staff
> reports that they spend fielding phone calls from POCs who have no idea
> they are in Whois.
>
> Finally, it is hopeful that this proposal will improve the overall POC
> validation situation, by forcing ISPs and customers to work together to
> insert proper information into Whois at the time of sub-delegation.
>
> Policy statement:
>
> Insert two new sections into NRPM 3:
>
> 3.7 New POC Validation Upon Reassignment
>
> When an ISP submits a valid reallocation or detailed reassignment request
> to ARIN which would result in a new POC object being created, ARIN must
> (before otherwise approving the request) contact the new POC by email for
> validation. ARIN's notification will, at a minimum, notify the POC of:
>
> - the information about the organization submitting the record; and
> - the resource(s) to which the POC is being attached; and
> - the organization(s) to which the POC is being attached.
>
> If the POC validates the request, the request shall be accepted by ARIN
> and the new objects inserted into Whois.  If the POC does not validate the
> request within 10 days, ARIN must reject the request.
>
> 3.8 Downstream Validation of Simple Reassignments
>
> When an ISP submits a valid simple reassigment request to ARIN with an
> organization name OR postal address that is identical to one or more
> existing OrgIDs, ARIN will notify the downstream organization and obtain
> guidance on whether to accept the simple reassigment, or redirect it to one
> of the existing OrgIDs as a detailed reassignment.
>
> Comments:
>
> Timetable for implementation: Immediate
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup

[Brian Jones]

On Wed, Dec 6, 2017 at 1:36 PM Owen DeLong  wrote:

> The proposed editorial changes do not conflict with the current language,
> nor do they present a conflict with the revised language that will occur if
> the board ratifies 2017-5. Staff can intelligently apply this update to the
> NRPM in either state without conflict or loss of fidelity in either case.
>
> Owen
>
>
I +1 Owen's comments. It seems these changes could be made with or without
ratification of 2015-5.

--
Brian


> > On Nov 21, 2017, at 15:48 , the...@uneedus.com wrote:
> >
> > For the same reason as stated in comments to ARIN-2017-10, this proposal
> changes language in 6.5.5.1 which is before the ARIN Board regarding a
> change of the standard from /64 or more to /47 or more, or any size
> individually announced.
> >
> > I suggest the author take into consideration the change of this section
> in ARIN-2017-5 before the ARIN Board, before any changes to this section
> are made.
> >
> > Albert Erdmann
> > Network Administrator
> > Paradise On Line Inc.
> >
> > On Tue, 21 Nov 2017, ARIN wrote:
> >
> >> On 16 November 2017, the ARIN Advisory Council (AC) advanced
> "ARIN-prop-246: Reallocation and Reassignment Language Cleanup" to Draft
> Policy status.
> >>
> >> Draft Policy ARIN-2017-11 is below and can be found at:
> >> https://www.arin.net/policy/proposals/2017_11.html
> >>
> >> You are encouraged to discuss all Draft Policies on PPML. The AC will
> evaluate the discussion in order to assess the conformance of this draft
> policy with ARIN's Principles of Internet number resource policy as stated
> in the Policy Development Process (PDP). Specifically, these principles are:
> >>
> >> * Enabling Fair and Impartial Number Resource Administration
> >> * Technically Sound
> >> * Supported by the Community
> >>
> >> The PDP can be found at:
> >> https://www.arin.net/policy/pdp.html
> >>
> >> Draft Policies and Proposals under discussion can be found at:
> >> https://www.arin.net/policy/proposals/index.html
> >>
> >> Regards,
> >>
> >> Sean Hopkins
> >> Policy Analyst
> >> American Registry for Internet Numbers (ARIN)
> >>
> >>
> >>
> >> Draft Policy ARIN-2017-11: Reallocation and Reassignment Language
> Cleanup
> >>
> >> Problem Statement:
> >>
> >> The current text of NRPM uses the terms ‘reallocate’ and ‘reassign’ in
> ways that are both internally inconsistent within NRPM and inconsistent
> with the definitions of Reassignments and Reallocations as fields within
> the ARIN database. Frequently the term ‘reassignment’ or ‘reassign’ is used
> in NRPM as an umbrella term for both reallocations and reassignments. As a
> result, someone familiar with the ARIN Whois database, but unfamiliar with
> history of particular portions of NRPM and their intended meaning may
> interpret certain NRPM requirements as applying only to reassignments and
> not to reallocations. This is particularly problematic when it comes to
> SWIP requirements and the requirement to record reallocations and
> reassignments with ARIN, which under current text could be read to only
> apply to reassignments.
> >>
> >> Policy Statement:
> >>
> >> Make the following changes to the definitions in Section 2.5
> >>
> >> Current text:
> >>
> >> 2.5. Allocate and Assign
> >>
> >> A distinction is made between address allocation and address
> assignment, i.e., ISPs are "allocated" address space as described herein,
> while end-users are "assigned" address space.
> >>
> >> Allocate - To allocate means to distribute address space to IRs for the
> purpose of subsequent distribution by them.
> >>
> >> Assign - To assign means to delegate address space to an ISP or
> end-user, for specific use within the Internet infrastructure they operate.
> Assignments must only be made for specific purposes documented by specific
> organizations and are not to be sub-assigned to other parties.
> >>
> >> Proposed Editorial Change:
> >>
> >> 2.5 Allocation, Assignment, Reallocation, Reassignment
> >>
> >> Allocation - Address space delegated to an organization directly by
> ARIN for the purpose of subsequent distribution by the recipient
> organization to other parties.
> >>
> >> Assignment - Address space delegated to an organization directly by
> ARIN for the exclusive use of the recipient organization.
> >>
> >> Reallocation - Address space sub-delegated to an organization by an
> upstream provider for the purpose of subsequent distribution by the
> recipient organization to other parties.
> >>
> >> Reassignment - Address space  sub-delegated to an organization by an
> upstream provider for the exclusive use of the recipient organization.
> >>
> >> Make the following editorial changes to section 4.2:
> >>
> >> Current text:
> >>
> >> 4.2.1.1. Purpose
> >>
> >> ARIN allocates blocks of IP addresses to ISPs for the purpose of
> reassigning that space to their customers.
> >>
> >> Proposed Editorial Change:
> >>
> >> 4.2.1.1. Purpose
> >>
> >> ARIN allocates blocks of IP addresses to 

Re: [arin-ppml] Draft Policy ARIN-2018-4: Clarification on IPv6 Sub-Assignments

[Brian Jones]

Temporary or temporarily carries the more appropriate meaning from my
viewpoint.

--
Brian

On Thu, May 10, 2018 at 11:19 AM, Chris Woodfield 
wrote:

> The two terms, from my reading, are synonymous but carry different
> implications, with the term “non-permanently” implying a longer period of
> time than “temporarily". In practice, It will most likely be a distinction
> built into how addresses are assigned by the organization (i.e. static or
> dynamic assignment); would using that as our distinction be a useful avenue
> to explore?
>
> -C
>
> On May 10, 2018, at 8:07 AM, JORDI PALET MARTINEZ <
> jordi.pa...@consulintel.es> wrote:
>
> When I first used “temporarily” in a preliminary version of the proposal,
> I was argued that it is not clear then if it is “minutes, hours, days, …”,
> so non-permanently, looks like clearer in that sense … It may be a matter
> of not being native English speaker.
>
>
> Regards,
>
> Jordi
>
>
>
> *De: *ARIN-PPML  en nombre de John Santos <
> j...@egh.com>
> *Fecha: *jueves, 10 de mayo de 2018, 15:01
> *Para: *
>
> *Asunto: *Re: [arin-ppml] Draft Policy ARIN-2018-4: Clarification on IPv6
> Sub-Assignments
>
>
> I find the word "temporarily" even more obvious than "non-permanently".
> If those two words don't mean the same thing, then we definitely need a
> definition.
>
> On 5/10/2018 5:08 AM, JORDI PALET MARTINEZ wrote:
>
> What will be your opinion if I amend this proposal, so it works for both
> IPv4 and IPv6, having this text in section 2.5 (Allocate and Assign), make
> it shorter and more generic:
>
> “A unique IPv4 or IPv6 address or a unique IPv6 /64 prefix, which is
> non-permanently provided to third parties, shall not be considered an
> assignment”
>
> Alternatively, if we don’t want to go so far as to define the “size”:
>
> “An IPv4 or IPv6 block of address, which is non-permanently provided to
> third parties, shall not be considered an assignment”
>
> I didn’t found short-term defined in the NRPM. Do you still think we need
> to define “permanently” ? I think saying non-permanently it is quite
> obvious, but maybe folks disagree …
>
> Regards,
>
> Jordi
>
>
>
> *De: *ARIN-PPML   en
> nombre de Jo Rhett  
> *Fecha: *miércoles, 9 de mayo de 2018, 20:37
> *Para: * 
> *CC: * 
> *Asunto: *Re: [arin-ppml] Draft Policy ARIN-2018-4: Clarification on IPv6
> Sub-Assignments
>
> "Nominative, verb indirect" isn't English ;) Clean english structure would
> be:
>
> "A unique address or a unique /64 prefix that is non-permanently provided
> to third parties shall not be considered an assignment. "
>
> Or if you really want a descriptive phrase that modifies the nominative
> you can get commas like so:
>
>
>
> "A unique address or a unique /64 prefix, which is non-permanently
> provided to third parties, shall not be considered an assignment."
>
> I would also argue that this phrase is very vague unless "permanently" is
> defined elsewhere in the document. Wasn't there some phrasing around
> short-term assignment? (sorry, too busy/too lazy to grab the entire doc
> right now)
>
> On Fri, May 4, 2018 at 6:40 PM Andrew Dul  wrote:
>
> I'd like to suggest that the proposed policy text be shorted and
> clarified.  I don't believe all the examples are necessary in the
> definition section.
>
> Add to the end of NRPM Section 2.5 - https://www.arin.net/policy/
> nrpm.html#two5
>
> Current draft text:
>
> The fact that a unique address or even a unique /64 prefix is
> non-permanently provided to third parties, on a link operated by the
> original receiver of the assignment, shall not be considered a
> sub-assignment. This includes, for example, guests or employees (devices or
> servers), hotspots, and point-to-point links or VPNs. The provision of
> addressing for permanent connectivity or broadband services is still
> considered a sub-assignment. Only the addressing of the point-to-point link
> itself can be permanent and that addressing can't be used (neither directly
> or indirectly) for the actual communication.
>
> My suggested rewrite:
>
> A unique address or a unique /64 prefix that is non-permanently provided
> to third parties, shall not be considered an assignment.
>
>
>
> On 4/24/2018 11:57 AM, David Farmer wrote:
>
> I note that the text in question is the subject of an editorial change
> that the AC has recently forwarded to Board for review, at a minimum the
> policy text need to be updated to account for this editorial change.
> Further, I do not support the text as written.
>
> I support a change to section 2 that is not quite so IPv6 specific and
> focused more on the idea that providing hotspot, guest access, or other
> such temporary access does not necessitate the making of 

Re: [arin-ppml] Draft Policy ARIN-2018-3: Remove Reallocation Requirements for Residential Market Assignments

[Brian Jones]

Support ARIN-2018-3 as written.

--
Brian

> On Apr 23, 2018, at 3:21 PM, ARIN  wrote:
> 
> ARIN-prop-253



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] IPv6 Transfers (was :Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers

[Brian Jones]

On Tue, Feb 6, 2018 at 4:13 PM Chris Woodfield  wrote:

> And I’d point to the evidence of a transfer market specifically for 16-bit
> ASNs as good evidence of this.
>
> That said, I’d like to understand better the relative imbalance of supply
> and demand for these resources in the various RIR regions before I form a
> conclusion as to whether that imbalance justifies a policy change to
> resolve.
>
>
+1 Chris’s sentiments about better understanding the imbalances of supply
and demand for these resources in the various RIR regions before discussing
policy changes.

—
Brian



> -C
>
> > On Feb 6, 2018, at 12:39 PM, Job Snijders  wrote:
> >
> > On Tue, Feb 06, 2018 at 10:27:55AM -0800, Chris Woodfield wrote:
> >> RFC8092 was published roughly a year ago. I can’t imagine that we’ll
> >> see universal support for it anytime soon, and there’s plenty of gear
> >> out there on the internet today that won’t be getting a software
> >> update to support it.
> >
> > It'll be end of 2018 for general available software on the majority of
> > platforms - and for a company like NTT, a deployment of configurations
> > that use large community are likely to be in 2019 or maybe even 2020.
> > I don't intend this statement as a roadmap announcement, but rather to
> > illustrate the timescale.
> >
> > I'm tracking large community support here:
> http://largebgpcommunities.net/implementations/
> >
> >> I have encountered exactly this scenario, albeit on a private network,
> >> but I can’t imagine this not being a real-world issue for multiple
> >> operators with public 32-bit ASNs.
> >
> > yes, there are real-world issues for 32-bit ASN users today related to
> > communities. If I'd have to do a greenfield deployment of a new transit
> > network today, using a 16-bit ASN would be a blocking requirement due to
> > BGP communities. I imagine that for a number of years to come 16-bit
> > ASNs will be more desirable than 32-bit ASNs.
> >
> > Kind regards,
> >
> > Job
> >
>
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy 2017-03: Update to NPRM 3.6: Annual Whois POC Validation

[Brian Jones]

I support this draft policy with the new language.

—
Brian

On Mon, Feb 5, 2018 at 4:12 PM Potter, Amy  wrote:

> In response to the staff & legal assessment for 2017-3, we are proposing
> the following new language for subsection  3.6.5:
>
>
>
> 3.6.5
>
> An invalid POC is restricted to payment and contact update functionality
> within ARIN Online. As a result, an organization without any valid POCs
> will be unable to access further functionalities within ARIN Online until
> at least one Admin or Tech POC validates that their information is accurate
> or modifies a POC to contain accurate information.
>
>
>
> *ARIN STAFF & LEGAL ASSESSMENT*
>
> *Draft Policy ARIN-2017-03*
>
> *Update to NPRM 3.6: Annual Whois POC Validation*
>
> https://arin.net/policy/proposals/2017_3.html
>
>
>
>
>
> *Date of Assessment:  3 January 2018*
>
>
>
> ___
>
> *1.  Summary (Staff Understanding)*
>
>
>
> Draft Policy 2017-03 establishes the specific Whois Points of Contact
> (POCs) that are required to be verified annually. It further identifies
> which organizations are covered by this policy according to the type of
> resources that it holds i.e. direct assignments, direct allocations, AS
> numbers from ARIN (or one of its predecessor registries) or a reallocation
> from an upstream ISP. It specifically excludes reassignments made to
> downstream end user customers. DP 2017-03 defines the procedure to be
> followed to ensure the above specified POCs are verified through an email
> notification on an annual basis. It instructs ARIN staff to marked POC
> records deemed completely and permanently abandoned or otherwise
> illegitimate as invalid in Whois. It also directs action to be taken if an
> ADMIN or TECH POC has been marked invalid.
>
>
>
> ___
>
> *2.  Comments*
>
>
>
> A.  ARIN Staff Comments
>
>
>
> * 3.6.2 Specified Public Whois Points of Contact for Verification:  Lists
> the 4 types of POCs that must be verified annually. This is very clear.
>
> * 3.6.3 Organizations Covered by this Policy: Clearly states
> qualifications for an Organization’s POCs to require annual verification as
> well as those that do not require it. This is clear.
>
> * 3.6.4 Procedure for Verification: Describes the steps in the
> verification process. This is clear.
>
> * 3.6.5 Non-Responsive Point of Contact Records: This section is unclear
> regarding the scope of the impact to an organization having non-responsive
> POCs, as the phrase "any organization lacking a validated Admin or Tech POC
> will be unable to access the full suite of functionality” fails to specify
> the allowed/prohibited functionality for organizations lacking a valid
> contact.  Absent further clarification, ARIN staff will interpret this to
> mean that an organization without at least one validated Admin or Tech POC
> will only be able to access payment and contact update functionality within
> ARIN Online, regardless of the contact used for access.  For organizations
> that have at least one valid Admin or Tech contact, the organization will
> be able to access full functionality of ARIN Online, even if access is via
> one of its other non-responsive POCs.  If instead the desired policy
> outcome is that only a validated Admin or Tech POC may access full ARIN
> Online functionality, then the policy text should be clarified to that
> effect.
>
> * The proposed policy does not impact ARIN’s ability to provide ongoing
> registry services for number resources, only the ability of impacted
> organizations to make changes to their number resources and related
> services.
>
> * This policy could be implemented as written.
>
>
>
> *B.  ARIN General Counsel – Legal Assessment*
>
>
>
> * There are no material legal issues regarding this proposal.
>
>
>
>
>
> ___
>
> *3.  Resource Impact*
>
>
>
> Implementation of this policy would have minimal resource impact. It is
> estimated that implementation could occur within 3 months after
> ratification by the ARIN Board of Trustees. The following would be needed
> in order to implement:
>
>
>
> * Updated guidelines and internal procedures
>
> * Staff training
>
> * Minimal engineering work
>
>
>
> ___
>
> 4*. Proposal / Draft Policy Text Assessed*
>
>
>
> Draft Policy ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation
>
>
>
> *Version Date:* 14 November 2017
>
>
>
> *Problem Statement:*
>
>
>
> Many of the Point of Contacts listed in ARIN's public Whois database
> contain out-of-date and inaccurate contact information.
>
>
>
> *Policy Statement:*
>
>
>
> *Current Text*:
>
>
>
> 3.6 Annual Whois POC Validation
>
> 3.6.1 Method of Annual Verification
>
> During ARIN's annual Whois POC validation, an email will be sent to every
> POC in the Whois database. Each POC will have a maximum of 60 days to
> respond with an affirmative that their Whois contact information is correct
> and complete. Unresponsive POC email addresses shall be marked as such in
> the database. If ARIN staff deems a POC to be 

Re: [arin-ppml] ARIN-PPML 2018-1

[Brian Jones]

On Mon, Feb 5, 2018 at 2:54 PM David R Huberman  wrote:

>
> If I may, I'd like to try and re-focus the discussion of 2018-1 on the
> network engineering problem that prompted this draft proposal. The
> solution this draft policy proposal offers to the problem is where I think
> the real value is, and where I think PPML needs to focus.
>
> Since the publication of RFC1997 in the 1996, network engineers have
> utilized an extension of BGP called the BGP communities attribute to
> enginer traffic (to "shape traffic") in a desirable way.
>
> RFC1997 only supports the use of 2-byte ASNs.  As the free pool of 2-byte
> ASNs began to shrink, a solultion was needed to enable networks
> labelled with 4-byte ASNs to utilize BGP community attributes.
>
> In 2010, a draft of Flexible Community attribute was discussed, but no
> working code was widely released. In 2016, a draft of Wide Comunity
> attributes was released, but also resulted in no working code.  Finally,
> in February 2017, RFC8092 was published, and Large BGP Communities became
> the protocol standard for defining 4-byte AS numbers within the BGP
> community attribute.
>
> Working code exists for some equipment and software, is planned for other
> equipment and software, but the point is that RFC8092-compliant code is
> not prevelant in the DFZ.  This is important because it means a network
> operator who wants to shape their traffic properly with BGP communities
> still needs a 2-byte ASN or it won't work.
>
> This proposal addresses the problem by allowing registrants of an unused
> or unwanted 2-byte ASN to transfer the registration to a network operator
> who needs one, all within the existing and community agreed-upon framework
> of Inter-RIR transfers.
>
> For this reason, I support draft policy proposal ARIN-2008-1.
>
>
I support this proposal for the same reason given:

“This proposal addresses the problem by allowing registrants of an unused or
unwanted 2-byte ASN to transfer the registration to a network operator who
needs one, all within the existing and community agreed-upon framework

of Inter-RIR transfers."

—
Brian


> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised/Re-titled - Draft Policy ARIN-2017-8: Amend Community Networks

[Brian Jones]

Don’t know if I responded to this for sure but agree it should be advanced.

—
Brian

On Wed, Jan 31, 2018 at 3:33 PM David Farmer  wrote:

> Unless there are additional comments or suggestions, I plan to propose
> this Policy is advanced to Recommended Draft Policy at the AC's February
> meeting.
>
> Thanks
>
> On Wed, Jan 24, 2018 at 7:46 AM, ARIN  wrote:
>
>> The following has been revised and re-titled:
>>
>> * Draft Policy ARIN-2017-8: Amend Community Networks
>>
>> Revised text is below and can be found at:
>> https://www.arin.net/policy/proposals/2017_8.html
>>
>> You are encouraged to discuss all Draft Policies on PPML. The AC will
>> evaluate the discussion in order to assess the conformance of this draft
>> policy with ARIN's Principles of Internet number resource policy as stated
>> in the Policy Development Process (PDP). Specifically, these principles are:
>>
>> * Enabling Fair and Impartial Number Resource Administration
>> * Technically Sound
>> * Supported by the Community
>>
>> The PDP can be found at:
>> https://www.arin.net/policy/pdp.html
>>
>> Draft Policies and Proposals under discussion can be found at:
>> https://www.arin.net/policy/proposals/index.html
>>
>> Regards,
>>
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>>
>>
>>
>>
>>
>> Draft Policy ARIN-2017-8: Amend Community Networks
>>
>> Problem Statement:
>>
>> The Community Networks section of the NRPM has only been used once since
>> implementation in January 2010. Proposal ARIN-2016-7, to increase the
>> number of use cases, was abandoned by the Advisory Council due to lack of
>> feedback. Proposal ARIN 2017-2, to remove all mention of community networks
>> from NRPM met with opposition by the community. Many responded that the
>> definition of "community network" was too narrow, which could be the reason
>> for lack of uptake.
>>
>> In the discussion at ARIN 40, it was clear that more than just the
>> definition of a community network needed revision and that community
>> networks need to have allocations, not assignments. Additionally, community
>> networks need to make reassignments to end-users in accordance with
>> applicable policies.
>> ​​
>> Policy statement:
>>
>> Replace section 2.11 with the following;
>>
>> 2.11 Community Network
>>
>> A community network is deployed, operated, and governed by its users, for
>> the purpose of providing free or low-cost connectivity to the community it
>> services. Users of the network or other volunteers must play a primary role
>> in the governance of the organization, whereas other functions may be
>> handled by either paid staff or volunteers.
>>
>> Rename section 6.5.9 and revise the last sentence as follows;
>>
>> 6.5.9. Community Network Allocations
>>
>>
+1

> While community networks would normally be considered to be ISP type
>> organizations under existing ARIN criteria, they tend to operate on much
>> tighter budgets and often depend on volunteer labor. As a result, they tend
>> to be much smaller and more communal in their organization rather than
>> provider/customer relationships of commercial ISPs. This section seeks to
>> provide a policy that is more friendly to those environments by allowing
>> community network to receive a smaller allocation than other LIRs or
>> commercial ISPs.
>>
>> +1


> Community networks may also qualify under section 6.5.2 as a regular LIR.
>>
>> Section 6.5.9.1 is not changing, but is included here for completeness;
>>
>> 6.5.9.1. Qualification Criteria
>>
>> To qualify under this section, a community network must demonstrate to
>> ARIN's satisfaction that it meets the definition of a community network
>> under section 2.11 of the NRPM.
>>
>> Replace section 6.5.9.2 and 6.5.9.3 with the following;
>>
>> 6.5.9.2. Allocation Size
>>
>> Community networks are eligible only to receive an allocation of /40 of
>> IPv6 resources under this section. Community networks that wish to receive
>> a larger initial allocation or any subsequent allocations must qualify as a
>> regular LIR, see sections 6.5.2 or 6.5.3 respectively.
>>
>> 6.5.9.3. Reassignments by Community Networks
>>
>> Similar to other LIRs, Community networks shall make reassignments to
>> end-users in accordance with applicable policies, in particular, but not
>> limited to sections 6.5.4 and 6.5.5. However, they shall not reallocate
>> resources under this section.
>>
>> Comments:
>>
>> Timetable for implementation: Immediate
>>
>> Anything Else:
>>
>> The rationale for restricting community networks that receive resources
>> through this policy from making reallocations is that a /40 is a tiny IPv6
>> allocation and it does not seem reasonable to subdivide such a small
>> allocation into even smaller reallocations.
>>
>> Also, the recommended size for reassignment is /48, to even the smallest
>> end-users, and therefore a /40 only provides 256 such reassignments.
>>
>>
I agree they should become or apply for 

Re: [arin-ppml] Recommended Draft Policy ARIN-2018-3: Remove Reallocation Requirements for Residential Market Assignments

[Brian Jones]

I agree with Owen that this is mostly clean up from post IPv4 exhaustion.

--
Brian E Jones, CSP-SM, CSP-PO
NI Virginia Tech
bjo...@vt.edu

> On Jul 26, 2018, at 6:44 AM, Owen DeLong  wrote:
> 
> I will point out that removing the requirement does not prevent anyone from 
> continuing to provide the information. It merely makes it optional instead of 
> mandatory.
> 
> In many cases, the reporting in question is an artifact of policy that was 
> specially crafted to aid CMTS-based providers in being able to obtain 
> sufficient IP space to actually provision networks while attempting to avoid 
> widespread and massive abuse through a gaping policy loophole. Given the 
> absence of an IPv4 free pool, that policy is no longer particularly 
> applicable and I believe some of it has already been eliminated. As such, 
> this is, IMHO, just some additional cleanup of the NRPM to further adapt to a 
> post-IPv4 world.
> 
> Owen
> 
> 
>> On Jul 25, 2018, at 15:27 , Azinger, Marla  wrote:
>> 
>> If I read this correct, you would be removing the requirement of public 
>> records that display not just static re-allocations for a general geographic 
>> area, but it would also remove Dynamic pool re-allocations.
>> 
>> If I saw what requirement is being removed correctly, in either respect 
>> should anyone stop doing those type of Re-allocations, they will receive an 
>> increase of abuse calls from law enforcement given one layer of useful data 
>> is being halted.  It also might increase geographic route issues because I 
>> have come across some companies that sell geo filter software based off ARIN 
>> records.
>> 
>> Food for thought
>> Marla
>> 
>> -Original Message-
>> From: ARIN-PPML  On Behalf Of ARIN
>> Sent: Tuesday, July 24, 2018 11:06 AM
>> To: arin-ppml@arin.net
>> Subject: [arin-ppml] Recommended Draft Policy ARIN-2018-3: Remove 
>> Reallocation Requirements for Residential Market Assignments
>> 
>> 
>> WARNING: External email. Please verify sender before opening attachments or 
>> clicking on links.
>> 
>> 
>> 
>> 
>> On 19 July 2018, the ARIN Advisory Council (AC) advanced the following Draft 
>> Policy to Recommended Draft Policy status:
>> 
>> ARIN-2018-3: Remove Reallocation Requirements for Residential Market 
>> Assignments
>> 
>> The text of the Recommended Draft Policy is below, and may also be found at:
>> 
>> https://www.arin.net/policy/proposals/2018_3.html
>> 
>> You are encouraged to discuss all Recommended Draft Policies on PPML prior 
>> to their presentation at the next ARIN Public Policy Consultation (PPC). 
>> PPML and PPC discussions are invaluable to the AC when determining community 
>> consensus.
>> 
>> The PDP can be found at:
>> https://www.arin.net/policy/pdp.html
>> 
>> Draft Policies and Proposals under discussion can be found at:
>> https://www.arin.net/policy/proposals/index.html
>> 
>> Regards,
>> 
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>> 
>> 
>> 
>> Recommended Draft Policy ARIN-2018-3: Remove Reallocation Requirements for 
>> Residential Market Assignments
>> 
>> Advisory Council Statement of Conformance with Principles of Internet Number 
>> Resource Policy:
>> 
>> This recommended draft policy is technically sound, creating a fair and 
>> impartial number policy. The draft policy removes the Residential Market 
>> Area record keeping and publication requirement placed upon one segment of 
>> the ISP population for ARIN IPv4 allocations. Since this requirement does 
>> not apply to IPv4 transfers it is a legacy element of policy sustaining 
>> administrative overhead for a subset of the community.  No concerns have 
>> been raised by the community  and there has been demonstrable support since 
>> its initial proposal.
>> 
>> Problem Statement:
>> 
>> Current number policy requires some organizations to create reallocations or 
>> reassignments for residential subscribers.  This requirement complicates 
>> record keeping for ISPs.  There is limited value today for requiring these 
>> records be put into the ARIN database.
>> 
>> ARIN number policy for a long time has required ISPs to add a reallocation 
>> or reassignment record for each of their subscriber address blocks.  This 
>> policy dates from the original cable allocations as a method to publicly 
>> show that a portion of a larger block has been put into use.
>> 
>> Since ARIN no longer has a free pool of IPv4 addresses and requirements for 
>> transfer are demonstrated without these records, this requirement is no 
>> longer needed.
>> 
>> Furthermore, this requirement complicates reallocation & reassignment entry 
>> into the ARIN database.3  Removing this requirement could reduce the 
>> complexity required for accurately maintaining reallocation and/or 
>> reassignment records.
>> 
>> Policy statement:
>> 
>> Remove Section 4.2.3.7.3.1 (Residential Market Area) from the NRPM
>> 
>> Comments:

Re: [arin-ppml] Draft Policy ARIN-2018-2 :Clarification to ISP Initial Allocation and Permit Renumbering (Language improvement)

[Brian Jones]

I support this policy. It aligns with the transfer policy better and clarifies 
initial allocation in section 4.2.2.

--
Brian E Jones
bjo...@vt.edu

> On Jun 23, 2018, at 4:18 PM, Kerrie Vassall-Richards 
>  wrote:
> 
> 
> Clarification to ISP initial allocation and permit renumbering
> Proposal Originator
> name: Jason Schiller
> email: jschil...@google.com 
> telephone: 202-258-8863
> organization: Google LLC
> Date: 02/01/2017
> Problem Statement:
> 
> As discussed in more detail in ARIN-2017-9 and noted in the ARIN 40 Policy 
> Experience Report, the criteria to qualify for an initial block of address 
> space in 4.2.2 and 8.5.4 are seeming at odds with each other. At ARIN 41 the 
> community seemed to prefer the approach contained in this policy over the 
> approach in ARIN-2017-9, which was subsequently abandoned.
> 
> Moreover, as the NRPM (2018-1) currently sits, 4.2.2 appears to state that an 
> initial allocation of up to a /21 could be granted without any more 
> justification than needed to qualify for a /24. Therefore, 4.2.2 should be 
> modified, allowing an initial allocation of only a /24 without any additional 
> justification and allowing an initial allocation of up to a /21 when 
> justified by a 24-month allocation plan.
> 
> Policy Statement:
> 
> Replace the current Section 4.2.2 with:
> 
> 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.
> 
> All ISP organizations without direct allocations, direct assignments, 
> re-allocations or reassignments automatically qualify for a /24. These 
> organizations are exempt from requirements of showing the efficient 
> utilization of previously held IPv4 space. These organizations may qualify 
> for a larger than a /24 by documenting how the requested allocation will be 
> utilized within the request size specified in 4.2.4.3
> 
> ISPs holding re-allocations and/or reassignments must show the efficient 
> utilization of their resources consistent with the requirements in sections 
> 4.2.3 and 4.2.4
> 
> 
> Comments:
> 
> The timetable for Implementation: Immediate
> 
> Anything Else:
> 
> This is an attempt to clarify the changes that came about from 2016-4.
> It also aligns section 4.2 with current transfer policy.
> It also re-established the understanding that ISP can renumber and return, 
> but putting the last section 4.2.2.1.4 into the ISP additional requests 
> section. This text is slightly modified to include returns to ARIN in 
> addition to returns to the upstream.
> 
> 
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] ARIN-2018-1: Allow Inter-regional ASN Transfers

[Brian Jones]

While I do not see the burning need for this, evidence suggests that it does 
occur, therefore a policy to cover it seems appropriate. I support this policy.

--
Brian E Jones, CSP-SM, CSP-PO
NI Virginia Tech
bjo...@vt.edu

> On Aug 13, 2018, at 1:01 PM, WOOD Alison * DAS  wrote:
> 
> ARIN Community:
> 
> As we approach the next ARIN meeting, I would like to remind the community of 
> the proposal to allow inter-regional ASN transfers.  I will be presenting 
> this topic at the meeting and would love to address any comments or questions 
> on this proposal.  Please feel free to email the PPML with your interest on 
> this policy proposal.
> 
> Thank you!
> 
> -Alison Wood
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net 
> ).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml 
> 
> Please contact i...@arin.net  if you experience any 
> issues.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Beneficial Owners

[Brian Jones]

> On Jul 16, 2018, at 5:36 AM, Ronald F. Guilmette  
> wrote:
> 
> Bottom line?  If goofballs from outside of ARIN's North American and
> Caribbean geographical region feel the need to get chunks of IPv4 space
> and then preceed to use those to screw up the Internet, then I for one
> would greatly prefer it if they were at least forced to obtain their
> IPv4 space from either legitimate broker transactions or preferably
> from their own Regional Internet Registries.

A huge +1.

--
Brian E Jones


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy 2017-12: Require POC Validation Upon Reassignment

[Brian Jones]

I support draft proposal 2017-12. It is a good step forward for POC
validation.

--
Brian
​ E Jones
Agile Process Engineer
​Virginia Tech​
​

On Mon, Mar 12, 2018 at 5:47 PM, Christian Tacit 
wrote:

> Dear Community Members,
>
>
>
> The shepherds for the Draft Policy 2017-12: Require POC Validation Upon
> Reassignment, are making two changes to its text.
>
>
>
> First, the problem statement is being expanded a bit to explain how POCs
> for reassigned blocks can be assigned without the knowledge of the
> individuals so assigned under the present policy.
>
>
>
> Second, proposed section 3.8 has been deleted. This is because it is
> unintentionally misleading because a simple reassignment results in a
> customer identifier versus an OrgID.   There is no contact information
> contained in a simple reassignment other than street address that could be
> used for notification, and thus it does not appear that the proposed NRPM
> 3.8 policy text is implementable.  Even if notification were possible, the
> “OR postal address” in this section may also cause significant problems for
> some companies as many companies have the same name associated with many
> different locations and there are several locations that have many
> companies registered there.
>
>
>
> Based on these changes, the revised text reads:
>
>
>
> *Version Date: March 12, 2018*
>
>
>
> *Problem Statement:*
>
> Some large ISPs assign individuals to be POCs for reassigned blocks
> without consultation of the individual they are inserting into Whois. For
> example, during the reassignment/reallocation process, some large ISPs
> automatically create POCs from their customer’s order form. This process is
> automated for many ISPs and therefore the resulting POCs are not validated
> prior to being created in the ARIN Whois database. This creates unknowing
> POCs that have no idea what Whois is or even who ARIN is at the time they
> receive the annual POC validation email. It can also create multiple POCs
> per email address causing that same person to receive a multitude of POC
> Validation emails each year.
>
> This policy proposal seeks to improve the situation where a POC is
> unwittingly and unintentionally inserted into Whois.
>
> It also seeks to mitigate the significant amount of time that ARIN staff
> reports that they spend fielding phone calls from POCs who have no idea
> they are in Whois.
>
> Finally, it is hopeful that this proposal will improve the overall POC
> validation situation, by forcing ISPs and customers to work together to
> insert proper information into Whois at the time of sub-delegation.
>
>
>
> *Policy statement:*
>
> Insert one new section into NRPM 3:
>
> 3.7 New POC Validation Upon Reassignment
>
> When an ISP submits a valid reallocation or detailed reassignment request
> to ARIN which would result in a new POC object being created, ARIN must
> (before otherwise approving the request) contact the new POC by email for
> validation. ARIN's notification will, at a minimum, notify the POC of:
>
> - the information about the organization submitting the record; and
> - the resource(s) to which the POC is being attached; and
> - the organization(s) to which the POC is being attached.
>
> If the POC validates the request, the request shall be accepted by ARIN
> and the new objects inserted into Whois.  If the POC does not validate the
> request within 10 days, ARIN must reject the request.
>
>
>
> *Timetable for implementation:* Immediate
>
>
>
> Comments from the community are welcome!
>
>
>
>
> Christian S. Tacit
>
>
>
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Requesting moderator intervention

[Brian Jones]

I would have to agree with others, most email lists I am a part of,
especially of this type, do not allow attachments these days.

--
Brian

On Fri, Apr 20, 2018 at 9:16 AM, Chris James  wrote:

> +1
> This list should NOT permit attachments.
>
> On Thu, Apr 19, 2018 at 2:34 PM, William Herrin  wrote:
>
>> On Thu, Apr 19, 2018 at 4:34 PM, Ron Grant  wrote:
>> > Please moderate the list. I don't want to unsub.
>>
>> 1. Slow down the train.
>>
>> 2. Marilson,the correct answer is: "I'm sorry. It won't happen again."
>> I get that you don't like spam. I don't like spam either. Forwarding a
>> spam with potentially pornographic content to this mailing list was a
>> real bonehead move. If you can't accept that it was an error, perhaps
>> you should be removed from this list.
>>
>> 3. Is there any compelling reason why this mailing list should permit
>> attachments in the first place? Can we not express our thoughts with
>> words?
>>
>> Regards,
>> Bill Herrin
>>
>>
>> --
>> William Herrin  her...@dirtside.com  b...@herrin.us
>> Dirtside Systems . Web: 
>> ___
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
>>
>
>
> This e-mail message may contain confidential or legally privileged
> information and is intended only for the use of the intended recipient(s).
> Any unauthorized disclosure, dissemination, distribution, copying or the
> taking of any action in reliance on the information herein is prohibited.
> E-mails are not secure and cannot be guaranteed to be error free as they
> can be intercepted, amended, or contain viruses. Anyone who communicates
> with us by e-mail is deemed to have accepted these risks. This company is
> not responsible for errors or omissions in this message and denies any
> responsibility for any damage arising from the use of e-mail. Any opinion
> and other statement contained in this message and any attachment are solely
> those of the author and do not necessarily represent those of the company.
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
>
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Board of Trustees Remands Recommended Draft Policy ARIN-2017-12

[Brian Jones]

This seems completely reasonable to me.

--
Brian E Jones, CSP-SM, CSP-PO
NI Virginia Tech
bjo...@vt.edu

> On Oct 20, 2018, at 2:14 PM, Andrew Dul  wrote:
> 
> I'd like to propose to the community a rewrite of 2017-12 that would 
> hopefully bring it in line with the Implementation B option of the Staff 
> Implementation memo.
> 
> What do others think of this approach?
> 
> Andrew
> 
> 
> ===
> 
> Policy statement:
> 
> Insert one new section into NRPM 3:
> 
> 3.7 POC Validation Upon Reassignment or Reallocation
> 
> When an organization submits a valid reallocation or detailed reassignment 
> request to ARIN, the reallocation or reassignment record must contain POC 
> objects which are currently valid in the ARIN database.  If the POC objects 
> are not valid, ARIN shall immediately reject the reallocation or reassignment 
> request.
> 
> If the reassignment or relocation record is inserted into the database, ARIN 
> will email the POCs associated with the new record notifying them of the new 
> resource being attached to their POC.
> 
> If the reassignment or relocation record fails to be inserted because the 
> POCs are not currently valid, ARIN should send an email notification to the 
> associated POCs that a reassignment or reallocation record was rejected 
> because their POC is not currently valid, and provide a link for the user to 
> validate their POC.
> 

+1


> 
> 
> On 8/27/2018 8:12 AM, John Curran wrote:
>> On 16 Aug 2018, at 7:04 PM, ARIN   
>> wrote:
>>> On 31 July 2018, the ARIN Board of Trustees remanded Recommended Draft 
>>> Policy ARIN-2017-12: Require New POC Validation Upon Reassignment to the 
>>> Advisory Council, noting:
>>> 
>>> "The ARIN Board of Trustees remands ARIN Recommended Draft Policy 2017-12: 
>>> Require New POC Validation Upon Reassignment to the ARIN Advisory Council. 
>>> Noting the complexity of the policy, the Board wants a more complete policy 
>>> assessment of technical soundness, and recommends interviews by the 
>>> Advisory Council with ISPs who make numerous delegation requests including 
>>> those with IP management platforms, if such interviews have not been 
>>> already conducted."
>>> 
>>> The Advisory Council is considering the remand of the Recommended Draft 
>>> Policy and appropriate next steps.
>>> 
>>> Board of Trustees Meeting Minutes are available at:
>>> 
>>> https://www.arin.net/about_us/bot/index.html 
>>> 
>>> 
>>> Draft Policy and Policy Proposal texts are available at:
>>> 
>>> https://www.arin.net/policy/proposals/index.html 
>>> 
>>> 
>>> The ARIN Policy Development Process (PDP) can be found at:
>>> 
>>> https://www.arin.net/policy/pdp.html 
>> Note also that the ARIN Board of Trustees reviewed the AC recommendation as 
>> well as a Staff Implementation Assessment memo when considering disposition 
>> of Recommended Draft Policy ARIN-2017-12.   A copy of that Staff 
>> Implementation Assessment memo is attached as background.
>> 
>> /John
>> 
>> John Curran
>> President and CEO
>> ARIN
>> 
>> 
>> 
>> ___
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net 
>> ).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml 
>> 
>> Please contact i...@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@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements

[Brian Jones]

I support this policy as written. Clarity is a good thing and section 4 can
definitely use the recommended updates.
—
Brian Jones


On Sun, Mar 3, 2019 at 9:00 PM Tom Fantacone  wrote:

> Chris,
>
> Thanks for the clarification.  I support the policy.
>
> In terms of implementation, I'm guessing when an organization seeks
> pre-approval for a particular block size, if they've transferred out space
> within the last 12 months, ARIN will advise them that their pre-approval
> will only allow them to receive space on the transfer market.  If they
> haven't transferred space out in the last 12 months, they'll have the
> option, as they do now, of receiving space via transfer or going on the
> waiting list.
>
> Tom
>
>
>  On Sun, 03 Mar 2019 13:02:35 -0500 *Chris Woodfield
> >* wrote 
>
> Hi Tom - responses inline.
>
> One additional point - the current policy places a limit on how often an
> organization can receive resources from the waiting list. This draft
> changes the hold-down timer so that it now applies to *applications* for
> new allocations under the waiting list policy, not the receipt of resources
> from it.
>
> > On Mar 3, 2019, at 7:18 AM, Tom Fantacone  wrote:
> >
> > Chris,
> >
> > The "clarification" part of your proposal seems to be a no brainer (the
> waiting period is meant to apply to allocations only under section 4). I
> assume ARIN staff is already interpreting it this way since that was the
> intent of the section. So I wouldn't sever it unless the full policy
> doesn't gain support in which case we could revisit just inserting the
> clarification part.
> >
>
> That assumption is my understanding as well.
>
> > Regarding this:
> > "- Disallows organizations that have transferred space to other parties
> within the past 12 months from applying for additional IPv4 space under
> NRPM Section 4. "
> >
> > I want to make sure I understand it correctly. If you transfer out space
> via 8.2/8.3/8.4, does this restriction mean you just can't receive space
> via the waiting list for 12 months, or via any mechanism (waiting
> list/transfer) for 12 months? I think it means from the waiting list only,
> but want to be sure.
> >
>
> That is correct - note the phrase “...under this section...” in the
> proposal text.
>
> Thanks,
>
> -Chris
>
>
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] ARIN-PPML Draft 2019-1

[Brian Jones]

I support Draft Policy 2019-1 with the new proposed language.

--
Brian E Jones, CSP-SM, CSP-PO
NI Virginia Tech
bjo...@vt.edu

> On Apr 18, 2019, at 7:20 AM, Rudolph Daniel  wrote:
> 
> 
> I support this draft proposal..
> RD
> 
> On Wed, Apr 17, 2019 at 12:00 PM  > wrote:
> Send ARIN-PPML mailing list submissions to
> arin-ppml@arin.net 
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.arin.net/mailman/listinfo/arin-ppml 
> 
> or, via email, send a message with subject or body 'help' to
> arin-ppml-requ...@arin.net 
> 
> You can reach the person managing the list at
> arin-ppml-ow...@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. Revised - Draft Policy ARIN-2019-1: Clarify Section 4 IPv4
>   Request Requirements (ARIN)
> 
> 
> --
> 
> Message: 1
> Date: Tue, 16 Apr 2019 14:26:07 -0400
> From: ARIN mailto:i...@arin.net>>
> To: arin-ppml@arin.net 
> Subject: [arin-ppml] Revised - Draft Policy ARIN-2019-1: Clarify
> Section 4 IPv4 Request Requirements
> Message-ID: <6a411169-0e13-2087-d6f2-5176a56bf...@arin.net 
> >
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> The following has been revised:
> 
> * Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements
> 
> Revised text is below and can be found at:
> https://www.arin.net/participate/policy/drafts/2019_1/ 
> 
> 
> You are encouraged to discuss all Draft Policies on PPML. The AC will 
> evaluate the discussion in order to assess the conformance of this draft 
> policy with ARIN's Principles of Internet number resource policy as 
> stated in the Policy Development Process (PDP). Specifically, these 
> principles are:
> 
> * Enabling Fair and Impartial Number Resource Administration
> * Technically Sound
> * Supported by the Community
> 
> The PDP can be found at:
> https://www.arin.net/participate/policy/pdp/ 
> 
> 
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/participate/policy/drafts/ 
> 
> 
> Regards,
> 
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
> 
> 
> 
> Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements
> 
> Problem Statement:
> 
> Per a recent ARIN Policy Experience Report and resulting AC discussion, 
> it was noted that the language of Section 4.1.8 is imprecise in that it 
> can be interpreted as specifying a waiting period for any allocation 
> activity, as opposed to being intended to limit only the frequency of 
> IPv4 allocations under Section 4.
> 
> The same Policy Experience Report also noted that ARIN staff has 
> observed a pattern where an organization transfers space under NRPM 
> Section 8.2 to a specified recipient, and then immediately applies for 
> space under Section 4. This activity appears to be speculative in nature 
> and not consistent with sound address management policy.
> 
> The updated language in this proposal addresses the two issues above, as 
> both concerns can be addressed via modifications to the same section and 
> sentence thereof of the NRPM:
> 
> * Clarifies the waiting period to only prohibit requests for IPv4 
> allocations under Section 4 of the NRPM
> 
> * Disallows organizations that have transferred space to other parties 
> within the past 36 months from applying for additional IPv4 space under 
> NRPM Section 4.
> 
> Policy Statement:
> 
> Current language found in NRPM Section 4.1.8 - Unmet Requests:
> 
> Repeated requests, in a manner that would circumvent 4.1.6, are not 
> allowed: an organization may only receive one allocation, assignment, or 
> transfer every 3 months, but ARIN, at its sole discretion, may waive 
> this requirement if the requester can document a change in circumstances 
> since their last request that could not have been reasonably foreseen at 
> the time of the original request, and which now justifies additional space.
> 
> Proposed new language:
> 
> Repeated requests, in a manner that would circumvent 4.1.6 are not 
> allowed: an organization may not apply for IPv4 address resources under 
> this section if they have received an allocation, assignment, or 
> transfer of IPv4 resources less than three months prior, or if the 
> organization has transferred space to another party under Section 8 less 
> than 36 months prior. ARIN, at its sole discretion, may waive this 
> restriction if the 

Re: [arin-ppml] Looking for final show of support on revised Advisory Council Recommendation Regarding NRPM 4.1.8. Unmet Requests

[Brian Jones]

 I support this policy revision as written and feel it should move forward
while further discussion takes place for hashing out more details.
—
Brian Jones, CSP, CSM, CSPO
NIS Virginia Tech
bjo...@vt.edu


On Thu, Jun 6, 2019 at 5:13 PM Nick Bogle  wrote:

> I support these changes as written.
>
> On Thu, Jun 6, 2019, 10:21 AM John Curran  wrote:
>
>> Folks -
>>
>> We’ve had excellent discussion of various options for the revised
>> “Advisory Council Recommendation Regarding NRPM 4.1.8. Unmet Requests"
>>  proposed policy change – some of which is likely to have to further
>> informed folks initial views on the matter (as well as on future policy
>> proposals in this area), but at this time it is fairly important that we
>> receive focused feedback on the revised policy text as written, with due
>> consideration to the discussion that has occurred online.
>>
>> To that end, at this time it would be good to know from everyone:
>>
>> 1.  Are you in favor of ARIN making the policy change specified in the
>> revised  "Advisory Council Recommendation Regarding NRPM 4.1.8. Unmet
>> Requests”  ?
>>
>> (“Yes” obviously indicative that you’d like ARIN to proceed with its
>> adoption and resumption of wait list issuance under its revised guidelines,
>> and
>>  “No” being indicative that you’d rather have the suspension of wait list
>> issuance continue unless/until some other policy change in this area
>> reaches consensus.)
>>
>> 2.  If you are not supportive of ARIN making the change specified in the
>> revised "Advisory Council Recommendation Regarding NRPM 4.1.8. Unmet
>> Requests”,
>> is there any modification to the proposed policy change that would enable
>> you to support it?
>>
>> I would ask that PPML participants take a moment to consider the proposed
>> policy change as written and please reply regarding the questions above.
>>
>> Thanks!
>> /John
>>
>> John Curran
>> President and CEO
>> American Registry for Internet Numbers
>>
>>
>> Begin forwarded message:
>>
>> *From: *ARIN 
>> *Subject: **[arin-ppml] Revised - Advisory Council Recommendation
>> Regarding NRPM 4.1.8. Unmet Requests*
>> *Date: *24 May 2019 at 1:04:58 PM EDT
>> *To: *
>>
>> At their 16 May meeting, the Advisory Council revised their
>> recommendation regarding NRPM 4.1.8. Unmet Requests.
>>
>> The revised recommendation is hereby submitted to the Public Policy
>> Mailing List for a second community discussion period of 14 days, to
>> conclude on 7 June.
>>
>> Once completed, the Board of Trustees will review the AC’s recommendation
>> and the PPML discussion.
>>
>> The full text of the Advisory Council's revised recommendation is below.
>>
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>>
>>
>>
>> Advisory Council recommendation:
>>
>> This is an updated version which incorporates feedback from the ARIN
>> staff and was approved for further community consultation at the ARIN AC
>> meeting on May 16, 2019.
>>
>> In accordance with section 10.2 of the ARIN Policy Development Process,
>> the ARIN Advisory Council recommends the following actions to the Board of
>> Trustees in response to the Board’s suspension of part of the operation of
>> sections 4.1.8, 4.1.8.1 and 4.1.8.2 of the Numbering Resource Policy Manual:
>>
>> Replace section 4.1.8 et. seq. as follows, then reinstate the full
>> operation of sections 4.1.8, 4.1.8.1 and 4.1.8.2 immediately.
>>
>> 4.1.8 ARIN Waitlist
>>
>> ARIN will only issue future IPv4 assignments/allocations (excluding 4.4
>> and 4.10 space) from the ARIN Waitlist. The maximum size aggregate that an
>> organization may qualify for at any one time is a /22. Organizations will
>> be able to elect a smaller block size than they qualify for down to a /24.
>> Only organizations holding a /20 or less of IPv4 address space may apply
>> and be approved. Address space distributed from the waitlist will not be
>> eligible for transfer for a period of 60 months. This policy will be
>> applied to all future distributions from the waitlist to include those
>> currently listed.
>>
>> Repeated requests, in a manner that would circumvent 4.1.6, are not
>> allowed: an organization currently on the waitlist must wait 90 days after
>> receiving a distribution from the waitlist before applying for additional
>> space. ARIN, at its sole discretion, may waive this requirement if the
>&

Re: [arin-ppml] ARIN-2019-7: Elimination of the Waiting List (was:Re: Looking for final show of support on revised Advisory Council Recommendation Regarding NRPM 4.1.8. Unmet Requests

[Brian Jones]

I oppose this draft policy.
—
Brian Jones, CSP, CSM, CSPO
NIS Virginia Tech
bjo...@vt.edu


On Thu, Jun 20, 2019 at 12:27 PM Alyssa Moore  wrote:

> Hi folks,
>
> Trying to do a temperature check here. If you're following this thread,
> please indicate whether you support or oppose this draft policy.
>
> On Mon, Jun 17, 2019 at 11:42 AM David Farmer  wrote:
>
>>
>>
>> On Sun, Jun 16, 2019 at 2:50 PM Mueller, Milton L 
>> wrote:
>>
>>> OK, I’ve read it, and here is my reaction:
>>>
>>>
>>>
>>> This policy requires legal comment. ARIN’s Articles and Bylaws do not
>>> specifically prohibit ARIN from monetizing returned or revoked resources by
>>> selling those resources into the transfer market
>>>
>>>
>>>
>>> So point #1 is that this proposed policy does not violate any articles
>>> or bylaws.
>>>
>>>
>>>
>>> Today, ARIN does not financially benefit in any material way from such
>>> revocations. Adoption of this policy would for the first time allow the
>>> party in a contested revocation situation to argue that ARIN seeks to
>>> financially benefit. Avoiding that concern is also significant.
>>>
>>>
>>>
>>> I am totally unimpressed with this argument. If ARIN revokes addresses
>>> for nonpayment it is financially benefiting from the revocation is it not?
>>> It is basically taking them back because it is not getting paid.
>>>
>>>
>>>
>>> If ARIN “gets paid” by selling the numbers into the transfer market what
>>> is the difference exactly?
>>>
>>
>> Referring to the waiting list policy, the Draft Policy says, "this policy
>> provides valuable number resources essentially for free".
>>
>> Yes, ARIN currently financially benefits, but currently, that benefit is
>> at a level of cost recovery, "essentially for free" as stated above.
>> Whereas, if ARIN were to dispose of resources using the market, the level
>> of financial benefit is likely to be orders of magnitude larger.
>> Furthermore, if this wasn't the case, then the impact on the market and the
>> potential for fraud supposedly created by the waiting list, that the draft
>> policy proposes to mitigate, wouldn't exist in the first place.
>>
>> In short, "what is the difference", probably, several orders of magnitude
>> in the level of financial benefit involved. Where the financial motivations
>> from simple "cost recovery" can probably be summarily dismissed by the
>> court. Whereas the potential financial motivations, that one might even
>> call a windfall, from market-based transactions probably at least needs to
>> be examined and evaluated by the court, and probably wouldn't be summarily
>> dismissed. The outcome of the two situations might be the same in the end,
>> but the level of effort involved defending and the level of risk of an
>> adverse ruling, are not the same at all.
>>
>> More generally, ARIN participating in the market seems distasteful and
>> counter to its overall mission, but doesn't directly violate its Articles
>> and Bylaws.
>>
>> That said that doesn't mean ARIN can't implement the policy, but these
>> risks need to be evaluated when compared to other alternatives being
>> considered, along with the possible benefits this policy could have as well.
>>
>> --
>> ===
>> David Farmer   Email:far...@umn.edu
>> Networking & Telecommunication Services
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SEPhone: 612-626-0815
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>> ===
>> ___
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@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@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Of interest?

[Brian Jones]

Thank you for sharing this Mike.

Great Job ARIN! I hope this sets a precedence to help deter future fraudulent 
behavior and hope those addresses go to the folks on the waiting list to, at 
least for those who are trying to move toward using IPv6.

--
Brian E Jones, CSP-SM, CSP-PO
NI Virginia Tech
bjo...@vt.edu

> On May 14, 2019, at 11:10 AM, Mike Burns  wrote:
> 
> I found this to be an interesting article and perhaps others on the list 
> would appreciate knowing about it.
>  
> https://www.news-journal.com/ap/national/arin-wins-important-legal-case-and-precedent-against-fraud/article_ceb57140-e574-5355-a8b3-c8f8c70a439e.html
>  
> 
>  
> Regards,
> Mike Burns
>  
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net 
> ).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml 
> 
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2019-15: Hijacking Authorization Not-intended

[Brian Jones]

I have questions about what is considered in violation with the proposed
wording. See inline comments.
—
Brian Jones
Virginia Tech


On Tue, Jun 25, 2019 at 7:17 PM John Santos  wrote:

> On 6/25/2019 05:18 PM, ARIN wrote:
> > On 20 June 2019, the ARIN Advisory Council (AC) accepted "ARIN-prop-275:
> [...]
> >
> > When prop-254 (Clarification on IPv6 Sub-assignments), it was not
> > related, neither intended, to modify the “exclusivity” criterion.
> [...]
>
> Huh?  This sounds totally garbled to me.
>

+1

>
> > Note that the incidental or transient use of address space by third
> > parties, within the network of the recipient organization, shall not be
> > considered a reassignment or a violation of the exclusive use criterion
> >
>
> Maybe "use of address space by AUTHORIZED third parties" (meaning
> authorized by the recipient)?
>
> I like the "AUTHORIZED third parties" ^^ wording.


I have an example that makes me question what would be in violation with
the proposed wording. Say a bunch of VT students begin a start up company
in the VT corporate research center and come to us (VT IT) for IPv6 address
space. They are technically not part of VT but are still connected to VT.
If we provide addresses to them, according to the proposed wording, it
seems we would be in violation.? Therefore I would rather have some wording
that is more accommodating to this type of situation.



> --
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2017-12: POC Notification and Validation Upon Reassignment or Reallocation

[Brian Jones]

I support this policy and as indicated from remotely at ARIN 43 anything to 
help keep the assignment contacts up to date and accurate is a good thing.

--
Brian 
Virginia Tech
bjo...@vt.edu

> On Apr 15, 2019, at 2:04 PM, ARIN  wrote:
> 
> The ARIN Advisory Council (AC) met on 10 April 2019 and decided to send the 
> following Recommended Draft Policy to Last Call:
> 
> ARIN-2017-12: POC Notification and Validation Upon Reassignment or 
> Reallocation
> 
> Feedback is encouraged during the Last Call period. All comments should be 
> provided to the Public Policy Mailing List. Last Call will expire on 29 April 
> 2019.
> 
> The Recommended Draft Policy text is below and available at:
> https://www.arin.net/participate/policy/drafts/
> 
> The ARIN Policy Development Process is available at:
> https://www.arin.net/participate/policy/pdp/
> 
> Regards,
> 
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
> 
> 
> 
> Recommended Draft Policy ARIN-2017-12: POC Notification and Validation Upon 
> Reassignment or Reallocation
> 
> AC Assessment of Conformance with the Principles of Internet Number Resource 
> Policy:
> 
> This recommended draft policy: (1) enables fair and impartial number 
> administration as it ensures that ARIN has the means to communicate with 
> organizations receiving reallocations or detailed reassignments, and does so 
> in a clear, complete, concise and unambiguous manner; (2) is technically 
> sound in that it supports ARIN’s ability to maintain the unique registration 
> of Internet number resources; and (3) has community support.
> 
> Problem Statement:
> 
> Some ISPs assign individuals to be POCs for reassigned blocks without 
> consultation of the individual they are inserting into Whois. For example, 
> during the reassignment/reallocation process, some large ISPs automatically 
> create POCs from their customer’s order form. This process is automated for 
> many ISPs and therefore the resulting POCs are not validated prior to being 
> created in the ARIN Whois database. This creates unknowing POCs that have no 
> idea what Whois is or even who ARIN is at the time they receive the annual 
> POC validation email. It can also create multiple POCs per email address 
> causing that same person to receive a multitude of POC Validation emails each 
> year.
> 
> This policy proposal seeks to prevent the situation where a POC is 
> unwittingly and unintentionally inserted into Whois. Doing so will reduce the 
> significant amount of time that ARIN staff spend fielding phone calls from 
> POCs who have no idea they are in Whois.
> 
> The proposal will improve the overall POC validation situation, by ensuring 
> that all reallocation or detailed reassignment requests are related to a 
> pre-existing receiving organization with at least one valid POC object, and 
> by requesting that any other existing invalid POC objects are validated.
> 
> Policy statement:
> 
> Insert one new section into NRPM 3:
> 
> 3.7 POC Notification and Validation Upon Reassignment or Reallocation
> 
> When a request for reallocation or detailed reassignment is made to ARIN, the 
> receiving organization must already be in the ARIN database and associated 
> with at least one validated POC object. If there are no validated POC objects 
> associated with the receiving organization, ARIN shall reject the request.
> 
> In addition to notifying the requester, ARIN will also notify, via email, all 
> POCs associated with the receiving organization, whether the request was 
> successful or not, and will request validation of any invalid POC objects 
> associated with the receiving organization.
> 
> Note: Simple reassignments are made without any linkage to an organization or 
> POC objects in the ARIN database.
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2019-17: Returned Addresses to the 4.10 Reserved Pool

[Brian Jones]

I oppose this policy as written, mainly for the reasons Owen outlines. This
would eliminate the wait list and possibly lock up useful resources now
that may not be as relevant or useful in the future. It does also seem
contrary to ARIN's mission in my view.

—
Brian Jones, CSP, CSM, CSPO
NIS Virginia Tech
bjo...@vt.edu


On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong  wrote:

> Really, it seems to me that this proposal is another attempt at
> eliminating the waiting list for unmet requests.
>
> The first attempt (ARIN auctions the space) met with resistance from
> ARIN’s legal team (for good reason), so now this attempts to sequester the
> space where it will be hard to distribute rather than allowing the waiting
> list to have any potential to compete with the transfer market.
>
> The proposed targets (4.4 and 4.10 pools) are well stocked and unlikely to
> run out in any useful IPv4 lifetime.
>
> As such, restocking them from returned space strikes me as just a way to
> sequester this space where it cannot be used.
>
> IMHO, this is counter to ARIN’s mission and should not be allowed.
>
> I oppose the policy as written and as proposed to be amended.
>
> Owen
>
>
> On Aug 15, 2019, at 13:55 , WOOD Alison * DAS via ARIN-PPML <
> arin-ppml@arin.net> wrote:
>
> Thank you for the continued input on this draft policy proposal.
>
> I will be updating the text of the draft policy to include both 4.4 and
> 4.10 pools.  Point of information, the 4.4 pool currently has approximately
> 391 /24’s and 4.10 has approximately 15,753 /24’s available and are not
> estimated to run out in the next five years.
>
> Please keep your feedback coming, it is very helpful for the council.
>
> -Alison
>
> *From:* ARIN-PPML [mailto:arin-ppml-boun...@arin.net
> ] *On Behalf Of *Fernando Frediani
> *Sent:* Tuesday, July 30, 2019 6:44 AM
> *To:* arin-ppml 
> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2019-17: Returned Addresses
> to the 4.10 Reserved Pool
>
>
> The point is that you treating IP marketing as something 'natural' or a
> 'default route' which it is not and can never be. Natural is to receive
> some addresses from the RIR in first place so they are treated as anyone
> else was in the past and have a chance to exist in the Internet with same
> conditions as all others. From that if they need extra space then fine to
> seek for alternative ways.
>
> I don't think a new entrants would automatically qualify for 4.10 in all
> cases therefore any space left should be targeted also to them as well to
> IPv6 transition and critical infrastructure. Otherwise the community will
> be creating an artificial barrier to them in order to favor the IP market
> while the RIR still has IPv4 space available for them.
>
> Fernando
> On 30/07/2019 10:30, Tom Fantacone wrote:
>
> I would think that the majority of new entrants would need at least some
> allocation to help with IPv6 transition and would qualify for addresses
> from the 4.10 pool.  Depending on what they receive from that pool and
> when, they may not qualify for additional waiting list addresses and would
> have to go to the transfer market for additional IPv4 space anyway.  Those
> that don't qualify under 4.10 can still get smaller IPv4 blocks on the
> transfer market readily, and the cost for blocks in the /24-/22 range is
> not prohibitive.  Certainly an organization seeking a small IPv4 block for
> multi-homing or other purposes is better off spending a few thousand
> dollars to purchase a range than waiting a year on the waiting list to put
> their plans in motion.
>
>
> Note that while RIPE does not have a reserve pool specifically for IPv6
> transition, the expectation of their final /8 policy was to allow new
> entrants access to IPv4 to assist in this transition.  In reality, it
> didn't work out that way and most of the /22 allocations to new LIRs from
> the final /8 were to existing organizations who spun up new, related
> entities in order to increase their IPv4 holdings:
>
>
> https://labs.ripe.net/Members/wilhelm/so-long-last-8-and-thanks-for-all-the-allocations
>
> I'm also sympathetic to new entrants, but don't see the current waiting
> list as a great help to them vs. the 4.10 pool or the transfer market, both
> of which allow you your allocation in a timely fashion.
>
> Best Regards,
>
> Tom Fantacone
>
>  On Mon, 29 Jul 2019 11:39:32 -0400 *Fernando Frediani
> >* wrote 
>
>
> I find it interesting the idea of privileging the pool dedicated to
> facilitate IPv6 Deployment and I also agree with the comments below in
> the sense that it's not very beneficial do most ARIN members due to max
> size, /22, cannot be holding more than a /20.
>
> Howev

Re: [arin-ppml] Revised - Draft Policy ARIN-2019-9: Clarify Interactions Between NRPM 4.10 IPv6 Transition Space Requests and NRPM 4.1.8.2 Unmet Needs Requests

[Brian Jones]

With the clarification that organizations will be removed from the waiting list 
if they receive an allocation for facilitating their IPv6 deployment, I no 
longer support this proposal for the reasons outlined by the ARIN staff below. 
My organization will not be impacted by this but I can understand where some 
could be detrimentally effected by this change. Receiving an allocation for 
deploying IPv6 should not be tied to the waiting list for a regular IPv4 
assignment IMO.

--
Brian E Jones, CSP-SM, CSP-PO
NI Virginia Tech
bjo...@vt.edu

> On Jul 30, 2019, at 1:33 PM, Kat Hunter  wrote:
> 
> All- Staff and legal review has been completed for 2019-9. Please take a 
> moment to review the comments. For those that supported this, do you still 
> support the policy given the staff notes. Additionally, we'd like to hear 
> from anyone that this may impact in a negative way. 
> 
> Policy: https://www.arin.net/participate/policy/drafts/2019_9/ 
> <https://www.arin.net/participate/policy/drafts/2019_9/>
> Staff and Legal Review 
> https://www.arin.net/participate/policy/drafts/2019_9/#slr 
> <https://www.arin.net/participate/policy/drafts/2019_9/#slr> 
> 
> "ARIN Staff Comments
> 
> This policy could be implemented as written. Current policy is that any 
> organization on the waiting list that receives IPv4 addresses through a 
> transfer are removed from the waiting list, but those receiving an NRPM 4.10 
> (Dedicated IPv4 Block to Facilitate IPv6 Deployment) assignment are not 
> removed from the waiting list. The proposed change would result those 
> organizations receiving an NRPM 4.10 assignment also being removed from the 
> waiting list.
> 
> Staff notes that adding the “…or an allocation request fulfilled under 
> Section 4.10…” may be detrimental to some organizations, as address space 
> received per NRPM 4.10 must be used in a manner consistent with IPv6 
> translation services and cannot be used for other purposes such as customer 
> assignments, shared hosting services, etc.
> 
> Organizations need IPv4 address space to assign to their customers, and many 
> organizations will request a block from the Waiting List to be used for their 
> customer assignments but still need some IPv4 space for deployment of IPv6 
> translation services as outlined in section NRPM 4.10. Removing organizations 
> from the Waiting List when they receive a NRPM 4.10 assignment would hinder 
> the existing IPv4 operations & growth of organizations, and may provide a 
> disincentive to IPv6 deployment."
> 
> 
> 
> -Kat Hunter 
> 
> 
> On Mon, Jul 15, 2019 at 1:42 PM Brian Jones  <mailto:bjo...@vt.edu>> wrote:
> I support this revised version of draft policy ARIN-2019-9 as written. 
> 
> Brian 
> 
> 
> On Thu, May 23, 2019, 12:44 PM ARIN mailto:i...@arin.net>> 
> wrote:
> The following has been revised:
> 
> * Draft Policy ARIN-2019-9: Clarify Interactions Between NRPM 4.10 IPv6 
> Transition Space Requests and NRPM 4.1.8.2 Unmet Needs Requests
> 
> Revised text is below and can be found at:
> https://www.arin.net/participate/policy/drafts/2019_9/ 
> <https://www.arin.net/participate/policy/drafts/2019_9/>
> 
> You are encouraged to discuss all Draft Policies on PPML. The AC will 
> evaluate the discussion in order to assess the conformance of this Draft 
> Policy with ARIN's Principles of Internet number resource policy as 
> stated in the Policy Development Process (PDP). Specifically, these 
> principles are:
> 
> * Enabling Fair and Impartial Number Resource Administration
> * Technically Sound
> * Supported by the Community
> 
> The PDP can be found at:
> https://www.arin.net/participate/policy/pdp/ 
> <https://www.arin.net/participate/policy/pdp/>
> 
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/participate/policy/drafts/ 
> <https://www.arin.net/participate/policy/drafts/>
> 
> Regards,
> 
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
> 
> 
> 
> Draft Policy ARIN-2019-9: Clarify Interactions Between NRPM 4.10 IPv6 
> Transition Space Requests and NRPM 4.1.8.2 Unmet Needs Requests
> 
> Problem Statement:
> 
> It has been observed that an organization requesting IPv4 resources 
> under NRPM Section 4.10, Dedicated IPv4 Block To Facilitate IPv6 
> Deployment, can also request similar or the same resources under Section 
> 4.2.1.8, Unmet Needs. This proposal aims to remove this potential for 
> duplicate requests under these sections.
> 
> Policy Statement:
> 
> Section 4.1.8.2, Unmet Needs:
> 
> Current language: Any requests met through a transfer will be considered 
> fulfilled 

Re: [arin-ppml] Revised - Draft Policy ARIN-2019-15: Hijacking Authorization Not-intended

[Brian Jones]

I am in support of the new proposed text for ARIN-2019-15. This should make
things clearer concerning the intentions of the policy and the use of the
address space.

—
Brian Jones, CSP, CSM, CSPO
NIS Virginia Tech
bjo...@vt.edu


On Mon, Jul 22, 2019 at 10:54 AM ARIN  wrote:

> The following has been revised:
>
> * Draft Policy ARIN-2019-15: Hijacking Authorization Not-intended
>
> Revised text is below and can be found at:
> https://www.arin.net/participate/policy/drafts/2019_15/
>
> You are encouraged to discuss all Draft Policies on PPML. The AC will
> evaluate the discussion in order to assess the conformance of this draft
> policy with ARIN's Principles of Internet number resource policy as
> stated in the Policy Development Process (PDP). Specifically, these
> principles are:
>
> * Enabling Fair and Impartial Number Resource Administration
> * Technically Sound
> * Supported by the Community
>
> The PDP can be found at:
> https://www.arin.net/participate/policy/pdp/
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/participate/policy/drafts/
>
> Regards,
>
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
>
>
>
> Draft Policy ARIN-2019-15: Hijacking Authorization Not-intended
>
> Problem Statement:
>
> The current text of Section 2.5 of the NRPM could be interpreted as
> implicitly giving incidental or transient users of IPv6 address space
> the ability to use that space without the authorization of the
> organization to which the space is delegated. This policy makes it clear
> that such third-party use must be authorized by the organization to
> which the address space is delegated.
>
> Policy Statement:
>
> Present Text
>
> Note that the incidental or transient use of address space by third
> parties shall not be considered a reassignment or a violation of the
> exclusive use criterion.
>
> Proposed Text
>
> Note that the authorized incidental or transient use by third parties of
> address space delegated to an organization shall not be considered a
> reassignment or a violation of the exclusive use provision.
>
> Comments: N/A
>
> Timetable for implementation: Immediate
>
> Anything Else: The proposed text is consistent the intent expressed by
> similar polices of other RIRs.
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2019-10: Inter-RIR M - Seeking Community Comments

[Brian Jones]

I am opposed to this draft policy as written. I believe the entity should
request resources from the new RIR, especially IPv6 resources, in order to
help keep accurate records. I would not be opposed to the transfer of IPv4
space should the destination RIR not be able to meet the needed
requirements.

—
Brian Jones, CSP, CSM, CSPO
NIS Virginia Tech
bjo...@vt.edu


On Mon, Jul 15, 2019 at 2:21 PM Kerrie Vassall-Richards <
kerriearicha...@gmail.com> wrote:

> Good day everyone,
>
> I am seeking community input on *Draft Policy ARIN-2019-10: Inter-RIR M 
> *since the last post on this policy on May 21, 2019 there has not been any 
> conversation around it. As primary shepherd I need to have a good sense of 
> the direction that the community wants to take in regards to this policy. As 
> a starting point I would like to hear from the community if it is thoght the 
> policy is:
>
> * Enabling Fair and Impartial Number Resource Administration
> * Technically Sound
> * Supported by the Community
>
>
>1. Draft Policy ARIN-2019-10 is below and can be found at: 
> https://www.arin.net/participate/policy/drafts/2019_10/
>2. NRPM Version 2019.2 - 10 July 2019 can be found here: 
> https://www.arin.net/participate/policy/nrpm/
>3. The Specific section of the NRPM affected by this policy can be found 
> here: 
> https://www.arin.net/participate/policy/nrpm/#8-2-mergers-acquisitions-and-reorganizations
>
> As a reminder please see the problem and the policy statements
> Problem Statement:
>
> Merger, acquisition, or reorganization activity sometimes results in a
> restructuring where company resources, the management of number
> resources, or the use of number resources are concentrated outside the
> ARIN service region. In this case it may be desirable for the current
> legal entity or a legal entity that is a parent, child or sister to move
> the servicing of the number resources to a different RIR.
>
> Policy Statement:
> *Add to section 8.2:*
>
> When merger, acquisition, or reorganization activity results in
> surviving legal entity that is incorporated outside the ARIN service
> region, or focused outside the ARIN service region, or is merging with
> an organization that already has a relationship with another RIR, then
> resources may be moved to another RIR in accordance with the receiving
> RIR’s policies.
>
> I look forward to hearing more from everyone on this policy.
>
> Warm regards
>
> Kerrie
>
>
>
>
>
>
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2019-12: M Legal Jurisdiction Exclusion

[Brian Jones]

+1 Scott's comments.

Support

—
Virginia Tech
bjo...@vt.edu


On Mon, Jul 15, 2019 at 5:23 PM Scott Leibrand 
wrote:

> Allowing entities outside the ARIN region to continue holding addresses
> originally assigned to an ARIN-region organization to which the
> non-ARIN-region entity is a legal successor seems reasonable to me, and
> less fraught than allowing IPv6 and IPv4 waitlist space to be M
> transferred to another RIR.
>
> Support.
>
> Scott
>
> > On Jul 15, 2019, at 1:32 PM, Joe Provo  wrote:
> >
> >
> > 
> > Hey folks,
> >
> > Like several other proposals, we seem to have been
> > hit by the summer slump considering the following.
> >
> > There was a single posted objection, and it isn't
> > clear if lack of activity stems from
> > - uninterest
> > - interest in seeing 2019-13 move instead
> > - interest in seeing 2019-4 move instead
> > - something else
> >
> > Thanks in advance for more input!
> >
> > Joe
> > 
> >
> >> On Tue, May 21, 2019 at 02:02:14PM -0400, ARIN wrote:
> >> On 16 May 2019, the ARIN Advisory Council (AC) accepted "ARIN-prop-272:
> >> M Legal Jurisdiction Exclusion" as a Draft Policy.
> >>
> >> Draft Policy ARIN-2019-12 is below and can be found at:
> >> https://www.arin.net/participate/policy/drafts/2019_12/
> > [snip]
> >> Draft Policy ARIN-2019-12: M Legal Jurisdiction Exclusion
> >>
> >> Problem Statement:
> >>
> >> M activity sometimes results in a surviving legal entity that is not
> >> in ARIN service region, but may prefer to continue the pre-existing
> >> relationship with ARIN.
> >>
> >> Example: Imagine a case where a global company has decided to
> >> discontinue service in the ARIN service region (shuttering ARIN region
> >> offices laying off ARIN region employees, and canceling ARIN region
> >> customers) and repurpose the network resources and number resources in
> >> the rest of its global footprint. During restructuring the company
> >> concentrates its holdings in its European subsidiary, and then
> dissolved
> >> its US legal entity.
> >>
> >> Imagine a case where a global company has decided to divest its service
> >> in the ARIN region (selling all ARIN region offices, all ARIN region
> >> network assets, all ARIN service region customers, all number resources
> >> used in the ARIN (associated with previous noted sale of network and
> >> customers), but retaining ARIN issued resources in use outside of the
> >> ARIN service region. During restructuring the company concentrates its
> >> holdings which are not in us in the ARIN service region in its European
> >> subsidiary, and then sells off its US legal entity (including the
> >> network, customers, addresses in use, etc) dissolved its US legal
> entity.
> >>
> >> Policy Statement:
> >>
> >> Add the following to section 8.2
> >>
> >> M activity resulting in the surviving legal entity which is not
> >> incorporated in the ARIN service region will be permitted to hold
> number
> >> resources directly allocated or assigned by ARIN.
> >>
> >> Comments:
> >>
> >> Timetable for implementation: Immediate
> >>
> >> Anything Else This proposal may be overtaken by a more general approach
> >> to ARIN membership legal jurisdiction exclusion
> >
> >
> >
> > --
> > Posted from my personal account - see X-Disclaimer header.
> > Joe Provo / Gweep / Earthling
> > ___
> > ARIN-PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact i...@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@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised - Draft Policy ARIN-2019-9: Clarify Interactions Between NRPM 4.10 IPv6 Transition Space Requests and NRPM 4.1.8.2 Unmet Needs Requests

[Brian Jones]

I support this revised version of draft policy ARIN-2019-9 as written.

Brian


On Thu, May 23, 2019, 12:44 PM ARIN  wrote:

> The following has been revised:
>
> * Draft Policy ARIN-2019-9: Clarify Interactions Between NRPM 4.10 IPv6
> Transition Space Requests and NRPM 4.1.8.2 Unmet Needs Requests
>
> Revised text is below and can be found at:
> https://www.arin.net/participate/policy/drafts/2019_9/
>
> You are encouraged to discuss all Draft Policies on PPML. The AC will
> evaluate the discussion in order to assess the conformance of this Draft
> Policy with ARIN's Principles of Internet number resource policy as
> stated in the Policy Development Process (PDP). Specifically, these
> principles are:
>
> * Enabling Fair and Impartial Number Resource Administration
> * Technically Sound
> * Supported by the Community
>
> The PDP can be found at:
> https://www.arin.net/participate/policy/pdp/
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/participate/policy/drafts/
>
> Regards,
>
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
>
>
>
> Draft Policy ARIN-2019-9: Clarify Interactions Between NRPM 4.10 IPv6
> Transition Space Requests and NRPM 4.1.8.2 Unmet Needs Requests
>
> Problem Statement:
>
> It has been observed that an organization requesting IPv4 resources
> under NRPM Section 4.10, Dedicated IPv4 Block To Facilitate IPv6
> Deployment, can also request similar or the same resources under Section
> 4.2.1.8, Unmet Needs. This proposal aims to remove this potential for
> duplicate requests under these sections.
>
> Policy Statement:
>
> Section 4.1.8.2, Unmet Needs:
>
> Current language: Any requests met through a transfer will be considered
> fulfilled and removed from the waiting list.
>
> Proposed language:
>
> Any requests met through a transfer or an allocation request fulfilled
> under Section 4.10 will be considered fulfilled and removed from the
> waiting list.
>
> Timetable for Implementation: Immediate
>
> Anything Else:
>
> Currently, organizations can receive no more than a /24 at a time under
> Section 4.10. However, Proposal ARIN-PROP-266, submitted by Chris Tacit
> and myself, could potentially allow an org to receive up to a /21 under
> that section, widening the potential for abuse by “double-dipping”
> waiting list and transition space requests. As such, this proposal
> should be considered in that context.
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2019-18: LIR/ISP Re-Assignment to Non-Connected Networks

[Brian Jones]

See inline.
—
Brian Jones
NIS Virginia Tech


On Tue, Oct 1, 2019 at 12:41 PM Jim  wrote:

> On Fri, Sep 27, 2019 at 6:00 PM John Santos  wrote:
>
> I am opposed to proposal that ARIN should in general be facilitating
> entities
> being able to obtain from ARIN   permanent allocations made to
> support  temporary use for non-connected networks.It sounds like
> creating an inviting environment for potential spammers and fraud, and
> LIRs/ISPs should not be involved in this.
>

+1 The above. I am all for the wait list for those who "need" resources and
may not be able to afford them on the transfer market. I also have evidence
of address resources allocated out of other RIR's (non-ARIN) being used for
nefarious purposes here in the states. The entities they are registered to
seem to pay little attention to any abuse complaints, so sometime entire
blocks of addresses get black listed, blocked, or otherwise ACL'led from
most legitimate network providers. The transfer market opens up a lane for
this activity.



>
> I would suggest a stance that IPv6 should be used for any new non-
> connected networks being created And applicants be required to prove
> that they have adequate justification for why they have existing IPv4 usage
> and it is not possible to meet their unique  Non-Connected networking
> needs using IPv6 space  and  technology such as 464XLAT, and why
> it is also impractical to meet their requirement using RFC1918 space.
>
> If someone's use is so transient as to merit leasing,  then perhaps ARIN
> could consider offering a process for providing a  90-day allocation
> from a block reserved for transient allocations for experimental use
>

Not a bad idea...



> > Someone needs to define "Non-Connected Network".  I take it to mean "a
> > network that is not connected to the Global Internet."  I.E. a private
>
> Yes...  Non-Connected = A standalone IP network, or it might be part of
> a confederation of  interconnected networks,   but they choose: for
> whatever reason  to not be globally reachable directly over the IP
> protocol.
>
> If the Non-connected network is truly standalone,  then RFC1918 space
> should be adequate.
>
+1. If it is truly standalone they technically could use "any" IPv4 space
they wanted to... Not recommended, but just saying.



>
>
>
> ---
> -Jimmy
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Recommended Draft Policy ARIN-2019-20: Harmonization of Maximum Allocation Requirements under Sections 4.1.8 (ARIN Waitlist) and 4.2.2 (Initial Allocation to ISPs)

[Brian Jones]

I support this policy as written. It clarifies, unifies, and makes both
sections more accurate.

—
Brian E Jones
NIS Virginia Tech


On Tue, Feb 25, 2020 at 4:54 PM ARIN  wrote:

> On 20 February 2020, the ARIN Advisory Council (AC) advanced the
> following Draft Policy to Recommended Draft Policy status:
>
> ARIN-2019-20: Harmonization of Maximum Allocation Requirements under
> Sections 4.1.8 (ARIN Waitlist) and 4.2.2 (Initial Allocation to ISPs)
>
> The text of the Recommended Draft Policy is below, and may also be found
> at:
>
> https://www.arin.net/participate/policy/drafts/2019_20/
>
> You are encouraged to discuss all Recommended Draft Policies on PPML
> prior to their presentation at the next ARIN Public Policy Consultation
> (PPC). PPML and PPC discussions are invaluable to the AC when
> determining community consensus.
>
> The PDP can be found at:
> https://www.arin.net/participate/policy/pdp/
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/participate/policy/drafts/
>
> Regards,
>
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers
>
>
>
> Recommended Draft Policy ARIN-2019-20: Harmonization of Maximum
> Allocation Requirements under Sections 4.1.8 (ARIN Waitlist) and 4.2.2
> (Initial Allocation to ISPs)
>
> AC Assessment of Conformance with the Principles of Internet Number
> Resource Policy:
>
> Recommended Draft Policy ARIN-2019-20 fixes the initial block size
> discrepancy between NRPM sections 4.2 (ISP allocations) and 4.1.8
> (Wait-list policy). This recommended draft is technically sound,
> supported by the community and enables fair and impartial administration
> of number resources by removing conflicting language within the NRPM.
>
> Problem Statement:
>
> Under the current ARIN waitlist policy (section 4.1.8), ARIN now only
> issues IPv4 assignments/allocations (excluding section 4.4 and 4.10
> space) from the ARIN waitlist. The maximum size aggregate for which an
> organization may qualify at any one time is a /22. On the other hand,
> the current initial allocations to ISPs policy (section 4.2.2) provides
> that direct assignments or allocations from ARIN qualify for an initial
> allocation of up to a /21, subject to ARIN’s minimum allocation size.
> This proposal seeks to resolve the conflict in the maximum allocation
> size requirements between the two sections in favour of the requirement
> in the waitlist policy, since that is the one that is intended to govern
> at the present time. Reconciling the policy language as proposed herein
> will avoid confusion by readers of the NRPM.
>
> Policy Statement:
>
> Change the first sentence of section 4.2.2 to read:
>
> “All ISP organizations without direct assignments or allocations from
> ARIN qualify for an initial allocation of up to a /22, subject to ARIN’s
> minimum allocation size.”
>
> Timetable for Implementation: Immediate
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised - Draft Policy ARIN-2019-12: M Legal Jurisdiction Exclusion

[Brian Jones]

On Wed, Jan 29, 2020 at 11:34 AM Andrew Dul  wrote:

> I would say as a continuing ARIN member they are responsible for keeping
> up their POC and abuse records just like any other member.
>
> Andrew
>

Point being, if those address blocks are ignored long enough, they could be
reclaimed eventually by ARIN for repurposing?
--
Brian


> On 1/28/2020 11:52 AM, Brian Jones wrote:
>
>
> Question: Does this mean that the entity responsible for the continued
> resource holdings is subject to keeping up the POC and abuse contact
> information for each of the locations or allocation blocks where it
> continues to use ARIN resources?
>
> —
> Brian Jones
> NI Virginia Tech
> bjo...@vt.edu
>
>
> On Tue, Jan 28, 2020 at 7:23 AM ARIN  wrote:
>
>> The following has been revised:
>>
>> * Draft Policy ARIN-2019-12: M Legal Jurisdiction Exclusion
>>
>> Revised text is below and can be found at:
>>
>> https://www.arin.net/participate/policy/drafts/2019_12/
>>
>> You are encouraged to discuss all Draft Policies on PPML. The AC will
>> evaluate the discussion in order to assess the conformance of this Draft
>> Policy with ARIN's Principles of Internet number resource policy as
>> stated in the Policy Development Process (PDP). Specifically, these
>> principles are:
>>
>> * Enabling Fair and Impartial Number Resource Administration
>> * Technically Sound
>> * Supported by the Community
>>
>> The PDP can be found at:
>> https://www.arin.net/participate/policy/pdp/
>>
>> Draft Policies and Proposals under discussion can be found at:
>> https://www.arin.net/participate/policy/drafts/
>>
>> Regards,
>>
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>>
>>
>>
>> Draft Policy ARIN-2019-12: M Legal Jurisdiction Exclusion
>>
>> Problem Statement:
>>
>> Merger and acquisition activity sometimes results in a surviving legal
>> entity that is not in ARIN service region, but may prefer to continue
>> the pre-existing relationship with ARIN.
>>
>> Example: Imagine a case where a global company has decided to
>> discontinue service in the ARIN service region (shuttering ARIN region
>> offices laying off ARIN region employees, and canceling ARIN region
>> customers) and repurpose the network resources and number resources in
>> the rest of its global footprint. During restructuring the company
>> concentrates its holdings in its European subsidiary, and then dissolved
>> its US legal entity.
>>
>> Imagine a case where a global company has decided to divest its service
>> in the ARIN region (selling all ARIN region offices, all ARIN region
>> network assets, all ARIN service region customers, all number resources
>> used in the ARIN (associated with previous noted sale of network and
>> customers), but retaining ARIN issued resources in use outside of the
>> ARIN service region. During restructuring the company concentrates its
>> holdings which are not in us in the ARIN service region in its European
>> subsidiary, and then sells off its US legal entity (including the
>> network, customers, addresses in use, etc) dissolved its US legal entity.
>>
>> Policy Statement:
>>
>> Add the following to section 8.2
>>
>> Mergers, acquisitions, and reorganization activity resulting in the
>> surviving entity ceasing to have a real and substantial connection with
>> the ARIN region shall be permitted to continue holding any numbering
>> resources issued (directly or indirectly) by ARIN prior to the merger,
>> acquisition or reorganization activity, but shall not qualify for any
>> additional numbering resources (directly or indirectly) from ARIN,
>> unless and until it once again has a real and substantial connection
>> with the ARIN region as required by the Numbering Resource Policy Manual.
>>
>> Timetable for Implementation: Immediate
>>
>> Anything Else:
>>
>> This proposal may be overtaken by a more general approach to ARIN
>> membership legal jurisdiction exclusion
>>
>> To clarify scope, a legal entity present within the ARIN service region,
>> and a current ARIN RSA executed with that entity, is necessary to
>> receive allocations or assignments from ARIN. Therefore in the scenario
>> postulated in the problem statement, the organization would have to
>> re-establish itself within the ARIN service region to receive additional
>> resources from ARIN, while it can continue to hold the allocations or
>> assignments made prior to any merger, acquisit

Re: [arin-ppml] Revised - Draft Policy ARIN-2019-12: M Legal Jurisdiction Exclusion

[Brian Jones]

Thank you for the clarification Joe. I have no further discussion of this
draft at this time.
—
Brian Jones


On Fri, Feb 7, 2020 at 9:15 AM Joe Provo  wrote:

>
> 
>
> On Wed, Jan 29, 2020 at 01:43:25PM -0500, Brian Jones wrote:
> > On Wed, Jan 29, 2020 at 11:34 AM Andrew Dul 
> wrote:
> >
> > > I would say as a continuing ARIN member they are responsible for
> keeping
> > > up their POC and abuse records just like any other member.
> > >
> > > Andrew
> > >
> >
> > Point being, if those address blocks are ignored long enough, they could
> be
> > reclaimed eventually by ARIN for repurposing?
>
>
> Brian,
>
> Since none of the updates to language affected that, I'm
> with Andrew as the previous S would have specified. Once
> this language settles and we seek the next S we can call
> out the concern to be directly addressed so there's no
> ambiguity.
>
> To that end, it'd be great if we could get any additional
> feedback on the current language in the next week. I'd love
> to iron out any further changes so we can have concensus
> on the text by the next AC meeting
>
> 
>
> Cheers!
>
> Joe
>
>
> > > On 1/28/2020 11:52 AM, Brian Jones wrote:
> > >
> > >
> > > Question: Does this mean that the entity responsible for the continued
> > > resource holdings is subject to keeping up the POC and abuse contact
> > > information for each of the locations or allocation blocks where it
> > > continues to use ARIN resources?
> > >
> > > ???
> > > Brian Jones
> > > NI Virginia Tech
> > > bjo...@vt.edu
> > >
> > >
> > > On Tue, Jan 28, 2020 at 7:23 AM ARIN  wrote:
> > >
> > >> The following has been revised:
> > >>
> > >> * Draft Policy ARIN-2019-12: M Legal Jurisdiction Exclusion
> > >>
> > >> Revised text is below and can be found at:
> > >>
> > >> https://www.arin.net/participate/policy/drafts/2019_12/
> > >>
> > >> You are encouraged to discuss all Draft Policies on PPML. The AC will
> > >> evaluate the discussion in order to assess the conformance of this
> Draft
> > >> Policy with ARIN's Principles of Internet number resource policy as
> > >> stated in the Policy Development Process (PDP). Specifically, these
> > >> principles are:
> > >>
> > >> * Enabling Fair and Impartial Number Resource Administration
> > >> * Technically Sound
> > >> * Supported by the Community
> > >>
> > >> The PDP can be found at:
> > >> https://www.arin.net/participate/policy/pdp/
> > >>
> > >> Draft Policies and Proposals under discussion can be found at:
> > >> https://www.arin.net/participate/policy/drafts/
> > >>
> > >> Regards,
> > >>
> > >> Sean Hopkins
> > >> Policy Analyst
> > >> American Registry for Internet Numbers (ARIN)
> > >>
> > >>
> > >>
> > >> Draft Policy ARIN-2019-12: M Legal Jurisdiction Exclusion
> > >>
> > >> Problem Statement:
> > >>
> > >> Merger and acquisition activity sometimes results in a surviving legal
> > >> entity that is not in ARIN service region, but may prefer to continue
> > >> the pre-existing relationship with ARIN.
> > >>
> > >> Example: Imagine a case where a global company has decided to
> > >> discontinue service in the ARIN service region (shuttering ARIN region
> > >> offices laying off ARIN region employees, and canceling ARIN region
> > >> customers) and repurpose the network resources and number resources in
> > >> the rest of its global footprint. During restructuring the company
> > >> concentrates its holdings in its European subsidiary, and then
> dissolved
> > >> its US legal entity.
> > >>
> > >> Imagine a case where a global company has decided to divest its
> service
> > >> in the ARIN region (selling all ARIN region offices, all ARIN region
> > >> network assets, all ARIN service region customers, all number
> resources
> > >> used in the ARIN (associated with previous noted sale of network and
> > >> customers), but retaining ARIN issued resources in use outside of the
> > >> ARIN service region. During restructuring the company concentrates its
> > >> holdings which are not in us in the ARIN service region in its
> 

Re: [arin-ppml] Revised - Draft Policy ARIN-2019-12: M Legal Jurisdiction Exclusion

[Brian Jones]

Question: Does this mean that the entity responsible for the continued
resource holdings is subject to keeping up the POC and abuse contact
information for each of the locations or allocation blocks where it
continues to use ARIN resources?

—
Brian Jones
NI Virginia Tech
bjo...@vt.edu


On Tue, Jan 28, 2020 at 7:23 AM ARIN  wrote:

> The following has been revised:
>
> * Draft Policy ARIN-2019-12: M Legal Jurisdiction Exclusion
>
> Revised text is below and can be found at:
>
> https://www.arin.net/participate/policy/drafts/2019_12/
>
> You are encouraged to discuss all Draft Policies on PPML. The AC will
> evaluate the discussion in order to assess the conformance of this Draft
> Policy with ARIN's Principles of Internet number resource policy as
> stated in the Policy Development Process (PDP). Specifically, these
> principles are:
>
> * Enabling Fair and Impartial Number Resource Administration
> * Technically Sound
> * Supported by the Community
>
> The PDP can be found at:
> https://www.arin.net/participate/policy/pdp/
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/participate/policy/drafts/
>
> Regards,
>
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
>
>
>
> Draft Policy ARIN-2019-12: M Legal Jurisdiction Exclusion
>
> Problem Statement:
>
> Merger and acquisition activity sometimes results in a surviving legal
> entity that is not in ARIN service region, but may prefer to continue
> the pre-existing relationship with ARIN.
>
> Example: Imagine a case where a global company has decided to
> discontinue service in the ARIN service region (shuttering ARIN region
> offices laying off ARIN region employees, and canceling ARIN region
> customers) and repurpose the network resources and number resources in
> the rest of its global footprint. During restructuring the company
> concentrates its holdings in its European subsidiary, and then dissolved
> its US legal entity.
>
> Imagine a case where a global company has decided to divest its service
> in the ARIN region (selling all ARIN region offices, all ARIN region
> network assets, all ARIN service region customers, all number resources
> used in the ARIN (associated with previous noted sale of network and
> customers), but retaining ARIN issued resources in use outside of the
> ARIN service region. During restructuring the company concentrates its
> holdings which are not in us in the ARIN service region in its European
> subsidiary, and then sells off its US legal entity (including the
> network, customers, addresses in use, etc) dissolved its US legal entity.
>
> Policy Statement:
>
> Add the following to section 8.2
>
> Mergers, acquisitions, and reorganization activity resulting in the
> surviving entity ceasing to have a real and substantial connection with
> the ARIN region shall be permitted to continue holding any numbering
> resources issued (directly or indirectly) by ARIN prior to the merger,
> acquisition or reorganization activity, but shall not qualify for any
> additional numbering resources (directly or indirectly) from ARIN,
> unless and until it once again has a real and substantial connection
> with the ARIN region as required by the Numbering Resource Policy Manual.
>
> Timetable for Implementation: Immediate
>
> Anything Else:
>
> This proposal may be overtaken by a more general approach to ARIN
> membership legal jurisdiction exclusion
>
> To clarify scope, a legal entity present within the ARIN service region,
> and a current ARIN RSA executed with that entity, is necessary to
> receive allocations or assignments from ARIN. Therefore in the scenario
> postulated in the problem statement, the organization would have to
> re-establish itself within the ARIN service region to receive additional
> resources from ARIN, while it can continue to hold the allocations or
> assignments made prior to any merger, acquisition, or reorganization
> activity.
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] ARIN-2019-19 Require IPv6 before receiving Section 8 IPv4 Transfers

[Brian Jones]

—
Brian Jones
Virginia Tech

On Mon, Jan 13, 2020 at 12:06 PM Andrew Dul  wrote:

> Happy New Year everyone...
>
> We had a robust discussion on this list before the New Year, but it was
> clear that we don't have consensus on the current draft.  Thus to help move
> this draft forward...  I'm proposing a couple of questions to see if we can
> find middle ground here to update the text of the draft policy.
>
> The policy as written today would require organizations who wish to obtain
> an IPv4 transfer to complete a limited scope IPv6 deployment.
>
> Do you support any IPv6 requirements on an IPv4 transfer?
>
While I am for any way to productively promote the use of IPv6, I do not
support any IPv6 requirements on IPv4 transfers because I do not think this
is a productive way of promoting implementation of IPv6. If there were an
IPv6 requirement folks would just go through the motions to get their IPv4
transfer block and not implement the IPv6 allocation.





> Would you support IPv6 requirements for receiving a block via the ARIN
> wait-list?
>
> Do you support different IPv6 deployment criteria that would qualify an
> organization for a IPv4 transfer?  (Such as, just requiring the org to have
> an IPv6 allocation or assignment from ARIN)  Please propose different IPv6
> criteria that you would support if the current criteria is unacceptable.
>
>
> Thanks for your comments on this draft,
>
> Andrew
>
>
> ===
>
> *Current Policy Statement:*
>
> In section 8.5.2, add the following language to the end of the paragraph
> entitled “Operational Use”:
>
> Such operational network must at minimum include an allocation or
> assignment by ARIN of IPv6 address space under the same Org ID receiving
> the transferred IPv4 space. Such Org must be able to prove this IPv6 space
> is being routed by using it to communicate with ARIN.
>
> In the event the receiver provides a written statement from its upstream
> that IPv6 connectivity is unavailable, the IPv6 requirement may be waived.
>
> ===
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Brian Jones]

Looking at the numbers John posted concerning this issue, it tends to *look
like* some of these 3x small folks decided to drop their request once they
encountered the price increase. If this is the case then we should move
forward with this proposal. We do not want to create a situation where
folks are continuing to use only IPv4 because of costs.

I support this proposal.

—
Brian


On Thu, Apr 16, 2020 at 7:19 AM  wrote:

> Is that very much because they found out if they accepted the IPv6 space,
> their fees would double???
>
> If so, this PROVES the need to adopt this plan.  We should not have things
> in place that prevent IPv6 adoption.  We have already decided that IPv6
> should be cost neutral.  Lets fix this glitch and let these 3x small
> people have IPv6 without doubling their cost.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
> On Thu, 16 Apr 2020, John Sweeting wrote:
>
> > Yes that is exactly what it means. After approval they decided for
> whatever reason they no longer wanted the resource.
> >
> > Sent from my iPhone
> >
> >> On Apr 16, 2020, at 1:56 AM, John Santos  wrote:
> >>
> >> What does "closed with no action" mean?  Does it mean the RSP
> abandoned the request?
> >>
> >>
> >>> On 4/15/2020 7:18 PM, John Sweeting wrote:
> >>> Hi Andrew,
> >>>
> >>> The numbers around this are:
> >>>
> >>> 320 3x small RSPs
> >>> 30 have applied and been approved for IPv6 of which 26 closed with no
> action to complete by the requester. The other 4 are currently still open
> and pending action.
> >>>
> >>> Thanks,
> >>> John S.
> >>>
> >>> On 4/15/20, 11:30 AM, "Andrew Dul"  wrote:
> >>>
> >>> John,
> >>>  Could you provide the community with a rough magnitude of
> this issue?
> >>>  Approximately how many of these 3x-small ISP organizations
> have come to
> >>> ARIN and requested IPv6?  How many accepted the block and how many
> >>> refused because of the fee issue?  How many 3x-small ISP
> organizations
> >>> does ARIN currently serve.
> >>>  Thanks,
> >>> Andrew
> >>>  On 4/14/2020 2:29 PM, John Sweeting wrote:
> >>>> All,
> >>>>
> >>>> For anyone interested in the content of the "Policy Experience
> Report presented by Registration
> >>>> Services to the AC at its annual workshop in January 2020"
> referenced in the problem statement you can see that report here:
> >>>>
> >>>>
> https://www.arin.net/about/welcome/ac/meetings/2020_0124/policy_experience_report.pdf
> >>>>
> >>>> Thank you.
> >>>>
> >>>> On 3/24/20, 1:22 PM, "ARIN-PPML on behalf of ARIN" <
> arin-ppml-boun...@arin.net on behalf of i...@arin.net> wrote:
> >>>>
> >>>> On 19 March 2020, the ARIN Advisory Council (AC) accepted
> >>>> "ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.
> >>>>
> >>>> Draft Policy ARIN-2020-3 is below and can be found at:
> >>>>
> >>>> https://www.arin.net/participate/policy/drafts/2020_3/
> >>>>
> >>>> You are encouraged to discuss all Draft Policies on PPML. The
> AC will
> >>>> evaluate the discussion in order to assess the conformance of
> this draft
> >>>> policy with ARIN's Principles of Internet number resource
> policy as
> >>>> stated in the Policy Development Process (PDP). Specifically,
> these
> >>>> principles are:
> >>>>
> >>>> * Enabling Fair and Impartial Number Resource Administration
> >>>> * Technically Sound
> >>>> * Supported by the Community
> >>>>
> >>>> The PDP can be found at:
> >>>> https://www.arin.net/participate/policy/pdp/
> >>>>
> >>>> Draft Policies and Proposals under discussion can be found at:
> >>>> https://www.arin.net/participate/policy/drafts/
> >>>>
> >>>> Regards,
> >>>>
> >>>> Sean Hopkins
> >>>> Policy Analyst
> >>>> American Registry for Internet Numbers (ARIN)
> >>>>
> >>>>
> >>>>
> >>>> Draft Policy ARIN-2020-3: IPv6 Nano-allocations
> >>>>
> >>>> Problem Statement:
> >>>>
> >>>> ARIN's fee structure provides a graduated system wherein
> organizations
> >>>> pay based on the amount of number resources they consume.
> >>>>
> >>>> In the case of the very smallest ISPs, if a 3X-Small ISP
> (with a /24 or
> >>>> smaller of IPv4) gets the present minimal-sized IPv6
> allocation (a /36),
> >>>> its annual fees will double from $250 to $500/year.
> >>>>
> >>>> According to a Policy Experience Report presented by
> Registration
> >>>> Services to the AC at its annual workshop in January 2020,
> this
> >>>> represents a disincentive to IPv6 adoption with a substantial
> fraction
> >>>> of so-situated ISPs saying "no thanks" and abandoning their
> request for
> >>>> IPv6 number resources when informed of the impact on their
> annual 

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Brian Jones]

No one is going to want to sell off their v4 space and if they did they
could certainly afford the IPv6 allocation charges. Possibly the
presentation of this option could change their view? They certainly need to
understand the importance of beginning to use IPv6...

—
Brian


On Thu, Apr 16, 2020 at 11:42 AM John Curran  wrote:

> On 24 Mar 2020, at 1:20 PM, ARIN  wrote:
>
> ...
> Reserving /40s only for organizations initially expanding into IPv6 from
> an initial sliver of IPv4 space will help to narrowly address the problem
> observed by Registration Services while avoiding unintended consequences by
> accidentally giving a discount for undersized allocations.
>
>
> ARIN tries to provide as much flexibility as possible in dealing with
> requests, so it is important that the community document the reasoning
> behind policy language that constrains the choices available to those
> requesting resources.   ARIN staff will certainly get asked about such
> restrictions, so we best understand the motivation.
>
> For this reason, would it be possible for the advocates of the policy to
> elaborate (on the list) on the perceived "unintended consequences by
> accidentally giving a discount for undersized allocations”?   (In
> particular, if a party specifically sought a /40 IPv6 allocation but they
> held more than /24 of IPv4, is the desire that ARIN would deny the request
> if they failed to agree to a larger IPv6 allocation or agree to divesture
> of IPv4 resources down to the /24 maximum?)
>
> Thanks!
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Brian Jones]

Good questions Andrew.I was wondering the same thing, what is the magnitude
of this issue.
—
Brian


On Wed, Apr 15, 2020 at 11:30 AM Andrew Dul  wrote:

> John,
>
> Could you provide the community with a rough magnitude of this issue?
>
> Approximately how many of these 3x-small ISP organizations have come to
> ARIN and requested IPv6?  How many accepted the block and how many
> refused because of the fee issue?  How many 3x-small ISP organizations
> does ARIN currently serve.
>
> Thanks,
> Andrew
>
> On 4/14/2020 2:29 PM, John Sweeting wrote:
> > All,
> >
> > For anyone interested in the content of the "Policy Experience Report
> presented by Registration
> > Services to the AC at its annual workshop in January 2020" referenced in
> the problem statement you can see that report here:
> >
> >
> https://www.arin.net/about/welcome/ac/meetings/2020_0124/policy_experience_report.pdf
> >
> > Thank you.
> >
> > On 3/24/20, 1:22 PM, "ARIN-PPML on behalf of ARIN" <
> arin-ppml-boun...@arin.net on behalf of i...@arin.net> wrote:
> >
> > On 19 March 2020, the ARIN Advisory Council (AC) accepted
> > "ARIN-prop-285: IPv6 Nano-allocations" as a Draft Policy.
> >
> > Draft Policy ARIN-2020-3 is below and can be found at:
> >
> > https://www.arin.net/participate/policy/drafts/2020_3/
> >
> > You are encouraged to discuss all Draft Policies on PPML. The AC
> will
> > evaluate the discussion in order to assess the conformance of this
> draft
> > policy with ARIN's Principles of Internet number resource policy as
> > stated in the Policy Development Process (PDP). Specifically, these
> > principles are:
> >
> > * Enabling Fair and Impartial Number Resource Administration
> > * Technically Sound
> > * Supported by the Community
> >
> > The PDP can be found at:
> > https://www.arin.net/participate/policy/pdp/
> >
> > Draft Policies and Proposals under discussion can be found at:
> > https://www.arin.net/participate/policy/drafts/
> >
> > Regards,
> >
> > Sean Hopkins
> > Policy Analyst
> > American Registry for Internet Numbers (ARIN)
> >
> >
> >
> > Draft Policy ARIN-2020-3: IPv6 Nano-allocations
> >
> > Problem Statement:
> >
> > ARIN's fee structure provides a graduated system wherein
> organizations
> > pay based on the amount of number resources they consume.
> >
> > In the case of the very smallest ISPs, if a 3X-Small ISP (with a /24
> or
> > smaller of IPv4) gets the present minimal-sized IPv6 allocation (a
> /36),
> > its annual fees will double from $250 to $500/year.
> >
> > According to a Policy Experience Report presented by Registration
> > Services to the AC at its annual workshop in January 2020, this
> > represents a disincentive to IPv6 adoption with a substantial
> fraction
> > of so-situated ISPs saying "no thanks" and abandoning their request
> for
> > IPv6 number resources when informed of the impact on their annual
> fees.
> >
> > This can be addressed by rewriting subsection 6.5.2(b). Initial
> > Allocation Size to allow allocation of a /40 to only the smallest
> ISPs
> > upon request, and adding a new clause 6.5.2(g) to cause an automatic
> > upgrade to at least a /36 in the case where the ISP is no longer
> 3X-Small.
> >
> > Reserving /40s only for organizations initially expanding into IPv6
> from
> > an initial sliver of IPv4 space will help to narrowly address the
> > problem observed by Registration Services while avoiding unintended
> > consequences by accidentally giving a discount for undersized
> allocations.
> >
> > Policy Statement:
> >
> > Replace the current 6.5.2(b) with the following:
> >
> > b. In no case shall an LIR receive smaller than a /32 unless they
> > specifically request a /36 or /40.
> >
> > In order to be eligible for a /40, an ISP must meet the following
> > requirements:
> >   * Hold IPv4 direct allocations totaling a /24 or less (to include
> zero)
> >   * Hold IPv4 reassignments/reallocations totaling a /22 or less (to
> > include zero)
> >
> > In no case shall an ISP receive more than a /16 initial allocation.
> >
> > Add 6.5.2(g) as follows:
> >
> > g. An LIR that requests a smaller /36 or /40 allocation is entitled
> to
> > expand the allocation to any nibble aligned size up to /32 at any
> time
> > without renumbering or additional justification.  /40 allocations
> shall
> > be automatically upgraded to /36 if at any time said LIR's IPv4
> direct
> > allocations exceed a /24. Expansions up to and including a /32 are
> not
> > considered subsequent allocations, however any expansions beyond /32
> are
> > considered subsequent allocations and must conform to section 6.5.3.
> > Downgrades of any IPv6 allocation to less than a /36 are not
> permitted
> > regardless of the ISP's current or former IPv4 number resource
> holdings.
> >

Re: [arin-ppml] Revised and Reverted to Draft Policy - Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements

[Brian Jones]

I support this proposal as written.
—
Brian

On Thu, May 14, 2020 at 10:56 AM Kat Hunter  wrote:

> After making adjustments to the text, ARIN staff and legal conducted a new
> staff and legal review on 2019-1. You can view the updated review here:
> https://www.arin.net/participate/policy/drafts/2019_1/#staff-and-legal-review-30-april-2020
>  .
> It has been suggested that
> "It is worth noting that this Draft Policy does not include the removal
> of pending ARIN Waitlist requests for organizations that act as source
> organizations for 8.2, 8.3, or 8.4 transfers, which would allow them to
> conduct such transfers while waitlisted, and receive resources from the
> ARIN Waitlist immediately thereafter, as all organizations on the ARIN
> Waitlist have already applied, and are pending fulfillment.
>
> The text is clear and understandable, and can be implemented as written."
>
> After some discussion with some members of the AC, it was suggested that a
> new subsection is added to section 8 which would allow for additional
> clarity from this policy and some future cleanup via other future policy.
>
> "8.6 Waitlist Restrictions
>
> Any organization which is on the wait list and submits a request to be the
> source of a transfer under any provision in section 8 will be summarily
> removed from the wait list."
>
> I'd like to get the community's thoughts on the addition. With this
> addition, would you support the policy as written?
>
> -Kat Hunter
>
> On Tue, Mar 24, 2020 at 1:24 PM Kat Hunter  wrote:
>
>> Owen, I think this is a good suggestion. I've updated the month
>> designations in the other section to 90 days as, I agree, it is more
>> precise when we are discussing shorter amounts of time. Additionally, I've
>> taken your suggestion on wordsmithing that section and adjusted it just a
>> little.
>>
>> " An organization which serves as the source of an 8.2 IPv4 transfer will
>> not be allowed to apply for IPv4 address space under section 4.1.8 ARIN
>> Waitlist for a period of 36 months following said transfer unless the
>> recipient organization remains a subsidiary, parent company, or under
>> common ownership with the source organization.".
>>
>> I wanted to make sure I specified that this was in reference to IPv4 and
>> that the organization also remains a subsidiary, parent company, or under
>> common ownership.  Thank you for the input. Additionally I'd like to see if
>> there is anyone else that still supports or no longer longer supports this
>> policy as written.
>>
>> Kat Hunter
>>
>> On Wed, Mar 11, 2020 at 4:42 AM Owen DeLong  wrote:
>>
>>>
>>>
>>> > On Mar 9, 2020, at 06:26 , ARIN  wrote:
>>> >
>>> > On 20 February 2020, the ARIN Advisory Council (AC) reverted the
>>> following Recommended Draft Policy to Draft Policy Status due to community
>>> feedback recommending significant substantive changes.:
>>> >
>>> > * Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements
>>> >
>>> > The text has since been revised in response to that feedback.
>>> >
>>> > Revised text is below and can be found at:
>>> >
>>> > https://www.arin.net/participate/policy/drafts/2019_1/
>>> >
>>> > You are encouraged to discuss all Draft Policies on PPML. The AC will
>>> evaluate the discussion in order to assess the conformance of this Draft
>>> Policy with ARIN's Principles of Internet number resource policy as stated
>>> in the Policy Development Process (PDP). Specifically, these principles are:
>>> >
>>> > * Enabling Fair and Impartial Number Resource Administration
>>> > * Technically Sound
>>> > * Supported by the Community
>>> >
>>> > The PDP can be found at:
>>> > https://www.arin.net/participate/policy/pdp/
>>> >
>>> > Draft Policies and Proposals under discussion can be found at:
>>> > https://www.arin.net/participate/policy/drafts/
>>> >
>>> > Regards,
>>> >
>>> > Sean Hopkins
>>> > Policy Analyst
>>> > American Registry for Internet Numbers (ARIN)
>>> >
>>> >
>>> >
>>> >
>>> > Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements
>>> >
>>> > Problem Statement:
>>> >
>>> > Per a recent ARIN Policy Experience Report and resulting AC
>>> discussion, it was noted that the language of Section 4.1.8 is imprecise in
>>> that it can be interpreted as specifying a waiting period for any
>>> allocation activity, as opposed to being intended to limit only the
>>> frequency of IPv4 allocations under Section 4.
>>> >
>>> > The same Policy Experience Report also noted that ARIN staff has
>>> observed a pattern where an organization transfers space under NRPM Section
>>> 8.2 to a specified recipient, and then immediately applies for space under
>>> Section 4. This activity appears to be speculative in nature and not
>>> consistent with sound address management policy.
>>> >
>>> > The updated language in this proposal addresses the two issues above,
>>> as both concerns can be addressed via modifications to the same section and
>>> sentence thereof of the NRPM:
>>> >
>>> > Clarifies the 

Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of Organizations Removed from Waitlist by Implementation of ARIN-2019-16

[Brian Jones]

I +1 Tom's input below. I think the organizations that were on the waiting
list before should receive the same benefits and restrictions they were
given in the original vetting process  when they were placed onto the
waiting list.

I also +1 Owen's comment about yes IPv4 is scarce but that's not the
problem. IMHO - IPv6 should be the first consideration of anyone looking to
implement networks now. As long as "we" keep placing high value on IPv4
addresses "we" are prolonging the adoption of IPv6, the technology of today
and the future.
—
Brian

On Fri, Jul 17, 2020 at 9:26 AM Tom Pruitt  wrote:

> I support the draft policy as written, which addresses grandfathering
> organizations
>
>
>
> Views 2, 3, and 4 seem to be addressing the list as a whole, which I would
> also support, but this draft policy was brought up to address the situation
> that happened when 2019-16 was implemented and dropped some organizations
> from the wait list.
>
>
>
> Thanks,
>
> Tom Pruitt
>
> Network Engineer
>
> Stratus Networks
>
> [image: stratus_networks_logo_FINAL]
>
> This e-mail, and any files transmitted with it are the property of Stratus
> Networks, Inc. and/or its affiliates, are confidential, and are intended
> solely for the use of the individual or entity to whom this e-mail is
> addressed. If you are not one of the named recipient(s) or otherwise have
> reason to believe that you have received this message in error, please
> notify the sender at 309-408-8704 and delete this message immediately from
> your computer. Any other use, retention, dissemination, forwarding,
> printing, or copying of this e-mail is strictly prohibited
>
>
>
> *From:* ARIN-PPML  *On Behalf Of *A N
> *Sent:* Friday, July 17, 2020 7:56 AM
> *To:* ARIN-PPML List 
> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of
> Organizations Removed from Waitlist by Implementation of ARIN-2019-16
>
>
>
> Hi all -
>
> Alyssa and I are shepherding this on behalf of the AC. Given the varying,
> thoughtful opinions, I'd like to prod to see if anyone else has thoughts
> one way or the other on this draft.
>
>
>
> Anita
>
>
>
> On Fri, Jun 19, 2020 at 6:26 PM Alyssa Moore 
> wrote:
>
> Hi folks,
>
> There was some great discussion of this policy proposal at ARIN45. We hear
> a wide range of views including:
>
>1. Don't grandfather organizations. The new waitlist policy is sound.
>2. Organizations that were on the waitlist before 2019-16 should be
>eligible for their original request size (even if it exceeds the new limit
>of a /22).
>3. Organizations that were on the waitlist before 2019-16 should
>remain eligible if their holdings exceed a /20 OR a /18. The draft policy
>under discussion specifies a /18 total holdings for grandfathered orgs,
>while the current waitlist policy (2019-16) specifies a /20.
>4. Organizations that were on the waitlist before 2019-16 should be
>eligible regardless of their total holdings because that was not a
>restriction of the policy under which they originally qualified for the
>waitlist.
>
>  There was general support to continue finessing this draft. If you have
> views on the above noted parameters, please make them known here.
>
>
>
> For reference:
>
> *Old waitlist policy*
>
>1. Requester specifies smallest block they'd be willing to accept,
>equal to or larger than the applicable minimum size specified elsewhere in
>ARIN policy.
>2. Did not place a limit on the total existing IP address holdings of
>a party eligible for the waitlist.
>3. Made resources issued from the waitlist ineligible for transfer
>until after a period of 12 months.
>
> *New Waitlist Policy*
>
>1. Limits the size of block ARIN can issue on the waitlist to a /22.
>2. Places a limit on the total existing IP address holdings of a party
>eligible for the waitlist at a /20 or less.
>3. Makes resources issued from the waitlist ineligible for transfer
>until after a period of 60 months.
>
>
> Best,
> Alyssa
>
>
>
> On Thu, Mar 26, 2020 at 3:35 PM David Farmer  wrote:
>
> I support this policy and believe the policy development process is the
> proper place to handle this issue. However, this policy seems to be
> implementable as a one-time policy directive to ARIN Staff. Once
> implemented, by putting the effected organizations back on the waiting
> list, it seems unnecessary to memorialized the text in the NRPM, it would
> immediately become extraneous and potentially confusing to future readers
> of the NRPM.
>
>
>
> Therefore, I would like to recommend the Policy Statement not be added to
> the NRPM upon its implementation. I believe this to be consistent with the
> intent of the policy.  Otherwise, does ARIN Staff have procedural advice on
> how best to handle what seems like a one-time directive?
>
>
>
> Thanks
>
>
>
> On Tue, Mar 24, 2020 at 12:21 PM ARIN  wrote:
>
>
> Draft Policy ARIN-2020-2: Grandfathering of Organizations Removed from

Re: [arin-ppml] Recommended Draft Policy ARIN-2020-3: IPv6 Nano-allocations

[Brian Jones]

+1 Leif's recommended wording.
—
Brian
bjo...@vt.edu


On Tue, Jul 21, 2020 at 12:34 PM Leif Sawyer  wrote:

> "Partial returns of any IPv6 allocation that results in less than a /36 of
> holding are not permitted, [...]"
>
>
> This would seem to address Albert's issue, and remove the uncertainty of
> "downgrade" while allowing for a "complete return" of IPv6 space.
>
>
>
> *Leif Sawyer*
> *GCI* | Enterprise Security Architect
> *t:* 907-868-0116 | *w:* *www.gci.com* 
>
>
>
> --
> *From:* ARIN-PPML  on behalf of
> hostmas...@uneedus.com 
> *Sent:* Tuesday, July 21, 2020 8:10 AM
> *To:* Rob Seastrom
> *Cc:* arin-ppml@arin.net
> *Subject:* Re: [arin-ppml] Recommended Draft Policy ARIN-2020-3: IPv6
> Nano-allocations
>
> [*EXTERNAL EMAIL* - CAUTION: Do not open unexpected attachments or links.]
>
> How about "Downgrades of any IPv6 allocation to less than a /36 OTHER THAN
> A RETURN OF ALL IPv6 RESOURCES are not permitted regardless of the ISP’s
> current or former IPv4 number resource holdings."
>
> At least this avoids the "Hotel California" issue.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
>
> On Tue, 21 Jul 2020, Rob Seastrom wrote:
>
> >
> > Hi Albert,
> >
> > As a practical matter, I don’t think the NRPM overrides your ability to
> terminate your contract with ARIN should that become a business requirement.
> >
> > Do you have alternative language to suggest that is clear, concise, and
> preserves the intent of narrowly boxing in nano-allocations for the tiniest
> of providers with IPv4 rather than incenting undersizing IPv6 allocations?
> Remember that the whole reason for the default /32 allocation is that we
> wish for IPv6 allocations to be the polar opposite of IPv4 slow-start - a
> one-and-done approach that minimizes both unnecessary routing table growth
> and the need to come back to ARIN for more space.
> >
> > Thanks,
> >
> > -r
> >
> >
> >
> >
> >> On Jul 21, 2020, at 11:26 AM, hostmas...@uneedus.com wrote:
> >>
> >> I have a problem with this language:
> >>
> >> "Downgrades of any IPv6 allocation to less than a /36 are not permitted
> regardless of the ISP’s current or former IPv4 number resource holdings."
> >>
> >> Downgrades include in my mind a return, and thus a downgrade to 0. This
> language seems to lock in anyone who has ever requested IPv6 space.
> >>
> >> Does this make a request for IPv6 space from ARIN like the Hotel
> California, where you can never leave
> >>
> >> If I were one of those ISP's with a /24 of IPv4, and I took the minimum
> allocation of IPv6 which raised my fees to $500 from $250, does this
> language make me continue to pay $500/yr even if I decide to return all my
> IPv6 resources to ARIN, and either get IPv6 space from my upstream or forgo
> use of IPv6?
> >>
> >> Albert Erdmann
> >> Network Administrator
> >> Paradise On Line Inc.
> >>
> >>
> >> On Tue, 21 Jul 2020, ARIN wrote:
> >>
> >>> On 16 July 2020, the ARIN Advisory Council (AC) advanced the following
> Draft Policy to Recommended Draft Policy status:
> >>>
> >>> ARIN-2020-3: IPv6 Nano-allocations
> >>>
> >>> The text of the Recommended Draft Policy is below, and may also be
> found at:
> >>>
> >>> https://www.arin.net/participate/policy/drafts/2020_3/
> >>>
> >>> You are encouraged to discuss all Recommended Draft Policies on PPML
> prior to their presentation at the next ARIN Public Policy Consultation
> (PPC). PPML and PPC discussions are invaluable to the AC when determining
> community consensus.
> >>>
> >>> The PDP can be found at:
> >>> https://www.arin.net/participate/policy/pdp/
> >>>
> >>> Draft Policies and Proposals under discussion can be found at:
> >>> https://www.arin.net/participate/policy/drafts/
> >>>
> >>> Regards,
> >>>
> >>> Sean Hopkins
> >>> Policy Analyst
> >>> American Registry for Internet Numbers
> >>>
> >>>
> >>>
> >>> Recommended Draft Policy ARIN-2020-3: IPv6 Nano-allocations
> >>>
> >>> AC Assessment of Conformance with the Principles of Internet Number
> Resource Policy:
> >>>
> >>> Recommended Draft Policy ARIN-2020-3 provides for small IPv6
> allocations to ISPs. This policy would allow the smallest ISP organizations
> to obtain a /40 of IPv6 addresses. This recommended draft is technically
> sound, supported by the community and enables fair and impartial
> administration of number resources by providing the smallest organizations
> the opportunity to obtain an IPv6 allocation without a fee increase under
> the current fee schedule.
> >>>
> >>> Problem Statement:
> >>>
> >>> ARIN’s ISP registration services fee structure has graduated fee
> categories based upon the total amount of number resources held within the
> ARIN registry.
> >>>
> >>> In the case of the very smallest ISPs, if a 3X-Small ISP (with a /24
> or smaller of IPv4) gets the present minimal-sized IPv6 allocation (a /36),
> its annual fees will double from $250 to $500/year.
> >>>
> >>> According to a Policy Experience 

Re: [arin-ppml] Draft Policy 2020-11: Replace the Image in Section 2 With a Textual Description

[Brian Jones]

I support ARIN-2020-11 with one suggestion. Spell out what RIR stands for
similar to the way IANA and ISP are spelled out to increase clarity and
understandability.
—
Brian

On Tue, Dec 22, 2020 at 5:20 PM ARIN  wrote:

> On 17 December 2020, the ARIN Advisory Council (AC) advanced
> "ARIN-prop-295: Replace the Image in Section 2 With a Textual Description"
> to Draft Policy.
>
> Draft Policy ARIN-2020-11 is below and can be found at:
>
> https://www.arin.net/participate/policy/drafts/2020_11/
>
> You are encouraged to discuss all Draft Policies on PPML. The AC will
> evaluate the discussion in order to assess the conformance of this draft
> policy with ARIN's Principles of Internet number resource policy as stated
> in the Policy Development Process (PDP). Specifically, these principles are:
>
> * Enabling Fair and Impartial Number Resource Administration
> * Technically Sound
> * Supported by the Community
>
> The PDP can be found at:
> https://www.arin.net/participate/policy/pdp/
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/participate/policy/drafts/
>
> Regards,
>
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
>
>
>
> Draft Policy ARIN-2020-11: Replace the Image in Section 2 With a Textual
> Description
>
>
>
> Problem Statement:
>
>
>
> The beginning of Section 2 in the NRPM shows a diagram of how addressing
> responsibility is delegated. However, this image does not appear to have a
> description or even alt text, and the actual text is not selectable. This
> could have accessibility implications, especially for blind people, if the
> NRPM is converted to plain text, or if the NRPM is translated into another
> language.
>
>
>
> Policy Statement:
>
>
>
> Proposal:
>
>
>
> Replace the lead section of Section 2 with the following:
>
>
>
> Responsibility for management of address spaces is distributed globally in
> accordance with the following procedures:
>
>
>
> - Global address space management is performed by the Internet Assigned
> Numbers Authority (IANA). IANA distributes address space to RIRs (AfriNIC,
> APNIC, ARIN, LACNIC, and the RIPE NCC), but not directly to ISPs or end
> users.
>
> - RIRs, such as ARIN, distribute address space to Internet Service
> Providers (ISPs) and directly to end-user organizations.
>
> - ISPs may further delegate address space to other ISPs, as well as to
> other end-user organizations.
>
>
>
> Timetable for implementation: Immediate.
>
>
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy 2020-11: Replace the Image in Section 2 With a Textual Description

[Brian Jones]

Yes, the names of the RIR's in the expanded test portion is what I meant.

+1 more coffee for me to...
—
Brian

On Wed, Dec 23, 2020 at 11:00 AM Joe Provo  wrote:

> Derp, you mean the names of the RIRs in the new expanded text.
> That sounds like a good suggestion to me!
>
> Joe, needing more coffee
>
> On Wed, Dec 23, 2020 at 10:59:07AM -0500, Joe Provo wrote:
> > On Wed, Dec 23, 2020 at 08:55:34AM -0500, Brian Jones wrote:
> > > I support ARIN-2020-11 with one suggestion. Spell out what RIR stands
> for
> > > similar to the way IANA and ISP are spelled out to increase clarity and
> > > understandability.
> >
> > Brian,
> >
> > The image in question is in the header of Section 2.
> > If you have a suggestion to improve the RIR definition in
> > Section 2.2 (
> >
> https://www.arin.net/participate/policy/nrpm/#2-2-regional-internet-registry-rir
> > ), can you be more specific?
> >
> > Cheers!
> >
> > Joe
> >
> > > Brian
> > >
> > > On Tue, Dec 22, 2020 at 5:20 PM ARIN  wrote:
> > >
> > > > On 17 December 2020, the ARIN Advisory Council (AC) advanced
> > > > "ARIN-prop-295: Replace the Image in Section 2 With a Textual
> Description"
> > > > to Draft Policy.
> > > >
> > > > Draft Policy ARIN-2020-11 is below and can be found at:
> > > >
> > > > https://www.arin.net/participate/policy/drafts/2020_11/
> > > >
> > > > You are encouraged to discuss all Draft Policies on PPML. The AC will
> > > > evaluate the discussion in order to assess the conformance of this
> draft
> > > > policy with ARIN's Principles of Internet number resource policy as
> stated
> > > > in the Policy Development Process (PDP). Specifically, these
> principles are:
> > > >
> > > > * Enabling Fair and Impartial Number Resource Administration
> > > > * Technically Sound
> > > > * Supported by the Community
> > > >
> > > > The PDP can be found at:
> > > > https://www.arin.net/participate/policy/pdp/
> > > >
> > > > Draft Policies and Proposals under discussion can be found at:
> > > > https://www.arin.net/participate/policy/drafts/
> > > >
> > > > Regards,
> > > >
> > > > Sean Hopkins
> > > > Policy Analyst
> > > > American Registry for Internet Numbers (ARIN)
> > > >
> > > >
> > > >
> > > > Draft Policy ARIN-2020-11: Replace the Image in Section 2 With a
> Textual
> > > > Description
> > > >
> > > >
> > > >
> > > > Problem Statement:
> > > >
> > > >
> > > >
> > > > The beginning of Section 2 in the NRPM shows a diagram of how
> addressing
> > > > responsibility is delegated. However, this image does not appear to
> have a
> > > > description or even alt text, and the actual text is not selectable.
> This
> > > > could have accessibility implications, especially for blind people,
> if the
> > > > NRPM is converted to plain text, or if the NRPM is translated into
> another
> > > > language.
> > > >
> > > >
> > > >
> > > > Policy Statement:
> > > >
> > > >
> > > >
> > > > Proposal:
> > > >
> > > >
> > > >
> > > > Replace the lead section of Section 2 with the following:
> > > >
> > > >
> > > >
> > > > Responsibility for management of address spaces is distributed
> globally in
> > > > accordance with the following procedures:
> > > >
> > > >
> > > >
> > > > - Global address space management is performed by the Internet
> Assigned
> > > > Numbers Authority (IANA). IANA distributes address space to RIRs
> (AfriNIC,
> > > > APNIC, ARIN, LACNIC, and the RIPE NCC), but not directly to ISPs or
> end
> > > > users.
> > > >
> > > > - RIRs, such as ARIN, distribute address space to Internet Service
> > > > Providers (ISPs) and directly to end-user organizations.
> > > >
> > > > - ISPs may further delegate address space to other ISPs, as well as
> to
> > > > other end-user organizations.
> > > >
> > > >
> > > >
> > > > Timetable for implementation: Immediate.
> > > >
&

Re: [arin-ppml] Revised - Editorial Change ARIN-edit-2020-9: Section 8 Editorial Clean-up

[Brian Jones]

This editorial change makes the NRPM cleaner and easier to read and understand. 
I support this change.


> On Aug 18, 2021, at 4:59 PM, ARIN  wrote:
> 
> The following Editorial Change has been revised:
> 
> * ARIN-edit-2020-9: Section 8 Editorial Clean-up
> 
> Revised text is below and can be found at:
> 
> https://www.arin.net/participate/policy/drafts/ARIN_edit_2020_9/ 
> <https://www.arin.net/participate/policy/drafts/ARIN_edit_2020_9/>
> 
> The process for Editorial Changes is found in Part One, Section 3.1, 
> paragraph 3 of the Policy Development Process (PDP):
> 
> "Changes to policy that are purely editorial and non-substantial in nature 
> are outside the scope of the full Policy Development Process and may only be 
> made with 30 days public notice followed by the concurrence of both the ARIN 
> Advisory Council and ARIN Board of Trustees that the changes are 
> non-substantial in nature."
> 
> Your feedback on this Editorial Change is encouraged as the community review 
> period continues. This review period will close on 26 August 2021.
> 
> The PDP can be found at:
> 
> https://www.arin.net/participate/policy/pdp/ 
> <https://www.arin.net/participate/policy/pdp/>
> 
> Draft Policies and Proposals under discussion can be found at:
> 
> https://www.arin.net/participate/policy/drafts/ 
> <https://www.arin.net/participate/policy/drafts/>
> 
> Regards,
> 
> Sean Hopkins
> Senior Policy Analyst
> American Registry for Internet Numbers (ARIN)
> 
> 
> 
> Editorial Change ARIN-edit-2020-9: Section 8 Editorial Clean-up
> 
> Problem Statement:
> 
> ARIN staff have identified some areas of potential NRPM editorial clean-up. 
> Building on those recommendations the ARIN AC NRPM Clean-up Working Group 
> undertook an editorial review of the NRPM.
> 
> The focus of the review was to clarify and simplify language, employ 
> consistent and more up to date terminology throughout and renumber the 
> sections after removing section numbers that were no longer being utilized. 
> The changes resulting from this review were captured in ARIN-edit-2020-9, 
> proposed in September 2020.
> 
> The portions of ARIN-edit-2020-9 relating to Sections 8.3 and 8.4 of the NRPM 
> are presented in this editorial change for community consideration. The 
> remaining portions will be presented separately.
> 
> Policy Statement:
> 
> In Section 8.3.:
> 
> Under "Conditions on source of the transfer," replace "The source entity must 
> not have received a transfer, allocation, or assignment of IPv4 number 
> resources from ARIN for the 12 months prior to the approval of a transfer 
> request. Number resources received as the result of an 8.2 transfer are out 
> of scope for the purposes of this restriction." with "Excluding section 8.2 
> transfers, the source entity must not have received a transfer, allocation, 
> or assignment of IPv4 number resources from ARIN during the 12 months prior 
> to the approval of a transfer request."
> 
> In Section 8.4.:
> 
> Under "Conditions on source of the transfer," replace "Number resources 
> received as the result of an 8.2 transfer are out of scope for the purposes 
> of this restriction" with "This restriction does not include 8.2 transfers."
> 
> Timetable for Implementation: Immediate
> 
> 
> 
> 
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net 
> <mailto:ARIN-PPML@arin.net>).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml 
> <https://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact i...@arin.net <mailto:i...@arin.net> if you experience any 
> issues.

Brian Jones
bjo...@vt.edu





signature.asc
Description: Message signed with OpenPGP
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised - Editorial Change ARIN-edit-2020-9: Section 8 Editorial Clean-up

[Brian Jones]

+1 Bill’s suggested edits below.


> On Jul 28, 2021, at 3:43 PM, William Herrin  wrote:
> 
> On Tue, Jul 27, 2021 at 9:56 AM ARIN  wrote:
>> In Section 8.3.:
>> 
>> Under “Conditions on source of the transfer,” replace “Number resources 
>> received as the result of an 8.2 transfer are out of scope for the purposes 
>> of this restriction” with “This restriction does not include 8.2 transfers.”
> 
> Howdy,
> 
> They both seem about the same to me. The replacement is less clumsy
> than the original but still clumsy. Just throwing out some
> wordsmithing here:
> 
> Current;
> 
> The source entity must not have received a transfer, allocation, or
> assignment of IPv4 number resources from ARIN for the 12 months prior
> to the approval of a transfer request. Number resources received as
> the result of an 8.2 transfer are out of scope for the purposes of
> this restriction.
> 
> Suggested:
> 
> Excluding section 8.2 transfers, the source entity must not have
> received a transfer, allocation, or assignment of IPv4 number
> resources from ARIN during the 12 months prior to the approval of a
> transfer request.
> 
> That seems to me to flow better.
> 
> Regards,
> Bill Herrin
> 
> 
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.

Brian Jones
bjo...@vt.edu





signature.asc
Description: Message signed with OpenPGP
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised and Retitled - Draft Policy ARIN-2021-6: Permit IPv4 Leased Addresses for Purposes of Determining Utilization for Future Allocations

[Brian Jones]

> On Mar 11, 2022, at 1:25 PM, Mike Burns  wrote:
> 
> Are you saying that because investors could buy more addresses (through 
> demonstrating to ARIN utilization on operating networks) that would raise 
> IPv4 purchase prices? Because they would add demand to the transfer market?
> 

I’m saying that IMO getting addresses from ARIN for the sole purpose of leasing 
them to an entity that would qualify on their own for Addresses from ARIN, Does 
not  meet requirements of building and operating networks.



signature.asc
Description: Message signed with OpenPGP
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised and Retitled - Draft Policy ARIN-2021-6: Permit IPv4 Leased Addresses for Purposes of Determining Utilization for Future Allocations

[Brian Jones]

Mike,
IMHO Allowing for rent-seeking behavior increases the cost to those who are 
actually building and operating networks, therefore further limiting the 
availability of Internet number resources available for those with less funds 
to purchase them.

—
Brian


> On Mar 11, 2022, at 10:09 AM, Mike Burns  wrote:
> 
> 
> This policy removes the circuit requirement but retains the requirement that 
> blocks be used on operating networks.
> This policy only affects transferred (read “purchased”) addresses and I don’t 
> see  how it affects fair and impartial distribution, can you elucidate the 
> manner in which fair and impartial distributions are affected by removing the 
> circuit requirement?
> 
> I don’t think the proposal would have been approved for discussion if it 
> opposed fair and impartial distribution.

The original proposal had wording to include the stipulation that Internet 
numbers were to be used by those building and operating networks.

> 



signature.asc
Description: Message signed with OpenPGP
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised and Retitled - Draft Policy ARIN-2021-6: Permit IPv4 Leased Addresses for Purposes of Determining Utilization for Future Allocations

[Brian Jones]

Speaking for myself, I oppose this policy if this is removed: “...entities 
building and operating networks…”.

If you are not building and operating networks, what are the resources needed 
for? This policy seems to oppose the fair and impartial dissemination of 
Internet number resources for their intended purposes.

-
Brian



> On Mar 9, 2022, at 11:23 PM, ARIN  wrote:
> 
> Section 1.4 Stewardship
> 
> Replace
> 
> “The fundamental purpose of Internet number stewardship is to distribute 
> unique number resources to entities building and operating networks thereby 
> facilitating the growth and sustainability of the Internet for the benefit of 
> all.”
> 
> with
> 
> “The fundamental purpose of Internet number stewardship is to distribute 
> unique number resources to facilitate the growth and sustainability of the 
> Internet for the benefit of all.”
> 



signature.asc
Description: Message signed with OpenPGP
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Advisory Council Meeting Results - October 2023 - ARIN-2023-7

[Brian Jones]

I would also support a separate action with your suggested definition for
Org-ID as you outline below.

Brian
bjo...@vt.edu
Mobile client - excuse the typos


On Thu, Oct 26, 2023, 14:35 Owen DeLong  wrote:

> I support this course of action, but I still believe there is value in
> adding a definition (as a separate proposal) of ORG-ID.
>
> Suggest:
> An ORG-ID is a unique handle pointing to an Organization record in the
> ARIN database. All resources in the ARIN database are tied to ORG-IDs.
>
> Owen
>
>
> On Oct 26, 2023, at 11:08, Brian Jones  wrote:
>
>
>
> As a member of the NRPM working group and one of the authors that worked
> on this particular proposal, I would be in support of dropping the OrgID
> definition all together and then submitting changes to sections 4.5 and
> 6.11 Multiple Discrete Networks as editorial changes to bring them into
> compliance with the style guide preferences and match the readability of
> the remainder of the NRPM. This seems to align with feedback received at
> ARIN 52 concerning this policy. Trying to define OrgID or organization in
> the NRPM does not make a lot of sense in light of information from
> participants in ARIN 52 who pointed out there can be essentially one
> organization with multiple OrgID’s e.g. divisions/subdivisions.
>
> Fwiw
>
> Brian Jones
> Virginia Tech
> ARIN Advisory Council
> NRPM Working Group
> NomCom
>
>
>
> On Oct 25, 2023, at 11:36 AM, ARIN  wrote:
>
> ARIN-2023-7: Clarification of NRPM Sections 4.5 and 6.11 Multiple Discrete
> Networks and the addition of new Section 2.18 Organizational Identifier
> (Org ID)
>
>
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Advisory Council Meeting Results - October 2023 - ARIN-2023-7

[Brian Jones]

As a member of the NRPM working group and one of the authors that worked on 
this particular proposal, I would be in support of dropping the OrgID 
definition all together and then submitting changes to sections 4.5 and 6.11 
Multiple Discrete Networks as editorial changes to bring them into compliance 
with the style guide preferences and match the readability of the remainder of 
the NRPM. This seems to align with feedback received at ARIN 52 concerning this 
policy. Trying to define OrgID or organization in the NRPM does not make a lot 
of sense in light of information from participants in ARIN 52 who pointed out 
there can be essentially one organization with multiple OrgID’s e.g. 
divisions/subdivisions.

Fwiw

Brian Jones
Virginia Tech
ARIN Advisory Council
NRPM Working Group
NomCom



> On Oct 25, 2023, at 11:36 AM, ARIN  wrote:
> 
> ARIN-2023-7: Clarification of NRPM Sections 4.5 and 6.11 Multiple Discrete 
> Networks and the addition of new Section 2.18 Organizational Identifier (Org 
> ID)



signature.asc
Description: Message signed with OpenPGP
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Recommended Draft Policy ARIN-2023-5: Clean-up of NRPM Sections 4.3.4, 4.4, 4.10 and 6.10.1

[Brian Jones]

I support this policy as written. I believe it makes each of these sections of 
the NRPM easier to read and removes some confusing unnecessary wording that 
doesn’t belong. e.g. “Organizations receiving these micro-allocations will be 
charged under the fee schedule” and the removal of the word “block/s”.

_
Brian Jones




> On Oct 25, 2023, at 11:36 AM, ARIN  wrote:
> 
> On 20 October 2023, the ARIN Advisory Council (AC) advanced the following 
> Draft Policy to Recommended Draft Policy status:
> 
> * ARIN-2023-5: Clean-up of NRPM Sections 4.3.4, 4.4, 4.10 and 6.10.1
> 
> The text of the Recommended Draft Policy is below, and may also be found at:
> 
> https://www.arin.net/participate/policy/drafts/2023_5/ 
> <https://www.arin.net/participate/policy/drafts/2023_5/>
> 
> You are encouraged to discuss all Recommended Draft Policies on PPML prior to 
> their presentation at the next ARIN Public Policy Consultation (PPC). PPML 
> and PPC discussions are invaluable to the AC when determining community 
> consensus.
> 
> The PDP can be found at:
> 
> https://www.arin.net/participate/policy/pdp/ 
> <https://www.arin.net/participate/policy/pdp/>
> 
> Draft Policies and Proposals under discussion can be found at:
> 
> https://www.arin.net/participate/policy/drafts/ 
> <https://www.arin.net/participate/policy/drafts/>
> 
> Regards,
> 
> Eddie Diego
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
> 
> 
> 
> Recommended Draft Policy ARIN-2023-5: Clean-up of NRPM Sections 4.3.4, 4.4, 
> 4.10 and 6.10.1
> 
> Current Text (25 October 2023)
> 
> Problem Statement:
> 
> This proposal continues the work that the ARIN AC NRPM Clean-up Working Group 
> undertook to simplify the NRPM. It relates specifically to sections 4.3.4, 
> 4.4, 4.10 and 6.10.1. The focus of this proposal is to remove unnecessary 
> wording from these sections. In the case of section 4.3.4, the text of the 
> entire section is redundant, because it is clear throughout the NRPM that 
> resources can be obtained under various policies and so it is not necessary 
> for that to be stated specifically. In the case of sections 4.4 and 6.10.1, 
> the references to fee payment should be removed since the PDP does not 
> address fees. In the case of section 4.10, unnecessarily complex language can 
> be simplified.
> 
> Policy Statement:
> 
> Delete section 4.3.4 in its entirety and replace it with the heading “4.3.4 
> [Retired]”.
> 
> For section 4.4, delete the sentence: “Organizations receiving these 
> micro-allocations will be charged under the fee schedule.”
> 
> For section 4.10, replace the text “This block will be subject to a minimum 
> and maximum size allocation of /24.” with the text “A /24 will be allocated.”
> 
> For section 6.10.1, delete the sentence: “Organizations receiving these 
> micro-allocations will be charged under the fee schedule.”
> 
> Comments:
> 
> The proposed changes relating to sections 4.3.4, 4.4, 4.10 and 6.10.1 were 
> combined even though they address different topics because they are all 
> viewed as very simple changes, and ARIN Community members have expressed a 
> desire not to have too many policy proposals moving through the PDP at the 
> same time to the extent that they can be reasonably aggregated without 
> introducing undue complexity.
> 
> Timetable for Implementation: Immediate
> 
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net 
> <mailto:ARIN-PPML@arin.net>).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml 
> <https://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact i...@arin.net <mailto:i...@arin.net> if you experience any 
> issues.



signature.asc
Description: Message signed with OpenPGP
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Draft Policy ARIN-2022-3: Remove Officer Attestation Requirement for 8.5.5

[Brian Jones]

Speaking for myself, I oppose this draft policy. In my opinion even though 
there is no legal binding to this attestation, there is a substantial 
organization awareness level that having an officer attestation brings to those 
beyond the IT or technical teams. This type of awareness helped me in efforts 
to bring our legacy resources under an RSA agreement.

Brian Jones
bjo...@vt.edu





> On Aug 24, 2022, at 3:50 PM, Matthew Wilder  wrote:
> 
> Hi PPML,
> 
> Staff and Legal review has been conducted for Draft Policy ARIN-2022-3. The 
> relevant bit for the community to consider is the legal review, which is as 
> follows:
> "No material legal issue. Removal of the officer attestation would not 
> materially impact ARIN’s ability to pursue cases of fraud."
> 
> As shepherds, we believe this directly resolves the primary concern voiced by 
> members of the community.
> 
> For the full staff and legal review, please check the following:
> https://www.arin.net/participate/policy/drafts/2022_3/#staff-and-legal-review-15-august-2022
>  
> <https://www.arin.net/participate/policy/drafts/2022_3/#staff-and-legal-review-15-august-2022>
> 
> Regards,
> Matthew Wilder
> 
> 
> 
> On Wed, Aug 3, 2022 at 12:24 PM Matthew Wilder  <mailto:matthew.wil...@telus.com>> wrote:
> Hi PPML,
> 
> I appreciate the lively discussion thus far on ARIN-2022-3, including 
> concerns around what prosecutorial powers might be lost if officer 
> attestations are no longer required. Thanks also to staff for summarizing the 
> result of the ACSP Consultation 2021.4 retiring the officer attestation 
> requirement for documentation of needs assessment.
> 
> The prevailing concern in the community around ARIN-2022-3 appears to be that 
> removing officer attestation would impede the prosecution of those conducting 
> fraud. In order to have the experts address this concern, I (along with my 
> fellow policy shepherd Joe) have requested a staff and legal review. Our hope 
> is that staff (and legal counsel in particular) might directly weigh in on 
> how important the officer attestation is.
> 
> We will make sure that relevant points are highlighted back to PPML for the 
> community to consider in further discussion of the draft policy.
> 
> Warm regards,
> 
> Matthew Wilder
> 
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.



signature.asc
Description: Message signed with OpenPGP
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Transferring Waiting List Space - Feedback Requested

[Brian Jones]

Alison,
As I stated at the ARIN50 meeting, in light of the report John Sweeting gave 
(https://www.arin.net/participate/meetings/ARIN50/materials/1020_policyimplementation.pdf)
 I would be in favor of reducing the minimum allocation size to a /24. I am not 
necessarily in favor of lowering the maximum holdings for eligibility. I would 
not favor eliminating the transfer of Waitlist blocks. I think five years 
serves the purpose for that.


Brian Jones
Virginia Tech
ARIN Advisory Council



> On Nov 14, 2022, at 4:42 PM, WOOD Alison * DAS  
> wrote:
> 
> Hello!
> 
> The Policy Experience Report Working Group has been working on the Policy 
> Experience Report from ARIN 50.  I would appreciate your feedback on the 
> following issue regarding transferring waitlist space.
> 
> The current wait list criteria is:
> 
> Must have a /20 or less in total IPv4 holdings.
> May request up to a /22.
> Removed from list if IPv4 received via 8.3/8.4 transfer.
> Received ip space is eligible for needs-based transfer after five years.
> 
> 
> The Policy Experience Working Group would like your feedback on a potential 
> policy that would restrict the transfer of IP space that has been obtained 
> from the waiting list.  In other words, any IP address space received from 
> the waiting list would be ineligible for transfer indefinitely and encouraged 
> to be returned to ARIN if not in use.  This policy would be specific to 
> transfers and not M & A’s.
> 
> The working group appreciates your feedback.
> 
> Thank you!
> 
> 
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net 
> <mailto:ARIN-PPML@arin.net>).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml 
> <https://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact i...@arin.net <mailto:i...@arin.net> if you experience any 
> issues.



signature.asc
Description: Message signed with OpenPGP
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised - Draft Policy ARIN-2022-12: ARIN-2022-12: Direct Assignment Language Update

[Brian Jones]

> On Nov 3, 2022, at 11:46 AM, ARIN  wrote:
> 
> Section 6.5.8: change “Direct Assignments from ARIN to End-user 
> Organizations” to “End-user Allocations”
> 

So the end result would be “End-user Allocations to End-user Organizations” in 
section 6.5.8?  Not sure that Header reads well. If it is just “End-user 
Allocations” then I’m in favor of all the mentioned changes for Draft Policy 
ARIN-2022-12.



Brian Jones
Virginia Tech
ARIN Advisory Council


signature.asc
Description: Message signed with OpenPGP
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised - Draft Policy ARIN-2022-8: Streamlining Section 11 Policy Language

[Brian Jones]

See inline comments.

Brian Jones
Virginia Tech
ARIN Advisory Council



> On Oct 31, 2022, at 8:09 PM, Owen DeLong via ARIN-PPML  
> wrote:
> 
> I’m not sure we’re looking to encourage greater use so much as to make the 
> policy more comprehensible.

Raising awareness that there is such a thing could increase usage.

> 
> Section 11 is rarely used these days (though it is used), but it was quite 
> frequently used in the earlier days of IP. Nonetheless, it does still get 
> used from time to time, often enough that I think it is worth keeping it on 
> the books.

I think it should stay on the books, it is a useful thing for researchers to 
have access to, whether academic or otherwise.

> 
> Certainly any institutions or individuals who have made or would make use of 
> section 11 are more than welcome to comment in this process.

I am not aware of Virginia Tech making use of this section of the policy, 
however I can easily see several scenarios where an experimental allocation 
would not only be useful but in some cases required either by contract or to 
meet grant demands.


> 
> Owen



signature.asc
Description: Message signed with OpenPGP
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

[arin-ppml] Draft Policy ARIN-2023-1: Retire 4.2.1.4 Slow Start

[Brian Jones]

The ARIN Advisory Council is still looking to receive feedback concerning the 
retirement of the Slow Start section of the NRPM 4.2.1.4. So far most of the 
comments have been supportive along with some feedback that was gathered at 
NANOG 88, also supportive. Retirement of this section of the NRPM dovetails 
into current work being done by the Advisory Council NRPM working group in 
revising and cleaning up section 4 of the NRPM that deals primarily with IPv4 
allocations. A simple ya or nay will suffice in helping us determine the pulse 
of the community.

Sincerely,
Shepherds: Brian Jones and Amy Potter


Brian Jones
ARIN Advisory Council



> On May 23, 2023, at 12:29 PM, ARIN  wrote:
> 
> On 18 May 2023, the ARIN Advisory Council (AC) accepted "ARIN-prop-319: 
> Retire 4.2.1.4. Slow Start" as a Draft Policy.
> 
> Draft Policy ARIN-2023-1 is below and can be found at:
> 
> https://www.arin.net/participate/policy/drafts/2023_1/ 
> <https://www.arin.net/participate/policy/drafts/2023_1/>
> 
> You are encouraged to discuss all Draft Policies on PPML. The AC will 
> evaluate the discussion to assess the conformance of this draft policy with 
> ARIN's Principles of Internet number resource policy as stated in the Policy 
> Development Process (PDP). Specifically, these principles are:
> 
> * Enabling Fair and Impartial Number Resource Administration
> * Technically Sound
> * Supported by the Community
> 
> The PDP can be found at:
> 
> https://www.arin.net/participate/policy/pdp/ 
> <https://www.arin.net/participate/policy/pdp/>
> 
> Draft Policies and Proposals under discussion can be found at: 
> https://www.arin.net/participate/policy/drafts/ 
> <https://www.arin.net/participate/policy/drafts/>
> 
> Regards,
> 
> Eddie Diego
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
> 
> 
> Draft Policy ARIN-2023-1: Retire 4.2.1.4. Slow Start
> 
> Problem Statement:
> 
> Section 4.2.1.4 Slow Start has been a part of the NRPM for two decades, and 
> successfully served to constrain the rate at which ARIN issued IPv4 address 
> allocations to its members for many years. Following the exhaustion of the 
> free pool, as well as the introduction and refinement of transfer policies, 
> Slow Start has ceased to be applicable to the operations of ARIN's 
> registration services. Staff has confirmed that this policy has not been used 
> since 2018.
> 
> Policy statement:
> 
> Retire 4.2.1.4 Slow Start
> 
> Timetable for implementation: Immediate
> 
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net 
> <mailto:ARIN-PPML@arin.net>).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml 
> <https://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact i...@arin.net <mailto:i...@arin.net> if you experience any 
> issues.



signature.asc
Description: Message signed with OpenPGP
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Sections 6.5.1.a and 6.5.1.b - More section 6 Potential simplifications from the NRPM Working Group

[Brian Jones]

Thank you for your feedback Dale. We are still gathering data at this point and 
I appreciate the mention of RFCs as I had not really considered that angle.


Brian Jones
ARIN Advisory Council (NRPM Working Group)



> On Dec 5, 2023, at 5:10 PM, Dale W. Carder  wrote:
> 
> Thus spake Brian Jones (bjo...@vt.edu) on Tue, Dec 05, 2023 at 02:28:18PM 
> -0500:
>> 
>> Section 6.5.1.a  “Terminology” explains that ISP and LIR terms are used 
>> interchangeably throughout the entire document. The NRPM working group in 
>> discussions with ARIN staff has concluded that the term LIR could be 
>> replaced everywhere in the NRPM with the term ISP. By my counts the term LIR 
>> appears 37 times in the NRPM currently, while ISP is referenced 62 times. 
>> The LIR term is utilized less nowadays than in times past and ISP is a more 
>> widely used and well understood term. The LIR term occurs more frequently in 
>> other RIRs and it is likely that if section 6 were written solely for ARIN 
>> the ISP term would have been used. So the question to the community is, 
>> would replacing the term LIR with ISP make the NRPM more consistent and 
>> readable? The NRPM working group would like to hear your feedback.
> 
> I think that would be a step in the wrong direction.  To me, the term
> ISP seems to carry a strong commercial connotation that excludes the
> existence of LIR entities that include governments, academic
> institutions, non-profits, large scale enterprises, or even cloud or
> content providers.
> 
> Of course, I have some bias coming from a network that is very much not
> an isp... ;-)
> 
> The term LIR is used at other RIR's as you mention, as well as in a
> number of RFC's since the mid 90's.  Why should we diverge?
> 
> I think you could delete 6.5.1.a and clarify in section 2 that LIR and
> ISP may be used interchangably in the document, but personally I would
> prefer use of the term ISP be cleaned up, not LIR.
> 
>> Part b
>> Section 6.5.1.b defines the IPv6 nibble boundaries . The working group feels 
>> like this definition would be a better fit if moved to section 2 of the NRPM 
>> which is the Definitions section. Your thoughts about moving the IPv6 nibble 
>> boundaries definition from section 6.5.1.b to section 2 would be appreciated.
> 
> Sounds perfectly reasonable.
> 
> Dale



signature.asc
Description: Message signed with OpenPGP
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Sections 6.5.1.a and 6.5.1.b - More section 6 Potential simplifications from the NRPM Working Group

[Brian Jones]

Thank you for the input Martin. Do you feel strongly about changing from LIR to 
ISP, or would you be okay either way as long as the definition is clear that 
they are interchangeable? Thank you again for the feedback and discussion 
points, they are very much appreciated.


Brian Jones
ARIN Advisory Council (NRPM Working Group)



> On Dec 5, 2023, at 8:53 PM, Martin Hannigan  wrote:
> 
> 
> 
> On Tue, Dec 5, 2023 at 18:11 John Santos mailto:j...@egh.com>> 
> wrote:
> I agree with Dale (I think). ISPs do a lot more than just register Internet
> addresses, but their interaction with ARIN and the NRPM is under their 
> function
> as an Internet Registry (allocating and registering addresses for their
> customers), so they are a special case of LIR.  If the term LIR is used most
> commonly by other regions and their definition of LIR is similar to ARIN's, 
> then
> I think "LIR" should be used in the NRPM, even if it requires more 
> single-point
> changes.
> 
> ISPs assign “to” their customers, but semantics.
> 
> 
> If everyone agrees that the terms ISP and LIR, as used in the NRPM, are
> equivalent, then substituting one for the other is a purely editorial change,
> not a policy change.
> 
> Staff or engineering also seems to equate LIR with ISP and vice versa. It’s 
> noted on the web tool when requesting v4 or v6 resources as “LIR/ISP”
> 
> In order for it not to be perceived as a policy change ISP seems to be the 
> right term. On a per ARIN region per ASN basis (individual network vs. 
> address holdings volume implying international) I believe most network 
> operators in North America don’t use the LIR acronym at all. If it wasn’t a 
> cultural change I’d agree with you re: the terms being the same. However, 
> it’s more confusing to redact ISP than LIR. When examining section 10, there 
> are  also no conflicts since neither term is used. Other than global policy, 
> I don’t think it’s terrible necessary to be “similar” to the other regions. 
> This particular issue doesn’t seem that important.
> 
> I’m +1 removing LIR.
> 
> Warm regards,
> 
> -M<
> 
> 
> 
> 
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.



signature.asc
Description: Message signed with OpenPGP
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Sections 6.5.1.a and 6.5.1.b - More section 6 Potential simplifications from the NRPM Working Group

[Brian Jones]

Thank you for the feedback Owen. It seems you have a strong leaning toward the 
LIR term over the term ISP, would you care to tell me more about why you feel 
the term LIR is the better choice? Thank you agin for the valuable input and 
feedback. It is greatly appreciated by myself and the NRPM working group.


Brian Jones
ARIN Advisory Council (NRPM Working Group)



> On Dec 9, 2023, at 5:10 AM, Owen DeLong  wrote:
> 
> This is a step in the wrong direction… If you’re going to unify the 
> terminology, ISP->LIR would be the better choice.



signature.asc
Description: Message signed with OpenPGP
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Sections 6.5.1.a and 6.5.1.b - More section 6 Potential simplifications from the NRPM Working Group

[Brian Jones]

Thank you for the input John. The NRPM working group will take this under 
advisement and I appreciate the perspective that maybe this is just an 
editorial change if consensus is reached about which term to use.


Brian Jones
ARIN Advisory Council (NRPM Working Group)



> On Dec 5, 2023, at 6:10 PM, John Santos  wrote:
> 
> I agree with Dale (I think). ISPs do a lot more than just register Internet 
> addresses, but their interaction with ARIN and the NRPM is under their 
> function as an Internet Registry (allocating and registering addresses for 
> their customers), so they are a special case of LIR.  If the term LIR is used 
> most commonly by other regions and their definition of LIR is similar to 
> ARIN's, then I think "LIR" should be used in the NRPM, even if it requires 
> more single-point changes.
> 
> If everyone agrees that the terms ISP and LIR, as used in the NRPM, are 
> equivalent, then substituting one for the other is a purely editorial change, 
> not a policy change.
> 
> If we want to make clear in the policy that ISPs and LIRs are the same, this
> should be explicitly stated in the definitions section at the beginning.  
> Both acronyms should be defined, and the statement should be made their that 
> their policy implications are identical and thereafter only one of the terms 
> will be used in the rest of the NRPM.
> 
> If, some time in the future, we develop a policy that distinguishes LIRs from 
> ISPs, a future policy revision could state that some particular aspects of 
> the new policy apply only to LIRs and not ISPs or vice versa, although there 
> appear to be no such policies at the current time.  Making the editorial 
> change to use only the term ISP or LIR now would make any such future change 
> much easier to understand and implement.
> 
> 
> On 12/5/2023 5:10 PM, Dale W. Carder wrote:
>> Thus spake Brian Jones (bjo...@vt.edu) on Tue, Dec 05, 2023 at 02:28:18PM 
>> -0500:
>>> 
>>> Section 6.5.1.a  “Terminology” explains that ISP and LIR terms are used 
>>> interchangeably throughout the entire document. The NRPM working group in 
>>> discussions with ARIN staff has concluded that the term LIR could be 
>>> replaced everywhere in the NRPM with the term ISP. By my counts the term 
>>> LIR appears 37 times in the NRPM currently, while ISP is referenced 62 
>>> times. The LIR term is utilized less nowadays than in times past and ISP is 
>>> a more widely used and well understood term. The LIR term occurs more 
>>> frequently in other RIRs and it is likely that if section 6 were written 
>>> solely for ARIN the ISP term would have been used. So the question to the 
>>> community is, would replacing the term LIR with ISP make the NRPM more 
>>> consistent and readable? The NRPM working group would like to hear your 
>>> feedback.
>> I think that would be a step in the wrong direction.  To me, the term
>> ISP seems to carry a strong commercial connotation that excludes the
>> existence of LIR entities that include governments, academic
>> institutions, non-profits, large scale enterprises, or even cloud or
>> content providers.
>> Of course, I have some bias coming from a network that is very much not
>> an isp... ;-)
>> The term LIR is used at other RIR's as you mention, as well as in a
>> number of RFC's since the mid 90's.  Why should we diverge?
>> I think you could delete 6.5.1.a and clarify in section 2 that LIR and
>> ISP may be used interchangably in the document, but personally I would
>> prefer use of the term ISP be cleaned up, not LIR.
>>> Part b
>>> Section 6.5.1.b defines the IPv6 nibble boundaries . The working group 
>>> feels like this definition would be a better fit if moved to section 2 of 
>>> the NRPM which is the Definitions section. Your thoughts about moving the 
>>> IPv6 nibble boundaries definition from section 6.5.1.b to section 2 would 
>>> be appreciated.
>> Sounds perfectly reasonable.
>> Dale
>> ___
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@arin.net if you experience any issues.
> 
> --
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsu

Re: [arin-ppml] Sections 6.5.1.a and 6.5.1.b - More section 6 Potential simplifications from the NRPM Working Group

[Brian Jones]

Very good. Thank you Owen for detailing your explanation. This is very helpful.


Brian Jones
ARIN Advisory Council (NRPM Working Group)




> On Dec 12, 2023, at 2:18 PM, o...@delong.com  wrote:
> 
> ISP is a very ambiguous term which carries a lot of different connotations to 
> different people, most of which don’t describe the full range of ARIN member 
> LIRs.
> 
> LIRs include cloud providers, CDNs, certain government entities, colocation 
> facilities, “eyeball” providers, backbone providers, tunnel/vpn service 
> providers, SDWAN providers, SAAS providers, etc.
> 
> Sure, most of those could be called an ISP under some definition of the term, 
> but would be excluded from the term in many other people’s minds. Best to 
> avoid the quagmire of ambiguity and talk in terms of what ARIN is actually 
> concerned about, which is the local registration of addresses to other 
> entities (whether internal, external, or both). As such, yes, I have a strong 
> belief that LIR is a term better suited to ARIN policy as it is both more 
> descriptive of the bodies being described and more relatable to the policy 
> intent.
> 
> Owen
> 
> 
>> On Dec 12, 2023, at 11:05, Brian Jones  wrote:
>> 
>> Thank you for the feedback Owen. It seems you have a strong leaning toward 
>> the LIR term over the term ISP, would you care to tell me more about why you 
>> feel the term LIR is the better choice? Thank you agin for the valuable 
>> input and feedback. It is greatly appreciated by myself and the NRPM working 
>> group.
>> 
>> 
>> Brian Jones
>> ARIN Advisory Council (NRPM Working Group)
>> 
>> 
>> 
>>> On Dec 9, 2023, at 5:10 AM, Owen DeLong >> <mailto:o...@delong.com>> wrote:
>>> 
>>> This is a step in the wrong direction… If you’re going to unify the 
>>> terminology, ISP->LIR would be the better choice.
>> 
> 



signature.asc
Description: Message signed with OpenPGP
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

[arin-ppml] Sections 6.5.1.a and 6.5.1.b - More section 6 Potential simplifications from the NRPM Working Group

[Brian Jones]

Part a
In a continuation of the NRPM Working Group's efforts to bring potential 
clarifications to the NRPM, this is another email in the series of Section 6 
potential changes we would like to raise awareness of and gather feedback about 
from the ARIN community.

Section 6.5.1.a  “Terminology” explains that ISP and LIR terms are used 
interchangeably throughout the entire document. The NRPM working group in 
discussions with ARIN staff has concluded that the term LIR could be replaced 
everywhere in the NRPM with the term ISP. By my counts the term LIR appears 37 
times in the NRPM currently, while ISP is referenced 62 times. The LIR term is 
utilized less nowadays than in times past and ISP is a more widely used and 
well understood term. The LIR term occurs more frequently in other RIRs and it 
is likely that if section 6 were written solely for ARIN the ISP term would 
have been used. So the question to the community is, would replacing the term 
LIR with ISP make the NRPM more consistent and readable? The NRPM working group 
would like to hear your feedback.

Part b
Section 6.5.1.b defines the IPv6 nibble boundaries . The working group feels 
like this definition would be a better fit if moved to section 2 of the NRPM 
which is the Definitions section. Your thoughts about moving the IPv6 nibble 
boundaries definition from section 6.5.1.b to section 2 would be appreciated.

_
Brian Jones
NRPM Working Group


signature.asc
Description: Message signed with OpenPGP
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Recommended Draft Policy ARIN-2023-1: Retire 4.2.1.4. Slow Start

[Brian Jones]

Thank you. As one of the shepherds on this now Recommended Draft Policy the 
feedback on retiring this section of the NRPM is appreciated.

Brian Jones
ARIN Advisory Council



> On Nov 28, 2023, at 1:34 PM, Dale W. Carder  wrote:
> 
> Thus spake ARIN (i...@arin.net) on Tue, Nov 21, 2023 at 12:34:39PM -0500:
>> On 16 November 2023, the ARIN Advisory Council (AC) advanced the following 
>> Draft Policy to Recommended Draft Policy status:
>> 
>> * ARIN-2023-1: Retire 4.2.1.4. Slow Start
>> 
>> The text of the Recommended Draft Policy is below, and may also be found at:
>> 
>> https://www.arin.net/participate/policy/drafts/2023_1/
> 
> Sounds perfectly reasonable as written.
> 
> Dale
> ___
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.



signature.asc
Description: Message signed with OpenPGP
___
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.