A customer asks why your firewall, email service or VPN configuration follows a particular rule. You find the answer in a vendor guide, then discover that the guide points to an RFC. For a junior engineer, RFC can look like another acronym to memorise. For an MSP, it's something more useful: a durable, vendor-neutral reference for explaining how Internet protocols are expected to work.

Once you understand what are RFCs, you can read them without treating every document as law, distinguish mature standards from proposals, and cite the right section in a customer report. That helps technical teams make decisions that remain understandable after a product changes, a supplier leaves, or an auditor asks for evidence.

What an RFC Is

RFC 5246 may look like a vendor note when it appears in a security advisory. It is the full technical specification for TLS 1.2, including protocol behaviour, message formats and security requirements. A vendor may point to it, but the RFC itself is vendor-neutral.

An RFC, or Request for Comments, is a numbered technical document published through the RFC Series. The name reflects the series' original purpose: circulate an idea, invite technical review, expose problems and allow improvements. The wording is collaborative, yet a published RFC can define the protocol rules that let independently built systems interoperate.

RFCs are publicly available through the RFC Editor, rather than being restricted to a supplier portal. The series historically used plain ASCII text so engineers could exchange documents across different systems. Current RFCs also appear in modern web formats, while retaining the same practical role: a stable public reference for a protocol or technical recommendation, not proprietary product documentation.

The distinctions that prevent confusion

An RFC is not automatically an Internet Standard. RFC 1796 identifies Informational, Experimental, Standards Track or Historic categories, and the RFC number identifies the document rather than its status. An Internet Standard keeps its RFC number. Its separate STD number does not replace that RFC on a one-to-one basis, as the RFC Index shows.

An Internet-Draft is still under development. It can change, expire or never become an RFC. An IEEE standard follows a different organisation and publication process. A vendor white paper describes a supplier's product, design or recommendation. An RFC records protocol behaviour or technical guidance for inspection by the wider Internet engineering community.

Pay close attention to normative terms such as MUST, SHOULD and MAY. They signal whether an implementation is required to follow a rule, expected to follow it unless it has a documented reason, or permitted to choose. This gives engineers precise language for configuration reviews and security decisions.

For that reason, cite “RFC 5246, Section Y”, not only a hyperlink. The number provides a stable identity, and the section directs the reader to the exact requirement or explanation.

How the RFC Series Began

In April 1969, Steve Crocker published RFC 1, starting a document series that would become central to Internet standards work. The original format was intentionally modest. An author circulated a technical memo, rather than issuing a command, and invited peers to review the idea.

That method matched a research environment in which protocols were still being tested and revised. Each document could preserve an idea, expose its assumptions and give engineers something specific to discuss. Over time, the series developed from project notes into a formal publication system connected with the IETF, ISOC and IRTF streams.

The RFC archive is a numbered historical record. The live IETF index changes as documents are published, so its current total should be checked directly through the IETF RFC process. RFC 8700 records the 50-year milestone of the series in 2019. A published RFC keeps its number even when a later document replaces it, allowing engineers to trace both earlier decisions and current specifications.

UK participation in the RFC tradition

The RFC story includes contributions from outside the United States. University College London-authored RFC 1137 and RFC 1138, published in December 1989, discussed the UK Academic Community and the relationship between Internet email protocols and UK academic systems. This illustrates how the series gave researchers in different institutions a shared place to document practical interoperability work.

RFC 1166, published in July 1990, listed UK-linked network identifiers such as BATH-AC-UK and UKCITY-NET (UK RFC history and network listings). These entries connect the founding idea of an open technical memo with real networks joining the emerging Internet.

For a UK service provider, that history has a practical lesson. RFCs provide a common reference when separate organisations exchange traffic, authenticate messages or interpret protocol behaviour. They also give engineers a defensible basis for documenting a security decision, because the relevant requirement can be tied to a public technical record rather than to a vendor's private implementation guidance.

How an RFC Becomes a Standard

An RFC usually begins as an Internet-Draft, where an author or group sets out a technical proposal. The draft is open to review and can change substantially. If the subject fits an IETF working group, that group may refine the document, test its assumptions and decide whether it should progress.

The typical path contains several distinct checks:

1. Working group development brings the proposal into a forum where engineers discuss design choices and implementation concerns.
2. IETF Last Call opens the work to wider community review, so people outside the immediate working group can raise technical or architectural objections.
3. IESG review assesses whether the document is ready for publication within the relevant IETF stream.
4. RFC Editor review handles editorial preparation, consistency checks and publication work.
5. Publication gives the document its permanent RFC number and places it in the archive.

