Original text:
6.  This section map the requirements to support proof of possession and proof of identity to selected existing enrollment protocols.  Note that that the work in the ACE WG described in I-D.selander-ace-coap- underlying TLS using OSCORE resulting in an authenticated self- contained object. <del> 6.1. </del>  When using EST RFC7030, the following constraints should be considered: [RFC Editor: please delete] /* TBD: clarification of retry for fullcmc is necessary as not specified in the context of EST */ <del> 6.2. </del>  Instead of using CMP RFC4210, this specification refers to the lightweight CMP profile I-D.ietf-lamps-lightweight-cmp-profile, as it as specified in section 5.2.4 of I-D.ietf-lamps-lightweight-cmp- profile with delayed enrollment. <del> 7. </del>  This document requires the following IANA actions: included for the defined namespaces in addressing and discovery_eo . */ <del> 8. </del>  The credential used by the registrar-agent to sign the data for the pledge in case of the pledge-initiator-mode should not contain technician operating the device, to avoid revealing this information to the MASA. <del> 9. </del>  <del> 9.1. </del>  Exhaustion attack on pledge based on DoS attack (connection establishment, etc.) <del> 9.2. </del>  Registrar-agent that uses acquired voucher and enrollment response for domain 1 in domain 2: can be detected in Voucher Request IDevID.  Alternatively, the LDevID may be acquired by a service technician after authentication against the issuing CA. <del> 10. </del>  We would like to thank the various reviewers for their input, in particular Brian E.  Carpenter, Michael Richardson, Giorgio

Reviewer comments:
Do we augment 8995? Do we augment 8366? Do we need to do both? What does it mean to augment something that augments something?
Hi, I'm working on that pull request right now. . I don't know how to manage YANG stuff in a bare MT / XML Makefile. We extend 8995 for the voucher-request. There are some practical YANG practices that I'm missing.
I enhanced the voucher-request with two additional leafs for the agent-sign-cert and the agent-provided-proximity-certificate.
YANG module for the extension of the voucher request will be put into the next update of the draft. The will need more investigation by the YANG doctor.
I guess this is fine as far as it goes, but I will admit to being nervous about augmenting a voucher-request (because it in itself is a voucher), but beyond that we also have to add a new assertion enumeration.

Revised text:
6. <ins> The following modules extends the RFC8995 Voucher Request to include a signed artifact from the registrar agent. 7. </ins> This section map the requirements to support proof of possession and proof of identity to selected existing enrollment protocols.  Note that that the work in the ACE WG described in I-D.selander-ace-coap- underlying TLS using OSCORE resulting in an authenticated self- contained object.  <ins> 7.1. </ins> When using EST RFC7030, the following constraints should be considered: [RFC Editor: please delete] /* TBD: clarification of retry for fullcmc is necessary as not specified in the context of EST */  <ins> 7.2. </ins> Instead of using CMP RFC4210, this specification refers to the lightweight CMP profile I-D.ietf-lamps-lightweight-cmp-profile, as it as specified in section 5.2.4 of I-D.ietf-lamps-lightweight-cmp- profile with delayed enrollment.  <ins> 8. </ins> This document requires the following IANA actions: included for the defined namespaces in addressing and discovery_eo . */  <ins> 9. </ins> The credential used by the registrar-agent to sign the data for the pledge in case of the pledge-initiator-mode should not contain technician operating the device, to avoid revealing this information to the MASA.  <ins> 10. </ins>  <ins> 10.1. </ins> Exhaustion attack on pledge based on DoS attack (connection establishment, etc.)  <ins> 10.2. </ins> Registrar-agent that uses acquired voucher and enrollment response for domain 1 in domain 2: can be detected in Voucher Request IDevID.  Alternatively, the LDevID may be acquired by a service technician after authentication against the issuing CA.  <ins> 11. </ins> We would like to thank the various reviewers for their input, in particular Brian E.  Carpenter, Michael Richardson, Giorgio