Summary

  • Sander Steffann’s documented work on RIPE-501, RIPE-554 and RIPE-772 put IPv6 compatibility into the language of tenders: device functions, certification, RFC requirements and the buyer’s own choices.
  • Those documents are a practical bridge between a protocol and a purchase, but they do not impose a rule, select a vendor or show that a network has been deployed. The adoption evidence must continue through bids, tests, installation and live operation.

The checkbox arrives before the packet

There is a moment in infrastructure procurement when the future of a network is decided in language that sounds less consequential than a routing change. A public agency, university, large company or service provider is preparing to replace equipment. A tender asks vendors whether a product supports IPv6. The answer may be “yes,” but the word alone can conceal several different things: an address can be configured, a packet can be forwarded, a feature can work under a narrow condition, or the product may offer behavior comparable to its IPv4 counterpart. Those are not equivalent assurances.

The purchaser’s question is not simply whether the product bears the label. It is what the buyer expects the equipment and its support services to do, how the claim can be verified, and which requirements apply to the intended use. If the contract leaves those questions undefined, an organization may buy equipment that technically contains some IPv6 capability while remaining unable to use the functions it needs. Discovering that gap after a network has been designed around a product is more expensive than exposing it during procurement.

This is where the work associated with Sander Steffann becomes visible. He is one of the named authors of successive RIPE documents on IPv6 requirements for information and communication technology equipment. Their purpose is not to create a new IPv6 protocol or grant RIPE a power over buyers. It is to help an organization translate a broad technical goal into purchasing language. A tender can state which functions are required, distinguish mandatory from optional support, name relevant standards, accept certification where it covers the need, and leave a place for technical evaluation.

That distinction between a published document and a completed deployment is the central boundary in this story. A procurement template can change what the buyer asks before signing. It cannot, by itself, make a tender adopt the template, determine which bidder wins, configure equipment, train an operations team or prove that customer traffic uses IPv6. The documents make a stage of decision more legible; they do not make the later stages disappear.

Steffann’s public record is unusually useful for following that boundary because it connects several kinds of work. RIPE’s biography describes him as an Internet professional since 1995, a longtime participant in the RIPE community, a former Address Policy Working Group co-chair and an independent consultant in network architecture and IPv6 deployment. His contributions range from equipment guidance to operational practice. In 2024 he became a member of the RIPE NCC Executive Board. Those roles do not make him the sole author of an Internet transition.

They show how an engineer can help build a reference that buyers may use, then continue to work in communities and organizations where operational choices remain distributed.

A technical problem becomes a purchasing problem

IPv6 compatibility is often presented as a property of a protocol stack. Procurement adds a different question: can a buyer specify the property in a way that is clear enough to compare offers before the equipment arrives?

That shift matters because a network’s useful life is longer than the period in which a tender is written. A router, firewall, switch, server or customer-premises device can remain in service through several software releases and operational changes. Replacing an installed fleet is not the same as choosing a feature in a new system. If support is incomplete, operators may have to build workarounds, preserve older protocols longer than planned, or replace hardware before the end of its expected life. The purchase creates dependencies that show up later in maintenance, migration and service design.

The first version of RIPE’s “Requirements for IPv6 in ICT Equipment,” RIPE-501, was published in November 2010. The document lists Jan Žorž and Sander Steffann as authors and associates the work with the IPv6 Working Group. Its introduction frames IPv6 uptake partly as a procurement issue: governments and large enterprises should state compatibility requirements when seeking tenders for equipment and support. It draws on existing technical references and certification work rather than claiming that the RIPE community owns the underlying protocol requirements.

The timing was important. Buyers could not assume that every product description used “IPv6 support” in the same way. A generic requirement might cover basic protocol behavior but say nothing about the particular functions a purchaser needs. An organization that buys a router for one purpose may need different capabilities from a buyer selecting a host, a security device or customer-premises equipment. A tender is where those differences can be made explicit.

RIPE-501 offered more than one route for stating the requirement. The equipment-oriented profile adapted ideas from the United States government’s USGv6 work; another route used the IPv6 Ready certification program; a third combined the two. That structure matters because certification can help buyers, but a logo cannot stand in for every feature that a specific network needs. The document connected the certificate to a set of technical requirements rather than treating the certificate as a universal answer.

