A shred of ethics on this unbridled laissez-faire would be helpful. Marilson
Em seg, 28 de jan de 2019 às 18:07, <[email protected]> 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) > > [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. > >
_______________________________________________ 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.
