Richard J Letts wrote: > I believe we should SWIP for /48. > I believe we may SWIP for /56 or longer if the Service provider deems it > useful.
Effectively, length is irrelevant. SWIP to the responsible & responsive network operator. > > As an example we assign /48's to school districts, So you believe in forced-renumbering ... You SHOULD be assigning blocks to school districts sufficient that they can reassign a /48 to each school. > colleges, and universities in > the State of Washington. A college/university is a service provider to their student clients. They SHOULD be assigned blocks large enough to reassign a /48 to each of their customers, as any other service provider. > I want each of them to have their own SWIP > records so any issues with traffic originating from the site can get addressed > by the local network administrators before they get escalated up to me as > the WA-K20 NOC manager. I agree that this is the appropriate use of SWIP, but it has absolutely nothing to do with prefix length. > We do not advertise separate routing for most of these /48 -- I do not want > any linkage between SWIP and routing. While the unadvertised case is a local call, I assume you would want the ability to find contact info for a prefix that was independently routed in the global table.?.?. > Stating SWIP is not required for /48 leaves me open to them asking me not to > SWIP (for some reason), and it is absolutely not the same as /32 SWIP in v4. So establish a firm policy that for DMCA and any other jurisdictionally appropriate legal tracking; all assignments are published, period. Length has nothing to do with it. While I agree that it is often handy to have a 3rd party policy to resolve local political issues, in this case DMCA is useful, and avoids the need to have overly restrictive ARIN policy that impacts everyone else. Tony > > Thank you > > Richard Letts > Manager: Network Operations Center: WA-K20, UW, UW Medicine, PNWGP, > PWAVE, WRN > > > -----Original Message----- > > From: ARIN-PPML [mailto:[email protected]] On Behalf Of > > [email protected] > > Sent: Thursday, July 27, 2017 10:10 AM > > To: [email protected] > > Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of > > Assignment Registration requirements between IPv4 and IPv6 - updated > > 2017-07-21 > > > > I agree that we need to act on THIS draft, and not load up the > > discussion with other issues that this draft is not intended to > > address. The one question regarding SWIP/WHOIS policy in general I > > have moved to another thread since it is unrelated to this draft. > > > > This draft is about changing the Assignment Registration rules to > > allow minimum static assigments of IPv6 space to be made most of the > > time without triggering a SWIP requirement. Current policy is > > effectively 100% registration, which is not true for the same customer using > IPv4. > > > > After discussing changing the standard from /64 to /60 or /56, we > > appear to have agreed that the end user site minimum assignment should > > be /48, and that operators should not be assigning less. > > > > The last draft has language that I understood to have the effect of: > > > > * /47 or more MUST SWIP, as these sizes are larger than an end user. > > > > * Any size that is separately routed, which under most routing > > policies would be a /48 or larger, shall also SWIP. This also leaves > > the decision as to what level is routed to others, as this is not an ARIN > decision. > > > > * Otherwise SWIP is not required for a /48, as this size is the basic > > end user or site assignment, similar to demanding /32 SWIP's in v4. > > > > There has also been some discussion that the current draft language > > does not reflect the above concepts, and suggesting changes. These are in > scope. > > However problems with SWIP, WHOIS, abuse, etc are not in scope for > > this draft, and are not helpful in deciding what we need to have in > > this draft. If there are others that seek to fix these other issues, > > lets have them propose a different draft to do so, rather than trying to > insert that here into this one. > > > > Albert Erdmann > > Network Administrator > > Paradise On Line Inc. > > > > > > On Thu, 27 Jul 2017, Jason Schiller wrote: > > > > > > three points: > > > 1. This proposal is not trying to address the problem of how ISPs > > > handle abuse. > > > > > > If that is a problem the community wants to tackle, lets define the > > > problem and propose policy in a DIFFERENT proposal > > > > > > 2. I do not believe the suggested changes impact how ISPs handle abuse. > > > > > > How ISPs handle abuse is orthogonal to this proposal. > > > > > > 3. How ISPs handle abuse is complicated and opaque and requires more > > > nuance and clarity about what is actually required for compliance. > > > > > > > > > As is said before compliance tends to be very good when it is either > > > required, or beneficial to the organization. > > > > > > > > > If an organization is trying in good faith, to follow ARIN rules, > > > then they will try to keep SWIP information for their networks > > > accurate, as well as for their down stream customers. > > > > > > There is no ARIN requirement that a provider need to process or > > > respond to abuse complaints on their network space, nor that they > > > take action on downstream customers who fail to process abuse > complaints. > > > > > > In some cases their are particular legal rules in particular > > > countries that some types of abuse complaints are required to be > > > processed, for example legal take down requests. I suspect you will > > > find very high compliance in processing these types of abuse complaints. > > > > > > In other cases there are unwritten standards of conduct that when > > > violated results in a TOS agreement violation leading to loss of > > > service. I suspect you will find a wide mix in terms of what is > > > permitted under various TOS (although generally it is expected that > > > the requirements are at least as strict for down stream > > > customers) > > > as well as a wide mix on level of compliance in processing TOS abuse > > > complaints. > > > > > > In yet other cases, media agreements will contractually require DMCA > > > violations to be processed. These are often completed by a > > > pre-defined process and not through > > > abuse@ email contact. These will also have a wide range of compliance > > > directly > > > proportional to the strength of the contract and importance of the > > > media agreement. > > > > > > In yet other cases there is an unwritten standard of conduct that > > > when violated results in being published on a black list. This also > > > has a wide mix in terms of what is needed to be added and removed > > > from the blacklist. Furthermore there is a wide mix of > > > corresponding behavior by blacklisted organizations from > > > aggressively cleaning up black listed space and maintain a positive > > > reputation (and usable IP space for its customers), to organizations that > do not engage black listers. > > > Often times innocent customers are caught in the middle, and network > > > abusers move on to new IP space often with newly stolen credentials, > > > with very little that well meaning providers can do to prevent > > > re-occurrence. > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN > > Public Policy Mailing List ([email protected]). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact [email protected] if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
