RFC 1466: Un plan de asignación temporal que sobrevivió a sus premisas

Resumen

• Los umbrales con clases y las reglas escalonadas de Clase C de RFC 1466 fueron reemplazados por el marco sin clases de RFC 2050, pero el plan de 1993 no contenía ninguna cláusula de caducidad para la delegación regional, la divulgación de los solicitantes o la revisión discrecional.
• El registro publicado muestra recurrencia textual y una implementación fechada a nivel de formulario de 1993, pero carece de denominadores sobre solicitudes, rechazos, excepciones, auditorías, apelaciones y resultados, por lo que la persistencia institucional posterior no puede atribuirse al plan de 1993 sin evidencia operativa.

El título es una hipótesis, no una cita

El adjetivo "temporal" es la hipótesis retrospectiva de este artículo. El plan de mayo de 1993,RFC 1466, no utiliza ni "temporal", "interino" ni "caducidad". No establece una fecha de expiración para sus reglas de asignación ni un calendario para reconsiderar las instituciones regionales asociadas a ellas. Su conclusión dice que las recomendaciones retrasarían el agotamiento, no lo pospondrían indefinidamente. Eso establece una eficacia técnica limitada. No establece una caducidad institucional prometida.

La distinción es esencial porque RFC 1466 combinó varias intervenciones diferentes. Abordó la escasez de números de red deseables con clases, especialmente las unidades de Clase B. Buscó reservar espacio de direcciones para un plan de numeración futuro. Organizó las asignaciones de Clase C para que las técnicas de agregación emergentes pudieran utilizar bloques contiguos. Propuso un registro distribuido geográficamente como forma de atender a una población cada vez más internacional. Exigió a los solicitantes que revelaran sus planes de red, y dejó a los registros la autoridad para juzgar excepciones.

Esas intervenciones no compartían una misma vida útil. Las pruebas con clases estaban ligadas a un entorno técnico ya bajo presión. Los bloques geográficos de Clase C eran en parte un arreglo administrativo y en parte una preparación para la agregación. La divulgación de los solicitantes y el juicio de los registros eran capacidades administrativas reutilizables. Las organizaciones regionales podían seguir sirviendo a los solicitantes incluso cuando el problema original de Clase B frente a Clase C ya no determinaba el tamaño de la asignación.

La introducción del plan describía que la demanda de números de red había crecido significativamente durante los dos años anteriores. Mantuvo al Internet Registry como el registro principal y por defecto, a la vez que proponía que organizaciones cualificadas recibieran bloques y responsabilidades de asignación. Su argumento de servicio declarado era la diversidad global: los registros más cercanos a los solicitantes podrían comprender mejor los idiomas y costumbres locales. Su argumento técnico se refería al agotamiento y a la presión sobre el enrutamiento. Estos argumentos convergieron en un solo documento, pero no deberían tratarse como un mandato indivisible.

RFC 1466 se publicó como Informativo. Su resumen registró el consenso general entre el Federal Engineering Planning Group, los co-presidentes del Intercontinental Engineering Planning Group y RIPE en apoyo de las recomendaciones. Eso es evidencia de revisión por parte de grupos técnicos nombrados. No es un denominador de electores para proveedores de servicios de Internet, suscriptores de red o solicitantes, y no prueba el consentimiento generalizado de los operadores.

Tampoco RFC 1466 originó cada desarrollo regional que más tarde se le asoció. El documento afirma que RIPE NCC había recibido un bloque de Clase C antes de que se adoptara la propuesta. Un relato retrospectivo posterior,RFC 7020, remonta la propuesta de delegar responsabilidad a organismos regionales a RFC 1366. Por lo tanto, RFC 1466 codificó, revisó y asoció disposiciones específicas con un proceso regional ya en desarrollo. No se puede describir de forma segura como el creador exclusivo de la administración regional.

La pregunta útil es más limitada que si el plan completo se volvió permanente. ¿Qué reglas técnicas perdieron autoridad? ¿Qué capacidades administrativas reaparecieron en texto posterior? ¿Qué disposiciones llegaron a un formulario fechado utilizado por los solicitantes? ¿Qué roles institucionales se describieron de nuevo bajo un razonamiento técnico modificado? ¿Y qué evidencia se necesitaría para pasar de un linaje textual a una afirmación sobre operación continua o causalidad?

Escasez en unidades con clases

La apertura numérica de RFC 1466 es fácil de malinterpretar porque sus unidades eran números de red, no direcciones individuales. El documento reprodujo estadísticas de asignación fechadas en mayo de 1992. Su fila de Clase A enumeró 126 unidades totales de número de red y 49 asignadas. La tabla imprimió 38 por ciento, pero la aritmética es49 / 126 = 38.888889%, que se redondea a 39 por ciento en lugar de 38. La discrepancia debe conservarse como una característica de la tabla publicada, no convertirse silenciosamente en un resultado matemáticamente exacto.

La fila de Clase B enumeró 16.383 unidades de número de red y 7.354 asignadas. Aquí7,354 / 16,383 = 44.887994%, consistente con el 45 por ciento impreso. La fila de Clase C enumeró 2.097.151 unidades de número de red y 44.014 asignadas. La proporción,44,014 / 2,097,151 = 2.098752%, es consistente con el 2 por ciento impreso cuando se expresa como un porcentaje entero.

Ninguna de estas proporciones mide hosts conectados, solicitantes atendidos, solicitudes aprobadas, prefijos anunciados, utilización de direcciones, rechazos o consentimiento. Comparan espacios de número de red con clases asignados con el denominador impreso para la clase correspondiente. Las filas no son intercambiables porque una Clase A, Clase B y Clase C contenían cantidades radicalmente diferentes de valores de dirección de host.

RFC 1466 caracterizó por separado a la Clase A como representando el 50 por ciento del total de direcciones IP de host, a la Clase B como el 25 por ciento y a la Clase C como aproximadamente el 12 por ciento. La proporción teórica de Clase C es el 12,5 por ciento del espacio IPv4 completo. Esa distribución del espacio de direcciones ayuda a explicar por qué solo se podía asignar alrededor del 2 por ciento de las unidades de número de red de Clase C mientras la preocupación seguía siendo intensa: el problema inmediato no era un simple recuento de todos los valores IPv4 brutos.

El direccionamiento con clases ofrecía a las organizaciones opciones marcadamente discontinuas. Una red de Clase C contenía 256 valores de dirección brutos. Bajo el tratamiento convencional de la época de un identificador de red y un identificador de difusión, ofrecía 254 identificadores de host utilizables. Una Clase B suministraba un campo de host mucho mayor. Por lo tanto, muchas organizaciones preferían una Clase B a la complejidad operativa de unir numerosas redes de Clase C, incluso cuando sus poblaciones proyectadas ocupaban solo una fracción de la capacidad de la Clase B.

