Re: [sig-policy] prop-061-v001: 32-bit ASNs for documentation purposes
- To: Philip Smith <pfs at cisco dot com>
- Subject: Re: [sig-policy] prop-061-v001: 32-bit ASNs for documentation purposes
- From: David Woodgate <David.Woodgate at telstra dot net>
- Date: Tue, 22 Jul 2008 10:07:34 +1000
- Cc: APNIC Policy SIG List <sig-policy at apnic dot net>
- Delivered-to: sig-policy at mailman dot apnic dot net
- In-reply-to: <488479BD.2030407 at cisco dot com>
- 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>
- References: <487B12CB.firstname.lastname@example.org> <200807142237.m6EMbZ7T065411@burn.telstra.net> <487C0C6B.email@example.com> <487C1376.firstname.lastname@example.org> <200807150402.m6F42K3Q068526@burn.telstra.net> <488479BD.email@example.com>
Philip, You seemed to have overlooked a comment I made in the previous email:
(Yes, the difference in sensitivity is immense between a /8 from the remaining IPv4 pool and 4 32-bit AS numbers, but the principle is the same.)
I'm not arguing that the impact of prop-061 is large; I'm arguing against its basic principle. I'm also arguing that APNIC should be consistent in its allocation practices, and that it shouldn't pick and choose based on the scale of the proposal whether it is or isn't allowed to reserve resources.
It was put strongly to me in Taipei that APNIC is bound by its agreement as an RIR with IANA to *distribute* the resources allocated to it, and it should *not* reserve resources. I accept and support that principle, but if that is the case, then I don't believe that following that principle is "optional" for APNIC.
Example documentation is a base function of the technology, and is not truly a function of the Asia-Pacific region or its resources.Why not? Operators need to write documentation too, not just IETF standards developers...
Operators from all regions need to write documentation, and not just the Asia-Pacific region. That's why this should be addressed at a global level.
That was taken to the IETF when one participant in the IETF noted that the APNIC proposal did something that this participant had been thinking about but had never actually got around to documenting. It really wouldn't have mattered one jot if it had gone to the IETF or not.
(Actually, I'd argue that this means that:- The proposal should have been considered within the aegis of the IETF in the first place, but it just happened that no one had thought of it there. - Taking it to the IETF after its acceptance by APNIC "corrected" the procedural error of it having been considered by APNIC rather than the IETF.
But that's probably beside the point.)
I haven't yet seen any reasoning here why prop-61 is to the detriment of APNIC membership.I'm opposing prop-061 on the principle that it is outside of APNIC's operational scope. I am not claiming that it has any detriment to APNIC members.