RFSeek: Protocol Summary Visualization

• RFSeek is an interactive tool that produces provenance-linked, explorable visual summaries by unifying diagrammed state-machine content with textual protocol logic.
• Its staged extraction pipeline leverages preprocessing, dense embedding retrieval, and LLM-based summarization to ensure complete and auditable representations.
• RFSeek distinguishes between diagram-derived and prose-derived transitions, supporting accurate implementation, auditing, and enhanced protocol comprehension.

RFSeek is an interactive tool for extracting visual summaries of protocol logic from Requests for Comments (RFCs). It is designed for the setting in which RFCs are authoritative but operationally difficult to read because they are long, prose-heavy, distributed across sections, and often pair incomplete diagrams with text that contains crucial behavior omitted from those diagrams. RFSeek uses LLMs to generate provenance-linked, explorable diagrams that unify official state-machine content with additional logic found only in prose, while preserving traceability for every extracted transition. The system frames this output as Summary Visualization, a human-readable, auditable protocol summary rather than a minimal machine-readable finite-state model for downstream automation (Rotman et al., 12 Sep 2025).

1. Problem setting and design objective

RFSeek addresses a specific problem in protocol engineering: RFCs are often difficult to translate into a faithful operational understanding suitable for implementation. The difficulty is not merely one of document length. RFCs are intentionally permissive, protocol rules are frequently spread across distant sections, and ASCII diagrams included in the specifications are often incomplete by design. As a result, an implementation-relevant transition may be described only in prose, or a diagram may omit behavior for readability even when that behavior is normative or practically important (Rotman et al., 12 Sep 2025).

The system is explicitly positioned against a different line of prior work that extracts approximate protocol models for tasks such as fuzzing or attack synthesis. In those contexts, approximate models may be acceptable if they improve coverage. RFSeek adopts a different objective: accurate protocol comprehension and implementation support. That objective changes the requirements. The extracted model must be faithful to the RFC, readable by humans, and auditable against the original document.

This emphasis on protocol comprehension leads to the central distinction of RFSeek. It does not treat RFC diagrams as complete ground truth, and it does not attempt only to “extract an FSM from text.” Instead, it treats the full RFC as authoritative and seeks a summary representation that merges diagrammed state-machine content with transitions, conditions, and actions found elsewhere in the prose. This suggests a shift from extraction for automation toward extraction for human understanding.

2. Summary Visualization as the core representation

RFSeek’s principal representational contribution is what its authors call Summary Visualization. This is not described as a minimal formal automaton. It is a provenance-aware, user-customizable visual model of protocol behavior that is intended to be more complete than the diagrams embedded in an RFC and more transparent than prior extraction tools (Rotman et al., 12 Sep 2025).

The summary representation has several defining properties. It does not omit transitions for which evidence has been found. If multiple states share the same event and behave identically, RFSeek may introduce a grouped node to reduce clutter. The representation includes not only mandatory transitions, but also recommended transitions and transitions inferred from prose, provided that the reasoning is shown. Every transition includes four elements: the triggering event and any conditions, the detailed action to take, the originating text, and, for grouped transitions, the set of states covered.

This representation is significant because it redefines completeness in a protocol-summary setting. Instead of privileging compactness, RFSeek privileges faithful surfacing of behavior together with the evidentiary trail needed for inspection. A plausible implication is that the representation is useful not only for implementers but also for RFC authors, since omissions and ambiguities in official diagrams become visually salient.

3. Extraction pipeline and architectural workflow

RFSeek is implemented as a staged pipeline that decomposes RFC processing into semantically narrower tasks. The pipeline begins by preprocessing and partitioning the RFC. Whitespace is cleaned up, ASCII tables are condensed, and the document is split into sections, subsections, or smaller fragments because RFCs are too large for a single prompt. For each chunk, RFSeek computes dense embeddings and retrieves semantically related excerpts from elsewhere in the RFC, reflecting the fact that protocol logic is often distributed across distant sections (Rotman et al., 12 Sep 2025).