La escasez resultante tenía al menos tres dimensiones. Primero, las unidades de número de red de Clase B se estaban consumiendo rápidamente en relación con su cantidad finita. Segundo, las asignaciones grandes podían dejar gran parte de su capacidad de direcciones sin usar. Tercero, reemplazar una Clase B con muchas redes de Clase C podía multiplicar las entradas de enrutamiento a menos que las técnicas de agregación y la topología permitieran que esas redes se representaran juntas.

RFC 1466 abordó las tres, pero no con una sola métrica. Sus restricciones para Clase B conservaron una unidad con clases deseable. Su esquema de Clase C convirtió la necesidad proyectada en asignaciones contiguas. Sus bloques geográficos crearon una estructura administrativa compatible con la posible agregación. Sus disposiciones de registro regional distribuyeron el trabajo de aplicar esas reglas. El plan unió la gestión de la escasez con el diseño institucional porque alguien tenía que recibir pronósticos, evaluar la arquitectura de red, preservar la información confidencial y decidir si las excepciones estaban justificadas.

Esta fue una respuesta moldeada por la escasez, no simplemente una tabla de límites de ingeniería. Una vez que un pronóstico se convertía en evidencia, la asignación dependía de una institución capaz de interpretarlo. Una vez que múltiples redes contiguas reemplazaban una sola Clase B, el asignador tenía que decidir el tamaño y la ubicación del bloque. Una vez que las divisiones geográficas se convirtieron en la base de la responsabilidad principal, un plan de distribución técnica también organizaba las relaciones de servicio.

Sin embargo, los números limitan hasta dónde puede llegar esta interpretación. La tabla no dice nada sobre por qué se asignó un número de red en particular. No ofrece una población de aplicaciones, ni una comparación de planes aceptados y rechazados, ni un relato de los solicitantes que alteraron o retiraron solicitudes. Las estadísticas establecen el escenario con clases en el que se redactó la política. No establecen los efectos de ninguna disposición individual.

La barrera de la Clase B

La barrera de asignación más explícita del plan se refería a las solicitudes de Clase B. La orientación anterior había favorecido una Clase B con subredes sobre múltiples redes de Clase C. RFC 1466 invirtió esa preferencia cuando era práctico usar múltiples Clases C, citando la escasez de números de red de Clase B y su infrautilización por parte de muchas organizaciones.

Se esperaba que una organización que buscara una Clase B cumpliera dos criterios conjuntivos: un plan de subredes que documentara más de 32 subredes y más de 4.096 hosts. También tenía que presentar un plan de ingeniería que mostrara por qué un bloque de redes de Clase C no era razonable para su diseño. El plan debía indicar el número proyectado de hosts y hosts por subred durante los próximos 24 meses.

Los umbrales eran importantes, pero no eran un derecho auto-ejecutable. Más de 32 subredes sin más de 4.096 hosts no cumplía la conjunción sugerida. Más de 4.096 hosts sin la estructura de subred requerida tampoco. Incluso cuando se presentaban las condiciones numéricas, el registro aún tenía que evaluar si la explicación de ingeniería justificaba la unidad con clases más escasa.

El vocabulario colocó el juicio en el centro. El solicitante debía demostrar que un bloque de Clase C era irrazonable de diseñar. El registro decidía si la solicitud estaba justificada y si el plan merecía una Clase B. Si no, la alternativa descrita era un bloque de números de red de Clase C. El plan presentado debía mantenerse en estricta confidencialidad y usarse solo para juzgar la solicitud.

RFC 1466 también preservó las excepciones. Reconoció que una organización podría no poder usar un bloque de Clase C incluso sin cumplir los criterios sugeridos de Clase B. Dicho solicitante podía explicar la restricción de ingeniería. El texto no enumeró cada topología aceptable, ni asignó pesos a la evidencia, ni publicó una fórmula que eliminara el juicio del revisor.

En el nivel superior al solicitante, el Internet Registry central podía asignar pequeños bloques de Clase B a un registro regional si eso mejoraba el servicio a la comunidad. Podía emitir orientaciones de subasignación más específicas, exigir la contabilización del bloque, recibir los planes de ingeniería de los solicitantes y auditarlos para verificar su coherencia con las directrices. Estas cláusulas identifican un actor autorizado y posibles formas de supervisión. No muestran que ocurriera una auditoría, con qué frecuencia se consideró o qué consecuencias siguieron.

El arreglo contenía así una premisa técnica, un criterio de asignación, un criterio institucional y una excepción. La premisa técnica era la escasez e infrautilización de la Clase B. El criterio ordinario combinaba umbrales de subred y host con un plan de ingeniería de 24 meses. El criterio institucional era la capacidad del registro para evaluar y proteger ese plan. La excepción permitía que un caso fuera de los umbrales sugeridos se considerara por razones de ingeniería.

Sus cargas eran asimétricas. Un solicitante debía convertir un crecimiento futuro incierto en una arquitectura documentada. El registro retenía la discreción sobre si el pronóstico era creíble y si múltiples Clases C eran prácticas. Esa asimetría no surgía de una base de datos de asignación por sí sola; estaba escrita en la relación probatoria entre el solicitante y el revisor.

Aun así, sería un error describir cada demanda posterior de información del solicitante como supervivencia de esta regla de Clase B. La prueba original preguntaba si una alternativa con clases era factible en un horizonte de dos años. Para noviembre de 1996, el marco publicado utilizaba la longitud de prefijo, la utilización y las asignaciones por etapas. La revisión de pronósticos reapareció, pero el objeto de revisión y sus horizontes temporales cambiaron. La continuidad de una función administrativa no es continuidad del umbral original.

Clases C contiguas y la aritmética de la agregación

RFC 1466 intentó conservar las unidades de Clase A y Clase B asignando múltiples Clases C siempre que fuera posible. Esa respuesta creó su propio problema de enrutamiento. Si cada Clase C aparecía por separado, el número de entradas de enrutamiento podía crecer rápidamente. Por lo tanto, el plan organizó las unidades de Clase C en bloques contiguos, en potencias de dos, compatibles con la agregación.

La división geográfica debe describirse en la unidad correcta. RFC 1466 dividió el rango de 192.0.0.0 a 207.255.255.255 en ocho bloques, cada uno cubriendo dos valores del primer octeto. Cada bloque contenía 131.072 unidades de número de red de Clase C:2 × 65.536. Eso es el 6,25 por ciento del espacio teórico de 2.097.152 unidades de número de red de Clase C. También son131.072 × 256 = 33.554.432direcciones IPv4 brutas.

