AFPUB-2018-GEN-001-DRAFT07

source representation · The retained source changes from a title-only Draft 1 capture to the full Draft 1 proposal and staff assessment. The comparison establishes added source detail, not a policy amendment between two policy texts.

Allocation and assignment scope is explicit · Compared with Draft 1, the page headed Draft 4 expressly covers resources allocated or assigned by AFRINIC and uses resource-holder language. Mandatory abuse contact and a monitored mailbox remain central. The archive header still says DRAFT01; the body and history identify this as Draft 4, so the header alone cannot establish version order.

Mailbox procedure is simplified · Draft 4 replaces detailed anti-filtering, automatic-reply and evidence-submission guidance with three requirements: recipient intervention, no compulsory web form, and receipt of reports with related evidence. It omits the two-email code/CAPTCHA example. This leaves operational procedure to AFRINIC rather than reproducing the earlier detailed workflow.

Validation windows become fifteen days each · Draft 4 changes the initial and escalated validation windows from two and three business days respectively to no more than fifteen days each. The newer text says days, not business days; those units must not be silently equated.

Routine validation interval becomes six months · The stated minimum routine validation frequency changes from once every three months in Draft 1 to once every six months in Draft 4. Validation on creation or update and additional validation at AFRINIC discretion remain.

Follow-up wording moves to discretionary warnings and service restrictions · Draft 4 replaces the operative follow-up reference especially to resource revocation with follow-up, warnings and blocking of certain services at AFRINIC discretion under relevant procedures. Escalation is simplified to reporting for revalidation. This is proposed wording, not evidence that any member was sanctioned.

IRT transition guidance is added · Draft 4 adds guidance to publish IRT as an alias or pointer to abuse-c while retaining other IRT information under updated guidelines. Draft 1 does not describe that transition. This is an implementation proposal, not proof of an actual WHOIS migration.

Timing flexibility is expressly described · Draft 4 adds explanatory permission for AFRINIC to vary validation periods and frequency when it informs the community of its reasons. Examples allow an easier initial rollout and later more frequent checks. The fixed defaults remain in the operative clauses; neither the examples nor the ninety-day expectation prove implementation occurred.

Abuse contact is clarified as an attribute pointing to a person or role · The page headed Draft 5 replaces the mandatory-object description with a mandatory abuse-c attribute and expressly states that it points to a person or role. The compulsory monitored mailbox remains. Both archive ID fields say DRAFT01; the page headings and revision history identify the comparison as Draft 4 to Draft 5.

Explicit discretionary service-blocking sentence is omitted · Draft 5 omits Draft 4’s sentence specifying follow-up, warnings and service blocking after non-compliance. It retains validation and revalidation for reported failures. That omission does not itself repeal obligations under the RSA or establish that sanctions were removed from other instruments.

IRT migration becomes a rename with discretionary compatibility · Draft 5 says that, if consensus is reached, AFRINIC must rename mnt-IRT to abuse-c. Keeping a compatibility alias, retaining IRT and its other data, and the transition duration become operational choices. Draft 4 instead describes publishing IRT as an alias and retaining other information under existing guidelines.

Yearly adjustment and gradual rollout become an explicit clause · Relative to the page headed Draft 5, the Draft 8 page includes section 8.7 allowing yearly changes to validation windows and frequency based on staffing, procedures and actual data, with reasons communicated to the community. Earlier explanatory flexibility already existed; this is not the first appearance of all timing discretion.

Validation checks reading rather than demonstrated understanding · Draft 8 asks confirmation that the resource holder has read the procedure and policy, where Draft 5 asks that the holder understands them. Monitoring, taking measures, and responding to reports remain. Draft 8 also uses other LIR contacts for escalation where Draft 5 says other member contacts; it does not explicitly exempt other resource holders.

