Speaking only for myself, I certainly will be taking all of the comments into
consideration for all policies to which they appear relevant.
I’m quite certain that my fellow AC members and I are able to discern what
fractions of the comments are most applicable to which policy proposals.
On 17/07/2019 16:40, Job Snijders wrote:
(recognising that this thread is less and less about M and more
and more about 2019-04. I apologize for having contributed to a
conflation of the two policy proposals. I hope the AC will
recontextualize these comments)
I hope this is not an attempt to
Hi Jimmy,
The cost of doing all that has been done already for IPv4 and by other RIRs.
It is one-time development cost anyway (to adapt the changes to IPv6), so not a
giant effort. And by the way, it has been done already to allow that working
among RIPE and APNIC, and I believe there is
On Mon, Jul 15, 2019 at 11:37 PM Job Snijders wrote:
> Even if inter-RIR transfers were permitted, ARIN would still
> operationally be responsible for all delegations under the
> "0.6.2.ip6.arpa." zone. So, no issue there.
[snip]
No that is exactly one potential issue.An entity wishing
(recognising that this thread is less and less about M and more and more
about 2019-04. I apologize for having contributed to a conflation of the
two policy proposals. I hope the AC will recontextualize these comments)
On Tue, Jul 16, 2019 at 12:39:54PM -0400, Joe Provo wrote:
> > 1/ Currently
+1 Scott's comments.
Support
—
Virginia Tech
bjo...@vt.edu
On Mon, Jul 15, 2019 at 5:23 PM Scott Leibrand
wrote:
> Allowing entities outside the ARIN region to continue holding addresses
> originally assigned to an ARIN-region organization to which the
> non-ARIN-region entity is a legal
I am opposed to this draft policy as written. I believe the entity should
request resources from the new RIR, especially IPv6 resources, in order to
help keep accurate records. I would not be opposed to the transfer of IPv4
space should the destination RIR not be able to meet the needed
Hello,
Just to confirm Leo's observation.
For each RIPE document, you can find on our website in the metadata on
the righthand side in chronological order which previous versions were
updated by that version.
If the document was obsoleted by another document, the metadata will
also show
On Tue, Jul 16, 2019 at 11:29 AM ARIN wrote:
[ clip ]
The current policy, “3.6. Annual Validation of ARIN’s Public Whois Point
> of Contact Data” does not provide sufficient validation of the actual
> availablility of the abuse mailbox.
>
RFC 2142 clearly identifies what mailboxes are used
> On Jul 17, 2019, at 8:12 AM, JORDI PALET MARTINEZ via ARIN-PPML
> wrote:
>
> Hi Steve,
>
> The actual POC validation is also sending an email with a link. So, if you
> aren’t able to "classify" that and have a human behind, then the validation
> fails, so in that sense I don't see the
Hi Steve,
The actual POC validation is also sending an email with a link. So, if you
aren’t able to "classify" that and have a human behind, then the validation
fails, so in that sense I don't see the difference.
The final goal is that we can be sure that if somebody is sending an abuse
11 matches
Mail list logo