El denominador teórico de 2.097.152 unidades de Clase C es distinto del total de 2.097.151 impreso en la tabla de asignación de RFC 1466. La diferencia no debe ocultarse tratando las dos cifras como si provinieran del mismo cálculo. La tabla informó su inventario con clases; la participación del bloque del 6,25 por ciento se deriva del campo teórico de 21 bits para el número de red de Clase C.

El plan reservó la mitad superior del rango de Clase C, en su mayoría no asignado, de 208.0.0.0 a 223.255.255.255, hasta nuevo aviso. En la mitad inferior, 192.0.0.0 a 193.255.255.255 se describió como multirregional porque las asignaciones allí eran anteriores a la implementación. Europa recibió el bloque 194–195, América del Norte 198–199, América Central y del Sur 200–201, y el Pacífico 202–203. Otros tres bloques de dos octetos se retuvieron para flexibilidad.

RFC 1466 calificó la división como principalmente administrativa y dijo que sentaba las bases para los registros distribuidos. También fue diseñada para ser compatible con las posibles técnicas de agregación de direcciones. Compatibilidad es el nivel correcto de afirmación. La contigüidad geográfica por sí sola no causaba la agregación de enrutamiento. Si un bloque podía anunciarse como una sola ruta dependía de la topología de red, las relaciones con los proveedores, la política de enrutamiento y la tecnología realmente desplegada.

Dentro de esos bloques amplios, el plan utilizó un esquema escalonado basado en la proyección de 24 meses de una organización sobre las direcciones de sistema final requeridas. Menos de 256 direcciones correspondían a una Clase C; menos de 512 a dos; menos de 1.024 a cuatro; menos de 2.048 a ocho; menos de 4.096 a 16; menos de 8.192 a 32; y menos de 16.384 a 64 redes de Clase C contiguas.

Esos umbrales se referían a tamaños de bloque de direcciones brutos. No deben mezclarse silenciosamente con ejemplos de hosts utilizables. Una Clase C contiene 256 valores brutos, pero 254 identificadores de host utilizables según la convención de la época. Treinta y dos Clases C contienen 8.192 valores brutos. Tratadas como 32 redes de Clase C separadas, contienen 8.128 de esos identificadores de host utilizables. Sesenta y cuatro Clases C contienen 16.384 valores brutos y 16.256 espacios de host utilizables con clases. El mismo espacio de direcciones contiguo corresponde a un único prefijo/18, pero esa notación de prefijo no borra la distinción entre valores brutos y la convención de host utilizables aplicada a redes de Clase C separadas.

El esquema tenía excepciones. Si la red de un suscriptor comprendía redes de área local lógicamente distintas para las que el bloque predeterminado era difícil de usar, los criterios podían aplicarse por red local. RFC 1466 dio un ejemplo de 600 hosts distribuidos en diez Ethernets, lo que potencialmente produciría diez asignaciones de Clase C. También advirtió contra el desperdicio excesivo donde era factible el subneteo y permitió a los registros solicitar una explicación de ingeniería.

Un suscriptor que requiriera más de 4.096 direcciones únicas podría calificar para una Clase B, sin embargo, el registro regional podía atender una solicitud de un bloque de Clase C más grande. Sesenta y cuatro Clases C contiguas se describieron como el bloque ordinario máximo, con desviaciones determinadas caso por caso. El esquema era, por consiguiente, estructurado pero no mecánico.

Esta disposición revela un plan que ya se inclinaba más allá de las etiquetas de clase que usaba formalmente. Su vocabulario de asignación seguía siendo Clase C, pero las potencias de dos, la contigüidad a nivel de bits y un prefijo de 18 bits apuntaban hacia una representación sin clases. El plan no resolvió la tensión entre conservación y presión de enrutamiento; organizó las asignaciones para que técnicas de enrutamiento posteriores pudieran manejarla.

Una fuente visual retrospectiva no puede proporcionar el puente causal faltante. LaVisual History of Internet IPv4 Address Allocationsde CAIDA se publicó el 18 de julio de 2020. Su método indicado agrupa los bloques de direcciones por la organización que regula la asignación, utilizando el archivo de espacio de direcciones IPv4 de IANA y los RFC como base. El material público no proporciona una instantánea histórica reproducible, un denominador de eventos de asignación, exclusiones, registros de solicitantes o razones de decisión. Puede ilustrar la agrupación retrospectiva de CAIDA. No puede mostrar que RFC 1466 causó una asignación, que un registro rechazó una alternativa, o que un solicitante usó o declinó una ruta alternativa.

Servicio regional, responsabilidad delegada y un respaldo central

Las disposiciones regionales de RFC 1466 se justificaron primero como una respuesta de servicio a una Internet cada vez más diversa. Un registro ubicado más cerca de una comunidad podría atender mejor a los solicitantes en los idiomas y costumbres locales. Europa, América del Norte, América Central y del Sur, y el Pacífico fueron nombrados como áreas suficientemente maduras en las que podía considerarse la delegación.

La proximidad por sí sola no era suficiente. Se esperaba que una organización candidata estuviera legitimada por las autoridades de redes de su área geográfica, bien establecida, y reconocida más allá de la función de registro. Debía comprometer recursos adecuados para un servicio estable, oportuno y fiable. Debía seguir las directrices de IANA y del Internet Registry y coordinar las calificaciones y estrategias de subasignación con el centro.

El plan también dijo que un registro regional debía ser imparcial y ampliamente reconocido por los proveedores de red y suscriptores. Consideró que un solo registro a ese nivel regional era importante para una subasignación eficiente y justa. Estas declaraciones eran criterios para la selección institucional. No eran prueba de que todos los proveedores o suscriptores afectados autorizaran al candidato. El documento no proporciona un denominador de electores para "autoridades de redes", reconocimiento o apoyo del grupo de revisión.

Una vez seleccionado, un registro regional era facultado por IANA y el Internet Registry para proporcionar servicios de registro en un área geográfica. Donde existía uno, la responsabilidad principal de la asignación del bloque de Clase C correspondiente podía delegarse en él. Donde no existía una autoridad designada, el registro central seguía siendo el predeterminado.

El plan no hizo que el canal regional fuera textualmente absoluto. Un solicitante podía contactar directamente al Internet Registry central. Dependiendo de las circunstancias, el solicitante podía ser remitido al registro regional, pero el registro central dijo que estaría preparado para atender a cualquier suscriptor de red si fuera necesario.

