[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6
owen at delong.com
Mon Jul 24 14:28:06 EDT 2017
> On Jul 20, 2017, at 13:51 , Paul McNary <pmcnary at cameron.net> wrote:
> The reassignment policy page says IPv6 has to be done vi API.
> Is that something else that is incorrect on the web site?
I’m not sure what the “reassignment policy page” you refer to is, but here’s the quote from the NRPM:
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.
22.214.171.124. 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.
126.96.36.199. Assignments visible within 7 days
All assignments shall be made visible as required in section 188.8.131.52.1 within seven calendar days of assignment.
184.108.40.206. Residential Subscribers
220.127.116.11.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 18.104.22.168 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 22.214.171.124.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?
> 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?
>>> On Jul 19, 2017, at 23:48 , Pallieter Koopmans <Pallieter at pallieter.org> wrote:
>>> 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.
>>> Innovative Internet Ideas
>>> Pallieter Koopmans
>>> Managing Director
>>> +31-6-3400-3800 (mon-sat 9-22 CET)
>>> Skype: PallieterKoopmans
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> Please contact info at arin.net if you experience any issues.
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> Please contact info at arin.net if you experience any issues.
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ARIN-PPML