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 <pmcn...@cameron.net> 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
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 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.