Esa cláusula de respaldo debe seguir siendo parte de la arquitectura de 1993. Impide que el documento se reescriba como una concesión no calificada de jurisdicción exclusiva. Al mismo tiempo, se desconoce su importancia práctica. RFC 1466 no definió "necesario", no estableció una prueba de servicio exigible ni especificó cómo se resolvería un desacuerdo sobre la remisión. La fuente confirma la ruta en el plan publicado; no revela su frecuencia, accesibilidad o consecuencias para el solicitante.

La posición anterior a la adopción de RIPE NCC limita aún más la causalidad centrada en el RFC. RFC 1466 registra que RIPE NCC ya había recibido el bloque de Clase C 193.0.0.0 a 193.255.255.255 antes de la adopción de la propuesta y había acordado asignar dentro de él bajo las nuevas directrices. Por lo tanto, el plan adjuntó sus criterios a una delegación existente en lugar de crear esa delegación de la nada.

El relato retrospectivo de RFC 7020 refuerza el punto sin resolver cada detalle histórico. Dice que RFC 1366 propuso delegar responsabilidad a organismos regionales y señala la sucesión a través de RFC 1466 y RFC 2050. También dice que el sistema de registros de números cambió significativamente después de RFC 2050. Eso establece un linaje reconocido en un documento Informativo de 2013, no un mandato inalterado que se extiende desde 1993 hasta un sistema posterior de cinco registros.

La afirmación defendible de 1993 es que RFC 1466 codificó las calificaciones para los delegados regionales, asoció bloques geográficos de Clase C con la responsabilidad regional primaria y retuvo un respaldo central. Vinculó el servicio, la asignación y la coordinación dentro de una estructura institucional en desarrollo. Si el nivel regional perduró más tarde porque ofreció un mejor servicio, mantuvo recursos delegados, redujo la carga de trabajo central o se volvió costoso de reemplazar requiere evidencia más allá de la disposición misma.

RIPE 95: una implementación fechada a nivel de formulario

ElEuropean IP Network Number Application Form and Supporting Notes, RIPE 95, proporciona una visión más concreta pero estrechamente acotada. Emitido el 1 de octubre de 1993, declaró que era válido solo hasta el 30 de diciembre de 1993. Es evidencia de un formulario europeo particular y de los canales de presentación prescritos durante ese período, no un libro de reglas operativo indefinidamente.

Su introducción describió un arreglo distribuido en el que InterNIC delegaba bloques a RIPE NCC, que a su vez delegaba a los registros de Internet locales. Se indicaba a los solicitantes que presentaran primero a través de un registro local. Se decía a un cliente de un proveedor de servicios de Internet que contactara a ese proveedor; un solicitante sin tal proveedor era dirigido al registro local apropiado que no fuera proveedor de servicios. Alguien inseguro sobre la ruta correcta podía contactar a RIPE NCC para obtener asesoramiento. El formulario no autorizaba generalmente la incertidumbre como razón para eludir la ruta local de primera instancia.

Las solicitudes de Clase B seguían una escalada más clara. El solicitante presentaba a través de un registro local. Si el registro local consideraba que la solicitud estaba justificada, remitía el material a RIPE NCC, que era el único que asignaba números de Clase B en Europa bajo el arreglo establecido. Eso es evidencia de canales prescritos y niveles de revisión. No es evidencia del número de solicitudes remitidas, rechazadas o modificadas.

El formulario dividió la información en material administrativo público y material técnico confidencial. Los campos públicos cubrían el nombre de la red, la descripción de la organización, el país, los contactos administrativos y técnicos, direcciones y detalles de comunicación. La sección técnica, descrita como confidencial y excluida de la base de datos pública de RIPE, solicitaba la clase y cantidad solicitada, las máquinas actuales, las estimaciones de máquinas a uno y dos años, las subredes actuales y proyectadas, el estado de conectividad a Internet, los números de red existentes y los países en los que operaría la red.

Sus ejemplos hacen visible la distinción entre valores brutos y utilizables. El formulario enumeró una Clase C como un máximo de 254 hosts, dos como 508, cuatro como 1.016, ocho como 2.032, 16 como 4.064 y 32 como 8.128. Estos eran los máximos de host utilizables según la convención de la época después de excluir dos identificadores por red de Clase C. No cambiaron el esquema bruto de RFC 1466 de 256 valores de dirección por Clase C.

Las solicitudes de más de dos Clases C requerían una descripción de red más completa. Se pedía a los solicitantes que justificaran los tamaños de subred, las redes de tránsito y los servidores terminales. Las asignaciones existentes importaban: se esperaba que las organizaciones que buscaban espacio adicional describieran los números de red utilizados y no utilizados, las subredes instaladas, los hosts conectados y otros hechos estructurales. Los objetivos declarados eran el uso eficiente y las asignaciones contiguas siempre que fuera posible para que la información de enrutamiento pudiera agregarse.

Para las solicitudes de Clase B, RIPE 95 describió los criterios como extremadamente estrictos debido a la escasez global. Las estimaciones de host debían respaldarse con información como el número de empleados, la distribución geográfica y los tipos de host. Los solicitantes debían explicar por qué las Clases C contiguas no podían soportar el diseño. La conveniencia administrativa fue expresamente descartada. Las solicitudes de múltiples Clases B requerían una justificación detallada capaz de persuadir tanto al registro local como a RIPE NCC.

Esta es una evidencia más fuerte que un documento de política por sí solo para una proposición limitada: los requisitos de información de la era del RFC llegaron a un formulario de solicitante fechado en Europa. Los campos muestran cómo las máquinas proyectadas, las subredes, las asignaciones previas y la conectividad se hicieron legibles para los revisores. La ruta local de primera instancia y la escalada de Clase B identifican el camino administrativo prescrito.

El formulario es una evidencia mucho más débil para la adjudicación. No contiene un denominador de solicitudes completadas, remisiones, aprobaciones, rechazos o retiros. No muestra si dos solicitantes similares fueron tratados de igual manera, si los revisores siguieron cada campo, cómo se razonaron las excepciones, si los pronósticos se verificaron posteriormente o si un solicitante consideró el proceso como legítimo. Un formulario estándar puede demostrar la divulgación esperada sin demostrar decisiones consistentes.

Tampoco puede establecer la continuidad hasta 1996. Su fecha de caducidad es explícita. Un formulario posterior pudo haber retenido, modificado o eliminado campos individuales, pero esa conclusión requiere el instrumento posterior. Por lo tanto, RIPE 95 debe permanecer como una observación fechada: una implementación a nivel de formulario de partes de la arquitectura de 1993, limitada a finales de 1993 y a Europa.

