Summary

  • Susan Hares’s attributed record in RFC 1745, RFC 4271, RFC 8241, RFC 8242, and current IDR stewardship traces a consistent operational concern: routing decisions become governable only when the inputs, policy boundaries, state changes, conflict rules, and withdrawal conditions are made explicit.
  • That record defines requirements and common behavior, not guaranteed results. IETF consensus, co-authors, implementers, vendors, and network operators retain distinct authority over specifications, software, configuration, deployment, observation, and recovery; no individual controls BGP or the outcomes produced by running networks.

Attribution without personalizing a distributed system

The useful way to read Susan Hares’s IETF record is not as a conventional biography. The frozen public record establishes a narrower and more defensible proposition. The IETF profile identifies Susan Hares, also listed there as Sue Hares, as a chair of the Inter-Domain Routing Working Group and associates her with a substantial set of routing RFCs. Four documents provide the technical spine for this analysis: the 1994 BGP–OSPF interaction specification, the 2006 BGP-4 specification, and two 2017 requirements documents addressing security and ephemeral state for a programmable interface to the routing system.

Attribution matters because standards work is performed by identifiable people, and operational choices do not emerge from nowhere. Yet attribution is not ownership. RFC 4271 lists Yakov Rekhter, Tony Li, and Susan Hares as editors. RFC 1745 lists Kannan Varadhan, Susan Hares, and Yakov Rekhter as authors. RFC 8241 is attributed to Hares, Daniel Migault, and Joel Halpern, while RFC 8242 is attributed to Jeff Haas and Hares. The documents also acknowledge working-group discussion, reviewers, earlier protocol work, and contributions from many named entities. The current IDR charter lists Hares alongside Keyur Patel and Jeffrey Haas as chairs.

These facts establish participation and stewardship, but they rule out a story of solitary design.

That boundary is especially important for BGP. A specification can define common vocabulary, externally visible behavior, and required error handling. A working group can refine those requirements through review and consensus. An implementer can translate them into software, a vendor can package the software, and an operator can select policies and decide where it runs. Observed reachability then depends on the interaction of many independently controlled systems.

The standards record can show where Hares helped make choices explicit; it cannot show that she chose every route, directed every working-group result, or caused a measured operational outcome.

Within that limit, the record has a coherent operational thesis. RFC 4271 separates received information, local selection, and outbound advertisement. RFC 1745 examines what can go wrong when exterior and interior routing systems translate each other’s information. RFC 8241 bounds who may read or change routing state and over what kind of channel. RFC 8242 defines what temporary state means, how writers contend, and what does not roll back automatically. The current IDR charter places continued BGP maintenance inside a scoped, multi-party process.

Across these documents, control becomes visible as a chain of decisions rather than a title held by one person.

RFC 4271: policy begins with a bounded protocol

RFC 4271 describes BGP as an inter-Autonomous System routing protocol whose primary function is to exchange network reachability information. That information includes the sequence of autonomous systems traversed, allowing a BGP speaker to construct a view of AS connectivity, prune loops at that level, and enforce some policies. The word “some” carries weight. The specification says BGP’s routing information supports destination-based forwarding and therefore can support only policies compatible with that paradigm. It does not present BGP as a universal policy language.

This boundary keeps the protocol honest. BGP pairs reachable destinations with path attributes, but a route is not a command issued by a central controller. It is information received from or prepared for a peer, interpreted under local policy. The protocol provides a shared structure for exchange while leaving important decisions to each participating system. Even the definition of an Autonomous System emphasizes a coherent external picture under one technical administration, not uniform internal machinery. An AS may use multiple interior protocols and metrics while still presenting consistent reachability to others.

The specification turns that principle into a three-part conceptual separation. Adj-RIBs-In contain unprocessed routing information learned from peers. The Loc-RIB contains routes selected after the local speaker applies its policies. Adj-RIBs-Out organize routes selected for advertisement to particular peers. This separation is conceptually strong and operationally modest: RFC 4271 explicitly says an implementation need not keep three physical copies. One implementation may use separate stores; another may use a shared structure with references. What must remain compatible is the externally visible behavior.

That distinction between conceptual responsibility and implementation freedom is central to Hares’s attributed standards work. It gives operators and implementers a common way to ask where a result came from. Was a route received? Was it eligible? Did local policy prefer it? Was its next hop resolvable? Was it installed for local use? Was it allowed into the outbound set for this peer? The vocabulary does not answer those questions for a particular network, but it makes the questions separable.

