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

[Jason Schiller]

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 <rjle...@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-boun...@arin.net] On Behalf Of
> > hostmas...@uneedus.com
> > Sent: Thursday, July 27, 2017 10:10 AM
> > To: arin-ppml@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.
> > 

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

[hostmaster]

The first draft of my proposal was very conservative.  For v6 I proposed 
the two smallest possible subnet values be exempted from SWIP, which was 
/60 and /64.  I figured that this would be enough for 16 subnets, enough 
for IOT and/or guest,wired, and wireless networks on different segments.


Those in the know on this list suggested that I was setting my sights too 
low, and we quickly added values up to /56 to be exempted from SWIP and 
reached consensus on "more than a /56".  The bus networks I speak of are 
just an example of many networks I know of in the real world where a 
single public IPv4 address is used, or a /32, which has never required 
SWIP, and the thinking that simply adding v6 should not change this.


Because of SLAAC, the smallest v6 subnet used is /64.  However, unlike v4, 
the current rule requires this smallest size network be SWIP'ed.  Unlike 
your government network, in the real ISP world, 95-99 percent of the 
customers have only a single v4 address, and therefore most customers in 
the v4 world has never triggered the SWIP requirements.  Adding the 
minimum /64 for v6 now triggers 100% SWIP and all the associated labor, 
and this is what I seek to address with this draft.  I do not believe that 
these small size networks should trigger SWIP simply because they decided 
to do the right thing and add IPv6.


Others spoke that getting rid of the conserving v4 mentality is what is 
needed, and that even ARIN policy considers the default end user site 
should be a /48.  This is in fact what I have at my home, divided into 3 
/64's, which seems very wasteful in v4 mentality which would suggest that 
I should not require more than a /60.  Others here pointed out the 
benefits of all end sites being /48, which will allow automatic 
configuration in future devices, uniformity of all networks, and expansion 
into things using their own subnets that we may not even consider viable 
at this time.


While my conserving nature tells me I should be happy with a /56 or /60, I 
have been convinced by others in the know that the benefits described are 
worth the extra address space, which will be grown into in the future. 
These same voices speak with the desire for uniformity of network size and 
that we should have a policy of /48 for each end site. This third round of 
the draft is where we are at.  Quite a bit of consensus has been reached 
so far that the draft policy should not do anything to encourage operators 
to assign less than a /48 to each site.


Since the numbers work for you and the assignments are already in place, 
maybe the majority opinion of not less than a /48 per site will not work 
for you, and nothing in the draft would require you to change this.  In 
fact with my bus example, I have been actually considering assigning /60's 
out of a master /48 to reduce the amount of fees paid to ARIN, a site 
non-standard subnet size of /60.


In defense of the current proposal, do remember the principle of "your 
network, your rules".  If you require each district or university to be 
registered in SWIP in order to reduce your own abuse workload, go ahead 
and make SWIP a local requirement of receiving an assignment of your 
allocation. The draft assumes every end point is a /48 and therefore is an 
endpoint not requiring registration, a fact that is not true on your 
network. Based on your own statements, it sounds like you will be mostly 
SWIP'ing /48's for each district, and the districts will be assigning 
something smaller for its sites, such as a /56.


I note that the draft proposal is just a minimum standard, and does not 
forbid an operator from requiring additional SWIP registration above these 
requirements in order to receive space from your allocation.  If I were 
you, I would record a proper SWIP record of /48 for each district and call 
it a day, unless a district asks to subdelegate their space to more than 
one contact, in which case I would divide their assignment into however 
administrative abuse contacts they require and hope that number is a power 
of 2.  This takes care of all of your identifed needs with your smaller 
than /48 end site assignments, but allows the default policy values for 
SWIP which are in your case too large for your network that is already in 
place.  The draft is based on the recommendation of /48 per end user site, 
so that future networks are encouraged to follow the /48 per site rule.


Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Thu, 27 Jul 2017, Richard J Letts wrote:



On this thread we've gone from near-real-time update of bus GPS co-ordinates to 
suggesting allocating over 64 subnets per student for most of our school 
districts was a bad idea and we should have allocated more(!)

Some stats for SY2017   # districts: 317; # districts <=100 students: 46  ;  # 
districts <=1000 students: 173 (including the 46)  ; # districts >= 10,000: 33 
(source: http://www.k12.wa.us/DataAdmin/enrollment.aspx)
Initial 

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

[Richard J Letts]

On this thread we've gone from near-real-time update of bus GPS co-ordinates to 
suggesting allocating over 64 subnets per student for most of our school 
districts was a bad idea and we should have allocated more(!)

Some stats for SY2017   # districts: 317; # districts <=100 students: 46  ; 
# districts <=1000 students: 173 (including the 46)  ; # districts >= 10,000: 
33 (source: http://www.k12.wa.us/DataAdmin/enrollment.aspx)
Initial allocations have been around for more than 7 years. In 7+ years no 
school district has come back and asked for more or a larger allocation than a 
/48.

I'm going to point out the current policy supports how we're swiping address 
space and it's up to you to persuade me your change is worthwhile. 

Richard


___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[hostmaster]

Richard J Letts wrote:



As an example we assign /48's to school districts,


If it is a really small school district, that is unlikely to expand beyond 
16 sites, you could give them a /44, otherwise each district should get at 
least a /40 or more.  A university might need more, or maybe a /40 for 
each college within it if each college within the university takes care of 
their own needs. This gives them room to give each of their schools or 
other sites a /48. Either way, the policy proposal would require SWIP for 
the main block assigned to that district, but no SWIP requirement for 
individual schools or other sites, all of which will be SWIP'ed to that 
specific district or college.


The only reason you are complaining about the school districts getting 
away without SWIP under the proposal is that you are assigning them too 
small of a block.  Each school, bus depot, admin headquarters, etc should 
be getting a /48.  I assume that instead you expect the districts to 
assign smaller blocks to their sites, like a /56, instead of the 
recommended /48.


Doing so follows the intent of the policy proposal to require larger 
allocations (/47 or larger) to be SWIP'ed, but /48's belonging to a single 
site without special routing not requiring SWIP.  Doing this does 
everything you want, because each assigned district block will be SWIP'ed 
as a whole, making that district responsible.  In the case of a 
University, 2 levels of SWIP might be needed, one for the University, and 
one under it for each College of that University, or other unit like a 
facilities group.



 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.


Give them the proper sized blocks, and your wish will be required by the 
policy proposal.  A /47 or more in the policy means ALL your assignments 
to districts and colleges require SWIP, getting you out of the abuse loop. 
It also relieves you and the district/college from any burden of having to 
SWIP the individual sites of each district/college.  Much better than the 
current policy where you would be responsible to SWIP all the way down to 
the site level, as the current standard is a /64 or more of static space.


Albert Erdmann
Network Administrator
Paradise On Line Inc.
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Tony Hain]

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:arin-ppml-boun...@arin.net] On Behalf Of
> > hostmas...@uneedus.com
> > Sent: Thursday, July 27, 2017 10:10 AM
> > To: arin-ppml@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 pro

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

[Richard J Letts]

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-boun...@arin.net] On Behalf Of
> hostmas...@uneedus.com
> Sent: Thursday, July 27, 2017 10:10 AM
> To: arin-ppml@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
&

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

[hostmaster]

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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Roberts, Orin]

On the contrary, it questions the validity and purpose of a swip.
Why is a SWIP necessary for IPv6? When is it necessary? And is necessity 
dependent on network/allocation size? All questions others have asked.

For all direct allocations , there are several POC's and an Organisation Name & 
Address, I think validation should be compulosary by ARIN at this level.
The ORG I work for has a min of  4, ADMIN, NOC, ABUSE, TECH per supernet (IPv4 
/16 or IPv6 /32). 
Beyond this I share your view point ~ "The only thing I give a crap about whois 
for is that the contact is someone with authority over the IP in question"

Now if "Authority" is defined as IANA>>ARIN>>Direct Allocation>>Realloaction# 
and the buck stops here. There won't be a need for Reassignment SWIPS on IPv6!

For IPv4 , we can ignore purpose and move straight to the issue of End User 
service address v.s. End User Legal address/tech contact address vs Service 
Provider address.
Right now the model is mixed. Most SWIPs are End User Service address but a few 
are the Service Provider Address or Legal Owner address (hence the bus 
analogy). 
I simple wanted clarity on what is general practice vs what is OBLIGATORY as 
per ARIN existing policy.

Orin 



-Original Message-
From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net] On Behalf Of Seth Mattinen
Sent: July-26-17 11:51 AM
To: arin-ppml@arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment 
Registration requirements between IPv4 and IPv6

On 7/26/17 08:34, hostmas...@uneedus.com wrote:
> Im sure glad that /32's of static IPv4 are not subject to SWIP, and 
> that SWIP does not require GPS info.
> 
> If it did, we would be in trouble, as our GPS tracking only updates 
> every 300 seconds or 5 minutes, and we would need a T1 of bandwidth 
> just to keep the SWIP updated, and for what purpose?  In all cases the 
> only place that will address abuse is our NOC.


If anyone really cares about the GPS location of a given IP at any time, just 
dynamically update some DNS LOC records.

This entire thread has gone beyond insane. I can't believe this list is 
actually discussing where a bus is located in whois. The only thing I give a 
crap about whois for is that the contact is someone with authority over the IP 
in question.

~Seth
___
PPML
You are receiving this message because you are subscribed to the ARIN Public 
Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Jason Schiller]

> On Wed, Jul 26, 2017 at 3:24 PM, Owen DeLong  wrote:

> > On Jul 26, 2017, at 07:20 , Michael Peddemors 
wrote:
> >
> > But, in keeping with your 'flippant' style, we do have some ISP's that
aren't responsible for the traffic that happens on their networks too ;)

> Well… We have ISPs that fail to act responsibly about traffic that
happens on their network. Saying they are not actually responsible is
another
> question which I don’t necessarily agree with.

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.


On Wed, Jul 26, 2017 at 3:24 PM, Owen DeLong  wrote:

>
> > On Jul 26, 2017, at 07:20 , Michael Peddemors 
> wrote:
> >
> > On 17-07-25 02:31 PM, Owen DeLong wrote:
> >>> On Jul 25, 2017, at 10:34 , Michael Peddemors 
> wrote:
> >>>
> >>> On 17-07-24 05:06 PM, Tony Hain wrote:
>  I still don’t see any value in specifying length. What you are
> looking for is contact info for someone with a clue about how a given
> network works and using length as a really poor proxy. I could live with a
> fourth line:
>  Any end network emitting SMTP system SHOULD provide SWIP.
>  I just don’t know how that gets enforced in any reasonable way. In
> general SMTP & independent routing are the big targets needing accurate
> contact info, and length has absolutely nothing to do with either.
>  Tony
> >>>
> >>> While I agree in principle, it CAN be provided by "SWIP" OR 'rwhois',
> and that should be pointed out, as rwhois is more flexible in the IPv4
> space, eg providing allocation information to the /32 level.
> >>>
> >>> This again goes to an earlier email where I described that it should
> be more conceptual, than specific ranges..
> >>>
> >>> It should be, "if a party is responsible for the originating traffic",
> then that party should be displayed via SWIP/rwhois.
> >> Well… That’s hard to implement in practice. How do we go about SWIPing
> all those home windows boxes to the hackers that are actually controlling
> the emitted traffic?
> >> Owen
> >
> > I assume you were being flippant/joking.  The person who should be
> contacted if the device is hacked in that case, would 'normally' be the
> ISP, unless the person notified the ISP that they were taking
> responsibility.  (Same way as they 

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

[Owen DeLong]

> On Jul 26, 2017, at 08:34 , hostmas...@uneedus.com wrote:
> 
> Im sure glad that /32's of static IPv4 are not subject to SWIP, and that SWIP 
> does not require GPS info.
> 
> If it did, we would be in trouble, as our GPS tracking only updates every 300 
> seconds or 5 minutes, and we would need a T1 of bandwidth just to keep the 
> SWIP updated, and for what purpose?  In all cases the only place that will 
> address abuse is our NOC.

If your GPS updates every 5 minutes, then that’s a $GPGGA and possibly a $GPRMC 
sentence every 300 seconds.

In general, each of these sentences is under 80 characters (usually around 64 
characters IIRC). Conservatively using 80 characters, we have 80*8=640 bits 
every 300 seconds.

This leaves 1,572,224 bits per second on a T1 for protocol overhead.

OTOH, if you’re talking about the SWIP template size (reassign simple is all 
that this really calls for), then that’s a bit larger, weighing in at 463*8 = 
3,704 bits without any data added to the basic template. Let’s assume another 
an average of 40 characters (probably closer to 20, but let’s again be 
conservative) for each of the 12 fields giving us an additional 480*8=3,804 
bits for a total of 7,508 bits. Adding EMAIL message size overhead and TCP/IP 
overhead, let’s call it an even 16Kbits per SWIP. (that’s pretty high overhead, 
I think) At that rate (16kbb per 300 seconds, A T1 requirement means you need 
to support 28,800 busses in your system.

As such, 1,000 busses or less actually fit on a DS0 with room to spare.

> Right now, all 500+ busses use a static IPv4 address, that is assigned by the 
> Major wireless provider.  They are NOT in a block reserved for us. They are 
> scattered around several blocks of addresses of the provider, some of which 
> they appear to be leasing from another party, and those SWIP records list the 
> leasing company.  None of them have a SWIP to us, our provider has to forward 
> the reports to us, sometimes thru the leasing co.

While there may be people willing to SWIP GPS coordinates, I would argue this 
is the exception rather than the rule and constantly updating SWIP to reflect 
the location of a mobile element rather than simply SWIPing it to a 
headquarters location is illogical in the extreme.

> As we move to v6, I am hoping the policy will change from 100% SWIP to a 
> level not requiring it.  This is because our provider insists the current 
> ARIN rule requires a street address for each bus.  I think I will point them 
> to the thread that states the site address is not required in SWIP, and we 
> can use the ADMIN address, or better yet wait for the policy to change and 
> let them forward reports just like they do in v4.  In any case, my guess is 
> that nearly no abuse will happen on v6 for lack of customer abuse, and we 
> will continue to receive a couple of reports a month on the new contract 
> dynamic addresses, if they at the provider can even figure out who to send 
> them to, as in the future the addresses for v4 might be CGnat, and they would 
> have to figure out who did it.

The provider is mistaken. The current ARIN rule requires a street address for 
each customer delegation in excess of a /64. If he delegates a /48 to the bus 
company (or even a /32 or a /24 or whatever), then he only needs to SWIP the 
address of the bus company on that particular block and he has fulfilled his 
ARIN obligations. (This is my personal opinion and not an official statement 
from ARIN staff or the AC, however, I’m sure one of those entities will correct 
me quickly and publicly if I am wrong).

I’ve worked for and with a number of ISPs and end users and dealt with many 
ARIN allocations and assignments as well as many reallocations and 
reassignments to downstream customers. I assure you that SWIPing individual 
busses even if each bus got an IPv4 /24 would be considered illogical by 
virtually anyone involved in the process and that SWIPing an aggregate block to 
the bus company would make much more sense.

If each bus gets a random IPv6 static assignment individually and they can’t be 
aggregated, then, they would have to be SWIP’d individually, but they could 
still be SWIP’d to the address and name of the bus company without requiring 
the current location of the individual bus in question.

Owen

> 
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
> 
> 
> 
> On Wed, 26 Jul 2017, Roberts, Orin wrote:
> 
>> Ref: Geolocation and SWIPs
>> 
>> I have seen SWIPs with GPS coordinates similar to the bus example; 
>> wifi/camera in remote park.
>> 
>> “A bus would be SWIPd to the bus yard or administrative offices of the bus 
>> company. The SWIP data is not required to be the service address, it is 
>> required to be an address for administrative and/or technical contact 
>> regarding the network and/or legal process service regarding same”.
>> 
>> Is this in ARIN’s policy? “The SWIP data is not required to be the service 
>> address”
>> 
>> 
>> 
>> 
>> 

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

[Owen DeLong]

> On Jul 26, 2017, at 07:20 , Michael Peddemors  wrote:
> 
> On 17-07-25 02:31 PM, Owen DeLong wrote:
>>> On Jul 25, 2017, at 10:34 , Michael Peddemors  
>>> wrote:
>>> 
>>> On 17-07-24 05:06 PM, Tony Hain wrote:
 I still don’t see any value in specifying length. What you are looking for 
 is contact info for someone with a clue about how a given network works 
 and using length as a really poor proxy. I could live with a fourth line:
 Any end network emitting SMTP system SHOULD provide SWIP.
 I just don’t know how that gets enforced in any reasonable way. In general 
 SMTP & independent routing are the big targets needing accurate contact 
 info, and length has absolutely nothing to do with either.
 Tony
>>> 
>>> While I agree in principle, it CAN be provided by "SWIP" OR 'rwhois', and 
>>> that should be pointed out, as rwhois is more flexible in the IPv4 space, 
>>> eg providing allocation information to the /32 level.
>>> 
>>> This again goes to an earlier email where I described that it should be 
>>> more conceptual, than specific ranges..
>>> 
>>> It should be, "if a party is responsible for the originating traffic", then 
>>> that party should be displayed via SWIP/rwhois.
>> Well… That’s hard to implement in practice. How do we go about SWIPing all 
>> those home windows boxes to the hackers that are actually controlling the 
>> emitted traffic?
>> Owen
> 
> I assume you were being flippant/joking.  The person who should be contacted 
> if the device is hacked in that case, would 'normally' be the ISP, unless the 
> person notified the ISP that they were taking responsibility.  (Same way as 
> they now request a static IP address instead of dynamic)

Yes, Of course I was joking, but my point is that it really isn’t “the party 
responsible for originating the traffic” rather than “the closest knowledgeable 
party to the party responsible for the operation of the machine originating the 
traffic.

> But, in keeping with your 'flippant' style, we do have some ISP's that aren't 
> responsible for the traffic that happens on their networks too ;)

Well… We have ISPs that fail to act responsibly about traffic that happens on 
their network. Saying they are not actually responsible is another question 
which I don’t necessarily agree with.

Owen

___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Owen DeLong]

I don’t know if it is spelled out in policy, but it is certainly widespread 
practice and I know of nothing prohibiting it.

Owen

> On Jul 26, 2017, at 06:50 , Roberts, Orin  wrote:
> 
> Ref: Geolocation and SWIPs
>  
> I have seen SWIPs with GPS coordinates similar to the bus example; 
> wifi/camera in remote park.
>  
> “A bus would be SWIPd to the bus yard or administrative offices of the bus 
> company. The SWIP data is not required to be the service address, it is 
> required to be an address for administrative and/or technical contact 
> regarding the network and/or legal process service regarding same”.
>  
> Is this in ARIN’s policy? “The SWIP data is not required to be the service 
> address”
>  
>  
>  
>  
> 
>  
>  
> Orin Roberts - JNCIA, CCNA, ITILv3
> IP PROVISIONING
> Bell Canada
> ' 905.614.9338 |  * orobe...@bell.ca 
>  
> 
> 
> On 7/24/2017 1:31 PM, Owen DeLong wrote:
> On Jul 20, 2017, at 14:28 , hostmas...@uneedus.com 
>  wrote:
> 
> My transit bus example is another example of SWIP difficulty.  Very hard to 
> provide a street address to SWIP a bus when it is mobile 16 hours a day.
> Not at all. A bus would be SWIPd to the bus yard or administrative offices of 
> the bus company. The SWIP data is not required to be the service address, it 
> is required to be an address for administrative and/or technical contact 
> regarding the network and/or legal process service regarding same.
> 
> [rest trimmed because we are in agreement on that part]
> 
> Owen
> 
> On Thu, 20 Jul 2017, Chris James wrote:
> @Paul - The API key is to email it.
> 
> @Owen - Very difficult when you have dynamic ranges, and vps/container
> platforms spanning tens of thousands of instances across these dynamic
> ranges.
> 
> 
> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary  > wrote:
> 
> Owen
> 
> The reassignment policy page says IPv6 has to be done vi API.
> Is that something else that is incorrect on the web site?
> 
> Paul
> 
> 
> On 7/20/2017 3:16 PM, Owen DeLong wrote:
> 
> How can it be overly difficult to fill out an email template with your
> customers’
> Name, Address, Phone Number?
> 
> Really?
> 
> Owen
> 
> On Jul 19, 2017, at 23:48 , Pallieter Koopmans  >
> wrote:
> 
> Hello,
> 
> ARIN could quantify and require rules for when to SWIP, but in the
> end, there are going to be exceptions needed if the rules are to be
> strictly followed. Many will not separately SWIP a separately routed
> sub-block if it is too difficult or pointless to gather and share that
> data back upstream to ARIN.
> 
> Thus a more fuzzy rule to require a best-effort and to add a
> rule-based reason (preferably both a carrot and a stick) for block
> owners to do their best to provide (only) useful data. In order to do
> that, one needs to look back at why that data is needed. For a block
> owner to assign the SWIP on a sub-block, he basically delegates tech
> and abuse contact requests down to those that are probably more likely
> to be able to actually act on the tech/abuse requests (and thus reduce
> request-handling workload higher up and overall). But for that to
> work, those tech/abuse contact requests need to be actually handled,
> otherwise, it is better to leave them with the block owner.
> 
> In the end, the contact details should be as close to the "person"
> that is actually capable to both handle (think: volume/languages/etc)
> and act (think: authority) on the tech/abuse requests.
> 
> eBrain
> Innovative Internet Ideas
> 
> Pallieter Koopmans
> Managing Director
> 
> +31-6-3400-3800  (mon-sat 9-22 CET)
> Skype: PallieterKoopmans
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net 
> ).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml 
> 
> Please contact i...@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@arin.net 
> ).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml 
> 
> Please contact i...@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@arin.net 
> ).
> Unsubscribe or manage your mailing list subscription at:
> 

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

[Owen DeLong]

I believe that both the existing and proposed policies handle the CPNI issues 
sufficiently through the
ARIN requirement that providers require similar reassignment terms from their 
assignees and other recipients.

Otherwise, yes, I think we are in agreement about the policy.

Owen

> On Jul 26, 2017, at 02:11 , Paul McNary  wrote:
> 
> Hello Owen
> I think we are really almost in total agreement! :-)
> I think we use words a little differently, but It think
> we want a similar result. "Address Tracking" was not
> on my concerns list except for possible CPNI violations
> which I see a solution of how to handle this.
> Take care
> Paul
> 
> On 7/26/2017 1:13 AM, Owen DeLong wrote:
>> 
>> 
>> On Jul 25, 2017, at 15:46, Paul McNary > > wrote:
>> 
>>> Let me change "geolocation" to "address tracking".
>>> For instance, Netflix blocks a certain region and whois is showing customer
>>> in that region, whereas the customer is actually in a non-blocked region.
>>> If I had my own IPv4 /24 or above I don't have any issue making this entry 
>>> correct to ARIN.
>> 
>> I know for a fact that Netflix bases very little (if any) of their 
>> geo-fencing on Whois data. 
>> 
>>> But I have a /25 block from a datacenter that shows I am in California.
>>> Their SWIP policy on IPv4 is /24 to SWIP.
>>> We are trying to minimize these issues as we deploy IPv6 when we have 
>>> direct allocation.
>>> I am not debating the "address tracking" issue just brought it up because I 
>>> think John made a comment about it.
>> 
>> I think if you review the record I stated early on that I didn't believe 
>> geolocation was a practical use of Whois. 
>> 
>>> We see ebay, amazon, craig's list all using whois information.
>> 
>> Really? Source needed. 
>> 
>> In my experience they use other geolocation providers. 
>> 
>>> Also our /25's have been blocked at the /24 and /18 level.
>>> We had /24's blocked that are reallocated at the parent /18 level.
>>> So unless there is some way to enforce, it just seems to be words on paper.
>> 
>> Enforce what? Geolocation is a truly black art and there is no central 
>> clearing house or community driven policy body driving its practitioners. 
>> 
>>> 
>>> CHANGE of subject not topic
>>> --
>>> What I had wished to do on IPv6 deployment is assign an IPv6 /48 to each 
>>> Tower(WISP), each POP(ISP)
>>> I would want that switched as will as any individually announced block 
>>> smaller than that.
>>> Haven't decided but have a separate /48 to handle DNS, mail servers, etc. 
>>> ie Our Infrastructure
>>> Anything less specific that a /48 would just add noise to the world and 
>>> would be somewhat proprietary.
>>> I give away some info just advertising my POP's/Towers but I think that 
>>> would be for the collective good. :-)
>>> The world doesn't need to know my Access Points or neighborhood routers, 
>>> etc.
>> 
>> I see no reason you can't accomplish this under the proposed policy. I 
>> support the current draft as previously stated. 
>> 
>> 
>> Owen
>> 
>>>  
>>> I think I need to get off my soapbox and take a nap now!
>>> I know I ramble a lot, but getting too old to change much! :-)
>>> Thanks
>>> Take care
>>> Paul
>>> 
>>> On 7/25/2017 5:17 PM, Scott Leibrand wrote:
 If I, as an End User network, want to inform geolocation providers of 
 where I'm using each netblock, having them assigned to me in the whois DB 
 with an appropriate address is one of the best ways to do that.  But if 
 I'm running a geolocation service, I can't rely on whois as the sole 
 source of data on where an address is used.  If I have other info that 
 contradicts the whois information, I'd probably just ignore the whois data 
 and go with the facts on the ground.
 
 -Scott
 
 On Tue, Jul 25, 2017 at 3:12 PM, Paul McNary > wrote:
 Owen
 Several weeks ago geolocation was one of the arguments for having accurate 
 whois in this thread.
 This is no longer being argued?
 Paul
 
 
 On 7/25/2017 4:26 PM, Owen DeLong wrote:
 Huh?
 
 WHOIS is not a geolocation service and anyone who thinks it is should 
 reduce their use of recreational pharmaceuticals.
 
 Owen
 
 On Jul 24, 2017, at 12:03 , Paul McNary > wrote:
 
 Then that totally negates the reasoning for geolocation.
 The administrative address could be on the other side of the earth.
 
 Paul
 
 
 On 7/24/2017 1:31 PM, Owen DeLong wrote:
 On Jul 20, 2017, at 14:28 , hostmas...@uneedus.com 
  wrote:
 
 My transit bus example is another example of SWIP difficulty.  Very hard 
 to provide a street address to SWIP a bus when it is mobile 16 hours a day.
 Not at all. A bus 

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

[John Santos]

On 7/26/2017 11:34 AM, hostmas...@uneedus.com wrote:


Right now, all 500+ busses use a static IPv4 address, that is assigned 
by the Major wireless provider.  They are NOT in a block reserved for 
us. They are scattered around several blocks of addresses of the 
provider, some of which they appear to be leasing from another party, 
and those SWIP records list the leasing company.  None of them have a 
SWIP to us, our provider has to forward the reports to us, sometimes 
thru the leasing co. 


When one ISP leases addresses to a 2nd ISP, shouldn't that 1st ISP SWIP 
those address blocks to the lessee?  In your case, this would reduce the 
complexity of abuse report handling, since everything would (or should) 
go directly to your ISP and directly from them to you.


As far as SWIPing the individual buses to their constantly changing 
locations, that sounds to me utterly pointless.  Would someone be 
expecting the bus driver to handle abuse complaints about a passenger on 
the bus who sent a lot of spam two days ago?


Clearly, the SWIP records should point to the Org contact (i.e. your bus 
company or transit authority) and the Org POC information, (i.e. the 
person or group which handles abuse and technical issues relating to the 
buses.)  This is borne out by actually looking at the information ARIN 
requires,  is exactly the information requested on the ARIN form 
"ARIN-REASSIGN-DETAILED", which is the form your ISP should be using to 
SWIP your bus networks (if they are using the "email a SWIP request", 
which I assume is the same set of information as would be required by 
the RESTful or online assignment methods.)  Furthermore, if the ORG 
already has an ORG-ID on file, the only information required is the Org 
ID, the IP address block, the network's name and the upstream AS.  The 
contact information would necessarily be identical for every bus.


As for the policy, I support the current version, i.e. not changing the 
current IPv4 policy (which as far as I can tell, would require all the 
individual bus subnets to be SWIPed to the bus company, not to the 
individual buses, with the contact info for the bus company's network 
tech staff*), and changing the IPv6 size so as to exclude residences and 
small businesses which typically let their ISP handle technical and 
abuse issues.  The exact value of the IPv6 network size is not important 
to me, but I think if /48 is the current best practice recommendation, 
the limit should be /47 or larger, which /48 SWIPable at the customer's 
request.



[*]Which, I think, can be contracted out to some other organization, 
i.e. the email and physical address can be that of a service provider, 
not necessarily a bus company employee or the physical address of the 
bus yard or the building where the bus company's offices are, as long as 
they are contractually responsible for network management for the bus 
company.)


--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Jason Schiller]

David, Tony, Thank you for bringing up the IPS must SWIP when address user
asks.

Scott, Thank you for putting the changes in context.


I oppose as written.  I support with the David/Tony friendly admendment.

Why?
> It should be required for an ISP to SWIP / Rwhois any reassignment
> when the down stream address user has requested such.
>
> It is sometimes useful to SWIP the reassignemnts to the down stream
> organization so that the down stream organization can provide their abuse
> contact or technical support contact info, or public comments.
>
> I fear without my friendly amendment the policy change may send
> the wrong message and suggest that an ISP can safely conclude
> that if they are never going to support mutli-homing, and if they never
> give out anything larger than a /48, that they do not need to support the
> facility to SWIP at all, and can openly refuse all SWIPs for IPv6
> re-assignments.

Possible simple text addition:

On Fri, Jul 21, 2017 at 1:34 PM, Scott Leibrand 
 wrote:
>
>
> For clarity, so we don't all have to do it, and to help make sure we're
> not missing anything, here's what the resulting 6.5.5 looks like after
> modification:
>
> 6.5.5. Registration
>
> ISPs are required to demonstrate efficient use of IP address space
> allocations by providing appropriate documentation, including but not
> limited to assignment histories, showing their efficient use.
>
> 6.5.5.1. Re-allocation / Reassignment information
>
>
Each of the following

shall be registered in the WHOIS directory via SWIP or a distributed
> service which meets the standards set forth in section 3.2. Reassignment
> registrations shall include each client's organizational information,
> except where specifically exempted by this policy.
>

> - static IPv6 re-assignment containing a /47 or more addresses,
>
-  sub-delegation of any size that will be individually announced,
- any re-assignment where the address holder specifically requests a
reassign simple, reassign detail, or (if applicable) privacy registration
- re-allocations of any size


> 6.5.5.2. Assignments visible within 7 days
>
> All assignments shall be made visible as required in section 4.2.3.7.1
> within seven calendar days of assignment.
>
> 6.5.5.3. Residential Subscribers
>
> 6.5.5.3.1. Residential Customer Privacy
>
> To maintain the privacy of their residential customers, an organization
> with downstream residential customers may substitute that organization's
> name for the customer's name, e.g. 'Private Customer - XYZ Network', and
> the customer's street address may read 'Private Residence'. Each private
> downstream residential reassignment must have accurate upstream Abuse and
> Technical POCs visible on the WHOIS record for that block.
>
> -Scott
>
>
I'd like to (mostly) stay out of the MUST/SHOULD discussion wrt
the requirement to SWIP if the intent is to route.
I prefer MUST over SHOULD and SHOULD over no advice.
I feel strongly that at the least the advice should be preserved.

__Jason





On Mon, Jul 24, 2017 at 5:07 PM, David Farmer  wrote:

> Honestly, I could live with it just those three lines.  However, I'm
> willing to recognize at least the possibility there is a legitimate
> community interest in having records for assignments that are shorter than
> /48.
>
> As for IPv4, I'd also be just fine with those three lines.  Again,
> recognizing at least the possibility there is a legitimate community
> interest in having records for assignments that are shorter than /24
>
> On Mon, Jul 24, 2017 at 2:51 PM, Tony Hain  wrote:
>
>> While I agree with the general direction David is heading, his text is
>> still overly complex to deal with the goal. This whole thread only requires
>> 3 lines:
>>
>>
>>
>> Reallocations MUST provide SWIP.
>>
>> Requests by the assignee MUST provide SWIP.
>> Anything appearing independently in the global routing table SHOULD
>> provide SWIP.
>>
>>
>>
>> All the rest is noise that doesn’t add to solving any problem known to
>> mankind, and is simply an artifact of the IPv4-think insane conservation
>> mindset. Size is irrelevant in both protocol versions, and even if you
>> think it is, the only time it comes up is in #3. In any case the length of
>> #3 might change over time, and there is no reason the policy text needs to
>> change to track it. If something is independent, no matter what it’s length
>> is, the intent is to have accurate contact info.
>>
>>
>>
>> Saying anything more is trying to legislate ISP behavior, which is
>> explicitly outside the scope of ARIN.
>>
>>
>>
>> Tony
>>
>
>
> --
> ===
> David Farmer   Email:far...@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SEPhone: 612-626-0815 <(612)%20626-0815>
> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
> 

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

[Seth Mattinen]

On 7/26/17 08:34, hostmas...@uneedus.com wrote:
Im sure glad that /32's of static IPv4 are not subject to SWIP, and that 
SWIP does not require GPS info.