That first edition was itself a contribution to a longer, collective process. The official RIPE 63 minutes, held in November 2011, say that RIPE-501 had been translated into ten languages and that requests for changes had arrived. The replacement work added device types, including load balancers, and simplified compliance criteria. The minutes identify the session as “Replacing ripe-501” and list Jan Zorz and Sander Steffann together. They also record the authors thanking Merike Kaeo for substantial input.

The number of translations and the requests for revision are evidence that the document had traveled beyond its initial page. They do not show how many organizations used it in a tender or whether their equipment passed operational testing. The distinction is important because the word “success” in a standards community can refer to a document being read, discussed or improved. A buyer’s adoption of requirements and a network’s successful operation are separate events.

During that same RIPE 63 session, the group discussed a German administrative IPv6 profile. The meeting record says the federal administration was considering RIPE-501 as a basis for its own work. It also records the practical barriers described by the presenter: address space had to be coordinated across different levels of government, budgets were held by separate departments, and completion would take a long time. The case is useful precisely because it does not end with a simple success story.

It shows a document becoming a reference while implementation remains distributed across institutions that cannot be compelled by the publication of a template.

From a list to a tender mechanism

RIPE-554, published in June 2012, made the procurement mechanism more explicit. Its authors were Merike Käo, Jan Žorž and Sander Steffann. It obsoleted RIPE-501 and retained the basic project: provide a best-current-practice template that organizations can use when drafting equipment tenders.

The document says that it does not itself set standards or policy. The standards it references originate in other bodies and may change. Buyers are warned to adjust the recommendations to local needs. This is not a disclaimer appended to an otherwise binding specification. It defines how the tool is meant to work. RIPE can publish a useful reference; the organization issuing a tender decides what its network requires.

That division of authority prevents two different kinds of confusion. First, readers should not confuse a RIPE document with an IETF standard or a law. Second, they should not assume that one equipment checklist is a complete design for every organization. The standards are external, and the purchase is local. A shared document can reduce the cost of starting from scratch without deciding the buyer’s use case for them.

RIPE-554 gives a tender initiator a way to combine certification and specific RFC requirements. It explains that IPv6 Ready certification covers basic requirements and some advanced features, but not every possible need. If an organization wants a function outside the program’s coverage, it can list the technical requirements for that function as well. It can also avoid excluding equipment merely because the manufacturer has not put it through a particular certification procedure, if the product meets the requirements the buyer has named.

This is a subtle procurement design choice. A certificate can make comparison easier, but a rigid certificate-only rule can shut out a capable product whose test coverage is different. A requirements-only rule can be precise, but it may leave evaluators with an unmanageable set of claims to check. The document puts the trade-off in the tender initiator’s hands: use certification for what it verifies, then state what else the equipment must do.

The mandatory and optional lists carry the same allocation of responsibility. The equipment must meet the requirements that the buyer marks as mandatory. Optional items may be considered when the tender awards additional points. If a function is essential in one organization, the buyer can move that requirement into its required set. The vendor does not define the purchaser’s need simply by listing whatever its product already happens to support.

That choice has consequences for fairness and scope. A tender that names too little can compare bids on an inadequate baseline. A tender that names every possible feature can reduce competition or impose cost for capabilities the organization does not need. A good specification has to connect a technical requirement to an intended use. The document does not solve that judgment for the buyer; it makes the decision visible enough to debate and evaluate.

RIPE-554 also reaches beyond the physical equipment. It discusses software that communicates over IP and asks for IPv4 and IPv6 support, as well as attention to the skill of the system integrator. Those provisions recognize that equipment works inside a system. A router with a capability that the software does not use, or an installation carried out without the competence to configure the network, can leave the purchaser with a technically compliant box and an operational gap.

This is one reason a procurement clause can matter over a long period. The vendor’s initial claim is only one component of the delivered system. Software may change; standards may be revised; the buyer’s network may have security requirements or address-selection behavior that the generic word “support” does not capture. The implementation and support contract decide whether those functions survive the transition from the bid to the operating environment.

The engineering surface behind the phrase “supports IPv6”

A purchaser can state requirements only if the equipment categories are concrete enough to compare. RIPE-554 divides hardware into types, including hosts, layer-2 switches, routers and layer-3 switches, network security equipment, customer-premises equipment, mobile devices and load balancers. The document then associates technical requirements with those classes. The point is not that every product has the same specification. A device forwards, filters, hosts or translates traffic in a different way, so relevant behavior differs.