RFC 4271 also distinguishes the BGP information bases from the routing table used to construct forwarding state. The routing table can accumulate connected, static, interior-protocol, and BGP routes. Whether a selected BGP route displaces a route learned through another source is a local policy decision outside the document’s prescription. This is a decisive limit on standards authority. The RFC structures the choice; it does not make the choice for an operator.

The same is true of route change. A speaker may withdraw a prefix explicitly, advertise a replacement with the same reachability information and changed attributes, or close a peering connection, which implicitly removes the routes exchanged across that connection. These are explicit state-change mechanisms. They make removal and replacement observable at the protocol boundary, but they do not guarantee that every surrounding system will converge in a particular time or select the same alternative. The standard supplies the grammar of change, not a universal outcome.

The three phases of the BGP decision process

The decision process in RFC 4271 is the clearest expression of routing policy as an operational sequence. It takes routes stored in Adj-RIBs-In, applies policies from the local policy information base, selects routes for local use, and prepares routes for advertisement. The description is conceptual: software need not reproduce the internal organization word for word, provided it supplies the required function and the same visible behavior.

Phase 1 calculates a degree of preference for each feasible route. For a route learned from an internal peer, the speaker can use LOCAL_PREF or compute preference from configured policy. For a route learned from an external peer, the speaker computes preference from preconfigured policy and may declare the route ineligible. If eligible, that preference becomes the LOCAL_PREF used in internal readvertisement. The exact policy and computation are local matters.

The specification adds an important constraint: the preference function for one route must not use the existence, absence, or path attributes of other routes as inputs. Preference is first assigned individually; comparison follows. That separation limits hidden interdependence. It does not remove operator discretion, but it locates discretion before competitive selection. An operator reviewing unexpected behavior can distinguish the policy that scored a route from the later process that compared it with alternatives.

Phase 2 chooses the best eligible route for each destination and installs it in the Loc-RIB. Preference is necessary but not sufficient. A route whose NEXT_HOP cannot be resolved must be excluded, as must a route that would become unresolvable if installed. Mutually recursive resolution is therefore not a usable basis for forwarding. If next-hop reachability or the interior cost to that next hop changes, selection must run again. Unresolvable routes are removed from the Loc-RIB and routing table, although they should remain in Adj-RIBs-In in case their next hops later become resolvable.

This behavior links declared policy to running state. A route can be desirable under policy yet unusable under current reachability. Conversely, an available next hop does not decide policy by itself. The route must pass both preference and resolvability conditions. The specification also warns that BGP speakers inside an AS must not make conflicting choices that create forwarding loops. Consistency is not an abstract virtue here; it is a condition for safely turning distributed information into local forwarding.

When several routes have equal preference, RFC 4271 defines an ordered tie-breaking procedure. It progressively narrows the candidates using path length, origin, eligible comparison of MULTI_EXIT_DISC, external versus internal learning, interior cost to the next hop, BGP identifier, and peer address. The order matters because later criteria apply only after earlier ones leave a tie. The document allows different algorithms internally, but they must produce the described result. This is another form of bounded implementation freedom: optimize the mechanism if needed, but preserve the decision semantics.

The attributes themselves express different scopes of policy. LOCAL_PREF communicates a degree of preference among internal peers and is not ordinarily sent to external peers. MULTI_EXIT_DISC is an optional, non-transitive signal used among multiple connections to the same neighboring AS, with the lower value preferred when other factors are equal. NEXT_HOP names the router address to resolve for forwarding. AS_PATH records the autonomous systems through which the routing information has passed. None of these attributes is a global instruction. Each has a defined scope, and local configuration can affect how it is interpreted or transformed.

Phase 3 begins after the Loc-RIB changes. It processes local selections into Adj-RIBs-Out according to configured policy. A selected route may be excluded from advertisement to a particular peer. If policy newly excludes a route that was previously advertised, that route must be withdrawn from that peer. A route may not be placed in an outbound set unless the destination and next hop can be forwarded appropriately through the routing table. This ties advertisement to current forwarding capability within the scope described by the RFC.

