[LACNIC/Politicas] Sumary Week 23th May - 29th May - Resumen Semana del 23 al 29 de Mayo - Sumário Semana 23 ao 29 de maio.
Roque Gagliano
roque at lacnic.net
Tue Jun 9 16:45:31 BRT 2009
Português abaixo.
Español a continuación.
--------------------------
Summary of Public Policy List discussions from 24 May to 31 May, 2009
[LACNIC-2007-01] Modification of the IPv6 Block Announcement Policy
The following is a summary of the comments received in relation to this
policy. The full text of the policy can be found at the following
address:
http://www.lacnic.net/documentos/politicas/LAC-2007-01-2.1-propuesta-sp.pdf
[Pedro Torres - 25 May 2009] - The Portuguese and Spanish versions of
the
text make it clear that a single block which aggregates the entire
assignment must be announced (via BGP). This does not exclude the
possibility of announcing more specific prefixes. For example, a /32
accompanied by two /33s or several /48s. Is this the object of rule? The
English version of the text does not say exactly this. My suggestion
is that
a future revision of the policy excludes such recommendation which,
from my
point of view, is merely operational.
[Nicolás Antoniello - 25 May 2009] - A proposal for modifying the
policy and
eliminating this requirement already exists.
[Pedro Torres - 25 May 2009] - The proposal refers to section 4.5.1.1,
not
4.5.4. I would like to see the proposal applied to the entire policy
(and
mainly to section 4.5.4).
[Francisco Arias - 26 May 2009] - Reply to Pedro Torres’s comments:
According to two good sources that I show below, the verb "shall" is
equivalent in strength to "must":
http://www.merriam-webster.com/dictionary/shall
http://www.ietf.org/rfc/rfc2119.txt
And yes, the proposal of Nicolas (LAC-2007-01) is about LIRs and you
comment was about the section on End-users.
[Nicolás Antoniello - 29 May 2009] - I believe we should work together
on a
revision of the IPv6 block assignment policy with the aim of removing
routing aspects from said policy.
A proposal similar to the one presented at RIPE, which I mentioned on
Wednesday during the presentation of the LACNIC-2007-01 policy, can be
found
at the following address:
http://www.ripe.net/ripe/policies/proposals/2009-06.html
The arguments are similar in many aspects to those that were raised
during
the discussion the other day.
I believe we could divide the arguments in two parts: one for the
technical
arguments, the other for the political arguments. In light of the
discussions we have had during these past three years regarding this
issue,
I also think that we should focus on the political aspect, i.e. the
argument
that an assignment policy should not include technical routing
requirements,
least of all when it can be inferred from the policy itself that RIRs
do not
have the tools for monitoring their compliance. In addition, I
personally
believe that the routing issue should be left up to the relationships
between LIRs, ISPs, carriers, etc.
[Jordi Palet - 29 May 2009] - It is important to observe that the
existence
of a policy proposal in a specific region (in this case RIPE) does not
imply
that it will be accepted. At this moment, although there are many
opinions
in favor of accepting this policy, consensus has NOT been achieved and
there
are well-founded opinions indicating that if this modification is
accepted
IT NECESSARILY FOLLOWS that many aspects and texts referring to
routing have
to be changed in many other policies, and I doubt that this can be
done with
“improper timing”.
On the other hand, I insist on one of the aspects I mentioned during the
meeting: If we change this only at LACNIC, who will guarantee that the
operators in other regions will respect this disaggregation and
consequently
that our traffic will not be filtered??? I believe that this would be
very
serious, and it has been proven that there are still operators that
filter
/48s originating from PI IPv6 space in other regions and it takes
months, if
not years, to get these restrictions lifted.
I believe disaggregation is bad and, because technical solutions
exist, it
is preferable to adopt them before reaching a future situation where the
number of routes becomes unacceptable for many ISPs, specially small and
medium-sized ISPs, which would need to make huge investments for using
routers that in today's world do not even exist.
Clearly this type of changes in network operation only benefits larger
companies who do not mind multiplying the cost of their routers by
several
hundred thousand; in the end, such changes are paid by all operators and
Internet users, simply for not having invested more resources for the
operation of networks with MORE cooperation or, in short, being "better
Internet-citizens".
Our efforts in attempting to introduce this type of policy modifications
would be put to better use in attempting to increase cooperation in
network
operation, a better implementation of better protocols (if you'll
excuse the
repetition), for example by having the work carried out at the IETF
regarding LISP become operational as soon as possible.
[Luis Carlos Solano - 29 May 2009] - Disaggregation is very bad, it is
true.
However, I think that in IPv6, because a /48 is so large, it lends
itself to
disaggregation at commercial levels.
It could be the case that a large customer and/or a particular service
require an exclusive STM-4 link. Considering that a /48 may be
sufficient
for that customer, commercial reasons (differentiated service) appear to
indicate that said /48 should be routed through a particular link.
Evidently, an ISP that announces a /48 would be considered an enemy of
the
community (this is an extreme example) but, because the minimum unit
is so
large, perhaps each one of these minimum units could generate enough
traffic
to fill a BGP session of an ISP.
Thus, it is my humble opinion that everything related to routing
should be
eliminated from every policy. Best practices will dictate the size of
routing filters so that "bad neighbors" will be at risk of being
filtered.
[Pedro Torres - 29 May 2009] - I would like to stress the fact that the
current policy already allows disaggregation.
Current policy text:
"Announce a single block on the Internet inter-domain routing system,
aggregating the total IPv6 address allocation received, within a
period not
longer than 12 months."
I understand that the current policy allows fragmentation, as long as a
single block that aggregates all prefixes is announced together with the
smaller prefixes. The text says nothing about more specific prefix
announcements not being allowed together with the announcement of the
single
block.
My proposal is to remove all operational requirements; what we must
include
is a recommendation stating that fragmentation should be avoided.
[Ricardo Patara - 29 May 2009] - A comment on the Portuguese wording
of the
text:
The phrase "Anunciar no sistema de roteamento inter-domínio da
Internet um
bloco único" has a very different meaning than "Anunciar no sistema de
roteamento inter-domínio da Internet um _unico_ bloco."
The Spanish text is worded as follows:
"Anunciar en el sistema de rutas inter-dominio de Internet un único
bloque"
[Jordi Palet - 29 May 2009] - If you have a customer who is large
enough to
have to announce its /48, the most logical thing would be for that
customer
to receive that /48 (or the corresponding prefix size) directly from
LACNIC
(as PI IPv6), because most probably that customer already has several
paths
to the Internet (with one or more providers). Thus it would not be
necessary
to disaggregate that prefix from yours, but rather it would be a
different
prefix.
If we eliminate this restriction from the policy, as long as this does
not
happen in the other regions, a situation might occur where "all" LACNIC
region operators could be considered "bad neighbors".
[Luis Carlos Solano - 29 May 2009] - This is correct. What is not
clear to
me in this scheme of things is what the benefit for the global routing
table
would be. If this were to happen, the global routing table would have
a /32
(that of the ISP) and a /48 (that of the client). I think that the end
result would be the same.
However, what is clear to me is that a "bad" ISP may negatively
contribute
with thousands of /48s, whereas individual /48 assignments may be
easier to
control.
[Scott Leibrand - 29 May 2009] FYI, a new proposal (Open Access To
IPv6) was
just posted to the public policy mailing list (PPML) in ARIN that would
(among other things) remove "by advertising that connectivity through
its
single aggregated address allocation" from article 3 of section 6.5.1.1.
In my personal opinion, LACNIC would not be considered a "bad
neighbor" if
you were to do the same.
[Pedro Torres - 29 May 2009] - Portuguese term "único" meaning
"singular".
In any case, we will work to propose that operational aspects not be
discussed in the policy.
- -------------------------
Sumário das discussões na Lista Pública de Políticas desde o dia 23 de
maio
até o dia 31 de maio de 2009.
[LACNIC-2007-01] Modificação à política de publicação de blocos IPv6
A seguir são sumarizados os comentários que houve acerca dessa
política.
Veja texto completo da mesma em:
http://www.lacnic.net/documentos/politicas/LAC-2007-01-2.1-propuesta-sp.pdf
[Pedro Torres - 25 maio 2009] – A versão do texto em português e
espanhol
deixa claro que um bloco único que agregue toda a designação deve ser
anunciado (via BGP). Isso não exclui a possibilidade de que sejam
anunciados prefixos mais específicos. Por exemplo, um /32 acompanhado de
dois /33 ou alguns /48s. É esse o objetivo da regra? A versão em
inglês não
disse exatamente isso. Minha sugestão é que numa próxima revisão da
política
essa recomendação seja excluída já que, segundo meu ponto de vista, é
puramente operacional”.
[Nicolás Antoniello - 25 maio 2009] - Existe uma proposta de
modificação da
política que propõe eliminar esse requerimento.
[Pedro Torres - 25 maio 2009] – A proposta refere à seção 4.5.1.1 e não
4.5.4. Gostaria de ver a proposta aplicada à política completa (e
principalmente ao ponto 4.5.4).
[Francisco Arias - 26 maio2009] - De acordo com duas boas fontes ao
verbo
modal “shall” é equivalente em tenacidade ao “must”. Ver:
http://www.merriam-webster.com/dictionary/shall
http://www.ietf.org/rfc/rfc2119.txt
Francisco concorda que a proposta de Nicolas (LAC-2007-01) se refere aos
LIRs e ISPs porem os comentários de Pedro Torres são sobre a seção de
usuários finais.
[Nicolás Antoniello - 29 maio 2009] – Concordo com a proposta de Pedro e
acredito que devemos trabalhar em parceria numa revisão da política de
designação de blocos IPv6 com o objetivo de remover os aspectos de
roteamento da mesma. Na seguinte URL:
http://www.ripe.net/ripe/policies/proposals/2009-06.html
está disponível a proposta similar de RIPE à que fiz referência na
apresentação da política LACNIC-2007-01 na quarta-feira.
Os argumentos são similares em vários aspectos aos aportados na
discussão do
outro dia.
Acredito que poderíamos separar os argumentos em duas partes, uma com os
argumentos técnicos e outra com os argumentos políticos. Também acho
que à
luz da discussão que tivemos sobre esse assunto nesses últimos três
anos,
deveríamos focar-nos no aspecto político, isto é, no argumento de que
uma
política de designação não deveria incluir imposições técnicas de
roteamento
e menos ainda quando da mesma política desprende-se que os RIRs não
possuem
ferramentas para controlar seu cumprimento. Além disso fica claro que na
minha opinião que o assunto do roteamento deve deixar-se às relações
entre
LIRs, ISPs, Carriers, etc...
[Jordi Palet - 29 maio 2009] – É importante dar-se conta de que uma
proposta
de política em uma determinada região (neste caso RIPE) não implica
que será
aceita. Neste momento, na lista de discussão ainda que existam muitas
opções
a favor de que essa política seja aceita, NÃO HÁ consenso, e há
opiniões bem
fundadas de que se for aceita essa mudança, também forçosamente haverá
que
mudar muitos aspectos e textos referidos ao roteamento em muitas outras
políticas, e duvido que isso possa ser feito “a destempo”.
Do outro lado insisto em um dos aspectos que salientei na reunião: se
apenas
o mudarmos no LACNIC, qual vai ser a garantia de que os operadores das
outras regiões vão respeitar essa desagregação e portanto nosso
tráfego não
vai ser filtrado??? Acredito que isso seria muito grave, e são casos
provados que ainda há operadores que filtram /48 procedentes de IPv6
PI em
outras regiões e demora meses ou melhor, anos em conseguir que isso
acabe.
Acredito que a desagregação é ruim, e existindo soluções técnicas, é
melhor
adotá-las antes de chegar a uma situação futura em que o número de rotas
seja inaceitável para muitos ISPs, principalmente para os pequenos e
médios,
que teriam que fazer investimentos enormes em usar routers que ainda nem
sequer existem.
É claro que esse tipo de mudanças na operação das redes somente
beneficia
aos grandes que não têm problemas em multiplicar por milhares o preço do
custo de seus routers, e essa mudança no final somos nós, os
operadores e
usuários da Internet que acabamos pagando somente por não investir mais
recursos em operar as redes com MAIS cooperação, definitivamente sendo
“melhores Interent-citizens”.
Os esforços que realizamos em tentar este tipo de modificações nas
políticas, estariam melhor utilizados em incrementar a cooperação na
operação das redes, implementar melhor melhores protocolos (valha a
redundância), como por exemplo em conseguir que o esforço realizado no
IETF
ao respeito de LISP seja operativo o mais rápido possível.
[Luis Carlos Solano - 29 maio 2009] – A desagregação é muito ruim, com
certeza, mas eu acredito que em IPv6, por ser um /48 tão grande, se
presta
para a desagregação, a níveis comerciais. Poderia
acontecer que
um cliente/ grande/ e/ ou/ serviço particular precise somente para
ele, um
enlace STM-4. Em vista de que um /48 pode ser suficiente para esse
cliente,
pareceria que por motivos comerciais (serviço diferenciado) esse /48
deveria
ser roteado por um enlace em particular.
Evidentemente, um ISP que anuncie um /48 seria um inimigo da
comunidade (e é
um exemplo extremo) mas sendo a unidade mínima tão grande, cada uma
dessas
unidades mínimas poderia gerar suficiente tráfego para encher uma
sessão BGP
de um ISP.
Na minha humilde opinião é que em todo o relativo ao roteamento deve
eliminar-se qualquer política. As melhores práticas vão impor o
tamanho dos
filtros nos roteadores de modo que os /maus vizinhos/ se exponham a
serem
filtrados.
[Pedro Torres - 29 maio 2009] – Gostaria de enfatizar que a política
atual
já permite desagregação.
Texto da política atual:
"Anunciar no sistema de roteamento inter-domínio da Internet um único
bloco,
que agregue toda a alocação de endereços IPv6 recebida, em um prazo
até 12
meses."
Na política atual, entendo que a fragmentação é permitida, desde que,
junto
com a fragmentação seja anunciado um bloco único que agregue todos os
prefixos.
O texto não comenta nada de que junto com o anúncio do bloco único não
possam existir anúncios de prefixos mais específicos.
A minha proposta é de removermos qualquer imposição operacional, o que
devemos colocar é uma recomendação de que a fragmentação deve ser
evitada.
[Ricardo Patara - 29 maio 2009] - Um comentário do idioma:
"Anunciar no sistema de roteamento inter-domínio da Internet um bloco
único"
tem um significado bastante diferente do que:
"Anunciar no sistema de roteamento inter-domínio da Internet um _único_
bloco"
No texto em espanhol temos:
"Anunciar en el sistema de rutas inter-dominio de Internet un único
bloque"
[Jordi Palet - 29 maio 2009] – Se tiver um cliente o suficientemente
grande
como para que precise anunciar seu /48, o mais lógico seria que esse
cliente
recebesse do LACNIC diretamente (como IPv6 PI) esse /48 (ou o tamanho de
prefixo que corresponder) porque o mais provável é que esse cliente
tenha
vários caminhos para a Internet (com um ou vários provedores). Assim
que não
seria necessário desagregar esse prefixo seu mas sim outro diferente.
Se eliminarmos essa restrição da política, enquanto isso não ocorrer em
outras regiões, poderia acontecer que “todos” os operadores da região do
LACNIC puderem ser considerados “maus vizinhos”.
[Luis Carlos Solano - 29 maio 2009] – Isso está certo. O que no fica
claro
para mim nesse esquema são as vantagens na tabela de rotas globais. Se
isso
acontecer, a tabela de rotas global terá um /32 (o do ISP) e um /48 (do
cliente). O resultado final acho que seria o mesmo.
Sim tenho claro contudo, que um /mau/ ISP pode colaborar negativamente
com
milhares de /48s, enquanto que podem ser mais controláveis as
designações
individuais de /48s.
[Scott Leibrand - 29 maio 2009] A título de informação, foi publicada
recentemente uma nova proposta (Open Access To IPv6) na lista pública de
políticas (PPML) do ARIN que entre outras coisas eliminaria a frase “by
advertising that connectivity through its single aggregated address
allocation" do Artigo 3 da seção 6.5.1.1.
Na minha opinião, o LACNIC não seria considerado um "mau vizinho" se
fizessem o mesmo.
[Pedro Torres - 29 maio 2009] - Único com significado de "singular".
De qualquer forma vamos trabalhar para propor que as questões
operacionais
não sejam tratadas na política.
- -------------------------
Resumen de las discusiones en la Lista Pública de Políticas desde el
24 de
Mayo 2009 hasta el 31 de Mayo.
[LACNIC-2007-01] Modificación a la política de publicación de bloques
IPv6
A continuación se sumarizan los comentarios que hubo sobre esta
política.
Ver texto completo de la misma en:
http://www.lacnic.net/documentos/politicas/LAC-2007-01-2.1-propuesta-sp.pdf
[Pedro Torres - 25 mayo 2009] - La versión del texto en portugues y
español
deja claro que un bloque único que agregue toda la asignación debe ser
anunciado (via BGP). Esto no excluye la posibilidad de que sean
anunciados
prefijos más específicos. Por ejemplo, un /32 acompañado de dos /33 o
algunos /48s. Es este el objetivo de la regla? La versión en inglés no
dice
exactamente eso. Mi sugerencia es que una próxima revisión de la
política
excluya tal recomendación, que desde mi punto de vista es puramente
operacional"
[Nicolás Antoniello - 25 mayo 2009] - Existe una propuesta de
modificación
de la política que propone eliminar ese requerimiento.
[Pedro Torres - 25 mayo 2009] - La propuesta habla de la sección
4.5.1.1 y
no 4.5.4. Me gustaría ver la propuesta aplicada a la política completa
(y
principalmente al punto 4.5.4).
[Francisco Arias - 26 mayo 2009] - De acuerdo con dos buenas fuentes el
verbo modal “shall” es equivalente en tenacidad al “must”. Ver:
http://www.merriam-webster.com/dictionary/shall
http://www.ietf.org/rfc/rfc2119.txt
Afirma que la propuesta de Nicolas (LAC-2007-01) se refiere a LIRs y los
comentarios de Pedro Torres son sobre la sección de usuarios finales.
[Pedro Torres - 26 de mayo 2009] - Concuerda con el comentario
anterior de
Francisco Arias. Respecto al texto planteado en LACNIC-2009-01, observa
que sería posible integrar el texto utilizado en ARIN/RIPE/APNIC
por ser
muy similar.
[Nicolás Antoniello - 29 mayo 2009] - Me parece bien la propuesta de
Pedro y
creo que debemos trabajar juntos en una revisión de la política de
asignación de bloques IPv6 con la finalidad de remover los aspectos de
routing de la misma.
En la siguiente URL:
http://www.ripe.net/ripe/policies/proposals/2009-06.html
se encuentra la propuesta similar de RIPE de la que les hablaba el
miércoles
en la presentación de la política LACNIC-2007-01.
Los argumentos son similares en muchos aspectos a los que se aportaron
en la
discusión del otro día.
Creo que podríamos separar los argumentos en dos partes, una con los
argumentos técnicos y otra con los argumentos políticos. Pienso
también que
a la luz de la discusión que hemos tenido en estos tres últimos años
sobre
este tema, deberíamos centrarnos en el aspecto político, es decir, en el
argumento de que una política de asignación no debería incluir
imposiciones
técnicas de routing y menos aún cuando de la misma política se
desprende que
los RIR no poseen herramientas para controlar su cumplimiento. Además
claro
está, que personalmente creo que el tema de routing debe dejarse a las
relaciones entre LIRs, ISPs, Carriers, etc...
[Jordi Palet - 29 mayo 2009] - Es importante darse cuenta de que una
propuesta de politica en una determinada region (RIPE en este caso), no
implica que vaya a ser aceptada. En este momento, en la lista de
discusion
aunque hay muchas opciones a favor de que se acepte esta politica, NO
HAY
consenso, y hay opiniones bien fundadas que indican que si se acepta
este
cambio, TAMBIEN FORZOSAMENTE, hay que cambiar muchos aspectos y textos
referidos al routing en muchas otras politicas, y dudo que se pueda
hacer
"a destiempo".
Por otro lado insisto en uno de los aspectos que indique en la
reunion: Si
lo cambiamos solo en LACNIC, quien nos garantiza que los operadores
de las
demas regiones respeten dicha desagregacion y por tanto nuestro
trafico no
sea filtrado ??? Creo que esto seria muy grave, y son casos probados
que aun
hay operadores que filtran /48 procedentes de IPv6 PI en otras
regiones y se
tarda meses, sino años, en conseguir que esto se relaje.
Creo que la desagregacion es mala, y habiendo soluciones tecnicas, es
preferible adoptarlas antes que llegar a una situacion en el futuro en
que
el numero de rutas sea inaceptable para muchos ISPs, sobre todo los
pequeños
y medianos, que tendrian que hacer inversiones astronomicas en utilizar
routers que hoy por hoy, ni siquiera existen.
Esta claro que este tipo de cambios en la operación de las redes, solo
beneficia a los mas grandes, que nos les importa multiplicar por varios
cientos de miles el precio del coste de sus routers, y tal cambio al
final
lo pagamos todos los operadores y usuarios de Internet, solo por no
invertir
mas recursos en operar las redes con MAS cooperacion, en definitiva
siendo
"mejores Internet-citizens".
Los esfuerzos que realizamos en intentar este tipo de modificaciones
en las
politicas, estarian mejor empleados en incrementar la cooperacion en la
operación de las redes, implementar mejor protocolos mejores (valga la
redundancia), como por ejemplo en lograr que el esfuerzo que se hace
en el
IETF al respecto de LISP, sea operativo lo antes posible.
[Luis Carlos Solano - 29 mayo 2009] - La desagregación es pésima,
cierto,
pero pienso que en IPv6, por ser un /48 tan grande, se presta para la
desagregación, a niveles comerciales.
Podría darse que un cliente /grande/ y/o servicio particular necesite
sólo
para él, un enlace STM-4. En vista que un /48 puede ser suficiente
para un
ese cliente, parecería que por razones comerciales (servicio
diferenciado)
ese /48 debería enrutarse por un enlace en particular.
Evidentemente, un ISP que anuncie un /48 sería un enemigo de la
comunidad (y
es un ejemplo extremo), pero al ser la unidad mínima tan grande,
podría cada
una de estas unidades mínimas generar suficiente tráfico para llenar una
sesión BGP de un ISP.
Mi humuilde opinión es entonces que todo lo relacionado con el
enrutamiento
debe eliminarse cualquier política. Las mejores prácticas dictarán el
tamaño
de los filtros en los enrutadores de modo que los /malos vecinos/ se
expongan a ser filtrados.
[Pedro Torres - 29 mayo 2009] - Me gustaria enfatizar que la politica
actual
ya permite desagregación.
Texto de la política actual:
"Anunciar en el sistema de rutas inter-dominio de Internet un único
bloque,
que agregue toda la distribución de direcciones IPv6 recibida, en un
plazo
no mayor de 12 meses."
Entiendo que en la política actual la fragmentación es permitida,
siempre
que junto con la fragmentación sea anunciado un bloque único que agregue
todos los prefijos.
El texto no comenta nada de que junto con el anuncio del bloque único no
puedan existir anuncios de prefijos mas específicos.
Mi propuesta es remover cualquier imposición operacional, lo que debemos
colocar es una recomendación de que la fragmentación debe ser evitada.
[Ricardo Patara - 29 mayo 2009] - Un comentario del idioma:
"Anunciar no sistema de roteamento inter-domínio da Internet um bloco
único"
tiene un significado bastante diferente se fuera:
"Anunciar no sistema de roteamento inter-domínio da Internet um _unico_
bloco"
En el texto en espanol tenemos:
"Anunciar en el sistema de rutas inter-dominio de Internet un único
bloque"
[Jordi Palet - 29 mayo 2009] - Si tienes un cliente lo suficientemente
grande para que necesite anunciar su /48, lo mas logico, es que ese
cliente
reciba de LACNIC directamente (como IPv6 PI) ese /48 (o el tamaño de
prefijo
que corresponda), porque lo mas probable es que ese cliente tenga varios
caminos hacia Internet (con uno o varios proveedores). Asi que no haria
falta
desagregar ese prefijo del tuyo, sino que seria otro diferente.
Si eliminamos esa restriccion de la politica, mientras eso no ocurra en
otras regiones, podria darse el caso de que "todos" los operadores de la
region de LACNIC, puedan ser considerados "malos vecinos".
[Luis Carlos Solano - 29 mayo 2009] - Eso es correcto. Lo que no me
queda
claro en este esquema es la ganancia en la tabla de rutas global. Si eso
sucede, la tabla de rutas global tendrá un /32 (el del ISP) y un /48
(del
cliente). El resultado final creo que sería el mismo.
Si tengo claro no obstante, que un /mal/ ISP puede colaborar
negativamente
con miles de /48s, mientras que pueden ser más controlables las
asignaciones
individuales de /48s.
[Scott Leibrand - 29 mayo 2009] FYI, a new proposal (Open Access To
IPv6)
was just posted to the public policy mailing list (PPML) in ARIN that
would
(among other things) remove "by advertising that connectivity through
its
single aggregated address allocation" from article 3 of section 6.5.1.1.
In my personal opinion, LACNIC would not be considered a "bad
neighbor" if
you do the same.
[Pedro Torres - 29 mayo 2009] - Único con significado de "singular".
De todos modos vamos a trabajar para proponer que no se traten
cuestiones
operacionales en la política.
- -------------------------
--------------------------------------------------------
Roque Gagliano
roque at lacnic.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <https://mail.lacnic.net/pipermail/politicas/attachments/20090609/cba014e0/attachment.sig>
More information about the Politicas
mailing list