RIPE NCC · Vigilancia de RIR
Consulta aquí el historial de cada propuesta: qué cambió, por qué fue relevante, quién defendió cada postura, cómo evolucionaron las posiciones, qué se decidió y dónde persisten las lagunas en la evidencia.
Hechos con fuentes
¿Quiénes marcaron realmente el debate?
Análisis de BTW
No puede establecerse ningún cambio sustantivo o procedimental de la política porque la cronología verificada está vacía y no se aportaron versiones, modificaciones, fechas, hitos ni decisiones. Esto no demuestra que no hubiera cambios; únicamente indica que el conjunto suministrado no permite identificarlos.
No puede determinarse el objeto real del debate porque no se suministraron mensajes, argumentos, posiciones de participantes ni argumentos minoritarios o no resueltos. Atribuir una controversia concreta, incentivos o una disputa de poder excedería los hechos verificados.
No es posible distinguir entre discusión y decisión. La revisión registra cero mensajes, cero participantes de discusión y cero actores formales, mientras que la cronología está vacía; por tanto, no acredita debate observable ni permite determinar si la política fue aceptada, rechazada, retirada, abandonada, sustituida o resuelta administrativamente.
Las participaciones top-1, top-5 y top-10, el HHI y el número efectivo de participantes son cero, pero también lo son los mensajes y los participantes. En consecuencia, no existe una base sobre la cual medir concentración: estos valores no prueban participación distribuida, igualdad de influencia ni ausencia de dominio.
No puede identificarse un cuello de botella sustantivo, procedimental o institucional porque no se suministraron actores, intervenciones, hitos ni registros de decisión. El único cuello de botella demostrable es probatorio: la ausencia de cronología, posturas y actividad capturada impide localizar puntos de veto, control de agenda o aprobación.
Resource coverage and investigation boundary · Version 2 expressly includes unassigned IP address space and Autonomous System Numbers and limits investigation to suspected hijackers subject to RIPE policies. Version 1 instead expressly makes both parties' location irrelevant. This compares proposed coverage and does not establish present jurisdiction or an adopted enforcement rule.
The location of the resource holder or hijacker in such cases is irrelevant. A hijack constitutes a policy violation even if both parties are located outside of the RIPE NCC service region. The announcement of unallocated address space to third parties is also considered a policy violation and is evaluated according to the same parameters.Hechos con fuentes ↗
A hijack of numbering resources or the announcement of unallocated or unassigned IP addressing space or Autonomous System Numbers to third parties are also considered a policy violation. Only reports in which the suspected hijacker is subject to RIPE policies can be investigated.Hechos con fuentes ↗
More explicit exclusions for accidental events · Version 2 develops the distinction between accidental and deliberate conduct: clearly accidental cases are dismissed, BGP leaks are outside scope, and proven third-party manipulation of the alleged hijacker's infrastructure is not treated as intentional. Similar-looking prefixes and parallel legitimate announcements are not sufficient by themselves to prove intent. Version 1 gives general assessment factors without these express safeguards.
A distinction can be made between accidental or deliberate hijacks from available routing datasets, looking at parameters such as duration, recurrence, possible goals, and the size of hijacked blocks.Hechos con fuentes ↗
BGP leaks are outside the scope of this policy. Any case strictly related to BGP leaks should be dismissed.Hechos con fuentes ↗
Directly affected claimants and six-month evidence limit · Version 2 permits reports only from directly affected networks: legitimate resource holders or networks that received the hijacked route or AS path. It excludes reports by unaffected parties and evidence older than six months at submission. Version 1 relies on external reports without stating these limits; both versions exclude pre-implementation events.
It must therefore rely on external parties, both to report hijacks and determine whether they are deliberate.Hechos con fuentes ↗
A report is not admissible if the person reporting it was not affected in any way by the hijack. Evidence older than six months, counted from the time a report is submitted, cannot be considered or included in any expert report.Hechos con fuentes ↗
Earlier notice and treatment of connected networks · Version 2 makes reported routes or ASNs public to reduce duplicate reports and notifies identified parties early so they can respond and mitigate harm. It also provides for informational notice to direct upstream or transit providers and investigation of related organisations. Such notice is not a formal warning; experts are separately prohibited from adding accused parties to the case. Version 1 mainly provides notice when the judgement report is sent to the suspected hijacker.
A report containing an expert judgement on the case will be sent to the suspected hijacker.Hechos con fuentes ↗
Information regarding the hijacked routes/ASNs reported will be made publicly available to limit the risk of duplicate reports being submitted. The involved parties will be notified as soon as they are identified. This will allow them to provide any relevant information and mitigate the hijack, avoiding further damages and possibly false claims.Hechos con fuentes ↗
Longer initial assessment with an express dismissal consequence · Version 2 extends the expert judgement deadline from four to six weeks after receipt of the report and expressly requires dismissal if it is missed. The retained Version 1 states the four-week deadline without that dismissal rule.
Experts from this pool will provide a judgement regarding each reported case, no later than four weeks from the moment the report was received.Hechos con fuentes ↗
Experts from this pool will provide a judgement regarding each reported case, no later than six weeks from the moment the report was received. If this judgement report is not completed within six weeks, the case will be dismissed.Hechos con fuentes ↗
Defined expert qualifications and eligibility · Version 2 adds an open biennial selection process, suggested BGP experience, support from three networks in three economies under different LIR sponsorships, and a four-consecutive-year service limit followed by a two-year break. Proposal authors and active RIPE working-group chairs cannot serve as experts. Version 1 only requires the RIPE NCC to define a worldwide expert pool.
The RIPE NCC will define a pool of worldwide experts who can assess whether reported BGP hijacks constitute policy violations.Hechos con fuentes ↗
To join the pool of experts, a candidate will need a statement support from three different networks (ASes) from three different economies within the RIPE NCC service region, which are within different LIR sponsorships. The authors of this proposal and active RIPE WG Chairs are not eligible to become experts.Hechos con fuentes ↗
Multi-expert panels and case-integrity safeguards · Version 2 requires at least three experts per case and phase, with any larger panel having an odd number and the same size used across cases. It adds random assignment, confidential panel identities, impartiality declarations, appeal confidentiality, continuity and replacement rules, legal insurance and a minimum available pool twice the per-case minimum. These replace Version 1's largely unspecified expert arrangement.
The RIPE NCC will define a pool of worldwide experts who can assess whether reported BGP hijacks constitute policy violations.Hechos con fuentes ↗
The minimum number of experts per case and phase will be three. If a larger number is necessary, it must be odd, and the community will be informed of the reasons for the change. The experts for each case/phase will be chosen at random, to ensure a balanced sharing of cases.Hechos con fuentes ↗
Unanimity and procedural independence · Version 2 adds a sufficiency check before assignment, a response opportunity for the suspected hijacker and a joint expert report. An intentional-hijack finding requires unanimity. RIR staff cannot sit on the panel, and neither the RIPE NCC nor claimants may appeal the experts' decisions. These safeguards are not specified in Version 1's short lines-of-action provision.
Experts from this pool will provide a judgement regarding each reported case, no later than four weeks from the moment the report was received.Hechos con fuentes ↗
For an event to be identified as an intentional hijack, there must be unanimity between all experts on the case. Experts cannot add accused parties to a case.Hechos con fuentes ↗
A separate unanimous panel for appeals · Version 2 replaces review by an alternative expert with a different panel of at least three experts. All reviewing experts must agree to maintain an intentional-hijack finding; otherwise the case is dismissed. The maximum two-week appeal-filing and four-week review periods remain, with finality after review.
If an appeal is filed, an alternative expert will review this for a maximum of four weeks. The results of this review are final and cannot be further appealed.Hechos con fuentes ↗
If an appeal is filed, an alternative set of experts (a minimum of three) will review the report for a maximum of four weeks. In order to maintain a ruling of “intentional hijack”, all experts involved in the review need to agree that this has occurred.Hechos con fuentes ↗
Ratification moves from the board to the experts · Version 2 replaces RIPE NCC Executive Board ratification with unanimous ratification by all experts involved, after a two-week public consultation. Without unanimity the report is archived, and experts may decline ratification on the basis of undisclosed information or consultation input. Ratification still waits for an appeal to finish.
Once the report has been published, any policy violation will be ratified by the RIPE NCC Executive Board. Otherwise, the complaint/report will be archived.Hechos con fuentes ↗
Once the report has been published, any policy violation will need to be ratified by all experts involved in the case, following a two-week public consultation on the report. If ratification is not declared unanimously, the report will be archived.Hechos con fuentes ↗
Transition arrangements and existing bogons · Version 2 adds six months of warning-only treatment for non-malicious announcements of unassigned resources and excludes bogons already present when implementation begins. Version 1 states only that eligible hijacks must occur after implementation. These are proposed transition protections, not evidence that an implementation date was reached.
Only hijacking events that occur after this policy has been implemented are eligible to be considered.Hechos con fuentes ↗
As soon as the policy implementation is completed, a transition period of six months will be established. This will allow organisations that announce unassigned address space or Autonomous System Numbers (due to operational errors or other non-malicious reasons) to receive only a warning.Hechos con fuentes ↗
Protection of legacy and uninvolved PI resource holders · Version 2 expressly preserves legacy registration, while allowing possible restrictions on other RIPE NCC services in the repeated-violation circumstances described later. Uninvolved PI holders are protected from deregistration and may change sponsoring LIRs; sponsorship alone does not make the LIR responsible for a customer's hijack. Version 1 has no comparable resource-holder safeguards.
There must be consequences for hijacking for members or individuals/organisations that have a service agreement (either directly or indirectly) with the RIPE NCC.Hechos con fuentes ↗
Holders of Provider Independent resources that are sponsored by an LIR that is found have committed a deliberate hijack will not have their resources de-registered and will be able to find a new sponsoring LIR (provided they were not involved). In the same way, a sponsoring LIR is not responsible if its customer is found to have committed a hijack.Hechos con fuentes ↗
Repeated violations rather than a single violation for closure · Version 2 expressly links possible closure procedures to regular and repeated hijacking and says a single policy violation is not a basis it endorses for initiating LIR closure. Version 1 discusses refusing or ending contractual relationships in its rationale without stating this repeated-conduct threshold. This does not make closure automatic.
However, the RIPE NCC needs to be able to choose not to enter into (or maintain) a contractual relationship with people/companies that are performing BGP hijacks.Hechos con fuentes ↗
This policy does not endorse the initiation of an LIR closure procedure on the basis of a single policy violation.Hechos con fuentes ↗
Cargando
Parcial
Primera captura: 30 jun 1992
Última captura: 12 nov 2026