Zum Hauptinhalt springen

LACNIC · RIR-Beobachtung

Registration and validation of abuse contact

Beginnen Sie hier mit der Dokumentation zu jedem einzelnen Vorschlag: Was änderte sich, warum war dies von Bedeutung, wer argumentierte wofür, wie entwickelten sich die Positionen, was wurde beschlossen und wo weist die Beleglage noch Lücken auf?

Quellenbelegte Fakten

Richtlinien-ID
LAC-2018-5
RIR
LACNIC
Offizieller Status
Implemented
Normalisierter Status
Angenommen
Eingebracht
04.03.2018
Letzte Quellenaktualisierung
13.10.2026
Abdeckung
Teilweise

Wer hat die Debatte tatsächlich geprägt?

6Beteiligte insgesamt
5Diskussionsteilnehmende
1Formelle Akteure
21Diskussionsbeiträge
2,6Effektive Beteiligte
100 %Diskussionsanteil der Top 5
2Personen für 50 %
2Personen für 80 %

Entwicklung der Richtlinie

2
Angenommen · Implemented
04.03.2018
Quellenbelegte Fakten ↗

Rationale—scope of mandatory abuse-c registration · The new rationale adds an explicit statement that the abuse-c attribute, previously referenced only for aut-num objects, is intended to become mandatory for inetnum, inetnum6, and any analogous future objects, and that it must contain at least an abuse-mailbox attribute; the old rationale proceeds directly to the proposed text without this statement.

Operational management of abuse-mailbox · The required mailbox changes from being valid and monitored to being valid, monitored, and actively managed, adding an express operational-management requirement.

Section 12.3—status and design of the validation procedure · The old text prescribes a ten-step validation workflow, including two consecutive plain-text emails, a specified validation URL, a separate code, anti-automation controls, temporary and permanent invalid status, and automatic repetition. The new text instead requires LACNIC to develop a procedure meeting five stated objectives; the detailed workflow is retained only as an example under Additional Information. This changes the detailed workflow from prescribed policy text to an illustrative implementation example.

Section 12.5—escalation mailbox address · The old text specifies [email protected] as the escalation mailbox. The new text makes that address illustrative by introducing it with “for example,” allowing a different mailbox to be used.

3
Angenommen · Implemented
04.03.2018
Quellenbelegte Fakten ↗

Scope of affected resource recipients · The supplied old text frames missing or ineffective abuse contacts primarily in terms of LIRs. The supplied new text broadens this framing to organizations that received LACNIC resources and expressly mentions LIRs/ISPs, end users, and other recipients.

Resource-object terminology for mandatory abuse contacts · The supplied old text identifies the relevant address objects as “inetnum” and “inetnum6.” The supplied new text instead refers to “inetnum” objects for both IPv4 and IPv6.

Policy Manual section and appendix numbering · The supplied new text adds a note specifying that the existing Section 12 appendixes would become Section A at the end of the Manual, with corresponding numbering updates, so the proposal text can become Section 12. The supplied old text proceeds directly to proposed Section 12 without this renumbering note.

Validation and escalation deadlines · The supplied old text sets a validation period of no more than two business days and, after failure, a three-business-day escalation period directed to the LIR. The supplied new text sets separate initial and escalated periods of up to fifteen days each, directs escalation to the resource recipient—including an LIR or end user—and authorizes LACNIC to modify both periods while informing the community of its reasons.

Periodic validation frequency · The supplied old text requires periodic validation at least once every three months. The supplied new text changes the minimum to twice per year and expressly allows LACNIC to modify the frequency while informing the community of its reasons.

Consequences of noncompliance · The supplied old text states generally that noncompliance will result in more exhaustive follow-up under relevant policies and procedures. The supplied new text adds an initial block on “milacnic” for all resources associated with the organization, except access needed to update and revalidate abuse contacts, followed by more exhaustive follow-up and action under applicable policies if the next automatic validation confirms continued noncompliance.

4
Angenommen · Implemented
04.03.2018
Quellenbelegte Fakten ↗

Placement and numbering of the proposed policy section · The old version placed the appendix-renumbering note before Section 12 as part of the proposed new-text presentation and stated that the proposal would become Section 12. The new version moves this note to Additional Information, expressly excludes it from the Policy Manual, and allows the policy section to use Section 12 or another number selected by staff at implementation.

Resources required to have an abuse-c contact · The requirement changes from all resources allocated by LACNIC to all resources that use LACNIC's registration systems.

