<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=ISO-8859-7">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Hello Albert</p>
    <p>I would agree with most of what you said specially with the
      condition to have a prove use of IPv6 in order to receive any IPv4
      if that is according to whatever policy for waitlist.<br>
      However the 4.10 conditions are very specific on how these
      resources must be used in order to be justified and for a new
      entrant that may not be the case for all possible scenarios and it
      would not be fair with them. Therefore things need to be
      differentiated for both cases and that doesn't exclude the need of
      prove IPv6 deployment, just without the bindings of 4.10 for new
      entrants.<br>
      Regards<br>
      Fernando<br>
    </p>
    <div class="moz-cite-prefix">On 15/08/2019 22:38,
      <a class="moz-txt-link-abbreviated" href="mailto:hostmaster@uneedus.com">hostmaster@uneedus.com</a> wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:alpine.LRH.2.21.1908152057180.14553@bigone.uneedus.com">I
      am in favor of this proposal.
      <br>
      <br>
      4.10 will in effect become the new "waiting list", but with an
      additional condition that I feel is important.  That condition is
      a requirement for the use of IPv6. The only other real change from
      the existing waiting is the size of each "dip", and the total size
      that one can obtain.  The current waiting list is more generous
      versus this proposal.  I consider that "feature" to be a positive
      change.
      <br>
      <br>
      I am ready for ARIN to start an IPv6 requirement whenever it
      allocates IPv4 space. The current waiting list has NO IPv6
      requirement.  This proposal is a good start to that goal.
      <br>
      <br>
      I would consider it not responsible at this point for a new
      entrant to not implement IPv6 at this point. Let those that want
      to continue or newly establish new IPv4 infrastructure to go to
      the marketplace, and reserve all IPv4 returns for those that have
      or will establish IPv6.
      <br>
      <br>
      Albert Erdmann
      <br>
      Network Administrator
      <br>
      Paradise On Line Inc.
      <br>
      <br>
      On Thu, 15 Aug 2019, Owen DeLong wrote:
      <br>
      <br>
      <blockquote type="cite">Really, it seems to me that this proposal
        is another attempt at eliminating the waiting list for unmet
        requests.
        <br>
        The first attempt (ARIN auctions the space) met with resistance
        from ARIN¢s legal team (for good reason), so now this attempts
        to sequester the space where it will be
        <br>
        hard to distribute rather than allowing the waiting list to have
        any potential to compete with the transfer market.
        <br>
        <br>
        The proposed targets (4.4 and 4.10 pools) are well stocked and
        unlikely to run out in any useful IPv4 lifetime.
        <br>
        <br>
        As such, restocking them from returned space strikes me as just
        a way to sequester this space where it cannot be used.
        <br>
        <br>
        IMHO, this is counter to ARIN¢s mission and should not be
        allowed.
        <br>
        <br>
        I oppose the policy as written and as proposed to be amended.
        <br>
        <br>
        Owen
        <br>
        <br>
        <br>
              On Aug 15, 2019, at 13:55 , WOOD Alison * DAS via
        ARIN-PPML <a class="moz-txt-link-rfc2396E" href="mailto:arin-ppml@arin.net"><arin-ppml@arin.net></a> wrote:
        <br>
        <br>
        Thank you for the continued input on this draft policy proposal.
        <br>
         
        <br>
        I will be updating the text of the draft policy to include both
        4.4 and 4.10 pools.  Point of information, the 4.4 pool
        currently has approximately 391 /24¢s
        <br>
        and 4.10 has approximately 15,753 /24¢s available and are not
        estimated to run out in the next five years.
        <br>
         
        <br>
        Please keep your feedback coming, it is very helpful for the
        council.
        <br>
         
        <br>
        -Alison
        <br>
         
        <br>
        From: ARIN-PPML [<a class="moz-txt-link-freetext" href="mailto:arin-ppml-bounces@arin.net">mailto:arin-ppml-bounces@arin.net</a>] On Behalf
        Of Fernando Frediani
        <br>
        Sent: Tuesday, July 30, 2019 6:44 AM
        <br>
        To: arin-ppml <a class="moz-txt-link-rfc2396E" href="mailto:arin-ppml@arin.net"><arin-ppml@arin.net></a>
        <br>
        Subject: Re: [arin-ppml] Draft Policy ARIN-2019-17: Returned
        Addresses to the 4.10 Reserved Pool
        <br>
         
        <br>
        <br>
        The point is that you treating IP marketing as something
        'natural' or a 'default route' which it is not and can never be.
        Natural is to receive some addresses
        <br>
        from the RIR in first place so they are treated as anyone else
        was in the past and have a chance to exist in the Internet with
        same conditions as all others.
        <br>
        From that if they need extra space then fine to seek for
        alternative ways.
        <br>
        <br>
        I don't think a new entrants would automatically qualify for
        4.10 in all cases therefore any space left should be targeted
        also to them as well to IPv6
        <br>
        transition and critical infrastructure. Otherwise the community
        will be creating an artificial barrier to them in order to favor
        the IP market while the RIR
        <br>
        still has IPv4 space available for them.
        <br>
        <br>
        Fernando
        <br>
        <br>
        On 30/07/2019 10:30, Tom Fantacone wrote:
        <br>
              I would think that the majority of new entrants would need
        at least some allocation to help with IPv6 transition and would
        qualify for addresses
        <br>
              from the 4.10 pool.  Depending on what they receive from
        that pool and when, they may not qualify for additional waiting
        list addresses and would
        <br>
              have to go to the transfer market for additional IPv4
        space anyway.  Those that don't qualify under 4.10 can still get
        smaller IPv4 blocks on the
        <br>
              transfer market readily, and the cost for blocks in the
        /24-/22 range is not prohibitive.  Certainly an organization
        seeking a small IPv4 block for
        <br>
              multi-homing or other purposes is better off spending a
        few thousand dollars to purchase a range than waiting a year on
        the waiting list to put
        <br>
              their plans in motion.
        <br>
        <br>
        <br>
        Note that while RIPE does not have a reserve pool specifically
        for IPv6 transition, the expectation of their final /8 policy
        was to allow new entrants
        <br>
        access to IPv4 to assist in this transition.  In reality, it
        didn't work out that way and most of the /22 allocations to new
        LIRs from the final /8 were
        <br>
        to existing organizations who spun up new, related entities in
        order to increase their IPv4 holdings:
        <br>
        <br>
