<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div><br>On Jul 25, 2017, at 15:46, Paul McNary <<a href="mailto:pmcnary@cameron.net">pmcnary@cameron.net</a>> wrote:<br><br></div><blockquote type="cite"><div>
  
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  
  
    Let me change "geolocation" to "address tracking".<br>
    For instance, Netflix blocks a certain region and whois is showing
    customer<br>
    in that region, whereas the customer is actually in a non-blocked
    region.<br>
    If I had my own IPv4 /24 or above I don't have any issue making this
    entry correct to ARIN.<br></div></blockquote><div><br></div>I know for a fact that Netflix bases very little (if any) of their geo-fencing on Whois data. <div><br><blockquote type="cite"><div>
    But I have a /25 block from a datacenter that shows I am in
    California.<br>
    Their SWIP policy on IPv4 is /24 to SWIP.<br>
    We are trying to minimize these issues as we deploy IPv6 when we
    have direct allocation.<br>
    I am not debating the "address tracking" issue just brought it up
    because I think John made a comment about it.<br></div></blockquote><div><br></div>I think if you review the record I stated early on that I didn't believe geolocation was a practical use of Whois. </div><div><br><blockquote type="cite"><div>
    We see ebay, amazon, craig's list all using whois information.<br></div></blockquote><div><br></div>Really? Source needed. </div><div><br></div><div>In my experience they use other geolocation providers. </div><div><br><blockquote type="cite"><div>
    Also our /25's have been blocked at the /24 and /18 level.<br>
    We had /24's blocked that are reallocated at the parent /18 level.<br>
    So unless there is some way to enforce, it just seems to be words on
    paper.<br></div></blockquote><div><br></div>Enforce what? Geolocation is a truly black art and there is no central clearing house or community driven policy body driving its practitioners. </div><div><br><blockquote type="cite"><div>
    <br>
    CHANGE of subject not topic<br>
    --------------------------------------<br>
    What I had wished to do on IPv6 deployment is assign an IPv6 /48 to
    each Tower(WISP), each POP(ISP)<br>
    I would want that switched as will as any individually announced
    block smaller than that.<br>
    Haven't decided but have a separate /48 to handle DNS, mail servers,
    etc. ie Our Infrastructure<br>
    Anything less specific that a /48 would just add noise to the world
    and would be somewhat proprietary.<br>
    I give away some info just advertising my POP's/Towers but I think
    that would be for the collective good. :-)<br>
    The world doesn't need to know my Access Points or neighborhood
    routers, etc.<br></div></blockquote><div><br></div>I see no reason you can't accomplish this under the proposed policy. I support the current draft as previously stated. </div><div><br></div><div><br></div><div>Owen</div><div><br></div><div><blockquote type="cite"><div>
     <br>
    I think I need to get off my soapbox and take a nap now!<br>
    I know I ramble a lot, but getting too old to change much! :-)<br>
    Thanks<br>
    Take care<br>
    Paul<br>
    <br>
    <div class="moz-cite-prefix">On 7/25/2017 5:17 PM, Scott Leibrand
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CAGkMwz4W8uaax9KcNM1fTbNhA=zSEJYuCGvVL7NxnumiP0-QyA@mail.gmail.com">
      <div dir="ltr">If I, as an End User network, want to inform
        geolocation providers of where I'm using each netblock, having
        them assigned to me in the whois DB with an appropriate address
        is one of the best ways to do that.  But if I'm running a
        geolocation service, I can't rely on whois as the sole source of
        data on where an address is used.  If I have other info that
        contradicts the whois information, I'd probably just ignore the
        whois data and go with the facts on the ground.
        <div><br>
        </div>
        <div>-Scott</div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Tue, Jul 25, 2017 at 3:12 PM, Paul
          McNary <span dir="ltr"><<a href="mailto:pmcnary@cameron.net" target="_blank" moz-do-not-send="true">pmcnary@cameron.net</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">Owen<br>
            Several weeks ago geolocation was one of the arguments for
            having accurate whois in this thread.<br>
            This is no longer being argued?<span class="HOEnZb"><font color="#888888"><br>
                Paul</font></span>
            <div class="HOEnZb">
              <div class="h5"><br>
                <br>
                On 7/25/2017 4:26 PM, Owen DeLong wrote:<br>
                <blockquote class="gmail_quote" style="margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  Huh?<br>
                  <br>
                  WHOIS is not a geolocation service and anyone who
                  thinks it is should reduce their use of recreational
                  pharmaceuticals.<br>
                  <br>
                  Owen<br>
                  <br>
                  <blockquote class="gmail_quote" style="margin:0 0 0
                    .8ex;border-left:1px #ccc solid;padding-left:1ex">
                    On Jul 24, 2017, at 12:03 , Paul McNary <<a href="mailto:pmcnary@cameron.net" target="_blank" moz-do-not-send="true">pmcnary@cameron.net</a>>
                    wrote:<br>
                    <br>
                    Then that totally negates the reasoning for
                    geolocation.<br>
                    The administrative address could be on the other
                    side of the earth.<br>
                    <br>
                    Paul<br>
                    <br>
                    <br>
                    On 7/24/2017 1:31 PM, Owen DeLong wrote:<br>
                    <blockquote class="gmail_quote" style="margin:0 0 0
                      .8ex;border-left:1px #ccc solid;padding-left:1ex">
                      <blockquote class="gmail_quote" style="margin:0 0
                        0 .8ex;border-left:1px #ccc
                        solid;padding-left:1ex">
                        On Jul 20, 2017, at 14:28 , <a href="mailto:hostmaster@uneedus.com" target="_blank" moz-do-not-send="true">hostmaster@uneedus.com</a>
                        wrote:<br>
                        <br>
                        My transit bus example is another example of
                        SWIP difficulty.  Very hard to provide a street
                        address to SWIP a bus when it is mobile 16 hours
                        a day.<br>
                      </blockquote>
                      Not at all. A bus would be SWIPd to the bus yard
                      or administrative offices of the bus company. The
                      SWIP data is not required to be the service
                      address, it is required to be an address for
                      administrative and/or technical contact regarding
                      the network and/or legal process service regarding
                      same.<br>
                      <br>
                      [rest trimmed because we are in agreement on that
                      part]<br>
                      <br>
                      Owen<br>
                      <br>
                      <blockquote class="gmail_quote" style="margin:0 0
                        0 .8ex;border-left:1px #ccc
                        solid;padding-left:1ex">
                        On Thu, 20 Jul 2017, Chris James wrote:<br>
                        <blockquote class="gmail_quote" style="margin:0
                          0 0 .8ex;border-left:1px #ccc
                          solid;padding-left:1ex">
                          @Paul - The API key is to email it.<br>
                          <br>
                          @Owen - Very difficult when you have dynamic
                          ranges, and vps/container<br>
                          platforms spanning tens of thousands of
                          instances across these dynamic<br>
                          ranges.<br>
                          <br>
                          <br>
                          On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary
                          <<a href="mailto:pmcnary@cameron.net" target="_blank" moz-do-not-send="true">pmcnary@cameron.net</a>>
                          wrote:<br>
                          <br>
                          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px
                            #ccc solid;padding-left:1ex">
                            Owen<br>
                            <br>
                            The reassignment policy page says IPv6 has
                            to be done vi API.<br>
                            Is that something else that is incorrect on
                            the web site?<br>
                            <br>
                            Paul<br>
                            <br>
                            <br>
                            On 7/20/2017 3:16 PM, Owen DeLong wrote:<br>
                            <br>
                            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px
                              #ccc solid;padding-left:1ex">
                              How can it be overly difficult to fill out
                              an email template with your<br>
                              customers’<br>
                              Name, Address, Phone Number?<br>
                              <br>
                              Really?<br>
                              <br>
                              Owen<br>
                              <br>
                              On Jul 19, 2017, at 23:48 , Pallieter
                              Koopmans <<a href="mailto:Pallieter@pallieter.org" target="_blank" moz-do-not-send="true">Pallieter@pallieter.org</a>><br>
                              <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px
                                #ccc solid;padding-left:1ex">
                                wrote:<br>
                                <br>
                                Hello,<br>
                                <br>
                                ARIN could quantify and require rules
                                for when to SWIP, but in the<br>
                                end, there are going to be exceptions
                                needed if the rules are to be<br>
                                strictly followed. Many will not
                                separately SWIP a separately routed<br>
                                sub-block if it is too difficult or
                                pointless to gather and share that<br>
                                data back upstream to ARIN.<br>
                                <br>
                                Thus a more fuzzy rule to require a
                                best-effort and to add a<br>
                                rule-based reason (preferably both a
                                carrot and a stick) for block<br>
                                owners to do their best to provide
                                (only) useful data. In order to do<br>
                                that, one needs to look back at why that
                                data is needed. For a block<br>
                                owner to assign the SWIP on a sub-block,
                                he basically delegates tech<br>
                                and abuse contact requests down to those
                                that are probably more likely<br>
                                to be able to actually act on the
                                tech/abuse requests (and thus reduce<br>
                                request-handling workload higher up and
                                overall). But for that to<br>
                                work, those tech/abuse contact requests
                                need to be actually handled,<br>
                                otherwise, it is better to leave them
                                with the block owner.<br>
                                <br>
                                In the end, the contact details should
                                be as close to the "person"<br>
                                that is actually capable to both handle
                                (think: volume/languages/etc)<br>
                                and act (think: authority) on the
                                tech/abuse requests.<br>
                                <br>
                                eBrain<br>
                                Innovative Internet Ideas<br>
                                <br>
                                Pallieter Koopmans<br>
                                Managing Director<br>
                                <br>
                                <a href="tel:%2B31-6-3400-3800" value="+31634003800" target="_blank" moz-do-not-send="true">+31-6-3400-3800</a> (mon-sat
                                9-22 CET)<br>
                                Skype: PallieterKoopmans<br>
                                ______________________________<wbr>_________________<br>
                                PPML<br>
                                You are receiving this message because
                                you are subscribed to<br>
                                the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
                                Unsubscribe or manage your mailing list
                                subscription at:<br>
                                <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
                                Please contact <a href="mailto:info@arin.net" target="_blank" moz-do-not-send="true">info@arin.net</a>
                                if you experience any issues.<br>
                                <br>
                              </blockquote>
                              ______________________________<wbr>_________________<br>
                              PPML<br>
                              You are receiving this message because you
                              are subscribed to<br>
                              the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
                              Unsubscribe or manage your mailing list
                              subscription at:<br>
                              <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
                              Please contact <a href="mailto:info@arin.net" target="_blank" moz-do-not-send="true">info@arin.net</a>
                              if you experience any issues.<br>
                              <br>
                            </blockquote>
                            ______________________________<wbr>_________________<br>
                            PPML<br>
                            You are receiving this message because you
                            are subscribed to<br>
                            the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
                            Unsubscribe or manage your mailing list
                            subscription at:<br>
                            <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
                            Please contact <a href="mailto:info@arin.net" target="_blank" moz-do-not-send="true">info@arin.net</a>
                            if you experience any issues.<br>
                          </blockquote>
                          -- <br>
                          This e-mail message may contain confidential
                          or legally privileged<br>
                          information and is intended only for the use
                          of the intended recipient(s).<br>
                          Any unauthorized disclosure, dissemination,
                          distribution, copying or the<br>
                          taking of any action in reliance on the
                          information herein is prohibited.<br>
                          E-mails are not secure and cannot be
                          guaranteed to be error free as they<br>
                          can be intercepted, amended, or contain
                          viruses. Anyone who communicates<br>
                          with us by e-mail is deemed to have accepted
                          these risks. This company is<br>
                          not responsible for errors or omissions in
                          this message and denies any<br>
                          responsibility for any damage arising from the
                          use of e-mail. Any opinion<br>
                          and other statement contained in this message
                          and any attachment are solely<br>
                          those of the author and do not necessarily
                          represent those of the company.<br>
                        </blockquote>
                        ______________________________<wbr>_________________<br>
                        PPML<br>
                        You are receiving this message because you are
                        subscribed to<br>
                        the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
                        Unsubscribe or manage your mailing list
                        subscription at:<br>
                        <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
                        Please contact <a href="mailto:info@arin.net" target="_blank" moz-do-not-send="true">info@arin.net</a>
                        if you experience any issues.<br>
                      </blockquote>
                      ______________________________<wbr>_________________<br>
                      PPML<br>
                      You are receiving this message because you are
                      subscribed to<br>
                      the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
                      Unsubscribe or manage your mailing list
                      subscription at:<br>
                      <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
                      Please contact <a href="mailto:info@arin.net" target="_blank" moz-do-not-send="true">info@arin.net</a>
                      if you experience any issues.<br>
                    </blockquote>
                  </blockquote>
                  <br>
                  <br>
                </blockquote>
                <br>
                ______________________________<wbr>_________________<br>
                PPML<br>
                You are receiving this message because you are
                subscribed to<br>
                the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
                Unsubscribe or manage your mailing list subscription at:<br>
                <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
                Please contact <a href="mailto:info@arin.net" target="_blank" moz-do-not-send="true">info@arin.net</a>
                if you experience any issues.</div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  

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