"NOTE: IPv6 simple reassigns are only available in the RESTful web
service <https://www.arin.net/resources/restful-interfaces.html>."
On 7/25/2017 4:25 PM, Owen DeLong wrote:
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.
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.
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.
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.
Owen
On Jul 24, 2017, at 12:01 , Paul McNary <[email protected]
<mailto:[email protected]>> wrote:
https://www.arin.net/resources/request/reassignments.html
On 7/24/2017 1:28 PM, Owen DeLong wrote:
On Jul 20, 2017, at 13:51 , Paul McNary <[email protected]
<mailto:[email protected]>> wrote:
Owen
The reassignment policy page says IPv6 has to be done vi API.
Is that something else that is incorrect on the web site?
Paul
I’m not sure what the “reassignment policy page” you refer to is,
but here’s the quote from the NRPM:
6.5.5. Registration
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.
6.5.5.1. Reassignment information
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.
6.5.5.2. Assignments visible within 7 days
All assignments shall be made visible as required in section
4.2.3.7.1 within seven calendar days of assignment.
6.5.5.3. Residential Subscribers
6.5.5.3.1. Residential Customer Privacy
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.
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.
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.
Given that, can you clarify your above statement?
Owen
On 7/20/2017 3:16 PM, Owen DeLong wrote:
How can it be overly difficult to fill out an email template with
your customers’
Name, Address, Phone Number?
Really?
Owen
On Jul 19, 2017, at 23:48 , Pallieter Koopmans
<[email protected] <mailto:[email protected]>> wrote:
Hello,
ARIN could quantify and require rules for when to SWIP, but in the
end, there are going to be exceptions needed if the rules are to be
strictly followed. Many will not separately SWIP a separately routed
sub-block if it is too difficult or pointless to gather and share
that
data back upstream to ARIN.
Thus a more fuzzy rule to require a best-effort and to add a
rule-based reason (preferably both a carrot and a stick) for block
owners to do their best to provide (only) useful data. In order to do
that, one needs to look back at why that data is needed. For a block
owner to assign the SWIP on a sub-block, he basically delegates tech
and abuse contact requests down to those that are probably more
likely
to be able to actually act on the tech/abuse requests (and thus
reduce
request-handling workload higher up and overall). But for that to
work, those tech/abuse contact requests need to be actually handled,
otherwise, it is better to leave them with the block owner.
In the end, the contact details should be as close to the "person"
that is actually capable to both handle (think: volume/languages/etc)
and act (think: authority) on the tech/abuse requests.
eBrain
Innovative Internet Ideas
Pallieter Koopmans
Managing Director
+31-6-3400-3800 (mon-sat 9-22 CET)
Skype: PallieterKoopmans
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]
<mailto:[email protected]>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]
<mailto:[email protected]>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]
<mailto:[email protected]>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