Treatment of child objects · The old text said child IP-address objects may be covered by parent objects or may have their own abuse-c attribute. The new text says child objects, including sub-assignments, are covered by parent objects and that a child object's own abuse-c attribute is optional.

Submission and handling of abuse reports · The new text generalizes the reporting party from a company developing an interface for each case to any entity developing an interface for each resource recipient, broadens the acceptable initial information to information applicable to each type of abuse, and adds an expectation that an assigned ticket number be maintained throughout communications.

Automation of validation · The old validation objectives directed LACNIC to avoid automated processing. The new version states that a fully automated process should be avoided, while retaining a requirement for the validating person to understand the procedure, monitor the mailbox, take measures, and respond to reports.

Validation and escalation periods · The old policy set initial and escalated validation periods that must not exceed fifteen days. The new policy specifies an initial period of fifteen days and an additional period of fifteen days, with escalation expressly directed to the original recipient of the resources. Both versions permit LACNIC to modify the periods after informing the community, but the new text removes the example concerning future shortening of the periods.

Events and frequency triggering validation · The old text required validation when either abuse-c or abuse-mailbox was created or updated, periodically at least twice yearly, and whenever LACNIC saw fit. The new text requires periodic validation at least twice yearly and whenever abuse-c attributes are created or modified; it no longer expressly identifies abuse-mailbox-only changes or an unrestricted additional 'whenever LACNIC sees fit' trigger.

Validation-message domains and content · The old policy text authorized LACNIC to use domains other than lacnic.* and modify validation-message subjects and bodies. The new policy text removes that authorization from Section 12.4 and places comparable language in the non-policy example validation procedure under Additional Information.

Definition of noncompliance · The new version creates a separate Failure to comply section and expressly defines noncompliance as failure to validate during both the initial and additional validation periods. The old version did not provide this separate definition.

Consequences and scope of system blocking · The old text specified blocking milacnic for all resources associated with the organization, except access needed to update and revalidate abuse contacts. The new text applies blocking to MiLACNIC and equivalent NIR-system measures, adds exceptions for strictly contractual and payment matters, retains contact-update access, and requires blocked access attempts to display the policy warning for full reading and affirmative confirmation before proceeding.

Continued noncompliance and resource-recovery reference · The old version required more exhaustive follow-up and a subsequent automatic validation, then expressly referenced Policy 7.1, Resource recovery, if noncompliance continued. The new version instead states generally that LACNIC will act under its relevant policies and procedures and does not expressly require the follow-up automatic validation or name Policy 7.1.

Escalation of fraudulent or mishandled abuse contacts · The old version prescribed an escalation mailbox and contemplated LACNIC revalidation, intermediation, and application of relevant policies and procedures, expressly including Resource recovery. The new version states that fraudulent behavior or failure to manage abuse cases may be reported to LACNIC for revalidation under Section 12.4, without prescribing a mailbox or expressly providing for intermediation or Resource recovery in this section.

Non-policy example validation deadlines · In the Additional Information example, the validation-code validity changes from a maximum of two working days to a maximum of fifteen days, and the follow-up period before permanent invalidation changes from three working days to an additional fifteen days.

Non-policy escalation mechanisms · The new Additional Information example adds a requirement for LACNIC mechanisms such as a form or email address to facilitate reports of policy breaches, revalidation, and intervention under applicable policies, procedures, and contracts. The old example contained no corresponding numbered mechanism provision.

Implementation timetable · The old timetable described ninety days, subject to LACNIC confirmation, for tool development and LIR contact updates. The new timetable describes a reasonable time of ninety days, also subject to confirmation, extends the update language to recipients of LACNIC resources, and adds that LACNIC may send a reminder with notice of Board ratification.

6
Angenommen · Implemented
04.03.2018
Quellenbelegte Fakten ↗

Policy text · Astra identified a substantive wording change in this retained policy section.

Policy text · Astra identified a substantive wording change in this retained policy section.

Policy text · Astra identified a substantive wording change in this retained policy section.

Policy text · Astra identified a substantive wording change in this retained policy section.

Policy text · Astra identified a substantive wording change in this retained policy section.

Policy text · Astra identified a substantive wording change in this retained policy section.

Policy text · Astra identified a substantive wording change in this retained policy section.

Policy text · Astra identified a substantive wording change in this retained policy section.

Policy text · Astra identified a substantive wording change in this retained policy section.

Policy text · Astra identified a substantive wording change in this retained policy section.