The system then performs an LLM-based summarization stage using GPT-4.1 via the OpenAI API. These summaries are tailored to finite-state extraction rather than generic document summarization. The goal is to preserve transitions grounded in evidence, include recommended and inferred transitions when justified, and retain the relevant conditions, actions, and source text. A second LLM stage converts these summaries into a visual protocol model. For each edge, the model is instructed to identify the exact summary segment or segments that justify it.

The final stage is semantic grounding. RFSeek retrieves the exact RFC passages that support each extracted edge and loads the resulting model into an interactive interface where nodes and transitions can be traced back to their textual origin. The paper stresses that the LLM is not asked to hallucinate a final FSM directly. Instead, it is used in modular steps aligned with summarization and grounding. This staged decomposition is presented as a mechanism for improving both controllability and auditability.

The workflow can be summarized concisely:

Stage	Function	Output
Preprocess and partition	Normalize RFC and split into chunks	Structural fragments
Retrieve related context	Use dense embeddings to gather semantically relevant excerpts	Context-expanded chunk
Summarize and extract	Produce FSM-oriented summaries, then derive nodes and edges	Visual protocol model
Ground and render	Link edges to exact RFC passages	Provenance-aware interactive diagram

4. Official diagrams, prose-only logic, and visual encoding

A major feature of RFSeek is its explicit distinction between logic extracted from official state-machine diagrams and logic found only in the surrounding prose. In the user interface, diagram-derived edges are shown in blue, while edges found elsewhere in the RFC text are shown in green. A “light bulb” toggle can gray out the diagram-derived edges and highlight the extra logic found only in prose (Rotman et al., 12 Sep 2025).

This distinction is central to the system’s purpose. RFC diagrams are treated as partial views rather than exhaustive protocol models. RFSeek therefore attempts to recover transitions that the diagrams omit for readability, and it can even recover behavior that is never drawn but is described textually. The paper argues that this capability is more aligned with implementation support than tools that merely reconstruct the visual content already present in a specification.

The TCP example illustrates the point sharply. RFSeek finds a transition from SYN-RECEIVED to LISTEN triggered by receiving a SYN under a passive OPEN setup. This edge is absent from both the RFC’s ASCII FSM diagram and its notes, but the behavior is described in §3.10.7.4 of the text. The paper further notes that this transition also appears in the Linux TCP implementation, which supports the claim that the extracted edge reflects real protocol logic rather than extraction noise (Rotman et al., 12 Sep 2025).

The same mechanism underlies RFSeek’s use as a semantic diffing tool. The “diff” is semantic rather than textual: it reveals transitions or nodes that are present in the authoritative specification but absent from the embedded diagram, or behavior that is represented differently across separate parts of the RFC. This makes the system useful for auditing where official protocol visualizations under-specify operational behavior.

5. Case studies across TCP, PPTP, QUIC, and DCCP

RFSeek is evaluated on four protocols: TCP (RFC 9293), PPTP (RFC 2637), QUIC (RFC 9000), and DCCP (RFC 4341). These case studies are used to demonstrate both reconstruction of official diagrams and extraction of additional logic from prose (Rotman et al., 12 Sep 2025).

In TCP, the principal finding is the recovery of the SYN-RECEIVED $\rightarrow$ LISTEN transition described above. The paper treats this as evidence that implementation-relevant logic can be present in prose while being absent from the canonical diagram.

In PPTP, RFSeek recovers nearly all RFC diagrams, missing only six transitions, and also surfaces a previously undocumented node together with additional branching around a connection-initiation collision scenario. The discussion centers on the state wait_ctl_reply and an idle transition. The RFC diagram shows the loser of a race returning to idle, while the prose explains that the winner follows a different path. RFSeek synthesizes this missing distinction and constructs a new collision node.