The third phase also permits aggregation and information reduction. Those mechanisms can reduce the amount of routing information exchanged, but RFC 4271 notes the tradeoff: collapsing information can reduce the granularity of policy control because the same policy then applies across an equivalence class of destinations or paths. Efficiency is therefore not free. The decision to aggregate changes what downstream systems can distinguish, and the attributes of an aggregate must obey rules designed to preserve essential path information and loop-avoidance properties.

Taken together, the phases make policy inspectable as a pipeline. Receipt is not acceptance. Acceptance is not preference. Preference is not resolvability. Local selection is not outbound authorization. Advertisement is not proof of forwarding everywhere. This chain is the article’s core operational reading of Hares’s role as one of RFC 4271’s editors: the document makes the stages and boundaries explicit while leaving actual policy values, software design, and network consequences to their proper owners.

Session state and the limits of conceptual precision

RFC 4271’s finite-state machine adds a second kind of explicitness. It defines peer operation through events, timers, connection state, and actions. The standard requires a separate state machine for each configured peering and describes progression through states including Idle, Connect, Active, OpenSent, OpenConfirm, and Established. UPDATE messages are valid only in Established. Session attributes track state, connection retries, hold time, and keepalive behavior, while optional attributes support features such as delayed opening or peer-oscillation damping.

Again, the RFC calls these structures conceptual. Implementations do not have to reproduce them internally if they provide the same function and visible behavior. That caveat avoids confusing a standards diagram with running software. What the document supplies is a common account of when resources are initialized, when connections are attempted, when messages are accepted, and when a session returns to a safer state.

The operational value lies in explicit transitions. A connection is not simply “up” or “down”; it moves through stages in response to administrative events, transport events, protocol messages, and timers. A route update is not valid whenever bytes arrive; it is tied to an established protocol relationship. This makes session state part of the control boundary. Yet the RFC also says initialization details and associated resource handling depend on the policy portion of an implementation. The standard defines externally important behavior without claiming authority over every internal choice.

RFC 1745: translating between exterior and interior routing

RFC 1745 addresses a harder boundary than selecting among BGP routes: the interaction between an exterior routing protocol and OSPF inside an autonomous system. The document, co-authored by Kannan Varadhan, Susan Hares, and Yakov Rekhter, specifies criteria for an Autonomous System Border Router running BGP-4 or IDRP externally and OSPF internally. Its subject is not merely data conversion. It is the preservation of meaning when two routing systems use different attributes, metrics, and decision rules.

The specification starts with cautious defaults. When exporting OSPF information into BGP, the administrator must be able to filter at the granularity of an address-and-mask pair and by the OSPF external-route tag and its subfields. The default is to export no OSPF routes. One setting may permit broad export of internal and inter-area information, but OSPF external routes must not be exported unless explicitly configured. When importing BGP information into OSPF, the default is likewise to import nothing; administrators must select the destinations they want, although an implementation may offer an explicit import-all option.

These defaults reveal an operational judgment: protocol boundaries should fail closed. The alternative—automatic redistribution—can convert information intended for one scope into reachability advertised in another. RFC 1745 does not say that selective configuration prevents all failures. It defines a safer starting point and the controls an implementation must expose.

The document also requires the export process to track real reachability. An ASBR may advertise a set of destinations once at least one member is reachable through OSPF, but it must stop when none are reachable. It must not export a non-contiguous mask. Administrators must be able to set MULTI_EXIT_DISC for exported routes, while omission is the default. Implementations must also provide a configurable delay between learning interior reachability and advertising it externally, with zero as the default. These are choices about timing, granularity, and evidence of reachability, not claims about measured convergence.

Importing in the opposite direction presents a semantic mismatch. OSPF prefers lower cost; BGP LOCAL_PREF prefers a higher value. Their numerical ranges also differ. RFC 1745 therefore warns that constructing OSPF cost from LOCAL_PREF requires extreme care. In addition, when ASBRs correlate exterior and interior information as the document describes, OSPF cost can determine the selected border path while LOCAL_PREF ceases to control that particular choice. A value that expresses preference in one system cannot be copied blindly into another without considering direction, range, and the point at which selection occurs.

The specification treats default reachability with similar caution. An ASBR must never inject a default destination into OSPF unless explicitly configured. It offers a conditional method based on selected destination-and-path tuples, but the operator remains responsible for choosing the condition, cost, and type. A default route compresses many possibilities into a single instruction; making its creation explicit limits accidental authority.

