LACNIC · Мониторинг RIR
Registration and validation of abuse contact
Здесь можно проследить судьбу каждого предложения: что изменилось, почему это было важно, кто и за что выступал, как менялись позиции, какое решение было принято и где в доказательной базе всё ещё остаются пробелы.
Факты из источников
- Идентификатор предложения
- LAC-2018-5
- RIR
- LACNIC
- Официальный статус
- Implemented
- Статус в системе
- Принято
- Внесено
- 4 мар. 2018 г.
- Последнее обновление источника
- 9 окт. 2026 г.
- Полнота данных
- Частично
Кто на самом деле определял ход дискуссии?
Как менялось предложение
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.
Факты из источников −
Проверенные данные недоступны.Факты из источников +
Проверенные данные недоступны.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.
Факты из источников −
As a result, some LIRs may not have this contact information registered for their resources. In fact, there are even cases of LIRs that use a non-existent mailbox or one that is not actively monitored. In practice, this contact becomes ineffective to report abuses and generally gives rise to security issues anФакты из источников ↗
Факты из источников +
As a result, some organizations that have received resources from LACNIC may not have this contact information registered for their resources. There are even cases of LIRs/ISPs, end users or others that use a non-existent mailbox or one that is not actively monitored. In practice, this contact becomes ineffective to report abuses and generally gives rise to sФакты из источников ↗
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.
Факты из источников −
Проверенные данные недоступны.Факты из источников +
Проверенные данные недоступны.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.
Факты из источников −
Проверенные данные недоступны.Факты из источников +
Проверенные данные недоступны.Policy text · Astra identified a substantive wording change in this retained policy section.
Факты из источников −
About the “abuse-mailbox” Email messages sent to the “abuse-mailbox” must require manual intervention by the recipient at some time and may not be filtered, as in certain cases this might prevent the reception of abuse reports.Факты из источников ↗
Факты из источников +
About the “abuse-mailbox” The “abuse-mailbox”: • Must require intervention by the recipient.Факты из источников ↗
Policy text · Astra identified a substantive wording change in this retained policy section.
Факты из источников −
About the “abuse-mailbox” Email messages sent to the “abuse-mailbox” must require manual intervention by the recipient at some time and may not be filtered, as in certain cases this might prevent the reception of abuse reports.Факты из источников ↗
Policy text · Astra identified a substantive wording change in this retained policy section.
Факты из источников −
However, it may not require the use of a form, as this would mean that each entity that needs to report cases of abuse (a task that is typically automated) would be forced to develop a specific interface for each resource recipient to which it must submit its reports.Факты из источников ↗
Policy text · Astra identified a substantive wording change in this retained policy section.
Факты из источников −
However, it may not require the use of a form, as this would mean that each entity that needs to report cases of abuse (a task that is typically automated) would be forced to develop a specific interface for each resource recipient to which it must submit its reports.Факты из источников ↗
Policy text · Astra identified a substantive wording change in this retained policy section.
Факты из источников −
This allows automatic reporting, for example, via fail2ban, SpamCop or other reporting services, keeping costs at a minimum for both parties involved.Факты из источников ↗
Policy text · Astra identified a substantive wording change in this retained policy section.
Факты из источников −
Purpose of “abuse-c”/ “abuse-mailbox” validation The procedure is to be developed by LACNIC and must meet the following objectives: 1) It must guarantee its functionality and allow the helpdesks that deal with the abuse reports to verify that the validation actually originated from LACNIC and not from other sources (involving security risks, avoiding, for example, a single “direct” URL for validation).Факты из источников ↗
Факты из источников +
Purpose of “abuse-c”/ “abuse-mailbox” validation The procedure, to be developed by LACNIC, must meet the following objectives: 1) A simple process that guarantees its functionality and the fulfillment of its purpose.Факты из источников ↗
Policy text · Astra identified a substantive wording change in this retained policy section.
Факты из источников +
2) It should confirm that the person performing the validation: • understands the procedure and the LACNIC policies in force; • regularly monitors the “abuse-mailbox”; • takes measures in connection thereto; • responds to the abuse report.Факты из источников ↗
Policy text · Astra identified a substantive wording change in this retained policy section.
Факты из источников +
3) Include an “Initial” validation period of fifteen (15) days.Факты из источников ↗
Policy text · Astra identified a substantive wording change in this retained policy section.
Факты из источников −
5) If this validation fails, “escalate” to the original recipient of the resources (LIR, end user, etc.) for an additional period of fifteen (15) days.Факты из источников ↗
Факты из источников +
4) If this validation fails, “escalate”, by any possible means, to the rest of the available contacts within an additional period of fifteen (15) days.Факты из источников ↗
Policy text · Astra identified a substantive wording change in this retained policy section.
Факты из источников −
5) If this validation fails, “escalate” to the original recipient of the resources (LIR, end user, etc.) for an additional period of fifteen (15) days. The validation periods may be modified at LACNIC's discretion, informing the community of the reasons for doing so.Факты из источников ↗
Факты из источников +
4) If this validation fails, “escalate”, by any possible means, to the rest of the available contacts within an additional period of fifteen (15) days.Факты из источников ↗
Policy text · Astra identified a substantive wording change in this retained policy section.
Факты из источников −
The validation frequency may be modified at LACNIC's discretion, informing the community of the reasons for doing so.Факты из источников ↗
Факты из источников +
Validation of “abuse-c”/“abuse-mailbox” LACNIC will periodically validate compliance with the policy, at least twice a year and whenever “abuse-c” attributes are created or modified. Failure of an organization to comply with this section occurs if it has not been validated during the “initial” or the “additional” validation periods.Факты из источников ↗
Policy text · Astra identified a substantive wording change in this retained policy section.
Факты из источников −
This will result in the blocking of MiLACNIC and equivalent measures in the systems of the NIRs for all the resources associated with the organization.Факты из источников ↗
Факты из источников +
Failure of an organization to comply with this section occurs if it has not been validated during the “initial” or the “additional” validation periods. 12.5.Факты из источников ↗
Хронология обсуждения
Публичное обсуждение
[LACNIC/Politicas] Nueva propuesta LAC-2018-5 / Nova proposta LAC-2018-5 / New proposal LAC-2018-5
9 Сообщения в обсуждении · 4 Участники
Факты из источников ↗Публичное обсуждение
[LACNIC/Politicas] LAC-2018-5 Registro y Validación del "abuse-c" y "abuse-mailbox"
9 Сообщения в обсуждении · 2 Участники
Факты из источников ↗Публичное обсуждение
[LACNIC/Politicas] opiniones de la propuesta LAC-2018-5 (abuse-c)
2 Сообщения в обсуждении · 2 Участники
Факты из источников ↗
Участники
- Сообщения в обсуждении10Первое участие5 мар. 2018 г.Последнее участие26 сент. 2018 г.Первая заявленная позицияПоддержкаПоследняя заявленная позицияПоддержка с изменениямиИзменения позиций3Согласованность позицииСмешаннаяДругие предложения39Актуальность: Устарело · Последнее обновление: · Последнее обновление не удалось. Показан результат последнего успешного обновления.
Последняя попытка исследования: 17 сент. 2026 г.
Личность подтверждена: 11 окт. 2026 г.
The IPv6 Company · Исторические сведения Name: Jordi Palet Martínez Email: [email protected] Organization: The IPv6 Company
politicas.lacnic.netПроверенные публичные профили
- Сообщения в обсуждении
- 10
- Первое участие
- 5 мар. 2018 г.
- Последнее участие
- 26 сент. 2018 г.
- Первая заявленная позиция
- Поддержка
- Последняя заявленная позиция
- Поддержка с изменениями
- Изменения позиций
- 3
- Согласованность позиции
- Смешанная
- Другие предложения
- 39
Первая заявленная позиция: Поддержка → Последняя заявленная позиция: Поддержка с изменениями · Изменения позиций: 3
Согласованность позиции: Смешанная
The main policy objectives remain coherent: usable address plans without avoidable renumbering, meaningful participation in consensus, and functional abuse contacts. The record also contains real, explained changes in mechanisms, including withdrawal of the separate non-ISP category in favor of a common allocation rule. One university example contains unresolved end-user classification language, so the record should not be described as uniformly consistent in every detail. Procedural replies and single contributions cannot establish a lasting substantive position, and quoted disagreements are not the author's own votes.
Modify direct IPv6 address assignments to end users
Оценка: Недостаточно доказательств для оценки согласованности · The author accepts clearer old-and-new text and a stronger rationale while deliberately separating the allocation-size question from the two changes being proposed. This one reply shows willingness to refine the proposal, but supplies no sequence from which to assess a reversal or durable consistency.
Условия: Support for this limited change does not endorse a separate size change or every later draft.
Mi idea en esta propuesta es SOLO tocar los dos puntos indicados.
Modify the size of initial IPv6 allocations
Оценка: Согласованная · From March 2016 through May 2017 the author seeks an aggregated, realistic IPv6 plan for government and other nontraditional networks. His preferred mechanism evolves: he first argues for differentiated non-ISP treatment, offers an alternative at the community's request, and finally abandons this proposal because the common mechanism serves the same objective with less complexity. The withdrawal is explained rather than an unexplained rejection of the objective.
Условия: The initial willingness to withdraw depended on staff confirming that the existing rule already permitted the case; it was not an actual March withdrawal. · The later report of community consensus is not independent evidence of final ratification or implementation. · Claims about government allocations and regional experience are the author's examples and assertions.
Y creo que no es conveniente tener tantas pol?ticas como ?casos?.
Mi propuesta pretende aclarar esta situacion, con una categoria nueva diferente de ISP, aunque es muy similar a un ISP.
que evitamos con un solo mecanismo para justificar los recursos
Modify the size of initial IPv6 allocations
Оценка: Согласованная · The November correction changes the stated horizon from the organization's life expectancy to the allocation's expected longevity. The author acknowledges an overlooked drafting error and explains why the latter better bounds the addressing plan. This is a real correction with an explanation, not evidence that every earlier version already said the same thing.
Условия: The author's account of his original intention cannot erase the earlier organization-longevity wording.
El plan de direccionamiento ha de tener en cuenta la longevidad prevista de la organizaci?n.
nunca fue la intenci?n que la longevidad fuera de la organizaci?n, sino de la distribuci?n inicial
Modify the size of initial IPv6 allocations
Оценка: Смешанная · The August university example calls a university with several providers not an end user, yet immediately says each university could obtain its own /32 under the end-user policy. Elsewhere the distinction turns on assigning resources to separate organizations. The example therefore contains an unresolved classification ambiguity; it does not establish that multihoming alone changes an organization into an LIR.
Условия: This concerns the precision of the example, not a demonstrated reversal of the objective of aggregated national-network addressing. · No supplied follow-up expressly reconciles those two descriptions of the university.
necesita direccionamiento propio y obviamente NO es un usuario final.
Si aplican a la pol?tica de usuario final, podr?an obtener, cada una de ellas su propio /32.
asignar direcciones? a terceros
Modify the size of initial IPv6 allocations
Оценка: Согласованная · The author presents the common ISP/LIR rule as an explicit alternative, explains its longer-horizon planning benefit, and later favors it over separate categories because it achieves the shared aim more simply. Offering two mutually exclusive community choices is not support for adopting conflicting rules simultaneously.
Условия: This entails a change from preserving the commercial-ISP time limit to accepting a common mechanism; the design preference did evolve. · The source describes community consensus, not proof of all subsequent implementation steps.
Mi idea es ofrecer AMBAS alternativas para que la comunidad decida.
Por supuesto que la idea no es que se aprueben las dos, sino una u otra.
v?lido para ambos casos.
Rectifying the size of initial allocations
Оценка: Согласованная · The sequence consistently supports a one-time correction of an inadequate initial IPv6 allocation to avoid renumbering. It preserves the ordinary subsequent-allocation procedure, acknowledges that contiguous space may not remain available, and leaves end-user inclusion open if relevant cases are presented. Encouraging discussion is separate from this substantive advocacy.
Условия: The residential /64 remark is a reductio, not a recommendation to reduce customer assignments. · The /33 example and worldwide adoption fraction are not independently established technical or statistical evidence. · Future contiguous allocations are not guaranteed.
No se trata de evitar que haya ?nuevas asignaciones? en el futuro, pero si dar la oportunidad de ?corregir? la primera por una sola vez.
ser?a muy sencillo actualizar la propuesta para incluir ese caso.
ahora pague por ello el cliente.
Reducing the last-call-for-comments period in LACNIC's Policy Development Process.
Оценка: Согласованная · The author repeats a preference for 30 calendar days, finds discretionary chair-adjusted intervals too subjective, and then proposes a broader list-based consensus process. The broader process discussion does not endorse the specific 20-day option or retract the stated 30-day preference within this exchange.
Условия: The comparative timing list is supplied by another participant. · The claimed benefits of avoiding meeting delays are advocacy, not measured outcomes.
creo que 30 d?as naturales ser?a suficiente y siempre m?s f?cil de contar.
Me refuerza en mi punto de vista de 30 d?as.
la decisi?n del consenso (igual que en IETF) se toma en la lista, no en el meeting
MODIFYING INITIAL IPv6 ALLOCATIONS TO END USERS
Оценка: Недостаточно доказательств для оценки согласованности · The single contribution welcomes correction of an end user's initial allocation while proposing clearer language about contiguous expansion, unavailable adjacent space, and the choice to renumber earlier. It establishes a conditional design preference, not longitudinal consistency or endorsement of every provision.
Условия: The suggested wording is a proposal, not evidence that it was incorporated into an adopted text.
Me parece buena idea la propuesta, sin embargo, tengo una duda.
que si lo desea renumere ahora en lugar de luego
Modifying "Subsequent Allocation" for IPv6
Оценка: Недостаточно доказательств для оценки согласованности · The author advocates aligning subsequent IPv6 allocation criteria with the revised initial-allocation criteria so earlier recipients are not disadvantaged. Only one contribution is supplied, so persistence or reversal within this proposal cannot be assessed.
Условия: The quoted announcement distinguishes consensus from pending board ratification; the author's shorthand about approval does not prove implementation.
Mi propuesta simplemente incorpora *el mismo* texto que se aprob? para las distribuciones iniciales en las distribuciones subsiguientes
Simplifying the PDP (Mailing List + Forum Option)
Оценка: Недостаточно доказательств для оценки согласованности · This contribution supports a substantive rather than numerical understanding of consensus and associates that objective with the author's PDP proposal. It does not reproduce all the process provisions or provide a time series of positions on this proposal.
Условия: The definition quoted from the PDP is attributed material; the author's explicit endorsement is the evidence of his position. · No stance on an unrelated later proposal follows from the discussion.
para evitar que se entienda como "mas votos" a favor o "en contra", cuando en realidad quiere decir que no haya objeciones que no sean respondidas.
Оценка: Недостаточно доказательств для оценки согласованности · The author supports removing the IPv4 end-user multihoming requirement and explains that this component was split from a combined proposal after feedback. This single statement cannot show whether the position persisted or changed later.
Условия: The alignment with IPv6 is his stated rationale. · Neither the split nor the request for feedback establishes consensus on this component.
La LAC-2018-11, simplemente elimina el requisito de multihoming para IPv4 para ser usuario final
Оценка: Недостаточно доказательств для оценки согласованности · The author regards an explicit restart clause as redundant but accepts wording that restarts the eight-week discussion period in every case. Calling it a clarification while accepting it is not opposition, but one reply cannot establish consistency across subsequent revisions.
Условия: A proposed revision or offered new version is not proof of adoption. · The rule being discussed is a failed-consensus restart, not the length of last call.
Luego, bajo mi punto de vista, es *redundante* poner que se reinician los plazos.
En cualquier caso, se reiniciar?a el plazo de debate de 8 semanas.
Review and correction of errors in the IPv6 policy
Оценка: Недостаточно доказательств для оценки согласованности · The author supplies a comparison link and explains its colors to facilitate review. The message contains neither the comparison itself nor a substantive sequence of positions, so it cannot support a finding about consistency of the proposed IPv6 corrections.
Условия: Authorship and assistance with presentation are not endorsement of every unseen change.
La columna de la izquierda es el texto de la pol?tica actual (color rojo), y la de la derecha (color verde), como quedar?a con los cambios que propongo.
Registration and validation of abuse contact
Оценка: Согласованная · Across the discussion the author continues to seek registered, usable abuse contacts and periodic validation. He accepts clarification of validation triggers, discusses longer intervals and grace periods, and considers splitting disputed components. By September he favors stating the validation objective while leaving the operational procedure to LACNIC. Those are substantive refinements around a persistent objective.
Условия: The final interval and precise consequences of failed validation are not settled by these replies. · General agreement with a suggested revision does not adopt every sanction in the quoted reply. · Predictions of court victories and civil liability remain the author's historical claims, not verified legal conclusions.
Totalmente de acuerdo en lo que propones del punto 12.4
Que se verifican autom?ticamente cada cierto tiempo, con un proceso automatizado desde LACNIC
es mejor que el procedimiento lo defina LACNIC.
Registration and validation of abuse contact
Оценка: Согласованная · The objection to automated abuse contacts concerns systems that ignore email and force victims into incompatible forms. The author expressly supports automatic initial reports and automatic or semi-automatic processing that responds. Read together, the broad phrase against automation is qualified by this functional distinction, not a ban on all automation.
Условия: Claims about reporting volume, regional response rates, and negligible validation cost are not measured evidence in this corpus. · The proposal distinguishes common reporting access from the ISP's own contractual treatment of a customer.
eso implica que no sean automatizados
Lo razonable es que el primer contacto de abuso, por parte de la v?ctima, pueda ser procesado de forma autom?tica.
procesar ese email de forma autom?tica o semi-autom?tica y RESPONDEN.
Оценка: Согласованная · The author consistently prioritizes participation in consensus by the whole community. His initial list-only design would remove the expedited track, but he subsequently offers to retain forum presentation and the expedited process, or combine list and forum, if remote participants have equal standing. This is a conditional compromise, not abandonment of the objective.
Условия: The offered changes are not evidence that a revised text was actually published or approved. · Replacing the word discriminatory with exclusionary softens the description without removing the stated objection. · The illustrative participation percentages and accounts of prior forums are not independently verified measurements.
El objetivo es que el consenso se alcance en la lista, y no en el foro
y entonces mantener el proceso expeditivo
hacer que el consenso sea de lista+foro en lugar de solo lista o solo foro
Clarifications of Sub-Assignments
Оценка: Недостаточно доказательств для оценки согласованности · The author seeks an exception for temporary addressing of guests, employees or students while retaining the distinction from permanent connectivity service. He explicitly asks whether to cap that exception at a /64 or leave size open. Presenting these alternatives does not choose either one, and there is no later position here to compare.
Условия: Other regions are contextual references, not evidence that a particular LACNIC alternative was adopted.
La diferencia es limitar esto a un m?ximo de un /64, o dejarlo abierto.
Update to the Policy on IPv4 Assignments to End Users
Оценка: Согласованная · The May contribution defends avoiding disruptive end-user renumbering; the August explanation preserves that objective while describing the simplified transfer component after the multihoming question was separated. The split changes the packaging, not the stated purpose of enabling the existing user to keep its addressing.
Условия: The quoted participant's uncertainty is not the author's own neutral position. · An ISP proposal's reported consensus does not establish consensus for the end-user proposal.
un end-user puede tener requisitos que le impiden renumerar
un ISP "ceda" con un sistema simplificado de transferencias, el direccionamiento al usuario final que lo usa.
Update to the Policy on Initial IPv4 Allocations to ISPs
Оценка: Согласованная · The author repeatedly defends voluntary transfer of the same addressing to avoid renumbering and argues that the routing and cost consequences are comparable to ordinary transfers. The later offer to replace ceder with transferir makes his intended mechanism explicit rather than reversing it.
Условия: His routing-equivalence argument is contested advocacy, not an independently measured network outcome. · The half-joking routing-table remark is not a policy commitment; the rhetorical question about abolishing transfers is not a repeal proposal. · The participating organizations must agree and an authorized representative must approve; no unilateral right is asserted.
tiene que haber acuerdo entre ambas partes.
pero resuelve el problema de evitar la renumeraci?n.
poner transferir en lugar de ceder.
Оценка: Недостаточно доказательств для оценки согласованности · The author acknowledges missing a response deadline and agrees that further versions may be needed. This procedural exchange does not establish support for every chair-election provision, a substantive reversal, or a declaration of consensus.
Условия: A preference for immediate replies is not a position on each election rule. · A shared email subject does not by itself attribute a stance on another proposal.
Mi respuesta no negaba una versi?n 2 o 3 o las que hagan falta
Update to “Resource Recovery and Return” and consistency with the rest of the Manual
Оценка: Недостаточно доказательств для оценки согласованности · The author favors a side-by-side comparison tool, downloadable text and PDF, and room for exceptional formats. This is agreement about how to discuss a proposal, not evidence of support or opposition to its resource-recovery provisions or a later policy outcome.
Условия: No substantive recovery-rule consistency judgment can be inferred from agreement with the tooling suggestion.
Yo desde luego votar?a por un sistema que muestre ?lado a lado? en la web
Modify the size of initial IPv6 allocations · Modify the size of initial IPv6 allocations
Оценка: Согласованная · The separate-category and common-rule proposals are competing mechanisms for the same planning objective. The author expressly presents them as alternatives, then explains abandoning the more complex category approach after the common rule received community support. The record documents a reasoned change in preferred mechanism rather than simultaneous contradictory commitments.
Условия: A consistent objective does not mean identical eligibility criteria across the two designs. · The final implementation status is outside what these statements establish.
Mi idea es ofrecer AMBAS alternativas para que la comunidad decida.
esta pol?tica se abandona, porque el objetivo que persegu?a se cumple igualmente con la LAC-2016-7
Rectifying the size of initial allocations · MODIFYING INITIAL IPv6 ALLOCATIONS TO END USERS
Оценка: Согласованная · The initial-correction discussion explicitly leaves end-user inclusion open if cases are raised. The later welcome for an end-user correction mechanism is compatible with that openness and with the repeated concern about avoidable renumbering; it is not a reversal from categorical exclusion of end users.
Условия: The two proposals address different recipient classes. · The emails do not independently establish the frequency of end-user cases.
ser?a muy sencillo actualizar la propuesta para incluir ese caso.
Me parece buena idea la propuesta, sin embargo, tengo una duda.
Modify the size of initial IPv6 allocations · Modifying "Subsequent Allocation" for IPv6
Оценка: Согласованная · Support for a common initial-allocation rule is followed by advocacy of matching subsequent-allocation criteria, expressly to avoid disadvantaging earlier recipients. These are complementary positions on the same planning issue.
Условия: The comparison concerns the author's rationale, not proof of ratification or deployment.
v?lido para ambos casos.
dejar?a en desventaja a quien haya obtenido una distribuci?n inicial *antes* de la reciente aprobaci?n del cambio.
Rectifying the size of initial allocations · Modifying "Subsequent Allocation" for IPv6
Оценка: Согласованная · Saying the initial-correction proposal does not change subsequent allocations is a statement about that proposal's scope. Advocating a separate subsequent-allocation revision later does not contradict it or promise that the rules would never change.
Условия: Distinct proposals and dates must remain separate.
no cambiamos, con esta propuesta, subsiguientes asignaciones
el texto de subsiguientes distribuciones, al probarse este cambio, queda desfasado.
Reducing the last-call-for-comments period in LACNIC's Policy Development Process. · Simplification of the PDP
Оценка: Согласованная · The 2017 preference for list-based consensus carries into the later PDP redesign and its equal-participation rationale. Details do change: the earlier preference is 30 calendar days, while the later outline gives a four-week last call. The later emphasis on inclusion rather than speed narrows the stated priority without negating the earlier observation that meetings can delay a decision.
Условия: Do not describe the two timing specifications as identical. · The asserted benefits and participation problems are the author's reasoning, not measured causal findings.
creo que 30 d?as naturales ser?a suficiente y siempre m?s f?cil de contar.
ello permite participar a quienes no necesariamente viajan
un "last call" de 4 semanas
El objetivo principal es facilitar la participaci?n de *toda la comunidad* en igualdad de condiciones
Simplifying the PDP (Mailing List + Forum Option) · Simplification of the PDP
Оценка: Согласованная · The later explanation that consensus is not a count of votes matches the earlier PDP reform argument for evaluating substantive objections and including list participants. No reversal of that conception of consensus is shown.
Условия: Endorsement of this principle does not establish agreement with every procedural provision.
para evitar que se entienda como "mas votos" a favor o "en contra"
definir "consenso" (que no es un cuenteo de votos).
Update to the Policy on IPv4 Assignments to End Users · Update to the Policy on Initial IPv4 Allocations to ISPs
Оценка: Согласованная · Both the ISP and end-user discussions pursue retention of existing addressing through an agreed transfer to avoid renumbering. The author separates the recipient classes while using the same operational rationale; support in one discussion is not evidence of consensus in the other.
Условия: The effect on routing remains a debated claim.
un end-user puede tener requisitos que le impiden renumerar
pero resuelve el problema de evitar la renumeraci?n.
Remove the reference to an applicant's multihomed status from the policy on IPv4 assignments to end users · Update to the Policy on IPv4 Assignments to End Users
Оценка: Согласованная · The author explains dividing the combined end-user proposal into transfer and multihoming components after community feedback. Supporting both as separate proposals is coherent; it does not imply either had been adopted.
Условия: This is an explicitly described change in proposal structure, not an inferred change from a shared subject line.
afrontara cada problema con una propuesta especifica y as? lo hice ese mismo d?a.
La LAC-2018-11, simplemente elimina el requisito de multihoming para IPv4 para ser usuario final
Modify the size of initial IPv6 allocations · Clarifications of Sub-Assignments
Оценка: Согласованная · The earlier end-user/LIR distinction concerns assignment to separate institutions in a national network. The later sub-assignment clarification explicitly distinguishes temporary guest or employee connectivity from permanent service. These scopes can coexist; the later temporary-use exception does not establish that permanent distribution to other organizations was reclassified as end-user use.
Условия: The imprecise university wording in the earlier example remains an uncertainty, not a basis for a categorical identity rule. · The later message leaves the /64 size alternative undecided.
El gobierno aplicar?a por end user SI la asignaci?n de direcciones fuera SOLO a entidades de la MISMA entidad
Simplemente se considera que debe ser "temporal" y por tanto no un servicio de "banda ancha".
Review and correction of errors in the IPv6 policy · Update to “Resource Recovery and Return” and consistency with the rest of the Manual
Оценка: Согласованная · Providing a policy diff and later favoring side-by-side comparisons show a compatible preference for making textual changes easier to inspect. That narrow presentation preference supplies no evidence of consistency on the substantive IPv6 or resource-recovery provisions.
Условия: Only the presentation practice is compared here.
La columna de la izquierda es el texto de la pol?tica actual (color rojo)
Yo desde luego votar?a por un sistema que muestre ?lado a lado? en la web
- 5 мар. 2018 г. · Поддержка
[LACNIC/Politicas] Nueva propuesta LAC-2018-5 / Nova proposta LAC-2018-5 / New proposal LAC-2018-5
Lo que no es l?gico, nunca, y en ello incido en esta propuesta, es que el que hace el da?o (o sus clientes), no este "obligado" a resolverlo (y por tanto a responder al caso de abuso), y en cambio, todos los costes asociados a ese abuso, lo tenga que pagar el ISP que es v?ctima del abuso.
Факты из источников ↗ - 5 мар. 2018 г. · Поддержка
[LACNIC/Politicas] Nueva propuesta LAC-2018-5 / Nova proposta LAC-2018-5 / New proposal LAC-2018-5
De todos modos, creo que la propuesta no entra en como el ISP debe tratar los abusos (si quiere rescindir el contrato, advertir al cliente un n?mero de veces, etc.), sino en un procedimiento com?n para poder comunicar los abusos sin coste adicional para la "victima".
Факты из источников ↗ - 7 мар. 2018 г. · Поддержка
[LACNIC/Politicas] Nueva propuesta LAC-2018-5 / Nova proposta LAC-2018-5 / New proposal LAC-2018-5
Una pol?tica, aunque no se "diga" en su texto, es de obligado cumplimiento (en todos los RIR), y el RIR puede exigir su cumplimiento o incluso retroceder dichos recursos. … [Jordi] Obviamente es una propuesta, y seguro que admite mejoras y cambios, veamos punto a punto con detalle y busquemos el consenso, para eso es el PDP ;-)
Факты из источников ↗ - 8 мар. 2018 г. · Поддержка с изменениями
[LACNIC/Politicas] Nueva propuesta LAC-2018-5 / Nova proposta LAC-2018-5 / New proposal LAC-2018-5
Totalmente de acuerdo en lo que propones del punto 12.4, creo que es obvio que se debe verificar en cualquiera de los 3 casos. … Si te parece poco, no tengo problema en proponer un punto adicional, de forma que la primera verificaci?n, pasados los 3 meses del plazo de implementaci?n, sea de 6 meses m?s o algo as?.
Факты из источников ↗ - 13 авг. 2018 г. · Поддержка
[LACNIC/Politicas] LAC-2018-5 Registro y Validación del "abuse-c" y "abuse-mailbox"
1) Garantizar que existen contactos de abuso en cada objeto de whois … 2) Que esos contactos funcionan y no son robots que no llevan a "nada" … 3) Que se verifican autom?ticamente cada cierto tiempo, con un proceso automatizado desde LACNIC
Факты из источников ↗ - 13 авг. 2018 г. · Поддержка
[LACNIC/Politicas] LAC-2018-5 Registro y Validación del "abuse-c" y "abuse-mailbox"
- pedir que se registren contactos de abuso … - pedir que se validen peri?dicamente … 3) Otra que indique como LACNIC los valida (aunque en la propuesta actual ese texto es informativo, y LACNIC lo har? como mejor crea conveniente)
Факты из источников ↗ - 13 авг. 2018 г. · Поддержка
[LACNIC/Politicas] LAC-2018-5 Registro y Validación del "abuse-c" y "abuse-mailbox"
Lo razonable es que el primer contacto de abuso, por parte de la v?ctima, pueda ser procesado de forma autom?tica. … Si hay miles de formularios, aunque solo sean cientos, no se pueden automatizar, y una ISP peque?o/mediano o un usuario final que tiene menos recursos, no puede procesarlo a mano, y le cuesta dinero, que obviamente es responsabilidad de la red del atacante, no de la v?ctima.
Факты из источников ↗ - 14 авг. 2018 г. · Поддержка
[LACNIC/Politicas] LAC-2018-5 Registro y Validación del "abuse-c" y "abuse-mailbox"
* entonces una misma receta de justificaci?n de necesidad de direcciones (es un ejemplo), tampoco es igual para todos. Si no establecemos "recetas" (pol?ticas) comunes, no hay gobernanza en Internet, ni necesidad de RIRs (bastar?a con un registro central), etc. … * A mi se me ocurre una alternativa: Si estandarizamos en IETF un mecanismo para reportar abusos (incluso id?ntico al que yo propongo), luego podemos hacer una pol?tica que obligue a su cumplimiento. F?jate que el resultado es el mismo, solo que a?adimos un proceso intermedio, de m?nimo 1 a?o. Creo que es injustificado e innecesario.
Факты из источников ↗ - 15 авг. 2018 г. · Поддержка
[LACNIC/Politicas] LAC-2018-5 Registro y Validación del "abuse-c" y "abuse-mailbox"
Si la comunidad decide aplicar una pol?tica para usar un procedimiento formulario para tal o cual cosa (sea abuso u otra cosa), la comunidad puede hacerlo.
Факты из источников ↗ - 26 сент. 2018 г. · Поддержка с изменениями
[LACNIC/Politicas] opiniones de la propuesta LAC-2018-5 (abuse-c)
Creo que entiendo tu idea y coincide con lo que hemos hablado ayer, lo ?nico en lo que no estoy de acuerdo es en retirar el punto 12.3, porque si no indicamos cual es el objetivo de la validaci?n, entonces hay que indicar el procedimiento, y es mejor que el procedimiento lo defina LACNIC.
Факты из источников ↗
Хронология позиций по каждому предложению:LAC-2016-4 · Поддержка с изменениями · Недостаточно доказательств для оценки согласованностиLAC-2016-5 · Поддержка · СогласованнаяLAC-2016-7 · Поддержка · СогласованнаяLAC-2017-1 · Поддержка · СогласованнаяLAC-2017-7 · Предложить альтернативу · СогласованнаяLAC-2017-8 · Предложить альтернативу · Недостаточно доказательств для оценки согласованностиLAC-2017-9 · Поддержка · Недостаточно доказательств для оценки согласованностиLAC-2018-10 · Поддержка · Недостаточно доказательств для оценки согласованностиLAC-2018-11 · Поддержка · Недостаточно доказательств для оценки согласованностиLAC-2018-12 · Поддержка с изменениями · Недостаточно доказательств для оценки согласованностиLAC-2018-13 · Неизвестно · Явная позиция не заявленаLAC-2018-14 · Неизвестно · Явная позиция не заявленаLAC-2018-4 · Неизвестно · Недостаточно доказательств для оценки согласованностиLAC-2018-5 · Поддержка с изменениями · СогласованнаяLAC-2018-6 · Поддержка с изменениями · СогласованнаяLAC-2018-7 · Поддержка · Недостаточно доказательств для оценки согласованностиLAC-2018-8 · Поддержка · СогласованнаяLAC-2018-9 · Поддержка с изменениями · СогласованнаяLAC-2019-2 · Неизвестно · Явная позиция не заявленаLAC-2019-3 · Неизвестно · Явная позиция не заявленаLAC-2019-4 · Неизвестно · Явная позиция не заявленаLAC-2019-5 · Неизвестно · Явная позиция не заявленаLAC-2019-6 · Неизвестно · Явная позиция не заявленаLAC-2019-7 · Неизвестно · Недостаточно доказательств для оценки согласованностиLAC-2019-9 · Неизвестно · Недостаточно доказательств для оценки согласованностиLAC-2020-3 · Неизвестно · Явная позиция не заявленаLAC-2020-4 · Неизвестно · Явная позиция не заявленаLAC-2020-6 · Неизвестно · Явная позиция не заявленаLAC-2021-2 · Неизвестно · Явная позиция не заявленаLAC-2021-3 · Неизвестно · Явная позиция не заявленаLAC-2021-4 · Неизвестно · Явная позиция не заявленаLAC-2021-5 · Неизвестно · Явная позиция не заявленаLAC-2022-1 · Неизвестно · Явная позиция не заявленаLAC-2022-2 · Неизвестно · Явная позиция не заявленаLAC-2022-4 · Неизвестно · Явная позиция не заявленаLAC-2023-1 · Неизвестно · Явная позиция не заявленаLAC-2023-7 · Неизвестно · Явная позиция не заявленаLAC-2024-1 · Неизвестно · Явная позиция не заявленаLAC-2025-1 · Неизвестно · Явная позиция не заявленаLAC-2025-4 · Неизвестно · Явная позиция не заявленаВсего сообщений в обсуждениях: 141
- Сообщения в обсуждении8Первое участие5 мар. 2018 г.Последнее участие26 сент. 2018 г.Первая заявленная позицияПротивПоследняя заявленная позицияПоддержка с изменениямиИзменения позиций1Согласованность позицииСмешаннаяДругие предложения25
- Сообщения в обсуждении1Первое участие7 мар. 2018 г.Последнее участие7 мар. 2018 г.Первая заявленная позицияПредложить альтернативуПоследняя заявленная позицияПредложить альтернативуИзменения позиций0Согласованность позицииНедостаточно доказательств для оценки согласованностиДругие предложения25
- Paola Perez · Участник не установленСообщения в обсуждении1Первое участие9 окт. 2018 г.Последнее участие9 окт. 2018 г.Первая заявленная позицияНеизвестноПоследняя заявленная позицияНеизвестноИзменения позиций0Согласованность позицииНедостаточно доказательств для оценки согласованностиДругие предложения17
- Неизвестно · Открытые источники найдены; проверка личности ещё не завершенаСообщения в обсуждении1Первое участие5 мар. 2018 г.Последнее участие5 мар. 2018 г.Первая заявленная позицияНеизвестноПоследняя заявленная позицияНеизвестноИзменения позиций0Согласованность позицииЯвная позиция не заявленаДругие предложения20
- Jordi Palet Martinez · Участник не установленСообщения в обсуждении0Первое участиеНеизвестноПоследнее участиеНеизвестноПервая заявленная позицияНеизвестноПоследняя заявленная позицияНеизвестноИзменения позиций0Согласованность позицииЯвная позиция не заявленаДругие предложения0
Источники и полнота данных
Официальные источники политики
Архивы публичных обсуждений
- lacnic-politicas
- Самая ранняя фиксация
- 21 окт. 1999 г.
- Последний снимок
- 8 окт. 2026 г.
- Последнее обновление
- 13 авг. 2026 г.
- Полнота данных
- Данные из источников собраны не полностью.
- Загрузка
- 5 258
- Известные пробелы
- 26
- www.lacnic.net
- lacnic-anuncios
- Самая ранняя фиксация
- 13 авг. 2026 г.
- Последний снимок
- 7 окт. 2026 г.
- Последнее обновление
- 9 окт. 2026 г.
- Полнота данных
- Данные из источников собраны не полностью.
- Загрузка
- 2 088
- Известные пробелы
- 0
- lacnic-ietf-lac
- Самая ранняя фиксация
- 30 мая 2013 г.
- Последний снимок
- 30 дек. 2015 г.
- Последнее обновление
- 9 окт. 2026 г.
- Полнота данных
- Данные из источников собраны не полностью.
- Загрузка
- 1 133
- Известные пробелы
- 0
- lacnic-infofrida
- Самая ранняя фиксация
- 14 авг. 2006 г.
- Последний снимок
- 13 сент. 2011 г.
- Последнее обновление
- 9 окт. 2026 г.
- Полнота данных
- Данные из источников собраны не полностью.
- Загрузка
- 287
- Известные пробелы
- 0
- lacnic-iot
- Самая ранняя фиксация
- 6 окт. 2015 г.
- Последний снимок
- 11 июл. 2017 г.
- Последнее обновление
- 9 окт. 2026 г.
- Полнота данных
- Данные из источников собраны не полностью.
- Загрузка
- 373
- Известные пробелы
- 0
- lacnic-lacnog
- Самая ранняя фиксация
- 1 авг. 2026 г.
- Последний снимок
- 8 окт. 2026 г.
- Последнее обновление
- 9 окт. 2026 г.
- Полнота данных
- Данные из источников собраны не полностью.
- Загрузка
- 5 951
- Известные пробелы
- 0
- lacnic-lactf
- Самая ранняя фиксация
- 13 апр. 2004 г.
- Последний снимок
- 29 дек. 2006 г.
- Последнее обновление
- 9 окт. 2026 г.
- Полнота данных
- Данные из источников собраны не полностью.
- Загрузка
- 2 267
- Известные пробелы
- 0
- lacnic-seguridad
- Самая ранняя фиксация
- 26 янв. 2006 г.
- Последний снимок
- 28 дек. 2007 г.
- Последнее обновление
- 9 окт. 2026 г.
- Полнота данных
- Данные из источников собраны не полностью.
- Загрузка
- 1 356
- Известные пробелы
- 0
Полнота данных
Частично
Самая ранняя фиксация: 21 окт. 1999 г.
Последний снимок: 9 окт. 2026 г.
Актуальность
Известные пробелы
- politicas.lacnic.net: Данные из источников собраны не полностью. · Сбор данных из заявленных источников ещё не завершён.
- www.lacnic.net: Данные из источников собраны не полностью. · Сбор данных из заявленных источников ещё не завершён.
- lacnic-politicas: Данные из источников собраны не полностью. · Сбор данных из заявленных источников ещё не завершён.
- www.lacnic.net: Данные из источников собраны не полностью. · Сбор данных из заявленных источников ещё не завершён.
- lacnic-anuncios: Данные из источников собраны не полностью. · Сбор данных из заявленных источников ещё не завершён.
- lacnic-ietf-lac: Данные из источников собраны не полностью. · Сбор данных из заявленных источников ещё не завершён.
- lacnic-infofrida: Данные из источников собраны не полностью. · Сбор данных из заявленных источников ещё не завершён.
- lacnic-iot: Данные из источников собраны не полностью. · Сбор данных из заявленных источников ещё не завершён.
- lacnic-lacnog: Данные из источников собраны не полностью. · Сбор данных из заявленных источников ещё не завершён.
- lacnic-lactf: Данные из источников собраны не полностью. · Сбор данных из заявленных источников ещё не завершён.
- lacnic-seguridad: Данные из источников собраны не полностью. · Сбор данных из заявленных источников ещё не завершён.