<HTML><HEAD></HEAD>
<BODY dir=ltr>
<DIV dir=ltr>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'; COLOR: #000000">
<DIV>
<DIV
style='FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: "Calibri"; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; DISPLAY: inline'>Hi
Jason,</DIV></DIV>
<DIV>
<DIV
style='FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: "Calibri"; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; DISPLAY: inline'></DIV>
<DIV dir=ltr>
<DIV>You wrote:</DIV>
<DIV>I think there are issues with the status quo. </DIV>
<DIV>How to deal with slow start</DIV>
<DIV> - can't assume the upstream can or will provide addresses</DIV>
<DIV> </DIV>
<DIV><STRONG>This is a tremendous problem, which your proposal solves, but it is
also solved with 2014-14 with more brevity.</STRONG></DIV>
<DIV><STRONG></STRONG> </DIV>
<DIV> </DIV>
<DIV>How to reduce the burden of multiple transfers </DIV>
<DIV> - multiple transfers are much more time intensive than multiple ARIN
allocations / assignments</DIV>
<DIV> - there is a higher per transaction overhead cost</DIV>
<DIV> </DIV>
<DIV><STRONG>Where is the evidence that multiple transfers are more time
intensive than multiple ARIN allocations?</STRONG></DIV>
<DIV><STRONG>In my experience, there is only the single additional invoice for
$500 per transfer that is different. </STRONG></DIV>
<DIV><STRONG>If you are going to say that finding the supplier of transfers is
more difficult, you would have a point, but that point eviscerates the fear of
market speculation should 2014-14 be implemented, see more below.</STRONG></DIV>
<DIV> </DIV>
<DIV>How to reduce the problems of over issuing </DIV>
<DIV> - reclaiming is problematic in the transfer space, how do you deal
with the exchange of money.</DIV>
<DIV> - what was the price when the deal was inked, what is the price now,
who is responsible for the difference?</DIV>
<DIV> </DIV>
<DIV><STRONG>What problem of over-issuing? Reclaiming does not really
happen, but reselling certainly does. And reselling in a needs-free environment
is easier than in a needs-tested environment. Once again 2014-14 facilitates the
easy resale of un-needed addresses (less than a /16 anyway). </STRONG></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>These reasons are the essential differences between transfer space and ARIN
space.</DIV>
<DIV> </DIV>
<DIV><STRONG>You are ignoring the true essential difference. Transfer space
costs money. Real money that businesses need to justify to their
accountants/owners/shareholders. This imposes a conservative force absent from
ARIN space.</STRONG></DIV>
<DIV> </DIV>
<DIV>I do not believe there is a need to separate justified need for transfer
policy and justified need for ARIN issued resources. I feel that the
community is pushing to have them separated. </DIV>
<DIV><STRONG>You clearly understand that the current needs-testing of transfers
imposes many problems which you have identified. I have offered an alternative
that solves those problems. What are the problems with 2014-14 that make 2014-20
more appealing to you?</STRONG></DIV>
<DIV> </DIV>
<DIV>I also think the community recognizes there are issues with the transfer
policy (most clearly how does slow start work), and are more willing to accept
changes. I think the community has less of a willingness to change
justified need wrt ARIN issued resources, partly on the grounds that changing it
now feels unfair, like changing the rules of the game when we are all so close
to the finish line, especially when organizations have may plans within the time
horizon that these rules do not change.</DIV>
<DIV> </DIV>
<DIV><STRONG>Is not 2014-20 also a change to the rules?</STRONG> </DIV>
<DIV> </DIV>
<DIV>In short it less controversial to make changes to needs justification of
transfers than of ARIN issued space.</DIV>
<DIV> </DIV>
<DIV><STRONG>Agreed. That controversy is what I seek to address. Is there
anybody who cares to make an argument against 2014-14? Even some die-hard
needs-test advocates have supported the removal of needs testing for small(er)
transfers, does this reduce the controversy? I have yet to hear a reasonable
scenario which allows for effective market manipulation to take place should
2014-14 pass and be implemented. The idea that organizations will be
spun-up invisibly to ARIN, and that these organizations would provide real
individuals who would attest to the accuracy of the request, and that ARIN
policymakers would be unable to change policy in the event of such an attempt
before harm could come to the market is just unbelievable to me. Add to that the
fragmentation of the supply market and the whole idea is
untenable.</STRONG></DIV>
<DIV><STRONG></STRONG> </DIV>
<DIV><STRONG>Regards,</STRONG></DIV>
<DIV><STRONG>Mike</STRONG></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>___Jason</DIV>
<DIV> </DIV>
<DIV> </DIV></DIV>
<DIV class=gmail_extra>
<DIV> </DIV>
<DIV class=gmail_quote>On Mon, Sep 15, 2014 at 4:07 PM, Mike Burns <SPAN
dir=ltr><<A href="mailto:mike@iptrading.com"
target=_blank>mike@iptrading.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV dir=ltr>
<DIV dir=ltr>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'; COLOR: #000000">
<DIV>
<DIV
style='FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: "Calibri"; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; DISPLAY: inline'>Scott
wrote:</DIV></DIV>
<DIV
style='FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: "Calibri"; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; DISPLAY: inline'>
<DIV dir=ltr><SPAN>It seems to me that this proposal actually simplifies
things a lot more than it appears at first glance. Obviously it expands
section 8 with a lot more words. But it does so in order to almost
completely remove the dependencies on section 4 (leaving just a reference to
the minimum allocation size). So once the ARIN free pool is exhausted,
that will mean that the policy under which most people get IPv4 space will be
dramatically simpler than it is today. It will also open up the way to
dramatically simplifying section 4 after free pool exhaustion.
<DIV><BR>I haven't yet worked through all the situations I can think of to
make sure this is better than current policy in all cases, but on first pass
it appears to me to be a significant improvement on the status quo.</DIV>
<DIV> </DIV>
<DIV>-Scott</DIV>
<DIV> </DIV>
<DIV> </DIV></SPAN>
<DIV>Hi Scott and Jason,</DIV>
<DIV> </DIV>
<DIV>Maybe it would help to understand WHY there is a need to separate the
needs policy for transfers before we endeavor to create an all-new and
separate policy.</DIV>
<DIV>What is it about transfers that changes justifiable need of
recipients?</DIV>
<DIV>Is there any difference between free-pool and transferred
addresses?</DIV>
<DIV>Is it the $500 transfer fee?</DIV>
<DIV>Why do you support dramatically simplifying the needs test policy
now?</DIV>
<DIV> </DIV>
<DIV>My understanding is that we chose to utilized the existing needs regime
for transfers, but extended the horizon from 3 to 24 months for the purposes
of providing some incentive to get the STLS system operational. Or was it some
other reason?</DIV>
<DIV>If there is some qualitative difference between transfers and free pool
allocations, why is there an RFC2050 principle requiring needs tests for
transfers as well as free pool allocations?</DIV>
<DIV> </DIV>
<DIV>My answers to these questions have been offered, and I believe they are
consistent with the thought processes at the time of RIR creation:</DIV>
<DIV>“We are responsible for growing the Internet through dissemination of IP
addresses.</DIV>
<DIV>We want to give addresses out, we want to grow the Internet, but we can’t
just allow anybody to take all the addresses.”</DIV>
<DIV>So, RFC2050 required needs testing of allocations to prevent plunder of
the free pool.</DIV>
<DIV>RFC2050 also required needs tests for transfers, because without them,
there would be plunder of the free pool.</DIV>
<DIV> </DIV>
<DIV>But conservation is a natural mechanism of a market, and the price of
transferred IPv4 addresses imposes a natural conserving force absent from the
RFC2050 environment.</DIV>
<DIV>That is why there is in fact a qualitative difference between free pool
and transfer addresses. The one has no natural conservation force and requires
the needs test. The other has a natural conservative force which does not
require the needs test.</DIV>
<DIV> </DIV>
<DIV>That is my rationale for 2014-14, which removes needs tests from small
transfers. It has the benefit of addressing all the scenarios addressed by
2014-20, and does so in a more streamlined fashion.</DIV>
<DIV> </DIV>
<DIV>TL’DR:</DIV>
<DIV>What is the rationale behind 2014-20’s call for a different needs test
for transfers versus free pool allocations?</DIV>
<DIV>Didn’t we have small, medium, large, slow growing, fast growing, and
every other business scenario in the past?</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Mike</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV></DIV>
<DIV>
<DIV class=h5>
<DIV class=gmail_extra>
<DIV> </DIV>
<DIV class=gmail_quote>On Sat, Sep 13, 2014 at 5:34 AM, Mike Burns <SPAN
dir=ltr><<A href="mailto:mike@iptrading.com"
target=_blank>mike@iptrading.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><U></U>
<DIV bgcolor="#ffffff">
<DIV><FONT face=Arial>Hi Jason,</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; PADDING-RIGHT: 0px; MARGIN-RIGHT: 0px"
dir=ltr>
<DIV style="FONT: 10pt arial"><BR> </DIV>
<DIV dir=ltr><SPAN>
<DIV>However, assuming that 2014-14 is discussed first and does not pass,
would you still oppose 2014-20?</DIV>
<DIV> </DIV></SPAN>
<DIV><FONT face=Arial>Possibly. </FONT></DIV><SPAN>
<DIV><FONT face=Arial></FONT><BR> </DIV>
<DIV>Would you agree that 2014-20 a movement in the direction as it is in
the middle ground between current needs based and transfers without
need?</DIV>
<DIV> </DIV></SPAN>
<DIV><FONT face=Arial>It seems like you are removing the 24month
distinction between transfers and free pool allocations and replacing it
with a more complex, although possibly more expansive mechanism. I would
have to consider more analysis of the various scenarios and balance my
support against my opposition to NRPM bloat and transfer policy
complexity.</FONT></DIV><SPAN>
<DIV> </DIV>
<DIV>Would you agree that while 2014-20, in your opinion does not go far
enough, it is still better than the status quo?</DIV>
<DIV> </DIV></SPAN>
<DIV><FONT face=Arial>Well the status quo has changed, with minimums
reduced to /24, and I have not had time to analyze sufficiently. One of
the real problems I had encountered with transfers was related to the /20
minimum and I have not had problems with transfers due to explosive
growth. Unfortunately!</FONT></DIV><SPAN>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV> </DIV>
<DIV>2014-20 does in fact separate the needs test for transfers from the
needs test for ARIN allocations and assignments.</DIV>
<DIV>WRT transfers, at any time, an org that can demonstrate 80%
utilization on average across all their IP space, is eligible to completed
1 or more transfer and up to double their holdings. This is very
different from demonstrating 80% utilization of your most recent block,
and efficiently using all your older IP space, and only getting double
what you used in the last 12 months.</DIV>
<DIV> </DIV>
<DIV>This however does not help orgs with no resources 2*0=0, nor does it
help orgs that have a history of slow growth with recent rapid
growth.</DIV>
<DIV> </DIV>
<DIV>To help orgs that have no resources, I wanted to make it fairly easy
for them to get what ever the minimum assignment/allocation is (the only
tie back to ARIN issued IP space) up to a /24 for end-sites and up to a
/21 for ISPs. I wanted at the same time to disqualify orgs that have
no actual plan on having stuff to number. Once they get their
initial space that can use it to 80% and then double, us that to 80%, and
double again, and so on.</DIV>
<DIV> </DIV>
<DIV>For orgs with only recent rapid growth, and for new orgs who don't
want to keep doubling, they can choose a look back window between 3 and 12
months, and calculate a two year supply.</DIV>
<DIV> </DIV>
<DIV>So a new org may transfer in a /24, show 80% utilization after 45
days, transfer in an additional /24, show 80% utilization of both blocks
after 90 days, and then qualify to transfer in up to the <SPAN
style="FONT-SIZE: 12px; FONT-FAMILY: arial,helvetica,sans-serif; COLOR: rgb(0,0,0); LINE-HEIGHT: 18px">equivalent</SPAN>
of 16 * /24s.</DIV>
<DIV> </DIV>
<DIV>__Jason</DIV>
<DIV> </DIV>
<DIV> </DIV></SPAN>
<DIV><FONT face=Arial>It sounds better to me than the current system, but
I definitely prefer 2014-14. My concern is that whenever verbiage is added
to the NRPM it opens new doors to misinterpretation which have to be
addressed through more verbiage. In addition, whenever new issues or
problems are discovered when applying this new mechanism to different
business-case scenarios, more verbiage would be necessary to restore
"fairness". And considering the myriad ways that businesses can find
themselves in need of IPv4 space I think we are taking the first steps
down a dangerous path with your proposal. On the other hand 2014-14
addresses the needs of fast and slow growing companies, and the needs of
small companies, with less of this danger and less risk of out-of-policy
transfers which hold their own separate dangers. </FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>Regards,</FONT></DIV>
<DIV><FONT face=Arial>Mike</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV></DIV>
<DIV> </DIV>
<DIV></DIV>
<DIV>
<DIV> </DIV>
<DIV> </DIV></DIV></DIV>
<DIV>
<DIV>
<DIV class=gmail_extra>
<DIV> </DIV>
<DIV class=gmail_quote>On Fri, Sep 12, 2014 at 1:19 PM, Mike Burns <SPAN
dir=ltr><<A href="mailto:mike@iptrading.com"
target=_blank>mike@iptrading.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV dir=ltr>
<DIV dir=ltr>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'; COLOR: #000000">
<DIV>Hi Jason,</DIV>
<DIV> </DIV>
<DIV>I apologize for not commenting on this earlier, I decided to sit
back and see what other input was received.</DIV>
<DIV> </DIV>
<DIV>I think that you have correctly identified in your problem
statement certain issues we face at the near-exhaust stage and
beyond.</DIV>
<DIV>ARIN allocation policy was always premised on the free pool, and we
have decided to borrow the same policy and apply it to the wholly new
environment of a trading market.</DIV>
<DIV
style="FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: 'Calibri'; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; DISPLAY: inline">
<DIV style="FONT: 10pt tahoma">
<DIV><FONT size=3 face=Calibri>You correctly identify issues like
transactional costs which are imposed on recipients as a result of
free-pool premised policies whose authors did not consider these
implications.</FONT></DIV>
<DIV><FONT size=3 face=Calibri>You note that ARIN policy does not
efficiently accommodate various recipient growth profiles, especially as
any wiggle-room is squeezed out of every allocation by a team of ARIN
reviewers.</FONT></DIV>
<DIV><FONT size=3 face=Calibri></FONT> </DIV>
<DIV><FONT size=3 face=Calibri>We can expect more such problems as
market forces tend to diverge from ARIN policy prescriptions, and it is
my belief that the weight of these distortions puts a strain on Whois
accuracy as more money flows into this market. When business needs
are faced-up against ARIN policy, at a certain point the business risk
of inadequate allocation overrides the risk of an out-of-policy
transfer. And these out-of-policy transfers can happen by multiple
means, including phased-contracts, permanent leasing, and zombie
corporations which ARIN policy can’t touch. ARIN policy is a market
distortion which will likely grow larger over time.</FONT></DIV>
<DIV><FONT size=3 face=Calibri></FONT> </DIV>
<DIV><FONT size=3 face=Calibri>Rather than try to put our finger in the
dyke through more and more NRPM verbiage, isn’t it time we acknowledged
that a separate allocation paradigm exists in the trading market which
requires a separate (or absent) needs-test for transfers? </FONT></DIV>
<DIV><FONT size=3 face=Calibri></FONT> </DIV>
<DIV><FONT size=3 face=Calibri>I believe that every circumstance
elucidated in your proposal is answered by the much more streamlined
2014-14, which removes needs testing from transfers smaller than a /16,
once per year. </FONT></DIV>
<DIV><FONT size=3 face=Calibri></FONT> </DIV>
<DIV><FONT size=3 face=Calibri>I am against further un-necessary clutter
in the NRPM, and if we seek to match every unknown and unknowable vagary
of the impending transfer market with new policy, we open the door to a
virtual tax code of text. Here is one of your new
sections:</FONT></DIV><SPAN>
<DIV><FONT size=3 face=Calibri></FONT> </DIV><FONT
face=Arial><SPAN><FONT style="FONT-SIZE: 6pt">8.3.2.3.2.1 Calculation of
Monthly Average Use Rate</FONT></SPAN><FONT style="FONT-SIZE: 6pt"><BR
style="WHITE-SPACE: normal; WORD-SPACING: 0px; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); FONT: 12px/18px arial,helvetica,sans-serif; LETTER-SPACING: normal; BACKGROUND-COLOR: rgb(255,255,255); TEXT-INDENT: 0px"></FONT><SPAN><FONT
style="FONT-SIZE: 6pt">An organization may choose a look-back window of
any number of months between 3 and 12, inclusive, from the date of the
current request. ARIN will calculate the total amount of new addresses
acquired, during the look-back window, by the organization from
non-M&A transfers, direct allocations or assignments from ARIN, or
reallocations or reassignments from an ISP. That total will be divided
by the number of months in the look-back window to calculate the
organization’s monthly average use rate.</FONT></SPAN></FONT>
<DIV><FONT size=3 face=Calibri></FONT> </DIV></SPAN>
<DIV><FONT size=3 face=Calibri>8.3.2.3.2.1?</FONT></DIV>
<DIV><FONT size=3 face=Calibri></FONT> </DIV>
<DIV><FONT size=3 face=Calibri>While I support the recognition of the
problems Jason identified, I am opposed to 2014-20. </FONT></DIV>
<DIV><FONT size=3 face=Calibri>(Also I would counsel against regarding
silence as approval.)</FONT></DIV>
<DIV><FONT size=3 face=Calibri></FONT> </DIV>
<DIV><FONT size=3 face=Calibri>Regards</FONT></DIV>
<DIV><FONT size=3 face=Calibri></FONT> </DIV>
<DIV><FONT size=3 face=Calibri>Mike Burns</FONT></DIV>
<DIV><FONT size=3 face=Calibri></FONT> </DIV>
<DIV><FONT size=3 face=Calibri></FONT> </DIV>
<DIV style="BACKGROUND: #f5f5f5">
<DIV><B>From:</B> <A title=jschiller@google.com
href="mailto:jschiller@google.com" target=_blank>Jason Schiller</A>
</DIV>
<DIV><B>Sent:</B> Friday, September 12, 2014 12:13 PM</DIV>
<DIV><B>To:</B> <A title=owens@nysernet.org
href="mailto:owens@nysernet.org" target=_blank>owens@nysernet.org</A> ;
<A title=kevinb@thewire.ca href="mailto:kevinb@thewire.ca"
target=_blank>Kevin Blumberg</A> ; <A title=farmer@umn.edu
href="mailto:farmer@umn.edu" target=_blank>David Farmer</A> </DIV>
<DIV><B>Cc:</B> <A title=arin-ppml@arin.net
href="mailto:arin-ppml@arin.net" target=_blank>arin-ppml@arin.net</A>
</DIV>
<DIV><B>Subject:</B> Re: [arin-ppml] Draft Policy ARIN-2014-20: Transfer
Policy Slow Start and Simplified Needs Verification</DIV></DIV></DIV>
<DIV> </DIV></DIV>
<DIV
style="FONT-SIZE: small; TEXT-DECORATION: none; FONT-FAMILY: 'Calibri'; FONT-WEIGHT: normal; COLOR: #000000; FONT-STYLE: normal; DISPLAY: inline">
<DIV>
<DIV>
<DIV dir=ltr>It has been a week, and there has been no discussion on
this thread.
<DIV> </DIV>
<DIV>I take the silence to mean the suggested "option 2" rewrite is
non-controversial and meets all of Bill's concerns.</DIV>
<DIV> </DIV>
<DIV>I also take the silence to mean that all three options I have
suggested all result in the same implementation, </DIV>
<DIV>and since no one believes any of the three options differ in
implementation, there is no preference.</DIV>
<DIV> </DIV>
<DIV>I humbly submit we should go with option 2, as it is closest to
Bill's suggestion, and keeps 8.2 and 8.3 in line </DIV>
<DIV>(setting the ground work for a future unification of 8.2 and
8.3).</DIV>
<DIV> </DIV>
<DIV>Will there be discussion now? Or should we just silently move
forward?</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Thanks,</DIV>
<DIV> </DIV>
<DIV>___Jason</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV></DIV>
<DIV class=gmail_extra>
<DIV> </DIV>
<DIV class=gmail_quote>On Thu, Sep 4, 2014 at 11:34 AM, Jason Schiller
<SPAN dir=ltr><<A href="mailto:jschiller@google.com"
target=_blank>jschiller@google.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV dir=ltr>Bill,
<DIV> </DIV>
<DIV>Thank you.</DIV>
<DIV> </DIV>
<DIV>The intent was NOT to remove the <SPAN
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif">requirement for
in-region recipients of transfers to sign an RSA.</SPAN></DIV>
<DIV><SPAN
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif"><BR></SPAN></DIV>
<DIV><FONT face="arial, sans-serif">My apologies. </FONT></DIV>
<DIV><SPAN
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif"><BR></SPAN></DIV>
<DIV><FONT face="arial, sans-serif">There is a lot or parallel
structure in 8.3 and 8.4 and in my mind 8.4 is identical to 8.3 except
8.4 has a clause "Except when the </FONT><SPAN
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif">recipient</SPAN><FONT
face="arial, sans-serif"> is out of region then that region's policy
applies", and " </FONT><FONT face="arial, sans-serif">Except when the
</FONT><SPAN
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif">source</SPAN><FONT
face="arial, sans-serif"> is out of region then that region's policy
applies". I really wanted to completely merge 8.3 and 8.4 to
remove the parallel structure but as an editorial re-write only and
not part of this discussion. </FONT></DIV>
<DIV><FONT face="arial, sans-serif"><BR></FONT></DIV>in 8.4 there are
a separate bullets for 24-month supply and sign the RSA:<BR>
<DIV>"> Recipients within the ARIN region will be subject to
current ARIN policies and sign an RSA for the resources being
received.<BR>> Recipients within the ARIN region must demonstrate
the need for up to a 24-month supply of IPv4 address space."
<DIV> </DIV>
<DIV>I think in my mind I imagined a similar separate bullets in 8.3,
one for 24-month supply and another for sign RSA, and I intended just
to remove the 24 month part. </DIV>
<DIV> </DIV>
<DIV>I think there are a few ways to fix this.</DIV>
<DIV> </DIV>
<DIV>
<DIV>Option 1 - minimun rewrtite</DIV>
<DIV>- remove only the "24-month" portion of the 8.3 text. This is the
minimum change, but brings section 8.3 and 8.4 further out of
alignment</DIV>
<DIV> </DIV>
<DIV>Option 2 - single bullet for "meet ARIN policy" and "sign RSA"
(8.3 as the model text)</DIV>
<DIV>- replace the whole "24-month" text and "meet ARIN policy" text
in 8.3 with a bullet that included "sign the RSA" and "meet ARIN
policy" under one bullet and is parallel to text in 8.4 (minus within
the ARIN region)</DIV>
<DIV> </DIV>
<DIV>Option 3 - two separate bullets for "meet ARIN policy" and "sign
RSA" (8.2 as the model text) </DIV>
<DIV>- replace the whole "24-month" text in 8.3 with a bullet that
included "sign the RSA"</DIV>
<DIV>-separate the "sign the RSA" and "meet ARIN policy" in 8.4 into
two bullets and is parallel to text in 8.3 (plus the within ARIN
region)</DIV></DIV>
<DIV> </DIV>
<DIV>(If the summary of the options are hard to follow I have a
suggestion for the specific rewrites below)</DIV>
<DIV> </DIV>
<DIV>I think your suggestion is roughly Option 2 below (the only
difference is with your suggested rewrite, there are now two bullets
in 8.3 stating the recipient is subject to current ARIN
policies). Assuming all the options have the same policy
implications, I would prefer option 2 or 3, as these bring greater
alignment of the sections. </DIV>
<DIV> </DIV>
<DIV>Do these options all meet your concern?</DIV>
<DIV> </DIV>
<DIV>Does the community and ARIN staff agree that the thee options
have the same policy implications?</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Kevin, David,</DIV>
<DIV> </DIV>
<DIV>I think at this point you own the text?</DIV>
<DIV>I would be supportive of the friendly amendment to modify the
draft policy as follows:</DIV>
<DIV> </DIV>
<DIV><SPAN
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif"></SPAN> </DIV>
<DIV><SPAN
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif">OPTION
1:</SPAN></DIV><SPAN>
<DIV><SPAN
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif">Replace the
following Section 8.3 text:</SPAN><BR
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif">
<DIV style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif"><BR>">
The recipient must demonstrate the need for up to a 24-month
supply<BR> of IP address resources under current ARIN policies
and sign an<BR> RSA."</DIV>
<DIV
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif"> </DIV><SPAN
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif">with:</SPAN></DIV>
<DIV><SPAN
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif"><BR></SPAN></DIV></SPAN>
<DIV><SPAN
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif">">
</SPAN>Recipients will sign an RSA for the resources being
received."</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>OPTION 2:</DIV>
<DIV> </DIV>
<DIV>
<DIV><SPAN><SPAN
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif">Replace the
following Section 8.3 text:</SPAN><BR
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif"></SPAN>
<DIV><SPAN><BR><FONT face="arial, sans-serif">"> The recipient must
demonstrate the need for up to a 24-month supply</FONT><BR><FONT
face="arial, sans-serif"> of IP address resources under current
ARIN policies and sign an</FONT><BR> RSA.<BR></SPAN> >
The resources transferred will be subject to current ARIN
policies.<SPAN
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif">"</SPAN></DIV>
<DIV
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif"> </DIV><SPAN
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif">with:</SPAN></DIV>
<DIV><SPAN
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif"><BR></SPAN></DIV>
<DIV>
<DIV>"> Recipients will be subject to current ARIN policies and
sign an RSA for the resources being received."<BR></DIV></DIV></DIV>
<DIV> </DIV>
<DIV>OPTION 3:</DIV>
<DIV><SPAN>
<DIV><SPAN
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif">Replace the
following Section 8.3 text:</SPAN><BR
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif">
<DIV style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif"><BR>">
The recipient must demonstrate the need for up to a 24-month
supply<BR> of IP address resources under current ARIN policies
and sign an<BR> RSA."</DIV>
<DIV
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif"> </DIV><SPAN
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif">with:</SPAN></DIV>
<DIV><SPAN
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif"><BR></SPAN></DIV></SPAN>
<DIV><SPAN
style="FONT-SIZE: 13px; FONT-FAMILY: arial,sans-serif">">
</SPAN>Recipients will sign an RSA for the resources being
received."</DIV></DIV>
<DIV> </DIV>
<DIV>and replace the following Section 8.4 text:</DIV>
<DIV> </DIV>"> Recipients within the ARIN region will be
subject to current ARIN policies and sign an RSA for the resources
being received.<BR> > Recipients within the ARIN region must
demonstrate the need for up to a 24-month supply of IPv4 address
space."</DIV>
<DIV> </DIV>
<DIV>With:</DIV>
<DIV> </DIV>
<DIV>
<DIV>"> Recipients within the ARIN region will sign an RSA for the
resources being received.</DIV>
<DIV>> The resources transferred to recipients within the ARIN
region will be subject to current ARIN policies."</DIV>
<DIV> </DIV>
<DIV>If all the options are indeed the same I would prefer option 2 or
3.</DIV>
<DIV>If the options have different policy implications and we can
converge on one standard for both 8.2 and 8.3, then I would prefer
that.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>___Jason</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV></DIV></DIV>
<DIV class=gmail_extra>
<DIV>
<DIV><BR><BR>
<DIV class=gmail_quote>On Thu, Sep 4, 2014 at 8:50 AM, Bill Owens
<SPAN dir=ltr><<A href="mailto:owens@nysernet.org"
target=_blank>owens@nysernet.org</A>></SPAN> wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV>On Wed, Sep 03, 2014 at 04:55:58PM -0400, ARIN wrote:<BR>>
On 28 August 2014 the ARIN Advisory Council (AC) accepted<BR>>
"ARIN-prop-212 Transfer policy slow start and simplified
needs<BR>> verification" as a Draft Policy.<BR>><BR></DIV>. .
.<BR>
<DIV>><BR>> Draft Policy ARIN-2014-20<BR>> Transfer Policy
Slow Start and Simplified Needs Verification<BR>><BR>> Date: 3
September 2014<BR>><BR></DIV>. . .<BR>
<DIV>><BR>> Policy statement:<BR>><BR>> Remove the
following section 8.3 text:<BR>><BR>> “The recipient must
demonstrate the need for up to a 24-month supply<BR>> of IP
address resources under current ARIN policies and sign an<BR>>
RSA.”<BR><BR></DIV>Shouldn't that be something like this,
instead?<BR><BR>Replace the following Section 8.3 text:<BR>
<DIV><BR>"The recipient must demonstrate the need for up to a
24-month supply<BR> of IP address resources under current ARIN
policies and sign an<BR> RSA.”<BR><BR></DIV>with:<BR><BR>"The
recipient will be subject to current ARIN policies and sign
an<BR> RSA for the resources being received."<BR><BR>As
written it appears to remove the requirement for recipients of
in-region transfers to sign an RSA.<BR><SPAN><FONT
color=#888888><BR>Bill.<BR></FONT></SPAN>
<DIV>
<DIV>_______________________________________________<BR>PPML<BR>You
are receiving this message because you are subscribed to<BR>the ARIN
Public Policy Mailing List (<A href="mailto:ARIN-PPML@arin.net"
target=_blank>ARIN-PPML@arin.net</A>).<BR>Unsubscribe or manage your
mailing list subscription at:<BR><A
href="http://lists.arin.net/mailman/listinfo/arin-ppml"
target=_blank>http://lists.arin.net/mailman/listinfo/arin-ppml</A><BR>Please
contact <A href="mailto:info@arin.net"
target=_blank>info@arin.net</A> if you experience any
issues.</DIV></DIV></BLOCKQUOTE></DIV><BR><BR clear=all>
<DIV> </DIV></DIV></DIV><SPAN><FONT color=#888888>-- <BR><FONT
color=#555555 face="'courier new', monospace">
<DIV><SPAN style="FONT-FAMILY: arial; COLOR: rgb(0,0,0)"><FONT
color=#555555
face="'courier new', monospace">_______________________________________________________<BR></FONT>
<DIV><FONT face="'courier new', monospace">Jason Schiller|NetOps|<A
href="mailto:jschiller@google.com"
target=_blank>jschiller@google.com</A>|<A href="tel:571-266-0006"
target=_blank value="+15712660006">571-266-0006</A></FONT></DIV>
<DIV><FONT
face="'courier new', monospace"><BR></FONT></DIV></SPAN></DIV></FONT></FONT></SPAN></DIV></BLOCKQUOTE></DIV><BR><BR
clear=all>
<DIV> </DIV>-- <BR><FONT color=#555555
face="'courier new', monospace">
<DIV><SPAN style="FONT-FAMILY: arial; COLOR: rgb(0,0,0)"><FONT
color=#555555
face="'courier new', monospace">_______________________________________________________<BR></FONT>
<DIV><FONT face="'courier new', monospace">Jason Schiller|NetOps|<A
href="mailto:jschiller@google.com"
target=_blank>jschiller@google.com</A>|<A href="tel:571-266-0006"
target=_blank value="+15712660006">571-266-0006</A></FONT></DIV>
<DIV><FONT
face="'courier new', monospace"><BR></FONT></DIV></SPAN></DIV></FONT></DIV></DIV></DIV>
<HR>
<SPAN>_______________________________________________<BR>PPML<BR>You are
receiving this message because you are subscribed to<BR>the ARIN Public
Policy Mailing List (<A href="mailto:ARIN-PPML@arin.net"
target=_blank>ARIN-PPML@arin.net</A>).<BR>Unsubscribe or manage your
mailing list subscription at:<BR><A
href="http://lists.arin.net/mailman/listinfo/arin-ppml"
target=_blank>http://lists.arin.net/mailman/listinfo/arin-ppml</A><BR>Please
contact <A href="mailto:info@arin.net" target=_blank>info@arin.net</A>
if you experience any issues.</SPAN>
</DIV></DIV></DIV></DIV></BLOCKQUOTE></DIV><BR><BR clear=all>
<DIV> </DIV>-- <BR><FONT color=#555555
face="'courier new', monospace">
<DIV><SPAN style="FONT-FAMILY: arial; COLOR: rgb(0,0,0)"><FONT
color=#555555
face="'courier new', monospace">_______________________________________________________<BR></FONT>
<DIV><FONT face="'courier new', monospace">Jason Schiller|NetOps|<A
href="mailto:jschiller@google.com"
target=_blank>jschiller@google.com</A>|<A href="tel:571-266-0006"
target=_blank value="+15712660006">571-266-0006</A></FONT></DIV>
<DIV><FONT
face="'courier new', monospace"><BR></FONT></DIV></SPAN></DIV></FONT></DIV></DIV></DIV></BLOCKQUOTE></DIV><BR>_______________________________________________<BR>PPML<BR>You
are receiving this message because you are subscribed to<BR>the ARIN Public
Policy Mailing List (<A href="mailto:ARIN-PPML@arin.net"
target=_blank>ARIN-PPML@arin.net</A>).<BR>Unsubscribe or manage your mailing
list subscription at:<BR><A
href="http://lists.arin.net/mailman/listinfo/arin-ppml"
target=_blank>http://lists.arin.net/mailman/listinfo/arin-ppml</A><BR>Please
contact <A href="mailto:info@arin.net" target=_blank>info@arin.net</A> if
you experience any issues.<BR></BLOCKQUOTE></DIV>
<DIV> </DIV></DIV></DIV></DIV></DIV></DIV></DIV></DIV></BLOCKQUOTE></DIV><BR><BR
clear=all>
<DIV> </DIV>-- <BR><FONT color=#555555 face="'courier new', monospace">
<DIV><SPAN style="FONT-FAMILY: arial; COLOR: rgb(0,0,0)"><FONT color=#555555
face="'courier new', monospace">_______________________________________________________<BR></FONT>
<DIV><FONT face="'courier new', monospace">Jason Schiller|NetOps|<A
href="mailto:jschiller@google.com"
target=_blank>jschiller@google.com</A>|571-266-0006</FONT></DIV>
<DIV><FONT
face="'courier new', monospace"><BR></FONT></DIV></SPAN></DIV></FONT></DIV></DIV></DIV></DIV></BODY></HTML>