Metadata, equal-cost paths, and a documented loop

RFC 1745 uses OSPF tags to carry enough context for an ASBR to reconstruct BGP origin and path information when routes cross the protocol boundary. The tag can indicate whether it was generated automatically, whether path information is complete, an abbreviated path-length class, and an autonomous-system value. Manually configured tags remain possible, but the document warns that no characteristics of the destination set may be inferred from such a tag.

Some automatically generated combinations permit export with reconstructed attributes; others require that a route never be exported back into BGP because path information is truncated or because the route already came from BGP.

This is security metadata in a broad operational sense: not a cryptographic proof, but information that constrains what a receiving process may safely do. Its value depends on accurate setting and correct interpretation. RFC 1745 makes accurate tags part of a minimal implementation and says truncated-path cases must not be re-exported. A tag is therefore not decorative annotation. It carries a boundary decision about provenance and re-advertisement.

The same concern appears in the relationship between OSPF forwarding addresses and BGP NEXT_HOP. When importing a BGP destination into OSPF, the ASBR must place the BGP next-hop value into OSPF’s forwarding-address field. When exporting interior destinations, it may name another reachable router as the BGP next hop when the conditions permit, avoiding an unnecessary additional hop through the translating ASBR. The rule aligns control information with the intended forwarding path, but it remains conditional on topology and reachability.

The document’s appendix provides its sharpest failure case. Two autonomous systems can each run OSPF consistently and each border router can follow its local rules, yet equal-cost paths across their borders can produce a stable forwarding loop. The problem is not that one protocol emits obviously invalid information. It is that each system’s locally coherent picture omits enough of the multi-path context for the combined result to loop.

RFC 1745’s response is to require the relevant border routers to merge the paths available through equal-cost exits into a set before advertising. This constrains selection so that one domain stops preserving the conflicting multipath combination. The appendix says which domain loses the multiple paths is nondeterministic. That detail matters: the requirement targets the unsafe structure without pretending to dictate every downstream choice.

This early document therefore contributes a distinctive operational lesson. Correct components can compose into an incorrect forwarding result when information crosses control domains. Filters, tags, identifiers, forwarding addresses, and path aggregation are ways to preserve constraints across that boundary. They are not evidence that every implementation adopted the rules or that every network avoided the failure. The standard identifies a failure mode and a required response; only running behavior can establish what happened in a particular system.

RFC 8241: programmable control requires an authority boundary

By 2017, the problem addressed in Hares’s attributed work had shifted from exchange between routing protocols to programmatic access to routing-system state. RFC 8241, authored by Susan Hares, Daniel Migault, and Joel Halpern, presents security-related requirements for the Interface to the Routing System. I2RS permits clients to read and write information and state through agents associated with routing systems.

That capability creates a direct control surface, so the document asks not merely whether a message is syntactically valid, but who sent it, what that identity may do, how the message is protected, and how competing writers are resolved.

RFC 8241 relies on secure transport functions rather than inventing each one anew. It identifies confidentiality, data integrity, mutual peer authentication, and replay protection as required features for protected communication, with key management appropriate to the transport. It also allows identity and role information to be distributed by existing authentication, authorization, and accounting mechanisms when those mechanisms themselves use protected transport. Reuse is a design decision: build the higher-layer interface from existing management and transport capabilities, then add the routing-specific context they lack.

Identity is required on both sides. Clients and agents must each have an identity and at least one unique identifier, and the protocol must use those identifiers for mutual identification. An agent receiving a client request must confirm that the client identity is valid. A client receiving a protected message must likewise confirm the agent identifier. Crucially, RFC 8241 locates validation at message processing, not merely at the existence of a transport session. A channel can span multiple sessions or close and reopen; authorization must follow the identity associated with the action.

The document then separates identity from role. A valid client is not automatically permitted to read or write every item. Scope depends on identity and associated roles for reading, writing, or events. Role-based controls are intended to make permission manageable across groups, and they must continue to work when multiple transport connections exist between a client and agent. This is bounded authority: authentication says who is present; authorization says what that party may do.

Multi-headed control adds another boundary. Several clients may connect to one agent. Deployments should coordinate write scopes to avoid contention, but the architecture still needs a deterministic response when coordination fails. Each client identifier is associated with one priority. When clients contend for the same writable value, the higher-priority client receives permission and the other receives an error. Priority is not proof of correctness, and it does not turn one client into a universal controller. It is a conflict-resolution rule within a defined scope.