If it did, we would be in trouble, as our GPS tracking only updates 
every 300 seconds or 5 minutes, and we would need a T1 of bandwidth just 
to keep the SWIP updated, and for what purpose?  In all cases the only 
place that will address abuse is our NOC.



If anyone really cares about the GPS location of a given IP at any time, 
just dynamically update some DNS LOC records.


This entire thread has gone beyond insane. I can't believe this list is 
actually discussing where a bus is located in whois. The only thing I 
give a crap about whois for is that the contact is someone with 
authority over the IP in question.


~Seth
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[hostmaster]

Im sure glad that /32's of static IPv4 are not subject to SWIP, and that 
SWIP does not require GPS info.


If it did, we would be in trouble, as our GPS tracking only updates every 
300 seconds or 5 minutes, and we would need a T1 of bandwidth just to keep 
the SWIP updated, and for what purpose?  In all cases the only place that 
will address abuse is our NOC.


Right now, all 500+ busses use a static IPv4 address, that is assigned by 
the Major wireless provider.  They are NOT in a block reserved for us. 
They are scattered around several blocks of addresses of the provider, 
some of which they appear to be leasing from another party, and those SWIP 
records list the leasing company.  None of them have a SWIP to us, our 
provider has to forward the reports to us, sometimes thru the leasing co.


Before the bus wifi was added, we had NO abuse reports.  Now, out of this 
fleet, we draw about 2 a month, all associated with the public wifi.  We 
do filter port 25 to keep spammers from setting up on our busses, along 
with a block of other problem ports and locations.


As we move to v6, I am hoping the policy will change from 100% SWIP to a 
level not requiring it.  This is because our provider insists the current 
ARIN rule requires a street address for each bus.  I think I will point 
them to the thread that states the site address is not required in SWIP, 
and we can use the ADMIN address, or better yet wait for the policy to 
change and let them forward reports just like they do in v4.  In any case, 
my guess is that nearly no abuse will happen on v6 for lack of customer 
abuse, and we will continue to receive a couple of reports a month on the 
new contract dynamic addresses, if they at the provider can even figure 
out who to send them to, as in the future the addresses for v4 might be 
CGnat, and they would have to figure out who did it.


Albert Erdmann
Network Administrator
Paradise On Line Inc.



On Wed, 26 Jul 2017, Roberts, Orin wrote:


Ref: Geolocation and SWIPs

I have seen SWIPs with GPS coordinates similar to the bus example; wifi/camera 
in remote park.

???A bus would be SWIPd to the bus yard or administrative offices of the bus 
company. The SWIP data is not required to be the service address, it is 
required to be an address for administrative and/or technical contact regarding 
the network and/or legal process service regarding same???.

Is this in ARIN???s policy? ???The SWIP data is not required to be the service 
address???




[cid:image001.jpg@01C9B448.7DFDA670]



Orin Roberts - JNCIA, CCNA, ITILv3
IP PROVISIONING
Bell Canada

' 905.614.9338 |  ??? orobe...@bell.ca



On 7/24/2017 1:31 PM, Owen DeLong wrote:
On Jul 20, 2017, at 14:28 , 
hostmas...@uneedus.com wrote:

My transit bus example is another example of SWIP difficulty.  Very hard to 
provide a street address to SWIP a bus when it is mobile 16 hours a day.
Not at all. A bus would be SWIPd to the bus yard or administrative offices of 
the bus company. The SWIP data is not required to be the service address, it is 
required to be an address for administrative and/or technical contact regarding 
the network and/or legal process service regarding same.

[rest trimmed because we are in agreement on that part]

Owen
On Thu, 20 Jul 2017, Chris James wrote:
@Paul - The API key is to email it.

@Owen - Very difficult when you have dynamic ranges, and vps/container
platforms spanning tens of thousands of instances across these dynamic
ranges.


On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary 
> wrote:
Owen

The reassignment policy page says IPv6 has to be done vi API.
Is that something else that is incorrect on the web site?

Paul


On 7/20/2017 3:16 PM, Owen DeLong wrote:
How can it be overly difficult to fill out an email template with your
customers???
Name, Address, Phone Number?

Really?

Owen

On Jul 19, 2017, at 23:48 , Pallieter Koopmans 
>
wrote:

Hello,

ARIN could quantify and require rules for when to SWIP, but in the
end, there are going to be exceptions needed if the rules are to be
strictly followed. Many will not separately SWIP a separately routed
sub-block if it is too difficult or pointless to gather and share that
data back upstream to ARIN.

Thus a more fuzzy rule to require a best-effort and to add a
rule-based reason (preferably both a carrot and a stick) for block
owners to do their best to provide (only) useful data. In order to do
that, one needs to look back at why that data is needed. For a block
owner to assign the SWIP on a sub-block, he basically delegates tech
and abuse contact requests down to those that are probably more likely
to be able to actually act on the tech/abuse requests (and thus reduce
request-handling workload higher up and overall). But for that to
work, those tech/abuse contact requests need to be actually handled,
otherwise, it is 

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

[Michael Peddemors]

On 17-07-25 02:31 PM, Owen DeLong wrote:



On Jul 25, 2017, at 10:34 , Michael Peddemors  wrote:

On 17-07-24 05:06 PM, Tony Hain wrote:

I still don’t see any value in specifying length. What you are looking for is 
contact info for someone with a clue about how a given network works and using 
length as a really poor proxy. I could live with a fourth line:
Any end network emitting SMTP system SHOULD provide SWIP.
I just don’t know how that gets enforced in any reasonable way. In general SMTP 
& independent routing are the big targets needing accurate contact info, and 
length has absolutely nothing to do with either.
Tony


While I agree in principle, it CAN be provided by "SWIP" OR 'rwhois', and that 
should be pointed out, as rwhois is more flexible in the IPv4 space, eg providing 
allocation information to the /32 level.

This again goes to an earlier email where I described that it should be more 
conceptual, than specific ranges..

It should be, "if a party is responsible for the originating traffic", then 
that party should be displayed via SWIP/rwhois.


Well… That’s hard to implement in practice. How do we go about SWIPing all 
those home windows boxes to the hackers that are actually controlling the 
emitted traffic?

Owen



I assume you were being flippant/joking.  The person who should be 
contacted if the device is hacked in that case, would 'normally' be the 
ISP, unless the person notified the ISP that they were taking 
responsibility.  (Same way as they now request a static IP address 
instead of dynamic)


But, in keeping with your 'flippant' style, we do have some ISP's that 
aren't responsible for the traffic that happens on their networks too ;)





--
"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 (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Roberts, Orin]

Ref: Geolocation and SWIPs

I have seen SWIPs with GPS coordinates similar to the bus example; wifi/camera 
in remote park.

“A bus would be SWIPd to the bus yard or administrative offices of the bus 
company. The SWIP data is not required to be the service address, it is 
required to be an address for administrative and/or technical contact regarding 
the network and/or legal process service regarding same”.

Is this in ARIN’s policy? “The SWIP data is not required to be the service 
address”




[cid:image001.jpg@01C9B448.7DFDA670]



Orin Roberts - JNCIA, CCNA, ITILv3
IP PROVISIONING
Bell Canada

' 905.614.9338 |  • orobe...@bell.ca



On 7/24/2017 1:31 PM, Owen DeLong wrote:
On Jul 20, 2017, at 14:28 , 
hostmas...@uneedus.com wrote:

My transit bus example is another example of SWIP difficulty.  Very hard to 
provide a street address to SWIP a bus when it is mobile 16 hours a day.
Not at all. A bus would be SWIPd to the bus yard or administrative offices of 
the bus company. The SWIP data is not required to be the service address, it is 
required to be an address for administrative and/or technical contact regarding 
the network and/or legal process service regarding same.

[rest trimmed because we are in agreement on that part]

Owen
On Thu, 20 Jul 2017, Chris James wrote:
@Paul - The API key is to email it.

@Owen - Very difficult when you have dynamic ranges, and vps/container
platforms spanning tens of thousands of instances across these dynamic
ranges.


On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary 
> wrote:
Owen

The reassignment policy page says IPv6 has to be done vi API.
Is that something else that is incorrect on the web site?

Paul


On 7/20/2017 3:16 PM, Owen DeLong wrote:
How can it be overly difficult to fill out an email template with your
customers’
Name, Address, Phone Number?

Really?

Owen

On Jul 19, 2017, at 23:48 , Pallieter Koopmans 
>
wrote:

Hello,

ARIN could quantify and require rules for when to SWIP, but in the
end, there are going to be exceptions needed if the rules are to be
strictly followed. Many will not separately SWIP a separately routed
sub-block if it is too difficult or pointless to gather and share that
data back upstream to ARIN.

Thus a more fuzzy rule to require a best-effort and to add a
rule-based reason (preferably both a carrot and a stick) for block
owners to do their best to provide (only) useful data. In order to do
that, one needs to look back at why that data is needed. For a block
owner to assign the SWIP on a sub-block, he basically delegates tech
and abuse contact requests down to those that are probably more likely
to be able to actually act on the tech/abuse requests (and thus reduce
request-handling workload higher up and overall). But for that to
work, those tech/abuse contact requests need to be actually handled,
otherwise, it is better to leave them with the block owner.

In the end, the contact details should be as close to the "person"
that is actually capable to both handle (think: volume/languages/etc)
and act (think: authority) on the tech/abuse requests.

eBrain
Innovative Internet Ideas

Pallieter Koopmans
Managing Director

+31-6-3400-3800 (mon-sat 9-22 CET)
Skype: PallieterKoopmans
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List 
(ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
--
This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with 

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

[Paul McNary]

Hello Owen
I think we are really almost in total agreement! :-)
I think we use words a little differently, but It think
we want a similar result. "Address Tracking" was not
on my concerns list except for possible CPNI violations
which I see a solution of how to handle this.

Take care
Paul


On 7/26/2017 1:13 AM, Owen DeLong wrote:



On Jul 25, 2017, at 15:46, Paul McNary > wrote:



Let me change "geolocation" to "address tracking".
For instance, Netflix blocks a certain region and whois is showing 
customer

in that region, whereas the customer is actually in a non-blocked region.
If I had my own IPv4 /24 or above I don't have any issue making this 
entry correct to ARIN.


I know for a fact that Netflix bases very little (if any) of their 
geo-fencing on Whois data.



But I have a /25 block from a datacenter that shows I am in California.
Their SWIP policy on IPv4 is /24 to SWIP.
We are trying to minimize these issues as we deploy IPv6 when we have 
direct allocation.
I am not debating the "address tracking" issue just brought it up 
because I think John made a comment about it.


I think if you review the record I stated early on that I didn't 
believe geolocation was a practical use of Whois.



We see ebay, amazon, craig's list all using whois information.


Really? Source needed.

In my experience they use other geolocation providers.


Also our /25's have been blocked at the /24 and /18 level.
We had /24's blocked that are reallocated at the parent /18 level.
So unless there is some way to enforce, it just seems to be words on 
paper.


Enforce what? Geolocation is a truly black art and there is no central 
clearing house or community driven policy body driving its practitioners.




CHANGE of subject not topic
--
What I had wished to do on IPv6 deployment is assign an IPv6 /48 to 
each Tower(WISP), each POP(ISP)
I would want that switched as will as any individually announced 
block smaller than that.
Haven't decided but have a separate /48 to handle DNS, mail servers, 
etc. ie Our Infrastructure
Anything less specific that a /48 would just add noise to the world 
and would be somewhat proprietary.
I give away some info just advertising my POP's/Towers but I think 
that would be for the collective good. :-)
The world doesn't need to know my Access Points or neighborhood 
routers, etc.


I see no reason you can't accomplish this under the proposed policy. I 
support the current draft as previously stated.



Owen



I think I need to get off my soapbox and take a nap now!
I know I ramble a lot, but getting too old to change much! :-)
Thanks
Take care
Paul

On 7/25/2017 5:17 PM, Scott Leibrand wrote:
If I, as an End User network, want to inform geolocation providers 
of where I'm using each netblock, having them assigned to me in the 
whois DB with an appropriate address is one of the best ways to do 
that.  But if I'm running a geolocation service, I can't rely on 
whois as the sole source of data on where an address is used.  If I 
have other info that contradicts the whois information, I'd probably 
just ignore the whois data and go with the facts on the ground.


-Scott

On Tue, Jul 25, 2017 at 3:12 PM, Paul McNary > wrote:


Owen
Several weeks ago geolocation was one of the arguments for
having accurate whois in this thread.
This is no longer being argued?
Paul


On 7/25/2017 4:26 PM, Owen DeLong wrote:

Huh?

WHOIS is not a geolocation service and anyone who thinks it
is should reduce their use of recreational pharmaceuticals.

Owen

On Jul 24, 2017, at 12:03 , Paul McNary
> wrote:

Then that totally negates the reasoning for geolocation.
The administrative address could be on the other side of
the earth.

Paul


On 7/24/2017 1:31 PM, Owen DeLong wrote:

On Jul 20, 2017, at 14:28 ,
hostmas...@uneedus.com
 wrote:

My transit bus example is another example of
SWIP difficulty.  Very hard to provide a street
address to SWIP a bus when it is mobile 16 hours
a day.

Not at all. A bus would be SWIPd to the bus yard or
administrative offices of the bus company. The SWIP
data is not required to be the service address, it
is required to be an address for administrative
and/or technical contact regarding the network
and/or legal process service regarding same.

[rest trimmed because we are in agreement on that part]

Owen

On Thu, 20 Jul 2017, Chris James wrote:

  

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

[Owen DeLong]

I called it specious when it was first argued and I continue to call it 
specious. 

Owen


> On Jul 25, 2017, at 15:12, Paul McNary  wrote:
> 
> Owen
> Several weeks ago geolocation was one of the arguments for having accurate 
> whois in this thread.
> This is no longer being argued?
> Paul
> 
>> On 7/25/2017 4:26 PM, Owen DeLong wrote:
>> Huh?
>> 
>> WHOIS is not a geolocation service and anyone who thinks it is should reduce 
>> their use of recreational pharmaceuticals.
>> 
>> Owen
>> 
>>> On Jul 24, 2017, at 12:03 , Paul McNary  wrote:
>>> 
>>> Then that totally negates the reasoning for geolocation.
>>> The administrative address could be on the other side of the earth.
>>> 
>>> Paul
>>> 
>>> 
>>> On 7/24/2017 1:31 PM, Owen DeLong wrote:
> On Jul 20, 2017, at 14:28 , hostmas...@uneedus.com wrote:
> 
> My transit bus example is another example of SWIP difficulty.  Very hard 
> to provide a street address to SWIP a bus when it is mobile 16 hours a 
> day.
 Not at all. A bus would be SWIPd to the bus yard or administrative offices 
 of the bus company. The SWIP data is not required to be the service 
 address, it is required to be an address for administrative and/or 
 technical contact regarding the network and/or legal process service 
 regarding same.
 
 [rest trimmed because we are in agreement on that part]
 
 Owen
 
>> On Thu, 20 Jul 2017, Chris James wrote:
>> @Paul - The API key is to email it.
>> 
>> @Owen - Very difficult when you have dynamic ranges, and vps/container
>> platforms spanning tens of thousands of instances across these dynamic
>> ranges.
>> 
>> 
>>> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary  
>>> wrote:
>>> 
>>> Owen
>>> 
>>> The reassignment policy page says IPv6 has to be done vi API.
>>> Is that something else that is incorrect on the web site?
>>> 
>>> Paul
>>> 
>>> 
 On 7/20/2017 3:16 PM, Owen DeLong wrote:
 
 How can it be overly difficult to fill out an email template with your
 customers’
 Name, Address, Phone Number?
 
 Really?
 
 Owen
 
 On Jul 19, 2017, at 23:48 , Pallieter Koopmans 
 
> wrote:
> 
> Hello,
> 
> ARIN could quantify and require rules for when to SWIP, but in the
> end, there are going to be exceptions needed if the rules are to be
> strictly followed. Many will not separately SWIP a separately routed
> sub-block if it is too difficult or pointless to gather and share that
> data back upstream to ARIN.
> 
> Thus a more fuzzy rule to require a best-effort and to add a
> rule-based reason (preferably both a carrot and a stick) for block
> owners to do their best to provide (only) useful data. In order to do
> that, one needs to look back at why that data is needed. For a block
> owner to assign the SWIP on a sub-block, he basically delegates tech
> and abuse contact requests down to those that are probably more likely
> to be able to actually act on the tech/abuse requests (and thus reduce
> request-handling workload higher up and overall). But for that to
> work, those tech/abuse contact requests need to be actually handled,
> otherwise, it is better to leave them with the block owner.
> 
> In the end, the contact details should be as close to the "person"
> that is actually capable to both handle (think: volume/languages/etc)
> and act (think: authority) on the tech/abuse requests.
> 
> eBrain
> Innovative Internet Ideas
> 
> Pallieter Koopmans
> Managing Director
> 
> +31-6-3400-3800 (mon-sat 9-22 CET)
> Skype: PallieterKoopmans
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
 Unsubscribe or manage your mailing list subscription at:
 http://lists.arin.net/mailman/listinfo/arin-ppml
 Please contact i...@arin.net if you experience any issues.
 
>>> ___
>>> PPML
>>> You are receiving this message because you are subscribed to

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

[Owen DeLong]

> On Jul 25, 2017, at 15:46, Paul McNary  wrote:
> 
> Let me change "geolocation" to "address tracking".
> For instance, Netflix blocks a certain region and whois is showing customer
> in that region, whereas the customer is actually in a non-blocked region.
> If I had my own IPv4 /24 or above I don't have any issue making this entry 
> correct to ARIN.

I know for a fact that Netflix bases very little (if any) of their geo-fencing 
on Whois data. 

> But I have a /25 block from a datacenter that shows I am in California.
> Their SWIP policy on IPv4 is /24 to SWIP.
> We are trying to minimize these issues as we deploy IPv6 when we have direct 
> allocation.
> I am not debating the "address tracking" issue just brought it up because I 
> think John made a comment about it.

I think if you review the record I stated early on that I didn't believe 
geolocation was a practical use of Whois. 

> We see ebay, amazon, craig's list all using whois information.

Really? Source needed. 

In my experience they use other geolocation providers. 

> Also our /25's have been blocked at the /24 and /18 level.
> We had /24's blocked that are reallocated at the parent /18 level.
> So unless there is some way to enforce, it just seems to be words on paper.

Enforce what? Geolocation is a truly black art and there is no central clearing 
house or community driven policy body driving its practitioners. 

> 
> CHANGE of subject not topic
> --
> What I had wished to do on IPv6 deployment is assign an IPv6 /48 to each 
> Tower(WISP), each POP(ISP)
> I would want that switched as will as any individually announced block 
> smaller than that.
> Haven't decided but have a separate /48 to handle DNS, mail servers, etc. ie 
> Our Infrastructure
> Anything less specific that a /48 would just add noise to the world and would 
> be somewhat proprietary.
> I give away some info just advertising my POP's/Towers but I think that would 
> be for the collective good. :-)
> The world doesn't need to know my Access Points or neighborhood routers, etc.

I see no reason you can't accomplish this under the proposed policy. I support 
the current draft as previously stated. 


Owen

>  
> I think I need to get off my soapbox and take a nap now!
> I know I ramble a lot, but getting too old to change much! :-)
> Thanks
> Take care
> Paul
> 
>> On 7/25/2017 5:17 PM, Scott Leibrand wrote:
>> If I, as an End User network, want to inform geolocation providers of where 
>> I'm using each netblock, having them assigned to me in the whois DB with an 
>> appropriate address is one of the best ways to do that.  But if I'm running 
>> a geolocation service, I can't rely on whois as the sole source of data on 
>> where an address is used.  If I have other info that contradicts the whois 
>> information, I'd probably just ignore the whois data and go with the facts 
>> on the ground.
>> 
>> -Scott
>> 
>>> On Tue, Jul 25, 2017 at 3:12 PM, Paul McNary  wrote:
>>> Owen
>>> Several weeks ago geolocation was one of the arguments for having accurate 
>>> whois in this thread.
>>> This is no longer being argued?
>>> Paul
>>> 
>>> 
 On 7/25/2017 4:26 PM, Owen DeLong wrote:
 Huh?
 
 WHOIS is not a geolocation service and anyone who thinks it is should 
 reduce their use of recreational pharmaceuticals.
 
 Owen
 
> On Jul 24, 2017, at 12:03 , Paul McNary  wrote:
> 
> Then that totally negates the reasoning for geolocation.
> The administrative address could be on the other side of the earth.
> 
> Paul
> 
> 
>> On 7/24/2017 1:31 PM, Owen DeLong wrote:
>>> On Jul 20, 2017, at 14:28 , hostmas...@uneedus.com wrote:
>>> 
>>> My transit bus example is another example of SWIP difficulty.  Very 
>>> hard to provide a street address to SWIP a bus when it is mobile 16 
>>> hours a day.
>> Not at all. A bus would be SWIPd to the bus yard or administrative 
>> offices of the bus company. The SWIP data is not required to be the 
>> service address, it is required to be an address for administrative 
>> and/or technical contact regarding the network and/or legal process 
>> service regarding same.
>> 
>> [rest trimmed because we are in agreement on that part]
>> 
>> Owen
>> 
 On Thu, 20 Jul 2017, Chris James wrote:
 @Paul - The API key is to email it.
 
 @Owen - Very difficult when you have dynamic ranges, and vps/container
 platforms spanning tens of thousands of instances across these dynamic
 ranges.
 
 
 On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary  
 wrote:
 
> Owen
> 
> The reassignment policy page says IPv6 has to be done vi API.
> Is that something else that is incorrect on the web site?
> 
> Paul

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

[Scott Leibrand]

If I, as an End User network, want to inform geolocation providers of where
I'm using each netblock, having them assigned to me in the whois DB with an
appropriate address is one of the best ways to do that.  But if I'm running
a geolocation service, I can't rely on whois as the sole source of data on
where an address is used.  If I have other info that contradicts the whois
information, I'd probably just ignore the whois data and go with the facts
on the ground.

-Scott

On Tue, Jul 25, 2017 at 3:12 PM, Paul McNary  wrote:

> Owen
> Several weeks ago geolocation was one of the arguments for having accurate
> whois in this thread.
> This is no longer being argued?
> Paul
>
>
> On 7/25/2017 4:26 PM, Owen DeLong wrote:
>
>> Huh?
>>
>> WHOIS is not a geolocation service and anyone who thinks it is should
>> reduce their use of recreational pharmaceuticals.
>>
>> Owen
>>
>> On Jul 24, 2017, at 12:03 , Paul McNary  wrote:
>>>
>>> Then that totally negates the reasoning for geolocation.
>>> The administrative address could be on the other side of the earth.
>>>
>>> Paul
>>>
>>>
>>> On 7/24/2017 1:31 PM, Owen DeLong wrote:
>>>
 On Jul 20, 2017, at 14:28 , hostmas...@uneedus.com wrote:
>
> My transit bus example is another example of SWIP difficulty.  Very
> hard to provide a street address to SWIP a bus when it is mobile 16 hours 
> a
> day.
>
 Not at all. A bus would be SWIPd to the bus yard or administrative
 offices of the bus company. The SWIP data is not required to be the service
 address, it is required to be an address for administrative and/or
 technical contact regarding the network and/or legal process service
 regarding same.

 [rest trimmed because we are in agreement on that part]

 Owen

 On Thu, 20 Jul 2017, Chris James wrote:
>
>> @Paul - The API key is to email it.
>>
>> @Owen - Very difficult when you have dynamic ranges, and vps/container
>> platforms spanning tens of thousands of instances across these dynamic
>> ranges.
>>
>>
>> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary 
>> wrote:
>>
>> Owen
>>>
>>> The reassignment policy page says IPv6 has to be done vi API.
>>> Is that something else that is incorrect on the web site?
>>>
>>> Paul
>>>
>>>
>>> On 7/20/2017 3:16 PM, Owen DeLong wrote:
>>>
>>> How can it be overly difficult to fill out an email template with
 your
 customers’
 Name, Address, Phone Number?

 Really?

 Owen

 On Jul 19, 2017, at 23:48 , Pallieter Koopmans <
 pallie...@pallieter.org>

> wrote:
>
> Hello,
>
> ARIN could quantify and require rules for when to SWIP, but in the
> end, there are going to be exceptions needed if the rules are to be
> strictly followed. Many will not separately SWIP a separately
> routed
> sub-block if it is too difficult or pointless to gather and share
> that
> data back upstream to ARIN.
>
> Thus a more fuzzy rule to require a best-effort and to add a
> rule-based reason (preferably both a carrot and a stick) for block
> owners to do their best to provide (only) useful data. In order to
> do
> that, one needs to look back at why that data is needed. For a
> block
> owner to assign the SWIP on a sub-block, he basically delegates
> tech
> and abuse contact requests down to those that are probably more
> likely
> to be able to actually act on the tech/abuse requests (and thus
> reduce
> request-handling workload higher up and overall). But for that to
> work, those tech/abuse contact requests need to be actually
> handled,
> otherwise, it is better to leave them with the block owner.
>
> In the end, the contact details should be as close to the "person"
> that is actually capable to both handle (think:
> volume/languages/etc)
> and act (think: authority) on the tech/abuse requests.
>
> eBrain
> Innovative Internet Ideas
>
> Pallieter Koopmans
> Managing Director
>
> +31-6-3400-3800 (mon-sat 9-22 CET)
> Skype: PallieterKoopmans
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
> ___
 PPML

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

[Paul McNary]

Owen
Several weeks ago geolocation was one of the arguments for having 
accurate whois in this thread.

This is no longer being argued?
Paul

On 7/25/2017 4:26 PM, Owen DeLong wrote:

Huh?

WHOIS is not a geolocation service and anyone who thinks it is should reduce 
their use of recreational pharmaceuticals.

Owen


On Jul 24, 2017, at 12:03 , Paul McNary  wrote:

Then that totally negates the reasoning for geolocation.
The administrative address could be on the other side of the earth.

Paul


On 7/24/2017 1:31 PM, Owen DeLong wrote:

On Jul 20, 2017, at 14:28 , hostmas...@uneedus.com wrote:

My transit bus example is another example of SWIP difficulty.  Very hard to 
provide a street address to SWIP a bus when it is mobile 16 hours a day.

Not at all. A bus would be SWIPd to the bus yard or administrative offices of 
the bus company. The SWIP data is not required to be the service address, it is 
required to be an address for administrative and/or technical contact regarding 
the network and/or legal process service regarding same.

[rest trimmed because we are in agreement on that part]

Owen


On Thu, 20 Jul 2017, Chris James wrote:

@Paul - The API key is to email it.

@Owen - Very difficult when you have dynamic ranges, and vps/container
platforms spanning tens of thousands of instances across these dynamic
ranges.


On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary  wrote:


Owen

The reassignment policy page says IPv6 has to be done vi API.
Is that something else that is incorrect on the web site?

Paul


On 7/20/2017 3:16 PM, Owen DeLong wrote:


How can it be overly difficult to fill out an email template with your
customers’
Name, Address, Phone Number?

Really?

Owen

On Jul 19, 2017, at 23:48 , Pallieter Koopmans 

wrote:

Hello,

ARIN could quantify and require rules for when to SWIP, but in the
end, there are going to be exceptions needed if the rules are to be
strictly followed. Many will not separately SWIP a separately routed
sub-block if it is too difficult or pointless to gather and share that
data back upstream to ARIN.

Thus a more fuzzy rule to require a best-effort and to add a
rule-based reason (preferably both a carrot and a stick) for block
owners to do their best to provide (only) useful data. In order to do
that, one needs to look back at why that data is needed. For a block
owner to assign the SWIP on a sub-block, he basically delegates tech
and abuse contact requests down to those that are probably more likely
to be able to actually act on the tech/abuse requests (and thus reduce
request-handling workload higher up and overall). But for that to
work, those tech/abuse contact requests need to be actually handled,
otherwise, it is better to leave them with the block owner.

In the end, the contact details should be as close to the "person"
that is actually capable to both handle (think: volume/languages/etc)
and act (think: authority) on the tech/abuse requests.

eBrain
Innovative Internet Ideas

Pallieter Koopmans
Managing Director

+31-6-3400-3800 (mon-sat 9-22 CET)
Skype: PallieterKoopmans
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

--
This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. This company is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the company.

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

[Paul McNary]

"NOTE: IPv6 simple reassigns are only available in the RESTful web 
service ."



On 7/25/2017 4:25 PM, Owen DeLong wrote:
I think you’re misinterpreting something on that page. I might be 
blind, but I don’t read anything on that page to say that IPv6 
reassignments must be done by RESTful API.


I know that in practice you can do IPv6 reassignments via RWHOIS and I 
believe templates are also supported as well as ARIN On-Line.


Certainly the NRPM is the authoritative governing document, so if 
there is a shortcoming in the process as implemented such that it 
doesn’t line up with policy, the correct response would be to bring 
this to staff’s attention and request that they address it. However, 
to the best of my knowledge, there is no such discrepancy.


If you can highlight the portions of that page which you believe to be 
errant in nature, I’m happy to try and work with staff to make sure 
they get clarified.


Owen

On Jul 24, 2017, at 12:01 , Paul McNary > wrote:


https://www.arin.net/resources/request/reassignments.html



On 7/24/2017 1:28 PM, Owen DeLong wrote:


On Jul 20, 2017, at 13:51 , Paul McNary > wrote:


Owen

The reassignment policy page says IPv6 has to be done vi API.
Is that something else that is incorrect on the web site?

Paul


I’m not sure what the “reassignment policy page” you refer to is, 
but here’s the quote from the NRPM:


6.5.5. Registration

ISPs are required to demonstrate efficient use of IP address
space allocations by providing appropriate documentation,
including but not limited to assignment histories, showing their
efficient use.

6.5.5.1. Reassignment information
Each static IPv6 assignment containing a /64 or more addresses
shall be registered in the WHOIS directory via SWIP or a
distributed service which meets the standards set forth in
section 3.2. Reassignment registrations shall include each
client's organizational information, except where specifically
exempted by this policy.

6.5.5.2. Assignments visible within 7 days
All assignments shall be made visible as required in section
4.2.3.7.1 within seven calendar days of assignment.

6.5.5.3. Residential Subscribers
6.5.5.3.1. Residential Customer Privacy
To maintain the privacy of their residential customers, an
organization with downstream residential customers holding /64
and larger blocks may substitute that organization's name for
the customer's name, e.g. 'Private Customer - XYZ Network', and
the customer's street address may read 'Private Residence'. Each
private downstream residential reassignment must have
accurate upstream Abuse and Technical POCs visible on the WHOIS
record for that block.

I’ll call your attention to the phrase in 6.5.5.1 which states 
"registered in the WHOIS directory via SWIP or a distributed service 
which meets the standards set forth in section 3.2” which at this 
point includes (IIRC) SWIP, RestFUL API, RWHOIS, and possibly RDAP.



I’ll also note that 6.5.5.3.1 provides for the residential customer 
privacy as I defined it, regardless of the mechanism used to make 
the data available.


Given that, can you clarify your above statement?

Owen




On 7/20/2017 3:16 PM, Owen DeLong wrote:
How can it be overly difficult to fill out an email template with 
your customers’

Name, Address, Phone Number?

Really?

Owen

On Jul 19, 2017, at 23:48 , Pallieter Koopmans 
> wrote:


Hello,

ARIN could quantify and require rules for when to SWIP, but in the
end, there are going to be exceptions needed if the rules are to be
strictly followed. Many will not separately SWIP a separately routed
sub-block if it is too difficult or pointless to gather and share 
that

data back upstream to ARIN.

Thus a more fuzzy rule to require a best-effort and to add a
rule-based reason (preferably both a carrot and a stick) for block
owners to do their best to provide (only) useful data. In order to do
that, one needs to look back at why that data is needed. For a block
owner to assign the SWIP on a sub-block, he basically delegates tech
and abuse contact requests down to those that are probably more 
likely
to be able to actually act on the tech/abuse requests (and thus 
reduce

request-handling workload higher up and overall). But for that to
work, those tech/abuse contact requests need to be actually handled,
otherwise, it is better to leave them with the block owner.

In the end, the contact details should be as close to the "person"
that is actually capable to both handle (think: volume/languages/etc)
and act (think: authority) on the tech/abuse requests.

eBrain
Innovative Internet Ideas

Pallieter Koopmans
Managing Director

+31-6-3400-3800 (mon-sat 9-22 CET)
Skype: PallieterKoopmans

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

[Owen DeLong]

> On Jul 25, 2017, at 10:34 , Michael Peddemors  wrote:
> 
> On 17-07-24 05:06 PM, Tony Hain wrote:
>> I still don’t see any value in specifying length. What you are looking for 
>> is contact info for someone with a clue about how a given network works and 
>> using length as a really poor proxy. I could live with a fourth line:
>> Any end network emitting SMTP system SHOULD provide SWIP.
>> I just don’t know how that gets enforced in any reasonable way. In general 
>> SMTP & independent routing are the big targets needing accurate contact 
>> info, and length has absolutely nothing to do with either.
>> Tony
> 
> While I agree in principle, it CAN be provided by "SWIP" OR 'rwhois', and 
> that should be pointed out, as rwhois is more flexible in the IPv4 space, eg 
> providing allocation information to the /32 level.
> 
> This again goes to an earlier email where I described that it should be more 
> conceptual, than specific ranges..
> 
> It should be, "if a party is responsible for the originating traffic", then 
> that party should be displayed via SWIP/rwhois.

