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.
