You have a good number of uses of "SHOULD". It is generally considered
good documentation to explain the circumstances under which an
implementation might vary from a "SHOULD". If you can't think of one,
then you probably have a "MUST".
For example, in 4.1, you have
Proxies SHOULD
choose an error type that best captures the connection failure.
...and I find it amusing to consider "but a proxy MAY send a different
error type if it wishes to cause chaos and confusion."
And in 4.1
Proxies must check that client requests are correctly encoded
the request must additionally contain
"targethost" and "targetpath" variables
Given how you use "MUST" elsewhere, I think these should also be "MUST".
I think you have done a good job at balancing MAY/may, but in
Target servers may
throttle processing requests if such an event occurs.
...and...
Proxies may throttle specific clients in response to these
errors.
...and...
Malicious Targets or Proxies may send bogus answers in response to
Oblivious DoH queries.
...that is probably MAY.
In all cases of "MAY" it is customary to give some motivation for choosing to do or not do the action.
You have a good number of uses of "SHOULD". It is generally considered good documentation to explain the circumstances under which an implementation might vary from a "SHOULD". If you can't think of one, then you probably have a "MUST".
For example, in 4.1, you have
And in 4.1
I think you have done a good job at balancing MAY/may, but in