RFC 8241 also introduces an opaque secondary identifier for the application acting through a client. One client may serve several applications, so the secondary value can help trace which application initiated an action. The client is trusted to assert it, and traceability is expressly distinguished from a complete security audit trail. This is a valuable limitation. Attribution metadata can support investigation, but it is not self-validating evidence that an action was authorized, correct, or successful.

The document permits a narrowly constrained unprotected channel, but only for information explicitly marked nonconfidential and only for read or notification scopes. It cannot be used for writes or for configuring event streams. Protected transport is mandatory to implement for agents and for clients that write or configure events, and mandatory to use for those actions. The unprotected path must not contain information identifying a person. Operators may still choose protected transport for data labeled nonconfidential.

The asymmetry is deliberate. Reading public telemetry is not granted the same authority as changing routing state. Even then, integrity remains a concern: if data received without protection becomes questionable, the client should disconnect that channel. For writes, the standard requires confidentiality, integrity, practical replay prevention, suitable key control, and traceability. The requirements define the minimum security boundary around programmability; they do not certify any particular implementation or deployment as secure.

RFC 8242: temporary state, conflict, and the absence of automatic rollback

RFC 8242, authored by Jeff Haas and Susan Hares, turns “ephemeral” from an appealing label into explicit state semantics. Ephemeral state is state that does not survive a reboot of the routing device or the software handling the interface. If it must be restored, restoration should occur solely through replayed actions from the client through the agent. The document is emphatic that temporary routing state must not be copied into persistence merely because an underlying management protocol can maintain a running configuration.

This rule establishes a clean recovery boundary. After restart, the device does not silently revive control state whose authorizing context may no longer exist. The client must decide whether to replay it. That creates an operational obligation: a controller that depends on temporary state needs an inventory of desired actions and a way to reconcile them after loss. RFC 8242 states the semantics, but it does not assert that any product or operator has implemented that reconciliation.

Constraints are directional. Persistent state must not refer to ephemeral state for validation, because the referenced state may disappear. Ephemeral state may depend on operational state, including fast-changing entries, and may also refer to non-ephemeral configuration or operational state. Constraints are checked when temporary state is written; if later changes make them invalid, the agent should notify the client. The design recognizes that validity can decay after acceptance.

That distinction prevents a temporary value from becoming an invisible foundation for durable configuration. It also makes monitoring part of control. A successful write is not the end of responsibility when its prerequisites can change. Notification gives the client an opportunity to reassess, but it does not guarantee an automatic repair or a particular result.

RFC 8242 extends the priority rules for multiple clients. Data nodes must retain the client identity and may retain the effective priority at the time of writing. A collision is an error even when priority resolves it. If a higher-priority client changes a node owned by another, the original client must be notified and may need to repair its own state. For equal-priority writers, the protocol must provide a deterministic mechanism, such as first update winning, or another approach that prevents oscillation.

The key word is deterministic, not benevolent. Priority chooses a winner; it does not prove that the winning value is safer. First-writer behavior prevents endless flipping; it does not validate the first write’s intent. The standard keeps these questions separate so an operator can reason about conflict mechanics without mistaking them for policy correctness.

Local configuration participates in the same contest. RFC 8242 requires local configuration to have a priority comparable with client priorities, allowing an implementation to decide whether a local change or an ephemeral change takes precedence. This makes an often-hidden conflict visible: automated and local control are not independent planes when they touch the same state. A useful implementation must define which authority wins and how the losing party learns of the change.

The document’s treatment of rollback is equally direct. The I2RS architecture does not include multi-message atomicity and rollback mechanisms, and an implementation must not require them. Within one message containing multiple operations, an error in one operation must not stop later operations or reverse earlier ones. Across messages, error handling must not insert erroneous temporary state. This is not a recommendation to ignore recovery. It is a warning against assuming transactional semantics that the interface does not promise.

For operators, that means a multi-operation change can be partially applied. Safe use requires actions that can be assessed individually, awareness of dependencies, and an explicit compensating strategy outside the guaranteed protocol behavior. A controller should not infer that a failed later operation restored the earlier state. RFC 8242 thus makes rollback behavior explicit by defining its absence at this layer.