Noviembre de 1996: un reemplazo textual, no un evento instantáneo

En noviembre de 1996,RFC 2050declaró explícitamente obsoleto y reemplazó a RFC 1466. Publicado como Mejor Práctica Actual 12, decía que las directrices y procedimientos anteriores habían sido actualizados y modificados a la luz de la experiencia. Textualmente, la sucesión es inequívoca.

Su nota de estado requiere precisión. El Internet Engineering Steering Group dijo que la aprobación reflejaba su creencia de que la política representaba con precisión la práctica actual de asignación del registro. La nota agregó de inmediato que la aprobación no constituía un respaldo o recomendación del IESG. También anticipó una reevaluación en diciembre de 1997 tras más discusiones.

Esa nota apoya una afirmación de codificación publicada y práctica actual reclamada. No autentica una decisión separada de retención institucional, no establece una implementación uniforme en todos los registros ni prueba que cada disposición entrara en vigor simultáneamente con la publicación. El estado del RFC, la obsolescencia, la práctica reclamada y la implementación son proposiciones distintas.

Los cambios técnicos fueron sustanciales. RFC 2050 organizó la distribución en torno a tres objetivos: conservación, enrutabilidad y registro. Conservación significaba distribución justa basada en la necesidad operativa y prevención del acaparamiento. Enrutabilidad significaba distribución jerárquica que ayudara a la escalabilidad del enrutamiento, mientras se negaba expresamente a garantizar que las direcciones asignadas serían enrutadas. Registro significaba mantener un registro público para preservar la unicidad y apoyar la resolución de problemas.

El documento reconoció que estos objetivos podían entrar en conflicto entre sí y con los intereses de los usuarios finales y los proveedores de servicios. Hizo un llamado al análisis y juicio en casos individuales. La discreción posterior, por lo tanto, tenía una base de tres objetivos recién articulada en lugar de simplemente repetir el problema de Clase B versus Clase C.

RFC 2050 describió una jerarquía establecida de IANA, registros regionales y registros locales. En ese momento nombró tres registros regionales: InterNIC, RIPE NCC y APNIC. Esa descripción de 1996 no debe ser reemplazada por la geografía posterior de cinco registros. Los registros regionales operaban en grandes áreas geopolíticas, coordinaban los registros locales y se describían como establecidos bajo la autoridad de IANA con el consenso de la comunidad de Internet regional.

La asignación ahora era explícitamente sin clases. Los registros regionales emitían bloques en límites de bits compatibles con CIDR. Las asignaciones se hacían por longitud de prefijo en lugar de como Clase B o Clase C. Las suposiciones con clases hechas por conveniencia administrativa requerían una justificación especial. Una organización que anteriormente podría haberse descrito como receptora de una Clase B recibiría en su lugar un prefijo/16si ese tamaño estuviera justificado, independientemente de la clase de dirección histórica.

La jerarquía de proveedores se volvió central para la enrutabilidad. Un proveedor de servicios de Internet que cumpliera las condiciones de enrutamiento especificadas, incluyendo el multihoming calificado o la conexión directa a un intercambio importante definido, podía solicitar espacio a un registro regional en su área geográfica. Un proveedor sin un registro regional designado podía contactar a otro registro regional, que podía manejar o remitir la solicitud. Generalmente se indicaba a otros proveedores que obtuvieran espacio de un proveedor ascendente para que las asignaciones pudieran encajar en los agregados del proveedor.

El documento advirtió que las direcciones emitidas directamente por un registro estaban entre las menos propensas a ser enrutables globalmente. Alentó a los proveedores a tratar las asignaciones a los clientes como préstamos durante la duración de la conectividad y contempló la renumeración cuando un cliente cambiaba de proveedor. Esta era una relación diferente entre agregación y asignación a la cuadrícula geográfica amplia de Clase C de RFC 1466.

Para los nuevos proveedores de servicios, RFC 2050 prescribió un inicio lento. La asignación inicial debía ser mínima y basarse en el requerimiento inmediato demostrado. Los bloques posteriores podían aumentar después de que el registro regional verificara la utilización. Los registros principales determinaban los tamaños iniciales y subsiguientes. El número proyectado de clientes tenía poca influencia, y una asignación adicional estaba destinada a cubrir aproximadamente tres meses de asignaciones.

Esa regla de asignación de proveedores debe permanecer separada de la directriz de asignación para empresas finales. Para una empresa final, RFC 2050 enumeró un 25% de utilización inmediata y un 50% de utilización en un año. Definió la utilización como los hosts conectados divididos por el total de hosts posibles en la red. Una organización debía mostrar una alta confianza en su proyección de un año y proporcionar documentación de respaldo. La topología podía justificar excepciones, pero los porcentajes se presentaron como la directriz común.

El documento posterior también requirió planes de ingeniería de red. Antes de la asignación, un registro debía examinar las máscaras de subred, los hosts por subred, la topología, los planes de enrutamiento y las limitaciones del protocolo, con información de subred y host que cubriera al menos un año. Las asignaciones de direcciones anteriores en divisiones y subsidiarias debían ser contabilizadas. Los registros podían requerir evidencia corroborante e información que confirmara la identidad organizativa.

Estas demandas de información se asemejan a la arquitectura de 1993 a un alto nivel, pero servían a una prueba modificada. RFC 1466 utilizaba un pronóstico de 24 meses para determinar si múltiples Clases C eran razonables y para seleccionar un bloque con clases escalonado. RFC 2050 utilizaba la necesidad inmediata, la utilización a un año, la evidencia de uso previo, el tamaño del prefijo, la agregación del proveedor y las asignaciones por etapas. El solicitante aún proporcionaba información; la información ya no respondía a la misma pregunta de asignación.

La autoridad de auditoría también cambió. RFC 1466 permitía al registro central auditar los planes de ingeniería regionales de Clase B. RFC 2050 decía que todas las solicitudes de direcciones estaban sujetas a auditoría y verificación por los medios que un registro regional considerara apropiados. La información falsa podía dar lugar a la invalidación y devolución de las direcciones asignadas al grupo libre. Los registros regionales podían establecer umbrales de tamaño que requirieran una segunda opinión.

La confidencialidad y las rutas de revisión se describieron más completamente. La información identificada por un solicitante como sensible debía tratarse como confidencial. Si el registro asignador no podía garantizar la privacidad, su superior podía realizar la asignación. Una organización insatisfecha con una decisión de asignación tenía el derecho escrito de apelar al registro superior, con la posibilidad de apelar finalmente ante IANA después de agotar otras vías.

