<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 5, 2014 at 7:00 AM, Bill Darte <span dir="ltr"><<a href="mailto:billdarte@gmail.com" target="_blank">billdarte@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Feb. 21 I sent the message (far below) to PPML asking the community to support one of 3 alternatives or propose new language which makes one or the other better, or a completely new wording which they believe accomplishes the goal of producing policy language that is needed, technically sound and improves existing policy in the 8.4 Inter-RIR transfer realm.<div>

<br></div> [...]</div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div style="font-family:arial,sans-serif;font-size:13px">
<font face="arial, sans-serif">3. T</font><span style="font-size:small">ake an alternative tack and simply restrict transfers on a per-block rather than a per-organization basis. e.g. 'No block acquired within the past 24 months would be eligible for transfer.' (The time frame is of course an arbitrary number at this point.)</span></div>

<div style="font-family:arial,sans-serif;font-size:13px"><font face="arial, sans-serif"><br></font></div></div></div></div></blockquote><div><br><br></div><div>I support option #3.<br><br></div><div>I'm curious if it would be better to reference time<br>
</div><div>periods from other sections of the NRPM, rather<br>than hard-coding a specific term here?  IE, if we<br></div><div>limit transfer requests to a 24-month supply, then<br>tie the anti-transfer period to be the same duration<br>
as the supply length, so that if we extend or contract<br>the supply length for transfers, this anti-flip language<br></div><div>inherits the same change.   This doesn't affect my<br>support for option #3, I'm just looking to see if there's<br>
</div><div>ways we can limit the potential for the NRPM getting<br></div><div>'out of sync' with itself in the future, if we change one<br>section but don't catch all the related sections like this.<br><br></div>
<div>Thanks!<br><br>Matt<br></div></div></div></div>