I agree with Christopher and Larry that in most cases it's going to be
pointless, but if it's pointless, the better question becomes: why SWIP it in
the first place?
I don't disagree with either of your specific points, but this is something
I've pondered for a very long time: the point of delegation, historically (in
my memory, anyway) was to delegate authority and responsibility. The only
reason most of us (AFAIK) are normally looking at WHOIS data for an IP address
in the first place, is because we're about to send email to the listed contact
because of some bad action or other by that IP. So if that contact is a priori
useless... what was the point of having that data recorded in the first place?
If the proposal was to remove the requirement for reassignment and/or reallocation to end customers
completely, in cases where the delegating entity has sound reason to believe the customer is not
capable of being "responsible" for the block, and the delegating entity feels they can
better be "responsible" (I'm not going to attempt to define that term right now, sorry!)
then, yeah, I think that would be a worthwhile change. Reversing the onus of proof in the previous
sentence would be much easier for ISPs, I'm not sure if it's a good idea or not. Even lobotomizing
simple reassignments to contain names *only* might be a useful change.
Any of what I've suggested acknowledges the uselessness of the data commonly
found in /29s, /28s, etc.; the existing proposal, however, does not appear to
do so, instead ratifying the entire now-broken concept.
Would there be broad community support for a more radical change (e.g., see
above) than what was originally proposed? I think I would support such a
change, and I guess most ISPs would...? What realistic downside is there that
I'm just not thinking of right now?
Adam Thompson
Consultant, Infrastructure Services
MERLIN??????????
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
[email protected]
www.merlin.mb.ca
-----Original Message-----
From: Christopher E. Altland <[email protected]>
Sent: Monday, January 28, 2019 1:07 PM
To: Larry Ash <[email protected]>; Adam Thompson <[email protected]>; 'Marilson
Mapa' <[email protected]>; [email protected]
Cc: ARIN-PPML List <[email protected]>
Subject: RE: [arin-ppml] Draft Policy ARIN-2018-6: Clarify Reassignment
Requirements in 4.2.3.7.1
I support this proposal.
Almost all end users with /29 or larger in our network would not understand
what you were contacting them about. We get all of the complaints and will
follow up with the end user to get it resolved. I kind of feel that is what
they are paying use to do.
Christopher
--
Christopher Altland
Network Engineer | MCTV
[email protected] | www.MCTVOhio.com
814 Cable Ct. NW Massillon, OH 44647
-----Original Message-----
From: ARIN-PPML <[email protected]> On Behalf Of Larry Ash
Sent: Monday, January 28, 2019 1:50 PM
To: Adam Thompson <[email protected]>; 'Marilson Mapa'
<[email protected]>; [email protected]
Cc: ARIN-PPML List <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2018-6: Clarify Reassignment
Requirements in 4.2.3.7.1
On Mon, 28 Jan 2019 16:47:34 +0000
Adam Thompson <[email protected]> wrote:
I would phrase it in far less colourful language, and my motivations are almost
entirely opposite, but with the same end result:
I don???t like this proposal.
If I have a /29 or larger, and it???s sending spam or doing anything
else anti-social, I want to know about it. Relaxing the reassignment
requirements (whether that???s in fact or in appearance only) will guarantee
that nearly all ISPs will do the minimum possible, specifically not include any
relevant contact info for me.
From at least this one tiny piece of the community, no this proposal does not
have support right now.
-Adam
Of the /29 we have reassigned not a single one will respond to a message from
any one of you. None of them have internal IT resources. Many have equipment
that we manage and couldn't do anything anyway. Others have local computer
stores that take care of their stuff. The customer pays every time they call
with a question. They ignore every plea until it impacts their service.
I know because I have blocked several of them to stop attacks when we were
contacted as the customer's ISP and after several attempts to deal with the
problem without affecting service.
In a perfect world most of these companies would not have these addresses but
when corporate demands two or three ip's for the firewall and the heating
contractor demands an IP for the heating/cooling system and the security
company demands an IP for maintenance of the security system and remote access
to the cameras an ISP either assigns the address or the customer goes elsewhere.
At the same time, several times a day the phone rings and a person claims to be
from Microsoft or some other well known IT company claiming that if the person
called doesn't do the following bad things will happen. Hopefully by now every
person in the country as been trained to just hang up.
I think that direct contact to end users expecting solutions to technical
problems is delusional.
I support the proposal and feel that any contact information should be limited
to those that would have the technical ability to do something no matter the
size of reassignment.
Larry Ash
Mountain West Technologies
Casper Wyoming
Adam Thompson
Consultant, Infrastructure Services
[1DE92D93]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
[email protected]<mailto:[email protected]>
www.merlin.mb.ca<http://www.merlin.mb.ca/>
From: ARIN-PPML <[email protected]> On Behalf Of Marilson Mapa
Sent: Sunday, January 27, 2019 1:43 AM
To: [email protected]
Cc: ARIN-PPML List <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2018-6: Clarify
Reassignment Requirements in 4.2.3.7.1
The elimination of any reasonable means of contact in the event of
abuse it is an aberration and characterizes at least complicity with
unlawful acts. The ISPs need to stop hiding and protect spammers and scammers.
500 billion spam and scam a day are not enough? What is the new goal? A
trillion?
You, ISPs, RIRs, and Registrars represent GGM21C, the Great Global
Mafia of the 21st Century. We know that people's personal and financial
data are worth gold these days. Creating ISPs and inventing scammers to
steal data is a problem for authorities. Not to prohibit a spammer, or
scammer, from continuing to send his trash after being reported, is also a
criminal attitude of sociopaths who abound in that environment. This is the
rule with the complicity of RIRs, Registrars and ICANN. But the discomfort that
complaints bring to ISPs is being eliminated through policies such as the EU
GDPR and re-ordering in RIRs.
The threat of arresting the Facebook owner or billionaire fines such
as that imposed by the EU on Google will not be enough to force an
ethical stance on the part of the Mafia. The answer to this criminal behavior will come
in the worst way: politicians, under pressure from society, will say how free internet
should be "free." Then do not complain.
This policy intends to hide and protect a customer regardless of their behavior.
Marilson
Em s??b, 26 de jan de 2019 ??s 23:18,
<[email protected]<mailto:[email protected]>> escreveu:
Looking at this, I am a NO as it is currently written.
This section deals with /29 or more IPv4 addresses, or stated another
way,
8 or more addresses. Someone who is running such a network in today's
IPv4 exhausted world needs to have a means to contact them directly in
the event of abuse from their network. The reassign-simple does not
provide for this, unless you consider postal mail a reasonable means
of contact for abuse reports. I have ALWAYS directed abuse reports by
either email or telephone, as a letter is not fast enough for an ongoing abuse
problem.
As for the current ISP impact in regard to this policy as it currently
exists before amendment, the greatest majority of ISP customers, both
Business and Residential only have a single IPv4 address or less
(CGnat) and therefore are exempt from this policy. Only larger
networks with multiple hosts are likely to have 8 or more IPv4
addresses and subject to this policy. Those with a /29 or more are
very likely a very small amount of the total ISP customers, but are
also the ones with multiple hosts that would be more likely to be
compromised compared those who just have machines behind a NAT router
that cannot accept inbound traffic without a router that is programmed
to allow it. I doubt this policy change will have much change at most
ISP's, since the customer base it addresses is very small.
I would also suggest the residential exemption be eliminated for /29
or more, as nearly all residential IPv4 use today is NAT, rather than
public
IPv4 address assignment for each host. We have talked of the problem
of spammers on this list using such /29 or more of residential space,
that are protected by the current privacy rules for residental
customers, and their abuse reports being ignored by their upstream.
Looking at the differences between the Detailed and Simple reassign
templates, I do see one thing that would merit a change. It is that
the 2 fields that are most often used for abuse reporting (telephone
and email) are missing from the simple reassignment, and fields that
are rarely used for abuse reporting (mailing address) are instead
present. This is a decision that I would like to see changed.
I would have no problem with a template change to reassign simple to
only have Name, Contact Email and Telephone number, and omitting all
the mailing address fields. If that change were made, I would have no
problem with the proposal, as then the Simple Reassignment will at
least provide me with a reasonable means of contact in the event of
abuse from that network.
Eliminating the requirement for a Detailed Assignment, without
changing the fields contained in a Simple Assignment will have the
effect of eliminating the abuse contacts for that network. I think
that would be wrong.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Fri, 25 Jan 2019, Alyssa Moore wrote:
Helloooo PPML,
It's been a couple weeks since there's been any action here, but it's
time to shake off the winter and think about some policy! Woo!
This proposal has to do with clarifying the language and requirements
around reassignments. Please take a look and let your AC know if you
think we're on the right track or not.
Cheers,
AM
On Tue, Nov 20, 2018 at 3:55 PM ARIN <[email protected]<mailto:[email protected]>>
wrote:
On 15 November 2018 the ARIN Advisory Council (AC) accepted
"ARIN-prop-258: Clarify Reassignment Requirements in 4.2.3.7.1" as a
Draft Policy.
Draft Policy ARIN-2018-6 is below and can be found at:
https://www.arin.net/policy/proposals/2018_6.html
You are encouraged to discuss all Draft Policies on PPML. The AC
will evaluate the discussion in order to assess the conformance of
this draft policy with ARIN's Principles of Internet number resource
policy as stated in the Policy Development Process (PDP).
Specifically, these principles are:
* Enabling Fair and Impartial Number Resource Administration
* Technically Sound
* Supported by the Community
The PDP can be found at:
https://www.arin.net/policy/pdp.html
Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html
Regards,
Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)
Draft Policy ARIN-2018-6: Clarify Reassignment Requirements in
4.2.3.7.1
Problem Statement:
Current NRMP section ???Reassignment and Reallocation Information??? is
being interpreted by some organizations to require a ???detailed
reassignment??? for all customers. Under the current reassignment
schema, only a ???detailed reassignment or reallocation??? contains
fields for ???organizational information???.
This policy intends to simplify the reassignment requirements by
noting that only a customer???s name is required. Thus a ???simple
reassignment???
can be used for most reassignments.
Policy Statement:
Replace section 4.2.3.7.1 with the following:
4.2.3.7.1. Reassignment and Reallocation Information
Each IPv4 reassignment or reallocation containing a /29 or more
addresses shall be registered via a directory services system which
meets the standards set forth in section 3.2.
Reassignment registrations must include each customer name, except
where specifically exempted by this policy. Reassignment
registrations shall only include point of contact (POC) information
if either: (1) requested by the customer; or (2) the reassigned
block is intended to be routed and announced outside of the provider's network.
Reallocation registrations must contain the customer???s organization
name and appropriate point of contact (POC) information.
Comments:
Timetable for implementation: immediate
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to the
ARIN Public Policy Mailing List ([email protected]<mailto:[email protected]>).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected]<mailto:[email protected]> if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to the ARIN
Public Policy Mailing List ([email protected]<mailto:[email protected]>).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected]<mailto:[email protected]> if you experience any issues.
Larry Ash
Mountain West Technologies
123 W 1st St.
Casper, WY 82601
Office 307 233-8387
_______________________________________________
ARIN-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:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