The process relies on rough consensus and running code, rather than a simple vote. “Rough consensus” doesn't mean that every participant agrees with every sentence. It means the community has worked through significant objections and reached a position that can support interoperability. Running code matters because an elegant specification that cannot be implemented reliably isn't a useful Internet protocol.

Reading the requirement language

RFC 2119 defines the familiar requirement vocabulary. RFC 8174 clarifies how those terms are interpreted when they appear in the specified form. The key terms include:

• MUST means a requirement for conformance. An implementation that fails to meet it isn't following the specified protocol behaviour.
• SHOULD means a strong recommendation. There may be a valid reason to depart from it, but the implementer needs to understand and document that reason.
• MAY identifies an optional behaviour. Supporting it can improve capability, but the protocol doesn't require every implementation to do so.

The NCSC discussion of RFC indicators of compromise highlights the formal requirement language and the many revision cycles involved in RFC publication. For an engineer, this is more useful than treating an RFC as narrative guidance. Map each operational decision to the relevant keyword, then record any exception and its security impact.

A draft's Datatracker record also preserves useful traceability. You can follow versions, discussions and publication progress instead of relying on a copied document in a shared folder. For security teams that need to justify a change later, that history provides context around how the specification reached its published form.

For a practical comparison between technical standards and security frameworks, the GoSafe Dark Web monitoring NIST guide provides useful additional context.

RFC Status Types and What They Mean

The status on an RFC's front page tells you how to treat the document. It answers an important implementation question: is this defining a required protocol, documenting advice, recording an experiment, or preserving history?

Standards Track documents

The Standards Track category can include Proposed Standard, Draft Standard and Internet Standard stages. These labels help an engineer judge how established a protocol specification is, but they don't replace reading the document's current relationships. A later RFC may update the behaviour, clarify a requirement or obsolete an earlier version.

A status such as Internet Standard signals a mature protocol specification, but implementation still requires attention to scope, security considerations and updates. “RFC compliant” is incomplete without the RFC number, status and relevant version relationships.

Informational and Experimental documents

An Informational RFC can be valuable without defining mandatory interoperability rules. It may record background, operational practice or advice that helps engineers design a service. RFC 9325, for example, provides guidance related to QUIC and TLS rather than functioning as a universal substitute for every protocol specification.

Experimental RFCs document ideas that need practical testing. Congestion-control variants are a useful example. An engineer may evaluate such a document in a controlled design, but shouldn't assume that an Experimental status makes the mechanism suitable for every production environment.

Historic documents

Historic status tells you that the document belongs to the archive rather than the current implementation path. RFC 6949 is an example of a Historic RFC. A supplier that presents support for a Historic document as evidence of modern protocol maturity deserves careful questioning. The document may still help explain legacy behaviour, but it isn't automatically the right target for a new deployment.

The RFC index includes each entry's issue date, status, DOI and relationships such as obsoletes, obsoleted by, updates and updated by. Use those fields before approving a design. The number alone can't tell you whether the text is current or whether another RFC has changed its meaning.

How to Read and Reference an RFC

Start with the front matter, not the first technical paragraph. The opening pages normally identify the document, publication date, authors, status of the memo, intellectual property information and any important notices. This material tells you what kind of authority the document has and how the publisher expects readers to interpret it.

Next, read the abstract and table of contents. The abstract gives you the scope in compact form. The contents show whether the RFC covers protocol syntax, operational guidance, security considerations, implementation requirements or appendices that contain important detail.

A published RFC's header also contains the relationship information you need to check currency:

• Obsoletes identifies an earlier document this RFC replaces.
• Obsoleted by points to a later document that replaces this one.
• Updates shows that this RFC changes or clarifies another document.
• Updated by identifies a later RFC that modifies the original text.

These lines form a version graph. Don't copy an RFC into a customer report without checking that graph first.

Following a citation chain

JSON provides a useful reading exercise. RFC 8259 is the current reference point in the chain described here. Its references lead back through RFC 7159 and RFC 4627, allowing you to see how the specification developed and which earlier assumptions the later text retained or changed.

Don't read every referenced document immediately. Follow a citation when:

• The requirement appears ambiguous: Read the cited definition or earlier protocol rule.
• The document is being updated: Open the newer RFC and compare the affected section.
• An implementation disagrees: Check whether an erratum or later update changes the interpretation.
• A customer needs evidence: Record the exact RFC and section, not just the topic name.

The RFC Editor provides an errata system, and an erratum can identify a correction to published text. Treat that correction as something to investigate, not as permission to rewrite the original document. In a report, write the reference in a form such as RFC 8259, Section Y, then note any relevant update or verified erratum.