Estos eran poderes y salvaguardas publicados. Su inclusión no dice nada por sí misma sobre la selección de auditorías, la frecuencia de apelaciones, las tasas de revocación o el acceso en la práctica. Sin embargo, demuestran que el marco posterior no era meramente RFC 1466 con los nombres de clase eliminados. Replanteó la asignación en torno a CIDR, la jerarquía de proveedores, la utilización, el inicio lento, la verificación y la apelación.

La obsolescencia textual importa, por lo tanto. Después de noviembre de 1996, la línea base publicada autorizada era RFC 2050, no un RFC 1466 que continuara silenciosamente. Igualmente, la publicación no puede mostrar la fecha en la que cada formulario regional, hábito del revisor, herramienta de software o canal del solicitante cambió. La continuidad de las reglas y la continuidad institucional deben evaluarse por separado.

Cuatro explicaciones para la persistencia aparente

Tres características generales asociadas con RFC 1466 reaparecieron después de que su mecánica con clases perdiera autoridad: organizaciones regionales, cargas de información al solicitante y revisión discrecional. Su recurrencia no identifica su propia causa.

Cuatro explicaciones merecen consideración. La primera es la necesidad técnica continua. La asignación única, los grupos de direcciones finitos y la agregación de enrutamiento podrían justificar de forma independiente registros coordinados y revisión basada en evidencia después de que el problema de Clase B cambiara.

La segunda es la responsabilidad delegada. Una organización que posee bloques de direcciones, registros y obligaciones con los registros descendentes tenía responsabilidades prácticas que no desaparecieron cuando apareció un RFC sucesor. La continuación podría reflejar la necesidad de preservar asignaciones precisas y el servicio operativo en lugar del apego al texto anterior.

La tercera combina el costo de cambio y la inercia administrativa. El personal existente, los formularios, las bases de datos, los canales confidenciales, las relaciones de escalada y el conocimiento del solicitante hacen que el reemplazo institucional sea costoso. Ese mecanismo es plausible una vez que existe infraestructura, pero la plausibilidad no es medición. Las fuentes revisadas no valoran la transición ni documentan una alternativa rechazada.

La cuarta es la codificación textual posterior. RFC 2050 describió la jerarquía regional, la documentación del solicitante, la verificación y las apelaciones bajo un marco sin clases. Esto muestra que los autores posteriores reformularon y reorganizaron amplias funciones administrativas. Es más débil que un registro de decisión autenticado que identifique un órgano responsable, una disposición de 1993 retenida, las razones de la retención y una fecha de implementación.

Estas explicaciones no son mutuamente excluyentes. La necesidad técnica continua puede coexistir con la responsabilidad delegada. Una institución útil también puede ser costosa de reemplazar. La codificación posterior puede reconocer arreglos que se desarrollaron a través de la práctica en lugar de crearlos. La evidencia permite la comprobación selectiva de cada posibilidad, no una asignación numérica de causalidad.

Organizaciones regionales después de la cuadrícula geográfica

La disposición precisa de 1993 unía organizaciones regionales calificadas con la responsabilidad primaria dentro de amplios bloques de Clase C, preservando al mismo tiempo el servicio central predeterminado y una vía de respaldo directa. Su entorno técnico era la asignación con clases compatible con la agregación potencial. Su entorno institucional era un modelo en desarrollo de servicio distribuido geográficamente.

Para 1996, RFC 2050 describía los registros regionales como componentes establecidos de una jerarquía de tres niveles. IANA les asignaba; ellos coordinaban los registros locales; los registros locales y los proveedores servían a los usuarios descendentes. El mecanismo ya no era el simple emparejamiento de una organización regional con un bloque de Clase C de dos octetos. Implicaba asignaciones CIDR, direccionamiento basado en el proveedor, registros de reasignación y revisión jerárquica.

El texto posterior no repitió la lista completa de calificaciones de 1993. El idioma y las costumbres, la legitimidad más allá de la función de registro, una sola organización regional por área y el servicio central universal "si es necesario" no se reiteraron de la misma forma. RFC 2050 se refirió en cambio al consenso de la comunidad de Internet regional, la autoridad de IANA y la coordinación de los registros locales.

La evidencia observada dentro del período permanece acotada. RIPE 95 muestra un arreglo europeo de local a regional a finales de 1993. RFC 2050 codifica una jerarquía regional en noviembre de 1996 y la caracteriza como la práctica actual del registro, sujeta a la limitación de la nota del IESG. RFC 7020 reconoce más tarde el linaje institucional al tiempo que registra cambios importantes posteriores.

La necesidad técnica continua es una alternativa sólida a la causalidad centrada en el RFC. La unicidad de direcciones requería coordinación, y la agregación se beneficiaba de la distribución jerárquica. El servicio regional podía reducir la carga de trabajo central y colocar a los revisores más cerca de los solicitantes. Ninguna de esas necesidades dependía del uso continuo del mapa de Clase C de 1993.

La responsabilidad delegada también es plausible. RIPE NCC ya tenía un bloque antes de la adopción de RFC 1466. Una vez que los registros regionales y locales tenían espacio de direcciones, mantenían registros y servían a organizaciones descendentes, un reemplazo abrupto habría requerido transferencias de datos, autoridad y funciones técnicas. Las fuentes muestran que existían estas responsabilidades; no establecen los instrumentos completos por los cuales se mantuvo cada una.

El costo de cambio lo sugiere la infraestructura a nivel de formulario visible en RIPE 95. Los solicitantes tenían canales reconocidos, campos públicos y confidenciales, contactos locales y una ruta de escalada para la revisión de Clase B. Reemplazar esos arreglos impondría un esfuerzo. Ninguna evidencia revisada muestra que una alternativa propuesta fuera rechazada porque el costo se considerara excesivo.

La codificación posterior es el hecho documental más claro. RFC 2050 publicó una jerarquía bajo un régimen de asignación diferente. Llamar a esto readopción textual evita confundir la publicación con la prueba de una decisión de retención distinta u operación universal.

El respaldo central es donde una afirmación de continuidad inalterada falla más marcadamente. RFC 1466 decía que el registro central atendería a un suscriptor si fuera necesario. RFC 2050 en cambio describió los canales ordinarios de proveedor y regional, el contacto entre regiones cuando no existía un registro regional, la intervención del superior para la confidencialidad y las apelaciones jerárquicas. Estos mecanismos de nivel superior no son los mismos que la garantía anterior.

