<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 14, 2015 at 12:17 PM, James Blessing <span dir="ltr"><<a href="mailto:james.blessing@despres.co.uk" target="_blank">james.blessing@despres.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 14 August 2015 at 10:54, Marco Schmidt <<a href="mailto:mschmidt@ripe.net">mschmidt@ripe.net</a>> wrote:<br>
<br>
>     <a href="https://www.ripe.net/participate/policies/proposals/2015-04" rel="noreferrer" target="_blank">https://www.ripe.net/participate/policies/proposals/2015-04</a><br></span></blockquote><div><br></div><div>Thanks for putting in the time and effort, Erik!</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Couple of questions/comments...<br>
<br>
>From 1.0<br>
<br>
Shouldn't the scope be explicit as to what is/isn't included<br></blockquote><div><br></div><div>I agree that this would help.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>From 2.1<br>
<br>
"Transfers can be on a permanent or non-permanent basis."<br>
<br>
How is this going to be recorded and managed within the context of<br>
reflecting it being a non-permanent transfer?<br></blockquote><div><br></div><div>Wouldn't that be up to the RIPE NCC?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>From 2.2<br>
<br>
"assigned by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit ASNs)"<br>
<br>
Rather than "such as" this needs to be a definitive list of what is<br>
classed as a restricted resource<br></blockquote><div><br></div><div>I concur, but I don't think it should be listed in the same document.</div><div><br></div><div>My first thought is that this list should be maintained by the RIPE NCC.</div><div><br></div><div>Keeping that list in a separate document means changing fewer documents when policy changes, or reality reaches a pre-set limit set in policy.</div><div><br></div><div>That separate list should reference the policy documents enabling the restrictions.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>From 3.1<br>
<br>
Again a list of conditions or references to policies that impose<br>
restrictions needed<br></blockquote><div><br></div><div>I'm a bit confused both by the point and by your response to it, maybe I'm just tired, but I think both could be clearer. :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>From 4.0<br>
<br>
M&A process is mentioned, should there be other references to this?<br>
Especially as M&A (as I understand it) allows 2.2 to be overridden<br></blockquote><div><br></div><div>"<span style="color:rgb(51,51,51);font-family:'Open Sans',Helvetica,Arial,sans-serif;font-size:14.3000001907349px;line-height:22.8800010681152px">The document proposes to include the transfer restrictions to mergers and acquisitions. This is done to make the policy more in line with the intention of the transfer policy restrictions when proposed."</span></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
General<br>
<br>
- As this is about transfers should this also cover returning<br>
resources to ripe NCC so all types of transfers be included<br></blockquote><div><br></div><div>I'm not sure that this would be useful, but 2015-04 could 1) include a reference to the policy for that, and 2) make it even clearer that this is a document for transfers between resource holders.</div><div><br></div><div>I don't think it's useful to consider the RIR a resource holder in this context.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- broadly support the unification of transfer policy into a single<br>
document, just things bits are missing or muddy<br></blockquote><div><br></div><div>Agreed, but the document is largely clarifying more than muddying, IMHO.</div></div>-- <br><div class="gmail_signature">Jan</div>
</div></div>