I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other comments.

I have previously reviewed this document at its -09 version. The document reads better now and I thank the authors for making the changes. I still have one discussion point to raise.

Section 4.3 says "The Join Proxy SHOULD encrypt this context with a symmetric key known only to the Join Proxy. This key need not persist on a long term basis, and MAY be changed periodically. The considerations of Section 5.2 of [RFC8974] apply."

Section 5.2 of RFC8974 recommends integrity and replay protection of the transported state. Security Considerations section of this document references this and recommends integrity and replay protection as well. However, the example in Section 4.3 talks about a single AES128 block being encrypted and transported as context. This is somewhat inconsistent. I would recommend discussing integrity and replay protection as part of the normative language in Section 4.3 and providing an example following that.

Nits:
- Section 4.2: Introduce acronym JPY upon first usage
- Section 4.3.1: “The pledge_content field must be provided as input to a DTLS library”. Field name is “content”.
- Section 7: “When the communication between JOIN Proxy...". s/JOIN/Join