[Ietf-lac] 2001:0db8::/32 - RFC 3849

[Alejandro Acosta]

Hola Antonio,
  Creo que tuviste consenso.
  Cuenta con mi apoyo también si necesitas algo en el documento.

Saludos,

Alejandro,



On 7/29/13, Carlos M. martinez <carlosm3011 at gmail.com> wrote:
> Creo que tiene que ver con el scope de los documentos. Si uno documenta
> su propia red o su plan de direccionamiento, de hecho termina
> escribiendo direcciones global unicast en documentos.
>
> Por eso, en el caso de un documento cuyo scope es un lab, y que se
> *supone* que uno lo va a implementar en un simulador o en unos routers,
> alguien podría argumentar que utilizar ULAs es aceptable.
>
> Si uno va a escribir un libro para publicar, que no tiene p.ej. aspectos
> directamente que deban ser implementados, ahi si tiene mas sentido usar
> un prefijo unicamente de documentación.
>
> (De nuevo, acuérdense que estoy jugando a ser el abogado del diablo)
>
> s2
>
> C.
>
>
> On 7/29/13 10:54 AM, Arturo Servin wrote:
>>
>>
>> On 7/29/13 10:51 AM, Carlos M. martinez wrote:
>>> Me cuesta ver porque las ULAs no pueden estar en documentos, sabiendo
>>> que son ULAs :-) Ojo, en realidad no lo dije como que esa fuera mi
>>> posición, sino mas bien tratando de prever un posible contra-argumento
>>> que podría surgir.
>>>
>>
>> RFC4193
>>
>> 3.2.1.  Locally Assigned Global IDs
>>
>>    Locally assigned Global IDs MUST be generated with a pseudo-random
>>    algorithm consistent with [RANDOM].  Section 3.2.2 describes a
>>    suggested algorithm.  It is important that all sites generating
>>    Global IDs use a functionally similar algorithm to ensure there is a
>>    high probability of uniqueness.
>>
>>    The use of a pseudo-random algorithm to generate Global IDs in the
>>    locally assigned prefix gives an assurance that any network numbered
>>    using such a prefix is highly unlikely to have that address space
>>    clash with any other network that has another locally assigned prefix
>>    allocated to it.  This is a particularly useful property when
>>    considering a number of scenarios including networks that merge,
>>    overlapping VPN address space, or hosts mobile between such networks.
>>
>>
>>> Entiendo que la preocupación de Antonio es doble, tanto los documentos
>>> como los labs.
>>>
>>> s2
>>>
>>
>> Slds
>> as
>>
>> _____________________________________________
>> Ietf-lac mailing list
>> Ietf-lac at lacnog.org
>> Cancelar suscripcion: ietf-lac-unsubscribe at lacnog.org
>>
> _____________________________________________
> Ietf-lac mailing list
> Ietf-lac at lacnog.org
> Cancelar suscripcion: ietf-lac-unsubscribe at lacnog.org
>
>


-- 
=====
^A.......o$