<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>"NOTE: IPv6 simple reassigns are only available in the <a
href="https://www.arin.net/resources/restful-interfaces.html">RESTful
web service</a>."</p>
<br>
<div class="moz-cite-prefix">On 7/25/2017 4:25 PM, Owen DeLong
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:D03DE1FA-2D95-4CB4-AD04-96903A26538E@delong.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
I think you’re misinterpreting something on that page. I might be
blind, but I don’t read anything on that page to say that IPv6
reassignments must be done by RESTful API.
<div class=""><br class="">
</div>
<div class="">I know that in practice you can do IPv6
reassignments via RWHOIS and I believe templates are also
supported as well as ARIN On-Line.</div>
<div class=""><br class="">
</div>
<div class="">Certainly the NRPM is the authoritative governing
document, so if there is a shortcoming in the process as
implemented such that it doesn’t line up with policy, the
correct response would be to bring this to staff’s attention and
request that they address it. However, to the best of my
knowledge, there is no such discrepancy.</div>
<div class=""><br class="">
</div>
<div class="">If you can highlight the portions of that page which
you believe to be errant in nature, I’m happy to try and work
with staff to make sure they get clarified.</div>
<div class=""><br class="">
</div>
<div class="">Owen</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jul 24, 2017, at 12:01 , 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="">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<p class=""><a class="moz-txt-link-freetext"
href="https://www.arin.net/resources/request/reassignments.html"
moz-do-not-send="true">https://www.arin.net/resources/request/reassignments.html</a></p>
<p class=""><br class="">
</p>
<br class="">
<div class="moz-cite-prefix">On 7/24/2017 1:28 PM, Owen
DeLong wrote:<br class="">
</div>
<blockquote type="cite"
cite="mid:2388FEC4-86C3-48CD-8BFD-B186E214828F@delong.com"
class="">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" class="">
<br class="">
<div class="">
<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 class=""><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 class=""><br class="">
</div>
<blockquote style="margin: 0 0 0 40px; border: none;
padding: 0px;" class="">
<div class="">6.5.5. Registration</div>
<div class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">6.5.5.1. Reassignment information</div>
<div class="">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 class=""><br class="">
</div>
<div class="">6.5.5.2. Assignments visible within 7
days</div>
<div class="">All assignments shall be made visible
as required in section 4.2.3.7.1 within seven
calendar days of assignment.</div>
<div class=""><br class="">
</div>
<div class="">6.5.5.3. Residential Subscribers</div>
<div class="">6.5.5.3.1. Residential Customer
Privacy</div>
<div class="">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 class=""><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 class="">
<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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">info@arin.net</a>
if you experience any issues.<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<br>
</body>
</html>