This is the ARTART review for draft-ietf-acme-integrations-12.  

The document is ready with nits.

When reading the review keep in mind that your reviewer has limited
experience with ACME and none with EST, BRKSI, or TEAP.

In each of the four examples, I gather that the servers are already
configured to handle subdomains of example.com, per the second para of
7.5 that says it's an error if a client asks for anything else. This
is likely obvious if you know about EST, BRKSI, and TEAP, but it would
be a kindness to us newbies to note it perhaps just before section 3.

In the four examples, EAP and TEAP have pre-authorization as the first
step, while the two BRSKI ones just say it's complete. It's not clear
whether there's something different about BRKSI pre-auth. If there is,
it would be nice to note why, if not, perhaps the TEAP one could take
it out and say the first step is complete as the BRSKI ones do.  Other
than that, the diagrams are quite clear even though they are long.

In the Security Considerations, it says that it is expected that the
registrar wil use RFC 3007 updates to put records into the DNS. In my
admittedly limited ACME experience, it's more common to use a local
API to talk to whatever is managing the DNS. (I rolled my own API for
my own DNS toaster and acme.sh, because I could.) Is it really limited
to RFC 3007 updates? If not, you might want to reword it more
generally to say it's going to use something to update the DNS, and if
the credentials leak, that would be bad. 

I agree with the advice to limit the name scope of updates, and if
possible the RRTYPEs. My API only lets the ACME client update CAA and
TXT records since that's all ACME needs.