[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

[Paul McNary]

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 <pmcnary at cameron.net 
>> <mailto:pmcnary at cameron.net>> 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 
>>>> <Pallieter at pallieter.org <mailto:Pallieter at pallieter.org>> 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 (ARIN-PPML at arin.net 
>>>> <mailto:ARIN-PPML at arin.net>).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net 
>>> <mailto:ARIN-PPML at arin.net>).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net 
>> <mailto:ARIN-PPML at arin.net>).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170724/09a09011/attachment.htm>