[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21
jschiller at google.com
Wed Jul 26 13:47:29 EDT 2017
David, Tony, Thank you for bringing up the IPS must SWIP when address user
Scott, Thank you for putting the changes in context.
I oppose as written. I support with the David/Tony friendly admendment.
> 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
Possible simple text addition:
On Fri, Jul 21, 2017 at 1:34 PM, Scott Leibrand <scottleibrand at gmail.com>
> 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
> 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.
> 22.214.171.124. 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
> 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 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'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.
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
> 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.
> 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>
> 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.
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ARIN-PPML