Well… That’s hard to implement in practice. How do we go about SWIPing all 
those home windows boxes to the hackers that are actually controlling the 
emitted traffic?

Owen

___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Owen DeLong]

Huh?

WHOIS is not a geolocation service and anyone who thinks it is should reduce 
their use of recreational pharmaceuticals.

Owen

> On Jul 24, 2017, at 12:03 , Paul McNary  wrote:
> 
> Then that totally negates the reasoning for geolocation.
> The administrative address could be on the other side of the earth.
> 
> Paul
> 
> 
> On 7/24/2017 1:31 PM, Owen DeLong wrote:
>>> On Jul 20, 2017, at 14:28 , hostmas...@uneedus.com wrote:
>>> 
>>> My transit bus example is another example of SWIP difficulty.  Very hard to 
>>> provide a street address to SWIP a bus when it is mobile 16 hours a day.
>> Not at all. A bus would be SWIPd to the bus yard or administrative offices 
>> of the bus company. The SWIP data is not required to be the service address, 
>> it is required to be an address for administrative and/or technical contact 
>> regarding the network and/or legal process service regarding same.
>> 
>> [rest trimmed because we are in agreement on that part]
>> 
>> Owen
>> 
>>> On Thu, 20 Jul 2017, Chris James wrote:
 @Paul - The API key is to email it.
 
 @Owen - Very difficult when you have dynamic ranges, and vps/container
 platforms spanning tens of thousands of instances across these dynamic
 ranges.
 
 
 On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary  wrote:
 
> Owen
> 
> The reassignment policy page says IPv6 has to be done vi API.
> Is that something else that is incorrect on the web site?
> 
> Paul
> 
> 
> On 7/20/2017 3:16 PM, Owen DeLong wrote:
> 
>> How can it be overly difficult to fill out an email template with your
>> customers’
>> Name, Address, Phone Number?
>> 
>> Really?
>> 
>> Owen
>> 
>> On Jul 19, 2017, at 23:48 , Pallieter Koopmans 
>>> wrote:
>>> 
>>> Hello,
>>> 
>>> ARIN could quantify and require rules for when to SWIP, but in the
>>> end, there are going to be exceptions needed if the rules are to be
>>> strictly followed. Many will not separately SWIP a separately routed
>>> sub-block if it is too difficult or pointless to gather and share that
>>> data back upstream to ARIN.
>>> 
>>> Thus a more fuzzy rule to require a best-effort and to add a
>>> rule-based reason (preferably both a carrot and a stick) for block
>>> owners to do their best to provide (only) useful data. In order to do
>>> that, one needs to look back at why that data is needed. For a block
>>> owner to assign the SWIP on a sub-block, he basically delegates tech
>>> and abuse contact requests down to those that are probably more likely
>>> to be able to actually act on the tech/abuse requests (and thus reduce
>>> request-handling workload higher up and overall). But for that to
>>> work, those tech/abuse contact requests need to be actually handled,
>>> otherwise, it is better to leave them with the block owner.
>>> 
>>> In the end, the contact details should be as close to the "person"
>>> that is actually capable to both handle (think: volume/languages/etc)
>>> and act (think: authority) on the tech/abuse requests.
>>> 
>>> eBrain
>>> Innovative Internet Ideas
>>> 
>>> Pallieter Koopmans
>>> Managing Director
>>> 
>>> +31-6-3400-3800 (mon-sat 9-22 CET)
>>> Skype: PallieterKoopmans
>>> ___
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact i...@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@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@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@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
 -- 
 This e-mail message may contain confidential or legally privileged
 information and is intended only for the use of the intended recipient(s).
 Any unauthorized disclosure, dissemination, distribution, copying or the
 taking of any action in reliance on the information herein is prohibited.
 E-mails are not secure and cannot be guaranteed to be 

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

[Owen DeLong]

I think you’re misinterpreting something on that page. I might be blind, but I 
don’t read anything on that page to say that IPv6 reassignments must be done by 
RESTful API.

I know that in practice you can do IPv6 reassignments via RWHOIS and I believe 
templates are also supported as well as ARIN On-Line.

Certainly the NRPM is the authoritative governing document, so if there is a 
shortcoming in the process as implemented such that it doesn’t line up with 
policy, the correct response would be to bring this to staff’s attention and 
request that they address it. However, to the best of my knowledge, there is no 
such discrepancy.

If you can highlight the portions of that page which you believe to be errant 
in nature, I’m happy to try and work with staff to make sure they get clarified.

Owen

> On Jul 24, 2017, at 12:01 , Paul McNary  wrote:
> 
> https://www.arin.net/resources/request/reassignments.html 
> 
> 
> 
> On 7/24/2017 1:28 PM, Owen DeLong wrote:
>> 
>>> On Jul 20, 2017, at 13:51 , Paul McNary >> > wrote:
>>> 
>>> Owen
>>> 
>>> The reassignment policy page says IPv6 has to be done vi API.
>>> Is that something else that is incorrect on the web site?
>>> 
>>> Paul
>> 
>> I’m not sure what the “reassignment policy page” you refer to is, but here’s 
>> the quote from the NRPM:
>> 
>> 6.5.5. Registration
>> 
>> ISPs are required to demonstrate efficient use of IP address space 
>> allocations by providing appropriate documentation, including but not 
>> limited to assignment histories, showing their efficient use.
>> 
>> 6.5.5.1. Reassignment information
>> Each static IPv6 assignment containing a /64 or more addresses shall be 
>> registered in the WHOIS directory via SWIP or a distributed service which 
>> meets the standards set forth in section 3.2. Reassignment registrations 
>> shall include each client's organizational information, except where 
>> specifically exempted by this policy.
>> 
>> 6.5.5.2. Assignments visible within 7 days
>> All assignments shall be made visible as required in section 4.2.3.7.1 
>> within seven calendar days of assignment.
>> 
>> 6.5.5.3. Residential Subscribers
>> 6.5.5.3.1. Residential Customer Privacy
>> To maintain the privacy of their residential customers, an organization with 
>> downstream residential customers holding /64 and larger blocks may 
>> substitute that organization's name for the customer's name, e.g. 'Private 
>> Customer - XYZ Network', and the customer's street address may read 'Private 
>> Residence'. Each private downstream residential reassignment must have 
>> accurate upstream Abuse and Technical POCs visible on the WHOIS record for 
>> that block.
>> 
>> I’ll call your attention to the phrase in 6.5.5.1 which states "registered 
>> in the WHOIS directory via SWIP or a distributed service which meets the 
>> standards set forth in section 3.2” which at this point includes (IIRC) 
>> SWIP, RestFUL API, RWHOIS, and possibly RDAP.
>> 
>> 
>> I’ll also note that 6.5.5.3.1 provides for the residential customer privacy 
>> as I defined it, regardless of the mechanism used to make the data available.
>> 
>> Given that, can you clarify your above statement?
>> 
>> Owen
>> 
>>> 
>>> 
>>> On 7/20/2017 3:16 PM, Owen DeLong wrote:
 How can it be overly difficult to fill out an email template with your 
 customers’
 Name, Address, Phone Number?
 
 Really?
 
 Owen
 
> On Jul 19, 2017, at 23:48 , Pallieter Koopmans  > wrote:
> 
> Hello,
> 
> ARIN could quantify and require rules for when to SWIP, but in the
> end, there are going to be exceptions needed if the rules are to be
> strictly followed. Many will not separately SWIP a separately routed
> sub-block if it is too difficult or pointless to gather and share that
> data back upstream to ARIN.
> 
> Thus a more fuzzy rule to require a best-effort and to add a
> rule-based reason (preferably both a carrot and a stick) for block
> owners to do their best to provide (only) useful data. In order to do
> that, one needs to look back at why that data is needed. For a block
> owner to assign the SWIP on a sub-block, he basically delegates tech
> and abuse contact requests down to those that are probably more likely
> to be able to actually act on the tech/abuse requests (and thus reduce
> request-handling workload higher up and overall). But for that to
> work, those tech/abuse contact requests need to be actually handled,
> otherwise, it is better to leave them with the block owner.
> 
> In the end, the contact details should be as close to the "person"
> that is actually capable to both handle (think: volume/languages/etc)
> and act (think: authority) on the tech/abuse requests.

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

[Michael Peddemors]

On 17-07-24 05:06 PM, Tony Hain wrote:
I still don’t see any value in specifying length. What you are looking 
for is contact info for someone with a clue about how a given network 
works and using length as a really poor proxy. I could live with a 
fourth line:


Any end network emitting SMTP system SHOULD provide SWIP.

I just don’t know how that gets enforced in any reasonable way. In 
general SMTP & independent routing are the big targets needing accurate 
contact info, and length has absolutely nothing to do with either.


Tony


While I agree in principle, it CAN be provided by "SWIP" OR 'rwhois', 
and that should be pointed out, as rwhois is more flexible in the IPv4 
space, eg providing allocation information to the /32 level.


This again goes to an earlier email where I described that it should be 
more conceptual, than specific ranges..


It should be, "if a party is responsible for the originating traffic", 
then that party should be displayed via SWIP/rwhois.


Of course, we can just look at the sad state of this in IPv4, eg large 
cloud providers assigning IP(s), without any indication who the 
responsible party is (eg Amazon, MicroSoft, and many large hosting 
providers)


The concern is again, writing something up that is a 'mandate', yet 
without any form of 'enforcement', it will simply be ignored...






--
"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 (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Tony Hain]

I still don’t see any value in specifying length. What you are looking for is 
contact info for someone with a clue about how a given network works and using 
length as a really poor proxy. I could live with a fourth line:

 

Any end network emitting SMTP system SHOULD provide SWIP. 

 

I just don’t know how that gets enforced in any reasonable way. In general SMTP 
& independent routing are the big targets needing accurate contact info, and 
length has absolutely nothing to do with either. 

 

Tony

 

 

From: David Farmer [mailto:far...@umn.edu] 
Sent: Monday, July 24, 2017 2:53 PM
To: Tony Hain
Cc: arin-ppml@arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment 
Registration requirements between IPv4 and IPv6 - updated 2017-07-21

 

Actually, let me revise that; I'm willing to recognize at least the possibility 
there is a legitimate community interest in having records for assignments that 
are shorter than /40 for IPv6 and /24 for IPv4.  Why, those numbers?  They are 
the sizes at the bottom of ARIN's fee schedule, if anything smaller is the same 
fee, I'm not sure where there is a compelling community policy interest. 

 

On Mon, Jul 24, 2017 at 4:07 PM, David Farmer <far...@umn.edu> wrote:

Honestly, I could live with it just those three lines.  However, I'm willing to 
recognize at least the possibility there is a legitimate community interest in 
having records for assignments that are shorter than /48. 

 

As for IPv4, I'd also be just fine with those three lines.  Again, recognizing 
at least the possibility there is a legitimate community interest in having 
records for assignments that are shorter than /24

 

On Mon, Jul 24, 2017 at 2:51 PM, Tony Hain <alh-i...@tndh.net> wrote:

While I agree with the general direction David is heading, his text is still 
overly complex to deal with the goal. This whole thread only requires 3 lines:

 

Reallocations MUST provide SWIP.

Requests by the assignee MUST provide SWIP.
Anything appearing independently in the global routing table SHOULD provide 
SWIP.

 

All the rest is noise that doesn’t add to solving any problem known to mankind, 
and is simply an artifact of the IPv4-think insane conservation mindset. Size 
is irrelevant in both protocol versions, and even if you think it is, the only 
time it comes up is in #3. In any case the length of #3 might change over time, 
and there is no reason the policy text needs to change to track it. If 
something is independent, no matter what it’s length is, the intent is to have 
accurate contact info. 

 

Saying anything more is trying to legislate ISP behavior, which is explicitly 
outside the scope of ARIN.

 

Tony




 

-- 

===
David Farmer   Email:far...@umn.edu <mailto:email%3afar...@umn.edu> 
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota   
2218 University Ave SEPhone: 612-626-0815 <tel:(612)%20626-0815> 
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <tel:(612)%20812-9952> 
=== 





 

-- 

===
David Farmer   Email:far...@umn.edu <mailto:email%3afar...@umn.edu> 
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota   
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
=== 

___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[David Farmer]

Actually, let me revise that; I'm willing to recognize at least the
possibility there is a legitimate community interest in having records for
assignments that are shorter than /40 for IPv6 and /24 for IPv4.  Why,
those numbers?  They are the sizes at the bottom of ARIN's fee schedule, if
anything smaller is the same fee, I'm not sure where there is a compelling
community policy interest.

On Mon, Jul 24, 2017 at 4:07 PM, David Farmer  wrote:

> Honestly, I could live with it just those three lines.  However, I'm
> willing to recognize at least the possibility there is a legitimate
> community interest in having records for assignments that are shorter than
> /48.
>
> As for IPv4, I'd also be just fine with those three lines.  Again,
> recognizing at least the possibility there is a legitimate community
> interest in having records for assignments that are shorter than /24
>
> On Mon, Jul 24, 2017 at 2:51 PM, Tony Hain  wrote:
>
>> While I agree with the general direction David is heading, his text is
>> still overly complex to deal with the goal. This whole thread only requires
>> 3 lines:
>>
>>
>>
>> Reallocations MUST provide SWIP.
>>
>> Requests by the assignee MUST provide SWIP.
>> Anything appearing independently in the global routing table SHOULD
>> provide SWIP.
>>
>>
>>
>> All the rest is noise that doesn’t add to solving any problem known to
>> mankind, and is simply an artifact of the IPv4-think insane conservation
>> mindset. Size is irrelevant in both protocol versions, and even if you
>> think it is, the only time it comes up is in #3. In any case the length of
>> #3 might change over time, and there is no reason the policy text needs to
>> change to track it. If something is independent, no matter what it’s length
>> is, the intent is to have accurate contact info.
>>
>>
>>
>> Saying anything more is trying to legislate ISP behavior, which is
>> explicitly outside the scope of ARIN.
>>
>>
>>
>> Tony
>>
>
>
> --
> ===
> David Farmer   Email:far...@umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SEPhone: 612-626-0815 <(612)%20626-0815>
> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
> ===
>



-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[David Farmer]

Honestly, I could live with it just those three lines.  However, I'm
willing to recognize at least the possibility there is a legitimate
community interest in having records for assignments that are shorter than
/48.

As for IPv4, I'd also be just fine with those three lines.  Again,
recognizing at least the possibility there is a legitimate community
interest in having records for assignments that are shorter than /24

On Mon, Jul 24, 2017 at 2:51 PM, Tony Hain  wrote:

> While I agree with the general direction David is heading, his text is
> still overly complex to deal with the goal. This whole thread only requires
> 3 lines:
>
>
>
> Reallocations MUST provide SWIP.
>
> Requests by the assignee MUST provide SWIP.
> Anything appearing independently in the global routing table SHOULD
> provide SWIP.
>
>
>
> All the rest is noise that doesn’t add to solving any problem known to
> mankind, and is simply an artifact of the IPv4-think insane conservation
> mindset. Size is irrelevant in both protocol versions, and even if you
> think it is, the only time it comes up is in #3. In any case the length of
> #3 might change over time, and there is no reason the policy text needs to
> change to track it. If something is independent, no matter what it’s length
> is, the intent is to have accurate contact info.
>
>
>
> Saying anything more is trying to legislate ISP behavior, which is
> explicitly outside the scope of ARIN.
>
>
>
> Tony
>


-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[james machado]

On Mon, Jul 24, 2017 at 12:48 PM,  wrote:

> In the case of that 69.0.0.0 block we were talking about, it may not be on
> the other side of the earth, but certainly in different states.  That block
> had the serving site as CT, the parent record as TX, and a note in that
> record to send legal process to FL.  Quite a trip.
>
> What is the purpose of the SWIP record, if the contact is nowhere near the
> site?
>
>
I don't care where you network is.  I care that you know what it is doing
and that when I contact you about your network you will deal with it.



> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
>
On a side note I agree with Tony's version. It's clear and concise and it
doesn't require a re-write when a new assignment paradigm comes out to play.

James
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Tony Hain]

While I agree with the general direction David is heading, his text is still 
overly complex to deal with the goal. This whole thread only requires 3 lines:

 

Reallocations MUST provide SWIP.

Requests by the assignee MUST provide SWIP.
Anything appearing independently in the global routing table SHOULD provide 
SWIP.

 

All the rest is noise that doesn’t add to solving any problem known to mankind, 
and is simply an artifact of the IPv4-think insane conservation mindset. Size 
is irrelevant in both protocol versions, and even if you think it is, the only 
time it comes up is in #3. In any case the length of #3 might change over time, 
and there is no reason the policy text needs to change to track it. If 
something is independent, no matter what it’s length is, the intent is to have 
accurate contact info. 

 

Saying anything more is trying to legislate ISP behavior, which is explicitly 
outside the scope of ARIN.

 

Tony

 

 

From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net] On Behalf Of David Farmer
Sent: Sunday, July 23, 2017 7:03 AM
To: arin-ppml@arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment 
Registration requirements between IPv4 and IPv6 - updated 2017-07-21

 

The rewrite is a pretty good step forward, and I support this policy as 
written, but I also would like to see some additional changes. 

 

The following is a summary of what I would like to see the overall policy look 
like, it is not in policy language but provided as list of requirement, with 
some additional notes, then I note what I think is missing from the current 
proposed policy text;

 

Reallocations:

- All reallocations* MUST have a SWIP provided regardless of size.

 

Reassignments: 

- For prefixes shorter than /48 a SWIP MUST be provided.

- For prefixes at /48 or longer a SWIP is provided at the discretion** of the 
ISP, except; 

  - If requested by the end-user, then a SWIP MUST be provided, or;

  - If intended to appear in global routing table, then a SWIP SHOULD*** be 
provided.

 

*  Reallocations are made to other ISPs which then can make reassignments, for 
IPv6 it is RECOMMENDED that all ISPs obtain an allocation directly from ARIN, 
however reallocations are still permitted. Further, reallocations for prefixes 
/48 or longer are NOT RECOMMENDED.  SWIPs for reallocations need to be required 
because the abuse and other POC for the down stream ISP need to be know.

 

** There should be some guidance (NOT policy enforced by ARIN) to ISPs making 
reassignments at /48 or longer: SWIPs for business customers, especially those 
with information technology(IT) operations sophisticated enough to handle their 
own abuse and/or technical incidents, are of interest to the community. SWIPs 
for residential customers (individual persons) are NOT normally of interest to 
the community.

 

*** This might be more appropriate as MUST, however as ARIN does not define 
routing policy, therefore SHOULD seems more appropriate.


 

So, I think the following is missing from the current proposed policy text;

 

1. Any mention of reallocations, but this wasn't in the original policy either 

2. A requirement that SWIP is provided if requested by end-user

3. Guidance for SWIPs for /48 or longer, while these SWIPs aren't required, 
some guidance still might be useful.

 

Thanks

 

On Fri, Jul 21, 2017 at 11:44 AM, Leif Sawyer <lsaw...@gci.com> wrote:

Happy Friday, everybody.

 

As promised, here is the latest rewrite of the draft policy below,  and it will 
soon be updated at:

https://www.arin.net/policy/proposals/2017_5.html

 

There are two changes noted in the policy statement: the first of which 
reflects what seems to be the current

consensus of the PPML regarding netblock sizing; the second is to strike 
language that may be read as either restrictive

or non-operational.

 



 

Problem Statement:

   Current ARIN policy has different WHOIS directory registration 
requirements for IPv4 vs IPv6 address assignments.  

   IPv4 registration is triggered for an assignment of any address block 
equal to or greater than a /29 (i.e., eight IPv4 addresses).

   In the case of IPv6, registration occurs for an assignment of any block 
equal to or greater than a /64, which constitutes one entire IPv6 subnet and is 
the minimum block size for an allocation.

   Accordingly, there is a significant disparity between IPv4 and IPv6 
WHOIS registration thresholds in the case of assignments, resulting in more 
work in the case of IPv6 than is the case for IPv4.

   There is no technical or policy rationale for the disparity, which could 
serve as a deterrent to more rapid IPv6 adoption.

   The purpose of this proposal is to eliminate the disparity and 
corresponding adverse consequences.

 

Policy statement:

   1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to 
strike "/64 or more addresses" and change to "

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

[hostmaster]

In the case of that 69.0.0.0 block we were talking about, it may not be on 
the other side of the earth, but certainly in different states.  That 
block had the serving site as CT, the parent record as TX, and a note in 
that record to send legal process to FL.  Quite a trip.


What is the purpose of the SWIP record, if the contact is nowhere near the 
site?


Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Mon, 24 Jul 2017, Paul McNary wrote:


Then that totally negates the reasoning for geolocation.
The administrative address could be on the other side of the earth.

Paul


On 7/24/2017 1:31 PM, Owen DeLong wrote:

On Jul 20, 2017, at 14:28 , hostmas...@uneedus.com wrote:

My transit bus example is another example of SWIP difficulty.  Very hard 
to provide a street address to SWIP a bus when it is mobile 16 hours a 
day.
Not at all. A bus would be SWIPd to the bus yard or administrative offices 
of the bus company. The SWIP data is not required to be the service 
address, it is required to be an address for administrative and/or 
technical contact regarding the network and/or legal process service 
regarding same.


[rest trimmed because we are in agreement on that part]

Owen


On Thu, 20 Jul 2017, Chris James wrote:

@Paul - The API key is to email it.

@Owen - Very difficult when you have dynamic ranges, and vps/container
platforms spanning tens of thousands of instances across these dynamic
ranges.


On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary  wrote:


Owen

The reassignment policy page says IPv6 has to be done vi API.
Is that something else that is incorrect on the web site?

Paul


On 7/20/2017 3:16 PM, Owen DeLong wrote:


How can it be overly difficult to fill out an email template with your
customers’
Name, Address, Phone Number?

Really?

Owen

On Jul 19, 2017, at 23:48 , Pallieter Koopmans 


wrote:

Hello,

ARIN could quantify and require rules for when to SWIP, but in the
end, there are going to be exceptions needed if the rules are to be
strictly followed. Many will not separately SWIP a separately routed
sub-block if it is too difficult or pointless to gather and share that
data back upstream to ARIN.

Thus a more fuzzy rule to require a best-effort and to add a
rule-based reason (preferably both a carrot and a stick) for block
owners to do their best to provide (only) useful data. In order to do
that, one needs to look back at why that data is needed. For a block
owner to assign the SWIP on a sub-block, he basically delegates tech
and abuse contact requests down to those that are probably more likely
to be able to actually act on the tech/abuse requests (and thus reduce
request-handling workload higher up and overall). But for that to
work, those tech/abuse contact requests need to be actually handled,
otherwise, it is better to leave them with the block owner.

In the end, the contact details should be as close to the "person"
that is actually capable to both handle (think: volume/languages/etc)
and act (think: authority) on the tech/abuse requests.

eBrain
Innovative Internet Ideas

Pallieter Koopmans
Managing Director

+31-6-3400-3800 (mon-sat 9-22 CET)
Skype: PallieterKoopmans
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

--
This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended 
recipient(s).

Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. This company is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are 
solely
those of the author and do 

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

[Paul McNary]

I agree with that!

Paul


On 7/24/2017 2:00 PM, Owen DeLong wrote:

The current proposal language says:

/47 or shorter are SWIP’d in all cases.
/48 or longer are SWIP’d if they are independently announced.

Owen


On Jul 24, 2017, at 11:53 , Paul McNary  wrote:

What does the new language say?
I then am totally confused as I am with the rest of the NPRM!

So many contradictions using Missouri English.

Paul


On 7/24/2017 1:22 PM, Owen DeLong wrote:

That’s not what the new language actually says.

Owen


On Jul 20, 2017, at 13:26 , Paul McNary  wrote:

Yes

/48 is the SWIP boundary. /48 is SWIP'ed.
/49 is not.

Paul


On 7/20/2017 3:07 PM, Owen DeLong wrote:

My recommendation was “shorter than /48” which would essentially mean the same 
thing.

Owen


On Jul 17, 2017, at 15:46 , hostmas...@uneedus.com wrote:

The language of "b)" actually makes more sense with a /47:

Each static IPv6 assignment containing a /47 or more addresses, or 
subdelegation of any size that will be individually announced, shall be 
registered in the WHOIS directory via SWIP or a distributed service which meets 
the standards set forth in section 3.2.

The major difference is that this language eliminates the SWIP requirement for 
/48 blocks that are not announced, but all larger blocks require SWIP, and 
blocks smaller than /48 are also exempt and of course also non-routeable.

This is best for those that think SWIP should be limited to only blocks that 
are individually announced.  I could go either way on this issue.

Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Mon, 17 Jul 2017, Leif Sawyer wrote:


Shepherd of the draft policy chiming in.

Thanks for the lively discussion, everybody.   There's certainly a lot to think 
about here.

Just as a reminder to folk, the current policy under question is located here:
https://www.arin.net/policy/nrpm.html#six551

And, to help clarify some confusion, per  6.5.5.3.1  
(https://www.arin.net/policy/nrpm.html#six5531)
residential customers "holding/64 and larger blocks"   may use censored data,  i.e.  
"Private Customer/Residence"
in lieu of actual names and street addresses.

--

With that said,  I have a couple of questions to ask, based on potential 
rewrites that are brewing.

First:Assuming a preference for /56  (based on PPML feedback)  for the 
moment,   which is the more
preferential rewrite of the opening sentence of 6.5.5.1?


a)  Each static IPv6 assignment containing a /55 or more addresses shall be 
registered in the WHOIS directory via SWIP or a distributed service which meets 
the standards set forth in section 3.2.



b)  Each static IPv6 assignment containing a /55 or more addresses, or 
subdelegation of any size that will be individually announced, shall be 
registered in the WHOIS directory via SWIP or a distributed service which meets 
the standards set forth in section 3.2.


Second:   Given your specific choice of A or B,  are you preferentially inclined to 
choose the provided bit-boundary, or "/48"

Third:  If none of these options are palatable, do you have a proposed approach?



Thanks,

Leif Sawyer
Advisory Council



___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Brian Jones]

On Mon, Jul 24, 2017 at 2:46 PM Owen DeLong  wrote:

> On Jul 24, 2017, at 04:03 , hostmas...@uneedus.com wrote:
>
> /47 or more addresses is intended to be /47, /46 . /1 and not the
> reverse.  The current language is "/64 or more", and I read that same
> phrase as /64, /63 . /1.  For comparison, the current IPv4 language is
> "/29 or more", and that seems clear to mean /29, /28 . /1, and not the
> reverse.  I do not think the "/X or more" language in the current NRPM or
> the proposal is unclear.
>
> As far as the remainder, I read this draft as two statements connected
> with an OR.  Thus there are 2 classes of assignments that are required to
> be SWIP'ed.  They are:
>
> 1) ANY IPv6 assignment containing a /47 or more addresses.
> 2) ANY sub-delegation of any size that will be individually announced.
>
> Due to rules for the GRT, this means /49 or less is not covered by 2).
> However, should the rules for the GRT ever change, 2) will cover it.  The
> intent of 2) is to require SWIP on ALL sub-delegations, without expressing
> that level, which is outside of ARIN control.
>
>
> There are no rules for the GRT. There are only each ASNs rules for what
> they will accept and announce and what ends up in any particular routing
> table is the intersection of routes accepted and routes advertised by peers.
>
> Just a quick sampling from Route-views:
>
> *  2001:218:200e:100::/56
> 2a01:73e0::1   0 47872 2914 i
> *   2001:67c:22dc:def1::1
>0 31019 41887
> 2914 i
> *   2c0f:fc00::2   0 3741 2914 i
> *   2001:d98::19   0 18106 4657
> 2914 i
> *   2001:418:0:1000::f000
>  17346  0 2914 i
> *   2a00:1728::2d:
>  0  0 34224 2914 i
> *>  2001:418:0:1000::f002
>  11266  0 2914 i
> *  2001:218:200e:200::/56
> 2a01:73e0::1   0 47872 2914 i
> *   2001:67c:22dc:def1::1
>0 31019 41887
> 2914 i
> *   2c0f:fc00::2   0 3741 2914 i
> *   2001:d98::19   0 18106 4657
> 2914 i
> *   2001:418:0:1000::f000
>  17346  0 2914 i
> *   2a00:1728::2d:
>  0  0 34224 2914 i
> *>  2001:418:0:1000::f002
>  11266  0 2914 i
> *  2001:218:200e:300::/56
> 2a01:73e0::1   0 47872 2914 i
> *   2001:67c:22dc:def1::1
>0 31019 41887
> 2914 i
> *   2c0f:fc00::2   0 3741 2914 i
> *   2001:d98::19   0 18106 4657
> 2914 i
> *   2001:418:0:1000::f000
>  17346  0 2914 i
> *   2a00:1728::2d:
>  0  0 34224 2914 i
> *>  2001:418:0:1000::f002
>  11266  0 2914 i
> *  2001:218:200e:400::/56
> 2a01:73e0::1   0 47872 2914 i
> *   2001:67c:22dc:def1::1
>0 31019 41887
> 2914 i
> *   2c0f:fc00::2   0 3741 2914 i
> *   2001:d98::19   0 18106 4657
> 2914 i
> *   2001:418:0:1000::f000
>  17346  0 2914 i
> *   2a00:1728::2d:
>  0  0 34224 2914 i
> *>  2001:418:0:1000::f002
>  11266  0 2914 i
>
> So clearly it is possible to announce  at least a /56 and even maybe a
> /126:
>
> *> 2001:218:4000:5000::338/126
> 2001:d98::19   0 18106 132602 ?
> *> 2001:218:4000:5000::368/126
> 2001:d98::19   0 18106 132602 ?
> *> 2001:218:4000:5000::42c/126
> 2001:d98::19   0 18106 132602 ?
> (though that doesn’t seem to have gotten very far)
>
> But this /64 got a bit further:
>
> *  2001:254:1:b::/64
> 2001:d98::19   0 18106 4635
> 10103 3662 3662 3662 3662 3662 3662 

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

[Paul McNary]

Then that totally negates the reasoning for geolocation.
The administrative address could be on the other side of the earth.

Paul


On 7/24/2017 1:31 PM, Owen DeLong wrote:

On Jul 20, 2017, at 14:28 , hostmas...@uneedus.com wrote:

My transit bus example is another example of SWIP difficulty.  Very hard to 
provide a street address to SWIP a bus when it is mobile 16 hours a day.

Not at all. A bus would be SWIPd to the bus yard or administrative offices of 
the bus company. The SWIP data is not required to be the service address, it is 
required to be an address for administrative and/or technical contact regarding 
the network and/or legal process service regarding same.

[rest trimmed because we are in agreement on that part]

Owen


On Thu, 20 Jul 2017, Chris James wrote:

@Paul - The API key is to email it.

@Owen - Very difficult when you have dynamic ranges, and vps/container
platforms spanning tens of thousands of instances across these dynamic
ranges.


On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary  wrote:


Owen

The reassignment policy page says IPv6 has to be done vi API.
Is that something else that is incorrect on the web site?

Paul


On 7/20/2017 3:16 PM, Owen DeLong wrote:


How can it be overly difficult to fill out an email template with your
customers’
Name, Address, Phone Number?

Really?

Owen

On Jul 19, 2017, at 23:48 , Pallieter Koopmans 

wrote:

Hello,

ARIN could quantify and require rules for when to SWIP, but in the
end, there are going to be exceptions needed if the rules are to be
strictly followed. Many will not separately SWIP a separately routed
sub-block if it is too difficult or pointless to gather and share that
data back upstream to ARIN.

Thus a more fuzzy rule to require a best-effort and to add a
rule-based reason (preferably both a carrot and a stick) for block
owners to do their best to provide (only) useful data. In order to do
that, one needs to look back at why that data is needed. For a block
owner to assign the SWIP on a sub-block, he basically delegates tech
and abuse contact requests down to those that are probably more likely
to be able to actually act on the tech/abuse requests (and thus reduce
request-handling workload higher up and overall). But for that to
work, those tech/abuse contact requests need to be actually handled,
otherwise, it is better to leave them with the block owner.

In the end, the contact details should be as close to the "person"
that is actually capable to both handle (think: volume/languages/etc)
and act (think: authority) on the tech/abuse requests.

eBrain
Innovative Internet Ideas

Pallieter Koopmans
Managing Director

+31-6-3400-3800 (mon-sat 9-22 CET)
Skype: PallieterKoopmans
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

--
This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. This company is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the company.

___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

___
PPML
You are receiving this message 

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

[Owen DeLong]

The current proposal language says:

/47 or shorter are SWIP’d in all cases.
/48 or longer are SWIP’d if they are independently announced.

Owen

