Re: [sig-policy] prop-061-v001: 32-bit ASNs for documentation purposes
- To: Geoff Huston <gih at apnic dot net>
- Subject: Re: [sig-policy] prop-061-v001: 32-bit ASNs for documentation purposes
- From: Philip Smith <pfs at cisco dot com>
- Date: Tue, 15 Jul 2008 13:03:18 +1000
- Authentication-results: syd-dkim-1; header.Fromemail@example.com; dkim=pass ( sig from cisco.com/syddkim1002 verified; );
- Cc: APNIC Policy SIG List <sig-policy at apnic dot net>
- Delivered-to: sig-policy at mailman dot apnic dot net
- In-reply-to: <487C0C6B.3040104 at apnic dot net>
- List-archive: <http://mailman.apnic.net/mailing-lists/sig-policy>
- List-help: <mailto:firstname.lastname@example.org?subject=help>
- List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
- List-post: <mailto:email@example.com>
- List-subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:firstname.lastname@example.org?subject=subscribe>
- List-unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:email@example.com?subject=unsubscribe>
- Organization: Cisco Systems
- References: <487B12CB.firstname.lastname@example.org> <200807142237.m6EMbZ7T065411@burn.telstra.net> <487C0C6B.email@example.com>
- User-agent: Thunderbird 220.127.116.11 (Macintosh/20080421)
Hi Geoff, Geoff Huston said the following on 15/7/08 12:33:
I have to agree with David Woodgate here that procedurally such reservations in the IANA AS number registry are correctly actions taken as standards actions.
Right, but the policy proposal is requesting that *APNIC* reserve 4 ASNs for documentation purposes. It made no request or implied request on IANA at all.
So APNIC can decide to adopt this as policy but that will not mean anything in terms of an action recorded in IANA's AS Number registry.
The required action is that of a standards action undertaken by the IETF. So why not headstraight to the IETF in the first place, using RFC 3849 as a template?
Like we did the last time. ;-) If the policy proposal is adopted by the community, then the next step could very well be to head to the IETF, using RFC3849 as the template. One bridge at a time.