Draft: draft-ietf-anima-brski-prm

Commentary: 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  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 ca n'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   to include specifics into Draft 
 I made two corrections : pledge - agent to registrar - agent . I ca n'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 .
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.