Change:
I think this is the text we discussed, and can do so again tomorrow.
I accepted the proposal and changed the heading from Applicability to Limitations. As Michael wrote, the statements were rather directed towards examples, in which the approach does not work. I also deleted the last sentence, referring to BRSKI as this may not be an option for the pledge as server. I made two corrections: pledge-agent to registrar-agent. I can't recall if we are including the - or not. [stf] always with ”-“ In general, when I read about applicability, I'd rather that it had more positive hint. I.e. "use this when X,Y,Z is true", while this text tells me to not use it when not-Q. [stf] yes, changed to limitations. CAs may also demand higher security in the registration procedures. Especially the CA/Browser forum currently increases the security requirements in the certificate issuance procedures for publicly trusted certificates. There may be the situation in which the target domain does not offer enough security to operate a RA/CA and therefore this service is transferred to a backend that offers a higher level of operational security. +## Applicability +The mechanisms in this draft presume the availability of the pledge to +communicate with the pledge agent. This may not be possible in Suggested change CAs may also demand higher security in the registration procedures. Especially the CA/Browser forum currently increases the security requirements in the certificate issuance procedures for publicly trusted certificates. There may be the situation in which the target domain does not offer enough security to operate a RA/CA and therefore this service is transferred to a backend that offers a higher level of operational security. +## Applicability +The mechanisms in this draft presume the availability of the pledge to +communicate with the pledge agent. This may not be possible in +constrained environments where, in particular, power must be +conserved. In these situations, it is anticipated that the +transceiver will be powered down most of the time. This presents a +rendezvous problem: the pledge is unavailable for certain periods of +time, and the pledge agent is similarly presumed to be unavailable for Suggested change
See PR for text.
Was included as limitation section. General boundary conditions may also be discussed in architecture documents. Eliot already contacted Brendan Moran to include specifics into Draft
I made two corrections: pledge-agent to registrar-agent. I can't recall if we are including the - or not. In general, when I read about applicability, I'd rather that it had more positive hint. I.e. "use this when X,Y,Z is true", while this text tells me to not use it when not-Q. Proposal to delete the last sentence. As BRSKI-PRM addresses the case in which the pledge is not the initiator, it would be contrary to use it as fallback here. A solution in this case may be that the pledge provides a (physically or other) wakeup function.

Discussion:
transferred to a backend that offers a higher level of operational security. <ins> 3.3. The mechanisms in this draft presume the availability of the pledge to communicate with the registrar-agent. This may not be possible in constrained environments where, in particular, power must be conserved.  In these situations, it is anticipated that the transceiver will be powered down most of the time.  This presents a rendezvous problem: the pledge is unavailable for certain periods of time, and the registrar-agent is similarly presumed to be unavailable for certain periods of time.  In this case, it is recommended that pledges initiate communications directly to the registrar as originally specified in RFC8995. </ins> 4. Based on the intended target environment described in sup-env and the