For a host, basic IPv6 connectivity is not the same as feature parity with IPv4. For a switch or router, forwarding and address-related behavior affect the network around it. For a firewall or intrusion-detection device, a missing or unevenly configured IPv6 feature can create an exposure that a buyer did not intend to accept. Customer-premises equipment has to connect end users to the provider’s network. A load balancer can influence whether application traffic gets the same treatment across protocol versions. These are different equipment roles, not interchangeable checkboxes.

The same principle applies to the standards listed in the document. The references include many RFCs and some 3GPP material, but a list alone does not tell an organization which functions it needs. Some entries are mandatory in the generic template; others are optional or depend on whether a certain capability is requested. The tender initiator has to decide what the network will require and how to compare a vendor’s response.

RIPE-554 says that the tender initiator should decide the functionality, not the equipment vendor. That statement marks a control surface. Vendors understand their product and can describe its capabilities, but a vendor’s menu is not a neutral definition of a public agency’s requirements. The buyer has to own the purpose of the purchase, translate it into testable requirements and apply the same standard to competing offers.

A contract also has to distinguish a claim from evidence. A vendor may state that a device supports a protocol. A certification program may verify a defined baseline. A tender may ask for additional RFC compliance or additional evidence for a specified function. A lab may test the actual configuration that the buyer expects. Those forms of evidence answer different questions. None automatically proves that the equipment will be configured correctly in production or remain compatible with every future feature a network may need.

The document’s use of mandatory and optional categories does not remove judgment; it gives judgment a place to live. A public buyer may need a feature for a particular service, but that does not make the feature universal. An enterprise may accept an optional function because it supports a future plan. Another purchaser may omit it to avoid paying for capability it will not use. The correct requirement depends on the network, the services and the expected operating period.

The distinction resembles a test plan. A test that verifies basic compatibility answers whether a product meets a baseline. A test that checks a security function, a transition mechanism or software behavior answers a narrower question. A procurement document can help an evaluator know what to test, but only the buyer can decide whether a given test reflects a real requirement. This is why a common template may improve comparison without standardizing every purchase.

RIPE-554’s treatment of IPv6 support in software extends the scope of the tender beyond hardware. It says that software communicating over IP should support both versions and that IPv4 features should not quietly disappear when traffic is sent over IPv6, unless a difference is intentional and useful. For a buyer, this is a reminder that protocol readiness can fail at several layers: a router may forward packets, but a management interface, application, monitoring tool or service component may not behave consistently.

System integrator skill is another dependency. A manufacturer certificate or a standards list cannot establish that a local team can design, install and troubleshoot a production network. RIPE-554 therefore includes guidance on declaring IPv6 competence for integrators. The buyer has to consider who will connect the equipment to the existing system, and whether that service provider has people who know both the technical and operational questions involved.

That detail is easy to overlook when a procurement discussion is reduced to product choice. The system integrator is part of the product’s practical outcome even if it is a separate supplier. If the tender omits installation skill, a buyer can award a compliant device and still face delays or defects during deployment. The checklist highlights the dependency; it does not guarantee that the buyer’s evaluation or later supervision will be adequate.

The template’s update problem

A procurement reference has an unusual maintenance burden. It needs enough detail to help a buyer today, but the underlying standards and equipment keep changing. If it is too broad, it can become difficult to use. If it is too narrow or too old, it can omit capabilities that buyers now expect. If it tries to resolve every technical question before publication, the document may take too long to update.

The history from RIPE-501 to RIPE-554 shows that revisability was part of the project, not an afterthought. RIPE-63’s meeting record describes requests for changes only about a year after the original document. The replacement added classes of devices and changed compliance criteria. The authors’ reminder to use the document as a template was also a warning against treating a particular edition as universally reusable without modification.

RIPE-772, the 2021 update, retains that character. It lists Merike Käo, Jan Žorž, Sander Steffann, Tim Chown and Tim Winters as authors and updates RIPE-554 and RIPE-501. Its introduction again says that the document is guidance for commercial, public-sector and research-and-education organizations. It does not set standards or policy. It warns that the technical references can age and that mandatory and optional items may need to be tuned for each use case.

A newer edition is not simply a larger catalog. RIPE-772 narrows or re-describes categories, defines scope and out-of-scope cases, and updates what a tender should ask for. Some device functions are included through one procurement channel; others are expressly excluded or deferred. The value of that boundary is not that it settles every question. It lets a buyer know when the template stops and where another reference, contract requirement or test may be needed.

