Re: [sig-policy] The full picture

To: Sanjaya <sanjaya at apnic dot net>
Subject: Re: [sig-policy] The full picture
From: Terry Manderson <terry at terrym dot net>
Date: Thu, 2 Dec 2010 11:21:37 +1000
Cc: "sig-policy at apnic dot net" <sig-policy at apnic dot net>
Delivered-to: sig-policy at mailman dot apnic dot net
In-reply-to: <4CF5F480.3020506 at apnic 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: <C91B2D9E.19326%marty@akamai.com> <4CF5F480.3020506@apnic.net>

On 01/12/2010, at 5:08 PM, Sanjaya wrote:

> 
> While we have the ability to track our IPv4 stock level internally, we 
> are still working on finalizing a public reporting format that meets the 
> community needs.

"Still working"? I was unaware that a discussion paper or community feedback request was sent out. If this has or was done, my apologies and please provide a URL.

What is the currently held list of community needs?

> We'd like to hear more from you about how we can best 
> do this, so please keep sending ideas to this list. We are monitoring 
> this thread closely. Thanks.

Currently not knowing what you have listed as 'community needs' I might be suggesting already considered options. But here goes.

All of the RIRs appear to participate in the RIR stats production as seen here:

ftp://ftp.apnic.net/apnic/stats/apnic/

and the description of the stats format here:
http://www.apnic.net/publications/media-library/documents/resource-guidelines/rir-statistics-exchange-format

So not wanting to reinvent the wheel completely.

Perhaps update the enumerated list of 'status' to include "reserved" and  "unallocated". In the 'extensions' field provide more information about the reason for the reserved/unallocated status.

e.g. 
	- RQA state 
	- PDP outcome such the /16 in the final /8 (PROP-reference)
	- Targeted allocation such as critical infrastructure assignments
	- 'dirty' prefix due to debogon research
	- ..

The date field should reflect when any status, or extension 'state' (for RQA) changes.

It probably doesn't need to be said, but the IP resources _should_ be in efficient aggregated CIDR blocks where possible. (as opposed to non-cidr blocks) I'm happy for best effort...

I'm also leaning to a "pending" status - meaning that the resource block has been earmarked for something that does not yet fit into reserved or unallocated. And thus a meaningful description can be put into the extensions section. This makes sense if the earmarking lasts for more than one issuance of the stats file.

Cheers
Terry