> On Jul 24, 2017, at 11:53 , Paul McNary  wrote:
> 
> What does the new language say?
> I then am totally confused as I am with the rest of the NPRM!
> 
> So many contradictions using Missouri English.
> 
> Paul
> 
> 
> On 7/24/2017 1:22 PM, Owen DeLong wrote:
>> That’s not what the new language actually says.
>> 
>> Owen
>> 
>>> On Jul 20, 2017, at 13:26 , Paul McNary  wrote:
>>> 
>>> Yes
>>> 
>>> /48 is the SWIP boundary. /48 is SWIP'ed.
>>> /49 is not.
>>> 
>>> Paul
>>> 
>>> 
>>> On 7/20/2017 3:07 PM, Owen DeLong wrote:
 My recommendation was “shorter than /48” which would essentially mean the 
 same thing.
 
 Owen
 
> On Jul 17, 2017, at 15:46 , hostmas...@uneedus.com wrote:
> 
> The language of "b)" actually makes more sense with a /47:
> 
> Each static IPv6 assignment containing a /47 or more addresses, or 
> subdelegation of any size that will be individually announced, shall be 
> registered in the WHOIS directory via SWIP or a distributed service which 
> meets the standards set forth in section 3.2.
> 
> The major difference is that this language eliminates the SWIP 
> requirement for /48 blocks that are not announced, but all larger blocks 
> require SWIP, and blocks smaller than /48 are also exempt and of course 
> also non-routeable.
> 
> This is best for those that think SWIP should be limited to only blocks 
> that are individually announced.  I could go either way on this issue.
> 
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
> 
> On Mon, 17 Jul 2017, Leif Sawyer wrote:
> 
>> Shepherd of the draft policy chiming in.
>> 
>> Thanks for the lively discussion, everybody.   There's certainly a lot 
>> to think about here.
>> 
>> Just as a reminder to folk, the current policy under question is located 
>> here:
>> https://www.arin.net/policy/nrpm.html#six551
>> 
>> And, to help clarify some confusion, per  6.5.5.3.1  
>> (https://www.arin.net/policy/nrpm.html#six5531)
>> residential customers "holding/64 and larger blocks"   may use censored 
>> data,  i.e.  "Private Customer/Residence"
>> in lieu of actual names and street addresses.
>> 
>> --
>> 
>> With that said,  I have a couple of questions to ask, based on potential 
>> rewrites that are brewing.
>> 
>> First:Assuming a preference for /56  (based on PPML feedback)  for 
>> the moment,   which is the more
>> preferential rewrite of the opening sentence of 6.5.5.1?
>> 
>> 
>> a)  Each static IPv6 assignment containing a /55 or more addresses 
>> shall be registered in the WHOIS directory via SWIP or a distributed 
>> service which meets the standards set forth in section 3.2.
>> 
>> 
>> 
>> b)  Each static IPv6 assignment containing a /55 or more addresses, 
>> or subdelegation of any size that will be individually announced, shall 
>> be registered in the WHOIS directory via SWIP or a distributed service 
>> which meets the standards set forth in section 3.2.
>> 
>> 
>> Second:   Given your specific choice of A or B,  are you preferentially 
>> inclined to choose the provided bit-boundary, or "/48"
>> 
>> Third:  If none of these options are palatable, do you have a proposed 
>> approach?
>> 
>> 
>> 
>> Thanks,
>> 
>> Leif Sawyer
>> Advisory Council
>> 
>> 
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
 Unsubscribe or manage your mailing list subscription at:
 http://lists.arin.net/mailman/listinfo/arin-ppml
 Please contact i...@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@arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact i...@arin.net if you experience any issues.
>> 
>> 
> 
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public 

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

[Paul McNary]

https://www.arin.net/resources/request/reassignments.html



On 7/24/2017 1:28 PM, Owen DeLong wrote:


On Jul 20, 2017, at 13:51 , Paul McNary > wrote:


Owen

The reassignment policy page says IPv6 has to be done vi API.
Is that something else that is incorrect on the web site?

Paul


I’m not sure what the “reassignment policy page” you refer to is, but 
here’s the quote from the NRPM:


6.5.5. Registration

ISPs are required to demonstrate efficient use of IP address space
allocations by providing appropriate documentation, including but
not limited to assignment histories, showing their efficient use.

6.5.5.1. Reassignment information
Each static IPv6 assignment containing a /64 or more addresses
shall be registered in the WHOIS directory via SWIP or a
distributed service which meets the standards set forth in section
3.2. Reassignment registrations shall include each client's
organizational information, except where specifically exempted by
this policy.

6.5.5.2. Assignments visible within 7 days
All assignments shall be made visible as required in section
4.2.3.7.1 within seven calendar days of assignment.

6.5.5.3. Residential Subscribers
6.5.5.3.1. Residential Customer Privacy
To maintain the privacy of their residential customers, an
organization with downstream residential customers holding /64 and
larger blocks may substitute that organization's name for
the customer's name, e.g. 'Private Customer - XYZ Network', and
the customer's street address may read 'Private Residence'. Each
private downstream residential reassignment must have
accurate upstream Abuse and Technical POCs visible on the WHOIS
record for that block.

I’ll call your attention to the phrase in 6.5.5.1 which states 
"registered in the WHOIS directory via SWIP or a distributed service 
which meets the standards set forth in section 3.2” which at this 
point includes (IIRC) SWIP, RestFUL API, RWHOIS, and possibly RDAP.



I’ll also note that 6.5.5.3.1 provides for the residential customer 
privacy as I defined it, regardless of the mechanism used to make the 
data available.


Given that, can you clarify your above statement?

Owen




On 7/20/2017 3:16 PM, Owen DeLong wrote:
How can it be overly difficult to fill out an email template with 
your customers’

Name, Address, Phone Number?

Really?

Owen

On Jul 19, 2017, at 23:48 , Pallieter Koopmans 
> wrote:


Hello,

ARIN could quantify and require rules for when to SWIP, but in the
end, there are going to be exceptions needed if the rules are to be
strictly followed. Many will not separately SWIP a separately routed
sub-block if it is too difficult or pointless to gather and share that
data back upstream to ARIN.

Thus a more fuzzy rule to require a best-effort and to add a
rule-based reason (preferably both a carrot and a stick) for block
owners to do their best to provide (only) useful data. In order to do
that, one needs to look back at why that data is needed. For a block
owner to assign the SWIP on a sub-block, he basically delegates tech
and abuse contact requests down to those that are probably more likely
to be able to actually act on the tech/abuse requests (and thus reduce
request-handling workload higher up and overall). But for that to
work, those tech/abuse contact requests need to be actually handled,
otherwise, it is better to leave them with the block owner.

In the end, the contact details should be as close to the "person"
that is actually capable to both handle (think: volume/languages/etc)
and act (think: authority) on the tech/abuse requests.

eBrain
Innovative Internet Ideas

Pallieter Koopmans
Managing Director

+31-6-3400-3800 (mon-sat 9-22 CET)
Skype: PallieterKoopmans
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net 
).

Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net 
).

Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net 
).

Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Owen DeLong]

> On Jul 21, 2017, at 00:09 , the...@uneedus.com wrote:
> 
> As for discussion of SWIP for /48's, some have suggested since these are the 
> recommended minimum assignment for an end site, /48 should not trigger SWIP 
> unless independently routed.  Others believe all /48's be SWIP'ed. Thus the 
> two main ideas for this proposal currently are:
> 
> 1) SWIP all independently routed (in the GRT) networks regardless of size but 
> in actual fact they must be at least a /48 to be in the GRT, and all other 
> assignments greater than a /48.  This is the "b)" language using /47 from the 
> other day.

As I demonstrated in my previous post, the GRT is not entirely as restrictive 
as stated, so I would say that your option 1 would be better (and more 
accurately) restated as:

1) SWIP all independently announced networks regardless of size and all 
assignments shorter than /48 (i.e. /0../47).

This is the option which I currently support.

> 2) SWIP every /48 regardless of routing, smaller are exempt.  This is the 
> "/48 or more" language. Since the standard site size is /48, this catches a 
> lot of small sites that are not independently routed but avoids setting the 
> policy based on routing.  If this is chosen many ISP's are likely to choose 
> giving out /52 or less instead of /48's.  As pointed out by others, a major 
> cable ISP in the US already gives out only a /60 with their prefix delegation 
> server.  Although like the mobile networks, they do have a current valid 
> argument against SWIP, since these are not "static”.

So far, I saw opposition to 1) favoring 2) only from Bill Herrin and generally 
good support for 1) otherwise. However, I admit this is not the result of a 
careful or detailed review of every message specifically for this 
determination, so I may have missed something along the way.

> Now that we want to change the bus administrative network to v6 for lack of 
> v4 static assignments from the contract wireless provider, we run into the 
> ARIN 100% SWIP registration requirement of /64 or more in NRPM 6.5.5.1. as v6 
> does not use NAT.  The policy of /64 or more is what I seek to change, to 
> allow smaller v6 networks, like these busses to avoid a SWIP requirement.  
> Switching the same size network with the same number of hosts from v4 to v6 
> should not change the SWIP requirement, but current policy does. This is 
> where the debate is, where to draw that line.

The reality is that the over-arching /48 containing all of the bus /64s could 
be SWIPd as a single block to the bus company and would be a completely 
legitimate solution to this issue. I suspect that the IPv4 aggregate containing 
the static IPv4 addresses for all the busses was also SWIPd previously (or at 
least should have been under policy). As such,
I’m not sure this is the ideal example for your argument.

> The thing to remember is that currently a /48, according to the 2.15 of the 
> NRPM is the recommended value for every end site, residential or commercial.  
> Current ARIN policy would allow the transit agency to receive a /36 and 
> assign each bus a /48. I have suggested they instead obtain a single end user 
> /48 from either ARIN or a /48 assignment from a /32 block already controlled 
> by state government for their bus use to avoid renumbering during contract 
> provider changes, and use a /60 on each bus. Either saves money over getting 
> a /36 from ARIN.

Yes, but the bus isn’t necessarily technically considered a separate end site 
(or at least not necessarily one that has to be SWIPd). For example, a major 
corporation that is numbering a variety of end-sites on multiple corporate 
campuses around the world can qualify for nx/48 as an aggregate, let’s say /40 
for convenience here. (some value >128 and less than 256 end sites). Said 
corporation would not need to SWIP each and every campus. The corporation is 
not considered an LIR, but an end-user (unless they choose to be an LIR for 
reasons of their own) and as such could register the entire /40 as a single 
block to Corporate HQ without issue and without being required to make any more 
specific SWIPs. Similarly, the bus company could register their aggregate IPv6 
address block (/48, /36, /32, or whatever) to an appropriate headquarters 
address and be done. There is no need to register the assignments to the 
individual busses.

In fact, if the busses become independently routed, this policy proposal would, 
in fact, increase the registration requirement from what it is today rather 
than decrease it.

> As far as public disclosure of CPNI, the size of an organization does not 
> matter.  In the example discussed here of that 69.0.0.0/29 block we have been 
> talking of, unless AT has written permission from that customer, they have 
> committed a CPNI violation by simply publishing the name and address of that 
> customer in SWIP, and AT could in theory be fined for that disclosure, even 
> though ARIN policy requires the information 

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

[Paul McNary]

What does the new language say?
I then am totally confused as I am with the rest of the NPRM!

So many contradictions using Missouri English.

Paul


On 7/24/2017 1:22 PM, Owen DeLong wrote:

That’s not what the new language actually says.

Owen


On Jul 20, 2017, at 13:26 , Paul McNary  wrote:

Yes

/48 is the SWIP boundary. /48 is SWIP'ed.
/49 is not.

Paul


On 7/20/2017 3:07 PM, Owen DeLong wrote:

My recommendation was “shorter than /48” which would essentially mean the same 
thing.

Owen


On Jul 17, 2017, at 15:46 , hostmas...@uneedus.com wrote:

The language of "b)" actually makes more sense with a /47:

Each static IPv6 assignment containing a /47 or more addresses, or 
subdelegation of any size that will be individually announced, shall be 
registered in the WHOIS directory via SWIP or a distributed service which meets 
the standards set forth in section 3.2.

The major difference is that this language eliminates the SWIP requirement for 
/48 blocks that are not announced, but all larger blocks require SWIP, and 
blocks smaller than /48 are also exempt and of course also non-routeable.

This is best for those that think SWIP should be limited to only blocks that 
are individually announced.  I could go either way on this issue.

Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Mon, 17 Jul 2017, Leif Sawyer wrote:


Shepherd of the draft policy chiming in.

Thanks for the lively discussion, everybody.   There's certainly a lot to think 
about here.

Just as a reminder to folk, the current policy under question is located here:
https://www.arin.net/policy/nrpm.html#six551

And, to help clarify some confusion, per  6.5.5.3.1  
(https://www.arin.net/policy/nrpm.html#six5531)
residential customers "holding/64 and larger blocks"   may use censored data,  i.e.  
"Private Customer/Residence"
in lieu of actual names and street addresses.

--

With that said,  I have a couple of questions to ask, based on potential 
rewrites that are brewing.

First:Assuming a preference for /56  (based on PPML feedback)  for the 
moment,   which is the more
preferential rewrite of the opening sentence of 6.5.5.1?


a)  Each static IPv6 assignment containing a /55 or more addresses shall be 
registered in the WHOIS directory via SWIP or a distributed service which meets 
the standards set forth in section 3.2.



b)  Each static IPv6 assignment containing a /55 or more addresses, or 
subdelegation of any size that will be individually announced, shall be 
registered in the WHOIS directory via SWIP or a distributed service which meets 
the standards set forth in section 3.2.


Second:   Given your specific choice of A or B,  are you preferentially inclined to 
choose the provided bit-boundary, or "/48"

Third:  If none of these options are palatable, do you have a proposed approach?



Thanks,

Leif Sawyer
Advisory Council



___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Owen DeLong]

> On Jul 24, 2017, at 04:03 , hostmas...@uneedus.com wrote:
> 
> /47 or more addresses is intended to be /47, /46 . /1 and not the 
> reverse.  The current language is "/64 or more", and I read that same phrase 
> as /64, /63 . /1.  For comparison, the current IPv4 language is "/29 or 
> more", and that seems clear to mean /29, /28 . /1, and not the reverse.  
> I do not think the "/X or more" language in the current NRPM or the proposal 
> is unclear.
> 
> As far as the remainder, I read this draft as two statements connected with 
> an OR.  Thus there are 2 classes of assignments that are required to be 
> SWIP'ed.  They are:
> 
> 1) ANY IPv6 assignment containing a /47 or more addresses.
> 2) ANY sub-delegation of any size that will be individually announced.
> 
> Due to rules for the GRT, this means /49 or less is not covered by 2). 
> However, should the rules for the GRT ever change, 2) will cover it.  The 
> intent of 2) is to require SWIP on ALL sub-delegations, without expressing 
> that level, which is outside of ARIN control.

There are no rules for the GRT. There are only each ASNs rules for what they 
will accept and announce and what ends up in any particular routing table is 
the intersection of routes accepted and routes advertised by peers.

Just a quick sampling from Route-views:

*  2001:218:200e:100::/56
2a01:73e0::1   0 47872 2914 i
*   2001:67c:22dc:def1::1
   0 31019 41887 2914 i
*   2c0f:fc00::2   0 3741 2914 i
*   2001:d98::19   0 18106 4657 2914 i
*   2001:418:0:1000::f000
 17346  0 2914 i
*   2a00:1728::2d:
 0  0 34224 2914 i
*>  2001:418:0:1000::f002
 11266  0 2914 i
*  2001:218:200e:200::/56
2a01:73e0::1   0 47872 2914 i
*   2001:67c:22dc:def1::1
   0 31019 41887 2914 i
*   2c0f:fc00::2   0 3741 2914 i
*   2001:d98::19   0 18106 4657 2914 i
*   2001:418:0:1000::f000
 17346  0 2914 i
*   2a00:1728::2d:
 0  0 34224 2914 i
*>  2001:418:0:1000::f002
 11266  0 2914 i
*  2001:218:200e:300::/56
2a01:73e0::1   0 47872 2914 i
*   2001:67c:22dc:def1::1
   0 31019 41887 2914 i
*   2c0f:fc00::2   0 3741 2914 i
*   2001:d98::19   0 18106 4657 2914 i
*   2001:418:0:1000::f000
 17346  0 2914 i
*   2a00:1728::2d:
 0  0 34224 2914 i
*>  2001:418:0:1000::f002
 11266  0 2914 i
*  2001:218:200e:400::/56
2a01:73e0::1   0 47872 2914 i
*   2001:67c:22dc:def1::1
   0 31019 41887 2914 i
*   2c0f:fc00::2   0 3741 2914 i
*   2001:d98::19   0 18106 4657 2914 i
*   2001:418:0:1000::f000
 17346  0 2914 i
*   2a00:1728::2d:
 0  0 34224 2914 i
*>  2001:418:0:1000::f002
 11266  0 2914 i

So clearly it is possible to announce  at least a /56 and even maybe a /126:

*> 2001:218:4000:5000::338/126
2001:d98::19   0 18106 132602 ?
*> 2001:218:4000:5000::368/126
2001:d98::19   0 18106 132602 ?
*> 2001:218:4000:5000::42c/126
2001:d98::19   0 18106 132602 ?
(though that doesn’t seem to have gotten very far)

But this /64 got a bit further:

*  2001:254:1:b::/64
2001:d98::19   0 18106 4635 10103 
3662 3662 3662 3662 3662 3662 3662 ?
*   2402:c100::104 0 23673 4635 10103 
3662 3662 3662 3662 3662 3662 3662 ?
*>  2404:cc00:1::1 0 24441 4635 10103 
3662 

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

[Owen DeLong]

> On Jul 20, 2017, at 14:28 , hostmas...@uneedus.com wrote:
> 
> My transit bus example is another example of SWIP difficulty.  Very hard to 
> provide a street address to SWIP a bus when it is mobile 16 hours a day.

Not at all. A bus would be SWIPd to the bus yard or administrative offices of 
the bus company. The SWIP data is not required to be the service address, it is 
required to be an address for administrative and/or technical contact regarding 
the network and/or legal process service regarding same.

[rest trimmed because we are in agreement on that part]

Owen

> On Thu, 20 Jul 2017, Chris James wrote:

> 
>> @Paul - The API key is to email it.
>> 
>> @Owen - Very difficult when you have dynamic ranges, and vps/container
>> platforms spanning tens of thousands of instances across these dynamic
>> ranges.
>> 
>> 
>> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary  wrote:
>> 
>>> Owen
>>> 
>>> The reassignment policy page says IPv6 has to be done vi API.
>>> Is that something else that is incorrect on the web site?
>>> 
>>> Paul
>>> 
>>> 
>>> On 7/20/2017 3:16 PM, Owen DeLong wrote:
>>> 
 How can it be overly difficult to fill out an email template with your
 customers’
 Name, Address, Phone Number?
 
 Really?
 
 Owen
 
 On Jul 19, 2017, at 23:48 , Pallieter Koopmans 
> wrote:
> 
> Hello,
> 
> ARIN could quantify and require rules for when to SWIP, but in the
> end, there are going to be exceptions needed if the rules are to be
> strictly followed. Many will not separately SWIP a separately routed
> sub-block if it is too difficult or pointless to gather and share that
> data back upstream to ARIN.
> 
> Thus a more fuzzy rule to require a best-effort and to add a
> rule-based reason (preferably both a carrot and a stick) for block
> owners to do their best to provide (only) useful data. In order to do
> that, one needs to look back at why that data is needed. For a block
> owner to assign the SWIP on a sub-block, he basically delegates tech
> and abuse contact requests down to those that are probably more likely
> to be able to actually act on the tech/abuse requests (and thus reduce
> request-handling workload higher up and overall). But for that to
> work, those tech/abuse contact requests need to be actually handled,
> otherwise, it is better to leave them with the block owner.
> 
> In the end, the contact details should be as close to the "person"
> that is actually capable to both handle (think: volume/languages/etc)
> and act (think: authority) on the tech/abuse requests.
> 
> eBrain
> Innovative Internet Ideas
> 
> Pallieter Koopmans
> Managing Director
> 
> +31-6-3400-3800 (mon-sat 9-22 CET)
> Skype: PallieterKoopmans
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
 Unsubscribe or manage your mailing list subscription at:
 http://lists.arin.net/mailman/listinfo/arin-ppml
 Please contact i...@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@arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact i...@arin.net if you experience any issues.
>> 
>> -- 
>> This e-mail message may contain confidential or legally privileged
>> information and is intended only for the use of the intended recipient(s).
>> Any unauthorized disclosure, dissemination, distribution, copying or the
>> taking of any action in reliance on the information herein is prohibited.
>> E-mails are not secure and cannot be guaranteed to be error free as they
>> can be intercepted, amended, or contain viruses. Anyone who communicates
>> with us by e-mail is deemed to have accepted these risks. This company is
>> not responsible for errors or omissions in this message and denies any
>> responsibility for any damage arising from the use of e-mail. Any opinion
>> and other statement contained in this message and any attachment are solely
>> those of the author and do not necessarily represent those of the company.
> ___
> PPML
> You are receiving this message because you are subscribed to

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

[Owen DeLong]

Dynamic assignments are not required to be registered… STATIC assignments are 
required to be registered, so that argument doesn’t work.

Owen

> On Jul 20, 2017, at 13:54 , Chris James  wrote:
> 
> @Paul - The API key is to email it.
> 
> @Owen - Very difficult when you have dynamic ranges, and vps/container 
> platforms spanning tens of thousands of instances across these dynamic ranges.
> 
> 
> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary  > wrote:
> Owen
> 
> The reassignment policy page says IPv6 has to be done vi API.
> Is that something else that is incorrect on the web site?
> 
> Paul
> 
> 
> On 7/20/2017 3:16 PM, Owen DeLong wrote:
> How can it be overly difficult to fill out an email template with your 
> customers’
> Name, Address, Phone Number?
> 
> Really?
> 
> Owen
> 
> On Jul 19, 2017, at 23:48 , Pallieter Koopmans  > wrote:
> 
> Hello,
> 
> ARIN could quantify and require rules for when to SWIP, but in the
> end, there are going to be exceptions needed if the rules are to be
> strictly followed. Many will not separately SWIP a separately routed
> sub-block if it is too difficult or pointless to gather and share that
> data back upstream to ARIN.
> 
> Thus a more fuzzy rule to require a best-effort and to add a
> rule-based reason (preferably both a carrot and a stick) for block
> owners to do their best to provide (only) useful data. In order to do
> that, one needs to look back at why that data is needed. For a block
> owner to assign the SWIP on a sub-block, he basically delegates tech
> and abuse contact requests down to those that are probably more likely
> to be able to actually act on the tech/abuse requests (and thus reduce
> request-handling workload higher up and overall). But for that to
> work, those tech/abuse contact requests need to be actually handled,
> otherwise, it is better to leave them with the block owner.
> 
> In the end, the contact details should be as close to the "person"
> that is actually capable to both handle (think: volume/languages/etc)
> and act (think: authority) on the tech/abuse requests.
> 
> eBrain
> Innovative Internet Ideas
> 
> Pallieter Koopmans
> Managing Director
> 
> +31-6-3400-3800  (mon-sat 9-22 CET)
> Skype: PallieterKoopmans
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net 
> ).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml 
> 
> Please contact i...@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@arin.net 
> ).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml 
> 
> Please contact i...@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@arin.net 
> ).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml 
> 
> Please contact i...@arin.net  if you experience any 
> issues.
> 
> 
> This e-mail message may contain confidential or legally privileged 
> information and is intended only for the use of the intended recipient(s). 
> Any unauthorized disclosure, dissemination, distribution, copying or the 
> taking of any action in reliance on the information herein is prohibited. 
> E-mails are not secure and cannot be guaranteed to be error free as they can 
> be intercepted, amended, or contain viruses. Anyone who communicates with us 
> by e-mail is deemed to have accepted these risks. This company is not 
> responsible for errors or omissions in this message and denies any 
> responsibility for any damage arising from the use of e-mail. Any opinion and 
> other statement contained in this message and any attachment are solely those 
> of the author and do not necessarily represent those of the 
> company.___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.

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

[Owen DeLong]

That’s not what the new language actually says.

Owen

> On Jul 20, 2017, at 13:26 , Paul McNary  wrote:
> 
> Yes
> 
> /48 is the SWIP boundary. /48 is SWIP'ed.
> /49 is not.
> 
> Paul
> 
> 
> On 7/20/2017 3:07 PM, Owen DeLong wrote:
>> My recommendation was “shorter than /48” which would essentially mean the 
>> same thing.
>> 
>> Owen
>> 
>>> On Jul 17, 2017, at 15:46 , hostmas...@uneedus.com wrote:
>>> 
>>> The language of "b)" actually makes more sense with a /47:
>>> 
>>> Each static IPv6 assignment containing a /47 or more addresses, or 
>>> subdelegation of any size that will be individually announced, shall be 
>>> registered in the WHOIS directory via SWIP or a distributed service which 
>>> meets the standards set forth in section 3.2.
>>> 
>>> The major difference is that this language eliminates the SWIP requirement 
>>> for /48 blocks that are not announced, but all larger blocks require SWIP, 
>>> and blocks smaller than /48 are also exempt and of course also 
>>> non-routeable.
>>> 
>>> This is best for those that think SWIP should be limited to only blocks 
>>> that are individually announced.  I could go either way on this issue.
>>> 
>>> Albert Erdmann
>>> Network Administrator
>>> Paradise On Line Inc.
>>> 
>>> On Mon, 17 Jul 2017, Leif Sawyer wrote:
>>> 
 Shepherd of the draft policy chiming in.
 
 Thanks for the lively discussion, everybody.   There's certainly a lot to 
 think about here.
 
 Just as a reminder to folk, the current policy under question is located 
 here:
 https://www.arin.net/policy/nrpm.html#six551
 
 And, to help clarify some confusion, per  6.5.5.3.1  
 (https://www.arin.net/policy/nrpm.html#six5531)
 residential customers "holding/64 and larger blocks"   may use censored 
 data,  i.e.  "Private Customer/Residence"
 in lieu of actual names and street addresses.
 
 --
 
 With that said,  I have a couple of questions to ask, based on potential 
 rewrites that are brewing.
 
 First:Assuming a preference for /56  (based on PPML feedback)  for the 
 moment,   which is the more
 preferential rewrite of the opening sentence of 6.5.5.1?
 
 
 a)  Each static IPv6 assignment containing a /55 or more addresses 
 shall be registered in the WHOIS directory via SWIP or a distributed 
 service which meets the standards set forth in section 3.2.
 
 
 
 b)  Each static IPv6 assignment containing a /55 or more addresses, or 
 subdelegation of any size that will be individually announced, shall be 
 registered in the WHOIS directory via SWIP or a distributed service which 
 meets the standards set forth in section 3.2.
 
 
 Second:   Given your specific choice of A or B,  are you preferentially 
 inclined to choose the provided bit-boundary, or "/48"
 
 Third:  If none of these options are palatable, do you have a proposed 
 approach?
 
 
 
 Thanks,
 
 Leif Sawyer
 Advisory Council
 
 
>>> ___
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact i...@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@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact i...@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@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[theone]

As for discussion of SWIP for /48's, some have suggested since these are 
the recommended minimum assignment for an end site, /48 should not trigger 
SWIP unless independently routed.  Others believe all /48's be SWIP'ed. 
Thus the two main ideas for this proposal currently are:


1) SWIP all independently routed (in the GRT) networks regardless of size 
but in actual fact they must be at least a /48 to be in the GRT, and all 
other assignments greater than a /48.  This is the "b)" language using /47 
from the other day.


2) SWIP every /48 regardless of routing, smaller are exempt.  This is the 
"/48 or more" language. Since the standard site size is /48, this catches 
a lot of small sites that are not independently routed but avoids setting 
the policy based on routing.  If this is chosen many ISP's are likely to 
choose giving out /52 or less instead of /48's.  As pointed out by others, 
a major cable ISP in the US already gives out only a /60 with their prefix 
delegation server.  Although like the mobile networks, they do have a 
current valid argument against SWIP, since these are not "static".


We are in agreement that anything smaller than /48 including /56 should 
not require SWIP. I would be happy with either result, but am biased 
toward not requiring SWIP for /48 blocks not independently routed.


The inequality between v4 and v6 is why I drafted this proposal.  The bus 
network I speak of operates today using a single static v4 address per 
bus. The wireless provider will no longer provide static v4 after the 
contract ends next year. There are currently two RFC1918 v4 subnets on 
each bus, one for administrative, and one for wifi. and each device on the 
bus is accessable from headquarters via forwarded ports from the bus 
router's static v4. There has never been a SWIP requirement for having a 
single static v4 address.


Now that we want to change the bus administrative network to v6 for lack 
of v4 static assignments from the contract wireless provider, we run into 
the ARIN 100% SWIP registration requirement of /64 or more in NRPM 
6.5.5.1. as v6 does not use NAT.  The policy of /64 or more is what I seek 
to change, to allow smaller v6 networks, like these busses to avoid a SWIP 
requirement.  Switching the same size network with the same number of 
hosts from v4 to v6 should not change the SWIP requirement, but current 
policy does. This is where the debate is, where to draw that line.


The thing to remember is that currently a /48, according to the 2.15 of 
the NRPM is the recommended value for every end site, residential or 
commercial.  Current ARIN policy would allow the transit agency to receive 
a /36 and assign each bus a /48. I have suggested they instead obtain a 
single end user /48 from either ARIN or a /48 assignment from a /32 block 
already controlled by state government for their bus use to avoid 
renumbering during contract provider changes, and use a /60 on each bus. 
Either saves money over getting a /36 from ARIN.


As far as public disclosure of CPNI, the size of an organization does not 
matter.  In the example discussed here of that 69.0.0.0/29 block we have 
been talking of, unless AT has written permission from that customer, 
they have committed a CPNI violation by simply publishing the name and 
address of that customer in SWIP, and AT could in theory be fined for 
that disclosure, even though ARIN policy requires the information be 
disclosed in SWIP. If the FCC in fact takes action is a different story. 
The usefulness of this SWIP record is also in doubt, as staff at that 
location, even if contacted might be unable to deal with an "owned" box.
It is better to have tech records with the contact info of actual 
technicians.


Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Thu, 20 Jul 2017, Chris James wrote:


Well I think in the bus example you would swip to the overall authority.
But seriously this conversation has gone in so many different directions do
any of us remember the original point?

My vote as it applies to v6: Non-residential allocations of greater than or
equal to a /48.

If you as an ISP choose to allocate a /48 to a residential customer - then
have fun. But this does not affect the purpose of the policy as most use it
these days which is abuse management. Also as I understand it, there is an
exception to the CPNI as it applies to business customers as long as they
have an account manager and adequate language in the contract. How many of
the smaller ISPs have a customer deserving of a /48 or better that does not
have a larger account or spend? If a customer requests a large enough block
from us, regardless of v4 vs v6, they agree via email/ticketing/contract
that their business information will be made public. This is not difficult
to put in your signed agreements with your business customers thus making
the CPNI argument invalid.

-Chris



On Thu, Jul 20, 2017 at 2:28 PM,  wrote:


My transit bus 

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

[John Springer]

"As far as John's comment, this proposal began with a suggestion that
changed the v4 requirement as well, making both "more than 16" networks or
IPv4 addresses.  Since changing the v4 language from 8 addresses to more
than 16 addresses was clearly not desired by the community, the v4 language
was removed from the draft.  The comments still reflect that the equality
of the policy between v4 and v6 was the original idea.  You are correct
that this draft now is only about changing the v6 part.  Are you suggesting
that the older portions of description that are no longer in it, due to the
community input needs to be removed?"

Needs? No. The older parts of the problem statement referencing V4 and
disparity are, in my view, vestigial and irrelevant at best, but do not
actively disqualify the Draft Proposal from being technically sound and
enabling fair and impartial number policy. It may be felt that the older
parts need to remain to somehow entice further community support. I don't
think that is optimum, but whatever.

At this point, I think it would be cleaner to modify the Problem Statement
and Author Comments to reflect only the current Policy statement intent,
but that is not my decision. I am still, somewhat reluctantly, in support.

John Springer
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[John Springer]

Thanks, Scott,

Are we energetically agreeing? You scared me there for a second. /48s are
excluded, unless they are part of a "subdelegation of any size that will be
individually announced". Yes.

How is that defined by the way? Will be individually announced in 2 years,
2 days, right now?

On another matter, this problem statement has been making me uneasy all
along, but because it was only required to be clear and in scope to be
accepted as Draft Policy, it was not appropriate for me to object. This
seems like as good a time as any to address some concerns, which are my
opinions only.

"Current ARIN policy has different WHOIS directory registration
requirements for IPv4 vs IPv6 address assignments."

This is a correct statement! It is not a problem however, nor is it
sufficient motive for trying to solve a problem, per se.

"IPv4 registration is triggered for an assignment of any address block
equal to or greater than a /29 (i.e., eight IPv4 addresses).
 In the case of IPv6, registration occurs for an assignment of any block
equal to or greater than a /64,"

Two facts. The second is undoubtedly a great pity, but to entangle these
logically is a fallacy of inconsistency, specifically a false equivalence.
These two facts are unrelated. It does not help the case to try to make
them interdependent. And it is not needed. All that is being attempted is
to modify V6 SWIP requirements. Do that. And DO NOT settle on 8 subnets.

