Hi Scott, On Tue, Feb 3, 2026, at 23:10, Hollenbeck, Scott wrote: > If those two commands aren't processed in that specified order, the > "remove name server C" command will fail if it gets processed first > because C isn't part of the existing set.
In HTTP-land, we have the same issue often. The way this is managed is at the application layer. You don't pipeline those requests and rely on pipeline ordering. Instead, you issue the first request, wait for a reply, then issue the second. (Or, in this case, you don't issue either request, because the end result should be net nothing.) Obviously, pipelining can make some operations more latency efficient, but I get the distinct sense that EPP isn't really optimized for latency. Robustness seems to be far more important. Maybe it is the specifics of this example that are in the way. Are there more generally cases where one command sets up state that subsequent commands rely on? Like the creation of a name server that you then assume is present in subsequent commands? And you really need those commands to be pipelined, if not for performance, at least because this is common practice in existing implementations. If that is the case, having multiple commands per stream is (very) well justified. That would be the justification I use for the design, to the point of saying that, rather than saying "commands must be ordered" without explanation.
