[arin-ppml] Draft Policy ARIN-2018-6: Clarify Reassignment Requirements in 4.2.3.7.1

Tue Jan 29 23:56:21 EST 2019

A shred of ethics on this unbridled laissez-faire would be helpful.

Marilson

Em seg, 28 de jan de 2019 às 18:07, <hostmaster at uneedus.com> escreveu:

> I learned a lot about the feelings of the community regarding the
> requirement to SWIP 8 IPs or more when I proposed 2017-5.  My intent was
> originally to change the policy for IPv6 SWIP registration from EVERY
> network to those who had more than 16 networks, or more than a /60.  As
> part of that, I proposed changing IPv4 policy to match from the current 8
> or more IPs to more than 16 IPs.  When the proposal hit the list, there
> was near unity that everyone with 8 or more IPv4 needs to SWIP their
> addresses and provide contact information.  My response was to eliminate
> all IPv4 bits from my draft policy, and it passed, changing the standard
> to more than a /48 for swip unless it is advertised differently.
>
> Now 2 years later, because of pointlessness or otherwise, a proposal to
> eliminate ANY means of contact for these networks is now being discussed,
> and many now agree with the idea. I think that is wrong, even if emails to
> a SWIP contact are generally ignored.
>
> While I agree that end user contacts would be pointless for this purpose,
> generally these contacts should not be end user contacts, but instead
> should be the people who are responsible for IT management for that
> network.  It might be a central IT contact in a business with many
> branches, or in smaller orgs might simply be the ISP contacts, as many
> ISP's do offer managed services along with connectivity.
>
> Personally I would tell the Camera, A/C and other vendors that I will give
> them an internal IPv4 address, and a port forward to their box, or if they
> MUST have a static IP, it will have to be an IPv6 address.  After all, I
> have plenty of those to offer :).  At some point, that will be all that is
> available.
>
> Our policy should be based on best practices, and that means a contact
> means for every block with 8 or more IPv4 addresses.  ISPs need to educate
> their customers to the fact that this contact needs to be a technical
> person that is able to deal with abuse, and not a contact in purchasing. A
> cost avoidance model should not be allowed either, or they should not be
> shocked when the circult is turned down by the ISP for abuse.
>
> If those here still think we should get rid of the contacts for 8 or more
> addresses, instead lets consider changing the standard to /24 like it was
> in the past.  The language proposed would allow ANY size network get by
> without anything other than a simple, providing no contact information.
> The ideal process is still to have the abuse complaint land on the desk of
> the person closest to the problem.  Clearly once you get to a /24, you
> should be required to register your addresses.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
>
> On Mon, 28 Jan 2019, Adam Thompson wrote:
>
> > 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)
> > athompson at merlin.mb.ca
> > www.merlin.mb.ca
> >
> > -----Original Message-----
> > From: Christopher E. Altland <caltland at mctvohio.com>
> > Sent: Monday, January 28, 2019 1:07 PM
> > To: Larry Ash <lar at mwtcorp.net>; Adam Thompson <athompson at merlin.mb.ca>;
> 'Marilson Mapa' <marilson.mapa at gmail.com>; hostmaster at uneedus.com
> > Cc: ARIN-PPML List <arin-ppml at arin.net>
> > 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
> > caltland at MCTVOhio.com | www.MCTVOhio.com
> > 814 Cable Ct. NW  Massillon, OH 44647
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: ARIN-PPML <arin-ppml-bounces at arin.net> On Behalf Of Larry Ash
> > Sent: Monday, January 28, 2019 1:50 PM
> > To: Adam Thompson <athompson at merlin.mb.ca>; 'Marilson Mapa' <
> marilson.mapa at gmail.com>; hostmaster at uneedus.com
> > Cc: ARIN-PPML List <arin-ppml at arin.net>
> > 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 <athompson at merlin.mb.ca> 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)
> >> athompson at merlin.mb.ca<mailto:athompson at merlin.mb.ca>
> >> www.merlin.mb.ca<http://www.merlin.mb.ca/>
> >>
> >> From: ARIN-PPML <arin-ppml-bounces at arin.net> On Behalf Of Marilson Mapa
> >> Sent: Sunday, January 27, 2019 1:43 AM
> >> To: hostmaster at uneedus.com
> >> Cc: ARIN-PPML List <arin-ppml at arin.net>
> >> 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, <hostmaster at uneedus.com<mailto:
> hostmaster at uneedus.com>> 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 <info at arin.net<mailto:
> info at arin.net>> 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 (ARIN-PPML at arin.net<mailto:
> ARIN-PPML at arin.net>).
> >>>> Unsubscribe or manage your mailing list subscription at:
> >>>> https://lists.arin.net/mailman/listinfo/arin-ppml
> >>>> Please contact info at arin.net<mailto:info at arin.net> if you experience
> any issues.
> >>>>
> >>> _______________________________________________
> >> ARIN-PPML
> >> You are receiving this message because you are subscribed to the ARIN
> >> Public Policy Mailing List (ARIN-PPML at arin.net<mailto:
> ARIN-PPML at arin.net>).
> >> Unsubscribe or manage your mailing list subscription at:
> >> https://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net<mailto:info at arin.net> 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 (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20190130/b13c79ad/attachment.htm>