On Wed, Jul 17, 2019 at 4:09 PM JORDI PALET MARTINEZ via ARIN-PPML
wrote:
>
Hello,
> Regarding the cost of a member "leaving" ARIN membership, it is
> comparable to the reverse case, when a RIPE or APNIC member moves to ARIN.
> This is something that we need to live with,
No... That is
This is an idea based on past operation right here at ARIN.
Right after CIDR was started, there was a move, although not mandatory to
get those requesting more IPv4 space, especially those holding many
multiple blocks to give these parties a larger single block, and time to
renumber into the
On Thu, Jul 18, 2019 at 5:48 PM Roberts, Orin wrote:
> Well said Albert, I agree with this viewpoint, IPv6 was meant to solve the
> existing IPv4 operational issues; I see this policy proposal as extending
> them.
I cannot believe that the idea of "if you want a larger block, you'll
need to
To: ARIN-PPML List
Subject: [EXT]Re: [arin-ppml] Draft Policy ARIN-2019-10: Inter-RIR M -
Seeking Community Comments
Hi, Jordi,
I do not agree with your points, and strongly oppose IPv6 transfers for ARIN.
Just because two RIR's have developed a policy to allow this is NOT a good
reason for ARIN
Hi, Jordi,
I do not agree with your points, and strongly oppose IPv6 transfers for
ARIN. Just because two RIR's have developed a policy to allow this is NOT
a good reason for ARIN to jump unto that bandwagon.
There are clear costs to allowing IPv6 transfers at ARIN. They include
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
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
On Tue, Jul 16, 2019 at 03:49:31PM +, Job Snijders wrote:
> Dear all,
>
> (Note for the AC - it appears that discussion in context of 2019-04 is
> bleeding over into the 2019-10 thread, please take these comments under
> advisement for 2019-04. I'm sorry there is so much e-mail to plow
>
Without bringing some numbers and practical data to this discussion it
becomes harder to find out for example real situations where these
transfers (in the context of RIPE and APNIC) were a game changer and
that benefited IPv6, it may just be a wish to have.
I really don't see that allowing
Dear all,
(Note for the AC - it appears that discussion in context of 2019-04 is
bleeding over into the 2019-10 thread, please take these comments under
advisement for 2019-04. I'm sorry there is so much e-mail to plow
through related to the policy propoals, thank you for your time.)
On Tue, Jul
On 16/07/2019 01:36, Job Snijders wrote:
On Mon, Jul 15, 2019 at 11:17:48PM -0400, hostmas...@uneedus.com wrote:
This means the ENTIRE BLOCK has been assigned to ARIN, and therefore
ARIN controls the reverse DNS of this entire block.
I think you may be overstating the 'control' aspect. ARIN is
Same as in IPv4. If course the difference is the size of the blocks received
from IANA, but this is comparative to the order of magnitude difference between
IPv4 and IPv6.
Regards,
Jordi
@jordipalet
El 16/7/19 5:18, "arin-ppml-boun...@arin.net en nombre de
hostmas...@uneedus.com"
On Mon, Jul 15, 2019 at 11:17:48PM -0400, hostmas...@uneedus.com wrote:
> This means the ENTIRE BLOCK has been assigned to ARIN, and therefore
> ARIN controls the reverse DNS of this entire block.
I think you may be overstating the 'control' aspect. ARIN is part of a
chain of delegations. If we
Thanks Albert for such a comprehensive explanation and for going over
something that certainly most people understand well so didactically and
covering that "objection" completely.
I support that this fracturing of the reverse DNS is something
unnecessary and at the cost of not having to
I will take a stab at what this means.
I am choosing the block containing my IPv6 addresses as an example. If you
go to the ARIN whois site and look up network NET6-2600, you will see that
this network range is 2600:: to 260f:::::::.
This network is otherwise
Dear Fernando,
On Mon, Jul 15, 2019 at 08:13:12PM -0300, Fernando Frediani wrote:
> I will comment only in one of the points, the other I believe are
> really well explained by others and it doesn't seem good to 'rain on
> the wet floor'.
I'm sorry but I don't think we can skip over some of
I will comment only in one of the points, the other I believe are really
well explained by others and it doesn't seem good to 'rain on the wet
floor'.
On 15/07/2019 19:58, Job Snijders wrote:
- Readdressing is part of the business and not something prohibitive
Can you elaborate? I
On Mon, 15 Jul 2019 at 22:51, Fernando Frediani
wrote:
> I think regardless there would be an increase in the IPv6 routing table
> Inter-RIR transfers should not be allowed at all for the other given
> reasons as such:
>
> - Fracturing of Reverse DNS zone
>
Can you elaborate on the above? What
I think regardless there would be an increase in the IPv6 routing table
Inter-RIR transfers should not be allowed at all for the other given
reasons as such:
- Fracturing of Reverse DNS zone
- Complication of management of each /12
- No shortage of IPv6
- IPv6 migration and readdressing is
On Mon, Jul 15, 2019 at 2:27 PM wrote:
> It depends on if this is PI or PA space.
>
> In the case of PI space, you may be right, one route removed, one route
> added - net change likely zero. However in the long run, PI space is
> going to make the IPv4 routing tables look small when everyone
On Mon, Jul 15, 2019 at 4:07 PM Job Snijders wrote:
> On Mon, Jul 15, 2019 at 05:01:43PM -0400, hostmas...@uneedus.com wrote:
> > I understand that we allow this in IPv4 only because of the shortage.
> > Further, changing IPv6 addresseses is not as big of hardship as it was
> > in IPv4 land,
It depends on if this is PI or PA space.
In the case of PI space, you may be right, one route removed, one route
added - net change likely zero. However in the long run, PI space is
going to make the IPv4 routing tables look small when everyone has their
own route, rather than a combined
On Mon, Jul 15, 2019 at 05:01:43PM -0400, hostmas...@uneedus.com wrote:
> I understand that we allow this in IPv4 only because of the shortage.
> Further, changing IPv6 addresseses is not as big of hardship as it was
> in IPv4 land, since both networks can exist during a changeover
> period. Also,
I think fracturing the Reverse DNS zone, along with the PKI issues is not
worth allowing IPv6 transfers to happen. It needlessly complicates
management of each /12 IPv6 block which currently is 100% managed by ARIN,
and causes part of that space to be managed by another RIR.
I understand
It depends on the type of network.
A hosting infrastructure based in VMs, may be replicated "online" to another DC
in a different region.
The magic of that replication is a very good motivation for this policy, as
clearly doesn't make any sense that you can replicate everying including no
I did find the RIPE-682 document, and I do see that RIPE allows IPv6
transfers.
However, I still do not think this is a good idea for ARIN. It adds an
extra level of complexity to both the reverse DNS zone and PKI.
Therefore, I am still opposed to allowing IPv6 RIR transfers from ARIN
Yes… It would be nice if RIPE would move to a system similar to the other RIRs
where there
is a single comprehensive policy document which is amended through the PDP
rather than
their current RFC (usually without the back references and without the
advantages of a
responsible RFC editor
I fully agree with the comments on below message.
Fine IPv4 and 16 bit ASN transfers but not to IPv6.
Some people justify that it is to avoid renumbering, but I don't
consider a strong enough reason to allow IPv6 transfers. Renumbering is
part of the business whenever necessary and not
Hi Albert,
I think you looked at the wrong RIPE documents. Unless I got it wrong, the
right document is RIPE-682, and it clearly states that IPv6 can also be
transferred (both intra and inter-RIR).
I've a similar policy proposal in LACNIC and APNIC, and working as well for
submitting in a few
Apologies for missing your comment Scott. It fell through my manual search.
This is an excellent observation and suggestion for the community to
consider. I look forward to hear more from you and others.
Warm regards
Kerrie
On Jul 15, 2019 1:51 PM, "Scott Leibrand" wrote:
> On June 18 I
The only problem I have with this policy is that allows IPv6 transfers.
I have no problem with IPv4 and 16 bit ASN transfers because they are both
scarce resources. However, I do not think we should start down the road
of allowing IPv6 RIR transfers. If they are operating in a portion of the
On June 18 I commented that "It would probably also provide a way to bypass
ARIN policy, so we should think carefully about whether all resources (such
as waiting list space) should be transferable this way."
Would it be better to limit the applicability of ARIN-2019-10 to only apply
to space
Good day everyone,
I am seeking community input on *Draft Policy ARIN-2019-10: Inter-RIR
M *since the last post on this policy on May 21, 2019 there has not
been any conversation around it. As primary shepherd I need to have a
good sense of the direction that the community wants to take in
On Tue, Jun 18, 2019 at 20:30 Joe Provo wrote:
> On Tue, Jun 18, 2019 at 07:46:42PM +0200, Job Snijders wrote:
> > On
> > Tue, Jun 18, 2019 at 18:53 wrote:
> [snip]
> > There may be other reasons than ???shortage??? to administratively move
> > resources. Have you considered that others may
On Tue, Jun 18, 2019 at 20:21 Fernando Frediani
wrote:
> Well, I can't see how allowing IPv6 transfers or not can be compared to a
> 'feature' and discourage people to adopt it or not. If they do this based
> on this premise it is much worse for them than for the rest of the
> internet. And
On Tue, Jun 18, 2019 at 07:46:42PM +0200, Job Snijders wrote:
> On
> Tue, Jun 18, 2019 at 18:53 wrote:
[snip]
> There may be other reasons than ???shortage??? to administratively move
> resources. Have you considered that others may have other priorities and
> that there may be no clear downside
Well, I can't see how allowing IPv6 transfers or not can be compared to
a 'feature' and discourage people to adopt it or not. If they do this
based on this premise it is much worse for them than for the rest of the
internet. And going beyond as it is normally discussed in these policy
lists it
I would like to add to Chris' questions;
Do you prefer Draft Policy ARIN-2019-10 or Draft Policy ARIN-2019-4: Allow
Inter-regional IPv6 Resource Transfers to move forward?
Or, is there a need for both Draft Policy's to continue forward?
Is there some part of one or the other that should be
On
Tue, Jun 18, 2019 at 18:53 wrote:
> The main problem I see is that this policy for the first time will open
> the door up to IPv6 transfers. I do not agree with IPv6 transfers.
>
> Up to this point, the primary reason why we allow transfers of IPv4 and 16
> bit ASN numbers is the shortage
Well said !
On 18/06/2019 13:53, hostmas...@uneedus.com wrote:
The main problem I see is that this policy for the first time will
open the door up to IPv6 transfers. I do not agree with IPv6 transfers.
Me either
Up to this point, the primary reason why we allow transfers of IPv4
and 16 bit
Hello,
3. Is there any potential deleterious impact should this language be
adopted into the NRPM?
I speak neither for or against this draft policy.
I would like to note that the delegation of ip6.arpa zones are currently
cleanly delineated. In the simple and current example, each RIR is
Yes, yes, yes, and yes.
This sort of flexibility would be useful and helpful for multinationals that
want to consolidate RIR accounts after acquisitions. It would probably also
provide a way to bypass ARIN policy, so we should think carefully about whether
all resources (such as waiting list
The main problem I see is that this policy for the first time will open
the door up to IPv6 transfers. I do not agree with IPv6 transfers.
Up to this point, the primary reason why we allow transfers of IPv4 and 16
bit ASN numbers is the shortage of these resources.
In the case of IPv6
Hello PPML,
The Advisory Council is seeking statements of support or opposition to the
below draft policy, which so far have not been seen on PPML. I’d advise the
community to consider the following questions:
1. Is the problem statement a valid and/or likely occurrence that would require
a
On 16 May 2019, the ARIN Advisory Council (AC) accepted "ARIN-prop-270:
Inter-RIR M" as a Draft Policy.
Draft Policy ARIN-2019-10 is below and can be found at:
https://www.arin.net/participate/policy/drafts/2019_10/
You are encouraged to discuss all Draft Policies on PPML. The AC will
49 matches
Mail list logo
