<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Fernando - I would support language similar to what you’ve proposed, as it explicitly requires the address allocation to be part of a connectivity service.<div class=""><br class=""></div><div class="">The trick then would be to make sure organizations can’t do it the other way around; I’m reminded of a nightclub I used to frequent that held a restaurant license, which only allowed them to serve alcohol as part of a order for food. As such, customers did not order drinks, they would buy a packet of peanuts that happened to be served with an alcoholic beverage alongside.</div><div class=""><br class=""></div><div class="">Let’s make sure that with this language, we don’t suddenly see an influx of “VPN Providers” who happen to be routing /24 or larger blocks to each of their customer’s tunnels.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class=""><br class=""></div><div class="">-Chris <br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 22, 2021, at 9:12 AM, Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" class="">fhfrediani@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
  
  <div class=""><p class="">I believe maybe Michael didn't understand well the matter fully
      or got only part of it.<br class="">
      Probably what caused more confusion was how Owen put the part "No
      signatory to any ARIN RSA is permitted by policy to engage in a
      recurring charge for addresses or a differentiated service charge
      based on the number if addresses issued to a customer.". That
      could be dubious in the sense that a LIR could not charge
      administrative fees when they assign addresses to their
      connectivity customers.</p><p class="">A simple: "No signatory to any ARIN RSA is permitted by policy to
      engage issuing addresses to non-conectivity customers. Addresses
      must be provided strictly as part of a contract for connectivity
      services."</p><p class="">I think Owen tried to put in a way to <span class="VIiyi" lang="en"><span class="JLqJ4b ChMk0b" data-language-for-alternatives="en" data-language-to-translate-into="pt" data-phrase-index="0"><span class="">strengthen
          </span></span></span>his point of view the LIR lease addresses
      and by that text they would not permitted to do even for
      connectivity customers.Simplifying it would achieve the objective
      in the subject without necessarily change the usual way LIRs
      allocate addresses to their *connectivity customers*.</p><p class="">Regards<br class="">
      Fernando<br class="">
    </p>
    <div class="moz-cite-prefix">On 22/09/2021 13:00, Isaiah Olson
      wrote:<br class="">
    </div>
    <blockquote type="cite" cite="mid:13b00bea-5247-10e5-ded3-274a462bc5ef@olson-network.com" class="">Hi
      Michael,
      <br class="">
      <br class="">
      I appreciate you clarifying this issue. If this policy proposal is
      considered out of scope, I would ask why Mike's policy proposal to
      explicitly allow leasing is considered in-scope for this PDP? If
      it is ARIN's position that it "does not impose any such
      restrictions on trade or pricing" with regards to pricing
      structure, why does ARIN differentiate justified need for
      transfers (trade) based on the absence or presence of connectivity
      services?
      <br class="">
      <br class="">
      I am happy to dispatch with any discussions that are not relevant
      or allowed, but I think that your post requires additional
      clarification of what topics are not permissible since many of the
      issues you have raised as out of scope are germane to other
      policies under discussion.
      <br class="">
      <br class="">
      Thanks,
      <br class="">
      Isaiah
      <br class="">
      <br class="">
      _______________________________________________
      <br class="">
      ARIN-PPML
      <br class="">
      You are receiving this message because you are subscribed to
      <br class="">
      the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
      <br class="">
      Unsubscribe or manage your mailing list subscription at:
      <br class="">
      <a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
      <br class="">
      Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
      <br class="">
    </blockquote>
  </div>

_______________________________________________<br class="">ARIN-PPML<br class="">You are receiving this message because you are subscribed to<br class="">the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" class="">ARIN-PPML@arin.net</a>).<br class="">Unsubscribe or manage your mailing list subscription at:<br class=""><a href="https://lists.arin.net/mailman/listinfo/arin-ppml" class="">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">Please contact info@arin.net if you experience any issues.<br class=""></div></blockquote></div><br class=""></div></body></html>