The later RIPE-554bis discussion recorded at RIPE 83 shows how this maintenance works at the edge. Participants considered which RFCs belonged in the updated guidance, whether the presentation reflected the latest draft, and how far to expand the scope. A question arose about converting recommendations into automated tests. The meeting notes record that Sander did not claim certainty about every proposed technical item. In one exchange, the group discussed leaving an item for a later version to keep the current update from growing indefinitely.

That is useful evidence of restraint, but it should not be turned into a heroic anecdote. The meeting shows discussion about scope; it does not tell us that the final update settled every issue or that an automated test system was built. The broader lesson is simpler: a specification can lose practical value if it tries to promise coverage it cannot sustain. A working group has to decide what belongs in the current version, what can be tested, what should be changed later and how users should be told about the limits.

This creates a recurring tension. The equipment buyer wants a stable reference to compare offers. The technical community needs to update that reference as protocols, products and tests change. Vendors have incentives to present the most favorable interpretation of support. Engineers may want more exhaustive requirements. Public buyers also need competitive tenders and rules they can evaluate fairly. RIPE-772’s repeated emphasis on local adaptation exposes the tension rather than pretending that one global document can remove it.

What the German example says—and does not say

The German administrative profile discussed at RIPE 63 offers an early example of local reference use. Meeting minutes report that the federal administration was coordinating IPv6 address space and deployments across federal bodies and institutions. A presenter said the process would take time because the German system was complex, budgets were split across states and municipalities, and cooperation had to be persuaded rather than imposed. The minutes say RIPE-501 was being considered as a basis for the administration’s own documentation.

This is a valuable case because it puts the document in a real institutional setting while limiting what can be inferred. It shows a policy or procurement team looking at a shared technical reference while managing a decentralized structure. It does not establish that RIPE-501 caused the German plan, that the plan covered every public body, that the later deployment was finished or that IPv6 traffic increased because of the document.

That caution is more than editorial modesty. Infrastructure rollouts are multi-stage processes. An administrative profile can be written, procurement documents can be revised, a bid can meet the stated requirement, equipment can be installed, software can be configured, routes can be announced and customers can use a service. Evidence at one step does not prove the next. Meeting minutes may document a discussion or an intention; they are not a deployment database.

For that reason, the article does not treat “RIPE-501 was translated into ten languages” as proof of ten-country adoption. Nor does it treat a discussion of German use as an outcome audit. Translation shows distribution of the text; reference use shows that at least one team considered it; a completed tender and an operational network would require different evidence.

The relevant public question is not whether a document is famous within a technical community. It is whether a buyer can show where a requirement entered a procurement, how bidders were evaluated, what verification was conducted and whether the installed system delivered the required behavior. The current public sources do not provide a count of tenders using RIPE-501, RIPE-554 or RIPE-772, nor a portfolio of measured outcomes. That gap must stay visible.

From working-group chair to board member

Steffann’s biography provides context for why his work moves between engineering, practice and community process. RIPE NCC says he has been active in the RIPE community since 2004. It records almost eleven years as an Address Policy Working Group co-chair, from 2007 to 2018, and a period on the RIPE NCC Arbiters Panel. His education focused on communications topics such as protocol design, implementation and validation. Since 2010, he has advised enterprises and service providers on network architecture and IPv6 deployment.

These are different responsibilities. A working-group chair helps a community run a discussion and reach decisions under its procedures. A consultant advises a client on its own architecture or implementation. A document author contributes to text that a buyer may use. A board member serves the membership of an organization. None of those roles automatically grants authority over operators who have not chosen to act.

The distinction matters for a biography because profiles of technical figures can slide from participation to ownership. Co-authoring a document does not mean writing every rule in it. Chairing a group does not mean deciding policy without the group. Advising a client does not prove a wider market result. Board service does not make the board responsible for every outcome of community guidance.

RIPE NCC currently lists Steffann as an Executive Board member for the May 2024 to May 2027 term and as an observer at NRO Executive Council meetings. The NCC describes board members as responsible to the membership. That role places him in a formal governance setting, but it does not convert a best-current-practice document into an instruction to every member, vendor or network operator.

His biography also says that, starting in summer 2025, he worked part-time with Hilco on the ProVision team, which provides DDI software, anycast DNS and network-management services. The current profile gives readers a concrete view of his professional connection to tools used by network operators. It does not support an inference that RIPE documentation privileges a vendor or that board duties conflict with that work. Such claims would require evidence beyond a job description.