"which constitutes one entire IPv6 subnet and is the minimum block size for
an allocation."

I think I'm looking at current text. How did this make it this far? One
ENTIRE IPV6 subnet? There are lots of entire V6 subnets all the way from /0
to /128. What does that have to do with anything? And, yeah, the SWIP
boundary being the so called "minimum" allocation seems broken, but that is
its own thing.

"There is no technical or policy rationale for the disparity, which could
serve as a deterrent to more rapid IPv6 adoption."

Possibly true, but irrelevant. There is no technical or policy rationale
for them being alike either, nor is there any reason to suppose that if
they were, folks would adopt V6 faster. SWIPing /64 is definitely wrong for
V6. Concentrate on that. We can make policy for V6 without needing to refer
to V4.

"The purpose of this proposal is to eliminate the disparity and
corresponding adverse consequences."

With respect, it is not. The disparity does not qualify as a logical
motive. The brokenness of SWIPing /64s does not require injustice and if
/64 SWIPing is a deterrent to V6 adoption, that is its own good and
sufficient reason. If you had to refer to an analogy, you could say,
"SWIPing /64s is analogous to SWIPing /32s and that seems dumb".

So all you need is:

Problem Statement: SWIPing IPV6 /64s is the problem. The purpose of this
proposal is to pick a different number.

Policy statement:
   1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to
strike "/64 or more addresses" and change to "/47 or more addresses, or
subdelegation of any size that will be individually announced,"
and
   2) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the
NRPM by deleting the phrase "holding /64 and larger blocks"

BUT. These observations do not appear to have any effect one way or the
other on the policy text. To me, picking a different number does not have
anything to do with disparity, but so what? Changing the IPV6 SWIP
threshold is not unfair and partial if someone makes unfounded assertions
regarding linkages between v4 and V6. And it is not technically unsound to
make fallacious observations if they are kind of orthogonal to the meat of
the matter.

So, still support. I'd rather see it simpler, but  I guess I can tolerate a
little hand waving.

Writing solely on my own behalf,

John Springer

On Fri, Jul 21, 2017 at 9:15 PM, Scott Leibrand 
wrote:

> On Jul 21, 2017, at 8:31 PM, John Springer <3jo...@gmail.com> wrote:
>
> I support this Draft Policy as re-written.
>
> I shared the author's distaste for the requirement that IPV6 /64s be
> SWIP'd, but was not reassured when the discussion veered to consider
> prefixes between /48 and /64. AFAIK, ISPs have long been encouraged to
> apply for their allocations based on the idea of assigning a /48 to each
> 'customer' to provide room for unknown technologies, among other things. I
> did not wish to endanger that premise, but current language appears to moot
> that concern.
>
> To be explicit, to me, "/47 or more addresses, or sub-delegation of any
> size that will be individually announced," refers to /47s, /46s, /45s ...
> and not /48s, /49s, /50s, etc.
>
>
> That's not what it says. It says /48s (or longer) should be individually
> SWIPped if they're going to be announced. Otherwise there's no reason for
> the extra clause.
>
> Blocks in the GRT need to be SWIPped to the announcing party if that's a
> different organization from the holder of the larger block.
>
> -Scott
>

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

[David Farmer]

On Sun, Jul 23, 2017 at 1:23 PM,  wrote:

> Boy, am I learning from this process.  Please let me know if I am not
> defining these terms we are discussing below properly:
>

Not quite:  see NRPM section 2.5;

2.5. Allocate and Assign

A distinction is made between address allocation and address assignment,
i.e., ISPs are "allocated" address space as described herein, while
end-users are "assigned" address space.

Allocate - To allocate means to distribute address space to IRs for the
purpose of subsequent distribution by them.

Assign - To assign means to delegate address space to an ISP or end-user,
for specific use within the Internet infrastructure they operate.
Assignments must only be made for specific purposes documented by specific
organizations and are not to be sub-assigned to other parties.

And re-[allocate or assign] means an ISP is doing it not ARIN.


Ok, now that I have the terms out of the way, lets talk.
>
> There seems to be a current disconnect identified in the policy between
> Re-allocation and assignment because the term "Reassignment" in 6.5.5 is
> not defined.
>
> Many have identified that the minimum unit of assignment should be a /48
> and ARIN policy should not change this fact by putting policies in place
> that would make it more likely that assignments of less than /48 will be
> made by ISPs/LIRs.  Therefore I propose the following amendments to the
> draft to address the issues that have been identified:
>
> Add new section 2.17 as follows:
>
> 2.17 Reassignment
>
> The term shall mean all cases where an Internet Registry, as defined in
> section 2.1 assigns or Re-allocates a portion of the addresses received
> from ARIN or another Internet Registry, for the use by end users or another
> Internet Registry.  This term shall include within it the terms assignment
> and Re-allocation.
>

I might suggest this get added to section 2.5 or at least you reference the
definitions in that section.

I'll digest the rest of this later;

Amend 6.5.5.1 as follows:
>
> Change "Each static IPv6 assignment" to "Each static IPv6 reassignment".
>
> Change the word "sub-delegation" to "reassignment".
>
>
> Now some examples of how this draft policy will work with different size
> IPv6 blocks with the current global routing rules:
>
> For sites with exactly /48, there will be two classes of sites:
>
> 1) Those sites with a /48 assigned to them, and using the same routing as
> the parent block (Allocation or Re-allocation) above them.
>
> 2) Those sites with a /48 assigned to them, where the entity with the /48
> has made arrangements to have their /48 assignment routed differently than
> the parent block (Allocation or Re-allocation) above them.
>
> It is the intent of the language proposed to require 2) above to be
> registered in SWIP (since they have different routing), and to exempt 1)
> above from the SWIP requirement, as they are using the standard routing of
> their parent block, and for the most part will be normal sites that use
> just a single IPv4 address which no SWIP requirement exists, and a single
> /48 assigned to them for their site which has been identified as the best
> practice for all sites.
>
> I think this is the confusing part of the language, since a /48 can go
> either way, SWIP or no SWIP depending on independent routing, while
> anything larger is ALWAYS SWIP'ed and and everything smaller would under
> current best practices would never require SWIP.
>
> Under the draft, For any reassignment with a /47 or More of addresses, ALL
> will require SWIP.  This should cover ALL Re-allocation cases, as the
> reallocated block received must for technical reasons be large enough for
> the reallocator to have 1 or more /48's to assign to the customers below
> them.
>
> Under the draft, For any site of any size, if the GRT policy is ever
> changed from a /48, all such sites smaller than the new limit that has
> independent routing MUST be registered in SWIP. The policy intent expressed
> is SWIP registration of all independently routed blocks, not a specific
> block size, since routing is not an ARIN decision. Since current best
> practice does not allow independent routing of less than a /48, all sites
> regardless of any attempts of independent routing that are smaller than /48
> actually are not independently routed since those routes will not appear in
> the GRT, and thus are exempt from SWIP.  This level of /48 could change in
> the future via processes outside of the control of ARIN.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
> On Sun, 23 Jul 2017, David Farmer wrote:
>
> The rewrite is a pretty good step forward, and I support this policy as
>> written, but I also would like to see some additional changes.
>>
>> The following is a summary of what I would like to see the overall policy
>> look like, it is not in policy language but provided as list of
>> requirement, with some additional notes, then I note what I think is
>> 

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

[hostmaster]

Boy, am I learning from this process.  Please let me know if I am not 
defining these terms we are discussing below properly:


Allocation:  Directly receiving a block of IP addresses from ARIN.

Re-Allocation:  Taking part of an Allocation from ARIN, and permitting 
another ISP/LIR to use this block for assignment to their end user 
customers.


Assignment:  When the original ARIN blockholder assigns a block from their 
allocation to an end user customer for their use in networks, OR when 
another ISP without an ARIN allocation for the original block 
(re-allocation), assigns a portion of their re-allocation to the end user 
customers.


Reassignment:  A superset of all the cases of Assignment, as well as 
all the cases of Re-allocation, which is not currently defined in the 
NRPM.


Ok, now that I have the terms out of the way, lets talk.

There seems to be a current disconnect identified in the policy between 
Re-allocation and assignment because the term "Reassignment" in 6.5.5 is 
not defined.


Many have identified that the minimum unit of assignment should be a /48 
and ARIN policy should not change this fact by putting policies in place 
that would make it more likely that assignments of less than /48 will be 
made by ISPs/LIRs.  Therefore I propose the following amendments to the 
draft to address the issues that have been identified:


Add new section 2.17 as follows:

2.17 Reassignment

The term shall mean all cases where an Internet Registry, as defined in 
section 2.1 assigns or Re-allocates a portion of the addresses received 
from ARIN or another Internet Registry, for the use by end users or 
another Internet Registry.  This term shall include within it the terms 
assignment and Re-allocation.


Amend 6.5.5.1 as follows:

Change "Each static IPv6 assignment" to "Each static IPv6 reassignment".

Change the word "sub-delegation" to "reassignment".


Now some examples of how this draft policy will work with different size 
IPv6 blocks with the current global routing rules:


For sites with exactly /48, there will be two classes of sites:

1) Those sites with a /48 assigned to them, and using the same routing as 
the parent block (Allocation or Re-allocation) above them.


2) Those sites with a /48 assigned to them, where the entity with the /48 
has made arrangements to have their /48 assignment routed differently than 
the parent block (Allocation or Re-allocation) above them.


It is the intent of the language proposed to require 2) above to be 
registered in SWIP (since they have different routing), and to exempt 1) 
above from the SWIP requirement, as they are using the standard routing of 
their parent block, and for the most part will be normal sites that use 
just a single IPv4 address which no SWIP requirement exists, and a single 
/48 assigned to them for their site which has been identified as the best 
practice for all sites.


I think this is the confusing part of the language, since a /48 can go 
either way, SWIP or no SWIP depending on independent routing, while 
anything larger is ALWAYS SWIP'ed and and everything smaller would under 
current best practices would never require SWIP.


Under the draft, For any reassignment with a /47 or More of addresses, ALL 
will require SWIP.  This should cover ALL Re-allocation cases, as the 
reallocated block received must for technical reasons be large enough for 
the reallocator to have 1 or more /48's to assign to the customers below 
them.


Under the draft, For any site of any size, if the GRT policy is ever 
changed from a /48, all such sites smaller than the new limit that has 
independent routing MUST be registered in SWIP. The policy intent 
expressed is SWIP registration of all independently routed blocks, not a 
specific block size, since routing is not an ARIN decision. Since current 
best practice does not allow independent routing of less than a /48, all 
sites regardless of any attempts of independent routing that are smaller 
than /48 actually are not independently routed since those routes will not 
appear in the GRT, and thus are exempt from SWIP.  This level of /48 could 
change in the future via processes outside of the control of ARIN.


Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Sun, 23 Jul 2017, David Farmer wrote:


The rewrite is a pretty good step forward, and I support this policy as
written, but I also would like to see some additional changes.

The following is a summary of what I would like to see the overall policy
look like, it is not in policy language but provided as list of
requirement, with some additional notes, then I note what I think is
missing from the current proposed policy text;

Reallocations:
- All reallocations* MUST have a SWIP provided regardless of size.

Reassignments:
- For prefixes shorter than /48 a SWIP MUST be provided.
- For prefixes at /48 or longer a SWIP is provided at the discretion** of
the ISP, except;
 - If requested by the end-user, then a SWIP MUST be 

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

[David Farmer]

The rewrite is a pretty good step forward, and I support this policy as
written, but I also would like to see some additional changes.

The following is a summary of what I would like to see the overall policy
look like, it is not in policy language but provided as list of
requirement, with some additional notes, then I note what I think is
missing from the current proposed policy text;

Reallocations:
- All reallocations* MUST have a SWIP provided regardless of size.

Reassignments:
- For prefixes shorter than /48 a SWIP MUST be provided.
- For prefixes at /48 or longer a SWIP is provided at the discretion** of
the ISP, except;
  - If requested by the end-user, then a SWIP MUST be provided, or;
  - If intended to appear in global routing table, then a SWIP SHOULD*** be
provided.

*  Reallocations are made to other ISPs which then can make reassignments,
for IPv6 it is RECOMMENDED that all ISPs obtain an allocation directly from
ARIN, however reallocations are still permitted. Further, reallocations for
prefixes /48 or longer are NOT RECOMMENDED.  SWIPs for reallocations need
to be required because the abuse and other POC for the down stream ISP need
to be know.

** There should be some guidance (NOT policy enforced by ARIN) to ISPs
making reassignments at /48 or longer: SWIPs for business customers,
especially those with information technology(IT) operations sophisticated
enough to handle their own abuse and/or technical incidents, are of
interest to the community. SWIPs for residential customers (individual
persons) are NOT normally of interest to the community.

*** This might be more appropriate as MUST, however as ARIN does not define
routing policy, therefore SHOULD seems more appropriate.

So, I think the following is missing from the current proposed policy text;

1. Any mention of reallocations, but this wasn't in the original policy
either
2. A requirement that SWIP is provided if requested by end-user
3. Guidance for SWIPs for /48 or longer, while these SWIPs aren't required,
some guidance still might be useful.

Thanks

On Fri, Jul 21, 2017 at 11:44 AM, Leif Sawyer  wrote:

> Happy Friday, everybody.
>
>
>
> As promised, here is the latest rewrite of the draft policy below,  and it
> will soon be updated at:
>
> https://www.arin.net/policy/proposals/2017_5.html
>
>
>
> There are two changes noted in the policy statement: the first of which
> reflects what seems to be the current
>
> consensus of the PPML regarding netblock sizing; the second is to strike
> language that may be read as either restrictive
>
> or non-operational.
>
>
>
> 
>
>
>
> Problem Statement:
>
>Current ARIN policy has different WHOIS directory registration
> requirements for IPv4 vs IPv6 address assignments.
>
>IPv4 registration is triggered for an assignment of any address
> block equal to or greater than a /29 (i.e., eight IPv4 addresses).
>
>In the case of IPv6, registration occurs for an assignment of any
> block equal to or greater than a /64, which constitutes one entire IPv6
> subnet and is the minimum block size for an allocation.
>
>Accordingly, there is a significant disparity between IPv4 and IPv6
> WHOIS registration thresholds in the case of assignments, resulting in more
> work in the case of IPv6 than is the case for IPv4.
>
>There is no technical or policy rationale for the disparity, which
> could serve as a deterrent to more rapid IPv6 adoption.
>
>The purpose of this proposal is to eliminate the disparity and
> corresponding adverse consequences.
>
>
>
> Policy statement:
>
>1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to
> strike "/64 or more addresses" and change to "/47 or more addresses, or
> sub-delegation of any size that will be individually announced,"
>
> and
>
>2) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the
> NRPM by deleting the phrase "holding /64 and larger blocks"
>
>
>
> Comments:
>
> a.Timetable for implementation:
>
>Policy should be adopted as soon as possible.
>
>
>
> b.Anything else:
>
> Author Comments:
>
>  IPv6 should not be more burdensome than the equivalent IPv4
> network size.
>
>  Currently, assignments of /29 or more of IPv4 space (8 addresses)
> require registration
>
>  The greatest majority of ISP customers who have assignments of
> IPv4 space are of a single IPv4 address which do not trigger any ARIN
> registration requirement when using IPv4.
>
>  This is NOT true when these same exact customers use IPv6, as
> assignments of /64 or more of IPv6 space require registration.
>
>  Beginning with RFC 3177, it has been standard practice to assign
> a minimum assignment of /64 to every customer end user site, and less is
> never used.
>
>  This means that ALL IPv6 assignments, including those customers
> that only use a single IPv4 address must be registered with ARIN if they
> are given 

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

[William Herrin]

On Fri, Jul 21, 2017 at 12:44 PM, Leif Sawyer  wrote:

> Policy statement:
>
>1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to
> strike "/64 or more addresses" and change to "/47 or more addresses, or
> sub-delegation of any size that will be individually announced,"
>
> and
>

I OPPOSE this policy as written.

1. Blocks large enough to independently route on the Internet under current
operations best practice should not be assignable without publishing the
holder's identity.

2. It is not general practice to review the address assignment upon
changing the routing segment except to the extent of verifying the a
routable-size block was assigned. Probability of non-compliance even by
those who intend to comply is high.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[William Herrin]

For the record, I continue to support changing current policy (all IPv6
reassignments are SWIPed) to allow ISP reassignments of /56 to /128 to be
made without processing a SWIP entry while continuing to require
assignments of /0 to /55 be SWIPed.

I remain unconvinced by the more complicated proposals and outright oppose
permitting /48 reassignments to be made without SWIP under any
circumstances.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Marilson]

John,

I'm in favor and opposed to the policy change being discussed. Simply because, 
what will be implemented, will certainly not address my concerns.

On July 21, 2017 8:23 AM Andrew Bagrin wrote:
"I hope we’re not trying solve a security problem..." 
"As soon as ARIN decides to do something for "security" and that enforcement is 
"worked around", ARIN will be looked at as a failure."

Andrew, do not worry. Your business will continue to sell security. I do not 
intend to compete with your company. And certainly ARIN will never be your 
competitor. As a rule I seek protection against your bad customers, if you has 
some.

Cheers
Marilson

From: John Curran 
Sent: Friday, July 21, 2017 8:23 AM
To: Marilson 
Cc: mailto:arin-ppml@arin.net 
Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment 
Registration requirements between IPv4 and IPv6

Marilson - 

   Please indicate whether you are in favor or opposed to the policy change
   being discussed, including any supporting reasoning.

Thank you,
/John

John Curran
President and CEO
ARIN

On 21 Jul 2017, at 12:45 AM, Marilson <marilson.m...@gmail.com> wrote:

Gentlemen, let me introduce practical elements into this "difficult and 
onerous" attitude, but ethical, on the tech and abuse contact requests.

Let's see in practice how it works when organizations accept and disclose 
absolutely false data, and when questioned, they simply lie or ignore it.
We have on one side a well-known and hated spammer, on the other an ISP who 
insists on ignoring the denunciations, norms and laws, protecting and 
maintaining the profits that this spammer provides. And above all an entity 
that is self-titled as the regulator of good practice on the internet:

From: Marilson 
Sent: Wednesday, July 19, 2017 3:55 AM
To: complia...@icann.org ; complai...@icann.org 
Cc: cr...@icann.org ; t...@nytimes.com ; s...@uce.gov ; priv...@council.bbb.org 
; i...@iana.org ; anonb...@anonymousbrasil.com 
Subject: Fw: [#HTK-505-74506]: Whois Inaccuracy complaint re: boasvendas.info 
closed

Lie! The domain was not suspended and neither the Registrar or ISP suspended, 
deleted, cancelled or even deactivated the domain name. The spammer continues 
with their totally incorrect WHOIS data, making it impossible to take any 
defensive action because he has the protection of his ISP, Registrar, RIR and 
ICANN.

What makes me impressed is how all of you treat the complaints, as if we were 
all morons.

Your behavior is exactly like the behavior of most ISPs when receiving spam and 
scam complaints. Greed and lack of ethics in protecting spammers and scammers, 
to increase traffic on the internet, has no limits. You... (truncated). And you 
survive because you have the protection of your governments that are, as a 
rule, run by corrupt politicians.

Thanks for nothing
Marilson

***
From: compliance-tick...@icann.org 
Sent: Monday, July 17, 2017 11:43 PM
To: marilson.m...@gmail.com 
Subject: [#HTK-505-74506]: Whois Inaccuracy complaint re: boasvendas.info closed

Dear Marilson,

Thank you for submitting a Whois Inaccuracy complaint concerning the domain 
name boasvendas.info. ICANN has reviewed and closed your complaint because:

- Based on the current Whois data, the domain was suspended when the complaint 
was received by ICANN, or the registrar demonstrated that it took reasonable 
steps to investigate the Whois inaccuracy claim by suspending, deleting, 
cancelling or otherwise deactivating the domain name.

ICANN considers this matter now closed.

Please do not reply to the email. If you require future assistance, please 
email complia...@icann.org; if you have a new complaint, please submit it at 
http://www.icann.org/resources/compliance/complaints .

ICANN is requesting your feedback on this closed complaint. Please complete 
this optional survey at 
https://www.surveymonkey.com/s/8F2Z6DP?ticket=HTK-505-74506 .

Sincerely,

ICANN Contractual Compliance



The problem summary:

Reporter Name: Marilson
Reporter Email: marilson.m...@gmail.com
Domain being reported: boasvendas.info

Time of submission/processing: Wed Jun 28 17:59:43 2017

Problem in whois block: Expiration Date
--- Error in date: Nothing to report

Problem in whois block: Technical Contact
--- Error in address: Incorrect address
--- Error in phone number: Incorrect phone
--- Error in name: Wrong person or entity
--- Error in email: Nothing to report
--- Error in fax number: Fax is missing
--- Comment: He is a spammer and someone want to keep him hidden from his 
victims.

Problem in whois block: Registrant Contact
--- Error in address: Incorrect address
--- Error in name: Wrong person or entity
--- Comment: Registrant ID: C205479611-LRMS 
Registrant Name: BenL. A.  - FAKE – DOESNOT EXIST
R

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

[hostmaster]

Even though the /49, /50 ... /128 is technically covered by the "any size" 
language, for all practical purposes /48 or more is all that can be 
advertised, as nothing smaller than a /48 is contained in the GRT.


Thus, your perception that it covers only sub-delegations of /48 or more 
is correct.


Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Fri, 21 Jul 2017, Scott Leibrand wrote:


On Jul 21, 2017, at 8:31 PM, John Springer <3jo...@gmail.com> wrote:

I support this Draft Policy as re-written.

I shared the author's distaste for the requirement that IPV6 /64s be SWIP'd, 
but was not reassured when the discussion veered to consider prefixes between 
/48 and /64. AFAIK, ISPs have long been encouraged to apply for their 
allocations based on the idea of assigning a /48 to each 'customer' to provide 
room for unknown technologies, among other things. I did not wish to endanger 
that premise, but current language appears to moot that concern.

To be explicit, to me, "/47 or more addresses, or sub-delegation of any size that 
will be individually announced," refers to /47s, /46s, /45s ... and not /48s, /49s, 
/50s, etc.


That's not what it says. It says /48s (or longer) should be individually 
SWIPped if they're going to be announced. Otherwise there's no reason for the 
extra clause.

Blocks in the GRT need to be SWIPped to the announcing party if that's a 
different organization from the holder of the larger block.

-Scott




On Fri, Jul 21, 2017 at 9:44 AM, Leif Sawyer  wrote:
Happy Friday, everybody.



As promised, here is the latest rewrite of the draft policy below,  and it will 
soon be updated at:

https://www.arin.net/policy/proposals/2017_5.html



There are two changes noted in the policy statement: the first of which 
reflects what seems to be the current

consensus of the PPML regarding netblock sizing; the second is to strike 
language that may be read as either restrictive

or non-operational.







Problem Statement:

   Current ARIN policy has different WHOIS directory registration 
requirements for IPv4 vs IPv6 address assignments.

   IPv4 registration is triggered for an assignment of any address block 
equal to or greater than a /29 (i.e., eight IPv4 addresses).

   In the case of IPv6, registration occurs for an assignment of any block 
equal to or greater than a /64, which constitutes one entire IPv6 subnet and is 
the minimum block size for an allocation.

   Accordingly, there is a significant disparity between IPv4 and IPv6 
WHOIS registration thresholds in the case of assignments, resulting in more 
work in the case of IPv6 than is the case for IPv4.

   There is no technical or policy rationale for the disparity, which could 
serve as a deterrent to more rapid IPv6 adoption.

   The purpose of this proposal is to eliminate the disparity and 
corresponding adverse consequences.



Policy statement:

   1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike "/64 or more 
addresses" and change to "/47 or more addresses, or sub-delegation of any size that will be 
individually announced,"

and

   2) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by deleting 
the phrase "holding /64 and larger blocks"



Comments:

a.Timetable for implementation:

   Policy should be adopted as soon as possible.



b.Anything else:

Author Comments:

 IPv6 should not be more burdensome than the equivalent IPv4 network 
size.

 Currently, assignments of /29 or more of IPv4 space (8 addresses) 
require registration

 The greatest majority of ISP customers who have assignments of IPv4 
space are of a single IPv4 address which do not trigger any ARIN registration 
requirement when using IPv4.

 This is NOT true when these same exact customers use IPv6, as 
assignments of /64 or more of IPv6 space require registration.

 Beginning with RFC 3177, it has been standard practice to assign a 
minimum assignment of /64 to every customer end user site, and less is never 
used.

 This means that ALL IPv6 assignments, including those customers that 
only use a single IPv4 address must be registered with ARIN if they are given 
the minimum assignment of /64 of IPv6 space.

 This additional effort may prevent ISP's from giving IPv6 addresses 
because of the additional expense of registering those addresses with ARIN, 
which is not required for IPv4.

 The administrative burden of 100% customer registration of IPv6 
customers is unreasonable, when such is not required for those customers 
receiving only IPv4 connections.





---



Leif Sawyer

Advisory Council




___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:

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

[Scott Leibrand]

> On Jul 21, 2017, at 8:31 PM, John Springer <3jo...@gmail.com> wrote:
> 
> I support this Draft Policy as re-written.
> 
> I shared the author's distaste for the requirement that IPV6 /64s be SWIP'd, 
> but was not reassured when the discussion veered to consider prefixes between 
> /48 and /64. AFAIK, ISPs have long been encouraged to apply for their 
> allocations based on the idea of assigning a /48 to each 'customer' to 
> provide room for unknown technologies, among other things. I did not wish to 
> endanger that premise, but current language appears to moot that concern.
> 
> To be explicit, to me, "/47 or more addresses, or sub-delegation of any size 
> that will be individually announced," refers to /47s, /46s, /45s ... and not 
> /48s, /49s, /50s, etc.

That's not what it says. It says /48s (or longer) should be individually 
SWIPped if they're going to be announced. Otherwise there's no reason for the 
extra clause. 

Blocks in the GRT need to be SWIPped to the announcing party if that's a 
different organization from the holder of the larger block. 

-Scott

> 
>> On Fri, Jul 21, 2017 at 9:44 AM, Leif Sawyer  wrote:
>> Happy Friday, everybody.
>> 
>>  
>> 
>> As promised, here is the latest rewrite of the draft policy below,  and it 
>> will soon be updated at:
>> 
>> https://www.arin.net/policy/proposals/2017_5.html
>> 
>>  
>> 
>> There are two changes noted in the policy statement: the first of which 
>> reflects what seems to be the current
>> 
>> consensus of the PPML regarding netblock sizing; the second is to strike 
>> language that may be read as either restrictive
>> 
>> or non-operational.
>> 
>>  
>> 
>> 
>> 
>>  
>> 
>> Problem Statement:
>> 
>>Current ARIN policy has different WHOIS directory registration 
>> requirements for IPv4 vs IPv6 address assignments. 
>> 
>>IPv4 registration is triggered for an assignment of any address block 
>> equal to or greater than a /29 (i.e., eight IPv4 addresses).
>> 
>>In the case of IPv6, registration occurs for an assignment of any 
>> block equal to or greater than a /64, which constitutes one entire IPv6 
>> subnet and is the minimum block size for an allocation.
>> 
>>Accordingly, there is a significant disparity between IPv4 and IPv6 
>> WHOIS registration thresholds in the case of assignments, resulting in more 
>> work in the case of IPv6 than is the case for IPv4.
>> 
>>There is no technical or policy rationale for the disparity, which 
>> could serve as a deterrent to more rapid IPv6 adoption.
>> 
>>The purpose of this proposal is to eliminate the disparity and 
>> corresponding adverse consequences.
>> 
>>  
>> 
>> Policy statement:
>> 
>>1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to 
>> strike "/64 or more addresses" and change to "/47 or more addresses, or 
>> sub-delegation of any size that will be individually announced,"
>> 
>> and 
>> 
>>2) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the 
>> NRPM by deleting the phrase "holding /64 and larger blocks"
>> 
>>  
>> 
>> Comments:
>> 
>> a.Timetable for implementation:
>> 
>>Policy should be adopted as soon as possible.
>> 
>>  
>> 
>> b.Anything else:
>> 
>> Author Comments:
>> 
>>  IPv6 should not be more burdensome than the equivalent IPv4 network 
>> size.
>> 
>>  Currently, assignments of /29 or more of IPv4 space (8 addresses) 
>> require registration
>> 
>>  The greatest majority of ISP customers who have assignments of IPv4 
>> space are of a single IPv4 address which do not trigger any ARIN 
>> registration requirement when using IPv4.
>> 
>>  This is NOT true when these same exact customers use IPv6, as 
>> assignments of /64 or more of IPv6 space require registration. 
>> 
>>  Beginning with RFC 3177, it has been standard practice to assign a 
>> minimum assignment of /64 to every customer end user site, and less is never 
>> used. 
>> 
>>  This means that ALL IPv6 assignments, including those customers 
>> that only use a single IPv4 address must be registered with ARIN if they are 
>> given the minimum assignment of /64 of IPv6 space. 
>> 
>>  This additional effort may prevent ISP's from giving IPv6 addresses 
>> because of the additional expense of registering those addresses with ARIN, 
>> which is not required for IPv4.
>> 
>>  The administrative burden of 100% customer registration of IPv6 
>> customers is unreasonable, when such is not required for those customers 
>> receiving only IPv4 connections.
>> 
>>  
>> 
>>  
>> 
>> ---
>> 
>>  
>> 
>> Leif Sawyer
>> 
>> Advisory Council
>> 
>>  
>> 
>> 
>> ___
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> 

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

[John Springer]

I support this Draft Policy as re-written.

I shared the author's distaste for the requirement that IPV6 /64s be
SWIP'd, but was not reassured when the discussion veered to consider
prefixes between /48 and /64. AFAIK, ISPs have long been encouraged to
apply for their allocations based on the idea of assigning a /48 to each
'customer' to provide room for unknown technologies, among other things. I
did not wish to endanger that premise, but current language appears to moot
that concern.

To be explicit, to me, "/47 or more addresses, or sub-delegation of any
size that will be individually announced," refers to /47s, /46s, /45s ...
and not /48s, /49s, /50s, etc.

John Springer

On Fri, Jul 21, 2017 at 9:44 AM, Leif Sawyer  wrote:

> Happy Friday, everybody.
>
>
>
> As promised, here is the latest rewrite of the draft policy below,  and it
> will soon be updated at:
>
> https://www.arin.net/policy/proposals/2017_5.html
>
>
>
> There are two changes noted in the policy statement: the first of which
> reflects what seems to be the current
>
> consensus of the PPML regarding netblock sizing; the second is to strike
> language that may be read as either restrictive
>
> or non-operational.
>
>
>
> 
>
>
>
> Problem Statement:
>
>Current ARIN policy has different WHOIS directory registration
> requirements for IPv4 vs IPv6 address assignments.
>
>IPv4 registration is triggered for an assignment of any address
> block equal to or greater than a /29 (i.e., eight IPv4 addresses).
>
>In the case of IPv6, registration occurs for an assignment of any
> block equal to or greater than a /64, which constitutes one entire IPv6
> subnet and is the minimum block size for an allocation.
>
>Accordingly, there is a significant disparity between IPv4 and IPv6
> WHOIS registration thresholds in the case of assignments, resulting in more
> work in the case of IPv6 than is the case for IPv4.
>
>There is no technical or policy rationale for the disparity, which
> could serve as a deterrent to more rapid IPv6 adoption.
>
>The purpose of this proposal is to eliminate the disparity and
> corresponding adverse consequences.
>
>
>
> Policy statement:
>
>1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to
> strike "/64 or more addresses" and change to "/47 or more addresses, or
> sub-delegation of any size that will be individually announced,"
>
> and
>
>2) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the
> NRPM by deleting the phrase "holding /64 and larger blocks"
>
>
>
> Comments:
>
> a.Timetable for implementation:
>
>Policy should be adopted as soon as possible.
>
>
>
> b.Anything else:
>
> Author Comments:
>
>  IPv6 should not be more burdensome than the equivalent IPv4
> network size.
>
>  Currently, assignments of /29 or more of IPv4 space (8 addresses)
> require registration
>
>  The greatest majority of ISP customers who have assignments of
> IPv4 space are of a single IPv4 address which do not trigger any ARIN
> registration requirement when using IPv4.
>
>  This is NOT true when these same exact customers use IPv6, as
> assignments of /64 or more of IPv6 space require registration.
>
>  Beginning with RFC 3177, it has been standard practice to assign
> a minimum assignment of /64 to every customer end user site, and less is
> never used.
>
>  This means that ALL IPv6 assignments, including those customers
> that only use a single IPv4 address must be registered with ARIN if they
> are given the minimum assignment of /64 of IPv6 space.
>
>  This additional effort may prevent ISP's from giving IPv6
> addresses because of the additional expense of registering those addresses
> with ARIN, which is not required for IPv4.
>
>  The administrative burden of 100% customer registration of IPv6
> customers is unreasonable, when such is not required for those customers
> receiving only IPv4 connections.
>
>
>
>
>
> ---
>
>
>
> Leif Sawyer
>
> Advisory Council
>
>
>
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Paul McNary]