Rollout timing is expressly left to operational capacity · Draft 8 adds guidance for a phased first pass, potentially over twelve to twenty-four months, and says implementation timing is not enforced. Its earlier summary still expects ninety days subject to AFRINIC confirmation. Those passages must be read together, not reported as a binding ninety-day deadline.

Boundary of enforcement and abuse assessment is explained · Draft 8 adds explanations that the proposal creates no special legacy-holder conditions, leaves non-compliance consequences to the RSA, and leaves the definition and substantive handling of abuse to Internet participants and applicable local processes. Draft 5 lacks these explanations. These are the author’s scope statements, not settled legal findings or a new exemption.

The pair spans several drafts and does not show new Draft 8 obligations · The later page records Drafts 6 and 7 before Draft 8. It describes Draft 8 as a validity extension without policy-text changes from Draft 7, with updated references to other RIRs. Differences from Draft 5 therefore cannot all be attributed to the Draft 8 update. The record does not prove board ratification.

The retained comparison runs from Draft 8 back to Draft 6 · The first retained page is headed Draft 8 and the second Draft 6, despite both archive ID fields saying DRAFT01. The second is therefore not evidence of a later rollback. Its absence of section 8.7 and later scope explanations reflects an older text in this comparison, not proof those provisions were subsequently repealed.

The second page retains a dated Draft 6 staff assessment · The Draft 6 page includes a 24 August 2020 assessment that requests clarification on legacy holders and estimates significant implementation and support work. The Draft 8 page merely marks its staff assessment as in progress. This changes the available assessment evidence; it is not a new policy rule or proof that the Draft 8 assessment completed.

Staff estimates must remain separate from proposed deadlines · The Draft 6 assessment says ninety days cannot be met, estimates six months for systems and twelve months for member compliance, and discusses RSA consequences of persistent non-compliance. The Draft 8 proposal instead explicitly leaves implementation timing to operational practices. These are different types and dates of statement, not proof of an enacted deadline or actual sanctions.

Only a title is retained for the second document · The first retained document is the full page headed Draft 6, including its staff assessment. The second contains only the archived Draft 2 title. This comparison establishes an incomplete source representation and reversed draft order; it cannot show what Draft 2 changed, prove removal of Draft 6 provisions, or establish a later rollback.

source representation · The retained source changes from a title-only Draft 2 capture to a full proposal page containing the draft text, revision history and staff assessment. The newly available detail should be treated as source enrichment rather than an inferred policy change.

Coverage of directly assigned resources · Draft 3 explicitly applies the mandatory abuse-c contact to resources allocated or assigned by AFRINIC; Draft 2's operative wording referred to allocated resources. This clarifies the text's coverage of direct assignments rather than establishing that the proposal had already been implemented.

Response to failed abuse-contact validation · Draft 2 prescribed initial account blocking, except for contact updates, and release of the block after revalidation. Draft 3 replaces that fixed sequence with further follow-up, warnings and blocking of certain services at AFRINIC's discretion under the relevant policies and procedures. The new wording does not identify which services must be blocked.

Escalation mechanism in section 8.6 · Draft 3 retains escalation for fraudulent validation or inadequate abuse responses, but states the operative requirement as a method enabling revalidation. Draft 2 placed an example mailbox and possible AFRINIC intermediation or resource-revocation procedures in section 8.6 itself; Draft 3 moves implementation examples and those further actions to the additional-information procedure. This is a change in how the requirement is specified, not evidence that escalation ceased to exist.

Time limits in the illustrative validation procedure · The worked example in Draft 3 extends validation-code validity from two working days to 15 working days and the subsequent correction period from three business days to 15 business days. These changes belong to the example procedure; the section 8.4 objectives already specified initial and escalation periods of no more than 15 days in both drafts.

Automation and human validation · Draft 3 changes the validation objective from avoiding automated processing to avoiding exclusively automated processing. The distinction allows automation alongside the retained requirement for a person to understand the procedure and monitor the abuse mailbox.