The more useful through-line is about proximity to operational choices. Steffann’s biography says he began in a small ISP, later worked on network architecture and automation, participated in IPv6 community guidance and then served in RIPE NCC governance. The connection is not a straight line of control. It is a series of roles in which implementation experience can inform shared references while the final choices stay with clients, members, purchasers and operators.

A stated test for market maturity

RIPE 73’s IPv6 Working Group minutes include a discussion of what success would look like. Steffann is recorded as agreeing that success would come when a network professional heard “IP” and assumed IPv6, and when it was no longer viable to sell products without IPv6 support. This is a statement of aspiration in a meeting, not a measured estimate of when the market would reach that condition.

It is nevertheless a useful clue to the logic behind procurement guidance. If a product without IPv6 remains viable, buyers may continue to encounter offers that meet a narrow legacy requirement but frustrate later plans. A tender is one point where a buyer can make protocol support a condition of purchase. It is a direct lever for one organization, not a global lever for the market.

The same minutes record a disagreement about the desired transition. One participant emphasized a smooth move without economic shocks; Steffann described a market in which products without IPv6 were no longer saleable as success. The minutes do not resolve that difference or measure its economic effects. It does, however, show that “success” is not one metric. Operators may prioritize a safe migration, buyers may prioritize future compatibility, vendors may prioritize market demand and users may care only that services work.

A tender template is strongest when it supports this practical diversity. A buyer can require the functions it will actually need; it need not turn a broad vision into an all-or-nothing directive. If an organization can specify mandatory features, accept equivalent verification for capable devices and test those features in its own environment, it can make progress without claiming that every network has to change on the same schedule.

The evidence ladder after the tender

The document’s impact should be evaluated through a ladder of evidence. The first rung is publication: a current, intelligible technical reference exists. The second is uptake: an organization cites or adapts the reference in a tender or procurement rule. The third is bid evaluation: vendors provide evidence, and the buyer applies the same criteria to each offer. The fourth is acceptance: the selected product passes technical and operational tests in the buyer’s environment. The fifth is deployment: the required functions are configured and placed into service.

The last is outcome: users, network operators and services experience the intended behavior.

Each rung can fail independently. A document can exist without being used. A tender can cite it but reproduce a generic template without matching local needs. A bid can claim compliance while a test reveals a gap. Equipment can pass a lab test but fail during integration. A deployed device can have IPv6 enabled but be bypassed by software or traffic patterns that remain on IPv4. None of these possibilities is an argument against procurement guidance. They are reasons to collect evidence at each stage.

This is where RIPE-554 and RIPE-772’s own warnings are useful. They tell the tender initiator to adjust the template, distinguish mandatory and optional needs, combine certification with selected RFCs and consider integrator skill. They also remind the reader that referenced standards come from separate bodies and can change. That structure directs the buyer toward a process rather than a single badge.

The word “test” in this article’s title is therefore literal. A procurement test asks whether the tender requires the right functions, whether the evidence offered covers them, and whether the product works in the network that will use it. It is not a claim that a purchase document is a full compliance audit or proof of successful deployment.

A useful operational report would connect the versions of the tender to the installed equipment and actual network behavior. It might show how many bids were evaluated, which criteria were mandatory, what certification covered, where an RFC requirement was added, which devices passed acceptance tests and whether the IPv6 functions were enabled in production. It could also show what happened when firmware, monitoring tools or vendor support changed. The source set used here does not contain that report, so this article does not invent its findings.

The point at which a shared reference stops

There is a temptation to treat a widely cited document as an authority simply because organizations recognize its title. RIPE-772 resists that interpretation in its own introduction: it is a BCP for tender processes, not a policy that binds buyers. It offers a starting point that organizations can adapt. The decision is localized to a purchasing body and its operational needs.

That design has both a strength and a cost. The strength is flexibility: a university network, a public agency and an ISP do not need identical optional features. Buyers can choose the relevant device classes and adjust the mandatory list. The cost is variation: one organization may require a capability that another leaves optional; one may test in a lab, another may rely on vendor evidence; one may update its template promptly, another may keep an old version. A shared reference can make differences more intelligible, but it does not erase them.

