Re: [sig-policy] prop-085: Eligibility for critical infrastructureassign

  • To: Terence Zhang YH <zhangyinghao at cnnic dot cn>
  • Subject: Re: [sig-policy] prop-085: Eligibility for critical infrastructureassignments from the final /8
  • From: Izumi Okutani <izumi at nic dot ad dot jp>
  • Date: Thu, 19 Aug 2010 21:02:10 +0900
  • Cc: sig-policy at lists dot apnic dot net
  • Delivered-to: sig-policy at mailman dot apnic dot net
  • In-reply-to: <2D01DAA7-A036-4532-8D31-D3F632EEAA33 at terrym dot net>
  • List-archive: <http://mailman.apnic.net/mailing-lists/sig-policy>
  • List-help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
  • List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
  • List-post: <mailto:sig-policy@lists.apnic.net>
  • List-subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
  • List-unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
  • References: <482182673.27379@cnnic.cn> <2D01DAA7-A036-4532-8D31-D3F632EEAA33@terrym.net>
  • User-agent: Thunderbird 2.0.0.24 (Windows/20100228)
    • 
      
      I support the idea of making sure critical infrastructures can receive
      IPv4 space, but I think we can accomodate this needs from the reserved
      block we have today. (as shown by the data)
      
      So I have a question to Terence -
      
      Would it solve your problem if we explictly state
      "Critical Infrastructure assignments will be continued to be allowed
      until the current reserved block for Critical Infrastructures runs out"?
      
      (i.e, secure assignments for critical infrastructures from the reserved
      block today, even after the regular APNIC pool runs out)
      
      The current policy is ambiguous if we can continue to allow assignments
      from this reserved block after regular APNIC pool runs out, so I can see
      that it's worth explicitly defining this.
      
      
      Izumi/JPNIC
      
      Terry Manderson wrote:
      > Hi Terence,
      > 
      > On 19/08/2010, at 11:51 AM, Terence Zhang YH wrote:
      > 
      >> Hi Terry, 
      >>
      >> Thanks for your comments. 
      >>
      >> The statistics you show is correct, there are not many CI assignments these two years. 
      >> CI requirement is not large, but it's important.  Since ICANN recently launched 
      >> New gTLD program,  IDN and IDN ccTLD fast Track, 
      >> we can expect modest  increase of new  IDN TLDs and gTLDs in the next few years, 
      >> and that will coincide with our entering into final /8. 
      >>
      > 
      > Right, modest. and even with the updated stats from Sanjaya, 36.7% utilised over 7 years still says to me that there is head room there.
      > 
      > 
      >>> The question in my mind relates to if 203.119/16 is 100% set aside for critical infrastructure assignments or not, given that section 11.3 doesn't actually say. If so then I struggle to see what real live problem prop-085 is going to solve. My belief is that the final /8 will have its assignment policy set and will be all consumed well before enough new critical infrastructure organisations can form and apply to use up the remaining space in 203.119/16 which would imply a restraint in the wrong direction. 
      >>>
      >> What I understand is, even if that block is reserved and available, assignments/allocations
      >> from that block still have to be justified according to some policy criteria. 
      > 
      > yes. as would be expected for a very constrained resource.
      > 
      >> Currently final /8 policy ONLY allow allocations, so even if there are enough space in  203.119/16 when we enter final /8, 
      >> critical infrastructure users still have no way to justify their needs using '11.3  Critical Infrastructure Policy',
      > 
      >> they have to justify their needs under allocation policy :
      > 
      >> 9.3 Criteria for initial allocation
      >> 9.4 Criteria for subsequent allocations
      >> Which they might have difficulty to justify, ie. they may not be able to show the need of /22. 
      >>
      > 
      > o.k. If you say so. Although originally that wasn't my interpretation of the effect of prop-62-v002. But it seems as written to be the case.
      > 
      >>> If 203.119/16 isn't set aside for just CI applications and other member applications can encroach on it, then I think you might want to consider that to be the low hanging fruit instead of heading toward the last /8 policy space.
      >>>
      >> According to the final /8 policy '9.10 Distribution of the final /8', 
      >> the final /8 doesn't mean a single stand alone  /8 block,  it means 
      >> 'When the total remaining space in the unallocated APNIC address pool reaches a threshold of a total of one /8'
      >>
      > 
      > right.
      > 
      >> So, 
      >> If the 203.119/16  still have available space when we enter final /8, it's a component of the final /8 space, 
      >> it's reasonable to continue make CI assignments from it. 
      > 
      > 
      > yes.
      > 
      >> if the 203.119/16 is used up when we enter final /8, that shows the need is steady, it's reasonable 
      >> to open another block for it.
      > 
      > sorry "if".. that is stretching it a bit.. And that is the problem I have. With still over 60% of the 203.119/16 still remaining and a consumption rate at such a low level, and even with the new IDNs (which generally go to the existing gTLD/ccTLD) and TLDs I would rather see an pragmatic analysis of the proposed CI demand backed by facts which coincide by the last /8 mark to say that the CI /16 would be consumed by then and there would be a very very high likely-hood of another block from the /8 required for CI.. if we aren't all on IPv6 by then.
      > 
      > My other point is at the final APNIC /8 point AND the 203.119/16 is consumed I see very little difference between a new CI organisation and a LIR. Why should we bless one category in particular? 
      > 
      > Terry
      > *              sig-policy:  APNIC SIG on resource management policy           *
      > _______________________________________________
      > sig-policy mailing list
      > sig-policy at lists dot apnic dot net
      > http://mailman.apnic.net/mailman/listinfo/sig-policy