date:20140917

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

2014-09-17 Thread Jay Daley


On 18/09/2014, at 4:11 pm, Skeeve Stevens  wrote:

> Ok, thinking about this some more, I am still conflicted.
> 
> There are two schools here... simplicity and conservation.
> 
> I think worrying about conservation is important.  But are we trying to 
> converse needlessly?

No.   We need to try harder.

> 
> If we think we will be using v6 in 20 years, I think we are kidding 
> ourselves.  

It took 20 years to agree IPv6.  Next time around the change will be even 
harder.  We should expect that IPv6 will last at least the next 50 years.

> With the IoE/IoT, the consumption of address space is going to accelerate in 
> a huge way.  If we're not thinking about what is after IPv6, then we're doing 
> ourselves a disservice anyway. But that is the future, and extremely 
> difficult to predict in this area.

That's seems to be the most egregious excuse for not doing things correctly now 
- "It doesn't matter because we're going to replace it anyway".  An argument 
that could be applied to IPv7, 8 and so on.

Jay

> I think simplicity is better in this case... except if it is not really 
> simple.  If we have to alter a significant amount of policy to make it 
> simpler, then it isn't really simple.
> 
> The question is, how critical is this at the moment?  I'd like to see thing 
> simpler, but I'd like to know how complex it would be to implement it - 
> correctly.
> 
> 
> 
> 
> ...Skeeve
> 
> Skeeve Stevens - Senior IP Broker
> v4Now - an eintellego Networks service
> ske...@v4now.com ; www.v4now.com
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
> facebook.com/v4now ; linkedin.com/in/skeeve
> twitter.com/theispguy ; blog: www.theispguy.com
> 
> IP Address Brokering - Introducing sellers and buyers
> 
> On 18 September 2014 12:02, Skeeve Stevens  wrote:
> Elvis,
> 
> Owens position has been quite simply explained.
> 
> He does NOT oppose the increase in the size of the allocation just just 
> wants it done more cleanly.
> 
> Deans argument is that this will potentially waste additional space.
> 
> I see, and actually agree with both positions...   I like to conserve address 
> space, but Owens point is very valid... even if 1 million organisations took 
> a /28, it would still make minimal impact on the address space over a 
> significant period.
> 
> But, planning for the future is something we should keep in our mind... but, 
> not at the detriment of todays operations.
> 
> His point of the number of name servers for reverse delegation for a /29 
> being 8 and a /28 being 1 is quite a compelling reason to increase the 
> default 'larger' allocation to /28.
> 
> So... balancing the two.. I support increasing the standard large allocation 
> to a /28.
> 
> 
> ...Skeeve
> 
> Skeeve Stevens - Senior IP Broker
> v4Now - an eintellego Networks service
> ske...@v4now.com ; www.v4now.com
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
> facebook.com/v4now ; linkedin.com/in/skeeve
> twitter.com/theispguy ; blog: www.theispguy.com
> 
> IP Address Brokering - Introducing sellers and buyers
> 
> On 18 September 2014 09:59, Elvis Velea  wrote:
> Hi Owen,
> 
> what has ARIN to do with the policy in APNIC?
> I could also justify my arguments by saying that the RIPE policy allows up to 
> a /29 per member.. and that policy works very well as well.
> 
> Let's not use other regions' policies to justify disapproval of this policy 
> proposal. Especially when both ARIN and RIPE have different policies that 
> work very well.
> 
> I would like to ask you to explain what kind of errors/difficulties may 
> induce the allocation of a /29 (instead of a /28) in regards to RPKI and 
> DNSSSEC. I do not really understand that part (sorry, I am not very 
> technical). If it's fat-fingering you are talking about, that can happen 
> regardless of the size of the allocation.
> 
> I find it surprising that you oppose to a policy proposal that would allow 
> members of APNIC to use more IPv6 addresses just because the policy does not 
> say 'more than more' (/28s instead of /29s).
> 
> cheers,
> elvis
> 
> On 18/09/14 09:35, Owen DeLong wrote:
>> Absolutely… That is current policy in the ARIN region and it is working well.
>> 
>> The reality is that the amount saved by doing non-nibble boundary 
>> allocations is insignificant compared to the likely increase in human 
>> factors related errors induced and other varieties of inconvenience (RPKI 
>> difficulties, DNSSEC difficulties, etc.)
>> 
>> In reality, there are probably well under 1,000,000 organizations that could 
>> justify more than a /28 (i.e. a /24) world wide. Probably at most a few 
>> million ISPs that would be able to justify more than a /32 (i.e. a /28, 
>> serving more than 50,000 customers), I think we’re fine.
>> 
>> If it turns out I’m wrong and we burn through 2000::/3 this way in less than 
>> 50 years, than I will happily admit it and help anyone who is interested 
>> draft more restrictive policies for the remaining untouched

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

2014-09-17 Thread Skeeve Stevens

Ok, thinking about this some more, I am still conflicted.

There are two schools here... simplicity and conservation.

I think worrying about conservation is important.  But are we trying to
converse needlessly?

If we think we will be using v6 in 20 years, I think we are kidding
ourselves.  With the IoE/IoT, the consumption of address space is going to
accelerate in a huge way.  If we're not thinking about what is after IPv6,
then we're doing ourselves a disservice anyway. But that is the future, and
extremely difficult to predict in this area.

I think simplicity is better in this case... except if it is not really
simple.  If we have to alter a significant amount of policy to make it
simpler, then it isn't really simple.

The question is, how critical is this at the moment?  I'd like to see thing
simpler, but I'd like to know how complex it would be to implement it -
correctly.




...Skeeve

*Skeeve Stevens - Senior IP Broker*
*v4Now - *an eintellego Networks service
ske...@v4now.com ; www.v4now.com

Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve

facebook.com/v4now ;  
linkedin.com/in/skeeve

twitter.com/theispguy ; blog: www.theispguy.com


IP Address Brokering - Introducing sellers and buyers

On 18 September 2014 12:02, Skeeve Stevens  wrote:

