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

Wed Mar 21 09:39:30 BRT 2007

German

2 thumbs up for this effort. I hope we will be able to do in French 
also in the future. Hope to see you in Venezuela in May.

Reynold

At 10:36 AM 3/13/2007, Ray Plzak wrote:
>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
>_______________________________________________
>Politicas mailing list
>Politicas at lacnic.net
>https://mail.lacnic.net/mailman/listinfo/politicas