Hello
My concern is where the magic boundary will occur. If the swip boundary
includes the
recommended /XX for residential customers and small business. I could
see where the
whois database could be abused by harvesting our customer information.
Competitors
could, would have access and ability to harvest proprietary information
concerning
our ISP business. We would have to limit our end user details to the
area which will
not be swip'ed to protect our business. That might not be the proper way
to utilize IPv6.
Current guidance has been to assign a /56 to even residential customers
and some have
recommended a /48 as the minimum assignment. I don't want my customer
information
available in such a public accessible database as whois. They could
count my subscribers,
harvest their names, addresses and even contact phone numbers. I do not
see this
as being good. I would not even like my SMB businesses to have public
information
unless they ask for it. I would prefer that the boundary be greater than
/48. With /48
not being swip'ed or /56 even that is the minimum end user allocation.
If I understand correctly (many times I do not) RFC/common agreement
that a /32
is the smallest allocation to be announced. I have also have heard /48.
So in my
case if it can't be BGP public routable, I don't want to swip it. What
ever my BGP
routers can publicly advertise, my BGP gateway, will be assigned to us.
Everything
smaller than that, I don't want to publicly advertise.
Why would we want the ability to give the competition the tools to
analyze our
business with a publicly available tool (ie whois). I also don't think
that if ARIN
will not provide an allocation size it shouldn't be swip'ed. So if ARIN
wants to directly
provide /56 to end users, then I will rethink my thought process.
Anything smaller than
a minimum ARIN allocation, should not have to be swip'ed or under their
control.
Am I not understanding this correctly?
Thank you
Paul McNary
McNary Computer Services
[email protected]
On 7/15/2017 12:42 PM, Scott Leibrand wrote:
On Sat, Jul 15, 2017 at 10:24 AM, William Herrin <[email protected]
<mailto:[email protected]>> wrote:
On Sat, Jul 15, 2017 at 8:52 AM, John Curran <[email protected]
<mailto:[email protected]>> wrote:
Such a separation doesn’t preclude the community from adopting
policy which
references the present or future state of routing (note, for
example, the use of
“multihoming” criteria in several portions of the NRPM), but
folks are reminded
that in Internet number resource policy we should only be
specifying how the
ARIN registry is to be administered, not how things are to be
routed, since the
latter is up to each ISP.
Hi John,
In the interests of clarifying your remarks:
ARIN does not set or even recommend routing policy. Participants
in the ARIN policy process routinely consider industry routing
practices, IETF recommendations, etc. when suggesting ARIN address
management policy and ARIN routinely enacts such policy.
Right?
That is true, but I think John is making a stronger point, which I'll
make here: It's perfectly fine for ARIN policy to be contingent on
(applied differently depending on) how a particular block is (going to
be) routed. So if we think it's the right thing to do, we could
require in the NRPM that all blocks in the global routing system be
SWIP'ed. But we *can't* enforce such a requirement by saying, for
example, that ISPs can't accept a block until it's SWIP'ed. We can
only issue guidelines on what should be SWIP'ed and make ARIN services
(like allocation of additional blocks) contingent on whether such a
policy is followed. If an enforced SWIP-before-routing rule is
desired by the ISPs that participate in the global routing system,
then they'll have to do so voluntarily by refusing to accept the
announcement of non-SWIP'ed blocks.
-Scott
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