IRT and abuse-c publication wording · Draft 3 describes the IRT publication relationship explicitly as an alias to abuse-c, where Draft 2 said the IRT would also be published as abuse-c. Both retain the aim of finding the same contact information through either name and preserving the remaining IRT information; neither passage demonstrates that the migration had occurred.

Ticket continuity in abuse correspondence · Draft 3 adds that a generated ticket number should be retained, typically in the subject, through successive communications. Draft 2 already described automatic reporting and optional initial ticket assignment but did not include this explicit continuity instruction in the corresponding passage.

Warnings in the illustrative follow-up procedure · Draft 3 adds explicit multi-channel warnings to the resource holder, including other mailboxes and alert pop-ups, with the policy text and consequences of continued non-compliance. It also says that blocking access to certain services should be considered in the example procedure. Draft 2 proceeded from its short correction window to repeated validation without this warning paragraph.

Abuse-mailbox handling requirements · Draft 4 replaces draft 3's detailed manual-intervention, filtering, automatic-reply and ticket-handling discussion with three requirements: recipient intervention, no mandatory reporter form, and receipt of reports and accompanying evidence. The shorter wording retains the practical contact obligation but no longer expressly prohibits filtering or describes permissible automatic replies. That textual simplification does not establish that reports may be discarded or that automation is prohibited.

Validation objectives and responsible contact · The newer draft removes the express objectives of authenticating AFRINIC validation requests and avoiding exclusively automated processing. It instead requires a simple process that makes the contact functional and confirmation that the resource holder understands the procedure, monitors the mailbox, takes measures and responds. Failure escalates to other LIR contacts; the two initial and escalation limits remain 15 days. These are changes in the specified objectives, not evidence that an operational validation system was deployed.

Where adjustable validation periods are specified · Draft 4 moves the explanations permitting AFRINIC to adjust initial and escalation periods, and the frequency of periodic checks, into Additional information. The proposal still specifies 15-day initial and escalation limits and validation at least every six months, while retaining adjustment explanations conditioned on informing the community. The relocation must not be described as an unqualified removal of timing requirements or discretion.

Detailed validation example and accompanying assessment · The newer retained page omits the old two-email, code and captcha example, including its temporary-invalid and invalid states, and does not carry the earlier staff assessment. It states the validation objectives and permits reporting non-compliance to AFRINIC for revalidation. The removed example was additional guidance, and the omitted assessment was staff commentary; neither absence proves repeal of the policy's escalation mechanism or of separate RSA enforcement powers.

Contact data model · Draft 5 clarifies that abuse-c is a mandatory attribute pointing to a person or role, with at least one monitored abuse mailbox. Draft 4 described a mandatory object and a contact in the corresponding WHOIS entry. This makes the reference structure more explicit; it does not create evidence of a completed WHOIS migration.

Contacts used when validation fails · The escalation recipient changes from other LIR contacts to other member contacts, and the surrounding implementation discussion similarly refers to members. The new wording is less tied to the LIR class. Both versions keep the second validation period at no more than 15 days; the text does not establish how many members were affected in practice.

Express enforcement sentence · The draft-4 sentence prescribing follow-up, warnings and discretionary service blocking after non-compliance is absent from draft 5's proposed section 8.5. The validation frequency and escalation-to-AFRINIC mechanism remain. The newer rationale expressly invokes database-accuracy obligations under the RSA, so this omission must not be treated as a waiver of separate RSA enforcement or proof that sanctions were abolished.

IRT transition and operational discretion · The earlier additional information promised an IRT alias or pointer to abuse-c. The newer draft says that, if consensus is reached, mnt-IRT must be renamed to abuse-c; AFRINIC chooses whether and how long to retain an alias and the IRT data, and how to update the guidelines. This replaces a specific transitional arrangement with more operational discretion, conditional on the proposal's approval.

