<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 10 nov. 2019 à 21:58, Jaco Kroon <<a href="mailto:jaco@uls.co.za">jaco@uls.co.za</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <p>Hi Chevalier.</p>
    <p>Please allow me to be blunt.  That's short sighted.</p>
    <p>We cannot transfer IN from other regions unless we allow OUT.</p></div></blockquote><div><br></div><div>Agree 100%, </div><div>Then you have no problems with wait till all RIRs are equal run out before we etablish full in and out transfer policy no?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <p>All the other RIRs require reciprocal *compatible* policies,
      which means bi-directional transfers.</p></div></blockquote><div><br></div><div><br></div><div>All RIRs don't all have equal amount of free space. Big difference</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <p>Not allowing this means we can't get resources in either.</p></div></blockquote><div><br></div><div>While AfriNIC have free space, operators don't need it</div><div>When it run out, then we can allow transfer policy</div><div><br></div><div><br></div><div>Until that time, I oppose these "AfriNIC Broker Support Policy"<br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <p><br>
    </p>
    <div>
      
      <p>Kind Regards,<br>
        <span style="font-size:24px;color:rgb(141,198,65)">Jaco Kroon</span>
        <br>
        <span style="font-size:16px">C.E.O.</span></p>
      <table width="540" cellspacing="0" cellpadding="0">
        <tbody>
          <tr>
            <td>
              <p><b>T:</b> +27 (0)12 021 0000 | <b>F:</b> +27 86 648
                8561 | <b>E:</b> <a href="mailto:jaco@iewc.co.za" target="_blank">jaco@iewc.co.za</a><br>
                <b>W:</b> <a href="https://www.iewc.co.za/" target="_blank">iewc.co.za</a>
                | <b>A:</b> Unit 201, Building 2B, Sunwood Park,
                Queen's Crescent Lynnwood, Pretoria</p>
            </td>
          </tr>
          <tr>
            <td valign="middle" bgcolor="8dc641" align="left">
              <table style="font-size:12px;font-family:Arial,sans-serif" width="100%" cellspacing="0" cellpadding="0">
                <tbody>
                  <tr>
                    <td colspan="2" style="height:5px" height="5"><br>
                    </td>
                  </tr>
                  <tr>
                    <td width="10"> </td>
                    <td>
                      <p> <a style="display:inline-block" href="https://www.facebook.com/Interexcel/" target="_blank"><img src="cid:16e56a3b858b21f4f11" alt="Facebook"></a> <a style="display:inline-block" href="https://twitter.com/Interexcel/" target="_blank"><img src="cid:16e56a3b8588bb52eae2" alt="Twitter"></a> <a style="display:inline-block" href="https://plus.google.com/+InterexcelCoZaPTA/posts" target="_blank"><img src="cid:16e56a3b858c0e00f293" alt="Google+"></a> <a style="display:inline-block" href="https://www.linkedin.com/company/interexcel-world-connection/" target="_blank"><img src="cid:16e56a3b858c0e00f293" alt="LinkedIn"></a> </p>
                    </td>
                  </tr>
                </tbody>
              </table>
            </td>
          </tr>
          <tr>
            <td colspan="3" valign="middle">
              <p><a href="https://www.iewc.co.za/" target="_blank"><img alt="IEWC" src="cid:16e56a3b858b8d2a40f4" width="200" height="40"></a> <a href="http://www.uls.co.za/" style="margin-left:40px" target="_blank"><img alt="ULS Group" src="cid:16e56a3b859b933f2b65" width="136" height="53"></a></p>
            </td>
          </tr>
          
        </tbody>
      </table>
    </div>
    <div>On 2019/11/10 18:50, Chevalier du Borg
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div dir="ltr"><br>
        </div>
        <div>I opposed this and any out of continent transfer policy at
          this time. I can revise my choice when ALL RIRs have finish
          their free pool. Otherwise, this policy can as well be call</div>
        <div><br>
        </div>
        <div>"The AfriNIC Broker Support Policy"</div>
        <div><br>
        </div>
        <div><br>
        </div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">Le mer. 6 nov. 2019 à 23:42,
            Owen DeLong <<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>> a écrit :<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div><br>
              <div><br>
                <blockquote type="cite">
                  <div>On Nov 6, 2019, at 07:00 , Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" target="_blank">fhfrediani@gmail.com</a>>
                    wrote:</div>
                  <br>
                  <div>
                    <div>
                      <p>This proposal states in 5.7.3.2 that "the
                        source entities are eligible to receive further
                        IPv4 allocations or assigments from AFRINIC".
                        What is the logic on that ?<br>
                        If a organization is transferring its resources
                        it means it doesn't need them anymore and
                        therefore it doesn't make sense they can receive
                        any further space from AFRINIC.</p>
                    </div>
                  </div>
                </blockquote>
                Transferring out should not result in a permanent ban on
                acquiring more resources, but there should definitely be
                some hold-down time to prevent address cycling and
                speculation.</div>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div><br>
          </div>
          <div>Why not? </div>
          <div>Unless they can prove they retrieve the last block of
            address they 'transfer' (aka SELL), why should they get more
            from the community pool?</div>
          <div>And again. I oppose this "The AfriNIC Broker Support
            Policy"</div>
          <div><br>
          </div>
          <div><br>
          </div>
          <div> </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div>
              <div><br>
              </div>
              <div>Suggest that sources of resources for transfer be
                prohibited from acquiring additional resources for at
                least 24 months.</div>
              <div><br>
              </div>
              <div>
                <blockquote type="cite">
                  <div>
                    <div>
                      <p>It also proposes in 5.7.4.1 that "the transfer
                        does not require approval from AFRINIC". Of
                        course there must be a mutual agreement on both
                        sides for a transfer to happen but the RIR must
                        check everything and 'approve' that everything
                        is correct and can happen. Furthermore the
                        justification for coming 10 years it way to long
                        and I've never seen it in any other place which
                        for me doesn't make sense otherwise would
                        clearly allow stockpiling which is one of the
                        key things to be avoided in IP assignment since
                        the very beginning.</p>
                    </div>
                  </div>
                </blockquote>
                Agreed… Recipients of transfers should be subject to the
                same reviews as recipients of space from the free pool,
                IMHO. Further, local sources of resources for transfer
                should be validated by the RIR as the legitimate and
                uncontested registrant.</div>
              <div><br>
              </div>
              <div>For inter-RIR transfers, I would suggest the
                following:</div>
              <div><span style="white-space:pre-wrap">    </span>Source
                Entity should be verified by Source RIR according to
                that RIR’s policies and practices.</div>
              <div><span style="white-space:pre-wrap">    </span>Recipient
                Entity should be verified by Destination RIR according
                to that RIR’s policies and practices.</div>
              <div><br>
              </div>
              <div>This is the general approach taken in the existing
                inter-RIR transfer policies and will yield greatest
                compatibility with existing inter-RIR policies.</div>
              <div>
                <blockquote type="cite">
                  <div>
                    <div>
                      <p>The proposal also removes something fundamental
                        to fix a historical mistake, with the removal o
                        5.7.4.3 which converts legacy transferred
                        resources to non-legacy.</p>
                    </div>
                  </div>
                </blockquote>
                <div>Agreed…</div>
                <div><br>
                </div>
                There should, in my opinion, be no such thing as legacy
                resources, only legacy registrations. An existing
                registration which existed before the RIR and has not
                been brought into contract with an existing RIR is a
                legacy registration. Any transfer or other transaction
                which involves a change in ownership of that
                registration should require that the recipient enter a
                contract with the RIR and that the new registration be
                non-legacy.</div>
              <div><br>
              </div>
              <div>If the authors can adopt these recommendations, I
                could support the proposal. Without them, I must oppose
                the proposal as written.</div>
              <div><br>
              </div>
              <div>Owen</div>
              <div><br>
              </div>
              <br>
            </div>
            _______________________________________________<br>
            RPD mailing list<br>
            <a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a><br>
            <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
          </blockquote>
        </div>
        <br clear="all">
        <div><br>
        </div>
        -- <br>
        <div dir="ltr">Borg le Chevalier<br>
          ___________________________________<br>
          "Common sense is what tells us the world is flat" </div>
      </div>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
RPD mailing list
<a href="mailto:RPD@afrinic.net" target="_blank">RPD@afrinic.net</a>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a>
</pre>
    </blockquote>
  </div>

</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Borg le Chevalier<br>___________________________________<br>"Common sense is what tells us the world is flat" </div></div>