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

[Jason Schiller]

David, Tony, Thank you for bringing up the IPS must SWIP when address user
asks.

Scott, Thank you for putting the changes in context.


I oppose as written.  I support with the David/Tony friendly admendment.

Why?
> It should be required for an ISP to SWIP / Rwhois any reassignment
> when the down stream address user has requested such.
>
> It is sometimes useful to SWIP the reassignemnts to the down stream
> organization so that the down stream organization can provide their abuse
> contact or technical support contact info, or public comments.
>
> I fear without my friendly amendment the policy change may send
> the wrong message and suggest that an ISP can safely conclude
> that if they are never going to support mutli-homing, and if they never
> give out anything larger than a /48, that they do not need to support the
> facility to SWIP at all, and can openly refuse all SWIPs for IPv6
> re-assignments.

Possible simple text addition:

On Fri, Jul 21, 2017 at 1:34 PM, Scott Leibrand <scottleibrand at gmail.com>
 wrote:
>
>
> For clarity, so we don't all have to do it, and to help make sure we're
> not missing anything, here's what the resulting 6.5.5 looks like after
> modification:
>
> 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. Re-allocation / Reassignment information
>
>
Each of the following

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.
>

> - static IPv6 re-assignment containing a /47 or more addresses,
>
-  sub-delegation of any size that will be individually announced,
- any re-assignment where the address holder specifically requests a
reassign simple, reassign detail, or (if applicable) privacy registration
- re-allocations of any size


> 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 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.
>
> -Scott
>
>
I'd like to (mostly) stay out of the MUST/SHOULD discussion wrt
the requirement to SWIP if the intent is to route.
I prefer MUST over SHOULD and SHOULD over no advice.
I feel strongly that at the least the advice should be preserved.

__Jason





On Mon, Jul 24, 2017 at 5:07 PM, David Farmer <farmer at umn.edu> wrote:

> Honestly, I could live with it just those three lines.  However, I'm
> willing to recognize at least the possibility there is a legitimate
> community interest in having records for assignments that are shorter than
> /48.
>
> As for IPv4, I'd also be just fine with those three lines.  Again,
> recognizing at least the possibility there is a legitimate community
> interest in having records for assignments that are shorter than /24
>
> On Mon, Jul 24, 2017 at 2:51 PM, Tony Hain <alh-ietf at tndh.net> wrote:
>
>> While I agree with the general direction David is heading, his text is
>> still overly complex to deal with the goal. This whole thread only requires
>> 3 lines:
>>
>>
>>
>> Reallocations MUST provide SWIP.
>>
>> Requests by the assignee MUST provide SWIP.
>> Anything appearing independently in the global routing table SHOULD
>> provide SWIP.
>>
>>
>>
>> All the rest is noise that doesn’t add to solving any problem known to
>> mankind, and is simply an artifact of the IPv4-think insane conservation
>> mindset. Size is irrelevant in both protocol versions, and even if you
>> think it is, the only time it comes up is in #3. In any case the length of
>> #3 might change over time, and there is no reason the policy text needs to
>> change to track it. If something is independent, no matter what it’s length
>> is, the intent is to have accurate contact info.
>>
>>
>>
>> Saying anything more is trying to legislate ISP behavior, which is
>> explicitly outside the scope of ARIN.
>>
>>
>>
>> Tony
>>
>
>
> --
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
> ===============================================
>
> _______________________________________________
> PPML
> 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:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170726/5fd41d96/attachment.htm>