For day-to-day work, use the RFC Editor and IETF Datatracker rather than an old PDF attached to an email. The live index exposes publication relationships and status fields, which reduces the risk of implementing an obsolete interpretation.

Why RFCs Matter for Networking and Security

RFCs connect a customer-facing service to the technical rules underneath it. A network diagram may show DNS, HTTP, IPv6 and email, but an RFC gives the engineer a stable place to verify what those systems are expected to do.

Examples include RFC 1034 and RFC 1035 for DNS, RFC 8484 for DNS over HTTPS, RFC 8200 for IPv6, and RFC 9110 for HTTP semantics. Email authentication also has defined references, including RFC 6376 for DKIM, RFC 7489 for DMARC and RFC 7208 for SPF. These numbers don't replace configuration testing, vendor documentation or risk assessment. They provide the protocol baseline against which those activities can be checked.

From protocol text to operational evidence

Suppose an MSP is documenting why a firewall policy handles TCP traffic in a particular way. A reference to RFC 9293, the TCP specification, gives the reader a standards-level starting point. A blog post may offer a useful explanation, but it doesn't carry the same role as the protocol document that defines the relevant behaviour.

The distinction matters when suppliers use different terminology or expose different settings. A vendor may call a control “strict mode”, while another calls it “protocol validation”. The RFC reference helps the MSP ask what each product supports and whether the implementation meets the required behaviour.

Practical rule: Use vendor documentation to learn how a product implements a protocol. Use the relevant RFC to verify what interoperability and conformance require.

For UK providers working with regulated customers, this creates an auditable trail. A security decision can name the protocol, RFC and section, then add the local risk assessment, test evidence and exception rationale. That record remains useful after personnel changes or supplier churn because it doesn't depend on one engineer's memory of a product interface.

Security advisories often cite RFCs when the issue concerns protocol-level behaviour rather than a single vendor defect. Engineers can therefore connect a mitigation to the underlying standard, test the affected behaviour and explain the result in language a customer's technical reviewer can follow.

For related background on encrypted connections and remote access, see GoSafe's VPN guide for MSPs. The broader lesson is simple: RFCs let service providers separate protocol requirements from product claims, which makes security decisions easier to review and defend.

Turning RFC Knowledge into Customer Value

An MSP is writing a security policy for a customer. The phrase “we follow best practice” sounds reasonable, but an auditor may ask which practice, defined by whom, and how the team verifies it. Replacing vague language with a precise RFC citation gives the policy a firmer technical foundation without pretending that one document solves the whole risk question.

Consider an outbound email discussion. The MSP can reference RFC 7208 when explaining SPF, then describe how the customer's controls reduce the chance of unauthorised systems sending mail that appears to come from the organisation. The citation doesn't promise perfect protection. It shows that the explanation is based on the protocol definition rather than the MSP's preferred product setting.

A proposal involving transport security can cite RFC 8446 for TLS 1.3 when recommending the removal of older cipher suites. The customer still needs compatibility testing, application review and a documented exception process. The RFC supplies the technical reference for the protocol version under discussion.

A SIEM integration offers another example. If the scope includes Syslog transport, RFC 7011 gives the project team a precise reference for the protocol being considered. That helps the MSP define what the integration must receive, what the customer needs to test and where a product's marketing description leaves unanswered questions.

Making the reference useful in conversation

RFC numbers work as shorthand for a disciplined position: this is how the protocol is defined, and here is the section we used. In an incident report, that can make the difference between “the system was configured incorrectly” and a clear explanation of the expected behaviour, observed deviation and corrective action.

The same discipline supports service packaging. A provider that documents its standards, reviews updates and explains exceptions can make its technical work easier for customers to understand. It can also support wider offers designed to reduce churn with managed security by showing ongoing, evidence-based value rather than a one-off installation.

For MSPs, telecom providers, hosting companies, web agencies and technology resellers, this creates a credible base for white label security services and recurring revenue security services. The RFC provides the neutral technical reference. The service provider adds the customer relationship, monitoring process, response guidance and commercial model.

The practical next step is to choose one customer-facing service, identify the relevant RFCs, verify their status and record the sections your team relies on. That small habit improves proposals, change records and incident reports without requiring customers to become protocol specialists.

GoSafe Dark Web monitoring gives service providers continuous scanning for compromised email addresses, exposed passwords and breached domains, with clear alerts that business users can understand. Visit GoSafe Dark Web monitoring to explore a white-label service you can offer under your own brand and connect with your existing recurring services.