[LACNIC/Politicas] Summary LACNIC Policy Discussion March 1st - 12th

[Ray Plzak]

German,

I realize the extra effort that is required to do this. I applaud the commitment that LACNIC has made to do this.

Ray

> -----Original Message-----
> From: politicas-bounces at lacnic.net [mailto:politicas-
> bounces at lacnic.net] On Behalf Of German Valdez
> Sent: Tuesday, March 13, 2007 10:17 AM
> To: LACNIC Policy mailling list
> Subject: [LACNIC/Politicas] Summary LACNIC Policy Discussion March 1st
> - 12th
>
>
> Friends,
>
> In an effort to promote the participation of other sectors of the
> Internet
> community of Latin America and the Caribbean as well as of other
> regions, we
> will begin sending weekly summaries, in English of the issues presented
> and
> discussed on LACNIC's mailing lists.
>
> We would also like to take the opportunity to remind you that LACNIC
> mailing
> lists are also open to contributions in English and Portuguese.
>
> Summary of the discussions held on the Public Policy List between March
> 1-12.
>
> MULTICAST ADDRESS ASSIGNMENT POLICY
>
> A proposal was presented by Guillermo Cicileo (March 1) for LACNIC to
> join
> other RIRs to instantiate RFC 3138, which defines a range of addresses
> to be
> used for multicast applications (in case other solutions such as SSM,
> GLOP,
> etc. cannot be used). Concretely, the proposal requests that LACNIC
> assign a
> /20 block, just as ARIN is doing. The detailed proposal, in English,
> can be
> found included in the message at the following address:
>
> http://mail.lacnic.net/pipermail/politicas/2007-March/006879.html
>
> It was clarified that the blocks specified in RFC 3138 are not routable
> addresses but are within the multicast address range (224.0.0.0 to
> 239.255.255.255). They are used to represent "multicast groups" to
> which
> senders and receivers can subscribe but are not present in normal
> routing
> tables. The RFC mentions that within this segment there is an
> assignable
> range that may be distributed by all RIRs.
>
> In addition, it was noted that IANA is already assigning these
> addresses.
> The justification for RIRs to participate in the assignment of these
> segments is taken from the proposal's original author, who argues that
> small
> companies that need addresses do not have access to IANA while large
> companies do, despite the fact that IANA staff has denied the latter
> allegation.
>
> It was observed that there is no need for a similar policy, as this
> would
> imply assigning RIRs space reserved by the IETF, in addition to
> requiring a
> global policy which would demand a lot of time and effort. It was
> suggested
> to focus efforts on IPv6 multicast, as IPv4 has not had the anticipated
> success. It was added that in order for RIRs to provide this service
> there
> might be a cost for the service involved, something which does not
> currently
> happen with IANA.
>
> The current status of this discussion is that the Policy Mailing List
> moderator has suggested that the person who presented the proposal send
> an
> e-mail explaining the use of multicast addresses.
>
> PROPOSAL FOR PROVIDER-INDEPENDENT IPv6 ALLOCATIONS TO END-USER
> ORGANIZATIONS.
>
> A proposal was presented by Jordi Palet (March 6) for the allocation of
> provider-independent IPv6 space to organizations that are considered
> end-users. In order to qualify for such blocks the applicant cannot be
> an
> ISP/LIR and must qualify for receiving IPv4 space from LACNIC. The
> minimum
> size of said allocation must be a /48, although based on the
> documentation
> it could be larger.
>
> This issue is now open for comments.
>
> REPORT ON THE IPv4 COUNTDOWN PROPOSAL
>
> This report, sent by Ricardo Patara (Registry Services Manager),
> describes
> the discussion generated at the APNIC 23 meeting in relation to the
> IPv4
> Countdown proposal.
>
> Basically, this proposal proposes establishing a specific date for the
> exhaustion of the IPv4 address pool available for making allocations.
> The
> proposal further stated that this should be implemented globally in all
> RIRs
> so as to act in a synchronized manner. The final date would be
> calculated
> according to the number of free IPv4 blocks in the IANA pool. This date
> would be established as two years as of the date the pool of free
> blocks
> reaches 30 /8s.
>
> The intention of the proposal is to allow ISPs to have a plan for
> migrating
> to IPv6 as, once the final date is established, ISPs will know without
> any
> doubt the deadline as of which it will not be possible to receive IPv4
> allocations.
>
> During the session other ways of dealing with the problem were
> suggested
> that did not imply the use of an artificial exhaustion date. Concern
> was
> expressed that this proposal would not benefit small regions such as
> LACNIC
> and AFRINIC because it would stimulate a demand for IPv4 blocks,
> increasing
> even further the consumption rate in the more developed regions. In the
> meantime LACNIC would continue to allocate from its own space already
> in
> use, and it is highly probable that when the final date arrived
> LACNIC's
> pool would be exhausted or almost exhausted. This would represent a
> situation of inequitableness among the different regions.
>
> After comments were posted, the person who had made the proposal
> decided not
> to seek consensus for the policy as originally presented.
>
> End of report. No further comments have arrived so far.
>
> --
> German Valdez
> LACNIC
>
>
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas