[arin-ppml] Discussion on elimination of SWIP requirements.

hostmaster at uneedus.com hostmaster at uneedus.com
Fri Jun 2 15:34:11 EDT 2017

I for one do not see why a suggestion is HORRIBLE.

Of course, SWIP, like any other issue is not black and white.  There is a 
big difference between the current policy of requiring the registration of 
/29 or more of v4 and /64 or more of v6, and a different suggestion to ban 
SWIP servers.

I see the proposal as more of changing the requirements of operators, such 
that if an operator wants to continue SWIP for its assignments, it would 
be free to do so, but other operators who may see this process as 
duplicate and a waste of time might elect to not do so.  Others might 
elect to continue to maintain SWIP for DMCA or other reasons to reduce ISP 
workload, or that operators belief in transparency.

I would not support a proposal that would ban SWIP. Operators should be 
free to continue to do so, as long as it is disclosed to their customers. 
Looking at the future of no more IPv4 except the transfer market, the fact 
that this process will also run out at some point, and that IPv6 will be 
the protocol of the future, a serious look at the real need for SWIP is 

Generally SWIP is used by ARIN to justify qualifications for IP space. 
For the community, SWIP is used to find out contacts for dealing with 
network connectivity issues, security and spam.  Only the first purpose is 
part of the ARIN policies.  Only the second part is used by operators.

Because a /32 of v6 space is so large, almost all operators who have 
obtained their block of space is never going to be going back for more. 
Thus, I suggest a compromise might be to stop requiring SWIP for v6, 
except in the case of those operators who need completed SWIP records to 
justify expanding their v6 allocation.

By elimination of the SWIP requirement for v6 assignments for operators 
not intending to expand beyond their initial block, this would kinda give 
us a test bed to find out if lack of SWIP causes any real issues. 
Personally, I doubt this will make any real difference, as there is many 
operators who currently ignore SWIP for both protocols.  After such a 
test, the next step would eliminate the v4 SWIP requirement, or the 
community might let it die as v6 becomes the primary protocol.

Remember, those who have actual allocations with ARIN will continue to be 
recorded in the normal whois, and those contacts can still be used for 
contact with operators who have elected not to populate SWIP with data.

I tend to think, just like the discussion over POC indirect contact data, 
that ARIN needs to use all its time on the resources that it has directly 
assigned, and not waste staff time on SWIP, or indirect contacts, which 
are really 2 ways of talking about the same group of people, those that 
have received assignments from their ISP of address space.

Keeping the Whois clean is hard enough with those with direct resources, 
why not limit ARIN staff time to the Direct resources.

Further, if SWIP is to continue, ISP's should not be able to add contacts 
such as email and phone numbers without the express permission of their 
customers as to what email and phone number to use.  One of the persons 
commenting at New Orleans was against removing the indirect POC annual 
notice, because it was the only way he was discovering the many POC 
records created for his organization without his direct knowledge. Instead 
of getting his permission, and telling the ISP what handle to use for the 
contact, each of his upstream ISP's around the world have been instead 
creating a new handle for this organization, leaving him to clean up the 

He should have instead been complaining as to why ARIN allows each of 
these ISP's to add a contact handle without the permission of the person 
added.  Even the PPML requires verification the person wanted to be added 
before the PPML emails are received. Why should the creation of a POC 
handle in whois or SWIP be any different?

By putting a process in place that requires advance consent before the POC 
goes into the database, at least the customer can control their destiny. 
Many Orgs use a specific Role handle for these types of emails, and in 
many cases email addresses that were never intended to be widely use end 
up in the database without the customer knowledge.

Back to specifics, what "HORRIBLE" things are likely to happen if SWIP 
were to go away?  Lets talk.

Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Fri, 2 Jun 2017, Michael Peddemors wrote:

> On 17-06-01 11:01 PM, Martin Hannigan wrote:
>> I agree. Its easy to conclude that SWIP may possibly have outlived it's
>> usefulness and value to ARIN or it's members. Maybe the better policy
>> modification is to get rid of SWIP entirely and relieve operators of an
>> unnecessary burden?
>> Best,
> HORRIBLE idea...
> -- 
> "Catch the Magic of Linux..."
> ------------------------------------------------------------------------
> Michael Peddemors, President/CEO LinuxMagic Inc.
> Visit us at http://www.linuxmagic.com @linuxmagic
> ------------------------------------------------------------------------
> A Wizard IT Company - For More Info http://www.wizard.ca
> "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> ------------------------------------------------------------------------
> 604-682-0300 Beautiful British Columbia, Canada
> This email and any electronic data contained are confidential and intended
> solely for the use of the individual or entity to which they are addressed.
> Please note that any views or opinions presented in this email are solely
> those of the author and are not intended to represent those of the company.
> _______________________________________________
> 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.

More information about the ARIN-PPML mailing list