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
needed.
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
mess.
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.
_______________________________________________
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.
