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 <scottleibr...@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 <far...@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-i...@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:far...@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@arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschil...@google.com|571-266-0006
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.