+1


On 7/21/2017 12:34 PM, Scott Leibrand wrote:

This looks good: I support.

For clarity, so we don't all have to do it, and to help make sure 
we're not missing anything, here's what the resulting 6.5.5 looks like 
after modification:


6.5.5. Registration

ISPs are required to demonstrate efficient use of IP address space 
allocations by providing appropriate documentation, including but not 
limited to assignment histories, showing their efficient use.


6.5.5.1. Reassignment information

Each static IPv6 assignment containing a /47 or more addresses, or 
sub-delegation of any size that will be individually announced, shall 
be registered in the WHOIS directory via SWIP or a distributed service 
which meets the standards set forth in section 3.2. Reassignment 
registrations shall include each client's organizational information, 
except where specifically exempted by this policy.


6.5.5.2. Assignments visible within 7 days

All assignments shall be made visible as required in section 4.2.3.7.1 
within seven calendar days of assignment.


6.5.5.3. Residential Subscribers

6.5.5.3.1. Residential Customer Privacy

To maintain the privacy of their residential customers, an 
organization with downstream residential customers may substitute that 
organization's name for the customer's name, e.g. 'Private Customer - 
XYZ Network', and the customer's street address may read 'Private 
Residence'. Each private downstream residential reassignment must have 
accurate upstream Abuse and Technical POCs visible on the WHOIS record 
for that block.


-Scott

On Fri, Jul 21, 2017 at 9:44 AM, Leif Sawyer > wrote:


Happy Friday, everybody.

As promised, here is the latest rewrite of the draft policy below,
 and it will soon be updated at:

https://www.arin.net/policy/proposals/2017_5.html


There are two changes noted in the policy statement: the first of
which reflects what seems to be the current

consensus of the PPML regarding netblock sizing; the second is to
strike language that may be read as either restrictive

or non-operational.



Problem Statement:

Current ARIN policy has different WHOIS directory registration
requirements for IPv4 vs IPv6 address assignments.

   IPv4 registration is triggered for an assignment of any
address block equal to or greater than a /29 (i.e., eight IPv4
addresses).

In the case of IPv6, registration occurs for an assignment of any
block equal to or greater than a /64, which constitutes one entire
IPv6 subnet and is the minimum block size for an allocation.

Accordingly, there is a significant disparity between IPv4 and
IPv6 WHOIS registration thresholds in the case of assignments,
resulting in more work in the case of IPv6 than is the case for IPv4.

There is no technical or policy rationale for the disparity, which
could serve as a deterrent to more rapid IPv6 adoption.

The purpose of this proposal is to eliminate the disparity and
corresponding adverse consequences.

Policy statement:

1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to
strike "/64 or more addresses" and change to "/47 or more
addresses, or sub-delegation of any size that will be individually
announced,"

and

   2) Alter section 6.5.5.3.1. "Residential Customer Privacy"
of the NRPM by deleting the phrase "holding /64 and larger blocks"

Comments:

a. Timetable for implementation:

Policy should be adopted as soon as possible.

b. Anything else:

Author Comments:

IPv6 should not be more burdensome than the equivalent IPv4
network size.

Currently, assignments of /29 or more of IPv4 space (8 addresses)
require registration

The greatest majority of ISP customers who have assignments of
IPv4 space are of a single IPv4 address which do not trigger any
ARIN registration requirement when using IPv4.

This is NOT true when these same exact customers use IPv6, as
assignments of /64 or more of IPv6 space require registration.

 Beginning with RFC 3177, it has been standard practice to
assign a minimum assignment of /64 to every customer end user
site, and less is never used.

 This means that ALL IPv6 assignments, including those
customers that only use a single IPv4 address must be registered
with ARIN if they are given the minimum assignment of /64 of IPv6
space.

 This additional effort may prevent ISP's from giving IPv6
addresses because of the additional expense of registering those
addresses with ARIN, which is not required for IPv4.

The administrative burden of 100% customer registration of IPv6
customers is unreasonable, when such is not required for those
customers receiving only IPv4 connections.

---

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

[Paul McNary]

Leif
While not a committee member, this is tolerable and workable.
We can assign a /48 to every tower (POP) and that will geo locate
good enough for the rural area. Geo location by address doesn't
work that well in our rural area anyhow. Can be miles off. But
using tower location will get it into less than 10 mile geo location.
One comment is that most providers that I have dealt with are very
reluctant to swip anything less than an IPv4 /24. This no longer affects
me because these providers are in the process of reclaiming their IP
space when we shifted to fiber. One was nice and one wasn't, but we
basically had to shift all customers to NAT since we didn't make it in time
to get our own IPv4 allocation. Getting an IPv6 allocation is waiting on 
our fiber

provider providing dual stack and the issues you are some what addressing
in this current policy making.

Thanks
Paul McNary
pmcn...@cameron.net

On 7/21/2017 11:44 AM, Leif Sawyer wrote:


Happy Friday, everybody.

As promised, here is the latest rewrite of the draft policy below, 
 and it will soon be updated at:


https://www.arin.net/policy/proposals/2017_5.html

There are two changes noted in the policy statement: the first of 
which reflects what seems to be the current


consensus of the PPML regarding netblock sizing; the second is to 
strike language that may be read as either restrictive


or non-operational.



Problem Statement:

Current ARIN policy has different WHOIS directory registration 
requirements for IPv4 vs IPv6 address assignments.


   IPv4 registration is triggered for an assignment of any address 
block equal to or greater than a /29 (i.e., eight IPv4 addresses).


In the case of IPv6, registration occurs for an assignment of any 
block equal to or greater than a /64, which constitutes one entire 
IPv6 subnet and is the minimum block size for an allocation.


Accordingly, there is a significant disparity between IPv4 and IPv6 
WHOIS registration thresholds in the case of assignments, resulting in 
more work in the case of IPv6 than is the case for IPv4.


There is no technical or policy rationale for the disparity, which 
could serve as a deterrent to more rapid IPv6 adoption.


The purpose of this proposal is to eliminate the disparity and 
corresponding adverse consequences.


Policy statement:

1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to 
strike "/64 or more addresses" and change to "/47 or more addresses, 
or sub-delegation of any size that will be individually announced,"


and

   2) Alter section 6.5.5.3.1. "Residential Customer Privacy" of 
the NRPM by deleting the phrase "holding /64 and larger blocks"


Comments:

a. Timetable for implementation:

Policy should be adopted as soon as possible.

b. Anything else:

Author Comments:

IPv6 should not be more burdensome than the equivalent IPv4 network size.

Currently, assignments of /29 or more of IPv4 space (8 addresses) 
require registration


The greatest majority of ISP customers who have assignments of IPv4 
space are of a single IPv4 address which do not trigger any ARIN 
registration requirement when using IPv4.


This is NOT true when these same exact customers use IPv6, as 
assignments of /64 or more of IPv6 space require registration.


 Beginning with RFC 3177, it has been standard practice to 
assign a minimum assignment of /64 to every customer end user site, 
and less is never used.


 This means that ALL IPv6 assignments, including those 
customers that only use a single IPv4 address must be registered with 
ARIN if they are given the minimum assignment of /64 of IPv6 space.


 This additional effort may prevent ISP's from giving IPv6 
addresses because of the additional expense of registering those 
addresses with ARIN, which is not required for IPv4.


The administrative burden of 100% customer registration of IPv6 
customers is unreasonable, when such is not required for those 
customers receiving only IPv4 connections.


---

Leif Sawyer

Advisory Council



___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

This looks good: I support.

For clarity, so we don't all have to do it, and to help make sure we're not
missing anything, here's what the resulting 6.5.5 looks like after
modification:

6.5.5. Registration

ISPs are required to demonstrate efficient use of IP address space
allocations by providing appropriate documentation, including but not
limited to assignment histories, showing their efficient use.

6.5.5.1. Reassignment information

Each static IPv6 assignment containing a /47 or more addresses, or
sub-delegation of any size that will be individually announced, shall be
registered in the WHOIS directory via SWIP or a distributed service which
meets the standards set forth in section 3.2. Reassignment registrations
shall include each client's organizational information, except where
specifically exempted by this policy.

6.5.5.2. Assignments visible within 7 days

All assignments shall be made visible as required in section 4.2.3.7.1
within seven calendar days of assignment.

6.5.5.3. Residential Subscribers

6.5.5.3.1. Residential Customer Privacy

To maintain the privacy of their residential customers, an organization
with downstream residential customers may substitute that organization's
name for the customer's name, e.g. 'Private Customer - XYZ Network', and
the customer's street address may read 'Private Residence'. Each private
downstream residential reassignment must have accurate upstream Abuse and
Technical POCs visible on the WHOIS record for that block.

-Scott

On Fri, Jul 21, 2017 at 9:44 AM, Leif Sawyer  wrote:

> Happy Friday, everybody.
>
>
>
> As promised, here is the latest rewrite of the draft policy below,  and it
> will soon be updated at:
>
> https://www.arin.net/policy/proposals/2017_5.html
>
>
>
> There are two changes noted in the policy statement: the first of which
> reflects what seems to be the current
>
> consensus of the PPML regarding netblock sizing; the second is to strike
> language that may be read as either restrictive
>
> or non-operational.
>
>
>
> 
>
>
>
> Problem Statement:
>
>Current ARIN policy has different WHOIS directory registration
> requirements for IPv4 vs IPv6 address assignments.
>
>IPv4 registration is triggered for an assignment of any address
> block equal to or greater than a /29 (i.e., eight IPv4 addresses).
>
>In the case of IPv6, registration occurs for an assignment of any
> block equal to or greater than a /64, which constitutes one entire IPv6
> subnet and is the minimum block size for an allocation.
>
>Accordingly, there is a significant disparity between IPv4 and IPv6
> WHOIS registration thresholds in the case of assignments, resulting in more
> work in the case of IPv6 than is the case for IPv4.
>
>There is no technical or policy rationale for the disparity, which
> could serve as a deterrent to more rapid IPv6 adoption.
>
>The purpose of this proposal is to eliminate the disparity and
> corresponding adverse consequences.
>
>
>
> Policy statement:
>
>1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to
> strike "/64 or more addresses" and change to "/47 or more addresses, or
> sub-delegation of any size that will be individually announced,"
>
> and
>
>2) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the
> NRPM by deleting the phrase "holding /64 and larger blocks"
>
>
>
> Comments:
>
> a.Timetable for implementation:
>
>Policy should be adopted as soon as possible.
>
>
>
> b.Anything else:
>
> Author Comments:
>
>  IPv6 should not be more burdensome than the equivalent IPv4
> network size.
>
>  Currently, assignments of /29 or more of IPv4 space (8 addresses)
> require registration
>
>  The greatest majority of ISP customers who have assignments of
> IPv4 space are of a single IPv4 address which do not trigger any ARIN
> registration requirement when using IPv4.
>
>  This is NOT true when these same exact customers use IPv6, as
> assignments of /64 or more of IPv6 space require registration.
>
>  Beginning with RFC 3177, it has been standard practice to assign
> a minimum assignment of /64 to every customer end user site, and less is
> never used.
>
>  This means that ALL IPv6 assignments, including those customers
> that only use a single IPv4 address must be registered with ARIN if they
> are given the minimum assignment of /64 of IPv6 space.
>
>  This additional effort may prevent ISP's from giving IPv6
> addresses because of the additional expense of registering those addresses
> with ARIN, which is not required for IPv4.
>
>  The administrative burden of 100% customer registration of IPv6
> customers is unreasonable, when such is not required for those customers
> receiving only IPv4 connections.
>
>
>
>
>
> ---
>
>
>
> Leif Sawyer
>
> Advisory Council
>
>
>
> ___
> PPML
> You are receiving 

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

[Andrew Bagrin]

Wow, what did I miss?



I hope we’re not trying solve a security problem through a strict
requirement of SWIP or anything that we’re doing. I hate to break it to
everyone, but bad guys always find another way around and don’t really care
about following any rules we create. We should be more focused on what
makes sense and will benefit the general population when used correctly.

As soon as ARIN decides to do something for “security” and that enforcement
is “worked around”, ARIN will be looked at as a failure.



As long the tool is available and all ISP are motivated to use it properly,
it will work in general. There will always be exceptions. (fake entries
etc..) some for bad reasons (like spammers) and some for good reasons
(anonymity).



I’m good with any of the proposed. I would like to see more SWIP occurring
and motivate ISP’s to do it by default unless the customer specifies they
do not want their info tied to that IP address (commercial and
residential).



*From:* ARIN-PPML [mailto:arin-ppml-boun...@arin.net] *On Behalf Of *
Marilson
*Sent:* Friday, July 21, 2017 12:46 AM
*To:* Owen DeLong <o...@delong.com>; Pallieter Koopmans <
pallie...@pallieter.org>
*Cc:* arin-ppml@arin.net
*Subject:* Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of
Assignment Registration requirements between IPv4 and IPv6



Gentlemen, let me introduce practical elements into this "difficult and
onerous" attitude, but ethical, on the tech and abuse contact requests.



Let's see in practice how it works when organizations accept and disclose
absolutely false data, and when questioned, they simply lie or ignore it.

We have on one side a well-known and hated spammer, on the other an ISP who
insists on ignoring the denunciations, norms and laws, protecting and
maintaining the profits that this spammer provides. And above all an entity
that is self-titled as the regulator of good practice on the internet:



*From:* Marilson

*Sent:* Wednesday, July 19, 2017 3:55 AM

*To:* complia...@icann.org ; complai...@icann.org

*Cc:* cr...@icann.org ; t...@nytimes.com ; s...@uce.gov ;
priv...@council.bbb.org ; i...@iana.org ; anonb...@anonymousbrasil.com

*Subject:* Fw: [#HTK-505-74506]: Whois Inaccuracy complaint re:
boasvendas.info closed



Lie! The domain was not suspended and neither the Registrar or ISP
suspended, deleted, cancelled or even deactivated the domain name. The
spammer continues with their totally incorrect WHOIS data, making it
impossible to take any defensive action because he has the protection of
his ISP, Registrar, RIR and ICANN.



What makes me impressed is how all of you treat the complaints, as if we
were all morons.



Your behavior is exactly like the behavior of most ISPs when receiving spam
and scam complaints. Greed and lack of ethics in protecting spammers and
scammers, to increase traffic on the internet, has no limits. You...
(truncated). And you survive because you have the protection of your
governments that are, as a rule, run by corrupt politicians.



Thanks for nothing

Marilson



***

*From:* compliance-tick...@icann.org

*Sent:* Monday, July 17, 2017 11:43 PM

*To:* marilson.m...@gmail.com

*Subject:* [#HTK-505-74506]: Whois Inaccuracy complaint re: boasvendas.info
closed



Dear Marilson,

Thank you for submitting a Whois Inaccuracy complaint concerning the domain
name boasvendas.info. ICANN has reviewed and closed your complaint because:

- Based on the current Whois data, the domain was suspended when the
complaint was received by ICANN, or the registrar demonstrated that it took
reasonable steps to investigate the Whois inaccuracy claim by suspending,
deleting, cancelling or otherwise deactivating the domain name.

ICANN considers this matter now closed.

Please do not reply to the email. If you require future assistance, please
email complia...@icann.org; if you have a new complaint, please submit it
at http://www.icann.org/resources/compliance/complaints .

ICANN is requesting your feedback on this closed complaint. Please complete
this optional survey at
https://www.surveymonkey.com/s/8F2Z6DP?ticket=HTK-505-74506 .

Sincerely,

ICANN Contractual Compliance



The problem summary:

Reporter Name: Marilson
Reporter Email: marilson.m...@gmail.com
Domain being reported: boasvendas.info

Time of submission/processing: Wed Jun 28 17:59:43 2017

Problem in whois block: Expiration Date
--- Error in date: Nothing to report

Problem in whois block: Technical Contact
--- Error in address: Incorrect address
--- Error in phone number: Incorrect phone
--- Error in name: Wrong person or entity
--- Error in email: Nothing to report
--- Error in fax number: Fax is missing
--- Comment: He is a spammer and someone want to keep him hidden from his
victims.

Problem in whois block: Registrant Contact
--- Error

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

[Marilson]

Registrar IANA ID: 440
Registrar Abuse Contact Email:
Registrar Abuse Contact Phone:
Reseller:
Domain Status: clientDeleteProhibited
https://icann.org/epp#clientDeleteProhibited
Domain Status: clientRenewProhibited
https://icann.org/epp#clientRenewProhibited
Domain Status: clientTransferProhibited
https://icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited
https://icann.org/epp#clientUpdateProhibited
Domain Status: serverTransferProhibited
https://icann.org/epp#serverTransferProhibited
Registry Registrant ID: C205479611-LRMS
Registrant Name: BenL. A.
Registrant Organization:
Registrant Street: Estrada J. C.
Registrant City: Curtume
Registrant State/Province: Sao Paulo
Registrant Postal Code: 1811
Registrant Country: BR
Registrant Phone: +55.4333566600
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email: bouces1...@gmail.com
Registry Admin ID: C205479613-LRMS
Admin Name: BenL. A.
Admin Organization:
Admin Street: Estrada J. C.
Admin City: Curtume
Admin State/Province: Sao Paulo
Admin Postal Code: 1811
Admin Country: BR
Admin Phone: +55.4333566600
Admin Phone Ext:
Admin Fax:
Admin Fax Ext:
Admin Email: bouces1...@gmail.com
Registry Tech ID: C205479612-LRMS
Tech Name: BenL. A.
Tech Organization:
Tech Street: Estrada J. C.
Tech City: Curtume
Tech State/Province: Sao Paulo
Tech Postal Code: 1811
Tech Country: BR
Tech Phone: +55.4333566600
Tech Phone Ext:
Tech Fax:
Tech Fax Ext:
Tech Email: bouces1...@gmail.com
Registry Billing ID: C205479614-LRMS
Billing Name: BenL. A.
Billing Organization:
Billing Street: Estrada J. C.
Billing City: Curtume
Billing State/Province: Sao Paulo
Billing Postal Code: 1811
Billing Country: BR
Billing Phone: +55.4333566600
Billing Phone Ext:
Billing Fax:
Billing Fax Ext:
Billing Email: bouces1...@gmail.com
Name Server: NS1.BOASVENDAS.INFO
Name Server: NS2.BOASVENDAS.INFO
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form:
https://www.icann.org/wicf/
>>> Last update of WHOIS database: 2017-06-28T17:59:03Z <<<

For more information on Whois status codes, please visit
https://icann.org/epp



That is it.
Marilson
***
From: Owen DeLong 
Sent: Thursday, July 20, 2017 5:16 PM
To: Pallieter Koopmans 
Cc: arin-ppml@arin.net 
Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment 
Registration requirements between IPv4 and IPv6

How can it be overly difficult to fill out an email template with your 
customers’
Name, Address, Phone Number?

Really?

Owen

> On Jul 19, 2017, at 23:48 , Pallieter Koopmans <pallie...@pallieter.org> 
> wrote:
> 
> Hello,
> 
> ARIN could quantify and require rules for when to SWIP, but in the
> end, there are going to be exceptions needed if the rules are to be
> strictly followed. Many will not separately SWIP a separately routed
> sub-block if it is too difficult or pointless to gather and share that
> data back upstream to ARIN.
> 
> Thus a more fuzzy rule to require a best-effort and to add a
> rule-based reason (preferably both a carrot and a stick) for block
> owners to do their best to provide (only) useful data. In order to do
> that, one needs to look back at why that data is needed. For a block
> owner to assign the SWIP on a sub-block, he basically delegates tech
> and abuse contact requests down to those that are probably more likely
> to be able to actually act on the tech/abuse requests (and thus reduce
> request-handling workload higher up and overall). But for that to
> work, those tech/abuse contact requests need to be actually handled,
> otherwise, it is better to leave them with the block owner.
> 
> In the end, the contact details should be as close to the "person"
> that is actually capable to both handle (think: volume/languages/etc)
> and act (think: authority) on the tech/abuse requests.
> 
> eBrain
> Innovative Internet Ideas
> 
> Pallieter Koopmans
> Managing Director
> 
> +31-6-3400-3800 (mon-sat 9-22 CET)
> Skype: PallieterKoopmans
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you

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

[Chris James]

Well I think in the bus example you would swip to the overall authority.
But seriously this conversation has gone in so many different directions do
any of us remember the original point?

My vote as it applies to v6: Non-residential allocations of greater than or
equal to a /48.

If you as an ISP choose to allocate a /48 to a residential customer - then
have fun. But this does not affect the purpose of the policy as most use it
these days which is abuse management. Also as I understand it, there is an
exception to the CPNI as it applies to business customers as long as they
have an account manager and adequate language in the contract. How many of
the smaller ISPs have a customer deserving of a /48 or better that does not
have a larger account or spend? If a customer requests a large enough block
from us, regardless of v4 vs v6, they agree via email/ticketing/contract
that their business information will be made public. This is not difficult
to put in your signed agreements with your business customers thus making
the CPNI argument invalid.

-Chris



On Thu, Jul 20, 2017 at 2:28 PM,  wrote:

> My transit bus example is another example of SWIP difficulty.  Very hard
> to provide a street address to SWIP a bus when it is mobile 16 hours a day.
>
> Current policy says SWIP every /64 or more, which is every network in v6.
>
> I did a check here, and in v4, only 1% of customers have more than 8 ip's,
> and these customers are colocation customers who have a bunch of SSL
> sites.  These are grandfathered. New customers are told to use 1 IPv4
> address and SNI or better yet, IPv6, as we do not have the money to buy
> more V4.  We would rather use our v4 inventory for access customers.
>
> Yes, it is just a few pieces of information for SWIP.  However, we do not
> have clerical staff to do it, because except for the SSL colocates, there
> never has been v4 SWIP's required here. Why should the policy state that
> just because we give each customer an assignment of v6, we must SWIP that
> same small customer that did not require SWIP in v4? (Welcome to IPv6, now
> fill out this form.) Also noted is that the SWIP registration details
> without written permission might get us in trouble with the FCC over CPNI.
> As a WISP that has licensed microwave links, we do pay attention to Uncle
> Charlie.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
> On Thu, 20 Jul 2017, Chris James wrote:
>
> @Paul - The API key is to email it.
>>
>> @Owen - Very difficult when you have dynamic ranges, and vps/container
>> platforms spanning tens of thousands of instances across these dynamic
>> ranges.
>>
>>
>> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary  wrote:
>>
>> Owen
>>>
>>> The reassignment policy page says IPv6 has to be done vi API.
>>> Is that something else that is incorrect on the web site?
>>>
>>> Paul
>>>
>>>
>>> On 7/20/2017 3:16 PM, Owen DeLong wrote:
>>>
>>> How can it be overly difficult to fill out an email template with your
 customers’
 Name, Address, Phone Number?

 Really?

 Owen

 On Jul 19, 2017, at 23:48 , Pallieter Koopmans 

> wrote:
>
> Hello,
>
> ARIN could quantify and require rules for when to SWIP, but in the
> end, there are going to be exceptions needed if the rules are to be
> strictly followed. Many will not separately SWIP a separately routed
> sub-block if it is too difficult or pointless to gather and share that
> data back upstream to ARIN.
>
> Thus a more fuzzy rule to require a best-effort and to add a
> rule-based reason (preferably both a carrot and a stick) for block
> owners to do their best to provide (only) useful data. In order to do
> that, one needs to look back at why that data is needed. For a block
> owner to assign the SWIP on a sub-block, he basically delegates tech
> and abuse contact requests down to those that are probably more likely
> to be able to actually act on the tech/abuse requests (and thus reduce
> request-handling workload higher up and overall). But for that to
> work, those tech/abuse contact requests need to be actually handled,
> otherwise, it is better to leave them with the block owner.
>
> In the end, the contact details should be as close to the "person"
> that is actually capable to both handle (think: volume/languages/etc)
> and act (think: authority) on the tech/abuse requests.
>
> eBrain
> Innovative Internet Ideas
>
> Pallieter Koopmans
> Managing Director
>
> +31-6-3400-3800 (mon-sat 9-22 CET)
> Skype: PallieterKoopmans
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> 

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

[hostmaster]

My transit bus example is another example of SWIP difficulty.  Very hard 
to provide a street address to SWIP a bus when it is mobile 16 hours a 
day.


Current policy says SWIP every /64 or more, which is every network in v6.

I did a check here, and in v4, only 1% of customers have more than 8 ip's, 
and these customers are colocation customers who have a bunch of SSL 
sites.  These are grandfathered. New customers are told to use 1 IPv4 
address and SNI or better yet, IPv6, as we do not have the money to buy 
more V4.  We would rather use our v4 inventory for access customers.


Yes, it is just a few pieces of information for SWIP.  However, we do not 
have clerical staff to do it, because except for the SSL colocates, there 
never has been v4 SWIP's required here. Why should the policy state that 
just because we give each customer an assignment of v6, we must SWIP that 
same small customer that did not require SWIP in v4? (Welcome to IPv6, now 
fill out this form.) Also noted is that the SWIP registration details 
without written permission might get us in trouble with the FCC over CPNI. 
As a WISP that has licensed microwave links, we do pay attention to Uncle 
Charlie.


Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Thu, 20 Jul 2017, Chris James wrote:


@Paul - The API key is to email it.

@Owen - Very difficult when you have dynamic ranges, and vps/container
platforms spanning tens of thousands of instances across these dynamic
ranges.


On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary  wrote:


Owen

The reassignment policy page says IPv6 has to be done vi API.
Is that something else that is incorrect on the web site?

Paul


On 7/20/2017 3:16 PM, Owen DeLong wrote:


How can it be overly difficult to fill out an email template with your
customers???
Name, Address, Phone Number?

Really?

Owen

On Jul 19, 2017, at 23:48 , Pallieter Koopmans 

wrote:

Hello,

ARIN could quantify and require rules for when to SWIP, but in the
end, there are going to be exceptions needed if the rules are to be
strictly followed. Many will not separately SWIP a separately routed
sub-block if it is too difficult or pointless to gather and share that
data back upstream to ARIN.

Thus a more fuzzy rule to require a best-effort and to add a
rule-based reason (preferably both a carrot and a stick) for block
owners to do their best to provide (only) useful data. In order to do
that, one needs to look back at why that data is needed. For a block
owner to assign the SWIP on a sub-block, he basically delegates tech
and abuse contact requests down to those that are probably more likely
to be able to actually act on the tech/abuse requests (and thus reduce
request-handling workload higher up and overall). But for that to
work, those tech/abuse contact requests need to be actually handled,
otherwise, it is better to leave them with the block owner.

In the end, the contact details should be as close to the "person"
that is actually capable to both handle (think: volume/languages/etc)
and act (think: authority) on the tech/abuse requests.

eBrain
Innovative Internet Ideas

Pallieter Koopmans
Managing Director

+31-6-3400-3800 (mon-sat 9-22 CET)
Skype: PallieterKoopmans
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.


--
This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. This company is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any 

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

[Paul McNary]

Owen

The reassignment policy page says IPv6 has to be done vi API.
Is that something else that is incorrect on the web site?

Paul


On 7/20/2017 3:16 PM, Owen DeLong wrote:

How can it be overly difficult to fill out an email template with your 
customers’
Name, Address, Phone Number?

Really?

Owen


On Jul 19, 2017, at 23:48 , Pallieter Koopmans  wrote:

Hello,

ARIN could quantify and require rules for when to SWIP, but in the
end, there are going to be exceptions needed if the rules are to be
strictly followed. Many will not separately SWIP a separately routed
sub-block if it is too difficult or pointless to gather and share that
data back upstream to ARIN.

Thus a more fuzzy rule to require a best-effort and to add a
rule-based reason (preferably both a carrot and a stick) for block
owners to do their best to provide (only) useful data. In order to do
that, one needs to look back at why that data is needed. For a block
owner to assign the SWIP on a sub-block, he basically delegates tech
and abuse contact requests down to those that are probably more likely
to be able to actually act on the tech/abuse requests (and thus reduce
request-handling workload higher up and overall). But for that to
work, those tech/abuse contact requests need to be actually handled,
otherwise, it is better to leave them with the block owner.

In the end, the contact details should be as close to the "person"
that is actually capable to both handle (think: volume/languages/etc)
and act (think: authority) on the tech/abuse requests.

eBrain
Innovative Internet Ideas

Pallieter Koopmans
Managing Director

+31-6-3400-3800 (mon-sat 9-22 CET)
Skype: PallieterKoopmans
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Joe Provo]

Hey David,

On Mon, Jul 17, 2017 at 01:54:08PM -0400, David R Huberman wrote:
> Hello Joe,
> 
> Thanks for the reply. A reminder that I'm *asking* a genuine question. 

Sure, and I was supplying my genuine response. My personal hat is still 
firmly on my head, fwiw.

> Now, I wrote:
> 
> >> Whois reassignments are not the proper place for the information LE 
> >> wants, in my opinion, and has almost no value to NOCs.
> 
> Joe replied:
> 
> > I find this assertion at odds with both my experience and direct
> > inquiries to those in the anti-abuse community.  Upon what basis
> > is it made?

Nit - I should have trimmed LE because my scope in response was 
regarding the NOC comment. I work in the operational realm, not legal
interface.

> So a few things.
> 
> 1) I specifically said 'reassignments', and by that I meant end-user data. 
> I have always been in favor of 'reallocations' (to downstream ISPs) being 
> in Whois.

I find both to be of value in the data gathering phase of investigating 
anamolies, dealing with incidents, and so on. Frankly, most all data
sources are noisy and therefore multiple sources of medium confidence
are better than attempting to pin high confidence to fewer sources.

> 2) The *vast* majority (and we're talking 99%+ -- I've studied the data 
> many times) of end-user SWIP data is things like:
> 
> AT Internet Services SBCIS-SIS80-1005 (NET-69-0-0-0-1) 69.0.0.0 - 
> 69.0.127.255
> THE MEDICINE SHOPPE SBC0690030204 (NET-69-0-0-0-2) 69.0.0.0 - 
> 69.0.0.7
> 
> When you lookup the specific /29, you get:
> 
> CustName:   THE MEDICINE SHOPPE
> Address:310 ORANGE ST
> City:   NEW HAVEN
> StateProv:  CT
> PostalCode: 06510
> Country:US
> 
> ... with vanilla AT*T contact information from the parent /17.
> 
> Yes: I assert this data has no value to NOCs or general internetworking 
> operations, in my experience, and I wrote that I do not believe this is 
> the proper place for LE to be gleaning it's info. (That's a whole other 
> conversation, but it's my opinion here.)
> 
> I don't understand how this SWIP data provides value in terms of 
> transparency?  It is, as others have noted, just giving out customer lists 
> -- information which is typically considered confidential.  ARIN policy 
> *can* require this information, but *should* it?

Even if the published *contact* data is incorrect, it is a trivial step
to get contact data for the reassigned entity which is published via 
other vectors. Your straw-man provides me the info to contact the user 
of the designated resources directly ["Hi, you are owned"] rather than 
contact an entity with which I have no association. There are a vast 
number of organizations across the globe who will not accept external 
reports or contacts regardless of impact. If you aren't a customer or 
have subpeona power, you don't exist as they are optimized around call 
metrics.  Avoiding them is a win, and even if the direct contact ends 
up being fruitless, the attempt can be made (and documented for evidence 
if need be).

> Additing to this conversation, two other items:
> 
> 3) Since 2004, when Dave Barger first got up to a microphone at an ARIN 
> meeting (Reston) and admitted that his company's SWIPs were non-compliant 
> because of software issues, we've had huge swaths of SWIP data that is 
> just wrong.  It's very difficult (especially at scale) to both publish and 
> maintain accurate SWIP data.  There's a real cost to requiring accurate 
> SWIP data for providers -- large and small.  If we're going to put this 
> cost on them for IPv6, I'd really like us to have a solid justification 
> that's relevant to 2017 network operations, and not based on what was true 
> in 1999.

Sadly those we can't rely upon for accurate SWIP data also couldn't be 
trusted for accurate rWHOIS data. I'd be interested in hearing other 
distributed options, and suspect there's an answer involving blockchain 
buried in there but I'm just not clever enough to unearth it.  If as a 
community we still value being able to get things done without involving 
legal action then providing an reasonable accounting of how an organization
is using the community's resources (and let's make no mistake - that is 
what the concensus pool of addressing *is*) is simply the cost of doing 
business. If recouping the cost of data publication and upkeep isn't 
built into their product or customer relations then they probably have
a broken business plan. 
 
> 4) And finally, we go back to an early convversation point that as 
> presently drafted, this policy idea (required SWIPs for IPv6) is not 
> enforceable by ARIN.  In a world where you generally do not go back to the 
> RIR for additional IPv6 prefixes, ARIN has no enforcement tools in the 
> policy -- and the one's they could have that I can envisage, I don't 
> support.

I see this to be a fundamental failing of our region's fragmented 
model.  We dither over things which are non-problems in 

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

[Paul McNary]

Yes

/48 is the SWIP boundary. /48 is SWIP'ed.
/49 is not.

Paul


On 7/20/2017 3:07 PM, Owen DeLong wrote:

My recommendation was “shorter than /48” which would essentially mean the same 
thing.

Owen