Policy text · Astra identified a substantive wording change in this retained policy section.

Policy text · Astra identified a substantive wording change in this retained policy section.

Zeitverlauf der Debatte

  1. Eingebracht

    Eingebracht

    Quellenbelegte Fakten ↗
  2. Offizielle Version

    1

    Angenommen · Implemented

    Quellenbelegte Fakten ↗
  3. Offizielle Version

    2

    Angenommen · Implemented

    Quellenbelegte Fakten ↗
  4. Offizielle Version

    3

    Angenommen · Implemented

    Quellenbelegte Fakten ↗
  5. Offizielle Version

    4

    Angenommen · Implemented

    Quellenbelegte Fakten ↗
  6. Offizielle Version

    5

    Angenommen · Implemented

    Quellenbelegte Fakten ↗
  7. Offizielle Version

    6

    Angenommen · Implemented

    Quellenbelegte Fakten ↗
  8. Öffentliche Diskussion

    [LACNIC/Politicas] Nueva propuesta LAC-2018-5 / Nova proposta LAC-2018-5 / New proposal LAC-2018-5

    9 Diskussionsbeiträge · 4 Entitäten

    Quellenbelegte Fakten ↗
  9. Öffentliche Diskussion

    [LACNIC/Politicas] LAC-2018-5 Registro y Validación del "abuse-c" y "abuse-mailbox"

    9 Diskussionsbeiträge · 2 Entitäten

    Quellenbelegte Fakten ↗
  10. Öffentliche Diskussion

    [LACNIC/Politicas] opiniones de la propuesta LAC-2018-5 (abuse-c)

    2 Diskussionsbeiträge · 2 Entitäten

    Quellenbelegte Fakten ↗
  11. Offizielle Entscheidung

    accepted

    accepted

    Quellenbelegte Fakten ↗

Entitäten