In QUIC, the system is applied to a specification that contains only partial and inconsistent state-machine figures for selected procedures, while much of the state logic is textual. RFSeek reconstructs and unifies these fragmented descriptions into a more coherent summary, surfacing procedures that are not visualized in the official document at all. The QUIC case is presented as the representative example for deriving genuinely new visualization diagrams for complex RFCs.

In DCCP, RFSeek exposes a subtle distinction in reset handling by creating two grouped nodes for receiving a DCCP-Reset packet: one for CLOSED, LISTEN, and TIMEWAIT with reset code 3, and another for REQUEST and RESPOND with reset code 4. The RFC text distinguishes these behaviors, but the diagram does not make the split explicit. Grouped nodes are used here to keep the summary readable while preserving semantically meaningful distinctions.

6. Evaluation, transparency, and limitations

RFSeek is compared against PROSPER where a direct comparison is meaningful. The paper reports the following missing-node and missing-edge counts: PPTP: PROSPER missed 19 edges, whereas RFSeek missed 6 edges and 0 nodes; DCCP: PROSPER missed 1 node and 7 edges, whereas RFSeek missed 0 nodes and 1 edge; QUIC: RFSeek missed 0 nodes and 2 edges, and PROSPER is not directly compared because QUIC’s RFC contains only two diagrams and much of the state logic is textual; TCP: RFSeek missed 0 nodes and 1 edge, and the comparison to PROSPER is considered unfair because PROSPER used RFC 793 rather than RFC 9293 (Rotman et al., 12 Sep 2025).

The paper is careful not to claim completeness. Its stronger claim is correctness paired with traceability. Transparency is therefore a central evaluation dimension. In the interface, users can hover on edges to view supporting summary text, click “Show in RFC” to jump to relevant passages, navigate among multiple supporting excerpts, and visually isolate prose-only logic. The authors frame this as a new standard for auditability in protocol analysis, since an extracted model that cannot be justified against the authoritative text is difficult to trust in implementation settings.

The limitations are also discussed explicitly. RFSeek is sensitive to prompting. If the LLM is prompted to extract only a “precise and accurate FSM,” it may omit edges that had previously been identified, including the TCP edge discussed above. If the original FSM diagram is omitted from the input, some transitions disappear, suggesting that some diagram-only information is difficult for a text-only model to recover. Short, targeted summaries worked better than generic summaries without reducing precision. Conversely, when the prompt was modified to force explicit extraction of all transitions mentioned in summaries, explicitly mentioned transitions were retained but some implicitly inferred transitions disappeared. The paper states that this behavior requires further investigation.

These observations place RFSeek in an intermediate position between fully manual protocol analysis and fully automated formal extraction. It is effective as a provenance-aware summarization system, but its behavior still depends on prompt design and document structure.

7. Significance and broader implications

RFSeek’s main contributions are fourfold: a new summary representation for RFC protocols; a modular extraction pipeline combining LLMs, retrieval, and grounding; an interactive tool for exploring protocol logic; and an evaluation on TCP, QUIC, PPTP, and DCCP showing both reconstruction of official structure and recovery of logic hidden in prose (Rotman et al., 12 Sep 2025).

Its broader significance lies in the reframing of protocol visualization. Rather than replacing RFCs, RFSeek treats the entire RFC as the source of structured behavior and produces a readable summary richer than the official figures. This suggests a practical role in implementation support, specification auditing, and semantic comparison between prose and diagrams. It also suggests a methodological direction in which LLMs are paired not with opaque end-to-end extraction, but with provenance-aware visual abstractions that remain inspectable by domain experts.

Within that framing, RFSeek can be understood as an instance of LLM-assisted specification analysis in which interpretability is not an afterthought. The system’s emphasis on grounding, user-customized visual summaries, grouped states, and explicit differentiation between diagram-derived and prose-derived logic reflects a research agenda centered on robust protocol comprehension rather than mere model extraction.