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

Tue Jul 25 18:11:03 EDT 2017

"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 <pmcnary at cameron.net 
>> <mailto:pmcnary at cameron.net>> 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 <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/20170725/111acbc4/attachment.htm>