Aktualität: Veraltet · Letzte Aktualisierung: · Die letzte Aktualisierung ist fehlgeschlagen. Das letzte erfolgreiche Ergebnis wird angezeigt.
  1. Diskussionsbeiträge10
    Erste Aktivität05.03.2018
    Letzte Aktivität26.09.2018
    Erste ausdrückliche HaltungUnterstützung
    Letzte ausdrückliche HaltungUnterstützung mit Änderungen
    Haltungswechsel3
    Konsistenz der PositionKonsistent
    Weitere Richtlinien39
  2. Diskussionsbeiträge8
    Erste Aktivität05.03.2018
    Letzte Aktivität26.09.2018
    Erste ausdrückliche HaltungAblehnung
    Letzte ausdrückliche HaltungUnterstützung mit Änderungen
    Haltungswechsel1
    Konsistenz der PositionGemischt
    Weitere Richtlinien25
  3. Diskussionsbeiträge1
    Erste Aktivität07.03.2018
    Letzte Aktivität07.03.2018
    Erste ausdrückliche HaltungAlternativvorschlag
    Letzte ausdrückliche HaltungAlternativvorschlag
    Haltungswechsel0
    Konsistenz der PositionKonsistent
    Weitere Richtlinien25
    Aktualität: Veraltet · Letzte Aktualisierung: · Die letzte Aktualisierung ist fehlgeschlagen. Das letzte erfolgreiche Ergebnis wird angezeigt.

    Letzter Rechercheversuch: 18.09.2026

    Identität verifiziert: 25.09.2026

    · Historisch
    Nicolas Antoniello
    lacnic.net
    · Historisch
    Nicolás Antoniello - Version [1]
    politicas.lacnic.net
    LACNIC · Historisch
    Nicolas Antoniello co-Chairs of Public Policy Forum - LACNIC
    mail.lacnic.net
    Diskussionsbeiträge
    1
    Erste Aktivität
    07.03.2018
    Letzte Aktivität
    07.03.2018
    Erste ausdrückliche Haltung
    Alternativvorschlag
    Letzte ausdrückliche Haltung
    Alternativvorschlag
    Haltungswechsel
    0
    Konsistenz der Position
    Konsistent
    Weitere Richtlinien
    25

    Erste ausdrückliche Haltung: Alternativvorschlag → Letzte ausdrückliche Haltung: Alternativvorschlag · Haltungswechsel: 0

    Konsistenz der Position: Konsistent

    The substantive comparisons show consistent concern for reliable registry records, meaningful community deliberation and the boundary between registration policy and operational policing. Two real changes are explained: moving from a formal GIR proposal to wider exploratory discussion, and from an inbound-only transfer proposal to a bidirectional IPv4 proposal. Joint moderator reports do not establish personal votes, and isolated comments remain insufficient for a longitudinal finding.

    Management of Returned Internet Resources

    Bewertung: Die Datenlage reicht nicht aus, um die Konsistenz zu beurteilen. · The joint co-chair notice reports board ratification of the returned-resources proposal. It does not establish Nicolas's personal position or a sequence of such positions.

    Bedingungen: A reported board decision is distinguished from the messenger's individual vote.

    The proposal was ratified and has entered the implementation stage.

    Creation of an IPv4 reserve exclusively for IPv6 deployment

    Bewertung: Die Datenlage reicht nicht aus, um die Konsistenz zu beurteilen. · The co-chair notice reports non-ratification of the IPv6-deployment reserve and the board's participation and implementation concerns. Those institutional reasons are not personal opposition by the sender.

    Bedingungen: The technical and participation statements are historical reported reasons, not independent verification of current routing behavior or registry capabilities. · The different outcomes for two proposals in one notice do not establish inconsistent personal treatment.

    The proposal was not ratified by LACNIC?s board and it has returned to the Policy List.

    Modification to the text describing ASN distribution requirements

    Bewertung: Die Datenlage reicht nicht aus, um die Konsistenz zu beurteilen. · The jointly signed status summary places the ASN-requirements proposal under board analysis. Summarizing proposed changes is not authoring or endorsing them, and no personal vote is supplied.

    Bedingungen: A mistaken heading in the English summary must not be used to infer a new personal position.

    Proposals on analysis by the board LAC-2014-2: "Modification to the text describing ASN distribution requirements".

    Update to the Policy Development Process

    Bewertung: Die Datenlage reicht nicht aus, um die Konsistenz zu beurteilen. · The January status report and May report of community approval describe successive procedural stages. They do not establish that Nicolas personally supported or changed his position on the PDP update.

    Bedingungen: The reports are jointly signed by the moderators. · Community approval and subsequent procedural reporting are not the same as a personal vote.

    Proposals in discussion: LAC-2014-3: "Update to the Policy Development Process".

    The proposal was approved by LACNIC community.

    Trigger 2.3.2.18 when a justified request larger than /22 is received which can not be allocated from any remaining pool of addresses at LACNIC.

    Bewertung: Die Datenlage reicht nicht aus, um die Konsistenz zu beurteilen. · The May joint report that the proposal returned to discussion is followed in September by explicit personal support based on keeping transfer records accurate. The earlier report is not a personal opposing position, so this is not evidence of a reversal.

    Bedingungen: The May language versions disagree on favorable votes and abstentions; the disputed figures are not treated as authoritative. · The detailed transfer provisions quoted in September are existing text being explained, not a new list of conditions authored by the sender. · Only the September contribution supplies an explicit personal vote.

    thus the proposal returns to the discussion list.

    Por todo ello, en este caso yo estoy a favor de esta propuesta

    Inter-RIR Transfers

    Bewertung: Die Datenlage reicht nicht aus, um die Konsistenz zu beurteilen. · The joint moderator report describes broad community interest in inter-RIR transfers and continued discussion of this particular proposal. It supplies no individual vote from Nicolas.

    Bedingungen: Community-level support must not be reassigned to each person signing a procedural report.

    while the majority of the community agrees that there should be a policy of Inter-RIR transfer, it shall continue the discussion.

    Settling IPv4-IPv6 connectivity disputes when only one of the protocols is supported

    Bewertung: Die Datenlage reicht nicht aus, um die Konsistenz zu beurteilen. · The author opposes the proposed connectivity-dispute mechanism because he doubts both the RIR's role and its ability to compel technical choices. One message establishes this scoped objection, not persistence or reversal over time.

    Bedingungen: Acknowledging a good intention is not support for the proposal as written. · The mandate and enforcement assessment is the author's reasoning.

    No estoy a favor de esta pol?tica tal cual est? planteada.

    dificilmente Lacnic pueda "obligar" a alguien a adoptar ciertas medidas

    Modify the size of initial IPv6 allocations

    Bewertung: Die Datenlage reicht nicht aus, um die Konsistenz zu beurteilen. · The author asks that internal delegation by noncommercial organizations be considered when assessing IPv6 utilization requirements. This single contribution identifies an operational case and suggests examination, without establishing a final vote or longitudinal consistency.

    Bedingungen: The Uruguay university example is the author's account. · An expectation of less frequent IPv6 reassignment is a forecast, not a demonstrated outcome.

    Tal vez debemos tener en cuenta esta situaci?n y analizar el nivel porcentual de exigencia de argumentaci?n de uso de las direcciones adapt?ndonos a estos casos que antes no hab?amos considerado.

    One-way interregional transfers to LACNIC

    Bewertung: Konsistent · The April questions about source regions, contracts and reciprocity develop into explicit support for inbound transfer registration. Throughout, the author distinguishes ethical discomfort with transfers from the practical need to record transactions that occur. Those two views are not contradictory.

    Bedingungen: The proposed inter-RIR workflow and recollection of ARIN discussions are questions and attributed understandings, not verified legal or procedural conclusions. · Supporting accurate registration does not imply approval of every commercial transfer.

    mantener un registro confiable por parte del RIR

    deber?amos aclarar bien ese punto con ARIN

    a fin de mantener los registros fiables tenemos que atender dicha realidad.

    apoyo enf?ticamente esta pol?tica LAC-2017-2.

    Modify the minimum size of IPv4 assignments to Internet Service Providers

    Bewertung: Die Datenlage reicht nicht aus, um die Konsistenz zu beurteilen. · The author requests differences between the two IPv4-size proposals, then expresses tentative agreement in principle while reserving a choice until exact changes are explained. These messages do not establish a final vote or a reversal.

    Bedingungen: A preference for merging proposals is a process suggestion, not a decision on their exact substantive wording.

    hagan alguna aclaraci?n ya que al menos a mi me parecen similares

    poder definirme por una de las propuestas o por ninguna.

    Modify the minimum size of initial allocations to ISPs

    Bewertung: Die Datenlage reicht nicht aus, um die Konsistenz zu beurteilen. · The same comparative discussion asks for each proposal's exact changes and objective before choosing either or neither. Tentative agreement with the direction does not establish endorsement of this particular text.

    Bedingungen: The two quoted proposal summaries are context for the question, not separately authored positions by Nicolas.

    por lo menos el t?tulo es pr?cticamente el mismo

    me gustar?a conocer a fondo las diferencias explicadas por los autores.

    Addenda − Resource revocation

    Bewertung: Die Datenlage reicht nicht aus, um die Konsistenz zu beurteilen. · The author proposes staff technical evaluation of essential resources followed by board ratification, with exceptional board discretion. This is a specific alternative division of responsibilities, but there is no second substantive contribution for comparison.

    Bedingungen: Calling the proposal interesting does not establish unconditional support. · The asserted limits of the board's technical role are the author's view.

    la evaluaci?n deber?a ser del staff de LACNIC el cual elevar?a una propuesta al directorio

    Reducing the last-call-for-comments period in LACNIC's Policy Development Process.

    Bewertung: Konsistent · Across the June discussion the author defends time for normal community review, rejects a period below thirty days and points urgent cases toward the expedited process. A possible thirty-day compromise does not retract that position or amount to firm support for shortening the period.

    Bedingungen: He acknowledges arbitrariness in the exact number of days. · Rare use of a review stage is not accepted by the author as proof that the stage is unnecessary. · His historical timing description is not a statement of today's PDP rules.

    no creo que dicho per?odo deba ser menor a 30 d?as.

    es una garant?a adicional a la comunidad

    para esos casos "urgentes" est? el proceso expeditivo.

    no veo positivo que se reduzca a menos de 30 d?as.

    Si se quiere llevar a 30 dias

    Proposal to create a Global Internet Registry (GIR)

    Bewertung: Konsistent · The author initially advocates a virtual global registry operated by the existing RIRs, defends its administrative purpose, and later proposes withdrawing the formal proposal while continuing wider discussion and seeking a clearer process. That is an explicit change in procedural strategy and urgency, while the possible value of a GIR remains under consideration.

    Bedingungen: The June withdrawal proposal must not be hidden or treated as continued pursuit of the same formal draft. · The later acknowledgement that a GIR may not yet be necessary qualifies urgency without becoming opposition to examining the concept. · Reports of circulation to other bodies are not evidence of their acceptance. · ICP-2 interpretations, cost expectations, operator recollections and future off-Earth scenarios remain the author's historical arguments, not independently verified present facts.

    no puede ser expeditivo en este caso porque no tendr?a sentido ?apresurar? una pol?tica global de este tipo

    Nuevamente todo est? abierto a discusi?n.

    un registro virtual operado por los mismos 5 RIRs

    los registros y el tratamiento de los recursos reflejen la realidad.

    No son t?cnicas. Son administrativas, pol?ticas y econ?micas

    El feedback de la idea es, como mencionas, lo m?s importante

    Puede que hoy no sea a?n tan necesario disponer de un GIR

    lo mejor es bajarla como propuesta y eventualmente platear la discusi?n en las listas de los diferentes RIR

    Minor revision to the PDP

    Bewertung: Konsistent · Support in principle develops into a repeated request for version-neutral wording about continuing discussion or abandoning a proposal. The author separately accepts restarting the discussion period. The shift from support to alternative-wording labels reflects specification of the same position, not withdrawal.

    Bedingungen: The final message calls the timing issue secondary to his wording suggestion; it does not oppose resetting the period. · No adoption of the proposed wording is established.

    En principio estoy de acuerdo con la modificacion que se propone.

    De esa forma queda libre lo de las versiones.

    Y luego habr?a que agregar en todo caso lo del reset de los meses.

    estoy de acuerdo en que se reinicie

    Inter-RIR Transfer Policy

    Bewertung: Die Datenlage reicht nicht aus, um die Konsistenz zu beurteilen. · The author supports a transfer policy for registry accuracy, but requests an IPv4-only, bidirectional proposal. This single contribution establishes those conditions; earlier transfer proposals provide cross-policy context rather than another vote on this same proposal.

    Bedingungen: Deferring IPv6 transfer rules is not permanent opposition to them. · The description of other RIR practices is the author's historical assertion.

    propongo que la propuesta sea sobre IPv4 estrictamente y por supuesto que trate las transferencias en forma bidireccional

    Registration and validation of abuse contact

    Bewertung: Die Datenlage reicht nicht aus, um die Konsistenz zu beurteilen. · The author accepts the idea of registering an abuse contact with changed wording, while preferring best-practice guidance to binding operational abuse-handling rules. Partial agreement and rejection of an enforcement role concern different provisions, not opposing votes on the same provision.

    Bedingungen: This does not establish support for the entire proposal as written. · His mandate and capacity concerns are assessments, not legal determinations.

    En principio estar?a de acuerdo con el primer punto de tu propuesta

    un manual de BCPs m?s que en una pol?tica.

    Simplification of the PDP

    Bewertung: Konsistent · A request for marked changes is followed by opposition to broad simplification and a defense of cumulative list-and-forum consensus. Interest in selected individual elements does not withdraw opposition to the package or to reducing the forum's role without a demonstrated need.

    Bedingungen: The initial request for review material is not an earlier supporting vote. · The author's participation, historical-frequency and legitimacy claims are arguments, not verified statistics or proof of equal access.

    un texto con control de cambios

    por ahora creo que el proceso es el adecuado para nuestra regi?n.

    no veo una urgencia para nuestra regi?n, que amerite quitarle importancia al lugar que ocupa el foro en el proceso.

    Clarifications of Sub-Assignments

    Bewertung: Die Datenlage reicht nicht aus, um die Konsistenz zu beurteilen. · The author tentatively prefers the option allowing a data centre to assign multiple addresses to customers. This one clarification does not establish a sequence of positions or endorsement of every sub-assignment clause.

    Bedingungen: References to other participants' clarifications are context, not additional positions independently expressed by Nicolas.

    me inclino m?s por la opci?n 2 que menciona Jordi, que permite asignar direcciones a los clientes (y no solo una).

    Update to the Policy on IPv4 Assignments to End Users

    Bewertung: Konsistent · The May request to clarify a scenario is followed in November by support for advancing the proposal because the author considers material objections addressed. Seeking clarification and later accepting the discussion's outcome are compatible; the earlier message did not oppose the proposal.

    Bedingungen: The later statement describes his assessment of resolved objections, not a formal declaration of community consensus.

    creo que Jordi debe aclararlo nuevamente en todo caso.

    no veo en este momento, en lo personal, nada que impida avanzar con esta propuesta.

    Trigger 2.3.2.18 when a justified request larger than /22 is received which can not be allocated from any remaining pool of addresses at LACNIC. · One-way interregional transfers to LACNIC

    Bewertung: Konsistent · Personal support for registering intra-regional transfers and later support for inbound inter-RIR transfers share the same reason: the registry should reflect actual resource use. The earlier moderator report of a failed forum outcome is not personal opposition.

    Bedingungen: Intra-regional and interregional mechanisms have different procedural requirements.

    los registros de LACNIC contin?en siendo vigentes y manteni?ndose actualizados.

    confianza y fiabilidad en los registros.

    One-way interregional transfers to LACNIC · Inter-RIR Transfer Policy

    Bewertung: Konsistent · The move from supporting inbound-only transfers in 2017 to requesting bidirectional IPv4 transfers in 2018 is an acknowledged design change. The author explicitly connects it to objections encountered by the earlier proposal, while retaining registry accuracy as his objective.

    Bedingungen: This is not an unchanged preference about directionality; it is an explained adaptation. · His account of why the earlier proposal was discarded remains attributed to him.

    apoyo enf?ticamente esta pol?tica LAC-2017-2.

    trate las transferencias en forma bidireccional ya que ese fue uno de los argumentos que se manejaron cuando se descart? la propuesta de transferencias unidireccionales anterior.

    Settling IPv4-IPv6 connectivity disputes when only one of the protocols is supported · Registration and validation of abuse contact

    Bewertung: Konsistent · The connectivity-dispute objection and the abuse-handling alternative both distinguish registration responsibilities from compelling particular network operations. Accepting contact information while preferring guidance for operational behavior does not contradict the earlier boundary concern.

    Bedingungen: The comparison describes the author's view of the RIR role, not an authoritative definition of that role.

    menos cuando se tratan de soluciones t?cnicas

    no creo que LACNIC deba tener el rol de polic?a de Internet regional.

    Reducing the last-call-for-comments period in LACNIC's Policy Development Process. · Simplification of the PDP

    Bewertung: Konsistent · Opposition to shortening ordinary last call and opposition to broad PDP simplification share a concern for deliberative safeguards and an existing expedited exception. Neither contribution treats faster processing alone as sufficient justification.

    Bedingungen: The comparison does not imply opposition to every procedural improvement.

    para esos casos "urgentes" est? el proceso expeditivo.

    apurar estos procesos o simplificarlos no siempre los vuelve m?s leg?timos

    Simplification of the PDP · Minor revision to the PDP

    Bewertung: Konsistent · Rejecting a broad PDP overhaul is compatible with later supporting a narrower amendment using clearer, version-neutral wording. The later proposal preserves continued discussion and a reset period rather than establishing a general preference for removing deliberative stages.

    Bedingungen: The author had expressly left room for considering useful individual changes in the broader discussion.

    algunas cosas de las que propones son muy interesantes

    De esa forma queda libre lo de las versiones.

    Modify the minimum size of IPv4 assignments to Internet Service Providers · Modify the minimum size of initial allocations to ISPs

    Bewertung: Konsistent · Across both IPv4-size proposals the author requests comparable exact changes and reserves a choice. Tentative agreement with the general direction is compatible with asking the authors to distinguish or combine their proposals.

    Bedingungen: This comparison concerns his decision process; it does not establish a final substantive vote on either draft.

    Consulto por las dos propuestas

    poder definirme por una de las propuestas o por ninguna.

    Proposal to create a Global Internet Registry (GIR) · Registration and validation of abuse contact

    Bewertung: Konsistent · Advocating a global administrative registration mechanism is compatible with rejecting an operational policing role for LACNIC. The GIR argument explicitly describes administrative, political and economic aims, while the abuse-policy objection concerns prescribing and supervising network conduct.

    Bedingungen: Support for changing registry administration is not support for every expansion of enforcement authority. · The comparison does not validate the proposed GIR's feasibility or recognition requirements.

    No son t?cnicas. Son administrativas, pol?ticas y econ?micas

    un rol de fiscalizaci?n para el cual no est? ni mandatado ni tendr?a la capacidad de hacerlo

    1. 07.03.2018 · Alternativvorschlag

      [LACNIC/Politicas] Nueva propuesta LAC-2018-5 / Nova proposta LAC-2018-5 / New proposal LAC-2018-5

      En principio estar?a de acuerdo con el primer punto de tu propuesta, … Si veo muy positivo todo lo que propones pero creo que ser?a algo ideal para generar y poner en un manual de BCPs m?s que en una pol?tica.

      Quellenbelegte Fakten ↗

    Richtliniennachrichten insgesamt: 54

  4. Paola Perez · Identität ungeklärt
    Diskussionsbeiträge1
    Erste Aktivität09.10.2018
    Letzte Aktivität09.10.2018
    Erste ausdrückliche HaltungUnbekannt
    Letzte ausdrückliche HaltungUnbekannt
    Haltungswechsel0
    Konsistenz der PositionDie Datenlage reicht nicht aus, um die Konsistenz zu beurteilen.
    Weitere Richtlinien17
  5. Unbekannt · Öffentliche Quellen gefunden; Identitätsprüfung steht noch aus
    Diskussionsbeiträge1
    Erste Aktivität05.03.2018
    Letzte Aktivität05.03.2018
    Erste ausdrückliche HaltungUnbekannt
    Letzte ausdrückliche HaltungUnbekannt
    Haltungswechsel0
    Konsistenz der PositionKeine ausdrückliche Position angegeben
    Weitere Richtlinien20
  6. Jordi Palet Martinez · Identität ungeklärt
    Diskussionsbeiträge0
    Erste AktivitätUnbekannt
    Letzte AktivitätUnbekannt
    Erste ausdrückliche HaltungUnbekannt
    Letzte ausdrückliche HaltungUnbekannt
    Haltungswechsel0
    Konsistenz der PositionKeine ausdrückliche Position angegeben
    Weitere Richtlinien0