Validation wording and escalation contacts · Draft 6 changes confirmation that the resource holder understands the policy into confirmation that the holder has read it, with separate monitoring, action and response bullets. It also changes other member contacts back to other LIR contacts. Although its history calls the revision editorial improvements, those are observable wording differences; the latter should not be silently treated as identical coverage of all member categories.

New staff assessment and implementation constraints · The new page adds a dated staff assessment describing WHOIS, MyAFRINIC and registration-process changes, the initial compliance workload and potential staffing needs. It says the proposal's 90-day expectation cannot be met, estimates six months for systems work and twelve months for member compliance, and requests clarification about legacy resources. These are staff estimates and unresolved scope questions, not evidence of implementation or an amendment that automatically imposes those timelines.

Historical references and date uncertainty · The references now describe LACNIC as having accepted an equivalent proposal that was under implementation, and describe discussion in RIPE. These are the source's historical comparisons, not verified present-day implementation status. Draft 5's own history dates it to 22 November 2019, while draft 6's retrospective history says 21 November; that disagreement remains visible. Draft 6's dated assessment and later typo correction are separate from its 5 August 2020 draft date.

New operative slow-start provision · Draft 7 adds proposed section 8.7, expressly allowing yearly adjustment of initial and escalation periods and validation frequency in light of staffing, procedures and actual data, with reasons communicated to the community. Draft 6 discussed adjustable periods in Additional information but lacked this separate operative section. The change gives the gradual rollout an explicit policy basis; it is not proof that any particular extension was exercised.

Legacy resources, abuse definitions and enforcement boundaries · The new explanatory text says the proposal sets no different conditions for legacy holders, leaves non-compliance consequences to the RSA and leaves the definition of abuse and escalation beyond contact validation to participants and their local rules. It also asserts no additional GDPR impact. The earlier staff assessment expressly requested guidance on legacy applicability; the newer assessment lists no clarification requests. These statements clarify the author's intended scope and the assessment's position, but are not an independent legal determination or proof that every legacy resource was brought into compliance.

Rollout timing and financial assessment · The newer additional information illustrates an initial pass lasting 12–24 months and explicitly leaves implementation timing to AFRINIC's operations, priorities and staffing. Its revised staff assessment records no financial impact and a phased rollout, replacing the earlier assessment's extra-staff requirement and six-month systems/twelve-month compliance estimates. These remain proposal explanations and staff planning statements; they do not establish actual completion dates or a measured absence of cost.

Publication and adoption context · The newer retained page identifies DRAFT07, gives 17 May 2021 and labels the proposal Ratified, whereas the earlier retained page is an archived draft-6 page with a conflicting DRAFT01 header. The comparison follows the source-specific draft sequence. The Ratified label is evidence of the later page's stated status; it does not itself date a Board decision to the submission date or prove technical implementation.

Renewal of proposal validity · Draft 8's revision history explicitly describes a version update without policy changes to extend validity for Board ratification, with reference information updated. The retained operative provisions, including the yearly-adjustable slow-start rule, remain substantively the same as draft 7; punctuation and explanatory wording differ. This is evidence of the stated purpose of the renewal, not proof that the Board ratified the proposal or that deployment occurred on 15 May 2022.

Availability of the staff assessment · The draft-7 page carries a full staff assessment, including operational effects and phased implementation. The retained draft-8 page ends with Staff Assessment (In Progress). That changes the evidence available on this page; it does not prove that the prior assessment was repudiated or that previously described systems obligations were removed. The earlier assessment remains retained separately.

Conflicting migrated metadata and status labels · The newer page title says Draft 8 and its history dates that version to 15 May 2022, yet its header reuses DRAFT01 and a 5 August 2020 submission date and labels the page Archived. The older draft-7 page says Ratified. These are conflicting retained page metadata and capture contexts, not evidence that ratification was reversed. The derived sequence uses the explicit draft-8 title and history while preserving both source snapshots and their status differences.