> Elvis,
>
> Owens position has been quite simply explained.
>
> He does NOT oppose the increase in the size of the allocation just
> just wants it done more cleanly.
>
> Deans argument is that this will potentially waste additional space.
>
> I see, and actually agree with both positions...   I like to conserve
> address space, but Owens point is very valid... even if 1 million
> organisations took a /28, it would still make minimal impact on the address
> space over a significant period.
>
> But, planning for the future is something we should keep in our mind...
> but, not at the detriment of todays operations.
>
> His point of the number of name servers for reverse delegation for a /29
> being 8 and a /28 being 1 is quite a compelling reason to increase the
> default 'larger' allocation to /28.
>
> So... balancing the two.. I support increasing the standard large
> allocation to a /28.
>
>
> ...Skeeve
>
> *Skeeve Stevens - Senior IP Broker*
> *v4Now - *an eintellego Networks service
> ske...@v4now.com ; www.v4now.com
>
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
>
> facebook.com/v4now ;  
> linkedin.com/in/skeeve
>
> twitter.com/theispguy ; blog: www.theispguy.com
>
>
> IP Address Brokering - Introducing sellers and buyers
>
> On 18 September 2014 09:59, Elvis Velea  wrote:
>
>>  Hi Owen,
>>
>> what has ARIN to do with the policy in APNIC?
>> I could also justify my arguments by saying that the RIPE policy allows
>> up to a /29 per member.. and that policy works very well as well.
>>
>> Let's not use other regions' policies to justify disapproval of this
>> policy proposal. Especially when both ARIN and RIPE have different policies
>> that work very well.
>>
>> I would like to ask you to explain what kind of errors/difficulties may
>> induce the allocation of a /29 (instead of a /28) in regards to RPKI and
>> DNSSSEC. I do not really understand that part (sorry, I am not very
>> technical). If it's fat-fingering you are talking about, that can happen
>> regardless of the size of the allocation.
>>
>> I find it surprising that you oppose to a policy proposal that would
>> allow members of APNIC to use more IPv6 addresses just because the policy
>> does not say 'more than more' (/28s instead of /29s).
>>
>> cheers,
>> elvis
>>
>> On 18/09/14 09:35, Owen DeLong wrote:
>>
>> Absolutely… That is current policy in the ARIN region and it is working
>> well.
>>
>>  The reality is that the amount saved by doing non-nibble boundary
>> allocations is insignificant compared to the likely increase in human
>> factors related errors induced and other varieties of inconvenience (RPKI
>> difficulties, DNSSEC difficulties, etc.)
>>
>>  In reality, there are probably well under 1,000,000 organizations that
>> could justify more than a /28 (i.e. a /24) world wide. Probably at most a
>> few million ISPs that would be able to justify more than a /32 (i.e. a /28,
>> serving more than 50,000 customers), I think we’re fine.
>>
>>  If it turns out I’m wrong and we burn through 2000::/3 this way in less
>> than 50 years, than I will happily admit it and help anyone who is
>> interested draft more restrictive policies for the remaining untouched ~3/4
>> of IPv6 address space.
>>
>>  So far, we haven’t even managed to polish off a /12 in any region.
>>
>>  Owen
>>
>>  On Sep 17, 2014, at 4:07 PM, Elvis Velea  wrote:
>>
>>  Hi Owen and Mike,
>>
>> can you explain why /28 and not /29?
>>
>> Why waste so much and use only nibble boundaries? What would you accept
>> if someone needs more than a /28, allocation of a /24?
>>
>> Kind regards,
>> Elvis
>>
>> On 18/09/14 06:24, HENDERSON M

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size

2014-09-17 Thread Tomohiro -INSTALLER- Fujisaki/藤崎智宏


Hi Owen,

Thank you again!

From: Owen DeLong 
Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 
default allocation size
Date: Wed, 17 Sep 2014 11:16:04 -0700

 | Yes, I still feel it misses my point completely.

Oh sorry, but I just would like to ask you, your first point, which
you wrote as yours and Dean's opposing view. That is,

 | > |  1.  unrestricted issuance of /29s to every organization regardless 
of needs.

My previous reply is just only for this point.

I wrote my standpoint for extending allocation to /28 in another mail.

Yours Sincerely,
--
Tomohiro Fujisaki


From: Owen DeLong 
Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 
default allocation size
Date: Wed, 17 Sep 2014 11:16:04 -0700

 | Yes, I still feel it misses my point completely.
 | 
 | I have no problem with expanding the existing reservations which are bounded 
at /29 to /29.
 | 
 | I don’t want to see us move the default allocation in the sparse allocation 
world to larger than /32. Larger than /32 should require additional 
justification for those blocks.
 | 
 | Further, I don’t want to see us creating a default at a non-nibble boundary. 
For organizations that show need for larger than a /32, I would support a 
default of /28, but will continue to oppose a default expansion to /29.
 | 
 | Owen
 | 
 | On Sep 16, 2014, at 6:59 PM, (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) 
 wrote:
 | 
 | > 
 | > Hi,
 | > 
 | > Thank you so much for your comments.
 | > 
 | > Here, just I would like to confirm,
 | > 
 | > |  1.  unrestricted issuance of /29s to every organization regardless 
of needs.
 | > 
 | > I've added some texts that LIRs would like to to obtain a additional
 | > block larger than /32 need to demonstrate their needs in version 3
 | > (prop-111-v003).
 | > 
 | >> From the mail I sent on 1st August:
 | > |
 | > | I submitted revised version of:
 | > | “prop-111: Request-based expansion of IPv6 default allocation size"
 | > | 
 | > | At the last policy sig discussion, I got concern about address allocation
 | > | without any constraint, and some criteria should be added to expand the
 | > | block size.
 | > | 
 | > | In this revised proposal, I added the requirement to demonstrate need
 | > | for both initial and subsequent allocations to reflect such opinions.
 | > | 
 | > | For initial allocation:
 | > | >  The organizations
 | > | >  can receive up to /29 by providing utilization information of the 
whole
 | > | >  address space.
 | > | 
 | > | For subsequent allocation:
 | > | >  LIRs that hold one or more IPv6 allocations are able to request
 | > | >  extension of each of these allocations up to a /29 without meeting
 | > | >  the utilization rate for subsequent allocation by explaining
 | > | >  how the whole address space will be used.
 | > 
 | > # The wording is slightly different from latest (v004) version.
 | > 
 | > Do you think corrent text is not enough?
 | > 
 | > Yours Sincerely,
 | > --
 | > Tomohiro Fujisaki
 | > *  sig-policy:  APNIC SIG on resource management policy
   *
 | > ___
 | > sig-policy mailing list
 | > sig-policy@lists.apnic.net
 | > http://mailman.apnic.net/mailman/listinfo/sig-policy
 | 
 | 
 | 
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] Crowd Sourcing for Translation

2014-09-17 Thread Skeeve Stevens

Based on a discussion at APNIC 38 regarding translation inside APNIC,
specifically related to barriers to involvement in the Policy Development
Process.

Some services for stakeholders to consider.

http://www.oneskyapp.com/translation-management/manage-global-content/

http://www.crosslang.com/en/translation-management/crowdsourcing-platforms

https://www.getlocalization.com/

http://www.moravia.com/en/services/managed-services/multilingual-crowdsourcing/

The last one, Moravia has 80% of crowd sourced projects within 24 hours...

There is no reason that translation has to be done by the RIR community
themselves, but by the wider world... surely the cost in this would be much
cheaper.



...Skeeve

*Skeeve Stevens - *eintellego Networks Pty Ltd
ske...@eintellegonetworks.com ; www.eintellegonetworks.com

Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve

facebook.com/eintellegonetworks ;  
linkedin.com/in/skeeve

experts360: https://expert360.com/profile/d54a9

twitter.com/theispguy ; blog: www.theispguy.com


The Experts Who The Experts Call
Juniper - Cisco - Cloud - Consulting - IPv4 Brokering
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

2014-09-17 Thread Tomohiro -INSTALLER- Fujisaki/藤崎智宏

Hi Skeeve,

Thank you for your comment!

From: Skeeve Stevens 
Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 
default allocation size (SECURITY=UNCLASSIFIED)
Date: Thu, 18 Sep 2014 12:02:43 +1000

 | So... balancing the two.. I support increasing the standard large
 | allocation to a /28.

I have two concerns. I'm sorry for repeating these.

1. LIRs in legacy space, who has been tackling IPv6 deployment from
   the early stage could not expand their address space to /28. I
   think it's not fair.

2. If we employ 'nibble boundary' allocation for technical reasons,
   the additional subsequent allocation should be /24, /20, and so on.
   It might be meaningless if only first allocation aligns.  To do
   that, I think we need difference proposal since there will be so
   big changes in our policy.

And one more, ARIN implements totally different address allocation
scheme, which discussed also in our APNIC region as prop-098. I'm not
sure but nibble boundary allocation scheme will be suitable under that
policy.

Yours Sincerely,
--
Tomohiro Fujisaki

