ast.
>
> From: Jason Schiller [mailto:jschil...@google.com
> <mailto:jschil...@google.com>]
> Sent: Wednesday, April 18, 2018 9:01 AM
> To: Delacruz, Anthony B
> Cc: ARIN-PPML List
> Subject: Re: [arin-ppml] Draft Policy 2017-12: Require POC Validation Upon
> Reassignme
B
Cc: ARIN-PPML List
Subject: Re: [arin-ppml] Draft Policy 2017-12: Require POC Validation Upon
Reassignment
Anthony,
I hear you. And I think we should try a "lets do better" approach.
I think the goal here is to get good SWIP data, and make sure the
contact info is correct.
Thi
Backbone Planning and Design
>
> Office: +1 703 363 8503
>
> anthony.delac...@centurylink.com
>
> ipad...@centurylink.com
>
>
>
>
>
>
>
> *From:* ARIN-PPML [mailto:arin-ppml-boun...@arin.net] *On Behalf Of *John
> Santos
> *Sent:* Tuesday, April 17, 2018 1:58 PM
>
] On Behalf Of John Santos
Sent: Tuesday, April 17, 2018 1:58 PM
To: arin-ppml@arin.net
Subject: Re: [arin-ppml] Draft Policy 2017-12: Require POC Validation Upon
Reassignment
I think anyone who supplies someone else's email address to a third party
without their permission is responsible
M
*To:* Christian Tacit <cta...@tacitlaw.com
<mailto:cta...@tacitlaw.com>>
*Cc:* arin-ppml@arin.net <mailto:arin-ppml@arin.net>
*Subject:* Re: [arin-ppml] Draft Policy 2017-12: Require POC
Validation Upon Reassignment
This problem is not scoped only to with a new POC is c
ions will have the awareness and knowledge to
> resolve that issue between themselves.
>
>
>
> Chris
>
>
>
> *From:* Jason Schiller <jschil...@google.com>
> *Sent:* March 15, 2018 4:29 PM
> *To:* Christian Tacit <cta...@tacitlaw.com>
> *Cc:
and knowledge to resolve that issue between themselves.
Chris
From: Jason Schiller <jschil...@google.com>
Sent: March 15, 2018 4:29 PM
To: Christian Tacit <cta...@tacitlaw.com>
Cc: arin-ppml@arin.net
Subject: Re: [arin-ppml] Draft Policy 2017-12: Require POC Validation Upon
Reassignment
This problem is not scoped only to with a new POC is created.
This was also supposed to be a check in 3.7 to insure a resource is not
randomly SWIP'd to a pre-existing org.
3.8 was intended to chatch when a resource is SWIP'd to a pre-existing org,
but that org ID is not used, and that org's
> On Mar 13, 2018, at 11:54 , Scott Leibrand wrote:
>
> How do we address the risk that companies with fully automated
> whois-population systems simply don't bother to do that research, and their
> delegation ends up not getting added to whois at all?
I see that as
Oh, I forgot to mention, I support the proposal in principle and as written.
Thanks,
Scott
On Tue, Mar 13, 2018 at 1:11 PM, Brian Jones wrote:
> I support draft proposal 2017-12. It is a good step forward for POC
> validation.
>
> --
> Brian
> E Jones
> Agile Process Engineer
I support draft proposal 2017-12. It is a good step forward for POC
validation.
--
Brian
E Jones
Agile Process Engineer
Virginia Tech
On Mon, Mar 12, 2018 at 5:47 PM, Christian Tacit
wrote:
> Dear Community Members,
>
>
>
> The shepherds for the Draft Policy 2017-12:
How do we address the risk that companies with fully automated
whois-population systems simply don't bother to do that research, and their
delegation ends up not getting added to whois at all?
This may be an implementation detail, but I think we should make sure the
policy allows for an option
I support.
I think this will go a long way in getting correct POC's in the database
at the start. Currently, whoever is doing the ordering might end up with
their contacts in the database, because that is the only information that
the service provider has. This is how we end up with
13 matches
Mail list logo