Hi. 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 last call comments. I believe the document is ready. One main security concern is the reversal of roles that this document introduce, but letting TCP clients act as TLS/SSH servers, and vice versa, is not unheard of. As long as proper peer authentication is performed, and other parts of the security protocols are properly performed, I see no fundamental problem with this. I'm sure some implementations will need to be tweaked to deal with this, and terminology might confusing at times. The 'Security Considerations' section does a good job discussing this, and some other issues too. Two minor questions: 1) Are non-certificate-based TLS out of scope for NETCONF/RESTCONF? I see no discussion of it in this draft, and text in the document implicitly assumes host keys (SSH) or certificates (TLS) are used. Think about TLS-PSK for example, which seems like a relevant idea for embedded devices. This may not be the document to adress this, but if there is work towards that goal already, it might be useful to align this document with that. 2) Section 2 says 'The term "NETCONF/RESTCONF client" can refer to the [RFC6241], Section 1.1 "client".'. Shouldn't this say the term may refer to a RESTCONF client and reference draft-ietf-netconf-restconf? Or is that not intentional? The use of the word 'can' make this text vague to me. The previous section (1.5) says that 'NETCONF/RESTCONF' is an abbrevation for 'the NETCONF or the RESTCONF'. The same comment applies to section 3. Maybe this is a misunderstanding on my side, but the text confused me so it may be useful to resolve. Thanks, /Simon Attachment: signature.asc Description: PGP signature