Las fuentes no muestran si el respaldo de RFC 1466 se utilizó con frecuencia, raramente, se redujo, se transformó o quedó inactivo. Tampoco establecen su exigibilidad o conveniencia práctica. La conclusión segura es que la administración regional persistió en forma publicada mientras su base técnica y jerarquía de servicio cambiaban. El rol perduró; la cuadrícula de asignación de 1993 y el lenguaje de respaldo no perduraron demostrablemente sin cambios con él.

Divulgación del solicitante después de los umbrales con clases

RFC 1466 requería que un solicitante de Clase B presentara proyecciones de subred y host, explicara por qué las Clases C no eran razonables y revelara un plan de ingeniería de 24 meses. Su esquema de Clase C también dependía de una estimación de dos años de las direcciones de sistema final requeridas. RIPE 95 tradujo demandas relacionadas en campos que cubrían máquinas presentes y futuras, subredes, conectividad, asignaciones previas y estructura de red.

RFC 2050 retuvo la proposición general de que una solicitud no era autovalidante. Un registro examinaba la evidencia sobre los planes de red, la topología, el enrutamiento, el uso previo y la utilización esperada. Los proveedores que buscaban asignaciones adicionales debían demostrar el uso. Las empresas finales enfrentaban expectativas de utilización inmediata y a un año. Se podía requerir corroboración.

Los actores portadores diferían según el nivel. Un registro local o un proveedor podía recibir una solicitud ordinaria. Un registro regional podía revisar asignaciones más grandes o directas. Un registro superior podía involucrarse en confidencialidad, segundas opiniones o apelaciones. El solicitante seguía dependiendo de una evaluación institucional, pero el órgano revisor y el propósito probatorio variaban.

El mecanismo cambió más de lo que la recurrencia de formularios podría sugerir. En 1993, una proyección de dos años seleccionaba entre la elegibilidad de Clase B y los bloques de Clase C en potencias de dos. En 1996, un nuevo proveedor comenzaba con espacio mínimo basado en la necesidad inmediata, mientras que el espacio adicional del proveedor cubría aproximadamente tres meses después de la verificación de la utilización. Una empresa final se evaluaba contra la utilización inmediata y a un año, definida por los hosts conectados sobre los hosts posibles.

Ese cambio redujo materialmente el papel del crecimiento especulativo para los proveedores. RFC 2050 decía que la base de clientes proyectada tenía poco efecto en las asignaciones del registro principal. El uso histórico y la necesidad por etapas se volvieron más importantes. La recopilación de información sobrevivió, pero su lógica pasó de elegir unidades con clases a controlar la asignación sin clases a lo largo del tiempo.

La escasez continua proporciona una explicación independiente. Un grupo finito y una demanda incierta crean una razón para pedir evidencia a los solicitantes incluso si no existe un formulario anterior. La enrutabilidad añade otra: la topología y las relaciones con los proveedores afectan si un prefijo puede contribuir a la agregación. La carga de información posterior podría, por lo tanto, justificarse por las condiciones técnicas actuales en lugar de por un hábito heredado.

La capacidad administrativa existente sigue siendo un contribuyente plausible. Los revisores ya sabían cómo manejar planes confidenciales, asignaciones previas y proyecciones. Los solicitantes ya se encontraban con preguntas estandarizadas. Una prueba técnica modificada podía insertarse en canales familiares. Ese es un relato creíble de adaptabilidad, no una prueba de que la inercia causó las reglas posteriores.

La codificación publicada es de nuevo el resultado más firme. RFC 2050 requería documentación bajo un nuevo marco. El artículo puede establecer la recurrencia textual y una implementación a nivel de formulario de 1993. No puede establecer un uso ininterrumpido del mismo formulario, una práctica estable del revisor o efectos consistentes a lo largo del período 1993–1998.

La vida institucional posterior es, por lo tanto, más estrecha que la supervivencia de un umbral particular. La característica duradera fue una arquitectura de solicitud en la que un solicitante proporcionaba evidencia de red y un registro la interpretaba en función de objetivos compartidos de recursos y enrutamiento. Las pruebas de 32 subredes, 4.096 hosts y 24 meses no sobrevivieron como la gramática general de asignación.

Discreción recodificada bajo diferentes objetivos técnicos

RFC 1466 reservó el juicio en varios puntos. Las asignaciones de Clase A quedaban a discreción de IANA. Un solicitante de Clase B fuera de los umbrales sugeridos podía argumentar que las Clases C eran técnicamente inutilizables. Una asignación de Clase C podía apartarse del esquema predeterminado cuando la estructura de la red local lo justificara. Los bloques de Clase C más grandes y otras excepciones se determinaban caso por caso.

Su posible auditoría se refería a la supervisión del registro central de los planes de ingeniería que respaldaban las asignaciones regionales de Clase B. La autoridad era permisiva: el registro podía exigir contabilidad y podía auditar. Esa redacción establece la discreción para actuar, no evidencia de que la acción fuera frecuente o sistemática.

RFC 2050 recodificó la discreción de manera más amplia. La conservación, la enrutabilidad y el registro podían entrar en conflicto entre sí y con los intereses individuales. Se esperaba que los registros ejercieran el juicio. Las consideraciones topológicas podían justificar desviaciones de las directrices de utilización. La eficiencia del enrutamiento, el historial de asignaciones previas y los planes de red se evaluaban caso por caso. Se podían requerir segundas opiniones por encima de un umbral regional.

El documento posterior también declaró que todas las solicitudes estaban sujetas a auditoría y verificación y permitió la invalidación cuando una asignación se basaba en información falsa. Al mismo tiempo, formalizó las obligaciones de confidencialidad y una ruta de apelación. La arquitectura publicada combinaba la autoridad del revisor con vías establecidas para la revisión superior.

Esto no era una continuación inalterada de RFC 1466. El juicio anterior se centraba en la selección de clase, la factibilidad de múltiples Clases C y las desviaciones de un esquema con clases. El juicio posterior se refería a la longitud del prefijo, la necesidad inmediata, la utilización, la agregación del proveedor, la probabilidad de enrutamiento y el diseño de red sin clases. Verbos institucionales similares ocultaban objetos técnicos diferentes.

La necesidad continua es especialmente persuasiva aquí. Ningún umbral fijo puede representar cada topología, y la conservación puede entrar en conflicto con la agregación de enrutamiento. El juicio experto puede persistir porque los casos varían, no porque una organización sea incapaz de abandonar una práctica anterior.

