<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><a class="moz-txt-link-freetext" href="https://www.arin.net/resources/request/reassignments.html">https://www.arin.net/resources/request/reassignments.html</a></p>
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 7/24/2017 1:28 PM, Owen DeLong
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:2388FEC4-86C3-48CD-8BFD-B186E214828F@delong.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jul 20, 2017, at 13:51 , Paul McNary <<a
href="mailto:pmcnary@cameron.net" class=""
moz-do-not-send="true">pmcnary@cameron.net</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Owen<br class="">
<br class="">
The reassignment policy page says IPv6 has to be done vi
API.<br class="">
Is that something else that is incorrect on the web site?<br
class="">
<br class="">
Paul<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
I’m not sure what the “reassignment policy page” you refer to
is, but here’s the quote from the NRPM:</div>
<div><br class="">
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding:
0px;" class="">
<div>6.5.5. Registration</div>
<div><br class="">
</div>
<div>ISPs are required to demonstrate efficient use of IP
address space allocations by providing appropriate
documentation, including but not limited to assignment
histories, showing their efficient use.</div>
<div><br class="">
</div>
<div>6.5.5.1. Reassignment information</div>
<div>Each static IPv6 assignment containing a /64 or more
addresses shall be registered in the WHOIS directory via SWIP
or a distributed service which meets the standards set forth
in section 3.2. Reassignment registrations shall include each
client's organizational information, except where specifically
exempted by this policy.</div>
<div><br class="">
</div>
<div>6.5.5.2. Assignments visible within 7 days</div>
<div>All assignments shall be made visible as required in
section 4.2.3.7.1 within seven calendar days of assignment.</div>
<div><br class="">
</div>
<div>6.5.5.3. Residential Subscribers</div>
<div>6.5.5.3.1. Residential Customer Privacy</div>
<div>To maintain the privacy of their residential customers, an
organization with downstream residential customers holding /64
and larger blocks may substitute that organization's name for
the customer's name, e.g. 'Private Customer - XYZ Network',
and the customer's street address may read 'Private
Residence'. Each private downstream residential reassignment
must have accurate upstream Abuse and Technical POCs visible
on the WHOIS record for that block.</div>
<div><br class="">
</div>
</blockquote>
I’ll call your attention to the phrase in 6.5.5.1 which states
"registered in the WHOIS directory via SWIP or a distributed
service which meets the standards set forth in section 3.2” which
at this point includes (IIRC) SWIP, RestFUL API, RWHOIS, and
possibly RDAP.
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">I’ll also note that 6.5.5.3.1 provides for the
residential customer privacy as I defined it, regardless of the
mechanism used to make the data available.</div>
<div class=""><br class="">
</div>
<div class="">Given that, can you clarify your above statement?</div>
<div class=""><br class="">
</div>
<div class="">Owen</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">
<div class=""><br class="">
<br class="">
On 7/20/2017 3:16 PM, Owen DeLong wrote:<br class="">
<blockquote type="cite" class="">How can it be overly
difficult to fill out an email template with your
customers’<br class="">
Name, Address, Phone Number?<br class="">
<br class="">
Really?<br class="">
<br class="">
Owen<br class="">
<br class="">
<blockquote type="cite" class="">On Jul 19, 2017, at
23:48 , Pallieter Koopmans <<a
href="mailto:Pallieter@pallieter.org" class=""
moz-do-not-send="true">Pallieter@pallieter.org</a>>
wrote:<br class="">
<br class="">
Hello,<br class="">
<br class="">
ARIN could quantify and require rules for when to
SWIP, but in the<br class="">
end, there are going to be exceptions needed if the
rules are to be<br class="">
strictly followed. Many will not separately SWIP a
separately routed<br class="">
sub-block if it is too difficult or pointless to
gather and share that<br class="">
data back upstream to ARIN.<br class="">
<br class="">
Thus a more fuzzy rule to require a best-effort and
to add a<br class="">
rule-based reason (preferably both a carrot and a
stick) for block<br class="">
owners to do their best to provide (only) useful
data. In order to do<br class="">
that, one needs to look back at why that data is
needed. For a block<br class="">
owner to assign the SWIP on a sub-block, he
basically delegates tech<br class="">
and abuse contact requests down to those that are
probably more likely<br class="">
to be able to actually act on the tech/abuse
requests (and thus reduce<br class="">
request-handling workload higher up and overall).
But for that to<br class="">
work, those tech/abuse contact requests need to be
actually handled,<br class="">
otherwise, it is better to leave them with the block
owner.<br class="">
<br class="">
In the end, the contact details should be as close
to the "person"<br class="">
that is actually capable to both handle (think:
volume/languages/etc)<br class="">
and act (think: authority) on the tech/abuse
requests.<br class="">
<br class="">
eBrain<br class="">
Innovative Internet Ideas<br class="">
<br class="">
Pallieter Koopmans<br class="">
Managing Director<br class="">
<br class="">
+31-6-3400-3800 (mon-sat 9-22 CET)<br class="">
Skype: PallieterKoopmans<br class="">
_______________________________________________<br
class="">
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=""
moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br
class="">
Unsubscribe or manage your mailing list subscription
at:<br class="">
<a
href="http://lists.arin.net/mailman/listinfo/arin-ppml"
class="" moz-do-not-send="true">http://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>
_______________________________________________<br
class="">
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=""
moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br
class="">
Unsubscribe or manage your mailing list subscription
at:<br class="">
<a
href="http://lists.arin.net/mailman/listinfo/arin-ppml"
class="" moz-do-not-send="true">http://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>
<br class="">
_______________________________________________<br
class="">
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=""
moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br
class="">
Unsubscribe or manage your mailing list subscription at:<br
class="">
<a
href="http://lists.arin.net/mailman/listinfo/arin-ppml"
class="" moz-do-not-send="true">http://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="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<br>
</body>
</html>