<div dir="ltr">Well I think in the bus example you would swip to the overall authority. But seriously this conversation has gone in so many different directions do any of us remember the original point?<div><br></div><div>My vote as it applies to v6: Non-residential allocations of greater than or equal to a /48.</div><div><br></div><div>If you as an ISP choose to allocate a /48 to a residential customer - then have fun. But this does not affect the purpose of the policy as most use it these days which is abuse management. Also as I understand it, there is an exception to the CPNI as it applies to business customers as long as they have an account manager and adequate language in the contract. How many of the smaller ISPs have a customer deserving of a /48 or better that does not have a larger account or spend? If a customer requests a large enough block from us, regardless of v4 vs v6, they agree via email/ticketing/contract that their business information will be made public. This is not difficult to put in your signed agreements with your business customers thus making the CPNI argument invalid.</div><div><br></div><div>-Chris</div><div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="text-align:left"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p style="margin:0in 0in 0.0001pt;background-image:initial;background-position:initial;background-repeat:initial"><span></span></p><span><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><span><div dir="ltr"><br></div></span></div></div></div></div></div></div></div></div></div></span></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Jul 20, 2017 at 2:28 PM,  <span dir="ltr"><<a href="mailto:hostmaster@uneedus.com" target="_blank">hostmaster@uneedus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
<br>
Current policy says SWIP every /64 or more, which is every network in v6.<br>
<br>
I did a check here, and in v4, only 1% of customers have more than 8 ip's, and these customers are colocation customers who have a bunch of SSL sites.  These are grandfathered. New customers are told to use 1 IPv4 address and SNI or better yet, IPv6, as we do not have the money to buy more V4.  We would rather use our v4 inventory for access customers.<br>
<br>
Yes, it is just a few pieces of information for SWIP.  However, we do not have clerical staff to do it, because except for the SSL colocates, there never has been v4 SWIP's required here. Why should the policy state that just because we give each customer an assignment of v6, we must SWIP that same small customer that did not require SWIP in v4? (Welcome to IPv6, now fill out this form.....) Also noted is that the SWIP registration details without written permission might get us in trouble with the FCC over CPNI. As a WISP that has licensed microwave links, we do pay attention to Uncle Charlie.<br>
<br>
Albert Erdmann<br>
Network Administrator<br>
Paradise On Line Inc.<br>
<br>
On Thu, 20 Jul 2017, Chris James wrote:<br>
<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">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">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">+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">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">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">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">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">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<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">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">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote>
<br><span class="HOEnZb"><font color="#888888">
-- <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>
</font></span></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">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">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br></blockquote></div><br></div></div></div>

<br>
<font size="1" style="background-color:white"><span style="font-family:Arial,sans-serif"><span style="font:9px/11px Helvetica,Arial,sans-serif;color:rgb(153,153,153);text-transform:none;text-indent:0px;letter-spacing:normal;word-spacing:0px;float:none;display:inline!important;white-space:normal;background-color:rgb(255,255,255)">This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. This company is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.</span></span></font>