[arin-ppml] Proposed update for ARIN-2017-12

[Marilson Mapa]

>Do you see problems with this text?

When I read *But given GDPR and the general focus on privacy these days...*
I can only see one word: subservience. The GDPR is a work of the European
Union Socialist Republic. The EU has used American liberal capitalism to
achieve a good standard of living.. But an army of socialists has taken
over the EU and will raze their economies as they always do when they see
themselves as capable of doing better than the capitalist individual.
It seems that the only American who understands this situation and has the
balls to face these socialist parasites is Trump. I also have a question:
Will GDPR dictate your actions?

Marilson

Em ter, 29 de jan de 2019 às 11:01, David Farmer <farmer at umn.edu> escreveu:

> The following is a proposed update for the Policy Text of ARIN-2017-12, it
> also updates the Problem Statement and the Title of the Policy based on
> this new Policy Text.
>
> This policy envisions that both it and 2018-5 will move forward, but it
> was considered what would happen if 2018-5 doesn't go forward. If 2018-5
> doesn't go forward and this policy does, then an organization can still
> create another organization's entry in the database, but that must happen
> separately and before the reallocation or detailed reassignment is made.
>
> It is also envisioned that all POCs will be validated when they are
> created, again before the reallocation or detailed reassignment is made,
> the latter being the purpose of this policy. Maybe the former can be
> handled in 2018-5, a separate policy, or simply as an operational
> suggestion to ARIN. But given GDPR and the general focus on privacy these
> days, I think ARIN separate from number policy reasons would want to ensure
> that POCs themselves approved or are at least notified when a database
> entry is made for them as an individual.
>
> The primary purpose of this policy is to logically separate ORG and POC
> creation, ensuring that they are in the ARIN database prior to the process
> of making reallocations or detailed reassignments and ensures the receiving
> organization knows when any reallocations or detailed reassignments are
> made to it. Further, it directs ARIN treat reallocations or detailed
> reassignments consistent with section 3.6.5, there must be at least one
> valid POC in order for them to occur.
>
> Is this a good direction to take this policy?  Do you see problems with
> this text?
>
> Comment and suggestions, please.
>
> Thanks.
>
> ------
> Draft Policy ARIN-2017-12:
> New Title:  POC Notification and Validation Upon Reassignment or
> Reallocation
>
> Problem Statement:
>
> Some ISPs assign individuals to be POCs for reassigned blocks without
> consultation of the individual they are inserting into Whois. For example,
> during the reassignment/reallocation process, some large ISPs automatically
> create POCs from their customer's order form. This process is automated for
> many ISPs and therefore the resulting POCs are not validated prior to being
> created in the ARIN Whois database. This creates unknowing POCs that have
> no idea what Whois is or even who ARIN is at the time they receive the
> annual POC validation email. It can also create multiple POCs per email
> address causing that same person to receive a multitude of POC Validation
> emails each year.
>
> This policy proposal seeks to prevent the situation where a POC is
> unwittingly and unintentionally inserted into Whois. Doing so will reduce
> the significant amount of time that ARIN staff spend fielding phone calls
> from POCs who have no idea they are in Whois.
>
> The proposal will improve the overall POC validation situation, by
> ensuring that all reallocation or detailed reassignment requests are
> related to a pre-existing receiving organization with at least one valid
> POC object, and by requesting that any other existing invalid POC objects
> are validated.
>
> Policy statement:
>
> Insert one new section into NRPM 3:
>
> 3.7 POC Notification and Validation Upon Reassignment or Reallocation
>
> When a request for reallocation or detailed reassignment is made to ARIN,
> the receiving organization must already be in the ARIN database and linked
> to at least one valid POC object.  If there is no valid POC object
> associated with the receiving organization, ARIN shall reject the request.
>
> In addition to notifying the requester, ARIN will also notify, via email,
> all POCs associated with the receiving organization, whether the request
> was successful or not, and will request validation of any invalid POC
> objects associated with the receiving organization.
>
> Note: Simple reassignments are made without any linkage to an organization
> or POC objects in the ARIN database.
>
> Timetable for implementation: Immediate
>
> --
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> _______________________________________________
> 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/c3cee5cf/attachment.htm>