From: Skeeve Stevens 
Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 
default allocation size (SECURITY=UNCLASSIFIED)
Date: Thu, 18 Sep 2014 12:02:43 +1000

 | Elvis,
 | 
 | Owens position has been quite simply explained.
 | 
 | He does NOT oppose the increase in the size of the allocation just just
 | wants it done more cleanly.
 | 
 | Deans argument is that this will potentially waste additional space.
 | 
 | I see, and actually agree with both positions...   I like to conserve
 | address space, but Owens point is very valid... even if 1 million
 | organisations took a /28, it would still make minimal impact on the address
 | space over a significant period.
 | 
 | But, planning for the future is something we should keep in our mind...
 | but, not at the detriment of todays operations.
 | 
 | His point of the number of name servers for reverse delegation for a /29
 | being 8 and a /28 being 1 is quite a compelling reason to increase the
 | default 'larger' allocation to /28.
 | 
 | So... balancing the two.. I support increasing the standard large
 | allocation to a /28.
 | 
 | 
 | ...Skeeve
 | 
 | *Skeeve Stevens - Senior IP Broker*
 | *v4Now - *an eintellego Networks service
 | ske...@v4now.com ; www.v4now.com
 | 
 | Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
 | 
 | facebook.com/v4now ;  
 | linkedin.com/in/skeeve
 | 
 | twitter.com/theispguy ; blog: www.theispguy.com
 | 
 | 
 | IP Address Brokering - Introducing sellers and buyers
 | 
 | On 18 September 2014 09:59, Elvis Velea  wrote:
 | 
 | >  Hi Owen,
 | >
 | > what has ARIN to do with the policy in APNIC?
 | > I could also justify my arguments by saying that the RIPE policy allows up
 | > to a /29 per member.. and that policy works very well as well.
 | >
 | > Let's not use other regions' policies to justify disapproval of this
 | > policy proposal. Especially when both ARIN and RIPE have different policies
 | > that work very well.
 | >
 | > I would like to ask you to explain what kind of errors/difficulties may
 | > induce the allocation of a /29 (instead of a /28) in regards to RPKI and
 | > DNSSSEC. I do not really understand that part (sorry, I am not very
 | > technical). If it's fat-fingering you are talking about, that can happen
 | > regardless of the size of the allocation.
 | >
 | > I find it surprising that you oppose to a policy proposal that would allow
 | > members of APNIC to use more IPv6 addresses just because the policy does
 | > not say 'more than more' (/28s instead of /29s).
 | >
 | > cheers,
 | > elvis
 | >
 | > On 18/09/14 09:35, Owen DeLong wrote:
 | >
 | > Absolutely… That is current policy in the ARIN region and it is working
 | > well.
 | >
 | >  The reality is that the amount saved by doing non-nibble boundary
 | > allocations is insignificant compared to the likely increase in human
 | > factors related errors induced and other varieties of inconvenience (RPKI
 | > difficulties, DNSSEC difficulties, etc.)
 | >
 | >  In reality, there are probably well under 1,000,000 organizations that
 | > could justify more than a /28 (i.e. a /24) world wide. Probably at most a
 | > few million ISPs that would be able to justify more than a /32 (i.e. a /28,
 | > serving more than 50,000 customers), I think we’re fine.
 | >
 | >  If it turns out I’m wrong and we burn through 2000::/3 this way in less
 | > than 50 years, than I will happily admit it and help anyone who is
 | > interested draft more restrictive policies for the remaining untouched ~3/4
 | > of IPv6 address space.
 | >
 | >  So far, we haven’t even managed to polish off a /12 in any region.
 | >
 | >  Owen
 | >
 | >  On Sep 17, 2014, at 4:07 PM, Elvis Velea  wrote:
 | >
 | >  Hi Owen and Mike,
 | >
 | > can you explain why /28 and not /29?
 | >
 | > Why waste so much and use only nibble boundaries? What would you accept

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

2014-09-17 Thread Skeeve Stevens

Elvis,

Owens position has been quite simply explained.

He does NOT oppose the increase in the size of the allocation just just
wants it done more cleanly.

Deans argument is that this will potentially waste additional space.

I see, and actually agree with both positions...   I like to conserve
address space, but Owens point is very valid... even if 1 million
organisations took a /28, it would still make minimal impact on the address
space over a significant period.

But, planning for the future is something we should keep in our mind...
but, not at the detriment of todays operations.

His point of the number of name servers for reverse delegation for a /29
being 8 and a /28 being 1 is quite a compelling reason to increase the
default 'larger' allocation to /28.

So... balancing the two.. I support increasing the standard large
allocation to a /28.


...Skeeve

*Skeeve Stevens - Senior IP Broker*
*v4Now - *an eintellego Networks service
ske...@v4now.com ; www.v4now.com

Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve

facebook.com/v4now ;  
linkedin.com/in/skeeve

twitter.com/theispguy ; blog: www.theispguy.com


IP Address Brokering - Introducing sellers and buyers

On 18 September 2014 09:59, Elvis Velea  wrote:

