On 26/01/2014, at 14:19, Andy Linton wrote:
> The proposal "prop-109v001: Allocate 1.0.0.0/24 and 1.1.1.0/24 to APNIC
> Labs as Research Prefixes" has been sent to the Policy SIG for review.
I support this proposal.
-Mike
* sig-policy: APNIC SIG on resource management policy
On 26/01/2014, at 14:22, Andy Linton wrote:
> The proposal "prop-111-v001: Request-based expansion of IPv6 default
> allocation size" has been sent to the Policy SIG for review. It will be
> presented at the Policy SIG at APNIC 37 in Petaling Jaya, Malaysia, on
> Thursday, 27 February 2014.
This
Dear Subscriber,
This is the monthly reminder of subscription information for the
sig-policy list, hosted at APNIC.
For subscription information including how to un-subscribe go to
http://mailman.apnic.net/mailman/listinfo/sig-policy
Thank you for participating in this discussion.
Kind Regards,
On 1/28/14, 20:48 , (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) wrote:
Hi Owen,
I'm sorry but I misread your commmet.
| If you're going to do this, I would rather see providers given the option
of choosing a size
| ranging from /28 to /32 with encouragement towards either end (/28 or /32).
As
Hi David,
> Also, correct me if I'm mistaken, but by raising the default from /32 to
> /29, you are raising the barrier to entry for small LIRs. I believe
> APNIC's fees are based on your allocation size. Yes, its a logarithmic
> function, but it still raises the fees. So a small LIR that does
The more I think about it, I just don’t see an advantage to this proposal.
I’m all for relaxing the utilization criteria, but if you’re going to do that,
relax it to the nibble boundary, not some bizarre arbitrary point like /29.
Owen
On Jan 31, 2014, at 11:03 AM, Aftab Siddiqui wrote:
> Hi D
I completely agree with Aftabs evaluation of the fee related issue.
This would create a significant burden on small LIR's.
I no longer/do not support this proposal.
...Skeeve
*Skeeve Stevens - *eintellego Networks Pty Ltd
ske...@eintellegonetworks.com ; www.eintellegonetworks.com
Phone: 1300
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I have reviewed this proposal and at this time do not support this. I
am netural on the main issue of designating 1.2.3.0/24 as an 'special
purpose anycast' block.
I have issues with the RPKI portion. It creates additional burden on
APNIC to
> I have issues with the RPKI portion. It creates additional burden on
> APNIC to support non-member entities, which I do not support. As a fee
> paying member, this whole idea of supporting the 46K ASNs currently
> visible on the Internet doesn't scale and I'd find it a waste of fee
> paying membe
I would be happy to look at an extension to the proposal to cover "Any
service with local-only significance within the autonomous system".
--
Dean Pemberton
Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
d...@internetnz.net.nz
To promote the Internet's benefits and uses, and protect i
10 matches
Mail list logo