The document also addresses constrained resources. Subscription, tracing, remote procedure calls, and other mechanisms can consume unsustainable resources, so implementations should support prioritization or work shedding such as rate limiting. Temporary control is therefore bounded not only by identity and priority but by the device’s ability to process work. Under stress, the system may need to discard or defer lower-priority activity. Once again, this is a requirement framework, not evidence of how a particular device behaves.

Current IDR stewardship as scoped maintenance

The current IDR charter connects the historical RFC record to continuing stewardship. It identifies the working group as active and names Sue Hares, Keyur Patel, and Jeffrey Haas as chairs. Its primary objective is to develop and maintain BGP as the standard inter-domain routing protocol for IPv4 and IPv6 over the Internet. The stated scope includes message processing, transports specific to BGP, session management, the neighbor finite-state machine, path selection, attributes, next-hop resolution, capability signaling, route filtering and constraint mechanisms, route-reflector operation, restart procedures, and selected security extensions.

That list is broad, but the charter also draws boundaries. Work in adjacent areas belongs with, or must be coordinated with, other working groups. The charter says IDR is not the automatic home for every proposal involving BGP. New areas require demonstrated interest, sufficient expertise, and potentially rechartering. Specifications originating from another group’s requirements must mature in coordination with that group. The working group’s primary focus remains Standards Track BGP specifications rather than general use-case or architecture documents, subject to limited exceptions.

The charter also records a running-code constraint: protocol specifications, excluding YANG modules, follow a long-standing policy requiring at least two independent implementations before advancing to publication. That policy does not prove wide adoption or operational success. It does connect specification progress to independent implementation evidence rather than text alone.

A chair helps organize this process; a chair does not own its results. Consensus involves entities, document authors, reviewers, area leadership, implementers, and feedback from operators. The charter’s structure reinforces the same control lesson found in the RFCs: responsibilities are distributed, scopes are explicit, and advancement depends on evidence from more than one implementation.

Requirements, alternatives, and unresolved operator questions

Across the four RFCs, the recurring alternative is implicit control versus explicit control. RFC 4271 could have treated route choice as one opaque calculation; instead, it separates preference, selection, and dissemination. RFC 1745 could have assumed redistribution between BGP and OSPF; instead, it defaults to no exchange and requires filters and metadata. RFC 8241 could have treated a connected client as trusted; instead, it separates transport, identity, role, scope, and priority. RFC 8242 could have left temporary state and rollback ambiguous; instead, it defines non-persistence, collision behavior, and non-atomic operations.

Each choice has costs. Separate stages require implementations to preserve consistent external behavior and operators to understand more than a single “best route” label. Fail-closed redistribution demands deliberate configuration. Protected control channels require identity and key management. Client priorities require governance: someone must decide which clients receive which priority and how local changes compare. Non-persistent state demands replay and reconciliation logic. The standards identify these obligations without showing that every deployment accepts or fulfills them.

They also leave questions that only local evidence can answer. Which policy made a route ineligible? Which received routes were retained, and which were advertised? How does an implementation expose the conceptual information bases? When a next hop changed, did selection run as required? Which OSPF tags and filters were configured at a boundary? Were temporary writes tied to the correct identity and role? If a constraint later failed, was the client notified? After a partial multi-operation change, what compensating action occurred? Following restart, which state was deliberately replayed?

Those are operator questions, not gaps that an individual standards contributor can close remotely. Answering them requires implementation documentation, configuration, logs, current routing state, packet forwarding observations, and controlled tests. Standards records are evidence of intended behavior and responsibility boundaries. Running systems provide evidence of actual behavior.

Susan Hares’s attributed contribution is therefore best understood as work on legibility. The documents make policy inputs, state transitions, authority boundaries, and recovery assumptions easier to name and test. That is consequential without being personal control. BGP remains a distributed protocol shaped by local policy and many independent networks. IETF consensus remains collective. Implementations remain the responsibility of their authors and vendors. Network outcomes remain contingent on configuration, topology, traffic, failures, and operator action.

Sources

  1. IETF Datatracker profile for Susan Hares
  2. RFC 4271: A Border Gateway Protocol 4 (BGP-4)
  3. RFC 1745: BGP4/IDRP for IP—OSPF Interaction
  4. RFC 8241: I2RS Security-Related Requirements
  5. RFC 8242: I2RS Ephemeral State Requirements
  6. IETF Inter-Domain Routing Working Group charter writeup