The document’s authorship also sits inside a larger standards ecosystem. RIPE’s role is to convene its community and publish RIPE documents. The RFCs referenced in the equipment guidance come from technical work in bodies such as the IETF, while IPv6 Ready certification has its own program and test procedures. A purchaser then applies the requirements under its own legal and organizational setting. Treating all of these as a single chain of command would misstate the actual control structure.

The buyer’s discretion creates a responsibility, not a free pass. A local tender should be traceable to a real requirement. If a buyer selects a mandatory test, it should know what that test covers. If it accepts a certificate, it should understand the scope. If it allows equivalent RFC compliance, it needs a way to evaluate that evidence. If it leaves a feature optional, it should be prepared for the possibility that the selected product does not have it. The template makes those choices easier to express; it does not make them harmless.

For the standards community, the corresponding responsibility is to maintain the reference and be candid about its scope. A document that presents itself as a universal compliance label invites overreliance. A document that gives a buyer device categories, external references, optional paths and explicit limits is more useful, but still requires judgment. RIPE-83’s debate over the 554bis perimeter demonstrates why a finite update cannot anticipate every feature, test environment or future change.

What can be said about Steffann’s contribution

The evidence supports a bounded account. Sander Steffann is one of several named authors of successive RIPE equipment guidance. He appeared with Jan Žorž in the RIPE 63 record about replacing RIPE-501, participated in a community whose documents are reviewed and revised, and later appeared in RIPE-83 minutes as a co-author during discussion of the updated guidance. His public biography connects that work to professional experience in network architecture and IPv6 consulting. He has also held community and governance roles.

The evidence does not establish that he personally wrote every part of the documents, that he persuaded a particular government to procure a particular product, or that the guidance changed IPv6 deployment rates. The RIPE-63 German example shows a reference being considered within a complex, long-running public-sector process; it does not show completion. The translations and revision requests show circulation and community engagement, not measured deployment. The RIPE-73 statement shows his public criterion for eventual success, not that the criterion was achieved.

That restraint does not diminish the work. It describes the actual lever. An engineer can help make a technical capability easier to demand, compare and verify without controlling the buyer, vendor or network operator. In a distributed Internet, that is a meaningful contribution precisely because it avoids claiming an authority the document does not have.

The procurement guidance helps define the space between an abstract protocol and an installed system. It can put questions on the record before a long-lived purchase is made: what does the device need to do, which evidence counts, what will be tested, who will install it, and how will the buyer handle functions that certification does not cover? The work also keeps the answer open to revision as products and standards change.

A procurement document is the beginning of the audit

A buyer who cites RIPE-501, RIPE-554 or RIPE-772 has taken a step, not reported an outcome. The next evidence should come from the tender, the bidders, the acceptance test and the network. Without those records, no one can tell whether the reference altered an award, excluded a device, improved software parity, shortened later migration or changed traffic on the live network.

This distinction is especially important when equipment is bought for a long horizon. A decision that appears economical at award can create costs later if software support ends, if IPv6 functions are incomplete, if the integrator cannot configure them or if the network has to be renumbered. At the same time, a requirement that exceeds the buyer’s needs can raise purchase cost, narrow the bidder pool or delay an otherwise useful upgrade. Neither risk can be evaluated by the presence of an IPv6 checkbox alone.

Steffann’s contribution is best understood as helping purchasers move one question earlier. Instead of waiting for a live network to reveal that a device cannot do what the organization expected, the buyer can state the expected function before the bid, ask for evidence and set an acceptance test. The decision remains with that buyer. The RFCs remain maintained by their standards bodies. The equipment remains the vendor’s product. The network still has to be operated.

This is also why the document must remain a template. If a buyer treats it as a fixed legal specification, it may carry requirements that do not match the local network or exclude an equivalent product. If a vendor treats it as a certificate, it may confuse a general baseline with a full feature test. If a journalist treats publication as adoption, the account overstates what happened. The official documents themselves warn about changing standards and local tuning.

The more durable achievement is not an instruction that every organization must follow. It is a reusable way to frame a purchase so that technical claims can be compared before the equipment becomes part of the network. Steffann’s work sits in that earlier stage, where standards vocabulary becomes a buyer’s question and a buyer’s question can become a contract term.

Whether that term led to functioning IPv6 remains a matter for procurement and operational evidence. The sources document the guidance, its revisions and its intended use. They do not show the resulting fleet, its configuration or its traffic. The next useful report would join those records rather than infer a network from a document.

Sources