<a class="moz-txt-link-freetext" href="https://labs.ripe.net/Members/wilhelm/so-long-last-8-and-thanks-for-all-the-allocations">https://labs.ripe.net/Members/wilhelm/so-long-last-8-and-thanks-for-all-the-allocations</a>
        <br>
        <br>
        I'm also sympathetic to new entrants, but don't see the current
        waiting list as a great help to them vs. the 4.10 pool or the
        transfer market, both of
        <br>
        which allow you your allocation in a timely fashion.
        <br>
        <br>
        Best Regards,
        <br>
        <br>
        Tom Fantacone
        <br>
        <br>
         
        <br>
        ---- On Mon, 29 Jul 2019 11:39:32 -0400 Fernando Frediani
        <a class="moz-txt-link-rfc2396E" href="mailto:fhfrediani@gmail.com"><fhfrediani@gmail.com></a> wrote ----
        <br>
         
        <br>
              I find it interesting the idea of privileging the pool
        dedicated to 
        <br>
              facilitate IPv6 Deployment and I also agree with the
        comments below in 
        <br>
              the sense that it's not very beneficial do most ARIN
        members due to max 
        <br>
              size, /22, cannot be holding more than a /20.
        <br>
        <br>
              However one point I couldn't identify is where the new
        entrants stand in 
        <br>
              this new possible scenario ? Will they only be able to
        apply under the 
        <br>
              4.10 reserved pool ? If so for a access/broadband ISPs may
        be easier to 
        <br>
              fit, but not necessarily for other scenarios and types of
        ISPs. 
        <br>
              Therefore if I didn't miss anything these returned
        addresses should also 
        <br>
              be able to go to new entrants, not only to 4.10 reserved
        pool conditions.
        <br>
        <br>
              Best regards
        <br>
              Fernando Frediani
        <br>
        <br>
              On 25/07/2019 17:32, Tom Fantacone wrote:
        <br>
              > I found the wording of the Problem Statement on this
        one a bit 
        <br>
              > confusing. However, after deciphering the effect of
        the actual policy 
        <br>
              > change I support it.
        <br>
              >
        <br>
              > Essentially, all returned IPv4 space will no longer
        go to the waiting 
        <br>
              > list but will supplement the 4.10 reserved pool used
        to enhance IPv6 
        <br>
              > deployment.  This essentially kills off the waiting
        list.
        <br>
              >
        <br>
              > The recent restrictions placed on the waiting list to
        reduce fraud 
        <br>
              > have hobbled it to the point where it's not very
        beneficial to most 
        <br>
              > ARIN members.  (Max size, /22, cannot be holding more
        than a /20).  
        <br>
              > It's essentially only useful to new entrants, but
        those that go on it 
        <br>
              > still have to wait many months to receive their small
        allocation.  If 
        <br>
              > they justify need now, but have to wait that long,
        how critical is 
        <br>
              > their need if they're willing to wait that long? 
        Small blocks are not 
        <br>
              > terribly expensive and can be quickly gotten on the
        transfer market.  
        <br>
              > I can understand waiting that long for a large block
        needed for a 
        <br>
              > longer term project due to prohibitive cost, but I
        don't see a great 
        <br>
              > benefit to the waiting list as it stands.
        <br>
              >
        <br>
              > Also, if there's any fraud left on the waiting list,
        this would kill it.
        <br>
              >
        <br>
              > I would hope, however, that if implemented, those
        currently on the 
        <br>
              > waiting list would be grandfathered in.  I do think
        some entities with 
        <br>
              > legitimate need got burned on the last change made to
        the waiting list.
        <br>
              >
        <br>
              > At 04:05 PM 7/23/2019, ARIN wrote:
        <br>
              >> On 18 July 2019, the ARIN Advisory Council (AC)
        accepted 
        <br>
              >> "ARIN-prop-276: Returned Addresses to the 4.10
        Reserved Pool" as a 
        <br>
              >> Draft Policy.
        <br>
              >>
        <br>
              >> Draft Policy ARIN-2019-17 is below and can be
        found at:
        <br>
              >>
        <br>
             
        >> <a class="moz-txt-link-freetext" href="https://www.arin.net/participate/policy/drafts/2019_17/">https://www.arin.net/participate/policy/drafts/2019_17/</a>
        <br>
              >>
        <br>
              >> You are encouraged to discuss all Draft Policies
        on PPML. The AC will 
        <br>
              >> evaluate the discussion in order to assess the
        conformance of this 
        <br>
              >> draft policy with ARIN's Principles of Internet
        number resource 
        <br>
              >> policy as stated in the Policy Development
        Process (PDP). 
        <br>
              >> Specifically, these principles are:
        <br>
              >>
        <br>
              >> * Enabling Fair and Impartial Number Resource
        Administration
        <br>
              >> * Technically Sound
        <br>
              >> * Supported by the Community
        <br>
              >>
        <br>
              >> The PDP can be found at:
        <br>
              >> <a class="moz-txt-link-freetext" href="https://www.arin.net/participate/policy/pdp/">https://www.arin.net/participate/policy/pdp/</a>
        <br>
              >>
        <br>
              >> Draft Policies and Proposals under discussion can
        be found at:
        <br>
              >> <a class="moz-txt-link-freetext" href="https://www.arin.net/participate/policy/drafts/">https://www.arin.net/participate/policy/drafts/</a>
        <br>
              >>
        <br>
              >> Regards,
        <br>
              >>
        <br>
              >> Sean Hopkins
        <br>
              >> Policy Analyst
        <br>
              >> American Registry for Internet Numbers (ARIN)
        <br>
              >>
        <br>
              >> Draft Policy ARIN-2019-17: Returned Addresses to
        the 4.10 Reserved Pool
        <br>
              >>
        <br>
              >> Problem Statement:
        <br>
              >>
        <br>
              >> An inconsistent and unpredictable stream of
        address space is an 
        <br>
              >> unsuitable method of populating the waiting list
        (4.1.8.1) and 
        <br>
              >> fulfilling subsequent requests.
        <br>
              >>
        <br>
              >> Policy statement:
        <br>
              >>
        <br>
              >> Change "4.10. Dedicated IPv4 Block to Facilitate
        IPv6 Deployment" to 
        <br>
              >> "4.10 Dedicated IPv4 Pool to Facilitate IPv6
        Deployment"
        <br>
              >>
        <br>
              >> Change" When ARIN receives its last /8 IPv4
        allocation from IANA, a 
        <br>
              >> contiguous /10 IPv4 block will be set aside and
        dedicated to 
        <br>
              >> facilitate IPv6 deployment. Allocations and
        assignments from this 
        <br>
              >> block " to "In addition to the contiguous /10
        IPv4 block set aside 
        <br>
              >> and dedicated to facilitate IPv6 deployment, all
        returns and 
        <br>
              >> revocations of IPv4  blocks will be added to the
        pool of space 
        <br>
              >> dedicated to the facilitation of IPv6 deployment.
        Allocations and 
        <br>
              >> assignments from this pool "
        <br>
              >>
        <br>
              >> Change "This block will be subject to a minimum
        size allocation of 
        <br>
              >> /28 and a maximum size allocation of /24. ARIN
        should use sparse 
        <br>
              >> allocation when possible within that /10 block."
        to "This pool will 
        <br>
              >> be subject to a minimum size allocation of /28
        and a maximum sized 
        <br>
              >> allocation of /24. ARIN should use sparse
        allocation when possible 
        <br>
              >> within the pool."
        <br>
              >>
        <br>
              >> Comments:
        <br>
              >>
        <br>
              >> Timetable for implementation: Immediate
        <br>
              >> _______________________________________________
        <br>
              >> ARIN-PPML
        <br>
              >> You are receiving this message because you are
        subscribed to
        <br>
              >> the ARIN Public Policy Mailing List
        (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
        <br>
              >> Unsubscribe or manage your mailing list
        subscription at:
        <br>
              >> <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>
              >> Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience
        any issues.
        <br>
              >
        <br>
              >
        <br>
              > _______________________________________________
        <br>
              > ARIN-PPML
        <br>
              > You are receiving this message because you are
        subscribed to
        <br>
              > the ARIN Public Policy Mailing List
        (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
        <br>
              > Unsubscribe or manage your mailing list subscription
        at:
        <br>
              > <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>
              > Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any
        issues.
        <br>
              _______________________________________________
        <br>
              ARIN-PPML
        <br>
              You are receiving this message because you are subscribed
        to
        <br>
              the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
        <br>
              Unsubscribe or manage your mailing list subscription at:
        <br>
              <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>
              Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
        <br>
        <br>
         
        <br>
         
        <br>
        <br>
        _______________________________________________
        <br>
        ARIN-PPML
        <br>
        You are receiving this message because you are subscribed to
        <br>
        the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
        <br>
        Unsubscribe or manage your mailing list subscription at:
        <br>
        <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>
        Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
        <br>
        <br>
        <br>
        <br>
        <br>
      </blockquote>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
</pre>
    </blockquote>
  </body>
</html>