[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21

Fri Jul 28 11:49:49 EDT 2017

An ISP may always choose to SWIP or Rwhois.
You can SWIP an IPv4 /32 if you like.
This is not something which needs protecting...

What needs to be protected is the inverse, when the ISP says
we don't have to SWIP, so we aren't going to and you can't make us.

For clarity, it may be useful to add language that is effectively a no-op.

"ISPs and Registration-services members will not be prevented from
registering a SWIP of any size from their address holdings."

___Jason

On Thu, Jul 27, 2017 at 2:28 PM, Richard J Letts <rjletts at uw.edu> wrote:

>
> I believe we should SWIP for /48.
> I believe we may SWIP for /56 or longer if the Service provider deems it
> useful.
>
> As an example we assign /48's to school districts, colleges, and
> universities in the State of Washington. 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.
> We do not advertise separate routing for most of these /48 -- I do not
> want any linkage between SWIP and routing.
> 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.
>
> Thank you
>
> Richard Letts
> Manager: Network Operations Center: WA-K20, UW, UW Medicine, PNWGP, PWAVE,
> WRN
>
> > -----Original Message-----
> > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of
> > hostmaster at uneedus.com
> > Sent: Thursday, July 27, 2017 10:10 AM
> > To: arin-ppml at arin.net
> > 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 (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.
> _______________________________________________
> PPML
> 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.
>

-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170728/6c8a31bd/attachment.htm>