Summary

  • RFC 5381 used WSDL and Apache Axis to generate NETCONF/SOAP client stubs and server skeletons, reducing development work without eliminating implementation or authority decisions.
  • The implementation copied NETCONF session identity into an HTTP cookie and therefore formed a self-consistent pair that the document explicitly says did not interoperate with RFC 4743-conformant implementations.

The successful build that proves too little

Picture the most persuasive demonstration in a development review. A WSDL file enters a generator. Client classes appear. Server skeletons appear. Both compile. Tomcat exposes the service. The client sends a SOAP envelope and receives a reply. Every tool in the chain reports success.

It is tempting to call that interoperability. RFC 5381 makes the opposite case by example.

The 2008 Informational RFC records how a network management system and network equipment were built around NETCONF over SOAP. Apache Axis generated Java interfaces from WSDL and XML Schema. Engineers could call methods corresponding to hello, get-config or edit-config without writing SOAP envelopes by hand. On the server, the same description generated skeleton code to be completed with device functions.

That shared machinery created syntactic agreement. It did not settle the governing session contract. RFC 4743 tied a NETCONF session over HTTP to the persistent transport connection. The implementation in RFC 5381 instead copied the NETCONF session identifier into an HTTP cookie and sent it with later requests. The client and server understood each other because both implemented the same private choice. The RFC says plainly that this alternative binding did not interoperate with an RFC 4743-conformant implementation.

Two sides compiled. Both ran. Neither fact proved the public contract.

A generator compresses syntax, not responsibility

WSDL is useful precisely because it turns an interface description into programming artifacts. RFC 5381 explains how WSDL2Java could produce classes such as NetconfBindingStub.java, Hello.java, GetConfigType.java and EditConfigType.java. The application developer could work through Java methods rather than directly constructing XML and SOAP messages.

But the description was not a complete service. The RFC notes that netconf-soap_1.0.wsdl lacked a service element, so another description supplied the endpoint. Device data models still had to be expressed as XML Schema. Server skeletons were templates; actual NETCONF functions still had to be added. A build could therefore succeed while the management behavior remained incomplete.

This is the first receipt boundary. A generator can prove that it consumed an input and emitted artifacts. A compiler can prove that those artifacts satisfy a language and type system. A deployment tool can prove that classes reached a container. None of those receipts establishes that the interface matches the normative contract, that the server authorizes an operation, or that a device applied it.

The more fluent the generated API looks, the easier it becomes to forget those later questions. A method named editConfig() feels local and typed. The underlying action still crosses a transport, a SOAP parser, a session boundary, a NETCONF capability surface, an authorization decision, a datastore transaction and a device-realization step.

One session, two possible owners

The cookie choice is the central evidence. HTTP is stateless at the message level, while NETCONF needs a session. RFC 4743 treated the persistent connection as the state carrier. RFC 5381’s implementation used a value in both the NETCONF <session> element and an HTTP cookie to correlate subsequent requests.

Within the pair, that could be orderly. The equipment allocated the identifier after hello; the NMS stored it; later requests repeated it; close-session triggered deletion. Yet the implementation had introduced a second ledger of session truth. Was a request part of the session because it arrived on the original transport connection, because it carried the cookie, because the XML element matched, or because all three agreed?

That is not a pedantic question. Reconnects, proxies, load balancers, cookie replay, parallel requests and failover can separate those signals. A private rule may choose one of them. A conformant peer may choose another. Each side can be internally coherent and mutually unintelligible.

An operator therefore needs more than a session ID in a log. The receipt must identify the transport instance, authenticated peer, NETCONF session, cookie provenance, capability exchange, request sequence and closure event. Otherwise the same identifier can become a reassuring label detached from the state it supposedly names.

Reachable was not implemented

RFC 5381 contrasts top-down and bottom-up Web Services development. Starting from an agreed WSDL supports interoperability because every implementation targets the same description. Starting from source code and generating WSDL is faster, but can encode vendor-specific choices.

Even the stronger top-down path stops short of outcome. A generated server skeleton can be deployed into Axis and Tomcat. At that point the endpoint becomes accessible. The RFC still says that the service functions must be added to the skeleton. Accessibility proves that a container can route a request to code. It does not prove that the code implements NETCONF semantics.

The constrained-device path makes the layers clearer. Equipment without enough memory for a Java stack might use an HTTP daemon, a smaller SOAP module and a NETCONF service provider written in C. The SOAP module removes the envelope and hands the NETCONF message onward. The service provider parses the management request and configures the equipment. These are separate stages because each can succeed while the next fails.

A useful operational chain is therefore: endpoint reachable; TLS peer authenticated; SOAP envelope accepted; NETCONF hello and capabilities agreed; session correlated; RPC parsed; authorization granted; datastore changed; commit completed; device realized the configuration; independent observation confirmed the intended effect. “HTTP 200” sits near the beginning, not the end.

TLS protects a channel, not a mandate

The RFC carries forward the security considerations of RFC 4741 and RFC 4743. For SOAP, it calls for authentication and encryption through TLS: NETCONF/SOAP/HTTPS. That is essential evidence about the channel.

It is not authorization evidence for a specific configuration change. A valid certificate can identify the peer without proving that the peer may edit a routing policy. Encryption can protect an RPC without proving that its target datastore is correct. Integrity can show that a reply was not altered without proving that the device reached the intended forwarding state.

The IESG note adds another boundary: at the time, a NETCONF implementation supporting only this SOAP transport and not at least SSH was not standards-compliant. A secure SOAP channel could exist and still leave the implementation outside the required NETCONF transport profile.

Security controls need the same discipline as code-generation receipts. Record what they authorize and protect; do not let them inherit the claims of later layers.

The registry changed, the evidence did not vanish

RFC 6241 later replaced the original NETCONF base specification, and RFC 6242 described the updated SSH transport. RFC 9900 eventually made RFC 4743 and RFC 4744 Historic and released their assigned ports while retaining historical service names. Those lifecycle decisions matter, but they do not retroactively erase private binaries, generated classes, copied WSDL files, firewall objects or lab configurations.

The existing BTW analysis of RFC 9900 owns that registry-versus-local-retirement problem. RFC 5381 contributes a different lesson: an implementation can leave durable artifacts of a contract fork even when its endpoint and registry assignment disappear. A WSDL digest, generator version, cookie rule or compiled stub may be the only surviving evidence explaining why one peer once worked and another did not.

Heng Lu’s running-code discipline asks what the deployed system actually did. Here the answer cannot be inferred from the description file alone. The interface document was an input. The generator was a transformer. The cookie rule was a local policy. The server code held device authority. The device state and observed network behavior were later outcomes.

The governing object is not “the SOAP service.” It is the complete chain and the authority boundary between every link.

Sources