On Jul 17, 2017, at 15:46 , hostmas...@uneedus.com wrote:

The language of "b)" actually makes more sense with a /47:

Each static IPv6 assignment containing a /47 or more addresses, or 
subdelegation of any size that will be individually announced, shall be 
registered in the WHOIS directory via SWIP or a distributed service which meets 
the standards set forth in section 3.2.

The major difference is that this language eliminates the SWIP requirement for 
/48 blocks that are not announced, but all larger blocks require SWIP, and 
blocks smaller than /48 are also exempt and of course also non-routeable.

This is best for those that think SWIP should be limited to only blocks that 
are individually announced.  I could go either way on this issue.

Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Mon, 17 Jul 2017, Leif Sawyer wrote:


Shepherd of the draft policy chiming in.

Thanks for the lively discussion, everybody.   There's certainly a lot to think 
about here.

Just as a reminder to folk, the current policy under question is located here:
https://www.arin.net/policy/nrpm.html#six551

And, to help clarify some confusion, per  6.5.5.3.1  
(https://www.arin.net/policy/nrpm.html#six5531)
residential customers "holding/64 and larger blocks"   may use censored data,  i.e.  
"Private Customer/Residence"
in lieu of actual names and street addresses.

--

With that said,  I have a couple of questions to ask, based on potential 
rewrites that are brewing.

First:Assuming a preference for /56  (based on PPML feedback)  for the 
moment,   which is the more
preferential rewrite of the opening sentence of 6.5.5.1?


a)  Each static IPv6 assignment containing a /55 or more addresses shall be 
registered in the WHOIS directory via SWIP or a distributed service which meets 
the standards set forth in section 3.2.



b)  Each static IPv6 assignment containing a /55 or more addresses, or 
subdelegation of any size that will be individually announced, shall be 
registered in the WHOIS directory via SWIP or a distributed service which meets 
the standards set forth in section 3.2.


Second:   Given your specific choice of A or B,  are you preferentially inclined to 
choose the provided bit-boundary, or "/48"

Third:  If none of these options are palatable, do you have a proposed approach?



Thanks,

Leif Sawyer
Advisory Council



___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Paul McNary]

Owen

I agree 100% with your statement below!
Longer than a /48. That would eliminate any
concerns I have. /48's could be assigned to each POP
giving basic location information for any downstream.
That is similar to BCP of a /24 for IPv4. If a downstream
business request SWIP that we can accommodate.

Take care
Paul


On 7/20/2017 3:06 PM, Owen DeLong wrote:
This makes the best case I can imagine for why setting the boundary at 
/56 is a bad idea and we should not be considering anything longer 
than /48.


Owen

On Jul 17, 2017, at 15:40 , Paul McNary > wrote:


Leif
If I understand your question:

Originally /48 to anyone was the BCP for future efficiency.
I can change my BCP to /56.
/48 is my preference, however, which is the BGP boundary.
Otherwise I have little issue with choice "b" if forced.

I would prefer to give my residential users a /48 for the future but 
a /56

could work, just a pain. Again rDNS could be a problem.

Do AS's use ARIN reverse DNS for size smaller than /48?
If rDNS will not work worldwide except with /48 advertising,
I think that should be the SWIP boundary.
I know for a while some AS's required /32.
I think that has finally changed.
However ARIN's assignment web page indicates we should be
SWIP'ing /29's on IPv4 by policy or risk ARIN action.

Thank you
Paul McNary
pmcn...@cameron.net


On 7/17/2017 5:09 PM, Leif Sawyer wrote:

Shepherd of the draft policy chiming in.
Thanks for the lively discussion, everybody.   There's certainly a 
lot to think about here.
Just as a reminder to folk, the current policy under question is 
located here:

https://www.arin.net/policy/nrpm.html#six551
And, to help clarify some confusion, per  6.5.5.3.1  
(https://www.arin.net/policy/nrpm.html#six5531)
residential customers "holding/64 and larger blocks"   may use 
censored data,  i.e.  "Private Customer/Residence"

in lieu of actual names and street addresses.
--
With that said,  I have a couple of questions to ask, based on 
potential rewrites that are brewing.
First: Assuming a preference for /56  (based on PPML feedback)  for 
the moment,   which is the more

preferential rewrite of the opening sentence of 6.5.5.1?
a)Each static IPv6 assignment containing a /55 or more addresses 
shall be registered in the WHOIS directory via SWIP or a distributed 
service which meets the standards set forth in section 3.2.



b)Each static IPv6 assignment containing a /55 or more addresses,or 
subdelegation of any size that will be individually announced, shall 
be registered in the WHOIS directory via SWIP or a distributed 
service which meets the standards set forth in section 3.2.
Second: Given your specific choice of A or B,  are you 
preferentially inclined to choose the provided bit-boundary, or "/48"
Third: If none of these options are palatable, do you have a 
proposed approach?

Thanks,
Leif Sawyer
Advisory Council


___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contacti...@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@arin.net 
).

Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contacti...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Owen DeLong]

How can it be overly difficult to fill out an email template with your 
customers’
Name, Address, Phone Number?

Really?

Owen

> On Jul 19, 2017, at 23:48 , Pallieter Koopmans  
> wrote:
> 
> Hello,
> 
> ARIN could quantify and require rules for when to SWIP, but in the
> end, there are going to be exceptions needed if the rules are to be
> strictly followed. Many will not separately SWIP a separately routed
> sub-block if it is too difficult or pointless to gather and share that
> data back upstream to ARIN.
> 
> Thus a more fuzzy rule to require a best-effort and to add a
> rule-based reason (preferably both a carrot and a stick) for block
> owners to do their best to provide (only) useful data. In order to do
> that, one needs to look back at why that data is needed. For a block
> owner to assign the SWIP on a sub-block, he basically delegates tech
> and abuse contact requests down to those that are probably more likely
> to be able to actually act on the tech/abuse requests (and thus reduce
> request-handling workload higher up and overall). But for that to
> work, those tech/abuse contact requests need to be actually handled,
> otherwise, it is better to leave them with the block owner.
> 
> In the end, the contact details should be as close to the "person"
> that is actually capable to both handle (think: volume/languages/etc)
> and act (think: authority) on the tech/abuse requests.
> 
> eBrain
> Innovative Internet Ideas
> 
> Pallieter Koopmans
> Managing Director
> 
> +31-6-3400-3800 (mon-sat 9-22 CET)
> Skype: PallieterKoopmans
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Owen DeLong]

My recommendation was “shorter than /48” which would essentially mean the same 
thing.

Owen

> On Jul 17, 2017, at 15:46 , hostmas...@uneedus.com wrote:
> 
> The language of "b)" actually makes more sense with a /47:
> 
> Each static IPv6 assignment containing a /47 or more addresses, or 
> subdelegation of any size that will be individually announced, shall be 
> registered in the WHOIS directory via SWIP or a distributed service which 
> meets the standards set forth in section 3.2.
> 
> The major difference is that this language eliminates the SWIP requirement 
> for /48 blocks that are not announced, but all larger blocks require SWIP, 
> and blocks smaller than /48 are also exempt and of course also non-routeable.
> 
> This is best for those that think SWIP should be limited to only blocks that 
> are individually announced.  I could go either way on this issue.
> 
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
> 
> On Mon, 17 Jul 2017, Leif Sawyer wrote:
> 
>> Shepherd of the draft policy chiming in.
>> 
>> Thanks for the lively discussion, everybody.   There's certainly a lot to 
>> think about here.
>> 
>> Just as a reminder to folk, the current policy under question is located 
>> here:
>> https://www.arin.net/policy/nrpm.html#six551
>> 
>> And, to help clarify some confusion, per  6.5.5.3.1  
>> (https://www.arin.net/policy/nrpm.html#six5531)
>> residential customers "holding/64 and larger blocks"   may use censored 
>> data,  i.e.  "Private Customer/Residence"
>> in lieu of actual names and street addresses.
>> 
>> --
>> 
>> With that said,  I have a couple of questions to ask, based on potential 
>> rewrites that are brewing.
>> 
>> First:Assuming a preference for /56  (based on PPML feedback)  for the 
>> moment,   which is the more
>> preferential rewrite of the opening sentence of 6.5.5.1?
>> 
>> 
>> a)  Each static IPv6 assignment containing a /55 or more addresses shall 
>> be registered in the WHOIS directory via SWIP or a distributed service which 
>> meets the standards set forth in section 3.2.
>> 
>> 
>> 
>> b)  Each static IPv6 assignment containing a /55 or more addresses, or 
>> subdelegation of any size that will be individually announced, shall be 
>> registered in the WHOIS directory via SWIP or a distributed service which 
>> meets the standards set forth in section 3.2.
>> 
>> 
>> Second:   Given your specific choice of A or B,  are you preferentially 
>> inclined to choose the provided bit-boundary, or "/48"
>> 
>> Third:  If none of these options are palatable, do you have a proposed 
>> approach?
>> 
>> 
>> 
>> Thanks,
>> 
>> Leif Sawyer
>> Advisory Council
>> 
>> 
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Owen DeLong]

This makes the best case I can imagine for why setting the boundary at /56 is a 
bad idea and we should not be considering anything longer than /48.

Owen

> On Jul 17, 2017, at 15:40 , Paul McNary  wrote:
> 
> Leif
> If I understand your question:
> 
> Originally /48 to anyone was the BCP for future efficiency.
> I can change my BCP to /56.
> /48 is my preference, however, which is the BGP boundary.
> Otherwise I have little issue with choice "b" if forced.
> 
> I would prefer to give my residential users a /48 for the future but a /56
> could work, just a pain. Again rDNS could be a problem.
> 
> Do AS's use ARIN reverse DNS for size smaller than /48?
> If rDNS will not work worldwide except with /48 advertising, 
> I think that should be the SWIP boundary.
> I know for a while some AS's required /32.
> I think that has finally changed.
> However ARIN's assignment web page indicates we should be 
> SWIP'ing /29's on IPv4 by policy or risk ARIN action.
> 
> Thank you
> Paul McNary
> pmcn...@cameron.net 
> 
> On 7/17/2017 5:09 PM, Leif Sawyer wrote:
>> Shepherd of the draft policy chiming in.
>>  
>> Thanks for the lively discussion, everybody.   There's certainly a lot to 
>> think about here.
>>  
>> Just as a reminder to folk, the current policy under question is located 
>> here:
>> https://www.arin.net/policy/nrpm.html#six551 
>> 
>>  
>> And, to help clarify some confusion, per  6.5.5.3.1  
>> (https://www.arin.net/policy/nrpm.html#six5531 
>> )
>> residential customers "holding/64 and larger blocks"   may use censored 
>> data,  i.e.  "Private Customer/Residence"
>> in lieu of actual names and street addresses.
>>  
>> --
>>  
>> With that said,  I have a couple of questions to ask, based on potential 
>> rewrites that are brewing.
>>  
>> First:Assuming a preference for /56  (based on PPML feedback)  for the 
>> moment,   which is the more
>> preferential rewrite of the opening sentence of 6.5.5.1?
>>  
>> a)  Each static IPv6 assignment containing a /55 or more addresses shall 
>> be registered in the WHOIS directory via SWIP or a distributed service which 
>> meets the standards set forth in section 3.2. 
>> 
>> 
>> b)  Each static IPv6 assignment containing a /55 or more addresses, or 
>> subdelegation of any size that will be individually announced, shall be 
>> registered in the WHOIS directory via SWIP or a distributed service which 
>> meets the standards set forth in section 3.2. 
>>  
>>  
>> Second:   Given your specific choice of A or B,  are you preferentially 
>> inclined to choose the provided bit-boundary, or "/48"
>>  
>> Third:  If none of these options are palatable, do you have a proposed 
>> approach?
>>  
>>  
>>  
>> Thanks,
>>  
>>   Leif Sawyer
>> Advisory Council
>>  
>> 
>> 
>> ___
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net 
>> ).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml 
>> 
>> Please contact i...@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@arin.net 
> ).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml 
> 
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Owen DeLong]

+1… Well said, Joe.

Owen

> On Jul 17, 2017, at 10:34 , Joe Provo  wrote:
> 
> 
> 
> On Mon, Jul 17, 2017 at 01:08:49PM -0400, David Huberman wrote:
>> In addition to these options/questions, I feel like we glossed
>> over the question posed by Marty Hannigan: what is the value of
>> REQUIRING SWIP anymore?  As a community member (not as an AC member)
>> I have trouble supporting any of these as I'm not sure I support
>> SWIP being anything other than voluntary.  Whois reassignments are
>> not the proper place for the information LE wants, in my opinion,
>> and has almost no value to NOCs.  
> 
> I find this assertion at odds with both my experience and direct 
> inquiries to those in the anti-abuse community.  Upon what basis
> is it made?
> 
>> And ARIN doesn't need it anymore
>> for qualification purposes for a scarce resource.  So what's he
>> point of all this?  Genuine question; no tone implied.
> 
> As a community, we (used to?) value accountability and transparency.
> Having a direct contact associated with a resource has IME always 
> worked better than trying to contact a porvider with whom I have no
> business relationship. 
> 
> [snip]
>>> On Jul 17, 2017, at 12:13 PM, Jason Schiller  wrote:
>>> 
>>> I am replying to bring the conversation to one of the suggestions 
>>> on the table.
>>> 
>>> Owen DeLong's suggesting of SWIP all IPv6 business users, and 
>>> not Residential users,
>>> 
>>> Or Kevin Blumberg (and David Farmer) suggestion of SWIP'ing all 
>>> prefixes that might show up as a more specific in the global routing 
>>> table.
>>> 
>>> 
>>> These are roughly the same result, and have a question of which
>>> has a more easily understandable policy.  
>>> 
>>> The question is who here supports one or both of these 
>>> proposals?
>>> 
>>> Who oppose one (if so which one) or both of these proposals?
> 
> Since my concern is associated with the resource usage, and we 
> in ARIN-land historically wash our hands of connectivity/reachability,
> as much as the second is appealing the former is more relevant and
> workable. I personally dislike the blanket exception embedded within 
> it, but know there's not going to be any upside to fighting that one
> so would rather take what I can get.
> 
>>> I would like to suggest one friendly amendment...  
>>> - ISPs are required to SWIP IP space that is a reallocation.  
>>> - ISPs are required to SWIP IP space that is a reassignment
>>>   whenever that down stream customer requests such.  That 
>>>   SWIP must be a reassign detail, reassign simple, or a 
>>>   residential privacy (if applicable) per the customer request.
>>> 
>>> ___Jason
> 
> I like the addition.
> 
> Cheers!
> 
> Joe
> 
> 
> 
> -- 
> Posted from my personal account - see X-Disclaimer header.
> Joe Provo / Gweep / Earthling 
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Owen DeLong]

I can accept any of the (now 3) proposals contained in this email.

Owen

> On Jul 17, 2017, at 09:13 , Jason Schiller  wrote:
> 
> I am replying to bring the conversation to one of the suggestions 
> on the table.
> 
> Owen DeLong's suggesting of SWIP all IPv6 business users, and 
> not Residential users,
> 
> Or Kevin Blumberg (and David Farmer) suggestion of SWIP'ing all 
> prefixes that might show up as a more specific in the global routing 
> table.
> 
> 
> These are roughly the same result, and have a question of which
> has a more easily understandable policy.  
> 
> The question is who here supports one or both of these 
> proposals?
> 
> Who oppose one (if so which one) or both of these proposals?
> 
> 
> I would like to suggest one friendly amendment...  
> - ISPs are required to SWIP IP space that is a reallocation.  
> - ISPs are required to SWIP IP space that is a reassignment
>whenever that down stream customer requests such.  That 
>SWIP must be a reassign detail, reassign simple, or a 
>residential privacy (if applicable) per the customer request.
> 
> ___Jason
> 
> 
> 
> On Mon, Jul 17, 2017 at 10:42 AM, John Curran  > wrote:
> On 17 Jul 2017, at 9:47 AM, hostmas...@uneedus.com 
>  wrote:
> > ,,,
> > This is the problem.  ARIN is not a carrier.  While disclosure to ARIN to 
> > obtain number resources for the connection is OK, Public disclosure by or 
> > at the direction of ARIN policy of elements like domain name, name, address 
> > and telephone number is not.  Since name, address, telephone number and 
> > domain name have already been identified have been defined in the order as 
> > elements of CPNI that are protected, world disclosure by ARIN or because of 
> > ARIN rules would not be a protected disclosure.
> >
> > The ISP might also be in trouble for providing the information to ARIN, if 
> > they know that ARIN intends to publish this information in a public 
> > directory, rather than disclosing it to ARIN solely to maintain number 
> > resources.  As suggested by the OP, might have to call them customer 1-n. 
> > However that would violate the NRPM as written.  Since the City, State and 
> > Zip Code are part of the address, even the "protected" residential records 
> > CPNI are being disclosed in violation of the CPNI Order.
> >
> > There is a big difference between disclosure to ARIN for taking care of 
> > numbering policy, and disclosure to the entire world.  Third party 
> > disclosure is the main thing that the CPNI rules are intended to address. 
> > That is only permitted when it is needed for the provision of service.
> 
> Compliance with registry policy is indeed necessary to receive number 
> resources;
> it is up to you to determine whether IP number resources are necessary for 
> provision
> of your Internet services.
> 
> If you choose not to make use of Internet Numbers Registry System resources 
> for
> provision of Internet services (or not assign them to your customers), then 
> that is
> your choice.   Some ISPs may feel that it is necessary to seek consent of 
> customers
> who wish to have public IP number resources assigned in the size that would 
> result in
> their publication in the public registry, whereas others may not based on 
> their reading
> of applicable regulations regarding handling of CPNI information.  Such 
> choices are
> an operational and business matter left to each ISP to decide based on their 
> individual
> understanding and circumstances.
> 
> Thanks!
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
> 
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net 
> ).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml 
> 
> Please contact i...@arin.net  if you experience any 
> issues.
> 
> 
> 
> -- 
> ___
> Jason Schiller|NetOps|jschil...@google.com 
> |571-266-0006
> 
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Pallieter Koopmans]

Hello,

ARIN could quantify and require rules for when to SWIP, but in the
end, there are going to be exceptions needed if the rules are to be
strictly followed. Many will not separately SWIP a separately routed
sub-block if it is too difficult or pointless to gather and share that
data back upstream to ARIN.

Thus a more fuzzy rule to require a best-effort and to add a
rule-based reason (preferably both a carrot and a stick) for block
owners to do their best to provide (only) useful data. In order to do
that, one needs to look back at why that data is needed. For a block
owner to assign the SWIP on a sub-block, he basically delegates tech
and abuse contact requests down to those that are probably more likely
to be able to actually act on the tech/abuse requests (and thus reduce
request-handling workload higher up and overall). But for that to
work, those tech/abuse contact requests need to be actually handled,
otherwise, it is better to leave them with the block owner.

In the end, the contact details should be as close to the "person"
that is actually capable to both handle (think: volume/languages/etc)
and act (think: authority) on the tech/abuse requests.

eBrain
Innovative Internet Ideas

Pallieter Koopmans
Managing Director

+31-6-3400-3800 (mon-sat 9-22 CET)
Skype: PallieterKoopmans
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[John Curran]

On 19 Jul 2017, at 4:36 PM, hostmas...@uneedus.com wrote:
> 
> While thinking about it John, there was some discussion over using the main 
> facility address in a single SWIP for an entire block that contained many 
> sites.  Is this allowed? 

Albert - 
 
   Alas, the only “advice” that I can provide will be based upon the adopted 
policy
   in the NRPM and accompanying policy discussion in PPML during the policy
   development process.

   As best as I can discern, the intent of the current policy is to provide 
that 
   address blocks of “significant" size which are reassigned will have accurate 
   technical and abuse contacts, while also respecting the need for residential 
   privacy in the case where the street address or postal code would be allow 
   for personal identification.
 
   To the extent that ISPs are attempting in good faith to follow the existing 
   policy regarding registration of reassignments, ARIN will consider such 
   efforts compliant. If the community wishes specific outcomes for particular 
   scenarios, then it will be necessary to provide additional policy language
   which covers those cases.

Thanks!
/John

John Curran
President and CEO
ARIN

___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Michael Peddemors]

On 17-07-17 10:54 AM, David R Huberman wrote:
AT Internet Services SBCIS-SIS80-1005 (NET-69-0-0-0-1) 69.0.0.0 - 
69.0.127.255
THE MEDICINE SHOPPE SBC0690030204 (NET-69-0-0-0-2) 69.0.0.0 - 
69.0.0.7


When you lookup the specific /29, you get:

CustName:   THE MEDICINE SHOPPE
Address:310 ORANGE ST
City:   NEW HAVEN
StateProv:  CT
PostalCode: 06510
Country:US


It depends, who do you want to be authorative for contact information on 
issues related to that network.


If ATT wants to deal with every issue related to every IP address in 
that /17, no need to do SWIP, however if you want the Medicine Shoppe to 
be be able to authoratively speak for the usage of that /29, you better 
give them SWIP/rwhois.


It also is a 'boundary' condition, eg can speak to the operations of the 
/29, but should not have to worry about activity from surrounding blocks..


Now, in terms of an ISP providing IP allocations to customers, it may 
not have to be SWIP'ed on the IP boundary, as for instance a /21 may ALL 
be dynamic IP Addresses for customers, which can be SWIP'ed as such, and 
the holder of the SWIP (poc) will be responsible for the combined 
behavior of the pool.


However, if a statically assigned IP to a business customer, it might 
want to be SWIP'ed so that the specific customer can set a 'boundary' on 
behavior, eg my IP is not like the rest around me, and I will be 
responsible for my IP's activity.


Aside from the concept's of SWIP helping 'justify' usage for resources, 
(and there is a slippery slope, if you don't care about justification 
for IPv6 but you do for IPv4 in terms of legal contests), the idea of 
setting a control boundary via SWIP and/or rwhois is a very important 
concept.


As such, I would suggest making this concept a basis for when SWIP 
'might' be used, but not enforced.. eg. SWIP should not be needed at any 
lower level than the boundary of responsibility.


An ISP could set that boundary for one household, or one business, IF 
that is the boundary of responsibility, and the household or business 
'chooses' to be the responsible party for that boundary, and in that 
case they should expect that their POC information be publicized.


It would be better if the concept of 'boundaries' be enshrined, instead 
of the actual number of IP (v6 or otherwise) or segments.. In some cases 
in the future it 'could' be a boundary be specified as low as a /56, but 
in reality, the segment would be different depending on the use case.


If you want to enshrine 'use cases' into the proposal, then you might 
come to agreement for a specific use case, when/how to SWIP it.


Also, remember, 'rwhois' is available at a lower granularity than SWIP 
might require as well..





--
"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 (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[John Curran]

On 19 Jul 2017, at 11:12 AM, Scott Leibrand  wrote:
> 
> As I understand it, if the ISP assigned you a /48 and individually routed the 
> /64s for you, they would only have to create a single SWIP entry for the /48, 
> and the street address of your central location (or your administrative HQ, 
> if different) would be perfectly appropriate for that SWIP. 

FYI - Present NRPM policy regarding residential privacy would provide for 
the reassignment to show the city, state, and postal code of the assignee
(omitting the street address) 

To the extent that one is aware of a detailed postal code which has a unique 
association with a single location, it is appropriate to use a less specific 
one 
to comply with the intent of the policy. 

Thanks,
/John

John Curran
President and CEO
ARIN

___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Scott Leibrand]

As I understand it, if the ISP assigned you a /48 and individually routed
the /64s for you, they would only have to create a single SWIP entry for
the /48, and the street address of your central location (or your
administrative HQ, if different) would be perfectly appropriate for that
SWIP.

I agree that eliminating the need to SWIP /64s and residential /56s would
be good, and still support the general idea of this proposal (and most of
the variations that have been proposed thus far). However, I think this use
case does highlight the need to make sure that we *do* consider requiring
SWIP of /48 aggregates like the one your ISP is assigning you, even if
they're routing the pieces of that aggregate independently to different
"sites".

-Scott

On Wed, Jul 12, 2017 at 1:20 AM,  wrote:

> I would like to give an example of why the current /64 or more rule for
> IPv6 SWIP vs IPv4 is an issue for a project I am working on:
>
> I am working on a project to enable public IPv6 on Public Transit busses.
> Currently we have a public V4 address assigned by the winner of a State
> Government Contract with a major wireless provider used for each bus in the
> fleet, which is in excess of 1000 busses.  Originally we used this
> connection only for administrative use, such as communicating the real time
> location of each bus back to headquarters and access to cameras and
> reporting in an emergency.  In the last few months, we added an additional
> RFC1918 IPv4 private address subnet so that a wireless access point for
> public wifi is available on each bus.  In order to address the
> administrative equipment from headquarters, we must have a static address
> to connect to.
>
> Because it is a State Government contract, the major wireless provider
> still has to provide us public, static IPv4 addresses until the end of this
> contract, which is Sept 30, 2018.  This major provider has publiclly
> announced that they will no longer provide Static IPv4 addresses to anyone,
> and we have been told they will not bid on the next contract if that
> contract would require an option to assign static v4 addresses like the
> current contract, as they are leasing the IPv4 addresses we are using. We
> have been told if we want Static assignments, they now must be only IPv6,
> and they will provide up to a /56 for each bus out of a /48 of their space
> assigned to all our busses.
>
> Thus, there is a plan to put the administrative parts of the busses onto
> IPv6 before the end of the contract. We wont care if the carrier v4 address
> is static, public, or even CGnat, as it would then only be only used for
> the public v4 wifi.  We might also consider a PI v6 allocation from ARIN if
> they will route it to us.  This would keep us from having to renumber if
> the State Contract provider changes, and a /48 of space would be plenty for
> all v6 use.
>
> Here is the SWIP issue:
>
> The major provider according to the current rules must SWIP each static
> "Serving site"(NRPM 2.14), which in this case is a transit bus.  Each bus
> is its own account with the wireless provider, and will have its own static
> IPv6 network and IPv4 address assigned.
>
> NRPM 2.12 requires each SWIP entry must contain Street Address, City,
> State, and Zip Code.  How can I give a Street Address for a mobile serving
> site as required by NPRM 2.12?  Each bus covers 200-300 miles a day, and
> about 1/2 do not return to our central location during any portion of their
> daily trips. I am sure that the abuse address for the SWIP will attract
> attention because of public wifi on each bus, and our intent to enable v6
> connections on each "Serving Site" (Transit Bus) including the public wifi.
>
> If the current proposal at more than a /60, or a greater amount such as
> more than a /56 is adopted, the wireless provider no longer has to SWIP
> each site (Transit Bus) just like v4. This would allow us to avoid having
> to SWIP each "Serving Site" as the current IPv6 rules would require and
> keep us legal with the policy manual.
>
> If the community comes out against relaxing the IPv6 SWIP rules, my only
> other choices are to hope the wireless provider will ignore the NRPM, or
> write another proposal to add language to 2.12 to allow mobile "Serving
> Sites" to be registered to a central location to avoid the street address
> and city problem with mobile "Serving Sites".  The wireless provider is
> unlikely to allow all the busses to be SWIP'ed to the Central site because
> they would be the one trying to explain to ARIN why 1000 networks are all
> registered at the same location.
>
> This was never an issue with IPv4, as each bus has only one IPv4 address,
> which did not trigger any SWIP requirement.  This example also shows how
> the different treatment of v4 and v6 affects small users of v6.
>
> I Would love to hear some input as to the issue of dealing with "Serving
> Sites" that are mobile (like Transit Busses), or do not have a street
> 

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

[joel jaeggli]

On 7/18/17 22:23, Owen DeLong wrote:
> 
>> On Jul 17, 2017, at 16:36 , John Curran  wrote:

>>> What I would like to know is my gut feeling correct, which is that after 
>>> receiving an allocation of IPv6, nearly nobody ever returns to the well for 
>>> more, or at least not like it was back in the IPv4 days when ARIN had IPv4 
>>> address space to allocate, and thus there are no sticks?
> 
> Your gut is definitely correct to date. However, prior performance does not 
> predict future results. It’s true that a lot fewer>organizations are likely 
> to come back for additional IPv6 blocks and
all will certainly come back less frequently than in IPv4.>Nearly nobody
is probably true today. It will probably remain less than “most” for the
foreseeable future, but I don’t think >“nearly nobody” is a permanent state.

A fair number of initial allocations were way too small. e.g. pre 2004
LIR/ISP assignments.

Failure of imagination seems like a common trope for direct/ciritical
assignments which makes returning to the well inevitable.



signature.asc
Description: OpenPGP digital signature
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Brian Jones]

On Tue, Jul 18, 2017 at 4:24 PM Owen DeLong  wrote:

>
> > On Jul 17, 2017, at 16:36 , John Curran  wrote:
> >
> > Albert -
> >
> >  We’ll research into these questions and report back shortly.
> >
> > Thanks!
> > /John
> >
> >> On 17 Jul 2017, at 2:53 PM, hostmas...@uneedus.com wrote:
> >>
> >> Just a couple of questions regarding the carrots and the sticks for the
> ARIN staff:
> >>
> >> Other than those who came back to change their initial /35 to a /32,
> how many ARIN customers have come back for another allocation of IPv6 space
> because they used the first one to the extent the rules require, which I
> think is 75% of /48 block assignments.
>
> Not many…. Yet. I know a few years ago, I filed the first such application
> (or at least so said RSHD at the time) on behalf of my employer at the time
> (HE) which requested (and received) a subsequent /24 to augment their
> existing /32 which was, in fact, more than 75% utilized.
>
> >> And, how many customers have received a first allocation of IPv6?
> >>
> >> Divide, and I can find out what percentage came back for more.
>
> The problem with this theory is that IPv6 is just getting started and the
> vast majority of ARIN customers that have received an initial IPv6
> allocation or assignment haven’t yet achieved full IPv6 deployment even to
> the point of parity with their IPv4 deployment. As such, measurements to
> date will be badly skewed to the low side of future reality.
>
+1
Even heavy users of IPv6 for years such as my organization are just now
realizing that we wished we had opted for for a /27 instead of a /32 now.
Even though we are mostly dual stacked everywhere we are just now seeing
the potential of being able to allocate IPv6 addressing in a more
meaningful way, and with all the research taking place with robots, drones,
driverless vehicles, bio-engineering, aerospace, etc… etc… we really may
have to go back to the well.


> >> What I would like to know is my gut feeling correct, which is that
> after receiving an allocation of IPv6, nearly nobody ever returns to the
> well for more, or at least not like it was back in the IPv4 days when ARIN
> had IPv4 address space to allocate, and thus there are no sticks?
>
> Your gut is definitely correct to date. However, prior performance does
> not predict future results. It’s true that a lot fewer organizations are
> likely to come back for additional IPv6 blocks and all will certainly come
> back less frequently than in IPv4. Nearly nobody is probably true today. It
> will probably remain less than “most” for the foreseeable future, but I
> don’t think “nearly nobody” is a permanent state.
>
> >> Another bit of info I would like to know if possible:  what percentage
> of customers with a v6 allocation has actually put any of their assignments
> into SWIP?  Since the current policy for SWIP in IPv6 is /64 or more, every
> allocation should be there.
>
>
We do have our IPv6 assignment in SWIP, not sure what percentage of folks
do, but it is useful information.


> Again, this isn’t necessarily going to yield accurate results. Many
> providers use RWHOIS as an alternative to SWIP. Many end users receive a
> /48 and it is directly registered by ARIN, so nothing to SWIP. There are
> also other situations (dynamic assignments, etc.) that are legitimately
> unlikely to result in SWIP.
>
> >> The answers are useful to determine as far as the documenting the
> assignment for ARIN, how useful SWIP is for that purpose.
> >>
> >> I have a /48 from 2 upstreams.  Only one is registered.  The other ISP
> does not appear to have ANY SWIP entries, even though I have set up the
> network with static v6 for at least a dozen customers, each of which
> received a /48.
>
> If that is the case, then that ISP is, indeed, in violation of ARIN policy
> and a fraud/abuse report to ARIN would not be out of order.
>
> >> Another "proxy" for to consider in deciding to SWIP or not might be the
> delegation of the reverse DNS for the allocated block. If there is a
> delegation, this is another way to find the technical contact other than
> SWIP if there is a problem.
>
> Not really reliable. In reality, there’s only one POC in the SOA and most
> providers in my experience populate that POC entry with meaningless
> unusable addresses.
>
> Owen
>
> >>
> >> Albert Erdmann
> >> Network Administrator
> >> Paradise On Line Inc.
> >>
> >>
> >> On Mon, 17 Jul 2017, David Farmer wrote:
> >>
> >>> On Mon, Jul 17, 2017 at 2:11 PM, David R Huberman 
> wrote:
> >>>
> 
>  Can you define voluntary?
> >
> > Is the voluntary choice to record a reassignment
> > up to the USP?
> >
> > Or does the choice belong to the end-user?
> >
> 
>  I think that's a business decision the two parties make together. I
> think
>  an ISP can choose to SWIP whatever it wants, and should do so with the
>  consent of the end-user. I think an end-user should be able 

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

[hostmas...@uneedus.com]