>  Hi Owen,
>
> what has ARIN to do with the policy in APNIC?
> I could also justify my arguments by saying that the RIPE policy allows up
> to a /29 per member.. and that policy works very well as well.
>
> Let's not use other regions' policies to justify disapproval of this
> policy proposal. Especially when both ARIN and RIPE have different policies
> that work very well.
>
> I would like to ask you to explain what kind of errors/difficulties may
> induce the allocation of a /29 (instead of a /28) in regards to RPKI and
> DNSSSEC. I do not really understand that part (sorry, I am not very
> technical). If it's fat-fingering you are talking about, that can happen
> regardless of the size of the allocation.
>
> I find it surprising that you oppose to a policy proposal that would allow
> members of APNIC to use more IPv6 addresses just because the policy does
> not say 'more than more' (/28s instead of /29s).
>
> cheers,
> elvis
>
> On 18/09/14 09:35, Owen DeLong wrote:
>
> Absolutely… That is current policy in the ARIN region and it is working
> well.
>
>  The reality is that the amount saved by doing non-nibble boundary
> allocations is insignificant compared to the likely increase in human
> factors related errors induced and other varieties of inconvenience (RPKI
> difficulties, DNSSEC difficulties, etc.)
>
>  In reality, there are probably well under 1,000,000 organizations that
> could justify more than a /28 (i.e. a /24) world wide. Probably at most a
> few million ISPs that would be able to justify more than a /32 (i.e. a /28,
> serving more than 50,000 customers), I think we’re fine.
>
>  If it turns out I’m wrong and we burn through 2000::/3 this way in less
> than 50 years, than I will happily admit it and help anyone who is
> interested draft more restrictive policies for the remaining untouched ~3/4
> of IPv6 address space.
>
>  So far, we haven’t even managed to polish off a /12 in any region.
>
>  Owen
>
>  On Sep 17, 2014, at 4:07 PM, Elvis Velea  wrote:
>
>  Hi Owen and Mike,
>
> can you explain why /28 and not /29?
>
> Why waste so much and use only nibble boundaries? What would you accept if
> someone needs more than a /28, allocation of a /24?
>
> Kind regards,
> Elvis
>
> On 18/09/14 06:24, HENDERSON MIKE, MR wrote:
>
>  Just for the avoidance of any doubt, I completely agree with Owen's
> position on this matter.
>
> To reiterate:
> · I can accept that sparse allocations already made on /29
> boundaries can be expanded to fill the entire /29, if there is no room to
> expand them to a /28.
> · I do not agree that any new/ 29 allocations should be made, the
> next size above /32  should be /28
>
>
> Regards
>
>
> Mike
>
> -Original Message-
> From: sig-policy-boun...@lists.apnic.net [
> mailto:sig-policy-boun...@lists.apnic.net
> ] On Behalf Of Owen DeLong
> Sent: Thursday, 18 September 2014 6:16 a.m.
> To: "(Tomohiro -INSTALLER- Fujisaki/藤崎 智宏)"
> Cc: sig-policy@lists.apnic.net
> Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6
> default allocation size
>
> Yes, I still feel it misses my point completely.
>
> I have no problem with expanding the existing reservations which are
> bounded at /29 to /29.
>
> I don’t want to see us move the default allocation in the sparse
> allocation world to larger than /32. Larger than /32 should require
> additional justification for those blocks.
>
> Further, I don’t want to see us creating a default at a non-nibble
> boundary. For organizations that show need for larger than a /32, I would
> support a default of /28, but will continue to oppose a default expansion
> to /29.
>
> Owen
>
> On Sep 16, 2014, at 6:59 PM, (Tomohiro -INSTALLER- Fu

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size

2014-09-17 Thread Tomohiro -INSTALLER- Fujisaki/藤崎智宏


Hi Elvis,

Thnak you for your comments!

 | This proposal has been already made and approved/implemented (May2012)
 | in the RIPE Region and as far as I can see, it was a good proposal and
 | it has not caused any problems.
 | 
 | The /29s are reserved anyway, why not allow the LIRs to use them if
 | they need a larger/additional block?
 | From my experience, some LIRs may need more than just the /32 used for
 | their main/primary network in order to test in a separate network a
 | transitioning protocol or equipment. For this reason only I think that
 | keeping the /29 reserved and not allocated is a waste.

I'll introduce situation of ripe region in my presentation.

Yours Sincerely,
--
Tomohiro Fujisaki

From: Elvis Velea 
Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 
default allocation size
Date: Wed, 17 Sep 2014 11:44:42 +1000

 | Hi,
 | 
 | you have my support.
 | 
 | This proposal has been already made and approved/implemented (May2012)
 | in the RIPE Region and as far as I can see, it was a good proposal and
 | it has not caused any problems.
 | 
 | The /29s are reserved anyway, why not allow the LIRs to use them if
 | they need a larger/additional block?
 | From my experience, some LIRs may need more than just the /32 used for
 | their main/primary network in order to test in a separate network a
 | transitioning protocol or equipment. For this reason only I think that
 | keeping the /29 reserved and not allocated is a waste.
 | 
 | Offcourse, the /29 allocation should be made upon request of the
 | LIR. If the LIR needs it, he can just request it but not have to send
 | any kind of justification (other than - I need/want the extension of
 | the allocation from /32 to /29)
 | 
 | my 2 cents,
 | elvis
 | 
 | On 17/09/14 10:26, Masato Yamanishi wrote:
 | > Dear SIG members
 | >
 | > A new version of the proposal "prop-111: Request-based expansion of
 | > IPv6
 | > default allocation size has been sent to the Policy SIG for review.
 | >
 | > There are changes to section 4. Proposed policy solution only.
 | >
 | > Information about earlier versions is available from:
 | >
 | > http://www.apnic.net/policy/proposals/prop-111
 | >
 | > You are encouraged to express your views on the proposal:
 | >
 | >  - Do you support or oppose the proposal?
 | >  - Is there anything in the proposal that is not clear?
 | >  - What change could be made to this proposal to make it more effective?
 | >
 | > Please find the text of the proposal below.
 | >
 | > Kind Regards,
 | >
 | > Andy and Masato
 | >
 | >
 | >
 | >
 | --
 | > prop-111-v004 Request-based expansion of IPv6 default allocation size
 | >
 | --
 | >
 | > Author: Tomohiro Fujisaki
 | > fujis...@syce.net 
 | >
 | >
 | > 1. Problem statement
 | > 
 | >
 | > IPv6 minimum allocation size to LIRs is defined as /32 in the "IPv6
 | > address allocation and assignment policy"[1]. It's better to
 | > expand this minimum allocation size up to /29 (/32 - /29) since:
 | >
 | > - Before sparse allocation mechanism implemented in late 2006, /29
 | > was reserved for all /32 allocations by sequential allocation
 | > method made from those old /23 blocks. These reserved blocks
 | > might be kept unused in the future.
 | >
 | > - Sparse allocation mechanism was implemented in late 2006 with a
 | > /12 allocation from the IANA. Under the sparse allocation
 | > mechanism, there is no reservation size defined, and the space
 | > between allocations continues to change, depending on the
 | > remaining free pool available in APNIC.
 | >
 | > However, the "APNIC guidelines for IPv6 allocation and
 | > assignment requests"[2] stated:
 | >
 | > "In accordance with APNIC's "IPv6 address allocation and
 | > assignment policy", where possible, subsequent delegations to the
 | > same resource holder are made from an adjacent address block by
 | > growing the delegation into the free space remaining, unless
 | > disaggregated ranges are requested for multiple discrete
 | > networks."
 | >
 | > So, it is expected that allocation up to /29 is guaranteed for
 | > consistency with allocations above. Based on the current
 | > situation, contiguous allocation of /29 can still be accommodated
 | > even under the sparse allocation mechanism (Current /32
 | > allocations from the /12 block can grow up to /24 at this stage).
 | >
 | > - After amended HD Ratio (0.94) and base calculation size (/56) was
 | > introduced (prop-031 and prop-033), to obtain address blocks larger
 | > than /32 and to request additional address blocks became harder
 | > especially for small and middle size ISPs.
 | >
 | > - For traffic control purpose, some LIRs announce address blocks
 | > longer than /32 (e.g. /35). However, some ISPs may set filters to
 | > block address size longer than /32 since some filtering

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

2014-09-17 Thread Owen DeLong

On Sep 17, 2014, at 4:59 PM, Elvis Velea  wrote:

> Hi Owen,
> 
> what has ARIN to do with the policy in APNIC?

Nothing at all… Simply pointing out that there is experience with such a policy 
and that the experience has been positive.

> I could also justify my arguments by saying that the RIPE policy allows up to 
> a /29 per member.. and that policy works very well as well.

Fair enough. So if policy up to a /29 works well and policy allowing /28s works 
well, why not favor /28s over /29s? What is the advantage of /29s?

> Let's not use other regions' policies to justify disapproval of this policy 
> proposal. Especially when both ARIN and RIPE have different policies that 
> work very well.

I’m not favoring disapproval of this policy. I’m favoring modifying it to allow 
/28s.

> I would like to ask you to explain what kind of errors/difficulties may 
> induce the allocation of a /29 (instead of a /28) in regards to RPKI and 
> DNSSSEC. I do not really understand that part (sorry, I am not very 
> technical). If it's fat-fingering you are talking about, that can happen 
> regardless of the size of the allocation.

When computing net masks and which networks are within/outside of a given 
prefix, things which fall on nibble boundaries are readily visible to human 
eyes.

If I have a prefix, for example, of 2620:0:930::/48, I know that anything which 
starts with 2620:0:930:… is within that prefix.

If I make it a /29, then instead of 2620:0:930:… it becomes 2620:0:930:0… 
through 2620:0:930:7…

It’s even worse for 28s vs. 29s… For example, 2601:5ca0::/28 includes 
everything that starts with 2601:5ca?:…
However, 2601:5ca8::/29 is everything from 260:15ca8:… thru 2601:5caf:…

Delegating a /29 requires 8 NS records per name server serving the ip6.arpa 
zones in question.
Delegating a /28 requires 1.

I believe that RPKI has similar issues to DNS.

> I find it surprising that you oppose to a policy proposal that would allow 
> members of APNIC to use more IPv6 addresses just because the policy does not 
> say 'more than more' (/28s instead of /29s).

Perhaps it is because you are not technical and have not had an operational 
role and experience.

Owen

> 
> cheers,
> elvis
> 
> On 18/09/14 09:35, Owen DeLong wrote:
>> Absolutely… That is current policy in the ARIN region and it is working well.
>> 
>> The reality is that the amount saved by doing non-nibble boundary 
>> allocations is insignificant compared to the likely increase in human 
>> factors related errors induced and other varieties of inconvenience (RPKI 
>> difficulties, DNSSEC difficulties, etc.)
>> 
>> In reality, there are probably well under 1,000,000 organizations that could 
>> justify more than a /28 (i.e. a /24) world wide. Probably at most a few 
>> million ISPs that would be able to justify more than a /32 (i.e. a /28, 
>> serving more than 50,000 customers), I think we’re fine.
>> 
>> If it turns out I’m wrong and we burn through 2000::/3 this way in less than 
>> 50 years, than I will happily admit it and help anyone who is interested 
>> draft more restrictive policies for the remaining untouched ~3/4 of IPv6 
>> address space.
>> 
>> So far, we haven’t even managed to polish off a /12 in any region.
>> 
>> Owen
>> 
>> On Sep 17, 2014, at 4:07 PM, Elvis Velea  wrote:
>> 
>>> Hi Owen and Mike,
>>> 
>>> can you explain why /28 and not /29?
>>> 
>>> Why waste so much and use only nibble boundaries? What would you accept if 
>>> someone needs more than a /28, allocation of a /24?
>>> 
>>> Kind regards,
>>> Elvis
>>> 
>>> On 18/09/14 06:24, HENDERSON MIKE, MR wrote:
 Just for the avoidance of any doubt, I completely agree with Owen's 
 position on this matter.

 To reiterate:
 · I can accept that sparse allocations already made on /29 
 boundaries can be expanded to fill the entire /29, if there is no room to 
 expand them to a /28.
 · I do not agree that any new/ 29 allocations should be made, the 
 next size above /32  should be /28

 Regards

 Mike

 -Original Message-
 From: sig-policy-boun...@lists.apnic.net 
 [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Owen DeLong
 Sent: Thursday, 18 September 2014 6:16 a.m.
 To: "(Tomohiro -INSTALLER- Fujisaki/藤崎 智宏)"
 Cc: sig-policy@lists.apnic.net
 Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 
 default allocation size

 Yes, I still feel it misses my point completely.

 I have no problem with expanding the existing reservations which are 
 bounded at /29 to /29.

 I don’t want to see us move the default allocation in the sparse 
 allocation world to larger than /32. Larger than /32 should require 
 additional justification for those blocks.

 Further, I don’t want to see us creating a default at a non-nibble 
 boundary. For organizations that show need for larger t

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

2014-09-17 Thread Elvis Velea

Hi Owen,

what has ARIN to do with the policy in APNIC?
I could also justify my arguments by saying that the RIPE policy allows 
up to a /29 per member.. and that policy works very well as well.

Let's not use other regions' policies to justify disapproval of this 
policy proposal. Especially when both ARIN and RIPE have different 
policies that work very well.

I would like to ask you to explain what kind of errors/difficulties may 
induce the allocation of a /29 (instead of a /28) in regards to RPKI and 
DNSSSEC. I do not really understand that part (sorry, I am not very 
technical). If it's fat-fingering you are talking about, that can happen 
regardless of the size of the allocation.

I find it surprising that you oppose to a policy proposal that would 
allow members of APNIC to use more IPv6 addresses just because the 
policy does not say 'more than more' (/28s instead of /29s).

cheers,
elvis

On 18/09/14 09:35, Owen DeLong wrote:
Absolutely… That is current policy in the ARIN region and it is 
working well.

The reality is that the amount saved by doing non-nibble boundary 
allocations is insignificant compared to the likely increase in human 
factors related errors induced and other varieties of inconvenience 
(RPKI difficulties, DNSSEC difficulties, etc.)

In reality, there are probably well under 1,000,000 organizations that 
could justify more than a /28 (i.e. a /24) world wide. Probably at 
most a few million ISPs that would be able to justify more than a /32 
(i.e. a /28, serving more than 50,000 customers), I think we’re fine.

If it turns out I’m wrong and we burn through 2000::/3 this way in 
less than 50 years, than I will happily admit it and help anyone who 
is interested draft more restrictive policies for the remaining 
untouched ~3/4 of IPv6 address space.

So far, we haven’t even managed to polish off a /12 in any region.

Owen

On Sep 17, 2014, at 4:07 PM, Elvis Velea > wrote:

Hi Owen and Mike,

can you explain why /28 and not /29?

Why waste so much and use only nibble boundaries? What would you 
accept if someone needs more than a /28, allocation of a /24?

Kind regards,
Elvis

On 18/09/14 06:24, HENDERSON MIKE, MR wrote:
Just for the avoidance of any doubt, I completely agree with Owen's 
position on this matter.

To reiterate:
·I can accept that sparse allocations already made on /29 boundaries 
can be expanded to fill the entire /29, if there is no room to 
expand them to a /28.
·I do not agree that any new/ 29 allocations should be made, the 
next size above /32  should be /28

Regards
Mike
-Original Message-
From:sig-policy-boun...@lists.apnic.net[mailto:sig-policy-boun...@lists.apnic.net] 
On Behalf Of Owen DeLong

Sent: Thursday, 18 September 2014 6:16 a.m.
To: "(Tomohiro -INSTALLER- Fujisaki/藤崎智宏)"
Cc:sig-policy@lists.apnic.net
Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of 
IPv6 default allocation size

Yes, I still feel it misses my point completely.
I have no problem with expanding the existing reservations which are 
bounded at /29 to /29.
I don’t want to see us move the default allocation in the sparse 
allocation world to larger than /32. Larger than /32 should require 
additional justification for those blocks.
Further, I don’t want to see us creating a default at a non-nibble 
boundary. For organizations that show need for larger than a /32, I 
would support a default of /28, but will continue to oppose a 
default expansion to /29.

Owen
On Sep 16, 2014, at 6:59 PM, (Tomohiro -INSTALLER- Fujisaki/藤崎智 
宏) mailto:fujis...@syce.net>> wrote:

>
> Hi,
>
> Thank you so much for your comments.
>
> Here, just I would like to confirm,
>
> | 1.unrestricted issuance of /29s to every 
organization regardless of needs.

>
> I've added some texts that LIRs would like to to obtain a additional
> block larger than /32 need to demonstrate their needs in version 3
> (prop-111-v003).
>
>> From the mail I sent on 1st August:
> |
> | I submitted revised version of:
> | “prop-111: Request-based expansion of IPv6 default allocation size"
> |
> | At the last policy sig discussion, I got concern about address
> | allocation without any constraint, and some criteria should be added
> | to expand the block size.
> |
> | In this revised proposal, I added the requirement to demonstrate
> | need for both initial and subsequent allocations to reflect such 
opinions.

> |
> | For initial allocation:
> | > The organizations
> | > can receive up to /29 by providing utilization information of 
the whole

> | > address space.
> |
> | For subsequent allocation:
> | > LIRs that hold one or more IPv6 allocations are able to request
> | > extension of each of these allocations up to a /29 without meeting
> | > the utilization rate for subsequent allocation by explaining
> | > how the whole address space will be used.
>
> # The wording is slightly different from latest (v004) version.
>
> Do you think corrent text is not enough?

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

2014-09-17 Thread Dean Pemberton

I am familiar with Owen’s arguments, and he and I have agreed to
disagree in the past many times.
--
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 its potential.


On Thu, Sep 18, 2014 at 9:35 AM, Owen DeLong  wrote:
> Absolutely… That is current policy in the ARIN region and it is working
> well.
>
> The reality is that the amount saved by doing non-nibble boundary
> allocations is insignificant compared to the likely increase in human
> factors related errors induced and other varieties of inconvenience (RPKI
> difficulties, DNSSEC difficulties, etc.)
>
> In reality, there are probably well under 1,000,000 organizations that could
> justify more than a /28 (i.e. a /24) world wide. Probably at most a few
> million ISPs that would be able to justify more than a /32 (i.e. a /28,
> serving more than 50,000 customers), I think we’re fine.
>
> If it turns out I’m wrong and we burn through 2000::/3 this way in less than
> 50 years, than I will happily admit it and help anyone who is interested
> draft more restrictive policies for the remaining untouched ~3/4 of IPv6
> address space.
>
> So far, we haven’t even managed to polish off a /12 in any region.
>
> Owen
>
> On Sep 17, 2014, at 4:07 PM, Elvis Velea  wrote:
>
> Hi Owen and Mike,
>
> can you explain why /28 and not /29?
>
> Why waste so much and use only nibble boundaries? What would you accept if
> someone needs more than a /28, allocation of a /24?
>
> Kind regards,
> Elvis
>
> On 18/09/14 06:24, HENDERSON MIKE, MR wrote:
>
> Just for the avoidance of any doubt, I completely agree with Owen's position
> on this matter.
>
> To reiterate:
> · I can accept that sparse allocations already made on /29
> boundaries can be expanded to fill the entire /29, if there is no room to
> expand them to a /28.
> · I do not agree that any new/ 29 allocations should be made, the
> next size above /32  should be /28
>
>
> Regards
>
>
> Mike
>
> -Original Message-
> From: sig-policy-boun...@lists.apnic.net
> [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Owen DeLong
> Sent: Thursday, 18 September 2014 6:16 a.m.
> To: "(Tomohiro -INSTALLER- Fujisaki/藤崎 智宏)"
> Cc: sig-policy@lists.apnic.net
> Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6
> default allocation size
>
> Yes, I still feel it misses my point completely.
>
> I have no problem with expanding the existing reservations which are bounded
> at /29 to /29.
>
> I don’t want to see us move the default allocation in the sparse allocation
> world to larger than /32. Larger than /32 should require additional
> justification for those blocks.
>
> Further, I don’t want to see us creating a default at a non-nibble boundary.
> For organizations that show need for larger than a /32, I would support a
> default of /28, but will continue to oppose a default expansion to /29.
>
> Owen
>
> On Sep 16, 2014, at 6:59 PM, (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏)
>  wrote:
>
>>
>> Hi,
>>
>> Thank you so much for your comments.
>>
>> Here, just I would like to confirm,
>>
>> |  1.unrestricted issuance of /29s to every
>> organization regardless of needs.
>>
>> I've added some texts that LIRs would like to to obtain a additional
>> block larger than /32 need to demonstrate their needs in version 3
>> (prop-111-v003).
>>
>>> From the mail I sent on 1st August:
>> |
>> | I submitted revised version of:
>> | “prop-111: Request-based expansion of IPv6 default allocation size"
>> |
>> | At the last policy sig discussion, I got concern about address
>> | allocation without any constraint, and some criteria should be added
>> | to expand the block size.
>> |
>> | In this revised proposal, I added the requirement to demonstrate
>> | need for both initial and subsequent allocations to reflect such
>> opinions.
>> |
>> | For initial allocation:
>> | >  The organizations
>> | >  can receive up to /29 by providing utilization information of the
>> whole
>> | >  address space.
>> |
>> | For subsequent allocation:
>> | >  LIRs that hold one or more IPv6 allocations are able to request
>> | >  extension of each of these allocations up to a /29 without
>> meeting
>> | >  the utilization rate for subsequent allocation by explaining
>> | >  how the whole address space will be used.
>>
>> # The wording is slightly different from latest (v004) version.
>>
>> Do you think corrent text is not enough?
>>
>> Yours Sincerely,
>> --
>> Tomohiro Fujisaki
>> *  sig-policy:  APNIC SIG on resource management policy
>> *
>> ___
>> sig-policy mailing list
>> sig-policy@lists.apnic.net
>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>
> *  sig-policy:  APNIC SIG on resource management policy
> *
> ___
> sig-policy mailing list
> sig-policy@l

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

2014-09-17 Thread Owen DeLong

Absolutely… That is current policy in the ARIN region and it is working well.

The reality is that the amount saved by doing non-nibble boundary allocations 
is insignificant compared to the likely increase in human factors related 
errors induced and other varieties of inconvenience (RPKI difficulties, DNSSEC 
difficulties, etc.)

In reality, there are probably well under 1,000,000 organizations that could 
justify more than a /28 (i.e. a /24) world wide. Probably at most a few million 
ISPs that would be able to justify more than a /32 (i.e. a /28, serving more 
than 50,000 customers), I think we’re fine.

If it turns out I’m wrong and we burn through 2000::/3 this way in less than 50 
years, than I will happily admit it and help anyone who is interested draft 
more restrictive policies for the remaining untouched ~3/4 of IPv6 address 
space.

So far, we haven’t even managed to polish off a /12 in any region.

Owen

On Sep 17, 2014, at 4:07 PM, Elvis Velea  wrote:

> Hi Owen and Mike,
> 
> can you explain why /28 and not /29?
> 
> Why waste so much and use only nibble boundaries? What would you accept if 
> someone needs more than a /28, allocation of a /24?
> 
> Kind regards,
> Elvis
> 
> On 18/09/14 06:24, HENDERSON MIKE, MR wrote:
>> Just for the avoidance of any doubt, I completely agree with Owen's position 
>> on this matter.
>>  
>> To reiterate:
>> · I can accept that sparse allocations already made on /29 
>> boundaries can be expanded to fill the entire /29, if there is no room to 
>> expand them to a /28.
>> · I do not agree that any new/ 29 allocations should be made, the 
>> next size above /32  should be /28
>>  
>>  
>> Regards
>>  
>>  
>> Mike
>>  
>> -Original Message-
>> From: sig-policy-boun...@lists.apnic.net 
>> [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Owen DeLong
>> Sent: Thursday, 18 September 2014 6:16 a.m.
>> To: "(Tomohiro -INSTALLER- Fujisaki/藤崎 智宏)"
>> Cc: sig-policy@lists.apnic.net
>> Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 
>> default allocation size
>>  
>> Yes, I still feel it misses my point completely.
>>  
>> I have no problem with expanding the existing reservations which are bounded 
>> at /29 to /29.
>>  
>> I don’t want to see us move the default allocation in the sparse allocation 
>> world to larger than /32. Larger than /32 should require additional 
>> justification for those blocks.
>>  
>> Further, I don’t want to see us creating a default at a non-nibble boundary. 
>> For organizations that show need for larger than a /32, I would support a 
>> default of /28, but will continue to oppose a default expansion to /29.
>>  
>> Owen
>>  
>> On Sep 16, 2014, at 6:59 PM, (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) 
>>  wrote:
>>  
>> >
>> > Hi,
>> >
>> > Thank you so much for your comments.
>> >
>> > Here, just I would like to confirm,
>> >
>> > |  1.unrestricted issuance of /29s to every 
>> > organization regardless of needs.
>> >
>> > I've added some texts that LIRs would like to to obtain a additional
>> > block larger than /32 need to demonstrate their needs in version 3
>> > (prop-111-v003).
>> >
>> >> From the mail I sent on 1st August:
>> > |
>> > | I submitted revised version of:
>> > | “prop-111: Request-based expansion of IPv6 default allocation size"
>> > |
>> > | At the last policy sig discussion, I got concern about address
>> > | allocation without any constraint, and some criteria should be added
>> > | to expand the block size.
>> > |
>> > | In this revised proposal, I added the requirement to demonstrate
>> > | need for both initial and subsequent allocations to reflect such 
>> > opinions.
>> > |
>> > | For initial allocation:
>> > | >  The organizations
>> > | >  can receive up to /29 by providing utilization information of the 
>> > whole
>> > | >  address space.
>> > |
>> > | For subsequent allocation:
>> > | >  LIRs that hold one or more IPv6 allocations are able to request
>> > | >  extension of each of these allocations up to a /29 without meeting
>> > | >  the utilization rate for subsequent allocation by explaining
>> > | >  how the whole address space will be used.
>> >
>> > # The wording is slightly different from latest (v004) version.
>> >
>> > Do you think corrent text is not enough?
>> >
>> > Yours Sincerely,
>> > --
>> > Tomohiro Fujisaki
>> > *  sig-policy:  APNIC SIG on resource management policy
>> >*
>> > ___
>> > sig-policy mailing list
>> > sig-policy@lists.apnic.net
>> > http://mailman.apnic.net/mailman/listinfo/sig-policy
>>  
>> *  sig-policy:  APNIC SIG on resource management policy  
>>  *
>> ___
>> sig-policy mailing list
>> sig-policy@lists.apnic.net
>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>> The information contained in this Internet Email message is inten

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

2014-09-17 Thread Dean Pemberton

That's one of my concerns Elvis...

If we accept the argument that we'll only allocate on hex-char
boundaries, then it means that we're wasting more and more addresses
as time goes by.  We'll be having this discussion in a little while
about /24s rather than /27s then it will be /20s rather than..

I once had someone swear that they would never use the 'letters' in
the IPv6 address because it made the addresses look 'strange'.  They
ended up wasting over a third of their address space.  What is being
suggested here is almost as crazy.

Regards,
Dean
--
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 its potential.


On Thu, Sep 18, 2014 at 9:07 AM, Elvis Velea  wrote:
> Hi Owen and Mike,
>
> can you explain why /28 and not /29?
>
> Why waste so much and use only nibble boundaries? What would you accept if
> someone needs more than a /28, allocation of a /24?
>
> Kind regards,
> Elvis
>
>
> On 18/09/14 06:24, HENDERSON MIKE, MR wrote:
>
> Just for the avoidance of any doubt, I completely agree with Owen's position
> on this matter.
>
>
>
> To reiterate:
>
> · I can accept that sparse allocations already made on /29
> boundaries can be expanded to fill the entire /29, if there is no room to
> expand them to a /28.
>
> · I do not agree that any new/ 29 allocations should be made, the
> next size above /32  should be /28
>
>
>
>
>
> Regards
>
>
>
>
>
> Mike
>
>
>
> -Original Message-
> From: sig-policy-boun...@lists.apnic.net
> [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Owen DeLong
> Sent: Thursday, 18 September 2014 6:16 a.m.
> To: "(Tomohiro -INSTALLER- Fujisaki/藤崎 智宏)"
> Cc: sig-policy@lists.apnic.net
> Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6
> default allocation size
>
>
>
> Yes, I still feel it misses my point completely.
>
>
>
> I have no problem with expanding the existing reservations which are bounded
> at /29 to /29.
>
>
>
> I don’t want to see us move the default allocation in the sparse allocation
> world to larger than /32. Larger than /32 should require additional
> justification for those blocks.
>
>
>
> Further, I don’t want to see us creating a default at a non-nibble boundary.
> For organizations that show need for larger than a /32, I would support a
> default of /28, but will continue to oppose a default expansion to /29.
>
>
>
> Owen
>
>
>
> On Sep 16, 2014, at 6:59 PM, (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏)
>  wrote:
>
>
>
>>
>
>> Hi,
>
>>
>
>> Thank you so much for your comments.
>
>>
>
>> Here, just I would like to confirm,
>
>>
>
>> |  1.unrestricted issuance of /29s to every
>> organization regardless of needs.
>
>>
>
>> I've added some texts that LIRs would like to to obtain a additional
>
>> block larger than /32 need to demonstrate their needs in version 3
>
>> (prop-111-v003).
>
>>
>
>>> From the mail I sent on 1st August:
>
>> |
>
>> | I submitted revised version of:
>
>> | “prop-111: Request-based expansion of IPv6 default allocation size"
>
>> |
>
>> | At the last policy sig discussion, I got concern about address
>
>> | allocation without any constraint, and some criteria should be added
>
>> | to expand the block size.
>
>> |
>
>> | In this revised proposal, I added the requirement to demonstrate
>
>> | need for both initial and subsequent allocations to reflect such
>> opinions.
>
>> |
>
>> | For initial allocation:
>
>> | >  The organizations
>
>> | >  can receive up to /29 by providing utilization information of the
>> whole
>
>> | >  address space.
>
>> |
>
>> | For subsequent allocation:
>
>> | >  LIRs that hold one or more IPv6 allocations are able to request
>
>> | >  extension of each of these allocations up to a /29 without
>> meeting
>
>> | >  the utilization rate for subsequent allocation by explaining
>
>> | >  how the whole address space will be used.
>
>>
>
>> # The wording is slightly different from latest (v004) version.
>
>>
>
>> Do you think corrent text is not enough?
>
>>
>
>> Yours Sincerely,
>
>> --
>
>> Tomohiro Fujisaki
>
>> *  sig-policy:  APNIC SIG on resource management policy
>> *
>
>> ___
>
>> sig-policy mailing list
>
>> sig-policy@lists.apnic.net
>
>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>
>
>
> *  sig-policy:  APNIC SIG on resource management policy
> *
>
> ___
>
> sig-policy mailing list
>
> sig-policy@lists.apnic.net
>
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>
> The information contained in this Internet Email message is intended for the
> addressee only and may contain privileged information, but not necessarily
> the official views or opinions of the New Zealand Defence Force.  If you are
> not the intended recipient you must not use, disclose, copy or
> distribute this me

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

2014-09-17 Thread Elvis Velea

Hi Owen and Mike,

can you explain why /28 and not /29?

Why waste so much and use only nibble boundaries? What would you accept 
if someone needs more than a /28, allocation of a /24?

Kind regards,
Elvis

On 18/09/14 06:24, HENDERSON MIKE, MR wrote:

Just for the avoidance of any doubt, I completely agree with Owen's 
position on this matter.

To reiterate:

·I can accept that sparse allocations already made on /29 boundaries 
can be expanded to fill the entire /29, if there is no room to expand 
them to a /28.

·I do not agree that any new/ 29 allocations should be made, the next 
size above /32  should be /28

Regards

Mike

-Original Message-
From: sig-policy-boun...@lists.apnic.net 
[mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Owen DeLong

Sent: Thursday, 18 September 2014 6:16 a.m.
To: "(Tomohiro -INSTALLER- Fujisaki/)"
Cc: sig-policy@lists.apnic.net
Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of 
IPv6 default allocation size

Yes, I still feel it misses my point completely.

I have no problem with expanding the existing reservations which are 
bounded at /29 to /29.

I don't want to see us move the default allocation in the sparse 
allocation world to larger than /32. Larger than /32 should require 
additional justification for those blocks.

Further, I don't want to see us creating a default at a non-nibble 
boundary. For organizations that show need for larger than a /32, I 
would support a default of /28, but will continue to oppose a default 
expansion to /29.

Owen

On Sep 16, 2014, at 6:59 PM, (Tomohiro -INSTALLER- Fujisaki/) 
mailto:fujis...@syce.net>> wrote:

>

> Hi,

>

> Thank you so much for your comments.

>

> Here, just I would like to confirm,

>

> |  1. unrestricted issuance of /29s to every organization 
regardless of needs.

>

> I've added some texts that LIRs would like to to obtain a additional

> block larger than /32 need to demonstrate their needs in version 3

> (prop-111-v003).

>

>> From the mail I sent on 1st August:

> |

> | I submitted revised version of:

> | "prop-111: Request-based expansion of IPv6 default allocation 
size"

> |

> | At the last policy sig discussion, I got concern about address

> | allocation without any constraint, and some criteria should be added

> | to expand the block size.

> |

> | In this revised proposal, I added the requirement to demonstrate

> | need for both initial and subsequent allocations to reflect such 
opinions.

> |

> | For initial allocation:

> | >  The organizations

> | >  can receive up to /29 by providing utilization information 
of the whole

> | >  address space.

> |

> | For subsequent allocation:

> | >  LIRs that hold one or more IPv6 allocations are able to request

> | >  extension of each of these allocations up to a /29 without 
meeting

> | >  the utilization rate for subsequent allocation by explaining

> | >  how the whole address space will be used.

>

> # The wording is slightly different from latest (v004) version.

>

> Do you think corrent text is not enough?

>

> Yours Sincerely,

> --

> Tomohiro Fujisaki

> *  sig-policy:  APNIC SIG on resource management 
policy   *

> ___

> sig-policy mailing list

> sig-policy@lists.apnic.net 

> http://mailman.apnic.net/mailman/listinfo/sig-policy

*  sig-policy:  APNIC SIG on resource management 
policy   *

___

sig-policy mailing list

sig-policy@lists.apnic.net 

http://mailman.apnic.net/mailman/listinfo/sig-policy

The information contained in this Internet Email message is intended 
for the addressee only and may contain privileged information, but not 
necessarily the official views or opinions of the New Zealand Defence 
Force.  If you are not the intended recipient you must not use, 
disclose, copy or
distribute this message or the information in it.  If you have 
received this message in error, please Email or telephone the sender 
immediately.

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

2014-09-17 Thread HENDERSON MIKE, MR

Just for the avoidance of any doubt, I completely agree with Owen's position on 
this matter.

To reiterate:

* I can accept that sparse allocations already made on /29 boundaries 
can be expanded to fill the entire /29, if there is no room to expand them to a 
/28.

* I do not agree that any new/ 29 allocations should be made, the next 
size above /32  should be /28

Regards

Mike

-Original Message-
From: sig-policy-boun...@lists.apnic.net 
[mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Owen DeLong
Sent: Thursday, 18 September 2014 6:16 a.m.
To: "(Tomohiro -INSTALLER- Fujisaki/藤崎 智宏)"
Cc: sig-policy@lists.apnic.net
Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 
default allocation size

Yes, I still feel it misses my point completely.

I have no problem with expanding the existing reservations which are bounded at 
/29 to /29.

I don’t want to see us move the default allocation in the sparse allocation 
world to larger than /32. Larger than /32 should require additional 
justification for those blocks.

Further, I don’t want to see us creating a default at a non-nibble boundary. 
For organizations that show need for larger than a /32, I would support a 
default of /28, but will continue to oppose a default expansion to /29.

Owen

On Sep 16, 2014, at 6:59 PM, (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) 
mailto:fujis...@syce.net>> wrote:

>

> Hi,

>

> Thank you so much for your comments.

>

> Here, just I would like to confirm,

>

> |  1.unrestricted issuance of /29s to every organization 
> regardless of needs.

>

> I've added some texts that LIRs would like to to obtain a additional

> block larger than /32 need to demonstrate their needs in version 3

> (prop-111-v003).

>

>> From the mail I sent on 1st August:

> |

> | I submitted revised version of:

> | “prop-111: Request-based expansion of IPv6 default allocation size"

> |

> | At the last policy sig discussion, I got concern about address

> | allocation without any constraint, and some criteria should be added

> | to expand the block size.

> |

> | In this revised proposal, I added the requirement to demonstrate

> | need for both initial and subsequent allocations to reflect such opinions.

> |

> | For initial allocation:

> | >  The organizations

> | >  can receive up to /29 by providing utilization information of the 
> whole

> | >  address space.

> |

> | For subsequent allocation:

> | >  LIRs that hold one or more IPv6 allocations are able to request

> | >  extension of each of these allocations up to a /29 without meeting

> | >  the utilization rate for subsequent allocation by explaining

> | >  how the whole address space will be used.

>

> # The wording is slightly different from latest (v004) version.

>

> Do you think corrent text is not enough?

>

> Yours Sincerely,

> --

> Tomohiro Fujisaki

> *  sig-policy:  APNIC SIG on resource management policy   
> *

> ___

> sig-policy mailing list

> sig-policy@lists.apnic.net

> http://mailman.apnic.net/mailman/listinfo/sig-policy

*  sig-policy:  APNIC SIG on resource management policy   *

___

sig-policy mailing list

sig-policy@lists.apnic.net

http://mailman.apnic.net/mailman/listinfo/sig-policy

The information contained in this Internet Email message is intended
for the addressee only and may contain privileged information, but not
necessarily the official views or opinions of the New Zealand Defence Force.
If you are not the intended recipient you must not use, disclose, copy or 
distribute this message or the information in it.

If you have received this message in error, please Email or telephone
the sender immediately.
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size

2014-09-17 Thread Owen DeLong

Yes, I still feel it misses my point completely.

I have no problem with expanding the existing reservations which are bounded at 
/29 to /29.

I don’t want to see us move the default allocation in the sparse allocation 
world to larger than /32. Larger than /32 should require additional 
justification for those blocks.

Further, I don’t want to see us creating a default at a non-nibble boundary. 
For organizations that show need for larger than a /32, I would support a 
default of /28, but will continue to oppose a default expansion to /29.

Owen

On Sep 16, 2014, at 6:59 PM, (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) 
 wrote:

> 
> Hi,
> 
> Thank you so much for your comments.
> 
> Here, just I would like to confirm,
> 
> | 1.  unrestricted issuance of /29s to every organization regardless 
> of needs.
> 
> I've added some texts that LIRs would like to to obtain a additional
> block larger than /32 need to demonstrate their needs in version 3
> (prop-111-v003).
> 
>> From the mail I sent on 1st August:
> |
> | I submitted revised version of:
> | “prop-111: Request-based expansion of IPv6 default allocation size"
> | 
> | At the last policy sig discussion, I got concern about address allocation
> | without any constraint, and some criteria should be added to expand the
> | block size.
> | 
> | In this revised proposal, I added the requirement to demonstrate need
> | for both initial and subsequent allocations to reflect such opinions.
> | 
> | For initial allocation:
> | >  The organizations
> | >  can receive up to /29 by providing utilization information of the 
> whole
> | >  address space.
> | 
> | For subsequent allocation:
> | >  LIRs that hold one or more IPv6 allocations are able to request
> | >  extension of each of these allocations up to a /29 without meeting
> | >  the utilization rate for subsequent allocation by explaining
> | >  how the whole address space will be used.
> 
> # The wording is slightly different from latest (v004) version.
> 
> Do you think corrent text is not enough?
> 
> Yours Sincerely,
> --
> Tomohiro Fujisaki
> *  sig-policy:  APNIC SIG on resource management policy   
> *
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size

[sig-policy] Crowd Sourcing for Translation

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size

15 matches

Site Navigation

Mail list logo

Footer information