conext-reproducibility

name	conext-reproducibility
description	Use when building the reproducibility story for an ACM CoNEXT paper — pinned traces and configs, a runnable artifact, an honest data-availability posture, and the one-page artifact description the CoNEXT reproducibility committee needs — remembering that the ACM badge opt-in is due before the submission deadline.

CoNEXT Reproducibility

Build the reproducible-networking story alongside the experiments, not after acceptance. CoNEXT runs a dedicated reproducibility committee that awards optional ACM badges, and the single most missed rule is that badge eligibility requires opting in before the paper submission deadline — you cannot bolt it on later. Even for authors who skip badging, a reproducible artifact strengthens a double-anonymous, one-shot-revision review.

The timing trap (read this first)

[Before the submission deadline]  OPT IN for ACM badging (required for eligibility)
[At submission]                   anonymized, runnable artifact referenced from the paper
[Within ~1 week of acceptance]    send a ONE-PAGE artifact description to the reproducibility
                                  committee with pointers to code and other artifacts
[Camera-ready / post-accept]      committee evaluates for Available / Functional / Reusable /
                                  Reproduced badges (see conext-artifact-evaluation)

Miss the opt-in and the strongest artifact in the world cannot earn a badge this cycle.

What "reproducible" means for a networking paper

Networking reproducibility is harder than "here is the code," because the result depends on an environment:

• Traces: the exact captures, with vantage points, dates, and anonymization documented, plus the extraction scripts that turn raw captures into the paper's inputs.
• Configs: the exact parameters, topology, and settings used for each figure — not a representative example.
• Environment: hardware models, firmware, kernel/OS versions, link rates, and buffer depths for a testbed; container/VM images where feasible.
• Pipeline: a scripted path from raw data/trace to each table and figure, so the numbers regenerate rather than being hand-copied.

Pin provenance at collection time

You cannot reconstruct provenance after the campaign ends:

• Record capture vantage points, timestamps, and anonymization method as you collect.
• Snapshot configs and firmware/OS versions at run time; a later "we think it was v2.1" is not reproducible.
• For ML-for-networking, pin model identifiers and dates and cache raw model outputs — a package that needs live API calls re-samples rather than reproduces.

Honest data-availability posture

• If you can release traces/code, do — with a DOI-issuing archive (Zenodo/figshare/Software Heritage) and an open license.
• If operator agreements or privacy limits block release, say so and why, and release what you can (aggregate data, synthetic traces, the analysis pipeline). "Available upon request" reads as a scored weakness, not a neutral placeholder.
• Keep the availability statement honest and matched to what the artifact actually contains — a reviewer or the committee will check.

Anonymity of the artifact (double-anonymous review)

• Re-host the artifact behind an anonymizing service before submission; scrub commit metadata, internal hostnames, and owner-identifying paths.
• Topology diagrams and configs can leak an operator or institution — sanitize AS numbers, hostnames, and IP ranges you own.
• The reproducibility material referenced at review time must not de-anonymize you.

The one-page artifact description

After acceptance, the committee wants a one-page description that lets an evaluator start quickly:

• What the artifact contains (code, traces, configs, testbed scripts) and pointers to each.
• The hardware/software the evaluator needs, and any hardware you must provide access to (some networking artifacts need specific switches/NICs — flag this early).
• A short "getting started" path and the claims the artifact supports.

Pre-submission reproducibility audit

[Opt-in]        badge opt-in done BEFORE the submission deadline? (if badging) yes/no
[Traces]        captures + vantage points + dates + extraction scripts present? yes/no
[Configs]       exact per-figure configs and topology recorded? yes/no
[Environment]   hardware/firmware/OS versions pinned; image where feasible? yes/no
[Pipeline]      raw -> figure regenerates by script? yes/no
[Availability]  honest statement; DOI archive or a documented reason not to release? yes/no
[Anonymity]     artifact re-hosted anonymously; metadata scrubbed? yes/no

Output format

[Reproducibility status] ready / gaps
[Badge intent] opt-in before submission? yes/no/n-a
[Provenance] traces/configs/environment pinned at collection time
[Availability] what is released, where (DOI), and any documented restriction
[Anonymity] artifact anonymized for double-anonymous review
[One-pager] artifact description drafted for the committee (post-accept)