It looks to me like as far as using SWIP as a tool to track IPv6 
assignments so that we know if they have reached the 75% mark to ask for 
more, this is not happening.  As reported, NOONE has come back to ARIN at 
this time for more IPv6 space because they have exhausted their initital 
allocation.  Thus, the need to have SWIP in IPv6 for this purpose is zero. 
Since noone is coming back for more v6, looks like that stick for doing 
SWIP is not there.


As far as recording IPv6 assignments in SWIP, it looks like that only 8.5% 
have recorded any assignments at all to date.  Even though the current 
policy for the past 6 years says /64 or more, effectively 100% 
registration required, it does not look like it is being done.


Since there is only 8.5% of the total with ANY amount of IPv6 recorded in 
SWIP, maybe this is the right time to propose that IPv6 SWIP requirements 
be eliminated in total.  As far as policy proposals go, this would be done 
with the following language:


Strike from the NRPM the following sections: 6.5.5.1, 6.5.5.2, 6.5.5.3, 
and 6.5.5.3.1.


It does not in fact appear that IPv6 SWIP has ever been used to document 
for ARIN the need for future assignments, nor does the 8.5% of the 
reassignment records make that much difference to people using SWIP for 
other reasons.  In fact, the community appears to ignored the current SWIP 
requirement that has been policy for quite a while.


This language is the way to go if we want to get rid of SWIP for IPv6. 
Otherwise, if this is not acceptable, I still suggest option "b)" from 
yesterday, with the size of "/47".


Albert Erdmann
Network Administrator
Paradise On Line Inc.



On Tue, 18 Jul 2017, John Curran wrote:


Albert -

As requested –

As far as ARIN staff can ascertain, no ISP/LIR has yet qualified for an 
additional allocation
based on having used enough of their existing allocation to qualify for more.   
There have
been some additional allocations under other circumstance, e.g.

-  Multiple Discrete Networks (I have a /32, I’m opening a second 
autonomous site, I need more)
-  “Do-over” (I got a /32, I did my addressing plan, I now realize I 
need a /28)
-  Downstream ISP customers (I have a /32, I have a downstream ISP 
customer,
  therefore I need additional space so I can assign them a /32)

Regarding reassignments:  there are 3,346 IPv6 direct allocations. Of those, 
283 (8.5%) have one
or more reassignments.  For comparison, there are 20,217 IPv4 direct 
allocations. Of those, 10,230
(50.7%) have one or more reassignments.

May you find this information useful in your policy development efforts!
/John

John Curran
President and CEO
ARIN



___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[John Curran]

Albert - 
 
  We’ll research into these questions and report back shortly.

Thanks!
/John

> On 17 Jul 2017, at 2:53 PM, hostmas...@uneedus.com wrote:
> 
> Just a couple of questions regarding the carrots and the sticks for the ARIN 
> staff:
> 
> Other than those who came back to change their initial /35 to a /32, how many 
> ARIN customers have come back for another allocation of IPv6 space because 
> they used the first one to the extent the rules require, which I think is 75% 
> of /48 block assignments.
> 
> And, how many customers have received a first allocation of IPv6?
> 
> Divide, and I can find out what percentage came back for more.
> 
> What I would like to know is my gut feeling correct, which is that after 
> receiving an allocation of IPv6, nearly nobody ever returns to the well for 
> more, or at least not like it was back in the IPv4 days when ARIN had IPv4 
> address space to allocate, and thus there are no sticks?
> 
> Another bit of info I would like to know if possible:  what percentage of 
> customers with a v6 allocation has actually put any of their assignments into 
> SWIP?  Since the current policy for SWIP in IPv6 is /64 or more, every 
> allocation should be there.
> 
> The answers are useful to determine as far as the documenting the assignment 
> for ARIN, how useful SWIP is for that purpose.
> 
> I have a /48 from 2 upstreams.  Only one is registered.  The other ISP does 
> not appear to have ANY SWIP entries, even though I have set up the network 
> with static v6 for at least a dozen customers, each of which received a /48.
> 
> Another "proxy" for to consider in deciding to SWIP or not might be the 
> delegation of the reverse DNS for the allocated block. If there is a 
> delegation, this is another way to find the technical contact other than SWIP 
> if there is a problem.
> 
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
> 
> 
> On Mon, 17 Jul 2017, David Farmer wrote:
> 
>> On Mon, Jul 17, 2017 at 2:11 PM, David R Huberman  wrote:
>> 
>>> 
>>> Can you define voluntary?
 
 Is the voluntary choice to record a reassignment
 up to the USP?
 
 Or does the choice belong to the end-user?
 
>>> 
>>> I think that's a business decision the two parties make together. I think
>>> an ISP can choose to SWIP whatever it wants, and should do so with the
>>> consent of the end-user. I think an end-user should be able to demand a
>>> SWIP entry, and the ISP should generally comply.
>>> 
>> 
>> And if the ISP doesn't comply with the user's demand, can one of their
>> recourses be to appeal to ARIN?  Obviously, in a healthy market another,
>> and maybe more effective, option is to get another ISP.  However, not all
>> markets are healthy and too frequently users have only one realistic option
>> for an ISP, especially in rural areas.
>> 
>> I think it is important that if a user requests a SWIP from an ISP, and
>> they not given the SWIP, this should be at very least a technical violation
>> of ARIN policy.  Is ARIN going to revoke an ISP's address space because of
>> a single complaint from a user in this regard, of course not, but I would
>> expect ARIN to intercede with an ISP on behalf of the user.  However, if
>> there are repeated issues, especially large numbers of them, and if there
>> are other policy violations too, then I would expect harsher actions by
>> ARIN eventually.
>> 
>> Thanks
>> 
>> -- 
>> ===
>> David Farmer   Email:far...@umn.edu
>> Networking & Telecommunication Services
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SEPhone: 612-626-0815
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>> ===
>> 
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[William Herrin]

On Mon, Jul 17, 2017 at 7:02 PM, William Herrin  wrote:

> On Mon, Jul 17, 2017 at 6:40 PM, Paul McNary  wrote:
>
>> I would prefer to give my residential users a /48 for the future but a /56
>>
> Hi Paul,
>
> This is acceptable under current ARIN policy and would remain so under
> variant of the policy currently under discussion.
>

Any variant. Trying to say "any variant" there. If you like the idea of
assigning /48s to your customers, the proposal on the table will not stop
you from doing so.

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[William Herrin]

On Mon, Jul 17, 2017 at 6:40 PM, Paul McNary  wrote:

> I would prefer to give my residential users a /48 for the future but a /56
>
Hi Paul,

This is acceptable under current ARIN policy and would remain so under
variant of the policy currently under discussion.


> could work, just a pain. Again rDNS could be a problem.
>
> Do AS's use ARIN reverse DNS for size smaller than /48?
> If rDNS will not work worldwide except with /48 advertising,
>
RDNS for IPv6 works best with allocations on nibble boundaries. /48, /52,
/56, /60, /64, etc. It's only fractionally more work on non-nibble
boundaries but not nearly as clean. Clean solutions are desirable.


> I think that should be the SWIP boundary.
> I know for a while some AS's required /32.
>
You may be confusing RDNS with BGP. For a while, a few Internet backbones
refused to accept and route BGP prefixes longer than (less than) a /32. The
last holdout gave up a couple years ago; standard practice is now /48. It's
unlikely to change to anything longer than a /48, ever.

IPv6 RDNS has always worked at any CIDR level and continues to work most
cleanly at any nibble boundary.

Regards,
Bill Herrin

-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Paul McNary]

+1
That is what I agree with.

However reading the ARIN reassignment web page they are showing
policy that /60 should be SWIP'ed on IPv6 and /29 on IPv4.

Thanks you
Paul


On 7/17/2017 5:46 PM, hostmas...@uneedus.com wrote:

The language of "b)" actually makes more sense with a /47:

Each static IPv6 assignment containing a /47 or more addresses, or 
subdelegation of any size that will be individually announced, shall 
be registered in the WHOIS directory via SWIP or a distributed service 
which meets the standards set forth in section 3.2.


The major difference is that this language eliminates the SWIP 
requirement for /48 blocks that are not announced, but all larger 
blocks require SWIP, and blocks smaller than /48 are also exempt and 
of course also non-routeable.


This is best for those that think SWIP should be limited to only 
blocks that are individually announced.  I could go either way on this 
issue.


Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Mon, 17 Jul 2017, Leif Sawyer wrote:


Shepherd of the draft policy chiming in.

Thanks for the lively discussion, everybody.   There's certainly a 
lot to think about here.


Just as a reminder to folk, the current policy under question is 
located here:

https://www.arin.net/policy/nrpm.html#six551

And, to help clarify some confusion, per  6.5.5.3.1 
(https://www.arin.net/policy/nrpm.html#six5531)
residential customers "holding/64 and larger blocks"   may use 
censored data,  i.e.  "Private Customer/Residence"

in lieu of actual names and street addresses.

--

With that said,  I have a couple of questions to ask, based on 
potential rewrites that are brewing.


First:Assuming a preference for /56  (based on PPML feedback)  
for the moment,   which is the more

preferential rewrite of the opening sentence of 6.5.5.1?


a)  Each static IPv6 assignment containing a /55 or more 
addresses shall be registered in the WHOIS directory via SWIP or a 
distributed service which meets the standards set forth in section 3.2.




b)  Each static IPv6 assignment containing a /55 or more 
addresses, or subdelegation of any size that will be individually 
announced, shall be registered in the WHOIS directory via SWIP or a 
distributed service which meets the standards set forth in section 3.2.



Second:   Given your specific choice of A or B,  are you 
preferentially inclined to choose the provided bit-boundary, or "/48"


Third:  If none of these options are palatable, do you have a 
proposed approach?




Thanks,

 Leif Sawyer
Advisory Council



___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[hostmaster]

The language of "b)" actually makes more sense with a /47:

Each static IPv6 assignment containing a /47 or more addresses, or 
subdelegation of any size that will be individually announced, shall be 
registered in the WHOIS directory via SWIP or a distributed service which 
meets the standards set forth in section 3.2.


The major difference is that this language eliminates the SWIP requirement 
for /48 blocks that are not announced, but all larger blocks require SWIP, 
and blocks smaller than /48 are also exempt and of course 
also non-routeable.


This is best for those that think SWIP should be limited to only blocks 
that are individually announced.  I could go either way on this issue.


Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Mon, 17 Jul 2017, Leif Sawyer wrote:


Shepherd of the draft policy chiming in.

Thanks for the lively discussion, everybody.   There's certainly a lot to think 
about here.

Just as a reminder to folk, the current policy under question is located here:
https://www.arin.net/policy/nrpm.html#six551

And, to help clarify some confusion, per  6.5.5.3.1  
(https://www.arin.net/policy/nrpm.html#six5531)
residential customers "holding/64 and larger blocks"   may use censored data,  i.e.  
"Private Customer/Residence"
in lieu of actual names and street addresses.

--

With that said,  I have a couple of questions to ask, based on potential 
rewrites that are brewing.

First:Assuming a preference for /56  (based on PPML feedback)  for the 
moment,   which is the more
preferential rewrite of the opening sentence of 6.5.5.1?


a)  Each static IPv6 assignment containing a /55 or more addresses shall be 
registered in the WHOIS directory via SWIP or a distributed service which meets 
the standards set forth in section 3.2.



b)  Each static IPv6 assignment containing a /55 or more addresses, or 
subdelegation of any size that will be individually announced, shall be 
registered in the WHOIS directory via SWIP or a distributed service which meets 
the standards set forth in section 3.2.


Second:   Given your specific choice of A or B,  are you preferentially inclined to 
choose the provided bit-boundary, or "/48"

Third:  If none of these options are palatable, do you have a proposed approach?



Thanks,

 Leif Sawyer
Advisory Council



___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Paul McNary]

Leif
If I understand your question:

Originally /48 to anyone was the BCP for future efficiency.
I can change my BCP to /56.
/48 is my preference, however, which is the BGP boundary.
Otherwise I have little issue with choice "b" if forced.

I would prefer to give my residential users a /48 for the future but a /56
could work, just a pain. Again rDNS could be a problem.

Do AS's use ARIN reverse DNS for size smaller than /48?
If rDNS will not work worldwide except with /48 advertising,
I think that should be the SWIP boundary.
I know for a while some AS's required /32.
I think that has finally changed.
However ARIN's assignment web page indicates we should be
SWIP'ing /29's on IPv4 by policy or risk ARIN action.

Thank you
Paul McNary
pmcn...@cameron.net


On 7/17/2017 5:09 PM, Leif Sawyer wrote:


Shepherd of the draft policy chiming in.

Thanks for the lively discussion, everybody.   There's certainly a lot 
to think about here.


Just as a reminder to folk, the current policy under question is 
located here:


https://www.arin.net/policy/nrpm.html#six551

And, to help clarify some confusion, per  6.5.5.3.1  
(https://www.arin.net/policy/nrpm.html#six5531)


residential customers "holding/64 and larger blocks"   may use 
censored data,  i.e.  "Private Customer/Residence"


in lieu of actual names and street addresses.

--

With that said,  I have a couple of questions to ask, based on 
potential rewrites that are brewing.


First: Assuming a preference for /56  (based on PPML feedback)  for 
the moment,   which is the more


preferential rewrite of the opening sentence of 6.5.5.1?

a)Each static IPv6 assignment containing a /55 or more addresses shall 
be registered in the WHOIS directory via SWIP or a distributed service 
which meets the standards set forth in section 3.2.



b)Each static IPv6 assignment containing a /55 or more addresses, or 
subdelegation of any size that will be individually announced, shall 
be registered in the WHOIS directory via SWIP or a distributed service 
which meets the standards set forth in section 3.2.


Second: Given your specific choice of A or B,  are you preferentially 
inclined to choose the provided bit-boundary, or "/48"


Third: If none of these options are palatable, do you have a proposed 
approach?


Thanks,

Leif Sawyer

Advisory Council



___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Leif Sawyer]

Shepherd of the draft policy chiming in.

Thanks for the lively discussion, everybody.   There's certainly a lot to think 
about here.

Just as a reminder to folk, the current policy under question is located here:
https://www.arin.net/policy/nrpm.html#six551

And, to help clarify some confusion, per  6.5.5.3.1  
(https://www.arin.net/policy/nrpm.html#six5531)
residential customers "holding/64 and larger blocks"   may use censored data,  
i.e.  "Private Customer/Residence"
in lieu of actual names and street addresses.

--

With that said,  I have a couple of questions to ask, based on potential 
rewrites that are brewing.

First:Assuming a preference for /56  (based on PPML feedback)  for the 
moment,   which is the more
preferential rewrite of the opening sentence of 6.5.5.1?


a)  Each static IPv6 assignment containing a /55 or more addresses shall be 
registered in the WHOIS directory via SWIP or a distributed service which meets 
the standards set forth in section 3.2.



b)  Each static IPv6 assignment containing a /55 or more addresses, or 
subdelegation of any size that will be individually announced, shall be 
registered in the WHOIS directory via SWIP or a distributed service which meets 
the standards set forth in section 3.2.


Second:   Given your specific choice of A or B,  are you preferentially 
inclined to choose the provided bit-boundary, or "/48"

Third:  If none of these options are palatable, do you have a proposed approach?



Thanks,

  Leif Sawyer
Advisory Council

___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[hostmaster]

Just a couple of questions regarding the carrots and the sticks for the 
ARIN staff:


Other than those who came back to change their initial /35 to a /32, how 
many ARIN customers have come back for another allocation of IPv6 space 
because they used the first one to the extent the rules require, which I 
think is 75% of /48 block assignments.


And, how many customers have received a first allocation of IPv6?

Divide, and I can find out what percentage came back for more.

What I would like to know is my gut feeling correct, which is that after 
receiving an allocation of IPv6, nearly nobody ever returns to the well 
for more, or at least not like it was back in the IPv4 days when ARIN had 
IPv4 address space to allocate, and thus there are no sticks?


Another bit of info I would like to know if possible:  what percentage of 
customers with a v6 allocation has actually put any of their assignments 
into SWIP?  Since the current policy for SWIP in IPv6 is /64 or more, 
every allocation should be there.


The answers are useful to determine as far as the documenting the 
assignment for ARIN, how useful SWIP is for that purpose.


I have a /48 from 2 upstreams.  Only one is registered.  The other ISP 
does not appear to have ANY SWIP entries, even though I have set up the 
network with static v6 for at least a dozen customers, each of which 
received a /48.


Another "proxy" for to consider in deciding to SWIP or not might be the 
delegation of the reverse DNS for the allocated block. If there is a 
delegation, this is another way to find the technical contact other than 
SWIP if there is a problem.


Albert Erdmann
Network Administrator
Paradise On Line Inc.


On Mon, 17 Jul 2017, David Farmer wrote:


On Mon, Jul 17, 2017 at 2:11 PM, David R Huberman  wrote:



Can you define voluntary?


Is the voluntary choice to record a reassignment
up to the USP?

Or does the choice belong to the end-user?



I think that's a business decision the two parties make together. I think
an ISP can choose to SWIP whatever it wants, and should do so with the
consent of the end-user. I think an end-user should be able to demand a
SWIP entry, and the ISP should generally comply.



And if the ISP doesn't comply with the user's demand, can one of their
recourses be to appeal to ARIN?  Obviously, in a healthy market another,
and maybe more effective, option is to get another ISP.  However, not all
markets are healthy and too frequently users have only one realistic option
for an ISP, especially in rural areas.

I think it is important that if a user requests a SWIP from an ISP, and
they not given the SWIP, this should be at very least a technical violation
of ARIN policy.  Is ARIN going to revoke an ISP's address space because of
a single complaint from a user in this regard, of course not, but I would
expect ARIN to intercede with an ISP on behalf of the user.  However, if
there are repeated issues, especially large numbers of them, and if there
are other policy violations too, then I would expect harsher actions by
ARIN eventually.

Thanks

--
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===


___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[John Curran]

On 17 Jul 2017, at 2:25 PM, Tony Hain 
> wrote:

John,

I think we are in violent agreement here, other than the ARIN membership is the 
wrong venue (not broad enough to encompass the appropriate community) for the 
base statement that SWIP data  must exist for a routing entry. If the 
appropriately broad community established that BCP; a policy enforceable by 
ARIN staff would be “complies with community established BCP’s related to 
routing”.

The only problem I have with the general braindead conservation mindset that 
says a /48 is non-consumer, and must be SWIPed while longer values would be 
only consumer and therefore exempt. As far as it goes, if a consumer convinced 
the ISP they had a technical need for a /36, that should be exempt based on 
consumer protection. Length has nothing to do with it. Identifiable routing 
slot contact info is the “need” here, so anything that is not broken out 
doesn’t “need” SWIP data. That said, this whole paragraph, and most of the 
current discussion belongs in another venue.

Tony -

This is an open forum – i.e. one does not have to be an ARIN
Member to participate in the discussion.   To that end, if there
is number resource policy to be developed by the community
which is applicable to the ARIN registry, then such policy is
developed on the ARIN Public Policy mailing list and associated
(also open w/o charge to all) ARIN Public policy meetings.

Thanks!
/John

John Curran
President and CEO
ARIN

___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Paul McNary]

Tony

Do you mean BGP instead of BCP. I agree that IP's that are BGP routable 
should be the proper place
to place the SWIP requirement. Anything not BGP routable should be 
considered local routed.


Paul
On 7/17/2017 4:25 PM, Tony Hain wrote:


John,

I think we are in violent agreement here, other than the ARIN 
membership is the wrong venue (not broad enough to encompass the 
appropriate community) for the base statement that SWIP data  must 
exist for a routing entry. If the appropriately broad community 
established that BCP; a policy enforceable by ARIN staff would be 
“complies with community established BCP’s related to routing”.


The only problem I have with the general braindead conservation 
mindset that says a /48 is non-consumer, and must be SWIPed while 
longer values would be only consumer and therefore exempt. As far as 
it goes, if a consumer convinced the ISP they had a technical need for 
a /36, that should be exempt based on consumer protection. Length has 
nothing to do with it. Identifiable routing slot contact info is the 
“need” here, so anything that is not broken out doesn’t “need” SWIP 
data. That said, this whole paragraph, and most of the current 
discussion belongs in another venue.


Tony

*From:*John Curran [mailto:jcur...@arin.net]
*Sent:* Monday, July 17, 2017 12:25 PM
*To:* Tony Hain
*Cc:* arin-ppml@arin.net
*Subject:* Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of 
Assignment Registration requirements between IPv4 and IPv6


On 17 Jul 2017, at 11:20 AM, Tony Hain <alh-i...@tndh.net 
<mailto:alh-i...@tndh.net>> wrote:


John,

So you are OK with a policy that says ARIN is required to revoke
address space if other ISP’s choose to accept it into the routing
table, but there is no SWIP for it? To me that says you are making
a statement about “how things are routed” by requiring a database
entry before it gets accepted into routing.

I have no problem with a BCP to the effect that the data SHOULD
exist, but as a policy this has ARIN stomping right on the line it
claims to avoid.

Tony -

ARIN number resource policy must be germane to administration of the 
registry;


i.e. if you want a policy that says an address block will only be 
issued for a certain


reason (and that reason includes some routing characteristic, such as 
multihoming)


then ARIN will have parties represent that they intend to use in 
accordance with


that requirement, and will investigate representations that appear to 
be fraudulent.


For example, a policy that states that "IPv6 blocks will have SWIP 
performed for any


sub-delegations which are going to be individually announced by the 
ISP" would be


a policy which is enforceable, since the ISP is representing that 
they’ll do “X" under


certain circumstances, and it’s trivial to revoke if they fail to 
follow through and we


receive a fraud report from the community calling attention to that 
fraud.


Just remember, any characteristic or behavior that you intend to 
promulgate in this


manner effectively effective defines or extends the scope of ARIN’s 
mission, so it’s


worth being very cautious and very certain before proposing such…   
The fact that


parties need IP address space mean that they have little effective 
remedy to the


implications of community-developed number policy, and so requirements 
that aren’t


directly and clearly related to ARIN’s mission (e.g. “requester agrees 
that they will


put a statute of ARIN’s CEO in their lobby within 12 months of 
issuance”) are likely


to be found out of scope by ARIN’s Board of Trustees...

Thanks!

/John

John Curran

President and CEO

American Registry of Internet Numbers



___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Tony Hain]

John,

 

I think we are in violent agreement here, other than the ARIN membership is the 
wrong venue (not broad enough to encompass the appropriate community) for the 
base statement that SWIP data  must exist for a routing entry. If the 
appropriately broad community established that BCP; a policy enforceable by 
ARIN staff would be “complies with community established BCP’s related to 
routing”.  

 

The only problem I have with the general braindead conservation mindset that 
says a /48 is non-consumer, and must be SWIPed while longer values would be 
only consumer and therefore exempt. As far as it goes, if a consumer convinced 
the ISP they had a technical need for a /36, that should be exempt based on 
consumer protection. Length has nothing to do with it. Identifiable routing 
slot contact info is the “need” here, so anything that is not broken out 
doesn’t “need” SWIP data. That said, this whole paragraph, and most of the 
current discussion belongs in another venue.

 

Tony

 

 

From: John Curran [mailto:jcur...@arin.net] 
Sent: Monday, July 17, 2017 12:25 PM
To: Tony Hain
Cc: arin-ppml@arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment 
Registration requirements between IPv4 and IPv6

 

On 17 Jul 2017, at 11:20 AM, Tony Hain <alh-i...@tndh.net> wrote:

 

John,

 

So you are OK with a policy that says ARIN is required to revoke address space 
if other ISP’s choose to accept it into the routing table, but there is no SWIP 
for it? To me that says you are making a statement about “how things are 
routed” by requiring a database entry before it gets accepted into routing.

 

I have no problem with a BCP to the effect that the data SHOULD exist, but as a 
policy this has ARIN stomping right on the line it claims to avoid.

 

Tony - 

 

ARIN number resource policy must be germane to administration of the registry;

i.e. if you want a policy that says an address block will only be issued for a 
certain

reason (and that reason includes some routing characteristic, such as 
multihoming)

then ARIN will have parties represent that they intend to use in accordance with

that requirement, and will investigate representations that appear to be 
fraudulent.

 

For example, a policy that states that "IPv6 blocks will have SWIP performed 
for any

sub-delegations which are going to be individually announced by the ISP" would 
be 

a policy which is enforceable, since the ISP is representing that they’ll do 
“X" under 

certain circumstances, and it’s trivial to revoke if they fail to follow 
through and we 

receive a fraud report from the community calling attention to that fraud. 

 

Just remember, any characteristic or behavior that you intend to promulgate in 
this

manner effectively effective defines or extends the scope of ARIN’s mission, so 
it’s 

worth being very cautious and very certain before proposing such…   The fact 
that 

parties need IP address space mean that they have little effective remedy to 
the 

implications of community-developed number policy, and so requirements that 
aren’t 

directly and clearly related to ARIN’s mission (e.g. “requester agrees that 
they will 

put a statute of ARIN’s CEO in their lobby within 12 months of issuance”) are 
likely

to be found out of scope by ARIN’s Board of Trustees...

 

Thanks!

/John

 

John Curran

President and CEO

American Registry of Internet Numbers

 

 

___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[David Farmer]

On Mon, Jul 17, 2017 at 2:11 PM, David R Huberman  wrote:

>
> Can you define voluntary?
>>
>> Is the voluntary choice to record a reassignment
>> up to the USP?
>>
>> Or does the choice belong to the end-user?
>>
>
> I think that's a business decision the two parties make together. I think
> an ISP can choose to SWIP whatever it wants, and should do so with the
> consent of the end-user. I think an end-user should be able to demand a
> SWIP entry, and the ISP should generally comply.
>

And if the ISP doesn't comply with the user's demand, can one of their
recourses be to appeal to ARIN?  Obviously, in a healthy market another,
and maybe more effective, option is to get another ISP.  However, not all
markets are healthy and too frequently users have only one realistic option
for an ISP, especially in rural areas.

I think it is important that if a user requests a SWIP from an ISP, and
they not given the SWIP, this should be at very least a technical violation
of ARIN policy.  Is ARIN going to revoke an ISP's address space because of
a single complaint from a user in this regard, of course not, but I would
expect ARIN to intercede with an ISP on behalf of the user.  However, if
there are repeated issues, especially large numbers of them, and if there
are other policy violations too, then I would expect harsher actions by
ARIN eventually.

Thanks

-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Richard J Letts]

I have too many roles and job-titles, so below is my opinion only (as I'm at 
lunch right now)

My 2c.

As a residential customer with IPv6:
There are many valid reasons not to expose individual residential customer 
addresses. For example someone being stalked or harassed by an ex. If their 
IPv6 address is exposed in any way that leads someone too easily back to them 
then that is not a good thing. I feel that the length should mirror what is 
implicitly provided for ipv4 because the customer expectation has some 
importance here. 
I'm going to note that Comcast is currently handing out /60 to residential 
customers. 
Therefore I think swipping:
/60 & smaller : Bad idea (does not provide the same _implicit_ privacy 
that IPv4 does)
/56: maybe if that's your default assignment block
/52: maybe if that's your default assignment block
/48: should be required.

I'm also going to note that with IPv6 I can have multiple IPv6 addresses from 
different providers if I am simply multi-homed (i.e. not exchanging routing 
information). 

As a NOC manager:
I find SWIP records occasionally useful for reaching people I need to when 
discussing routing or abuse issues. It's not often but they are useful when 
they are there.
For the WA-State K20 network we do our best to ensure that we have these 
correctly published so people can reach the right contacts on that network (we 
are not always told when contacts leave)

I find SWIP records a pain to manage, but given I find them useful I'm quite 
happy to publish them as a help to the community.
It's as easy to SWIP a /56 as a /48 if I'm already doing the /48 -- it's all 
just database updates and a SMOP. Anyone getting a /56 or /48 isn't likely to 
be a residential customer.
(note: WA-K20 State network default assignment is a /48 -- but that's not 
relevant to the point here)
Business are generally required to have registered address for communications, 
they can always use that for their registration.



Richard Letts
Manager: Network Operations Center: UW, UW Medicine, WA-K20, PNWGP, 
PacificWave, WRN
Process Manager: Incident Management, Event Management
Service Manager: Wired Network Service
UW Information Technology
Mail: Box 354840
Street: 4545 15th Ave NE, Seattle, WA, 98105
206.685.1699 | mobile 206.790.5837
rjle...@uw.edu


___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[John Curran]

On 17 Jul 2017, at 11:53 AM, Paul McNary  wrote:
> 
> 
>> Compliance with registry policy is indeed necessary to receive number 
>> resources;
>> it is up to you to determine whether IP number resources are necessary for 
>> provision
>> of your Internet services.
> 
> But doesn't ARIN registry policy have to follow the law concerning CPNI ?

Paul -  if you are a regulated service provider, then you need to comply with 
the appropriate regulations, and that may govern how your firm interacts with
its customers and how you interact with ARIN.   ARIN is neither a regulated
service provider nor subject to the regulations that you reference, and we 
will operate accordingly to the community-developed policy.  

Thanks,
/John

John Curran
President and CEO
ARIN


___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Joe Provo]

On Mon, Jul 17, 2017 at 01:04:26AM -0400, hostmas...@uneedus.com wrote:
> John,
> 
> I think this is the FCC ruling he speaks of, and it does seem to shut down 
> public disclosures of most of what is contained in SWIP/WHOIS without 
> customer consent.  This has been the rule for regular phone calls for a 
> long time, called CPNI. Until today I did not realise the FCC extended 
> this to the internet. 

I'm not currently providing this service, but I did so when the 
discussion came around and recall when this was extended. It was 
specifically regarding services. All the CPNI rules stremmed from 
a customer's existing providers having an unfair marketing advantage 
by looking at the customer's services and usage. It was rooted in 
the age of slamming and "pretexting".  Even expanding that to generic 
Internet service did not change the definition to remove the scope 
of services provided to a customer.

[snip]
> http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-07-22A1.pdf
[snip]

In that doc, see "Discussion" section F "Extension of CPNI 
Requirements to Providers of Interconnected VoIP Service". Even 
with ISPs under title 2, without inclusion of service information 
a public registry has [IME] no relationship to the CPNI issue. 
That said, my personal suggestion would be to not include type of 
service ( -DSL-, -FTTH-, etc) in the SWIP netblock name or 
elsewhere in the record purely from an infosec PoV. :-)

Cheers (this is not legal advice),

Joe

-- 
Posted from my personal account - see X-Disclaimer header.
Joe Provo / Gweep / Earthling 
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[John Curran]

On 17 Jul 2017, at 11:20 AM, Tony Hain 
> wrote:

John,

So you are OK with a policy that says ARIN is required to revoke address space 
if other ISP’s choose to accept it into the routing table, but there is no SWIP 
for it? To me that says you are making a statement about “how things are 
routed” by requiring a database entry before it gets accepted into routing.

I have no problem with a BCP to the effect that the data SHOULD exist, but as a 
policy this has ARIN stomping right on the line it claims to avoid.

Tony -

ARIN number resource policy must be germane to administration of the registry;
i.e. if you want a policy that says an address block will only be issued for a 
certain
reason (and that reason includes some routing characteristic, such as 
multihoming)
then ARIN will have parties represent that they intend to use in accordance with
that requirement, and will investigate representations that appear to be 
fraudulent.

For example, a policy that states that "IPv6 blocks will have SWIP performed 
for any
sub-delegations which are going to be individually announced by the ISP" would 
be
a policy which is enforceable, since the ISP is representing that they’ll do 
“X" under
certain circumstances, and it’s trivial to revoke if they fail to follow 
through and we
receive a fraud report from the community calling attention to that fraud.

Just remember, any characteristic or behavior that you intend to promulgate in 
this
manner effectively effective defines or extends the scope of ARIN’s mission, so 
it’s
worth being very cautious and very certain before proposing such…   The fact 
that
parties need IP address space mean that they have little effective remedy to the
implications of community-developed number policy, and so requirements that 
aren’t
directly and clearly related to ARIN’s mission (e.g. “requester agrees that 
they will
put a statute of ARIN’s CEO in their lobby within 12 months of issuance”) are 
likely
to be found out of scope by ARIN’s Board of Trustees...

Thanks!
/John

John Curran
President and CEO
American Registry of Internet Numbers


___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[Paul McNary]

The way I understand, SWIP can be voluntary but with consequences at 
ARIN if we don't.

Am I hearing wrong?

Take care
Paul

pmcn...@cameron.net


On 7/17/2017 2:11 PM, David R Huberman wrote:



Can you define voluntary?

Is the voluntary choice to record a reassignment
up to the USP?

Or does the choice belong to the end-user?


I think that's a business decision the two parties make together. I 
think an ISP can choose to SWIP whatever it wants, and should do so 
with the consent of the end-user. I think an end-user should be able 
to demand a SWIP entry, and the ISP should generally comply.


___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

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

[David R Huberman]

Can you define voluntary?

Is the voluntary choice to record a reassignment
up to the USP?

Or does the choice belong to the end-user?


I think that's a business decision the two parties make together. I think 
an ISP can choose to SWIP whatever it wants, and should do so with the 
consent of the end-user. I think an end-user should be able to demand a 
SWIP entry, and the ISP should generally comply.


___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.