La herencia administrativa aún puede importar. Un registro ya equipado para recibir planes y proteger la información confidencial podía extender la revisión a la evidencia de utilización y enrutamiento. La delegación jerárquica también colocaba el juicio en múltiples niveles. Sin embargo, las fuentes no revelan si los revisores aplicaron una cultura interpretativa estable a través de la ruptura documental.

La codificación posterior es observable en el texto. La consistencia operativa no lo es. Una excepción escrita dice que se pueden considerar casos atípicos; no revela la frecuencia o dirección de la excepción. La autoridad de auditoría identifica un poder; no revela el método de selección, los hallazgos o las consecuencias. Una ruta de apelación escrita identifica un remedio; no establece la accesibilidad, el uso o la revocación.

La afirmación apropiada sobre la vida posterior es, por lo tanto, funcional y limitada. La discreción del registro sobre la conservación de recursos y el diseño de la red reapareció bajo RFC 2050, con un lenguaje de auditoría más amplio y una disposición de apelación escrita. Los criterios sustantivos cambiaron, y la evidencia no muestra que la discreción posterior fuera causada por RFC 1466 o se ejerciera de manera uniforme.

Lo que el registro publicado establece—y lo que oculta

La secuencia documental es clara en varios puntos. RFC 1466 se publicó en mayo de 1993 como un plan Informativo. Contenía estadísticas con clases, pruebas de Clase B, esquemas de Clase C contiguas, criterios de calificación regional, excepciones caso por caso y un respaldo central directo. También reconoció que RIPE NCC tenía un bloque de Clase C antes de la adopción.

RIPE 95, válido hasta el 30 de diciembre de 1993, muestra un formulario europeo que solicita información de red presente y proyectada y prescribe una ruta de registro local de primera instancia. RFC 2050 se publicó en noviembre de 1996 como BCP 12, reemplazó expresamente a RFC 1466 y codificó la asignación sin clases, la jerarquía de proveedores, el inicio lento, la revisión de utilización, la verificación y las apelaciones. RFC 7020 proporcionó un linaje retrospectivo en 2013 al tiempo que reconoció cambios significativos posteriores.

El registro es escaso cuando la unidad cambia de un documento a un caso. Ninguna fuente revisada proporciona un denominador para el total de solicitudes, aprobaciones, rechazos, retiros, excepciones, auditorías, apelaciones, contactos directos con el IR, remisiones o solicitudes abandonadas. No hay una población vinculada que muestre qué canal utilizó primero un solicitante, qué evidencia se solicitó, cómo razonó un revisor, qué bloque se asignó, si se aplicó una excepción, si ocurrió una auditoría o si una apelación cambió el resultado.

Los registros de asignación agregados no pueden recuperar todos esos hechos. Un bloque emitido identifica un resultado de asignación, pero no las alternativas rechazadas, las solicitudes retiradas, los solicitantes no exitosos, los motivos del revisor o la ruta por la que llegó la solicitud. Una agrupación retrospectiva de bloques por organización reguladora no puede identificar qué regla causó una asignación individual.

Los denominadores faltantes limitan las afirmaciones de diferentes maneras. Sin casos de IR directo, el respaldo de 1993 no puede clasificarse como robusto, nominal o impracticable. Sin poblaciones de excepciones, los umbrales publicados no pueden traducirse en regularidad real. Sin registros de auditoría, la autoridad no puede convertirse en frecuencia de aplicación. Sin registros de apelaciones, un remedio escrito no puede evaluarse en cuanto a acceso o efecto.

La correspondencia contemporánea en torno a RFC 2050 respondería a una pregunta diferente. El sucesor decía que actualizaba y modificaba las disposiciones anteriores a la luz de la experiencia, pero las fuentes revisadas aquí no proporcionan un relato completo cláusula por cláusula de lo que los autores pretendían preservar, lo que consideraban obsoleto o lo que ya podría haber caído en desuso. El reemplazo textual prueba la sucesión. No revela cada motivo de reemplazo.

La ausencia de estos registros no es evidencia de consentimiento, oposición, equidad o fracaso. Es un límite a la inferencia. Los documentos muestran lo que las instituciones publicaron, lo que un formulario de finales de 1993 pedía a los solicitantes que proporcionaran y cómo un sucesor de 1996 describió el sistema de registros. No establecen una historia operativa a nivel de toda la población.

Ese límite también protege contra un error opuesto: asumir la persistencia institucional meramente porque los relatos retrospectivos posteriores reconocen un linaje. Un linaje puede contener una revisión extensa. RFC 2050 desplazó los umbrales con clases, cambió la unidad de asignación a la longitud del prefijo, formalizó el inicio lento y replanteó la agregación en torno a los proveedores y CIDR. El propio RFC 7020 dice que el sistema cambió significativamente después de 1996.

Una respuesta acotada

RFC 1466 no era textualmente temporal. No proporcionó caducidad, ni etiqueta de interino, ni ocaso institucional. Su declaración de que las recomendaciones solo retrasarían el agotamiento describió los límites del remedio técnico, no una promesa de que la delegación regional, la divulgación del solicitante o el juicio del registro expirarían con la asignación con clases.

Sin embargo, fue textualmente declarado obsoleto en noviembre de 1996. RFC 2050 desplazó materialmente su prueba de Clase B, el algoritmo geográfico de Clase C y el esquema con clases de 24 meses. La asignación por longitud de prefijo, los límites CIDR, la jerarquía de proveedores, el inicio lento, la utilización verificada y las proyecciones a un año para empresas finales se convirtieron en el marco publicado.

Algunas capacidades administrativas asociadas con el plan de 1993 reaparecieron. Las organizaciones regionales ocuparon una posición publicada entre IANA y los registros descendentes. Los solicitantes continuaron proporcionando evidencia de red. Los registros continuaron juzgando la escasez, la topología y la agregación, ahora bajo criterios diferentes. RIPE 95 proporciona un ejemplo fechado de implementación a nivel de formulario, mientras que RFC 2050 proporciona la codificación posterior y una afirmación sobre la práctica actual.

Las fuentes no establecen que RFC 1466 causara la persistencia de esas capacidades. La administración regional ya se estaba desarrollando antes de su adopción. La necesidad técnica continua, la responsabilidad delegada, el costo de cambio, la inercia administrativa y la codificación posterior siguen siendo explicaciones plausibles y superpuestas. El registro no distribuye su peso causal.

La distinción final es, por lo tanto, nítida. RFC 1466 no era textualmente temporal; fue textualmente declarado obsoleto en 1996; y la evidencia publicada muestra una implementación limitada a nivel de formulario y una codificación posterior sin probar que el plan de 1993 causó la persistencia operativa que se le atribuye.