Original text:
The following list provides an abstract description of the flow depicted in enrollfigure. <del> CA Certs Request: The pledge optionally requests the latest </del>  relevant CA certificates.  This ensures that the pledge has the complete set of current CA certificates beyond the pinned-domain- cert (which is contained in the voucher and may be just the domain registrar certificate). <del> CA Certs Response: It MUST contain the current root CA </del>  certificate, which typically is the LDevID trust anchor, and any additional certificates that the pledge may need to validate certificates. <del> Attribute Request: Typically, the automated bootstrapping occurs without local administrative configuration of the pledge. </del>  Nevertheless, there are cases in which the pledge may also include additional attributes specific to the target domain into the certification request.  To get these attributes in advance, the attribute request can be used. <del> Attribute Response: It MUST contain the attributes to be included in the subsequent certification request. </del>  <del> Certificate Request: This certification request MUST contain the authenticated self-contained object ensuring both proof-of- </del>  possession of the corresponding private key and proof-of-identity of the requester. <del> Certificate Response: The certification response message MUST </del>  contain on success the requested certificate and MAY include further information, like certificates of intermediate CAs. <del> Certificate Confirm: An optional confirmation sent after the </del>  requested certificate has been received and validated.  It contains a positive or negative confirmation by the pledge whether the certificate was successfully enrolled and fits its needs. <del> PKI/Registrar Confirm: An acknowledgment by the PKI or registrar that MUST be sent on reception of the Cert Confirm. </del>  The generic messages described above may be implemented using various enrollment protocols supporting authenticated self-contained objects,

Reviewer comments:
This is mostly typos and rewording, plus converting some diagrams so that aasvg can do a better job.
Thank you for improvements. I will merge them now and then place some fixups.

Revised text:
The following list provides an abstract description of the flow depicted in enrollfigure.  <ins> CA Certs Request [1]: The pledge optionally requests the latest </ins> relevant CA certificates.  This ensures that the pledge has the complete set of current CA certificates beyond the pinned-domain- cert (which is contained in the voucher and may be just the domain registrar certificate).  <ins> CA Certs Response [2]: It MUST contain the current root CA </ins> certificate, which typically is the LDevID trust anchor, and any additional certificates that the pledge may need to validate certificates.  <ins> Attribute Request [3]: Typically, the automated bootstrapping occurs without local administrative configuration of the pledge. </ins> Nevertheless, there are cases in which the pledge may also include additional attributes specific to the target domain into the certification request.  To get these attributes in advance, the attribute request can be used.  <ins> Attribute Response [4]: It MUST contain the attributes to be included in the subsequent certification request. </ins>  <ins> Certificate Request [5]: This certification request MUST contain the authenticated self-contained object ensuring both proof-of- </ins> possession of the corresponding private key and proof-of-identity of the requester.  <ins> Certificate Response [6]: The certification response message MUST </ins> contain on success the requested certificate and MAY include further information, like certificates of intermediate CAs.  <ins> Certificate Confirm [7]: An optional confirmation sent after the </ins> requested certificate has been received and validated.  It contains a positive or negative confirmation by the pledge whether the certificate was successfully enrolled and fits its needs.  <ins> PKI/Registrar Confirm [8]: An acknowledgment by the PKI or registrar that MUST be sent on reception of the Cert Confirm. </ins> The generic messages described above may be implemented using various enrollment protocols supporting authenticated self-contained objects,