Quellen und Abdeckung

Offizielle Richtlinienquellen

Öffentliche Diskussionsarchive

  • lacnic-politicas
    Früheste Erfassung
    21.10.1999
    Letzte Erfassung
    12.10.2026
    Letzte Aktualisierung
    13.08.2026
    Abdeckung
    Die Quellenabdeckung ist unvollständig.
    Wird geladen
    5.603
    Bekannte Lücken
    26
  • www.lacnic.net
  • lacnic-anuncios
    Früheste Erfassung
    13.08.2026
    Letzte Erfassung
    07.10.2026
    Letzte Aktualisierung
    13.10.2026
    Abdeckung
    Die Quellenabdeckung ist unvollständig.
    Wird geladen
    2.155
    Bekannte Lücken
    0
  • lacnic-ietf-lac
    Früheste Erfassung
    30.05.2013
    Letzte Erfassung
    30.12.2015
    Letzte Aktualisierung
    13.10.2026
    Abdeckung
    Die Quellenabdeckung ist unvollständig.
    Wird geladen
    1.133
    Bekannte Lücken
    0
  • lacnic-infofrida
    Früheste Erfassung
    14.08.2006
    Letzte Erfassung
    13.09.2011
    Letzte Aktualisierung
    13.10.2026
    Abdeckung
    Die Quellenabdeckung ist unvollständig.
    Wird geladen
    292
    Bekannte Lücken
    0
  • lacnic-iot
    Früheste Erfassung
    06.10.2015
    Letzte Erfassung
    11.07.2017
    Letzte Aktualisierung
    13.10.2026
    Abdeckung
    Die Quellenabdeckung ist unvollständig.
    Wird geladen
    373
    Bekannte Lücken
    0
  • lacnic-lacnog
    Früheste Erfassung
    01.08.2026
    Letzte Erfassung
    09.10.2026
    Letzte Aktualisierung
    11.10.2026
    Abdeckung
    Die Quellenabdeckung ist unvollständig.
    Wird geladen
    6.486
    Bekannte Lücken
    3
  • lacnic-lactf
    Früheste Erfassung
    13.04.2004
    Letzte Erfassung
    29.12.2006
    Letzte Aktualisierung
    13.10.2026
    Abdeckung
    Die Quellenabdeckung ist unvollständig.
    Wird geladen
    2.267
    Bekannte Lücken
    0
  • lacnic-seguridad
    Früheste Erfassung
    26.01.2006
    Letzte Erfassung
    28.12.2007
    Letzte Aktualisierung
    13.10.2026
    Abdeckung
    Die Quellenabdeckung ist unvollständig.
    Wird geladen
    1.356
    Bekannte Lücken
    0

Abdeckung

Teilweise
Früheste Erfassung: 21.10.1999
Letzte Erfassung: 13.10.2026

Aktualität

Aktualität: Veraltet · Letzte Aktualisierung: · Die letzte Aktualisierung ist fehlgeschlagen. Das letzte erfolgreiche Ergebnis wird angezeigt.

Bekannte Lücken

  • politicas.lacnic.net: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.
  • www.lacnic.net: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.
  • lacnic-politicas: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.
  • www.lacnic.net: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.
  • lacnic-anuncios: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.
  • lacnic-ietf-lac: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.
  • lacnic-infofrida: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.
  • lacnic-iot: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.
  • lacnic-lacnog: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.
  • lacnic-lactf: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.
  • lacnic-seguridad: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.