<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">As the current AC shepherd of this
      draft, I'm all for bringing this to Baltimore if there is
      something substantial to discuss.  However, there is a lot of time
      between now and the next PPM time which we could use on the
      mailing-list to get to a better understanding of the issues
      surrounding the problem statement and crafting updated policy
      language to solve the problem.  IMO, we shouldn't just "punt" to
      the next PPM.  Everyone should also realize that time to discuss
      this in person will be greatly limited at the PPM by the current
      large docket of draft policies now before the community.<br>
      <br>
      Andrew<br>
      <br>
      On 6/16/2014 11:19 AM, Jeffrey Lyon wrote:<br>
    </div>
    <blockquote
cite="mid:CACrmG8eExzK5BpxmD31vGPejBCf5eFWWDd0qvRSgqR71VeBfng@mail.gmail.com"
      type="cite">
      <p dir="ltr">Agreed re Baltimore</p>
      <p dir="ltr">Thanks, Jeff</p>
      <div class="gmail_quote">On Jun 16, 2014 2:13 PM, "David Huberman"
        <<a moz-do-not-send="true"
          href="mailto:David.Huberman@microsoft.com">David.Huberman@microsoft.com</a>>
        wrote:<br type="attribution">
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <br>
          <br>
          I believe we should discuss in Baltimore in front of a more
          substantial audience. There are by enough people participating
          here, in my opinion, for any "sense of the room" to make
          sense.<br>
          <br>
          David R Huberman<br>
          Microsoft Corporation<br>
          Senior IT/OPS Program Manager (GFS)<br>
          <br>
          ________________________________________<br>
          From: <a moz-do-not-send="true"
            href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a>
          <<a moz-do-not-send="true"
            href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a>>
          on behalf of Andrew Dul <<a moz-do-not-send="true"
            href="mailto:andrew.dul@quark.net">andrew.dul@quark.net</a>><br>
          Sent: Monday, June 16, 2014 10:53:15 AM<br>
          To: <a moz-do-not-send="true"
            href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
          Subject: Re: [arin-ppml] Policy discussion - Method of
          calculating utilization ARIN-2014-17<br>
          <br>
          Hello,<br>
          <br>
          I sent a longer summary of where this policy discussion is
          last week,<br>
          I've pasted a link below to that message in the archive.<br>
          <br>
          <a moz-do-not-send="true"
            href="http://lists.arin.net/pipermail/arin-ppml/2014-June/028654.html"
            target="_blank">http://lists.arin.net/pipermail/arin-ppml/2014-June/028654.html</a><br>
          <br>
          In general, I would say that this draft policy is stalled at
          this<br>
          point.  The 80% utilization policy underpins a large majority
          of the<br>
          current policies and thus is a substantial change.  There have
          been a<br>
          few people who have voiced their support, but not enough that
          I believe<br>
          would allow this policy to move forward as a recommended draft
          at this<br>
          point.<br>
          <br>
          I would also point out that they current policy also
          constrains larger<br>
          providers but in a different way as ARIN is now more closely
          enforcing<br>
          the current policy of "efficiently utilized all previous
          allocations"<br>
          (4.2.4.1) as noted during the NANOG PPC.<br>
          <br>
          Leif, I don't think there is an easy scaling algorithm to
          apply to<br>
          utilization.  The problem with a scaling algorithm is it
          likely will be<br>
          perceived as "unfair" by organizations on one side of the size<br>
          continuum.   (We tried HD ratio for v6 and that was not easily<br>
          understood, and lead to lots of confusion.)<br>
          <br>
          Thanks,<br>
          Andrew<br>
          <br>
          <br>
          <br>
          On 6/13/2014 4:33 PM, Leif Sawyer wrote:<br>
          > I was really hoping somebody would suggest, perhaps, some
          sort<br>
          > of easy-to-apply scaling algorithm so that it makes it
          easier for<br>
          > the smaller guys to get the space they need, but harder
          for the bigger<br>
          > guys to game the system.<br>
          ><br>
          > I'm sure there's some sort of curve that fits, but my
          advanced maths<br>
          > are limited to Pythagoras.<br>
          ><br>
          ><br>
          > -----Original Message-----<br>
          > From: <a moz-do-not-send="true"
            href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a>
          [mailto:<a moz-do-not-send="true"
            href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a>]
          On Behalf Of Jeffrey Lyon<br>
          > Sent: Friday, June 13, 2014 2:41 PM<br>
          > To: Tim Gimmel<br>
          > Cc: <a moz-do-not-send="true"
            href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a> List<br>
          > Subject: Re: [arin-ppml] Policy discussion - Method of
          calculating utilization<br>
          ><br>
          > Tim,<br>
          ><br>
          > I am also uncertain of the current status but would like
          to see some progress.<br>
          ><br>
          > Thanks, Jeff<br>
          ><br>
          > On Sat, Jun 14, 2014 at 5:50 AM, Tim Gimmel <<a
            moz-do-not-send="true"
            href="mailto:Tim.Gimmel@metronetinc.com">Tim.Gimmel@metronetinc.com</a>>
          wrote:<br>
          >> I not really sure where this policy discussion is at
          the moment, but I want to assert the current method places a
          strain on small carriers just trying to do business.  We are
          in the process of implementing IPv6, but is will be a long
          journey.<br>
          >> Overall I am way past 80% utilization, but because my
          last allocation (and this is based on actual usage, not just
          what has been 'swiped') has not yet reached 80% we are
          practically stymied.<br>
          >><br>
          >> Tim's 2 cents!<br>
          >><br>
          >> Tim<br>
          >><br>
          >> Tim Gimmel<br>
          >> Metronet | Senior Network Engineer<br>
          >> 3701 Communications Way | Evansville, IN 47715<br>
          >> Office: <a moz-do-not-send="true"
            href="tel:812.456.4750" value="+18124564750">812.456.4750</a><br>
          >> <a moz-do-not-send="true"
            href="http://www.MetronetInc.com" target="_blank">www.MetronetInc.com</a><br>
          >><br>
          >><br>
          >>> -----Original Message-----<br>
          >>> From: <a moz-do-not-send="true"
            href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a>
          [mailto:<a moz-do-not-send="true"
            href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a>]<br>
          >>> On Behalf Of Owen DeLong<br>
          >>> Sent: Friday, May 02, 2014 8:14 PM<br>
          >>> To: Jeffrey Lyon<br>
          >>> Cc: <a moz-do-not-send="true"
            href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a> List<br>
          >>> Subject: Re: [arin-ppml] Policy discussion -
          Method of calculating<br>
          >>> utilization<br>
          >>><br>
          >>> While I support Jeffry's proposal for changing
          the calculation<br>
          >>> method, in terms of changing the threshold, I'd
          like to say that I<br>
          >>> really think it is time to stop trying to
          re-arrange the IPv4 deck<br>
          >>> chairs and get on board the IPv6 luxury liners
          that have come to<br>
          >>> rescue us from the sinking IPv4 ship.<br>
          >>><br>
          >>> Owen<br>
          >>><br>
          >>> On May 2, 2014, at 6:04 PM, Jeffrey Lyon<br>
          >>> <<a moz-do-not-send="true"
            href="mailto:jeffrey.lyon@blacklotus.net">jeffrey.lyon@blacklotus.net</a>><br>
          >>> wrote:<br>
          >>><br>
          >>>> On Sat, May 3, 2014 at 9:52 AM, Jimmy Hess
          <<a moz-do-not-send="true" href="mailto:mysidia@gmail.com">mysidia@gmail.com</a>>
          wrote:<br>
          >>>>> On Fri, May 2, 2014 at 7:33 PM, John
          Santos <<a moz-do-not-send="true"
            href="mailto:JOHN@egh.com">JOHN@egh.com</a>> wrote:<br>
          >>>>>> On Fri, 2 May 2014, Jimmy Hess wrote:<br>
          >>>>>> I think 95% is too high, if the
          previous example of 3 /24's at<br>
          >>>>>> 100% and<br>
          >>>>>> 1 /24 at 75% is realistic.  That
          works out to 93.75% aggregate<br>
          >>>>>> utilization, not quite reaching the
          bar, so 90% might be a better<br>
          >>> threshold.<br>
          >>>>> For 3 /24s   yes.      The difficulty
          here, is trying to pick a single<br>
          >>>>> utilization proportion that works
          regardless   of the aggregate<br>
          >>>>> allocation size, to allow for the loss of
          the oddball /26 or /27 that<br>
          >>>>> can neither be returned nor reused,  
           perhaps another method is in<br>
          >>>>> order  than presuming a single  
          aggregate utilization criterion  is<br>
          >>>>> the most proper.<br>
          >>>>><br>
          >>>>><br>
          >>>>> The more resources you are allocated,
           the more opportunity to make<br>
          >>>>> your resource allocation efficient.    By
          the time you get down to a<br>
          >>>>> /26,   an entire  /24 is less than 0.4%.<br>
          >>>>><br>
          >>>>> Aggregate Resources Allocated            
                  Required Aggregate<br>
          >>>>> Utilization criterion<br>
          >>>>> more than a /25                          
                               75%<br>
          >>>>> more than a /22,                        
                                80%<br>
          >>>>> more than a /20                          
                               85%<br>
          >>>>> more than a /19                          
                               90%<br>
          >>>>> more than a /18                          
                               95%<br>
          >>>>> more than a /17                          
                               97%<br>
          >>>>> more than a /16                          
                               98%<br>
          >>>>> more than a /15                          
                               99%<br>
          >>>>><br>
          >>>>><br>
          >>>>><br>
          >>>>>> OTOH, /24's are pretty small and
          maybe that example was just for<br>
          >>>>>> illustration.  If people really in
          this situation have much<br>
          >>>>>> larger allocations, they would be
          easier to slice and dice and<br>
          >>>>>> thus use<br>
          >>>>>> (relatively) efficiently.  75% of a
          /24 leaves just 64 addresses<br>
          >>>>>> (a<br>
          >>>>>> /26) unused, which even if contiguous
          are hard to redeploy for<br>
          >>>>>> some other use.  75% of a /16 would
          leave 16384 unused addresses,<br>
          >>>>>> which<br>
          >>> could be utilized much more easily.<br>
          >>>>>><br>
          >>>>>> Personally, I don't much care since
          my company has its /24, and<br>
          >>>>>> that's probably all the IPv4 we'll
          ever need :-)<br>
          >>>>>><br>
          >>>>>><br>
          >>>>>> --<br>
          >>>>>> John Santos<br>
          >>>>>> Evans Griffiths & Hart, Inc.<br>
          >>>>>> 781-861-0670 ext 539<br>
          >>>>>><br>
          >>>>><br>
          >>>>><br>
          >>>>> --<br>
          >>>>> -JH<br>
          >>>>>
          _______________________________________________<br>
          >>>>> PPML<br>
          >>>>> You are receiving this message because
          you are subscribed to the<br>
          >>>>> ARIN Public Policy Mailing List (<a
            moz-do-not-send="true" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
          >>>>> Unsubscribe or manage your mailing list
          subscription at:<br>
          >>>>> <a moz-do-not-send="true"
            href="http://lists.arin.net/mailman/listinfo/arin-ppml"
            target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
          >>>>> Please contact <a moz-do-not-send="true"
            href="mailto:info@arin.net">info@arin.net</a> if you
          experience any issues.<br>
          >>>> Jimmy,<br>
          >>>><br>
          >>>> I would not support scaling this beyond 80%
          except at the larger<br>
          >>>> allocation levels (eg. perhaps /17 and
          shorter, aggregate).<br>
          >>>><br>
          >>>> As a practical matter I believe these
          measures should be handled as<br>
          >>>> separate policy proposals. The current
          proposal should be limited<br>
          >>>> to the calculation method and perhaps you
          could write a new<br>
          >>>> proposal if you wanted to change the
          utilization threshold?<br>
          >>>><br>
          >>>> Thanks,<br>
          >>>> --<br>
          >>>> Jeffrey A. Lyon, CISSP-ISSMP<br>
          >>>> Fellow, Black Lotus Communications<br>
          >>>> mobile: <a moz-do-not-send="true"
            href="tel:%28757%29%20304-0668" value="+17573040668">(757)
            304-0668</a> | gtalk: <a moz-do-not-send="true"
            href="mailto:jeffrey.lyon@gmail.com">jeffrey.lyon@gmail.com</a>
          | skype:<br>
          >>>> <a moz-do-not-send="true"
            href="http://blacklotus.net" target="_blank">blacklotus.net</a>
          _______________________________________________<br>
          >>>> PPML<br>
          >>>> You are receiving this message because you
          are subscribed to the<br>
          >>>> ARIN Public Policy Mailing List (<a
            moz-do-not-send="true" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
          >>>> Unsubscribe or manage your mailing list
          subscription at:<br>
          >>>> <a moz-do-not-send="true"
            href="http://lists.arin.net/mailman/listinfo/arin-ppml"
            target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
          >>>> Please contact <a moz-do-not-send="true"
            href="mailto:info@arin.net">info@arin.net</a> if you
          experience any issues.<br>
          >>> _______________________________________________<br>
          >>> PPML<br>
          >>> You are receiving this message because you are
          subscribed to the ARIN<br>
          >>> Public Policy Mailing List (<a
            moz-do-not-send="true" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
          >>> Unsubscribe or manage your mailing list
          subscription at:<br>
          >>> <a moz-do-not-send="true"
            href="http://lists.arin.net/mailman/listinfo/arin-ppml"
            target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
          >>> Please contact <a moz-do-not-send="true"
            href="mailto:info@arin.net">info@arin.net</a> if you
          experience any issues.<br>
          >><br>
          >> _______________________________________________<br>
          >> PPML<br>
          >> You are receiving this message because you are
          subscribed to the ARIN<br>
          >> Public Policy Mailing List (<a moz-do-not-send="true"
            href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
          >> Unsubscribe or manage your mailing list subscription
          at:<br>
          >> <a moz-do-not-send="true"
            href="http://lists.arin.net/mailman/listinfo/arin-ppml"
            target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
          >> Please contact <a moz-do-not-send="true"
            href="mailto:info@arin.net">info@arin.net</a> if you
          experience any issues.<br>
          ><br>
          ><br>
          > --<br>
          > Jeffrey A. Lyon, CISSP-ISSMP<br>
          > Fellow, Black Lotus Communications<br>
          > mobile: <a moz-do-not-send="true"
            href="tel:%28757%29%20304-0668" value="+17573040668">(757)
            304-0668</a> | gtalk: <a moz-do-not-send="true"
            href="mailto:jeffrey.lyon@gmail.com">jeffrey.lyon@gmail.com</a>
          | skype: <a moz-do-not-send="true"
            href="http://blacklotus.net" target="_blank">blacklotus.net</a>
          _______________________________________________<br>
          > PPML<br>
          > You are receiving this message because you are subscribed
          to the ARIN Public Policy Mailing List (<a
            moz-do-not-send="true" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
          > Unsubscribe or manage your mailing list subscription at:<br>
          > <a moz-do-not-send="true"
            href="http://lists.arin.net/mailman/listinfo/arin-ppml"
            target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
          > Please contact <a moz-do-not-send="true"
            href="mailto:info@arin.net">info@arin.net</a> if you
          experience any issues.<br>
          ><br>
          > _______________________________________________<br>
          > PPML<br>
          > You are receiving this message because you are subscribed
          to<br>
          > the ARIN Public Policy Mailing List (<a
            moz-do-not-send="true" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
          > Unsubscribe or manage your mailing list subscription at:<br>
          > <a moz-do-not-send="true"
            href="http://lists.arin.net/mailman/listinfo/arin-ppml"
            target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
          > Please contact <a moz-do-not-send="true"
            href="mailto:info@arin.net">info@arin.net</a> if you
          experience any issues.<br>
          <br>
          _______________________________________________<br>
          PPML<br>
          You are receiving this message because you are subscribed to<br>
          the ARIN Public Policy Mailing List (<a moz-do-not-send="true"
            href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
          Unsubscribe or manage your mailing list subscription at:<br>
          <a moz-do-not-send="true"
            href="http://lists.arin.net/mailman/listinfo/arin-ppml"
            target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
          Please contact <a moz-do-not-send="true"
            href="mailto:info@arin.net">info@arin.net</a> if you
          experience any issues.<br>
          _______________________________________________<br>
          PPML<br>
          You are receiving this message because you are subscribed to<br>
          the ARIN Public Policy Mailing List (<a moz-do-not-send="true"
            href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
          Unsubscribe or manage your mailing list subscription at:<br>
          <a moz-do-not-send="true"
            href="http://lists.arin.net/mailman/listinfo/arin-ppml"
            target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
          Please contact <a moz-do-not-send="true"
            href="mailto:info@arin.net">info@arin.net</a> if you
          experience any issues.<br>
        </blockquote>
      </div>
    </blockquote>
    <br>
  </body>
</html>